Using A Server Side Interception Proxy To Fix (Not Block) an SQL Injection

Using A Server Side Interception Proxy To Fix (Not Block) an SQL Injection

THE SITUATION

During a routine application penetration test an SQL injection vulnerability was discovered for a public banking application. The pen tester was then able to demonstrate a technique via SQLMap to extract all usernames and hashed passwords and then brute force specific user passwords in a matter of minutes.

The nature of the application meant that the problem was systematic within the code and hence fixing quickly was not practical. Attempts were made to change permissions on the database to stop the exploit, however the Pen Tester proved it was possible to bypass this control.

Given the Bank had already engaged RedShield with a generic trial, the trial was extended to address the issues highlighted in the pen test report including this one.

 

OUR SOLUTION

RedShield’s shielding team immediately swung into action and produced a shielding plan for all reported issues. Given the application was susceptible to SQLi, a shield that escaped all user input was developed. This shield blocks nothing but rather transforms all user input to text, so that the exploit is no longer possible, just like a software developer would.

The WAF style REGEX blocking of suspicious input is too limited in such a sensitive information case. It has been formally proved that for any regex validator it is possible to construct either a safe query which would be flagged as dangerous, or a dangerous query which would be flagged as safe1.

 

Faced with taking our key client application offline, RedShield responded with the speed & accuracy that we needed. Dual confirmation from security audit companies has given us confidence in their shields. The fact that no customers can be blocked by mistake is also a bonus, and something I was not aware was possible before this engagement.

 

THE RESULT

In less that 1 day from engaging RedShield, the application specific shields were deployed in a test environment.

Testing from the Pen Tester then confirmed that the shields were effective to their reported exploit methods.

Given the sensitive nature of the problem a second Pen Testing company was also engaged, they were informed that RedShield was protecting the site and that the scope of work was to attempt to bypass the deployed shields.

They reported back that ‘as the application was not susceptible to injection [they] should be given a more vulnerable application to test the limits of RedShield’s shielding capabilities.’

Note: normally these type of tests do reveal more vulnerability intelligence that RedShield then iterates with the Pen Tester to solve. Just not in this particular case. RedShield would claim that to be more secure you should discover more application specific issues that RedShield can then fix.

Before the results of the 2nd Pen Testing report were available the shields were placed on the production site, where they will remain until the developers have either remediated the code fully or replaced the application.

 

1 Robert J. Hansen, Meredith L. Patterson, Guns and Butter: Towards Formal Axioms of Input Validation, Department of Computer Science The University of Iowa Iowa City, Iowa, 2005

May 21, 2020