An Embedded Risk

Securing Internet of Things (IoT) devices can be difficult, but it is possible

Introduction

Until recently, companies making physical devices probably didn’t need to worry about hackers too much and so few had security assessments of their devices. Unless there was a financial impact of compromising a physical device, hackers were unlikely to try and even less likely to succeed with a physical device. However, times are changing and now hobbyist hackers are even cracking kid’s toys just for fun.

So what’s changed?

  • Hardware and radio have been demystified, and there are now many resources available explaining how to start reverse engineering physical devices and radio protocols. Almost all hacker conferences will include talks on hardware and radio, and there is real passion in the hacker community for such research.
  • Hardware tools are becoming more available. In the past, the tools needed to reverse engineer hardware were prohibitively expensive and only affordable for dedicated laboratories. The same tools now are not only cheaper but also widely available. For example, USB oscilloscopes can be bought for under £100, meaning hobbyists can afford them. The hacker community is also creating tools such as the GoodFET and JTAGulator, which allow attacks on components and interfaces.
  • Radio tools are becoming more available. For a long while, radio required expensive and complicated equipment, and a lot of signal processing knowledge. Then, software defined radio (SDR) meant that with expensive equipment, a range of frequencies could be communicated on far more easily. Now, the prices of SDR have dropped to around £30 for a basic device and software has reached the point where radio communications can be deciphered in a point and click interface.

The evidence of these changes is the wealth of research being published of people hacking their home routers, TV boxes, alarm units, cars, and even children’s toys.

What does this mean for companies?

Companies that produce or rebrand devices now need to assume that hackers, and not necessarily malicious hackers, will attempt to reverse engineer and modify their devices. The results may be blog posts, modifications, and even the creation of a subculture of people modifying their devices, which can all be great things. However, the flip side of people hacking devices is that some of those people may be malicious and be seeking to identify and exploit vulnerabilities, rather than modify the device. Furthermore, in MWR’s experience, the security of embedded devices is typically far behind that of full operating systems and so attackers are often successful in their efforts.

How do you secure an embedded device?

Securing embedded devices can be hard as there are multiple levels that need to be secured. However, the areas where MWR tend to find the most vulnerabilities are shown below.

Software:

At the end of the day, embedded devices are often a number of small processors/microcontrollers running software and as such, can be vulnerable to all the same software issues as computers. Worse still, embedded devices rarely have the sort of platform defences that can make exploiting traditional computers hard. MWR’s PinPadPwn research showed how software flaws in Chip&Pin payment terminals, which are well physically hardened, allowed exploitation and compromise of credit card data. Organisations should ensure that software on embedded devices is developed based on security best practices. A large number of embedded devices often run Linux or VXWorks, and so securely configuring the operating system can be just as important as on a desktop computer.

Debug connections:

A common attack surface on embedded devices is the debug interfaces to the chips. Often these are the serial port and the JTAG ports. Where the device runs Linux, serial ports often allow access to a root console, whilst JTAG ports can allow full read and write of memory, as well as debugging of code. Where possible, companies should ensure that debug functionality is disabled when it leaves the factory. Serial ports can often be disabled in software and most processors will have a fuse that can be blown to prevent JTAG access. However, some attacks have shown it is possible to “re-blow” the fuse and gain access.

Don’t trust inputs / outputs:

Another common attack is intercepting communications between chips on the device. These connections are typically unencrypted, and attackers can connect to the lines and both intercept and send messages to chips on the device. In one assessment, MWR intercepted communications between the master processor and the radio module, extracting ip addresses, ports, and credentials for the servers the device was contacting. Hardening can be difficult as components used in embedded devices are often too low powered to do effective encryption/decryption. Where possible, organisations should ensure that, for example, data is encrypted on the more powerful master processor and then just sent through other modules without them needing to decrypt it.
A related issue is that software should assume that inputs can be used as an attack vector. Even inputs where it is highly unlikely an attacker will communicate on that medium (i.e. GSM), if an attacker can connect directly to the connections between components they can attempt to trigger software vulnerabilities.

Secure Storage:

Another issue MWR often see is insecure storage of data, including the program data for the device. Data is typically stored on flash chips, and so attackers will attempt to compromise the data through either software vulnerabilities or by accessing the storage directly. Debug connections can allow reading from flash memory, or memory chips can be de-soldered and attached to a device to read the contents. Companies should look at using encrypted flash memory, or on-processor storage (which prevents an attacker from de-soldering the flash chips), and also ensure that debug connections are disabled. For sensitive information, organisations may look to using secure modules that do not allow access to the data itself (a SIM card is an example of a secure module).

Radio Communications:

A common assumption in the past was that attackers wouldn’t be able to intercept or modify radio communications. With SDR now readily available, this is no longer the case. MWR have successfully reverse engineered custom protocols that devices are using, leading to a compromise of data confidentiality and integrity, as devices often do not sufficiently verify the data they are receiving. Depending on the nature of the device, this can be a significant problem.

A common approach is to use a standard protocol such as wireless, Bluetooth, or ZigBee. However, organisations should be aware that all of these have implementation flaws and if not implemented correctly, can make attacker’s lives even easier as they can easily source equipment to communicate on these systems.

Organisations are recommended to distrust the communications layer and instead tunnel SSLencrypted traffic over it. MWR have assessed cases where companies implement their own encryption on their protocol and it has been found to be possible to break this custom encryption.

Physical Hardening:

Although often possible to bypass, physically hardening of devices can be a cheap and easy solution to make reverse engineering harder. This can be implemented when designing devices, for example by using “system on chip” processors instead of separate modules so that there are fewer communication lines to attack. Using chips that attach to the circuit board using Ball Grid Array (BGA) solder points can prevent lower skilled attackers from removing the chips and interacting with them with their equipment.

Another common approach is using anti-tamper resin / plastic in the device. This can be slowly dissolved or chipped away, but for certain situations, for example where the attacker can only easily acquire a single device, it may dissuade attacks.

Backend Systems:

Although not directly related to the embedded devices themselves, the security of backend systems that might communicate with the device is crucial. MWR have seen examples where the devices are believed to be “safe”, and so the same standards applied to other inputs to a system are not applied to communications from embedded devices. For example, a website might have been checked for code execution and SQL injection vulnerabilities, whilst the custom service the embedded device communicates with had not been so closely scrutinised.

Summary

Thanks to better availability of tools and information, embedded devices are now squarely within the crosshairs of both hobbyist hackers and malicious attackers. Companies need to assume that their devices will be looked at, and if the device may be a target for an attacker (for example processing financial information, information that may be used for billing, or may have privileged access to the companies or customer’s networks), that attention may be malicious.

 

 

Accreditations

As members of CHECK we are measured against high standards set by CESG for the services we provide to Her Majesty's Government.
We are certified in the ISO 9001 quality management system (QMS) in the UK, ensuring reliable delivery of our products and services.
We are certified to comply with ISO 14001 in the UK, an internationally accepted standard that outlines how to put an effective environmental management system in place.
MWR is certified to comply with ISO 27001 to help ensure our client information is managed securely.
As an Approved Scanning Vendor MWR are approved by PCI SSC to conduct external vulnerability scanning services to PCI DSS Requirement 11.2.2.
We are members of the Council of Registered Ethical Security Testers (CREST), an organisation serving the needs of the information security sector.
MWR is a supplier to the Crown Commercial Service (CCS), which provides commercial and procurement services to the UK public sector.
MWR is a Qualified Security Assessor, meaning we have been qualified by PCI to validate other organisation's adherence to PCI DSS.