Every piece of new technology carries intrinsically a new balance of benefits/risks and brings new security trade-offs from a forensic perspective.
I’d like to give a forensic point of view on Desired State Configuration (DSC) as it isn’t an exception of the above rule.
The following sentence inspired me
Windows 10 and Server 2016 will have PowerShell version 5.0. PowerShell 5.0 includes a feature called “Desired State Configuration”, which is similar to Chef, and will be the future of Windows security templates, such as for DoD STIGs and enforcing Windows-related critical controls.
First, let’s correct quickly the above sentence. PowerShell Desired State Configuration aka DSC is already built-in into PowerShell version 4.0 and shipped along with Windows 8.1 and 2012 R2. DSC is actually already present. I know the course SEC505 targets Windows and I also don’t want you to believe that DSC is a Windows thing only. It’s actually a declarative language and distributed heterogeneous configuration management platform that will allow you to target both Windows and Linux operating systems.
Now let’s examine DSC from 2 different angles and security stances: attack/defense.
DSC will allow you to deploy security settings (registry based), features (Bitlocker,…), anything actually … that will help hardening the configuration of your assets and protect these assets. Yes, Jason Fossen is right, it will help you implement faster security templates and controls. Because of the simplicity of DSC, you’ll also be able to scale out more easily and quickly.
But, even if you declare everything in your configuration either set to present or absent, DSC won’t be able to detect and handle something new that has not been previously declared.
Let’s think of services or firewall rules,… for example. Although you’ve inventoried every known and expected services or firewall rules, if a malware creates a random service name and open a random port in your firewall rules, DSC cannot do anything about it. Once this malicious service or firewall rule is known and identified, DSC can of course help you remediate and fix the problem by deploying a new configuration that takes care of it.
DSC is currently more a post-mortem remediation tool and cannot help you identify the unknown (usually malicious).
DSC could theoretically enforce a better security posture if it wasn’t based only on a declared list of absent/present things. DSC is built in mind with the concept of idem-potency which is not ground-breaking but a very good layer to built on top of and that will for sure make the success and foster the adoption of DSC in the IT landscape.
If the list of configuration items wasn’t treated as a strict list of things to be set to present and absent, I could declare known things to be set to present or absent and have a third implicit rule by default that would set anything (*.*) not declared to absent. It would somehow mimic the way the Applocker works in Windows where you can combine both a whitelist (present known items), a blacklist (absent known items) and an implicit rule that blocks unknown items.
From a attacker perspective DSC could be used to achieve persistence.
Let’s think of a small configuration that would download a zip file from the Internet, escaping your Antivirus detection, expand the archive to deliver the malicious payload, make sure the malicious service or process is in a running state. A malware could leverage DSC to deploy this configuration to your computer(s). Currently tools like autoruns.exe from Sysinternals can scan the WMI repository for permanent events but I don’t think it’s currently able to scan for a malicious DSC configuration or a malicious WMI provider.
From an architecture perspective, the pull server is also an attractive target because once compromised, it allows to deliver the payload to all the managed computer nodes that pull their configuration from it. Having an unsecured pull server puts your data center at risks and is worst than having none.
Let’s think bigger and that the attacker has great DSC skills. I don’t like to spread FUD but let’s imagine a second that an attacker compromised your fabric where he found unused (and fortunately limited) compute, storage and networking resources. DSC would allow him to deploy Hyper-V (or another hypervisor), create an external and internal virtual switch, a rogue virtual machine plugged onto these two virtual network switches. This virtual machine would be binding the private subnet and its Internet connected network interface, could host a rogue Dhcp, Dns, Vpn, Proxy… server and could be responsible for encrypting network traffic. Then, the attacker could provision virtual machines on this private subnet – an army of zombie computers – to carry on his malicious duties and consume your (unused yet) data center resources. He could send spam, perform DoS (denial of service) attacks and even use Docker-like technologies to reach a greater VM density. If you think of the recent attack on Sony in 2014 where about one hundred terabytes were exfiltrated before it got discovered, the scary scenario I imagined could be feasible. The attack could also take place on the public consumer market where the attacker would perform the same attack on your Windows 8.1, Windows 10 or Ubuntu workstation. By using DSC, the attacker could easily raise and control a botnet, an army of zombie virtual computers. The DSC pull server could be considered as his C&C (Command and Control server) in this case.
DSC can be considered as a great opportunity and facilitator by attackers because it helps scaling out and utilizing compromised resources to their full potential.