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