POS#1 Self-Executing HTML: Internet Explorer 5.5 and 6.0 Part III

[http-equiv@excite.com]

Wednesday, November 5, 2003

In our never-ending quest for entertainment, we commece from
this date forward to end-2004 our POS series of findings. That
is the 'perfect operating system'. Today we debut and regurgitate
new and not so new for fun as follows. A warm up for the New Year if
you will !:

The following file is an html file comprising both scripting and an
executable [*.exe].

We inject scripting and an executable into the html file which is
designed to point back to the executable in the html file and execute
it. Provided the html file is an html file, Internet Explorer 5.5 and
6.0 will execute it.

Because it is an html file proper, Internet Explorer opens it. The
scripting inside is then parsed and fired. That scripting is pointing
back to the same executable file and because it is a self-executing
html file, it executes !

Fully self-contained harmless *.exe:

CAUTION: back up notepad.exe before opening

http://www.malware.com/self-exec.zip

What a POS !

Be aware of html files out there.

--
http://www.malware.com

[Kurt Seifried]

> In our never-ending quest for entertainment, we commece from
> this date forward to end-2004 our POS series of findings. That
> is the 'perfect operating system'. Today we debut and regurgitate
> new and not so new for fun as follows. A warm up for the New Year if
> you will !:

This is easy to avoid. Just set the kill bit for the affected Active
component, Adodb.Stream for which the CLSID is
4B106874-DD36-11D0-8B44-00A024DD9EFF.


Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

[Kurt Seifried]

> >> In our never-ending quest for entertainment, we commece from
> >> this date forward to end-2004 our POS series of findings. That
> >> is the 'perfect operating system'. Today we debut and regurgitate
> >> new and not so new for fun as follows. A warm up for the New Year if
> >> you will !:
> >
> > This is easy to avoid. Just set the kill bit for the affected Active
> > component, Adodb.Stream for which the CLSID is
> > 4B106874-DD36-11D0-8B44-00A024DD9EFF.
>
> {4B106874-DD36-11D0-8B44-00A024DD9EFF} is the Local Troubleshooter
control.
>
> The ADODB.Stream control, an important part of several current IE
exploits,
> is {00000566-0000-0010-8000-00AA006D2EA4}.
>
> MS KB article about the kill bit:
>
> <http://support.microsoft.com/support/kb/articles/q240/7/97.asp>
>
> Disable Active scripting for untrusted sites.

Ack, my bad, I cut and paste the wrong one (to many bits to kill, and after
a while CLSID's all look the same). It should also be noted that exploit
code for this problem has been around since early (i.e. first week) of
September, and it at least one major virus has used it.

The good news is that MS is setting kill bits with some service packs, the
bad news is that they aren't publicizing what CLSID's need to be killed.
Listing MS IE installed components is relatively simple:

HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components

The bad news is this does not cover "built-in" components. As well it isn't
always the most helpful:

CLSID: 3bf42070-b3b1-11d1-b5c5-0000f8051515
version: 1.0161.1890.3
uniscribe
USP10

No link in the registry to any files, or what it does. Google indicates it
most likely is Japanese language support.

If anyone knows a tool for finding out the CLSID of an ActiveX object I
would love to know it. Essentially something that would pop up the CLSID of
a program when it runs so when you visit a web page and an activex
components runs or is installed you can get ahold of the CLSID of it.

The MS OLE viewer:

http://www.microsoft.com/com/resources/oleview.asp

Only works for installed ones, one site covering the kill bit says:

"Determine the CLSID for the ActiveX control that you want to disable. If
you are not sure of the CLSID for the control, contact the manufacturer."

Which isn't overly helpful in most cases. Symantec goes with:

"To determine which CLSID corresponds with the ActiveX control that you want
to disable, first remove all of the ActiveX controls that are currently
installed. Then install the control that you want to disable and add the
Kill Bit to its CLSID. "

In other words no good methods for enumerating CLSID's seem to exist.

>
> - Art



Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/

[James C. Slora Jr.]

Kurt Seifried wrote Friday, November 07, 2003 4:38 PM

> In other words no good methods for enumerating CLSID's seem to exist.

Doesn't HKLM\Software\Classes\(control name)\CLSID do the job OK?
You can also search HKLM\Software\Classes\ for the control name - it will
turn up another listing under (CLSID). This key is useful because it
specifies both the ProgID (specific version of the control) and the
VersionIndependentProgID if there is one.

Speaking of which, other ADODB.Stream control versions are listed in Classes
on machines that have been updated with various versions of MDAC:
ADODB.Stream.2.5
ADODB.Stream.2.7
etc.

These also work just fine in the malware script. Substitute
"Adodb.Stream.2.5" for "Adodb.Stream" in the script if the target machine
has ever had MDAC 2.5 installed - 2.7 is probably a better target because
IIRC it was a Critical Update that is likely to be installed on patched
machines. I'm too lazy to verify this.

This is not an additional vulnerability unless Microsoft somehow fails to
take these into acccount when they someday patch IE against http-equiv's
exploit, but it can be used to bypass overly explicit detection of
http-equiv's code. The CLSID for the version-specific object names is the
same as the version-independent ADODB.Stream, so the same kill bit entry
will kill them.

I think setting the kill bit for ADODB.Stream will cause collateral damage
in some environments. For instance Intranet ASP pages that incorporate file
downloads will be killed if the pages were build using ADO.

[Thor Larholm]

> From: "Cowperthwaite, Eric" <eric.cowperthwaite@eds.com>
> On a related topic,
>
> Does anyone have a method to programatically (perhaps using registry
> entries) change security settings in Internet Explorer for a specific zone.
> For example, if I wanted to disable active scripting for the Internet Zone
> for 1000 end users by pushing a script, reg entry or something similar to
> them.

Description of Internet Explorer Security Zones Registry Entries

SUMMARY
This document describes how and where Internet Explorer security zones and
privacy settings are stored and managed in the registry.

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q182/5/69.ASP&NoWebContent=1

http://tinyurl.com/ubfq



Regards
Thor Larholm
Senior Security Researcher
PivX Solutions, LLC

Get our research, join our mailinglist - http://pivx.com/larholm/

[Robert C. Auch]

From: "Cowperthwaite, Eric" <eric.cowperthwaite@eds.com>
> On a related topic,
>
> Does anyone have a method to programatically (perhaps using registry
> entries) change security settings in Internet Explorer for a specific
zone.
> For example, if I wanted to disable active scripting for the Internet
Zone
> for 1000 end users by pushing a script, reg entry or something similar
to
> them.

If you're using a Windows 2000 or higher network (servers and
workstations), you can use Group Policy (Edit your local IE settings as
you want them to be for all users, then Create / edit a policy, go to
User Configuration/Windows Settings/Internet Explorer
Maintenance/Security, click "Import the current security zones and
privacy settings", and then you can edit from there.

IF you follow this method, I STRONGLY suggest you use a single station
for all GPO updates in your network - there's a small problem with
service packs potentially causing all GPO settings to be lost due to
date-checking of GPO modules.

The other option that I'm aware of is a product called ScriptLogic
(again, only MS-network aware, but I'm willing to bet a good Netware
admin can get it to run for all user's logon script with little
prodding) which runs on NT4 and higher networks, which will allow you to
set a host of registry settings at logon. www.scriptlogic.com

If you're a programmer, use the registry settings Thor just emailed.

Robert Auch=20
http://www.totalnetsolutions.net=20

[Evans, Arian]

>On a related topic,
>
>Does anyone have a method to programatically (perhaps using registry
>entries) change security settings in Internet Explorer for a=20
>specific zone.
>For example, if I wanted to disable active scripting for the=20
>Internet Zone
>for 1000 end users by pushing a script, reg entry or something=20
>similar to
>them.

You can via GPO in AD 2k or 2003. To set an IE GPO in 2k:

Start>Programs>Administrative Tools>Active Directory Users and Computers
>[OU Name]>Rt-click>Properties>|Group Policy|New|Edit:

>User Configuration>Windows Settings>Internet Explorer
Maintenance>Security
>dbl-click 'Security Zones and Content Ratings' and select 'Import
Current
Security Zones' and then click |Modify Settings|.

note: you can't set a GPO on a CN; has to be an OU.

If you are looking for a programmatic solution, you could use ADSI and
script
your own enterprise-wide settings/changes. You can do about anything
with
Windows you want through ADSI using VB Script, Perl, or anything else it
supports. Of course if you're using AD I think using a GPO is simplest.

Arian Evans
Sr. Security Engineer
FishNet Security

Phone: 816.421.6611
Toll Free: 888.732.9406
Fax: 816.421.6677

The information transmitted in this e-mail is intended only for the =
addressee and may contain confidential and/or privileged material.=20
Any interception, review, retransmission, dissemination, or other use =
of, or taking of any action upon this information by persons or entities
other than the intended recipient is prohibited by law and may subject =
them to criminal or civil liability. If you received this communication=20
in error, please contact us immediately at 816.421.6611, and delete the =
communication from any computer or network system.