October 22, 2018
How to secure your Windows services
Windows services
Windows services are apps that run hidden in the background when the computer boots up and they have two important details relevant to this post:
They generally log on and run as “Local System” / “SYSTEM”. This is the highest level of permissions - even higher than administrator!
2. They have a “path to executable”. This specifies where the source EXE file that should be run is located.
So, basically, Windows runs the specified EXE files generally at the highest level of permissions possible.
The problem
Unfortunately, it has become common practice to proactively or reactively resolve certain problems with apps by granting deep permissions to broad groups (see below) on the app’s source folders and files. The reason for this is that it’s pretty much guaranteed to work without having to know the specific details of the system. However, doing this always opens an invisible can of worms and, almost all of the time, there are much more appropriate and secure solutions.
So, if a Windows service’s EXE file is affected by these insecure permissions then it can simply be replaced and the new EXE file will be executed on next startup. A lot of bad things can happen when anyone or anything with any level of permissions can run arbitrary apps at the highest level of permissions on a computer.
One such problem is called privilege escalation which means that elevated access can be granted with no authorisation from anyone. This is a common attack method for hackers and, as such, it has a high Common Vulnerability Scoring System (CVSS) rating of 7.2 out of 10 and could fail a Cyber Essentials Plus assessment. In fact, as a Cyber Essentials Certification Body (CB), we have seen this first-hand which is what led to this post.
To demonstrate a relatively tame version of this, we created a simple EXE file configured to add our standard user account to the administrators security group, replaced the EXE file of an insecure Windows service, rebooted the PC, and voilà - we have granted ourselves local administrative permissions and in only a few minutes no less. We have recorded a short video of this in action which you can see here or below (feel free to skip 01:25 to 05:15 which is just the reboot and sign-ins):
Now, I can imagine that this is somewhat difficult to understand so let’s try to use an analogy.
A security guard has keys to the front doors and locker room, as all staff members do, but also a key to the security room which contains the keys, codes, IDs, etc required to get access to all other areas. When the new manager was onboarded, they were told to make a copy of another staff member’s keys for themselves and for all other new staff members in the future so they did so using the security guard’s keys. See the problem? Most staff members probably wouldn’t know that that extra key was for the security room but if they found out and were so inclined then they could access all other areas and do whatever they want. All for no good reason.
A reactive solution
Please note: As previously mentioned, these insecure permissions are usually implemented to pre-empt or resolve problems with apps so removing the insecure permissions may cause those problems until a better solution can be implemented.
So, how can you remove these permissions if they are already set?
Well, we have created a PowerShell script which will automatically check and, if required, correct the permissions on the folder and file of each and every single one of the hundreds of Windows services! Or you could do so manually but that’d take a long time indeed.
As with our PowerShell toolkit for Cyber Essentials, this script is:
Free.
Digitally signed by us.
Compatible with PowerShell version 2 and newer.
Documented.
Should be bug-free but you should check and safely test it for yourself before deploying it.
We have made the PS1 script file available to download from our GitHub here and we have recorded a short video of it in action which you can see here or below:
A proactive solution
So, how can you prevent these permissions from being set in the first place?
Well, these insecure permissions are usually set:
By or via everyday users.
For example, a user has a problem with an app so they either (1) contact the software company whose technical support personnel either talks the user through implementing the “fix” or has the user remote them in and does so themselves or (2) they research the problem, find the aforementioned advice, and implement the “fix” themselves.
In either case, changes such as this (1) require local administrative permissions and (2) should be submitted to the IT support department for review. So, with this in mind, we advise revoking local administrative permissions from everyday users (we’ve made a PowerShell script for this too). Doing so will guarantee that dangerous changes such as this can’t be made by the users themselves (or anyone or anything using their account) without IT support being involved.By IT support personnel.
In this case, we advise educating the IT support personnel as to the potential dangers of doing so. Feel free to send them this post!
