Demystifying SCADA Testing - P1

There is a big difference between doing pen-tests in IT and doing it in SCADA. Tools and methodology outlines will be almost the same but the main concern is availability. You need to know certain things before attempting to find flaws in industrial networks. Else, you won't realize why shift managers were rushing here and there while you were sitting in their control room with your test laptop.

Approach: Always remember we are not trying to prove anything by breaking stuff ruthlessly. A PLC or RTU, stuck in a loop, can delay production for several hours, creating not-so-funny consequences.

While trying to assess cyber risk in plants our aim should be clear. Here are few points to keep in mind.

1. Find out unnecessary hosts in the network. These hosts can be legitimate, else they are leaking into the plant network by a badly configured switch or the plant team was badly stuck with finance and they have used a generic switch (those household tp-link/d-link devices). 
2. Try to impersonate a device by spoofing IP and MAC. See how far you can reach by impersonating. Check if you are anywhere near a position where you can listen to queries sent to RTU/PLC by Engineering station/Master. 
3. Once you are at a point from where you can listen to Master queries and Slave responses, mark that point as attacker(testing) base.
4. Check for protocols being transmitted in the plant network. Industrial equipment vendors stick to particular protocols only (eg. Modbus, DNP3, S7, etc). If any other unknown protocol is seen, try to analyze the source and destination in order to find out if they are required to be in that network or they were accidentally introduced. Keep in mind, industrial networks are very flimsy in terms of bandwidth consumption. If any of the network paths remains fully exhausted during a configuration change or code download, things won't take much time to break apart. 
5. Remember the operating stations and engineering stations are mostly windows based systems. Also as the plant ecosystem loves network file share, you will find SMB open in almost all of the systems. Don't forget to run explicit service scans on these hosts.
6. Most of the SCADA software is built using VB or C# and they contain a lot of vulnerabilities in code. Authentication and RBAC tampering are the most common possibilities.  SCADA also has dependency softwares, created by different vendors, thus integration points can leak real-time data and also might become victims of MiTM. 

Now, after all these points, let's explore how to do the assessment practically. In this post, we will see how host and port discovery can be done safely using Nmap.

Safe host discovery:

1. While doing host discovery, use -sL to list the hosts with minimum probing.
2. Use -Pn switch to disable ping. Most devices respond to specially crafted SYN messages and don't reply to ping, thus unnecessary traffic is better avoided. 
3. Keep --scan-delay 1s or 2s as we need to reduce our scan aggression to the lowest level.
4. Use --max-rate 20 so Nmap will send a maximum of 20 packets per second. Reduce this number based on the existing congestion and type of switches present in the network (100 Mbps or gigabit).
5. Also, don't forget to stop parallel probing by setting --max-parallelism 

Sample scan example: 

• $ nmap  -sL -Pn --scan-delay 2s  --max-rate 20 --max-parallelism 1 192.168.0.1/24

Warning: Don't ever do a ping sweep by nmap -sn 192.168.0.1/24 in an Industrial network, else this can make certain industrial controllers unresponsive.

But this can become a use-case if performing in Lab. We can assess if any ping sweep handling capability had been introduced by the DCS vendor or not. 

Port discovery safe practice using Nmap:

1. Use -sT switch in Nmap. This is used to perform TCP connect scan so that it opens and closes port probe connections properly before moving to the next port. Keep in mind that in Industrial networks, half-open ports can cause issues in SCADA/DCS communications. 
2. Use -Pn switch to disable ping. Most devices respond to specially crafted SYN messages and don't reply to ping, thus unnecessary traffic is better avoided. 
3. Keep --scan-delay 1s or 2s as we need to reduce our scan aggression to the lowest level.
4. Also, don't forget to stop parallel probing by setting --max-parallelism 1
5. Depending upon the environment, try to scan the industrial ports one by one or else patch multiple ports in one scan. 

Sample safe scan example: 

• $ nmap  -sT -Pn --scan-delay 2s  --max-parallelism 1 -p80,443,445,502,530,593 192.168.0.2

Identified host IPs will either be provided by the plant (if agreed in contract agreement) else this list needs to be done after host discovery.

💭Did you know you could actually kill a GE RTU by simply sending a Nmap query with -PA, which sends ACK packets. GE RTU will fall in a loop after receiving ACK without sending SYN previously.  

Will be continued..