In our last blog about agents - The Problem with Agents (as a Primary Means of Security Policy Enforcement) - our CTO Marc Woolward called out several areas in which the effectiveness of an agent as a means of security control is ineffective. This ineffectiveness is largely caused by the nature of the circular dependency that an agent has on the integrity of the asset itself - if an attacker can gain control of the asset, then the agent protecting that asset is effectively useless; in some cases, the agent IS the security issue, and we cannot reliably attach our controls to the applications we are trying to protect.
When my daily infosec reading concluded with another write up about a severe Windows vulnerability (directly in the part of the OS that helps maintain asset integrity - what an agent depends on to provide security controls!), I knew I wanted to take Marc’s idea even further by illustrating the vArmour data center network segmentation approach using detailed, real world attack scenarios through the lens of agent-based versus independent controls.
For this post, let’s agree that many attacks leading to a breach can be described with a simple chronology, starting with reconnaissance activity, leading to internal lateral spread and asset acquisition, followed by data exfiltration. These are carried out using reliable, repeatable, and (usually) simple techniques:
- Infiltration - via phishing or social engineering which leads to credential theft and privilege escalation through any number of means.
- Special malware for compromise - can be part of an attacker’s playbook, but attackers will often “live off the land” using tools/resources already on the assets themselves - PowerShell, Windows SCCM, devops tools, etc.. Compromising a network is NOT all about exploit kung fu.
- Asset enumeration - Attackers perform asset enumeration to understand the relationship between the assets, where data might live, and where the egress points are - ActiveDirectory, port mapping, ping sweeping. If agents can be made to lie (or become mute), this anomalous activity might remain invisible - a network view cannot be made to lie, so these behaviors would stand out.
- Data egress from legitimate ports - Data is tunneled out of the environment through ports allowed by the firewall to locations allowed by geo policy - not every malicious server is in Eastern Europe!
Agents and Vulnerabilities in the Data Center
Marc earlier highlighted that an asset under the watchful eye of an agent is at the mercy of an attacker who can get at the operating system, revealing what policies the agent is enforcing, enumerating the running state of an asset like kernel hooks, applications, services etc.. Agents depending on iptables or Windows Filter Platform can be manipulated into sharing that information with an attacker OR simply by hooking directly into the host firewall itself. Unforeseen instabilities that arise from adding agent mechanism to the OS aside - some attackers focus on the host based firewall itself as a means of command and control, like the Derusbi malware family that was used in the Anthem breach of 2014, by using a special driver that hooked into the Windows Firewall, essentially becoming part of the asset’s network control stack. The attackers could remotely control the asset in the same way a legitimate agent would. Because of the kernel level access that the malware provided, an agent would have reported that the operating system was acting normally and that the asset wasn’t communicating over the network but a network control view would have shown the command and control traffic.
Sometimes the weaknesses that degrade the reliability of an agent are actually a clever misuse of a legitimate feature of the operating system like the very recent “Atom Bomb” code injection attack, which allows an attacker to run arbitrary code at the kernel level. With full control over the asset, an attacker could manipulate what information an agent sees (Analyst: “Is port 8888 open?”; Compromised Asset: “No it’s not!”), changing the agent’s configuration (“Open port 8888, please and thank you!”), or killing the agent entirely so it can’t enforce policies or provide visibility. Controls inserted at the network fabric level simply can’t be attacked in this way.
Windows is not alone. Linux has recently suffered severe issues that introduce holes in an agent-based security strategy, too. CVE-2016-5195, which has been called “the most serious Linux local priv esc ever”, allows a similar means of control over the operating system at the kernel level. Even worse, this particular issue existed in the operating system for 9 years (research shows linux critical severity issues exist in the OS for an average of 5.2 years before they are discovered and fixed!) Agents depending on the integrity of things like iptables could be manipulated or subverted entirely. Again, any utilization of this vulnerability by an attacker could be invisible to an agent but a network view of the data center would show the attacker path - where an attacker came from and where the attacker went next. Since the controls are decoupled from the assets, it would also be possible to entirely stop, or degrade, the exploitation of the vulnerability in the first place.
The data center’s entire attack surface is vast, with holes that start with trivial account access issues to emerging critical vulnerabilities that enable full control at the kernel level. As we look ahead, there are new realms of ingress and risk that aren’t fully understood yet and need to be addressed.
One of my favorite brain teasers goes something like this: You are in front of two doors with two guards. The guards say “one of us always tells the truth, one of us always lies. Only one door leads to freedom. You can only ask one of us one question to gain your freedom. What is your question?” This simple puzzle might keep your mental gears turning for a while - you certainly wouldn’t want to pick the wrong door.
Similarly, our data center might comprise thousands of guards in front of thousands of doors - our agents and assets. The key question to ask: Which of these can be coerced to lie, and which ones can’t? Agents or the network itself? While we certainly get to ask more than one question to our agents, we can see that a reliable answer might not always be guaranteed when we rely on these agents for our security.