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

5/30/2013
12:04 PM
Commentary
Commentary
Commentary
50%
50%

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
Comments
Newest First  |  Oldest First  |  Threaded View
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16772
PUBLISHED: 2019-12-07
The serialize-to-js NPM package before version 3.0.1 is vulnerable to Cross-site Scripting (XSS). It does not properly mitigate against unsafe characters in serialized regular expressions. This vulnerability is not affected on Node.js environment since Node.js's implementation of RegExp.prototype.to...
CVE-2019-9464
PUBLISHED: 2019-12-06
In various functions of RecentLocationApps.java, DevicePolicyManagerService.java, and RecognitionService.java, there is an incorrect warning indicating an app accessed the user's location. This could dissolve the trust in the platform's permission system, with no additional execution privileges need...
CVE-2019-2220
PUBLISHED: 2019-12-06
In checkOperation of AppOpsService.java, there is a possible bypass of user interaction requirements due to mishandling application suspend. This could lead to local information disclosure no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVers...
CVE-2019-2221
PUBLISHED: 2019-12-06
In hasActivityInVisibleTask of WindowProcessController.java there?s a possible bypass of user interaction requirements due to incorrect handling of top activities in INITIALIZING state. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction ...
CVE-2019-2222
PUBLISHED: 2019-12-06
n ihevcd_parse_slice_data of ihevcd_parse_slice.c, there is a possible out of bounds write due to a missing bounds check. This could lead to remote code execution with no additional execution privileges needed. User interaction is needed for exploitation.Product: AndroidVersions: Android-8.0 Android...