From: Dave Aitel (daveimmunitysec.com)
Date: Tue Mar 11 2003 - 00:08:48 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Not to mention the bugs in MAPI RPC endpoints I've already posted about. I
don't think they're fixed yet. You can crash Exchange fairly easily with
SPIKE 2.5 or greater. Makes a good demo in case people think it's still cool
to have MAPI open to the world (or use HTTP-RPC redirection for it).

-dave
----- Original Message -----
From: "Brian W. Spolarich" <bspolarichnephrostherapeutics.com>
To: "Joseph Burton" <joseph_burton1970hotmail.com>;
<focus-mssecurityfocus.com>
Sent: Monday, March 10, 2003 1:13 PM
Subject: RE: Exchange/MAPI/RPC

Joseph Burton wrote:

> My question is simply, why? Why is it dangerous to use MAPI/RPC over
> Internet? Is the password sent in clear text or something? I need
> some good arguments to convince my client to use VPN for the roaming
> users.

  The primary reason in my mind is that the RPC service uses a single UDP
port (135) for service discovery, which means that you need to open this
fairly sensitive service up to the world in order to enable your clients to
connect.

  By default RPC-based servers use random port numbers to listen for
requests, and thus the RPC service locator has to be on a well-known port
for the clients to discover the server listeners (Exchange 2000 has three),
and you have to leave all possible listener ports open as well.

  You can address this by telling Exchange 2000 to listen on ports you
assign yourself:

  http://support.microsoft.com/default.aspx?scid=KB;en-us;q270836

  Thus you'd only have to open up 4 UDP ports to enable your roaming users
to connect. However you've still got to leave the service discovery port
open, so folks can connect and say "where is service X listening at the
moment?" and creates an exposure (its hard to close ALL UDP off inbound if
you want to use DNS, for example). I'm somewhat nervous about the RPC
Locator service as well...the old *nix variants of this service were
notorious for having buffer overflow issues and resulted in arbitrary code
execution attacks with root privileges. I'm sure there are similar issues
lurking in the Windows code as well.

  Given that we're talking about UDP here, we have the increased potential
for packet injection and other "person in the middle" attacks. Given the
increased use of wireless and other unmanaged network configurations, the
potential for this is increased.

  My strong preference is to only enable Exchange remote connectivity via
VPN, or through Outlook Web Access over SSL. A reasonable VPN concentrator
is relatively inexpensive ($2500K for a Cisco 3005 box that will support up
to 100 users), and the client software easy enough to install. My rather
untechnical users seem to "get it", and most opt for the browser-based
access when working remotely.

  Password authentication should take place using NTLM, which doesn't use
plaintext passwords but has its own issues. By default MAPI connections are
unencrypted w/ Outlook, but users can turn this on. I don't know how strong
or well-implemented that cipher system is.

  Have I missed anything important?

  -bws

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]