Web application firewalls bypasses collection and testing tools

How to test, evaluate, compare, and bypass web application and API security solutions like WAF, NGWAF, RASP, and WAAP

How hackers community cracked Imperva anti-bot solution

In the modern web, it’s not a surprise that your application can become a target for a lot of different visitors and not all of them are human beings, of course. There are plenty of automated guys around: from good-old search engine robots to sophisticated armed to the teeth bots, scrapers, scanners, and so on. 

To protect applications from all the bad robots, anti-bot solutions come into play, and one of the most popular ones is the Imperva Incapsula Advanced Bot Protection solution.

Imperva offers some methods, like cookie challenge or its modification – JavaScript cookie challenge, to defend applications from bots that can not use JavaScript or not able to handle cookies.

What’s the incapsula-cracker project?

But, it’s always a big and popular question – how to bypass it? Bot-makers and anyone who tries to use any bots always plays in cat and mouse with antibot solutions. To answer this question in general, several projects exist, one of the oldest ones is an incapsula-cracker (https://github.com/ziplokk1/incapsula-cracker-py3).   

As for now, incapsula-cracker is not up-to-date and can not cover up all the solution’s changes, but the idea behind this and the way of bypassing is really interesting and still the same – and that’s what we are looking forward to. 

Simply put, incapsula-cracker tries to re-implement part of the javascript logic delivered by Incapsula anti-bot solution on the client-side, but with Python, instead of browser appliance. For example, incapsula-cracker spoofs all the browser checkings by re-implementing JavaScript function on the python-cracker side – basically, incapsula-cracker sends all the browser flags (such as “navigator.webdriver”, which is works like a bot-flag, or special browser-related flags like “chrome”, “opera”, “yandex” and so on) manually, so it becomes impossible to Incapsula to detect if it sent from a browser or by another method. So, it’s easy for a cracker to bypass the browser check, even when it looks really complicated

Also, besides this, the cracker collects all the required parameters and JavaScript variables from the provided scripts just to calculate and process it the same way as it was with the browser flags. Basically, the cracker is able to use some regular expression for it, and then it can calculate it on the Python side too. So, here we have full logic re-implementation which can be handled on the side of the client, without any browser or JavaScript engine. 

More interesting is that the community around it is really passionate about the way of solving the problems, their discussions and thoughts about “how to solve it better” can be seen in the issues with a lot of technical details:
https://github.com/ziplokk1/incapsula-cracker-py3/issues/4

It’s worth mentioning that besides the fact that all of the provided JavaScript scripts are obfuscated or packed, it’s not a big problem to unpack and deobfuscate them – it’s just a matter of time (and sometimes the size of the community and interested people in it), so obfuscation is not a silver bullet in terms of protection the logic in any way, but can be an additional “step to solve” for the bot-maker.

The other community project incapsula-bypass

Another example of bypassing provided by the incapsula-bypass project (https://github.com/Imbuedhush/Incapsula-Bypass), which uses a kind of additional local JavaScript server to use parts of the provided scripts more naturally. But the idea is still the same here, we collect some scripts and values from the incapsula response, send it to our evaluation donor to solve and create the required cookie, and after that we all set and ready to fire up the original request.

What motivates the community?

The most interesting thing here is the motivation and interest of the community in the cracking of it in general – it’s not about an Imperva at all, it’s about the process. A lot of discussions about re-implementation can be seen in issues, a lot of improvements or reverse-like solutions were proposed by the community – and now, even when some of the solutions don’t work or update anymore, it’s still can be seen that interest in it is not over.

But as for now, unfortunately, it becomes more commercial and not so open-source as it was before – currently, solutions with improvements and fixes can be seen on the markets (for example, https://bhf.im/threads/609788/). Basically, some of them is a modified version of the original ones open-source solutions from GitHub, but with some new features and additions.

Conclusions

In conclusion, it’s worth saying that this kind of solution exists for mostly all of the bot solutions, and the difference here only in the answer for the question: “How complicated and hard would it be to break through it?”

%d bloggers like this: