The Speedport Hack Myth
This translation was generated automatically.
Telekom has published its own account of the outage:
Myth of the open interface: what really happened
Not a myth. The port was open. If it hadn’t been open, nothing would have happened.
The ACS asked the end device to contact it. This “knocking function” is described in the TR-069 standard as a “Connection Request”. For the Connection Request to work, the end device must be reachable by the ACS over the internet. The standard specifies port 7547/tcp, which all Speedport routers use. The Connection Request is triggered over HTTP. On Speedport routers, several security features protect this mechanism against abuse. For example, the ACS must authenticate to the end device using a device-specific password.
The device doesn’t need to be reachable from the internet; it needs to be reachable by Telekom’s ACS and nobody else. How that restriction is implemented is another question. If providers really can’t give up “remote maintenance”, a maintenance VLAN seems like a possible solution—one that keeps the port unreachable from the internet.
Again: triggering a Connection Request makes the end device establish a secure connection to Deutsche Telekom’s preconfigured ACS. In principle, the Connection Request does not allow access to the end device’s data model.
Again: putting plastic routers with no meaningful security updates and open ports on the internet is a bad idea.
The current attacks do not target the ACS but the Connection Request endpoint on the device, reachable over port 7547/tcp. The attack method used is new and wasn’t previously known. Current information suggests it is based on a publication released online in early November 2016.
The basic problem is poorly secured software on the customer’s device. You don’t need to know a specific attack to realize that your own hardware might be vulnerable.
Another problem is the poor quality of the sprawling TR-069 specification. It does, for example, call for a connection secured with SSL/TLS between ACS and devices—but, irresponsibly, only as a recommendation.
The researcher examined several hundred URLs ISPs use to communicate between end devices and their ACS. Result: 81% of connections use unsecured HTTP. “In principle, a single correctly constructed packet is enough to trigger a firmware update with manipulated firmware,” Tal said.
Even when TLS is used, there are problems: one DSL modem Tal studied accepted arbitrary, self-signed TLS certificates. That makes a man-in-the-middle attack possible, with the attacker impersonating the ACS. It’s also problematic that many ISPs hide TR-069 settings in routers, leaving technically savvy customers no way to inspect or change the configuration themselves.
I think TR-069 is fundamentally a very bad idea, rooted in the provider view of customer-premises equipment—that the box at the customer’s end is part of the provider’s network.
Telekom again:
The recent large-scale attack was not specifically designed for Deutsche Telekom Speedport routers; it didn’t exploit a vulnerability in Telekom’s Speedport routers. Based on current knowledge, no Speedport routers are affected by the issue published online; this method cannot run malware on a Speedport router.
“Not my problem” is a poor excuse here. The next attack may work, and then it won’t be a million routers crashing—it’ll be millions of permanently hacked routers joining a DDoS. What then? Replace millions of devices, block connections, a prime-time ARD special?
Telekom’s failure: The TR-069 remote-maintenance port should not have been reachable from the internet. Even if the routers weren’t vulnerable to the current attacks, one can safely assume that a custom operating system with a proprietary TR-069 implementation has other exploitable vulnerabilities. Weinmann has already hinted that he found and reported additional bugs to Telekom.
Nico Ernst’s comment at Heise, which I agree with:
Remote router management via TR protocols should be considered a failure. Criminals have discovered the millions of plastic boxes as targets. The attacks weren’t limited to some Telekom Speedport models; they were a shotgun blast at everything reachable over port 7547 from the internet.
One can assume Telekom knew about this and the many other TR-protocol vulnerabilities. Otherwise it could hardly have delivered a fix so quickly. Less than 24 hours after the attacks became known, Telekom distributed new versions …
What did Telekom do wrong?
The TR-069 port should not have been reachable over the internet from arbitrary IP addresses—there are ACLs, firewalls, and separate management networks for this. Telekom’s own customers alerted the company to this in 2014.
The result was an outage affecting almost a million internet connections, which shouldn’t be downplayed. It could even have been triggered without the attacker intending to do so.
The next attack on Germany’s 18 million DSL connections may be deliberate. Shifting responsibility in a press release leaves a bad feeling.
At least Telekom’s CEO seems to have read the memo before it went through PR, and says:
“CEOs, when it comes to security, listen to your nerds, not your CFOs.” T. Höttges at the #TelekomSecurity conference photo — Alexia Sailer, November 30, 2016