Every enterprise with teleworkers should be worried about home network security, as evidenced by the recent Black Hat USA 2014 conference. In a breakout session, Jonathan Spring and Paul Vixie presented a briefing titled “Abuse of Customer Premise Equipment (CPE) Devices and Recommended Fixes.” Here, the term refers to network equipment installed in home and small-business environments. The briefing focused on cable and DSL modems but also included home routers, Wi-Fi access points and devices with specific, limited functionality.
This presentation comes at an opportune moment, as our industry has seen increasingly more public disclosures of vulnerabilities in CPE devices and more campaigns to exploit them. Our industry often focuses on the needs of large institutions and network operations, while those “little plastic boxes” (LPBs), in the words of Vixie, receive comparatively little attention. That needs to change.
Like it or not, those LPBs are a part of your enterprise network. They arrived as an underappreciated aspect of teleworking. For instance, LPBs are often the first and last stops for the Internet traffic of your remote employees; they often mediate your communication with your customers because they’re working from home, too.
Compromised LPBs can provide access to the communication channel that is second only to malware installed directly on the hosts. Their position in the communication channel gives them the capacity to execute Man-in-the-Middle (MitM) attacks on secure communications. They also provide a collection of resources that adversaries can use to execute or amplify distributed attacks.
As long as they work, few LPB owners pay much attention to them, allowing a well-executed attack to essentially go unnoticed forever. Each LPB has few resources, but the Internet contains millions of them. Considered in aggregate, they present an intimidating capability. The scope of the problem is such that Spring and Vixie refer to it as a public health hazard for the Internet.
Threat
This is not a theoretical discussion. The vulnerabilities are real, as are the exploitation campaigns. Those of you who follow the InfoSec news will recognize the following examples:
Carna Botnet
Perhaps the best-known CPE exploitation campaign was reported in 2012 — by the perpetrator. Apparently, no one publicly noted the campaign while it was progressing. The perpetrator published a report describing the campaign, in which the botnet employed over 420,000 individual infections. In the report, the author remarked that a large percentage of the unsecured devices bore the hallmarks of broadband modems, network routers and other devices with embedded operating systems that typically aren’t intended to be exposed to the outside world.
It is important to note that the report indicates the campaign tools could tell that other unauthorized software was also running in thousands of devices. Specifically, the campaign tools detected a distributed denial-of-service (DDoS) application known as Aidra on about 30,000 of the devices compromised by the campaign.
Further, the report claims that the campaign infected about 100,000 hosts in the first 24 hours of the operation. Consider the resources that 100,000 hosts could bring to bear against your network. Even as LPBs on DSL and cable lines, 100,000 of them represents a noticeable threat, just from DDoS concerns.
The Moon
This unlikely threat surfaced in February 2014 when a bizarre attack infected Linksys routers with self-replicating malware in a worm attack called The Moon. This malware infects a variety of consumer-grade Linksys routers and exploits a vulnerability that allows it to slip shell commands through the HTTP interface to take over the router. The malware targets certain Linksys models that are commonly deployed in small-office/home-office environments.
This campaign presents two obvious peculiarities. First, according to available reports, it doesn’t do anything particularly nefarious. It spreads and infects new hosts, but that’s about it. Once it controls a device, it often changes nothing. The modifications it does make tend to be benign, such as pointing the device’s domain name system resolver to Google’s public name resolvers.
Further, this campaign exhibits “peculiar specificity” in the subnets that it scans for infectible hosts. The executable holds a hard-coded list of dozens of subnets that it will scan. The list appears to focus on last-mile Internet service providers (ISPs), such as Cox, Comcast, Time Warner Cable, Shaw and RCN. Thus, it seems to seek the subnets most likely to host quantities of consumer-grade CPE. Technically, that’s not peculiar — it’s just smart.
Considering those points, this incident looks like testing or validation of some experimental threat. Perhaps it’s a proof of concept to accumulate sensor data and calibrate further development. Luckily, a mistake in the malware made it noticeable to an ISP, and there was a chance to review and analyze it.
Operation GHOST CLICK
In 2011, the FBI published “DNS Malware: Is Your Computer Infected?,” describing an advertising fraud malware campaign called Operation GHOST CLICK. The malware infected LPBs and changed their DNS settings to redirect Web requests to malicious servers. Controlling the device, the attack affects all users “behind” that LPB. The malicious servers used the requests to execute advertising click fraud for revenue. Luckily, the malware appears only to have used the DNS redirection technique for click fraud. They could have done much worse, as the next example shows.
Polish Banking Attack
Finally, CERT Polska reported a large-scale redirection attack on home routers for financial theft. Researchers noticed this campaign due to e-banking site modifications observed on iPhones. This attack also involved changing the LPB’s DNS settings. The altered settings sent users to malicious servers that monitored the traffic to identify e-banking transactions; they then rewrote the transactions to steal the users’ credentials.
The malicious servers terminated the TLS/SSL connection before it reached the user. Adversaries then had access to the plain text traffic and could rewrite nearly anything in the transaction. For example, the attack modifies traffic to display false URL information in the browser. If the “hoax” succeeds, after the user enters his or her credentials into the hoax website, the attackers have access to them.
Modern Implications for Network Security
If the current situation provides any guide, the Internet of Things (IoT) will likely worsen the situation because most vendors and device owners don’t have their eye on the ball. LPBs are already everywhere, so imagine how many more vulnerable devices are waiting in the wings as the IoT starts to take off — this isn’t even to mention smartphones.
Cost constraints present one problem. Limiting unit costs, many of these devices have few computing resources. For instance, many simply cannot reasonably provide secure communications. This issue applies more to the IoT than CPE equipment, though. On the CPE side, the devices tend to have somewhat more capable hardware, but costs limit the firmware capability.
A second problem relates to the variety of devices available with Internet capability these days. Consider home security and automation systems controllable with a smartphone or over the Internet. They suffer from many of the same issues as the LPBs. Even if you use good passwords, did your vendor intentionally include a back door? Is your vendor diligent about finding and fixing vulnerabilities, notifying customers and distributing the fixes?
At Black Hat USA 2014, Jesus Molina described some of these possibilities in a presentation titled “Learn How to Control Every Room at a Luxury Hotel Remotely: The Dangers of Insecure Home Automation Deployment.” The talk’s essential message was that vulnerabilities in automation systems deployed by a luxury hotel allowed for the impersonation of other rooms and guests.
Private labeling means the same vulnerability can affect large numbers of models, even from different manufacturers. Inside the LPB, they are all the same device with the same “firmware” (except for the logos, company names, etc.). Looking to the positive, though, that means one set of infrastructure updates could take care of all of them.
Attacks Enabled
Beyond the attacks discussed above, adversaries can use the open DNS resolvers in many of these devices to originate or amplify DNS-based DDoS attacks. The LPB must only originate a 60-byte DNS query. Using EDNS0, however, the responses are hundreds or thousands of bytes each. The LPBs don’t run that fast, but hundreds or thousands of them can still produce large volumes of traffic.
The LPBs could also participate in spam origination. They have few resources, but they are often enough to compose and send messages (slowly), usually through some third-party open Simple Mail Transfer Protocol relay. Having stolen the user’s credentials, it could even send these messages through the user’s email account.
MitM attacks probably present the greatest threat, though. The Polish e-banking attack illustrates this threat quite well. The position of the LPB in the connection allowed the adversaries to inject malware into the session and eliminate the Secure Sockets Layer/Transport Layer Security protection, enabling user credential theft.
This threat highlights the enterprise InfoSec risk. LPB malware can steal banking credentials and may be able to steal your teleworkers’ corporate network credentials. Using VPNs and other forms of encrypted sessions can close this vector, but the LPB gets the first crack at the traffic. This gives the adversary a wide latitude in attack techniques.
We all know that software will always have bugs and vulnerabilities. The firmware in the LPBs suffers as surely as any other software. However, LPBs have the following two additional burdens:
Device Management and Monitoring
Most LPBs are managed by people with little to no training who have less time to learn how to keep their systems safe and secure: homeowners. Most homeowners turn the device on, configure it based on the quick-start guide and ignore it until it stops working. Then, the homeowner turns it off and back on. If traffic flows, all is well; if not, homeowners may wrestle with the ISP and vendor customer support. Eventually, if all else fails, they buy another device.
Many people managing LPBs know only what the device manual says about things such as IP addresses, subnet masks and MAC addresses. If traffic moves, they have no way to tell whether things have gone wrong if they look at the configuration settings. They remain blissfully unaware of InfoSec best practices and are completely in the dark as to the ramifications of some of the configuration settings offered by the devices. They have lives, and they like it that way.
Firmware Updates
Even assuming there are capable operators managing the LPBs, manufacturers often leave the operator holding the bag. Many older devices offer no way to update their firmware. Even for newer devices that could accept updates, vendors (ISPs) often lock the device, preventing the homeowner from even trying to manage it. Vendors that do produce updates often offer only fully manual update methods. The methods and their instructions tend to be terribly scary to busy parents trying to keep the Internet working so their kids can finish their homework.
However, even vendors offering manual update functions may never produce any updates; they usually stop producing updates long before the last one goes to that great recycling center in the sky. Even if they produced an update, the announcement rarely reaches a harried homeowner. Sometimes, the bag is empty — or hidden.
Finally, even the updates vendors provide can be very suspect. According to IT World, a study found firmware to be plagued by poor encryption and back doors. In one case, a firmware update in the past year contained a 10-year-old Linux kernel. Adding insult to injury, according to Ars Technica, a vendor produced a firmware update after public furor about an open back door in the firmware. However, the update did not eliminate the back door; instead, the vendor tried to leave the back door there but hid it. That is not acting in good faith.
Suggestions for Improvement
Now that we’ve looked at the risks and breakdowns, what can we do to improve the situation? It seems obvious that liability will end up playing a role in the solutions. It could be regulatory, civil or criminal liability, or liability to a body, such as Underwriter’s Labs or the Computer and Communications Industry Association. It could also simply be liability in the court of public opinion, though current structures haven’t had the effects we would have liked. Obviously, though, society needs to incentivize the vendors to do better, and disincentivize them from leaving security issues hanging.
First, the industry must clean up some fundamental failings. The vendors must ensure device configurations default to “as secure as possible” settings, such as disabling remote device configuration by default. Most modern devices already do a decent job at this. Vendors must also work harder to make secure configuration of the devices easier for mom-and-pop operators to manage.
Vendors must completely eliminate all back doors and all default administrative accounts and passwords that cannot be changed or removed from the devices. As noted above, some vendors think that back doors are such a good idea that they’ll try to hide them rather than removing them when caught.
The industry and vendors must attain an awareness of the security implications of their products and their product development methods. We must find ways to narrow the adversaries’ window of opportunity to exploit vulnerabilities that end up in products. An easy — and expensive — choice would be limited lifetime products that simply refuse to continue working after a period. Spring and Vixie mentioned this option in their briefing. Dan Geer also mentioned it in his keynote speech, “Cybersecurity as Realpolitik.”
This seems destined to produce customer discontent when discussing things the homeowner typically purchases directly, such as cable or DSL routers; it might work more smoothly for equipment owned by ISPs, such as cable and DSL modems. However, this looks like vendors are accosting their users due to their inability to produce secure products. That said, if the price of those devices drops enough, the fallout might be negligible.
On the other side, creating automatically-updating products leaves vendors with a pile of expenses they don’t currently suffer. This obviously pushes up prices, which neither vendors nor customers will love. The following are among the extra expenses for the vendors:
- Identification of vulnerabilities
- Correction of vulnerabilities, plus testing and production of new firmware images
- Distribution of updated firmware images
- Addition of secure update capabilities to the device firmware and maintenance of that added code
- Maintenance of a secure automatic update infrastructure
These expenses could potentially drive smaller operations out of the business completely if pushed fully onto their shoulders. However, they could also offer an opportunity for a company or industry body to provide the distribution infrastructure necessary if some agency comes along that requires automatic updates.
The security of our digital information requires that we narrow the attackers’ window of opportunity. Either these devices must leave service often enough, or they must receive continuous, automatic updates, like Microsoft’s Windows, Apple’s Mac OS and Adobe’s Flash and Reader — and for the same reasons.
Spring and Vixie also recommended that all LPBs enforce source address validation. In other words, they pass traffic only for specific devices, similar to how Bluetooth devices must be “paired” before they will operate together. Many LPBs already have the capability to allow only specific MAC addresses, but the configuration of those options needs to be much more straightforward.
Finally, they recommend what might be called “forced open sourcing” for products abandoned by a vendor. This approach holds potential value but opens more than one can of worms. For example, the legal definition of “product abandonment” might require modifications to balance owner security with the intellectual property rights of the vendor.
Further, open sourcing the firmware entails more than many would suspect. Obviously, to be able to find and fix vulnerabilities, the raw source code of the firmware must be available. By itself, that can present legal challenges involving the vendor’s intellectual property and often other vendors’ intellectual property, as well. The problem gets sticky before that, though: Having the raw source code only helps those who also have access to the necessary build infrastructure. In order to produce an update, one must possess the firmware source code and the entire tool chain necessary to compile, link, locate and package the update. In most cases, this process usually drags in the legal departments of several more vendors.
Conclusion
Home network security presents challenges that are as important as those found in enterprises. Weak home network security can affect the owners and operators of all the devices in the home network. It can also compromise many measures aimed at protecting the enterprise network by allowing the adversary to gain unwarranted privileges in the home network and its hosts. The problems presented by CPE can be every bit as challenging as those presented by malware targeting desktops and servers. Correcting the situation of vulnerabilities and firmware updates will take time to fund, implement and deliver, so you must begin taking steps as soon as possible to get the effort off the ground.
Additional Reading
The Black Hat USA 2014 conference offered several other briefings and round-table discussions on related topics. Unfortunately, the Black Hat website does not provide copies of the papers or presentations. They may be included in the videos that the BlackHat organizers sell.
- “Breaking the Security of Physical Devices,” by Silvia Cesare
- “Network Attached Shell: N.A.S.T.Y. Systems That Store Network Accessible Shells,” by Jakob Holcomb
- “Medical Devices Roundtable: Is There a Doctor in the House? Security and Privacy in the Medical World,” by Jay Radcliffe
The Black Hat site does offer the briefing slideshow and a PDF file of the paper for “Smart Nest Thermostat: A Smart Spy in Your Home,” by Yier Jin, Grant Hernandez and Daniel Buentello.
Finally, here are a few papers from venues other than Black Hat:
Research Technologist, IBM Security X-Force