Le premier hébergeur européen est une cible de choix pour les attaques par déni de service, de plus en plus menées via des objets connectés. OVH a donc créé un système pour déconnecter automatiquement les serveurs présents sur son réseau, avec les risques que cela comporte. Entretien avec Sébastien Mériot, l'un des ingénieurs derrière cet outil.

La lutte contre les botnets, ces larges réseaux d'appareils zombies, nécessite de traiter toujours plus de données, toujours plus rapidement. En décembre, la Botconf 2017 était placée sous le signe de l'automatisation et de l'intelligence artificielle (voir notre compte-rendu). Des chercheurs y présentaient autant des outils d'apprentissage que des systèmes capables de désassembler à la chaine des logiciels, peu importe l'architecture sur laquelle ils reposent.

À cette occasion, Sébastien Mériot, ingénieur en sécurité chez OVH, a montré comment l'hébergeur automatise la suppression de serveurs de contrôle des botnets sur son réseau. « La première menace pour un fournisseur d’accès est une attaque DDoS [déni de service distribué, NDLR], pas un rançongiciel. Si le réseau tombe, notre activité meurt » déclarait-il alors. C'est ce danger que portent les malwares destinés à l'Internet des objets.

L'Internet des objets, cobaye idéal

« Nous avions choisi les malwares IoT, car c’est un domaine qui s’y prête très bien : la menace est en plein boom et les malwares sont généralement assez basiques » nous déclare Mériot, dans un entretien écrit. S'ils existent depuis une dizaine d'années, ils ont gagné leurs lettres de noblesse fin 2016, avec des campagnes fondées sur Mirai, dont celle contre Dyn, qui a rendu un nombre important de sites inaccessibles.

Ces attaques sont massives à cause de la piètre sécurité de millions d'objets connectés, comme les caméras ou les routeurs. « Ces malwares utilisent presque tous le même fait : les fabricants ont écrit les identifiants en dur dans le code, sans pouvoir les changer » affirmait le spécialiste en décembre. L'Union européenne prépare un rehaussement de cette sécurité, via un futur système de certification, attendu en fin d'année.

Malheureusement, il est difficile (voire impossible) de mettre hors ligne en masse des objets infectés, qui se multiplient exponentiellement. Le nerf de la guerre, pour les fournisseurs d'accès et hébergeurs, est donc de dénicher et démanteler les serveurs de commande et contrôle (C&C). Ils dirigent les attaques de ces objets zombies, avec un avantage face aux défenseurs : ils peuvent bouger rapidement d'hébergeur en hébergeur, disparaissant aussi vite qu'ils sont apparus.

Un jeu du chat et de la souris que les humains ne peuvent assurer seuls.

Un serveur de contrôle de Mirai hébergé chez OVH

En 2016, Mirai a montré l'ampleur du problème à l'hébergeur roubaisien. Au mois de septembre, il subissait une attaque de 1 Tb/s, contrée par ses techniques anti-DDoS (son « VAC »), qui envoient les attaquants vers un trou noir (null route). Un sinistre record doublé d'une découverte : « Nous avons été touchés par un botnet dont le serveur de contrôle a été hébergé plusieurs fois sur nos services ».

Cet épisode aurait fait de la société un « étalon » pour réseaux zombies. « Si votre botnet est capable de faire tomber une machine hébergée chez OVH, vous gagnez en crédibilité. On voit de nombreux herders afficher pouvoir déjouer nos protections comme un argument commercial, et donc inciter à attaquer des services hébergés chez OVH » assure-t-elle.

Selon OVH, les premiers essais datent de début 2016, avant un déploiement sur « un périmètre restreint » dans le courant de l'année. Ces efforts suivent un travail lancé en 2014, sur l'ensemble des problèmes de sécurité du premier hébergeur européen.

Dans ce dossier, l'entreprise s'est concentrée sur le traitement des requêtes « abuse », les signalements d'activités malveillantes hébergées chez OVH. Sont autant concernés les serveurs de contrôle de botnets que ceux propageant des charges malveillantes.

La base de données mondiale « Virus Total voit passer environ 200 000 malwares différents par jour en moyenne. Autant dire qu’il nous est impossible de vérifier si, pour les 200 000 malwares, il y en aurait un qui utilise potentiellement notre infrastructure, d’autant plus que nous faisons face à des attaquants qui ont compris que la volatilité était leur première alliée » explique Sébastien Mériot.

Avec cette automatisation, OVH a un objectif : couper les serveurs en moins de trois jours, au lieu de plusieurs semaines dans certains cas.

Être réactif et trouver des preuves

La chasse aux serveurs fait face à plusieurs obstacles de poids. Le premier est l'interdiction pour l'hébergeur de fouiller dans les données de ses clients. Il pourrait donc se fier aux requêtes « abuse ». Problème : elles sont trop peu fiables et arrivent parfois trop tard pour agir tant que le serveur est présent.

Surtout, « un opérateur traitant [des] abus de service doit avoir des preuves que son client participe à des activités contraires à ses conditions de vente (et à la législation en vigueur). Or, les signalements que nous recevons sont en majeure partie dépourvus de toutes preuves. Il nous revient donc d’effectuer un travail de collecte d’informations que nous soumettons ensuite au client en question afin qu’il corrige le problème. Ce travail est colossal » relate Sébastien Mériot.

Il est donc interdit de fouiller les données des clients et irréaliste de se fier aux remontées tierces, qui ne fournissent pas de preuves (une URL avec capture d'écran, des journaux serveur...). Il faut surveiller l'activité des botnets, pour trouver les serveurs de contrôle hébergés chez OVH. Le meilleur allié est Shodan, un service qui examine en permanence Internet et catalogue les machines accessibles.

« Shodan a ce petit plus, il nous permet de faire des recherches relativement rapides à l’aide de nos indicateurs de compromission (IOC) et nous donne une preuve que l’IP identifiée héberge bien un serveur de contrôle. Ce qui nous simplifie beaucoup le travail ! » se réjouit l'ingénieur. Malheureusement, il scanne Internet lentement, donc n'en fournit qu'une vue incomplète.

La main dans le pot de miel

L'hébergeur se fonde aussi sur des « flux d'intelligence », c'est-à-dire des flux d'indices techniques, utilisés par les services en ligne pour repérer des activités suspectes sur leurs infrastructures. OVH s'appuie sur l'éditeur d'antivirus chinois Qihoo 360.

« Les chercheurs de Qihoo 360 sont peu connus, alors que leur travail est formidable. Orienté intelligence, leur flux est très intéressant. Mais, comme avec beaucoup de flux d’intelligence, nous n’obtenons pas facilement de preuves utilisables et automatisables » assure l'entreprise.

Sébastien Mériot regrette d'ailleurs que les acteurs de « l'abuse » (qui traitent au quotidien les problèmes) et de la « threat intelligence » (qui mènent du renseignement sur les menaces) discutent peu : « Ces deux mondes ont la même volonté de rendre l’Internet plus sûr, mais ils communiquent relativement mal entre eux. [...] Il y a un réel travail de recherche [à mener] dans ce domaine. »

Dernière arme des Roubaisiens : les serveurs pots de miel, des machines rendues volontairement vulnérables et surveillées à chaque instant. Un botnet, qui scanne Internet et infecte tout ce qu'il peut, est facilement dupé. De quoi récupérer un échantillon du malware.

L'avantage d'un pot de miel est qu'il peut consommer peu de ressources. Pour une version « passive », qui subit simplement ce qui lui tombe dessus, un serveur dédié virtuel (VPS) à trois euros par mois suffirait. « En revanche, pour augmenter les probabilités de capter les signaux qui nous intéressent, il faut écouter sur beaucoup d’adresses IP. Et de préférence, des adresses IP sur plusieurs opérateurs », ce qui demande plus de moyens, assure Mériot.

Analyser les malwares, trouver les serveurs

Concrètement, OVH scanne Internet (via les résultats de Shodan) et récupère les échantillons avec ses pots de miel. Ces malwares sont ensuite analysés automatiquement, via un processus mis en place par l'hébergeur. Il compte trois étapes : un dépaquetage (pour obtenir le contenu), une analyse statique du code et une analyse dynamique optionnelle.

Tout l'enjeu est de trouver, automatiquement dans le code, les adresses des serveurs de contrôle. Certaines sont masquées via une méthode connue (XOR), qui poserait peu de difficultés. Avec cette première étape, « on arrive à retrouver six adresses de serveurs de contrôle sur dix », assure Sébastien Mériot.

L'analyse statique du code permet ensuite d'identifier des valeurs constantes, qui aident à dénicher de nouvelles adresses de serveurs de commande. Il s'appuie sur l'outil de rétroingénierie Radare2, automatisé via R2Pipe. En enchainant différentes commandes, la technique permet de retrouver neuf adresses de serveurs sur dix. Une commande est réservée à des cas particuliers, prenant quarante secondes pour « grappiller » une adresse.

Une analyse dynamique peut suivre sur « un vieux Raspberry Pi » si besoin, pour étudier les requêtes DNS et les flux réseau, donc voir avec qui ils communiquent. Seules, les requêtes DNS ne seraient pas un très bon indice, la plupart de ces logiciels ayant des serveurs connus (comme 8.8.8.8 de Google) écrits en dur dans le code. Les flux réseau donneraient, eux, des statistiques améliorant la vision donnée par les pots de miel.

« Nous nous intéressons également aux dépôts de noms de domaines, qui peuvent parfois nous conduire à l’identification de serveurs de contrôle » ajoute l'entreprise.

Ces logiciels restent difficiles à exécuter en environnement contrôlé (en sandbox), dans la mesure où ils sont adaptés à des systèmes exotiques. À raison d'environ trente échantillons par minute, systématiser ces tests prendrait aussi trop de temps.

Une supervision humaine nécessaire

Une fois le malware trituré, les adresses IP des serveurs de contrôle se révèlent, dont celles directement hébergées par les Français. Le système tente une connexion, pour vérifier qu'il est en ligne, et remplit une requête « abuse ». Une action automatique peut ensuite suivre, c'est-à-dire une suspension du serveur.

« Chez OVH, nous avons pris le parti de n’automatiser que des actions réversibles, et ce, uniquement si nous disposons des preuves suffisantes, et tout en respectant les contraintes légales bien évidemment » promet le groupe.

Pour l'hébergeur, la partie technique n'est pas la plus complexe. « L’automatisation de la rétroingénierie n’en est qu’à ses débuts. L’apparition d’outils comme Radare2, par exemple, révolutionne pas mal de choses dans notre métier, car nous pouvons enfin industrialiser des tâches répétitives d’analyse, ce qui aurait pu paraître complètement impensable il y a encore quelques années » précise Sébastien Mériot.

La majorité de la réflexion a, en fait, porté sur la prise de décision par le système, pour placer assez de garde-fous en cas de faux positif. L'outil est toujours supervisé par un humain, pour améliorer pots de miel et extraction des adresses IP. Un employé d'OVH est sollicité dès que le système a un doute, par exemple s'il manque de preuves d'activité répréhensible. « Le processus est donc un peu plus long, mais préférable à l’attente d’un signalement d’un tiers qui n’arrivera peut-être jamais. »

La conception et l'implémentation du système auraient pris à peine deux mois. Une « longue » phase de supervision a suivi, pour contrôler les décisions prises. Aujourd'hui, OVH aurait très peu de faux positifs, grâce à « des contraintes fortes » dans l'identification des adresses.

De plus, peu de serveurs seraient compromis pour mener des hordes d'objets connectés zombies, ceux utilisés étant donc montés à dessein. Couper un site légitime, qui cache un serveur de botnet en arrière-boutique, serait donc rare.

« Et même si c’était le cas, ce ne serait pas si problématique tant que nous sommes en présence d’un vrai positif. Couper une menace peut, malheureusement, aussi passer par couper d’Internet une machine qui a été compromise afin de demander à son propriétaire de faire le nécessaire pour la sécuriser » avance l'ingénieur.

Une chute drastique des détections de serveurs sur son réseau

Quels effets pour OVH ? Avant ce système, monté en octobre 2016, la société recevait de nombreuses requêtes « abuse » sur les malwares Tsunami et QBot. Son déclenchement a causé un nouveau pic de notifications. L'entreprise a découvert pléthore de serveurs liés à des botnets, qui n'avaient jamais été signalés. « C’est la partie immergée de l’iceberg » pense Mériot.

Depuis, le nombre de requêtes a été divisé par cinq. La part des serveurs de contrôle découverts sur son infrastructure serait passée de 15/20 % à moins de 5 %. Aucun volume concret ne nous a été fourni.

Désormais, un tel serveur serait détecté automatiquement en trois jours, avant qu'il ne puisse causer des dégâts importants. En cas d'intervention humaine, le délai entre la détection et la mise hors ligne peut passer à cinq jours. Un gain significatif face aux semaines d'existence des serveurs non signalés précédemment.

Il n'empêche que la menace des botnets continue de croître, avec des attaques toujours plus puissantes... Quand bien même les hébergeurs sont capables de contrer aisément ces malwares, assure OVH.

OVH, passion automatisation

Ce système se veut représentatif des Roubaisiens. « Chez OVH, nous automatisons tout ce que nous pouvons ! » déclare la société. Elle y voit une nécessité, y compris sur la sécurité, vu la taille de son infrastructure. « Dans l’ensemble, si un humain ne fait que suivre une procédure répétitive, on peut automatiser cette procédure et permettre à l’humain de se concentrer sur les sujets nécessitant une analyse poussée. »

Pour le moment, l'automatisation va du pot de miel au démantèlement. Compte-t-elle aller plus loin en identifiant les comportements typiques (patterns) des botnets dans les flux réseau ? L'entreprise dit avoir quelques idées dans sa besace, mais rien qui puisse être annoncé.

À court terme, le système pourrait être adapté aux scans de vulnérabilités agressifs. Plus tard, la société pense aussi l'étendre aux mineurs de crypto-monnaies, qui exploitent des ressources sans l'accord de l'hébergeur ou du client.

Bien entendu, OVH collabore avec ses confrères sur le démantèlement des réseaux zombies. Il note pourtant que l'automatisation n'est pas si bien vue partout, vu les risques importants pour un hébergeur en cas d'erreur. La déconnexion automatisée des serveurs serait, elle, encore très rare.

« Le niveau de maturité en matière d’automatisation est très hétérogène d’un opérateur à un autre, indépendamment du nombre d’adresse IP qu’il gère » résume Sébastien Mériot, qui voit encore des serveurs de contrôle rester des mois en ligne sans problème.

Note : cet article est publié huit mois après la Botconf, où nous avons rencontré Sébastien Mériot. OVH a refusé un entretien sur place, puis un entretien téléphonique demandé en janvier. Nous avons envoyé une vingtaine de questions en février, auxquelles OVH a répondu par email le 12 juillet, après plusieurs relances.