RE: [Full-Disclosure] RE: SECURE SOCKETS LAYER COELACANTH: Phreak Phishing Expedition
I played around with it a bit just now and thus far I have been unable to
read any cookies or access the dom of a page located on another domain
Try pasting javascript:alert(document.cookie) in the address bar when the
e-gold page is loaded for instance it will show the cookie of the e-gold
page instead of the one from microsoft.com, (as it should)
Something like win = window.open('http://www.microsoft.com'); will not let
you access it's document object, so those checks appear to be in place
So while pretty similar to Marc Slemko's bug it's effects are quite
different and require further study
-----Original Message-----
From: full-disclosure-admin@xxxxxxxxxxxxxxxx
[mailto:full-disclosure-admin@xxxxxxxxxxxxxxxx] On Behalf Of Drew Copley
Sent: zaterdag 12 juni 2004 0:48
To: bugtraq@xxxxxxxxxxxxxxxxx; ntbugtraq@xxxxxxxxxxxxxxxxxxxxxx;
full-disclosure@xxxxxxxxxxxxxxxx
Cc: brett.moore@xxxxxxxxxxxxxxxxxxxxxxx; 1@xxxxxxxxxxx
Subject: [Full-Disclosure] RE: SECURE SOCKETS LAYER COELACANTH: Phreak
Phishing Expedition
As a addendum, perhaps, though I wouldn't doubt someone
might make some nice proof of concept code for this...
A similiar issue of this kind was found in IE a few
years ago - remember of course - it is IE's fault that they
are not properly parsing this, regardless of what they need
to parse... so this is ultimately a Microsoft bug...
http://groups.google.com/groups?q=group:bugtraq+dns+wildcard&hl=en&lr=&i
e=UTF-8&selm=bugtraq/Pine.BSF.4.20.0111142031560.527-100000%40alive.znep
.com&rnum=1
Useful extract:
<quote>
Marc Slemko <marcs@xxxxxxxx> Date: 2001-11-15 19:11:45 PST
"The patch for MS01-055 released today by Microsoft includes three
fixes. Two of them are for cookie stealing bugs. One of those
cookie stealing bugs was previously publicized on bugtraq, details on
the
other are now available at
http://alive.znep.com/~marcs/security/iecookie2/";
...
Details
The details are very trivial. Why am I writing up this big document
anyway? Hmm. Loading a URL such as:
http://passport.com%20.sub.znep.com/cgi-bin/cookies
...will cause IE to connect to the hostname specified, but send the
cookies to the server based on the hostname before the "%20", in this
case passport.com. The "%20" is the URL encoded version of a space
character. "%20" isn't the only character that works, there are a
variety of others that are also misparsed.
For this to work, the hostname "passport.com
.1005795014.sub.znep.com"
must be resolvable as a hostname by the client. In this case, I did
this by creating a wildcard A record for *.sub.znep.com, so any
hostname under sub.znep.com will get resolved to a particular IP
address. This attack does require that the attacker have access to
configure a DNS server in such a way, however gaining such access
anonymously or pseudo-anonymously is trivial.
<end quote>
Similiar yet quite different in affect, for in one case, you did
not have full spoofing -- now you have full spoofing, which allows
you to run code.
I am quite surprised Microsoft did not properly fix this way back
then.
I believe some old, free dns systems should allow these kinds of
wildcards, like dyndns, but I am not sure. There should certainly
be other methods of exploitation, regardless... and it very well may
some ownable sites already -- if not some free hosting sites.
> -----Original Message-----
> From: http-equiv@xxxxxxxxxx [mailto:1@xxxxxxxxxxx]
> Sent: Thursday, June 10, 2004 8:08 PM
> To: Drew Copley; osioniusx@xxxxxxxxx
> Cc: brett.moore@xxxxxxxxxxxxxxxxxxxxxxx
> Subject: SECURE SOCKETS LAYER COELACANTH: Phreak Phishing Expedition
>
>
>
> as sent out, this is the one that didn't get away :)
>
> ---
>
> We wrap this up with a full-on ssl site spoof. It seems limited
> how far you can 'shove' the real domain out of the way, but just
> enough to make it convincing so we adapt the window to 'cover'
> it up. Interestingly [with apologies to e-gold for playing with
> their site], they have a secured connection [ignore the warning]
> which gives us our https, our little golden 'safe' padlock and
> most interestingly, all the links inside the site function and
> show the spoofed address:
>
>
> http://www.malware.com/gutted.html
>
> couple all that with the absurd ability to trick Internet
> Explorer into believing it is in a 'trusted zone' by inserting
> whatever gibberish you want into the fake link regardless of the
> actual domain, and you have the catch of the day.
>
> Big thanks to Drew Copley for whacking the sucker on the head,
> Brett Moore for correctly pointing out that it can be achieved
> without the 'redir' thing as well being able to stuff it with
> anything else you want and expedition leader: 'bitlance winter'
> who sighted it, tracked it, snagged it and reeled it in.
>
> End Call
>
> --
> http://www.malware.com
>
>
>
>
>
>
>
>
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html