Chasse aux malwares sous GNU/Linux

1. Les honeypots

Une des techniques de découverte de codes malveillants les plus intéressantes est l'utilisation des honeypots, ou pots de miel en français. Les honeypots [1] sont des logiciels servant de leurre afin d’appâter des attaquants qu'ils soient des humains ou des bots, dans un environnement cloisonné.

Cette technique va nous permettre d’observer une attaque, de recueillir des traces et surtout des échantillons, afin de comprendre comment un pirate agit et quel est son but.

Il existe trois types d’honeypots :

- À faible interaction : ce sont les plus simples à utiliser. Ils visent à émuler un ou plusieurs services. On peut évoquer des projets comme dionaea [2]et honeyd [3].

- À haute interaction :  dans ce cas, le service ne sera plus émulé. On peut, par exemple, utiliser une VM équipée d’un vrai serveur SSH, très mal configuré, avec un mot de passe root faible, et puis attendre... Évidemment, il faudra bien faire attention au cloisonnement de cette VM pour éviter tout dégât collatéral sur votre environnement de travail : que la machine serve de relais, par exemple, pour d’autres attaques en interne ou externe, comme des attaques de type DDoS. Pour consulter les logs une fois la machine piratée, un outil d’administration système bien pratique est sysdig [4].

- À interaction moyenne :  c'est un compromis entre les deux types précédents. Il sera fondé sur la mise en œuvre de vrais-faux services dans une prison virtuelle, via un jail ou chroot. Comme pour le type précédent, il faudra s’assurer que la sécurité de la machine hôte soit parfaitement opérante. Pour émuler un service SSH, on se tournera vers des logiciels comme Kojoney [5], Kippo [6] et le petit nouveau Cowrie [7] un fork de Kippo.

2. Cowrie

Étant le plus récent (Kippo n’est plus maintenu depuis 2010 et Kojoney depuis 2006), je me suis penché sur Cowrie dont une version alpha est sortie en août 2015. Elle est parfaitement fonctionnelle et corrige en outre certains défauts de Kippo. Je citerais deux  exemples : le fait que  sous Kippo une simple commande echo -n test affichera -n test ce qui permettra à l’attaquant de détecter la présence du honeypot. De même, un ping 999.999.999.999 répondra... Sans compter que des scripts Metasploit [8][9]ont été écrits pour automatiser ce genre de détection.

Passons à l'installation : côté matériel, un simple Raspberry Pi conviendra très bien, peu de ressources étant nécessaires. Il faudra seulement installer une base de données MySQL et un serveur Web Apache, lighttpd ou Nginx, selon sa préférence.

Cowrie s'installe depuis son dépôt GitHub. Sa configuration repose sur le fichier cowrie.cfg. Il est possible de choisir différentes options, comme le port d’écoute, le hostname, déterminer les identifiants de connexion à la base de données, etc. La liste des couples login/password que l'on souhaite autoriser ou activer, est stockée dans le fichier data/userdb.txt.

Son lancement est simple et s’effectue avec une simple exécution d’un script start.sh. Ne pas oublier cependant au préalable d’activer une règle iptables pour forwarder le trafic sur le port 22 (Cowrie écoute par défaut sur le port 2222). Les attaquants ne prenant que rarement le temps de scanner tous les ports pour trouver un serveur SSH, laisser la configuration par défaut nous expose à ne pas voir passer grand-chose. Il est donc préférable de se mettre en écoute sur le port standard, et aussi d’activer la redirection de port depuis votre routeur Internet. On évitera également de lancer Cowrie en tant que root, celui-ci pouvant être victime, comme tout logiciel, de failles de sécurité.

Évidemment, un environnement simulé ne possède pas toutes les fonctionnalités d'un vrai système d'exploitation ; seules quelques commandes shell, parmi les plus courantes, sont présentes. Il suffira de taper « env » pour avoir un « command not found » en retour et ainsi détecter la présence de notre honeypot.

Cependant, il est possible d'ajouter à la liste des commandes de base, des commandes simples dans un fichier texte qui sera inclus dans le dossier txtcmd. Il suffira alors d'écrire ce que l'on veut que la commande renvoie pour donner à l’attaquant l’impression qu’il dialogue avec un vrai service.  

Pour des commandes plus complexes, il est possible d'utiliser des scripts Python dans le dossier cowrie/commands.

Les logs sont au format JSON et texte brut dans les fichiers log/cowrie.json et log/cowrie.log, puis dans la base de données MySQL si celle-ci est activée. Une interface Web très complète a déjà été développée, kippo-graph [10], avec de jolies statistiques sur les attaques par pays, IP et la possibilité de rejouer les attaques via playlog. Facile à installer, c'est une simple archive tgz contenant notamment un fichier de configuration config.php dans lequel il faut entrer les identifiants de la base de données.

Et voilà ! Il ne reste plus qu’à attendre que le poisson morde à l'hameçon.

Et cela arrive assez vite : au bout de quelques heures, on peut déjà constater les premières attaques. La plupart  se résument à des tentatives de bruteforce SSH, ou quand il y a une connexion réussie, à des passages de simples commandes shell. Mais parfois un bot ou un humain passe par là et lance des commandes plus intéressantes.

Pour visualiser les logs sans se casser la tête, Kippo-graph génère des jolis diagrammes. Ne pas oublier pour l'utiliser de mettre les droits d'écriture sur le dossier kippo-graph/generated-graphs, car c'est à cet emplacement que le logiciel va y écrire les images des diagrammes.

Les figures suivantes donnent quelques exemples des statistiques sur une période d'analyse d'environ deux mois.

La partie la plus intéressante de ces graphes, ce sont les fichiers téléchargés sur la figure 2, pas loin d'une trentaine durant la période d'analyse. Ce sont très souvent des scripts shell servant à automatiser le téléchargement d'autres binaires, ou alors des bot IRC codés en Perl ou Python qui infecteront le serveur.

3. Radare2

Analysons la première avec Radare2 [11].

Initialement, Radare était un éditeur hexadécimal ; puis à force de rajouter de nouvelles fonctionnalités,  il est devenu un framework de reverse engineering open source complet, supportant un nombre imposant d'architectures (x86, ARM, PowerPC…) et de formats de fichiers exécutables (PE, ELF, COFF, DEX...). Il peut être considéré comme une alternative à des solutions comme gdb et même IDA. La liste de toutes ses fonctionnalités est trop longue pour être énumérée ici, il peut même être utilisé pour le développement d'exploits (recherche de chaînes ROP), ou la construction de shellcode, tout comme Metasploit.

Voici quelques commandes utiles :

Analyse statique

Analyse dynamique

4. Analyse d'attaque

Sur la figure 2 (attaque numéro 27), on peut voir que l'attaquant a téléchargé un script shell  via la commande wget. Cowrie l’a sauvegardé automatiquement pour nous dans le dossier dl.

Comme nous pouvons le voir sur la capture, notre script shell télécharge douze binaires dans /tmp (j'ai volontairement supprimé plusieurs lignes par souci de place), leur attribue les droits d'exécution puis les exécute à la suite.

Ces derniers binaires n'ayant pas été téléchargés automatiquement par Cowrie, il faut le faire manuellement pour les analyser ensuite.

Il s'agit d'exécutables au format ELF compilés chacun pour une architecture spécifique (x86, amd64, ARM, ia64...). Une recherche à partir de leur hash MD5 sur VirusTotal, une règle YARA ou un scan avec ClamAV  va nous permettre d'identifier à quel type de malwares nous avons affaire. Il s'agit d'un exemplaire de code malveillant bien connu, Linux/Bash0day ou Linux.Gafgyt.

Nous allons nous pencher sur le binaire 8 (MD5 : ca2fa3de6da0dfe579410f76cad26fcc) compilé pour l'architecture x86. La commande rabin2 nous permet d'afficher quelques informations le concernant ainsi que le point d'entrée.

Le binaire est lié statiquement, ce qui explique sa taille (160Ko) et n'est même pas strippé.

Jetons un œil du côté des chaînes de caractères présentes. Cela peut nous donner quelques indications sur son comportement.

Avec cette vue, nous avons déjà l'adresse IP d'un serveur (192.3.207.242 port : 7632), une liste de ce qui semble être des logins et des mots de passe, des commandes envoyées au botnet, puis une ligne de commandes shell comme lors du premier script, et donc pas même de signes d'un packer. Avec toutes ces informations, nous en savons donc déjà beaucoup sur son comportement !

Une chaîne de caractères intéressante est echo -e '\147\141\171\146\147\164'. Cette commande va aussi servir à notre malware à détecter s’il est exécuté sur un honeypot ou pas. Dans l'exemple ci-dessous, la commande est exécutée dans un shell classique.

Puis ensuite, on peut voir le résultat de cette même commande sur le honeypot ou dans une busybox, elle va afficher le nom de la famille du malware.

Jetons un œil au binaire : pour une analyse statique, il faut l’ouvrir avec la commande r2 ./8 (r2 -d $BINAIRE pour une analyse dynamique). Au lancement, on se trouve dans un shell positionné automatiquement à l'entry point. On rentre aaa pour que Radare effectue une analyse ; fs nous affichera le nombre de chaîne de caractères et de symboles ; afl nous affichera les noms et adresses des fonctions, assez nombreuses dans ce cas précis, car il s'agit d’un binaire statique. Pour obtenir de l’aide sur une commande, il faut la faire suivre d’un point d’interrogation. L’aide sur la commande f sera obtenue en tapant f?.

Parmi les fonctions intéressantes, on trouvera notamment :

Au départ, dans la fonction main, le programme va appeler la fonction getOurIP, pour faire une connexion vers le serveur DNS de Google 8.8.8.8 port 53 afin de tester la connexion ; puis il va lire le fichier /proc/net/route afin de récupérer l'adresse de la passerelle, et le nom de la première interface réseau affichée.

Ensuite, via un appel à ioctl, il récupérera l'adresse MAC afin d'identifier notre machine, comme montré dans la figure 3, ou l'on peut voir un exemple de graphique sous Radare2.

Plus loin, la fonction StartTheLelz sera appelée : il ouvrira une connexion sur le port 23 (0x17) et chargera la liste des identifiants et mots de passe compilés en dur, puis tentera un attaque par force brute.

Notre malware cherchera donc à avoir un accès à notre routeur, et générera via la fonction getRandomIP et getRandomPublicIP de nouvelles adresses à scanner.

D'autres fonctions comme getBogos et getCores vont lire le fichier /proc/cpuinfo pour voler des informations sur l'architecture de la machine: nombre de cœurs, fréquence du CPU, etc.

Ensuite la fonction processCmd dans la figure 4 servira à communiquer avec le c&c.

Commandes utilisées par le bot :

Si vous voulez voir d'autres analyses de malwares Linux, je vous invite à aller sur le site de l'équipe Malware Must Die [12].

5. Beer Persistent Threat

Voici un second exemple collecté par Cowrie. Il s'agit d'une archive tar nommée flood.tar.gz (hash: 847177b71a4db6c071cdc711d0d9ad46) contenant une nouvelle fois un script bash nommé flood (hash: 2266b094df55630e77fa6739a7579683) et une trentaine de binaires dans un dossier bin.

Le script prend en paramètre un nom d'hôte/adresse IP et un type d'attaque parmi les 23 au choix lançant chacun un des binaires du dossier bin. Tous exploitent des vieilles failles sur Windows9x et 2000 ainsi que des attaques DoS.  

Au hasard, jetons un œil au binaire bin/beer :

Comme précédemment, affichons les chaînes de caractères contenues dans le malware une fois servi bien frais dans Radare :

Ok, c'est donc notre cher Cyranix0r qui doit être un amateur de la Vores Øl, une bière danoise open source [13].

Décapsulons ces fonctions :

Deux fonctions, pas de quoi se mettre la pression. Pour faire simple, car ce malware est vraiment bidon, la fonction alcohol, sur la figure 5, appelle la fonction beer en boucle avec le nombre d'itérations passées en paramètre au lancement du binaire, donc 100 dans notre cas.

Et la fonction beer va établir une connexion vers l’hôte distant. On a donc un DoS basique. La famille de ce binaire est connue sous le nom de Linux.Alcohol.a. Ça ne s'invente pas !

Conclusion

Pendant deux mois d'analyses, j'ai collecté plusieurs binaires, mais ce sont toujours les mêmes familles qui reviennent (Linux/XOR.DDOS, Linux/Billgates, Linux/Tsunami, Bash0day…), avec souvent les mêmes fonctionnalités, DoS, bruteforce d'interface d'administration... Comme dans le cas étudié ici, ils ne sont pas compliqués techniquement, et ne posent pas vraiment de problèmes pour être analysés. Lorsqu’on découvre un binaire compressé avec UPX, c’est vraiment le bout du monde… Cependant, ils restent didactiques pour qui veut se faire la main en reverse d'exécutables Linux.

Remerciements

Je tiens à remercier Matthieu Aubigny pour la relecture, Maxime Morin @Maijin212 pour ses aides sur Radare2, ainsi que Paul Rascagneres @r00tbsd pour tous ses coups de main et conseils.

Références

[1] Le projet Honeynet : https://www.honeynet.org/project

[2] dionaea : http://dionaea.carnivore.it/

[3] honeyd : http://www.honeyd.org/

[4] sysdig : http://www.sysdig.org/

[5] kojoney : http://kojoney.sourceforge.net/

[6] kippo : https://github.com/desaster/kippo

[7] cowrie : https://github.com/micheloosterhof/cowrie

[8] Detecting kippo : http://morris.guru/detecting-kippo-ssh-honeypots/

[9] Script Metasploit : http://www.rapid7.com/db/modules/auxiliary/scanner/ssh/detect_kippo

[10] Kippo-graph : https://bruteforce.gr/kippo-graph

[11] Radare2 radare.org : https://github.com/radare/radare2

[12] http://blog.malwaremustdie.org/

[13] https://fr.wikipedia.org/wiki/Vores_%C3%98l