Microsoft Builds In Security Bypasses

I am very suspicious of tools that allow you to bypass network security systems. Yes, they make life easier. But if security is important, than all security decisions should be made by a central process; tools that bypass that centrality are very risky.

I didn’t like SOAP for that reason, and I don’t like the sound of this new Microsoft thingy:

We’re always looking for new things that can allow you to do things uniquely different today. For example, this new feature tool we have would allow me to tunnel directly using HTTP into my corporate Exchange server without having to go through the whole VPN (virtual private network) process, bypassing the need to use a smart card. It’s such a huge time-saver, for me at least, compared to how long it takes me now. We will be extending that functionality to the next version of Windows.

That’s Martin Taylor, Microsoft’s general manager of platform strategy, talking.

Tags: Microsoft, network security, Windows

Posted on July 26, 2005 at 1:20 PM • 33 Comments

Comments

Nicholas Weaver • July 26, 2005 1:51 PM

Well, thats the problem with “too much” security (namely, anything that annoys the user), it gets bypassed (“tunnel everything over http/https”).

A better question is “Why is the VPN such a pain to use that you WANT to tunnel everything over HTTP?”

girlscoutcookie • July 26, 2005 1:54 PM

Well… I’m not sure if it is relieving or frightening that Windows security issues aren’t always “bugs” but “features”…

Pat Cahalan • July 26, 2005 2:00 PM

I have reservations about this, but I also have some positive comments.

I’ve been waiting for MS to do this or something like it for 5 years since Exchange 5.5 was replaced with Exchange 2000. End-users don’t like VPNs, due to a great number of reasons (slower connections, inaccessibility of local resources, and “something else to click on and another password to remember” amongst others.)

My principle argument against this follows Bruce’s comments -> this is a vendor enabling non-central security processes, and that can be a bad thing, especially if the process is a black box (how are they doing the tunnelling?)

However, one big upside here is that you can enable native Exchange functionality without giving VPN access to your end-users. Since a great many VPN deployments are rather badly done (“here, download this client on your horribly insecure home machine and connect to our network!”) and/or poorly managed (“remote machines become full members of the internal network”) due to time and complexity considerations, and since at least some of those come from complaints about Exchange, you can now take the VPN client away from people who only need Exchange, which is probably overall a good thing.

If you’re supporting Exchange, anyway 🙂

Joseph Milner • July 26, 2005 2:21 PM

I agree with Pat. Probably 95% of all the VPN clients at the very large international company I work for are using the VPN exclusively for Outlook access.

Gary Potter • July 26, 2005 2:22 PM

Wow, the GM for Platform Strategy openly talking about hacking his own system?

Ben Rogers • July 26, 2005 2:25 PM

If you don’t approve of such software, perhaps you shouldn’t provide links to what appear to be equivalent products:

http://www.schneier.com/blowfish-products.html

“HTTPort by Technology Networks LLC
TCP/IP through HTTP tunneling software that allows users to bypass virtually any HTTP proxy and tunnel arbitrary TCP/IP through it. From version 3 it uses Blowfish to encrypt traffic. ”

“Loophole by Loophole Software LLC
HTTP tunneling software that provides unrestricted, confidential Internet access for users behind a company firewall or web filter. ”

I know, I know, “Counterpane has not verified that Blowfish has been implemented properly, nor have we evaluated the security of these products. Readers are cautioned that there is more to creating a secure product than having a secure algorithm…” Nevertheless, if you link to those products, you are, in effect, advertising them, which seems incongruent with this post.

Nick • July 26, 2005 2:32 PM

It’s not about Blowfish any more than it’s about HTTP.

The point is that security is greatly diminished when you decide to create a bypass, even if that bypass has its own password-protection and encryption.

It’s the ‘easy path’ vs. ‘hard path’ problem. VPN’s created a hard path that inconveniences users as much as attackers, so an ‘easy path’ has been created. Given how well most users observe security procedures in their offices, I wouldn’t be at all surprised to find this exploited quickly (i.e., spyware captures your keystrokes, and voila, we can get into your Exchange server).

Ian Mason • July 26, 2005 2:34 PM

@Nicholas

I think the issue is, as is often the case, just bad design. I don’t think it’s hard to use a secure computer system PROVIDED that it is designed from step one to be secure and makes the decision to use an insecure mechanism the hard path to follow.

I’ve been thinking long and hard about this and trying to sketch out a design for a secure operating system. One of the conclusions I’ve come to is that TCP/IP as deployed is a major barrier to this. This is twofold, IP itself is insecure and then mechanisms used on top are hard to secure.

Firstly. In IP itself there is no way to ensure that traffic to or from a particular IP address is going to or from that origin. There are innumerable attacks on IP via ICMP, route hijacking, address hijacking etc.

Secondly. The implicit use of port numbers as part of the visible signature of traffic is problematic. People filter everything but port 80 because they want to permit web traffic but they don’t characterise the actual traffic over that port – so people bypass policy by stuffing everything over port 80. Conversely VPN traffic can come in over a confusing mixture of ports depending on the encapsulation. Also most fielded VPN methods are hard to understand and hard to implement reliably – I could rant at length about IPSEC based VPNs, fragmentation, path MTU discovery and amateurish ISP filtering of ICMP.

Further, what most users of VPNs really want is reliable authentication and authorization of traffic origin – most VPN setups just prove that the traffic has passed through some software set up by the VPN owner or provided with a key by them.

chuck • July 26, 2005 2:42 PM

Are we all on the same page? With MS Exchange it’s like this. It has its own ActiveSync protocol, which is quite secure, but most BOFH-type system administrators block access to it from outside the company network making users “dial??? VPN first just to get to the computer required. There’s usually no other functionality to this VPN thing. So MS thought about its users and allowed ActiveSyc to work over HTTPS. What’s wrong with that? Well, these BOFH morons now block HTTPS access. There’s no security bypass as such.

Mark J. • July 26, 2005 2:54 PM

We use this on our Exchange server. If properly configured, it is much less of a hassle and actually safer than a VPN. As some folks above mentioned, it keeps infected PCs from becoming part of your network and keeps your corporate Help Desk from answering a million VPN questions a day. But this has been around for a while. Why is this just now news?

Davi Ottenheimer • July 26, 2005 3:07 PM

Ha! I really like that. From now on, Microsoft “features” must be called “security bypasses”.

This guy is great for quotes on how to think incorrectly about security. Here’s another good one:

“You have to understand why we have security problems today. In some ways, it’s because a lot more things are connected today than they were when we architected some of the things we built into Windows.”

Yeah, weak security design at Microsoft is the fault of untrusted stuff being on the network. I seem to remember being forced into incident response for fully compromised Windows NT 3.5 systems back in 1994…for the same basic reasons that we still have issues with Windows systems today — strategic thinkers looking to release security bypasses into the wild.

What a laugh this guy is. Let me guess, next he is going to say that Ford’s problem with accidental death from exploding Firestones is because the roads are worse now than when the tires were being designed? Please.

&rw • July 26, 2005 3:20 PM

Sounds about as worse as UPnP (which, IIRC, is a system specifically designed so that clients can tell a firewall what they’d like to have opened up, thankyouverymuch)

Micah Brandon • July 26, 2005 3:29 PM

I’ve used a SOAP API provided by my SSL certificate provider so that I’m able to completely customize the purchase of SSL certificates from my own website. My application talks to theirs behind the scenes. Maybe I’m using PHP/MySQL/Linux and they’re using Weblogic/Java servlets/SQL Server… With SOAP it doesn’t matter. I ask question. They give answer. It greatly facilitates communication between two web applications… In my mind this is what SOAP was created for.

I find it difficult to get my head around what this Microsoft GM is saying… He’s taking the whole idea and concept of SOAP and basically, sorta imagines it as some kind of time saving tool, a way to bypass that pesky VPN. Then, the journalist asks him about security (and I’ll just sidestep the whole Linux thing) and the GM ends with:

“What we’re trying to build though is processes which will allow us to be smarter about that and processes that will allow us to be even predictive in some ways.”

Here’s my prediction: Hackers will exploit the hell out of this as soon as they get their hands on Vista. It’s going to be such a time saver not having to worry about that pesky VPN anymore.

iain • July 26, 2005 3:40 PM

umm, i think this is a case of a little knowledge is dangerous. The feature being discussed is far from a bypass – it’s RPC over HTTP. As Mark J points out above it actually enables better security rather than dimishes/bypasses it. It allows an authenticated client to connect to a front end mail server from outside the permiter. The only traffic that is now going over that connection is mail. Compare with a VPN where you are opening up a trusted connection for pretty much all traffic and this feature is actually very attractive as well as user friendly. With a compromised VPN connection you stand to loose anything the client can access; with an RPC over HTTP connection to an Exchange server you stand to loose mail, which is still bad, but comparitively less so

Charles Ballowe • July 26, 2005 4:17 PM

Ever think that maybe Microsoft is pushing this technology and at the same time using its existence to sell ISA server so that people can protect it? If you don’t start considering the problems of running extended services over HTTP, why would you ever buy a deep inspection firewall system? I’ve seen MS consultants pull a move like that on many occasions. “Here — use this method of getting around the security that you have .. oh… and by the way, you can add security to it with this other product.”

John • July 26, 2005 4:26 PM

@iain

“with an RPC over HTTP connection to an Exchange server you stand to loose mail, which is still bad, but comparitively less so”

Well, more correctly, you stand to lose anything that can be accessed, directly or indirectly, from the exchange servers, which, in the real world, is generally going to be “A lot more than email”.

As far as getting in to such a system, you’re still running IIS, with all of its “benefits”. Combine this with the degree to which a typical Exchange server is tied into the rest of an AD domain, and you almost certainly have an entry point into the rest of the network. This isn’t to say that IIS, Exchange, Active Directory, and the rest of their ilk can’t be locked down reasonably tightly – they can, given an admin with sufficient experience in doing so – but reality seems to say that admins truly capable of securing such a system are relatively few and far between. They also tend to be expensive, with salaries that are difficult to justify when “All I need to do is click this radio box to enable $FEATURE”

RPC over HTML itself could be completely secure, but you still have all of the underlying pieces required to make it work, and historically,

Dejan Jelovic • July 26, 2005 4:27 PM

Bruce,

Long time ago we had an email exchange where you said that you would prefer a pervasive authentication system to firewalls. So what’s wrong with being able to talk directly to a server provided that the channel is secure.

Also, having to VPN manually to access corporate networks is a huge pain in the ass. OS vendors should think about some kind of automagic VPN connect/teardown whenever you try to access some subnets.

Dejan

John • July 26, 2005 4:27 PM

to finish up

“RPC over HTML itself could be completely secure, but you still have all of the underlying pieces required to make it work, and historically,”

those pieces tend to be pretty full of holes.

wim • July 26, 2005 4:42 PM

And if you use ISA the whole thing is first authenticated and checked on the firewall and only then passed to the exchange server.
As said before you have less access than you would using a VPN.

Davi Ottenheimer • July 26, 2005 5:04 PM

@Dejan

“what’s wrong with being able to talk directly to a server provided that the channel is secure”

Nothing. That’s not the point here. In theory, the more direct the connection the better and more easily secured, right? But Taylor seems to be saying that he is trying to save time by bypassing a two-factor control like a smart card. That does not sound like a trade-off that coporate security would favor, especially if it is required for proper authentication.

Ralph • July 26, 2005 5:37 PM

An interesting direction MS keep traveling in; the light of both historical TCP stack vulnerabilities and the latest RDP DoS vulnerability.

http://www.microsoft.com/technet/security/advisory/904797.mspx

Whatever the people problems involved we must remember that the risks of tunneling.

But then again we all know that the real issues are all people issues anyway so shouldn’t show too much surprise.

Clearly we have to make our security controls as easy to live with as possible.

Ian Mason • July 26, 2005 6:01 PM

@Iain

“… It allows an authenticated client to connect to a front end mail server from outside the permiter. …”

Alternatively it allows an unauthenticated DDOS attacker to attempt to authenticate and force the server to do relatively expensive work to reject the connection. Because it’s not on a dedicated port you can’t filter it with a simple router in front of it. A router, even a small one, can dump thousands of unwanted packets a second without breaking a sweat while still permitting connection attempts from a select list of addresses or using simple lock and key type access control lists. Thousands of connection attempts a second will kill the average Windows server. Designing an system that deliberately overloads port 80 so that you’re forced to use expensive deep inspection techniques on firewalls is dumb.

Scott Johnson • July 26, 2005 8:35 PM

From what I understand of Microsoft’s recent HTTP tunneling undertakings, they are using some sort of RPC over HTTP proxy. So instead of rewriting their RPC apps to be HTTP aware, they are tunnelling the RPC. Considering the many security problems that MS has had with RPC in the past, this is very scary.

Alastair • July 27, 2005 12:04 AM

Notice also the revisionism from this Taylor guy:

“When you look at the issue of buffer overruns, eight to 10 years ago in software development, you did not know how much space you might need for something so you just create a big buffer zone to allow things to happen. Who knew that people could go exploit that and use that buffer space to do malicious things?”

He seems to be saying that buffer overflows (and possibly dynamic memory management?) were unknown in 1995. Inside Microsoft maybe. The rest of the Internet had watched the Morris worm 7 years before that, which propogated using known vulnerabilities, including buffer overflows.

fatmanmp • July 27, 2005 2:29 AM

RPC over HTTP has been around for a while now and whilst using the standard ‘firewall bypass and avoidance port’ appears from analysis to be pretty secure.

In fact, there are a number of solutions for proxying such connections to the Exchange front-end server and not just ISA (though admittedly ISA 2004 makes it easy to set up!) You can also use proxy servers from the likes of Bluecoat to do this as well.

With ISA, nothing gets through to Exchange at all unless first authenticated. Additionally, authentication methods can also include SecurID, providing additional protection.

Frankly, I think RPC over HTTP is small beer when compared to something like GotoMyPC and its ilk which scares the hell out of me.

wim • July 27, 2005 3:56 AM

”
Alternatively it allows an unauthenticated DDOS attacker to attempt to authenticate and force the server to do relatively expensive work to reject the connection. Because it’s not on a dedicated port you can’t filter it with a simple router in front of it. A router, even a small one, can dump thousands of unwanted packets a second without breaking a sweat while still permitting connection attempts from a select list of addresses or using simple lock and key type access control lists. Thousands of connection attempts a second will kill the average Windows server. Designing an system that deliberately overloads port 80 so that you’re forced to use expensive deep inspection techniques on firewalls is dumb.
”

Would the same not be true if a VPN was setup first?

Matthias Leisi • July 27, 2005 4:54 AM

Access to company e-mail does not suffer from a lack of technologies and possibilities of protecting the connection (be it VPN- or SSL-type).

Of a far greater concern to me is that data (attachments!) end up on a potentially insecure and untrustworthy machine full of trojans and spyware. Obviously, a VPN connection would also not solve the problem of the untrusted device.

Although bypassing an established authentication mechanism is against common best practice at first sight, it is not in and of itself a bad thing, but may be justified by usability issues (“the CFO does not manage to enter the six digits of the RSA token”).

The real challenge in remote access to company information is a safe and sane strategy on how to cope with the untrusted device. Once that is solved, the differences between VPN- and SSL-type connections are either irrelevant or ditacted by exogenous factors.

Ari Heikkinen • July 27, 2005 1:32 PM

Is there anyone out there these days who takes anything that microsoft says seriously anyway? I’d suggest checking any credible source first before taking any of their advice.

David • July 27, 2005 1:55 PM

One of the “problems” of security pros is that they often create their security empires and make it hard to get things done.

For example, when firewalls first become popular, there was always something that broke because the firewall wouldn’t allow some traffic through. When we’d tell them that they need to open port N from IP X.X.X.X. for things to work, the “security pros” would make it nearly impossible to get any firewall rule change implemented. It was as if they wanted full control, even if it meant denying users the ability to use external apps despite the fact that the “fix” was trivial.

The same has occurred with VPNs, SPAM filtering, etc. These security measures nearly always create new problems with existing functionality.

Spam filtering included throwing lots of once-valid emails into a spam buckets or rejected outright. SPF also created rules that allowed external systems to send emails on behalf of other domains, but the security pros would never add domains/IP addresses of external systems — only their own MX systems.

At any rate, as security gets tighter, a lot of things break. If the security pros would then make changes to allow special needs (rarely creating any real threat) to work, life could be better. But that’s rarely the case.

So, just like how the PC and other “personally controlled” devices forced their way in when the computer folks wouldn’t respond to their real business needs quickly, so too will these types of tunnelling and work-arounds. In the end, people are doing these things because it’s just too hard and slow to have them done by those “in charge,” who think their power comes from denying access or otherwise making life harder than it needs to be.

But that’s just my rant on admins who hold too dearly to their work domains. If you keep making it impossible for new firewall rules to be inserted, and new spam-filtering rules to be added, and use of VPNs hard to get going, then people will find ways to work around the measure.

This isn’t a matter of terrorists/hackers adjusting their methods to security barriers, but regular business folks.

Davi Ottenheimer • July 27, 2005 2:18 PM

@David

Good points. Microsoft might offer you a job too as a strategic thinker after that rant about how security is really a barrier to getting “things done”.

Sadly, you miss the point entirely. A mail server is available to users (read: open for business) essentially because of security, not in spite of it. What you are describing are some pitfalls of security practices not reasons to pull authority away from security admins; security introduces trade-offs, in Bruce’s terms, that need to be evaluated in business terms and it sounds like you sees cons and are still uncomfortable or unfamiliar with the pros.

The issue with Taylor’s statements in particular, is that he advocates “bypassing the need to use a smart card. It’s such a huge time-saver, for me at least, compared to how long it takes me now”. The key word there is “bypass” as it relates to two-factor authentication. Has he improved things in terms of the existing controls? No, not at all. In fact, it sounds like he gave up on two-factor authentication before he even started. This is like saying “hey this seatbelt slows my travel time down, so I am going to ride a motorcycle”. He has reduced a control. Has he bothered to enhance another control instead (e.g. started to wear a helmet), or is he just looking for the quick solution to make his life “easier” without doing any due diligence or basic risk evaluation?

john • July 27, 2005 2:58 PM

“Microsoft Builds In Security Bypasses”

I thought those were just remote exploit bugs eventually “discovered” and fixed in available Windows Updates?

Install for yourself a copy of WinXP without SP1 and SP2 and update all the way and read the descriptions for each update and COUNT FOR YOURSELF how many of the patches resolve issues with REMOTE EXPLOITS that can/may allow COMPLETE CONTROL over the system.

I say the backdoors are only bugs to be patched if they’re actually discovered.

Gotta love those closed source operating systems. 😛 All of the text in this post is in my opinion of course 😛

JohnJ • July 28, 2005 7:24 AM

Two comments:

Is the risk significantly different than Outlook Web Mail, the browser-based access method built in to Exchange?
We are deploying this technology right now. As a service provider, we have employees who are located on client networks. Those clients are generally very reluctant to allow VPN connections between their network and ours. We’re reluctant as well. By doing RPC over HTTPS, our staff gets full Outlook/Exchange functionality without the need for a VPN connection. Thus they get the functionality that OWA does not provide and our clients don’t have to make special concessions, other than perhaps a proxy rule.

We’re also using it to finally eliminate POP-based email, which has been a thorn in our side for years.

Roger • July 29, 2005 12:02 AM

“We’re also using it to finally eliminate POP-based email, which has been a thorn in our side for years.”

Interesting. What exactly has been the problem?
Of course technically POP has been obsoleted by IMAP for nearly twenty years. Have you considered IMAP over SSL (or now, IMAP v4 which has SSL built in)? I personally would have called IMAP-SSL the correct solution for this problem (and a solution which was available, BTW, years before MS did RPC over HTTP). The only reason I can imagine MS didn’t use IMAP-SSL was that it was standards compliant and hence interoperable. (Of course, modern versions of Outlook and Exchange can in fact be configured to use IMAP!)

Schneier on Security

Microsoft Builds In Security Bypasses

Comments

Leave a comment Cancel reply