Bucare O Entrare In Un Sito Internet. Resoconto Di Un Attacco

Basta poco per rendere vulnerabile ad attacchi il proprio sito e, nella peggiore delle ipotesi, anche il server dove risiede. E’ quello che è successo con uno fra i più grandi gruppi editoriali siciliani, gestore di un server che, come faccio notare in questo articolo, risulta fortemente vulnerabile.

Possibili siti che potevano essere coinvolti in un reale attacco? oltre 151!

Mi sono premurato di correggere il bug sui server dell’editore prima di pubblicare questo articolo. Oggi, 05 Giugno, il provider ringrazia ;-)

1 Giugno, ore 22:00 Il tutto inizia in una chat dove un certo Francesco [nome fittizio], non avendo nulla da fare, mi rivolge delle offese, mostrandomi il suo sito. Bene, apro il mio fido Notrace.it, per avere maggiori informazioni sul dominio. E’ gestito dal noto editore siciliano. Vedo che monta dBlog 1.4.

Il sito di Francesco

1 Giugno, ore 23:00 Vado a letto [Fate finta che questo punto non ci sia, ma mi era d'obbligo inserirlo]

2 Giugno, ore 10:00 Mi ritorna in mente una vulnerabilità da me scoperta in dBlog nell’Agosto 04 per entrare nell’amministrazione del blog di Francesco. Cerco l’exploit nella cartella D:\Progetti\hacking, lo apro e lo eseguo.

Apro l’exploit

Eseguo l’exploit

2 Giugno, ore 10:05 Sono entrato nell’amministrazione dal blog. Ben lungi da azioni lameresche/defaceresche, mi limito solo a dare una occhiata. Vedendo la funzione “Upload”.

L’admin del blog

3 Giugno, ore 21:00 Ripenso al blog di… Francesco, rientro nell’amministrazione e do uno sguardo alla sezione “Upload”. Voglio provare a caricare uno scriptino ASP per prendere il controllo del server [umm... non avevo che fare]. Entrando nell’upload vedo che non ci sono limitazione ai file da caricare.

Seleziono dal mio PC l’exploit controllo.asp [che nome suggestivo!]. Clicco su Upload. Il file viene caricato.

Upload del file controllo.asp

Exploit caricato

3 Giugno, ore 21:15 Entro in http://www.sitodifrancesco.it/public/controllo.asp. Bingo! Nessuna limitazione da parte di IIS posso girare liberamente fra i file del server.

L’hardisk del server

3 Giugno, ore 21:18 Provo a cercare i siti web ospitati dal server nella cartella C:\inetpub\, ma niente. Mi viene un lampo di genio: provare a vedere se esiste l’unità D:\. L’unità esiste ed è presente la pomposa cartella sitiweb. [lascio indovinare a voi cose c'è dentro]

L’unità D:\

3 Giugno, ore 21:19 Clicco sulla cartella sitiweb. Mi vengono mostrati liberamente tutti i siti che risiedono nel server. I siti dovrebbero essere più e meno 151, da come si evince dal numero di sottocartelle (una sottocartella = un sito).

I siti web hostati dal server

3 Giugno, ore 21:21 Provo a vedere se ho accesso libero ai vari siti. Provo con la prima cartella. IIS mi fa entrare tranquillamente. Provo quindi a scrivere un file (la pagina messaggio.htm).

Creo un file sul server

3 Giugno, ore 21:23 Dopo due esitanti minuti, il sobrio messaggio “File scritto” mi informa che il file è stato creato. Andando nell’indirizzo del sito e /messaggio.htm, difatti questo esiste.

Il file creato sul server

3 Giugno, ore 21:25 Elimino quindi il file creato, ed il mio tool, richiamando “controllo.asp?operazione=toolcancella”

Il mio tool non esiste più sul server

3 Giugno, ore 21:30 Contatto l’editore, segnalando di aver testato l’(in)sicurezza dei loro server e dicendo loro di aver lasciato intatti i log, in modo da far capire la modalità di attacco utilizzato. Francesco intanto diventa “buono”.

Come avete capito, non ho fatto alcun danno. Ma penso ad un defacer: potrebbe superare le protezioni, caricare un file ASP che sostituisca tutte le home page o che cancelli tutto.

Questo “passo a passo” non vuole essere un incitamento a fare danni, ma, solamente, vuole far notare come una web application scritta male può favorire l’attacco ad un sito web (avrei potuto inserire messaggi nel blog) oltre che a prendere il pieno controllo del server.

Ciò che risulta imperdonabile è l’assenza di limitazioni da parte di IIS (che è stato configurato male) e la presenza di permessi di scrittura/modifica/eliminazione ovunque.