One of the first posts on this blog was about different (free) options you have to temporarily elevate your privileges under Windows. So it is natural that this blog post from George Ou sparked my interest. It talks about a product, BeyondTrust, using which you can temporarily elevate the privileges of certain applications and provides a centralized management interface to it through Active Directory.
Their website contains the usual propaganda, like protection against zero day threats
, but this is not why I’m mentioning them. I’m talking about them because I suspect that I found a loophole in their bulletproof
system. Remember, how I talked about the fact that under Windows the parent process owns every right to the child process, even in a limited account? We can use the same mechanism to expand our privileges beyond what was intended as shown in the following scenario:
- Process X has a given privilege we need.
- Process Y wants to gain those privileges. It launches a new instance of X, becoming the owner of the instance.
- The privilege is automatically granted to X by BeyondTrust
- Now Y, using its privileges, can insert arbitrary code in the instance of X
The probability of an automated tool figuring out such complicated chain of actions (or even figuring out which programs it needs to use to gain the needed privileges) is of course very low, however in the case of an insider threat this attack is still feasible. Of course there exists much simpler attacks, which can leave the system exposed even with a slight misconfiguration (for example, the fact that the open / save dialogs are complete file manager solutions, which can be used to move / overwrite files from inside a privileged application). The point I’m trying to make here is that there is no silver-bullet for security.
PS I couldn’t try this attack, because although they have a free version on their website, it kept insisting on having the computer in a domain, which I won’t set up for the sake of this program. Anyway, if somebody has already configured this program, please perform the following test and report back with the result:
- Pick an arbitrary executable (telnet.exe for example) and assign it some special privileges.
- Download the very nice user mode-debugger, OllyDbg and from a limited user account open telnet.exe for debugging.
- Use ProcessExplorer to verify that OllyDbg doesn’t have the special privilege, while telnet.exe does.
3 responses to “An other tool to manage security in Windows”
Hi there,
my name is Marco Peretti, and I am the CTO of BeyondTrust. I have read with interest your article and am writing to let you know that such a simple attack will not work. By default, we strip child processes from inherited privileges thereby reverting them to the default user privileges. Moreover, we protect our processes against fellow processes trying to take ownership and, for instance, inject a remote thread into a process running with elevated privileges.
cheers,
Marco
It would be interesting to see if this was also possible even with something like AppSense Application Manager, which essentially stop any process, not owned by the Administrator, from running.
I’m not entirely convinced by your answer. Maybe I misstated my attack plan, so here are some clarifications:
– the child doesn’t inherit the privileges, it gets them from BeyondTrust, because it is a trusted application
– the launching process does not need to “take ownership” of the child process, because it already has it given the way the Windows security model is designed.
It may be possible (and in fact desirable) for BeyondTrust and other such solutions to disallow the running of privileged processes by unprivileged ones or at least close the handles very early on (although this solution may have race conditions in it depending on the way it is implemented). I don’t know if this is implemented in BeyondTrust or not because I couldn’t test it.
I would be happy to test this attack and report on it if anyone could provide me with installation instructions of a VM image of it.
In reply to the first comment: yes, a whitelisting applications (like the one you mentioned) would stop such attacks if they came in the form of separate binaries (ie. not arbitrary code exectution vulnerabilities in already trusted applications). A possible threat scenarion in that case would be the following:
– an employee knows that Word is not pached for the latest vulnerabilities
– it creates the above code as the code included in the exploit. The whitelisting application trusts Word, but in fact Word becomes a program which can execute anything after opening the specially crafted document.
While this requires a high level of knowledge, the idea is that most security measures are not perfect.