Blog Home Topics: DDoS , IoT , PDoS

Chatter avec les bots IoT

août 01, 2017 | Radware
Chatter avec les bots IoT

Auteur : Pascal Geenens, Radware Ltd – @geenensp

Après l’attaque du prestataire Dyn par Mirai en octobre 2016, nous savions qu’un tournant s’opérait et que l’environnement des menaces DDoS allait se transformer pour les mois, voire les années à venir. L’Internet des objets (IoT, Internet of Things) était voué à devenir une part importante de ce nouvel environnement. Après l’attaque, l’état de sécurité peu satisfaisant de l’IoT et le caractère simple des botnets exploitant les appareils IoT, tels que les caméras IP, les enregistreurs DVR et les routeurs, devinrent manifestes et attirèrent l’attention d’un grand nombre de journalistes et de chercheurs en sécurité. IoT devint le terrain de jeu de nombreux nouveaux bots et se transforma vite en champ de bataille où bots malveillants, bots bienveillants et autres bots d’autodéfense luttèrent pour s’imposer auprès d’un nombre toujours plus important d’appareils mal conçus et peu sécurisés.
 
Dès décembre 2016, le nombre de botnets avait connu une forte croissance. Leur taille atteignait plusieurs centaines de milliers de bots, et sans la tentative de prise de contrôle de DT en novembre 2016, qui se traduisit par le refus de fonctionner de 900 000 modems Internet résidentiels à la suite de l’exploit TR-069, ce chiffre aurait pu être porté à près de 1 million de bots. IoT étant devenu une arme majeure pour les attaques DDoS, le moment était venu pour nous de commencer à mesurer l’ampleur de la menace et de surveiller les exploits nouveaux et évolutifs utilisés par les botnets IoT.
 
Compte tenu de la méthode d’analyse et de collecte agressive employée par Mirai et du nombre considérable de botnets signalés au cours de ces neuf derniers mois, il ne fait aucun doute qu’un appareil non protégé et peu sécurisé fera rapidement l’objet d’un exploit et deviendra une proie une fois connecté à Internet. À moins que votre adresse IP fasse partie des plages exclues, codées en dur dans la version d’origine de Mirai, notamment le service postal des États-Unis (USPS), le Département de la Défense des États-Unis, l’IANA (Internet Assigned Numbers Authority) et les plages d’adresses IP appartenant à Hewlett-Packard et General Electric, toute connexion Internet, où qu’elle se situe, qu’elle soit résidentielle ou pas, est appelée à subir des tentatives d’infection de la part de Mirai et ses amis. Début janvier, nous avons commencé à déployer des capteurs pour nous faire une idée plus précise de la gravité de la situation. Nous avons donc commencé avec un serveur telnet personnalisé très simple, à l’écoute du port 23, acceptant toutes les combinaisons de nom d’utilisateur et de mot de passe et présentant à l’homologue distant ce qui s’apparente à une interface d’interpréteur de commandes (ou « Shell ») ou de ligne de commande. Dès nos premières analyses, nous avons constaté que le délai entre deux connexions de bots cherchant à compromettre notre nœud était inférieur à 10 minutes. Ce chiffre est désormais réduit à 3-5 minutes entre deux tentatives de compromission.
 
Compte tenu de cette activité régulière, nous avons décidé de créer un chatterbot (que nous avons baptisé fort à propos notre pot de miel IoT), le but étant qu’à travers un dialogue utile avec les bots, ceux-ci révèlent leurs fichiers binaires malveillants. Certains bots attendent des réponses précises des commandes émises. S’ils ne les obtiennent pas, ils disparaissent. Mais face à l’abondance des nouvelles tentatives, nous n’avons eu aucune difficulté à instaurer un dialogue cohérent avec la plupart des bots et à nourrir ce dialogue jusqu’à ce que les homologues incriminés montrent leur vrai visage et nous indiquent l’emplacement de leurs fichiers binaires malveillants, généralement représentés par une commande wget ou ftp/tftp.
 
Comme on pouvait s’y attendre, la plupart des séquences de commandes de l’injecteur allaient dans le même sens et présentaient beaucoup de similarités, hormis quelques jetons randomisés et les emplacements de téléchargement des fichiers binaires. En concaténant et en normalisant la séquence de commandes des bots et en la hachant, nous avons pu créer une empreinte digitale identifiant de manière unique des familles de bots similaires.
 
hajime-dropper-command-sequence.png

Illustration : séquence de commandes de l’injecteur Hajime

 
Dès l’instant où les bots ont eu suffisamment confiance en notre pot de miel pour lui faire part de l’emplacement de téléchargement des fichiers binaires malveillants, nous avons ajouté des fonctionnalités pour permettre au pot de miel d’extraire les fichiers binaires et de les télécharger dans la mémoire pour nous permettre de hacher le contenu et ainsi créer une empreinte digitale du programme malveillant. Les nouvelles empreintes digitales inconnues du pot de miel ont fait l’objet d’une analyse plus poussée via le dépôt des hachages md5 et sha256 sur virustotal.com. Les programmes malveillants nouveaux ou inconnus ont été soumis à virustotal, devenant ainsi de bons candidats pour une étude approfondie. Les empreintes digitales des fichiers offrent un moyen efficace d’identifier les bots dotés de fichiers binaires malveillants qui évoluent dans le temps, comme Hajime. L’empreinte numérique de la séquence de commandes correspond à celle de Hajime, mais les empreintes numériques des fichiers binaires changent dans le temps, ce qui nous permet de suivre les nouvelles versions fournies par un même bot.
 
Les informations sur l’homologue distant, notamment les données geoip, la séquence de commandes initiale, l’empreinte digitale de celle-ci, ainsi que l’empreinte digitale des fichiers binaires malveillants, sont stockées dans MongoDB pour être analysées. En interrogeant les données dans MongoDB, nous pouvons suivre l’historique et l’évolution des bots existants et nouveaux qui ont essayé de compromettre nos pots de miel. Au fil du temps, nous avons ajouté la prise en charge de nouveaux protocoles et exploits tels que le serveur TR-064/069 et l’exploit NewNTPServer, les exploits HTTP go-ahead RCE et le protocole SSH général – simulant de vrais appareils aussi fidèlement que possible et faisant croire aux bots qu’ils avaient une nouvelle victime en puissance.
 
tr-064-newntpserver-rce-exploit.png
Illustration : exploit TR-064 NewNTPServer RCE
 
L’ajout le plus récent à notre infrastructure de pot de miel IoT est une pile ELK (Elasticsearch, Logstash, Kibana) qui nous procure des tableaux de bord et des informations en temps réel sur l’activité des botnets IoT dans nos pots de miel.

kibana-dashboard.png
Illustration : tableau de bord Kibana pour l’un de nos pots de miel
 
Le recours à une logique de chatterbot pour le pot de miel confère un outil de détection plus sûr et plus robuste qui offre une grande souplesse en matière de création d’empreintes digitales et d’analyse de l’activité. Aucune des commandes de bot ne sont réellement exécutées par le pot de miel ; seules les demandes connues et préprogrammées génèrent des réponses préprogrammées. Compte tenu du nombre important de tentatives d’infection à l’heure, cette logique de conception s’est avérée efficace pour étudier et collecter les données sur les menaces et les botnets IoT. Le pot de miel ne saurait être comparé à un pot de miel telnet/SSH traditionnel dans la mesure où il ne tient pas compte des commandes et des réponses non anticipées ou non programmées. D’autres pots de miel font valoir de véritables fonctionnalités d’interpréteur de commande et autorisent une plus grande créativité de la part de l’homologue attaquant, ce qui permet d’étudier efficacement le comportement des nouveaux attaquants. Le pot de miel IoT n’offre pas une telle liberté et une telle créativité, et bien qu’il permette de découvrir de nouveaux types de bots et de tentatives d’injecteurs, programmer et simuler des commandes, des protocoles et des exploits nouveaux avec celui-ci demande du travail. Pour les besoins de notre étude, le pot de miel nous procure les outils et les statistiques dont nous avons besoin pour mieux comprendre et appréhender l’environnement des menaces constitué par les botnets IoT.

Radware
© 2008-2018 Radware, Ltd. All rights reserved.