attaques DDoS over spam

Début mai se tenait en République Tchèque la conférence "Security and Protection of Information" avec en ouverture une conférence intitulée "Denial of Service attacks using the white horse systems: new proof-of-concept DoS against the DNS server".

La présentation concernait une nouvelle méthode d'attaques en déni de service de serveurs DNS, via l'utilisation de campagnes de spam.

le principe de l'attaque

Ci-dessus l'architecture de principe qui a été présentée par les chercheurs Jakub Alimov (Sez​nam​.cz) et Minor (Zone​-​h​.org).

amuse-bouche : toast DNS

La mise en bouche est somme toute standard puisque l'attaquant va modifier la zone DNS d'un nom de domaine pour y enregistrer le serveur cible comme serveur NS (ex: foobar.com NS 1.2.3.4).

Ainsi, tout serveur SMTP souhaitant envoyer un email à destination du nom de domaine, devra récupérer les informations adéquates telle que le précise la RFC2821, en interrogeant le serveur DNS autoritaire (ici 1.2.3.4).

entrée : salade de spam

L'entrée en matière de l'attaque relève alors des techniques habituelles de spam en utilisant comme adresse(s) d'expédition une (ou des) adresse(s) appartenant au domaine préalablement déclaré sur le serveur DNS (exemple: user.123@foobar.com, user.456@foobar.com). Il est également possible d'utiliser des sous-domaines (ex: user.789@dummy.foobar.com).

Note : lors de leurs observations, les chercheurs ont recensé plus de 14 000 adresses IP uniques, issues apparemment du même botnet, pour l'opération de spam.

plat principal : steak de cheval blanc

L'astuce consiste ici à utiliser ce que les chercheurs nomment des "White Horses", à savoir des serveurs disposant d'une importante capacité en terme de bande passante. A noter que les gros hébergeurs de serveurs SMTP tels Yahoo Mail, Microsoft ou Google sont par définition des cibles favorites. 

Dotés d'une force de frappe importante, ces serveurs sont en mesure de lutter efficacement contre les attaques de type spam. Mais dans de nombreux cas de figure, une analyse concernant la légitimité de l'expéditeur est requise. Conformément à la RFC en vigueur, les serveurs SMTP vont vérifier, pour chacun des messages, les informations associées au nom de domaine (ici une requête DNS de type MX RR ou A RR sur la zone foobar.com).

Les chercheurs précisent qu'il est envisageable d'utiliser un botnet de 50 000 machines, envoyant chacune des messages à destination de 100 systèmes "White Horse" différents.

dessert :  farandoles de DNS sauce DDoS

Pour réaliser la tâche qui leur incombent, les serveurs SMTP vont (directement ou indirectement) solliciter le serveur DNS autoritaire sur le nom de domaine. Ils vont donc propager un volume important de requêtes DNS à destination du serveur DNS cible (ici 1.2.3.4).

Ce dernier n'ayant pas forcément les capacités à absorber la volumétrie, il est victime d'un déni de service. Pour rappel, les serveurs "demandeurs" d'informations font partie des "White Horses" qui, eux, bénéficient de ressources importantes.

En reprenant les chiffres plus haut, nous arrivons vite ici à 50 000 (machines) x 100 (White-Horses) x 1 (message) = 5 millions de messages, soit autant de requêtes MX RR auprès du serveur DNS cible.

remèdes anti-indigestion

La protection des zones DNS est bien évidemment la première des protections à mettre en place. Malgré cela, rien de vous garantit qu'une zone cyber-squattée ne déclare pas votre serveur DNS comme cible.

Le black-listage des domaines concernés reste également une protection simple, mais peu efficace dans la mesure où l'attaquant a toute liberté de varier les plaisirs en utilisant plusieurs noms de domaines durant l'opération (adaptant ainsi sa campagne de spam au fur et à mesure des blacklists).

Seuls les mécanismes de protection mis en place du côté des "White-Horses" peuvent être efficaces (protection anti-spam, limitation des flux de requêtes DNS, etc.).

Une autre solution reste la mise en oeuvre de protection anti-DDoS au sein ou en amont de votre infrastructure.

Vincent

Vincent Maurin

Chez Orange Business, je suis en charge du domaine Sécurité au sein de la Direction du Développement des Produits et des Services. Mes expériences passées au cœur d'entités opérationnelles m'amènent à porter un regard particulier sur les difficultés de mise en œuvre des politiques et stratégies de sécurité pour les entreprises. Sécurité, efficacité et pragmatisme sont mes principaux axes de réflexion.