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:
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 Set- tings, 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) but- ton. 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,
Another
feature in Burp proxy is that we can change field content in the requests. For
example, let’s say that a login form does not allow for more than 14 characters
in the username field, and this check happens client side, but we want to
insert some SQL queries to be able to bypass WAF with SQL Injection method. We
will be able to insert our query simply by adding it in the appropriate field
in the request we see in Burp Suite. And this is only a simple example in the
enormous amount of Burp’s capabilities.
As
you can see, the proxy window of Burp Suite has some other buttons and
categories. First of all, we have the for- ward 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 Another feature in Burp proxy is that we can change field content in the requests. For example, let’s say that a login form does not allow for more than 14 characters in the username field, and this check happens client side, but we want to insert some SQL queries to be able to bypass WAF with SQL Injection method. We will be able to insert our query simply by adding it in the appropriate field in the request we see in Burp Suite. And this is only a simple example in the enormous amount of Burp’s capabilities.
As you can see, the proxy window of Burp Suite has some other buttons and categories. First of all, we have the for- ward 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 Fin- gerprinters 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 http-
waf-fingerprint. To start it we just have to execute:
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 contaiing 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 "
<target>
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 finger- printing and identifies Web Application Firewall (WAF) prod- ucts. It is an active reconnaissance
tool as it actually con- nects 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
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:
WAF Bypassing
WAFs Implementations many times
has serious problems that can result in bypassing them to execute a real and
lethal at- tack 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 Applica- tion behind
the WAF and many times can block normal requests (false positives), or the rule
set needs to be ad- justed and no one did it. Another problem that can arise is
in a rule set with exceptions that can result in false nega- tives, 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 pre- processor, where WAF decides
whether a request will be processed further, or will immediately be stopped.
This usu- ally 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 check- ing the user input against policies. After these three steps,
and if the request passes it, it is forwarded to the back
end.
The step of Normalization is really
important because with the functions that will be used, the writing of rules
(as we said earlier) is simplified, and no knowledge about different forms of
input is needed. In Image 6, you can see some of the f
unctions that are used in
this process.
Typical bypass flow
This
step is serious because the attacker doesn’t get to choose what en- codings
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:
·
Positive
Security Model
·
Negative Security Model
·
Hybrid
Security 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.
•
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 proc- essed 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 succes- sion. 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 fol- lowing 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
Path Parameters Exploitation
One
of the most serious exploitations is exploiting the path pa- rameters, 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 val- ues supplied are treated as a prefix and the
changes fail to return anything. Also, not all web servers support PA- TH_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 cor- rectly
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:
<Location ~
(?i)^[\x5c/]+myapp(;[^\x5c/]*)?[\x5c/]+admin\.php(;[^\x5c/]*)?> SecRule
ARGS:userid "!^\d+$"
</Location>
In the
next part , we will extend this knowledge and start with HTTP parameter
pollution technique.