Wie man für 20 US-Dollar RCE anstrebte und versehentlich Admin von .mobi wurde

 (labs.watchtowr.com)
2 Punkte von GN⁺ 2024-09-12 | 1 Kommentare | Auf WhatsApp teilen
  • watchTowr Labs registrierte für etwa 20 US-Dollar die abgelaufene Domain dotmobiregistry.net und übernahm damit die Kontrolle über den früheren Hostnamen des WHOIS-Servers für .mobi. Dabei zeigte sich, dass veraltete WHOIS-Clients und Abläufe zur TLS/SSL-Zertifikatsprüfung dieser Adresse weiterhin vertrauen.
  • Der offizielle WHOIS-Server für .mobi wurde auf whois.nic.mobi migriert, doch viele Tools fragten weiterhin die alte Adresse whois.dotmobiregistry.net ab, weil sie hartcodiert war.
  • Nachdem am 30. August 2024 ein temporärer WHOIS-Server bereitgestellt worden war, gingen bis zum 4. September Anfragen von mehr als 135.000 eindeutigen Systemen und insgesamt 2,5 Millionen Abfragen ein. Das zeigte, wie breit eine verwaiste Legacy-Domain noch mit realer Internet-Infrastruktur verbunden war.
  • Einige TLS/SSL-Zertifizierungsstellen nutzten zur Prüfung der Inhaberschaft von .mobi-Domains eine WHOIS-basierte E-Mail-Verifizierung. In einem GlobalSign-Test wurde für microsoft.mobi als Kandidat für die Verifizierungs-E-Mail whois@watchtowr.com angezeigt.
  • Die Forschenden ließen kein bösartiges Zertifikat tatsächlich ausstellen. Später leiteten das britische NCSC und ShadowServer die Domain in ein Sinkhole um, das legitime .mobi-WHOIS-Antworten per Proxy bereitstellt.

Eine abgelaufene 20-Dollar-Domain wird als WHOIS-Infrastruktur wiederbelebt

  • Das ursprüngliche Ziel von watchTowr Labs war es, beim Parsen von Serverantworten durch WHOIS-Clients eine realistisch ausnutzbare RCE zu finden.
  • In ersten Experimenten gaben sie sich als WHOIS-Server aus und lieferten lange Zeichenketten zurück; dabei zeigte sich, dass einige Clients leicht zum Absturz gebracht werden konnten.
  • Damit ein Angreifer WHOIS-Antworten kontrollieren kann, ist normalerweise eines der folgenden Dinge nötig:
    • ein MITM, der WHOIS-Traffic auf Netzwerkebene abfängt
    • Zugriff auf den echten WHOIS-Server
    • eine WHOIS-Referral auf einen vom Angreifer kontrollierten Server
  • Diese Voraussetzungen sind bei realen Angriffen eine hohe Hürde, doch mit dem Ablauf der früheren WHOIS-Server-Domain von .mobi änderte sich die Lage.
  • Der WHOIS-Server für .mobi war früher unter whois.dotmobiregistry.net erreichbar und wurde später auf whois.nic.mobi migriert; die alte Domain dotmobiregistry.net war etwa seit Dezember 2023 abgelaufen.
  • watchTowr registrierte diese Domain und stellte hinter whois.dotmobiregistry.net einen WHOIS-Server bereit, um zu prüfen, ob WHOIS-Clients mit hartcodierter alter Adresse weiterhin Abfragen stellen.

Angriffsfläche durch hartcodierte WHOIS-Server-Adressen

  • WHOIS nutzt je nach TLD eigene Server, doch es gibt keinen starken standardisierten Mechanismus, mit dem Clients diesen Server in Echtzeit ermitteln.
  • In der Praxis orientieren sich WHOIS-Tools häufig an einer von der IANA veröffentlichten Textliste und hartcodieren die Serveradresse zum Entwicklungszeitpunkt.
  • Solange sich Serveradressen selten ändern, fällt das Problem weniger auf. Wenn sich eine Adresse aber ändert und die frühere Domain abläuft, können alte Clients weiter Anfragen an die ausgemusterte Adresse senden.
  • watchTowr beantwortete WHOIS-Anfragen, die beim lglass-Server eingingen, und gab gefälschte WHOIS-Informationen zurück, die so wirkten, als sei watchTowr Inhaber aller abgefragten Ziele.
  • Die Antwort enthielt auch ASCII-Art und die Bitte, die Abfragen einzustellen.

Beobachtetes Abfragevolumen und Quellen

  • Nach der Bereitstellung des WHOIS-Servers am 30. August 2024 stellten innerhalb weniger Stunden mehr als 76.000 eindeutige Quell-IP-Adressen Anfragen.
  • Innerhalb von etwa zwei Tagen sammelten sich 1,3 Millionen Abfragen in einer SQLite-DB; zum 4. September 2024 wurden 2,5 Millionen Abfragen und mehr als 135.000 eindeutige Systeme festgestellt.
  • Zu den Quellen der Abfragen gehörten große Domain-Registrare und Websites mit WHOIS-Funktionen:
    • domain.com
    • godaddy.com
    • who.is
    • whois.ru
    • smallseo.tools
    • seocheki.net
    • centralops.net
    • name.com
    • webchart.org
  • Auch Sicherheitsanalyse-Dienste nutzten den früheren .mobi-WHOIS-Server:
    • urlscan.io verwendet auf .mobi-Domainseiten die entsprechenden WHOIS-Ergebnisse.
    • VirusTotal fragte den temporären WHOIS-Server von watchTowr ab und zeigte die Ergebnisse an.
  • Auch zahlreiche Mailserver und Spamfilter wurden beobachtet:
    • Spamfilter können WHOIS-Lookups für Absenderdomains durchführen.
    • Die Spannbreite reichte von cheapsender.email bis zu Hosts wie mail.bdcustoms.gov.bd, die wie Infrastruktur der Regierung von Bangladesch wirkten.
  • Adressen mit .gov-Bezug wurden in mehreren Ländern festgestellt:
    • Argentinien, Pakistan, Indien, Bangladesch, Indonesien, Bhutan, Philippinen, Israel, Äthiopien, Ukraine, USA
    • Als Beispiele mit Brasilien-Bezug wurden antispam.ap.gov.br und master.aneel.gov.br genannt.
  • Unter den .mil-Quellen wurden beispielhaft die Swedish Armed Forces genannt.
  • Auch Quellen aus .edu sowie von Sicherheitsunternehmen wurden gefunden; erwähnt wurden unter anderem Group-IB, Detectify und Censys.
  • Wenn .gov-Stellen und Mailserver jedes Mal den WHOIS-Server abfragen, wenn sie E-Mails von .mobi-Domains erhalten, entsteht die Möglichkeit, passiv zu beobachten, wer mit wem kommuniziert.

Alte WHOIS-Client-Schwachstellen und RCE-Potenzial

  • watchTowr suchte nach früheren Fällen von Schwachstellen beim Parsen von WHOIS-Antworten und fasste zusammen, dass von 26 relevanten CVE-Suchergebnissen nur 3 Bugs übrig blieben, die durch fehlerhafte WHOIS-Antworten ausgelöst werden.
  • Dass es so wenige Fälle gibt, könnte damit zusammenhängen, dass für eine reale Ausnutzung schwierige Voraussetzungen wie die Kontrolle über einen TLD-WHOIS-Server angenommen werden.
  • phpWHOIS CVE-2015-5243 ist eine Schwachstelle, bei der vom WHOIS-Server empfangene Daten per PHP-eval ausgeführt werden und dadurch RCE möglich ist.
    • Der verwundbare Code escapt in der WHOIS-Antwortzeichenkette nur " unvollständig und übergibt sie anschließend an eval.
    • Die Analyse von Netitude nennt Beispiel-Payloads wie ”;phpinfo();//.
    • Die verwundbare phpWHOIS-Version hatte whois.dotmobiregistry.net hartcodiert.
  • Fail2Ban CVE-2021-32749 ist eine Schwachstelle, bei der WHOIS-Ausgaben nicht korrekt bereinigt an das Tool mail übergeben werden, wodurch Command Injection möglich ist.
    • Fail2Ban kann per WHOIS Informationen zum Inhaber einer gesperrten IP-Adresse abfragen und in eine Admin-E-Mail aufnehmen.
    • Diese Schwachstelle tritt jedoch bei WHOIS-Abfragen zu IP-Adressen auf und ist daher allein durch die Kontrolle über den von watchTowr übernommenen .mobi-Domain-WHOIS-Server nicht direkt erreichbar.
  • Für echte Codeausführung braucht es weiterhin sowohl Clients, die noch den alten .mobi-WHOIS-Server abfragen, als auch eine verwundbare Client-Implementierung.

Auswirkungen bis in TLS/SSL-Zertifikatsprüfungen

  • Einige TLS/SSL-Zertifizierungsstellen unterstützen ein Verfahren, bei dem sie zur Prüfung der Domain-Inhaberschaft die E-Mail-Adresse des administrativen Kontakts aus WHOIS-Daten parsen und an diese Adresse einen Verifizierungslink senden.
  • Von watchTowr aufgelistete Beispiele für Zertifizierungsstellen oder Reseller mit Unterstützung für WHOIS-basierte Inhaberschaftsprüfung sind:
    • Trustico
    • Comodo
    • SSLS
    • GoGetSSL
    • GlobalSign
    • DigiSign
    • Sectigo
  • In einem GoGetSSL-Test wurde beim Hochladen eines fiktiven CSR für watchTowr.mobi das von watchTowr gesetzte whois@watchtowr.com nicht angezeigt; stattdessen erschien nur eine Placeholder-E-Mail, die darauf hindeutete, dass WHOIS nicht erfolgreich war.
  • In einem Entrust-Test wurde der legitime WHOIS-Record von microsoft.mobi geparst, sodass nur E-Mail-Adressen der Domain microsoft.com als Verifizierungskandidaten angezeigt wurden; watchTowr.mobi wurde nicht geparst.
  • In einem GlobalSign-Test schien es zunächst, als könne der WHOIS-Record von microsoft.mobi nicht geparst werden. Nachdem watchTowr jedoch das Ausgabeformat des legitimen WHOIS-Servers für microsoft.mobi kopierte und auf dem eigenen WHOIS-Server passend bereitstellte, änderte sich das Ergebnis.
  • GlobalSign fragte den WHOIS-Server von watchTowr ab, parste aus der Antwort whois@watchtowr.com und schlug diese Adresse als Verifizierungs-E-Mail für microsoft.mobi vor.
  • watchTowr brach an diesem Punkt ab und ließ kein bösartiges TLS/SSL-Zertifikat tatsächlich ausstellen.
  • Der theoretische Angriffsablauf sieht so aus:
    • Auf einem früher autoritativen Hostnamen wird ein bösartiger WHOIS-Server platziert.
    • Es wird versucht, ein TLS/SSL-Zertifikat für die Ziel-.mobi-Domain zu kaufen.
    • Die Zertifizierungsstelle fragt WHOIS ab und sendet die Verifizierungs-E-Mail an die E-Mail-Adresse des Angreifers statt an den tatsächlichen Inhaber.
    • Klickt der Angreifer auf den Link, kann er ein TLS/SSL-Zertifikat für die Zieldomain erhalten.
  • Mit dieser Fähigkeit wären theoretisch Angriffe wie Traffic Interception oder die Imitation des Zielservers möglich.

Nachmaßnahmen und verbleibende Probleme

  • Vor der Veröffentlichung reagierten das britische NCSC und die ShadowServer Foundation gemeinsam.
  • Die Domain dotmobiregistry.net und der Hostname whois.dotmobiregistry.net wurden auf ein von ShadowServer bereitgestelltes Sinkhole-System umgeleitet.
  • Dieses Sinkhole proxyt legitime WHOIS-Antworten für .mobi-Domains.
  • Außerdem wurde ein Verfahren eingerichtet, um betroffene Parteien zu informieren.
  • Der Fall zeigt einen strukturellen Fehler, der entsteht, wenn Legacy-Infrastruktur, verwaiste Domains, WHOIS-basierte Verarbeitung und Prüfprozesse von TLS/SSL-Zertifizierungsstellen zusammenwirken.
  • Auch Akteure mit MITM-Möglichkeiten könnten WHOIS-Daten fälschen und Angriffe desselben Typs versuchen; selbst mit Mechanismen wie Certificate Transparency bleiben bei groß angelegten Angriffen operative Hürden bestehen.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-12
Meinungen auf Hacker News

  • Dass es so weit kommen konnte, lag vermutlich an einer Verkettung von Fehlern mehrerer Personen, aber eines ist klar, was diesen konkreten Angriff hätte verhindern können: Domains niemals auslaufen lassen
    Der WHOIS-Server der Top-Level-Domain .MOBI wurde vor einigen Jahren von whois.dotmobiregistry.net zu whois.nic.mobi migriert, und die Domain dotmobiregistry.net scheint etwa im Dezember 2023 abgelaufen und unbeachtet geblieben zu sein.
    Wenn ein Unternehmen anfängt, eine neue Domain zu nutzen, weil sie 10 Dollar pro Jahr kostet, wird diese Domain faktisch zu einem Asset, für das für immer 10 Dollar pro Jahr fällig werden. Eine Domain, die einmal mit dem Geschäft verknüpft war, lässt sich nie vollständig von dieser Verknüpfung lösen.

    • Das ist der deutlichste Grund, warum Verisign ein Monopolbetreiber ist und wie ein öffentliches Gut, ähnlich Strom oder Wasser, reguliert werden sollte. Die Behauptung, man habe Wahlfreiheit und sei nicht abhängig, ist nahezu eine Illusion; sobald man eine Domain kauft und zu nutzen beginnt, ist man faktisch für immer daran gebunden. Verisign weiß das ebenfalls und kämpft deshalb verzweifelt darum, sein Monopol zu bewahren.
    • Sogar Google hat das einmal kurz vermasselt
      https://money.cnn.com/2016/01/29/technology/google-domain-pu...
    • Man sollte immer Subdomains verwenden. Für ein Unternehmen reicht während seiner gesamten Existenz eine einzige Domain für 10 Dollar pro Jahr.
    • Diesen Punkt finde ich gut. Er erinnert mich an die Blogbeiträge von Backblaze, in denen berechnet wurde, wie wahrscheinlich es ist, dass so viele Festplatten ausfallen, dass Nutzerdaten verloren gehen.
      Am Ende fand ich den berechneten Wert selbst nicht besonders wichtig, weil es wahrscheinlicher ist, dass man wegen einer abgelaufenen Kreditkarte oder Spam-Filterung eine Verlängerungsbenachrichtigung verpasst und die Zahlung vergisst.
      Wie vergessen Großunternehmen eigentlich nicht, Domaingebühren zu zahlen? Beauftragen sie teure Registrare mit Verlängerungen für einen Zeitraum nahe „unendlich“? Das wirkt wie ein ziemlich schwieriges Business-Operations-Problem.

  • Ich habe das Gefühl, dass ich eines Morgens aufwache und die Nachricht sehe, dass das gesamte Internet verschwunden ist, weil jemand in einem abgelegenen Hotelzimmer mit einem Raspberry Pi, der mit dem WLAN-Hotspot eines nahegelegenen Cafés verbunden war, irgendetwas gemacht hat.

    • Das erinnert mich daran, wie in Studentenwohnheimen das Internet kaputtging, wenn jemand irgendeinen Router von zu Hause einsteckte und falsche DHCP-Adressen verteilte. Es fühlt sich an wie dasselbe im globalen Maßstab.
    • Tatsächlich beruhen ziemlich viele Dinge auf Hoffnung und Gebeten [0], aber das Internet wurde vom Design her robust gebaut [1]. In diesem Fall war der Umfang auf .mobi beschränkt.
      [0] https://xkcd.com/2347/
      [1] https://en.wikipedia.org/wiki/ARPANET#Debate_about_design_go...
    • Dass dies mit der jüngsten Meldung „White House asks agencies to step up internet routing security efforts“ [1] zusammenhängt, ist reiner Zufall.
      [1] https://news.ycombinator.com/item?id=41482087

  • Warum verwenden Tools hartcodierte Listen von WHOIS-Servern?
    Es scheint eine standardisierte Möglichkeit zu geben, dies in DNS einzutragen, aber ein kurzer Test zeigt, dass bei vielen Top-Level-Domains die Records fehlen. Ein funktionierendes Beispiel ist dig _nicname._tcp.fr SRV +noall +answer, wobei _nicname._tcp.fr. 3588 IN SRV 0 0 43 whois.nic.fr. zurückgegeben wird.
    Außerdem gibt es dazu auch einen abgelaufenen Internet-Draft: https://datatracker.ietf.org/doc/html/draft-sanz-whois-srv-0...

    • Schon ein einfaches mobi.whois.arpa. CNAME whois.nic.mobi hätte das Problem lösen können. Schwierig ist allerdings, alle dazu zu bringen, sich auf so einen Ansatz zu einigen und ihn zu übernehmen.
      Wie fanf2 unten sagte, könnte man wohl auch zuerst den IANA-WHOIS-Server abfragen. Wenn man auf https://www.iana.org/whois nach mobi sucht, kommt als Teil der Antwort whois: whois.nic.mobi zurück.
    • In der Realität gibt es viel mehr hartcodierte Strings, als man sich vorstellt – und viel mehr, als es geben sollte.
    • WHOIS ist vermutlich deutlich älter als überhaupt das Konzept von SRV-Records.
    • Solche Tools entstehen meist aus einem einmaligen Bedarf heraus und werden dann veröffentlicht, damit andere sie nutzen oder man selbst später darauf zurückgreifen kann. Andere „Ingenieure“ kopieren sie ohne Zögern, und wenn das in Produktionsumgebungen landet, wird daraus wie hier eine CVE.
      Mangelnde Entwicklerkompetenz ist schon ein Problem, aber KI-Halluzinationen werden diese Situation noch verschärfen.

  • Ich habe zu viele Teams gesehen, die nicht begreifen, dass man eine Domain, sobald man sie einmal in nennenswerter Weise nutzt, faktisch bis zum Wärmetod des Universums verlängern muss – oder zumindest bis zum Wärmetod des Teams.
    Ob in so einem Fall, bei einer alten, aber wichtigen URL, die irgendwo noch übrig ist, oder wenn ein Teammitglied sich mit einer E-Mail-Adresse einer alten Domain bei einem Dienst registriert hat: Es ist viel zu schwer zu wissen, wann man eine alte Domain wirklich loslassen kann.

  • Die Angriffsfläche, die allein dadurch entsteht, dass man eine abgelaufene Domain eines alten WHOIS-Servers kauft, ist wirklich gewaltig.

  • Die eigentliche Lösung für WHOIS ist RDAP.
    Leider ist es für länderspezifische Top-Level-Domains nicht verpflichtend, und auch unter den nicht länderspezifischen Top-Level-Domains gibt es viele, bei denen es nicht richtig funktioniert.
    https://en.wikipedia.org/wiki/Registration_Data_Access_Proto...
    https://resolve.rs/domains/rdap-missing.html

    • Wie entschärft das die im Artikel beschriebenen Probleme?

  • Sehr gute Arbeit.
    Die Domain dotmobiregistry.net und der Hostname whois.dotmobiregisry.net zeigen nun offenbar auf ein von ShadowServer bereitgestelltes Sinkhole-System, das die regulären WHOIS-Antworten für .mobi-Domains proxyt.
    Wenn diese Domains außer Betrieb genommen werden sollten, wäre es besser gewesen, eine Antwort wie 404 zurückzugeben. Lässt man sie weiter scheinbar normal funktionieren, sinkt der Anreiz, auf die offizielle Domain umzustellen.

    • Whois unterstützt keine HTTP-Statuscodes, aber das ShadowServer-Sinkhole antwortet so:
      Domain not found.
      >>> Please update your code or tell your system administrator to use whois.nic.mobi, the authoritative WHOIS server for this domain. <<<
    • Dem Artikel zufolge war der Dienst offenbar schon seit Jahren kaputt, und viele Clients haben das nicht bemerkt.

  • Ich denke, der grundlegende Ansatz in der Computerwelt insgesamt ist zum Scheitern verurteilt. Er setzt auf perfekte Sicherheit und nimmt an, dass diese durch SBOM-Prüfungen und häufige Updates erreicht wird.
    Aber so wird es niemals kommen. Selbst bei log4j entfallen 40 % aller Downloads auf verwundbare Versionen. Ganz zu schweigen davon, wenn ein Anbieter in der Lieferkette den Betrieb einstellt oder die Wartung einer Komponente aufgibt.
    So wie unser Körper ständig ein Schlachtfeld im Kampf gegen Mikroorganismen ist, wird alles immer voller Bugs und voller Löcher sein.

    • Nein, langsam, aber sicher kann man guten und vertrauenswürdigen Code schreiben, damit bessere Werkzeuge bauen und mit diesen Werkzeugen dann das Nächste schaffen.
      Es wird vermutlich Jahrzehnte dauern, aber der Weg wirkt ziemlich klar: Aufwand investieren, das Wissen aus jeder „Lektion“ anwenden und nicht aufhören.

  • Insgesamt gefiel mir die Stimmung von „Wir wollten das eigentlich nicht machen, aber die Sache wurde immer größer, und bei jedem Schritt bekamen wir etwas noch Größeres als erwartet“.
    Hätten die Leute, die sich dagegen gewehrt haben, zugehört und ihr Parsing repariert, hätten sich die Autoren diese Mühe vielleicht sparen können.

  • Wenn man das umdreht: Müssen wir dann darauf vertrauen, dass alle WHOIS-Server weltweit immer echt und sicher sind?
    Besonders aus Sicht einer Zertifizierungsstelle, die TLS-Validierung durchführt, möchte man wohl nicht wissen, dass man mit whois somethingarbitrary.ru durch einen russischen Server einer Remote Code Execution ausgesetzt ist.