Cloud based WAF against cyber attacks? - Part II
The above Figure shows a very abstract architecture where we have two separate network lines from two different service provider, in order to ensure availability if one line is down.
Then in any typical network we have network firewall where we create Access Control Lists (ACL) based on the company’s policies and requirements. After the network firewalls, we have two separate Web Application Firewalls. From the implementation point of view different kinds of WAFs provide different features as far as the operations is concerned, in some cases they can communicate with each other in order to maintain the configuration synchronized via a single management console and in some cases one needs to manually merge the changes from one WAF to another.
Now considering the Figure given above, for all the applications that are hosted into the data center and registered into WAF, all the traffic is passing by WAF. And from company to company there may be some other security measures as well e.g., IDS and IPS etc.
In most of the web applications the GET parameter becomes the part of URL e.g., http://www.someurl.com/search/?q=”onmouseover=”ale... In my previous blog, the attack vector was part of the GET parameter (Search Query) as you can see below
But in this case, web application is using base64 encoding (in the form of a JavaScript function) on the client-side before sending the data to the server and therefore the GET parameter in the URL is in encoded form. If you try to use any base64 decoding then you can easily analyze what the result could be, as an example below:
JTIyb25tb3VzZW92ZXIlM0QlMjJhbGVydCgxKQ== = %22onmouseover%3D%22alert(1)
Source: https://www.base64decode.org/
Note: This clearly means that the Cloud based WAF(Sucuri) couldn’t able to parse the malicious query in the URL and hence it is clearly bypassed.
Now out of my curiosity I wanted to verify again whether this issue was fixed or not so I tried the same malicious vector but this time there was no popup so I tried to check the source and the attack vector was clearly visible in the source that means that WAF was again bypassed because of the same reason (base64 encoding).
But this time as we can see the developers have removed “=”, () unfortunately even after some efforts from the developers we can still insert malicious JavaScript code within the attribute context and and closes the tag prematurely. Moreover as the developer is remove parentheses so instead of (), we can use `` as according to new ECMA Script Template strings allows embedded expressions. You can use multi-line strings and string interpolation features with them
and the result was as follows:
Decoded String: JTIyJTNFJTNDc2NyaXB0JTNFY29uZmlybSU2MDElNjAlM0MlMkZzY3JpcHQlM0U= = %22%3E%3Cscript%3Econfirm%601%60%3C%2Fscript%3E
Source: Gartner Magic Quadrant
As you can see above there are mainly 4-5 big players based on the report from Gartner - July 2015. Unfortunately Sucuri is not mentioned there but what I would like to point out is whether the other WAFs supports base64 decoding or not?
And I have found some evidences as follows:
- Barracuda WAF
Base64 Decode Parameter Value - Set to Yes to apply base64
decoding to the parameter values. If the parameter value adheres to the Data URI Scheme, the base64 decoding is applied on the parameter value irrespective of Base64 Decode Parameter Value is set to Yes or No. If not, the base64 decoding is applied to the parameter value only when Base64 Decode Parameter Value is set to Yes. Once the decoding is successful, other parameter checks are enforced as per the policy settings.
Source: Barracuda Base64
- F5
Adding base64 decoding to a new user-input parameter When enabled, the system can apply base64 decoding for a user-input parameter. If the decoding is successful, the system applies the parameter checks specified in the security policy. If the decoding is not successful, the system issues the Illegal base64 parameter value violation and responds to the offending request according the associated blocking policy
Source: F5 - Base64
Sucuri Vulnerable Outdated Software If existing detection signatures are unable to separate legitimate requests from malicious ones, our heuristic detection and auditing will flag new samples for research. The new signature is quickly analyzed and decoded. In a recent vulnerability that our research team discovered and disclosed responsibly, the exploit used a base64 encoded string to send its malicious payload, which is hard to detect as it only contained random alphanumeric characters. To detect it, the Website Firewall was set to review different elements such as the size of the particular parameter:
Source: SUCURI - Base64
Summary :
The purpose of WAF is to provide an extra layer of protection against the attackers but one should always prioritize the “secure coding” instead of relying solely on WAF.
e.g. always consider the white-list approach.
And if an enterprise is using a WAF then they should continuously monitor the logs and fine tune the policies in WAF based on the false positives and attacks. Moreover they should clearly identify the use cases before implementing any WAF i.e. they should verify the capabilities of WAF whether it suits their environment or not.
The above Figure shows a very abstract architecture where we have two separate network lines from two different service provider, in order to ensure availability if one line is down.
Then in any typical network we have network firewall where we create Access Control Lists (ACL) based on the company’s policies and requirements. After the network firewalls, we have two separate Web Application Firewalls. From the implementation point of view different kinds of WAFs provide different features as far as the operations is concerned, in some cases they can communicate with each other in order to maintain the configuration synchronized via a single management console and in some cases one needs to manually merge the changes from one WAF to another.
Now considering the Figure given above, for all the applications that are hosted into the data center and registered into WAF, all the traffic is passing by WAF. And from company to company there may be some other security measures as well e.g., IDS and IPS etc.
In most of the web applications the GET parameter becomes the part of URL e.g., http://www.someurl.com/search/?q=”onmouseover=”ale... In my previous blog, the attack vector was part of the GET parameter (Search Query) as you can see below
But in this case, web application is using base64 encoding (in the form of a JavaScript function) on the client-side before sending the data to the server and therefore the GET parameter in the URL is in encoded form. If you try to use any base64 decoding then you can easily analyze what the result could be, as an example below:
JTIyb25tb3VzZW92ZXIlM0QlMjJhbGVydCgxKQ== = %22onmouseover%3D%22alert(1)
Source: https://www.base64decode.org/
Note: This clearly means that the Cloud based WAF(Sucuri) couldn’t able to parse the malicious query in the URL and hence it is clearly bypassed.
Now out of my curiosity I wanted to verify again whether this issue was fixed or not so I tried the same malicious vector but this time there was no popup so I tried to check the source and the attack vector was clearly visible in the source that means that WAF was again bypassed because of the same reason (base64 encoding).
But this time as we can see the developers have removed “=”, () unfortunately even after some efforts from the developers we can still insert malicious JavaScript code within the attribute context and and closes the tag prematurely. Moreover as the developer is remove parentheses so instead of (), we can use `` as according to new ECMA Script Template strings allows embedded expressions. You can use multi-line strings and string interpolation features with them
and the result was as follows:
Decoded String: JTIyJTNFJTNDc2NyaXB0JTNFY29uZmlybSU2MDElNjAlM0MlMkZzY3JpcHQlM0U= = %22%3E%3Cscript%3Econfirm%601%60%3C%2Fscript%3E
Source: Gartner Magic Quadrant
As you can see above there are mainly 4-5 big players based on the report from Gartner - July 2015. Unfortunately Sucuri is not mentioned there but what I would like to point out is whether the other WAFs supports base64 decoding or not?
And I have found some evidences as follows:
- Barracuda WAF
Base64 Decode Parameter Value - Set to Yes to apply base64
decoding to the parameter values. If the parameter value adheres to the Data URI Scheme, the base64 decoding is applied on the parameter value irrespective of Base64 Decode Parameter Value is set to Yes or No. If not, the base64 decoding is applied to the parameter value only when Base64 Decode Parameter Value is set to Yes. Once the decoding is successful, other parameter checks are enforced as per the policy settings.
decoding to the parameter values. If the parameter value adheres to the Data URI Scheme, the base64 decoding is applied on the parameter value irrespective of Base64 Decode Parameter Value is set to Yes or No. If not, the base64 decoding is applied to the parameter value only when Base64 Decode Parameter Value is set to Yes. Once the decoding is successful, other parameter checks are enforced as per the policy settings.
Source: Barracuda Base64
- F5
Adding base64 decoding to a new user-input parameter When enabled, the system can apply base64 decoding for a user-input parameter. If the decoding is successful, the system applies the parameter checks specified in the security policy. If the decoding is not successful, the system issues the Illegal base64 parameter value violation and responds to the offending request according the associated blocking policy
Source: F5 - Base64
Sucuri Vulnerable Outdated Software If existing detection signatures are unable to separate legitimate requests from malicious ones, our heuristic detection and auditing will flag new samples for research. The new signature is quickly analyzed and decoded. In a recent vulnerability that our research team discovered and disclosed responsibly, the exploit used a base64 encoded string to send its malicious payload, which is hard to detect as it only contained random alphanumeric characters. To detect it, the Website Firewall was set to review different elements such as the size of the particular parameter:
Source: SUCURI - Base64
Summary :
The purpose of WAF is to provide an extra layer of protection against the attackers but one should always prioritize the “secure coding” instead of relying solely on WAF.
e.g. always consider the white-list approach.
And if an enterprise is using a WAF then they should continuously monitor the logs and fine tune the policies in WAF based on the false positives and attacks. Moreover they should clearly identify the use cases before implementing any WAF i.e. they should verify the capabilities of WAF whether it suits their environment or not.
Comments
Post a Comment