Attaque DNS DYN, ou comment se protéger du malware Mirai

En quelques semaines, le monde de l’Internet vient de subir une série d’attaques DDoS ciblée et encore inconnue. Inconnue par la technique utilisée et par le volume. Ces attaques ont une particularité : le nombre de sources utilisées pour chaque attaque. Ce nombre dépasse les 100 000. Mais il est très difficile de savoir ce qui se cache derrière une adresse IP à cause du Spoofing et du NAT.

Comment un BotNet de plusieurs centaines de milliers de machines (ou objets) a pu être constitué aussi rapidement et ceci sans être détecté ?

Tout simplement grâce à un « simple » malware nommé « Mirai ».

Mirai, comme tout malware, est très bien pensé et peut donc faire de très gros dégâts. Sa particularité est de s’efforcer à s’installer cibler les objets connectés (IoT ou Internet Of Things) telles que les caméras IP grâce à un outil appelé Loader.

Rechercher un IoT sur Internet est très simple, via Shodan par exemple (https://www.shodan.io/).

Une fois ces objets ciblés, ce « Loader » teste les diverses vulnérabilités connues afin de pénétrer l’objet.

En effet la sécurité de ces objets est souvent la dernière roue du carrosse par rapport aux enjeux que représentent la course à l’innovation et la disponibilité de ces objets sur le marché. En conséquence beaucoup de ces objets ne sont pas ou peu protégés et sont bien souvent configurés avec les identifiants par défaut du constructeur.

Mirai et son loader va donc essayer les différents identifiants connus pour se connecter aux objets.

Une fois connecté sur l’équipement IoT, le Malware Mirai s’installe et se connecte à son centre de commandes (Command And Control) afin de recevoir ces éventuels ordre d’attaques.

Ci-dessous, un schéma (source Level3) qui résume le fonctionnement de Mirai en expliquant les différents acteurs impliqués lors des 2 phases de ciblage des IOT puis d’attaque une fois le BotNet constitué.

Quelles sont les vecteurs d’attaques utilisés par MIRAI ?

A la suite des attaques OVH et Krebs, le code source de Mirai a été délibérément mis en ligne par son créateur.

F5 Networks, via ses F5 labs, a donc analysé le code source de Mirai afin de comprendre les différentes attaques que celui-ci pouvait générer. Il y a plusieurs attaques possibles, certaines n’étant pas encore totalement codées.

La principale utilisée ces dernières semaines s’appelle « DNS Water Torture ». La technique est très simple mais diffère des techniques de « DNS reflection » habituelles. Celle-ci nécessite beaucoup moins de ressources de la part du Botnet, en s’appuyant sur le serveur DNS récursif de l’opérateur (le resolver ou tout simplement le DNS sur lequel la box internet du botnet se connecte). Ce sont ces Resolvers DNS qui vont s’occuper de l’attaque en ciblant le serveur DNS de la victime.

Dans cette attaque, le Botnet envoie une requête « légitime », c’est-à-dire bien formée et donc conforme à la RFC, contenant le nom de domaine de la cible à résoudre, mais en y ajoutant un nom de machine aléatoire et non-existant dans la zone DNS du domaine visé.

Ainsi, le résolveur DNS de l’opérateur transfèrera cette demande au DNS cible.

Le DNS cible répondra que ce nom de machine n’existe pas. Ce type de réponse n’étant pas cacheable par l’infrastructure DNS l’attaquant est sûr d’atteindre le serveur cible.

L’attaque est déterminée , il ne reste plus qu’à y ajouter la puissance de tir apportée par le BotNet MIRAI.

L’attaque devient efficace lorsque le serveur DNS de la cible ne répond plus. Automatiquement, le résolveur DNS basculera sur le second serveur DNS de la cible. Et ainsi de suite. A l’aide d’un BotNet puissant, l’attaquant fera tomber tous les serveurs DNS de la cible comme des dominos.

En analysant les logs , la société Dyn s’est aperçue que 24% du trafic provenait de 4 serveurs DNS récursifs particuliers : Google, Hurricane Electric, Verisign, et Level 3.

Ce sont les mêmes configurés dans Mirai lorsque les objets connectés n’ont pas de resolver DNS configuré.

Comment se protéger ?

Cette attaque comporte deux difficultés :

Les requêtes sont légitimes et non cacheable (car le hostname de la zone DNS n’existe pas)
La volumétrie du flux DNS généré

Il est impossible de demander à un serveur DNS récursif de ne plus vous envoyer de requêtes, vous bloqueriez des réquêtes légitimes, même si ce serveur est un serveur DNS récursif ouvert. Le fait de laisser des serveurs récursifs ouverts sur Internet est un débat ouvert depuis plusieurs , mais là n’est pas le sujet de cet article.

Donc pour faire simple, il y a 2 facteurs qui peuvent rendre un service DNS indisponible :

Trop de requêtes par secondes, donc le serveur ne peut plus répondre
Trop de volume, donc le lien est saturé

Sur le premier facteur, la solution est de disposer d’une solution hautement disponible et ayant les capacités de traitement suffisante pour supporter la charge lors d’une attaque DNS. Les requêtes DNS utilisent quasi exclusivement le protocole UDP, donc une sécurité de type TCP StateFull ne peut aider.

La solution F5 DNS Express permet de déporter une zone DNS sur le BIGIP afin que celui-ci se charge directement de la réponse DNS. Un BIGIP peut supporter jusqu’à 10 millions de QRPS (Query Response Per Second). Le BIG-IP devient serveurs DNS Secondaire de votre zone DNS Primaire.

Ainsi, lors de l’attaque « DNS Water Torture », toute requête « légitime » mais dont le hostname (le préfix) est inconnu, sera automatiquement traitée par le BIGIP lui-même.

Plus d’informations sur DNS Express : https://devcentral.f5.com/s/articles/dns-express-and-zone-transfers

F5 Networks dispose d’une offre beaucoup plus large sur la protection DNS permettant de protéger les infrastructures DNS contre tout type d’attaque de type réflexion, amplification avec des technologies telles que RPZ (Response Policy Zone), IP réputation, DNSSEC …

Sur le deuxième facteur (la volumétrie), il va falloir s’appuyer sur une solution de délestage afin de re-router le trafic vers un centre de traitement disposant de suffisamment de bande passante.

La solution F5 Silverline DDoS, en mode Always Available, permet à ses clients de disposer d’une « assurance » en cas d’attaque DDoS dépassant leur capacité de traitement. Ainsi, le trafic est re-routé vers les centres de traitement F5 Silverline afin de traiter et dépolluer le flux. Le flux propre est ensuite envoyé à l’infrastructure cliente.

Plus d’informations sur F5 Silverline : https://f5.com/products/deployment-methods/silverline

Pour finir, une attaque évolue et se répète. Krebs, OVH et Dyn en sont les témoins et un SOC est aujourd’hui indispensable pour adapter sa protection en fonction de l’évolution de l’attaque.

Pour cela, dans son offre Silverline, F5 Networks intègre son SOC et ses équipes d’analyse. Une approche hybride est devenue aujourd’hui indispensable afin de pouvoir se protéger des attaques volumétriques et ciblées.

Les protections dans le Cloud (off-premises) se chargeront de prendre la charge volumétrique et de nettoyer le flux le mieux possible. Ensuite, les solutions on-premises se chargeront d’une analyse plus fine et se chargeront de protéger au plus près l’infrastructure IT.

Pour cela, F5 Networks propose ses solutions de protection hybride permettant aux solutions on-premises d’information les off-premises d’une attaque en cours. Ainsi, lorsque la solution off-premises reprend le trafic, celle-ci dispose déjà d’informations pertinentes lui permettant de bloquer l’attaque le plus tôt possible.

Le code source de MIRAI ayant été mis en ligne, il est fort probable dans les semaines et mois à venir que des attaques semblables ou encore plus puissantes voient le jour en utilisant la source du malware MIRAI et ses capacités à constituer de manière très rapide un BOTNET très important en ciblant les équipements IOT.

Sources :

Published Oct 28, 2016

Version 1.0