- This topic has 7 replies, 2 voices, and was last updated 3 years, 7 months ago by .
-
Posts
-
I’m sure everyone has seen this zero day vulnerability for PsExec. Do we need to patch this within Batchpatch or elsewhere?
FYI: details of how the local privilege escalation is accomplished are here.
The simplest thing you can do right now to mitigate this issue is under ‘Tools > Settings > Remote Execution‘ set a value for ‘Use PsExec -r switch‘. When you enter a custom value in this field, the PsExec remote service and named pipe are created with that custom name instead of the default name, PSEXESVC. In this way a malicious user pipe squatting on your target servers as \PSEXESVC won’t have any impact on you because your pipe will be created as \YourCustomName. The malicious user would have to know/guess your custom pipe name in advance in order to cause trouble, which would be highly unlikely and require the attack to be targeted at you specifically instead of just a generic attack. Additionally, note that this is a local privilege escalation, which means that your machine would *already* have to be compromised by a malicious user in order to perform it. It would allow the attacker to gain higher level privileges on the computer, but the computer would already have to be compromised with lower level privileges, so the threat level of this attack is realistically not very high in most cases.
That said, we don’t know at this time when Microsoft will address the issue directly in the PsExec code (they apparently did suggest that they will release an update to PsExec to resolve this, though it’s unclear when), so we will be publishing an additional safety measure to BP soon that will enable you to add a pseudorandom number/string to your custom name so that every single action would get a unique remote service and pipe name. This would virtually eliminate any possibility for exploitation by making the pipe name even more unguessable, thus further reducing the possibility of any pipe squatting on that name. And we will additionally be considering other possibilities moving forward as well.
Looks like on January 11 2021 PsExec version 2.3 was released. However, we don’t know at the moment if it fixes the issue, though we assume there is a good chance that it does. Also, in our initial test, and confirmed by one other user, PsExec 2.3 seems to not work properly. In BP it produces ‘Error 1611:233 Failure’. We don’t know yet if all BP users would experience this or only some. We are investigating. Not yet sure what to make of it.
Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe v2.3 does not have the same issue.
OK so where things have been left is that PsExec v2.32, which is the current/new release, will work the same as previous versions of PsExec, when using SYSTEM remote execution context. However, when using ‘Elevated token’ in conjunction with alternate credentials in PsExec v2.32, you also have to now additionally use the -i (interactive) switch. In the next release of BP we will add this option as well.
Microsoft appears to be considering this change intentional, and not due to a bug after all. It’s unclear at this time if they will be making any additional changes in the near future, but all signs point to this being where things will be left, at least for now. It does not appear that they plan to release an update to replace v2.32 any time in the very near future.
It appears that the current version 2.32 doesn’t actually fix the root issue, so while the original PoC for the LPE doesn’t work on 2.32, the researcher who found the issue was able to quickly modify his PoC to work on 2.32. That said, we believe Microsoft is now working on another update, so it might make sense to wait for that to be released, but of course this is up to you. As an alternative you could also use PaExec if you want. With PaExec, if you specify alternate credentials (not an issue when using integrated security), it obfuscates but does not encrypt them when sending them across the network. While this is not optimal, it’s also not necessarily a deal-breaker, but there’s a tradeoff to consider. You can read more on that tradeoff here: https://batchpatch.com/psexec-v2-1-all-network-communication-is-now-encrypted
As for updating… You can just replace the psexec.exe on your computer with the new one (though you should keep a backup of the old one too in case you want to revert to it). Or you can use ‘Tools > Settings > Remote Execution > Use psexec.exe custom filepath’ to point BatchPatch to any version of PsExec or PaExec you want.
They released PsExec v2.33 yesterday (March 23, 2021). We believe the issue is now properly resolved in this version.
Thanks.
- You must be logged in to reply to this topic.