Why SCADA Firewalls Need to be Stateful – Part 2 of 3

In Part 1 of this series, I explained what a stateless firewall is and the hazards of stateless security.  In this article I will show you just how dangerously insecure these devices are.

Setting Up the Stateless Firewall

Let’s consider a simple session where a client computer issues a request to a web server using the HTTP protocol as shown in the figure below. As defined in the IETF specifications, this message will contain the IP addresses of both computers (“src.ip” and “dst.ip”in Figure 1). It will also contain the number 80 in the destination port (“dst.port”) field to indicate that the TCP packet contains a message for a HTTP server.

The HTTP server will reply with a message that has the “src.ip” and “dst.ip” reversed (since the message is in the reverse direction). The number“80” is moved to the source port field, indicating a reply from a HTTP server.

For completeness, this first illustration includes what is called the “TCP 3-way Handshake” shown in yellow in Figure ₁. This handshake is required to establish communication for all TCP communications and is also part of the “state”. However for today, we are going to skip the details of the 3-way handshake and focus on what happens after that.

Figure 1:  The TCP 3-Way Handshake and subsequent communications.

Now to manage these communications, let’s insert a simple switch or firewall that is unaware of the “state” of the communications. In other words, the device is unable to determine anything about any previous communication that may have taken place between the two hosts (including the presence or absence of the TCP 3-way handshake). The only information that this appliance can inspect are the IP addresses (source and destination) and the protocol port number (source and destination).

Now in order to allow our simple HTTP session to pass through this appliance, we would need to configure a unique rule for each “direction” of the session - one to allow the outbound HTTP “request” and the other to allow the inbound “response”. These rules might look something like this:

Allow     src.ip=10.1.1.100     dst.ip=10.1.1.200     dst.prt=80     (Outgoing rule)
Allow     src.ip=10.1.1.200     dst.ip=10.1.1.100     src.prt=80     (Incoming rule)

Spoofing Stateless Communication is Easy

While this looks simple, this type of paired access control rules immediately leads to security vulnerabilities.  Since the appliance can only analyze limited source and destination data, it is not possible for it to block “inbound” communication that was not the direct result of an “outbound” request!

To exploit this hole, an attacker could simply change their IP address to match the Application Server (this is known as “spoofing”) and send their malicious packets to the Client marked with TCP port 80 as his source port. (Note: this attack allows the packets into the control system - if you want to get replies back from the client you would require a second technique called arp poisoning, but that is another discussion).

Figure 2: Spoofing is possible when an attacker sends malicious packets using TCP port 80.

Not only is this simple to perform, but in this case, it is also difficult to detect since the traffic would appear as normal web browser traffic to monitoring tools. The stateless firewall or switch would only see the traffic as coming from the correct IP Address and as being some sort of HTTP message, and happily let it through.

Now this is a moderately serious security problem if you have configured your stateless firewall to only allow web traffic to a single server; at least that forces the hacker to pretend to be that one server. But what if you want your user to be able to browse the web?

The resulting stateless rule would allow the entire web to be able to send any packet they want to the poor client computer, provided they mark the packet with source port 80 to indicate HTTP traffic. It won’t matter if it is really HTTP traffic – it would just have to be marked as such. That is a very low bar to jump over. Plus the hacker can send as many of these packets as they want, a wonderful way to flood the control network.

Recap of Stateless Security

1. A security appliance that is Stateless can only analyze each packet using limited source and destination data. It is unable to determine anything about any previous communication that may have taken place between the two hosts.
2. It cannot block inbound traffic that was not the result of an outbound request.
3. Attackers can send malicious packets by using an IP address that matches the Application Server.  This is known as Spoofing.
4. Spoofing is difficult to detect as it appears as normal traffic to monitoring tools.  The volume of traffic is higher, but this will probably not be noticed.

In Part 3 of this article I will explain Stateful Inspection and how critical it is when securing ICS and SCADA Systems.

This article is a collaboration between Joel Langill and Eric Byres.

Related Content

Video: "SCADAhacker Demonstrates Attacking a Stateless Firewall"   Watch this video and see: How stateless “packet filter” firewalls can let inbound “pings” leak into the control system Why a rule to allow DNS resolution can be exploited by hackers, allowing a full network scan right through a firewall How firewalls capable of checking session state immediately block many common security holes

Related Links

• Why SCADA Firewalls Need to be Stateful – Part 1 of 3
• Why SCADA Firewalls Need to be Stateful – Part 3 of 3
• SCADA Security & Deep Packet Inspection – Part 1
• SCADA Security & Deep Packet Inspection – Part 2
• Why VLAN Security isn't SCADA Security at all
• Tofino Modbus TCP Enforcer Loadable Security Module

Subscribe to the "Practical SCADA Security" news feed