Windows Service Security Descriptors

Project:  Windows Service Security Descriptors

Overview:  A project aimed at tracking and mitigating the vulnerabilities in ACLs on Windows services in your network.

Requirements:

1. Windows Clients - Windows Vista+
2. Microsoft SMS/SCCM 2003+

Why Should I Care?:

1. Windows services run with the NT Authority\System account, unless otherwise specified.
2. The application of Windows service ACLs is left up to the vendor who installs the service.
3. Many Windows services (especially driver services) are poorly written so that the service allows Everyone, Full Control access.
4. The exploitation of vulnerable service ACLs is very common part of a hacker's escalation path in your network.

In a nutshell, any normal user account that is on a system with this vulernable ACL on a service can very easily elevate their credentials to that of a local Administrator.  This is a key part of the escalation path because once a hacker has local Administrator access, they can run/install any program they want on a system to start stealing domain-level user credentials.

Scope:

This project is nothing more than addressing one facet of a single part of a hacker's entire escalation path.  Some might argue that this is more effort than its worth and depending on your network's security requirements, and for some, it absolutely is.  However, if your goal is a high security environment or you simply want to prevent a hacker from penetrating your network by any and all means, this information would be of interest to you.

How it Works:

1. Host
• A script runs on each host that queries the Windows services for ACL information.  The data is filtered, formatted, and then written to a custom WMI namespace and class.  The SMS/SCCM client accounts for the new class and sends the data up to the SMS/SCCM server with the frequency of its own hardware inventory.
2. SMS/SCCM Server
• The SMS_DEF.MOF file must be updated to tell the SCCM clients to start accounting for the new WMI class in the new namespace. 

Now that the information is being aggregated by the SMS/SCCM client natively, you can leverage SMS/SCCM collections, reports, advertisements, etc. to:

1. Provide reports on vulnerable services in your network.
2. Create collections of "like" services with the same vulnerability.
3. Use advertisements to fix vulnerable services throughout your network in a targetted way. 

Installation Aspects:

1. Security_Descriptor_Service_WMI.vbs
• This script creates a custom WMI namespace and class and then populates that namespace and class with the data from the vulnerable services on the host.  This script should run at system startup or through an SCCM package.  I'd highly recommend the SCCM package over a startup script because of the integrated ability to enforce that the script runs and it runs with any kind of frequency.  A startup script requires the machine be rebooted before it will run.
2. SMS_DEF.MOF Modifications
• Append the mof file definitions to this file so the SMS/SCCM clients will start aggregating this information up to the SMS/SCCM database.  If you have multiple site servers, these changes must be done to each SMS_DEF.MOF file on each server.

Example Report: