Filter Evasion: Part 1

1. Introduction

First we must talk about vulnerabilities. We know that vulnerabilities that are present in any kind of software can be exploited by accepting the right input data, and parsing and executing it without checking it for malicious strings. Thus, vulnerabilities are present in software products because the programmers are not checking for user input before using the inputted data. So, it's entirely the developer's fault that a vulnerability exists. And once a vulnerability is discovered by an attacker, it's merely a matter of time before it is successfully exploited. The packet filters are there to try to prevent the exploitation of the vulnerabilities, while they do nothing to correct the actual vulnerabilities (the vulnerabilities are present in the software product the whole time).

Because of that, it's often the case that filters and IDS/IPS systems are present on the network. Usually, all the data flowing to the target system goes through filters, which analyze the traffic flowing through it. This ensures that known signatures of bad traffic will not be permitted to enter the network and harm the target system. Packet filtering and IDS/IPS systems often provide just another layer of security we need to bypass if we want to attack the target system. Remember the following: if a vulnerability exists, it can and will be exploited and none of the packet filters can prevent that from happening; it merely complicates stuff to a level where it's no longer feasible for the attacker to try to break it, because it would be too time consuming.

Whenever we encounter a packet filter on a network we want to pentest, we need to ask ourselves the following questions:

1. What IDS/IPS or any other filter is in use? This can greatly help us in bypassing that filter, since we know exactly what kind it is. If it is Snort, Suricata, or any other open source tool, we can install it on our system and test there. If we're hardcore, we can also look through the code and try to figure out the exact rules used to block our data from being forwarded to the target system.

1. Where in the network topology is it applied to packets? This can be of great help, because we know exactly where the packet filtering is being done. Maybe there are a few routes through the network that don't go through a packet filter. Sometimes even though our IP has been blocked and we can't access any servers in target network, some IPs in the target network will still accept connections from our IP; this clearly presents that our data can flow through the network without going through an IDS/IPS, firewall, etc.

1. Is packet filtering applied to all packets destined for all IPs? Maybe packet filtering is being done only on predetermined IPs, but not others. This way, it may be better to attack a different target inside the customer's network that is not protected by the packet filter rather than try to bypass the filter.

1. What protocols and OSI layers does the packet filter check: only the application layer and HTTP/HTTPS, or others as well? This is clearly an important part of a packet filter. We can read more about that here, but let's just say that if only certain protocols are being checked, then we can bypass the filter with ease by delivering our attack through other protocols (if that is possible of course).

2. More About Packet Filters

We need to know that nowadays we can find filters pretty much everywhere. The most commonly used filters are listed below:

• Snort: intrusion detection system filter
• ModSecurity: web application firewall (WAF) filter
• ASP.NET Request Validation: filter embedded in the framework itself. ASP.NET 2.0 XSS filter checks for the following:
  • characters &# used together
  • character < followed by a-zA-Z then /!?
  • skips input data that start with __VIEWSTATE
  • many other rules
• IE8 XSS Filter: filter embedded in the IE web browser
• Custom Filter: when the developers are using an additional filter in the code of an application itself

Whenever we're talking about filters it's imperative to talk about two things:

2.1. Where can malicious data be inserted?

Before answering this question, we must mention that what packet filtering (whatever it may be) sees is only the packets the attacker is sending over the network to the victim computer. This is why the malicious data (that could consequentially be detected by the packet filter) can only be inserted in the those packets the attacker is sending over the wire. This is why we must look at how the packet is constructed. I guess you're familiar with the ISO/OSI model, otherwise you probably wouldn't be reading this article, but let's summarize what it is.

The OSI model is a way to construct a standardized packet sent over the network, so that all network devices can understand it. This is done though layers; each packets has 7 layers, where each of the layers contains a very specific data used for different kinds of operations (we won't talk about the Ethernet, IP, TCP, UDP and other protocols here). So the end result of the encapsulation operation is a packet that is constructed from 7 layers. Thus whenever we're doing something on the Internet, uploading a photo on Facebook for example, a series of packets will be sent to the Facebook server, which will hold all the data that can be reassembled back into the original picture.

Let's take a look at the picture below, where we can see that each packet is constructed from 7 layers, namely: physical layer, data-link layer, network layer, transport layer, session layer, presentation layer and application layer. Commonly the session, presentation and application layer are presented only with the application layer. After the data is constructed, it is sent over the Internet to the target network, where it is passed to a packet filter.

A packet filter inspects the packet itself as well as series of packets for malicious data contained in them. It can inspect any layer of the packet to find malicious data; usually only the network, transport and application layer are checked. If malicious data is detected, a packet is rejected, otherwise it is passed on to the target server. We can see all that in the picture below.

But whenever we are checking the application layer with a packet filter, the packet filter must understand the protocol being used in that packet. If the packet filter is speaking HTTP, it can be used to check the application layer when the web browser is talking to a web server. In such cases the packet filter can reconstruct the data in the application layer and check whether it contains anything malicious. But what if a packet filter doesn't speak FTP, and the attacker is communicating with an FTP server (with a FTP client of course)? In such cases, the packet filter doesn't understand the application layer protocol being used and can't determine if the data in the FTP protocol is malicious or not. This is why it can decide only the following two things:

• I don't know anything about the protocol being used, so I'll just pass the packet right through.
• I don't know anything about the protocol being used, which is why I'll reject the packet.

The second option is really not an option, because the packet filter can't just drop everything it doesn't understand. Imagine what would happen if we wouldn't be able to communicate with most of the services in the internal network, because the packet filter doesn't understand the protocol being used. This wouldn't make any sense, because the packet filter can never really understand all of the protocols being used: there are too many. This leaves only one option on the table; the packet filter must pass all the packets it doesn't understand right through to enter the internal network.

2.2. Where can filters be implemented?

We've looked at the places where malicious data could theoretically be inserted, and now it's time to take a look at where the filters are implemented that can detect the malicious data. In the picture below we can see that the malicious attacker is sending malicious data over the Internet. The data arrives at the the IDS/IPS in our network where the network and transport layer is checked for malicious activity. Usually, the IDS/IPS solutions are not checking only the network and transport layer, but other layers as well. When the IDS/IPS filters don't detect anything suspicious, they pass the data along to some server (it doesn't matter which server it is; but if you want to be more specific, imagine it's a web server).

All the filters from there on check only the application data that was transmitted to the end application. The server is the first node that checks the input packets for any kind of malicious data. It then passes the data to the framework and then framework passes it to the application. All of those stop points can check the packets being received for malicious data. If something malicious is detected, they can reject the whole packet, or delete just the malicious data from the packet and send it onwards. The picture that represents that can be seen below: