Hot Potato – Windows Privilege Escalation(foxglovesecurity.com)
foxglovesecurity.com
Hot Potato – Windows Privilege Escalation
http://foxglovesecurity.com/2016/01/16/hot-potato/
4 comments
My jaw kind of hit the floor after reading Google Security Research's issue 222; very glad someone has built a simplified PoC. With any luck this will get some kind of response out of MS.
Is the summary basically "turn off WPAD and this won't work?" Because that's not hard to do:
http://stackoverflow.com/questions/15029615/how-to-turn-off-...
http://stackoverflow.com/questions/15029615/how-to-turn-off-...
Running a server on port 80 (< 1024) doesn't require any elevated privileges on Windows?
Windows makes up it's own rules and it isn't Unix at all.
This exploit doesn't depend on that; 80 might as well be 8000 or 8080(common proxy port) or anything else. Observe that the proxy port can be specified:
return "PROXY 127.0.0.1:80";}Don't you still need to run the WPAD "server" on port 80?
Yup. That's why it needs to run on port 80.
I don't think Windows Firewall lets you listen on *:80, but localhost:80 is just fine.
I don't think Windows Firewall lets you listen on *:80, but localhost:80 is just fine.
It does. The built-in firewall will by default block any program from listening on any port, unless authorized by a rule.
The article did not touch on this subject, but I believe that for this to work, the admin will have to either switch off the firewall or create a rule authorizing the program to use the port (or the port to be used by any program)
The article did not touch on this subject, but I believe that for this to work, the admin will have to either switch off the firewall or create a rule authorizing the program to use the port (or the port to be used by any program)
If you watch the video for Windows 7 you see Windows Firewall tries to block it. It is blocking Potato from listening on *:80. There are no such restrictions for localhost:80.
No modifications were made from default config.
No modifications were made from default config.
Nope. Windows got sockets before it got a reasonable privilege model.
stopping non root users from listening on low ports probably causes more security issues than it solves, it means crappy admins and developers just gift root access to exploits.
But that isn't a problem with the software, it's just human laziness. I don't know of any system that prevents a person from making poor choices.
I just gave you an example, if you don't force them to be root to do something, they wouldn't have bothered, preventing the poor choice.
> ...crappy admins and developers just gift root access to exploits.
Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root.
> ...stopping non root users from listening on low ports probably causes more security issues than it solves...
Requiring root privs to bind to low ports prevents the following attack:
* Attacker knows of a way to crash $SERVICE
* Attacker has a non-root shell on $MACHINE, which runs an instance of $SERVICE
* Attacker crashes $SERVICE and stands up his own malicious instance
The ability to prevent an attacker from turning a service crash bug + an unprivved shell into a malicious instance of that service is a good property to have. The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port.
I'm not willing to give up that property in order to make an incompetent sysadmin or developer slightly less likely to run an exploit as root.
Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root.
> ...stopping non root users from listening on low ports probably causes more security issues than it solves...
Requiring root privs to bind to low ports prevents the following attack:
* Attacker knows of a way to crash $SERVICE
* Attacker has a non-root shell on $MACHINE, which runs an instance of $SERVICE
* Attacker crashes $SERVICE and stands up his own malicious instance
The ability to prevent an attacker from turning a service crash bug + an unprivved shell into a malicious instance of that service is a good property to have. The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port.
I'm not willing to give up that property in order to make an incompetent sysadmin or developer slightly less likely to run an exploit as root.
> The only way it could get better is if you could dictate that only processes with a given set of UIDs or GIDs could bind to a given interface and port.
Ahem. That's what Windows does. The built-in firewall (on by default on all versions) will block all attempts to receive, unless a rule specifically allows it.
A rule can specify that a specific account (or group) can receive on a specific port. However, it is more common to have rules authorize programs to communicate, like e.g. allowing chrome to open outgoing TCP connections, or allowing a specific service to listen on specific ports.
Ahem. That's what Windows does. The built-in firewall (on by default on all versions) will block all attempts to receive, unless a rule specifically allows it.
A rule can specify that a specific account (or group) can receive on a specific port. However, it is more common to have rules authorize programs to communicate, like e.g. allowing chrome to open outgoing TCP connections, or allowing a specific service to listen on specific ports.
> Ahem. That's what Windows does.
No need to clear your throat, I'm aware of Windows Firewall. :)
I've never had to do real administration of a Windows system, so I ask: Does WF allow you to restrict which programs can be bind to a given port?
This [0] doesn't make it seem like it can, [1] and my gaming machine is booted into Linux for the next several hours, so I can't check for myself. :(
[0] https://technet.microsoft.com/en-us/library/cc753558.aspx
[1] Though -frankly- it's not the best intro to that UI that I've ever seen. :(
No need to clear your throat, I'm aware of Windows Firewall. :)
I've never had to do real administration of a Windows system, so I ask: Does WF allow you to restrict which programs can be bind to a given port?
This [0] doesn't make it seem like it can, [1] and my gaming machine is booted into Linux for the next several hours, so I can't check for myself. :(
[0] https://technet.microsoft.com/en-us/library/cc753558.aspx
[1] Though -frankly- it's not the best intro to that UI that I've ever seen. :(
> Does WF allow you to restrict which programs can be bind to a given port?
Yes.
> This [0] doesn't make it seem like it can
Indeed. Also check out the cmdlets of the PowerShell NetSecurity module:
> [1] Though -frankly- it's not the best intro to that UI that I've ever seen
No, it's pretty bad. :-) Not even a screenshot.
Yes.
> This [0] doesn't make it seem like it can
Indeed. Also check out the cmdlets of the PowerShell NetSecurity module:
gcm -mod netsecurity
> [1] Though -frankly- it's not the best intro to that UI that I've ever seen
No, it's pretty bad. :-) Not even a screenshot.
> No, it's pretty bad. :-) Not even a screenshot.
I KNOW, RIGHT?!? ;_;
> > Does WF allow you to restrict which programs can be bind to a given port?
> Yes.
So, I remembered that I had a Win 7 (Home Premium) VM lying around and spun that up and played around a bit with a server adapted from the server code found at [0]. It doesn't work as expected.
It doesn't look like Windows does anything at all regarding preventing programs from binding to a particular port, and it also doesn't look like an Allow rule that points to a particular executable overrides a general Deny rule. [1] In brief:
* Allow TCP/9999: OK.
* Deny TCP/9999: Can bind, but don't get packets. Ok.
* Deny TCP/9999, but Allow TCP/9999 when it's this particular program: Can bind (both the named executable and the same code with a different name), but don't get packets. Not Good.
Regardless of Windows firewall settings, the first executable I start is the one that shows up as bound to the given socket in (Windows) netstat. Because of my inability to figure out why Windows's executable-based inbound per-port connection filtering wasn't working, [2] I can't test to see if I could DoS a legit daemon with this.
Have you personally successfully used application-based inbound port filtering?
[0] https://www.akkadia.org/drepper/userapi-ipv6.html
[1] Maybe this has something to do with the fact that I'm using Cygwin to compile straight C code into Windows executables, but it would be... somewhat amusing if you had to do something particularly special that the Cygwin shim wasn't doing in order to make Windows Firewall link up a particular .EXE to a particular bound port. (After all, netstat has no trouble figuring it out!)
[2] And yeah, I made sure to cancel the Windows Firewall "This program is a server!" dialog and deactivate the automatic rules that got put into the Inbound Rules list once I started the little server for the first time.
I KNOW, RIGHT?!? ;_;
> > Does WF allow you to restrict which programs can be bind to a given port?
> Yes.
So, I remembered that I had a Win 7 (Home Premium) VM lying around and spun that up and played around a bit with a server adapted from the server code found at [0]. It doesn't work as expected.
It doesn't look like Windows does anything at all regarding preventing programs from binding to a particular port, and it also doesn't look like an Allow rule that points to a particular executable overrides a general Deny rule. [1] In brief:
* Allow TCP/9999: OK.
* Deny TCP/9999: Can bind, but don't get packets. Ok.
* Deny TCP/9999, but Allow TCP/9999 when it's this particular program: Can bind (both the named executable and the same code with a different name), but don't get packets. Not Good.
Regardless of Windows firewall settings, the first executable I start is the one that shows up as bound to the given socket in (Windows) netstat. Because of my inability to figure out why Windows's executable-based inbound per-port connection filtering wasn't working, [2] I can't test to see if I could DoS a legit daemon with this.
Have you personally successfully used application-based inbound port filtering?
[0] https://www.akkadia.org/drepper/userapi-ipv6.html
[1] Maybe this has something to do with the fact that I'm using Cygwin to compile straight C code into Windows executables, but it would be... somewhat amusing if you had to do something particularly special that the Cygwin shim wasn't doing in order to make Windows Firewall link up a particular .EXE to a particular bound port. (After all, netstat has no trouble figuring it out!)
[2] And yeah, I made sure to cancel the Windows Firewall "This program is a server!" dialog and deactivate the automatic rules that got put into the Inbound Rules list once I started the little server for the first time.
> It doesn't look like Windows does anything at all regarding preventing programs from binding to a particular port
Correct. By default a program may bind, but inbound traffic is blocked.
> and it also doesn't look like an Allow rule that points to a particular executable overrides a general Deny rule
Correct. That's not how the fw is designed. By design a "block" rule are processed before "allow" rules [0] (although authenticated bypass rules are processed before block rules).
There's an overall setting to allow or deny traffic not matching any rules. By default it is "block" for inbound and "allow" for outbound traffic.
> I can't test to see if I could DoS a legit daemon with this
I don't think you can. Perhaps if you could get in before the daemon (service)?
> Have you personally successfully used application-based inbound port filtering?
Yes. And I tested it with a small UDP server before I wrote my first post in this thread. When the server started I got a FW prompt that the program was trying to communicate. I canceled the dialog. The FW had now created a "block" rule for the server, blocking all inbound traffic. Yes, it showed up a bound to the port in netstat, but all traffic was blocked.
[0] https://technet.microsoft.com/en-us/library/dd421709(v=ws.10...
Correct. By default a program may bind, but inbound traffic is blocked.
> and it also doesn't look like an Allow rule that points to a particular executable overrides a general Deny rule
Correct. That's not how the fw is designed. By design a "block" rule are processed before "allow" rules [0] (although authenticated bypass rules are processed before block rules).
There's an overall setting to allow or deny traffic not matching any rules. By default it is "block" for inbound and "allow" for outbound traffic.
> I can't test to see if I could DoS a legit daemon with this
I don't think you can. Perhaps if you could get in before the daemon (service)?
> Have you personally successfully used application-based inbound port filtering?
Yes. And I tested it with a small UDP server before I wrote my first post in this thread. When the server started I got a FW prompt that the program was trying to communicate. I canceled the dialog. The FW had now created a "block" rule for the server, blocking all inbound traffic. Yes, it showed up a bound to the port in netstat, but all traffic was blocked.
[0] https://technet.microsoft.com/en-us/library/dd421709(v=ws.10...
Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux.
Neither platform can deny/allow traffic by the process full path (a Unix app can spoof its process name shown in ps/top) or in a GUI... at least one thing Windows got right.
Neither platform can deny/allow traffic by the process full path (a Unix app can spoof its process name shown in ps/top) or in a GUI... at least one thing Windows got right.
> Hate to say it, but out of the box Windows has the most flexible firewall compared to OS X and Linux.
1) Why would you hate to say it? If a tool is good, it's good. :)
2) Maybe the Windows Firewall GUI only exposes a tiny sliver of the functionality, but it's reasonably possible [0] to make really complex iptables rules. :)
[0] "Reasonably possible" as in, iptables provides the tools required to manage a fair bit of complexity.
1) Why would you hate to say it? If a tool is good, it's good. :)
2) Maybe the Windows Firewall GUI only exposes a tiny sliver of the functionality, but it's reasonably possible [0] to make really complex iptables rules. :)
[0] "Reasonably possible" as in, iptables provides the tools required to manage a fair bit of complexity.
Ugh. 16-hours later follow up comment (because I accidentally a couple of entire sentences):
Maybe the WF GUI only exposes a tiny sliver of what you can do with WF, but WF seems really limited when compared to iptables. It seems that the only thing you can do in WF that you can't do in stock iptables is refuse to direct IP traffic to (or from) a given program on the system.
Maybe the WF GUI only exposes a tiny sliver of what you can do with WF, but WF seems really limited when compared to iptables. It seems that the only thing you can do in WF that you can't do in stock iptables is refuse to direct IP traffic to (or from) a given program on the system.
Actually my usecase is to deny all traffic except for special applications - I'm often on mobile/tethered connections so I only want my browser but not crap like automatic updates or other background tasks to eat up my bandwidth.
Impossible on OS X and Linux without shelling out $$$.
Impossible on OS X and Linux without shelling out $$$.
> Impossible on OS X and Linux without shelling out $$$.
I've never used it, so I can't endorse it, but this was among the first results in a google search for "linux per application firewall":
http://douaneapp.com/
I guess there has been progress in this space since you last looked.
There is also SELinux controls that can be used... so -IIRC- you could create a per-app firewall with that. :) I would be slightly surprised if there weren't pretty reasonable GUIs for managing such SELinux rules.
I've never used it, so I can't endorse it, but this was among the first results in a google search for "linux per application firewall":
http://douaneapp.com/
I guess there has been progress in this space since you last looked.
There is also SELinux controls that can be used... so -IIRC- you could create a per-app firewall with that. :) I would be slightly surprised if there weren't pretty reasonable GUIs for managing such SELinux rules.
> Crappy admins shouldn't be administering critical systems and crappy developers should be writing neither security-critical code, nor code that runs as root.
I don't think you have a firm grasp of the state of the real world.
I don't think you have a firm grasp of the state of the real world.
> I don't think you have a firm grasp of the state of the real world.
I expected you to make this objection. :)
I have a rather firm grasp of the current state of both development and system administration.
Note carefully that I said "$CLASS shouldn't $DO_IMPORTANT_THING", rather than "$CLASS doesn't $DO_IMPORTANT_THING". It's a subtle detail that I guess you missed. ;)
I also notice that you didn't address my larger, more technical point. I guess that means that you didn't find fault in it. That's good, as it's pretty universally recognized that it's a good thing when you get near-zero-cost removal of a given class of exploits.
I expected you to make this objection. :)
I have a rather firm grasp of the current state of both development and system administration.
Note carefully that I said "$CLASS shouldn't $DO_IMPORTANT_THING", rather than "$CLASS doesn't $DO_IMPORTANT_THING". It's a subtle detail that I guess you missed. ;)
I also notice that you didn't address my larger, more technical point. I guess that means that you didn't find fault in it. That's good, as it's pretty universally recognized that it's a good thing when you get near-zero-cost removal of a given class of exploits.
Many times I see commenters on HN making statements to the effect of "users cannot run their own servers" and spurring a "debate" in the context of someone trying to innovate away from the current asymmetric, client-server, "calf-cow" internet.
I saw one such commment earlier today.
Thought experiment:
What about exploits like this one, among so many others over the years, in Microsft Windows?
In many cases it sure looks like the user is "running a server".
There is a port open and listening, waiting for connections. And some remote client can connect and issue commands.
I saw one such commment earlier today.
Thought experiment:
What about exploits like this one, among so many others over the years, in Microsft Windows?
In many cases it sure looks like the user is "running a server".
There is a port open and listening, waiting for connections. And some remote client can connect and issue commands.
> Many times I see commenters on HN making statements to the effect of "users cannot run their own servers" and spurring a "debate" in the context of someone trying to innovate away from the current asymmetric, client-server, "calf-cow" internet.
What that is about is that most consumer level internet connections do not have a fix IP address. Thus you can't (easily) aim a DNS reference at it etc.
What that is about is that most consumer level internet connections do not have a fix IP address. Thus you can't (easily) aim a DNS reference at it etc.
Understood. However try to reconcile this with the thought experiment I gave above. You would be saying that these Windows exploits would not work because users have IP addresses that are changing too frequently. Is it possible that _in practice_ many "dynamic" IP addresses are actually quite static (i.e., remaining the same for months or longer)? In _theory_ they could change by the day or week.
Well most attacks just use such a "server" for the initial attack, afterwards they set up something that make outbound connections to a "command center" or similar.
Yes. But the server capability is always there. It can be launched again any time the attacker needs it.
In technical terms any computer can be a server. Just look at the BBSs that was run out of C64s and similar back in the day.
But a server that can't be reliably reached is a useless server.
And the BBSs worked back in the day because dialing the same number days, weeks, even months inbetween would lead you to the same BBS if the computer was still running.
A domestic internet connection is simply not reliable enough for that. Yes, if nothing happens electrically at either the customer or ISP end the IP will remain for some time. But have a power failure and it is likely that the IP will be reassigned. And that random aspect, that sometimes you can retain the address for months, and other times get it changed within hours, do not help.
But a server that can't be reliably reached is a useless server.
And the BBSs worked back in the day because dialing the same number days, weeks, even months inbetween would lead you to the same BBS if the computer was still running.
A domestic internet connection is simply not reliable enough for that. Yes, if nothing happens electrically at either the customer or ISP end the IP will remain for some time. But have a power failure and it is likely that the IP will be reassigned. And that random aspect, that sometimes you can retain the address for months, and other times get it changed within hours, do not help.
I agree firewalls and NAT are a nuisance, and today's internet is not one iota as cool as the BBS days. The nuisances introduced by "ISPs" have hindered but in the long run have not stopped reliable peer to peer internet. I will not name the commonly known examples lest it divert the conversation.
There are a variety of workarounds for dealing with firewalls and NAT, and after years of using them "experimentally", I can attest that they work reliably, at least for me. Some of them are well-known, some of them are commonly used, others are not.
If IP addresses assigned to so-called "reliably reached" servers were as static as you imply in practice, there would be little need for a mechanism like DNS. (And I'm not saying there is, just pointing out that there are a lot of folks who believe IP addresses must be able to change without notice.)
In my experience, domestic internet connections with "dynamic" IP addresses are "reliable enough" to do some "useful" things besides simply partaking in the "calf-cow" web.
There are a variety of workarounds for dealing with firewalls and NAT, and after years of using them "experimentally", I can attest that they work reliably, at least for me. Some of them are well-known, some of them are commonly used, others are not.
If IP addresses assigned to so-called "reliably reached" servers were as static as you imply in practice, there would be little need for a mechanism like DNS. (And I'm not saying there is, just pointing out that there are a lot of folks who believe IP addresses must be able to change without notice.)
In my experience, domestic internet connections with "dynamic" IP addresses are "reliable enough" to do some "useful" things besides simply partaking in the "calf-cow" web.