Des pirates utiliseraient trois techniques pour rediriger des noms de domaine vers des serveurs compromis, affirme la société de sécurité FireEye.
Elle présente l’attaque comme massive et mondiale, touchant « des dizaines de domaines appartenant à des entités gouvernementales, de télécommunications et d’infrastructures Internet au Moyen-Orient, en Afrique du Nord, en Europe et en Amérique du Nord », sans les nommer. La campagne serait active depuis janvier 2017.
La première technique consiste à pirater le tableau d’administration du site ciblé chez son fournisseur DNS. L’attaquant change alors l’adresse du serveur vers lequel diriger l’internaute (enregistrement A), pour entrer un compromis.
Le serveur compromis agit alors comme un proxy entre l’internaute et le vrai site, collectant certaines données, par exemple des identifiants. L’utilisateur ne doit y voir que du feu, accédant un peu plus lentement au site légitime. Le faux site paraît protégé grâce à un certificat TLS gratuit récupéré chez Let’s Encrypt, renvoyant ensuite vers le vrai et son certificat officiel.
La seconde technique consiste à exploiter un bureau d’enregistrement ou domaine géographique (ccTLD), en modifiant cette fois l’enregistrement NS (serveur de nom). Alors que l’entrée « A » désigne le serveur principal, la « NS » permet de ne toucher qu’à un sous-domaine précis, comme celui d’un webmail.
La troisième technique s’ajoute à l’une des deux autres. Une redirection DNS est effectuée, pour retourner l’adresse IP compromise si le site ciblé est demandé par l’internaute, et demander une adresse à un résolveur légitime si un autre site est demandé.
Pour FireEye, il est difficile de se protéger de cette attaque. La société recommande d’activer la double authentification sur les panneaux d’administration DNS des domaines, de vérifier les entrées « A » et « NS » de sa zone DNS, de vérifier les journaux d’accès au site et d’enquêter sur des intrusions dans son propre réseau.
Commentaires (17)
#1
Gloups, inquiétant quand même…
#2
Les conseils donnés par FireEye ne sont valables que pour des admins de DNS ou aussi des admins de sites web ?
#3
C’est valide pour tout tableau de bord avec configuration DNS, comme celui de ton registrar (OVH, Gandi et consorts). La double-authentification est à activer partout où on peut de toute façon.
#4
La technique 1 est illogique : un site pirate agit comme proxy vers le site légitime, ok, mais pourquoi préciser à la fin que l’on est redirigé vers ce dernier ? Soit c’est un proxy et ça le reste jusqu’au bout, pour chopper des infos, soit ça ne sert à rien. Puis même en cas de redirection, vers quoi rediriger puisque le DNS est corrompu ? Le vrai site est inaccessible directement.
J’ai l’impression que ça voulait plutôt parler de phishing, donc sans attaque DNS.
#5
Ou alors, comme souvent, c’est une boîte qui veut faire parler d’elle en faisant peur avec des mots compliqués :-p
#6
Je pense que c’est « renvoyant », dans le sens « affichant » (donc toujours en passant par le proxy).
#7
Je me suis toujours posé la question mais sans jamais vraiment chercher la réponse:
Let’s Encrypt ne vérifie pas la légitimité d’une demande de certificat ? Si je demande un certificat pour www.google.com ils me donne ça sans broncher ?
Pour moi c’est justement le rôle d’un tier “de confiance”. Si tlm peut demander et obtenir n’importe quoi elle est ou la sécurité ? (non, pas là…)
#8
Quand tu fais une demande Let’s Encrypt, il faut que le nom de domaine demandé pointe bien vers la machine d’où tu fais la demande.
Cette page résumera le fonctionnement bien mieux que moi si tu comprends l’anglais
#9
Ok je comprend un peu mieux.
Mais donc pour pouvoir faire la faille exposée en 1 il faut :
Entre les étapes 1 et 4 il faut en plus que le site attaqué ne se rende pas compte de l’interruption de service pour ses utilisateurs.
Sur de gros site ça semble quand même compliqué (pour peu qu’ils soient monitoré correctement), mais en effet c’est jouable pour attaquer de petites structures.
#10
a noter que ce process c’est uniquement pour avoir “le petit cadenas vert”
si le serveur de l’attaquant est prêt à faire miroir dès que le dns hacké est modifié, l’attaque fonctionne, même sans le certificat LE
#11
La seule information nouvelle à en tirer, c’est qu’il y aurait eu une attaque par on ne sait qui, si ce n’est peut-être des Iraniens, ciblant on ne sait quelles grosses sociétés, pour récupérer, par on ne sait quelle méthode, leurs accès à on ne sait quelle interface d’administration, gérant on ne sait quels domaines, afin d’intercepter on ne sait quelles données, et impactant donc on ne sait quelles victimes finales, mais sans doute des gouvernements du Moyen-Orient comme l’origine pourrait venir de l’Iran.
" /> À la différence de l’article de FireEye qui est surtout compréhensible par ceux ayant un minimum de connaissances dans le domaine, mais qui n’apprendront strictement rien au final. 
" />
Ça fait quand même beaucoup de « on ne séquelles sait quel(le)(s) » pour un seul article qui ne détail au final que des méthodes identifiées pour effectuer une interception de données via une zone DNS compromise, mais déjà largement connues et documentées dans le domaine. Et encore, l’article n’étant pas clair là-dessus, l’ont-elles été précisément dans le contexte de cette attaque ?
Ce passage de l’article résume à lui tout seul sa vacuité… « Il est difficile d’identifier un unique vecteur d’intrusion pour chaque changement d’enregistrement DNS, et il est possible que ce ou ces acteurs utilisent plusieurs techniques pour faire une infiltration préalable dans chacune des cibles précédemment décrites. » Autrement dit, on peut difficilement savoir ce qu’il s’est passé du début à la fin, mais on fait malgré tout un article, pour donner l’illusion qu’on sait sans savoir.
Bon au moins, votre brève a le mérite de rendre intelligible aux profanes ces techniques d’attaques DNS transparentes de type homme du milieu…
#12
Ce que je vais dire est peut-être une énorme ânerie mais en gros, on a un article qui nous explique que si on ne protège pas suffisamment les accès de son compte hébergeur (aka OVH, Infomaniak, 1&1 Ionos etc…), on se fait pirater ?
Fin je résume très grossièrement parce que je suis un profane en la matière mais ça revient pas à dire que le feu ça brûle ? C’est pas étonnamment alarmiste pour quelque chose que tout gestionnaire de domaine devraient naturellement faire ?
Ce que j’en retiens le plus, c’est qu’il y a des attaques ciblées auprès de certains propriétaires de ndd mais ça n’a pas nécessairement nouveau non plus. :L
#13
Oui, c’est tout à fait la lecture que j’en ai eu : qu’ils enfoncent des portes grandes ouvertes !
" /> ‘Fin là, ce ne sont même plus des portes, c’est carrément un portail. 
" />
#14
A noter cependant, qu’il existe des méthodes pour s’en “protéger” (enfin, à minima être alerté).
Il suffit de faire du monitoring de ses NS et entrées DNS.
En gros : je regarde à l’instant T qu’elles sont mes entrées DNS et serveurs NS. Demain, si je vois que mes entrées ont été modifiées alors que ce n’est pas moi, je sais que mon compte (OVH, etc.) a été “piraté” ou à minima qu’une utilisation frauduleuse de mes identifiants a eu lieu (ou qu’un branleur de l’équipe à modifié des trucs -SPF, DKIM, DMARC, MX, A, CNAME…- sans le dire à ses collegues !)
Il existe des services (payants et gratuits avec limitation) pour monitorer ses entrées DNS. D’ailleurs, le risque majeur est surtout sur les entrées emails “MX” qui permettent même de rediriger tout les flux mails entrants vers un serveur illiégitimes (en mode temporaire ou de manière définitive), avec alors la possibilité de récupérer les emails de récupération de mot de passe etc. etc. Autre danger, l’ajout d’une entrée Google Verify ou équivalente avec vol pontiel de stats Google Analytics (plus complexe) etc.
#15
« Alors que l’entrée « A » désigne le serveur principal, la « NS » permet
de ne toucher qu’à un sous-domaine précis, comme celui d’un webmail. » Cela ne veut absolument rien dire. Il faut virer cette phrase. Proposition de remplacement : Alors que l’entrée « A » désigne l’adresse IP d’un serveur donné, les « NS » permettent au pirate de rediriger ses victimes vers ses propres serveurs de noms, lui donnant un meilleur contrôle sur le domaine détourné.
#16
Pas complètement d’accord. En théorie, vous avez raison. Mais en pratique, dans pas mal de boîtes, il y a des services qui sont à peu près correctement gérés, et il y a le DNS, qui est sous le radar, pas pris en compte, et dont le mot de passe du compte chez l’hébergeur ou le BE est sur un post-it connu de tout le monde et du stagiaire.
C’est le mérite du rapport de FeuŒil. Rien de nouveau, en effet, mais une utile piqure de rappel : n’oubliez pas les noms de domaine !
#17
Il n’y a pas interruption de service si le site pirate sert de relais (terminant la session TLS, et en faisant une nouvelle vers le vrai site Web).