Serious vulnerability in CloudFlare allows its WAF to be rendered useless

There are more and more companies, organizations and users who are concerned about the security of digital products and services.

Unfortunately, this awareness arises when some type of attack or cyber incident has already been suffered in which company systems have been compromised.

As if that were not enough, the complexity of the technology means that in almost all applications there are errors that can be exploited by attackers to extort, or to carry out targeted, more sophisticated attacks and therefore, with a greater probability of success.

These errors are present in the applications and if they are not present in the future, they appear during the development of digital tools. Therefore, although many security flaws are currently solved, new gaps always appear.

When it comes to exploiting these gaps, SQL injections are one of the most frequent attacks. For this reason, various solutions have proliferated that prevent the infiltration of malicious code into web pages and applications.

According to the report "Web Application Attacks Statistics", during 2017, the IT and financial sector suffered a large part of the attacks aimed at web applications: more than 900 attacks per day.

The solution we are going to talk about below is the most used in the world by companies and organizations seeking to mitigate the exploitation of these vulnerabilities in their web applications. It is about the Web Application Firewall, also known as WAF.

What is a WAF?

A WAF is a service that processes and analyzes all requests that are directed to the web application. The WAF blocks any request identified as malicious directed to the application server, thus allowing the rest to pass through.

Depending on how you are configuring the WAF, it can block the IP from which the malicious request originated to prevent future attacks from it.

In order to separate malicious requests from legitimate ones, the WAF analyzes the different parts that make up a request to a web resource. Some of these parts are the headers, parameters and body of the query, among others.

During this analysis, patterns that match those of an attack are looked for. For example: references to file paths that contain system configurations, or code injections that allow altering queries made to the database to extract sensitive information.

Common WAF problems

On the one hand, among the main problems we encounter when using WAFs are false positives. These are legitimate requests that for some reason are blocked and cause the application to stop working.

On the other hand, WAFs generate a false sense of security among developers, system administrators and personnel responsible for the security of companies and organizations. Security protocols are neglected and preventive measures that are increasingly necessary, such as code and infrastructure audits, are stopped.

Like any other application, WAFs are not error-free. In this case, the serious thing is that if the WAF fails, your application is exposed to attacks as we are going to demonstrate below.

WAF Vulnerabilities

Just take a look at the open source WAFs available on the Internet to see that Nginx is used as one of the most widespread solutions for WAF implementation.

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 the WAF through different scripts written in LUA.

In most of these open source WAFs the same error occurs: they do not take into account that the module responsible for integrating LUA into Nginx (lua-nginx-module) does not allow access to all the information in the request.

This is not something new, in fact it is information that is reflected in the module documentation:

In other words: no matter how effective it is in detecting attacks, There are certain data that are invisible to the WAF. If we manage to ensure that the parameters that contain malicious data are outside the scope to which the WAF has access, it will be completely unusable.

To verify this, we have seen that the WAF lua-resty-waf may block the following request which contains a SQL injection:

On the other hand, when the same request contains many parameters, the injection is invisible to the WAF and therefore is not blocked:

The truth is that this is no discovery. This characteristic is controversial, it has been discussed for a long time and references to it can be found on the Internet among the reports submitted to the code repositories of these solutions.

We have to think that until now we have analyzed open source WAFs, that is, those that have been developed selflessly and of course without guarantee of correct functioning.

But what about commercial WAF providers that offer paid products and promise near-perfect defense of their services? Let's see.

Vulnerabilities, also in payment WAFs

CloudFlare and Cloudbric are two well-known vendors that offer products with WAF protection. During the tests carried out, we have found the same vulnerability in the products that both companies sell. This makes them 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 how by adding more parameters, CloudFlare WAF is not able to detect and block the malicious request:

As you have seen, this vulnerability occurs when analyzing the input data, both with GET and POST parameters or with the request headers.

Solution to WAF vulnerability

The WAF vulnerability was discovered when testing the Wolf-Ray WAF, the protection layer that we have developed at Open Data Security to protect companies' external resources and secure resources exposed to the Internet.

Upon discovering that the WAF is vulnerable to the described attacks, we decided to dig a little deeper and find the cause of the error. In this way, we have located other commercial products that suffer from the same problem.

To solve the WAF vulnerability 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 process, adjusting it to a level that would not interfere with the normal functioning of our clients' applications.

This way, The Wolf-Ray WAF protects web resources by blocking any request that exceeds the new limit we have tax. Without this limit, we cannot ensure the legitimacy of the data that is sent to the final servers.

For more information, visit the website: Wolf-Ray.