Questo documento

Un caso concreto di risposta ad un attacco hacker http://escher07.altervista.org Premessa Questo documento è ottenuto come generalizzazione di un caso reale. Sono stati oscurati per ovvi motivi indirizzi IP e nomi delle macchine coinvolte. Lo scenario è quello di un server Web W2K SP4 esposto su internet su cui un attaccante ha potuto salvare sulla root propri file. L’obiettivo del procedimento descritto è stato quello di rendere questa azione non più possibile, cosa che effettivamente è successa. Footprinting In questa sezione si descrivono tutte le operazioni finalizzate alla raccolta di informazioni utili alla definizione precisa del problema. I pentest sono fatti da una postazione “di attacco” che ha le stesse caratteristiche di quella dell’attaccante, ovvero è esterna e non interna alla LAN in cui si trova il server in oggetto.
Scansione MSBA Per prima cosa lanciamo una scansione sul nostro server Web con MSBA. Come dice il suo stesso nome MSBA è più uno strumento di analisi di vulnerabilità (con tecnologia simile a quella di Microsoft Update) che un vero e proprio test : ossia va inteso più come strumento locale o di livello LAN che come strumento di simulazione di attacco esterno. Nel caso specifico ho lanciato MSBA da un PC della stessa sottorete del server con una configurazione di questo tipo (è quella di default): Come si vede ci sono più sezioni. Nella prima relativa a Windows in generale otteniamo questo: A questo proposito visto che si consiglia di installare un aggiornamento sul MSXML lo facciamo. Non cambia per la cronaca nulla. Proseguiamo, allora : nella sezione relativa ad IIS otteniamo quanto segue: Quindi al di là di un paio di configurazioni applicative (disabilitare le sample application e impedire di scorrere verso l’alto l’albero delle directory) che possiamo fare subito velocemente, MSBA consiglia di eseguire IIS Lockdown che è uno strumento con cui vengono eliminati i permessi e le funzionalità “non necessarie” di IIS, di cui potete trovare info ed eseguibili qui: http://www.microsoft.com/italy/technet/security/guidance/secmod113.mspx IIS Lockdown può “chiudere” a vari livelli come si vede dalla seguente maschera: Quindi dobbiamo avere ancora qualche informazioni in più sul tipo di vulnerabilità del nostro server, prima di poter procedere alla cieca e chiudere magari servizi essenziali. Scansione Nessus e Nmap Nessus, al contrario di MSBA è uno strumento di pentest e quindi lo lanceremo dall’esterno sui servizi esposti, in particolare sul WWW. La reportistica dà una notevole serie di informazioni fra cui evidenziamo ad esempio questo specchietto: La cosa più pericolosa sembrerebbero i metodi http aggiuntivi (in particolare PUT e DELETE) oltre alla presenza di WebDav. Queste informazioni possono essere completate dalla scansione con Nmap (sempre lanciata dall’esterno) con queste configurazioni: Profile: Intense scan, no ping
Command: nmap –T4 –A –v –PN www.myhost.com
Importante è il settaggio “no ping”. Infatti il nostro server pur essendo esposto è dietro un firewall che, come tipicamente succede, blocca il traffico ICMP. Senza questa configurazione (ovvero assumendo che se il server non risponde al ping non c’è) otterremo che appunto il server in questione non risponde, cosa appunto non vera (risponde, ma solo sulla 80). Con Ie opzioni di cui sopra il risultato che si ottiene è questo: Analisi dei log A completare il quadro delle informazioni può aiutare anche l’analisi dei log, in questo caso di IIS. I log di IIS si trovano nella cartella mostrata qui: … con questa finestra che è ottenuta dallo Snap In di IIS, facendo “Proprietà” sul sito in oggetto. I log in questiono possono essere analizzati in vario modo. Uno strumento utile è LogParser : un programmino da linea di comando che consente di interrogare questi archivi con un linguaggio simil SQL e ad esempio ottenerne report CSV da analizzare con Excel. In questo caso specifico abbiamo ricavato come informazioni significative l’indirizzo dell’attaccante (correlando la lista IP con la data:ora del file lasciato) e il fatto che questi si è effettivamente servito del metodo PUT come supposto in precedenza. Replica della vulnerabilità Ricapitolando: siamo nel caso un attaccante riesce a carica dei file in un sistema Windows 2000 SP4 con IIS 5.0 e attivi WebDAV e metodi http opzionali. Effettuando ricerche in proposito (google, inj3ctor e così via) si arriva alla seguente ipotesi: NTDLL.DLL Buffer Overrun Vulnerability (MS03-007) on Windows 2000 / IIS5 / WebDAV
Windows 2000 Security Patch: IIS Remote Exploit from ntdll.dll Vulnerability E’ davvero questo l’exploit che il nostro attaccante ha utilizzato? Proviamo noi ad utilizzarlo. E qui entra in gioco Metasploit. Per capire come utilizzarlo e in particolare come il Metasploit Framework “chiama” il nostro exploit utilizziamo l’ottima documentazione in linea, in cui troviamo questo: L’exploit è ciò che viene eseguito per entrare sul server remoto, il payload quello che viene eseguito dopo. In questo caso abbiamo un’unica possibilità di scelta per il payload, che è il reverse TCP (ovvero il tentativo di aprire una connessione Vittima‐>Attaccante, su una porta opportuna in modo da far eventualmente eseguire alla prima codice che si trova sul secondo). Per farla breve possiamo fare la nostra prova specificando solo due informazioni: •
•
l’IP del proprio client [MY IP ADDRESS] l’IP del server che si vuole attaccare [TARGET IP] … cose che si fanno da linea di comando con set. Nel nostro caso otteniamo quanto segue: La sessione rimane appena: la si chiude con ^C. Come si vede l’exploit è stato completato, ma il payload (ovvero la creazione della sessione inversa, avendo scelto il reverse_tcp) non è stato portato a termine. Perché? Un’ipotesi è che essendo necessarie tutte queste condizioni per l’esecuzione completa dell’exploit: •
•
•
NTDLL.DLL a versione <=SP3 Presenza di WebDav Presenza dei metodi http PUT e TRACE … ed essendo il nostro sistema alla SP4 ne è stata possibile solo una parte. Verifichiamo quindi che il nostro file metasploit129512028.txt sia o no sul server digitando: http://www.myhost.com/metasploit129512028.txt Sorpresona: Il file c’è! Quindi questo è più o meno quello che ha fatto il nostro attaccante: ha sfruttato questa vulnerabilità. Non è riuscito ad ottenere una sessione sulla macchina (i file di log sembrano confermarlo) ma è riuscito a caricare dei file. Risoluzione della vulnerabilità Allora, occorre eliminare WebDav ed i metodi PUT e DELETE. Dopo aver verificato col fornitore della applicazione esposta che queste funzionalità non servivano al suo corretto funzionamento possiamo procedere. Ora dai seguenti indirizzi: http://www.klcconsulting.net/articles/webdav/webdav_vuln.htm#How%20to%20detect http://support.microsoft.com/default.aspx?scid=kb;en‐us;Q241520&sd=tech si ricava questo:
WebDAV enabled:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 17 Mar 2003 21:49:00 GMT
Content-Length: 0
Accept-Ranges: bytes
DASL:
DAV: 1, 2
Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND,
PROPPATCH, LOCK, UNLOCK, SEARCH
Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND,
PROPPATCH, LOCK, UNLOCK, SEARCH
Cache-Control: private
WebDAV disabled:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Mon, 17 Mar 2003 21:49:00 GMT
Public: OPTIONS, TRACE, GET, HEAD, POST
Content-Length: 0
Dunque è il WebDAV nel nostro caso, più che il resto, la chiave di tutto. La documentazione di cui sopra mostra modi di disabilitarlo da registro. A me sinceramente non hanno funzionato, mentre ha funzionato la riconfigurazione da IISLockdown. Dopo un po’ di tentativi (IISLockDown + Nmap) sono arrivato a questa impostazione: Con cui si elimina WedDav e si installa uno strumento detto URLscan che applica delle regole di filtraggio alle risposte predefinite di IIS. In questo modo si può verificare che il risultato di Nmap passa da: a: Riprovando con metasploit stavolta otteniamo un output di questo tipo: La figura è al stessa di prima : la differenza è che la sessione è andata giù da sola, senza dover dare il ^C. Per fugare ogni dubbio vediamo, se il file metasploit152114954.txt è stato creato. Otteniamo: Dama. (di fatti da un paio di mesi a questa parte non ci sono più files strani sul nostro server ☺) Disclaimer Al solito non mi assumo responsabilità sull’uso proprio o improprio di questo materiale. Non utilizzate gli strumenti discussi su reti sulle quali non siete stati espressamente autorizzati a farlo. Il presente documento è di carattere divulgativo e generale: la eventuale presenza di informazioni relative ai casi particolari da cui è stata tratta l’ispirazione è frutto di errore materiale : rimane pertanto l’obbligo per chi scarica e/o utilizza questo documento di segnalare eventuali manchevolezze in tale senso e comunque l’obbligo di non utilizzare in alcun modo tali dati inavvertitamente presenti.