Anyone familiar with Cross-site Tracking attacks?

[Lv4]

In the past week or so I have seen a tremendous increase in unsafe methods used in WWW traffic to my webservers. I have seen TRACE, SEARCH and PROPFIND being used during these attacks. My IDS logs would usually only show a TRACE method against a webserver about once a month, where now I'm seeing something on the order of 150-200 a day per server instance.

I started research on this a while back, when I first saw a couple of TRACE methods used against my webservers and found that it was most likely linked to Cross-site Tracking (XST) attacks, but so far I have found little to nothing regarding this style of attack. Whitehat Security had a write up about it in PCMag and they seemed to have had a white paper about it at some point, but then a few people in the security community, most notably Thor Larholm, came out hard against them saying that they had not discovered anything new and that it was all FUD they were spreading anyway. So my research in to how these attacks work has been very limited.

Now as far as I can tell my webservers aren't accepting these methods. We are running Sun ONE 6.1 and I checked the obj.conf file for anything regarding those three methods. They are not listed anywhere in there, and the only thing that my servers seem to be responding to are GET, POST and HEAD. Now doing the tests that Sun recommends to verify if these methods are indeed not being serviced yielded something other than spectacular results. Doing the telnet TRACE method on the localhost should result in:

HTTP/1.1 405 Method Not Allowed
Server: Sun-ONE-Web-Server/6.1

instead what I get is:

HTTP/1.1 error timeout
Server: Sun-ONE-Web-Server/6.1

not exactly that I wanted to see so I'm still not sure if these webservers are not processing these methods or if the request is just taking too long. Also keep in mind that there are up to 8 instances of these webservers running on each machine I'm testing and only some of them have access to the docs dir in the first place so it could be that I'm just hitting up against the wrong instances for this test.

I guess what I'm asking for here is for someone to point me in the correct direction to:

1. Learn how these style attacks really work
2. What I have to do to defend against them
3. What I can do to REALLY verify that my servers are not vulnerable to these types of attacks.

Considering the nature of these attacks I know that some people will not want to respond in a public forum like this with whitepaper information that can show how to perform these attacks, so if you feel this way just drop me a PM... I'll even take basic information regarding these attacks. Oh and before you ask, yes I Googled it and no I didn't find any satisfactory results doing that.

[Tiger Shark]

Yeah, I noticed those a couple of weeks ago too...... IIRC it's an MSDTC attempt and since I'm patched and good against them I dismissed them...... That's why I'm not entirely sure of the reason.... But if you are patched and secured against it you can forget it.... And since the server you are using isn't M$ you can probably really forget it.

[groovicus]

This information is from “Malware: Fighting malicious code” by Ed Skoudis. I am just providing a summary. I highly recommend this book, btw. It's also extremely condensed..I just tried to get the basics in.

Just to show the flipside of the XST (cross site tracking), is XSS (cross site scripting). In simple terms, it is injecting malicious code into a vulnerable website so that the visitor's browser unknowingly executes the code. The code tends to be in the form of a browser script, configured to steal cookies, or hijack the victim's browser session.

One vulnerability of a web site is if it reflects input back to the user. For example, a search engine. When you query, for instance “free porn”, the site echoes back something along the lines of “Here are the results of your search for: free porn”. The premise of XSS is, what if you include JavaScript in your query? If the site does not strip out the script, it would be executed when the results page loaded. This would allow you to hack yourself. By expanding this technique, an attacker can clone other peoples sessions by getting them to reflect malicious code back to themselves.

A normal search engine query would look something like this:

www. example.com/search.cgi?query=free+porn

If the search engine does not strip out the JavaScript, the URL might look like:

www. example.com/search?cgi?qeury=< script> alert(document.cookie)</script>

An attacker interested in obtaining someone's search engine cookies (spyware purposes?) could trick the victim into clicking on the URL. The browser releases the cookies because JavaScript is embedded in the page that is authorized to view them. A couple of ways to trick a user into clicking on the links is by including it on a third party web site, via email, or embed it in a posting on a discussion forum.

Actions typically involved in an attack:

1.The potential victim sets up an account on a vulnerable web site. The web site uses cookies to maintain session information.
2.The attacker creates a link that includes the cookie stealing code, and tricks victim into clicking on the link (i.e click here and win one million dollars).
3.The victim's browser transmits the attacker's scripts to the web site as part of the URL.
4.The site reflects the input, including the malicious script, back to the victim.
5.The script runs in the victim's browser. Because the browser thinks the script came from the “approved” web site, the browser runs the script within the context of the vulnerable site. The browser grabs the victim's cookies and relays them back to the attacker.
6.The attacker is then able to clone the victim's session with the target web site.

Including input as part of the URL is known as the GET submission method, so in order for the exploit to work, the target site needs to support the GET method.In contrast, some sites only support the POST method. With this type of attack, the code is embedded in an HTML form. In order for this to work, the victim would have to submit the crafted form for the site to reflect the attacker's script back to the user.

Another much more dangerous method of launching XSS attacks takes advantages of sites that take input from one user, and present it as output to another user. This method allows malicious code to be executed as soon as the victim views the infected page. This method works regardless of whether the site uses GET or POST to collect user input.

**** I'm not going to include the example here, because if some skiddie wants it, he can buy the damn book himself For anybody that is interested, ask, and I will try to elaborate a little.********

What is dangerous about this method, is that for instance, were I to capture a senior member's cookies, it would be theoretically possible to masquerade as that senior member. (or even a moderator)

DEFENDING AGAINST ATTACKS-Defenses can be applied in 2 general areas: at the web server and at the user's browser.

Server side filtering-Web sites need to carefully filter out input that a user's browser could interpret as a script. By removing this data, there is nothing harmful to be reflected back to the user.

***The book here lists 9 different methods of introducing malicious scripts into HTML files*****

Since there are so many different methods to introducing scripts, the book indicates that the best way to filter is to eliminate (if possible) the following characters:

< > ( ) = ” ' ; % &

Instead of deleting the characters, the web application can translate them into counterparts that look like the original symbols, but do not have the same contextual significance. This is also known as 'escaping' the characters.

A web site must know what encoding the visitor's browser will use to recognize them. To eliminate potential “work-arounds” for an attacker, the site should explicitly tell the browser what character set it should operate in. EXAMPLE:

<meta http-equiv=”content-type” content=”text/html; charset=ISO-8859-1>

***This is just one method listed***

Client side defense- for starters, never browse logged in as superuser, root, or administrator. Any scripts that may be running in your browser will have the same privelages.Most security concerns can be addressed by disabling scripts. If you need more flexibility, you can set up each individual web site according to your needs (i.e. Trusted zones) The downside to blanket disabling of scripts is that you may (and probably will) lose functionality.

I hope this helps you a little Lv4

[Lv4]

Thanks Tiger Shark, that's kind of what I was figuring. I haven't seen anything on the lists I'm on about this type of activity so it may still be fairly low level at this point, who knows. I'm fairly confident that our servers are not releasing information they shouldn't be just because those methods are not in my obj.conf file in the first place, add to that the fact that we aren't running any MS stuff in our DMZs or on the borders then I think we are fairly safe. If you do happen to find anything regarding this type of activity, or if you see another ramp up in activity let me know... I think I'm going to start tracking this and digging some more just because it has me interested now

Wow groovicius! Great information there. I knew a bit about XSS before but I learned quite a bit there, and I too believe that XSS and XST are flipsides to the same coin. I'll go check out that book at lunch today if I have the chance, it's always good to find new material like that. Thanks a lot.

[groovicus]

I just found this link that explains what I was trying to summarize up above, but it does it alot better.

http://www.technicalinfo.net/papers/CSS.html

Also here:

http://216.239.37.104/search?q=cache...hl=en&ie=UTF-8