Embedded device security is a topic that many will dismiss, in favor of more popular security concerns. I can understand this, to a certain extent, because mainstream press and information outlets often do not cover embedded security. They are focused on the more common threats, such as the latest Microsoft patches, network worm, Anti-Virus software, and social networking sites that have been hacked. While these are important stories to note, pay attention to, and react defensively, they do not cover all of the threats and associated risk for your organization. Embedded systems are in everyone’s network, and do things like route traffic, block packets, and in the control systems world, if Ethernet enabled, control critical infrastructure. Many believe that since the device is embedded, that no one would bother to attack it or take the time and effort to understand how it works. This is not always the case, in fact, by nature hackers are curious, and sometimes motivated by sheer curiosity (if we’re lucky).

There has been new research published on attacking embedded devices that has the potential to be much worse than the latest network work or XSS vulnerability (in my opinion anyhow). The first example comes from Graeme Neilson of Aura Software. Graeme gave a presentation at Ruxcon, a security conference held is Syndey, Australia, titled “Netscreen of the Dead: Developing A Trojaned Firmware for Juniper Netscreen Appliances”. He was able to reverse engineer firmware for the Juniper Netscreen firewalls and insert programs of his own choosing, manipulating the behavior of the firewall. So what, right? If we were to put our “evil hats” on for a few minutes and explore the evil things an attacker can do with this functionality, we might come up with a list like this:

1) Stealthily Modify The Configuration – If you have control of the firmware, you have the ability to load what is referred to by Graeme as “shadow configuration”. This configuration tells the device to behave in a certain way, but leaves no evidence that its happening. In the context of a firewall this means you can allow an external IP address full access through the firewall and/or mirror traffic from an interface to an outgoing data stream.

2) Persistent Infection – Embedded systems have a BIOS which acts similar to the one found in most PCs and servers. If you could infect the bootloader, you can then infect any subsequent firmware with you malicious programs. To put this into context, most will recommend that if you get infected with malware or viruses you should format your hard drive, re-install the operating system from clean media, and re-install all programs (Verifying that they are not trojaned). By infecting the boot loader, you can do all that but still be infected because the bootloader remains the same across OS and firmware upgrades (unless you are upgrading the bootloader itself).

3) Create Further Malware Delivery Mechanisms – It is conceivable that operators or administrators will access devices to manage them. In the case of a firewall, this typically means logging into the web GUI to make changes to firewall rules. A compromised device could contain malicious JavaScript or HTML of the attacker’s choosing, which then leads to the compromise of the operator’s workstation. This level of access is scary, as the operator most likely has access to other critical systems and data.

An additional feature of compromising an embedded device, would be collecting authentication credentials. This comes in two forms:

1) Usernames & Passwords – If there is one constant that I have found in many different networks, its that users re-use passwords. The sheer number of different passwords we have to keep memorized is frightening, so often people give in and use the same one for the firewall as they do for their domain login (for example). Collecting the usernames and passwords used to access devices could grant access to even more critical information.

2) “Secret” Keys – There are many protocols that require the use of a PSK, or Pre-Shared Key, as an authentication mechanism or encryption key. These can include SNMP, IPSec, RADIUS, and many others. Often many different devices will share the same key, for example maybe the read/write SNMP string is the same for all 10,000 devices in the network. Gaining access to this key now grants you control of every networking device in the environment.

The next embedded device security research I would like to highlight comes from none other than Felix “FX” Lindner, a security research with quite a bit of experience hacking embedded systems, and specifically Cisco devices. FX gave a presentation at the recent 25th Chaos Communications Congress titled “Cisco IOS attack and defense The State of the Art”. He has devised a way to exploit Cisco 1700 and 2600 series routers, based on PowerPC chips, in a reliable manner. He used similar techniques as Graeme Neilson and reverse engineered the firmware and crash dumps to create exploits. Of course, you will need a vulnerability in which to exploit to make this work. FX brought up several good points about the security of embedded network devices:

1) There Is No Reverse NAC – Network Access Control (NAC) attempts to verify that the client can connect to the network. There is no technology, to my knowledge, that can verify the network to the client. This means that clients will typically inherently trust the network and devices providing them access. For example, when you connect to a wireless router, do you have a way to verify that the firmware has not been modified to steal all of your credentials?

2) Embedded Systems Have Little OS Security Controls – Most embedded systems do not have a host-based intrusion prevention system, or any way to detect an attack against them. They usually are a shared memory environment with the concept of threads rather than processes. This means that taking over one thread gives you access to the entire operating system.

As Windows and UNIX computers become more difficult to attack due to advances in defensive technologies, attackers will continue to shift focus to embedded systems. As technology becomes smaller and just as critical as most servers in your environment, this will be a continuing concern for organizations. While the Zune faiure was due to programmer error, its a good example of how catastrophic the failure or compromise of an embedded system could be.

So, what can we do to defend our embedded systems? Stay tuned for next week’s blog post