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.
Principe
Voici l'architecture de principe qui a été présentée par les chercheurs Jakub Alimov (Seznam.cz) et Minor (Zone-h.org) dans leur article disponible ici.
Amuse-bouche : Toast DNS
La mise en bouche est somme toute standard puisque l'attaquant va enregistrer 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 d'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: [email protected], [email protected]). Il est également possible d'utiliser des sous-domaines (ex: [email protected]).
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 sur que les chercheurs nomment des "White Horses", à savoir des serveurs disposant d'une important 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) sollicités 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 par 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 à toute liberté à 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.