Thank you for your interest in our newsletters. You will receive an email shortly to confirm your subscription.
Dr David Chismon, Security Consultant
7 mins read
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.
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 F-Secure Consulting’s experience, the security of embedded devices is typically far behind that of full operating systems, so attackers are often successful in their efforts.
Securing embedded devices can be hard as there are multiple levels that need to be secured. However, the areas where F-Secure Consulting tends to find the most vulnerabilities are shown below.
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 defenses that can make exploiting traditional computers hard. F-Secure Consulting’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. Organizations 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.
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.
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, F-Secure Consulting 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, organizations 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.
Another issue F-Secure Consulting often sees 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, organizations may look to use secure modules that do not allow access to the data itself (a SIM card is an example of a secure module).
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. F-Secure Consulting has 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, organizations should be aware that all of these have implementation flaws, and if not implemented correctly, can make attackers’ lives even easier, as they can easily source equipment to communicate on these systems.
Organizations are recommended to distrust the communications layer and instead tunnel SSL encrypted traffic over it. F-Secure Consulting has assessed cases where companies implement their own encryption on their protocol, and it has been found to be possible to break this custom encryption.
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.
Although not directly related to the embedded devices themselves, the security of backend systems that might communicate with the device is crucial. F-Secure Consulting has 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 scrutinized.
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 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.