Bypassing Web Application Firewall — Part 1

Update: This article is part of a series. Check out the full series: Part 1, Part 2, Part 3, Part 4, Part 5!

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:

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 hardware 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 inte- grated 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.

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 seri- ous part to consider

when selecting a WAF for your company. The most famous operating modes are:

Reverseproxy: Aswesaidinthebeginningofthemodule,a WAFcanbeusedasareverseproxy,becauseitsitsinfrontoftheserverandfiltersalltheincomingtraffic,whichistheoppositefromaproxy.Manytimes, the negative in a reverse proxy is the latency that may occur, but this problem tends to be fixed in newer solu- tions. In this mode, WAF has its own IP address, and all traffic goes through this address.

Transparent Thisproxyhasthesameconditionsasthereverseproxy,withthechangethatitdoesnothaveanIPaddress.Thisisbecauseitsitsbehindanotherfirewall,anditdoesnotneedanynetworkingchanges in the server side.

Layer2bridge: In thismode, the WAFis again sittingbehind thefirewall and actslike a layer2 switch (moreaboutithere:https://en.wikipedia.org/wiki/LAN_switching).Itisamodewithhighperformance,andno

NetworkMonitormode: Inthismode,theWAFsitsoutsidethewebserver(likethecloudbasedones),whichsniffsandmonitorsallthetrafficthatheadstothewebserver.Inthissituation,theWAFisblockingun-wantedtraffic,bysendingTCPresetstointerruptit.

* WAFs have some preset rules out of the box, and of course, they get up- dated 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 Im- age 3. On the other hand, open source WAFs have their rules open, which is an open call for everyone to find by- pass methods easily, and add them to in the filter rules, which is a proven security model of the open source community.

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,weperformWAFfingerprintingtechniques,whichcanbe 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 re- quested 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. 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.

Another way of manually fingerprinting a target WAF is by examining Header alterations that a WAF may imple- ment. Some WAF products like the Netscaler again, allow the header to be rewritten and they can also make the web server to produce different HTTP responses from the common ones. This many times can confuse the attacker or automated tools that we may use.

Continuing, another interesting method is by examining the server responses. This is usually done

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 ac- companied by a message, which repels us from attacking the system. You can see a good example from the Web-Knight WAF, responding with a 999 code.

Further known methods for WAF fingerprint, are:

DropAction -SendingaFIN/RSTpacketfromtheserverorclienttoterminate aconnection(technically could also be an IDS/IPS)

Pre Built-In Rules — Each WAF has different negative securitysignatures

Side-ChannelAttacks -ManyWAFscanberecognizedbytheresponsetimeinaserverrequest(Timingbehaviour)

Originally published at https://learncybersec.blogspot.com.