CHAPTER 19
SCADA Attacks
The ever-changing world continues to bring with its evolution numerous accomplishments and challenges. In the last decade alone, we have created a network infrastructure of almost infinite proportions in which we communicate today. The IP cloud covers us all, and truly understanding its philosophical transparency and our critical dependence on its services could be a complex feat. Almost everything is connected to the vast realm of the Internet, and SCADA devices are no exception. The migration of the SCADA infrastructure from legacy to IP brings with it the relative ease of remote management and connectivity, but also the possible burden of network attacks and sabotage. One of the most important questions that you should ask your clients is, “Is your SCADA system secure, and how do you know?”
In this chapter, we cover the following topics:
• What is SCADA?
• Which protocols does SCADA use?
• SCADA fuzzing
• Stuxnet malware (the new wave in cyberterrorism)
• How to protect against SCADA attacks
What Is SCADA?
SCADA stands for supervisory control and data acquisition. SCADA networks control and monitor the critical utility and process control infrastructures for manufacturing, production, and power generation for utility companies, including electricity, natural gas, oil, water, sewage, and railroads.
The development of SCADA can be traced back to the beginning of the 19th century through the introduction of telemetry, which involves the transmission and monitoring of data obtained by sensing real-time conditions. Since the inception of telemetry, SCADA networks have become popular to control electrical and other infrastructure systems. An example of early telemetry is ComEd, one of the largest electric utility companies, that developed a system to monitor electrical loads on its power grid.
The following are common SCADA components:
• Remote terminal unit (RTU) A device used to convert analog and discrete measurements to digital information, such as an instruction to open a switch or valve.
• Intelligent electronic device (IED) A microprocessor-based controller that can issue control commands, such as to trip circuit breakers or raise or lower voltage levels if the IED senses voltage, current, or frequency anomalies. Some examples of IEDs are capacitor bank switches, circuit breakers, recloser controllers, transformers, and voltage regulators.
• Programmable logic controller (PLC) Very similar to an RTU in regard to operation, and may have additional intelligence through a real-time operating system (RTOS) with embedded I/O servers, and services such as SSH, FTP, and SNMP enabled.
• Human machine interface (HMI) The graphical representation (or GUI) of the control environment to the administrator.
Which Protocols Does SCADA Use?
SCADA uses several protocols. The most common protocols are
• Object Linking and Embedding for Process Control (OPC)
• Inter-Control Center Protocol (ICCP)
• Modbus
• Distributed Network Protocol version 3 (DNP3)
OPC
OLE for Process Control is a software interface standard that allows Windows programs to communicate with industrial hardware devices. OPC is implemented in client/server pairs. The OPC server is a software program that converts the hardware communications protocol used by a PLC into the OPC protocol. The OPC client software is any program that needs to connect to the hardware, such as an HMI. The OPC client uses the OPC server to get data from or send commands to the hardware.
ICCP
Inter-Control Center Protocol is an application layer protocol and is also known as International Electrotechnical Commission (IEC) Telecontrol Application Service Element 2 (TASE.2). It has been standardized under the IEC 60870-6 specifications and allows for real-time data exchange over wide area networks (WANs) between utility control centers. ICCP provides transactions for queries, monitoring, data transfer, and scheduling between clients and servers.
Modbus
Modbus is a protocol specification designed for building automation equipment used to interface with various devices over RS485 serial and TCP/IP interfaces. Due to the longevity of the Modbus protocol and its widespread implementation, it is now the most commonly available means of networking industrial electronic devices.
Several Modbus protocol versions exist, described as follows by Wikipedia (with minor adjustments):
• Modbus RTU This is used in serial communication and makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. Modbus RTU is the most common implementation available for Modbus. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.
• Modbus ASCII This is used in serial communication and makes use of ASCII characters for protocol communication. The ASCII format uses a longitudinal redundancy check checksum. Modbus ASCII messages are framed by a leading colon (:) and trailing newline (CR/LF).
• Modbus TCP/IP or Modbus TCP This is a Modbus variant used for communications over TCP/IP networks. It does not require a checksum calculation as lower layer takes care of the same.
• Modbus over TCP/IP or Modbus over TCP This is a Modbus variant that differs from Modbus TCP in that a checksum is included in the payload, as with Modbus RTU.
• Modbus Plus (Modbus+ or MB+) An extended version that remains proprietary to Modicon (a subsidiary of Schneider Electric). It requires a dedicated coprocessor to handle fast HDLC-like token rotation. It uses twisted pair at 1 Mbps and includes transformer isolation at each node, which makes it transition/edge triggered instead of voltage/level triggered. Special interfaces are required to connect Modbus Plus to a computer, typically a card made for the ISA (SA85), PCI, or PCMCIA bus.
Table 19-1 lists common Modbus function codes.
Table 19-1 Common Modbus Function Codes
DNP3
Distributed Network Protocol version 3 is an open master/slave control system protocol specifically designed for the requirements of electrical and water utility industries. Specifically, it was developed to facilitate communications between various types of data acquisition and control equipment. It plays a crucial role in SCADA systems, where it is used by SCADA master stations (aka control centers), RTUs, and IEDs.
DNP3 supports the following behaviors:
• Request and respond with multiple data types in single messages.
• Segment messages into multiple frames to ensure excellent error detection and recovery.
• Include only changed data in response messages.
• Assign priorities to data items and request data items periodically based on their priority.
• Respond without request (unsolicited).
• Support time synchronization and a standard time format.
• Allow multiple masters and peer-to-peer operations.
• Allow user definable objects including file transfer.
References
“DNP3 Overview” (Triangle MicroWorks, Inc.) www.trianglemicroworks.com/documents/DNP3_Overview.pdf
Modbus en.wikipedia.org/wiki/Modbus
“What Is OPC?” (Cogent Real-Time Systems, Inc.) www.opcdatahub.com/ WhatIsOPC.html#note1
“Telecontrol Standard IEC 60870-6 TASE.2 Globally Adopted” (Karlheinz Schwarz) www.nettedautomation.com/download/tase2_1999_09_24.pdf
SCADA Fuzzing
SCADA devices are prone to the same common vulnerabilities—such as enumeration, password cracking, network eavesdropping, and denial of service—that are found in any other types of network devices. Although these attacks may not be considered sophisticated, you would be amazed at how effective they still are. And you must keep in mind that attacks do evolve. They may become more strategic or even scientific, and this is where the principles of fuzzing can be applied.
SCADA Fuzzing with Autodafé
As mentioned in previous chapters, fuzzing provides an intelligent approach to injecting irregular message content and data inputs in an effort to qualify the robustness of a system. To demonstrate the remarkable capabilities of SCADA fuzzing, this section introduces you to the Autodafé fuzzing framework, written by Martin Vuagnoux. Selection was based on its unique ability to handle byte-oriented protocols, its quick setup time, its relative ease of use, its creative mutation mechanisms, and, most importantly, its block-based approach for protocol modeling.
Before you get started with the Autodafé fuzzing framework, you need the Back-Track 4 Linux Security Distro. Additionally, our test bed will have one PC laptop and one voltage regulator as our SCADA edge device connected to a private network. The need for a voltage regulator is not required, but is used as a means to document live behavior for our test method example.
NOTE
The name of the voltage regulator vendor will not be discussed nor documented.
Installing the Autodafé Fuzzing Framework
The following steps to install the Autodafé fuzzing framework assume that BackTrack 4 has been previously installed and configured with network access enabled.
1. Download Autodafé from either Packet Storm (http://packetstormsecurity.org/search/?q=autodafe) or Sourceforge (http://autodafe.sourceforge.net/). It is recommended that you place the Autodafé gunzip file in the /pentest/fuzzers directory.
2. Gunzip and untar Autodafé by issuing the following command: tar –zxvf Autodafe-0.1.tar.gz.
3. BackTrack 4 has most of the library dependencies built in. There is one mandatory library that you need, though, called bison. From a command line, enter the following command to install bison: apt-get install bison.
NOTE
You have the capability of updating BackTrack 4 by performing apt-get update and apt-get upgrade, but this is not necessary for this procedure. You must also consider the size of persistence that you have available on your USB key.
4. Download from the blog An Autonomous Zone (http://anautonomouszone.com/blog/tools) the hex generator script for Autodafé. Place it in the autodafe/tools directory. You can rename the generator.sh file to generator.sh_old and rename the newly downloaded file from generator_w_hex.sh to generator.sh.
5. Proceed in compiling the Autodafé fuzzing framework. cd to the Autodafe directory at /pentest/fuzzers/Autodafe/src/autodafe and vi the (file.c) source. You need to comment out a few lines to alleviate some compile problems that have been found:
/*---------------------------------------------------------------------------*
* NAME: check_directory
* DESC: check if filename is a directory
* RETN: 0 if ok
* -1 if error
*---------------------------------------------------------------------------*/
int check_directory(config *conf) {
struct stat *st = NULL;
/* debug */
debug(1, "<-----------------------[enter]
");
/* check the length of the directory - useless but ...
if (strlen(conf->fuzz_file_dir) >= PATH_MAX - 16) {
error_("error path too long
");
error_("QUITTING!
");
return -1;
}*/
6. cd back to /pentest/fuzzers/Autodafe directory and run the configuration script by typing ./configure.
7. Once the configuration script has run and checked for its dependencies, type the command make.
8. Type the command make install.
You should now be ready to play with the Autodafé framework.
Dissecting the Modbus (mbtcp) Protocol
Thank goodness for the power of the Internet. Instead of having to generate our own Modbus messages (or most any other messages, for that matter), we can utilize network capture files that were previously captured. There are several websites that offer packet captures for the very purpose of learning about the inner workings of the protocol itself. A few websites that provide a wealth of network capture information are Pcapr from Mu Dynamics (http://pcapr.net/) and SampleCaptures from Wireshark (http://wiki.wireshark.org/SampleCaptures). The Pcapr site requires registration, but sign up is quick and painless.
In this example, the Modbus message that is of interest to us is a query request for a Write single register using function code 06. We chose this message to test because it is the message that allows us to perform either a raise- or lower-voltage function when using a voltage regulator as our SCADA edge device.
1. Capture from SampleCaptures or Pcapr a Modbus Write single register using function code 06 packet with Wireshark.
2. Once the packet trace has been captured or downloaded, export the packet capture to PDML (Packet Details Markup Language) within Wireshark by selecting File | Export | As XML – “PDML” (Packet Details) File and save it within your Autodafe directory.
3. Use the PDML2AD utility to convert the PDML file to Autodafé’s script language. The syntax is as follows:
pdml2ad -v -p modbus_query_write.pdml modbus_query_write.ad
NOTE
The PDML2AD tool has a help menu that is accessible by typing pdml2ad –h. Otherwise, –v stands for verbose and –p stands for recover protocol.
4. Take a look at the parsed file by typing cat modbus_query_write.ad:
/*--------------------------------------------------------------------------*
* xml Autodafe's parser v.0.1 (c) Martin Vuagnoux - 2004-2006 *
* auto-generated script using PDML (Packet Details Markup Language) source *
*--------------------------------------------------------------------------*/
block_begin("packet_1");
block_begin("packet_1.6.54.mbtcp");
// name : modbus_tcp.trans_id
// showname: transaction identifier: 0
// show : 0
// size: 0x2 (2)
hex(
00 00
);
// name : modbus_tcp.prot_id
// showname: protocol identifier: 0
// show : 0
// size: 0x2 (2)
hex(
00 00
);
// name : modbus_tcp.len
// showname: length: 6
// show : 6
// size: 0x2 (2)
hex(
00 06
);
// name : modbus_tcp.unit_id
// showname: unit identifier: 255
// show : 255
// size: 0x1 (1)
hex(
ff
);
block_begin("packet_1.6.61.");
// name : modbus_tcp.func_code
// showname: function 6: Write single register
// show : 6
// size: 0x1 (1)
fuzz_hex(
0x06
);
// name : modbus_tcp.reference_num
// showname: reference number: 7700
// show : 7700
// size: 0x2 (2)
hex(
0x1e 14
);
// name :
// showname: (null)
// show : Data
// size: 0x2 (2)
hex(
0x00 01
);
block_end("packet_1.6.61.");
block_end("packet_1.6.54.mbtcp");
block_end("packet_1");
send("packet_1"); /* tcp */
In simple terms, we can see that the PDML2AD tool has parsed through the PDML export trace, leaving us with blocks of data that we can work with. As mentioned previously, let’s focus on function 06: Write single register. Fuzz this area by changing hex to fuzz_hex as noted and save it.
5. Compile the modbus_query_write.ad file using the ADC utility:
adc modbus_query_write.ad modbus_query_write.adc
[!] block: "packet_1.6.61." size: 5 (0x5)
[!] block: "packet_1.6.54.mbtcp" size: 12 (0xc)
[!] block: "packet_1" size: 12 (0xc)
NOTE
This test method is using a basic fuzzing approach that does not incorporate the Autodafé ADBG debugger. In this example, we are actually fuzzing a hardware device that has a TCP/IP stack. If you are fuzzing software, it is highly recommended that you use the ADBG utility/debugger since it will trace the software program in order to weight the fuzzing attacks.
6. We are ready to perform some basic fuzzing using the Autodafé utility. The Autodafé utility has several command-line functions, but for our test we are going to utilize the following commands:
NOTE
Before you execute the Autodafé command line, make sure you are running Wireshark so that you can examine the packets that the Autodafé tool is sending and receiving.
autodafe -v -r 192.168.2.28 -p 502 modbus_query_write.adc
NOTE
The Autodafé tool has a help menu that is accessible by typing autodafe –h. Otherwise, –v stands for verbose and –r stands for remote host. Also, by default, we are using TCP for transport. If you needed to use UDP, you could use the –u option.
7. Once the Autodafé tool has been executed, you should see following:
[!] source: "/Autodafe/hex/hex-x3F-x10-256" (257 bytes)
[!] source: "/Autodafe/hex/hex-x10-256-x20" (257 bytes)
[!] source: "/Autodafe/hex/hex-x20-x10-256" (257 bytes)
[!] source: "/Autodafe/hex/hex-x10-256-x40" (257 bytes)
[!] source: "/Autodafe/hex/hex-x40-x10-256" (257 bytes)
[!] source: "/Autodafe/hex/hex-x10-256-x60" (257 bytes)
[!] source: "/Autodafe/hex/hex-x60-x10-256" (257 bytes)
[!] source: "/Autodafe/hex/hex-x7f-x10-256-xFE" (1 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535" (65535 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535-xFF" (65536 bytes)
[!] source: "/Autodafe/hex/hex-xFF-x10-65535" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535-xFE" (65536 bytes)
[!] source: "/Autodafe/hex/hex-xFE-x10-65535" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535-x7F" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x7F-x10-65535" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535-x00" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x00-x10-65535" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535-x01" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x20-x10-65535" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535-x40" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x40-x10-65535" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x10-65535-x60" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x60-x10-65535" (65536 bytes)
[!] source: "/Autodafe/hex/hex-x7f-x10-65535-xFE" (1 bytes)
[!] source: "/Autodafe/hex/hex-x10-65536" (65536 bytes)
1] waiting 1 seconds before opening connection...
[*] connected to: 192.168.2.28 on port: 502
[*] connected to: 192.168.2.28 on port: 502
[*] connected to: 192.168.2.28 on port: 502
[*] connected to: 192.168.2.28 on port: 502
[*] connected to: 192.168.2.28 on port: 502
[*] connected to: 192.168.2.28 on port: 502
[*] connected to: 192.168.2.28 on port: 502
Autodafé will utilize the hex generator script that we previously installed, and then fuzz the variable or variables that we specified using the fuzz_hex expression. As the fuzzing test scenarios are taking place, we should see within Wireshark the packets being captured. With that said, let’s compare some of the messages. Following is a valid mbtcp (Modbus/TCP) Query/Response compared to a bad/fuzzed mbtcp Query/ Response that was transmitted and received:
No. Time Source Destination Protocol Info
389 18:54:23.228729 192.168.2.20 192.168.2.28 Modbus/TCP query
[1 pkt(s)]: trans:0; unit: 255, func: 6: Write single register.
Modbus/TCP
transaction identifier: 0
protocol identifier: 0
length: 6
unit identifier: 255
Modbus
function 6: Write single register
reference number: 7700
Data
0000 00 1f 5a 00 08 1c 00 23 8b ac 21 c9 08 00 45 00 ..Z....#..!...E.
0010 00 34 08 42 40 00 40 06 37 54 0a 42 f3 22 0a 42 .4.B@[email protected].".B
0020 f3 87 ae 75 01 f6 a2 35 64 b9 00 3a 3d 99 50 18 ...u...5d..:=.P.
0030 16 d0 8b 72 00 00 00 00 00 00 00 06 ff 06 1e 14 ...r............
0040 00 01 ..
No. Time Source Destination Protocol Info
389 18:54:23.230608 192.168.2.28 192.168.2.20 Modbus/TCP query
1 pkt(s)]: trans:0; unit: 255, func: 6: Write single register
Modbus/TCP
transaction identifier: 0
protocol identifier: 0
length: 6
unit identifier: 255
Modbus
function 6: Write single register
reference number: 7700
Data
0000 00 23 8b ac 21 c9 00 1f 5a 00 08 1c 08 00 45 00 .#..!...Z.....E.
0010 00 34 95 dc 00 00 40 06 e9 b9 0a 42 f3 87 0a 42 [email protected]
0020 f3 22 01 f6 ae 75 00 3a 3d 99 a2 35 64 c5 50 18 ."...u.:=..5d.P.
0030 05 a6 9c 90 00 00 00 00 00 00 00 06 ff 06 1e 14 ................
0040 00 01 ..
No. Time Source Destination Protocol Info
1281 18:54:23.983342 192.168.2.20 192.168.2.28 Modbus/TCP query
[1 pkt(s)]: trans:0; unit: 255, func: 126: Program (584/984).
Exception returned [Malformed Packet]
Modbus/TCP
transaction identifier: 0
protocol identifier: 0
length: 6
unit identifier: 255
Modbus
function 126: Program (584/984). Exception: Unknown exception code (255)
exception code: Unknown (255)
[Malformed Packet: Modbus/TCP]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Message: Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]
0000 00 1f 5a 00 08 1c 00 23 8b ac 21 c9 08 00 45 00 ..Z....#..!...E.
0010 00 3a 60 f8 40 00 40 06 de 97 0a 42 f3 22 0a 42 .:`.@[email protected].".B
0020 f3 87 ae f3 01 f6 a2 a3 0d 30 00 3a 3d 99 50 18 .........0.:=.P.
0030 16 d0 e1 11 00 00 00 00 00 00 00 06 ff fe ff ff ................
0040 ff ff ff ff 1e 14 00 01 ........
No. Time Source Destination Protocol Info
1284 18:54:23.986705 192.168.2.28 192.168.2.20 Modbus/TCP response
[1 pkt(s)]: trans:0; unit: 255, func: 126: Program (584/984).
Exception returned
Modbus/TCP
transaction identifier: 0
protocol identifier: 0
length: 3
unit identifier: 255
Modbus
function 126: Program (584/984). Exception: Illegal function
exception code: Illegal function (1)
0000 00 23 8b ac 21 c9 00 1f 5a 00 08 1c 08 00 45 00 .#..!...Z.....E.
0010 00 31 96 de 00 00 40 06 e8 ba 0a 42 f3 87 0a 42 [email protected]
0020 f3 22 01 f6 ae f3 00 3a 3d 99 a2 a3 0d 42 50 18 .".....:=....BP.
0030 05 a6 0f 4b 00 00 00 00 00 00 00 03 ff fe 01 ...K...........
Now just imagine what we could do if we were to take a harder look at the Modbus TCP/IP protocol specification, or any protocol for that matter. We would have an immense playground for testability. We don’t have to stop at fuzzing the Modbus Write single register. We could test every possible Modbus function that is available or supported on our system under test (SUT). In fact, let’s reflect on what we are trying to accomplish:
• Can we trigger abnormal behavior by sending invalid/nonsupported inputs or fuzzed data? The answer is more than likely yes. The example given for the device that was tested did not fail under this test scenario, but negative impact was accomplished when the fuzzing of other Modbus functions and registers was performed. Such impacts that were found would cause the device under test to reboot, or cause the network interface to become nonfunctional, requiring a manual reset/reboot to place the SCADA device back into working operation.
• What if the malicious user were able to gain access to this type of device and replicate the same behaviors? We can’t place blame on the Modbus protocol alone. The same negative impact could occur with any protocol that has been implemented on these SCADA devices that has not gone through a thorough security evaluation. In fact, security and quality assurance should be regarded as the most critical prerequisite to any research and development program.
SCADA Fuzzing with TFTP Daemon Fuzzer
Another interesting fuzzer that caused a brief outage impact to a capacitor bank controller (CBC) device is called TFTP Daemon Fuzzer. As mentioned previously, the CBC device falls into the category of an IED, which is similar to a voltage regulator. The fuzzer is a Perl script written by Jeremy Brown. This script tests for response behaviors to TFTP format string, overflow, and other miscellaneous fuzzing bugs. The script is easily modifiable and actually teaches the user how to implement and fuzz the TFTP protocol. In our test scenario, we connected a CBC device to a private network and then used the NMAP utility to identify which ports and services were active on the CBC device. Several service ports that were identified as being open were TFTP, HTTP, Telnet, and SNMP. The beauty of fuzzing is that all of these services/protocols can be fuzzed/ manipulated to determine if some type of error condition could occur. Let’s quickly take a look at the TFTPfuzz in action.
NOTE
The name of the CBC device vendor will not be discussed nor documented. Also, the need for a CBC device is not required, but is used as a means to document live behavior for our test method example.
Installing TFTPfuzz
To install TFTPfuzz script, follow these steps:
1. Within BackTrack 4, download and run the TFTPfuzz script. You can download TFTPfuzz from Packet Storm (http://packetstormsecurity.org/fuzzer/tftpfuzz.txt). It is recommended that you place the TFTPfuzz script in the /pentest/fuzzers directory.
2. Issue the following commands: mv tftpfuzz.txt tftpfuzz.pl and then chmod 777 tftpfuzz.pl.
3. The TFTPfuzz script will require the Net::TFTP module, written by Graham Barr and available at CPAN Search (http://search.cpan.org/~gbarr/Net-TFTP-0.18/TFTP.pm), or the Net::TFTP module can be downloaded manually.
Executing TFTPfuzz
1. After you install the Net::TFTP module, execute the TFTP script via the following command:
NOTE
Before executing the TFTPfuzz script, make sure you are running Wireshark so that you can examine the packets that the TFTPfuzz tool is sending and receiving. Also launch a secondary console window to send pings to assess whether the system under test fails to respond.
root@bt:/pentest/fuzzers# perl tftpfuzz.pl -h 192.168.2.28
Fuzzing [TFTP]->[MODE/GET] STAGE #1 COMPLETE...
Fuzzing [TFTP]->[MODE/PUT] STAGE #2 COMPLETE...
Fuzzing [TFTP]->[GET/ASCII/NETASCII] STAGE #1 COMPLETE...
Fuzzing [TFTP]->[GET/ASCII/OCTET] STAGE #2 COMPLETE...
Fuzzing [TFTP]->[GET/BINARY/NETASCII] STAGE #3 COMPLETE...
Fuzzing [TFTP]->[GET/BINARY/OCTET] STAGE #4 COMPLETE...
Fuzzing [TFTP]->[PUT/ASCII/NETASCII] STAGE #1 COMPLETE...
Fuzzing [TFTP]->[PUT/ASCII/OCTET] STAGE #2 COMPLETE...
Fuzzing [TFTP]->[PUT/BINARY/NETASCII] STAGE #3 COMPLETE...
Fuzzing [TFTP]->[PUT/BINARY/OCTET] STAGE #4 COMPLETE...
root@bt:/pentest/fuzzers#
2. Once the script is started, execution is pretty well automated. Let’s take a look at a TFTP response message that has come back from the CBC device:
No. Time Source Destination Protocol Info
10482 0.001609 192.168.2.28 192.168.2.29 TFTP
Error Code, Code: Access violation,
Message: Wrong destination file, valid is: X5, or WEB1 - WEB6 00
Source: 192.168.2.28 (192.168.2.28)
Destination: 192.168.2.29 (192.168.2.29)
User Datagram Protocol, Src Port: tftp (69), Dst Port: 51451 (51451)
Source port: tftp (69)
Destination port: 51451 (51451)
Length: 66
Checksum: 0x862c [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Trivial File Transfer Protocol
[DESTINATION File [truncated]:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA]
Opcode: Error Code (5)
Error code: Access violation (2)
Error message: Wrong destination file, valid is: X5, or WEB1 - WEB6
0000 00 23 8b ac 21 c9 00 20 4a 9a 22 8f 08 00 45 00 .#..!.. J."...E.
0010 00 56 ab 2c 40 00 40 11 94 9b 0a 42 f3 28 0a 42 .V.,@[email protected].(.B
0020 f3 22 00 45 c8 fb 00 42 86 2c 00 05 00 02 57 72 .".E...B.,....Wr
0030 6f 6e 67 20 64 65 73 74 69 6e 61 74 69 6f 6e 20 ong destination
0040 66 69 6c 65 2c 20 76 61 6c 69 64 20 69 73 20 3a file, valid is :
0050 20 58 35 2c 20 6f 72 20 57 45 42 31 20 2d 20 57 X5, or WEB1 - W
0060 45 42 36 00 EB6.
We can see that the CBC device responded with an access violation error and an error message, which is a normal response for the type of message that we are sending. The key here is to try every kind of malformed message trigger that we can think of, to see if we can cause some sort of abnormality or disruption. Another important concept to grasp is that fuzzing is not limited to just SCADA protocols; just about any protocol (ASCII or binary) has the potential to be reverse engineered and used for malicious intent.
References
Autodafé fuzzing framework autodafe.sourceforge.net/
“Autodafé Tutorial” (Martin Vuagnoux) autodafe.sourceforge.net/tutorial/index.html
Hex generator for the Autodafé fuzzing framework www.anautonomouszone.com/tools/generator_w_hex.sh
“Modbus Interface Tutorial” (Lammert Bies) www.lammertbies.nl/comm/info/modbus.html
Net::TFTP Perl module search.cpan.org/~gbarr/Net-TFTP-0.18/TFTP.pm
TFTPfuzz script www.packetstormsecurity.org/fuzzer/tftpfuzz.txt
Backtrack Live Security Auditing Distro www.backtrack-linux.org
Stuxnet Malware (The New Wave in Cyberterrorism)
Just when we thought FUD (fear, uncertainty, and doubt) was just a creative marketing technique, W32.Stuxnet emerged as a genuine wakeup call to the fact that cyberterrorism is quite real. This uniquely designed piece of malware is a formidable threat that targets SCADA-related systems. It appears that the most probable targets of this notorious infection were advanced critical infrastructure facilities within Iran, such as nuclear installations that utilized Siemens control systems or, more specifically, Siemens PLCs. In fact, Symantec claims that approximately 67 percent of the infected systems were in Iran alone.
As documented in the Symantec Security Response W32.Dossier, “Stuxnet is a large, complex piece of malware with many different components and functionalities.” These functionalities consist of self-replication based on zero-day exploits and unpatched Microsoft vulnerabilities, antivirus avoidance, network propagation, sophisticated code modification, process injection, network fingerprinting methods, and novel use of both Windows and PLC rootkits. Never before has such a terrifying foe struck such a nerve as critical infrastructure. Some other interesting tidbits about Stuxnet malware are that it is upgrade capable through peer-to-peer methods within the LAN, and can avoid installation detection through the use of two digitally signed authentic certificates, stolen from the certification authorities JMicron and Realtek.
Although Siemens, Microsoft, and antivirus vendors have potentially contained the malware threat through the introduction of Stuxnet removal tools, operating system patches, and updated virus/malware definitions, this alone should not be the only approach used to protect against SCADA attacks such as Stuxnet.
References
Stuxnet www.wikipedia.org/wiki/Stuxnet
“W32.Stuxnet Dossier” (Nicolas Falliere, Liam O Murchu, and Eric Chien) www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32stuxnet-dossier.pdf
How to Protect Against SCADA Attacks
Although you can’t know about and detect all vulnerabilities in advance of deployment, you certainly can be proactive in mitigating the potential of a SCADA security breach by taking the following defense-in-depth methods into consideration:
• Develop a security policy.
• Implement ACLs (access control lists).
• Use MAC address filtering.
• Use VLAN segmentation.
• Physically secure SCADA devices, including alarm and tamper management.
• Disallow the use of third-party USB and related memory sticks.
• Adhere to publications, guides, and standards, such as NERC Critical Infrastructure Protection (CIP) standards; NIST Special Publications 800 Series; IASE guidance; Security Technical Implementation Guides (STIGs); Advanced Metering Infrastructure Security (AMI-SEC) documents; and NISTIR 7628, Guidelines for Smart Grid Cyber Security: Vol. 1, Smart Grid Security Strategy, Architecture, and High-Level Requirements.
• Implement an IDS/IPS that supports SCADA protocol protection mechanisms.
• If a dial-up modem is utilized, implement enhanced security that supports activity logging, encryption, name and password authentication.
• Incorporate OS and firmware upgrades (including patch maintenance).
• Utilize protective protocols such as SSH, DNPsec, TLS, DTLS, SSL, PKI, and IPsec, if possible.
• Implement strong encryption capabilities.
• Implement a Security Information and Event Management (SIEM) system for log aggregation, log review, and audit analysis.
• Implement a scalable edge network strategy for all applicable firewalls, switches, routers, and IPS and IDS devices.
• Confirm and ensure policies are in place for two- and three-factor authentication.
• Ensure scheduled internal security assessments are routinely performed.
Reference
“Security Considerations in SCADA Communication Protocols” (James Graham and Sandip Patel) www.cs.louisville.edu/facilities/ISLab/tech%20papers/ISRL-04-01.pdf