[Last Reviewed: 2019-06-04]
At MMSMOA 2019, I enjoyed a great presentation by Tom Degreef and Kim Oppalfens about Configuration Manager security. It was an amazing session, and I want to share some of the learnings I took away from it.
But first, a heart-to-heart
Extend the peace branch to your network and security teams.
I’ve noticed at conferences and elsewhere–you’ll hear things like “who needs network admins or sysops, we just need sysadmins.” Perhaps this started as a lighthearted joke, but it’s grown into a battlecry for some. This is unfortunate. At the end of the day, we’re all working under the same organization with the same business goals (and all have a common enemy–those who wish to use our network for evil).
I get it, it’s really easy to think that other teams in your organization are there just to make your life miserable. The fact is these teams (including yours!) are doing what they’re required to do for the business, and they’re doing their best with the information they’ve got. Not every team speaks in application deployments or CMTrace-friendly logs. Other teams see ConfigMgr as bandwidth, as NTLM handshakes, as port 10123 traffic, or disk storage.
This is where you come in.
Add value to their perspective. Get them involved. Show them that there’s so much more to the ConfigMgr space. It will be a learning experience for everyone, and you might just start to see things from their perspective as well.
A slightly different outlook
ConfigMgr is a Tier 0 application sitting in your environment, holding all sorts of data and all sorts of control over your domain. Look at the power this product wields from a single console:
- Deploy applications or packages to any machine, including domain controllers
- Deploy policies (configuration baselines) to any machine, including domain controllers
- Run Scripts against any machine, including domain controllers
You’re probably getting the idea here, but it’s not just ConfigMgr pushing changes out. It’s also ingesting data. Does your database contain LAPS passwords? Patch compliance? Members of the local administrators group? This is useful information for you, but it’s a veritable gold mine for a security researcher who’s poking around for information on your network.
This is where the perspective change comes in. You use ConfigMgr because it’s an incredibly powerful tool for good. A researcher may use ConfigMgr because it’s an incredibly powerful tool for…something that probably doesn’t align well with the business.
Let’s take a look at a few different ways we can harden our environment.
NOTE: Some of these steps may look a bit “tin-foil-hat”, but it’s all about determining your business’ level of acceptable risk.
Content Source
Scenario
If you weren’t familiar with how ConfigMgr worked and spent time looking from the outside in, you’d probably notice the folder containing all your application, package, and script sources. If these files aren’t properly secured, a researcher could modify an installer (or modify a script that wraps around an installer–would you notice an extra line or two in a PSADT script?) These applications bypass UAC, and could even bypass Windows Defender Application Control.
If your source directory is read-only, there still could be information of value. Do your scripts have credentials or other secrets in them? Are there license files?
Mitigation Steps
To help keep your source content safe:
✅ Determine who is an admin of the server (and make sure they’re not using weak credentials). Content Managers do not need admin rights to the server.
✅ Consider setting NTFS permissions on the content source directory to only allow creation of new folders and content (and assign these to only those who need it).
✅ Consider setting separate NTFS permissions to allow updating content, but only grant these permissions when required.
✅ Consider using a PAWS (or a well-protected device) when updating content.
✅ Consider validating the content of your source files with a directory hash before updating.
ConfigMgr Server
Scenario
If you weren’t familiar with ConfigMgr, but wanted to gain access to it, you’d probably look at the server itself and see how it was configured. Who’s an administrator of this machine? Are they using weak credentials? Is Windows Firewall on and configured properly?
Mitigation Steps
To help keep your server safe:
✅ Determine who is an admin of the server (and make sure they’re not using weak credentials).
✅ Patch the server regularly!
✅ Validate that the server’s physical access is protected (and if it’s a virtual machine, validate that the host’s physical access is protected).
✅ Require MFA for login sessions (for interactive login or via RDP)
✅ Require MFA for the SMS Provider
✅ Limit the number of Full Administrators in ConfigMgr (to zero, if you can–use an empty group)
✅ Avoid adding individual users to RBA (Role-Based Access) who are already covered by a group membership
SQL Server
Scenario
If you are a local administrator of a SQL Server, you can become a SQL administrator with not much effort.
If you are a SQL administrator, you can become a ConfigMgr admin with, again, not much effort.
Mitigation Steps
To help keep your SQL server safe:
✅ Only open SQL firewall ports for roles that require direct SQL access
✅ Consider using a Group Managed Service Account
Status Filter Rules
Scenario
Status Filter Rules are great. You can trigger actions based on a state message ID. You can find many great scripts online, but be mindful where you download these. Status filter rules run with the highest privileges.
Mitigation Steps
To help keep your environment safe from rogue status filter rules:
✅ Sign your PowerShell scripts
✅ Validate NTFS permissions where your scripts are stored
✅ Consider using filters that are as strict as possible
Client Installation
Scenario
When a client is not yet managed by ConfigMgr, there’s the potential to trick a client into talking to a different Management Point (or even worse, execute a pass-the-hash attack to capture information about the client push account). Client push has a large attack surface: it requires a lot of dependencies to work, and it can be easily exploitable if Kerberos isn’t enforced.
Consider using a PKI infrastructure. This is not very popular, but has security benefits. Otherwise, consider Enhanced HTTP–you may find that it takes significantly less effort to enable this.
Mitigation Steps
To help keep your client installation safe:
✅ Don’t use client push
✅ If you must use client push, enforce Kerberos mutual authentication. Introduced in 1806, this prevents client push from using NTLM
Network Access Account
Scenario
The Network Access Account (NAA) is evil. This account is used by clients when they can’t use their local computer account to access content on distribution points (think OSD). It’s credentials are encrypted in a policy that is deployed to all machines, but the local ConfigMgr agent is able to decrypt this password.
Mitigation Steps
To help protect your NAA:
✅ Don’t use one! By enabling HTTPS/Enhanced HTTP and Token-based authentication, you can eliminate the need for the NAA
✅ If you must use a NAA, do not over-privilege the account.
Trusted Root Key
Scenario
ConfigMgr site servers exchange keys to communicate with each other. The top-level site in the hierarchy is the trusted root key–it’s function resembles that of a root certificate in a PKI.
Clients automatically retrieve this key from client push, or from Active Directory (when AD has been extended with the ConfigMgr schema). If a client cannot retrieve the trusted root key using one of these mechanisms, they could be misdirected to a rogue management point.
Mitigation Steps
To help protect your unassigned clients:
✅ Validate that ConfigMgr has published it’s site to any AD domain it’s managing
✅ If this cannot be done, manually deploy the key.
OSD/PXE
Scenario
OSD/PXE can be an interesting target. It’s during this time that machines are onboarded and built from scratch. If a researcher is able to open a command prompt during OSD, all sorts of information could be extracted–and any commands would be run with elevated permissions.
Mitigation Steps
To help protect your OSD environment:
✅ Use a client authentication certificate when creating boot media
✅ Disable command line support in boot images
✅ Be mindful of Runas accounts in task sequences, and validate that they are not over-privileged.
✅ Use HTTPS or Enhanced HTTP!
Local Machine Data (Data Leakage)
Scenario
ConfigMgr admins love logs–we are spoiled with lots of them. These logs, as well as other local ConfigMgr content, could be interesting to a security researcher.
Mitigation Steps
To help protect your local machine data:
✅ Be mindful of the logs that are left behind after OSD
✅ Be mindful of other ConfigMgr logs that may include interesting information (like execmgr.log)
✅ Are you storing sensitive information in WMI?
✅ CCMCache files are readable by regular users!
✅ Search through your logs or cache–do you see keywords like “-UserName“, “-Password“, or “-Key“?
Application Management
Scenario
Most application deployments are running with the highest privileges, which could make them a target. This risk is significantly higher if an application is interactive.
The Application Catalog roles are an IIS attack surface–they are no longer required if you are using the new Software Center.
Mitigation Steps
To help protect your deployments:
✅ Use the new Software Center and remove the application catalog roles
✅ Consider preventing user interaction with elevated processes
✅ Always download and execute applications–this ensures nothing is tampered with in-transit
Software Updates
Scenario
Much like the content source directory, the software updates directory could be tampered with–meaning incorrect content could be deployed to your machines under the guise of keeping them updated. Keep these locations secure!
Mitigation Steps
To help protect your software updates:
✅ Validate ACLs of the Software Updates download location
✅ Validate ACLs of the Software Updates package folders
✅ Protect these paths with SMB signing or IPSEC
✅ Consider using a dedicated WSUS website
Configuration Items
Scenario
CI’s are powerful, but a carefully-crafted CI could be used to execute code in your environment. You can find great CI’s online, but be careful where you download these.
Mitigation Steps
✅ Be mindful of importing CI’s from unknown sources
This is only the beginning
Your ConfigMgr environment is powerful. The product is outstanding and gets better with every release. More and more organizations are using ConfigMgr to manage their environments. As it becomes more popular and more powerful, it will continue to become increasingly interesting (and eventually become a common target).
As you continue to manage your environment, be mindful of the changes you implement. Stop and think for a moment–think like a security researcher–could the action you’re about to perform undermine existing controls in your environment (such as not signing a PowerShell script)? Is there an existing site configuration that could be used to exploit your environment (such as using client push)?
Remember: Security is everyone’s responsibility. Some day, your environment will thank you for it.