Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:00 AM
Terry Dunlap
Terry Dunlap
Connect Directly
E-Mail vvv

Unsecured IoT: 8 Ways Hackers Exploit Firmware Vulnerabilities

As new Internet of Things products enter the market, speed shouldn't trump concerns about security.

Microsoft made news recently at the annual Black Hat conference in Las Vegas, generating a lot of buzz about its discovery of a malicious Russian hacker group using common Internet of Things (IoT) devices to carry out widespread attacks on corporate networks.

Microsoft says hackers compromised several kinds of Internet-connected devices — including a voice-over-IP phone, a Wi-Fi office printer, and a video decoder — to gain access into enterprise networks. The attacks, according to Microsoft, were carried out by a group called Strontium — also known as Fancy Bear or APT28 — which has links to GRU, Russia's military intelligence agency.

There will be more than 14 billion IoT devices in use in homes and businesses by 2020, according to Gartner. Given Microsoft's news, now is the time to review security risks in firmware, the specific class of software that provides the low-level control for the hardware of an IoT device. Widely recognized as a pressing cybersecurity issue, firmware is a commonly unprotected attack surface that hackers use to get a foothold in a network. An unsecured IoT device is essentially an unlocked front door, which means that once attackers take over an IoT device, they can move laterally into a corporate network.

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "'Culture Eats Policy for Breakfast': Rethinking Security Awareness Training."

Hackers actively exploit weaknesses in IoT security not to attack the devices themselves, but as a jumping off point for all kinds of malicious behavior, which could include distributed denial-of-service attacks, malware distribution, spamming and phishing, click fraud, and credit card theft, among others. So, before a device breach leads to revenue loss, a lawsuit, damage to your company's reputation, or worse, it is important to be aware of the eight most common firmware vulnerabilities to make sure you haven't left the front door open to your network.

1. Unauthenticated access: One of the most common vulnerabilities in firmware, unauthenticated access allows threat actors to gain access to an IoT device, which makes it easy to exploit device data and any controls provided by it. 

2. Weak authentication: Threat actors can easily gain access to devices when the firmware has a weak authentication mechanism. These mechanisms can range from single-factor and password-based authentication to systems based on weak cryptographic algorithms that can be broken into with brute-force attacks.

3. Hidden backdoors: When it comes to firmware, hidden backdoors are a favorite hacker exploit Backdoors are intentional vulnerabilities that are planted into an embedded device to provide remote access to anyone with the "secret" authentication information. Although backdoors are potentially helpful for customer support, when they're discovered by malicious actors, they can have severe consequences. And hackers are great at finding them.

4. Password hashes: The firmware in most devices contains hard-coded passwords that users are unable to change or default passwords that users rarely change. Both result in devices that are relatively easy to exploit. In 2016, the Mirai botnet, which infected more than 2.5 million IoT devices around the world, leveraged default passwords in IoT devices to execute a DDoS attack that took down Netflix, Amazon, and The New York Times, among others. 

5. Encryption keys: When stored in a format that can be easily hacked, like variations of the Data Encryption Standard (DES), first introduced in the 1970s, encryption keys can present a huge problem for IoT security. Even though DES has been proven to be inadequate, it's still in use today. Hackers can exploit encryption keys to eavesdrop on communication, gain access to the device, or even create rogue devices that can perform malicious acts.

6. Buffer overflows: When coding firmware, problems can arise if the programmer uses insecure string-handling functions, which can lead to buffer overflows. Attackers spend a lot of time looking at the code within a device's software, trying to figure out how to cause erratic application behavior or crashes that can open a path to a security breach. Buffer overflows can allow hackers to remotely access devices and can be weaponized to create denial-of-service and code-injection attacks.

7. Open source code: Open source platforms and libraries enable the rapid development of sophisticated IoT products. However, because IoT devices frequently use third-party, open source components, which typically have unknown or undocumented sources, firmware is regularly left as an unprotected attack surface that is irresistible to hackers. Often, simply updating to the latest version of an open source platform will address this problem, yet many devices are released containing known vulnerabilities. 

8. Debugging services: Debugging information in beta versions of IoT devices equips developers with internal systems knowledge of a device. Unfortunately, debugging systems are often left in production devices, giving hackers access to the same inside knowledge of a device.

As companies quickly bring new IoT products to market, and enterprises move just as quickly to capitalize on the many benefits of IoT deployment, the prioritization of speed does not necessarily need to trump concerns about security.

The good news is that the most common IoT exploits outlined above are avoidable and can be remedied without any additional cost to the manufacturer. A good initial set of best practices when it comes to IoT security includes:

1. Upgrade the firmware on your IoT devices and change the default passwords.

2. Compile an inventory of IoT devices on your network so you have a complete picture of your risk exposure.

3. Contact the manufacturers of the IoT devices deployed on your network and ask if they’ve accounted for the common vulnerabilities outlined above. If not, demand that they implement secure coding practices in their firmware and IoT devices. 

Related Content:

Terry Dunlap is the Co-Founder and Chief Strategy Officer of ReFirm Labs, a provider of proactive IoT and firmware security solutions that empower both government agencies and Fortune 500 companies. A former teen hacker, Dunlap worked as a global network vulnerability ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Author
9/15/2019 | 3:19:46 AM
Firmware updates
With new legislations being passed and manufacturers taking security more seriously I do believe IoT devices will build basic security into their devices but they have the the expertise, research and technology to stay on top of cyber security attacks and threats for this security to provide complete protection.

There needs to be more. 
User Rank: Author
8/30/2019 | 12:02:37 PM
Re: VoIP and Printers
I recall from my early work with Voip the tech team amused themselves by downloading commical ring tones to unsuspecting users and their desktop phones.  Can you imagine the negative impact to any brand after an unauthorized action of a device in a home? in the workplace?  Service providers need to wiegh the risks of bad press or worse before deploying unverified devices.  
User Rank: Ninja
8/29/2019 | 1:24:21 PM
Re: A deeper resolve to the problem other than just patching
"since the apps or modules are outside of the kernel, then why not containerize the application so it does not affect the kernel or firmware"

This is really a good idea. Containers can isolate certain module so impact is minimized.
User Rank: Ninja
8/29/2019 | 1:22:30 PM
Re: A deeper resolve to the problem other than just patching
" most vendors don't encrypt firmware, but there is a methodology called HiTrust "

I think they should give a real thought how to encrypt the firmware. They should be able to keep updates coming  too.
User Rank: Ninja
8/29/2019 | 1:20:43 PM
Re: A deeper resolve to the problem other than just patching
"adding a password to the firmware is a good solution but any changes made to the firmware that is not part of their release"

I agree with this. However, as it is the case in all other system the firmware could still be compromised if we do not manage the password properly.
User Rank: Ninja
8/29/2019 | 1:08:07 PM
Re: A deeper resolve to the problem other than just patching
yes update the firmware whenever possible, but take it to another level just like the individuals from "Black-Hat" are doing, look into the binary and hex code to see if there is something there This makes sense. Manufacturers should keep their firmware up to date at all times. Like automated updates.
User Rank: Ninja
8/29/2019 | 1:05:43 PM
VoIP and Printers
We have known for long time that VoIP and printers are not designed security in mind, so it is not surprising that they were easily hacked.
User Rank: Ninja
8/27/2019 | 1:12:39 PM
A deeper resolve to the problem other than just patching
Where I do agree with you that there are numerous vulnerabilities and exploits that we need to address, I do think (much like the end-user) that the ways you mentioned only address the surface, I would say why not delve into the process if we are going to talk about it:
  • Firmware - I am not sure talking with the vendor is going to do anything about making a change, we need to put together a concerted effort where people and organizations from all over a saying the same thing but making it public (Similar to what Google is doing with "Project-X", yes update the firmware whenever possible, but take it to another level just like the individuals from "Black-Hat" are doing, look into the binary and hex code to see if there is something there
  • Unauthenticated access - adding a password to the firmware is a good solution but any changes made to the firmware that is not part of their release (by going to the web and verifying the firmware is at the correct revision level and use a SHA256 hash to verify it is the correct type
  • Authentication - if a user can access the physical device, then it is almost too late, but after a firmware flash, they can get to it from across the world, then that is something entirely different. We need to look into our NGFW (next-gen firewall) or NAC device to determine if the person accessing it is credible or not.
  • Password hashes - why doesn't the hash change randomly, it does not have to change every 30 seconds but within a week's time
  • Encryption keys - most vendors don't encrypt firmware, but there is a methodology called HiTrust so if the firmware does not come from a trusted source and the SHA256 hash has not been verified, then the upgrade process should not be applied. And if someone wanted to access the keys, the keys should have limited time or the number of times should be limited before using this key
  • Buffter-Overflows - this can be addressed with error-codes/handling and dumps that allow manufacturers to review the code at a later time
  • Debugging services - the user should be allowed to enable debugging services but there should be a finite amount of time it is to be used and if it is turned on, then it should be sent to the OEM (original equipment manufacturer)
  • Debugging transmission - the OEM should think about using IPv6 as part of their transmission process where information about the device is submitted in a secure environment using IPSec AES256 ESP/AH VPN connections using to transmit data back to the device in a secure form, anything outside of the local network or OEM that provides a notification before proceeding (similar to what NAC devices do)
  • Finally, since the apps or modules are outside of the kernel, then why not containerize the application so it does not affect the kernel or firmware (zone 0, or zone N+1), this could be an option.

COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.