Microsoft announces new ways to bypass security controls
For those not keeping up with Microsoft, because so many people have started blocking Netbios, RPC, SMB, etc; Microsoft announced yet another way to bypass security. On August 1, Microsoft introduced Exchange 2003. With Outlook 2003 this introduces an new implementation fo Exchange's MAPI protocol over HTTP allowing clients to natively connect to Exchange servers without using a virtual private network (VPN). Steve Conn, Microsoft's Product manager was quoted as "Since we have got a good implementation, we're going to keep supporting it." Microsoft will evangelise the new protocol, and developers of other mail clients and servers will be encouraged to implement it. http://www.microsoft.com/office/ork/xp/beta/three/ch8/OutC07.htm "Outlook 2003 now offers a better alternative to VPN connections -- RPC over HTTP. With this feature, users can have security-enhanced access to their Exchange Server accounts from the Internet when they are working outside your organization's firewall. Users do not need any special connections or hardware, such as smart cards and security tokens, and they can still get to their Exchange accounts even if the Exchange server and client computer behind the firewall are on different networks." By the way, Microsoft's RPC-Over-HTTP uses one of the ports in another Microsoft security advisory concerning RPC vulnerabilities. Extending the list of dangerous ports to include 593, RPC-over-HTTP. A suggested work around, use a virtual private network (VPN). Of course, Microsoft isn't the only one with mail protocol security weaknesses. POP3 is probably responsible for more cleartext passwords being transmitted over the Internet than any other network protocol.
Subject: Microsoft announces new ways to bypass security controls Date: Sun, Sep 14, 2003 at 10:03:32PM -0400 Quoting Sean Donelan (sean@donelan.com):
Of course, Microsoft isn't the only one with mail protocol security weaknesses.
POP3 is probably responsible for more cleartext passwords being transmitted over the Internet than any other network protocol.
That statement is nicely supported by my dnsiff logs from various networking conferences -- the top three have always been: POP webmail without SSL other http apps without SSL. Below this we see IMAP, IM, telnet (rare) and a storm of snmp from windows machines trying to manage HP printers. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE Send your questions to ``ASK ZIPPY'', Box 40474, San Francisco, CA 94140, USA
At 03:22 AM 9/15/2003, Mans Nilsson wrote:
Subject: Microsoft announces new ways to bypass security controls Date: Sun, Sep 14, 2003 at 10:03:32PM -0400 Quoting Sean Donelan (sean@donelan.com):
Of course, Microsoft isn't the only one with mail protocol security weaknesses.
POP3 is probably responsible for more cleartext passwords being transmitted over the Internet than any other network protocol.
That statement is nicely supported by my dnsiff logs from various networking conferences -- the top three have always been:
POP webmail without SSL other http apps without SSL.
We see that even when we offer POP with SSL and SMTP AUTH with SSL, few customers wind up using it. That there are continuing problems with the commercial certificate infrastructure doesn't help matters. Examples of the problems: 1. Eudora contains root certificates only for Verisign and Thawte, and uses its own root certificate store, whereas Microsoft client tools (for all their other weaknesses) include a much broader array of root certificates. If you want to buy certs from someone other than Verisign (since they own Thawte) you have to talk users through integrating other root certs (or your cert) into their copies of Eudora. Or just use a private CA and talk your customers through importing the root cert from your private CA. 2. SSL incompatabilities: Eudora changed their method of negotiation with Eudora 5.2 and later. The result is an inability to negotiate TLS with Sendmail/Openssl. A configuration parameter in Eudora gets it to go back to the "old way" in their code, which works fine. But now we're talking about another case of talking an end user through a configuration. Might be OK for a corporate setting, but it gets pretty problematic for the ISP. We've clearly got the mechanisms to allow encryption on the most important of the protocols. However the infrastructure and compatability issues make them more difficult to employ than should be the case. That these problems show up at networking conferences (IETF, NANOG, etc.), though, really points to a larger problem. If network research, engineering and operations folks can't manage to get encryption deployed for themselves, how likely is it that end customers will use them?
Speaking on Deep Background, the Press Secretary whispered:
We see that even when we offer POP with SSL and SMTP AUTH with SSL, few customers wind up using it. That there are continuing problems with the commercial certificate infrastructure doesn't help matters.
Examples of the problems:
1. Eudora contains root certificates only for Verisign and Thawte, and uses its own root certificate store, whereas Microsoft client tools (for all their other weaknesses) include a much broader array of root certificates. If you want to buy certs from someone other than Verisign (since they own Thawte) you have to talk users through integrating other root certs (or your cert) into their copies of Eudora. Or just use a private CA and talk your customers through importing the root cert from your private CA.
While the approval process for other certs in Eudora is obscure, it at least works. I ran into a brick wall trying to get Infernal Exploder for the Mac to accept same; the Windows version was not a problem.
2. SSL incompatabilities: Eudora changed their method of negotiation with Eudora 5.2 and later. The result is an inability to negotiate TLS with Sendmail/Openssl. A configuration parameter in Eudora gets it to go back to the "old way" in their code, which works fine. But now we're talking about another case of talking an end user through a configuration. Might be OK for a corporate setting, but it gets pretty problematic for the ISP.
Note Eudora 6.0 has a public configuration setting for the flavor of SSL.[1] Yes, it should be automagic but "the nice thing about standards in this industry..." applies lots of places...
We've clearly got the mechanisms to allow encryption on the most important of the protocols. However the infrastructure and compatability issues make them more difficult to employ than should be the case.
That these problems show up at networking conferences (IETF, NANOG, etc.), though, really points to a larger problem. If network research, engineering and operations folks can't manage to get encryption deployed for themselves, how likely is it that end customers will use them?
WhatHeSaid. We really need to do a better job of begging/cajoling/requiring encryption. I know one ISP that requires POP/SMTP be on SSL unless you're on their dialup, and I've heard Worldnet does too. [true?] The rest? [1] At least in the Mac version I can lay hands on.. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
participants (4)
-
Daniel Senie -
David Lesher -
Mans Nilsson -
Sean Donelan