Your Vulnerabilities are Making You Miss Your Misconfigurations

IT organizations regularly configure asset discovery tools in ways that leave them open to abuse by attackers; Vendor configuration documentation lacks details on the risk.

By Evan Anderson, Director of Offense, Randori

The security industry pays lots of attention to vulnerabilities and the need for patching. While there is a need for this, the industry has over-indexed on vulnerability management in the past couple decades. What doesn’t get as much attention, and is often more important to an attacker, are things like common misconfigurations or an improper implementation that introduces unintended risk.  I can say with confidence that some vendor-recommended implementation strategies are widely abused by red-teamers and attackers to achieve their objectives. I’ve been taking advantage of these types of flaws since the early 2000s, and it’s so common that red-teamers developed tooling to take advantage of faulty configurations.

At Randori, we regularly see improper implementations,suggesting many blue-teamers are unaware of the risks of certain configuration methods.  Vendor documented implementation methods — that are commonly used by IT orgs — can introduce unintended risk into your environment. And the challenge is that improper implementations can be near impossible to spot, and even more problematic to fix.

Let’s take a closer look at this problem, using asset discovery tools as an example — specifically ServiceNow Discovery.  Organizations have rightfully started using auto discovery tools in order to find services, applications, and devices to mitigate the exposure of misconfigs before attackers can take advantage of them. These tools give companies a better understanding of what systems are on their network, their patch level, and how the systems are configured. Discovery tools programmatically log into systems and run commands to check their configuration.

Unfortunately, asset discovery tools can themselves be improperly configured. This will increase risk to an organization rather than reducing it.

Before I go on, a note: ServiceNow Discovery is not vulnerable or bad, nor is Virima or BMC Helix Discovery (other asset discovery tools that suggest similar implementations), it’s simply a concrete example recently used by my team. The problem: When ServiceNow Discovery, BMC Helix Discovery or Virmia are configured with password credentials rather than a private key, they can easily be taken advantage of by an attacker.

It’s low risk to use this weakness to for a multitude of reasons:

1. I don’t have to make an exploit (which is expensive and takes time)
2. I can just sit on the network and it will give me credentials – I don’t have to do any discovery or port scanning.
3. I won’t trigger an alert. In many cases alerts associated with discovery tools are ignored or disable because they are considered benign (and with good reason).
4. I don’t have to brute force entry (which could trigger alerts).

“Discovery” explores UNIX and Linux devices utilizing SSH to execute commands on the system in question. In order to run the exploratory commands, “Discovery” must have some sort of credential in order to access the system. ServiceNow’s documentation has two ways to configure these credentials. One is username and password — the other is via an SSH key. It is more secure to use SSH private key credentials rather than an SSH password, but password credentials are often preferred because they are easier to configure. In fact, the ServiceNow Discovery documentation does explicitly state: “SSH private key credentials are recommended over SSH password credentials for security reasons.” However, it doesn’t go into detail.

ServiceNow Discovery Documentation

People use passwords more than private keys because of the ease of deployment. Simply add an account to the system with a password and you’re in. Private key authentication has the extra steps of generating the key pair, protecting the private key, and copying the public key into place on the server systems.

Capability in Action

Let’s assume then as the attacker, I have gained access to a network by compromising a Linux system and am looking to move laterally to other systems. I begin by quietly observing or sniffing the network traffic with the goal of gaining situational awareness attempting to figure out what I can see and what I have access to.

While watching network traffic, I notice an IP address attempting to connect to my compromised system on TCP port 22 (the default port for SSH servers.) So I know somebody or something is attempting to login via SSH. I quickly spin up an SSH server I control and wait.

Often the username for these types of asset discovery tools references the product in some way. For instance `ServiceNowUser`. Just armed with that information, I know those credentials likely work on other *nix systems (UNIX, MacOS, FreeBSD, linux), and users are trained to ignore logins from that user.

Now I’m off to the races — I can steal leaked credentials and move laterally to other systems on the network, with little operational risk. And credentials are often used to verify patch states and system configurations, thus I have access to that data on each system, giving me a lot more information to do my job easily and stealthily.

For anyone implementing a new technology considers taking the extra time to configure using a private key vs. a password (more on the advantages here). Review documentation thoroughly and pay special attention to best practices. Ask your vendor to give more details on security best practices if they aren’t included in the documentation. Some configurations may be quick wins for a project, but be careful you aren’t inadvertently giving away the keys to the kingdom. The details are important to understand what risk you are accepting.

Any software that is used on a network should be viewed as part of the attack surface, and thus must be considered when calculating risk. Purchasing a tool is not the solution to the problem, and may in fact cause more harm than good. You must allow teams the time to understand the ramifications of a product, how to properly implement and how to utilize tools properly in your environment. Recognize the risk you’re taking if you’re asking your team to implement something on a shorter timeframe — that often means not as secure.

About the Author

Evan Anderson is the Director of Offense at Randori – where he leads the company’s Hacker Operations Center. In this role, Evan leads a team developing new and novel offensive capabilities for Randori’s automated attack platform.

Evan can be reached online at linkedin.com/in/attack/ and at www.randori.com