SCADA Protocol Fuzzing Topic at Defcon 15
It’s that time of year again where the interesting topics that will be presented at Blackhat, Defcon, and the CCC Camp start popping up. One particular topic at Defcon (other than the hypervisor rootkit stuff) titled “Unraveling SCADA Protocols: Using Sulley Fuzzer” by Ganesh Devarajan of 3Com/Tipping Point caught my eye. This particular line:
…
Once the test cases are developed, the tool will be used to determine the vulnerabilities in various implementations and these vulnerabilities will be presented in Defcon. A case study of the various software implementations will as well be presented showing where they are normally vulnerable.
To me it sounds like Ganesh will be providing an overview on most of the popular SCADA protocols, showing off a Sulley based fuzzer, and publishing some vulnerabilities that have been found by the 3com/Tipping Point labs. I’m guessing from these vulnerabilities Tipping Point has created some ZDI signatures for their UnityOne’s to help protect customers utilizing their IPS systems.
In a former position I handled a large amount of inline segments and found that while the ZDI signatures may protect systems from attack, they may also block legitimate traffic. This was a risk the organization could not accept as the protected ZDI details kept the team from understanding what exactly the IPS may allow or block, we did however turn them on monitor/alert mode so that we may investigate further.
I’m curious to see if the fuzzer will be released to the general public under some type of open license similar to Tipping Point’s IPS tomahawk test tool.
Author: Landon Lewis
Posted: July 6th, 2007 under Conferences, IDS / IPS, SCADA Protocols, Vulnerability Disclosure.
Comments: 5
Comments
Comment from Erik Hjelmvik
Time: July 6, 2007, 9:59 am
From my contacts with TippingPoint I know that they are releasing signatures for Modbus, DNP3 and ICCP. They don’t have any signatures for the IEC-protocols…yet.
On http://dvlabs.tippingpoint.com/appearances/ you can read about the upcoming presentation:
“After the basics I will be getting into the finer details of the protocols as to what function code, internal indication flags does what and how that can be used to attack or take down the SCADA system. I shall as well discuss and demonstrate the current level of security implementation that these sites have.”
So I guess the knowledge needed to attack a SCADA system will be known to a greater public after that.
TippingPoint will present this at more places, for example Black and White Ball (London).
I do however wonder if they have focused on commands for shuting down/restarting devices or if they have looked for bugs in SCADA implementations of the protocols. Since they have used a fuzzer I would guess the latter, and that would mean that the vulnerabilities can be fixed.
I’m also curious regarding how thee tipping point signatures differ from Digital Bond’s. When I asked TippingPoint about it they said that they had not used the Digital Bond signatures, but instead used their own fuzzing tool to find vulnerabilities and create signatures.
Comment from Julian L. Rrushi
Time: July 6, 2007, 10:45 am
armykid@enigma:~$ cat message.asc
—–BEGIN PGP SIGNED MESSAGE—–
Hash: SHA1
>I do however wonder if they have focused on commands for shuting down/restarting devices or if they have looked for
>bugs in SCADA implementations of the protocols. Since they have used a fuzzer I would guess the latter, and that would >mean that the vulnerabilities can be fixed.
In my opinion an attack which directly sends commands to underlying critical infrastructure utilities would have to focus on a precise setting of function codes in protocol data units.
- From public information it looks like Tipping Point uses the Sulley tool to generate fuzzed SCADA protocol frames. I deduce that they aim at identifying coding/logical vulnerabilities in SCADA protocol implementations.
Regards,
Julian L. Rrushi
—–BEGIN PGP SIGNATURE—–
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFGjlUryHNOxuxOkNIRAi2NAJ0c3jpMGZ7P1xcKnWK8CChtiB3V3gCfWiwd
DFNmJ0bQmpbUBa3k7/YRgFQ=
=8mO2
—–END PGP SIGNATURE—–
Comment from Dale Peterson
Time: July 6, 2007, 11:08 am
3com/Tipping Point has released Digital Bond SCADA IDS signatures a couple of years ago. They may have some new signatures that were internally developed.
Comment from Landon Lewis
Time: July 6, 2007, 3:23 pm
Ironic as it is, Tipping Point released new digital vaccines in the past week and added or modified existing IPS signatures. Below is a excerpt from the notices:
…
Digital Vaccine #DV7330
July 06, 2007
Modified Signatures:
4127: MODBUS: Force Listen Mode Only
4129: MODBUS: Read Device Identification
4143: MODBUS: Restart Communication
4144: MODBUS: Clear Counters and Diagnostic Registers
4146: MODBUS: Unauthorized Read Request
4147: MODBUS: Unauthorized Write Request
4150: MODBUS: Report Slave ID
4968: DNP3: Disable Unsolicited Responses
4971: DNP3: Cold Restart from Un/Authorized Client
4974: DNP3: Unauthorized Read Request to a PLC
4979: DNP3: Unauthorized Write Request to a PLC
4980: DNP3: Unauthorized Miscellaneous Request to a PLC
4981: DNP3: Stop Applications
4982: DNP3: Warm Restart
4983: DNP3: Broadcast Request from Un/Authorized Client
5036: ICCP: Unauthorized Association Request
5039: ICCP: Unauthorized MMS Write Request
5040: ICCP: Unauthorized MMS Write Succeeded
5041: ICCP: Invalid OSI PSEL (ACSE Abort PDU)
…
Digital Vaccine #DV7326
July 03, 2007
Added Signatures:
4127: MODBUS: Force Listen Mode Only
Category: Client/Server – Policy
Description:
This filter detects a DoS attack on an established
Modbus connection between a Server and a Client.
4129: MODBUS: Read Device Identification
Category: Client/Server – Policy
Description:
This filter detects the attack carried out by a
malicious user to learn more about the vendor,
product, version number and other information
about a PLC or other MODBUS server.
4143: MODBUS: Restart Communication
Category: Client/Server – Policy
Description:
This Filter detects a command issued by the server
to force the client \to restart.
4144: MODBUS: Clear Counters and Diagnostic Registers
Category: Client/Server – Policy
Description:
This Filter detects an attempt made by an attacker
to clear the counters and registers to clear his
audit trails.
4146: MODBUS: Unauthorized Read Request
Category: Client/Server – Policy
Description:
This Filter detects an attempt made by an
unauthorized client to read data from the PLC or
other shop floor devices.
4147: MODBUS: Unauthorized Write Request
Category: Client/Server – Policy
Description:
This Filter detects an attempt made by an
unauthorized client to write data into PLC or
other shop floor devices.
4150: MODBUS: Report Slave ID
Category: Client/Server – Policy
Description:
This Filter detects an attempt by the attacker to
gain information about the device.
4968: DNP3: Disable Unsolicited Responses
Category: Client/Server – Policy
Description:
This filter detects an attempt by the attacker to
disable the Spontaneous messages from the field
devices.
4971: DNP3: Cold Restart from Un/Authorized Client
Category: Client/Server – Policy
Description:
This filter detects an attempt by an attacker to
force the victim into a complete Restart.
4974: DNP3: Unauthorized Read Request to a PLC
Category: Client/Server – Policy
Description:
This Filter detects an attempt made by an
unauthorized client to read data from the PLC or
other shop floor devices.
4979: DNP3: Unauthorized Write Request to a PLC
Category: Client/Server – Policy
Description:
This Filter detects an attempt made by an
unauthorized client to write data into the PLC or
other shop floor devices.
4980: DNP3: Unauthorized Miscellaneous Request to a PLC
Category: Client/Server – Policy
Description:
This filter detects an attempt by an unauthorized
client making legitimate requests to the PLC.
4981: DNP3: Stop Applications
Category: Client/Server – Policy
Description:
This filter detects an attempt by an attacker to
stop certain applications running on the DNP3
server.
4982: DNP3: Warm Restart
Category: Client/Server – Policy
Description:
This filter detects an attempt by an attacker to
force the victim into a warm restart.
4983: DNP3: Broadcast Request from Un/Authorized Client
Category: Client/Server – Policy
Description:
This filter detects an attempt by an attacker to
enumerate the network or to cause a broadcast
flooding.
5036: ICCP: Unauthorized Association Request
Category: Client/Server – Policy
Description:
This filter detects an attempt by an attacker to
initiate an association request.
5039: ICCP: Unauthorized MMS Write Request
Category: Client/Server – Policy
Description:
This Filter detects an attempt made by an
unauthorized client to write Manufacturing Message
Secification (MMS) data into the PLC or other shop
floor devices.
5040: ICCP: Unauthorized MMS Write Succeeded
Category: Client/Server – Policy
Description:
This Filter detects an acknowledgment attempt made
by an unauthorized client to write Manufacturing
Message Specification (MMS) data into the PLC or
other shop floor devices.
5041: ICCP: Invalid OSI PSEL (ACSE Abort PDU)
Category: Client/Server – Policy
Description:
This filter detects an invalid OSI Presentation
layer Selector (PSEL) request.
Comment from Dale Peterson
Time: July 6, 2007, 5:21 pm
Those are a subset of the Digital Bond signatures. Hopefully we at least got a mention in the documentation.
Modbus: http://www.digitalbond.com/wiki/index.php/Modbus_TCP_IDS_Signatures
DNP3: http://www.digitalbond.com/wiki/index.php/DNP3_IDS_Signatures
ICCP: http://www.digitalbond.com/wiki/index.php/ICCP_IDS_Signatures
Write a comment