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.
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 1. 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)
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.
In Part 3 of this article, I will explain Stateful Inspection and how critical it is when securing ICS and SCADA Systems.