Overview
Devices are becoming increasingly computerized and networked. That is mildly newsworthy. Most of these devices have a long history of not being computerized or networked. Once again, only mildly newsworthy. Some of the companies have limited background in designing computerized and networked devices, which is not newsworthy in any context.
However – If security researchers compromise a Jeep and disconnect the brakes on a moving vehicle, or changes the dosage on a medical infusion pump – that is wildly newsworthy. Newsworthy in the sense that by connecting the dots above, we now have systems used by millions of people that represent a previously unknown and very real risk of injury and death.
Designing secure embedded systems is complex and challenging, and requires at least some level of capability and comprehension of the system level risks. A level of capability that many companies/industries have proven they do not have. Lets examine some of these cases.
Operational Issues Driving Bad Security
System security is a feature of a system as a whole, and as such it is not easily distributed to the individual pieces of a system. When this is coupled with the modern practice of subcontracting out much of the design into subsystems, this often means that the security of the system is either defined poorly or not at all within these subsystems. This should logically shift the responsibility of security validation to the systems integrator, but often does not since the system integrator does have an in-depth understanding of the individual subsystems. Essentially, as systems are further subdivided the ability to develop and validate an effective security architecture becomes increasingly difficult.
A secondary aspect of this problem is that subsystems are defined in terms of what they are supposed to do – feature requirements. Security requirements express what the systems is supposed to prevent or what it is supposed to not do. This negative aspect of security requirements makes security much more difficult to define and even more difficult to validate. As a result security requirements are not a good mechanism to implement system-level security.
The third and last aspect of this problem is that developing a secure system is a process that incorporates threat modeling, attack models, and security domain modeling – which ultimately drive requirements and validation. Without this level of integration into the development process, effective security cannot happen.
Designing secure embedded systems is complex and challenging, and requires at least some level of capability and comprehension of the system level risks — a level of capability that many companies/industries have proven they do not have.
Device Compromises in the News
There have been a number of well publicized security compromises in the last few years, which are increasingly dramatic and applicable to the public at large. Many of these compromises are presented at conferences dedicated to security, such as the Blackhat Conference and the DefCon Conference (both held in late summer).
This association has resulted in some interesting aspects of device security compromises. The most significant is that since these compromises are the presented at non-academic conferences, the demonstration and illustration of them are increasingly dramatic to garner more attention. A secondary aspect is that many of these compromises are made public early in the summer to build interest before the conferences. This is not particularly relevant, but interesting.
2014 Jeep Compromise (Blackhat 2015 Talk)
In July 2015, a pair of security researchers went public with a compromise against a 2014 Jeep Cherokee that allowed them to get GPS location, disable brakes, disable the transmission, and affect steering. In addition, they were able to control the radio, wipers, seat heater, AC, and headlights.
All attacks took place through the built-in cellular radio data connection. The root compromise was based on the ability to telnet (with no password) into a D-Bus service from the cellular interface, allowing commands to be sent to any servers on the D-Bus. One of those servers happened to be the CAN bus processor, which has access to all of the computerized devices in the vehicle including the engine, transmission, braking system, and steering.
The secondary issues that allowed complete compromise of the system include a lack of system-level access controls along security domain boundaries. Or to put it bluntly – allowing the entertainment system the ability to disable critical systems like brakes or steering is a bad practice and potentially dangerous. Since this same system (UConnect) is used in a large number of Chrysler, Plymouth, Dodge, Mercedes, and Jeep vehicles, many of these security vulnerabilities are applicable to any vehicles that also use UConnect.
The overall risk this compromise represents is that an attacker can take control of an entire class of vehicle and track the vehicle, disable the vehicle or precipitate a high speed accident with the vehicle, from anywhere via a cellular network. Collectively these represent a threat to privacy, personal injury or death.
Brinks CompuSafe Galileo Compromise (DefCon 2015 Talk)
The Brinks CompuSafe is a computerized safe with a touch screen that allows multiple people to deposit money, and it will track the deposits, enabling tracking and accountability. The unfortunate reality is that it is based on WindowsXP, and it has an external exposed USB port that was fully functional (including support for mouse, keyboard and storage). In combination with a user interface-bypass attack, administrative access allowed the researchers to modify the database of transactions, unlock the safe, and cleanup any evidence of the compromise. Issues with this include 1) using a general purpose OS in a security critical role, 2) exposing unrestricted hardware system access externally via the USB port, 3) a user interface (kiosk) that fails insecurely. Ultimately, this computerized commercial safe is much less secure than most of the mechanical drop slot safes they were intended to replace.
BMW Lock Compromise
In the BMW compromise, the ConnectedDrive system queries BMW servers on a regular basis over HTTP. The researchers were able to implement a Man in the Middle Attack by posing as a fake cell phone tower and were able to inject commands into the vehicle’s system. In many practical attacks this was used to unlock the doors to simplify theft. The “fix” issued by BMW, forced this channel to HTTPS – which is better, but still does not qualify as a highly secure solution. A more complete and secure solution would implement digitally-signed updates and commands that would provide significantly greater resistance to injection attacks.
The overall risk this compromise represents is that an attacker can inject commands into the vehicle (from close proximity) enabling it to be unlocked, started and stolen without significant effort.
Hospira Infusion Pump Compromise
An infusion pump is a medical device that administers intravenous drugs in a very controlled manner in terms of dosage and scheduling. Modern infusion pumps are networked into the networks in clinical environment to provide remote monitoring and configuration. In addition, they often have built in failsafe mechanisms to mitigate risk of operator errors in dosage / scheduling. The Hospira pump that was compromised had an exposed Ethernet port with an open telnet service running, which enabled a local attacker to connect via Ethernet and gain access to the clinical network credentials. This then allowed the attacker to access the secure clinical network, and access servers, data and other infusion pumps on this network. From either the Wi-Fi or Ethernet port, the attacker could modify the configuration and failsafes since this infusion pump had no protections to prevent either overwriting the firmware or modifying the dosage tables. Later investigations indicate that there are a number of Hospira infusion pumps that are likely to have the same vulnerabilities since they use common parts and software. As a result the FDA has issued multiple security warnings (and sometimes recalls) to hospitals and medical care providers on these types of devices.
The overall risk this compromise represents is that an attacker could: a) compromise the device locally to modify the drug tables, dosing and disabling failsafes, b) compromise the clinical secure network by harvesting the unprotected Wi-Fi credentials from the device, and c) compromise any of these infusion pumps on the same network (wirelessly). Collectively these represent a significant risk of injury and death.
Samsung Refrigerator Compromise
Samsung produces number of smart refrigerators; a recent model has an LCD display that is linked to a Google Calendar that functions as a family calendar. Unfortunately, the operation of this device is also capable of exposing the Google credentials for the associated account. Each time the refrigerator accesses the Google account, it does not actually verify that the SSL/TLS certificate is a valid certificate, allowing a Man in the Middle Attack server to pose as the Google server, exposing the login credentials.
The overall risk associated with this compromise is that the username/password for a Google account is compromised, and that is often associated with many other accounts including banking, financial, and social accounts. This can lead to all of these accounts being compromised by the attacker.
Bottom Line
There is a common thread through all of these recent newsworthy examples. In every one of these cases, these devices not only failed to follow generally accepted best practices for embedded security, but every one of them followed one or more worst / risky practices.
Risky Practices
The following are a set of practices that are strictly not “bad practices” but are risky. They are risky in the sense that they can be used effectively in a secure architecture, but like explosives must be handled very carefully and deliberately.
Exposed Hardware Access
Many embedded devices have some hardware interfaces exposed. These include USB ports, UART ports, JTAG ports, both internal to the device and exposed externally. In many cases these are critical to some aspect of the operation of the device. However, when these interfaces are absolutely necessary, it is incredibly important that these interfaces be limited and locked down to minimize the opportunities to attack through that given interface. In cases where they can be eliminated or protected mechanically, this also should be done.
Pre-Shared Keys
As a general rule, pre-shared keys should only be used when there are no other better solutions (solution of last resort). The issue is that sooner or later, an embedded pre-shared key will be compromised and exposed publicly, compromising the security of every single device that uses that same pre-shared key. In the world of device security, key management represents the greatest risk in general, and with pre-shared keys we also have the greatest impact to compromise. This very broad impact also creates an incentive to compromise those very keys. If a pre-shared key is the only viable solution, ensure that a) the pre-shared key can be updated securely (when provisioned or regularly), and b) that the architecture allows for unique keys for each device (key stored separate from firmware). By storing the pre-shared keys separate from the firmware (rather than embedding in firmware), keys cannot be compromised through firmware images. These features can be used to minimize the overall attack exposure and reduce the value of a successful attack.
Worst Practices
Collectively these compromises represent a number of “worst practices”, or design practices that simply should not be done. Outside of development environments, these practices serve no legitimate purpose and they represent significant security risk.
Exposed Insecure Services
As part of any security evaluation of an embedded system, unused services need to be disabled and (if possible) removed. In addition, these services need to be examined interface by interface and blocked (firewalled) whenever possible. On the Jeep Cherokee, exposing an unauthenticated telnet D-Bus service on the cellular interface was the root access point into the vehicle, and this exposure provided absolutely no purpose or value to the operation of the system.
Non-Secure Channel Communications
If the wireless channel is not secured, everything on that channel is essentially public. This means that all wireless communications traffic can be monitored, and with minimal effort the system can be attacked by posing as a trusted system through a Man in the Middle Attack. Examples of these services include any telnet or HTTP services.
Non-Authenticated End Points
A slightly more secure system may use a SSL/TLS connection to secure the channel. However, if the embedded system fails to actually validate the server certificate, it is possible to pose as that system in a Man in the Middle Attack. As described above, a recent model Samsung Refrigerator has this flaw, exposing the end user Google credentials.
No Internal Security Boundaries / Access Controls
Many of the systems highlighted place all of their trust on a single security boundary between the system and the rest of the world, where the internal elements of the systems operate in a wide open trusted environment. The lack of strong internal boundaries between any of the subsystems is why the Jeep Cherokee was such an appealing target. Within systems are subsystems and each of these need to be defined by their roles and access controls need to be enforced on the interface for each subsystem. The infotainment system should never be able to impact critical vehicle operation – ever. Subsystems need to be protected locally to a degree that corresponds to the role and risk associated with that subsystem.
Non Digitally Signed Firmware / Embedded Credentials
Many embedded systems allow for end user firmware updates, and these firmware updates are often distributed on the Internet. There are functional bugs, security bugs and emergent security vulnerabilities that need to be mitigated or the device can become a liability. This approach to updating has the advantage that users can proactively ensure that their systems are up to date with minimal overhead effort on the part of the product vendor.
It also allows for attackers to dissect the firmware, identify any interesting vulnerabilities and often extract built in credentials. In addition, if the update process does not require / enforce code signing, it allows for the attacker to modify the firmware to more easily compromise the system. By requiring that firmware updates be digitally signed, this prevents any attacker from installing some modified or custom firmware that provides they attacker privileged access to further compromise the device or the network it is part of. Firmware updates need to require digital signatures, and not include embedded credentials.
Summary
As more and more devices evolve into smart interconnected devices, there will be more and more compromises that have increasing levels of risk to to life and property. As the examples above show, many of these will be due to ignorance and arrogance on the part of some companies. Knowledge and awareness of the risks associated with embedded networked devices is critical to minimizing the risks in your systems.
References
Automotive
- http://www.wired.com/2014/08/car-hacking-chart/
- http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/
- http://illmatics.com/Remote%20Car%20Hacking.pdf
- http://www.networkworld.com/article/2953553/brinks-safe-can-be-hacked-with-just-a-usb-stick.html
- https://grahamcluley.com/2015/07/land-rover-cars-bug/
- https://grahamcluley.com/2015/02/bmw-security-patch/
Infusion Pump
- http://rt.com/news/266491-drug-pumps-hacking-hospitals/
- http://www.engadget.com/2015/07/31/fda-security-warning-hackers/
- http://medcitynews.com/2015/08/hospira-blackberry-infusion-pump-hack-was-a-sham/
Other Devices