Advertisement

Blog

Fighting Back Against Embedded System Attacks

If you are involved in the electronics supply chain and are unaware of security vulnerabilities in firmware, you are in for a rude awakening.

Attackers are becoming increasingly aware of how easy it is to hack code in the firmware of peripheral PC devices and embedded systems. Looking for lower-hanging fruit than locked-down PCs, servers, and smartphones, attackers are increasingly taking advantage of exploitable code in the firmware of a wide range of embedded computing devices. These might include printers, modems, motherboards, IP phones, cars or anything else that runs embedded computing apps, such as wearable technology.

Researchers and security experts have demonstrated how these attacks can be used to steal data, to seize control of electronic devices for malicious purposes (think of the implications for cars, planes, or public transportation), or for eavesdropping.

Making firmware more secure will require participation across the supply chain, including chip makers, motherboard makers, and other suppliers, as well as the OEMs. Success will also involve spending more money to make devices secure; that will be the subject of many future discussions. The supply chain implications and engineering required to address the problem will be complex, as well. In the meantime, here are some key points outlining what must be done.

Firming up on-chip firmware
Chip-level code must be engineered better. Open-source firmware should replace proprietary binary code in firmware, for example. Most of the basic code on chips is open-source, and embedded systems run on Linux. However, a lot of the top-layer code, such as the drivers, is not open-source.

Moving up the supply chain, the original device manufacturers (ODMs) that are putting the chips in their devices are adding their own non-open-source code on top of already not-so-great code. The OEMs are often left with unpatchable devices when a vulnerability is reported.

Firmware in embedded systems should thus be completely open-source, and OEMs should be able to fix it easily if a vulnerability is discovered. This, of course, means chip suppliers will have to invest more engineering dollars in fixing their firmware.

Adopting the remote update model
More often than not, embedded system OEMs are forced to recall products when vulnerabilities are exposed. Even if it is possible to install security patches remotely on things like modems, routers, and printers, doing so is usually too difficult for the non-expert. OEMs will thus increasingly need to adopt the PC model for automatic firmware updates, which are downloaded and installed in a transparent way to the end user when the device connects to the Internet.

A preventive shot of software
A potential protective measure is to add layers of software to firmware that can ward off attacks. Researchers at Red Balloon Security, a startup founded by Columbia University computer scientists, reported last summer that code added to firmware can detect and disable malicious code that might otherwise comprise a device.

For example, the researchers said they designed software that protects embedded systems once it is injected into firmware. In many ways, the code functions like traditional anti-malware software designed to detect and neutralize attacks. But the researchers said their software is supposedly unique, because it disables malicious code in a randomized way that is different each time it runs. This means — in theory, at least — that an attacker circumventing the protective code for one device would not be able to attack the same kind of device again in the same way, since the protective code would be different each time.

Look for other firmware anti-virus software in the near future, if it does not exist already. Hopefully, these products will be more effective than PC anti-virus and anti-malware software, which has a poor track record for firmware protection.

Better visibility
Risks assessment in general requires visibility, and that applies to assessing firmware vulnerabilities, as well. You may have a good visibility about firmware from your first-tier supplier, but what about your second-, third-, and even fourth-tier suppliers? It takes a single component with bad firmware to cause problems.

A case in point is when Dell had to report a malware infiltration of its servers. The bad code came from the motherboard, which Dell obviously procured from another supplier. But bad firmware code, as well as counterfeit devices, also could have shown up in devices sold to Dell's motherboard supplier. Dell might have prevented the security lapse and ensuing PR nightmare if it had better assessed this firmware beforehand.

Knowing where and how firmware might be vulnerable at the different stages in the supply chain is crucial. This knowledge and analysis should also be part of a general risk management strategy.

9 comments on “Fighting Back Against Embedded System Attacks

  1. t.alex
    February 13, 2014

    Take the case of Dell, for example, how would it possible to detect bad firmware code inside the motherboard before mass production?

  2. Daniel
    February 14, 2014

    “Firmware in embedded systems should thus be completely open-source, and OEMs should be able to fix it easily if a vulnerability is discovered. This, of course, means chip suppliers will have to invest more engineering dollars in fixing their firmware.”

    Bruce, I don't how far it's possible. Moreover, the entire business model has to be reworked inorder to make the codes open source

  3. Daniel
    February 14, 2014

    “Take the case of Dell, for example, how would it possible to detect bad firmware code inside the motherboard before mass production?”

    Alex, it's part of V & V (verification and Validation) during the testing and QA process before burning to the chip.

  4. Bruce Gain
    February 14, 2014

    Yes, verification processes do exist. But the main point I was trying to make is that the firmware code is an easy target for the bad guys who are learning about these security holes. It also does look like firmware needs to move to open source, despite the inevitable effects on the business model. But if open source will not work, what is the alternative?

  5. Hailey Lynne McKeefry
    February 15, 2014

    @t.alex: there are a number of techniques to discover malware that has been put into firmware by testing before sending out the products. The three main categories are:

    1) anamoly-based detection. In this approach, the malware detection program learns what normal behavior of a system looks like and compares it on an ongoing basis–sounding the alarm when the behavior is deemed abnormal. The downside of this approach is a high number of false alarms.

    2) Specification-based detection. Basically this compares a set of rules about what the program or application is supposed to do and compares it to what it is doing.

    3) Signature-based detection. This uses known malware signatures to try to identify malware (this is familar to anyone with a basic anti-malware on a PC).

    Malware gets increasigly sophisticated–and so detection techniques have to keep up. it isn't an easy game to win.

  6. Hailey Lynne McKeefry
    February 15, 2014

    @Bruce, I agree with you. Often to move the ball forward there's a fairly high up front cost… but not doing it in the long run will be even more detrimental.

  7. _hm
    February 15, 2014

    Yes, this is very desirable. But when you experience pressure for time to market and cost control, this is pretty difficult. May be some standard tools/technique help little bit.

  8. prabhakar_deosthali
    February 16, 2014

    I just fail to understand how a firmware can b eprone to malware attack. A “forware” is a kind of code which cannot be modified unlike the code that runs in some kind of RAM and is prone to be replaced or modified by the malware.

     

    So unless , at some point in the supply chain if unauthorised firmware enters into the product as a counterfeit part, then only such attack is possible, in my opinion

     

  9. Bruce Gain
    February 17, 2014

    This research paper serves as an excellent case study and tutorial on firmware attacks: http://ids.cs.columbia.edu/sites/default/files/ndss-2013.pdf

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.