In November, researchers from cybersecurity firm Invincea reported a vulnerability that could have allowed hackers to infect Belkin WeMo smart plugs with malware. The flaw was located in a configuration protocol that worked over the local area network and didn’t require any authentication.
In 2015, when researchers from vulnerability intelligence firm Rapid7 analyzed nine Internet-connected baby monitors, they found hardcoded credentials in four of them. Those backdoor accounts provided administrative access to the devices over the local network.
The use of hidden accounts, unauthenticated management protocols and hard-coded cryptographic keys or passwords is very common in the IoT and embedded device world. These issues, which amount to insecure default configurations, are frequently found not just in consumer products, but also in enterprise ones, including in firewalls and other security devices.
For example, just earlier this month researchers from SEC Consult warned that 80 models of professional Sony security cameras used primarily by companies and government agencies had backdoor accounts. And this is just one of the many cases reported this year.
These basic weaknesses don’t stem from insecure programming practices — which plenty of vendors are also guilty of — but from failing to take all types of attacks into consideration when designing their products. As a result they could more easily be eliminated than code-related vulnerabilities, which would require investments in developer training and security reviews.
This kind of insecure configurations could be easily avoided if device manufacturers would include LAN-based attacks in their threat modelling, but most of them still appear to treat local area networks as implicitly trusted environments, believing that attackers only target devices they can reach directly from the Internet.
Unfortunately that hasn’t been for many years. Cross-site request forgery (CSRF) attacks that hijack users’ browsers when they visit malicious websites and then use them to attack routers and other devices through the local network are now common.
Hackers also frequently infect laptops or phones with malware and then search for other systems on LANs that they can compromise to gain a permanent foothold — a practice known as lateral movement.
“This ‘trust the LAN’ mentality is very prevalent,” said Craig Young, principal security researcher at Tripwire. “The risk of CSRF or compromised smartphone apps is huge and nobody seems to get it. In many cases, the LAN doesn’t need vulnerabilities exposed because the devices don’t even require authentication from local devices.”
Just a few weeks ago Proofpoint uncovered a large scale malvertizing campaign that hacked people’s routers via CSRF. The attackers placed malicious ads onto ad networks used by popular sites and redirected their visitors to an web-based attack toolkit. The end goal was to scan their local networks through their browsers, identify their routers and attempt to compromise them.
The toolkit had digital fingerprints for 129 router models and exploits for 36 of them. For the rest it tried to use known default credentials to log in.
CSRF attacks are not the only possibility to attack LAN devices that are not exposed directly to the Internet. Malware running on computers or smartphones can also be used for this purpose.
Researchers from Kaspersky Lab recently found the first Android-based malware built to hack routers. Once installed on a phone, the malicious app performs a brute-force password guessing attack against the router’s admin web interface over the local network.
Many IoT vendors base their defense strategy on the fact that their devices will be installed behind routers instead of focusing on securing the devices themselves, said Brian Knopf, senior director of security research and IoT architect at Neustar. “This thinking from manufacturers is ignorant.”
Knopf, who previously worked in product security at Linksys, Belkin and Wink, gave the example of a 2013 vulnerability found in the Philips Hue bridge that controls smart light bulbs in homes or offices. The weakness stemmed from an insecure management protocol that used access tokens based on physical MAC addresses for authenticating commands.
The flaw was only exploitable over the LAN, so the researcher who found the issue wrote an exploit in Java that could be remotely delivered to a computer through the browser to gather local MAC addresses and use them to send rogue commands to the Philips bridge.
“The only thing that will change this backward thinking by the vendors is for there to be enforceable requirements with penalties tied to not doing them,” Knopf said. “Sure, there are IoT companies that do the right thing, but they are far outnumbered by those that don’t.”
One of the primary flaws across most connected devices is that they trust other devices on the local network by default, said Ted Harrington, executive partner at Independent Security Evaluators, the company that organizes the IoT hacking contest at the Def Con conference every year. “This is a violation of the fundamental secure design principle known as Assume Hostility or Trust Reluctance.”
Assuming trust instead of hostility is problematic for several reasons and the so-called stepping stone attacks are one of them, Harrington said. These are attacks where hackers compromise systems that already have some level of trust or access to their final target.
One such attack led to the 2013 data breach at Target that affected over 100 million customers. In that case attackers started by compromising a heating, ventilation and air conditioning (HVAC) system and that allowed them to eventually reach the company’s point-of-sale network.
Many small electronic devices don’t appear to have much value for attackers at first glance because they have low computational power. But that can be deceptive: Their compromise is less likely to be detected and they can be used to launch attacks against more valuable targets located on the same network.
“Without adequately considering the trust model on the local network, each additional device installed presents a new way to compromise the network,” Harrington said.
In 2016 there were approximately 100 reports of hardcoded or insecure default credentials in embedded devices, according to statistics from vulnerability intelligence firm Risk Based Security. Since 2013, there’ve been about 550 such weaknesses reported.
“Even before IoT became hugely popular, embedded devices had paltry security,” said Carsten Eiram, the chief research officer at Risk Based Security. “These devices are often 10 years behind normal software when it comes to code maturity from a security perspective. A big part of that is the lack of scrutiny they received in comparison.”
According to Eiram it’s hard to say whether some IoT devices are plagued by insecure configuration issues because their creators don’t account for local threats or because they’re clueless about security in general.
“I think the call to action for embedded device/IoT vendors is not so much: ‘You need to take security seriously by not viewing LAN-based attacks as minor’ as much as ‘You need to start caring about security; period.’,” Eiram said. “But should some vendors consider LAN-based attacks to be outside of their threat model, they certainly have to start including it.”
In Eiram’s experience some vendors don’t even consider the possibility of someone being able to discover their hardcoded passwords or to reverse-engineer their proprietary communications protocols.
It’s worrying that many companies don’t have policies for controlling who and under what circumstances can bring IoT devices into their networks, Eiram said. This creates a shadow IT problem where companies don’t even keep track of such devices, making it even more important for them be developed with security in mind, Eiram said.
Consumers face a similar problem in enforcing access controls on their networks, according to Alex Balan, chief security researcher at antivirus vendor Bitdefender. They put these new devices — from smart thermostats and sensors to Internet-connected doorbells and security cameras — into their homes without restricting who can access them. They then share their Wi-Fi passwords with friends and family members who bring their own potentially infected laptops and smartphones into their networks.
“You should ask yourself one simple question: ‘Can my home network be hacked ?’,” Balan said. “If the answer is yes, then ask yourself why do you have such weak security policies considering all the sensitive data inside your network — private photos, documents, files that you took home from work. If the answer is no then you’re either really awesome or severely misinformed.”
Until vendors start locking down their devices properly there are a few things you can do. First, make sure you secure your router to the best that you can, as it’s the gateway into your network and probably the most targeted type of embedded device. At the very least change its default admin password and try to change its default LAN IP address to make it harder for automated CSRF attacks.
If your router offers the option to create virtual LANs (VLANs) use this feature to isolate your IoT devices in their own network segment and join your computer or phone to that network only when you need to manage them. Many IoT devices can be managed through cloud-based services so aside from the initial set-up you don’t even need to access them over the local network.
If your router allows you to create a guest Wi-Fi network you can use that as a VLAN alternative for your IoT devices. A guest network is typically isolated from the main network and only provides Internet access to the devices connected to it. If you decide to do this, don’t use that same guest Wi-Fi network for people who visit your home.
Companies should monitor their networks for newly connected devices all the time so they can immediately remove those that haven’t been authorized. Approved IoT devices should be placed behind internal firewalls with strong access policies so they can’t be attacked by other computers on the network.