A Shocking Flaw
Here’s an all too often overlooked item in the security architecture of industrial networks.
Below is a diagram of an industrial network architecture we’ve seen in a number of places.
In the diagram, a PLC with multiple network interfaces, in this case a PROFINET-enabled Siemens S7-300 or a S7-1500, is used to connect to the SCADA network on one side, and on the other side - to the I/O network.
Let’s imagine the following scenario:
- An attacker has gained access to a host in the SCADA network (10.0.0.x).
- The attacker wants to directly attack the I/O devices at 192.168.0.x, in order to sabotage the industrial process.
The question is: What should the attacker do in order to reach the I/O devices?
Think about it, then scroll down to see the answer.
If you answered “nothing”, that’s the correct answer.
The S7-300, S7-1500 and other controllers with multiple network interfaces are sometimes used to “separate” the SCADA and I/O networks.
However, there is no such separation. If you use this feature, from the perspective of the SCADA network, there’s full L2+ access to the I/O network, and vice-versa.
The PROFINET interface on the S7-1500 (for example, the S7-1511 PN model) is a network switch, allowing anyone from the SCADA network full access to the I/O network, and vice versa.
From the perspective of the attacker, the network is completely flat.
As documented in the manual entry for the S7-1500 PROFINET-enabled CPU:
And as documented in the manual entry for the S7-300 PROFINET-enabled CPU:
How Cyber Attackers Manipulate this Flaw
All an attacker has to do in order to access the I/O network directly, is to take a device in the SCADA network, add an IP address in the I/O network and then communicate with the field devices (in the I/O network) over any protocol they choose (Ethernet, IP, TCP, UDP, ICMP, etc).
This means that for example, if you have PROFINET I/O modules running on the I/O network, they’re accessible from ANY IP on the SCADA network, both by L2 (direct Ethernet) and by L3 (IP).
If you use this topology and you trust the I/O network to be separate from the OT network, this is a major flaw in your architecture.
How to Check if your I/O Field Network is Accessible From your SCADA Network
- Perform the test during maintenance windows or in production with caution. Contact SCADAfence support if you need help.
- Find out what is the IP range for your I/O network / fieldbus.
- Select an IP address that’s not in use, in the I/O network range.
- Change the IP of a test machine in the SCADA network using the following command:
netsh int ipv4 add address "Local Area Connection" 192.168.0.253 255.255.255.0
- Then, ping an I/O controller, a sensor, a PLC, or any other IP that answers pings in the I/O network. If you got a response back, your I/O network is flat together with your SCADA network.
How to Discover These Vulnerabilities Automatically
This flawed design has been discovered by the SCADAfence Platform: The platform has been used to monitor both the SCADA and I/O networks of a certain industrial facility. Although the I/O network was supposed to be segmented from the SCADA network, in the sensor installed in the SCADA network, the SCADAfence security teams have seen broadcasts originating from the I/O network. When the SCADAfence security teams inspected the topology further, they discovered that in contradiction with what the system integrator and OT team believed - the networks were connected and were completely flat.
How Many Networks are Separating Between I/O and SCADA Using A Network Switch?
For the purpose of this research, it was a network misconfiguration that the SCADAfence platform helped uncover. Nonetheless, this question is very important for OT & IoT network security.
This network architecture flaw is a very clear example of how network packet analysis is a fundamental technology for the security of OT and IoT networks.
If you want to try out the SCADAfence Platform and uncover all of the vulnerabilities in your OT network, we will be glad to help you. Book your free demo here