Want to get paid for a vulnerability similar to this one?
Contact us at: email@example.com
We have been working lately on improving beSTORM’s fuzzing support for SCADA. SCADA stands for Supervisory Control And Data Acquisition or in other words, the ability to monitor and control hardware/equipment.
SCADA isn’t one single protocol, rather it provides a concept which several protocols implement. One of them is DNP3 (Distributed Network Protocol). Originally SCADA protocols were used in closed environments with dedicated wires running through the organization which provided end-to-end communication. Today this type of physical implementation is uncommon and networking infrastructures are used – mainly Ethernet.
DNP3 is one of these, as it can be “carried” on a regular Ethernet infrastructure. It can also be routed through your network if you use DNP3 implementation over TCP/IP, in which case your deployment is much easier – connect the equipment to the network give it an IP address and you can control from anywhere that is reachable to that IP address.
As DNP3 and SCADA in general are mainly used in industrial equipment, it is not easy to come by hardware beSTORM will test. We therefore decided to start some place easier – the sniffer. There are several DNP3 Sniffers out there, the most common and popular is Wireshark (formerly known as Ethereal).
Testing was pretty straightforward. Put a listening netcat on DNP3’s designated port (20000) and fire our beSTORM DNP3 fuzzer at it. Pretty soon we noticed that beSTORM was able to not only fuzz the DNP3 protocol, but also cause several instances of Wireshark to freeze, one of them due to an endless loop Wireshark entered into (fixed in version 0.99.6) and another one caused it to exhaust large amounts of CPU and Memory as Wireshark tries to display more elements then would normally be in a single DNP3 packet (version 0.99.6 is vulnerable).
The endless loop, fixed in version 0.99.6, is caused by the following code:
for (temp16 = 0; temp16 < num_items; temp16++)
The code is vulnerable as the temp16 is set to be 16 bit value while num_items is set to be a 32bit value, which means that I can cause the temp16 to loop forever by supplying a 32bit value to the num_items parameter.
Update: Wireshark has released a new version which is immune to this attack version 0.99.7.