Fuzzing SCADA Programmable Logic Controllers
PLC’s for short, are used extensively in SCADA networks for meter readings and equipment status reports, which are then sent over an IP network (using IEC61850, DNP3, MODBUS, etc) to the Supervisory Station. PLC’s run both a piece of software to report back up to the station while simultaneously controlling physical entities like electric motors, pneumatic or hydraulic cylinders, magnetic relays, etc. You can see where I’m going with this: There are two alternate universes here and they should not affect each other. On the measurement/controlling side, responses have to be sent back within certain time bounds or things will break leading to physical and collateral damage. On the IP side, the inherent unreliability of IP networks has to be handled. This is very similar to how routing vendors [try and] isolate the control and forwarding planes, except the forwarding plane here controls and measures physical entities.
The Mu Test Suite has long supported fuzzing of IEC61850, MODBUS, DNP3 and other SCADA protocols. In fact we have key testimonials from ABB and Honeywell as to how we help them improve software reliability and resiliency.
With the 4.1.0 release that went out last month, we’ve added support for Digital IO monitors that can correlate effects of testing the IP-universe of the PLC against the physical universe. Before I go into details of what we support, take a moment to think about it. The software stack on these PLCs needs to be completely isolated from the control side or chaos will ensue. Think of an IEC-61850 vulnerability (it’s ASN.1 based, which by the way we all know is a bug-pit) that causes voltage spikes which then nukes the motors on a mining ventilation fan shutting off air to those deep within the ground. *shudder*.
The Mu platform now has built-in support for Ontrak ADU200 and ADU208 DAQ (Data Acquisition Module) through one of our USB ports. The overall test topology looks like this:
Effectively you are now connecting both the physical universe and the IP universe to Mu so we can muck with one side and correlate the effects on the other side, all fully automated so you don’t have to manually do this kind of correlation. The key parameters of the Digital IO monitor are the expected frequency and the % tolerance of variation from the expected value. When we start fuzzing the PLC, the Mu platform periodically reads the frequency values from the DAQ. These values are then correlated with the specific test case. Upon a crash of the PLC, you can easily see the test case that caused the fluctuations and how much the deviation was from the tolerance levels.
So that said, here’s how the report looks with the specific test cases correlated against what the DAQ reported.
As you can see we’ve managed to plot the output of the DAQ superimposed against the response time of the normal MODBUS transaction (instrumentation) while we are fuzzing MODBUS. The red dots at the bottom of the chart indicate the specific test-cases where the measured tolerance was outside of the configured range. Absolutely precious!
Credits: Heidi wrote the awesome product documentation from which I got many details for the blog. By the way, she’s probably the only technical writer that I know who can file a bug about a negative look-ahead assertion not working the way it was expected to. :-)