Millionen von Modems hacken und denjenigen untersuchen, der mein Modem gehackt hat

• Vor zwei Jahren erlebte ich während eines Schwachstellentests zu Hause etwas Seltsames
• Ich hatte auf einer AWS-Box einen HTTP-Server gestartet, um von einem verwundbaren Server eine Datei abzurufen
• Alles schien korrekt eingerichtet zu sein, doch als ich zum Schwachstellentest zurückkehren wollte, tauchte ein unerwarteter Log-Eintrag auf
• Jemand hatte dieselbe HTTP-Anfrage 10 Sekunden später zwischen meinem Heimnetzwerk und der AWS-Box abgefangen und erneut gesendet
• Dieser Traffic hätte nicht zugänglich sein dürfen und es hätte keinen Vermittler geben dürfen
• Mein erster Gedanke war sofort, dass mein Computer kompromittiert worden war und ein Angreifer den Traffic aktiv überwachte
• Ich prüfte, ob dasselbe Phänomen auch auf dem iPhone auftrat, und eine unbekannte IP-Adresse fing sowohl die HTTP-Anfragen meines Computers als auch meines iPhones ab und sendete sie erneut
• Es schien sehr wahrscheinlich, dass entweder der ISP, das Modem oder AWS kompromittiert worden war
• Um den absurden Gedanken auszuschließen, dass AWS gehackt worden sei, startete ich eine Box bei GCP, und dort trat dasselbe Verhalten auf
• Die einzige verbleibende Möglichkeit war, dass das Modem gehackt worden war, aber wer war der Angreifer? Eine Abfrage des Eigentümers der IP-Adresse ergab, dass sie zu DigitalOcean gehörte
• Diese IP war in den letzten Jahren für mehrere Phishing-Seiten und Mailserver genutzt worden
• Das kompromittierte Gerät lief weiter, also zog ich den Stecker und legte es in eine Kiste
• Ich ging in einen Cox-Shop, gab das gehackte Modem zurück und erhielt ein neues
• Nach der Installation des neuen Modems hörte das seltsame Verhalten auf, aber der genaue Weg der Kompromittierung blieb unklar
• Drei Jahre später sprach ich im Urlaub mit befreundeten Sicherheitsexperten über den Vorfall, und sie fanden ihn interessant und begannen zu ermitteln
• Beim Blick auf die von der IP-Adresse registrierten Domains fanden sie massenhaft algorithmisch erzeugte Domains. Das deutete auf einen C&C-Server hin
• Der Angreifer führte von derselben IP aus mehrere bösartige Aktivitäten durch, wurde aber drei Jahre lang nicht abgeschaltet. Die Absicht blieb schwer zu verstehen
• Da auch das neue Modem dasselbe Modell war, wurde zudem in Betracht gezogen, dass der Angreifer erneut eingedrungen sein könnte
• Die Aufmerksamkeit richtete sich auf das TR-069-Protokoll, über das der ISP Geräte verwalten kann. Wenn man die Infrastruktur der Support-Tools angreift, könnte man Modems übernehmen
• Durch die Analyse des JavaScript im Cox-Business-Portal wurden mehr als 700 API-Pfade gefunden. Die APIs mit den meisten Funktionen für Geräte- und Kundenzugriff waren accountequipment, datainternetgateway und account
• Es wurde eine Schwachstelle entdeckt, mit der sich die Authentifizierung umgehen ließ. Durch wiederholtes Senden von HTTP-Anfragen konnten unbefugt Befehle ausgeführt werden
• Es wurde bestätigt, dass sich über die MAC-Adresse direkt mit beliebigen Geräten kommunizieren ließ. Cox bedient Millionen von Kunden
• Es wurde nachgewiesen, dass sich Gerätekonfigurationen überschreiben, auf Router zugreifen und Befehle auf Geräten ausführen ließen — also Berechtigungen auf dem Niveau des technischen ISP-Supports
• Damit handelt es sich um eine Schwachstelle, mit der sich ohne Vorbedingungen die Konfiguration von Millionen Modems ändern, auf PII von Kunden zugreifen und Berechtigungen auf dem Niveau des ISP-Supportteams erlangen lassen
• Das Vorfallszenario sieht wie folgt aus
  1. Suche nach Cox-Business-Kunden über die API
  2. Abruf von Kundendaten wie Geräte-MAC-Adresse, E-Mail, Telefonnummer und Adresse über die UUID
  3. Abfrage des WiFi-Passworts und der verbundenen Geräte über die MAC-Adresse
  4. Ausführung beliebiger Befehle, Änderung von Geräteeigenschaften und Übernahme des Kontos
• Die Schwachstelle wurde an Cox gemeldet; innerhalb von 6 Stunden blockierte das Unternehmen die API und begann, das Authentifizierungsproblem zu beheben
• Von den mehr als 700 offengelegten APIs bot ein erheblicher Teil Administratorfunktionen, und alle hatten dasselbe Berechtigungsproblem
• Dieser Fall zeigt die Schwäche der Vertrauensebene zwischen ISP und Kundengeräten
• Wie genau mein Modem gehackt wurde, beschäftigt mich weiterhin. Auch warum der Angreifer den Traffic erneut sendete, verstehe ich nicht
• Theorien oder Meinungen dazu sind willkommen

Meinung von GN⁺

• Sicherheitsschwachstelle: Dieser Artikel zeigt, wie gravierend sich Sicherheitsschwachstellen bei ISPs auswirken können. Insbesondere können Funktionen zum entfernten Ändern von Geräteeinstellungen missbraucht werden.
• API-Sicherheit: Er unterstreicht die Bedeutung von API-Sicherheit. Schwachstellen wie eine Umgehung der Authentifizierung können schwerwiegende Sicherheitsprobleme verursachen.
• Schutz von Nutzerdaten: Er warnt vor dem Risiko, dass persönliche Daten von Kunden und Geräteeinstellungen leicht offengelegt werden können. ISPs müssen stärkere Sicherheitsmaßnahmen ergreifen, um diese Daten zu schützen.
• Technisches Verständnis: Durch die Erklärung technischer Details auf eine Weise, die auch ein Softwareentwickler auf Einsteigerniveau verstehen kann, lässt sich lernen, wie man Sicherheitsschwachstellen erkennt und behebt.
• Alternativen aufzeigen: Um solche Probleme zu lösen, ist der Einsatz sichererer Netzwerkgeräte und Sicherheitsprotokolle wichtig. Auch andere ISPs oder Sicherheitslösungen können in Betracht gezogen werden.

[GN⁺]

Hacker-News-Kommentare

• Beeindruckend, dass Cox verantwortungsvoll reagiert hat, statt das Problem zu leugnen oder den Überbringer der Nachricht anzugreifen. Ich würde gern einen Folgeartikel darüber lesen, worin der Bug genau bestand.
• Es ist unerquicklich, wenn ein ISP die Nutzung eigener Modems oder Router erzwingt. Mein AT&T-Router könnte zwar gehackt werden, aber dank HTTPS ist das immerhin ein Trost.
• Ausgezeichneter Artikel und gute Untersuchung. Die lokale Admin-Oberfläche des Nokia-Routers scheint nicht korrekt authentifiziert zu sein. Bestimmte Einstellungen ließen sich zwar nicht ändern, aber durch Manipulation der Seite konnte man sie dennoch ändern.
• Viele Router erfordern manuelle Firmware-Updates. Bei GL.iNet-Routern gab es kürzlich eine RCE-Sicherheitslücke. Empfohlen werden Maßnahmen wie Firmware-Updates und das Deaktivieren des SSH-Zugangs.
• Ich frage mich weiterhin, wie der Angreifer den HTTP-Traffic abgefangen hat. Cox dürfte das Problem beheben können, indem die Firmware-Version geprüft und per automatischem Update aktualisiert wird.
• Cox behauptet, dass diese Schwachstelle in der Vergangenheit nicht ausgenutzt wurde, aber das ist schwer zu glauben. Das Netzwerk wirkt schlampig abgesichert.
• Es ist schockierend, dass bei einem großen Tech-Unternehmen eine derart große Schwachstelle gefunden wurde. Der Artikel ist hervorragend, aber diese Sicherheitslücke ist unverzeihlich.
• Ich frage mich, ob die Person, die die Schwachstelle gemeldet hat, dafür belohnt wurde. Sie hat einen großen Beitrag geleistet, scheint aber keinerlei Vergütung erhalten zu haben. Das ist ziemlich beleidigend.
• Der Grund, warum Cox behauptet, dass es in der Vergangenheit keine Ausnutzung gab, dürfte sein, dass es an Logs oder Audit-Daten fehlt.
• Der Artikel ist großartig, aber ein entschlossener Angreifer könnte sich immer noch als Cox-Techniker ausgeben, um sich Zugang zu verschaffen. ISPs sollten eine Konfiguration umsetzen, bei der Remote-Zugriff standardmäßig deaktiviert ist.