The inheritance of object handles between processes in a Microsoft Windows system can be a good source to identify local privilege elevation (LPE) vulnerabilities. After introducing the basic concepts around this type of security weaknesses, a tool capable of identifying and exploiting them will be presented, providing Pentesters and Researchers with a new point to focus their intrusion and research actions respectively, read on!
Within a Microsoft Windows operating system, processes are able to interact with securable system objects such as files, PIPES, registry keys, threads or even other processes. To do this and through the use of the WINAPI the source process requires the O.S. of a handle to perform a certain action on the object in question.
If the appropriate permissions and/or privileges are available, the O.S. authorizes this access by delivering the aforementioned object handle to the process that requires it. From that moment on it is possible to interact with it within the limits of the requested permissions. Let’s see the following example where a source process would make use of the WinApi OpenProcess function to try to open a target process (spoolsv.exe) in order to obtain information remotely from it (PROCESS_QUERY_INFORMATION).
If the source process in this case belongs to the Administrators group and requests only the aforementioned permission, we see how the O.S. would deliver its handle, since the target process has an ACL that allows this type of interaction.
Therefore, obtaining a handle allows us to perform certain actions on a specific securable object, until we decide not to use it anymore and close it.
A remarkable feature of Windows systems is that these handles can be inherited from the parent process to the child processes. It is enough to indicate at the time of opening the boolean value TRUE in the call, in the previous image by setting the value of “bInheritHandle“. Therefore, as long as the handle is not closed, any child process created by the parent will inherit the handle if it is also instructed to apply inheritance.
In addition to this, within the world of Windows operating systems there is the concept of Impersonation, which means that a process running in a given security context can impersonate another context. That is, a process that has an identity of a given user/group (through its token), can impersonate another at a given time to, for example, perform a given action. In this sense, it is common for O.S. services running as a SYSTEM user to impersonate less privileged users by creating a child process with restricted capabilities.
From this, if we put the two previous concepts together, it is possible that a programmer not very aware of what they is doing, can introduce a local privilege elevation gateway in the system, from an unprivileged user to a user such as SYSTEM. This type of vulnerability is not very popular or at least there is not much public research on the subject, nor is there a tool that is able to identify and exploit them actively (at least after the state of the art done).
Let’s take a closer look at the reasons for this type of vulnerability.
A first process P1 running as a privileged user such as SYSTEM obtains a handle from another privileged process P2, or from itself, by setting the inheritance value to TRUE. It then creates a process P3 with less privilege by impersonation, but inheriting the handles. At this point, any process with a privilege level equal to that of P3 can access that handle, and therefore exploit this vulnerability as followings.
The malicious process P4 duplicates the P2 handle in P3, so, depending on the type of handle and access granted it could, among other things, inject a shellcode or cause it to create a child process such as a cmd shell, thus constituting a nice LPE.
This type of vulnerability is not new (James Forshaw seems to have introduced it in 2016), but as discussed, there is not much state of the art about it and there are no tools that allow them to be detected and exploited in an automated way.
The consulted state of the art exploits only 2 types of handles (threads and processes), but there are many more that could allow the door to local privilege escalations (LPE), such as those of type Key (Register) or File (PIPES), among others.
That said, I want to contribute my two cents to the state of the art by developing the LHF (Leaked Handles Finder) application capable of monitoring the system in real time, notifying of possible vulnerabilities of this type, and in case of being exploitable allowing its exploitability.
The tool is purely developed using the Native Api (ntdll.dll), avoiding the high-level Win32 Api. Its usefulness is twofold, so that it can be used during a pentest process to elevate privileges locally or it can be used by a Security Researcher to identify new 0-days of LPE type.
Some of the alerts it is capable of notifying are shown below:
As shown in the image, LHF is able to identify the inherited handlers in all processes and enrich this data with the integrity level of the process in question and that of its parent, in order to compare them with each other and identify a potential LPE. In turn, if the handle is of type process or thread, it is able to obtain to whom that handle belongs, concluding whether or not there is a possibility of LPE.
This tool was presented at the last RootedCon Madrid 2022, I leave the link to the GitHub for you to try it. If you identify with it any 0-day or just have doubts about how to use it, send me a private message on Twitter to @ramado78.
