TR-069: IoT Before It Was Cool!

It was first published in 2004 by the Broadband Forum. Most likely, you have a few devices in your home that use it on a daily basis. In case you’ve never heard of it before, here is the short version:

ISPs use TR-069 to manage their Customer Premises Equipment (CPE). The most common CPE devices are broadband gateways (e.g. a Wi-Fi router that provides internet access via DSL, Cable, LTE or WiMAX), set-top boxes and SIP phones. The counterpart on the ISP side is the Auto Configuration Server (ACS, no more telco-lingo from this point on, promise!). The ACS can set and query parameters on the CPE. In the TR-069 world a parameter is a setting on the device e.g. the password for the SIP server or a diagnostic value e.g. the signal-to-noise ratio on the radio interface.

A CPE either has the URL of the ACS hardcoded into the firmware or learns it via DHCP options. On first boot the CPE connects to the ACS in “bootstrap” mode. The ACS will then provision the device depending on the device type. What parameters are set during this part depend on the ISP. Some ISPs do a zero-touch provisioning via TR-069. This means that the customer must only plug in the CPE and the internet/phone connection is set up automatically. What happens in the background is that the parameters for the PPPoE or SIP credentials are set, firewall ACLs are set, device specific TR-069 credentials (connection request user/password) are set, accounts for remote assistance are added, a firmware update is scheduled etc.

TR-069 auto-provisioning is pretty interesting from a security point of view and probably worth a deep dive in a subsequent blog post. ISPs usually underestimate the risk involved. A common misconception is to assume that the CPE itself is somehow trusted and only trusted devices would talk to the ACS. In reality, an attacker can connect to the ACS and pretend to be another customer’s CPE in bootstrap mode (spoofing). In cases where zero-touch provisioning is implemented, and the ISP is not protected against spoofing attacks (e.g. by checking if the physical connection used for the connection is actually related to the customer), the attacker will get the SIP credentials or other interesting information like PPPoE credentials of random customers and can use them for fraudulent calls using premium numbers or more advanced attacks.

After bootstrap, all CPEs connect to the ACS periodically (e. g. every 24 hours) or on device boot. Here, the ACS has a chance to query and set parameters.TR-069 sessions are always initiated by the CPE.

For the sake of completeness: Usually, the ACS server is only accessible from within the ISP’s network (read: only subscribers can access it). If an ISP does not use TR-069 for managing CPEs right now, it probably uses SNMP (probably in connection with DOCSIS). It seems that TR-069 use is getting more common though.

While each CPE usually has a vendor specific TR-069 client implementation, the ACS solutions used by most ISPs are Nokia’s Motive Connected Device Platform (formerly called Motive Home Device Manager), Friendly Technologies, AVSystem and Axiros. If an attacker can find a serious vulnerability in the ACS server software, he/she can likely compromise all CPEs via deployment of malicious firmware.

CALL ME BACK? PLEASE?!!

If the ACS does not want to wait until the CPE connects again, it can send a connection request to the CPE. This works via a “Connection Request Server” HTTP server that listens on TCP port 7547 on the CPE. The ACS connects to this server and authenticates using a connection request user/password set during bootstrap.

From a TR-069 protocol view, the Connection Request Server is not a security risk. It can only be used to tell the CPE to connect to the ISP’s auto configuration server (ACS). But in the past, there have been various vulnerabilities in the implementation of the Connection Request Server:

Misfortune Cookie

The most widely known vulnerability is “Misfortune Cookie”, found by CheckPoint in 2014. It’s a memory corruption vulnerability in some ancient versions of Allego Software’s commercial HTTP server called RomPager. ZyXEL embedded RomPager into ZyNOS, their proprietary operating system for embedded systems and also some Linux based products. The supply chains for IoT devices are quite hard to follow, but it is likely that ZyXEL (or its sister company MitraStar) work as an OEM/ODM for various other vendors like TP-Link, Huawei, D-Link, ZTE, Edimax, etc. That explains why products from those vendors are vulnerable to “Misfortune Cookie” as well.

ROM-0 Vulnerability

Another vulnerability again affecting ZyXEL/MitraStar developed firmware is the “rom-0 vulnerability” also found in 2014. Again, Huawei, TP-Link, D-Link and ZTE products are affected as well. This is an information disclosure vulnerability. An attacker can download the device configuration including the admin password by requesting a file called “rom-0” via the webserver (e.g. http://IP:port/rom-0, exploit).

Both “Misfortune Cookie” and the “rom-0 vulnerability” are not specific to TR-069. ZyXEL just happens to use the same webserver code they used for the administration web interface of the device for the TR-069 Connection Request Server.

Newntpserver Vulnerability

In November 2016, another vulnerability affecting TR-069 Connection Request servers was discovered. A guy called “Kenzo2017” published a blog post regarding a vulnerability in one of the CPEs from the Irish ISP “Eir”, called “NewNTPServer vulnerability”. As it turns out, this command injection vulnerability again affects various devices from ZyXEL/MitraStar (you see the pattern?). Botnet herders quickly picked up the vulnerability and started exploiting devices worldwide, causing a bit of attention. What’s interesting about this vulnerability is that it exploits a command injection via a TR-064 command.

What Now?

ISPs should limit the attack surface on CPEs as much as possible by blocking all incoming connections from the internet. This is not just limited to the TR-069 Connection Request Server. Our research on HTTPS Certificate and SSH Key reuse has shown that millions of CPE devices also provide SSH access and HTTPS access via the internet.

Even if there are no known vulnerabilities in the TR-069 /HTTP/SNMP/[any component name here] server implementation of one CPE right now, attackers could find and exploit one tomorrow. Most CPEs are developed in pure C/C++ code that was probably never properly audited, scary vulnerabilities around every corner!

The firmware security analysis platform IoT Inspector detects the various vulnerabilities in IoT firmware, including the “Misfortune Cookie” vulnerabilities discussed above. IoT Inspector also detects various protocol implementations in uploaded firmware. This makes it easy to check which devices in your “IoT Zoo” could be affected by TR-064/TR-069 vulnerabilities.