About seventy percent of cyber-attacks target the application layer. Wireless connectivity creates an attack vector that hackers can exploit. While a secure RTOS is critical for security in embedded devices, they are just the foundation, not the complete solution.
by Alan Grau, Icon Labs
The Internet of Things continues to proliferate, with billions of new devices being connected to the Internet. The IoT is reaching into smaller and smaller devices including smart lighting systems, wearable devices, thermostats, health monitoring devices and sensors of all types. The majority of these smaller units connect either directly or indirectly to the Internet using a variety of wireless protocols including Wi-Fi, 6LoWPAN, ZigBee, Bluetooth, WiMax, cellular, Z-Wave, ANT+, etc. Many are tiny and run very low cost hardware to meet the business demands of these systems (low cost, small size and low power usage). As a result, they are very resource constrained and are not able to run a traditional operating system such as Linux, but instead run a specialized embedded operating system or RTOS (Real-time operating system).
Unsurprisingly, given the rapid deployment of new devices, vulnerabilities have been reported in many different types of devices. Internet connected light bulbs using 6LoWPAN mesh networks have been hacked, smart meters have been compromised via an optical debug port, wireless smart home devices have been compromised, Wi-Fi controlled SCADA devices have been hacked, pacemakers have been proven to be vulnerable, and a Tram control system was hijacked in Poland by a teenager using a modified TV remote control. This vulnerability resulted in the derailment of four vehicles and injuring twelve people.
Security of the RTOS
Advanced security capabilities are a major selling point for many RTOS vendors. Modern RTOSes provide capabilities such as MILS (Multiple, Independent Layers of Security) architecture, built in resource provisioning, and support for security certification such as IEC 62304, IEC 61508, IEC 50128, DO-178B/C, EAL and ARINC 653 certifications. In addition, many provide security services such as authentication, access controls, data encryption and security protocols. Without question, embedded design engineers now have a much richer set of security tools and a stronger security foundation available in the RTOS than was available a decade ago.
As impressive as all of this is, it is still just a foundation. A device running an insecure OS and communicating over an encrypted data channel is clearly insecure. The converse is not necessarily true. Securing the OS and adding security protocols is only first step to building a secure device.
Even with these pieces in place, there are still important security challenges to be considered. With security implemented at the RTOS level, a successful attack against a protocol or application may prevent the attacker from gaining full control of the system, but they may still be able to inflict considerable damage.
Data or communication that is valid and passes through the RTOS security may still present security threats to the application layer. Many of the attacks listed above focused on the application layer and resulted in a security failure despite the use of a secure OS. The OS security was never breached and yet the device was compromised. And with as many as 70% of all cyber-attacks targeting the application layer, it is clear that security must extend to the application layer.
Application layer attacks
In 2013, Security researcher Craig Heffner discovered a backdoor within the firmware found in a number of wireless D-Link routers. The HTTP server in these routes includes a backdoor that bypasses the standard authentication process. The web server examines the browser user agent, and if it matches “xmlset_roodkcableoj28840ybtide”, authentication checks are skipped. The string, read backwards, “edited by 04882 joel backdoor” shows this is an intentionally planted backdoor. The backdoor provides access to the device’s configuration capabilities. The web server used in this same D-Link router already contains a number of vulnerabilities (http://www.cvedetails.com/vulnerability-list/vendor_id-521/product_id-899/Acme-Labs-Thttpd.html), some of which can be used in certain circumstances to allow for remote code execution.
In Australia, Vitek Boden waged a three-month war against the SCADA (Supervisory Control and Data Acquisition) system of Maroochy Water Services beginning in January 2000, which resulted in millions of gallons of sewage spill into waterways, hotel grounds and canals around the Sunshine Coast suburb. It is an interesting case study because not only did the perpetrator cause pumps to not run when they should have been running, he also was able to prevent alarms from being reported, further complicating the problem. This example also shows the danger of insider attacks, as Boden was a former contractor of Maroochy Water Services. Boden was eventually arrested and sentenced to two years in prison after he was found with computer and radio equipment for communicating to the SCADA control systems.
Other widely reported attacks against application layer services include attacks on web enabled Wi-Fi and wired IP cameras and nanny cams, which have notoriously weak security. A quick google search will reveal multiple reports against web based security cameras, nanny cams and IP cameras, and there is even a website dedicated to streaming video for IP cameras with weak security (www.insecam.com). These vulnerabilities allow unauthorized users to view the video streaming from the camera, allowing them to spy on whatever the camera is set to watch. Even worse, in some cases they can even instruct the Camera On light to not activate, leading the victim to not know that they are being spied upon.
Application layer security
What all of these attacks have in common is that they did not target vulnerabilities in the underlying operating system, but rather relied on vulnerabilities at the application layer. Another thing that they all have in common is that they exploit standard interfaces of the system. In each of these cases, the application layer allowed legal commands to be executed by unauthorized parties. Wireless connected devices are particularly vulnerable to attack as anyone within range of the protocol who has a laptop, the appropriate wireless interface device and applicable software can launch an attack.
To protect the application layer of embedded devices from cyber-attacks requires a set of capabilities to ensure that the application only processes commands from authorized users, ensures that all processed commands are valid (i.e. contain legal data) and that all commands are appropriate (i.e., changing the ratios of ingredients or the processing temperature in a chemical processing plant).
Additional capabilities that will provide a higher level of security for the device are the ability to detect and report suspicious commands or activity, a command historian to allow auditing when a problem does occur, and data protection to ensure that device data is protected.
Application Security for an Industrial Control System
Industrial control systems are in many ways typical of modern embedded and IoT devices. They are frequently built using a secure RTOS, provide a customer application that performs a critical function, and can be controlled via messages received over an Ethernet or Wi-Fi network.
For our purposes, consider the example of an industrial control system utilized in the production processes of a chemical manufacturing plant. These systems frequently utilize Ethernet based control protocols such as EthernetIP or Modbus TCP for configuration, control and reporting. While these systems traditionally used closed Ethernet networks, many are starting to use Ethernet networks connected to the corporate network and Wi-Fi networks. The control protocols are used to specify the operation of a wide array of parameters involved in the chemical processing. These can include the temperature at which the processing is performed, the ratio and the ingredients, the timing of the various processing stages, flow rates, etc. In addition to the control protocol (Modbus TCP, EthernetIP, etc.), the device may also include a web interface for viewing configuration and processing information, and an FTP interface for downloading new firmware files.
While most cyber-attacks against the application will attempt to exploit weaknesses in the application interfaces, they may also attack the application implementation, or the interactions between interfaces/applications supported by the device (Table 1).
Table 1: Different types of attacks can be launched against a system and it is important to be aware of all of them.
Protection against application interface and application implementation attacks is provided by application protocol filtering. If the device includes an embedded firewall, it may be possible to extend the firewall to perform protocol filtering. Otherwise application guarding APIs can be implemented to perform protocol filtering for the device
Figure 1: Rules based filtering controls the packets processed by the embedded applications, providing the foundation for application security and intrusion detections capability.
Application-specific protocol filtering should provide protocol validation to ensure that all messages conform to the protocol specification and verify that all data is valid and in range. It should also support mutual authentication. Authentication is also critical for wireless networks to prevent attacks by unauthorized devices. For low bandwidth networks such as 6LoWPAN, support for application specific authentication methods such as the JPAKE cipher are critical.
It should also implement policy enforcement that will support user-defined policies to restrict data range values to device or installation specific ranges. For example, the protocol may allow a range of values for 0..100, but the operation of the device may only allow values in the range of 40..60. The protocol filter should support this more constrained set of values.
Protocol filtering should also include access control. Industrial protocols such as ModbusTCP do not provide any mechanism for access control, any legal Modbus command received by the device is processed. Access control policies can be implemented in an application filter to control what devices are allowed to send commands to a device. For example, a white list of IP addresses can be configured and Modbus commands blocked if they are not from a machine on the whitelist. Additional controls can be provided for finer grained control.
Another significant challenge for industrial control devices is encoding rules to answer the question, “Does this command make sense?” While protocol enforcement, policy enforcement and access control enforcement ensure that the commands received are legal and are received from a trusted device/ machine, they still don’t solve the problem of an accidental or malicious change from an authorized insider. Semantic filtering attempts to prevent things like rapid cycling of commands or changing values in ways that are operationally incorrect such as setting an inflow rate that exceeds an outflow rate for an extended period of time.
Command audit logs record all commands executed by the application for later analysis if a problem does occur. This capability is an important part of auditability for industry standards.
An API should be available that lets the device engineers log and report each access, authentication attempt, or any other intrusion event. For example, if the web interface includes a username/password based authentication, each login attempt should be logged using this API. The intrusion detection API will then report this event to a management system. The management system then analyzes the received data and is able to detect attempts to probe a single device or multiple devices in a way that is not possible on the device itself. The device may not have the intelligence or information to distinguish between repeated access attempts by a system administrator who forgot a password and systematic probing by a hacker. By the same token, there should be a mechanism to send alerts when any unusual behavior is detected.
Data anti-tamper detection allows the system to detect when unauthorized changes have been made. This is achieved by using a secure hash of static configuration data which Data anti-tamper can be used to detect cross-application attacks such as a change to configuration data via the FTP or Web interface by an unauthorized user.
An Application Layer Security Framework
An application layer security framework, such as the Icon Labs Floodgate Defender product family, provides a framework for application security in embedded devices. This framework includes the Floodgate Defender, which is an application protocol filtering engine and embedded IDS/IPS. Floodgate Anti-tamper provides secure file hashing for anti-tamper protection as well as an audit task for run validation of secure hashes. A user API for event reporting and command audit logging is supported by Floodgate Aware (Figure 2) and Floodgate Agent provides an interface to cloud-based management system supporting events and audit logs, management and enforcement of security policies along with system-level firewall filtering and intrusion detection capabilities.
Figure 2: A security framework for embedded applications should protect the device from invalid and unauthorized commands, protect data and detect and report unusual traffic.
Today’s IoT and embedded devices are complex connected computers that perform critical functions These devices frequently communicate over wireless networks, creating an attack vector that can be easily accessed. Including security in these devices is a critical design task. Using a secure OS and system level security features provides the foundation, but security features most be included at the application layer to ensure a secure overall system design.
Icon Labs, Des Moines, IA. (515) 226-3443. www.iconlabs.com