Zero Trust: Best Practices for Preventing Misunderstandings and Mistakes
Zero Trust can be perplexing when it devolves into just another marketing buzzword. Let’s clarify what it really means.
Another first for 2016: at the weekend, another unprecedented event occurred which left significant numbers of Deutsche Telekom customers with difficulties accessing the internet or no internet access at all. As is now widely known, the outage was caused by a malicious attack – which was not entirely successful − rather than a technical fault. The attackers attempted to exploit the TR-069 protocol used on customer routers and add them to a bot net. 900,000 users are reported to have been affected. Nevertheless, the hack was unsuccessful on several levels. Firstly, the attackers made mistakes: The routers which were attacked were not affected by the targeted vulnerability. This meant that malicious packets inviting routers to download software from a compromised server were ineffective and attackers failed to expand their bot nets. Furthermore, for an exploit which was supposed to escape notice, the attackers’ efforts were splashed across almost every form of online and offline media in Germany and Europe. It’s also not quite true that nothing serious happened. Although the routers could not be manipulated through the vulnerability, they were not able to handle so many requests to a specific port. Security analysts have found that the routers began to disconnect from the network after receiving a high number of requests on this port and then blocked access completely. This led to internet and telephone faults for Deutsche Telekom customers.
After Deutsche Telekom blocked port 7547, the situation normalized. As the routers did not install the malicious software, the devices were functional after restarting. Now the forensics or mutual finger pointing – with reputations at risk in the age of social media – has begun. One thing is clear, the manufacturer has not implemented TR-069 properly, otherwise the routers would have not failed. While such failures have been previously accepted with a shrug, the situation is now clearly hostile. Bundesverband IT-Sicherheit e.V. (TeleTrusT) is demanding consistent application of existing laws and sanctions for poorly secured IT products, as it is critical that end device security is a priority issue. Many have been left wondering why a port which is used for remote maintenance has been left open to the internet. Quite simply – there is no alternative. The TR-069 protocol is used by telecoms providers to remotely configure customer hardware such as modems and routers. Obviously, the protocol needs access to device settings. And the developers of the protocol have at least made efforts to address security. All connections via TR-069 originate from the client, which is the router, modem, or set-top box. End devices contact the Auto-Configuration Server (ACS) at regular intervals to check whether an updated configuration has been provided by the manufacturer or operator. This means that an open port is not required.
One exception, however, is when the provider needs to initiate a connection for an urgent update or remote support. To do this, they send packets to a specific port which establishes a connection to the ACS. Experience here shows that remote access should only be allowed with very solid security mechanisms. The TR-069 specification only recommends SSL/TLS secure connections between providers and end devices. Whether this is implemented depends on the provider and manufacturer, and this is often not the case. Secondly, authentication between the end device and ACS is problematic and, as the present case shows, also depends on hardware manufacturer’s implementation. IT security analysts Checkpoint had only recently found and published a number of vulnerabilities.
An impressive list of the implications of compromised TR-069 access can be found on the protocol’s Wikipedia page under “Security”. Generally, TR-069 can be used for back door access for manipulating router configuration and devices behind the router on the local network. To sum up, blocking remote maintenance is not really feasible but due care needs to be taken to make all implementations absolutely watertight. Attacks such as last weekend’s which we can learn from without a major disaster are likely to be few and far between.