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.
More Security Insights
- 10 Steps to Cleaning up Active Directory
- The Active Directory Management and Security You've Always Dreamed of
- Innovations in Integration: Achieving Holistic Rapid Detection and Response
- COBOL in the Big Data Era: A Guide
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.