Hacking von Millionen Modems und Untersuchung der Kompromittierung meines Modems

 (samcurry.net)
2 Punkte von GN⁺ 2024-06-05 | 1 Kommentare | Auf WhatsApp teilen
  • HTTP-Anfragen aus dem Heimnetz wurden rund 10 Sekunden später von einer DigitalOcean-IP unverändert erneut abgespielt, was darauf hindeutete, dass Traffic mehrerer Geräte hinter einem Cox Panoramic Wifi Gateway nach außen offengelegt wurde
  • Nachverfolgung mit VirusTotal und URLscan ergab, dass die IP in der Vergangenheit mit Phishing-Domains und massenhaft Domains im Format Wort+6 Ziffern+TLD verknüpft war, was den Verdacht auf einen Domain-Generation-Algorithmus für C&C weckte
  • Bei der Analyse des Cox-Business-Portals im Jahr 2024 wurden eine Spring-basierte API und Swagger-Dokumentation hinter /api/cbma/ offengelegt, und schon durch wiederholte Anfragen ließ sich die Autorisierungsprüfung umgehen
  • Die offengelegte API erlaubte Kundensuche, Einsicht in Konto-PII, Abfrage von Geräte-MAC-Adressen bis hin zu Änderungen der WiFi-Konfiguration; auch die Logik zur Erzeugung von encryptedValue ließ sich aus dem Frontend-JavaScript aufrufen
  • Cox nahm die offengelegte API innerhalb von 6 Stunden nach der Meldung vom Netz, aber der Dienst war erst 2023 gestartet, sodass die Ursache der ersten Modem-Kompromittierung von 2021 weiterhin getrennt davon bleibt

Wiederholung von HTTP-Anfragen im Heimnetz entdeckt

  • Um eine blind-XXE-Schwachstelle zu testen, wurde auf einer AWS-Instanz ein Python-HTTP-Server gestartet und vom Heimcomputer eine Anfrage an /test123 gesendet
    • Die ursprüngliche Anfrage traf von der Heim-IP 98.161.24.100 ein
    • Etwa 10 Sekunden später sendete die unbekannte IP 159.65.76.209 dieselbe Pfad-Anfrage erneut
  • Als dieselbe URL auch in iPhone Safari aufgerufen wurde, spielte dieselbe IP die Anfrage erneut ab
    • Das gleiche Verhalten wiederholte sich nicht nur auf dem Heimcomputer, sondern auch auf anderen Geräten im Heimnetz
  • Auch auf einer neuen AWS-Instanz mit Nginx und auf einer GCP-Instanz spielte dieselbe IP die Anfragen erneut ab, wodurch ein AWS-spezifisches Problem unwahrscheinlich wurde
    • Übrig blieben als Möglichkeiten der ISP, das Modem oder eine Kompromittierung des Netzwerkpfads
  • Die Abfrage des IP-Eigentümers ergab, dass 159.65.76.209 eine Adresse von DigitalOcean und keine ISP-Adresse war

Frühere bösartige Infrastruktur an die DigitalOcean-IP gebunden

  • Eine VirusTotal-Abfrage zeigte Domains, die in der Vergangenheit auf diese IP aufgelöst hatten
    • 3 der letzten 5 Domains waren Phishing-Seiten, 2 sahen wie Mailserver aus
    • Beispiel-Domains:
      • regional.adidas.com.py
      • isglatam.online
      • isglatam.tk
      • mx12.limit742921.tokyo
      • mx12.jingoism44769.xyz
  • isglatam.online und isglatam.tk waren Phishing-Seiten gegen das südamerikanische Cybersecurity-Unternehmen isglatam.com
    • Auf der echten ISG-Latam-Website wurde bestätigt, dass es sich um ein in Paraguay ansässiges Unternehmen handelt, das Partnerschaften mit Crowdstrike, AppGate, Acunetix, DarkTrace und ForcePoint angibt
  • URLscan enthielt Spuren dafür, dass beide Domains typische BeEF-Phishing-Seiten hosteten
  • Dieselbe IP war sowohl mit einer Adidas-bezogenen Domain, dem ISG-Latam-Phishing als auch mit Aktivitäten verbunden, die wie das Replay von Modem-Traffic aussahen
    • Zwar hätte die IP zwischen mehreren Besitzern rotieren können, aber wegen der langen Abstände zwischen den Aktivitäten wirkte eine unmittelbare Neuvergabe an einen anderen bösartigen Nutzer eher unwahrscheinlich

Modemtausch und erneute Untersuchung drei Jahre später

  • Das eingesetzte Gerät war ein Cox Panoramic Wifi Gateway, das in einem Cox-Shop gegen ein neues Modem ausgetauscht wurde
    • Das alte Gerät war vom ISP gemietet und musste zurückgegeben werden
    • Ein Firmware-Dump oder Reverse Engineering war daher nicht möglich
  • Nach der Installation des neuen Modems hörte das Replay der HTTP-Anfragen vollständig auf
    • In den Logs tauchte keine weitere fremde IP mehr auf
    • Damals ließ sich außer der Schlussfolgerung, dass das alte Modem kompromittiert war, kaum weiter ermitteln
  • Anfang 2024, rund 3 Jahre später, wurde die Untersuchung mit Bekannten aus der Sicherheitsbranche wieder aufgenommen, wobei das Domainformat wie limit742921.tokyo und jingoism44769.xyz auffiel
    • Eine Reverse-IP-Suche für die betreffende IP zeigte mehr als 1.000 Domains mit demselben Muster
  • Das Domainformat bestand durchgehend aus Wort + 6 Zahlen + TLD
    • Wegen der Massenregistrierung und der algorithmischen Struktur wirkte dies wie ein Domain-Generation-Algorithmus, mit dem ein bösartiger Betreiber C&C-Server-Adressen verbergen wollte
    • Die zuletzt beobachtete Domain wurde am 17. März 2023 registriert; danach wurden keine weiteren Hosts mehr auf diese IP aufgelöst
  • Das ausgetauschte neue Modem war zwar dasselbe Modell, doch über Google ließ sich keine öffentlich bekannte Schwachstelle für dieses Modell finden

Hypothese ausgehend von ISP-Support-Tools und TR-069

  • Beim Umzug eines Cox-Modems an einen neuen Standort wurde bestätigt, dass ein ISP-Supportmitarbeiter die Geräteeinstellungen aus der Ferne ändern kann
    • Der Supportmitarbeiter konnte Geräteeinstellungen aktualisieren, das WiFi-Passwort ändern und verbundene Geräte einsehen
  • Diese Fernverwaltung erfolgt über das TR-069-Protokoll, das 2004 eingeführt wurde
    • Dabei verwaltet der ISP Geräte im eigenen Netzwerk über Port 7547
    • Das Protokoll wurde zwar auch in einem DEF-CON-Vortrag behandelt, war aber keine von außen exponierte Angriffsfläche
  • Der Fokus der Untersuchung verlagerte sich daher vom Protokoll selbst auf das interne Webportal zur Geräteverwaltung der Supportmitarbeiter und die dahinterliegende API
    • Wenn eine solche API Geräteeinstellungen von Kunden lesen und ändern oder Befehle ausführen kann, könnte sie ein Pfad zur Modem-Kompromittierung sein

API-Struktur des Cox-Business-Portals

  • Das Cox-Business-Portal bietet Fernverwaltung von Geräten, Konfiguration von Firewall-Regeln und Überwachung des Netzwerk-Traffics
  • Aus der Frontend-JavaScript-Datei main.36624ed36fb0ff5b.js der Login-Seite wurden Routen extrahiert
    • Es wurden mehr als 100 API-Aufrufe auf Basis von /api/cbma/ gefunden
    • Beispiele:
      • /api/cbma/voicemail/services/voicemail/inbox/transcribeMessage/
      • /api/cbma/profile/services/profile/userroles/
      • /api/cbma/accountequipment/services/accountequipment/equipments/eligibleRebootDevice
  • /api/cbma/ lieferte andere Antworten als das normale Frontend und wirkte daher wie ein Reverse Proxy zu einem separaten Backend
    • Eine Anfrage an /api/anything_else/example gab einen 301-Redirect zurück
    • Eine Anfrage an /api/cbma/example gab 500 Internal Server Error zurück
  • Registrierungsanfragen enthielten mehrere Authentifizierungs-Header
    • Clientid: cbmauser
    • Apikey: 5d228662-aaa1-4a18-be1c-fb84db78cf13
    • Cb_session: unauthenticateduser
    • Authorization: Bearer undefined
  • Nach Änderung der HTTP-Methode wurde eine Spring-typische Fehlermeldung zurückgegeben, was bestätigte, dass das Backend auf Spring basiert

Swagger-Dokumentation und Umgehung statischer Ressourcen

  • Ein Spring-Actuator-Pfad konnte nicht gefunden werden, aber Teile eines Swagger-UI-Pfads waren erreichbar
    • Der Pfad /api/cbma/userauthorization/swagger-ui/index.html antwortete
  • Die anfangs geladene Swagger-Seite war leer
    • Statische Ressourcen wie .png, .js und .css wurden nicht über den API-Proxy, sondern über den ursprünglichen Host-Pfad geroutet, was zu Endlosschleifen bei Redirects führte
  • Tests mit Burp Intruder, bei denen an das URL-Ende %00 bis %FF angehängt wurden, zeigten, dass ein URL-kodiertes /, also %2f, hinter .js zu 200 OK führte
    • Beispiel: /swagger-initializer.js%2f
  • Mit Burp Match-and-Replace, das an alle statischen Ressourcen %2f anhängte, ließ sich die Swagger-Dokumentation vollständig laden
  • Insgesamt wurden etwa 700 API-Aufrufe identifiziert
    • account: 115
    • voiceutilities: 73
    • user: 70
    • datainternetgateway: 57
    • accountequipment: 55
    • billing: 53
    • ticket: 52
    • außerdem profile, voicecallmanagement, voicemail, userauthorization, csr usw.
  • Für Geräte und Kundenkonten unmittelbar relevante APIs schienen vor allem accountequipment, datainternetgateway und account zu sein

Umgehung der Autorisierungsprüfung durch Wiederholen von Anfragen

  • Bei der Prüfung aller GET-Endpunkte auf unauthentifizierten Zugriff lieferten manche Authentifizierungsfehler, andere 200 OK
  • Der Endpunkt profilesearch gab zunächst eine erfolgreiche Antwort mit leerem Suchergebnis zurück
    • Dieselbe Anfrage lieferte manchmal Authorization Error-Invalid User Token und nach erneutem Senden wieder Erfolg
  • Wurde dieselbe Anfrage mehrfach erneut gesendet, verschwand der Autorisierungsfehler und es wurden Kundensuchergebnisse zurückgegeben
    • Für die Suche nach cox wurden 10000+ hits zurückgegeben
    • Für die Suche nach fbi enthielt das Ergebnis physische Adressen von FBI-Außenstellen, die Cox-Business-Kunden waren
  • Schon das bloße Wiederholen von API-Anfragen ermöglichte eine Autorisierungsumgehung, und dasselbe Problem schien sich über mehr als 700 APIs hinweg auszuwirken

Zugriff auf Kundengeräte und Kontoeinsicht

  • Um zu prüfen, ob die Cox-Business-API auch auf Geräte in Privatkundennetzen zugreifen konnte, wurde eine einfache API getestet, die eine MAC-Adresse entgegennimmt
    • Endpunkt: /api/cbma/accountequipment/services/accountequipment/ipAddress?macAddress=:mac
  • Nachdem die MAC-Adresse im eigenen Cox-Konto eingesehen und die Anfrage wiederholt worden war, wurde die IPv4-Adresse des eigenen Modems zurückgegeben
    • Das bestätigte, dass diese API tatsächlich mit realen Cox-Geräten kommunizieren konnte
  • Auch eine Geräteauflistungs-API mit Konto-ID funktionierte
    • Endpunkt: /api/cbma/accountequipment/services/accountequipment/v1/equipments/{accountId}
    • Die Antwort enthielt Informationen zu Internet-, Sprach- und TV-Geräten
    • Zurückgegeben wurden Gerätemodell, Gerätetyp, MAC-Adresse, Portliste und Seriennummer
  • Auch eine API zur nutzerbasierten Suche per E-Mail lieferte Geschäftskontoinformationen zurück
    • Beispielanfrage: /api/cbma/user/services/user/admin@cox.net
    • Enthalten waren E-Mail-Adresse, Name, Telefonnummer, Status, Berechtigungen, ob der Nutzer Profilinhaber ist, und alternative E-Mail-Adressen
  • Eine ähnliche POST-Anfrage zur Kontoaktualisierung funktionierte ebenfalls und bestätigte Lese- und Schreibzugriff auf Geschäftskonten

encryptedValue und Änderung von Geräteeinstellungen

  • Anfragen zum Ändern von Hardware-Einstellungen erforderten einen Parameter namens encryptedValue
    • Zum Beispiel zum Ändern des Gerätepassworts oder der WiFi-Einstellungen
  • Im Frontend-JavaScript wurde die Logik zur Erzeugung und Entschlüsselung von encryptedValue nachverfolgt
    • encryptWithSaltandPadding
    • decryptWithSaltandPadding
  • Da auch die bei der Kontoregistrierung gesetzte vierstellige PIN mit derselben Funktion verschlüsselt wurde, konnte im Browser-Debugger ein Breakpoint an die entsprechende Aufrufstelle gesetzt und die Funktion direkt über die Konsole aufgerufen werden
  • Wurde ein aus einer echten Kontoantwort stammendes encryptedValue entschlüsselt, zeigte sich ein Wert im folgenden Format
    • Cox-Kontonummer
    • Gerätename
    • Geräte-ID
    • unbekannter Wert
    • MAC-Adresse
    • Label
  • Selbst wenn bis auf die gültige MAC-Adresse fast alle Felder wie die Kontonummer mit beliebigen Werten gefüllt und daraus ein neues encryptedValue erzeugt wurde, war die Anfrage erfolgreich
    • Der Server prüfte nicht, ob Konto-ID und MAC-Adresse zusammenpassen

Möglichkeit, beliebige Modemeinstellungen zu ändern

  • Für das eigene Gerät wurde eine POST-Anfrage gesendet, um die WiFi-SSID auf Curry zu ändern
    • Endpunkt: /api/cbma/accountequipment/services/accountequipment/gatewaydevice/wifisettings
    • Der Request-Body enthielt wifiSettings, additionalProperties und encryptedValue
  • Die Antwort war {"message": "Success"}; danach fiel das Netzwerk kurz aus und startete etwa 5 Minuten später neu
    • Die SSID wurde tatsächlich in Curry geändert
  • Dieses Verhalten zeigte, dass Konfigurationsänderungen über die API tatsächlich auf reale Geräte angewendet wurden
    • Ein Angreifer konnte per Kundensuche die Konto-UUID erhalten
    • die MAC-Adresse verbundener Geräte abfragen
    • und auf Basis der MAC-Adresse Geräteeinstellungen lesen oder ändern
  • Diese Berechtigungen entsprachen in etwa dem Zugriffsniveau des ISP-Supports und stellten einen möglichen Pfad dar, der sich auf Millionen von Cox-Geräten auswirken konnte

Auswirkungen und Angriffsszenario

  • Die Kombination der Schwachstellen zeigte, dass ein externer Angreifer ohne Vorbedingungen Folgendes hätte tun können
    • Befehle auf Millionen Modems ausführen und deren Konfiguration ändern
    • auf PII von Cox-Business-Kunden zugreifen
    • Berechtigungen auf dem Niveau des ISP-Supports erlangen
  • Cox ist in den USA der größte private Breitbandanbieter, der drittgrößte Kabel-TV-Anbieter, der siebtgrößte Telefonanbieter und in 10 Bundesstaaten der beliebteste ISP
  • Beispielhafter Angriffsablauf:
    • Suche nach Cox-Business-Zielen anhand von Name, Telefonnummer, E-Mail und Kontonummer
    • Abruf vollständiger Konto-PII sowie von Geräte-MAC-Adressen, E-Mails, Telefonnummern und Adressen über die zurückgegebene UUID
    • Abfrage des WiFi-Passworts und verbundener Geräte über die Hardware-MAC-Adresse
    • Ausführung beliebiger Befehle, Änderung von Geräteeigenschaften und Übernahme von Opferkonten
  • Unter den mehr als 700 offengelegten APIs boten viele Administratorfunktionen, und bei wiederholten Anfragen trat dasselbe Autorisierungsproblem auf

Meldung an Cox und Behebung

  • Die Schwachstelle wurde über das Responsible-Disclosure-Programm von Cox gemeldet
  • Cox nahm die offengelegten API-Aufrufe innerhalb von 6 Stunden nach der Meldung vom Netz und begann mit der Behebung der Autorisierungsschwachstelle
    • Am nächsten Tag ließ sich die Schwachstelle nicht mehr reproduzieren
  • Zeitachse der Veröffentlichung:
    • 2024-03-04: Schwachstelle an Cox gemeldet
    • 2024-03-05: Hotpatch eingespielt, nicht essenzielle Business-Endpunkte lieferten 403 und funktionierten nicht mehr
    • 2024-03-06: Cox per E-Mail informiert, dass sich die Schwachstelle nicht mehr reproduzieren lässt
    • 2024-03-07: Cox antwortet, dass eine umfassende Sicherheitsprüfung gestartet wird
    • 2024-04-10: Cox über die Absicht informiert, 90 Tage nach Meldung zu veröffentlichen
    • 2024-04-29: Link zum Blog-Entwurf mit Cox geteilt

Offene Fragen

  • Cox untersuchte, ob der konkrete Schwachstellenpfad in der Vergangenheit ausgenutzt worden war, und bestätigte, dass es keine Ausnutzung gegeben habe
    • Der betreffende Dienst war erst 2023 in Betrieb gegangen
    • Da die erste Modem-Kompromittierung bereits 2021 stattfand, war die offengelegte Schwachstelle in der Cox-Business-API damals nicht die Ursache
  • Cox teilte mit, dass es keinerlei Verbindung zu der DigitalOcean-IP gebe
    • Das Gerät war tatsächlich gehackt worden, aber auf einem anderen Weg als über die offengelegte API-Schwachstelle
  • Das Modem war nicht für externen Zugriff konfiguriert, und im Heimnetz wurde sich nie direkt am Gerät angemeldet
    • Als anderer möglicher Pfad wurde etwa ein lokales CSRF, das zu RCE führt, über eine 0day-Schwachstelle diskutiert
  • Die größte offene Frage bleibt, warum der Angreifer überhaupt HTTP-Anfragen wiederholt abgespielt hat
    • Wenn er bereits im Netzwerk war, hätte er unbemerkt zugreifen können; warum dennoch alle HTTP-Anfragen repliziert wurden, bleibt ungeklärt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-06-05
Hacker-News-Kommentare

  • Guter Artikel und leicht nachzuvollziehen. Besonders positiv fand ich, dass Cox den Hinweisgeber nicht angegriffen oder das Problem abgestritten hat, sondern sich wie ein Musterbeispiel für eine verantwortungsvolle Sicherheitsreaktion in so einer Situation verhalten hat
    Ich würde gern in einem Folgeartikel lesen, welcher Bug den nicht autorisierten API-Zugriff zeitweise erlaubt hat. Solche Fehler werden bei oberflächlichen Tests leicht übersehen oder lassen sich je nach Ursache in der Testumgebung womöglich gar nicht reproduzieren

    • Cox hat zwar verantwortungsvoll reagiert, aber als man anfangs mit dem kompromittierten Gerät vorbeikam, hätte man diese Gelegenheit besser nutzen können
      Ich habe früher einmal zufällig eine schwerwiegende Schwachstelle bei einem traditionellen Telekommunikationsanbieter entdeckt, und allein über den normalen Kundensupport hat es fast eine Woche gedauert, bis ich die zuständige Person erreicht habe; die Support-Organisation konnte überhaupt nicht eskalieren. Bei Cox brachte ein Informationssicherheitsexperte ebenfalls direkt ein kompromittiertes Gerät vorbei, und auch dort konnte die Support-Organisation das nicht richtig behandeln
    • Der Artikel war gut lesbar und auch die Reaktion von Cox war gut. Mir gefällt außerdem, dass weder der Entdeckungsprozess noch der Bug selbst negativ oder herablassend dargestellt wurden
    • Unternehmen sollten Leute, die so etwas finden, nicht verklagen, weil sie „gehackt“ hätten, sondern sie belohnen
    • Ich frage mich auch, welcher Bug den nicht autorisierten API-Zugriff zeitweise erlaubt hat. Vielleicht werden wir es am Ende nie erfahren, aber möglicherweise war es ein Test-Backend, das keine Autorisierungsprüfung durchführt und versehentlich in die Load-Balancer-Konfiguration aufgenommen wurde
    • Der Artikel war gut, aber dass ständig super verwendet wurde, etwa in „super curious“, „super interesting“ und „super interested“, fand ich etwas störend

  • Nervig an solchen Situationen ist, wenn der ISP einen dazu zwingt, seinen Modem- oder Router zu verwenden. AT&T Fiber nutzt zum Beispiel zertifikatsbasierte 802.1X-Authentifizierung für den Netzzugang; ohne das hätte man vermutlich einfach beliebige Geräte an das ONT anschließen können
    Es gab oder gibt Umgehungsmöglichkeiten, aber ich wollte für den Internetzugang keine solchen Prozeduren durchlaufen, also habe ich alle Funktionen des AT&T-Routers deaktiviert und dahinter meinen eigenen Router betrieben, den ich aktuell halte. Selbst wenn der AT&T-Router kompromittiert würde, würde ich das möglicherweise nicht bemerken, solange sich der Dienst nicht spürbar verschlechtert. Zum Glück ist heute das meiste HTTPS

    • Wenn es sich um AT&T Fiber mit getrenntem ONT und Modem handelt, ist die Umgehung von 802.1X ziemlich einfach. Man steckt einfach einen unmanaged Switch zwischen Modem und ONT, lässt das Modem die Authentifizierung durchführen und zieht es dann wieder ab
      Wenn das ONT neu startet, muss man das wahrscheinlich erneut tun, aber in meinem Fall hat AT&T mir eine USV für das ONT gegeben, daher sollte es selten neu starten. Ich persönlich habe eine komplexe Konfiguration auf Basis einer Bypass-NIC gebaut, bei der der Traffic durch das AT&T-Modem läuft, wenn meine Firewall aus oder gerade am Neustarten ist, und bei eingeschalteter Firewall nimmt meine Firewall den Traffic an und leitet ihn selektiv über das Modem weiter, aber ein unmanaged Switch reicht eigentlich völlig aus
    • Die Wahrscheinlichkeit, dass ein AT&T-CPE-Router kompromittiert wird, macht keinen großen Unterschied, solange sich zwischen meinem Netzwerk und dem AT&T-Netzwerk mein eigener Router befindet. Selbst wenn man den AT&T-CPE-Router entfernt, hängt man am Ende immer noch an einer Blackbox, die man nicht kontrolliert, und dieses Gerät könnte ebenfalls kompromittiert sein oder den Traffic auf verschiedene Weise inspizieren
    • Zum Glück ist Cox kein solcher ISP. Sie akzeptieren jedes hinreichend moderne DOCSIS-Modem, das zur gebuchten Geschwindigkeit passt
      Mehr Lob für Cox gibt es von mir aber nicht. Ich habe seit zwei Jahren intermittierenden Paketverlust, und obwohl ich Daten gesammelt habe, die nahelegen, dass ein bestimmter Node wahrscheinlich überbucht ist, scheint es keinen Eskalationsweg im Support zu geben, der mich zu jemandem bringt, der das verstehen würde
    • Nur als Hinweis: Bei xgspon ist die Umgehungsprozedur inzwischen automatisiert. Im Grunde heißt es nur noch: „SFP+ einstecken, Firmware über die Weboberfläche hochladen, Seriennummer des Geräts eingeben“, und je nach verwendetem SFP-Modul kann Schritt 2 sogar entfallen
      Tatsächlich wird der 802.1X-Status serverseitig nicht geprüft. Der Standard verlangt zwar, dass ein Modem keinen Traffic weiterleiten darf, wenn 802.1X erforderlich ist und nicht durchgeführt wurde, aber die meisten leiten ihn einfach weiter oder lassen sich entsprechend umstellen. Auf der AT&T-Seite wird das nicht validiert; dort wird Traffic immer durchgelassen, und intern passiert genau das
    • Es gibt verschiedene Möglichkeiten, sich ohne AT&T-Gateway zu verbinden, und mehrere davon sind unter https://pon.wiki/ zusammengefasst

  • Gut lesbarer Artikel und ausgezeichnete Untersuchung. Es ist auch schön zu sehen, wenn ein Großunternehmen keine Atombombe auf Sicherheitsforscher wirft
    Ich bin nicht sicher, aber ich bezweifle, dass Anfragen an die lokale Administratoroberfläche dieses Nokia-Routers korrekt authentifiziert werden. Ich habe vor Kurzem dasselbe Gerät bekommen, und es gab Einstellungen, die sich mit normalen Administratorrechten nicht ändern ließen, während der ISP kein Superadmin-Konto herausgab. Wenn ich jedoch mit dem Seiteninspektor deaktivierte Felder wieder aktiviert und die Werte geändert habe, hat die API das einfach akzeptiert. Wenn unter solchen Bedingungen eine Anwendung im internen Netzwerk ausgeführt werden kann, wäre es wohl nicht schwer, den Router auf diese Weise zu übernehmen, allerdings wirkt das wie ein ziemlich spezieller Fall

    • Die Tatsache, dass Cox der größte private Breitbandanbieter der USA, der drittgrößte Kabel-TV-Anbieter, der siebtgrößte Telefonanbieter und in zehn Bundesstaaten der beliebteste ISP ist, lässt mich denken, dass ISPs gar nicht so groß sein sollten
      Cox ist offensichtlich ein attraktives Angriffsziel, und wie das Beispiel im Artikel zeigt, kann durch eine einzelne Schwachstelle sogar ein FBI-Außenbüro gefährdet werden. Statt „Cox untersuchte frühere Ausnutzung und fand keine Aufzeichnungen“ wäre es wohl treffender gewesen zu schreiben, dass Cox „behauptete, untersucht zu haben“

  • Kann man der Aussage glauben, es habe „keine frühere Ausnutzung“ gegeben? Das ganze Netzwerk sieht aus wie Schweizer Käse

    • Deshalb schickt man alle Logs in einen S3-Bucket eines AWS-Kontos, das nur Schreibrechte hat, und sorgt dafür, dass man für den Zugriff auf ein Konto, das mit diesem Bucket noch etwas anderes tun kann, drei Personen braucht. Ich weiß nicht, ob Cox das so gemacht hat, aber wenn man so entwerfen wollte, dass man sagen kann „es gab keine Ausnutzung“, dann wäre das eine passende Struktur
    • Wenn man die Unterhaltung angefangen hat, kann man sich nicht bis zum Ende heraushalten. Irgendwann muss man sagen: „Das sind die Informationen, die wir haben, und das ist besser als vorher“
    • Wenn sie sagen „gab es nicht“, könnte das auch bedeuten, dass es andere Angriffsvektoren gibt, die Cox kennt oder nicht kennt, während bereits ein kompromittiertes Gerät gefunden wurde

  • Viele Router müssen manuell per Firmware-Update aktualisiert werden. Bei GL.iNet-Routern gab es in den letzten sechs Monaten mehrere Remote-Code-Execution-Schwachstellen, daher sollte man schnell prüfen, ob der eigene Router kompromittiert wurde, und wenn möglich die Firmware aktualisieren.
    Für normale Nutzer zeigten sich die Symptome als geringere Internetgeschwindigkeit, Aussetzer beim Wi‑Fi-Signal und fehlgeschlagene Geräteverbindungen; außerdem war der Router selbst zwar mit dem Internet verbunden, aber die interne Admin-Seite (192.168.8.1) reagierte nicht. In meinem Fall installierte der Angreifer die Pawns-App von IPRoyal, machte den Router zu einem Proxy-Server und verdiente damit Geld; außerdem wurden Systemprotokolle gestohlen, die Nutzungsdauer und den NAS-Verbindungsstatus enthielten, und es gab auch eine Reverse Shell. Zur Behebung ist die Reihenfolge Firmware-Update, Router-Reset zum Entfernen der Malware, Deaktivieren von SSH und Abschalten von Fernzugriff wie Dynamic DNS sinnvoll. Wenn Fernzugriff nötig ist, könnte man Dinge wie Cloudflare Tunnel, Zero Trust, GoodCloud, ZeroTier oder Tailscale prüfen, aber was davon geeignet ist, weiß ich nicht genau. GL.iNet scheint das Prinzip der geringsten Rechte nicht zu befolgen, da Prozesse standardmäßig als root laufen und SSH mit root-Zugang ebenfalls standardmäßig aktiviert ist, daher wirkt es besser, die Marke zu meiden

  • „Es gab keine bekannte Ausnutzung in der Vergangenheit“ kann auch bedeuten, dass von Anfang an nicht genug Logs oder Audit-Material vorhanden waren oder dass nach dem Hack keine Logs mehr übrig waren

    • Soweit ich den Artikel verstanden habe, wäre ein bestimmter Angriffsweg mit „nicht autorisierte Anfragen wiederholen, bis es klappt“ in den Logs sehr leicht zu erkennen. Schon eine grundlegende Logging-Policy, die nur Pfad, IP und Statuscode festhält, wäre ausreichend und liegt nahe an den Standardeinstellungen der meisten Webserver und Frameworks
    • „Fehlende Beweise sind kein Beweis für Abwesenheit“ passt hier genau
    • Oder sie haben gelogen. Wenn man aus Sicht von Cox denkt: Warum sollte das Unternehmen Leuten außerhalb der Firma offenlegen, dass es in der Vergangenheit bereits Ausnutzungen gab? Eigentlich gibt es keinen Grund, irgendetwas offenzulegen

  • Was für ein Authentifizierungssystem lässt Aufrufe gelegentlich zufällig durch? Das wirkt wirklich inkompetent

    • Ich habe so etwas schon einmal in einer Vendor-API gefunden. Der aktuelle User-Provider war nicht pro Request, sondern als Singleton registriert, sodass man gelegentlich im Windschatten eines authentifizierten Nutzers mitlaufen konnte
    • Ich habe einen ähnlich großen Bug gesehen. Eine API lehnte unauthentifizierte Requests genau 10 Minuten lang ab, erlaubte sie dann genau 1 Minute lang und wiederholte diesen Zyklus endlos. Ich würde wirklich gern wissen, was da im Backend passiert ist
    • Meiner Erfahrung nach kann so etwas durch einen Load Balancer entstehen. Zum Beispiel, wenn nicht korrekt auf die Server im Pool geroutet wird oder wenn sich Konfiguration oder Patchstand zwischen den Servern unterscheiden
    • Es könnte auch sein, dass einige der Origin-Server, auf die Requests geroutet wurden, falsch konfiguriert waren
    • Wenn die API hinter einem Reverse Proxy stand, könnte es auch ein Cache-Problem gewesen sein

  • Haben sie ihn bezahlt? Diese Person hat Cox im Grunde gerettet und auf eine schwer zu entdeckende vollständige Übernahme der Sicherheitsinfrastruktur hingewiesen
    Es wirkt ziemlich beleidigend, dass er für das „Richtige“ offenbar nichts bekommen hat. Wie die Firma jemanden gesehen haben dürfte, der mit kritischen Informationen bis ins Büro kommt, und wie er sich selbst gesehen hat, waren vermutlich sehr unterschiedliche Dinge. Solche Fälle zeigen gut, warum man einen 0day niemals melden sollte

    • Bei Cox kann man sich vermutlich schon glücklich schätzen, wenn sie nicht auch noch die Person verklagen, die ihren Fehler behoben hat
    • Sam ist ein sehr bekannter Sicherheitsforscher; es würde nicht überraschen, wenn er mehr als 350.000 Dollar im Jahr verdient. Solche Artikel bringen über Reputationsgewinn eine Menge Geld
    • Cox zahlt keine Bug Bounties

  • Die noch offene Frage ist, wie die Angreifer seinen HTTP-Traffic abgefangen haben
    Manche CPEs haben eine cloudartige Wireshark-Funktion für Debugging. Ich weiß nicht, ob so etwas im operativen Firmware-Image von Cox enthalten ist. Häufig gibt es getrennte Firmware für Produktion und Tests, was das Testen von Problemen in der Produktionsumgebung erschwert. Cox dürfte prüfen können, welche Firmware-Versionen draußen im Einsatz sind, und ein ISP kann Firmware, die nicht zu einer bestimmten Version passt, automatisch aktualisieren; da es sich um ein Cox-Modem handelt, haben sie die Firmware wahrscheinlich ebenfalls. Falls es eine Debug-Firmware war, wäre interessant, wie sie aufgespielt wurde und wie sie dort bleiben konnte

    • Unter Linux kann man mit PF_PACKET einen Socket erstellen und den Traffic aller Interfaces abgreifen. Das ist im Grunde wie ein tcpdump auf niedriger Ebene
      Alle Daten auf Port 80 abzufangen, die HTTP-Header zu parsen und dann das Nötige zu tun, ist einfach. Ich weiß nur nicht, warum jemand die Requests hätte replayen sollen
    • Wenn es HTTP und nicht HTTPS war, dann kann jede Person oder jedes Gerät auf dem Leitungsweg die Requests sehen
    • Noch ein Grund, vom ISP bereitgestellte Hardware nicht zu vertrauen und nicht zu verwenden. Remote-Management durch den ISP? Nein danke

  • Das ist einer der Gründe, warum man vom ISP bereitgestellte Kabelmodems mit Wi‑Fi-Funktion nicht begrüßen sollte und warum Endpunkte und Dienste im LAN gut abgesichert sein müssen. Mindestens im Abschnitt Modem/ISP braucht man TLS und DNS over TLS
    Ich lasse das Ganze einfach im Bridge-Modus, schalte Wi‑Fi aus und überlasse alle Netzwerkfunktionen meiner eigenen Hardware. Das letzte vom ISP gemietete Modem bekam vom ISP fast zehn Jahre lang keine Firmware-Updates, war dafür aber sehr stabil

    • Es gibt auch ein Gegenargument. Ein ISP mit mehr als einer Million Kunden hat einen Anreiz, Home Gateways „für immer“ aufzurüsten, um Investitionskosten zu senken
      Ich arbeite bei Free, einem französischen ISP, der über Iliad auch in Italien Home Gateways bereitstellt; sogar Geräte von 2011 werden noch aktualisiert. Darauf läuft aktuelles Linux 6.4, dazu moderne Funktionen wie airtime QoS, Updates über die Mobile App und diverse Software-Features
    • Router sind die am häufigsten ausgenutzten IoT-Geräte überhaupt, und Firmware-Schwachstellen bleiben oft jahrelang bestehen, weil Endnutzer keine Patches einspielen. Wenn ein ISP Patches auf Router pushen und nicht patchbare Geräte zurückholen kann, ist das unter dem Strich ein Gewinn für die Cybersicherheit, selbst wenn die Hardware dem ISP gehört
    • Ich nutze auch den Bridge-Modus und habe Wi‑Fi deaktiviert. Irgendwie habe ich es geschafft, ein simples Modem ohne Router- und Access-Point-Funktion installieren zu lassen; ich wusste gar nicht, dass es solche Einzweckgeräte noch gibt
      Ich habe einen halbwegs ordentlichen Router gekauft, OpenWrt installiert und ihn über die ISP-Hardware als Bridge ans Netzwerk gehängt; das funktioniert gut. Inzwischen verwende ich sogar innerhalb des LAN HTTPS
    • Ich habe dem ISP gesagt, dass ich zu einem anderen Anbieter wechsle, wenn ich meinen eigenen Router nicht verwenden darf