After my post about punching holes in HTTP.SYS – there was some discussion going on (on this blog, on Keith’s blog and in a number of private email conversations). Let me wrap this up.
Kenny commented on my post:
“I think that the main confusion here is around the purpose of http.sys reservations. Reservations are used to prevent squatting. For example, SQL doesn’t want other apps, admin or otherwise, to listen on http://+:80/sql/, so they make a reservation with their creds. Reservations are not for preventing malware from listening on your machine. If you have malware on your machine it can just open a socket if it wants to receive data.”
Keith then posted this:
“If Kenny is correct, then it would seem to me that things would work the other way around: that is, by default you’d be allowed to register with HTTP.SYS unless some other application set up a reservation on that port/prefix. But by default, HTTP.SYS is locked down (except for the holes that Dominick is discussing).”
“Squatting on a port is one attack. But it’s only one of a myriad of attacks that this reservation system prevents. I cannot imagine that squatting was the only consideration. The port sharing ability of HTTP.SYS makes it even more vulnerable to malware than simply opening a socket. If my exploit can port share with an existing, legitimate service, you might not notice it there if you’re using a traditional tool such as netstat. Plus, firewalls are configured to control access to ports – sharing a legitimate port might allow my malware to communicate with the cloud.”
I’m sure malware authors worldwide rejoiced when HTTP.SYS port sharing was introduced. I’d say that concerns like Dominick’s are well founded.”
In the meantime Kenny posted this (shocking IMO) comment:
“To followup, there is a confluence of unfortunate events that actually turn this into a larger concern:
Because of the absence of proper Http.sys – Firewall interaction (you cannot do per-app or per-service firewall exceptions with Http.sys), you have to use reservations to prevent firewall bypass.
It also turns out that WS-Man conveniently installs a firewall exception on port 80 (scoped to system). So with the WCF reservation for world, on every Vista client machine the port 80 is opened for anybody at the WCF temporary addresses prefix.”
It turns out that this is not as catastrophic as it first looked because the WS-Man firewall exception is not enabled by default (which is good news). So be aware that when you should ever open port 80 on a machine you might be sharing ports…
Kenny also asked:
“I understand the concerns here. I do have to wonder though, if you have malware running on your machine, can’t it just open a client socket to the cloud (which actually is worse since it will traverse your client-side NAT)? Is the difference Reputability since you can check what the client is connecting to?”
and Keith replied:
“Yep. It could. But it’d be noisy.
Windows Firewall, for example, would prompt the user whether she wanted to “unblock” the application. Any other sort of monitoring tool worth its salt would notice this as well.
Compare this to simply registering as a listener on an existing port via HTTP.SYS. The port is already open as far as the TCP/IP network stack is concerned, so would monitoring software notice this? I don’t know.
You have to ask yourself, why go to the bother of locking something down with an ACL if you’re then going to configure it loosely so that the ACL doesn’t have any effect. I believe that’s what Dominick may have been feeling when he wrote his post.”
In some private conversation I heard the comparison of the temporary listen URIs to a temp directory on the hard disk: “It is just as opening up a small part of the hard disk as opposed to the whole system.” I personally think this analogy is OK for squatting, but does not work very well for the malware opening a listener case.
A listener is a listener, regardless of where he is listening. If some widespread malware establishes a listener on some open URI, this becomes a well known URI.
Remember Back Orifice? This back door was distributed via various means. But BO was not necessarily also exploited by the same people that distributed it. Instead there was also scanning software available that could scan complete address ranges for BO. So a lot of people just used an already installed BO to exploit a machine…
So to sum up:
- The HTTP ACL system seems to target squatting only – in that case I wonder why it is not implemented as described by Keith above
- There are several mitigating factors like the Windows firewall and potential NATs
- You may not be always behind a NAT
- With the reservation open for world, some malware could potentially open a listener on a system without a single prompt – no UAC, no firewall.
- Malware establishing outgoing connections (as opposed to listeners) is also a big concern
Make up your mind yourself.