Manage the Administrators group
Examine any default install of Windows since NT4 SP6. You’ll notice that the SeDebugPrivilege is assigned by default only to the .\Administrators local group of the Windows host. While this isn’t exactly unusual for users to be members of Administrators on their own PC, don’t think that every user or process automatically gets this capability in Windows.
Countermeasure: If you want to assert an explicit distinction between those who do and do not have the SeDebugPrivilege on a Windows system, explicitly manage the membership of the Administrators local group. This is especially useful (and applicable) to Windows Servers, where most of your users won’t have (or have need for) this membership.
How to implement:
- run the net localgroup command locally e.g. with these parameters: “net localgroup Administrators NAME_OF_USER_OR_GROUP_TO_REMOVE /Delete” (or run it remotely via a remote-shell tool such as psexec.exe)
- configure a Group Policy (e.g. using Active Directory group policy) that sets the membership of the Administrators group using the Restricted Groups security setting (either overwriting the existing membership or incrementally adding/deleting specified security principals)
Manage the SeDebugPrivilege
The obvious flipside of the default SeDebugPrivilege assignment is that you can change the security principals to whom the privilege is assigned. In fact, if you review (or have implemented) the Microsoft Security Security Accelerators for Windows (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008), you’ll find they recommend
Countermeasure: remove the Administrators group from the SeDebugPrivilege.
How to implement:
- run the ntrights.exe Resource Kit command-line tool locally e.g. with these parameters: “ntrights.exe –u Administrators –r SeDebugPrivilege” (or run it remotely via a remote-shell tool such as psexec.exe)
- configure a Group Policy (e.g. using Active Directory group policy) that removes all security principals that are assigned the SeDebugPrivilege privilege
Run Apps, Services as lesser-privileged user
So the first two BKMs are great and all, but there are still lots of situations where you can’t make these blanket changes to the entire OS (though thankfully virtualization is reducing these “shared system” problems). You may have to find ways to launch one or more processes with different security context or privileges than the rest of the system – sometimes having to run something with more privilege than the rest of the system (e.g. try Sudo for Windows), but usually wanting to strip privilege and permissions away from specific processes.
Countermeasure: use Windows’ Software Restriction Policy (aka SRP or “SAFER”) to strip the Token of as many groups and privileges as the application can tolerate. You don’t have to set a restrictive policy for the whole system – you can set this on an application-by-application basis (which can be practical in server environments, where you may only have a few critical applications to have to protect from each other).
How to implement:
- Download and use Michael Howard’s SetSAFER application, which will strip varying levels of privileges and groups from the security token assigned to the process (thus making it more difficult for the process to access privileged objects in Windows). If you want to dig into the code for this, and if the source code isn’t available, you can take a look at the code included in the original article (on which SetSAFER was based), or fire up DotNet Reflector and inspect the MSIL for the SetSAFER “executable”.
- You could also try “psexec –l” (which implements one of the approaches taken by SetSAFER – one of the “stripped-down profiles”).
Something about this feels like I’ve missed another approach that should be mentioned in this context, but I’m sure there’s smarter folks than I reading this who can add any missing details to the picture. Thanks, and have fun with this!