On December 8th 2022, security researchers from Claroty Research published details of a novel WAF bypass technique using JSON syntax to bypass SQL injection signatures, which was tested successfully against a range of WAF vendors including those operated by RedShield.  On the same day, this bypass capability was added to the popular SQL injection test toolkit SQLmap.

What actions has RedShield taken since these WAF bypass techniques were published?

Claroty ‘responsibly disclosed’ in early 2022 to the WAF market and hence updates that mitigated this general bypass technique were available from 15 March 2022. RedShield customers have had these updates applied since the time of release, and are not affected by this general bypass.

 

Post the 8th of December release, RedShield’s research team has discovered a number of theoretical evasions and hence developed and deployed signatures to address these to both the component WAFs for defense and scanners for assurance.

We will continue to monitor bulletin boards and hacker forums for evasion techniques and modify our defenses accordingly. In addition we have supplied our bypass research to approved suppliers and will replace our custom signatures with their commercial sets once available.   

WAF bypass proven to always be theoretically possible in 2005

WAF bypass techniques like those recently published by the researchers @Claroty are inevitable.  As WAFs rely on classification of user input, the mathematics proving theoretical bypass is always possible was presented at Blackhat in 2005.

 

The central concept of the proof is that users have an infinite scope of items that they can try, whilst classification is a finite process.

Given new bypass techniques are inevitable, how does RedShield provide surety around protection for injection issues?

RedShield follows the OWASP recommendation to resolve injection through parameterizing or escaping user input, rather than simply relying on signatures.

 

To achieve this, RedShield develops, customizes and maintains Edge Compute shields that escape user input (equivalent to converting all input to text) external to the source code of an application. With this approach, input from all users is transformed to harmless  and hence the parameter is securely processed. A signature-based determination of whether the payload is good or bad is no longer required as it is not possible for escaped malicious payloads to detonate.

 

That said, a WAF, when configured correctly and actively maintained, can be extremely effective at minimizing injection risks and based on the techno-economics of the risks in question may be an appropriate risk containment technique. The maintainer must however diligently apply new signatures and resolve bypass techniques as either become available.

 

In addition to WAF injection signatures, additional reverse proxy controls are recommended to contain injection exploitation risks. Using Cross Site Scripting as an example in addition to escaping is impractical, RedShield implements the following controls in addition to user input signature detection:

1.   Implementing CORS or CSP headers to stop external scripts being referenced

2.  Limiting the input length of the affected parameter to restrict the size of any obfuscated script

3.  Encoding the output from the database

4.  Strictly enforcing the content type in the response

The positive side effect of strong hygiene policies

Implementing the broad practical range of signature and bypass detection plus implementing fairuse policies, like those listed above has the additional benefit of providing the best resistance to zero day exploits. 

 

Continually maintaining signatures sets and bypass techniques in blocking limits an attackers freedom to operate undetected. Applying maintained signature and bypass detection should also be coupled with additional controls on the reverse proxy hosting the WAF to narrow the exploit vector further.

 

A retrospective review of logs prior to the Log4Shell exploit, one year ago, revealed that a number of malicious payloads were blocked due to this narrowing of freedom to operate in the couple of hours it took RedShield to deploy direct mitigation shields.

Full zero day response is an incident response process

'Zero Day Exploits' are by definition previously undisclosed techniques. Hence, on publication, a race condition exists between attackers and defenders. Relying on hygiene defenses is not enough, to act with the required speed requires the following: 

1.   Knowledge of which applications are exploitable

2.  The skills to either fix or contain the flaw, and

3.  The operational process knowledge to ensure that resolving this security issue does not impact            the availability or performance of the application.

 

To achieve this RedShield maintains pre-agreed change management procedures and operational readiness plans, maintains updated inventories of component technologies and vulnerabilities for each application under management, and actively monitors a wide range of security intelligence sources for relevant exploit publications. 

How does RedShield maintain a robust signature set, in blocking mode?

RedShield's standard operating procedures maximize the signature sets in blocking whilst minimizing the foreseeable disruption to normal transactions, plus responding to any incidents reported across:

1.   Incompatibility

2.  Vulnerabilities

3.  Published exploits and bypasses pusblished

4.  Personal identifiable information detected

 

RedShield uses the following priorities to ensure that the broadest set of signatures is deployed to meet each application's acceptable risk profile:

1.   If the application is knowingly exploitable, escaping is recommended, and/or WAF and reverse          proxy detection and containment is deployed.

2.  If the application is non knowingly exploitable, then the WAF and reverse proxy signature set               and  hygiene controls are still deployed, however these are tuned for foreseeable compatibility           issues. For avoidance of doubt, if there is a risk that blocking matches against particular classes           of signature will disrupt the normal functioning of the application without mitigating any known         or foreseeable actual security risk, then RedShield will log the traffic, but allow it to reach the                 application. 

Dual weekly audits are used to manage and report on the risks:

1.   By running against the shielded instance, the efficacy of the defenses is confirmed

2.  By running against the unshielded site they highlight the exploitability of the site

 

When deploying signatures in both WAF's and scanners, RedShield has a preference for commercially supported software, however for speed, RedShield's own research team regularly develops and applies custom signatures ahead of the commercial vendors, plus maintains a higher degree of vigilance to published bypasses.

 

Learn more about RedShield's managed web application security services

Get in touch with RedShield's Solutions Architect team to discuss options for protection.

 

Next article: Comparing the RedShield-AWS DDoS Solution to Market Alternatives
All Knowledge base

See how we can shield your web applications and APIs

Get a free trial or talk to one of our experts

Free trial
or
Talk to us