Type packetstorm
Reporter Georgi Guninski
Modified 2001-03-30T00:00:00


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