SANS ISC: Looking for malicious traffic in electrical SCADA networks - part 1 - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

When infosec guys are performing intrusion detection, they usually look for attacks like portscans, buffer overflows and specific exploit signature. For example, remember OpenSSL heartbleed vulnerability? The following is the snort alert for this vulnerability, taken from the snort community rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET [25,443,465,636,992,993,995,2484] (msg:"SERVER-OTHER OpenSSL SSLv3 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 00|"; depth:3; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30510; rev:5;)

When you perform inline detection within electrical SCADA networks, latency is a big issue. That means you need to fully optimize the amount of checks so latency does not increase more than 3 ms. We also need to include other threats that could materialize from other threats different to malware, exploits and buffer overflows. I will detail in this diary some specific SCADA protocol packets that could be malicious traffic and cause terrible consecuences to the process infrastructure. Today I will detail malicious packets from DNP3 protocol.

The following text details DNP3 packet structure:

Source: Practical Industrial Data Communications

• Start: This is the starting delimiter of the DNP3 datalink layer. It is always set to 0x564
• Length: This is the number of bytes for user data inside the DNP3 packet, plus 5 and does not count CRC bytes.
• Control: This is the DNP3 Frame Control Byte, which provides control of data flow between the master and slave over the physical link. It identifies the type of the message and the flow direction for the communication.
• Destination: DNP3 outstations are identified by a two-byte address. These two bytes are the little-endian representation for the outstation destination address .
• Source: These two bytes are the little-endian representation for the outstation source address
• CRC: Little-endian representation of the CRC-16 DNP3. This is calculated for each block and placed in the end of it.
• Transport control: This DNP3 Frame Control Byte provides control of data flow between the master and slave in the transport level.
• Userdata for block n:
  • Application Layer: Control byte: Duplicates the control byte in the transport control field.
  • Application layer: Function code: Defines the function being invocated by the packet
  • Application layer: structures: Defines the structures being written or queried.
• CRC: Little-endian representation of the CRC-16 DNP3 for block n user data.

The following DNP3 functions could be used in a malicious way:

1. DNP3 Warm Restart: When this packet is received by the outstation and recognize that it comes from the master, it performs a partial restart on completition of the communications sequence. If this packet is received several times per second, the IED will experiment a denial of service and won't be able to perform actions to the industrial process, send events to the HMI or receive commands from the HMI. A typical DNP3 Warm Restart packet looks like the following: 

The following filters recognize these packets:

• Wireshark: dnp3.al.func==14
• Snort: alert tcp $DNP3_CLIENT any -> $DNP3_SERVER $DNP3_PORTS (flow:from_client,established; content:"|0E|"; offset:12; depth:1; msg:"SCADA_IDS: DNP3 Warm Restart From Authorized Client"; classtype:attempted-dos; sid:1111112; rev:1; priority:2;)

2. DNP3 Cold Restart: When this packet is received by the outstation and recognize that it comes from the master, it performs a full restart on completition of the communications sequence. If this packet is received several times per second, the IED will experiment a denial of service and won't be able to perform actions to the industrial process, send events to the HMI or receive commands from the HMI. Packet looks same as previous one with one little change: count three bytes from the last to the first and change 0E (DNP3 Warm Restart) to 0D (DNP3 Cold Restart).The following filters recognize these packets:

• Wireshark: dnp3.al.func==13
• Snort: alert tcp $DNP3_CLIENT any -> $DNP3_SERVER $DNP3_PORTS (flow:from_client,established; content:"|0D|"; offset:12; depth:1; msg:"SCADA_IDS: DNP3 Cold Restart From Authorized Client"; classtype:attempted-dos; sid:1111112; rev:1; priority:2;)

3. DNP3 Time Change: When this packet is received, the IED or RTU can change the internal clock time and so orders received with specific timestamp won't be executed and logs will be placed in other different places so the operator can't see them in real time. A typical DNP3 Warm Restart packet looks like the following: 

Wireshark can't fully filter this packets so the following tcpdump filter is provided: ip[52]=2 and ip[53]=0x32 and ip[54]=1

SCADA Information Security is different from the regular IT information security practices. We need to cover the specific vectors to improve the security level of the associated industrial process.

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org