Embedded security fails in ICS

Over the last 5 years, we’ve seen an increasing use of open-source software in ICS (Industrial Control Systems) devices, with a move away from traditional RTOS (Real Time Operating System) and proprietary software. We’ve seen RTUs (Remote Terminal Units), HMIs (Human-Machine Interfaces) and even PLCs (Programmable Logic Controllers) running Linux now.

There are many advantages:

• No need to reinvent the wheel. Instead of writing your own webserver, you can use an existing one, focusing on specific ICS functionality. Development tends to be more efficient; products get to market quicker.
• Compatibility. Libraries like openssl and software like openvpn allow connectivity to many disparate systems. ICS has traditionally relied on plaintext protocols or dated and weak encryption, often requiring highly specific hardware at both ends.
• Building on previous security. Many people have analysed the Linux kernel and common software packages. Although we know that “many eyes” isn’t perfect, it certainly helps.
• Widely understood, Many developers and engineers understand Linux well, so there is no need to learn new systems.

However, we’re seeing the same mistakes made in Industrial IoT as we’ve seen in consumer IoT.

Principle of Least Privilege not followed

It’s common to find all processes running as root on a device: the web server, the VPN daemon, database services, and custom binaries handing ICS traffic. If any one of these is compromised, there is no need for the attacker to escalate privileges – they already have complete control. A vulnerability in the webserver could allow an attacker direct access to the serial ports connected to equipment!

Without least privilege:

With least privilege:

This is far more important with services that establish network connections – either servers accepting them, or processes connecting out. The chance of these being compromised remotely is far greater.

We don’t expect to see this on servers or the desktop, and it’s not acceptable in ICS devices either.

Some of the common daemons used by embedded Linux distros can make this hard – OpenWRT uses uhttpd which must run as root if it is on a port <1024.

No Firmware Signing or Secure Boot

The threat model that ICS devices can operate under is extreme: nation state attackers may need to be considered. Therefore, it’s important that the software running on a device is authentic and has not been tampered with.

Firmware signing ensures that firmware update files have been cryptographically signed. Secure boot ensures that the firmware is cryptographically signed. The two work hand-in-hand to prevent a modified firmware being installed.

It’s rare for us to see either on an ICS device. We expect it on our phones and laptops, and we should expect it in ICS.

Secure boot can be challenging to get right, especially if the hardware and toolchain don’t natively support it. Firmware signing is far easier and should always be present in Linux based embedded systems.

Compile Time Hardening Not Used

Binaries can be compiled with certain functionality that make them more resistant to certain types of attack, particularly buffer overflows. These include

• Address Space Layout Randomisation (ASLR) and Position Independent Execution (PIE) – these change the memory addresses used by the binary to make it more difficult for an attacker to predict the address of certain instructions.
• Stack Canaries – guards are put around data in memory on the stack, and if these are altered by any means, an exception is raised. This makes stack-based buffer overflow attacks (where an attacker overwrites stack memory) harder to carry out.
• Non-Executable (NX) – this allows memory to be marked as code or data, preventing an attacker executing data as code.
• Fortification – certain known unsafe functions are wrapped or replaced by safe functions. Typically, this uses buffer-length aware replacements for functions such as memcpy, strcpy, memset etc.

Adoption of these has slowly increased in the server and desktop Linux market, but it is still rare to find them used in embedded systems. They do degrade performance somewhat – tests need to be carried out.

Turning these mitigations on can change a buffer overflow from total compromise into a temporary denial-of-service.

Out-of-Date Software

A kernel from 2011. Busybox from 2008. Apache from 2007.  This is a common picture for an embedded device.

Often, despite the age of the software, there aren’t any immediately exploitable vulnerabilities. That doesn’t mean that this isn’t an issue: if a vulnerability is found, updating 10-year old software over 2 major revisions is far more challenging than a minor version patch.

It’s common for the vendor to rely on an upstream device manufacturer for the toolchain and BSP (Board Support Package). Sometimes the software contained in this is already out-of-date and doesn’t receive updates, placing the onus on the vendor to do the work.

Conclusion

ICS equipment should always be protected by secondary security controls, such as segregated networks, physical access barriers, and per-device passwords. These secondary controls will fail from time-to-time. When they do, it’s vital that the devices themselves can withstand attack. Without this, you cannot have true defence-in-depth.

With a strong foundation, it can be easy to build robust ICS devices that can be kept up-to-date and hardened to attack. Make sure that strong foundation is in place before you start building on top of it!