En visant une RCE pour 20 $, ils sont devenus par hasard les administrateurs de .mobi

 (labs.watchtowr.com)
2 points par GN⁺ 2024-09-12 | 1 commentaires | Partager sur WhatsApp
  • watchTowr Labs a enregistré pour environ 20 $ le domaine expiré dotmobiregistry.net, prenant ainsi le contrôle de l’ancien nom d’hôte du serveur WHOIS de .mobi, et a constaté que d’anciens clients WHOIS ainsi que certains flux de validation de certificats TLS/SSL continuaient de faire confiance à cette adresse
  • Le serveur WHOIS officiel de .mobi a été déplacé vers whois.nic.mobi, mais de nombreux outils continuaient d’interroger l’ancienne adresse whois.dotmobiregistry.net, codée en dur
  • Après avoir déployé un serveur WHOIS temporaire le 30 août 2024, ils ont reçu jusqu’au 4 septembre plus de 135 000 systèmes uniques et 2,5 millions de requêtes, révélant à quel point un domaine legacy abandonné restait largement connecté à l’infrastructure réelle d’Internet
  • Certaines autorités de certification TLS/SSL utilisaient une validation par e-mail fondée sur le WHOIS pour vérifier la propriété des domaines .mobi, et lors d’un test avec GlobalSign, whois@watchtowr.com est apparu comme adresse de validation possible pour microsoft.mobi
  • Les chercheurs n’ont pas demandé l’émission d’un certificat malveillant, et par la suite le NCSC britannique et ShadowServer ont relié ce domaine à un sinkhole afin de proxyfier des réponses WHOIS .mobi légitimes

Un domaine expiré à 20 $ ressuscité comme infrastructure WHOIS

  • L’objectif initial de watchTowr Labs était de trouver une RCE réellement exploitable dans la manière dont les clients WHOIS analysent les réponses des serveurs
  • Lors des premières expériences, ils se sont fait passer pour un serveur WHOIS et ont renvoyé de longues chaînes de caractères, confirmant que certains clients plantaient facilement
  • Mais pour contrôler une réponse WHOIS, un attaquant devait généralement disposer de l’un des éléments suivants
    • un MITM permettant d’intercepter le trafic WHOIS au niveau réseau
    • un accès au véritable serveur WHOIS
    • une redirection WHOIS vers un serveur contrôlé par l’attaquant
  • Ces prérequis constituent une barrière élevée dans un scénario d’attaque réel, mais l’expiration de l’ancien domaine du serveur WHOIS de .mobi a changé la donne
  • Le serveur WHOIS de .mobi était passé de whois.dotmobiregistry.net à whois.nic.mobi, et l’ancien domaine dotmobiregistry.net avait expiré vers décembre 2023
  • Après avoir enregistré ce domaine, watchTowr a placé un serveur WHOIS derrière whois.dotmobiregistry.net afin de vérifier si des clients WHOIS qui avaient encore l’ancienne adresse codée en dur continuaient à l’interroger

La surface d’attaque créée par le codage en dur de l’adresse du serveur WHOIS

  • WHOIS utilise un serveur distinct pour chaque TLD, mais les mécanismes standardisés permettant aux clients de découvrir ce serveur en temps réel sont faibles
  • En pratique, les outils WHOIS s’appuient souvent sur une liste textuelle publiée par l’IANA et codent en dur les adresses des serveurs au moment du développement
  • Tant que l’adresse change rarement, le problème reste discret, mais si elle change et que l’ancien domaine expire, d’anciens clients peuvent continuer à interroger une adresse abandonnée
  • watchTowr a répondu aux requêtes WHOIS reçues par le serveur lglass et a renvoyé de fausses informations WHOIS faisant apparaître watchTowr comme propriétaire de toutes les cibles interrogées
  • Les réponses contenaient aussi un ASCII art et une demande d’arrêt des requêtes

Volume et provenance des requêtes observées

  • Après le déploiement du serveur WHOIS le 30 août 2024, plus de 76 000 adresses IP sources uniques ont envoyé des requêtes en quelques heures
  • En environ deux jours, la base SQLite a accumulé 1,3 million de requêtes, et au 4 septembre 2024, le total atteignait 2,5 millions de requêtes pour plus de 135 000 systèmes uniques
  • Parmi les sources figuraient de grands registrars et des sites fournissant des fonctions WHOIS
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • Des services d’analyse de sécurité utilisaient eux aussi l’ancien serveur WHOIS de .mobi
    • urlscan.io utilisait ce résultat WHOIS sur les pages de domaines .mobi
    • VirusTotal interrogeait le serveur WHOIS temporaire de watchTowr et affichait le résultat
  • De nombreux serveurs mail et filtres antispam ont également été identifiés
    • Les filtres antispam peuvent effectuer une requête WHOIS sur le domaine de l’expéditeur
    • Cela allait de cheapsender.email à des hôtes semblant appartenir à l’infrastructure gouvernementale du Bangladesh, comme mail.bdcustoms.gov.bd
  • Des adresses liées au .gov ont été observées dans plusieurs pays
    • Argentine, Pakistan, Inde, Bangladesh, Indonésie, Bhoutan, Philippines, Israël, Éthiopie, Ukraine, États-Unis
    • Pour le Brésil, les exemples incluaient antispam.ap.gov.br et master.aneel.gov.br
  • Parmi les sources .mil, les forces armées suédoises sont citées en exemple
  • Des sources .edu et des entreprises de cybersécurité ont aussi été observées, notamment Group-IB, Detectify et Censys
  • Si des entités .gov et des serveurs mail interrogent le serveur WHOIS à chaque réception d’un e-mail depuis un domaine .mobi, cela ouvre la possibilité d’observer passivement qui communique avec qui

Vulnérabilités des anciens clients WHOIS et possibilité de RCE

  • watchTowr a recherché des précédents de vulnérabilités dans l’analyse des réponses WHOIS et a conclu que, sur 26 CVE trouvées, seules 3 concernaient encore des bugs déclenchables par une réponse WHOIS malformée
  • La rareté de ces cas peut être liée à l’idée qu’une exploitation réelle exige des prérequis difficiles, comme le contrôle du serveur WHOIS d’un TLD
  • phpWHOIS CVE-2015-5243 est une vulnérabilité permettant une RCE en exécutant via PHP eval des données reçues du serveur WHOIS
    • Le code vulnérable n’échappait qu’imparfaitement \" dans la chaîne de réponse WHOIS avant de la transmettre à eval
    • L’analyse de Netitude donne comme exemple de charge utile ”;phpinfo();//
    • Les versions vulnérables de phpWHOIS avaient whois.dotmobiregistry.net codé en dur
  • Fail2Ban CVE-2021-32749 est une vulnérabilité d’injection de commande due à une sortie WHOIS transmise sans nettoyage correct à l’outil mail
    • Fail2Ban peut faire une requête WHOIS sur le propriétaire d’une IP bloquée et inclure cette information dans un e-mail à l’administrateur
    • Mais cette vulnérabilité se produit dans le cadre d’une requête WHOIS sur une adresse IP, si bien que le contrôle du serveur WHOIS de domaine .mobi obtenu par watchTowr ne permettait pas de l’atteindre directement
  • Une exécution de code réelle exigeait donc toujours à la fois des clients interrogeant l’ancien serveur WHOIS de .mobi et une implémentation cliente vulnérable

Impact jusque dans les flux de validation de certificats TLS/SSL

  • Certaines autorités de certification TLS/SSL prenaient en charge une vérification de propriété de domaine consistant à extraire une adresse e-mail de contact administratif depuis les données WHOIS puis à envoyer un lien de validation à cette adresse
  • watchTowr cite comme exemples d’autorités de certification ou de revendeurs prenant en charge cette validation fondée sur le WHOIS
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • Lors d’un test chez GoGetSSL, en soumettant une CSR fictive pour watchTowr.mobi, l’adresse whois@watchtowr.com configurée par watchTowr n’apparaissait pas, seule une adresse placeholder laissant penser que la requête WHOIS n’avait pas abouti était affichée
  • Lors d’un test chez Entrust, l’enregistrement WHOIS légitime de microsoft.mobi a été analysé et seules des adresses du domaine microsoft.com ont été proposées pour la validation, tandis que watchTowr.mobi n’était pas analysé
  • Lors d’un test avec GlobalSign, il semblait au départ que l’enregistrement WHOIS de microsoft.mobi n’était pas analysé, mais lorsque watchTowr a copié le format de sortie du serveur WHOIS légitime pour microsoft.mobi et l’a servi depuis son propre serveur WHOIS, le résultat a changé
  • GlobalSign a alors interrogé le serveur WHOIS de watchTowr et a extrait de la réponse whois@watchtowr.com, proposé comme e-mail de validation pour microsoft.mobi
  • watchTowr s’est arrêté à ce stade et n’a pas obtenu en pratique de certificat TLS/SSL malveillant
  • En théorie, la chaîne d’attaque serait la suivante
    • placer un serveur WHOIS malveillant sur l’ancien nom d’hôte faisant autorité
    • tenter d’acheter un certificat TLS/SSL pour un domaine .mobi ciblé
    • laisser l’autorité de certification interroger le WHOIS et envoyer l’e-mail de validation à l’adresse de l’attaquant plutôt qu’au véritable propriétaire
    • cliquer sur le lien pour obtenir un certificat TLS/SSL pour le domaine ciblé
  • Une telle capacité pourrait théoriquement permettre des attaques d’interception de trafic ou d’usurpation du serveur visé

Mesures correctives et problèmes persistants

  • Avant la publication, le NCSC britannique et la ShadowServer Foundation ont coordonné la réponse
  • Le domaine dotmobiregistry.net et le nom d’hôte whois.dotmobiregistry.net ont été reliés à un système de sinkhole fourni par ShadowServer
  • Ce sinkhole proxyfie des réponses WHOIS légitimes pour les domaines .mobi
  • Une procédure de notification des parties affectées a également été mise en place
  • Ce cas met en lumière un défaut structurel qui apparaît lorsque se combinent infrastructure legacy, domaines abandonnés, traitements fondés sur WHOIS et procédures de validation des autorités de certification TLS/SSL
  • Un acteur capable de faire du MITM pourrait lui aussi falsifier les données WHOIS pour tenter le même type d’attaque, et même avec des mécanismes comme la transparence des certificats, des obstacles opérationnels demeurent face à une attaque à grande échelle

À lire aussi

1 commentaires

 
GN⁺ 2024-09-12
Avis sur Hacker News

  • Plusieurs erreurs humaines ont sans doute mené à cette situation, mais il y a une chose qui aurait clairement pu empêcher cette attaque précise : ne jamais laisser expirer un domaine
    Le serveur WHOIS du domaine de premier niveau .MOBI a été migré il y a quelques années de whois.dotmobiregistry.net vers whois.nic.mobi, et le domaine dotmobiregistry.net semble avoir été laissé expirer vers décembre 2023
    Quand une entreprise commence à utiliser un nouveau domaine en se disant que cela ne coûte que 10 dollars par an, ce domaine devient en pratique un actif à 10 dollars par an pour toujours. Une fois qu’un domaine est lié à l’activité, il est impossible de rompre totalement ce lien

    • C’est la raison la plus évidente pour laquelle Verisign est un opérateur monopolistique et devrait être régulé comme un service public, à l’image de l’électricité ou de l’eau. L’idée qu’il existe un choix et qu’on n’est pas captif relève presque de l’illusion : une fois qu’on achète et utilise un domaine, on y est en pratique lié pour toujours. Verisign le sait aussi, c’est pourquoi l’entreprise se bat bec et ongles pour préserver son monopole
    • Même Google s’est brièvement raté là-dessus
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • Il faut toujours utiliser des sous-domaines. Pour toute sa durée de vie, une entreprise n’a besoin que d’un seul domaine à 10 dollars par an
    • J’aime ce point. Cela me rappelle les billets de blog de Backblaze qui calculaien​t la probabilité qu’un nombre suffisant de disques tombe en panne pour entraîner une perte de données utilisateur
      Au final, les chiffres calculés eux-mêmes me semblaient peu importants, car il est plus probable d’oublier le paiement après avoir manqué les notifications de renouvellement à cause d’une carte bancaire expirée ou d’un filtrage antispam
      Comment les grandes entreprises font-elles pour ne pas oublier de payer leurs domaines ? Confient-elles à des bureaux d’enregistrement coûteux des renouvellements pour une durée proche de « l’infini » ? Cela ressemble à un problème d’exploitation business assez difficile

  • J’ai l’impression qu’un matin, en me réveillant, je vais apprendre qu’Internet a complètement disparu parce que quelqu’un, dans une chambre d’hôtel isolée, aura fait quelque chose avec un Raspberry Pi connecté au hotspot Wi-Fi du café voisin

    • Cela me rappelle les pannes d’Internet en résidence universitaire quand quelqu’un branchait n’importe quel routeur apporté de chez lui et diffusait des adresses DHCP foireuses. C’est comme si ça se produisait à l’échelle mondiale
    • En réalité, beaucoup de choses reposent effectivement sur l’espoir et la prière [0], mais Internet a été conçu pour être robuste par architecture [1]. Dans ce cas, la portée était limitée à .mobi
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • Le fait que cela soit récemment lié à “White House asks agencies to step up internet routing security efforts” [1] est une pure coïncidence
      [1] https://news.ycombinator.com/item?id=41482087

  • Pourquoi les outils codent-ils en dur des listes de serveurs WHOIS ?
    Il semble exister une méthode standard pour publier cela dans le DNS, mais un test rapide montre que de nombreux domaines de premier niveau n’ont pas l’enregistrement correspondant. Un exemple qui fonctionne est dig _nicname._tcp.fr SRV +noall +answer, qui renvoie _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr.
    Il existe aussi un brouillon Internet expiré à ce sujet : https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • Un simple mobi.whois.arpa. CNAME whois.nic.mobi aurait déjà suffi à résoudre le problème. Mais faire en sorte que tout le monde s’accorde sur ce mécanisme et l’adopte est difficile
      Comme fanf2 le dit plus bas, on pourrait aussi commencer par interroger le serveur WHOIS de l’IANA. Si l’on interroge mobi sur https://www.iana.org/whois, une partie de la réponse contient whois: whois.nic.mobi
    • Dans le monde réel, il y a beaucoup plus de chaînes codées en dur qu’on ne l’imagine, et beaucoup plus qu’il ne devrait y en avoir
    • WHOIS est probablement bien plus ancien que le concept même d’enregistrement SRV
    • Ce genre d’outils est généralement créé pour un besoin ponctuel, puis publié pour que d’autres personnes l’utilisent ou pour que l’auteur puisse s’y référer plus tard. D’autres « ingénieurs » le copient-collent sans hésiter, et une fois que cela arrive en production, cela devient un CVE comme ici
      Le manque de compétence des développeurs est déjà un problème, mais les hallucinations de l’IA vont encore aggraver la situation

  • J’ai vu trop d’équipes ne pas comprendre qu’une fois qu’un domaine commence à être utilisé de manière significative, il faut en pratique le renouveler jusqu’à la mort thermique de l’univers, ou au moins jusqu’à la mort thermique de l’équipe
    Que ce soit dans ce genre de cas, avec une URL ancienne mais importante qui traîne quelque part, ou avec un membre de l’équipe qui s’est inscrit à un service avec une adresse e-mail de l’ancien domaine, il est très difficile de savoir quand on peut vraiment abandonner un vieux domaine

  • La surface d’attaque créée par le simple achat d’un domaine expiré appartenant à un ancien serveur WHOIS est vraiment immense

  • La vraie solution à WHOIS, c’est RDAP
    Malheureusement, ce n’est pas obligatoire pour les domaines de premier niveau nationaux, et même parmi les domaines de premier niveau non nationaux, beaucoup ne fonctionnent pas correctement
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • En quoi cela atténue-t-il les problèmes décrits dans l’article ?

  • Très beau travail
    Le domaine dotmobiregistry.net et le nom d’hôte whois.dotmobiregisry.net pointent désormais vers un système de sinkhole fourni par ShadowServer, qui est censé proxifier les réponses WHOIS légitimes pour les domaines .mobi
    Si ces domaines devaient être abandonnés, il aurait mieux valu renvoyer une réponse du type 404. Les laisser continuer à fonctionner comme si de rien n’était réduit l’incitation à passer au domaine officiel

    • Whois ne prend pas en charge les codes d’état HTTP, mais le sinkhole de ShadowServer répond ainsi :
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • À lire l’article, cela faisait déjà plusieurs années que c’était cassé, et beaucoup de clients ne semblaient pas s’en être aperçus

  • Je pense que l’approche globale de l’informatique est vouée à l’échec. Elle repose sur une sécurité parfaite, en supposant que cette sécurité sera obtenue par des contrôles SBOM et des mises à jour fréquentes
    Mais cela n’arrive jamais. Rien que pour log4j, 40 % de l’ensemble des téléchargements concernent des versions vulnérables. Et c’est sans parler des fournisseurs de la chaîne d’approvisionnement qui mettent la clé sous la porte ou cessent de maintenir des composants
    Comme notre corps est en permanence un champ de bataille contre les micro-organismes, tout sera toujours forcément plein de bugs et de failles

    • Non, lentement mais sûrement, on peut écrire du bon code et du code fiable, s’en servir pour créer de meilleurs outils, puis utiliser ces outils pour construire la suite
      Cela prendra probablement des décennies, mais la voie paraît assez claire. Il faut y consacrer des efforts, appliquer les connaissances tirées de chaque « leçon » et ne pas s’arrêter

  • J’ai bien aimé l’ambiance générale du type « on ne voulait pas faire ça, mais la situation a continué à prendre de l’ampleur et, à chaque étape, on a obtenu quelque chose de plus gros que prévu »
    Si les personnes qui s’y opposaient avaient écouté et corrigé le parsing, les auteurs auraient peut-être pu s’épargner tout ce travail

  • En retournant la question, faut-il croire que tous les serveurs WHOIS du monde sont toujours authentiques et sûrs ?
    En particulier, du point de vue d’une autorité de certification qui effectue une validation TLS, elle n’a sûrement pas envie de savoir qu’en exécutant whois somethingarbitrary.ru, elle s’expose à une exécution de code à distance à cause d’un serveur russe