RE: [Fwd: [Full-Disclosure] COELACANTH: Phreak Phishing Expedition]

[Drew Copley]

> Subject: [Full-Disclosure] COELACANTH: Phreak Phishing Expedition
> From: "http-equiv@excite.com" <1@malware.com>
> Date: Thu, June 10, 2004 12:35 pm
> To: full-disclosure@lists.netsys.com
> --------------------------------------------------------------
> ------------
>=20
>=20
>=20
> Thursday, June 10, 2004
>=20
> The following was presented by 'bitlance winter' of Japan today:
>=20
> <a href=3D"http://www.microsoft.com%2F redir=3Dwww.e-
> gold.com">test</a>
>=20
> Quite inexplicable from these quarters. Perhaps someone with
> server 'knowledge' can examine it.
>=20
> It carries over the address into the address bar:
>=20
> [screen shot: http://www.malware.com/gosh.png 72KB]
>=20
> while redirecting to egold. The key being %2F without that it
> fails. The big question is where is the 'redir' and why is it
> only applicable [so far] to e-gold. Other sites don't work and e-
> gold is running an old Microsoft-IIS/4.0.


IE makes this into a connection with e-gold.com like so:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR
1.1.4322; .NET CLR 1.0.3705)
Host: www.microsoft.com/ redir=3Dwww.e-gold.com
Connection: Keep-Alive

It never touches microsoft.com.

What is interesting, though, is IE spoofs the zone. If you change
www.microsoft.com
in there to a site in your trusted zone, you will see e-gold read as
your
trusted zone.

So, you should be able to bounce from any trusted zone and theoritically
from
local zone -- and with adodb still being open, you should be able to
run code because of the open adodb issue.

IE doesn't talk to e-gold first. It connects to it. It sends the GET
request,
it receives the first page.=20

But, can't replicate with other servers. It requires some more research.


>=20
> Working Example:
>=20
> http://www.malware.com/golly.html
>=20
>=20
> credit: 'bitlance winter'
>=20
>=20
> End Call
>=20
> --=20
> http://www.malware.com
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>=20
>=20
>=20

[Thor Larholm]

You can't replicate this with most other servers because the Host header
is set to a non-existant site on most servers.

Whenever IIS or Apache receives a request it will first locate the
proper site based on the IP adress being used, after which it will
lookup based on the Host header. In the case of e-gold, they have simply
not specified a Host header for the IIS website that they configured.
You can send a HTTP request to e-gold.com with "Host: foobar" and their
site still comes up, even though you should only get their site with a
header such as "Host: e-gold.com" or "Host: www.e-gold.com".

HTTP 1.1 requires the use of a Host header and it is bad practice to
accept HTTP requests without a Host header that corresponds to a locally
configured site. In most cases with IIS, this only happens if you are
using the Default Website or explicitly has choosen to not specify a
Host header for the site. You can specify multiple Host headers for a
site so there is not much excuse not to do so.

Whenever IE wants to send an HTTP request it first needs to determine
what server to connect to. Because of the URL escaping IE disregards
anything before the slash and equal sign, and sees that it has to send
an HTTP request to www.e-gold.com. It is only after IE has determined
what server to request information from that it URL decodes the URI and
ends up with http://www.microsoft.com/redir=3Dwww.e-gold.com, which it
then displays in the Address Bar and subsequently uses to determine what
security zone it should use to render the HTML. IE only decides what
security zone to use based on the Address Bar value after it has
successfully downloaded all of the HTML (untill then it is in the
Unknown Zone), at which point the URL decoding has long since happened.

If you want to exploit this to serve content from your site in the
security zone of another site, you will need to disregard the Host
header being sent by the client. A perfect candidate you can use to gain
additional privileges is WindowsUpdate.microsoft.com or
oca.microsoft.com who are both in the Trusted Sites security zone on a
default installation of Windows Server 2003 and Windows XP SP2.=20

You should be able to use this to compromise Windows XP SP2 through
Internet Explorer despite the My Computer zone hardening since the
Trusted Sites Zone has all of the privileges you need to plant and
execute a file.



Regards

Thor Larholm
Senior Security Researcher
PivX Solutions
24 Corporate Plaza #180
Newport Beach, CA 92660
http://www.pivx.com
thor@pivx.com
Stock symbol: (PIVX)
Phone: +1 (949) 231-8496
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

PivX defines a new genre in Desktop Security: Proactive Threat
Mitigation.=20
<http://www.pivx.com/qwikfix>


-----Original Message-----
From: Drew Copley [mailto:dcopley@eEye.com]=20
Sent: Thursday, June 10, 2004 4:40 PM
To: full-disclosure@lists.netsys.com; bugtraq@securityfocus.com
Subject: RE: [Fwd: [Full-Disclosure] COELACANTH: Phreak Phishing
Expedition]





> Subject: [Full-Disclosure] COELACANTH: Phreak Phishing Expedition
> From: "http-equiv@excite.com" <1@malware.com>
> Date: Thu, June 10, 2004 12:35 pm
> To: full-disclosure@lists.netsys.com
> --------------------------------------------------------------
> ------------
>=20
>=20
>=20
> Thursday, June 10, 2004
>=20
> The following was presented by 'bitlance winter' of Japan today:
>=20
> <a href=3D"http://www.microsoft.com%2F redir=3Dwww.e- =
gold.com">test</a>
>=20
> Quite inexplicable from these quarters. Perhaps someone with server=20
> 'knowledge' can examine it.
>=20
> It carries over the address into the address bar:
>=20
> [screen shot: http://www.malware.com/gosh.png 72KB]
>=20
> while redirecting to egold. The key being %2F without that it fails.=20
> The big question is where is the 'redir' and why is it only applicable

> [so far] to e-gold. Other sites don't work and e- gold is running an=20
> old Microsoft-IIS/4.0.


IE makes this into a connection with e-gold.com like so:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR
1.1.4322; .NET CLR 1.0.3705)
Host: www.microsoft.com/ redir=3Dwww.e-gold.com
Connection: Keep-Alive

It never touches microsoft.com.

What is interesting, though, is IE spoofs the zone. If you change
www.microsoft.com in there to a site in your trusted zone, you will see
e-gold read as your trusted zone.

So, you should be able to bounce from any trusted zone and theoritically
from local zone -- and with adodb still being open, you should be able
to run code because of the open adodb issue.

IE doesn't talk to e-gold first. It connects to it. It sends the GET
request, it receives the first page.=20

But, can't replicate with other servers. It requires some more research.


>=20
> Working Example:
>=20
> http://www.malware.com/golly.html
>=20
>=20
> credit: 'bitlance winter'
>=20
>=20
> End Call
>=20
> --
> http://www.malware.com
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>=20
>=20
>=20

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Thor Larholm]

I added the following to a re-send of my post, it didn't make it into
the first :)

Other than gaining access to the Trusted Sites zone, you can further
gain access to the execution privileges of the Local Intranet zone by
explicitly leaving out a TLD (Top Level Domain) in the first part of the
query. The following immediately gain Local Intranet privileges:

http://whatever%3fredir=3Dwww.e-gold.com
http://whatever%3fredir=3Dyourevilsite.com

The Local Intranet zone is independent of any pre-requisite sites being
added to any configuration, and will work equally well on all Windows
targets.


Thor

-----Original Message-----
From: Thor Larholm=20
Sent: Thursday, June 10, 2004 6:10 PM
To: Drew Copley; full-disclosure@lists.netsys.com;
bugtraq@securityfocus.com
Cc: ntbugtraq@listserv.ntbugtraq.com
Subject: RE: COELACANTH: Phreak Phishing Expedition]


You can't replicate this with most other servers because the Host header
is set to a non-existant site on most servers.

Whenever IIS or Apache receives a request it will first locate the
proper site based on the IP adress being used, after which it will
lookup based on the Host header. In the case of e-gold, they have simply
not specified a Host header for the IIS website that they configured.
You can send a HTTP request to e-gold.com with "Host: foobar" and their
site still comes up, even though you should only get their site with a
header such as "Host: e-gold.com" or "Host: www.e-gold.com".

HTTP 1.1 requires the use of a Host header and it is bad practice to
accept HTTP requests without a Host header that corresponds to a locally
configured site. In most cases with IIS, this only happens if you are
using the Default Website or explicitly has choosen to not specify a
Host header for the site. You can specify multiple Host headers for a
site so there is not much excuse not to do so.

Whenever IE wants to send an HTTP request it first needs to determine
what server to connect to. Because of the URL escaping IE disregards
anything before the slash and equal sign, and sees that it has to send
an HTTP request to www.e-gold.com. It is only after IE has determined
what server to request information from that it URL decodes the URI and
ends up with http://www.microsoft.com/redir=3Dwww.e-gold.com, which it
then displays in the Address Bar and subsequently uses to determine what
security zone it should use to render the HTML. IE only decides what
security zone to use based on the Address Bar value after it has
successfully downloaded all of the HTML (untill then it is in the
Unknown Zone), at which point the URL decoding has long since happened.

If you want to exploit this to serve content from your site in the
security zone of another site, you will need to disregard the Host
header being sent by the client. A perfect candidate you can use to gain
additional privileges is WindowsUpdate.microsoft.com or
oca.microsoft.com who are both in the Trusted Sites security zone on a
default installation of Windows Server 2003 and Windows XP SP2.=20

You should be able to use this to compromise Windows XP SP2 through
Internet Explorer despite the My Computer zone hardening since the
Trusted Sites Zone has all of the privileges you need to plant and
execute a file.



Regards

Thor Larholm
Senior Security Researcher
PivX Solutions
24 Corporate Plaza #180
Newport Beach, CA 92660
http://www.pivx.com
thor@pivx.com
Stock symbol: (PIVX)
Phone: +1 (949) 231-8496
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

PivX defines a new genre in Desktop Security: Proactive Threat
Mitigation.=20
<http://www.pivx.com/qwikfix>


-----Original Message-----
From: Drew Copley [mailto:dcopley@eEye.com]=20
Sent: Thursday, June 10, 2004 4:40 PM
To: full-disclosure@lists.netsys.com; bugtraq@securityfocus.com
Subject: RE: [Fwd: [Full-Disclosure] COELACANTH: Phreak Phishing
Expedition]





> Subject: [Full-Disclosure] COELACANTH: Phreak Phishing Expedition
> From: "http-equiv@excite.com" <1@malware.com>
> Date: Thu, June 10, 2004 12:35 pm
> To: full-disclosure@lists.netsys.com
> --------------------------------------------------------------
> ------------
>=20
>=20
>=20
> Thursday, June 10, 2004
>=20
> The following was presented by 'bitlance winter' of Japan today:
>=20
> <a href=3D"http://www.microsoft.com%2F redir=3Dwww.e- =
gold.com">test</a>
>=20
> Quite inexplicable from these quarters. Perhaps someone with server
> 'knowledge' can examine it.
>=20
> It carries over the address into the address bar:
>=20
> [screen shot: http://www.malware.com/gosh.png 72KB]
>=20
> while redirecting to egold. The key being %2F without that it fails.
> The big question is where is the 'redir' and why is it only applicable

> [so far] to e-gold. Other sites don't work and e- gold is running an
> old Microsoft-IIS/4.0.


IE makes this into a connection with e-gold.com like so:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR
1.1.4322; .NET CLR 1.0.3705)
Host: www.microsoft.com/ redir=3Dwww.e-gold.com
Connection: Keep-Alive

It never touches microsoft.com.

What is interesting, though, is IE spoofs the zone. If you change
www.microsoft.com in there to a site in your trusted zone, you will see
e-gold read as your trusted zone.

So, you should be able to bounce from any trusted zone and theoritically
from local zone -- and with adodb still being open, you should be able
to run code because of the open adodb issue.

IE doesn't talk to e-gold first. It connects to it. It sends the GET
request, it receives the first page.=20

But, can't replicate with other servers. It requires some more research.


>=20
> Working Example:
>=20
> http://www.malware.com/golly.html
>=20
>=20
> credit: 'bitlance winter'
>=20
>=20
> End Call
>=20
> --
> http://www.malware.com
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>=20
>=20
>=20

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Jelmer]

Almost correct, though not quite, I fired up a packetsniffer while clicking
the link and witnessed a dns lookup taking place

--snip--

Standard query www.jelmer.com?redir=www.e-gold.com

--snip--

This actually resolves to e-gold As you can see

C:\ >ping www.jelmer.com?redir=www.e-gold.com

Pinging www.jelmer.com?redir=www.e-gold.com [63.240.230.10] with 32 bytes
of data:

This is because they have setup wildcard dns for e-gold.com
So the combination ignore host header *AND* wildcard dns leads to an
exploitable condition

Tmf.nl for instance uses wildcard dns but complains about a malformed Host
header

<a href="http://www.microsoft.com%2F redir=www.tmf.nl">test</a>


-----Original Message-----
From: Thor Larholm [mailto:thor@pivx.com]
Sent: vrijdag 11 juni 2004 3:10
To: Drew Copley; full-disclosure@lists.netsys.com; bugtraq@securityfocus.com
Cc: ntbugtraq@listserv.ntbugtraq.com
Subject: RE: COELACANTH: Phreak Phishing Expedition]

You can't replicate this with most other servers because the Host header
is set to a non-existant site on most servers.

Whenever IIS or Apache receives a request it will first locate the
proper site based on the IP adress being used, after which it will
lookup based on the Host header. In the case of e-gold, they have simply
not specified a Host header for the IIS website that they configured.
You can send a HTTP request to e-gold.com with "Host: foobar" and their
site still comes up, even though you should only get their site with a
header such as "Host: e-gold.com" or "Host: www.e-gold.com".

HTTP 1.1 requires the use of a Host header and it is bad practice to
accept HTTP requests without a Host header that corresponds to a locally
configured site. In most cases with IIS, this only happens if you are
using the Default Website or explicitly has choosen to not specify a
Host header for the site. You can specify multiple Host headers for a
site so there is not much excuse not to do so.

Whenever IE wants to send an HTTP request it first needs to determine
what server to connect to. Because of the URL escaping IE disregards
anything before the slash and equal sign, and sees that it has to send
an HTTP request to www.e-gold.com. It is only after IE has determined
what server to request information from that it URL decodes the URI and
ends up with http://www.microsoft.com/redir=www.e-gold.com, which it
then displays in the Address Bar and subsequently uses to determine what
security zone it should use to render the HTML. IE only decides what
security zone to use based on the Address Bar value after it has
successfully downloaded all of the HTML (untill then it is in the
Unknown Zone), at which point the URL decoding has long since happened.

If you want to exploit this to serve content from your site in the
security zone of another site, you will need to disregard the Host
header being sent by the client. A perfect candidate you can use to gain
additional privileges is WindowsUpdate.microsoft.com or
oca.microsoft.com who are both in the Trusted Sites security zone on a
default installation of Windows Server 2003 and Windows XP SP2.

You should be able to use this to compromise Windows XP SP2 through
Internet Explorer despite the My Computer zone hardening since the
Trusted Sites Zone has all of the privileges you need to plant and
execute a file.



Regards

Thor Larholm
Senior Security Researcher
PivX Solutions
24 Corporate Plaza #180
Newport Beach, CA 92660
http://www.pivx.com
thor@pivx.com
Stock symbol: (PIVX)
Phone: +1 (949) 231-8496
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

PivX defines a new genre in Desktop Security: Proactive Threat
Mitigation.
<http://www.pivx.com/qwikfix>


-----Original Message-----
From: Drew Copley [mailto:dcopley@eEye.com]
Sent: Thursday, June 10, 2004 4:40 PM
To: full-disclosure@lists.netsys.com; bugtraq@securityfocus.com
Subject: RE: [Fwd: [Full-Disclosure] COELACANTH: Phreak Phishing
Expedition]





> Subject: [Full-Disclosure] COELACANTH: Phreak Phishing Expedition
> From: "http-equiv@excite.com" <1@malware.com>
> Date: Thu, June 10, 2004 12:35 pm
> To: full-disclosure@lists.netsys.com
> --------------------------------------------------------------
> ------------
>
>
>
> Thursday, June 10, 2004
>
> The following was presented by 'bitlance winter' of Japan today:
>
> <a href="http://www.microsoft.com%2F redir=www.e- gold.com">test</a>
>
> Quite inexplicable from these quarters. Perhaps someone with server
> 'knowledge' can examine it.
>
> It carries over the address into the address bar:
>
> [screen shot: http://www.malware.com/gosh.png 72KB]
>
> while redirecting to egold. The key being %2F without that it fails.
> The big question is where is the 'redir' and why is it only applicable

> [so far] to e-gold. Other sites don't work and e- gold is running an
> old Microsoft-IIS/4.0.


IE makes this into a connection with e-gold.com like so:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-shockwave-flash, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR
1.1.4322; .NET CLR 1.0.3705)
Host: www.microsoft.com/ redir=www.e-gold.com
Connection: Keep-Alive

It never touches microsoft.com.

What is interesting, though, is IE spoofs the zone. If you change
www.microsoft.com in there to a site in your trusted zone, you will see
e-gold read as your trusted zone.

So, you should be able to bounce from any trusted zone and theoritically
from local zone -- and with adodb still being open, you should be able
to run code because of the open adodb issue.

IE doesn't talk to e-gold first. It connects to it. It sends the GET
request, it receives the first page.

But, can't replicate with other servers. It requires some more research.


>
> Working Example:
>
> http://www.malware.com/golly.html
>
>
> credit: 'bitlance winter'
>
>
> End Call
>
> --
> http://www.malware.com
>
>
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Drew Copley]

=20

> -----Original Message-----
> From: Jelmer [mailto:jkuperus@planet.nl]=20
> Sent: Friday, June 11, 2004 3:22 PM
> To: 'Thor Larholm'; Drew Copley;=20
> full-disclosure@lists.netsys.com; bugtraq@securityfocus.com
> Cc: ntbugtraq@listserv.ntbugtraq.com
> Subject: RE: COELACANTH: Phreak Phishing Expedition]
>=20
> Almost correct, though not quite, I fired up a packetsniffer=20
> while clicking
> the link and witnessed a dns lookup taking place
>=20
> --snip--
>=20
> Standard query www.jelmer.com?redir=3Dwww.e-gold.com
>=20
> --snip--
>=20
> This actually resolves to e-gold As you can see
>=20
> C:\ >ping www.jelmer.com?redir=3Dwww.e-gold.com
>=20
> Pinging www.jelmer.com?redir=3Dwww.e-gold.com [63.240.230.10]=20
> with 32 bytes=20
> of data:=20
>=20
> This is because they have setup wildcard dns for e-gold.com
> So the combination ignore host header *AND* wildcard dns leads to an
> exploitable condition
>=20
> Tmf.nl for instance uses wildcard dns but complains about a=20
> malformed Host
> header

Again, everybody ignores the host header. I routinely use "whatever"
as my host header. A poster to bugtraq was correct, though, some
characters
will cause bad request returns with some web servers. Encoding these
characters will allow them through in some situations (Google.com),
and some servers will continue to have problems (apache.org does not
like the backslash unencoded normally -- the other script characters
and such are fine with it).


In some scenarios, encoding the characters should work.

As IE is forming the malformed host header in the connect, and
this is causing some problems with exploitability, it may/probably
is possible to put in some control line feeds to start a new line
for the request header. It might further be noted the full control
line feed sequence is not needed for a new line for some servers...
and there are other characters which are possibly interpreted as
this. (IIS and Apache, have, historically, allowed such situations,
which have helped in IDS evasion scenarios).



>=20
> <a href=3D"http://www.microsoft.com%2F redir=3Dwww.tmf.nl">test</a>
>=20
>=20
> -----Original Message-----
> From: Thor Larholm [mailto:thor@pivx.com]=20
> Sent: vrijdag 11 juni 2004 3:10
> To: Drew Copley; full-disclosure@lists.netsys.com;=20
> bugtraq@securityfocus.com
> Cc: ntbugtraq@listserv.ntbugtraq.com
> Subject: RE: COELACANTH: Phreak Phishing Expedition]
>=20
> You can't replicate this with most other servers because the=20
> Host header
> is set to a non-existant site on most servers.
>=20
> Whenever IIS or Apache receives a request it will first locate the
> proper site based on the IP adress being used, after which it will
> lookup based on the Host header. In the case of e-gold, they=20
> have simply
> not specified a Host header for the IIS website that they configured.
> You can send a HTTP request to e-gold.com with "Host: foobar"=20
> and their
> site still comes up, even though you should only get their site with a
> header such as "Host: e-gold.com" or "Host: www.e-gold.com".
>=20
> HTTP 1.1 requires the use of a Host header and it is bad practice to
> accept HTTP requests without a Host header that corresponds=20
> to a locally
> configured site. In most cases with IIS, this only happens if you are
> using the Default Website or explicitly has choosen to not specify a
> Host header for the site. You can specify multiple Host headers for a
> site so there is not much excuse not to do so.
>=20
> Whenever IE wants to send an HTTP request it first needs to determine
> what server to connect to. Because of the URL escaping IE disregards
> anything before the slash and equal sign, and sees that it has to send
> an HTTP request to www.e-gold.com. It is only after IE has determined
> what server to request information from that it URL decodes=20
> the URI and
> ends up with http://www.microsoft.com/redir=3Dwww.e-gold.com, which it
> then displays in the Address Bar and subsequently uses to=20
> determine what
> security zone it should use to render the HTML. IE only decides what
> security zone to use based on the Address Bar value after it has
> successfully downloaded all of the HTML (untill then it is in the
> Unknown Zone), at which point the URL decoding has long since=20
> happened.
>=20
> If you want to exploit this to serve content from your site in the
> security zone of another site, you will need to disregard the Host
> header being sent by the client. A perfect candidate you can=20
> use to gain
> additional privileges is WindowsUpdate.microsoft.com or
> oca.microsoft.com who are both in the Trusted Sites security zone on a
> default installation of Windows Server 2003 and Windows XP SP2.=20
>=20
> You should be able to use this to compromise Windows XP SP2 through
> Internet Explorer despite the My Computer zone hardening since the
> Trusted Sites Zone has all of the privileges you need to plant and
> execute a file.
>=20
>=20
>=20
> Regards
>=20
> Thor Larholm
> Senior Security Researcher
> PivX Solutions
> 24 Corporate Plaza #180
> Newport Beach, CA 92660
> http://www.pivx.com
> thor@pivx.com
> Stock symbol: (PIVX)
> Phone: +1 (949) 231-8496
> PGP: 0x5A276569
> 6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569
>=20
> PivX defines a new genre in Desktop Security: Proactive Threat
> Mitigation.=20
> <http://www.pivx.com/qwikfix>
>=20
>=20
> -----Original Message-----
> From: Drew Copley [mailto:dcopley@eEye.com]=20
> Sent: Thursday, June 10, 2004 4:40 PM
> To: full-disclosure@lists.netsys.com; bugtraq@securityfocus.com
> Subject: RE: [Fwd: [Full-Disclosure] COELACANTH: Phreak Phishing
> Expedition]
>=20
>=20
>=20
>=20
>=20
> > Subject: [Full-Disclosure] COELACANTH: Phreak Phishing Expedition
> > From: "http-equiv@excite.com" <1@malware.com>
> > Date: Thu, June 10, 2004 12:35 pm
> > To: full-disclosure@lists.netsys.com
> > --------------------------------------------------------------
> > ------------
> >=20
> >=20
> >=20
> > Thursday, June 10, 2004
> >=20
> > The following was presented by 'bitlance winter' of Japan today:
> >=20
> > <a href=3D"http://www.microsoft.com%2F redir=3Dwww.e- =
gold.com">test</a>
> >=20
> > Quite inexplicable from these quarters. Perhaps someone with server=20
> > 'knowledge' can examine it.
> >=20
> > It carries over the address into the address bar:
> >=20
> > [screen shot: http://www.malware.com/gosh.png 72KB]
> >=20
> > while redirecting to egold. The key being %2F without that=20
> it fails.=20
> > The big question is where is the 'redir' and why is it only=20
> applicable
>=20
> > [so far] to e-gold. Other sites don't work and e- gold is=20
> running an=20
> > old Microsoft-IIS/4.0.
>=20
>=20
> IE makes this into a connection with e-gold.com like so:
>=20
> GET / HTTP/1.1
> Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/vnd.ms-powerpoint,
> application/msword, application/x-shockwave-flash, */*
> Accept-Language: en-us
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT=20
> 5.2; .NET CLR
> 1.1.4322; .NET CLR 1.0.3705)
> Host: www.microsoft.com/ redir=3Dwww.e-gold.com
> Connection: Keep-Alive
>=20
> It never touches microsoft.com.
>=20
> What is interesting, though, is IE spoofs the zone. If you change
> www.microsoft.com in there to a site in your trusted zone,=20
> you will see
> e-gold read as your trusted zone.
>=20
> So, you should be able to bounce from any trusted zone and=20
> theoritically
> from local zone -- and with adodb still being open, you should be able
> to run code because of the open adodb issue.
>=20
> IE doesn't talk to e-gold first. It connects to it. It sends the GET
> request, it receives the first page.=20
>=20
> But, can't replicate with other servers. It requires some=20
> more research.
>=20
>=20
> >=20
> > Working Example:
> >=20
> > http://www.malware.com/golly.html
> >=20
> >=20
> > credit: 'bitlance winter'
> >=20
> >=20
> > End Call
> >=20
> > --
> > http://www.malware.com
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >=20
> >=20
> >=20
>=20
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>=20
>=20
>=20
>=20

[Jelmer]

One final addendum to this ongoing thread

Drew Copley was kind enough to point out to me that can steal any user's
windows password simply by having them view a specially prepared page using
this exploit

What basically happens is that the server sends an 8 byte challenge to the
browser, the browser uses the lanman and nt password hashes to generate a
response by appending some zero's to the hash and then using it as a des key
to encode the message. This message explains it more thoroughly

http://www.insecure.org/sploits/l0phtcrack.lanman.problems.html

If you know the response and you know the challenge (obviously we do since
we control what's being sent) you can crack it quite easily using l0phtcrack
Amazing that that insecure lanman hash is still being sent after all that
time

Anyway great find Bitlance winter!!

Updated demo at

http://jelmer.homedns.org/test2.htm

Updated (very messy) code at

http://jelmer.homedns.org/code2.zip



This page does a pretty good job at describing the ntlm protocol

http://www.innovation.ch/java/ntlm.html