IMPORTANT: this vulnerability affects websites of businesses and users.
Before publishing this vulnerability, as well as this article that describes it, we have followed a responsible disclosure by first notifying the companies affected by this vulnerability and giving them enough time to resolve it.
There are more and more businesses, organizations and users that care about the security of digital products and services.
Unfortunately, this awareness arises when there has been some type of attack or cyber-incident in which the systems of businesses have been compromised.
In addition, the complexity of technology means that there are vulnerabilities in almost all applications which can be exploited by attackers to extort or to perform targeted attacks with greater chances of success.
Vulnerabilities appear during the development of digital tools, so if they don’t appear right now, there will be in the future. Therefore, although many security flaws are resolved, new vulnerabilities always appear.
When exploiting these vulnerabilities, SQL injections are one of the most frequent attacks. For this reason, there are several solutions that prevent the infiltration of malicious code in web pages and applications.
According to the report “Web Application Attack Statistics”, during 2017, the IT and financial sector suffered a large part of the web application attacks: more than 900 attacks per day.
The Web Application Firewall (WAF) is the most used solution by companies and organizations that want to mitigate these vulnerabilities and attacks on their web applications. However, we discovered that this solution also has its problems.
What is a WAF?
A WAF is a service that analyzes and filters all HTTP requests to a web application. Also, a WAF blocks any request identified as malicious, and allows the rest.
Depending on how you configure a WAF, you can block the IP from which the malicious request originated to avoid future attacks from it.
In order to separate malicious requests from legitimate ones, a WAF analyzes the different parts of a request to a web resource. Some of those parts are headers, parameters and body of the query, among others.
During this analysis, we look for patterns that match with an attack. For example: references to file paths that contain system configurations, or code injections that allow altering queries made to a database for extracting sensitive information.
Common WAF problems
On the one hand, false positives are one of the main problems that we find in the use of WAF. These are legitimate requests that are blocked for some reason, so an application stops working.
On the other hand, a WAF generates a false sense of security among developers, system administrators and staff that are responsible for the security of companies and organizations. Security protocols are neglected and preventive measures such as code and infrastructure audits are not taken because of the use of a WAF.
Like any other application, a WAF has vulnerabilities and if it fails, your application is exposed to attacks. Hereafter, we want to demonstrate this scenario.
Vulnerabilities of WAF’s
Just take a look at the open source WAF available on the Internet to verify that Nginx is used as one of the most widespread solutions for the implementation of WAF.
Nginx is a web server that is responsible for processing web requests. It is a stable and versatile tool that allows developers to focus on the implementation of WAF through different scripts written in LUA.
Most of these open source WAF’s have the same problem: they don’t take into account that the module responsible for the integration of LUA in Nginx (lua-nginx-module) doesn’t allow access to all the information of a request.
Nothing new so far, as this information is reflected in the documentation of the module:
This means that no matter how effective a WAF is in detecting attacks, there is certain data that is invisible to its analysis. If the parameters that contain malicious data are outside the scope to which the WAF has access, it will be totally unusable.
To verify this, we have seen that WAF lua-resty-waf can block the following request which contains an injection of SQL code:
http://example.com/?param=’ OR 1=1 – –
However, when the same request contains many parameters, the injection is invisible to a WAF and therefore, it is not blocked:
http://example.com/?param=¶m=¶m=…¶m=’ OR 1=1 – –
This feature is controversial, it has been discussed for a long time. On the Internet, you can find references to this feature among the reports sent to the code repositories of these solutions.
Until now, we have analyzed the open source WAF, which means those that have been developed in a disinterested way and, of course, without any guarantee of a correct operation.
So, what about the commercial WAF providers that offer payment products and promise an almost perfect defense of their services? Let’s see.
Vulnerabilities, also in paid WAF services
CloudFlare and Cloudbric are two well-known suppliers that offer products with protection through WAF. During the tests we carried out, we found the same vulnerability in the products that both companies sell. That makes their services vulnerable and exposes their clients’ applications to possible attacks.
It must be said that in the case of Cloudbric, it is necessary to change the value of some parameter in each request to exploit this vulnerability.
In the following video, you can see that the CloudFlare WAF is not able to detect and block the malicious request when adding more parameters:
As you have seen, this vulnerability occurs when analyzing the input data, either with GET, POST parameters or with the headers of the request.
Solution to the vulnerability of the WAF
The vulnerability of WAF’s was discovered when testing the Wolf-Ray WAF. Wolf-Ray is a security layer that we have developed at Open Data Security to protect the external resources of companies and secure resources exposed to the Internet.
Upon discovering that WAF’s are vulnerable to the attacks described, we decided to dig a little deeper and find the cause of this error. In this way, we have located other commercial products that have the same problem.
To solve the vulnerability of WAF’s and implement this improvement in Wolf-Ray, we have considered multiple possibilities. Finally, we have decided to recompile lua-nginx-module with a new limit of variables to be processed, adjusting it to a level that does not interfere in the normal functioning of our clients’ applications.
With this solution, the Wolf-Ray WAF protects web resources as it blocks any request that exceeds the new limit that we have imposed. Without that limit, we can’t ensure the legitimacy of the data that is sent to the final servers.
For more information about Wolf-Ray visit this site.
- Serious vulnerability in CloudFlare that allows your WAF to be disabled - October 25, 2018
Comments are closed.