Over recent years, 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 our experiences in conducting SCADA assessments, we’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 blog post, I will share my experience performing a SCADA assessment, and discuss what pentesting approach and tools work best for assessing these highly sensitive systems.
TL;DR: You can safely skip this section if you already know and have background about SCADA systems; start from the next section.
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. Organisations 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.
Typically, SCADA systems are installed for long term use, and are then less frequently updated afterward due to the complexity involved in maintaining the SCADA hardware, software and communication links. As a result, security is often weaker than would otherwise be expected in such a critical system, which at any point could be compromised if due diligence is not performed. For SCADA systems, it is important to note that what security controls do exist are often not integrated into the solution, but instead are added as an after-thought.
Let’s talk at the protocol level
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.
A typical SCADA network
From a pentester’s point of view, the attack surface area can be determined from the network architecture diagram and how well it is segregated from the rest of the network. The more exposed it is, the more risk it is exposed to. We have experienced both an isolated network and an open network in our engagements. The next generation of SCADA network would involve IoT technology to reduce infrastructure costs and increase ease of maintenance and integration.
In the diagram above, a corporate and a SCADA network are separated by a firewall. For this post, we 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 organisation.
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.
Penetration testing approach: How to prepare
Practically, the chances that the organisation 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:
This is the first prerequisite of any assessment. The pentester needs to understand the purpose of the SCADA system: what mission critical systems are in place, what functionality it provides, who the end users are and how it benefits the organisation. It is a good idea to study system documentation, do your own research on implemented products and vendors, dig into known product vulnerabilities and note factory default credentials at this stage.
Pentester Action: Start thinking about modelling the threats.
Understand the network 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.
Pentester Action: Plan your attack surface.
With the information in hand from the above phases, it’s now good to begin exploring the network. Network exploration must be performed with all care and with customer consent. The preferred approach is to start with performing slow scans of only the well-known ports using appropriate timing options; enumerating protocols and services running over the SCADA network.
You may want to try different timing options so you don’t consume the bandwidth and create a DoS situation. On that note, SCADA systems are very fragile and could easily create a self DoS condition. At this stage you should also consider running Wireshark on the network to sniff the traffic and see if you can capture any clear text credentials.
Pentester Action: Perform exploration with all due care and keep stakeholders in communication during your testing.
Plan your attacks
The previous phase should provide you with 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 organised when testing extremely sensitive and fragile systems.
Pentester Action: Shortlist your tools now.
Exploitation: Do not go wild
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 pentest.
Pentester Action: The exploitation will be very similar to a normal network pentest but with extra caution before launching any exploit.
SCADA Pentest Checklist
- Are all factory default credentials changed?
- Are access to PLCs whitelisted to authorised 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 centre restricted?
- Can you access the internet from the controller machine?
- Are there any clear text services running on the SCADA network?
- Does the organisation follow a strict password policy?
- Are the controller machines, workstations and servers patched? Are they running anti-virus software and have application whitelisting enforced?
Here are the tools that I have personally used in a SCADA assessment and have found do their job well.
- 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
A great list of tools is also available at https://github.com/hslatman/awesome-industrial-control-system-security.