This article is more than 1 year old
Researchers offer simple scheme to stop the next Stuxnet
Don't get rung out about planting bugs in ladder logic: they should be easy to spot
One of the world's oldest programming styles, the ladder logic that runs on industrial programmable logic controllers, remains dangerously vulnerable to attack, according to boffins from Singapore and India.
The researchers – Naman Govil of the International Institute of Information Technology, Hyderabad; and Anand Agrawal and Nils Ole Tippenhauer of the Singapore University of Technology and Design – explain that for all the attention paid to attacks like Stuxnet, there's a dearth of work looking at what's going on at the control logic level.
They write that while industrial control systems are getting better protection from malicious or buggy firmware, the ladder logic that controllers run is less defended.
In the systems they tested, from Rockwell, firmware updates were protected by digital signatures, but not the ladder logic. That runs on the assumption that only trusted people will have access to insert programs: “there were absolutely no checks/verifications performed to ensure that logic updates being pushed onto the programmable logic controller (PLC) are coming from authorised sources.”
To demonstrate this, Tippenhauer and his collaborators wrote what they call “ladder logic bombs” (LLBs) with a focus on stealthy behaviour that's difficult for human operators to notice if they're validating what's running on their PLCs.
The payload types the trio tested included:
- A Denial of Service LLB that waits for a trigger and shuts a system down;
- A data manipulation LLB that manipulated sensor readings and commands; and
- A data logging LLB, which they note is particularly dangerous because they don't disturb the system, and might therefore leak sensitive data for long periods of time;
They note it's very easy to conceal commands that will go as far as bricking the PLC, using legitimate instructions to fool around with arrays or create stack overflows (the latter is pure simplicity: create a recursive subroutine that calls itself).
Defences proposed by the Tippenhauer paper are, thankfully, also simple. First, companies should centralise their PLC software storage into a single location, with all engineers submitting what they call “golden samples”, and PLCs only take updates from those samples. Second, operators should (preferably automatically) run periodic checks that validate the software on PLCs with the central logic store. ®
Biting the hand that feeds IT
