TR-069, die Telekom, und das was wirklich geschah

by Linus Neumann on November 30, 2016

[For a detailed analysis, move on to RPW’s post]

Am Montag und Dienstag versetzte ein Ausfall mehrerer hunderttausend Telekom-Router die deutsche Cyberlandschaft in Aufruhr. Dass der Ausfall mit einem Angriff in Verbindung steht, wurde recht früh von Telekom und Innenministerium bestätigt.

Das Einfallstor, so stellte sich bald heraus, war eine offen dem Internet ausgesetzte Fernwartungsschnittstelle. Ein kurzes Lauschen auf Port 7547 einer öffentlichen IP bestätigte (spätestens) nach wenigen Minuten eine Angriffswelle mit versuchter command injection:

TR069 Exploit Code

Der abgebildete Request will eine Lücke im TR-069 Befehl für das Setzen eines NTP-Servers ausnutzen, um eine Datei von einer fremdem Domain per wget herunterzuladen und auszuführen.

Für viele (auch mich) schien der Fall klar: Die Telekom-Router schienen eine Remote Code Execution im TR-069 zu haben – viel schlimmer hätte es kaum kommen können.

Es blieben jedoch eine wichtige Frage offen: Warum stürzten die Router ab, statt sich mit der Payload zu infizieren? Die Vermutung lag nahe, dass die Angreifer einen Bug in Payload oder Exploit-Code hätten. So könnten der Crash und die ausbleibende Infektion der Geräte erklärt werden. Den Angreifern schien irgendwo ein kleiner, aber entscheidender Fehler zu unterlaufen sein, der ihnen die Übernahme von 900.000 Geräten zu verhageln schien. Oder etwa nicht?

Zumindest nicht ganz. Während viele (auch ich) sich auf das Exploit-Binary stürzten, um den Fehler zu finden, besorgte sich Ralf-Philipp Weinmann erstmal in Ruhe eines der betroffenen Geräte. Dazu hat er eine erstklassige Analyse auf Englisch verfasst, die ich hier kurz in vereinfachten deutschen Worten zusammenfassen möchte:

Seine erste Erkenntnis: Auf den Telekom-Geräten lief gar kein Linux, das Voraussetzung für das Funktionieren des Befehls im TR069-Exploit wäre. Mit anderen Worten: Sie waren gegen den beabsichtigten Angriff immun, und somit wohl kaum Ziel des Angriffs.

Die nächste Hypothese wäre gewesen, dass sie zwar die Schwachstelle im TR-069 hätten, aber aufgrund des nicht interpretierbaren Befehls abschmieren würden. Wie Ralf feststellte, führte aber ein einmaliges Senden des Exploits zu gar keiner Reaktion der Geräte. Mit anderen Worten: Sie schienen nicht nur gegen den Exploit, sondern auch gegen den TR-069-Request selbst immun zu sein. Erst durch mehrmaliges Zusenden des Requests ließen sich die Geräte langsam aus dem Tritt bringen, bis sie irgendwann gar nicht mehr reagierten.

Was war also geschehen? Im großen weiten Internet wütet gerade eine Welle von versuchten TR-069-Angriffen. Viele vermeintlich infizierte Geräte scannen fortlaufend das Internet und sorgen dafür, dass jede öffentliche IP-Adresse annähernd im Minutentakt einem Angriffsversuch auf Port 7547 ausgesetzt ist. Die Telekom-Geräte haben den Port offen, waren jedoch gegen diesen speziellen Code-Injection-Angriffsversuch immun. Sie hatten weder die Schwachstelle, noch das Betriebssystem, auf das sich dieser Exploit richten.

Offenbar hatten sie jedoch eine DoS-Vulnerability im Interpretieren von TR-069-Befehlen. Dadurch wurden sie – von den Angreifern unbeabsichtigt – durch die Häufigkeit der Zugriffe zum Absturz gebracht. Ärgerlich für die Angreifer, ärgerlich für die Telekom, ärgerlich für die Kunden – ein bedauerliches Missverständnis 🙂

…dessen Ergebnis der Ausfall von fast einer Million Internet-Anschlüsse ist, der nicht verharmlost werden sollte: Er konnte sogar ohne Absicht des Angreifers ausgelöst werden.

Was hat die Telekom falsch gemacht?

  1. Der TR-069-Port hätte über das Internet nicht von arbiträren IP-Adressen erreichbar sein dürfen – dafür gibt es ACLs, Firewalls, und getrennte Management-Netze. Darauf wurde die Telekom schon 2014 von ihren eigenen Kunden aufmerksam gemacht.
  2. Die Verarbeitung der TR-069-Befehle hat darüber hinaus einen Fehler, der vermutlich im Verantwortungsbereich des Zulieferers der Geräte liegt. Entsprechend blockiert die Telekom gerade Zugriffe von außen auf diesen Port, und versorgt die Geräte mit Firmware-Updates.

Vielen Dank an dieser Stelle an Ralf-Philipp, der der Angelegenheit in Ruhe auf den Grund gegangen ist während viele (andere inklusive mir) zunächst auf der falschen Fährte waren, dass die Telekom-Router tatsächlich Ziel, und nicht etwa Kollateralschaden der Angriffswelle waren.

Als Vertreter des Chaos Computer Clubs durfte ich das Geschehen gestern kurz in den Tagesthemen zusammenfassen. Vor der Sendung gab es ein sogenanntes „Facebook live“, in dem Zuschauer direkt Fragen stellen können – kannte ich auch noch nicht, scheint aber ein gutes Format zu sein (leider auf der falschen Plattform!).

Zuvor hat das Thema auch die Tagesschau beschäftigt.

13 comments

???
Wireless ADSL IAD VR9 Loader v1.11.02 build Feb 20 2012 14:41:59
Arcadyan Technology Corporation

https://de.wikipedia.org/wiki/Speedport Siehe Hersteller 921 Arcadyan

Die waren doch eh zwischen „quasi nicht“ und nur teilweise betroffen, inwiefern trifft die analyse da?

721 TypA wäre eins von den betroffenen massengeräten (Huawei und daher wohl auch eher andere firmware)

by Klischeepunk on 30. November 2016 at 14:49. #

Ich verstehe deine Frage nicht.
Ja, es handelt sich um ein Arcadyan-Gerät,
Ja, es war nicht von der Code-Injection betroffen,
Ja, es ist trotzdem abgeschmiert.
WEIL es einen Bug im Verarbeiten von TR-069-Requests hatte.

Der entscheidende Absatz im Artikel lautet:

Die Telekom-Geräte haben den Port offen, waren jedoch gegen diesen speziellen Code-Injection-Angriffsversuch immun. Sie hatten weder die Schwachstelle, noch das Betriebssystem, auf das sich dieser Exploit richten.

Offenbar hatten sie jedoch eine DoS-Vulnerability im Interpretieren von TR-069-Befehlen. Dadurch wurden sie – von den Angreifern unbeabsichtigt – durch die Häufigkeit der Zugriffe zum Absturz gebracht. Ärgerlich für die Angreifer, ärgerlich für die Telekom, ärgerlich für die Kunden – ein bedauerliches Missverständnis 🙂

by Linus Neumann on 30. November 2016 at 15:20. #

Was ich noch nicht verstanden habe :-/

Ist denn klar, welche Geräte infiziert werden wollten und so die Telekom-Dinger nebenbei haben abrauchen lassen?

Also waren das dann die Zugangsgeräte von $Vodafone, die eben nicht abgeraucht sind aber jetzt fröhlich weiter infizieren?

by Pepo on 30. November 2016 at 15:36. #

Ob Geräte in Deutschland infiziert wurden, wissen wir nicht und können das auch nicht ausschließen.
Gehen wir aber mal davon aus, dass infizierte Geräte automatisch versuchen, andere zu infizieren.
Dann geben uns die Source-IPs Aufschluss darüber, in welchen Ländern infizierte Geräte stehen.
Ich habe gestern unter anderem Iran, Brasilien, Chile, Italien, Großbritanien und andere gesehen (unvollständige Aufzählung ohne Anspruch auf Richtigkeit), aber kein einziges Mal Deutschland. Das mag Zufall sein, aber auch niemand anderes hat nach meiner Kenntnis bisher deutsche Source IPs berichtet.
Zum jetzigen Zeitpunkt ist also davon auszugehen, dass wenn, dann nur sehr wenige Geräte in Deutschland infiziert sind. Irgendwo in Deutschland steht aber sicherlich irgendein Plaste-Router, der gerade Gottweißwen hackt 🙂

Kann auch gut sein, dass sich dieser Kenntnisstand bald ändert, weil die Provider jetzt sicherlich nach ausgehendem TR-069 suchen, um infizierte Kunden zu erkennen.

by Linus Neumann on 30. November 2016 at 15:48. #

Ich konkretisiere die Frage aus dem zitierten Absatz:
„Die Telekom-Geräte “ oder „Diese Telekom-Geräte“

Der Großteil der „Meldungen“ die ich als „problematisch“ erhalten hab drehen sich eben nämlich genau nicht um diese Geräte, das sorgt für meine Verwirrung. (Auch wenn es erfreulich ist, dass die konkrete Lücke/der konkrete Angriff bei Arcadyans keine weiteren Sorgen hinterlässt und wir wirklich bei „ärgerlicher Ausfall“ bleiben können) – auch: Wie erklären sich die „reboot hilft nicht“ ausfälle, die gehäuft aufgetreten sind? Rein der Analyse folgend dürfte das nicht vorkommen.

Was sich auch noch nicht – zumindest für mich sinnig – erschließt, sind die ersten SANS ISC Meldungen wo von registrierten Angriffsversuchen im Takt 5-10 Minuten gesprochen wurde.

Das der Bug (hier) weit weniger problematisch ist als befürchtet…. Gott sei dank. Und natürlich trotzdem rauswerfen & TKom aussperren. ^^

by Klischeepunk on 30. November 2016 at 15:48. #

Wie erklären sich die „reboot hilft nicht“ ausfälle, die gehäuft aufgetreten sind? Rein der Analyse folgend dürfte das nicht vorkommen.

So lange der Port noch nicht geblockt war, war das das zu erwartende Verhalten.

by Linus Neumann on 30. November 2016 at 15:50. #

[…] Beitrag erschien zuerst auf dem Blog von Linus Neumann. Er war außerdem bei den tagesthemen zu Gast, um über den Angriff auf die […]

by TR-069, die Telekom, und das, was wirklich geschah | netzpolitik.org on 30. November 2016 at 16:30. #

[…] TR-069, die Telekom, und das was wirklich geschah […]

by Kurz verlinkt | Schwerdtfegr (beta) on 30. November 2016 at 16:39. #

[…] Angreifer geplant handeln konnten, sind sie doch reihenweise ‚ausgetiegen’… Bei Linus Neumann findet man Details (via […]

by Kein (Internet)Anschluss unter dieser Nummer | nullenundeinsenschubser on 30. November 2016 at 23:41. #

[…] tanden hebben stukgebeten op de Speedport-routers, zegt Linus Neumann van de Computer Chaos Club in een blog. Op de Telekom-routers is geen besturingssysteem geïnstalleerd waarvoor de aanval bedoeld is. Ook […]

by Webaanval niet gericht op Telekom-routers - Niks te verbergenNiks te verbergen on 2. Dezember 2016 at 00:12. #

[…] Linus Neumann: TR-069, die Telekom, und das was wirklich geschah (via […]

by Froschs Blog: » Im Netz aufgefischt #293 on 4. Dezember 2016 at 16:50. #

[…] Beitrag erschien zuerst auf dem Blog von Linus Neumann, der spricht auch in den […]

by Der Internetausfall, TR-069, die Telekom, und das, was wirklich geschah | Jochens Sozialpolitische Nachrichten on 7. Dezember 2016 at 03:44. #