Das Hacken von Millionen Modems und die Untersuchung der Kompromittierung meines Modems

• Sam Curry entdeckte, dass eine HTTP-Anfrage aus seinem Heimnetzwerk 10 Sekunden später von einer DigitalOcean-IP identisch wiederholt wurde, und vermutete nach dem Austausch seines Cox-Panoramic-Wifi-Gateways eine Kompromittierung des bisherigen Modems, weil das Problem danach verschwand
• Die IP des wiederholten Traffics, 159.65.76.209, war mit Adidas-bezogenen Domains, ISG-Latam-Phishing-Domains und offenbar algorithmisch erzeugten Domains für C&C verknüpft, doch der tatsächliche Angriffsweg konnte nicht eindeutig bestimmt werden
• Bei der Analyse des Cox-Business-Portals im Jahr 2024 wurde hinter /api/cbma/ eine Spring-basierte API samt Swagger-Dokumentation gefunden; von rund 700 APIs zeigten einige ein Berechtigungsumgehungsproblem, bei dem sich Authentifizierungsfehler und 200 OK abwechselten
• Über diese Berechtigungsumgehung waren Kundensuche, Abruf von Konto-PII, Abfrage von Geräte-MAC-Adressen, Abfrage von Modem-IP-Adressen, Lesen und Schreiben von Cox-Business-Konten sowie Änderungen an Gerätekonfigurationen wie der WiFi-SSID möglich; im PoC wurde seine eigene SSID auf Curry geändert
• Cox nahm die exponierten APIs innerhalb von 6 Stunden nach der Meldung vom Netz, am nächsten Tag ließ sich das Problem nicht mehr reproduzieren, und das Unternehmen erklärte, der betroffene API-Service sei 2023 gestartet und unabhängig von der Modem-Kompromittierung von 2021; Hinweise auf frühere Ausnutzung habe es nicht gegeben

---

Merkwürdiger Traffic, der am Heimmodem begann

• Um eine Blind-XXE-Schwachstelle im Heimnetz zu testen, richtete er auf einer AWS-Instanz einen einfachen Python-HTTP-Server ein und prüfte, ob externe Anfragen ankamen
• Direkt nachdem eine mit curl vom Heimcomputer gesendete Anfrage korrekt geloggt wurde, forderte die unbekannte IP 159.65.76.209 denselben Pfad 10 Sekunden später erneut an
• Auch als er mit Safari auf dem iPhone einen anderen Pfad aufrief, spielte dieselbe IP die identische Anfrage nach, was so aussah, als würde nicht ein einzelner Computer, sondern der gesamte Traffic des Heimnetzwerks beobachtet
• Dasselbe Verhalten trat auf einer neuen AWS-Instanz mit Nginx und später auch auf einer GCP-Instanz auf, wodurch eine Kompromittierung von AWS ausgeschlossen wurde
• Nachdem er das bisherige Cox-Panoramic-Wifi-Gateway im Laden zurückgegeben und durch neue Hardware ersetzt hatte, verschwand der wiederholte Traffic, und in den Logs tauchte keine „andere IP“ mehr auf

Untersuchung von 159.65.76.209

• Die IP gehörte nachweislich DigitalOcean und war keine Cox-ISP-Adresse
• In den VirusTotal-Daten wirkten 3 der 5 zuletzt verknüpften Domains wie Phishing-Seiten, 2 wie Mailserver
  • regional.adidas.com.py
  • isglatam.online
  • isglatam.tk
  • mx12.limit742921.tokyo
  • mx12.jingoism44769.xyz
• isglatam.online und isglatam.tk waren zeitweise Phishing-Websites, die auf das südamerikanische Cybersecurity-Unternehmen isglatam.com zielten
• Laut URLscan hosteten die beiden ISG-Latam-Domains gewöhnliche BeEF-Phishing-Seiten; zugehörige Daten sind im urlscan.io-Ergebnis einsehbar
• Dieselbe IP war zwar mit Adidas, ISG Latam und dem Replay des Modem-Traffics verknüpft, dennoch ließ sich nicht vollständig ausschließen, dass die IP zwischen mehreren Besitzern neu zugewiesen worden war

Drei Jahre später fortgesetzte Analyse

• Anfang 2024 machten Freunde aus dem Sicherheitsbereich auf das Format von limit742921.tokyo und jingoism44769.xyz aufmerksam
• Eine Reverse-IP-Suche anhand der IP der mx1-Subdomain von limit742921.tokyo förderte mehr als 1.000 Domains mit demselben Muster zutage
• Alle Domainnamen hatten die Form [word][6 numbers].[TLD]
  • Beispiel: acquire543225.biz
  • Beispiel: battery935904.biz
  • Beispiel: grocery634272.biz
• Wegen der Massenregistrierung und der algorithmischen Struktur sah das wie ein Domain-Generierungsalgorithmus aus, den Malware-Betreiber zum Verbergen von C&C-Serveradressen nutzen könnten
• Die zuletzt beobachtete Domain wurde am 17. März 2023 registriert; zu diesem Zeitpunkt wurde kein Host mehr aufgelöst, und es fanden sich keine ähnlichen Domains mehr, die auf derselben IP registriert waren

Hypothese aus ISP-Managementfunktionen und TR-069

• Ein Cox-Supportmitarbeiter konnte das Modem remote aktualisieren, das WiFi-Passwort ändern und verbundene Geräte einsehen
• Dieses Remote-Management hängt mit dem 2004 eingeführten Protokoll TR-069 zusammen, über das ISPs Geräte im Netzwerk über Port 7547 verwalten
• TR-069 selbst war nicht nach außen exponiert und war bereits in einem DEF-CON-Vortrag behandelt worden; deshalb verlagerte sich das Interesse auf die Support-Tools und internen APIs, die die Mitarbeiter verwenden
• Wenn ein Angreifer ein Modem kompromittieren wollte, so die Annahme, würde er eher die zugrunde liegende Infrastruktur der Support-Tools angreifen, insbesondere APIs, mit denen sich Kundengeräteeinstellungen ändern oder beliebige Befehle ausführen lassen
• Die Untersuchung entwickelte sich daher eher in Richtung der Vertrauensebene zwischen ISP und Kundengeräten als zu einer eindeutigen Bestimmung des tatsächlichen Angriffswegs von 2021

Die API-Struktur des Cox-Business-Portals

• In der Frontend-JavaScript-Datei main.36624ed36fb0ff5b.js des Cox-Business-Portals wurden mehr als 100 API-Aufrufe auf Basis von /api/cbma/ gefunden
• Der Pfad /api/cbma/ verhielt sich anders als andere /api/-Pfade und wirkte wie eine API, die auf ein vom Frontend getrenntes Backend weitergeleitet wurde
  • /api/anything_else/example lieferte eine Redirect-Antwort
  • /api/cbma/example lieferte 500 Internal Server Error
• Registrierungsanfragen enthielten Header wie clientid, Apikey, Cb_session und Authorization; das Antwortverhalten erinnerte an ein Spring-basiertes Backend
• Nach Änderung der HTTP-Methode erschienen Spring-Fehlerantworten, was bestätigte, dass das API-Backend auf Spring basierte
• Ein Actuator-Pfad wurde nicht gefunden, aber ein Swagger-UI-Pfad wurde entdeckt

Umgehung beim Laden der Swagger-Dokumentation und 700 APIs

• Swagger UI lud zwar, doch statische Ressourcen landeten in einer Redirect-Schleife, sodass die Dokumentation leer wirkte
• Anfragen nach statischen Ressourcen wie .js, .css und .png schienen nicht über den API-Proxy, sondern an den Standard-Host geroutet zu werden
• Durch Anhängen eines kodierten /, also %2f, an das URL-Ende ließen sich die statischen JavaScript-Ressourcen über den API-Proxy laden
• Mit Match-and-Replace in Burp, das %2f an statische Ressourcenanfragen anhängte, wurde die Swagger-Dokumentation korrekt angezeigt
• Insgesamt wurden etwa 700 API-Aufrufe identifiziert; für Geräte- und Kontofunktionen waren insbesondere accountequipment, datainternetgateway und account relevant

Authentifizierungsumgehung und Zugriff auf Kundendaten

• Bei wiederholten Anfragen an alle GET-Endpunkte lieferten manche Authentifizierungsfehler, manche 200 OK, und selbst identische Requests wechselten bei Wiederholung ihr Ergebnis
• Der Endpunkt profilesearch lieferte zunächst ein leeres Suchergebnis; später wechselte dieselbe Anfrage zwischen Authentifizierungsfehler und erfolgreicher Antwort
• Bei wiederholten Suchanfragen mit cox wurden Ergebnisse zurückgegeben, die wie Cox-Business-Kundenprofile aussahen, einschließlich profileGuid
• Bei Suchanfragen nach fbi wurden Ergebnisse mit den physischen Adressen mehrerer FBI-Außenstellen zurückgegeben, die Cox-Business-Kunden waren
• Dasselbe Berechtigungsproblem betraf auch andere APIs; durch mehrfaches Wiederholen von Requests war auch ohne Authentifizierung Zugriff auf Administratorfunktionen möglich

Abruf von Geräte-MAC-Adressen und Kontoinformationen

• Nachdem er die MAC-Adresse seines eigenen Modems aus seinem Cox-Konto geholt und in eine API mit dem Parameter macAddress eingesetzt hatte, wurde die IPv4-Adresse des Geräts zurückgegeben
• Damit war bestätigt, dass die API der Cox-Business-Website tatsächlich mit realen Geräten kommunizieren konnte
• Eine Geräte-Listen-API auf Basis der Konto-ID lieferte Informationen über dem Konto zugeordnete Geräte
  • Gerätekategorie
  • Modellname
  • MAC-Adresse
  • Port-Informationen
  • Seriennummer
• Eine Benutzerabfrage per E-Mail lieferte Geschäftskontodaten wie Name, Telefonnummer, Status, Benutzertyp, Inhaber des Profils und alternative E-Mail-Adresse
• Auch ähnliche POST-Anfragen zum Aktualisieren von Konten funktionierten, womit bestätigt war, dass für Business-Konten Lese- und Schreibzugriff möglich war

encryptedValue und Änderungen an Geräteeinstellungen

• Anfragen zum Ändern von Geräteeinstellungen erforderten den Parameter encryptedValue
• Die Funktionen encryptWithSaltandPadding und decryptWithSaltandPadding im JavaScript wurden verwendet, um Werte AES-basiert zu ver- und entschlüsseln
• Auch die bei der Kontoerstellung gesetzte vierstellige PIN wurde mit denselben Funktionen verschlüsselt, sodass sich im Browser-Debugger der Ausführungskontext dieser Funktionen erfassen ließ
• Nachdem er bei einem Bekannten mit Cox Business ein in einer Geräteantwort enthaltenes encryptedValue entschlüsselt hatte, fand er darin folgende Elemente
  • Cox-Kontonummer
  • Gerätename
  • Geräte-ID
  • unbekannter Wert
  • MAC-Adresse
  • Bezeichnung
• Selbst wenn Kontonummer und Geräte-ID beliebig gesetzt und nur die MAC-Adresse gültig gelassen wurden, war eine nach erneuter Verschlüsselung gesendete Anfrage erfolgreich, was zeigte, dass der Server die Konsistenz von MAC-Adresse und Konto nicht prüfte

Möglichkeit zur Änderung beliebiger Modem-Konfigurationen

• Er sendete eine POST-Anfrage, um die WiFi-SSID für die MAC-Adresse seines eigenen Geräts zu ändern
• Die Antwort lautete 200 OK und Success, danach war das Netzwerk kurzzeitig offline
• Etwa 5 Minuten später startete das Netzwerk neu und die SSID war auf Curry geändert
• Dieser PoC zeigte, dass die API zur Aktualisierung der Gerätekonfiguration tatsächlich funktionierte und ein Angreifer Geräteeinstellungen über die API überschreiben konnte
• Diese Berechtigungen entsprachen ungefähr dem Niveau des ISP-Techniksupports und hätten sich auf Millionen von Cox-Geräten mit API-Zugriff auswirken können

Auswirkungsbereich und mögliche Angriffskette

• Die Kombination der Schwachstellen schuf für einen externen Angreifer ohne Vorbedingungen einen Weg zu Änderungen an Millionen Modem-Konfigurationen, Zugriff auf PII von Business-Kunden und Berechtigungen auf dem Niveau eines ISP-Supportteams
• Cox ist der größte private Breitbandanbieter in den USA, der drittgrößte Kabel-TV-Anbieter und der siebtgrößte Telefonanbieter; das Unternehmen hat Millionen Kunden und ist in 10 Bundesstaaten der beliebteste ISP
• Eine mögliche Angriffskette sah wie folgt aus
  • Suche nach Cox-Business-Zielen anhand von Name, Telefonnummer, E-Mail-Adresse und Kontonummer
  • Abruf von Konto-PII, Geräte-MAC-Adressen, E-Mail, Telefonnummer und Adresse über die zurückgegebene UUID
  • Abfrage von WiFi-Passwort und verbundenen Geräten über die Geräte-MAC-Adresse
  • Ausführung beliebiger Befehle, Aktualisierung von Geräteeigenschaften und Übernahme des Opferkontos
• Es waren mehr als 700 APIs exponiert, viele davon mit Administratorfunktionen wie dem Einsehen von am Modem verbundenen Geräten
• Jede dieser APIs litt unter demselben Berechtigungsproblem, durch das sich mit wiederholten Requests nicht autorisierte Befehle ausführen ließen

Meldung, Patch und offene Fragen

• Die Schwachstellen wurden über das Responsible-Disclosure-Programm von Cox gemeldet
• Cox nahm die exponierten API-Aufrufe innerhalb von 6 Stunden vom Netz, und am nächsten Tag ließ sich die Schwachstelle nicht mehr reproduzieren
• Laut Untersuchung von Cox gab es keine Hinweise auf frühere Ausnutzung dieses Vektors, und der verwundbare Dienst war erst 2023 gestartet, sodass er nicht für die Modem-Kompromittierung von 2021 verwendet worden sein konnte
• Cox teilte mit, dass keine Verbindung zur DigitalOcean-IP bestehe; damit bleibt offen, dass das ursprüngliche Modem auf einem anderen Weg kompromittiert wurde als dem in diesem Beitrag offengelegten
• Da das ursprüngliche Modem bereits zurückgegeben worden war, konnten weder Firmware-Dump noch forensische Analyse durchgeführt werden, und auch der Grund für das absichtliche Replay des Traffics blieb ungeklärt

Timeline der Veröffentlichung

• 2024-03-04: Meldung der Schwachstelle an das Responsible-Disclosure-Programm von Cox
• 2024-03-05: Hotpatch eingespielt, nicht essenzielle Business-Endpunkte lieferten 403 und funktionierten nicht mehr
• 2024-03-06: E-Mail an Cox, dass sich die Schwachstelle nicht mehr reproduzieren lässt
• 2024-03-07: Antwort von Cox, dass eine umfassende Sicherheitsprüfung eingeleitet werde
• 2024-04-10: Cox mitgeteilt, dass eine Veröffentlichung 90 Tage nach Meldung beabsichtigt ist
• 2024-04-29: Link zum Blog-Entwurf mit Cox geteilt

[GN⁺]

Kommentare auf Hacker News

• albinowax_ hatte das zuerst eingereicht, und es hat mich gestört, dass er dafür kein Karma bekommt, deshalb habe ich die Kommentare nach https://news.ycombinator.com/item?id=40560010 verschoben.
  Ich hoffe, xrayarx nimmt das gelassen. Wir planen, für solche Fälle eine echte Karma-Teilung zu implementieren, aber bis dahin greifen wir gelegentlich auf solche etwas unbeholfenen manuellen Methoden zurück.
  • Laut System habe ich es vor 13 Stunden eingereicht, er vor 10 Stunden. Daher verstehe ich nicht ganz, wie er es zuerst eingereicht haben soll.