Hot Potato – Windows Privilege Escalation
foxglovesecurity.com
foxglovesecurity.com
http://stackoverflow.com/questions/15029615/how-to-turn-off-...
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.
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.
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.
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. :(
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.
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.
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.
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.
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":
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 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.
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...
return "PROXY 127.0.0.1:80";}I don't think Windows Firewall lets you listen on *:80, but localhost:80 is just fine.
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)
No modifications were made from default config.
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.
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.
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.
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.