SCADA stands for Supervisory Control and Data Acquisition. In very simple terms, SCADA defines a type of control system that is used to control and monitor facilities and industrial infrastructure. Organizations use SCADA systems to automate complex industrial processes, detect and correct problems, and measure trends over time. SCADA systems are used in industries such as water management, building and facility management, traffic management, electric power generation, etc.
SCADA systems support various protocols such as DNP3, ModBus, IEC 60870, BACnet, LonWorks, and EPICS. In this blog post we’ll stick to discussing the ModBus over TCP protocol as it is still widely used in control systems.
ModBus is a serial communication protocol used to communicate with Programmable Logic Controllers (PLCs), which can be used over TCP (port 502). Each device intended to communicate using Modbus is given a unique address. The devices communicate using a master-slave model where only one device (master or slave) can initiate a transaction (called “queries”). A slave is usually the end device on the SCADA network (valve, sensor, or meter reading) which processes information and sends its output to the master.
A ModBus frame consist of target device address (or broadcast address), a function code defining the requested action, data field, and an error checking field. By default, ModBus has no authentication and encryption but can be transported over SSL/TLS to prevent sniffing, spoofing and replay attacks.
The diagram above, a corporate and a SCADA network are separated by a firewall. I assume that firewall rules are properly set and no access to the SCADA network is allowed. The three major components involved in SCADA are:
Human Machine Interface/Controller Machine: Usually a Windows workstation known as master used to manage and control PLCs on the network through client software. If compromised, an attacker gains access to everything on your SCADA network.
Programmable Logic Controller (PLC): A physical system connected with a power supply and network enabled with capability to talk over Ethernet networks. It could have an LCD panel showing controller status, operator messages, etc. In recent times we have seen that PLCs are accessible via web browsers, Telnet, SSH – exposing it to all kinds of application and network layer attacks. If compromised, an attacker can manipulate the input/output of your devices and cause serious damage to the organization.
End Devices (Sensor, Valve or Pump): End devices installed at the remote site. They report to PLCs over communication links such as radio, serial connections, Ethernet or direct modems. If compromised, an attacker can compromise the integrity of the environment.
Note: The above components are standard in every SCADA network. You’d probably discover other devices as well such as database servers, serial device interfaces, etc.
Recently, SCADA systems have moved from proprietary, closed networks and systems to open systems and TCP/IP networks. This has exposed these networks to the same risks that traditional computer networks face. However, this does not necessarily mean that the approach for security assessment remains the same for SCADA assessments.
From my experiences in conducting SCADA assessments, I’ve noticed that every assessment is different, and on each occasion a unique approach is required based on the system functionality and type of industry it is deployed in. In this article I will share my experience performing a SCADA assessment, and discuss what pen testing approach and tools work best for assessing these highly sensitive systems.
How to prepare?
First you have to ask these questions:
- Are all factory default credentials changed?
- Are access to PLCs whitelisted to authorized machines only? They should not be reachable from everywhere.
- Is the SCADA network separated from the rest of the network? If not, try reaching the PLCs from corporate workstations.
- Is physical access to the SCADA control center restricted?
- Can you access the internet from the controller machine?
- Are there any clear text services running on the SCADA network?
- Does the organization follow a strict password policy?
- Are the controller machines, workstations and servers patched? Are they running anti-virus software and have application whitelisting enforced?
Practically, the chances that the organization will have a SCADA test/QA environment are slim. So, we assume that you have to perform an assessment on a live network, taking into account all due care. It is advisable to be prepared before the start of an assessment and ensure that all stakeholders receive communications during each phase of testing. The high-level approach to perform a SCADA assessment includes:
Draw a network map and understand the layout:
The primary purpose of studying the network architecture is to logically understand how each component of the SCADA environment relates to each other (beware, this will be highly complex). You should understand what components are involved and how are they segregated, connected or exposed into the wider network. This phase also involves identification of various subnets present within the network. It is important to find out whether the corporate network is separated from the SCADA network or not.
Plan your Attack carefully (it’s not a normal IT level- simple error or an out of control action may result in a HUGE RISK).
After you gather enough information on what you need to test and what attacks are applicable. I recommend documenting each of the test cases before attacking the target. This will make you more organized when testing extremely sensitive and fragile systems.
Execute each exploit individually. This will help you detect the root cause in case any device unexpectedly experiences failure conditions. If this happens, you should halt testing and inform the customer. You should attempt exploiting each of the components within the SCADA network i.e. network infrastructure, web interfaces, host operating systems, PLCs, HMI, workstations – just as you would do in a traditional network pen-test.
Nessus (But you should control the request timing and preform the scan once for each ip)
smod: ModBus penetration testing framework
plcscan: Python script for scanning PLC devices
NMAP Scripts: NMAP script to scan PLC devices
Wireshark: Network sniffer
mbtget: Perl script to read data from PLC
plcinject: Tool to inject code into PLCs.
SCADA systems are super sensitive and sometimes you may face a SCADA computers that runs Windows XP with 1 G Ram like one of my clients was, so control all your request and monitor the network using WireShark before generating a traffic.