Domain Mayday EP14 : Quand une entreprise de sécurité s'est fait détourner son DNS — L'incident Fox-IT

Le propre d'une attaque man-in-the-middle, c'est que pendant qu'elle se déroule, tout semble normal.

Le site se charge. La barre d'adresse affiche le bon domaine. Le cadenas est fermé. Le certificat est valide. Les fichiers s'envoient, les connexions réussissent, les e-mails arrivent. Aucune erreur, aucun avertissement, aucune image cassée — juste un tiers silencieux, assis au milieu de la conversation, qui lit tout ce qui passe entre ses mains avant de le retransmettre, si bien qu'aucune des deux parties ne perçoit le moindre délai.

Imaginez maintenant que cela arrive précisément aux personnes dont le métier est de détecter exactement ce genre de chose.

En septembre 2017, la société de cybersécurité néerlandaise Fox-IT — une entreprise qui enquête sur les violations de données, fabrique des capteurs de détection d'interception et conseille les gouvernements sur les techniques d'attaque des hackers — a découvert qu'un attaquant avait détourné le DNS de son propre domaine, obtenu un certificat TLS en son nom et passé une bonne partie de la journée à lire le trafic entrant et sortant de son portail client. La serrure du serrurier avait été crochetée. Et Fox-IT a alors fait ce que presque aucune entreprise victime d'une violation ne fait : elle a publié un compte rendu détaillé de la manière exacte dont cela s'était produit.

Même une entreprise de sécurité dépend de son registrar

Voici la vérité inconfortable que ce cas rend concrète : peu importe la qualité de votre sécurité interne, une grande partie de votre surface d'attaque réside dans une entreprise que vous ne gérez pas.

Votre domaine — le nom que vos clients saisissent, l'adresse contre laquelle vos certificats sont émis, la destination vers laquelle pointe votre e-mail — est configuré chez un bureau d'enregistrement de domaines. Quiconque contrôle ce compte registrar contrôle la résolution de votre nom. Il peut réorienter votre site web, rediriger votre courrier et prouver la « propriété » de votre domaine auprès d'une autorité de certification. Rien de tout cela ne nécessite de toucher à vos serveurs, vos pare-feux ou votre code. Il suffit de se connecter à un tableau de bord web.

Fox-IT était, en tout état de cause, une organisation de sécurité sérieuse. Elle effectuait une capture complète des paquets et exploitait ses propres capteurs réseau. Elle utilisait l'authentification à deux facteurs sur son portail client. Elle a par la suite été rachetée par NCC Group. Et elle était pourtant exposée via le seul compte auquel elle ne se connectait presque jamais — car, comme l'entreprise l'a elle-même formulé, les paramètres DNS changent très rarement en général, si bien que les identifiants qui les protégeaient s'étaient silencieusement périmés.

Comme Fox-IT l'a formulé dans l'introduction de son propre rapport : si une telle attaque peut toucher une entreprise de sécurité, elle pourrait très probablement toucher de nombreux autres types d'entreprises moins axées sur la sécurité.

19 septembre 2017 : le détournement et l'attaque MITM

Le récit de Fox-IT s'ouvre sur une formule qui est depuis lors devenue un petit classique de l'écriture en réponse aux incidents : Pour Fox-IT, le « si » est devenu « quand » le mardi 19 septembre 2017, lorsque l'entreprise est devenue victime d'une attaque man-in-the-middle.

Ce qui s'est passé n'était pas une exploitation de serveur. Aux premières heures du 19 septembre, un attaquant a accédé aux enregistrements DNS du domaine Fox-IT.com chez notre fournisseur de registrar tiers. Avec le contrôle de ces enregistrements, l'attaquant a modifié un enregistrement DNS pour un serveur particulier afin de le faire pointer vers un serveur en sa possession et d'intercepter puis rediriger le trafic vers la vraie infrastructure Fox-IT.

Ce dernier détail — rediriger le trafic — est ce qui en faisait une attaque man-in-the-middle plutôt qu'une simple panne. Les visiteurs atteignaient toujours un portail fonctionnel. Ils l'atteignaient simplement en passant d'abord par l'attaquant.

La cible était précise. L'attaque visait spécifiquement ClientPortal, l'application web d'échange de documents de Fox-IT, le système que Fox-IT utilisait pour échanger des fichiers de façon sécurisée avec ses clients, fournisseurs et autres organisations. En d'autres termes, l'attaquant s'en est pris directement au canal par lequel transitaient les documents clients sensibles.

Parce que Fox-IT l'a détecté et contenu, l'entreprise a limité le temps total effectif de l'attaque MitM à 10 heures et 24 minutes. La couverture indépendante confirme le même chiffre : l'incident s'est produit le 19 septembre et a duré 10 heures et 24 minutes.

Ce qui a réellement été intercepté

Dix heures d'attaque man-in-the-middle sur un portail d'échange de documents semble catastrophique. Le butin réel était maigre — et c'est précisément cette maigre récolte qui constitue le cœur de l'histoire.

Durant la fenêtre d'attaque, neuf utilisateurs individuels se sont connectés et leurs identifiants ont été interceptés. Mais ces identifiants étaient en grande partie inutilisables : le portail de Fox-IT exigeait un second facteur d'authentification que l'attaquant, positionné dans le chemin réseau, ne pouvait pas rejouer. Help Net Security a noté que les identifiants de connexion de neuf utilisateurs avaient été capturés mais étaient inutilisables sans le second facteur d'authentification.

En termes de fichiers, douze fichiers (dont dix uniques) ont été transférés et interceptés. Une poignée contenait des informations confidentielles sur des clients. L'attaquant a également capturé un sous-ensemble de noms et d'adresses e-mail d'utilisateurs de ClientPortal, quelques noms de compte et un numéro de téléphone mobile, comme l'a résumé SecurityWeek.

Deux faits ont maintenu les dégâts dans des limites acceptables. Premièrement, Fox-IT a déclaré clairement que les fichiers classifiés secret d'État ne sont jamais transférés via notre ClientPortal — les informations les plus sensibles ne transitaient tout simplement jamais par le canal exposé. Deuxièmement, le second facteur interne de l'entreprise a amorti le vol des identifiants. L'architecture a limité le rayon d'impact même après l'échec du périmètre — le DNS.

Comment c'est arrivé : un mot de passe périmé, pas de second facteur

Le mécanisme ressemble à une checklist illustrant comment un domaine peut être pris sans qu'une seule ligne de malware soit présente sur les serveurs de la victime.

Étape un — accéder au compte registrar. L'attaquant s'est connecté avec succès au panneau de contrôle DNS de notre fournisseur de registrar tiers en utilisant des identifiants valides. L'enquête de Fox-IT a conclu que l'attaquant avait probablement obtenu l'accès aux identifiants du panneau de contrôle DNS de leur registrar via la compromission d'un fournisseur tiers. Deux faiblesses cumulées ont permis à cette connexion de réussir : le mot de passe n'avait pas été changé depuis 2013 et le registrar ne proposait aucun second facteur du tout — au moment de la rédaction du rapport, Fox-IT notait que le registrar ne supporte toujours pas la 2FA.

Étape deux — modifier le DNS et prouver la « propriété » à une CA. Une fois le panneau ouvert, l'attaquant a réorienté le DNS. Mais pour mener une attaque man-in-the-middle crédible sur un site HTTPS, il avait besoin d'un certificat valide pour fox-it.com — et la méthode moderne pour en obtenir un est de prouver que vous contrôlez le domaine. L'attaquant a fait exactement cela. Dans une courte fenêtre autour de 02h05–02h15, il a temporairement réacheminé et intercepté les e-mails de Fox-IT dans le but précis de prouver qu'il possédait notre domaine dans le cadre de l'enregistrement frauduleux d'un certificat SSL pour notre ClientPortal. C'est là que tout lecteur devrait marquer une pause : le contrôle du DNS est, en pratique, le contrôle de la validation de domaine. Un certificat validé par domaine est accordé à quiconque peut répondre au défi de la CA — et ici, contrôler le DNS a permis à l'attaquant de réacheminer l'e-mail de validation et d'y répondre. C'est le DNS qui décide où atterrit cette preuve de propriété.

Étape trois — se positionner au milieu. Armé d'un certificat légitimement émis (mais obtenu frauduleusement), l'attaquant a fait pointer le domaine vers un VPS à l'étranger et a intercepté le trafic. Comme SecurityWeek l'a décrit, le certificat SSL frauduleux a été utilisé pour une attaque MitM sur ClientPortal, avec le trafic vers le portail acheminé via un fournisseur de serveur privé virtuel (VPS) à l'étranger. Pour un visiteur, rien n'était anormal. Le cadenas était réel. Le certificat validait. L'homme au milieu détenait une clé que le navigateur reconnaissait.

Trois couches — le DNS, l'autorité de certification et TLS lui-même — fonctionnaient toutes techniquement correctement. L'attaquant n'en a cassé aucune. Il a convaincu les trois qu'il était Fox-IT, et la seule chose qui lui a permis de le faire était un unique identifiant périmé à facteur unique auprès d'un registrar.

La réponse de Fox-IT : détecter, contenir, puis informer tout le monde

Ce qui distingue cet incident d'une centaine d'autres plus discrets, c'est la réponse — tant technique qu'éditoriale.

La détection a été rapide. Fox-IT a déterminé que les serveurs de noms de son domaine fox-it.com avaient été redirigés, détectant l'intrusion environ cinq heures après son début — environ cinq heures après le début de l'attaque, selon Help Net Security. La capture complète de paquets et les capteurs réseau que l'entreprise exploitait sur elle-même lui ont fourni l'enregistrement forensique permettant de reconstituer exactement ce qui avait été touché ou non.

Le confinement a été délibéré. Plutôt que de mettre le portail hors ligne et d'alerter l'attaquant, Fox-IT a opté pour une mesure d'atténuation plus discrète : elle a désactivé l'authentification par second facteur pour notre système d'authentification de connexion ClientPortal — une décision contre-intuitive, mais qui lui a permis de gérer la situation tout en reprenant le contrôle de son DNS, sans révéler qu'elle avait repéré l'intrusion. Puis elle a immédiatement contacté les clients concernés par ces fichiers.

Ensuite est venu ce qui en a fait une étude de cas. Trois mois plus tard, après analyse et avec une enquête judiciaire en cours, Fox-IT a publié un post-mortem complet et horodaté sous une thèse simple : la transparence génère plus de confiance que le secret et il y a des leçons à tirer. Une entreprise de sécurité avait été compromise de la façon la plus emblématique qui soit — et plutôt que d'enterrer l'affaire, elle a offert au secteur une analyse détaillée. Le titre de BleepingComputer a bien cerné le ton que méritait ce moment : Top Security Firm Admits to MitM Security Incident.

Ce que cela enseigne sur la sécurité des registrars et les verrouillages de registre

Retirez les détails spécifiques et l'incident Fox-IT est une leçon sur l'emplacement réel du périmètre. Pour la plupart des organisations, le périmètre n'est pas seulement le pare-feu. C'est la connexion au registrar. Voici ce que ce cas plaide :

1. Traitez le compte registrar comme une infrastructure de production. Il change rarement, ce qui le fait facilement oublier — c'est précisément pourquoi il se dégrade. Un mot de passe inchangé depuis 2013 n'est pas « à faible risque parce que peu fréquenté » ; c'est un identifiant de haute valeur sans aucune surveillance.

2. Exigez l'authentification multi-facteurs auprès du registrar — et partez si elle n'est pas proposée. Le registrar de Fox-IT ne supportait pas la 2FA du tout. Le compte le plus important dans la chaîne de sécurité de votre domaine était protégé par un seul mot de passe. La présence ou l'absence de la 2FA auprès d'un registrar est un critère d'achat, pas un simple bonus.

3. Utilisez un verrouillage de registre. Au-delà de la connexion au registrar, de nombreux registres proposent un verrouillage de registre — un blocage côté serveur qui empêche toute modification des serveurs de noms et des enregistrements de contacts, sauf à accomplir une étape de vérification manuelle hors bande. Un verrouillage de registre aurait signifié que même un mot de passe de registrar entièrement compromis ne pouvait pas réorienter silencieusement le DNS. Cela transforme le « à un panneau de distance » en « plusieurs humains et un appel téléphonique de distance ».

4. Déployez DNSSEC autant que possible. DNSSEC signe cryptographiquement les réponses DNS afin que les résolveurs puissent détecter les altérations dans le chemin de résolution. Ce n'est pas une solution miracle ici — un attaquant qui contrôle les enregistrements faisant autorité peut les re-signer — mais cela augmente le coût et ferme des catégories entières de manipulation DNS en transit. La défense en profondeur au niveau DNS compte précisément parce que, comme ce cas l'a montré, le DNS se situe au-dessus de TLS et de l'émission des certificats dans la chaîne de confiance.

5. Rappelez-vous que le contrôle du DNS équivaut au contrôle des certificats. L'attaquant a obtenu un certificat TLS valide en prouvant la propriété du domaine via un e-mail réacheminé. Surveillez les journaux de Certificate Transparency pour détecter les certificats inattendus émis pour vos domaines. Un certificat frauduleux apparaissant dans CT est l'un des rares signaux externes indiquant qu'un détournement DNS pourrait être en cours.

6. Maintenez un second facteur sur l'application elle-même. La 2FA du portail Fox-IT est la raison pour laquelle neuf mots de passe volés étaient inutilisables sans le second facteur d'authentification. Quand la couche externe (DNS) a échoué, la couche interne (MFA au niveau applicatif) a tout de même limité les dégâts.

Le fil conducteur : votre domaine est un point de défaillance unique que vous sous-traitez en partie. Le renforcer n'est pas glamour, et cela ne paie qu'au moment où quelqu'un tente exactement ce qui s'est passé chez Fox-IT.

L'angle Namefi

L'incident Fox-IT est, à sa racine, un problème de contrôle et de provenance. L'attaquant n'avait jamais besoin d'être Fox-IT. Il avait seulement besoin qu'un système — le panneau du registrar — croie qu'il l'était, suffisamment longtemps pour réorienter le DNS et émettre un certificat. Tout ce qui en découlait faisait confiance à cette conviction.

Namefi est construit pour rendre le contrôle de domaine vérifiable et inviolable plutôt que dépendant d'un seul mot de passe réutilisable dans le tableau de bord web d'un fournisseur. En représentant la propriété du domaine comme un actif vérifiable et enregistré sur la blockchain, compatible avec le DNS, le contrôle devient quelque chose que vous pouvez auditer et prouver — pas seulement un compte dans lequel quelqu'un pourrait silencieusement se connecter et reconfigurer. Les modifications critiques peuvent être liées à la propriété que vous détenez réellement, dans l'esprit d'un verrouillage de registre, plutôt qu'à un identifiant qui n'a pas été renouvelé depuis des années.

Rien de tout cela ne rendrait un attaquant déterminé impossible. Mais l'histoire de Fox-IT est finalement celle d'un simple vol de connexion se traduisant par un contrôle total sur un nom. Plus le contrôle du domaine est proche d'une propriété vérifiable — et plus il est difficile de modifier un nom silencieusement avec un seul mot de passe périmé — moins un moment comme celui où Fox-IT est passé du « si » au « quand » peut se propager avant que quelqu'un ne le remarque.

Une entreprise de sécurité a détecté son propre détournement en cinq heures et a dit au monde comment. La plupart des organisations ne le détecteraient ni en cinq heures ni jamais. La leçon la moins chère est celle que Fox-IT a payée : sécurisez le registrar avant qu'il ne devienne la porte ouverte.

Sources et lectures complémentaires

• Fox-IT (NCC Group) — Lessons learned from a Man-in-the-Middle attack (post-mortem principal)
• BleepingComputer — Top Security Firm Admits to MitM Security Incident
• Help Net Security — Security company Fox-IT reveals, details MitM attack they suffered in September
• Graham Cluley — Fox-IT reveals hackers hijacked its DNS records, spied on clients' files
• SecurityWeek — Hackers Target Security Firm Fox-IT
• GBHackers — Leading IT Security Firm Fox-IT hit by Cyber Attack
• Krebs on Security — A Deep Dive on the Recent Widespread DNS Hijacking Attacks (connexe : technique de détournement DNS + certificat frauduleux à grande échelle)