Hi, Just want to throw out a question for open discussion. What can be done about privilege escalation? I have plated around with PowerUp, a privilege escalation tool. It found a 'modifiable' service which runs as local service or was it local system?. I checked the registry and file system and I don't know how to exploit it - the permissions were fine. The service belongs the Shade, a free sandbox program. I guess with new exploits coming out every day, it is impossible to foresee which component would harbor an exploitable flaw. What can be done?
Nothing much can be done for components that need to run with system or high integrity level to do their job. They can be exploitable, but you can't limit their rights as they probably wouldn't work any more.
Here an excellent primer on privilege escalation: http://www.fuzzysecurity.com/tutorials/16.html . Take note of the use of WMIC.
1. Disable unneeded services and drivers. 2. Use as few program run privileged as possible. For those programs you need to run privileged, ideally they should be well secured (ASLR, CFG, bug bounty, etc.) and have no remote attack surface window (AV is terrible in this sense) 3. Use SUA with UAC max on Windows. Use sudo instead of su on Linux, and patch Linux-hardened kernel as GRSecurity went private. UAC can still be bypassed so depending on your threat model you might want to forbid SUA's escalation entirely via registry tweak. 4. Use sandboxed browser such as Chrome and it will reduce EoP attack surface, not only Win32k lockdown but also technique like nulling-out ACLs will be harder. Chrome's sandbox is even tighter on Linux thanks to seccomp-bpf. You can also default-deny javascript and it might lower reliability of the EoP exploit, and also will mitigate many RCE exploit for the first place. 5. Needless to say properly secure your OS and programs, and don't forget to disable untrusted fonts as they often leads to EoP. Also LSA protection will mitigate pass-the-hash style attacks. OTOH AppArmor or Tomoyo will limit the damage even after privilege escalation. 6. Use 64 bit OS and make sure your CPU support SMEP (many bypasses but better than nothing) 7. You can even use VMs and run those vulnerable programs such as browser and document viewer in it so that even if kernel exploit was done, unless VM escape was combined, it will be contained.
Hi Umra, I have 2 layers for blocking execution of programs. VoodooShield and Simple Software Restriction Policy SSRP.
Hi Minimalist, I am thinking of blocking reg.exe, regedit.exe and regini.exe for the System account. Because one can reset SRP by changing the registry. That is, if they escalated to System. And, the System account would rarely need those 3 command utils, and Windows itself, if it needs to change the registry would do so by calling Win32 functions. What do you guys think?
I would think it pointless as anything that could access the registry with enough privilege to change those settings wouldn't need to as it could already do whatever it wanted. Unless I am missing something that I am unaware of.
You probably mean to block execution of those files by SYSTEM using ACL? I don't know if system doesn't need those rights (at least during system updates and similar). You would have to test it by yourself. Personally I would create system image before doing anything like this.
Agreed. You can put as many obstacles as you want but once attacker gain system priv it's matter of time, effort, and skills of him/her if they're bypassed. Remember, there're some SRP bypasses w/out escalation. It's better to put effort to prevent escalation and user-mode bypass. Some programs also use reg.exe, tho I don't remember what it was. It's long time after I removed blockage. Regarding ACL, attacker w/ admin or system priv can change ACL so that won't make much sense.
Yes, in this case attacker could change ACL if payload runs under something other than SYSTEM. Under SYSTEM it couldn't as it's rights on file were "revoked".
Here is one screenshot, that might explain it better: I denied all rights to SYSTEM ( I also had to take ownership before doing it). In theory, if process that runs under SYSTEM (let's say process belonging to AV) is exploited, it couldn't do anything with reg.exe. OTOH, if i run malware under my credentials and allow it to elevate, malware could use reg.exe with no problems. Personally I wouldn't use this approach, since it's IMO to dangerous.
