Chat avec les bots IoT

L’IoT est devenu le terrain de jeu favori de nombreux nouveaux bots. Bad bots, white-hat bots et vigilante bots se livrent bataille pour abuser les dispositifs les plus faibles en terme de conception et de sécurité.

Après l’attaque Dyn par Mirai en octobre 2016, nous savions qu’il fallait s’attendre à voir évoluer le paysage des menaces DDoS au cours des mois et années à venir. L’Internet des objets (IoT) allait devenir un élément important de ce nouveau paysage. Après l’attaque, il est devenu évident que la sécurité de l’IoT était insuffisante et que les botnets exploitant les dispositifs IoT, comme les caméras IP, les enregistreurs et les routeurs, manquaient de sophistication. 
En décembre 2016, le nombre et surtout la taille des botnets continuait d’augmenter. Certain pouvaient dépasser les centaines de milliers de bots et même approcher le million si la tentative d’infection de DT en novembre 2016 n’avait pas provoqué la mise hors circuit de 900 000 modems-routeurs résidentiels suite à l’exploitation d’une faille dans le protocole TR-069. L’IoT est devenu un formidable vecteur d’attaque DDoS. Il est temps que nous prenions conscience de l’ampleur de la menace et que nous analysions les nouvelles failles utilisées par les botnets IoT.

Du fait de la nature offensive des méthodes d’analyse et de collecte de données du ver Mirai, et au vu du nombre important de botnets signalés ces neuf derniers mois, ce ne sera pas long avant qu’un dispositif mal protégé soit infecté dès sa connexion à Internet. A moins que votre adresse IP fasse partie de la liste noire, codée en dur dans le code original de Mirai, qui recense les adresses IP du service postal des Etats-Unis, du département de la Défense, de l’IANA (Internet Assigned Numbers Authority) et des plages IP attribuées à Hewlett-Packard et General Electric, toute connexion à Internet, résidentielle ou non et où qu’elle se trouve, fera régulièrement l’objet de tentatives d’infection par Mirai et ses amis. 

Début janvier, nous avons commencé à déployer des capteurs pour nous faire une idée de la gravité de la situation (je travaille pour une entreprise de cybersécurité). Nous avons commencé avec un serveur telnet très simple, développé sur mesure, qui écoutait le port 23, et qui acceptait n’importe quelle combinaison d’identifiant et de mot de passe et présentait une interface shell ou à ligne de commande au serveur distant. L’analyse des premières connexions a révélé que moins de 10 minutes s’écoulaient entre deux connexions de bots cherchant à compromettre notre nœud. Aujourd’hui, ce ne sont plus que trois à cinq minutes qui séparent deux tentatives de compromission.

Au vu de la régularité de l’activité, nous avons voulu créer un agent conversationnel ou chatterbot (qu’on peut aussi voir comme un pot de miel IoT) pour qu’il ait un dialogue signifiant avec les bots, afin de les amener à révéler le code de leur malware. Certains bots attendent certaines réponses aux commandes émises et faute de réponse satisfaisante, ils disparaissent. Comme nous n’avons jamais manqué de nouvelles tentatives, nous avons pu établir un dialogue cohérent avec la plupart des bots et le poursuivre jusqu’à ce que l’agresseur tombe le masque et nous indique la position de son malware, généralement représenté par une commande wget ou ftp/tftp.

Comme on pouvait s’y attendre, la plupart des séquences de commande reçues étaient cohérentes avec de nombreuses similarités, à l’exception de quelques jetons randomisés et de la position de certains programmes binaires téléchargés. Après avoir concaténé et normalisé la séquence de commandes du bot et l’avoir hachée, nous avons pu créer une empreinte digitale d’identification des familles de bots similaires.

Une fois les bots suffisamment en confiance pour partager avec notre pot de miel la position de téléchargement du code binaire du malware, nous avons ajouté une fonctionnalité au pot de miel pour qu’il télécharge le programme binaire en mémoire et y applique un algorithme de hachage pour créer une empreinte digitale du malware. De nouvelles empreintes, inconnues du pot de miel, sont analysées en soumettant les hashs md5 et sha256 à virustotal.com et tout malware nouveau ou inconnu est soumis à virustotal. Les empreintes de fichiers sont un formidable outil pour identifier des bots identiques dont le code binaire du malware évolue dans le temps, comme Hajime. L’empreinte de la séquence de commandes correspond à celle de Hajime, mais les empreintes de fichiers binaires changent avec le temps, ce qui nous permet de suivre les nouvelles versions délivrées par le même bot.

Les informations concernant le serveur distant, y compris les données geoip, la séquence de commandes originale et l’empreinte de la séquence de commandes ainsi que l’empreinte du code binaire du malware sont stockées dans MongoDB pour être analysées. En interrogeant les données dans MongoDB, nous sommes en mesure de suivre l’historique et l’évolution des bots nouveaux et existants qui tentaient de compromettre nos pots de miel. Au fil du temps, nous avons ajouté le support de nouveaux protocoles et failles, comme celles du parametre NewNTPServer du protocole TR-064/69, de la faille RCE dans plusieurs caméras utilisant le server HTTP go-ahead, et SSH, de façon à simuler le mieux possible de véritables dispositifs pour tromper les bots qui croient avoir affaire à une vraie victime.

L’ajout le plus récent à notre infrastructure du pot de miel IoT est une pile ELK (Elasticsearch, Logstash, Kibana) qui génère des tableaux de bord en temps réel avec des insights sur l’activité des botnets IoT dans nos pots de miel.
L’utilisation d’un agent conversationnel (chatterbot) pour le pot de miel nous donne un outil de détection plus sûr et plus robuste source d’une grande flexibilité pour les empreintes et l’analyse de l’activité. Aucune des commandes du bot ne sont exécutées par le pot de miel, seules les requêtes connues et préprogrammées génèrent des réponses préprogrammées. En raison du grand nombre des tentatives d’infection par heure, cette configuration nous a donné satisfaction pour l’étude et la collecte des données sur les menaces IoT et les botnets. Le pot de miel n’est pas comparable aux pots de miel telnet/SSH plus traditionnels car il ne permet pas les commandes et réponses non anticipées ou non-programmées.
D’autres pots de miel exposent la véritable fonctionnalité shell et autorisent plus de créativité de la part de l’agresseur, ce qui permet d’étudier son comportement. Le pot de miel IoT n’offre pas autant de liberté et de créativité et, pour découvrir de nouveaux bots et tentatives d’infection, il faut programmer et simuler de nouvelles commandes, de nouveaux protocoles et failles à exploiter. Au final, le pot de miel nous apporte le bon outil et les statistiques nécessaires pour étudier et mieux comprendre le paysage de menaces que véhiculent l’espace IoT.