Vulnerabilities / Threats
5/30/2013
12:04 PM
Gunter Ollmann
Gunter Ollmann
Commentary
Connect Directly
RSS
E-Mail
50%
50%
Repost This

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.

Gunter Ollmann serves as CTO for IOActive Inc. where he is responsible for the strategic vision of the security services portfolio, driving new research areas and bringing new services to market. With over two decades in the information security arena, Gunter has stared down ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web