Video by GN has a little bit of info (but not a lot). Basically they made it so that the pipes only accept input from MSI signed software + the pipes can only invoke MSI signed executables.
> pipes only accept input from MSI signed software
This does not inspire confidence. I'm assuming the pipe exists so that some GUI process running as the current user can perform privileged actions since the other end of the pipe runs as SYSTEM. At this point, just inject a thread into that GUI process and send the command - the service will think it is coming from MSI software, because it is.
The "only invoke MSI signed executables" mitigation is a good one, but if these two things are all they have done, while leaving the "arbitrary registry write" primitive in, then this is still 100% vulnerable to local privilege escalation.
I don’t think “only invoke MSI signed executables” inspires confidence either. There’s ought to be an MSI signed executable that launches arbitrary executables by design and defeats the mitigation.
The author got around a similar mitigation in their exploit for ASUS DriverHub (linked in the original article).
Sure. On Windows, you can allocate memory into an arbitrary process’s address space with VirtualAllocEx, write arbitrary code into those allocated pages using WriteProcessMemory, and start a thread there with CreateRemoteThread.
Now, of course you can’t do this for every process, or it would be trivial to escalate privileges. But I’m pretty sure you can do this for child processes running as the same user.
Yep. There's a system of ACLs and integrity levels which determine whether you're allowed to do this or not (doesn't have to be a child process), but for the most common case:
* a process running at medium integrity level with the current user's token
* another medium integrity process with the same token can open it with PROCESS_CREATE_THREAD and PROCESS_VM_WRITE rights
https://youtu.be/Eck8NnoaD4M