5 ms·

Windows Exploitation Tricks: Spoofing Named Pipe Client PID

51 points by weinzierl 7y ago

mehrdadn 7y ago
Summary of the takeaway: the GetNamedPipeClientProcessId function returns the PID of the process that opened the pipe, not the one that is currently communicating. However, the client PID can sometimes be specified manually, and even when it can't, handle duplication followed by PID recycling can make this PID point to an arbitrary process (hence it should not be used for security checks).
- tinus_hn 7y ago
  So what is the use of this function?
  - londons_explore 7y ago
    Perhaps just for putting an informative PID in log messages?
- ammmir 7y ago
  Wouldn't it be better to return a kind of ENOENT status if the process creating the pipe has disappeared (or its PID recycled)? Seems like a design flaw since PIDs have finite lifetimes and not communicating that through any API call return could pose a potentially serious security issue.
Little_John 7y ago
Windows should never be used for security checks, who do you think they are?
muststopmyths 7y ago
>It was clear that there must be some applications which use the client PID for the purposes of security enforcement. However I couldn’t find any first-party applications installed on Windows which used the PID for anything security related. 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. 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. So, not a "Windows Exploitation Trick". Even the so-called "example" with Checkpoint is nothing of that sort. They were using the PID to find the executable and verify that it was signed with their certificate. The actual exploit in the link to the Checkpoint vulnerability has to do with spoofing the cert, nothing to do with the PID. The post is about a bullshit hypothetical "authentication" method that I have never seen anyone use in 25+ years of Windows programming. Edit: clarify last sentence I lost all respect for Project Zero this week.
- izacus 7y ago
  > I lost all respect for Project Zero this week. Aren't you being a bit... dramatic?
  - muststopmyths 7y ago
    I respect their technical expertise, of course. So, maybe all is an exaggeration :-)
    - tiraniddo 7y ago
      I'm not sure why I'm replying to the proverbial as you seem to have made up your mind, but being the original author of the blog post I thought I'd at least try and correct some seeming misconceptions. First off, the reason it's called "Windows Exploitation Tricks" is it's a blog post series ([1], [2], [3], [4]) of behaviors/tricks of the Windows OS that allow you to exploit security vulnerabilities, specifically logical privilege escalation vulnerabilities. If you read the introduction to [1] it outlines the purpose of the series, it's based on ways of exploiting real world vulnerabilities that I've discovered in real software whether it be in core Windows or third-parties. The rationale for writing them up is if you look for exploitation techniques and tricks on any platform almost everything you'll find it based around memory corruption, I don't look for fuzzed bugs so having a cool ROP chain is going to be much help to me and no doubt others who find themselves in this situation. So I write up interesting techniques I've discovered over my years of research to the benefit of others. There are secondary benefits to blogging about these techniques, for example it can act as developer education. If you look at the API referenced in the blog [5], you'll not see any security warning or advice associated with it. This leads developers to misuse the functionality without understanding how the OS works. The irony is not lost on AV vendors having no clue about the security principles of the OS they're protecting from security threats. Still if you've never seen a program using the PID (through whatever means it's got that value) being used for authentication on Windows or any other OS then I can only assume you've never really looked very hard for logical vulnerabilities. Another benefit is an aid to reporting. What I blog about in the series are not security issues in a traditional sense, instead they're chain building 'gadgets'. You might have a root vulnerability but not the means of exploiting it. In an ideal world a vendor would remove all non-essential functionality which could facilitate exploitation but we live in the real world and MS are not generally going to spend their time fixing something like this as a real security issue with a CVE etc. Therefore there's no real reporting process for me to follow to report it and demonstrate impact to MS, and as is typical if I find instances of the bug class which can be exploited with the trick they'll fix the reported bug, not the technique. However by making it very public it gets noticed by MS, for example [1] and [2] are both now fix/mitigated in the Windows 10 1903 in direct response to the blog posts. Finally I think you don't fully understood the scope of the example vulnerability I gave. The root cause of the Check Point bug is the service 100% trusted that the PID being passed from the named pipe was a useful piece of information to base a local security decision on (see end of the "Interacting with the Service" section). It used that PID as the start of a chain of checks to determine if the process at the other side of the pipe was a Check Point trusted application. The fact that in this case the whole logic of the check was fundamentally flawed is irrelevant for the purposes of the blog post. If their certificate checks had been completely robust and it wasn't possible to either spoof them or just inject a DLL then spoofing the PID would absolutely have allowed you to exploit that vulnerability. [1] https://googleprojectzero.blogspot.com/2017/08/windows-exploitation-tricks-arbitrary.html https://googleprojectzero.blogspot.com/2017/08/windows-explo... [2] https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html https://googleprojectzero.blogspot.com/2018/04/windows-explo... [3] https://googleprojectzero.blogspot.com/2018/08/windows-exploitation-tricks-exploiting.html https://googleprojectzero.blogspot.com/2018/08/windows-explo... [4] https://googleprojectzero.blogspot.com/2019/04/windows-exploitation-tricks-abusing.html https://googleprojectzero.blogspot.com/2019/04/windows-explo... [5] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getnamedpipeclientprocessid https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...

51 points by weinzierl 7y ago

Summary of the takeaway: the GetNamedPipeClientProcessId function returns the PID of the process that opened the pipe, not the one that is currently communicating. However, the client PID can sometimes be specified manually, and even when it can't, handle duplication followed by PID recycling can make this PID point to an arbitrary process (hence it should not be used for security checks).

tinus_hn 7y ago
So what is the use of this function?
- londons_explore 7y ago
  Perhaps just for putting an informative PID in log messages?
ammmir 7y ago
Wouldn't it be better to return a kind of ENOENT status if the process creating the pipe has disappeared (or its PID recycled)? Seems like a design flaw since PIDs have finite lifetimes and not communicating that through any API call return could pose a potentially serious security issue.

Little_John 7y ago

Windows should never be used for security checks, who do you think they are?

muststopmyths 7y ago

>It was clear that there must be some applications which use the client PID for the purposes of security enforcement. However I couldn’t find any first-party applications installed on Windows which used the PID for anything security related. 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. 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. So, not a "Windows Exploitation Trick". Even the so-called "example" with Checkpoint is nothing of that sort. They were using the PID to find the executable and verify that it was signed with their certificate. The actual exploit in the link to the Checkpoint vulnerability has to do with spoofing the cert, nothing to do with the PID. The post is about a bullshit hypothetical "authentication" method that I have never seen anyone use in 25+ years of Windows programming. Edit: clarify last sentence I lost all respect for Project Zero this week.

izacus 7y ago
> I lost all respect for Project Zero this week. Aren't you being a bit... dramatic?
- muststopmyths 7y ago
  I respect their technical expertise, of course. So, maybe all is an exaggeration :-)
  - tiraniddo 7y ago
    I'm not sure why I'm replying to the proverbial as you seem to have made up your mind, but being the original author of the blog post I thought I'd at least try and correct some seeming misconceptions. First off, the reason it's called "Windows Exploitation Tricks" is it's a blog post series ([1], [2], [3], [4]) of behaviors/tricks of the Windows OS that allow you to exploit security vulnerabilities, specifically logical privilege escalation vulnerabilities. If you read the introduction to [1] it outlines the purpose of the series, it's based on ways of exploiting real world vulnerabilities that I've discovered in real software whether it be in core Windows or third-parties. The rationale for writing them up is if you look for exploitation techniques and tricks on any platform almost everything you'll find it based around memory corruption, I don't look for fuzzed bugs so having a cool ROP chain is going to be much help to me and no doubt others who find themselves in this situation. So I write up interesting techniques I've discovered over my years of research to the benefit of others. There are secondary benefits to blogging about these techniques, for example it can act as developer education. If you look at the API referenced in the blog [5], you'll not see any security warning or advice associated with it. This leads developers to misuse the functionality without understanding how the OS works. The irony is not lost on AV vendors having no clue about the security principles of the OS they're protecting from security threats. Still if you've never seen a program using the PID (through whatever means it's got that value) being used for authentication on Windows or any other OS then I can only assume you've never really looked very hard for logical vulnerabilities. Another benefit is an aid to reporting. What I blog about in the series are not security issues in a traditional sense, instead they're chain building 'gadgets'. You might have a root vulnerability but not the means of exploiting it. In an ideal world a vendor would remove all non-essential functionality which could facilitate exploitation but we live in the real world and MS are not generally going to spend their time fixing something like this as a real security issue with a CVE etc. Therefore there's no real reporting process for me to follow to report it and demonstrate impact to MS, and as is typical if I find instances of the bug class which can be exploited with the trick they'll fix the reported bug, not the technique. However by making it very public it gets noticed by MS, for example [1] and [2] are both now fix/mitigated in the Windows 10 1903 in direct response to the blog posts. Finally I think you don't fully understood the scope of the example vulnerability I gave. The root cause of the Check Point bug is the service 100% trusted that the PID being passed from the named pipe was a useful piece of information to base a local security decision on (see end of the "Interacting with the Service" section). It used that PID as the start of a chain of checks to determine if the process at the other side of the pipe was a Check Point trusted application. The fact that in this case the whole logic of the check was fundamentally flawed is irrelevant for the purposes of the blog post. If their certificate checks had been completely robust and it wasn't possible to either spoof them or just inject a DLL then spoofing the PID would absolutely have allowed you to exploit that vulnerability. [1] https://googleprojectzero.blogspot.com/2017/08/windows-exploitation-tricks-arbitrary.html https://googleprojectzero.blogspot.com/2017/08/windows-explo... [2] https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html https://googleprojectzero.blogspot.com/2018/04/windows-explo... [3] https://googleprojectzero.blogspot.com/2018/08/windows-exploitation-tricks-exploiting.html https://googleprojectzero.blogspot.com/2018/08/windows-explo... [4] https://googleprojectzero.blogspot.com/2019/04/windows-exploitation-tricks-abusing.html https://googleprojectzero.blogspot.com/2019/04/windows-explo... [5] https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getnamedpipeclientprocessid https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...