Face au développement des objets connectés (IoT), le nombre d’attaques DDoS ne cesse de croître. Faut-il s’en inquiéter et comment les prévenir ? Voici un avis d’expert de Fred Raynal, CEO de Quarkslab.
Un botnet est un ensemble de machines, compromises, et transformées en “bot” ou “zombie », c’est-à-dire qu’elles continuent à remplir leur office, mais embarquant du code d’un pirate qui en détourne aussi les ressources pour ses propres intérêts. Une attaque par Déni de Service (DoS) consiste à saturer les ressources d’une cible, souvent ses connexions réseau. Ces attaques sont nées dans les années 80, en même temps qu’Internet.
Petit à petit, les DoS ont évolué, cherchant à saturer les connexions réseau et donc à envoyer plus de débit qu’un tuyau n’est capable de traiter. Sont ensuite apparues les attaques distribuées de dénis de service (DDoS) : l’idée a été de multiplier les envois de paquets vers la cible depuis des sources variées pour saturer le tuyau, et les éventuelles protections qui commençaient à se mettre en place contre les DoS.
L’explosion du nombre d’objets connectés à Internet (IoT) ces dernières années contribue à offrir de nouvelles opportunités aux attaquants.
Différence majeure entre « botnet traditionnel » et « botnet IoT »
Un botnet normal est composé essentiellement d’ordinateurs personnels. Ils tournent principalement sous Windows, et sont compromis via des attaques client-side : des utilisateurs attirés sur des sites piégés qui compromettent leur machine, ou qui sont trompés par des fausses mises-à-jour. Quand une machine est compromise, elle se connecte à un serveur “Command & Control” (C&C) pour recevoir ses instructions.
Dans le cas d’un botnet IoT (caméras IP, set-top-box, home-routers), les interactions clients sont très limitées. En revanche, ces appareils ont des identifiants par défaut, comme “root:root” ou “admin:admin ». La construction d’un botnet IoT consiste à scanner Internet pour recruter des appareils avec de tels identifiants par défaut. Une fois compromise, grâce aux identifiants, elle se connecte à son C&C, puis scanne Internet pour recruter d’autres zombies.
La différence majeure entre un botnet traditionnel et un botnet IoT vient de ce côté viral, vu au début des années 2000 avec les vers comme Code Red ou Sasser, mais ressuscité grâce aux identifiants par défaut. L’autre différence est la taille. Un botnet traditionnel compte quelques dizaines de milliers de zombies, là où un botnet IoT sera plutôt dans les centaines de milliers. Gartner estime qu’il y aura 20 milliards d’équipements connectés en 2020. Ce nombre augmente exponentiellement avec une connectivité accrue.
Enfin, dernier bénéfice pour l’attaquant, contrairement aux desktops, les appareils IoT sont allumés 24h sur 24, 7 jours sur 7, ce qui rend le botnet continuellement disponible.
Pour l’attaquant, ces 3 différences font du botnet IoT une option idéale : gros, facile à constituer, et résilient. Que demander de plus pour lancer des campagnes de DDoS ?
Mirai : le botnet qui a fait couler de l’encre
Le botnet IoT qui a fait le plus de bruit s’appelle Mirai (“futur” en japonais), actif en 2016, en participant en particulier aux attaques DDoS contre OVH, mais aussi Dyn, qui fournit la résolution de noms (DNS) pour de nombreux sites sur Internet. En attaquant Dyn, Mirai a notamment fait tomber des sites comme Airbnb, Visa, Twitter, Slack, Netflix, ou encore Amazon.
Les créateurs de Mirai ont été malins en dotant leur création :
- d’un scanner Internet pour trouver des cibles potentielles ;
- d’une base de données d’environ 60 identifiants par défaut pour des appareils grand public répandus.
On l’a vu, l’utilisation des identifiants par défaut a changé la mise et Mirai a tout raflé. Mais l’histoire de n’est pas arrêtée là. Le code source de Mirai a fui, et est maintenant disponible sur GitHub : GitHub – jgamblin/Mirai-Source-Code: Leaked Mirai Source Code for Research/IoC Development Purposes. La divulgation ultérieure du code source de Mirai a permis de bien comprendre comment fonctionnait le botnet, mais elle a aussi donné des idées à certaines personnes, aux intentions peu louables.E lles l’ont cloné, l’on modifié et ajouté des credentials par défaut et des exploits, ou encore des capacités de « bruteforce » des identifiants : tout pour accroître la capacité de propagation. Au final, de très nombreuses variantes de Mirai sont nées de ce leak, et la plupart des botnets IoT s’appuient toujours sur ce code.
Botnet IoT : orchestrer la défense
Les botnets IoT sont composés de systèmes Linux, plus ou moins personnalisés. Ils ont souvent des ressources limitées et ne disposent pas de toutes les protections disponibles. Dès lors, la défense doit prendre en compte ces capacités limitées.
La première piste est de s’appuyer sur du hardware offrant des options de sécurité, comme un secure element (SE). Cet ajout a un coût pour le fabricant, et le consommateur. Or aujourd’hui, la priorité est à la conquête de parts de marché, donc à la réduction des coûts. Néanmoins, sur certains appareils qui ont besoin de sécurité (ex : DVR, caméras de surveillance), cela se justifie.
La deuxième piste relève du monitoring, comme les EDR pour le desktop. Un appareil qui se met à scanner Internet laisse des traces (ex : accroissement du nombre de paquets émis/reçus, et utilisation mémoire). À l’inverse d’un desktop, un appareil IoT a un usage spécifique et un comportement bien plus stable : le monitorer permet d’en détecter les écarts.A
D’autres exemples.
Diminuer la surface d’attaque, c’est-à-dire retirer les bugs avant que les devices ne soient livrés au grand public où des gens mal intentionnés vont les trouver et les exploiter.
Augmenter le coût de l’exploitation : c’est ce qu’il s’est passé sur Windows, iOS ou Android par exemple. Ces systèmes ont mis en place des contre-mesures contre les exploits (randomisation, cookies, …). Ainsi, même en présence de vulnérabilités énormes, l’attaquant ne peut rien faire. Mais d’une part, Linux est un peu à la traine là-dessus (sauf avec GRSecurity) et d’autre part, ces mesures ont des impacts en performance. Or les devices IoT tournent essentiellement sur du Linux embarqué, souvent customisé par le fabricant, pour chercher à réduire la puissance nécessaire.
Gérer des mises à jour automatiques : quasiment aucun de ces devices “grand public” n’a de système de mises à jour automatiques, poussées par l’éditeur. Du coup, les systèmes vulnérables le restent longtemps, parfois très longtemps.
Ces approches ne sont pas exhaustives, mais toutes reposent essentiellement sur les constructeurs, qui ne sont pas prêts aujourd’hui à faire les efforts nécessaires… comme les fabricants de systèmes il y a 20-30 ans.
