SANS ISC: Authentication Issues between entities during protocol message exchange in SCADA Systems - 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

Well, better late than never ;) My SANSFIRE conference was about authentication issues between entities where unauthorized parties can exchange fake messages which may cause damage to the industrial process controlled by the SCADA system. I want to discuss today how you can change a timestamp of an Intelligent Electronic Device (IED) using DNP3 supplanting the Master Terminal Unit. For today's discussion, I will talk from the Power SCADA perspective.

Let's do a review on the SCADA systems architecture:

The components are:

• Remote Terminal Unit (RTU): The RTU is defined as a communication device within the SCADA system and is located at the remote substation. The RTU gathers data from field devices in memory until the MTU request that information. It also process orders from the SCADA like switch off a transmission line.
• Master Terminal Unit (MTU): The MTU is defined as the heart of a SCADA system and is located at the main monitoring center. MTU initiates communication with remote units and interfaces with the DAS and the HMI.
• Data Acquisition System (DAS): The DAS gathers information from the MTU, generates and store alerts that needs attention from the operator because it can cause impact on the system. 
• Human Machine Interface (HMI): The HMI is defined as the interface where the operator logs on to monitor the variables of the system. It gathers information from the DAS.

DNP3 is a set of communication protocols used between RTU and IED devices. The communication scheme is as follows:

Source: Practical Industrial Data Communications

Please note that there is no previous level 7 protocol synchronization requesting any kind of authentication. Master Station (RTU) just sends a request, Slave Station (IED) confirms reception, responds the requirement and then Master Station Acknowledge reception. This means the protocol is vulnerable to spoofing attacks to both Master Station and Slave Station as any station can pose as any of the points just sending spoofed packets.

The most dangerous point is that IED can answer any of the available commands inside the protocol. Those are:

• Read: Some of the objects inside the IED have sensitive data that can be used as information to perform a ciberterrorist attack. For example, if a power transmission line is transmitting on top of its capacity, more electricity can be directed to that line for causing a massive power blackout.
• Write: IED can be configured to open circuits, overload circuits or similar operations. Those parameters can be saved permanently to the configuration file. If network communications for the IED is disabled, the only way to restore its configuration is configuration override from the device console.
• Delete File: If the IED configuration is wiped and then restarted, it cannot longer perform its function and cause a blackout in the entire power system.
• Save configuration: We already discussed how can this be used with write and delete file functions.
• Start application and Stop application: The IED can perform tasks which can cause blackouts or explosions inside energy substations.

 How could we sent a spoofed DNP3 packet? Let's have a look to the DNP3 frame format:

Source: Practical Industrial Data Communications

If we want to set the IED time and date to July 11 2012 01:46:54.632 UTC, what do we need to do? Let's create a packet that can do the job according to the DNP3 frame:

• Start: Every DNP3 frame has a starting delimiter, which is 0x564.
• Length:The length of the packet is all user data plus the source addess, destination address and control byte. All the information in packet is placed using the little-endian byte order. For this packet will be 18 bytes (0x12)
• Control: The message is sent from the master station to the slave station. Master Station ID is 2 and Slave Station ID is 1. This means direction bit is set and primary bit is set, which indicates that communication is happening from the Master Station and directed to the slave station. Frame Count bit and Frame Count Valid is not set. Function code is 4 (no confirmation expected). Final value for this byte is 0xc4. More information on the control bit follows:

Source: Practical Industrial Data Communications

• Destination is set to 1 (0x0100) as described in the control byte.
• Source is set to 2 (0x0200) as described in the control byte.
• CRC: Once calculated, it is set to 0xc993.
• Transport Layer byte: Final bit is set because this is the last message sent for the function code. First bit is set because this is the first mesage sent for the function code. Sequence number is 1. Binary number obtained is 11000001, which is 0xc1.
• Application Layer byte: Final bit is set because this is the last message sent for the function code. First bit is set because this is the first mesage sent for the function code. Confirm bit is not set as confirmation is not needed. Unsolicited frame is not set as this message is not sent by the slave station as unrequested information and sequence number is set to 1. Binary number obtained is 11000001, which is 0xc1.
• Function code: We are writing a timestamp object, so the function code is Write (0x02).
• Qualifier field: There is no index prefix and qualifier code is 8-bit single field quantity, which is 7. Binary number obtained is 00000111, which is 0x07.
• Number of items: We are writing a single timestamp, so it is only one (0x01) item.
• Timestamp: It's stored using the CP56Time2a format. Once converted, we store 0x28b1b7733801
• Checksum: Once calculated, it is set to 0xb872.

The packet would be store as follows using C notation: char buffer1[256]="\x05\x64\x12\xc4\x01\x00\x02\x00\x93\xc9\xc1\xc1\x02\x32\x01\x07\x01\x28\xb1\xb7\x73\x38\x01\xb8\x72"

If we want to send this packet, we only need to build a TCP connection to port 20000 and send the information stored in buffer1 with source IP address same as the real master station. You will see the timestamp change on the IED.

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