Forensics : un cas réel d’intrusion

Dans le cadre de notre activité, un client, dont le serveur web semblait suspect, nous a demandé de réaliser une investigation de l’un de ces serveurs.

Description du système:

Le système analysé est un Linux Ubuntu hébergeant une application web accessible sur Internet et déployé via Apache. Le serveur est une VM hébergée sur un ESX 3.0.
Quelques mois auparavant, nous avions procédé à un autre Forensic d’une de ces VMs (serveur), et nous avons découvert que le système était compromis. Le hacker a profité d’un vieux phpMyAdmin, accessible et non sécurisé (voir http://www.exploit-db.com/exploits/8921).

Malheureusement, notre client utilise le même mot de passe pour toutes les VMs présentes sur cet ESX, ce qui a certainement joué un rôle dans tout cela.

Travail sur un clone

La machine compromise est installée sur un ESX, nous n’avions donc qu’à cloner cette VM pour l’analyser. Dans le cas contraire nous aurions été contraints de préparer une autre machine distante qui aurait reçu les résultats des analyses tout comme les fichiers corrompus.

En effet un rootkit ou des binaires modifiés (ls, cd, netstat…etc.) peuvent être présents, faussant ainsi les résultats. Dans notre cas nous pouvons travailler tranquillement à l’analyse sans nous soucier de modifier le système grâce aux snapshots.

Les étapes d’un Forensic sont longues et dépendent du système à analyser. Nous allons dans cet article présenter les étapes les plus importantes.

Premières étapes

Premièrement, une analyse des logs et des fichiers clés nous permet de restreindre l’étendue des recherches et d’établir les premières pistes.

Voici quelques points qui pourraient vous être utiles :

• le fichier /etc/passwd contient une entrée laissant penser à l’infection du système par un bot IRC.

• Nous remarquons aussi que que le fichier log  /var/log/secure est très volumineux (700MB), son analyse révèle une attaque de type brute force sur ssh(22) et ftp(21).
• Autre point suspect, le fichier history du compte root est vide.

On peut vérifier alors le contenu de /var/log/auth, pour voir les dernières connexions. Cela dit, si l’intrus a pensé à effacer l’historique, il a certainement pensé aussi à effacer ses traces.

Nous n’avons pu trouver aucune trace dans les logs qui ont peut être été nettoyés par un éventuel pirate. Par conséquent, nous avons supposé la présence d’un rootkit sur le serveur.

Une étape nécessaire fut donc de passer cette Ubuntu aux analyseurs de rootkit et Antivirus connus à savoir : ·

• Chkrootkit
• Rkhunter
• ClamAV

L’exécution des ces « anti-rootkit » et Antivirus n’a pourtant rien donné. La détection de binaires modifiés reste une étape fastidieuse (c’est dans ces moments que nous apprécions l’importance des logiciels tel que Tripwire ou Samhain pour le contrôle d’intégrité des fichiers, et qui nous alertent lors de la modification de ceux-ci).

Nous avons poursuivi notre recherche via l’étude des différents processus.
#netstat -lantp

A la vue de ce screenshot , l’application utilisant le port 22(ssh) est de toute évidence une piste à creuser à cause des caractères non imprimables affichés à l’écran.

La commande « lsof -in » révélait le même résultat, d’autant que l’emplacement du binaire était buggé/crypté. Il suffit alors de chercher le pid dans /proc/PID et exécuter ensuite « ls -al » pour avoir l’emplacement exacte.

La découverte

Le démon SSHd est probablement vérolé, mais nous devons le prouver !

Nous notons que la version affichée est OpenSSH_4.3p2 Debian-8ubuntu1.1, qui est la plus récente sur cette plateforme à cette date.

A notre connaissance, il n’existe pas de backdoor spécifique à cette version : il s’agit donc sans doute d’un « vieux » code source de Backdoor SSH, modifié pour inclure une bannière actuelle, et qui a ensuite été repackagé.

Nous remarquons que la taille du binaire (2.3M) est nettement supérieure à un sshd normal (~ 500k) obtenue sur une installation saine réalisée en laboratoire dans une version d’OS identique.

Les bibliothèques linkées sont ,elles aussi, différentes : ce sshd2 est certainement un binaire compilé (majoritaire statiquement) sur un autre système, que le hacker a juste déposé sur le serveur et a exécuté.

L’avantage ce cette méthode est qu’il n’a eu besoin sur la machine compromise ni d’un compilateur ni des librairies nécessaires : tout est dans le binaire ! (d’où le nom de kit)

L’inconvénient (pour le pirate) de cette méthode est un avantage pour nous : la taille du binaire a éveillé nos soupçons !

D’ailleurs nous ne sommes pas les premiers sur Internet à avoir remarqué cette anomalie (cf http://jhodges.co.uk/ssh-unknown-option-t/).

Detection des flux réseaux entrants et sortants

Supposant qu’il existe un canal de communication entre le serveur compromis et le pirate. Nous commençons par mettre des règles iptables qui vont permettre de logger les nouvelles connexions qui pourraient éventuellement être établies, comme l’envoi des mots de passe des utilisateurs qui se connectent ou alors une simple notification.

(Nous observerons effectivement des paquets RST lorsque nous « killerons » le process SSHd, alors que cette connexion TCP n’était pas visible sur le système).

#iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.10.0/24 anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
LOG tcp -- anywhere anywhere
LOG level warning
LOG udp -- anywhere anywhere
LOG level warning
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.10.0/24
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
LOG tcp -- anywhere anywhere
LOG level warning
LOG udp -- anywhere anywhere
LOG level warning

Chaque nouvelle connexion sera enregistrée dans le fichier /var/log/kern.log.

Analyse du Backdoor SSH

L’analyse d’un binaire est une étape délicate, qui prend du temps. Plusieurs types d’analyses peuvent être effectuées comme l’analyse de l’exécution du binaire en temps réel et voir comment il se comporte suivant différents évènements.

Dans notre cas nous avons commencer en analysant les chaînes de caractères présentes dans le binaire via la commande «strings». En effet, ayant déjà analysé quelques types de Backdoor SSH, nous savons par expérience que cette recherche pourrait donner des résultats probants.

Nous nous lançons donc dans la recherche des chaînes de caractère suspectes. Deux chaînes (parmi les milliers de lignes présentes) attirent notre attention :

Nous consultons le contenu du fichier /etc/sinux  …

Bingo ! Celui-ci est la liste de tous les utilisateurs qui se sont connectés sur le système (avec mot de passe, adresse IP source et heure de connexion).

Par déduction, cela nous permet d’évaluer la date de compromission.

Le principe de la plupart des backdoor SSH est de permettre au hacker de se servir d’un mot de passe dit Magic (dans le cas présent « bluechamp1835« ), qui lui permet de se connecter au serveur sans que son activité ne soit inscrite sur aucun des fichiers de logs mais aussi de cacher sa présence, et en la rendant indétectable via les commandes (w, who…etc.)

Effectivement le compte root/bluechamp1835 permet bien de se connecter en SSH…

Un md5sum du fichier binaire nous donne:

#md5sum /usr/sbin/sshd2
39066f0dc8590d7243bc011127e907a1 /usr/sbin/sshd2

Au final, seul sshd et quelques autres fichiers (sftp…etc.) semblent avoir été modifiés. Malheureusement, nous ne pouvons pas en être certains. Le système a été compromis en tant que root, cela veut dire que le pirate a pu modifier n’importe quel binaire présent.

Nous recommandons, dans ce cas, la réinstallation du système. L’analyse de tous les binaires prendrait beaucoup plus de temps/argent que sa réinstallation, mais elle est surtout plus sûre.

Conclusions

Le travail de Forensic doit s’effectuer sur une copie du système (dd, ghost).

Dans notre cas, l’utilisation d’une VM à été très utile. (Configuration d’un environnement similaire)

L’utilisation de scans (Anti-virus, anti-rootkit…) n’est qu’une première étape.

Une vérification manuelle, rapide et efficace est nécessaire. Avoir un contrôleur d’intégrité de type iWatch/Samhain/Tripwire qui surveillera les fichiers système et nous alertera en cas de changement devient de plus en plus important.

Cela révèle une fois de plus l’importance de l’association d’un firewall bien configuré à des mises à jour régulières.

L’OS dans notre cas présent n’était pas à jour et les règles iptables vides.

Derniers rappels, bien connus mais importants,

• changer le port d’écoute de SSHd permet d’éviter les scans permanents,
• mettre en place un système anti brute-force (type fail2ban) qui élimine ce type d’attaque et facilite l’analyse des logs.
• utiliser des clefs RSA et désactiver l’authentification SSH par mot de passe

Enfin, de manière générale, on observe une recrudescence des attaques. Celle-ci a été faite par un pirate discret, qui n’a été détecté que parce qu’il utilisait un binaire générant des caractères à l’affichage…

La signature de ce binaire n’est pas présente sur Internet : le hacker a sans doute recompilé lui-même les sources en modifiant les paramètres importants (probablement le mot de passe Magic et le fichier de stockage des login/passwords interceptés). On n’est donc plus tout à fait dans le cas typique d’un script-kiddie…

On peut également imaginer les dégâts si les mots de passe d’un utilisateur ayant des droits élevés sont répliqués sur plusieurs machines du même réseau…

Sans notre intervention, le hacker serait resté présent sur le système, qui aurait été inclus dans un botnet (réseau de machines zombies), dont l’usage est loué à toutes sortes d’activité illicites (DDOS, spam, etc..).

Cette prestation a été réalisée dans le cadre de notre offre Forensic, d’audit sécurité suite à une intrusion.

Les commentaires sont fermés.