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".
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
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 ;)
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.
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!
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.