Seventy percent of cyber attacks target the application layer. While a secure RTOS provides features that are critical for security in embedded devices, that’s just the foundation, not the complete solution. Some questions that need to be asked are: Why are IoT and embedded devices, even those with secure RTOS, still vulnerable to attack? What exploits are possible and what vulnerabilities have been reported? What’s missing to protect these devices and how do design engineers ensure that their devices are safe? I’m glad you asked.

Advanced security capabilities are a major selling point for many RTOS vendors. Modern RTOSs provide capabilities such as multiple, independent layers of security (MILS) 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 just a decade ago.

As impressive as all of this is, it’s still just a foundation. A device running an insecure OS and communicating over an encrypted data channel is clearly insecure. The converse is not 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 not enable the attacker to gain full control of the system, but that doesn’t mean he won’t be able to inflict considerable damage.

Data or communication that’s valid and passes through the RTOS security may still present security threats to the application layer. Examples are attacks on web services or against supervisory control and data acquisition (SCADA) systems. A recent SCADA attack involved turning a water pump on and off repeatedly until the pump motor burned out. This attack focused on the application layer and resulted in a device 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 percent of all cyber attacks targeting the application layer, it’s 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 D-Link routers. The HTTP server in these routers 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 backward, “edited by 04882 joel backdoor,” shows this is an intentionally planted backdoor.

The backdoor provided access to the device’s configuration capabilities. The web server used in this same D-Link router already contains a number of vulnerabilities, 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 system of Maroochy Water Services beginning in January 2000, which resulted in millions of gallons of sewage spilling into waterways, hotel grounds, and canals around the Sunshine Coast suburb. It’s an interesting case study because not only did the perpetrator cause pumps to not run when they should have, 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.

Other widely reported attacks against application layer services include attacks on web-enabled 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. 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’re being spied upon.

Application layer security

What all of these attacks have in common is that they didn’t target vulnerabilities in the underlying OS, but rather relied on vulnerabilities at the application layer. Another thing that they all have in common is that they exploit the system’s standard interfaces. In each of these cases, the application layer allowed legal commands to be executed by unauthorized parties.

To protect the embedded devices’ application layer from cyber-attacks requires a set of capabilities to ensure that the application only processes commands from authorized users, ensure that all processed commands are valid (e.g., contain legal data) and that all commands are appropriate (e.g., 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’re 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 used in the production processes of a chemical manufacturing plant. These systems frequently use Ethernet-based control protocols such as EtherNet/IP or Modbus TCP for configuration, control, and reporting. The control protocols 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, EtherNet/IP, etc.), the device may 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).

 

(Click graphic to zoom)

 

 

Protection against application-interface and -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. Application-specific protocol filtering should provide:

• Protocol validation – ensuring that all messages conform to the protocol specification and verifying that all data is valid and in range.
• Policy enforcement – the protocol filter should 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 to 100, but the device’s operation may only allow values in the range of 40 to 60. The protocol filter should support this more constrained set of values.
• Access control – industrial protocols such as ModbusTCP don’t provide any mechanism for access control. Hence, 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 aren’t from a machine on the whitelist. Additional controls can be provided for finer-grain control.
• Semantic filtering – a 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 from a trusted device or 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 time period.
• Command audit logs – record all commands executed by the application for later analysis in case a problem occurs.
• Intrusion detection API – an API allowing the device engineers to log and report each access, authentication attempt, or any other intrusion event. For example, if the web interface includes authentication with a username/password, each login attempt should be logged using this API. The intrusion detection API will then report this event to a management system, which would analyze the received data and detect attempts to probe a single device or multiple devices in a way that’s not possible on the device itself. The device may not have the intelligence or information to distinguish between repeated access attempts by a sysadmin who forgot a password and systematic probing by a hacker.
• Event reporting – provide a mechanism to send alerts when unusual behavior is detected.
• Data anti-tamper detections – this is achieved using a secure hash of static configuration data which lets the system detect when unauthorized changes have been made. Data anti-tamper can detect cross application attacks, such as a change to configuration data via the FTP or Web interface by an unauthorized user (Figure 1).

 

(Click graphic to zoom)

 

 

An application layer security framework

An application layer security framework, such as the Icon Labs Floodgate Defender, provides a framework for application security in embedded devices (Figure 2). This framework includes:

• Floodgate Defender
  • Application protocol filtering engine and embedded IDS/IPS
• Floodgate Secure
  • Secure file hashing for anti-tamper protection
  • Audit task for run validation of secure hashes
• Floodgate Aware
  • User API for event reporting and command audit logging
• Floodgate Agent
  • Interface to cloud based management system supporting
  • Events and audit logs
  • Management and enforcement of security policies
  • System level firewall filtering and intrusion detection capabilities

 

(Click graphic to zoom)

 

 

Alan Grau is the President and cofounder of Icon Labs, a provider of security solutions for embedded devices.