Cycling through PIDs could take a long time, especially with the semi-random allocation patterns of PIDs on modern versions of Windows, but it is possible to exploit.Ī simple example of PID cycling is as follows: Also note that thread IDs are taken from the same pool as PIDs so you might be unlucky and create a thread with the ID you wanted. Note that you can’t actually create a process with ID 65279 as all current versions of Windows align PIDs to multiples of 4, however if the server calls OpenProcess on 65279 it will round down and open the PID 65276 which we can create. Can we exploit this without writing our own SMB2 client or using an existing one such as IMPacket ? You can abuse the fact that Windows will re-use PID values and just create a suitable process which would meet the security check requirements until one of the processes has the correct PID. You’ll need to reference my NtApiDotNet library to use some of the types:Īs the server doesn’t seem to check the value you could set it to something arbitrary, however the in-built Windows client doesn’t allow you to change the value from 0xFEFF. The following C# example shows how you can do that to spoof the client PID as 1234 when opening the pipe named “ABC”. Therefore it’s still possible to spoof an arbitrary PID using the local SMB server, a mount point and a suitable EA buffer. Unfortunately since Windthe kernel’s handling of NTFS mount point targets was changed to allow reparsing to named pipe devices as well as more traditional file system volumes. Once CVE-2018-0749 was fixed it was technically no longer exploitable. As SMB file open requests can also specify an arbitrary EA buffer, this allowed a local client to open a named pipe connection with completely spoofed values, including the PID. Prior to the fix for CVE-2018-0749 it was possible to set an arbitrary local NTFS mount point and redirect all local SMB requests to any device including NPFS, which normally wouldn’t be possible if the file was opened directly as the kernel would refuse to link to a non-volume targets. The mode check should prevent a normal user-mode application spoofing the values.Īs I discussed in my IO Manager blog post, the check that the NPFS driver is making to prevent spoofing of connection attributes can be bypassed, if you can find a suitable initiator which will set the previous access mode to KernelMode. As a normal user-mode process can specify an arbitrary EA buffer the code also checks that the operation is coming from kernel mode. The second option is used by the local SMB server, by specifying an EA buffer the driver allows the SMB server to specify connection information such as the client’s computer name and additional PID and session ID. This is the normal operation when creating a client connection in-process. Firstly, if no Extended Attribute (EA) buffer is provided in the file creation request, the PID and session ID are taken from the current process. When setting the attributes there are two options. The value stored in the attribute list can be retrieved by issuing a File System Control request with the undocumented FSCTL_PIPE_GET_CONNECTION_ATTRIBUTE code to the server pipe. The PID (and associated session ID and computer name) values are set using a generic attribute mechanism through the NpSetAttributeInList function. Only if Securit圜heck (highlighted) returns true will the client’s call be handled. If the API call is successful then a call is made to Securit圜heck which performs some verification on the PID. This code creates a named pipe server, waits for a new connection then calls the GetNamedPipeClientProcessId API. As relying on this PID is dangerous I decided I should highlight ways of spoofing the PID value so that developers can stop using it as an enforcement mechanism and demonstrate to researchers how to exploit such dangerous checks.Ī simple example of a security check using the client PID written in C# is shown below. Third-party applications are another matter and other researchers have found examples of using the PID to prevent untrusted callers from accessing privileged operations, a recent example was Check Point Anti-Virus. However I couldn’t find any first-party applications installed on Windows which used the PID for anything security related. It was clear that there must be some applications which use the client PID for the purposes of security enforcement. This feature was introduced in Vista and is exposed to servers through the GetNamedPipeClientProcessId API, pass the API a handle to the pipe server and you’ll get back the PID of the connected client. While researching the Access Mode Mismatch in IO Manager bug class I came across an interesting feature in named pipes which allows a server to query the connected clients PID.
0 Comments
Leave a Reply. |