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
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-17
The overlayfs implementation in the linux kernel did not properly validate with respect to user namespaces the setting of file capabilities on files in an underlying file system. Due to the combination of unprivileged user namespaces along with a patch carried in the Ubuntu kernel to allow unprivile...
PUBLISHED: 2021-04-17
Shiftfs, an out-of-tree stacking file system included in Ubuntu Linux kernels, did not properly handle faults occurring during copy_from_user() correctly. These could lead to either a double-free situation or memory not being freed at all. An attacker could use this to cause a denial of service (ker...
PUBLISHED: 2021-04-17
A command injection vulnerability has been reported to affect QTS and QuTS hero. If exploited, this vulnerability allows attackers to execute arbitrary commands in a compromised application. We have already fixed this vulnerability in the following versions: QTS Build 20210202 and later Q...
PUBLISHED: 2021-04-17
An SQL injection vulnerability has been reported to affect QNAP NAS running Multimedia Console or the Media Streaming add-on. If exploited, the vulnerability allows remote attackers to obtain application information. QNAP has already fixed this vulnerability in the following versions of Multimedia C...
PUBLISHED: 2021-04-16
jose-node-esm-runtime is an npm package which provides a number of cryptographic functions. In versions prior to 3.11.4 the AES_CBC_HMAC_SHA2 Algorithm (A128CBC-HS256, A192CBC-HS384, A256CBC-HS512) decryption would always execute both HMAC tag verification and CBC decryption, if either failed `JWEDe...