Whitelisting Penetration Testers on Your WAF
Whitelisting Penetration Testers on Your WAF
Reasons Behind The Method | Penetration Testing Informational Blog
Penetration testing is a reality for any company that takes security seriously. Not only is it an important part of any serious cybersecurity program, it’s also required by most major compliance frameworks. Unfortunately, many organizations make a serious mistake when buying penetration testing services for their web applications: they don’t whitelist the tester on their Web Application Firewall (WAF).
And on the surface, that makes sense. After all, the customer wants to know if their web application can be exploited from outside the organization. And, of course, anyone who wants to attack the application will have to go through the WAF.
Penetration testers are supposed to be good at hacking. Surely they should be able to figure out a way to evade the WAF to test the application? As logical as these ideas may seem, they are (at best) misguided and misinformed.
Here’s why:
1
If they aren’t whitelisted, a penetration tester is really testing your WAF
There’s nothing wrong with having your WAF tested. After all, you need to know if it’s doing its job properly by testing its configurations, policies, and deployment however, a WAF test is not the same thing as a penetration test. The things a tester needs to do to fully test your WAF are not necessarily the same as what they’ll do to bypass your WAF to attack a specific application.
So, by all means, have your WAF tested — but keep it as a separate exercise to penetration testing your applications.
2
Penetration tests are typically billed by the hour
Bypassing a strong WAF is not trivial. It takes time. And, as noted above, penetration tests are billed by the hour or purchased in blocks of hours. Simply put, if your penetration tester has to spend time evading your WAF, it will take longer — and cost more — to complete a thorough test.
3
Penetration tests are conducted under time constraints — cyberattacks aren’t
In most cases, penetration testing is conducted over an agreed number of hours or defined level of effort which equates to a specific investment. Evading your WAF may be a slow process, leaving insufficient time to test the actual application — particularly if the engagement hours are low or restricted due to budget constraints.
At MegaplanIT, our penetration testing engagements last a minimum of 60 – 80 hours, with longer tests running as high as 160 – 300+ hours. For a high-value target, attackers may be willing to spend much longer than this to find and exploit a vulnerability. If you want your application to have a chance of withstanding serious, prolonged attacks, you need maximum efficiency from your penetration test investments.
Keep in mind that “high-value” targets are subjective. An application that may seem of minor importance to you could be very valuable to an attacker. This is particularly likely if it’s hosted on the same server as other applications, as compromising one application may allow access to the others.
4
Real vulnerabilities could be missed without whitelisting
The most important reason why it’s important to whitelist penetration testers is simple: If you don’t, there’s every chance a serious vulnerability will be missed.
Your penetration tester might take a long time to evade your WAF, or may not be able to evade it at all. In either case, when the engagement comes to an end you won’t know about real vulnerabilities that have been missed.
Of course, this begs another question:
If the WAF prevents the tester from finding or exploiting a vulnerability, does it really matter?
AFTER ALL.....
No Harm
No Foul
RIGHT?
1
If they aren’t whitelisted, a penetration tester is really testing your WAF
There’s nothing wrong with having your WAF tested. After all, you need to know if it’s doing its job properly by testing its configurations, policies, and deployment however, a WAF test is not the same thing as a penetration test. The things a tester needs to do to fully test your WAF are not necessarily the same as what they’ll do to bypass your WAF to attack a specific application.
So, by all means, have your WAF tested — but keep it as a separate exercise to penetration testing your applications.
2
Penetration tests are typically billed by the hour
Bypassing a strong WAF is not trivial. It takes time. And, as noted above, penetration tests are billed by the hour or purchased in blocks of hours. Simply put, if your penetration tester has to spend time evading your WAF, it will take longer — and cost more — to complete a thorough test.
3
Penetration tests are conducted under time constraints — cyberattacks aren’t
In most cases, penetration testing is conducted over an agreed number of hours or defined level of effort which equates to a specific investment. Evading your WAF may be a slow process, leaving insufficient time to test the actual application — particularly if the engagement hours are low or restricted due to budget constraints.
At MegaplanIT, our penetration testing engagements last a minimum of 60 – 80 hours, with longer tests running as high as 160 – 300+ hours. For a high-value target, attackers may be willing to spend much longer than this to find and exploit a vulnerability. If you want your application to have a chance of withstanding serious, prolonged attacks, you need maximum efficiency from your penetration test investments.
Keep in mind that “high-value” targets are subjective. An application that may seem of minor importance to you could be very valuable to an attacker. This is particularly likely if it’s hosted on the same server as other applications, as compromising one application may allow access to the others.
4
Real vulnerabilities could be missed without whitelisting
The most important reason why it’s important to whitelist penetration testers is simple: If you don’t, there’s every chance a serious vulnerability will be missed.
Your penetration tester might take a long time to evade your WAF, or may not be able to evade it at all. In either case, when the engagement comes to an end you won’t know about real vulnerabilities that have been missed.
Of course, this begs another question:
If the WAF prevents the tester from finding or exploiting a vulnerability, does it really matter?
AFTER ALL.....
No Harm
No Foul
RIGHT?
Well Not Exactly....
When a WAF prevents penetration testers from thoroughly testing an application — and causes them to miss real vulnerabilities — the customer organization misses the opportunity to find out about the root causes of vulnerabilities.
For example, maybe the organization’s app developers are using insecure coding practices. This is actually very common because most developers aren’t security experts. And if the organization doesn’t know that, because vulnerabilities aren’t being uncovered, those developers will keep on coding insecurely.
And that’s not the only reason why organizations shouldn’t rely exclusively on their WAF to protect web applications.
Here’s the real takeaway:
WAFs Are Great… But Not Perfect
Let’s be clear about one thing:
WAFs are not infallible.
If they were, nobody would need to worry about penetration testing. They would simply implement a WAF and tick application security off of their to-do list. To understand why that would be a bad idea, you need some basic knowledge of what WAFs actually do.
Fundamentally, WAFs work in one of three ways:
Blacklist
Allows any traffic to pass through unless it has been specifically banned. Blacklist WAFs are often cloud-based, are very easy to set up, and require minimal maintenance. For these reasons, they are by far the most popular choice. They are also the easiest WAFs to bypass.
Whitelists
block all traffic unless it has been specifically allowed. WAFs that use whitelists are more secure than blacklists, but are hard to set up and require a significant amount of ongoing tuning and maintenance.
Combination
WAFs that combine both blacklists and whitelists are, unsurprisingly, the most secure option — but they are also the most expensive, hardest to maintain, and most likely to accidentally block legitimate traffic.
Blacklist
Allows any traffic to pass through unless it has been specifically banned. Blacklist WAFs are often cloud-based, are very easy to set up, and require minimal maintenance. For these reasons, they are by far the most popular choice. They are also the easiest WAFs to bypass.
Whitelists
block all traffic unless it has been specifically allowed. WAFs that use whitelists are more secure than blacklists, but are hard to set up and require a significant amount of ongoing tuning and maintenance.
Combination
WAFs that combine both blacklists and whitelists are, unsurprisingly, the most secure option — but they are also the most expensive, hardest to maintain, and most likely to accidentally block legitimate traffic.
Since blacklist WAFs are by far the most popular option
Here’s a high-level overview of some of the many ways they can be circumvented:
Encoding Requests
Since most WAFs rely on blacklists to identify and block malicious requests, one technique attackers can use is to encode their requests. While far from a sure thing, this simple technique is sometimes enough to bypass a WAF.
Attack payload obfuscation
Again, most WAFs are set up to block payloads that are known to be malicious. But if those payloads are slightly altered they may slip by unnoticed.
New or missed payloads
Any malicious payloads or requests are not yet included in the WAF blacklist (or have been missed accidentally) will be treated as legitimate traffic.
Large requests
Strange as it may sound, many WAFs ignore very large requests because not doing so would cause significant performance issues.
Finding exceptions
Many WAFs are set up with exceptions to their normal ruleset to prevent known issues. For example, if a WAF has been erroneously blocking traffic from a certain type of device, it may be configured to accept everything from those devices to ensure legitimate traffic isn’t blocked. Attackers have various techniques at their disposal to track down these exceptions and may be able to exploit them once identified.
Taking over legitimate accounts
One of the most common tactics used to breach a target network is to take over a genuine user account. This can be done via “credential stuffing” (automatically trying millions of credential combinations until a hit is found) or by tricking a user into giving up their credentials. Either way, once an attacker has access to a genuine account, they can continue the rest of their activities freely without needing to manually evade the WAF.
To Summarize
As valuable as a WAF is for application security, it’s far from a perfect solution. And while it’s admittedly more difficult to circumvent whitelist and combination WAFs, it can still be done in a variety of ways. In fact, there are literally thousands of articles and video guides created by security experts and hackers that teach would-be attackers (and pentesters) how to bypass different types of WAF.
And it’s not always the fault of the WAF itself when things go wrong.
WAFs can go down. They can be misconfigured. Any number of technical issues that aren’t directly related to the WAF itself can prevent it from functioning properly. And when that happens, it’s important to know that your web applications are resistant to cyberattack.
Feeling a bit less certain about the security of your organization’s assets? That’s a good thing. Once you recognize that putting a WAF in front of your web applications doesn’t completely solve the problem of security, other measures — including penetration testing — become a higher priority.
The Best Compromise = DO BOTH!
There are plenty of reasons why it’s a good idea to whitelist penetration testers on your WAF. But that doesn’t mean there’s no value in finding out whether identified vulnerabilities can be exploited without the tester being whitelisted.
One excellent approach is to have your testers spend the majority of the engagement checking for vulnerabilities while whitelisted. Then, towards the end of the engagement, you can revoke their whitelist privileges to see if they can still exploit any identified vulnerabilities while evading the WAF.
If the testers are able to exploit identified vulnerabilities while evading the WAF, fixing those vulnerabilities should be a very high priority. If they can’t, it’s still important to fix them, but you can take some comfort in knowing your WAF is working as intended — at least for now.
See What We're About
As cyber threats grow in number and sophistication, many organizations are turning to managed security service providers to help secure their digital assets and data. Based at our 24/7/365 cutting-edge security operations center in Scottsdale, Arizona, we provide a suite of managed services to ensure your business stays safe from cyber attacks.
At MegaplanIT, our expert QSAs are fully certified and have decades of experience helping businesses like yours stay compliant with industry frameworks all year round. We build long-term relationships with our customers and provide holistic services to meet all your security and compliance needs.
The vast majority of security breaches are made possible by vulnerabilities and configuration errors in an organization’s network or applications. Our fully certified security testing services are designed to help you find and fix weaknesses in your networks and applications, and prepare you digital infrastructure to withstand the latest cyber threats.
MegaplanIT provides comprehensive, PCI-DSS approved testing for any web application, API, or web service. Following testing, we produce a comprehensive report that highlights any issues identified and provides specific recommendations for quick and efficient remediation. With our convenient Pen Testing portal, you can easily get the reports you need, provide feedback on any identified findings, schedule future tests, and approve additional application scope as needed.