“Mythos” Speedport-Hack

Die Telekom hat eine eigene Darstellung des Ausfalls veröffentlicht:

Mythos offene Schnittstelle: Was wirklich geschah

Kein Mythos. Der Port war offen. Wäre er nicht offen gewesen, wäre nichts passiert.

Der ACS hat das Endgerät dazu aufgefordert, sich bei ihm zu melden. Diese „Anklopffunktion“ wird im TR-069 Standard als sogenannter „Connection Request“ beschrieben.
Damit der Connection Request funktionieren kann, muss das Endgerät für den ACS über das Internet erreichbar sein. Laut Standard ist hierfür der Port 7547/tcp vorgesehen, der auch von allen Speedport Routern dazu genutzt wird. Das Auslösen des Connection Requests erfolgt über das HTTP Protokoll. Bei den Speedport Routern ist dieser Mechanismus durch verschiedene Sicherheitsfunktionen gegen Missbrauch geschützt. Beispielsweise muss der ACS sich gegenüber dem Endgerät mittels eines geräteindividuellen Passworts authentifizieren.

Das Endgerät muss nicht aus dem Internet erreichbar sein, es muss für den ACS der Telekom und für sonst niemanden erreichbar sein. Wie diese Einschränkung umgesetzt wird, sei dahingestellt. Sollten sich die Provider wirklich nicht von der “Fernwartung” trennen können, scheint ein Wartungs-VLAN eine denkbare Lösung zu sein, das den Port aus dem Internet nicht erreichbar macht.

Nochmals: Das Auslösen eines Connection Requests bewirkt, dass das Endgerät eine sichere Verbindung zum vorkonfigurierten ACS der Deutschen Telekom aufbaut. Der Connection Request ermöglicht grundsätzlich keinen Zugriff auf das Datenmodell des Endgerätes.

Nochmals: Plastikrouter ohne nennenswerte Sicherheitsupdates mit offenen Ports ins Internet zu stellen, ist eine schlechte Idee.

Die aktuellen Angriffe betreffen jedoch nicht den ACS, sondern den Endpunkt für den Connection Request auf dem Endgerät, der über Port 7547/tcp erreicht werden kann. Die hierbei verwendete Angriffsmethodik ist neu und war bis dato nicht bekannt. Nach aktueller Sachlage basiert diese auf einer Veröffentlichung im Internet von Anfang November 2016.

Das grundsätzliche Problem ist die schlecht abgesicherte Software auf Kundenseite. Ein konkreter Angriff muss nicht bekannt sein, um festzustellen, dass die eigene Hardware betroffen sein könnte.

Heise dazu im Jahr 2014:

Ein weiteres Problem sei die Qualität der ausufernden Spezifikation von TR-069. Sie sieht zwar beispielsweise eine per SSL/TLS gesicherte Verbindung zwischen ACS und Endgeräten vor – aber fahrlässigerweise nur als Empfehlung.

Der Forscher untersuchte auch einige hundert URLs, die ISPs zur Kommunikation zwischen Endgerät und ACS verwenden. Ergebnis: 81 Prozent aller Verbindungen finden ungesichert per HTTP statt. “Damit genügt im Prinzip ein einzelnes, korrekt zusammengesetztes Paket, um einen Update mit manipulierter Firmware auszulösen”, so Tal.

Aber selbst wenn TLS zum Einsatz kommt, gibt es Probleme: Ein von Tal untersuchtes DSL-Modem habe beliebige, selbstsignierte TLS-Zertifikate akzeptiert. Damit sei eine Man-in-the-Middle-Attacke möglich, bei der sich der Angreifer als ACS ausgibt. Problematisch sei auch, dass viele ISPs die TR-069 betreffenden Einstellungen in den Routern verstecken und sachverständigen Kunden somit keine Chance lassen, die Konfiguration selbst zu prüfen oder zu ändern.

Ich halte TR-069 für eine grundsätzlich sehr schlechte Idee, die aus dem CPE-Denken der Provider herrührt, die Box auf Kundenseite sei Teil des Providernetzes.

Wieder die Telekom:

Der aktuelle großflächige Angriff war nicht spezifisch für die Speedport Router der Deutschen Telekom ausgelegt, d.h. er nutzt keine Schwachstelle in den Speedport Routern der Deutschen Telekom aus. Nach aktuellem Kenntnisstand sind keine Speedport Router von der im Internet publizierten Problematik betroffen, d.h. es ist nicht möglich, mit dieser Methodik eine Schadsoftware auf einem Speedport Router zur Ausführung zu bringen.

“From the department of not-my-problem” ist hier eine schlechte Ausrede. Der nächste Angriff funktioniert vielleicht, und dann ist eben nicht eine Million Router abgestürzt, sondern beteiligt sich mit permanent gehackter Firmware an einem DDOS. Was dann? Millionen Geräte tauschen, Anschlüsse sperren, Brennpunkt in der ARD.

Heise:

Versäumnis der Telekom
Fehler kann man der Telekom natürlich trotzdem vorwerfen: Der Fernwartungs-Port TR-069 hätte nicht offen aus dem Internet erreichbar sein dürfen. Auch wenn die Router für die aktuellen Angriffe nicht anfällig waren, kann man gerade bei einem solchen selbstgestrickten Betriebssystem mit proprietärer TR-069-Implentierung getrost davon ausgehen, dass es andere Sicherheitslücken aufweist, die sich missbrauchen lassen. Weinmann deutet auch bereits an, weitere Fehler gefunden und der Telekom gemeldet zu haben.

Kommentar von Nico Ernst bei Heise, dem ich mich anschließen kann:

Die Fernwartung von Routern über die TR-Protokolle darf als gescheitert angesehen werden. Kriminelle haben die millionenfach vorhandenen Plastikkästchen als Angriffsziel entdeckt, die Attacken galten nicht allein manchen Speedport-Modellen der Telekom. Vielmehr handelt es sich um einen Schrotschuss auf alles, was über den Port 7547 per Internet erreichbar ist.

Man darf wohl davon ausgehen, dass diese und die zahlreichen weiteren Lücken in den TR-Protokollen der Telekom bekannt waren. Sonst wäre kaum eine so schnelle Anhilfe durch neue Firmware möglich gewesen. Schon weniger als 24 Stunden nach Bekanntwerden der Angriffe verteilte die Telekom die neuen Versionen

Netzpolitik.org:

Was hat die Telekom falsch gemacht?

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.

Ergebnis [ist] 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.

Der nächste Angriff auf die 18 Millionen DSL-Anschlüsse in Deutschland ist vielleicht ernstgemeint. Per Pressemitteilung die eigene Verantwortung abzuwälzen, hinterlässt schlechte Gefühle.

Wenigstens der Telekom-Chef hat wohl das Memo gelesen, bevor es durch die PR-Abteilung ging und sagt:

Speedport-Hack – Telekom kannte die Schwachstelle

Ein Detail zu dem großflächigen Ausfall bei Telekom-DSL-Kunden gestern, das in den Mainstream-Berichten häufig fehlt:

Heise:

Es sieht alles danach aus, als ob es sich um eine Variation der TR-069-Lücke handelt, die bereits 2014 von CheckPoint publik gemacht worden war. Zu diesem Zeitpunkt hatten deutsche Provider (darunter auch die Telekom) ihre Netze für sicher erklärt.

Die grundsätzliche Problematik der TR-069/064 Fernwartungs-Schnittstelle war seit mindestens zwei Jahren öffentlich bekannt und betrifft potentiell nicht nur die gestern betroffenen Speedport-Router, sondern alle Arten von Routern.

Der gestrige Ausfall erscheint mir also durchaus T-hausgemacht, und hätte leicht präventiv verhindert werden können, denn:

Internet-Verkehr wurde auf den dafür genutzten Port 7547 an die Router durchgeleitet. Ein legitimer Anwendungsfall dafür mag sich mir nicht erschließen.

Das grundsätzliche Problem war bekannt, und die Gegenmaßnahmen im eigenen Netz waren unzureichend. Wenn Angriffe auf diesem Port seit Jahren bekannt sind, und ein legitimer Zugriff nur aus dem Support-Netz der Telekom stammen dürfte, hätte der Port schon seit Jahren für Zugriffe aus dem Internet gesperrt sein müssen.

Die Aussagen der Telekom-Sprecher verschleiern die eigene Fahrlässigkeit.

Tagesschau

Die Fernwartung (“Easy Support” bei der Telekom) ließ sich lange auf gemieteten Speedports nicht deaktivieren. Das geht laut Dokumentation inzwischen. Update: Ist allerdings vertraglich bei Mietroutern weiterhin untersagt.

Eine wirkungsvoller Workaround wäre vermutlich schon am Sonntag gewesen: Router ohne DSL-Kabel booten, Fernwartung deaktivieren. Aber das hätte nur zusätzlichen Support-Aufwand in der Zukunft verursacht oder weitere Sicherheitsupdates verhindert, weil das Auto-Update nicht mehr angestoßen werden kann. Die Fernwartungs-Schnittstelle stellt ein großes Risiko dar und offener Zugriff darauf aus dem Internet hätte schon seit mindestens zwei Jahren aufgegeben werden sollen.

Details zum Angriff beim ISC

Tim Cook on iPod Classic and Mac Pro (2014)

From the Q&A at WSJD Live, November 2014. Starts at 28:45 in the video.

Q: [Why did you kill the iPod Classic 160GB?]

Tim Cook: “Because we couldn’t get the parts anymore. Not even anywhere, they’re not made anymore. And so we had the choice of either of doing a total redesign, a totally new project. Or try to get people to go to the iPod touch, if they wanted a sort of dedicated music device. iPod touch is not really a dedicated music device, but I think you know what I’m saying. We’re shipping a lot of flash in it now. You can get almost all the ones that you get on your Classic. Not quite yet. Over time, that might change. And so, it wasn’t a matter of where I was swinging the axe saying, let me see what I can kill today.
The engineering work to design a whole new product was pretty massive. And the number of people who wanted it, very small. Sometimes we decide to do those anyway, like Mac Pro. We’re doing those for our creative customers, but in the case of iPod [Classic] I felt that there are reasonable alternatives there and I’m sorry if you didn’t feel that way, because I want to keep you as a customer. But that was the rationale.”

To put it in other words: The Mac Pro wasn’t making enough money to justify the 2013 redesign in the first place from a pure business perspective. But they did it anyway for their creative customers. Is the MacBook Pro 2016 a reasonable enough alternative?