Bugtraq mailing list archives

RE: SECURE SOCKETS LAYER COELACANTH: Phreak Phishing Expedition


From: "Drew Copley" <dcopley () eEye com>
Date: Fri, 11 Jun 2004 15:48:15 -0700

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 () znep com> 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 () excite com [mailto:1 () malware com] 
Sent: Thursday, June 10, 2004 8:08 PM
To: Drew Copley; osioniusx () yahoo com
Cc: brett.moore () security-assessment com
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










Current thread: