Welcome to the second installment of, "Weekly Tech Tidbits". This week I am going to answer a very common question, "Why do we have to remove local Administrator rights to workstations?"
The answer is quite simple.
Almost every single attack on your network begins on a workstation.
Someone clicks on something. No matter how thorough you are in patching and updates and no matter how many layers of security you have there is always going to be a day zero exploit. Sooner or later something will get by all of us.
A few years back, the head of the NSA said that we as technical professionals have to assume that the bad guys are already inside our networks and sitting in the room next to us. Knowing that we have to design network security with that in mind.
The way most workstation based attacks work is that the bad guys get a foothold on your workstation. Then they start poking around to see what they can see and probing to see what they have rights to look at.
If the user is a limited user, that infection is probably trapped on that machine having been installed in something such as %USERPROFILE% (i.e. C:\USERS\USERNAME\TEMP). Even limited users have "ALL" rights to this section of their workstation.
In previous Tech Talks and webinars we have discussed that even a limited user can probe and map the network and potentially identify the domain admins for the network. Those domain admins will be the subject of a future phishing attack.
However, once we start giving out local administrator rights, we dramatically enhance how the bad guys can hurt us. The reason for this is a simple, but often forgotten concept of Windows security.
Privilege trumps permissions.
We are all familiar with Share and NTFS permissions. We know the rule that the effective permissions are the most restrictive combination of Share and NTFS permissions.
However, privileges shred permissions. By giving out the privilege of being a local administrator on the workstation you have created a scenario where you cannot completely control the user's access to the workstation. Whatever restrictions you impose, they are completely irrelevant to the bad guys. They can undo them. While you trust the special education teacher and can rationalize that even if they trash their workstation by having the additional rights, the reality is that if they are infected, the bad guys are going to quickly "undo" whatever local or group policies are in place to control and limit the end user experience. Again, this is because privilege trumps permissions.
At the last meeting I talked about the Microsoft Ignite presentation at the end of September where the presenter demonstrated how he could create a domain admin ID and password on your network just by creating a simple scheduled task on a local workstation and then creating a workstation issue that would warrant a tech visiting the workstation. They are counting on that tech having additional rights and "unlocking" access to the entire network. In that simple scenario the bad guy has just jumped from a local workstation infection to unfettered access to your entire network. They have whatever they want. If they want to destroy you, it is now effortless for them to do that. If they want to steal your personally identifiable information, they can take what they want.
There are many more reasons and scenarios I can give, but hopefully you get the point. We all must start working under the premise that the bad guys are going to be in your network and thus design security that limits what they can see and do - regardless of their rights. We need to keep them blind to anything about our network that can be used to exploit our network.
Instead of handing out local administrator rights use ICACLS and REGPERM to create the explicit extra rights your users require without giving everything away. This is arguably more challenging than just giving away the workstation. However, we can script these and push them out via KACE or SCCM or similar tools to make it easier for use to manage these special local rights requirements.
If you have questions, or having a problem making the transition to limited users on local workstations, please give me a call and let's talk about your specific situation.
Scott Quimby
You must be logged in to post a comment.