Les analystes de virus et les chercheurs en sécurité informatique s'efforcent de collecter autant d'exemplaires que possible de nouveaux botnets. Pour leurs objectifs, ils utilisent des honeypots.… Mais que faire si l'on souhaite observer un malware dans des conditions réelles ? Mettre son propre serveur ou routeur en danger ? Et si l'on n'a pas de dispositif approprié ? Ces questions m'ont conduit à créer bhunter — un outil pour accéder aux nœuds des botnets.

L'idée principale

Il existe de nombreuses façons de propager des malwares pour étendre les botnets : allant du phishing à l'exploitation de vulnérabilités 0-day. Cependant, la méthode la plus répandue reste encore l'attaque par force brute des mots de passe SSH.

L'idée est très simple. Si un nœud du botnet essaie de deviner les mots de passe pour votre serveur, il est fort probable que ce nœud ait lui-même été compromis par la méthode du mot de passe simple. Alors, pour accéder à lui, il suffit de répondre par la « réciprocité ».

C'est exactement comme cela que fonctionne bhunter. Il écoute le port 22 (service SSH) et collecte tous les identifiants et mots de passe avec lesquels des tentatives de connexion sont effectuées. Ensuite, en utilisant les mots de passe collectés, il essaie de se connecter aux nœuds attaquants.

Algorithme de fonctionnement

Le programme peut être grossièrement divisé en deux parties principales, qui fonctionnent dans des threads séparés. La première — honeypot. Elle traite les tentatives de connexion, collecte les identifiants et mots de passe uniques (dans ce cas, la paire identifiant + mot de passe est considérée comme un tout), et ajoute à la liste les adresses IP qui ont tenté de se connecter pour une attaque ultérieure.

La deuxième partie est directement responsable de l'attaque. L'attaque se déroule en deux modes : BurstAttack (attaque en queue) — permutation des identifiants et mots de passe d'une liste commune et SingleShotAttack (attaque par tirs uniques) — permutation des mots de passe utilisés par le nœud attaqué, mais qui n'ont pas encore été ajoutés à la liste commune.

Pour avoir au moins une base d'identifiants et de mots de passe dès le lancement, bhunter est initialisé avec une liste provenant du fichier /etc/bhunter/defaultLoginPairs.

Interface

Plusieurs façons de lancer bhunter sont prévues :

Simplement avec la commande

sudo bhunter

Avec ce lancement, il est possible de contrôler bhunter via son menu texte : ajouter des identifiants et mots de passe pour l'attaque, exporter la base d'identifiants et de mots de passe, spécifier l'objectif de l'attaque. Tous les nœuds compromis peuvent être vus dans le fichier /var/log/bhunter/hacked.log

En utilisant tmux

sudo bhunter-ts # commande pour lancer bhunter via tmux  
sudo tmux attach -t bhunter # nous connectons à la session dans laquelle bhunter est lancé

Tmux est un multiplexeur de terminal, un outil très pratique. Il permet de créer plusieurs fenêtres dans un même terminal et de diviser les fenêtres en panneaux. En l'utilisant, vous pouvez quitter le terminal puis revenir sans interrompre les processus lancés.

Le script bhunter-ts crée une session tmux et divise la fenêtre en trois panneaux. Le premier panneau, le plus grand, contient un menu texte. Le coin supérieur droit contient les journaux du honeypot, où vous pouvez voir les messages concernant les tentatives de connexion sur le honeypot. Le panneau inférieur droit affiche des informations sur l'évolution des attaques sur les nœuds des botnets et sur les piratages réussis.

L'avantage de cette méthode par rapport à la première est que nous pouvons fermer le terminal sans problème et y revenir plus tard, tout en permettant à bhunter de continuer à fonctionner. Pour ceux qui ne sont pas très familiers avec tmux, je propose ce mémo.

En tant que service

systemctl enable bhunter
systemctl start bhunter

Dans ce cas, nous activons le démarrage automatique de bhunter au démarrage du système. Dans cette méthode, l'interaction avec bhunter n'est pas prévue, et la liste des nœuds piratés peut être récupérée à partir de /var/log/bhunter/hacked.log

Efficacité

Au cours de mon travail sur bhunter, j'ai réussi à trouver et accéder à des appareils très variés : raspberry pi, routeurs (en particulier mikrotik), serveurs web, et une fois à une ferme de minage (malheureusement, l'accès à celle-ci était de courte durée, donc je n'ai pas eu d'histoire intéressante). Voici une capture d'écran du programme montrant la liste des nœuds piratés après plusieurs jours de fonctionnement :

Malheureusement, l'efficacité de cet outil n'a pas atteint mes attentes : bhunter peut passer plusieurs jours à tenter de deviner des mots de passe sans succès, mais peut également pirater plusieurs cibles en quelques heures. Cependant, pour un flux régulier de nouveaux échantillons de botnets, cela suffit.

L'efficacité est influencée par des paramètres tels que : le pays où se trouve le serveur avec bhunter, l'hébergement, et la plage à partir de laquelle l'adresse IP est assignée. D'après mon expérience, il y a eu un cas où j'ai loué deux serveurs virtuels chez le même hébergeur, et l'un d'eux a subi des attaques de botnets deux fois plus souvent.

Bugs que je n'ai pas encore corrigés

Lors de l'attaque de nœuds infectés, il y a des situations où il est difficile de déterminer si le mot de passe a fonctionné ou non. La journalisation de ces cas est effectuée dans le fichier /var/log/debug.log.

Le module Paramiko, utilisé pour travailler avec SSH, se comporte parfois de manière incorrecte : il entre dans une attente infinie de réponse du nœud lorsqu'il essaie de s'y connecter. J'ai expérimenté avec des minuteurs, mais je n'ai pas obtenu le résultat souhaité.

Sur quoi d'autre devons-nous travailler ?

Nom du service

Selon le RFC-4253, le client et le serveur échangent des noms de service mettant en œuvre le protocole SSH avant d'établir la connexion. Ce nom se trouve dans le champ « SERVICE NAME », présent à la fois dans la requête du client et dans la réponse du serveur. Ce champ est une chaîne, et sa valeur peut être détectée en utilisant Wireshark ou Nmap. Voici un exemple pour OpenSSH :

$ nmap -p 22 ***.**.***.** -sV
Démarrage de Nmap ...
PORT   ÉTAT SERVICE VERSION
22/tcp ouvert  ssh     <b>OpenSSH 7.9p1 Debian 10+deb10u2</b> (protocole 2.0)
Nmap terminé : 1 adresse IP (1 hôte actif) analysée en 0.47 secondes

Cependant, dans le cas de Paramiko, ce champ contient une chaîne du type « Paramiko Python sshd 2.4.2 », ce qui peut repousser les botnets qui incluent « l'évitement » des pièges. Je considère donc nécessaire de remplacer cette chaîne par quelque chose de plus neutre.

Autres vecteurs

SSH n'est pas le seul moyen de gestion à distance. Il y a aussi telnet, rdp. Il vaut la peine de s'y intéresser également.

Extension

Il serait formidable d'avoir plusieurs pièges dans différents pays et de collecter de manière centralisée les identifiants, mots de passe et nœuds compromis dans une base de données commune.

Où télécharger ?

Au moment de la rédaction de cet article, seule une version de test est disponible pour téléchargement à partir de du dépôt sur Github.

Source : habr.com