Introducing malicious code to deeply embedded systems that have been used in the field for years might seem far-fetched. However, today embedded systems often get equipped with remote access options for diagnostics or data mining purposes. Frequently, a system that was installed years ago and that was never specified for it is retrofitted with a gateway device or module with Internet connection. This, in essence, opens it up to any server, PC or smartphone on the Internet, making it a potential target for hackers.
Note that a remote attack from the Internet is not the only threat. If an attacker can physically install a device on-site, e.g. by connecting it to an internal CAN (Controller Area Network) bus of a construction machine, with enough patience and knowledge about the communication protocol gained over time, attacks may eventually be successful even without a connection to the Internet.
Over the last decade, bootloaders have become more common, too. Many embedded systems are based on microcontrollers with Flash memory and typically have at least a (primary) on-chip bootloader from the chip maker that can be used for reprogramming. The system manufacturers often add their own, secondary bootloader that allows programming via CAN, Ethernet or other communication interfaces already used in the system and conveniently accessible, to make sure they can more easily deploy updates and bug fixes for their systems.
If an attacker has the ability to monitor the firmware update process, there is a good chance that he can figure out what type of microcontroller is at the receiving end and which file formats and checksums are used. Many bootloaders out there are still completely unprotected. For some CAN applications following an industry standard, the bootloading process is included in the standard and well-documented, which can make attacks even easier.
What kind of code would an attacker introduce to the embedded system?
An attacker could try to replace not only the manufacturer’s application firmware but also the bootloader with one that only the hacker can use (e.g. requiring some specific keyword to unlock). The system would no longer be guaranteed to work and re-installing old code would be prohibited by the hacker’s bootloader.
At the lowest level, many microcontrollers have on-chip bootloader options that cannot be disabled. So even if after an attack re-programming via the network is not possible, a manufacturer reset/restore to repair the damage might be possible only when the component is physically removed and sent to the manufacturer. If several hundreds or even thousands of devices are affected, then this would become a quite costly recall for the manufacturer.
What kind of systems are possibly vulnerable?
If we look at the popularity of CAN and bootloading via CAN alone, then applications other than automotive using it are “everywhere”: industrial machinery, rail transport systems, all kinds of vehicles including construction or farming vehicles, maritime, wind farms, lifts/elevators. Most interesting for attackers are systems where with one infection they can access an entire “fleet” of embedded devices. So a PC that collects fleet data and possibly is involved in fleet diagnostics and updates would be a primary target.
If a hacker gets access to such a system, and if there are no further security levels, then it would be possible for him to replace update files, so that on the next update his malicious software gets installed instead of the intended update.
What can we do about it?
First, we have to carefully evaluate the true need to put a system online – especially if that has been in service for years and was not originally designed for it. There will likely be no strong security measures, so once an attacker passes the main entry – the entire system is at his command.
For any system supporting bootloading, we need to ensure that the bootloaders have strong enough security features, using authentication and encryption. If they do not have these features, consider updating the bootloader. Even for systems already installed this can be an option: instead of programming a regular application software one would program a special application that reprograms the bootloader.
There is no excuse for not having any security whatsoever, even when using a microcontroller that has only minimal performance! A minimal authentication process could use an obfuscated checksum, even an 8-bit microcontrollers can do that easily. Just as an example: on the calculated checksum execute a few XOR operations with values from fixed addresses within the code. Or, at some known/selected addresses, add the current value twice to the checksum. There are many possibilities for obfuscation that are very difficult to figure out if you do not have access to the algorithms used. This is not comparable to a full-blown security system with proper authentication and encryption, nevertheless, any hurdle is better than no hurdle.
If the communication channel used by the bootloader is CAN-based, then consider some of the techniques introduced by CANcrypt. CANcrypt supports the secret exchange of keys and authentication of communication at the CAN level. This allows a bootloader to only accept commands and files from an authorized transmitter in the first place.
Embedded systems come in many more varieties than PC-based systems and the differences are bigger, so most systems would require an individual, targeted attack. Therefore, a ransomware attack would most likely be limited to one class of devices or systems from one manufacturer. Nevertheless, the potential damage can be substantial.
If your embedded system supports firmware updates in the field, especially remotely, or has any sort of Internet connection, it is time for a worst-case security analysis: what would be the potential damage if an attacker gets access to your software update mechanism?
Olaf Pfeiffer studied technical computer science at the Cooperative University in Karlsruhe. He is one of the founders of the Embedded Systems Academy. Together with his partners, he wrote the books Embedded Networking with CAN and CANopen and Implementing Scalable CAN Security with CANcrypt. He is a regular speaker at the international CAN Conferences and other events. Olaf is chairman of the CiA 447 standardization group that defines how CANopen is used in special purpose vehicles (including police cars, taxis) and for automotive accessories.