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.