Qual è il prossimo passo di questo attacco di caricamento file?

Naviga le tue risposte
16

Ieri ho scoperto che qualcuno aveva caricato questo Codice PHP al mio server come file .jpg tramite il modulo "Carica la tua immagine del profilo" dell'applicazione asp.net MVC. Credo che l'attacco non abbia avuto successo per una serie di motivi (le immagini vengono assegnate a nomi di file casuali, quindi ridimensionate e memorizzate in una directory non di esecuzione). Il file è rimasto in quanto non è riuscito a ripulire il file temporaneo se il ridimensionamento non è riuscito, cosa che ho risolto ora.

Ma mi preoccupa il fatto che non capisco quale sarà il prossimo passo di questo attacco ... Supponiamo che abbia caricato con successo un file .jpg contenente codice PHP dannoso al mio server Windows / IIS, e conosceva l'URL del file. Ora cosa? Avrebbe bisogno di ottenere IIS per interpretare tale file .jpg come codice PHP piuttosto che un'immagine, giusto? Quale potrebbe essere stato il suo piano per raggiungere questo obiettivo?

L'unica cosa che posso pensare è se si trattasse di un server Apache e file .php venivano filtrati ma i file .htaccess non lo erano, forse avrebbe potuto gestirlo. Esiste un approccio equivalente che potrebbe aver funzionato in IIS?

    
posta Jared Phelps 13.03.2013 - 19:27
fonte

3 risposte

14

Un possibile percorso sarebbe cercare di farlo includere in qualche modo. Molti framework aggiuntivi possono eseguire un file di codice PHP arbitrario. Se l'autore dell'attacco era in grado di trovare un tale framework add-on, poteva dargli il percorso del file e sarebbe stato eseguito come PHP indipendentemente dall'estensione del file.

    
risposta data 13.03.2013 - 20:37
fonte
1

È uno script interessante che hai trovato lì. Una cosa che ho notato è che apparentemente servirà le immagini - se hai registrato mod-php per gestire i file .jpg:

Non ho idea di cosa sia questa immagine, ma è una caratteristica interessante.

Ad ogni modo, lo script sembra essere una shell remota. Non sono d'accordo con Manishearth su quasi ogni punto. AJ Henderson ha una risposta molto migliore: indipendentemente dall'estensione del file o dalla posizione in cui è memorizzato, PHP prova per eseguirlo se richiesto. Se l'utente malintenzionato può controllare il percorso di un file incluso, l'autore dell'attacco può eseguire questo script.

    
risposta data 14.03.2013 - 16:35
fonte
1

Finché hai il controllo sul nome del file e su dove è memorizzato 1 , non è un problema. In pratica, potrebbero provare a sostituire un file php esistente, in modo che al successivo avvio venga eseguito il codice.

Un altro trucco che potrebbero provare è forzare il server a eseguire il file. PHP viene eseguito con autorizzazioni che non possono essere ottenute da un hacker tramite il normale HTTP. L'autore dell'attacco può caricare foo.php e il tuo server lo sposterà su images/foo.php . Ora, l'attaccante visita la pagina. Questo può essere prevenuto controllando il nome del file (di nuovo) e / o impostando il tuo .htaccess per disabilitare PHP nella directory delle immagini.

Devi essere particolarmente attento a questo quando il tuo sito è nella forma in cui la visualizzazione di una pagina del modulo run.php?name=abc.php visualizzerà o includerà 'abc.php'. In tal caso, mantenere le restrizioni sul parametro GET in modo che sia possibile eseguire solo determinati file. Questo vale per qualsiasi parte della tua applicazione che include o esegue alcuni file PHP in base all'input dell'utente. Esamina questi elementi e assicurati che l'utente non possa forzare il sistema a eseguire un file all'esterno di quelli che desideri eseguire.

1 Questo include impedire loro di ottenere il file salvato come ../../foo.jpg o (shudder) ../index.php

    
risposta data 13.03.2013 - 20:49
fonte

Leggi altre domande sui tag

Un modo standard per aggiungere manualmente una firma digitale a un file PDF? XKCD # 936: in base a quali supposizioni ci sono 1000 ipotesi / secondo su una rete plausibile?