Alex Vranas profile picture

Alex Vranas

Support Desk Specialist

Thursday, August 30, 2018

At DEF CON 26, there were many exciting hacks and exploits demonstrated against technologies ranging from self-driving cars to voting machines.  Attendees competed to “pwn” (slang for exploit, or “own”) whatever tech they could get their hands on.

While voting machines and futuristic cars may make for an exciting news cycle, let’s talk about some vulnerabilities exposed on real infrastructure.  Let’s talk about Industrial Control Systems (ICS), or more specifically, Programmable Logic Controllers (PLCs).

These devices control a lot of the world around us.  Some of them aren’t that important – some just run shop-floor machinery – they aren’t networked, they don’t need updates for years, they just do what they need to do.  However, many of these devices operate critical infrastructure like dams, power stations, gas pumps and oil rigs, and many more are connected to a network – sometimes even to the Internet – where they can be exploited by a bad actor.  These high-profile PLCs are ticking time-bombs, as real catastrophes can result if they are compromised.

Thiago Alves, a Ph.D. Student at the University of Alabama in Huntsville and SCADA Cyber Security Researcher at the Center for Cybersecurity Research and Education (CCRE) demonstrated how one would go about doing exactly this.

The Attacks:

In his presentation he offers a look at three attacks.  The first is a DDoS attack against multiple PCLs, making them malfunction and become unmanageable.  The second is a buffer overflow attack that crashes a PLC and corrupts its programming.  The third exploits a badly-architected secret protocol that allows untrusted hosts to assume management rights to a PLC and exposes plaintext passwords.

His demonstration lab is simple.  He has three PLCs (Open PLC, Allen-Bradley and Modicon/Schneider), and three glasses of water.  The PLCs are programmed to keep the water in each glass at 40° C using a temperature probe and a heater.  He also has a ScadaBR control panel that allows him to turn the heaters on and off manually or give automated control back to the PLCs for automatic temperature regulation.

All three PLCs are running the same ladder-logic program and use Modbus for communication.

Attack 1:  Command Injection against OpenPLC, Allen-Bradley and Modicon (Schneider) PLCs – DDoSing a PLC with bad commands:

In the first Attack, Alves performs a DDoS attack against all three PLCs, forcing them into manual mode, and forcing the heaters on.  In this state, the water in the glasses will continue to be heated until they boil.  The ScadaBR interface does not respond to input while the PLC is under attack.

Alves runs his Injection attack against each PLC:

Running injections against each PLC.

And he loses the ability to take control of each PLC he attacks:


Open PLC





Left running, the PLCs will eventually raise the water to boiling temperature.  All he has to do is replay a previous Modbus packet sent from this ScadaBR panel from another host, and it will override the packets sent from legitimate hosts.  While legitimate Modbus instructions may make it to the PLC, their effect will be fleeting so long as the device is under attack with illegitimate packets.

Attack 2:  Micrologix 1400 Vulnerability - Lying about the size and contents of a Modbus packet to create a buffer overflow:

In the second attack, Alves sends specially-crafted Modbus packets to the PLC, lying about the size and contents of the packets, bringing the device offline.  Every time the device receives a Modbus packet, there’s a chance that it will fail to deallocate memory related to that packet.  By sending two malformed Modbus packets in sequence, the PLC crashes and reboots.

The magic Modbus packets look like this:

Micrologix Deadly Packets

The first packet gives a length longer than the actual payload.

The second packet gives the length of the previous packet’s payload but comes with no payload of its own.

Not only does this crash the PLC, but it corrupts onboard storage forcing a technician to re-flash the PLC with its program to bring it back online.

If this attack were levied against a remote PLC, it would require human intervention to fix, which could be very costly and time-consuming.

Attack 3:  Modicon (Schneider) M221 PLC “Unity” vulnerability.

In the third attack, Alves demonstrates how to use an undocumented Modbus protocol called “Unity” to take over a managed PLC and expose the password used to protect it.  In the demonstration, Alves explains that he and his colleagues have reverse-engineered the Unity protocol and created a program that allows them to send specially crafted Unity packets.

Unity contains specific instruction that can control a PLC, turning it on and off, replace programs, and read the contents of memory.

The first Unity message he sends to the PLC is a basic acknowledgement packet, which tells the PLC that he wishes to establish communication with it, in which is responds with a confirmation:

First Unity Message to PLC

The second message he sends asks the PLC to disconnect from any management servers it is connected to, in which is responds with another confirmation:

Second Message to PLC

Next, he sends a message asking it to “Reserve Me”, in which it responds with a confirmation and session number (90):

PLC sends confirmation and session number

Then he uses the session number to send command to the PLC telling it to stop executing its program:

Telling PLC to stop executing the program

The result is that the PLC shuts down and becomes unresponsive in ScadaBR (though it still returns sensor data):

PLC returns the sensor data.

Of course, it can be turned back on again using another Unity command:

PLC turned back on using Unity command

This is only the tip of the iceberg – Unity is an even bigger security risk than this demonstration has proven so far.  Alves next uses Schneider SoMachine Basic to demonstrate management of the PLC.  The Modicon PLC he wants to access requires a password to manage:

Modicon PLC password requirement

So, he sends a Unity message to the PLC requesting the project headers for the currently installed program:

Unity message requesting project headers to PLC

Which causes the PLC to return the Project name, “New project”, and the Unity password, “D3FC0N”.  This password can be used inside of SoMachine Basic to manage the PLC:

PLC returning project name and password.

Can HIP (Host Identity Protocol) help?

We followed up with Alves after seeing his presentation and asked him about the best ways to mitigate threats against PLCs.  The obvious answer is to upgrade your PLC firmware often (and yes, these exploits have been patched in the most current software releases), and without delay when critical security patches are pushed – however this isn’t always possible given 24/7 operation and other technical concerns.

I asked what he would consider to be the best way to mitigate these kinds of threats to infrastructure, assuming that updates were not an option.  “That is what every SCADA researcher is looking for”, he told us, “there is no solution I can find”.  He did illustrate what his ideal mitigation would be.  His suggestion is to isolate the PLC from the rest of the network or “build a wall around the PLC”.  This would prevent a rogue network device from sending malicious Modbus/Unity/etc. packets to PLCs on the network, as only authorized devices would be able to communicate with it.  Although, he warns that “the device is still vulnerable, and it will still talk to a node with an insecure protocol.  If the protected host is compromised, the same kinds of attacks can be replicated.”

Tempered Networks HIPswitches represent half of Alves’ ideal “bump-in-the-wire” (BITW) security model for protecting PLCs.  The rest, he says, is “side-channel defense”.  He envisions the use of a Modbus preprocessor with learned behavior.  As he explains it, “An attack might look a lot different [than normal traffic] and could trigger an alarm”.

What else does Alves recommend for KEEPING infrastructure secure?

Thiago Alves is also the lead programmer for OpenPLC, a project that aims to replace traditional industrial PLCs with commodity hardware like Raspberry Pis and Arduinos.

Open PLC

One of the biggest downsides to traditional PLCs is that they are closed-source, which makes security hard in the face of them ostensibly being a development platform.  Combined with the use of proprietary, insecure legacy protocols these devices are being exposed as some of the most vulnerable devices connected to our core infrastructure.

OpenPLC is fully open-source and is compatible with the same ladder-logic code (All 5 IEC 61131-3 languages) that powers existing PLCs, in addition to modern programming languages.  The hardware needed to run OpenPLC is a mere fraction of the cost of commercial equivalents.  While Tempered Network’s HIPswitches are one half of BITW threat mediation, perhaps community-driven solutions like OpenPLC will represent the other half, providing security against attacks while also maintaining compatibility with existing industrial systems.  The OpenPLC runtime is compatible with the PLCopen XML editor, and ScadaBR GUI builder.

All photos are courtesy of Thiago Alves / UAH / DEF CON