Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Cross-Site Tracing (XST) security vulnerability 13 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • If I understand how it works correctly, it goes a bit like this:

    I connect to malicious web server (or hacked friendly one)
    That web server sends me some javascript
    That javascript sends a TRACE request to some site it knows I use
    The TRACE request bounces back my cookies/credentials
    The javascript thus has access to those credentials that it didn't know how to get at before
    The malicious web server can then re-use these credentials in other attacks

    It's an interesting attack vector. I like it. One more reason n
    • I think that's a nice summary.

      #That javascript sends a TRACE request to some site it knows I use

      My only quibble is that for this attack to be useful to the person who initiates it, the TRACE must be sent to a server that you have already authenticated against -- otherwise, TRACE will not return the authentication string. Practically speaking, then, this is an attack from a hacked friendly server (because a malicious server would be able to access your authentication information directly), and the TRAC
      • Most sites that any user would be interested in stealing the credentials from will be cookie based logins. Thus it doesn't matter that much where it all happens, I don't think.

        My guess though is that this is really a bug in xmlHTTP (on both Mozilla and IE) because it really shouldn't send these credentials via TRACE, IMHO. And it's access to the credentials thats the issue.
        • #Most sites that any user would be interested in stealing the
          #credentials from will be cookie based logins

          That may well be true. I am not aware, for instance, of any financial institutions that use HTTP Basic authentication. (Because, let's face it, transferring the username and password in cleartext look's pretty silly from our perspective today). However, existing XSS attacks allow you to access a user's cookie -- the XST attack is interesting because it gives you access to the authentication strin
          • Some of the commentary on Bugtraq has made a similar point, that XMLHTTP should not allow you to make a TRACE request at all. To be clear, however, the HTTP spec is "at fault" for the decision to return the authentication string during a TRACE request. And the folks implementing the HTTP spec in servers like Apache perhaps share a bit of the "blame", as they don't provide a method to turn off TRACE requests. (The method that I mentioned in the original post uses mod_rewrite.)

            I strongly disagree. At the e
            • #Of course at the end of the day, just like XSS bugs,
              #we'll rarely see this used in practise.

              I agree with this part of your post. The more I think about this particular exploit, the less of a threat I think it represents. It's trivial to forbit TRACE requests if you run a mod_rewrite-enabled Apache, and you should not use HTTP Basic Authentication to secure anything important, for the same reason security-conscious organizations don't use telnet: passwords are sent in cleartext.

              #I strongly disagree
              • No, I believe in the TRACE situation that xmlHttp (which is what is responsible for accessing the credentials in the first place - any other http library wouldn't have access to them) should not include anything the programmer didn't specify in the headers.
                • Hmmm.

                  Somehow, we're talking past each other. Let me define a set of assumptions, because I think that will help us move past this.

                  XMLHTTP is analagous, in a sense, to LWP in Perl. It essentially lets you call a web browser from JavaScript (or VBScript, etc.). According to Microsoft [microsoft.com] , a "client computer can use the XMLHTTP object (MSXML2.XMLHTTP) to send an arbitrary HTTP request, [and] receive the response".

                  One of those arbitrary HTTP requests is an HTTP TRACE. According to the HTTP protocol [w3.org],
                  • OK, let me be a little clearer here.

                    If you tried this using (say, for example) LWP wrapped up as a COM object, so that it would be accessible via JavaScript (you can probably do this with the neat tools that ActiveState provide), you would have no vulnerability.

                    Why? Because xmlHttp has EXPLICIT access to the credentials that are internal to IE, and IE passes them to xmlHttp AUTOMATICALLY. No other HTTP library gets such priviledges.

                    Now do you understand why I think this is a bug in xmlHttp? - the very fa

                    • Re:Hmm... (Score:1)

                      by cbrooks (3267) on 2003.01.27 10:43 (#16418) Journal
                      #xmlHttp has EXPLICIT access to the credentials that are internal to IE,
                      #and IE passes them to xmlHttp AUTOMATICALLY. No other HTTP library
                      #gets such priviledges.

                      I believe this [microsoft.com] is what you're referring to:
                      Internet Explorer and various other Windows components (the XMLHttp class of MSXML, for example) use WinInet for their underlying HTTP communications. If you were to write the WinInet code directly, you would have to deal with the authentication challenge programmatically. Internet Explorer and those other Windows components instruct WinInet to respond to the authentication challenge by sending the system credentials of the current security context after the initial challenge. This makes it seem like it works magically (without authentication), but if you sniff the transmission using a trace utility (see the previous question), you'll see that multiple requests are indeed taking place and that credentials/tokens are being sent.

                      As I read this quote, it is saying that: (1) If XMLHTTP requests a page which responds with a 401 error and an HTTP Basic authentication challenge; (2) XMLHTTP will call WinInet, which checks to see if the user has configured IE such that IE should attempt to authenticate for the user (using their previously specified userid and password.) Then (3) WinInet will complete the challenge / authentication process without user input, and, if authentication is successful, WinInet will hand the authentication tokens to XMLHTTP so that XMLHTTP can construct the correct HTTP headers for the request.

                      So, it appears that there IS an additional vulnerability here that I was not aware of, and that (narrowly speaking) it would not affect LWP in your first sentence. That vulnerability is that when the JavaScript function (inserted through some XSS hole by an evil hacker) calls XMLHTTP, WinInet might actually authenticate for the user, even if the user had not previously authenticated. If the request would fall inside a security context that the user has previously defined as one for which their browser should authenticate them, XST is one method that could be used to retrieve those headers.

                      Note, however, the rather careful way that I phrased that last sentence. The issue with XMLHTTP and WinInet is separate from Cross-Site Tracing (XST). It doesn't require the use of HTTP TRACE at all. (For example, there were two additional vulnerabilities released to BugTraq over the weekend that make use of XMLHTTP to access the authentication string without using a TRACE -- one munges the Host: header for sites with name-based virtual hosts, and the other works through Apache Proxy.) Fixing this issue in XMLHTTP has zero impact on the XST vulnerability if a hacker attempts to exercise that vulnerability through a client other than XMLHTTP.

                      #If you tried this using (say, for example) LWP wrapped up as a COM object,
                      #so that it would be accessible via JavaScript (you can probably do this with
                      #the neat tools that ActiveState provide), you would have no vulnerability.

                      Whether or not the COM object included the WWW-Authenticate headers in the outgoing request would depend entirely on how you implemented the LWP client. You could certainly pass authentication credentials to your LWP client and, if you did so, LWP would happily include them in its TRACE request.

                      #Now do you understand why I think this is a bug in xmlHttp? - the very fact
                      #that it has access to those credentials and the ability to do requests
                      #across domains makes it all too powerful to be executing in javascript.

                      I will happily agree that you have identified a potential problem in XMLHTTP that may make it particularly vulnerable to XST attacks.

                      Do you understand why I think that the XST vulnerability itself has nothing to do with any one client, though? The XST vulnerability exists because web servers have TRACE enabled. Folks that implement web servers should provide a simple method to disable TRACE, or perhaps even disable it by default.
                    • This is getting complex, and really gets too deep into whatever layer you happen to be in. But I still think I'm right - this vulnerability is pretty strictly limited to certain clients. It doesn't work for other HTTP client libraries (though might if they used this WinInet thing, whatever that is), and since this is a remote attack the only thing you can assume is the presence of this xmlHttp, which in turn uses WinInet. The vulnerability (exposing credentials) is either in WinInet or xmlHttp, either way i
                    • #The vulnerability (exposing credentials) is either in WinInet or xmlHttp

                      I think we're just going to have to agree to disagree. The JavaScript method never sees the credentials until they have been echoed back by TRACE. If TRACE is turned off at the server, you will not be able to see the credentials using the XST vulnerability, even if no change is made to WinInet / XMLHTTP.

                      #Same issue on Mozilla too - it's only exposed via xmlHttp.

                      I would just note that according to the original white paper, th
                    • I think we're just going to have to agree to disagree. The JavaScript method never sees the credentials until they have been echoed back by TRACE. If TRACE is turned off at the server, you will not be able to see the credentials using the XST vulnerability, even if no change is made to WinInet / XMLHTTP.

                      On this we agree. What I disagree with is where it should be fixed. XSS (and XST) vulnerabilities affect both the user and the server end. While I agree that sites should take action to prevent this, I al
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.