Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security

Cross-Site-TRACE 187

Posted by michael from the uh-oh dept.
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."
This discussion has been archived. No new comments can be posted.

Cross-Site-TRACE More

Cross-Site-TRACE

Comments Filter:

  • relation? (Score:3, Insightful)

    by minddog ( 460206 ) on Saturday January 25, 2003 @04:19AM (#5155785) Journal
    This isn't at all related to whats going on right now is it?
    • I haven't been able to find out much on the current outtages, can't get to internettrafficreport.com :(
      • www.internethealthreport.com Major problems tonight. Look at yesterday's internethealthreport to compare (link on the page). Its ugly.

      • Re:relation? (Score:3, Interesting)

        by rchatterjee ( 211000 )
        Don't know if this is the reason for the internet slowdown right now but it seems likely, from about a few hours ago I've getting tons of incoming traffic on port 1434 which I believe is the port that MS SQL listens on. So it's probably another exploit on MS sever software.

        • Re:relation? (Score:2, Insightful)

          by walendo ( 163069 )
          Same here. Lots of hits on port 1434, currently from .kr and .mx ... sigh.

          • Most of my hits are actually coming from .edu machines.

            nd.edu, rpi.edu, psu.edu, syr.edu, ohiou.edu, albany.edu... and from the hostnames, they don't sound like student machines, but real servers.

            Sigh.

            -l
            • Would make sense if this is a MS-SQL Server exploit, all the uni's servers would be getting buggered, but none of the students' computers would be running the server, so no pingage from them.

              -Mark
        • re: hits on Port 1434:

          For me, this has just started up... I attach my Zone Labs Log File so you may compare the activity to what you are seeing. ( I am not trying to take up valuable area, but rather am trying to give you another dataset to compare your experiences to. Presently I am getting hit about once every fifteen seconds attempting to connect to my port 1434. As you can see, these are coming from various other IP's on varying ports.

          I am on a dialup. DHCP. ( I get whatever IP PacBell assigne me for the duration of my connect).

          ZoneLabs Log:

          FWIN,2003/01/24,14:23:48 -8:00 GMT,216.161.101.173:62540,67.112.46.155:3525,TCP FWIN,2003/01/24,14:23:48 -8:00 GMT,216.161.101.173:62539,67.112.46.155:3525,TCP FWIN,2003/01/24,14:23:48 -8:00 GMT,216.161.101.173:62541,67.112.46.155:3525,TCP FWIN,2003/01/24,14:30:22 -8:00 GMT,67.112.46.162:1028,67.112.46.155:137,UDP FWIN,2003/01/24,14:30:28 -8:00 GMT,67.112.46.161:1097,67.112.46.155:137,UDP FWIN,2003/01/24,14:37:08 -8:00 GMT,67.112.46.161:1098,67.112.46.155:137,UDP FWIN,2003/01/24,14:38:54 -8:00 GMT,67.112.46.161:1096,67.112.46.155:137,UDP FWIN,2003/01/24,14:40:16 -8:00 GMT,4.62.221.54:0,67.112.46.155:0,ICMP FWIN,2003/01/24,14:48:20 -8:00 GMT,67.112.46.161:1025,67.112.46.155:137,UDP FWIN,2003/01/24,15:03:22 -8:00 GMT,200.64.172.254:1084,67.112.46.155:137,UDP PE,2003/01/25,00:32:57 -8:00 GMT,Netscape Navigator application file,206.13.29.12:53,N/A

          and this is when the crap started flying

          PE,2003/01/25,00:33:08 -8:00 GMT,The Proxomitron,206.13.29.12:53,N/A FWIN,2003/01/25,00:37:22 -8:00 GMT,128.205.156.40:3537,67.112.46.156:1434,UDP FWIN,2003/01/25,00:38:42 -8:00 GMT,67.112.251.186:2991,67.112.46.156:80,TCP FWIN,2003/01/25,00:40:02 -8:00 GMT,211.13.231.200:4216,67.112.46.156:1434,UDP FWIN,2003/01/25,00:41:00 -8:00 GMT,63.254.129.14:4632,67.112.46.156:1434,UDP FWIN,2003/01/25,00:41:32 -8:00 GMT,207.97.136.48:4899,67.112.46.156:1434,UDP FWIN,2003/01/25,00:44:32 -8:00 GMT,64.239.122.46:53342,67.112.46.156:1434,UDP FWIN,2003/01/25,00:45:10 -8:00 GMT,207.46.200.139:2126,67.112.46.156:1434,UDP FWIN,2003/01/25,00:51:02 -8:00 GMT,62.149.128.35:1235,67.112.46.156:1434,UDP FWIN,2003/01/25,00:54:58 -8:00 GMT,63.240.201.75:1478,67.112.46.156:1434,UDP FWIN,2003/01/25,00:56:36 -8:00 GMT,216.97.147.185:1706,67.112.46.156:1434,UDP FWIN,2003/01/25,00:58:12 -8:00 GMT,129.250.226.100:3581,67.112.46.156:1434,UDP FWIN,2003/01/25,00:58:28 -8:00 GMT,24.30.207.206:4096,67.112.46.156:1434,UDP FWIN,2003/01/25,01:01:10 -8:00 GMT,212.219.8.246:4686,67.112.46.156:1434,UDP FWIN,2003/01/25,01:01:48 -8:00 GMT,10.208.128.97:4222,67.112.46.156:1434,UDP FWIN,2003/01/25,01:05:42 -8:00 GMT,164.67.192.239:4850,67.112.46.156:1434,UDP FWIN,2003/01/25,01:06:12 -8:00 GMT,64.15.237.180:1459,67.112.46.156:1434,UDP FWIN,2003/01/25,01:08:36 -8:00 GMT,66.230.209.230:3513,67.112.46.156:1434,UDP FWIN,2003/01/25,01:09:46 -8:00 GMT,130.94.19.249:2482,67.112.46.156:1434,UDP FWIN,2003/01/25,01:09:56 -8:00 GMT,65.118.242.70:3108,67.112.46.156:1434,UDP FWIN,2003/01/25,01:10:30 -8:00 GMT,62.129.134.253:1226,67.112.46.156:1434,UDP FWIN,2003/01/25,01:12:40 -8:00 GMT,64.210.7.98:4182,67.112.46.156:1434,UDP FWIN,2003/01/25,01:13:04 -8:00 GMT,66.28.8.72:3420,67.112.46.156:1434,UDP PE,2003/01/25,01:13:09 -8:00 GMT,Netscape Navigator application file,127.0.0.1:8080,N/A FWIN,2003/01/25,01:14:00 -8:00 GMT,210.214.8.133:1025,67.112.46.156:137,UDP FWIN,2003/01/25,01:16:06 -8:00 GMT,205.243.25.86:4181,67.112.46.156:1434,UDP FWIN,2003/01/25,01:17:24 -8:00 GMT,217.160.133.189:1098,67.112.46.156:1434,UDP FWIN,2003/01/25,01:18:48 -8:00 GMT,139.134.5.239:2274,67.112.46.156:1434,UDP FWIN,2003/01/25,01:19:26 -8:00 GMT,80.13.193.122:1026,67.112.46.156:137,UDP FWIN,2003/01/25,01:19:38 -8:00 GMT,145.101.195.133:2886,67.112.46.156:1434,UDP FWIN,2003/01/25,01:24:00 -8:00 GMT,62.20.108.24:1291,67.112.46.156:1434,UDP FWIN,2003/01/25,01:24:12 -8:00 GMT,65.160.127.210:2722,67.112.46.156:1434,UDP FWIN,2003/01/25,01:26:20 -8:00 GMT,157.169.10.11:3281,67.112.46.156:1434,UDP FWIN,2003/01/25,01:26:48 -8:00 GMT,129.125.140.178:2536,67.112.46.156:1434,UDP FWIN,2003/01/25,01:27:16 -8:00 GMT,193.140.134.125:1033,67.112.46.156:1434,UDP FWIN,2003/01/25,01:28:32 -8:00 GMT,216.29.52.98:3466,67.112.46.156:1434,UDP FWIN,2003/01/25,01:28:56 -8:00 GMT,129.242.210.240:1574,67.112.46.156:1434,UDP FWIN,2003/01/25,01:32:00 -8:00 GMT,212.141.84.123:1954,67.112.46.156:1434,UDP FWIN,2003/01/25,01:33:16 -8:00 GMT,65.209.2.2:1062,67.112.46.156:1434,UDP FWIN,2003/01/25,01:37:22 -8:00 GMT,203.251.202.13:1576,67.112.46.156:1434,UDP FWIN,2003/01/25,01:38:16 -8:00 GMT,63.215.151.135:1970,67.112.46.156:1434,UDP FWIN,2003/01/25,01:38:30 -8:00 GMT,61.61.104.231:1028,67.112.46.156:137,UDP PE,2003/01/25,01:41:18 -8:00 GMT,OPERA.EXE,127.0.0.1:8080,N/A FWIN,2003/01/25,01:41:34 -8:00 GMT,128.186.85.26:1757,67.112.46.156:1434,UDP FWIN,2003/01/25,01:43:00 -8:00 GMT,195.194.95.160:4327,67.112.46.156:1434,UDP FWIN,2003/01/25,01:43:10 -8:00 GMT,63.243.24.97:1107,67.112.46.156:1434,UDP FWIN,2003/01/25,01:45:18 -8:00 GMT,202.125.128.100:1603,67.112.46.156:1434,UDP FWIN,2003/01/25,01:45:38 -8:00 GMT,67.35.15.77:0,67.112.46.156:0,ICMP

          Actually, while I type this, I have had ZoneLabs notify me each time I get a hit, and I am now up to hit #12 or so. Weird! Its gonna be interesting to read on Slashdot just what this thing is.

        • I dug this up.. it may explain why port 1434 is under attack. It appears to be a Microsoft SQL server exploit.

          http://www.der-keiler.de/Mailing-Lists/Securiteam/ 2002-07/0115.html

        • 1434 is the general connection accept port. (Score:4, Informative)

          by Otis_INF ( 130595 ) on Saturday January 25, 2003 @07:42AM (#5156138) Homepage
          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.
      • I've been notified of 3 attempted attacks by ZoneAlarm, all over port 1000
        Traceroute to a.root-servers.net:
        <snip/>
        14 376 ms 340 ms 337 ms so-2-3-0.washdc3-nbr1.bbnplanet.net [4.24.4.109]
        15 401 ms 347 ms 336 ms p2-0.vienna1-nbr2.bbnplanet.net [4.24.4.214]
        16 345 ms 349 ms 343 ms p1-0.vienna1-cr6.bbnplanet.net [4.0.2.138]
        17 494 ms 471 ms 460 ms h2-0.internap5.bbnplanet.net [4.1.9.242]
        18 345 ms 334 ms 334 ms border7.ge2-0-bbnet1.wdc.pnap.net [216.52.127.11]
        19 * * * Request timed out.
        (goes on and on.... Gives up at 30)

        So it looks like 1 root server cannot be reached from my location (Geelong, Australia). I was able to reach b.root-servers.net though. I can't be bothered to do all of them.

    • Re:relation? (Score:4, Informative)

      by hudmond ( 644601 ) on Saturday January 25, 2003 @04:35AM (#5155840)
      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 ;)

      • Re:relation? (Score:4, Funny)

        by LinuxPunk ( 641305 ) on Saturday January 25, 2003 @05:08AM (#5155904) Journal
        Oh my god, they killed UUnet! Those bastards!

        Sprint seems to be doing very well, though.

      • Re:relation? (Score:3, Funny)

        by hudmond ( 644601 )
        excerpt taken from http://www.internet.com/
        Microsoft Promises a More Secure 2003 After a year of working on its security issues, the company's Trustworthy Computing initiative is taking more of a 'push' approach starting with Windows Server 2003.
        -internetnews
        Anyone else find this laughable? I'm slightly entertained I'll admit.

    • Re:relation? (Score:1, Offtopic)

      by LinuxPunk ( 641305 )
      Hmmm... Over here (canada) the internet seems mostly fine, only a few sites that i've been to are down, including www.distrowatch.com. In fact, im listening to internet radio right now, and there is no lag at all (digitallyimported.com). This seems like it is a mostly UUnet targeted attack.. according to internethealthreport.com...

    • No relation (Score:3, Informative)

      by The Tyro ( 247333 )
      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?

      • Re:No relation (Score:3, Informative)

        by Arrgh ( 9406 )
        Have a look at this advisory [nextgenss.com] from July 2002 of a "Critical/High Risk" vulnerability in MS SQL Server 2000, involving UDP 1434.

        It details stack-based, heap-based and network-based DOS vulnerabilities. Wheee!

    • Re:relation? (Score:5, Funny)

      by amigaluvr ( 644269 ) on Saturday January 25, 2003 @07:03AM (#5156078) Journal
      hrm kevin mitnick is allowed back o the net and the net goes fubar

      hrmmmmmmmmmmmmmmm????

  • not related (Score:5, Informative)

    by benh57 ( 525452 ) <bhines@alumnREDH ... edu minus distro> on Saturday January 25, 2003 @04:23AM (#5155799) Homepage
    This vulerability is about sites getting access to other sites' cookies.

    It is not likely to be related to the current DDOS [matrix.net], which seems to be this MS vuln [matrix.net].

    • Re:not related (Score:5, Informative)

      by benh57 ( 525452 ) <bhines@alumnREDH ... edu minus distro> on Saturday January 25, 2003 @04:25AM (#5155806) Homepage
      Oops, 2nd link should be to CERT. [cert.org]

      • Re:not related (Score:1, Offtopic)

        by Anonymous Coward
        Hmmm..My firewall log shows that I'm getting probed on this port (1434) every few seconds from 20 or more different IP addresses...I'm on AT&T's "broadband" network...

      • Re:not related (Score:4, Informative)

        by h2odragon ( 6908 ) on Saturday January 25, 2003 @05:15AM (#5155917) Homepage
        this is a new exploit; beginning with a buffer overflow related to the referenced CERT, and then proceeding to another buffer overflow ....

        Disassembly of the current probe packets available here [freedom.org] for what its worth. This is a nasty little sucker.
        • this is a new exploit

          Speaking of new exploits, how about reposting a bad link to get uber karma? Or has this one been in the bag for awhile already?
    • Sheesh, I thought my university's Residential Computing department was to blame. They've been pretty damned unreliable all year, but if everybody's having this problem I guess it's not their fault.

      So the Internet, which is supposedly impervious to a nuclear barrage, has succumbed to a simple attack from some moderately skilled hacker(s). Amazing how much more damaging sheer traffic volume can be than a physical destruction of the network, eh?

      At least people will soon be able to continue downloading things like this [dhs.org]. (Beware, it's > 3 gigs--a long download from my slow connection!)
      • I too was blaming this on my university network. Pretty damn bad. My firewall is blocking requests (mostly from Europe, but lots of Asia too) at an amazing rate. I can barely read my logs fast enough.

        Makes for an interesting evening I guess.

    • Re:not related (Score:3, Informative)

      by shannara256 ( 262093 )
      It is not likely to be related to the current DDOS [http://average.matrix.net/], which seems to be this MS vuln [http://www.kb.cert.org/vuls/id/370308].

      I don't believe that that vulnerability is what's being exploited at the moment. From the CERT article:

      Overview

      Microsoft SQL Server 2000 contains a vulnerability that allows remote attackers to create a denial-of-service condition between two Microsoft SQL servers.

      I'm getting hammered, and I am not a Microsoft SQL server. It's probably not too unreasonable to assume that SQL Server is what's been exploited, but I don't think it's the exploit you mentioned.

  • The write-up is misleading (Score:5, Informative)

    by Admiral Burrito ( 11807 ) on Saturday January 25, 2003 @04:27AM (#5155813)
    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.

    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.

    • Or in more detail; TRACE simply echos back wath the client send to the server; i.e. what the client fundamentally already *knows*. The server reveals nothing to the client than what it already knows; namely the request it just send.

      It is just that on the client, to prevent cross side scripting, there is some sandboxing; which is now violated.

      That is called cross site scripting.

  • /!\ Security Alert _ [] [X] (Score:5, Funny)

    by Seehund ( 86897 ) on Saturday January 25, 2003 @04:27AM (#5155815) Homepage Journal
    Your Computer Is Currently Broadcasting An
    Internet IP Address. With This Address, Someone Can
    Immediately Begin Attacking Your Computer! [ OK ]

    Shut up Slashdot. I get all the Security Alerts I need from media*.fastclick.net.

  • This story is crap (Score:5, Informative)

    by evilviper ( 135110 ) on Saturday January 25, 2003 @04:28AM (#5155819) Journal
    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:

    http://online.securityfocus.com/archive/1/307778/2 003-01-22/2003-01-28/0 [securityfocus.com]
    http://online.securityfocus.com/archive/1/308165/2 003-01-22/2003-01-28/0 [securityfocus.com]

  • CRAP! (If it's not Scottish, it's...) (Score:1, Informative)

    by Anonymous Coward
    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.)
    • Browsers routinely keep secrets from local scripts, like authentication responses or cookies for other realms. I wonder if Sun thought about this when they designed the sandbox (an applet needs to be granted the privilege of sending requests to any server other than the one it's hosted on).
    • This report is just nonsense. TRACE causes the web server to send a reply containing a 'body' part consisting of the request headers.

      There can be no security vulnerability in HTTP that is due to cross site scripting PERIOD.

      This is because support scripting was never considered in the design of HTTP. Scripting has known security problems. The onus for solving those problems rested and rests today on the idiots who introduced scripting. It has nothing to do with the protocol layer.

      TRACE was in the HTTP specs long long before Javascript was cobbled together in two weeks at Netscape. Netscape could not even be bothered to ask for advice from the HTTP community before unleashing their abomination, so why is this supposed to be my fault eh?

      Java script sucks, alwasy has always will. It was yet another of those hacks Netscape put in to please the advertisers or whichever customer they were going after that week. As a result we have pop-under adds and sites can screw up the navigation buttons. Oh yes and sites keep coming up 'javascript error class not found'.

      None of the uses javascript is necessary for could not have been better supported through extensions to HTML. But the Netscape guys didn't want to do that because they wanted to try to control the standards by simply throwing whatever crap they wrote over the wall and faxing the 'specification' to W3C to they could say that it had been submitted in their press release.

  • Well..... (Score:2, Informative)

    by Anonymous Coward

    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

    • Re:Well..... (Score:2, Redundant)

      by doubleyewdee ( 633486 )
      Well. That was kind of silly. I see you borrowed the text from this posting on bugtraq [securityfocus.com] to whore a little karma. That's fine, but shouldn't you have been logged in?
      • Mod parent down. It seems our friend doesn't quite understand slashdot yet - the reason people post stuff like that anonymously is because they think it will be useful, but aren't looking for karma. Try a little harder next time.
        • If it was a faithful reproduction I guess it would have been different. I just found it odd that the poster decided to tack on the extra line at the bottom, with no indiciation that every other portion of the message had been copied. As another post said, it was a good troll. ;)

          Of course I, unlike you, never demanded anyone or anything be "modded down." I didn't care that much. It's not like karma actually.. you know.. matters.
          • it does matter! mine is "Excellent"!

            but not for long, with this comment!

            but since i said that, people won't mod me down!

            but now they will!

            my brain hurts!
    • See here [securityfocus.com]. It's still the best description I've seen of the "problem", but the AC really should have credited the source.

  • Opera effected? (Score:1, Interesting)

    by (rypto* ( 641800 )
    From the article: users of both Internet Explorer and Netscape are equally at risk to the same vectors of attack.
    will it effect Opera browser?

    .

  • THE XSL VULNERABILITY IS SNAKE OIL (Score:5, Informative)

    by defile ( 1059 ) on Saturday January 25, 2003 @04:49AM (#5155869) Homepage Journal

    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).

  • A couple choice quotes from the "whitepaper" (Score:5, Insightful)

    by jeremie ( 257 ) on Saturday January 25, 2003 @05:09AM (#5155906) Homepage
    Typical Sky-Is-Falling (tm) propoganda, this is so 90's:

    "Scenarios assume the following:
    A user visits a malicious web site or views malicious content hosted by a trusted source (message board, web mail, etc..)"

    "To resolve this limitation, we had to utilize extended client-side scripting technologies to create and send a specially formatted HTTP request to a target web server." (this must pass through the web browser which must foolishly attach authentication cookies in question (which properly implemented secure systems don't rely on anyway))

    "To restate, all the sensitive information is still accessible even over an SSL link." (what the hell? it's just the friggin headers! cookies and weak basic auth (they didn't even show and I'm not convinced the (broken) browsers send the auth headers in such forged requests)

    "There is however at this point a limiting factor preventing wider a danger escalation. The TRACE connection made by the browser, will NOT be allowed by the browser, to connect to anything other than the domain hosting the actual script content... To increase the exposure of the exploit, we are in need of a domain-restriction-bypass vulnerability" (MAKE THIS CLEAR, IT ONLY WORKS IN A CROSS-SITE SCRIPTING VULNERABLE BROWSER)


    To re-iterate: your web server or site isn't vulnerable because it supports trace, that's about as silly as blaming ping packets for the ping-of-death problems on early windoze systems, sheesh.

    This is all a bunch of crap that requires a browser to be vulnerable to cross scripting, and for the user to have visited a malicious site just beforehand.

  • sorry about the lack of breaks... (Score:4, Informative)

    by eecue ( 605228 ) on Saturday January 25, 2003 @05:10AM (#5155908) Homepage
    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

  • At least... (Score:4, Funny)

    by mraymer ( 516227 ) <mraymer&centurytel,net> on Saturday January 25, 2003 @05:19AM (#5155922) Homepage Journal
    ...they didn't provide a link to an example script for this exploit. ;)

    Can you imagine the royal slashdotting that RIAA/MPAA/MS/etc would receive if the thousands of script kiddies that read /. suddenly had access to such a thing?

    Perhaps this is what Obi-Wan was talking about when he felt the tremor in the force, and the whole Alderaan blowing up thing was just a bizarre coincidence...

  • Read BugTraq (Score:5, Informative)

    by Goodbyte ( 539941 ) on Saturday January 25, 2003 @05:25AM (#5155935) Homepage

    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. [securityfocus.com]
    Original posting to Bugtraq [securityfocus.com]

  • Turn Javascript, activex, java off (Score:4, Informative)

    by TheLink ( 130905 ) on Saturday January 25, 2003 @05:32AM (#5155946) Journal
    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.
    • what about cookies? other scripts? .pl?
      • .pl (perl), is executed server side. it's cgi. Java, javascript and activex scripts are executed on your local machine, which is why they can be so dangerous.

        Cookies... well, to secure your cookies, the best policy is to turn all the aforementioned capabilities of your browser off. I for one prefer a little more security while browsing as opposed to seeing stupid sites with badly written/unnessesary scripting.

      • And other similar active content plugins your browser might have running.

        You can turn cookies off if you want, but that makes it hard to implement sessions between your browser and the site you are using. Implementing sessions by using cgi parameters has disadvantages like if your browser leaves to another site, your browser could send the cgi parameter in the http referrer field.

        So if your browser supports it just turn on cookies for selected sites and leave it off for other sites. The risk with cookies - if sites work together they can track where you go and what you do.

        Whereas with the active content stuff - javascript, activex, flash etc, you risk losing control over your entire computer, and your online accounts with other sites. Actually Java has been a tad more secure, but so far most java applets are either jokes or toys. You won't miss most of them, and it's likely they'll be ported to your cellphone anyway ;).

        Other scripts? They'd probably be just as dangerous, but most people don't have python/perl plugins in their browser, so attackers are less likely to cater for that.

        Sure the risks aren't that high, it's just the consequences can be really annoying. You know that spam you get? Those by crooks who think nothing of sneaking in installs of software that dial up international numbers? If you or your cat accidentally clicked one of their urls, how sure are you that these crooks won't abuse this trace flaw to steal info? They can get your browser to send trace requests to the usual sites - banks, ebay, amazon, hotmail, yahoo etc, and collect all the echoed associated cookies and authentication data.

        Even turning such stuff off isn't 100%. Last year whilst testing something out I actually managed to create some sort of a virus/worm on a site just by using IFRAME or img src (quite harmless - but in theory could do other nastier things ). Got them to fix it tho. That sort of problem affects the site and info on the site. THe site is responsible for securing their apps to prevent this sort of thing.

        You secure your computer and apps and hopefully your favourite site secures their stuff.
    • 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.

      For the last couple of weeks, IE has been popping up warnings that my security settings may not allow Slashdot to display properly, because I don't have ActiveX scripting enabled. I do allow Slashdot to use Javascript, but don't allow everything it wants to do.

      The stupid warnings are really irritating, but the only things I'm losing are the banner ads at the top of the page. I think the offending code is this:

      var prs="ads.PointRoll.com/PRServe/?ad=424m20021219174 23&pub=osdn&num="+prInst+"&size=728_90&code=no&red ir="+pr_redir+"&defredir="+pr_redir_def+"&r="+Math .random();

      document.write("<scr"+"ipt language='JavaScript' src='http://"+prs+"'></scr"+"ipt>");

      Any suggestions on how to get rid of this irritant?
  • The TRACE method is used to invoke a remote, application-layer loop-
    back of the request message. The final recipient of the request
    SHOULD reflect the message received back to the client as the
    entity-body of a 200 (OK) response

    .

  • SitRep (Score:4, Informative)

    by mabu ( 178417 ) on Saturday January 25, 2003 @05:50AM (#5155965)
    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!

    • Just saw the scanning originating from my friend's Windows machine. So at least it is not Linux only, if at all.

      Cheers,
      e.

    • Re:SitRep (Score:2, Insightful)

      by mabu ( 178417 )
      If you have something productive to say, go for it. But calling someone an idiot without any details is counterproductive.

      I fully-admit that some of the replies may not be related to the RFC trace issue that the main message applies to, however, the news article was posted right in the middle of a major backbone outage on the Internet. At this point, we're not sure the root cause of this, and so this seems the appropriate forum to post situation reports and news gathered. Slashdot remains one of the few trustworthy sites to check when things like this happen.

  • Hmm... Why RFC 2068? (Score:2, Informative)

    by Cin7 ( 626610 )
    "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 [whitehatsec.com]

    Strange... RFC 2068 seems to be obsoleted by RFC 2616 since June 1999... :-)
  • If someone who is behind a firewall or just wants see the traffic but can't get to it, I've listed what my router has been seeing lately: Click here. [rr.com]

  • Note the story submitter's name (Score:3, Informative)

    by LinuxParanoid ( 64467 ) on Saturday January 25, 2003 @06:40AM (#5156033) Homepage Journal
    Note the story submitters name.

    Quack King.

    Next!

    --LP

  • Update (Score:4, Informative)

    by mabu ( 178417 ) on Saturday January 25, 2003 @06:40AM (#5156034)
    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 [cert.org]. 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.
    • 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.

  • Alarmist crap article! (Score:5, Informative)

    by EvilStein ( 414640 ) <.ten.pbp. .ta. .maps.> on Saturday January 25, 2003 @06:44AM (#5156041)
    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.
  • After reading through the press-release, this seems to be just another way for a pathetic company to try get some publicity.
  • Not just inaccurate, but capitalized as well? What happened to basic research? OK, here is the peer review process in action: flame the poster of this misleading and alarmist article. What I would like to see on /. is super mod points that we can use to take down articles that don't meet even the basic requirements of accuracy.
    I'm possibly not entirely objective here, since my team makes a web server that is current, fairly popular, and most definitely not vulnerable.

  • Disabling the Use of Trace in Apache (Score:3, Informative)

    by EkiM in De ( 574327 ) on Saturday January 25, 2003 @07:24AM (#5156109)
    Apache Week [apacheweek.com] has a short piece [apacheweek.com] on this "vulnerability". It also includes this short snippet of configuration code to stop traces against your webserver.
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACE
    RewriteRule .* - [F]
    I haven't tried this yet!
    • I just tried it, and it worked (response to a trace request changed from successful to 403 Forbidden).

      The Apache Week article points out that since the vulnerability is in the browser, this doesn't address the issue very well...IE apparently supports other forms of cross-site scripting and header access.

      This does contradict the claim in that other article that Apache needed a source code patch if you wanted to block TRACE. Fifteen seconds of editing and a SIGHUP to reread the configuration files are all you need, if that's what you want to do.

  • Properly secured sites aren't affected (Score:5, Informative)

    by hyrdra ( 260687 ) on Saturday January 25, 2003 @07:27AM (#5156112) Homepage Journal
    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?
  • The Associated Press has now written about this attack:
    Internet traffic broadly affected by electronic attack World Internet Lead
    By Ted Bridis
    Traffic on the many parts of the Internet slowed dramatically early today, the apparent effects of a fast-spreading, virus-like infection interfering with Web browsing and delivery of email.
    Sites monitoring the health of the Internet reported significant slowdowns globally. Experts said the latest electronic attack bore remarkable similarities to ``Code Red'' virus during the summer of
    2001 which also ground traffic to a halt on much of the Internet.
    ``It's not debilitating,'' said Howard Schmidt, one of President George W Bush's top cyber-security advisers.
    ``Everybody seems to be getting it under control.'' Schmidt said the FBI's National Infrastructure Protection Centre and private experts at the CERT Coordination Centre were monitoring the attacks.
    The virus-like attack sought out vulnerable computers to infect on the Internet using a known flaw in popular database software from Microsoft Corp, called ``SQL Server''.
    But the attacking software code was scanning for victim computers so randomly and so aggressively - sending out thousands of probes each second - that it overwhelmed many Internet data pipelines.
    ``This is like Code Red all over again,'' said Marc Maiffret, an executive with eEye Digital Security, whose engineers were among the earliest to study samples of the attack software. ``The sheer number of attacks is eating up so much bandwidth that normal operations can't take place.''
    The attack sought to take advantage of a software flaw discovered in July 2002 that permits hackers to infect corporate database servers. Microsoft deemed the problem ``critical'' and offered a free repairing patch, but it was impossible to know how many computer administrators applied the fix.
    ``People need to do a better job about fixing vulnerabilities,'' Schmidt said.

  • bollocks - just another (IE) cross site vulnerabil (Score:3, Informative)

    by dirkx ( 540136 ) <dirkx@vangulik.org> on Saturday January 25, 2003 @07:42AM (#5156137) Homepage
    That web server is just doing what it is supposed to do; it is the client which allows for the cross site vulnerability.


    http://www.apacheweek.com/issues/03-01-24


    http://online.securityfocus.com/archive/1/308165 /2 003-01-22/2003-01-28/0


    Have more details.

  • Ironic... (Score:4, Funny)

    by weave ( 48069 ) on Saturday January 25, 2003 @08:03AM (#5156178) Journal
    /. runs a story on main page about huge security hole in all web servers that will bring the net to its knees, but it really only affects IE clients. They don't run a story about what may end up the biggest net story of the year, ala code red, the MS SQL worm running wild on the net now and shutting down entire sites and playing havoc with the backbone.

    /. posters work around the damage in the story and start posting comments en masse about the SQL attack -- the real story this day -- leaving people who lack reading comprehension to confuse the two issues, therefore causing a DDOS on their brain.

  • It's lucky that the worm writer didn't make the worm fire out random traffic on random udp ports with spoofed addresses.

    It's only the fact the traffic is all destined for a certain destination port that makes it easy to filter.
    You are filtering it out on your firewalls, aren't you?
    /sbin/iptables -I FORWARD -p udp --dport 1434 -j DROP

    This could have been a lot lot harder to filter out. I expect we'll see ThisWorm v2 soon.

    I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...
    • I dread the day someone finds a hole in Apache, Sendmail or something really popular and writes a worm like this...

      I dread the day when someone writes a worm exploiting unpatched windows desktops. So far, code red and this one (code blue?! -- would be fitting) have infected only unpatched windows servers. Keeping desktops patched and up-to-date is far more difficult and if a worm hit them, there'd be an insane amount of infected boxes causing havoc on the net.

      • The only difference between unpatched and patched windows boxes is:
        a: whether the exploit is known about (which it was here),
        b: whether there was a release (which there was here)
        and c: whether admins of these boxes apply it. (which is the age old problem)

        Targetting SQL servers is quite clever, as many of them will be in hosting centres with 34Mbs, burstable to 155Mb (for example).
        • Targetting SQL servers is quite clever, as many of them will be in hosting centres with 34Mbs, burstable to 155Mb (for example).
          Any DBA who lets his database server connect directly to the internet deserves to be drawn and quartered. There's no reason whatsoever for a database server to be talking to the internet; all external SQL requests should be made via a middle tier. You don't run 2 tier client-server apps over the internet without some kind a VPN or some other secure tunnel.

          Likewise, you shouldn't be running a database on the same box as your web server for any kind of serious production system - the web server goes on the DMZ, and the database server goes behind the firewall and only talks to trusted machines. Note that this applies to ANY database server, not just MS-SQL Server.

  • Can't you people puhleze consider doing basic checking on the drivel you choose to post here? This is just embarassing, coming from people who purport to be 'Nerds'.

    /. seems to have degenerated to the lowest common denominator between hack journalism(sic) and tech(sic) fluffery.

    I've stopped taking the time to M2, why bother when the base quality of this feed has dropped this low. You-all want to enhance quality on this site? Consider an M-system for the original posts/editors.

  • lets blame him anyway

  • OK, perhaps I need more coffee this morning, but I cannot see how TRACE would be used to cause harm - perhaps somebody can post this in simple terms.

    As I understand it:

    1) My browser requests a page from www.evilhaxor.org.
    2) ??????
    3) My browser sends a TRACE request to slashdot.org.
    4) slashdot.org sends back to my browser my cookie data.
    5) ????
    6) My browser sends ????? to www.evilhaxor.org.
    7) ????
    8) Profit!

    OK, sorry, but having more than one ???? is sufficient to make a plan unworkable.

    Besides, I run with Javascript off - so I guess the only real exploitable would be the Flash plugin (damn I will be glad when this bug [mozilla.org] is fixed!)

  • Bullshit (Score:3, Informative)

    by Cally ( 10873 ) on Saturday January 25, 2003 @12:57PM (#5157169) Homepage
    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.

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close