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.

Vulnerabilities / Threats

12:04 PM

Hacking Firmware And Detecting Backdoors

How device manufacturers can limit critical vulnerability discovery, public disclosure, and customer fallout

As the major software vendors have worked diligently over the past decade to harden their operating systems, and critical flaws have become much harder to uncover, many hackers have been pursuing lower-hanging fruit on the vulnerability tree.

One of the perpetually lower-hanging fruits has been the firmware updates for practically any physical device (consumer or industrial) that contains some kind of processing capability and options for increasing functionality over time.

For as long as I can remember, hackers have been pulling apart firmware and hunting for bugs. It's a bit more difficult than looking for exploitable vulnerabilities within commercial desktop software products -- meaning that fuzzers aren't going to identify a slew of possible security bugs, and the researcher will often find themselves having to deal with odd assembly instructions that are proprietary to the devices for which the firmware is destined.

That said, more and more hackers are turning their hands to dissecting firmware destined for popular commercial products. It's not only convenient, but as Stuxnet has shown us already, such device-level flaws can be exploited during disruptive attacks and as end objectives in breaches.

Take, for example, last week's disclosure by CERT on TURCK's industrial control systems -- in particular, the presence of hard-coded accounts that can serve as backdoors to devices. The bug hunter, Ruben Santamarta, had developed an automated system for hacking firmware updates and also published at the same time a walk trough of how he identifies backdoors in firmware using automatic string analysis.

For TURCK and its customers, it was a deeply embarrassing and critical security flaw. Owners of the vulnerable systems now have to "patch" these devices with newly available firmware in order to remove the hard-coded accounts. The odds are pretty good that most devices simply won't be updated in the short-to-medium haul (if ever), despite the warning. Such is life in the industrial control system (ICS) field.

TURCK is not alone, however. Many devices, appliances, and ICS technologies have similarly critical flaws that can be rapidly identified through dissecting their firmware updates. From a hacker's perspective, while gaining hands-on-access to a particular device maybe difficult (if not impossible), assessing the firmware via updates on the vendors public website is often trivial.

Let me offer a few bullet points of advice to device manufacturers that may help to limit their future exposure to critical vulnerability discovery, embarrassing public disclosure, and customer dissatisfaction:

* Do not ever, repeat EVER, use hard-coded accounts, passwords, private keys, etc., within your products. They are trivial to detect and, once exposed, present an immediate and critical exploit vector for an attacker.

* Make your firmware updates difficult for noncustomers to obtain. For ICS, networking infrastructure components, and other manufacturing devices, the more effort expended in restricting access to firmware updates to only your legitimate customers, the less exposure you will have. Most hackers and security researchers investigating firmware are opportunistic and will go for the lowest-hanging fruit. If a competitor makes its firmware easier to obtain that yours, then it's likely it'll have itsfirmware dissected first.

* Sign and (when feasible) encrypt your firmware updates. Signing your firmware will make it more difficult for attackers to apply modified firmware to your devices -- assuming that the device is capable of verifying the signature of the package correctly. Encrypting the firmware makes it much more difficult for hackers to pull apart in the first place. Be careful, though -- there is a difference between encryption and encoding data (e.g., XOR encoding etc.); the latter can often be easily deduced.

* If the device is capable of being networked, ensure that it can also alert and log when firmware has been updated. While hard-coded accounts and other exploitable vulnerabilities may be the primary routes to compromise, a vector not to be forgotten is the installation of modified and fraudulent firmware updates -- especially in the context of malware and additional backdoors.

With a meteorological hat on, the forecast for manufacturers that release firmware updates to their products is scattered showers, followed by thunderstorms in the evening. As Santamarta has recently shown, there are many new, critical vulnerabilities waiting to be discovered in device firmware. His recent tutorial and release of automated analysis tools have gained a lot of attention -- and I'd advise TURCK and other device manufacturers to employ these techniques (and the additional advice above) when testing their products. This is something that can be easily added to internal QA testing processes or outsourced.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Stop Defending Everything
Kevin Kurzawa, Senior Information Security Auditor,  2/12/2020
Small Business Security: 5 Tips on How and Where to Start
Mike Puglia, Chief Strategy Officer at Kaseya,  2/13/2020
5 Common Errors That Allow Attackers to Go Undetected
Matt Middleton-Leal, General Manager and Chief Security Strategist, Netwrix,  2/12/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
How Enterprises Are Developing and Maintaining Secure Applications
How Enterprises Are Developing and Maintaining Secure Applications
The concept of application security is well known, but application security testing and remediation processes remain unbalanced. Most organizations are confident in their approach to AppSec, although others seem to have no approach at all. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-02-19
PyYAML 5.1 through 5.1.2 has insufficient restrictions on the load and load_all functions because of a class deserialization issue, e.g., Popen is a class in the subprocess module. NOTE: this issue exists because of an incomplete fix for CVE-2017-18342.
PUBLISHED: 2020-02-19
In ruamel.yaml through 0.16.7, the load method allows remote code execution if the application calls this method with an untrusted argument. In other words, this issue affects developers who are unaware of the need to use methods such as safe_load in these use cases.
PUBLISHED: 2020-02-19
A vulnerability in the Cisco ASA that could allow a remote attacker to successfully authenticate using the Cisco AnyConnect VPN client if the Secondary Authentication type is LDAP and the password is left blank, providing the primary credentials are correct. The vulnerabilities is due to improper in...
PUBLISHED: 2020-02-19
A vulnerability in Cisco Unified Communications Manager could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack on the affected software. The vulnerabilities is due to improper input validation of certain parameters passed to the affected software. An attacker ...
PUBLISHED: 2020-02-19
An issue was discovered in OpenStack Nova before 18.2.4, 19.x before 19.1.0, and 20.x before 20.1.0. It can leak consoleauth tokens into log files. An attacker with read access to the service's logs may obtain tokens used for console access. All Nova setups using novncproxy are affected. This is rel...