Introduction to WAFs, WAF types and WAF Bypassing
As many of you may know, a Web Application Firewall is a firewall that sits in front of our web applications, and filters, analyzes and blocks all the HTTP traffic that passes through, and tries to communicate with the web server. The
basic element of this security implementation is the HTTP protocol, that manages the communication of the client
with the server, and the opposite. What WAFs are doing in this protocol is setting rules for the HTTP conversation.
These rules secure the website from common attacks in the industry, like cross site scripting and SQL injection, but
as you can understand, this is not so easy, and many times they fail.
You may have seen WAFs called reverse proxies. This is because WAFs are generally protecting the server side, and
if we say that a proxy can protect the client, then a reverse proxy can protect the server. It should also be noted that
HTTP is stateless, and the same happens with web applications. This means that web applications utilize the processing info from HTTP while HTTP is not. This results many times in incompatibilities but we will not analyze it in this
course.
You can encounter many forms of WAF installations, such as server plugins, filters, or even customized WAFs for a
certain application. Also, there are different types of WAFs that we can distinguish in the following three categories:
1. Appliance-based Web application firewalls
2. Cloud and hybrid Web application firewalls
3. Code integrated Web application firewalls
The first category, Appliance-based WAFs, has to do with physical WAFs that the server manager installs physically
to the server. It is placed in front of each web infrastructure of the server, and has the great advantage to not have
the need of connecting to a remote server for the WAF services. It is fast, reliable, and on your facilities, so you can
deal with problems that it may face on your own. Many times, this may be a negative aspect, because you will need
specialized staff all the time in your facilities, in case of an emergency problem. Because of the physical structure of
this type, appliance based WAFs have to deal with all the traffic and protocol requirements that your server may
have, so the time of installation has to be set up for any possible case, or else it may face problems in the future.
The next category, that has many differences from the first one, is cloud-based WAFs, and as the name implies, they
are firewalls that are based on the cloud. Most of the time they are installed in a remote server of the cloud WAF
provider, or they can be shared between the company’s and cloud provider’s servers. In the case of complete cloud based WAF, we have serious protection of DDoS attacks, which is a common threat the last decade. On the other
hand, a distributed solution can be used for companies that have more than one server location, and they do not
need a physical solution in all the locations.
Finally, we have Code Integrated solutions, which is only software based, and most of the time, makes changes to
the web application code, or sits to the server. As you can understand, the thing that has no need for hardware
makes it cheaper, easier to fix, and easier to update. You still need specialized stuff in your company, but if the WAF
is well built, it can make things so easy that even the usual IT staff can handle it.
Web Servers and WAF
Placement
Web servers are basically the host of web applications and
WAFs that we are talking about in this course. It consists of
specialized hardware and software that manages the communication between the client and the server, with a variety of
protocols, like HTTP and FTP. Web servers are used most of the time to serve web pages, and on the hardware side
of things, it is pretty similar to a computer that stores the files required for the webpage’s structure, and serves them
to the client. The software side manages the communication and access control of the file system, with many different implementations.
In the situation of a WAF placement on the web server we have the appliance based that as you can imagine is a
separate hardware piece, that sits in front of every other hardware on the web server. All the traffic has to first pass
and get filtered by the WAF, so everything is connected to it. In the cloud based systems, we may have both hard ware and remote cloud service, but the difference is in the remote solution, where the traffic first passes through the
remote cloud server, it gets filtered and then it gets redirected to our web server. Finally, we have the code integrated solutions that as we said is software that sits in front of all the other software in the web server, filters all the
traffic and allows it to the other web applications or blocks it.
There are also two security models that a WAF can follow in developing its security policies, which is positive or
negative. In the positive security policy, WAF allows the traffic that has come to be good to pass through, and
blocks all the other traffic. In the negative model, the WAF allows all the traffic to pass and only tries to block the
known to be bad traffic. Many times, WAF use both of these models, but things get complicated, so most of them
select one of the two.
WAF Operating Modes
Aside from the security models, we have the operating modes of a
WAF. A WAF can operate differently, according to the use we want it
for. Each of them has its positive and negative aspects and it is a serious part to consider when selecting a WAF for your company. The
most famous operating modes are:
• Reverse proxy: As we said in the beginning of the module, a WAF can be used as a reverse proxy, because it
sits in front of the server and filters all the incoming traffic, which is the opposite from a proxy. Many times,the negative in a reverse proxy is the latency that may occur, but this problem tends to be fixed in newer solutions. In this mode, WAF has its own IP address, and all traffic goes through this address.
• Transparent proxy: This proxy has the same conditions as the reverse proxy, with the change that it does not
have an IP address. This is because it sits behind another firewall, and it does not need any networking
changes in the server side.
• Layer 2 bridge: In this mode, the WAF is again sitting behind the firewall and acts like a layer 2 switch (more
about it here: https://en.wikipedia.org/wiki/LAN_switching). It is a mode with high performance, and no
server side changes.
• Network Monitor mode: In this mode, the WAF sits outside the web server (like the cloud based ones),
which sniffs and monitors all the traffic that heads to the web server. In this situation, the WAF is blocking unwanted traffic, by sending TCP resets to interrupt it.
WAFs have some preset rules out of the box, and of course, they get updated many times. These rules are known bad so that when a request is
done to the server, WAF is comparing it with these rules. If a request
matches one of the preset rules, the request is blocked, because it is
faced as malicious. Also, in most of the enterprise WAF solutions, these rules are hidden, and no one can access or
see them. This is happening because developers believe that if these rules are hidden, users won’t know them and
neither will attackers, so it protects users from easy bypass techniques. Of course, these rules can be bypassed many
ways that we will examine in later modules. Some common modifications to bypass filter rules can be shown in Image 3. On the other hand, open source WAFs have their rules open, which is an open call for everyone to find bypass methods easily, and add them to in the filter rules, which is a proven security model of the open source community.
WAF Fingerprinting
The first thing we need to know before starting bypassing WAFs is if
there is at all a WAF in the target, and how this WAF works. For these
reasons, we perform WAF fingerprinting techniques, which can be
separated in two different approaches of fingerprinting. One is passive, where we try to find signs of WAF in the
HTTP responses of the web server. Many times, WAFs are leaving HTTP headers or other interesting info about their
existence, which we can find and examine, to be able to verify it. The downside of this, is that many times WAFs
give false HTTP headers and info, or no info at all, so this technique can be faulty, or not useful at all. The other approach is active fingerprinting. In this approach, we examine the WAF’s behavior. Here we actively examine the web
servers’ responses. Many WAFs, for example, are changing its response depending on the way a URI is requested
due to the filter rules we saw earlier. If we give two different URIs and the one has successfully returned the requested material, and the other not, then we know that a WAF is presented, and we can do some research for this
filter to be able to completely fingerprint the WAF.
Let’s see some practical examples of WAF fingerprinting. As we said earlier, a good indication of WAF existence is
the cookies (or some other HTTP Header) because some web application firewalls add their own cookie in the communication between the client and the web server. For example, we can set a proxy, like Burp suite or OWASP ZAP,where we will filter all the HTTP Requests. If we see an HTTP request where a cookie has been added by the WAF,
we will distinguish the ns_af, which in this situation unveils that the web application firewall is a Citrix Netscaler.
Continuing, another interesting method is by examining the server responses. This is usually done with two ways:
1. WAFs identifying themselves inside the response
2. WAFs replying with specific response codes
For the first one, many times WAFs respond with messages from them into the HTML code, which can be easily identifiable. For the second one, many times we can face strange response codes, like 999, that may or may not be accompanied by a message, which repels us from attacking the system. You can see a good example from the WebKnight WAF, responding with a 999 code, in Image 5.
Further known methods for WAF fingerprint, are:
• Drop Action – Sending a FIN/RST packet from the server or client to terminate a connection (technically
could also be an IDS/IPS)
• Pre Built-In Rules – Each WAF has different negative security signatures
• Side-Channel Attacks – Many WAFs can be recognized by the response time in a server request (Timing behavior)
Automating WAF
Fingerprinting with Burp,
Nmap and wafw00f:
Burp Suite is an integrated platform for performing security
testing of web applications. It is a really powerful tool, if you
have the knowledge to use it. One thing we can do with it, of
course, is to fingerprint a WAF, and that’s what we are going
to do right now. There is no installation needed, but you
need to have Java installed in your PC (you can download
JDK from here:
WAF Fingerprinting with
Burp suite
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html). After the Java installation, head to the Portswiggers download section, and download the free plain .jar version of Burp suite
(https://portswigger.net/burp/download.html). As long as you have downloaded it, the first step is to set a Manual
proxy configuration in your browser. For example in Firefox, you go to Settings-Advanced-Network-Connection Settings, you select the Manual proxy configuration and fill it in with 127.0.0.1 in the HTTP Proxy field, and 8080 in the
port field. Also, we have to use this proxy for all protocols, so we select the box below and click OK to finish with
the setup.
Now, we are ready to start Burp suite where we head to the proxy tab and we see the Intercept is ON (or OFF) button. If the button states that it is ON, we are ready and the proxy is listening in the browser’s communication, but if
it is in the OFF state, we click it to change its state to ON. The last (or first) thing to do is start browsing, and all the
requests that the website does will be presented in our Burp proxy window, like in Image 6.
Introduction to WAFs, WAF types and WAF Bypassing
As you can see, the proxy window of Burp Suite has some other buttons and categories. First of all, we have the forward and drop buttons that we can use to forward a request to its destination or completely drop it, and that can
give us several responses from the server, if a specific request with important information never reaches its destination. Finally, we have the Action button that can perform several actions that have to do with other capabilities of
Burp, like the Intruder or Repeater. We can set the request to these parts of the program and attack them with several attacks that Burp gives us.
WAF Fingerprinting
with Nmap
A really good tool for active WAF fingerprinting (and generally an
excellent tool) is Nmap. It is one of the fastest automated WAF Fingerprinters and uses HTTP pipelining, which is a technique where
multiple HTTP requests are sent on a single TCP connection without waiting for the corresponding responses. Nmap is also more comprehensive than others by having many more
fingerprints and has way less false positives.
Nmap is available for a variety of OS, and you can download it and see install instructions here:
https://nmap.org/download.html In Linux, we just type nmap accompanied with options we need, in a terminal, to
start it. Nmap also has some scripts we can run, and the WAF fingerprinting is executed with a script called httpwaf-fingerprint. To start it we just have to execute:
nmap --script=http-waf-fingerprint <targets>
As you can understand –script is used to select a script to run, and in the targets position we put the IP address of
the website that we can find with a reverse domain tool, or just the host address. http-waf-fingerprint script works
by sending a number of requests and looking in the responses for known behavior and fingerprints, such as Server
header, cookies and headers values. Intensive mode works by sending additional WAF specific requests to detect
certain behavior. We can use intensive mode, as follows:
nmap --script=http-waf-fingerprint --script-args http-waf-fingerprint.intensive=1
Another Nmap script that we can use for WAFs is http-waf-detect. This script attempts to determine whether a web
server is protected by an IPS (Intrusion Prevention System), IDS (Intrusion Detection System) or WAF by probing the
web server with malicious payloads and detecting changes in the response code and body. To do this, the script will
send a “good” request and record the response, afterwards, it will match this response against new requests containing malicious payloads. In theory, web applications shouldn’t react to malicious requests because we are storing the
payloads in a variable that is not used by the script/file and only WAF/IDS/IPS should react to it. [8] If aggro mode is
set, the script will try all attack vectors (more noisy). An example, with the aggro script option, goes as follows:
nmap -p80 --script http-waf-detect --script-args="http-waf-detect.aggro "
This script can detect numerous IDS, IPS, and WAF products since they often protect web applications in the same
way. But it won’t detect products that don’t alter the HTTP traffic. Results can vary based on product configuration,
but this script has been tested to work against various configurations of the following products [8]:
• Apache ModSecurity
• Barracuda Web Application Firewall
• PHPIDS
• dotDefender
• Imperva Web Firewall
• Blue Coat SG 400
WAF Fingerprinting with
WAFW00F
WAFW00F is a Python script that automates WAF fingerprinting and identifies Web Application Firewall (WAF) products. It is an active reconnaissance tool as it actually connects to the web server, but it starts out with a normal HTTP
response and escalates as necessary. More clearly,
WAFW00F does the following:
• Sends a normal HTTP request and analyses the response; this identifies a number of WAF solutions
• If that is not successful, it sends a number of (potentially malicious) HTTP requests and uses simple logic to
deduce which WAF it is
• If that is also not successful, it analyses the responses previously returned and uses another simple algorithm
to guess if a WAF or security solution is actively responding to our attacks [9]
To install it, first of all clone the git repository on your Linux machine with the following command:
git clone https://github.com/EnableSecurity/wafw00f
After this, we just execute the following command in the folder of WAFW00F:
python setup.py install
Now we are ready to use it. First of all, to see which WAFs it can detect we can execute ./wafw00f -l and a list with
all the WAFs will appear. To use it, we just type ./wafw00f and the hostname we want to attack. For example:
./wafw00f https://www.smaple.net
Finally, we can use the –help argument to get help for the usage of the script. For more info, and examples of the
wafw00f usage, see the corresponding video of module 1.
WAF Bypassing
WAFs Implementations many times has serious problems that
can result in bypassing them to execute a real and lethal attack in the server, like SQL Injection or XSS. A typical problem
with WAFs implementations is using the right rule set. Rule sets have an impact on the function of the Web Application behind the WAF and many times can block normal requests (false positives), or the rule set needs to be adjusted and no one did it. Another problem that can arise is in a rule set with exceptions that can result in false negatives, which will have as a result the circumvention of the WAF and finally the servers’ application exploitation.
To start bypassing WAFs, let’s see some of the inner functionality of WAFs or what are the steps that a WAF is taking
to filter the requests. WAFs filter every incoming request to the web applications. The first step is to run the preprocessor, where WAF decides whether a request will be processed further, or will immediately be stopped. This usually happens in extreme situations when the request is really suspicious. Next, we have the normalization process,
where the WAF is standardizing the input. And finally we have the step of Input validation where the WAF is checking the user input against policies. After these three steps, and if the request passes it, it is forwarded to the back
end.
Typical bypass flow
This step is serious because the attacker doesn’t get to choose what encodings might be effective. If there is no base64-decoder at the WAF
end, for example, performing base64 encoding will achieve nothing. If
there is a base64 decoding step, on the other hand, the application should be performing input validation after the
decoding has been done. We will examine encryption attack techniques in a later module.
Now, in the Input Validation step, security models exist that define how to enforce policies, which consist of regular
expressions. There are three core security models:
1. Positive Security Model
2. Negative Security Model
3. Hybrid Security Model
Of course, these models have both positive and negative aspects, and that’s why many of the developers and users
select the hybrid model.
There is a typical bypass flow that is used by many attackers and professionals in WAF penetration testing. This flow
is only a direction, and not a rule. Many times the flow has to be changed for the bypass to come. The four flow
steps are:
1. Fingerprint WAF, and examine the filter rules that it is using. As we said earlier, HTTP responses and an
active fingerprint approach give useful info about the WAF that the server is using.
2. Encrypt the payload that you are using. Many times, we will know the way that the WAF can be bypassed,
but the payload we have made may keep failing. This is because the filter rules may block our approach.
We can solve this by encrypting our payload with many ways that we are going to examine in the next
module.
3. We test our payload and examine the response. We have to carefully examine the Server’s responses to
be able to see which of our payloads are accepted by the web applications, and if they are executed or
not. Many other steps may exist in this section, like exploitation of several aspects of the WAF, that we
are going to examine later.
4. If the payload cannot bypass the WAF, we repeat the flow from step 2.
Pre-processor Exploitation Example
As we said, the first step is for the WAF to run the pre-processor, and that is what we are going to exploit now. WAF
pre-processor attacks are aimed at trying to obscure or remove an attack payload from a request prior to being processed by a WAF’s rule-sets.
Let’s examine the following vulnerable php code from the PHPIDS open-source WAF:
public static function convertFromRepetition($value)
{
// remove obvious repetition patterns
$value = preg_replace{(
'/(?:(.{2,})\1{32,})|(?:[+=|\-@\s]{128,})/',
'x',
$value
);
return $ value;
}
The vulnerable part of the regex is (?:(.{2,})\1{32,}) and it is located in the ./lib/IDS/Converter.php
file, which contains the IDS_Converter class, which is a collection of pre-processor methods, all of which are executed on input data prior to reaching the filter.
The vulnerable regular expression we saw matches any two characters that are repeated 33 or more times in succession. The first match is a back reference declared in the regex with the \1, 32 additional matches are required to
satisfy this regex. An exploitation of this vulnerability with XSS would be executing the following string:
"<script>alert(1)</script>"
This will do nothing, because it’s only matched by four filter rules. If this string is repeated 33 times then the attack
will be successful, and the WAF will be bypassed.
The above situation can be exploited with SQL Injection too, with the only restriction that the attacking query will
end with an SQL comment. Let’s see an example:
' union select password from mySQL.user limit 1 /*
This string matches six filter rules in the code above, which we can bypass if we duplicate the string 33 times and
send it again. We can do this because we added a comment at the end of the query that will comment out the following 32 strings, and only the first one will be executed.
The same goes to directory traversal and Local File Include (LFI) attacks. If we supply the following string in a URI parameter, nothing will happen:
../../../etc/passwd
But if we terminate the string with a null character and copy it 32 times more, we can execute the string. It uses the
same principles as with the SQL attack, but this time we have to use a null byte to stop the following 32 copies from
execution. Format string vulnerabilities can also be exploited the same way. An example for the PHPIDS code would
be:
%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
Many other attacks are exploited by this vulnerability that we will see in the next modules, as well as the thorough
explanation of the attacks we pointed out in this chapter.
Path Parameters
Exploitation
One of the most serious exploitations is exploiting the path parameters, and many WAFs are still missing the concept of extra
path contents (PATH_INFO). Against such WAFs, the following
simple path change works:
/myapp/admin.php/xyz?userid=1PAYLOAD
By giving some random contents to the path, we can completely bypass this kind of measure. Many times, the values supplied are treated as a prefix and the changes fail to return anything. Also, not all web servers support PATH_INFO. In these situations, the path parameters may seem useful by the attacker. Consider the following URL:
/myapp/admin.php;param=value?userid=1PAYLOAD
In both cases, the operation of this evasion technique is the same: we alter the path so that it is not matched correctly by the WAF but still works in the backend [10].
Path parameters are actually path segment parameters, which means that any segment of a path can have them.
The following, for example, works against Tomcat:
/myapp;param=value/admin.php?userid=1PAYLOAD
And even a single semicolon is enough to break up the path:
/myapp;/admin.php?userid=1PAYLOAD
Let’s try to counter this evasion in Apache:
In the next module, we will extend this knowledge and start with HTTP parameter pollution technique.