-----BEGIN PGP SIGNED MESSAGE----- I did not deny that this was "real". Using ActiveX to get a web browser to create raw HTTP requests is a nice hack and indeed effective. I explicitly acknowledged it:
>> Is this a useful thing to know if you're looking for a way to >steal cookies? Sure! My objection is to the way that the whole issue was framed and presented. I realize that everyone has to gloss things up a bit for marketting and dumb things down for laypeople, but I think that the press release, the whitepaper and particularly the ExtremeTech article all overstep what is excusable. They are sensational and exagerated. Some examples for the whitepaper and press release: "First of all, anything that attempts to help prevent the xss plague on the web is a good thing." The XSS plague? The only XSS plague I know of is on Bugtraq and other disclosure mailing lists. Is anyone else sick of seeing posts about XSS problems in PHP applications that runs on a total of five sites? Code Red was a plague. Melissa was a plague. In all the time XSS has been around, I only know of a few instances where it has actually been used. Do you have any evidence of an actual XSS epidemic taking place? "What sites currently have TRACE enabled?" The obvious implication here is that an attacker could somehow compromise these sites. There really isn't a point in listing some big name sites that are vulnerable to this after you've stated that nearly everywhere has TRACE enabled. This also makes it look like the problem is focused on the server, when the more serious issue is obviously the ability to use ActiveX objects to create raw HTTP requests. "WHITEHAT DISCOVERS SERIOUS SECURITY FLAW AFFECTING ALL WEB SERVERS WORLDWIDE" (I didn't change the formatting, it's really in all caps) "While researching this issue, we discovered that a vast majority of commercial web sites have this vulnerability," "After discovering the vulnerability, WhiteHat attempted to find a way to mitigate the issue on web servers but found that no web servers had the ability to disable the TRACE command. WhiteHat found a way to work around these oversights but some are not supported by the vendors." "The vulnerability exploits a flaw in the TRACE method which is used to debug web server connections. This is a rarely used portion of the HTTP protocol but is turned on by default in all major web servers." The real heart of this exploit is the ability to (ab)use ActiveX (the only actual example provided) and reportedly JavaScript, Flash, etc. to create raw HTTP requests. That is far more serious than XSS using TRACE. The four above quotes from the press release are all sorry attempts to frame this as a "real" server vulnerability. The fact of the matter is that it's not so simple or serious. There is *nothing* in the press release that indicates that the issue is 100% reliant upon a vulnerability in the web client and has other mitigating factors, such as having to find someone that actually has credentials for the site you want to gain access to. "In terms of significance, the term "pandemic" springs to mind - it is feasible that the majority web applications from web-mail to embedded applications on printers and routers may be affected. Thus, given the pervasive nature of this vulnerability, I see this as one of the most notable exploits since Code Red and Nimda." This is a laughable, sensationalist statement. There is *long* list of issues that have been reported since then that are many times more serious than this. Chunked encoding issues, the OpenSSL overflow, the CVS problem, etc. etc. etc. A year from now, how many credential sets do you think will actually have been compromised using this technique? Do you honestly think it's up in the Code Red and Nimda range? Also, for more IT company praise from Bob Rodger, see here: http://www.act.bm/Aboutus/casestudies/bofbda.html "However, if the web server itself is not configured to deny TRACE, then the security of the domain credentials will reside in the security of the web browser." This is creates a false implication: If you turn off TRACE, the security of the domain credentials no longer resides in the security of the web browser. This is not true. The web browser can still give out credentials if attacked with normal XSS, ActiveX exploits, etc. The web browser must be trusted to protect the credentials it uses, no matter what. I hope that this clarifies my dissapointment with this issue. It's a nice hack, don't get me wrong, but it's much less serious than many other issues that get reported with less hoopla and fluff. Feedback (negative or positive) is welcome. On Wed, 22 Jan 2003 14:25:57 -0800 Jeremiah Grossman <[EMAIL PROTECTED]> wrote: >On Wed, 2003-01-22 at 13:31, [EMAIL PROTECTED] wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> I would like to point out that in order to execute an "XST" attack, > you have to be able >to able to get JavaScript/Flash/etc executed on the victim's system >as a PREREQUISITE. > >certainly. > > >> >> So, to summarize: >> >> If you can get arbitrary JavaScript executed on a web client, >you can use this attack method to >get arbitrary JavaScript executed on a web client, in a different >zone. > > >this is correct. Via a web page, message board, web mail, etc etc >etc. > >> >> Is this a useful thing to know if you're looking for a way to >steal cookies? Sure! >Is this a revolutionary tactic that will allow you to compromise >the security of any of >the webservers listed in the whitepaper? No. > > >Ok... we are not talk about "rooting" the web server here, but >compromising the user credentials client-side. The credentials be >it >cookies or basic authentication, from a protected domain. You can >now >XSS any domain from the users browser even if the domain has no >web apps >at all. > > > > >> This isn't any different from the many, many, many known ways >of violating >someone's HTTP client if you can get them to execute Flash or JavaScript >or ActiveX of your choice. > > >I must disagree... this is a much much different way to perform >a >credential theft. But...for the sake of information, can you provide >me >a link where they do it in this manner? > >We've seen dozens of holes in IE's security constraints that allow >attackers to view files, >steal cookies or execute commands. Unlike Guninski or GreyMagic's >advisories, this one has >simply been built up to ridiculous proportions with marketting language >in the press release >and in the ExtremeTech article. > >Again, not using this method. > > > > > > -----BEGIN PGP SIGNATURE----- Version: Hush 2.2 (Java) Note: This signature can be verified at https://www.hushtools.com/verify wmAEARECACAFAj4uB3sZHHhzcy1pcy1sYW1lQGh1c2htYWlsLmNvbQAKCRDs/5lboNFb hvP+AJ94XqS3YA6E9RhChobRJHFzk5vnZgCgqQsng+fPv111oeL+HeNHBdsQfbk= =1yMW -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
