VxWorks Secure Boot

The cause was traced back to the Mirai botnet that infected thousands of devices. Such incidents make a stark reminder of the importance of building security into our devices:  How do we prevent our devices from becoming a vehicle for attack?  How do we prevent our devices from running malware?  How do we prevent our devices from running any type of unwanted software?

VxWorks is a real-time operating system often deployed in devices with high risk of being attacked, like military equipment and power plant controls, or devices where successful infiltration results in fatal disasters, like those involving airplanes, or robotic equipment. 

Attackers in these situations are even more sophisticated than Mirai botnet developers. One method for device security is to make sure that any software that runs on the device is the original intended software, and not one that an attacker has loaded onto the device.

VxWorks offers solutions for securing devices against executing unauthorised software:

• Secure Boot sets up the device firmware to verify the authenticity of the boot loader and VxWorks before running it.
• Secure Loading is a VxWorks configuration to verify the authenticity of user applications before running them.

Secure Boot and Secure Loading details are described in the whitepaper Protect Critical IoT Devices with VxWorks Secure Boot and Secure Loading here. This blog shows Secure Boot and Secure Loading in action in VxWorks.

Demonstration of VxWorks Secure Loading
VxWorks applications come in the form of kernel-space software modules, user-space executables, and user-space shared libraries. These applications can reside in the device memory, in removable storage, or they can be transferred over the network from a remote site.

A simple application can start with a print statement. The following is a line of code to print out the secret of life at the beginning of an application.

On VxWorks, the application runs with no problems.

A hacker with access to the user application image can probe into an insufficiently protected device and change certain bytes in the application image to change the device behaviour. Notice in the hex editor below that the original message ‘The key to happiness is to use VxWorks’ has now been changed to ‘The key to happiness is giving me money.’

Application binary image before change:

Application binary image after change:

In a VxWorks configuration with no Secure Loading, running the altered application results in the wrong message on the console.

While this is a relatively harmless example, changes to user applications can take more disastrous forms, changing execution paths, by-passing safety checks, causing fatal exceptions in the system, and sending out denial of service attacks on DNS servers.

VxWorks Secure Loading protects against execution of malicious applications by performing signature checks on the application. The signing process and validation process are detailed in the whitepaper. Once VxWorks is protected with Secure Loading, the tampered application fails to run.

The execution above shows that the attempt to run the tampered user application failed. The error shows that the signature was invalid.

The original untampered user application coming from a trusted source loads and executes normally

Demonstration of VxWorks Secure Boot
For cases where the attack targets the system in an earlier stage, when the boot loader is loaded, and then when the operating system is loaded, VxWorks offers Secure Boot which uses the hardware security features of the firmware to ensure that both the boot loader and VxWorks authenticity are verified before execution.

Several hardware platforms are supported with VxWorks Secure Boot. The whitepaper gives details of two of these platforms: Intel Architecture boards and NXP i.MX6 boards.

Here is an example of an attack on an Intel architecture board. On one of these sample boards, the UEFI firmware loads the UEFI loader. The UEFI loader in turn loads VxWorks from a USB drive. A hacker gets a hold of the USB drive and modifies the loader to boot up a modified VxWorks with security holes instead.

Here is the console output when the UEFI loader attempts to load a tampered VxWorks image.

The VxWorks image authentication fails, the device fails to boot up, and the hacker cannot use this system for criminal purposes.

If the attacker targets even earlier stage in system startup, replacing the UEFI loader with one that will load up a Linux System containing the Mirai botnet malware, the UEFI firmware spits out a security violation message.

This demonstration shows the thwarted attacks on a VxWorks device with Secure Boot configuration. Details of Secure Boot and its chain of trust rooted in the hardware are too long to explain in this blog. 

The whitepaper gives a fuller explanation of how VxWorks uses hardware security features for its Secure Boot and Secure Loading functionality.

Find more information about security on VxWorks here.

To learn more about Wind River’s security capabilities, click here.

Courtesy of Wind River.