SECURE SOCKETS LAYER COELACANTH: Phreak Phishing Expedition

[http-equiv@excite.com]

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

[Drew Copley]

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=3D...rd&hl=3Den&lr=
=3D&i
e=3DUTF-8&selm=3Dbugtraq/Pine.BSF.4.20.0111142031560.527-100000%40alive.z=
nep
..com&rnum=3D1

Useful extract:

<quote>

Marc Slemko <marcs@znep.com> Date: 2001-11-15 19:11:45 PST=20

"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.
=20
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.=20

I am quite surprised Microsoft did not properly fix this way back
then.=20

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]=20
> 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
>=20
>=20
>=20
> as sent out, this is the one that didn't get away
>=20
> ---
>=20
> We wrap this up with a full-on ssl site spoof. It seems limited=20
> how far you can 'shove' the real domain out of the way, but just=20
> enough to make it convincing so we adapt the window to 'cover'=20
> it up. Interestingly [with apologies to e-gold for playing with=20
> their site], they have a secured connection [ignore the warning]=20
> which gives us our https, our little golden 'safe' padlock and=20
> most interestingly, all the links inside the site function and=20
> show the spoofed address:
>=20
> =20
> http://www.malware.com/gutted.html
>=20
> couple all that with the absurd ability to trick Internet=20
> Explorer into believing it is in a 'trusted zone' by inserting=20
> whatever gibberish you want into the fake link regardless of the=20
> actual domain, and you have the catch of the day.
>=20
> Big thanks to Drew Copley for whacking the sucker on the head, =20
> Brett Moore for correctly pointing out that it can be achieved=20
> without the 'redir' thing as well being able to stuff it with=20
> anything else you want and expedition leader: 'bitlance winter'=20
> who sighted it, tracked it, snagged it and reeled it in.
>=20
> End Call
>=20
> --=20
> http://www.malware.com
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20

[Nick FitzGerald]

"Drew Copley" <dcopley@eEye.com> reminded us:

> 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=gr...rd&hl=en&lr=&i
> e=UTF-8&selm=bugtraq/Pine.BSF.4.20.0111142031560.527-100000%40alive.znep
> .com&rnum=1
>
> Useful extract:
>
> <quote>
<<snip>>
> 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.
<<snip>>
> <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.

_Also_ quite similar to the much more recent spoofs based on inclusion
of %00/%01/binary null characters (some of which also affected other
browsers). At that time it was reported briefly in a couple of places
that "some other" non-printing characters had much the same effect on
IE as the %00 parsing flaw.

This would seem to be yet another flaw in a more general class of
(HTML) URL parsing bugs.

> I am quite surprised Microsoft did not properly fix this way back
> then.

Really?

Surely you are just being polite?

This is entirely consistent with a long line of shoddy "fixes" from
Microsoft (and, to be fair, many other vendors). Instead of seeing the
"%20 bug" reported by Slemko above for what it turns out it was -- a
clear indication something was horribly broken in multiple parts of the
codebase where (HTML) URL parsing occurs, it is now quite clear that it
was seen as a "there is a problem if '%20' is present in URLs" problem.

When "fixing" the %00/binary null issue recently, was _that_ seen for
what it really was -- a clear indication there was something horribly
broken in multiple parts of the codebase where (HTML) URL parsing
occurs?

Nope.

Despite all that extra security training the code monkeys in Redmond
(or perhaps Bangalore?) had as a result of Billy Boy's much publicized
Security Initiative, the same old blinkers as to locating the source of
the _reported problem_ were apparently still firmly in place. Rather
than opening an exhaustive analysis to uncover the underlying problem
that could have resulted in them properly fixing the (apparently still
undiscovered) base cause of the horribly broken (HTML) URL parsing
code, it seems "fixing the reported %00 problem" was the objective.

Lest anyone think this is an unusual, or possibly unique case with MS
products, I'll simply point out that we have seen multiple similar
instances with macro security issues in Word and the other Office
products where a bug is reported in one or other of the products in the
suite, fixed and subsequently the same bug is found in yet other Office
products. We also saw very similar failures of vulnerability analysis
in cases such as the Incorrect MIME Type and Incorrect Object Data Type
vulnerabilities.

The repetitive nature of some of the patterns of vulnerabilities we see
in its products suggests that the hugely labyrinthine codebase and the
distributed and always-changing make-up of the teams responsible for
specific components and products, means that the same functionality is
implemented over and over by groups who do not talk with each other.
Given the monstrous size of the whole codebase, its continual, rapid
growth and the market-grabbing strategy of stuffing more and more of
what is traditionally considered "application layer" functionality into
the OS ("the DoJ defence" in the IE/Netscape case and potentially to be
used in future against media player makers, software firewall makers,
perhaps AV developers, and no doubt all manner of others) we will see
many, many more instances of these repeated patterns of vulnerability
exposure because the scale of the problem is far beyond what the human
capital at MS can cope with and the problem is computationally
intractible (ala Turing) so cannot be fixed by throwing more technology
at it. As it is incredibly unlikely the whole morass of Windows code
will be ditched and re-written intelligently from scratch, I am quite
confident in this prediction.


Regards,

Nick FitzGerald