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:
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:
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:
Source: Practical Industrial Data Communications
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 |
Manuel Humberto Santander Pelaacuteez 194 Posts ISC Handler Aug 20th 2012 |
Thread locked Subscribe |
Aug 20th 2012 8 years ago |
In case SCADA developers read Manuel's interesting article and decide to imlement mutual authentication using asymmetric cryptography: make sure you get randomness right when generating key pairs (and -if applicable- secret keys for the actual data exchange).
https://factorable.net/ describes recent research on this matter. In particular "headless and embedded network devices, such as routers, firewalls, and server management cards" were found to be vulnerable. My guess is that SCADA devices could be equally vulnerable if random number generation is not treated with special care. |
Anonymous |
Quote |
Aug 20th 2012 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!