TR-069 NewNTPServer Exploits: What we know so far

Published: 2016-11-29
Last Updated: 2016-11-29 22:36:43 UTC
by Johannes Ullrich (Version: 1)
13 comment(s)

[This is a "cleaned up" version to summarize yesterday's diary about the attacks against DSL Routers]

What is "TR-069"

TR-069 (or its earlier version TR-064) is a standard published by the Broadband Forum. The Broadband Forum is an industry organization defining standards used to manage broadband networks. It focuses heavily on DSL type modems and more recently included fiber optic connections. "TR" stands for "Technical Report". TR-069 is considered the Broadband Forum's "Flagship Standard". [1] Many ISPs and device manufacturers are members of the broadband forum.

TR-069 allows ISPs to manage modems remotely. Port 7547 has been assigned to this protocol. Some devices appear to use port 5555 instead. I haven't found a standard defining port 5555 for this use, but it may be an older version. The standard suggests the use of TLS 1.2 but doesn't require it, and TLS would not have made a difference in this case. Authentication can happen via certificates, or 

TR-069 messages are encoded using SOAP. These SOAP requests include a message that is then parsed by the modem (CPE, "Consumer Premise Equipment). The standard defines a large range of required and optional features. For example, the modem can be rebooted, or reset to factory condition. A TR-069 message can also be used to get and set configuration parameters. Some of these parameters and the detail of the data model are defined in later technical reports. For example, TR-098 defined the NTP server feature abused in the exploit attempts we have seen.

A typical (non exploit) request to set an NTP Server would look like: (click on images for full size versions)

The response the modem would return will be:

The Vulnerability & Exploit

On November 7th, 2016, "kenzo2017" posted a blog post showing how the TR-064 "NewNTPServer" feature can be used to execute arbitrary commands. The blog post mentioned only the D1000 modem used by Irish ISP Eir as vulnerable [2]. As a proof of concept, the blog post included a Metasploit module to execute commands, and to retrieve the modems WiFi password. This particular modem is a rebranded modem manufactured by Zyxel. Other Eir modems (e.g. P-60HN-T1A_IPv6) were found to be vulnerable as well. There is no mention of Eir being notified of this issue. I also can't find a CVE number for this vulnerability. 

This isn't the first time TR-069 implementations were found to be vulnerable. Over the last couple of years, a number of different issues were discovered, most notably a "Misfortune Cookie" bug (CVE-2014-9222). 

Deutsche Telekom Outage

On Sunday, November 27th, 2016, a large number of Deutsche Telekom customers reported connectivity problems. These issues were later traced to attacks against a particular type of modem. Deutsche Telekom uses the brand name "Speedport" for its modems, but the modems themselves are manufactured by different companies. Deutsche Telekom lists the Speedport W 921 V, 723V Typ B, and 921 Fiber as affected. All of these modems are made by Taiwanese company Acadyan, which does not appear to be connected to Zyxel, the maker of the vulnerable Eir modem. [3] Comsecuris ran tests on one of the modems and found it not vulnerable, but they did point out that the modem will become slow and "hang" even under moderate load, so it is possible that the connections Mirai sent to the modem caused it to hang, not the exploit itself. [4] 

Deutsche Telekom rolled out a firmware update to fix the vulnerability exploited by the attack. There has been no official statement from Deutsche Telekom confirming that the TR-069 attack was used to crash the modem. However, Deutsche Telekom did state that an "coding error" in the exploit caused the modems to crash instead of run the exploit code.

Increase in Scans for Port 7547

Around the time the outage in Germany, we did notice a substantial increase in the number of attacks against port 7547. Later, a similar increase was noted on %%port:5555%.

Honeypots confirmed that these scans are attempting to exploit the TR-069 NewNTPServer vulnerability (line breaks and color added for readability)

.

The command executed will download additional malware from "tr069.pw" and execute it. We found a number of different URLs being used. The file name varies from 1 through 7, but 1 and 2 are the most common once seen. There is also an "x.sh" script, but it usually doesn't exist on the web server.

Here are some of the URLs seen in our honeypots, as well as URLs observed by our readers:
 http://5.8.65.5/1
 http://5.8.65.5/2
 http://l.ocalhost.host/1
 http://l.ocalhost.host/2
 http://l.ocalhost.host/3
 http://l.ocalhost.host/x.sh
 http://p.ocalhost.host/x.sh
 http://timeserver.host/1
 http://ntp.timerserver.host/1
 http://tr069.pw/1 
 http://tr069.pw/2
 http://srrys.pw/2 (resolves to 5.188.232.152 right now. the other host names appear dead right now)

The different binaries (1-7) are essentially the same code, but compiled for different architectures. This may indicate that the same exploit is attempted against a wide range of vulnerable devices:

1: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
2: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
3: ELF 32-bit LSB  executable, ARM, version 1, statically linked, stripped
4: ELF 32-bit LSB  executable, Renesas SH, version 1 (SYSV), statically linked, stripped
5: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped
6: ELF 32-bit MSB  executable, SPARC version 1 (SYSV), statically linked, stripped
7: ELF 32-bit MSB  executable, Motorola 68020 - invalid byte order, version 1 (SYSV), statically linked, stripped

Hashes observed (they vary based on the URL used to spread the code):

01fb38152c7f86aca2c42e8e8ebc46a9abeeac0501b0800e8009ee6328d112fd  1
b4d378a917b01bbb8a783bbd7a8cfe070c7dd6ac7b8aa5f205df6e7e24f0a85e  2
1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf  3
828984d1112f52f7f24bbc2b15d0f4cf2646cd03809e648f0d3121a1bdb83464  4
c597d3b8f61a5b49049006aff5abfe30af06d8979aaaf65454ad2691ef03943b  5
046659391b36a022a48e37bd80ce2c3bd120e3fe786c204128ba32aa8d03a182  6
5d4e46b3510679dc49ce295b7f448cd69e952d80ba1450f6800be074992b07cc  7

Based on a simple "strings" analysis, the code downloaded is the spreader looking for additional vulnerable systems. This code appears to be derived from the "Mirai" botnet. While earlier versions of Mirai used well know default or weak passwords, this version now added the TR-069 NetNTPServer exploit to its repertoire. The command and control servers resolve to a 6.0.0.0/8 IP address at this point which does not appear to be operations. It is assumed that this is used to "park" the botnet.

Countermeasures

As a consumer, if you suspect that your modem is vulnerable or worse, exploited: Reboot your modem and check on firmware updates. For some ISPs, like Deutsche Telekom, firmware updates are avaialbe. But you will typically receive the firmware from your ISP, not the modem's manufacturer. ISPs customize firmware, like for example by enabling TR-069, and a "default" manufacturer provided firmware may not work for you.

ISPs should (and typically will) restrict access to port 7547 and port 5555 if it is used for remote configuration. Modem should only accept connections from specific configuration servers. TR-069 implementations had vulnerabilities in the past, and it is very likely that additional issues will be found in the future. Restricting access to the port is necessary to protect the modem from exploits against unpatched vulnerabilities.

How Many Modems Are Vulnerable?

The number of devices listening on port 7547 is as larger as 40 Million according to counts performed with Shodan. But not all these modems may run vulnerable implementations, and some may only accept commends from specific servers. It is difficult to say which modems are vulnerable and which once are safe. My personal "best guess" is that this vulnerability may have added 1-2 Million new bots to the Mirai botnet. We do have about 600,000 source IPs scanning for this vulnerability in our database. But many of them may have been infected by Mirai via weak passwords. For a small number of sources that responded on Port 443, we connected and retrieved TLS certificates. The overwhelming portion of certificates where issues by Zyxel, indicating that it is infected Zyxel devices that are participating in the scanning.

Some tests done by Darren Martyn show that modems used by UK ISP TalkTalk, D-Link DSL 3780 modems, modems made by MitraStar, Digicom and Aztech are all vulnerable. He states that he found 48 different vulnerable devices [5] 

The attack so far doesn't appear to be targeting a particular geographic area or a particular ISP. 

What's Next?

At this point, the newly infected systems are just used to scan for more victims. But it is probably just a matter of time until they are used for DDoS attacks.

Further Reading

https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/
https://twitter.com/info_dox

Samples: https://isc.sans.edu/diaryimages/miraitr069binaries.zip (password: infected)

[1] https://www.broadband-forum.org/technical/download/TR-069_Amendment-5.pdf
[2] https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/
[3] https://de.wikipedia.org/wiki/Speedport​
[4] https://comsecuris.com/blog/posts/were_900k_deutsche_telekom_routers_compromised_by_mirai/
[5] https://twitter.com/info_dox

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
13 comment(s)

Comments

This has been covered as far back as August 14th, 2014.

http://www.routercheck.com/2014/08/14/major-problems-tr-069/

Over two years since serious, credible concerns were raised and nobody cared enough to fix it in all that time? That's some serious negligence there.
When feeding the download URLs to Virustotal, the URLs look harmless. Queried via Virustotal the sites seem to return 404 for the files in question.
Thank you very much for the informative summary!

One question though...
You wrote that "ISPs should (and typically will) restrict access to port 7547 and port 5555 if it is used for remote configuration".
Does that mean that for whatever reason the affected Telekom routers/customers had not such restrictions in place?
Good round up of the issues.

One thing worth correcting is that the exposed protocol is TR-064, not TR-069. TR-069 is only meant to connect from the router to an ISP's server, and doesn't accept settings by POST requests. TR-064 does accept settings via a POST request.

TR-064 isn't an earlier version of TR-069, it's a different protocol.

TR-064 is "LAN-Side DSL CPE Configuration" i.e. it is never supposed to be exposed to the WAN. The spec says it must always have authentication, so a number of failures here.
Just to be accurate:

TR-064 isn't the ancestor of TR-069: it was designed to allow *LAN-side management* whereas TR-069 is for the WAN side. (By the way, it's now deprecated in favor of UPnP DM.)
For a device to expose TR-064 on the WAN side is clearly a bad idea.

jd
A very interesting and thorough article! The second paragraph appears to be truncated, though:
[quote]Authentication can happen via certificates, or [/quote]
if we shut port 7547,we can neutralised the effect and services will be up but the ISP side management goes off.
Interesting article. And just thé article i was looking for.
We happen to use a ftp server in which we a few years ago (don't ask me why) choose 5555 for the port.
I saw a large increase of traffic and login's to NTP services on that particular FTP server. It has no use whatsoever; but the increase in traffic was substantial.
I didn't know older NTP services uses 5555 for the port. We changed the port settings and the logins/attacks stopped immediately
So a big thank you!
Seems most of the domains actually host all 8 of the files.

Todays:
hxxp://srrys.pw/1
hxxp://srrys.pw/2
hxxp://srrys.pw/3
hxxp://srrys.pw/4
hxxp://srrys.pw/5
hxxp://srrys.pw/6
hxxp://srrys.pw/7
hxxp://srrys.pw/x.sh


Remarkably is that x.sh still refers to l.ocalhost.host, which doesn't resolve anymore. wget of '1' and '2' is by far the most common seen on our infrastructure, while '3' also starts using port 5555 (https://detux.org/report.php?sha256=1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf)
Hello,

I have a Zyxel AMG1312-T10B router with firmware V2.00(AAFP.6)C0

TR-069 protocol is disabled on my router (like Upnp, WPS etc.) but after finding this article I ran a scan with Nmap on port 7547 and with great surprise it was found open even though the firewall was active !

How to identify if a router was compromised with this exploit? There is some particular check to make on the router file system accessible via ssh ?

- A comparison of the current config file with an old one revealed no changes in the configuration file itself.

- A firewall rule to block port 7547 access from the wan has no effect on my router.

- The only effective way to disable TR-069 was to set the port to 0 on my router admin.

Diary Archives