IIoT-enabled operating technology (OT) embedded systems are exposed to risks from the moment their comms ports open. In this blog we’ll ask and answer the question ‘How might an embedded system be attacked?’ by considering the two common types of attack.
Historically, embedded systems have been relatively secure. To steal data or install a rogue program, a hacker would need physical access to the system. If that system was something like a closed-loop control system residing in a locked cabinet on the factory floor of a security-conscious company, illegal access was no easy feat. The operational technology (OT) used to control motors, actuator valves, burners etc. could only be accessed physically and by authorised personnel.
Just as the Internet of Things provides remote access to IoT-enabled systems (such as ‘smart’ devices in the home) from anywhere in the world the industrial IoT (IIoT) is providing authorised personnel remote access to OT. Oh, and unauthorised people (hackers) are able to access it too unless the system is cybersecure.
Constant threat
In the commercial world, the IT specialists of large organisations (banks, airlines, large retail outlets and other high-profile targets) assume hackers are always trying to get in. Accordingly, security patches are released at frequent intervals within those organisations to protect their intranet and everything connected to it from any threats that may come through from the outside world.
IoT-enabled consumer goods are targets too and are relatively low-hanging fruit for hackers because the general public is not as security-conscious as, say, a business. And that’s unlikely to change, which is why device manufacturers are – under a new law – to be made more responsible for security.
Ground-breaking plans to protect people from cyber attacks
However, the focus of that law is on consumer goods and office equipment likely to be sold in high volumes. Also, these are products that may have an intended service life of just a few years. But what about IoT-enabled OT embedded systems? Will they be subject to the same law? The volumes are much lower and are often customised to order. They may even be one-offs. Also, they are expected to have much longer service lives than consumer or office products. And what about the systems that have been in place for years and not necessarily kept up-to-date? Or have ‘dormant’ elements that are no longer used and therefore not a concern? Or so you would think.
You may have read or heard about the cyberattack on a water treatment plant in Florida, in February of this year. A hacker attempted to poison a city’s water supply by increasing the levels of sodium hydroxide (safe in low concentrations and added to regulate the water’s pH level) from 100 to 11,000ppm.
The engineering / technical press reported that a SCADA system was accessed by TeamViewer; which provides remote access and is great for trouble-shooting. It was reported that the software had not been used for months but was left on the system. Also, an official investigation is said to have reported back that “…all computers shared the same password for remote accesses and appeared to be connected directly to the Internet without any type of firewall protection installed.”
Thankfully, the attack failed. The rogue commands were noticed by a legitimate user on the system at the same time, and the sodium hydroxide levels reduced immediately. The attack did reveal the above concerns plus it was discovered the plant had been using the Windows 7 operating system (support, including security patches, for which ended on 14th January 2020).
In a change to the scheduled program…
In the above example, the hacker had gained access to the plant’s OT and was interacting with the user interface. The OT’s software did not know the person was not an authorised user. The program was executing properly.
Another form of cyberattack sees the program’s behaviour altered. One of the most common ways of doing this is through a ‘memory buffer overflow’ attack; noting here that overflows can easily happen by accident – generally as a result of poor coding.
When data is written to memory it goes to a specific address, for which space has been allocated in the memory map. If a larger volume of data is written to the location than can be accommodated, rather than simply not writing the excess it goes into the next available location and overwrites anything already there.
The hacker’s aim is to overwrite data such that the execution of the software is such that it reveals sensitive data or grants access to other systems, without crashing or showing any outward signs of being compromised.
While you would think that the embedded code (or rather the design entry tool / compiler) would recognise the issue of trying to write more data than there is room for, many memory addressing functions in C and C++ are unbounded. For example, the get(s) function in C reads data into a buffer (in memory). But there is no limit to the size of that data. Without additional code to validate or automatically crop the data before sending it to the buffer there is no safeguard against buffer overflow.
An effective counter is to code in a more secure language (such as C# or Java). Operating systems have memory management mechanisms too. These include declaring some areas of memory as non-executable and allowing memory spaces used during runtime/execution to be given random locations. This last measure is particularly effective because a hacker planning a memory buffer overflow attack (with a view to altering the system’s behaviour in a specific way) needs to know exact addresses.
Above, I outlined two forms of cyberattack: a) gaining illegal access to an OT’s user interface and driving the system in a deliberately harmful way and b) changing the execution code through a forced memory overflow. However, while it’s easy to understand how both attacks work – and it’s not difficult to envisage prevention methods – there are still many challenges associated with securing IIoT-enabled OT embedded systems, which I shall be discussing in my next blog.
In the meantime, you may wish to check out our ‘Securing Your Embedded Memory’ guide. After all, an embedded system’s execution code resides in memory, which also proves the workspace for the program and the storage lockers for sensitive data and passwords. Most cyberattacks are therefore against embedded memory.
