3 ms·

Which implies that any malware capable of replacing these channel files can crash their kernel driver. I wonder if there's a non-crashing way to exploit this &

Which implies that any malware capable of replacing these channel files can crash their kernel driver. I wonder if there's a non-crashing way to exploit this & get kernel-space code execution.

numbsafari 2y ago
I can guarantee you that you aren't the only one thinking this right now.
ytch 2y ago
IIRC, there were some security software exploits, that trigger RCE (or DoS) of the scanning engine by malicious file?
joshka 2y ago
If you have write access a path like C:\Windows\System32\drivers\CrowdStrike\ (and I'd assume the parent directory), then you pretty much can crash the kernel many ways. If you have the means to insert an AV config file update in between the config servers and the user's host then you probably can PWN the system pretty easily as well. What this probably does mean is that Crowdstrike will be receiving some attention from hackers of both hat colors. Here's the bug bounty page ... https://hackerone.com/crowdstrike?type=team https://hackerone.com/crowdstrike?type=team
amiga386 2y ago
Any malware capable of modifying files under C:\Windows\System32 has no need to fiddle with these files because to have that capability means it already got the keys to the kingdom and could wreck the system in a billion different ways. See "It rather involved being on the other side of this airtight hatchway" https://devblogs.microsoft.com/oldnewthing/20200420-00/?p=103685 https://devblogs.microsoft.com/oldnewthing/20200420-00/?p=10...
- SAI_Peregrinus 2y ago
  The directory they're stored in needs Administrator access, but the kernel runs with SYSTEM level permissions. Administrator is an account, SYSTEM is a security principal. SYSTEM level processes can access domain servers in the context of the computer's domain account, while Administrators can't do so unless they provide explicit credentials (or share a password with an Administrator account on the domain). So this could be used as a way to elevate access from local Administrator up to whatever that computer can do on a connected domain server!
- SoftTalker 2y ago
  And yet the cleanup instructions were for the user to delete a file in that directory. That requires booting into safe mode, but if any random user is able to do that, kiss your systems goodbye, a good social engineer (or disgruntled employee) will own any desktop in your organization if he wants to.
  - amiga386 2y ago
    The point is, malware can't get into that directory without user consent. Having physical access to the machine, rebooting into safe mode and running commands is a stonking big user consent. I can pwn my own desktop, yes, all I have to do is say "run as administrator". But the point of the security boundary is to make it impossible for software to get these privileges without me actively giving it to them. If you're shifting the goalposts and imagining the computer does not belong to me, but to an organisation that I'm a mere employee of, they'll be using AD Group Policy to control what I can and can't do, and Bitlocker to encrypt the boot drive. I cannot boot into safe mode without having the tech support department give me a special code to unlock the computer. Again, that's how you get on the other side of the airtight hatch.
  - naib0930 2y ago
    In my organizations any user couldn't do it, we have to manually touch every computer and enter the bit locker key. We lost in the neighborhood of 14,000 end points, every single one needs touched. My team of 10 did about 800 in 5 hours. Pulling and entering the bitlocker key was what took the longest.

Which implies that any malware capable of replacing these channel files can crash their kernel driver. I wonder if there's a non-crashing way to exploit this & get kernel-space code execution.

numbsafari 2y ago

I can guarantee you that you aren't the only one thinking this right now.

ytch 2y ago

IIRC, there were some security software exploits, that trigger RCE (or DoS) of the scanning engine by malicious file?

joshka 2y ago

If you have write access a path like C:\Windows\System32\drivers\CrowdStrike\ (and I'd assume the parent directory), then you pretty much can crash the kernel many ways. If you have the means to insert an AV config file update in between the config servers and the user's host then you probably can PWN the system pretty easily as well. What this probably does mean is that Crowdstrike will be receiving some attention from hackers of both hat colors. Here's the bug bounty page ... https://hackerone.com/crowdstrike?type=team https://hackerone.com/crowdstrike?type=team

amiga386 2y ago

Any malware capable of modifying files under C:\Windows\System32 has no need to fiddle with these files because to have that capability means it already got the keys to the kingdom and could wreck the system in a billion different ways. See "It rather involved being on the other side of this airtight hatchway" https://devblogs.microsoft.com/oldnewthing/20200420-00/?p=103685 https://devblogs.microsoft.com/oldnewthing/20200420-00/?p=10...

SAI_Peregrinus 2y ago
The directory they're stored in needs Administrator access, but the kernel runs with SYSTEM level permissions. Administrator is an account, SYSTEM is a security principal. SYSTEM level processes can access domain servers in the context of the computer's domain account, while Administrators can't do so unless they provide explicit credentials (or share a password with an Administrator account on the domain). So this could be used as a way to elevate access from local Administrator up to whatever that computer can do on a connected domain server!
SoftTalker 2y ago
And yet the cleanup instructions were for the user to delete a file in that directory. That requires booting into safe mode, but if any random user is able to do that, kiss your systems goodbye, a good social engineer (or disgruntled employee) will own any desktop in your organization if he wants to.
- amiga386 2y ago
  The point is, malware can't get into that directory without user consent. Having physical access to the machine, rebooting into safe mode and running commands is a stonking big user consent. I can pwn my own desktop, yes, all I have to do is say "run as administrator". But the point of the security boundary is to make it impossible for software to get these privileges without me actively giving it to them. If you're shifting the goalposts and imagining the computer does not belong to me, but to an organisation that I'm a mere employee of, they'll be using AD Group Policy to control what I can and can't do, and Bitlocker to encrypt the boot drive. I cannot boot into safe mode without having the tech support department give me a special code to unlock the computer. Again, that's how you get on the other side of the airtight hatch.
- naib0930 2y ago
  In my organizations any user couldn't do it, we have to manually touch every computer and enter the bit locker key. We lost in the neighborhood of 14,000 end points, every single one needs touched. My team of 10 did about 800 in 5 hours. Pulling and entering the bitlocker key was what took the longest.