Update: Learn more about how this attack could be used against TR-069 devices here.
The week of November 28 2016 saw a massive attack on certain home routers deployed by several European service providers. The attack was based on the Mirai Malware attack several weeks previous that affected the dynamic DNS services provided by Dyn, Inc.. The attack focused on sending certain SOAP commands based on the Broadband Forum’s older TR-064 protocol, through port 7547. This is a commonly open TCP port on WAN devices that use the popular CPE WAN Management Protocol, more commonly known as TR-069.
The goal of the attack was to get these routers to execute arbitrary code and download the Mirai malware, making them robots for DDoS attacks.
This has led many news outlets, not understanding the difference between TR-064, TR-069, and the nature of this open port, to label the attack as a TR-069 vulnerability. While this is far from the truth, it does highlight certain things that should be done to secure TR-069 deployments (including the ones we’ve documented here).
This is not a TR-069 vulnerability
So what’s the real story? The truth is that this attack doesn’t really have much to do with any TR-069 vulnerability, rather, it is exploiting implementations that are using an HTTP based service for remote management.
What is TR-069?
TR-069 is the technical report produced by the Broadband Forum that defines the CPE WAN Management Protocol. It was developed to assist service providers deploying subscriber CPE (routers, set-top-boxes, VoIP devices, etc.) to remotely configure, manage, monitor, and troubleshoot those devices using an Auto-Configuration Server (ACS). It is secure when implemented correctly and has been used for more than a decade by service providers around the world. QA Cafe has an entire training series on TR-069 if you want to know more.
Why port 7547?
That this attack targets port 7547 is a coincidence based on the fact that this port is open on many home routers that use CWMP. The CWMP endpoint (on the CPE) is always the one who initiates a CWMP session. In order to allow for a not-always-on connection, a connection request mechanism was included, which lets the ACS “kick” the CPE to initiate a session. It takes the form of a simple HTTP GET to a URL set by the CPE - a URL that can be arbitrary and is not required to use port 7547 (though it is the suggested port). This mechanism was later expanded to include a way to do connection requests over XMPP.
Three things to note about the HTTP connection request mechanism with regards to this attack:
- The CWMP connection request mechanism is only intended to kick the CPE into initiating a connection with its known ACS. No CWMP messages are ever sent to this URL or transferred over this connection.
- This is an exclusively CWMP mechanism, and has no relation to the protocol that is the actual subject of the attack (TR-064).
- It is a best practice to white-list only those systems that will initiate the connection request on the CPE.
It is really an attack on an older protocol
The attack is actually attack on an older protocol from the Broadband Forum, called “LAN side DSL CPE configuration”, defined in TR-064. This was made in the days when providers were struggling with getting deployed CPE up and running with just end-user interaction, rather than sending a technician. It worked by allowing software on the LAN (such as through an installation CD or DVD-ROM) to communicate with the router to set up basic communication. It uses very rudimentarily defined SOAP messages to configure and read a limited set of parameters on the CPE.
TR-064 is older and deprecated
TR-064 was deprecated and replaced with TR-064 Issue 2. This issue simply recommends that those interested in LAN side configuration use UPnP-DM with the CWMP data models.
From TR-064 Issue 1:
The protocol and data model defined in TR-064 Issue 1 are DEPRECATED They SHOULD only be used by legacy devices. All new devices and upgrades of existing devices SHOULD use the mechanism described in TR-064 Issue 2. This provides a mechanism for using the TR-098 InternetGatewayDevice:1 (DEPRECATED), TR-181 Issue 1 Device:1, or TR-181 Issue 2 Device:2 root data models with improved device security.
Implementation specific shell injection, not a protocol vulnerability
So what is the problem? The issue arises from particular router implementations that contained a set of design choices that created a “perfect storm” for the attack. You can see the code for the attack here.
See a capture of this kind of attack in CloudShark
- The implementations happened to use both TR-069 and an older, deprecated version of TR-064
- The implementations were serving both TR-069 connection request AND the general TR-064 service over the same port (7547)
- TR-064 was never meant to run over the WAN
- The implementation responded to TR-064 requests without any authentication (TR-064 recommends HTTP digest authentication)
- The implementation allowed arbitrary code to be executed via shell injection using one of the possible configuration parameters (in this case, NewNTPServer1)
All of these add up to an easily exploitable vulnerability, but not a TR-069 vulnerability.
What’s being done about it?
If you’re a user
If you are a router user hearing about this attack, you’ll see many articles implying that seeing port 7547 open on your device means you are vulnerable to the attack - which is untrue. Providers use this port for TR-069 configuration, which is probably an integral part of your service. It may cause you problems if you try to close off this port! Only very specific devices with specific implementations are vulnerable. The vendors of the devices vulnerable to this attack are issuing a firmware fix to update it (which will take time).
If you’re a service provider
It looks like this attack was isolated to only two European service providers who deployed these particular devices. However, broadband devices aren’t perfect, and many contain all manner of different vulnerabilities. CDRouter’s test cases include nmap scanning, ssl security tests, firewall testing, and more - running your devices through vigorous security testing. Also, making sure you only use BBF.069 Certified devices can help you mitigate many issues with TR-069 implementations.
