Slashdot Mirror
Cross-Site-TRACE
quackking writes "Uh-oh! Looks bad for RFC 2068! Kudos to WhiteHat out of Santa Clara, CA for this one. ALL current web servers comply with this RFC, which means they ALL are vulnerable to this newly named attack - XST - cross-site-trace.
When misused, TRACE, part of the HTTP protocol, allows an unauthorized script to be passed to a Web server for execution even if the server is secured against running such scripts. Even devices like web-managed routers are open to this."
Just in case, here's a mirror. No PDF but bzipped versions of the HTML and text versions.
Grab it at Mirrored on an OC3
TODO: Something witty here...
If you look at the link, it's http://www.craphound.com/down/
Yep, that's exactly how it is, "down".
http://www.mit.edu/~dmark/palm/
-karlcritz
Well, at least this book has been distributed under the Creative Commons licence, which means it's never coming out of the public domain (well, the specific public domain in which it exists, anyhow). This sort of licence (and the opensource licences that Redhat et al operate under) are great for ensuring exactly what you fear doesn't occur - ie, free things becoming non-free due to greed after success.
And yes, I knew you were trolling. You just happened to also be talking out your arse, so I brought you up on it.
It is not likely to be related to the current DDOS, which seems to be this MS vuln.
The script is not executed on the server. It is executed on the client.
This is a sort of cross-site scripting vulnerability, not an "execute arbitrary commands on any web server" vulnerability like the writeup suggests.
This story is utter alarmist crap. There is nothing wrong with TRACE, and the internet is not falling apart. It's just another IE cross-site scripting vulnerability. Here's a few choice links from the discussion on bugtraq:
2 003-01-22/2003-01-28/0 2 003-01-22/2003-01-28/0
http://online.securityfocus.com/archive/1/307778/
http://online.securityfocus.com/archive/1/308165/
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Back to the drawing board, methinks. >p>Seriusly, yes, it's always an issue with a vulnerability discovered by a white hat - but on the whole, it's probably better that folk know about it than have to start figuring out what happened *after* they got hit with it.
[FUCK BETA]
This report is just nonsense. TRACE causes the web server to send a reply containing a 'body' part consisting of the request headers. Well, so what. Getting to the cookies enclosed with said request is not made any simpler by this method. The TRACE request method makes life no more joyful for those who would do your system harm. (Juicier than ActiveX and straight-ahead annoying VBScript/ECMACrap? Nope. More satisfying than polluting p2p with trojans? Nope.)
The issue currently happening, from what anyone can tell at any rate is that a flaw in MSSQL has been found, due to everyone noticing a lot of traffic on 1434.. MSSQL port anyhow, I was running MSSQL earlier and my dns crapped out ctrl+alt+del'd and saw 85% cpu used by mssql server, killed it and boom everything was okay, possibly a worm traveling around, http://internethealthreport.com/ UUnet seems absolutely destroyed ;)
I just finished reading this so-called whitepaper and the press release, and
all I can say is hyped, sensationalised snakeoil.
The HttpOnly cookie feature, a proprietary Microsoft extension designed to
mitigate a single aspect of XSS, can be circumvented in myriads of ways. In
fact, reading the HTTP response in any other way than through the
document.cookie property immediately exposed through JS will return the
cookie to you. Calling from JS to a Java applet that in turn parses a HTTP
response, using a Flash movie (or most any other plugin) or even needlessly
complicating matters by parsing the BODY of a TRACE response received
through XMLHTTP - such as this 'whitepaper' suggests.
By design, HttpOnly makes the cookie available only through the HTTP
headers - which, among many others, the XMLHTTP control can read.
What we end up with from WhiteHat Security is a way to circumvent the
HttpOnly cookie feature in IE6SP1, nothing else. In itself, worthy of a note
in a roundup of browser problems or a comment in a reply to the posting
announcing the HttpOnly feature on Bugtraq - but hardly a whitepaper,
pressrelease and blurbs such as comparing this to Code Red and Nimda or
calling this a flaw in all web servers worldwide. This is simply not "a new
class of web-app-sec attack" or a flaw in TRACE, as hyped by WhiteHat
Security.
System administrators should most definitely not waste their precious time
on implementing the silly workarounds suggested, such as disabling
TRACE/TRACK requests. The one, and only, impact the discovery from WhiteHat
Security has is that it re-enables cookie reading from JS despite if you had
already cared to specifically alter your webapplication to accomodate this.
in short, absolute FUD dreamt up by some "whiteHatSecurity" bahaha
If your applications aren't vulnerable to XSS, you have nothing to worry about w.r.t. HTTP TRACE. If your applications ARE vulnerable to XSS, you have bigger problems than HTTP TRACE.
If users visiting other sites somehow have untrusted code running in them, which performs an HTTP TRACE to your site, the user's browser is broken for not enforcing domain restrictions.
Ignore this advisory, it's sensationalist snakeoil. Leaving HTTP TRACE enabled is harmless (although you probably don't use it, so disable it anyway).
Resent-From: mbac@romulus.netgraft.com
From: Michael Bacarella
Date: Fri Jan 24, 2003 11:11:41 PM America/Los_Angeles
Resent-To: bugtraq@securityfocus.com
To: nylug-talk@nylug.org, wwwac@lists.wwwac.org, linux-elitists@zgp.org
Subject: MS SQL WORM IS DESTROYING INTERNET BLOCK PORT 1434!
I'm getting massive packet loss to various points on the globe.
I am seeing a lot of these in my tcpdump output on each
host.
02:06:31.017088 150.140.142.17.3047 > 24.193.37.212.ms-sql-m: udp 376
02:06:31.017244 24.193.37.212 > 150.140.142.17: icmp: 24.193.37.212 udp port ms-sql-m unreachable [tos 0xc0
It looks like there's a worm affecting MS SQL Server which is
pingflooding addresses at some random sequence.
All admins with access to routers should block port 1434 (ms-sql-m)!
Everyone running MS SQL Server shut it the hell down or make
sure it can't access the internet proper!
I make no guarantees that this information is correct, test it
out for yourself!
--
Michael Bacarella 24/7 phone: 646 641-8662
Netgraft Corporation http://netgraft.com/
"unique technologies to empower your business"
Finger email address for public key. Key fingerprint:
C40C CB1E D2F6 7628 6308 F554 7A68 A5CF 0BD8 C055
-- sigs suck --
As been discussed on BugTraq the latest days, this is not a 'general' vunerablility, rather a bug in Microsoft's XMLHTTP component (nomatter what the whitepaper says).
References: RE: TRACE used to increase the dangerous of XSS.
Original posting to Bugtraq
Without them on 99% of the recent browser/http/www problems go away. And 100% of the popups go away too. Sure you stop being able to view many sites, but most of those sites that lock you out when you don't have this stuff on are full of junk anyway.
Given what this attack can do, you have to 100% trust any site which you visit with these active stuff on, because they can use the active stuff to snarf your cookies and info for other sites.
In this light, how should you treat a site which absolutely _requires_ you to turn such dangerous stuff on in order to use their site? Is it worth all that potential hassle just to see some stupid shockwave which only the PHB likes?
Is there a javascript/activex/java program that will turn off javascript/activex/java support in a viewer's browser?
I also proposed a tag to mark regions of HTML as unsafe so the browser ignores any javascript/active stuff that slips through the site's filters. But there wasn't any interest. This doesn't help if users visit malicious sites, but it helps decent sites protect their users from stuff slipping through.
The article is about a new exploit they are talking about... nothing to do with the current mess.
I'm watching my firewall logs fill up even as I type, and all the 1434 hits are coming from different IPs... no dupes yet that I can see (maybe there are... but I'm not planning on sitting here all night reading logs).
These SQL attacks are coming from a plethora of different ports on the machines that are hitting me... anybody know if this is a normal part of this worm's behavior?
Even if a man chops off your hand with a sword, you still have two nice, sharp bones to stick in his eyes.
Two T3s with Quest: DOWN. Port udb traffic 1434 totally flooded. Uplinks have their heads up their asses and have no answers at this point. My uplink says he has a Linux server that when activated starts spamming port 1434. Is this or is this not a MS SQL-related issue?
I'm up because I'm multi-homed and I have no MS servers at all running on my network, but every other network that i know of running some MS servers is having blackouts.
We need to find out what is going on right now, and we need to make sure the media does NOT misrepresent exactly what is at fault. Everyone here has a responsibility!
"If you want to be 100% compliant with RFC 2068, a document defining the standard behavior of the world wide web, you must include TRACE." noted Lex Arquette, Chief Technology Officer of WhiteHat. http://www.whitehatsec.com/press_releases/WH-PR-20 030120.txt
:-)
Strange... RFC 2068 seems to be obsoleted by RFC 2616 since June 1999...
Note the story submitters name.
Quack King.
Next!
--LP
Here's what we've been able to learn, at 4:30am Central time.
We have reason to believe that something called the "SQL Worm" is in play. Some sort of DDOS attack which creates overwhelming traffic on port 1434. This is all preliminary stuff, so take it as such but I have one link up and 3 others down.
I don't have confirmation or details on what systems are affected but we have information to indicate that the following networks are currently affected: Quest, Cable & Wireless, Broadwing, Sprint (partially). My Worldcom link seems to be unaffected (which is why I can post). Note that the connectivity interruptions may be regional but that's what we are dealing with in the South Central area of the US. This has been going on now for about 4-5 hours.
What we are seeing is a major outage due to DDOS on port 1434, on portions of the Internet backbone. At this point, the exact pattern of the outage has not been clarified.
Expect the problem to potentially be addressed when the backbone providers start filtering port 1434. However, it's taken them at least four hours to figure this out.
We just got notice (a few moments ago) that Quest finally started filtering port 1434 and everything went back up. So now we need to figure out what vulnerability this was. My information indicates that port 1434 is MS SQL server resolution service (see related CERT advisory. My initial impression is that while this vulnerability was discovered awhile back, someone just recently figured out a very effective exploit using the vulnerability. I am looking forward to hearing more about what people find out.
Apparantly "ALL" web servers are *not* open to this "exploit" - here's a post someone made on macintouch.com:
When I read the article on MacInTouch about the TRACE security flaw, I immediately checked our Mac based servers to find out if they support the TRACE option in HTTP. Here's a summary of the servers and the OPTIONS they support. These results were shown after connecting to the server via telnet:
%telnet www.domain.com 80
Trying 123.123.123.123
Connected to www.domain.com.
Escape character is '^]'.
OPTIONS / HTTP/1.1
Host: www.domain.com
* WebSTAR 3.x answers: 405 Method Not Allowed
* WebSTAR 4.4 and 4.5 allows GET, POST, HEAD
* WebSTAR V allows GET, POST, HEAD
* Apache/1.3.27 (Personal WebSharing MacOS X 10.2.3): GET, HEAD, OPTIONS, TRACE
* Apache/1.3.27 (iTools - MacOS X Server 10.2.2): GET, HEAD, OPTIONS, TRACE
* Apache/1.3.27 (iTools - MacOS X Server 10.2.2 - PHP 4.x): GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE
When connecting to a system that has PHP 4.x installed, a lot more options are available.
This only shows which options are supported by which servers, however as the exact details of the flaw were not published, it's hard to say if you can use those options to exploit a server.
There are two things going on here I suspect. There is a discussion on a cross-trace vulnerability, at the same time, some type MS SQL-based worm was unleashed late Friday which caused lots of problems. Two different issues. Excuse the inter-mingling.
I haven't tried this yet!
Patriotism is the opium of the masses
Most sites don't store their user password in a cookie, they store a session ID in a cookie that translates to a session ID in a database. Then sensitive information is keyed up with that ID, on the server. The client never recives any of it, unless they are modifying it but it is never put in a cookie or other stateful client storage device.
Upon each page load, the IP address of the original session is checked with the sent cookie ID, and if they don't match, most applications will throw out the session completly. This annoys some with DHCP who like to maintain long sessions, but works a lot of the time for simple ID attacks (since most session IDs are generated from random numbers), because you now need to know both the IP and session ID of the user you want to impersonate. Granted, this can be had with a packet sniffer (for non SSL connections), but so can a lot of personal things. Next they'll be telling us it's quite easy to get into cars: just break the window. That doesn't mean its a security flaw.
Anyway, this is how most [good] sites work. Only fools store sensitive user information in cookies, and I would never subscribe to their site (yes, I check what goes in my cookies).
Also the article/press release (PR for this security company?) seems to be getting client/sever scripting confused, and is generally full of ignorant errors. How can it be trusted with the other claims it makes?
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95
http://www.apacheweek.com/issues/03-01-24
http://online.securityfocus.com/archive/1/30816
Have more details.
SQLServer listens to 1434 to accept incomming connections. SQLServer 7 would then normally transfer these connections to 1433 by default. SQLServer 2000 would transfer the connection to a random port.
It's best to 'hide' the SQLServer from the internet, and/or disable TCP/IP listening for SQLServer totally when it's connected to the Internet. MS also suggests SQLServer should never be exposed to the Internet directly. You can hide SQLServer (2000) directly, using the Server network utility, shipped with SQLServer. You can there first deselect TCP/IP as a protocol that's active, and if you need it, you can select 'hide' to hide the server on the internet, however it's better to disable TCP/IP totally, since you do not need it when you work with SQLServer from the same box (f.e. a website running on the same box accessing the SQLServer).
Oh, of course it should be mentioned, there is a patch for this available at MS' technet site.
Never underestimate the relief of true separation of Religion and State.
See here. It's still the best description I've seen of the "problem", but the AC really should have credited the source.
This is not an issue. The exploit uses existing, well-known vulns.in MS' IE. Nothing to see here. Move along, move along, read the Full Disclosure list for further background.
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe