Protecting routers from ‘the perfect storm’

In my last blog post, I outlined the chipset security features that can protect modern broadband Customer Premises Equipment (CPE).

In this post, I’m going to focus on the Secure Boot functionality and why ISPs ca easily take advantage of it to mitigate a new class of growing threats. Specifically, there should be few things that scare broadband service providers more than their router population becoming infected with “persistent” malware.

“Persistent” means that the attacker remains present even after you reboot the device. To achieve its goal, the malware installs itself somewhere in FLASH (i.e. the local storage) while ensuring that it always gets reactivated after a reboot. A bit like the proverbial friend that overstays at your place and eats your food (the food being – in this case – the consumers’ personal data or their bandwidth).

The ‘perfect storm’

First, let’s look at the potential damage that persistent malware can do, with the help of a cautionary tale about Deutsche Telekom (DT). In November 2016, around 900,000 DT internet subscribers were taken offline when three models of DT routers were attacked by a variant of the infamous Mirai malware. DT acted swiftly and pushed firmware updates that fixed the vulnerability: after a simple reboot, the router was clean and protected, and the subscribers’ service was restored.

Consider the implications though, if the malware had managed to gain persistence and further entrenched itself by disabling the remote management update capabilities, including the ability for the ISP to push updates. Think of your “friend” not just overstaying on your couch, but also changing the locks of your front door while you were out for a walk.

This scenario would be a “perfect storm” for the unlucky broadband service provider. Unlikely to happen?  Not really. There are indications that malware is evolving in that direction QSnatch is such an example.  It targeted a certain brand of Network Attached Storage devices and prevented the manufacturer to remotely push firmware security updates.

Recovering from similar infections has often required a full factory reset or even a hardware swap. If we put the cost at $40 per CPE, just the cost to replace the CPE would have cost DT in the example above $36 million. Add to this the expected spike in support calls, technician visits for customers who can’t manage re-installing the CPE themselves, refunds for periods of lost service, unavoidable increase customer churn, and plummeting subscriber satisfaction scores. Recovering (and even surviving) from such a ‘perfect storm’ would be difficult for any broadband operator.

Using the router’s Secure Boot function to ensure recoverability

So how can ISPs malware-proof their CPE, ensuring that only their legitimate firmware and software can be installed, and that any malicious modifications are detected and efficiently remediated?

Continuing the analogy with your (by now) former “friend”, you may consider ensuring that the lock in your front door cannot be changed in the first place.

The Secure Boot feature in the CPE chipset is such a lock – when it starts,  the chipset reads any new software installed on the router’s FLASH memory but will only execute it if it has been authorized (signed) using a recognized key. More importantly, the chipset cannot be convinced to use another key for the check (e.g. one controlled by the malware) because the verification key was written into the One Time Programmable memory during manufacturing.

Secure Boot is a prime example of device integrity protection enabled by a hardware root-of-trust. With it, the ISP has a strong guarantee that only authorized software can run on the router, and such authorized software always includes all the logic that allows the ISP to manage the device. The risk of an entire fleet of routers that cuts its ties with the ISP’s control tower is therefore drastically reduced.

However, Secure Boot is not the silver bullet that makes a device secure. Rogue software may still make it onto the device through vulnerabilities in the application software. But it won’t be able to install itself persistently. Therefore, the infection can’t take hold, and the ISP won’t be locked-out of the CPE, even if a “perfect storm” attack does occur.

Not all Secure Boot solutions are created equal

Secure Boot is a simple and effective concept. It should not come as a surprise then that it is always listed in  IoT security guidelines developed across industries (e.g. in ETSI EN 303 645, which underpins cybersecurity label initiatives for consumer devices in Singapore and is expected to also be adopted in the EU).

Secure Boot is not a point solution. Broadband service providers need to be sure their signing keys are securely stored, backed up, managed, accessed, used (in Code Signing ceremonies, or as part of secured CI/CD pipelines) and possibly revoked securely throughout the routers’ lifetime. Also, the configuration of the device and the implementation of the software need to be vetted and be consistent across all their CPE suppliers.

Secure Boot is not something that can be downloaded with a software update. It needs to be designed, configured, and its “Trust Anchor” fused correctly, at manufacturing time, by taking advantage of the hardware security features available in most recent router chipsets.

While many CPE vendors offer Secure Boot, they may not provide the all-round protection that an ISP expects and needs, including access to the code signing keys should one of their vendors cease trading, the right infrastructure, compliancy programs such as ISO 27001:2013, and the wealth of expertise from cybersecurity companies that have worked in the field of embedded security for more than 20 years.

Spotting the spoofed devices

A modern and successful architecture for deploying new services to subscribers is data-driven and based on a combination of cloud services, mobile apps, and intelligent CPE. Data collected from the household is fed back to the operator by the CPE telemetry. The ISP’s backend infrastructure stores and analyzes that data. Based on its findings, the backend then orchestrates the CPE to perform the necessary services. In other words, a modern CPE device communicates with, and is tightly coupled to, the ISP’s backend. The backend trusts the CPE as if it was part of the ISP’s own infrastructure.

But what happens when the backend has misplaced that trust? What if an adversary has managed to impersonate the CPE?  I will cover these topics in my next blog.

Want to learn more?

Download our e-book: “Broadband CPE: An ISP’s biggest asset or its weakest link?” for more real-life CPE security case studies, plus additional information on Trust Anchors, the characteristics of secure key storage, and effective ways to implement code signing within a multi-vendor CPE strategy.