Praetorian’s approach to cybersecurity centers around a core belief that combining innovative technologies and the best people in the business leads to real results. In our experience, neither can fully solve cybersecurity challenges on its own. We therefore have designed our services organization and offerings to blend them seamlessly. We applied the same philosophy when developing Chariot, our External Attack Surface Management offering. AI and Automation are effective, but we knew we needed the human element if we wanted to create something new.
The value of our hybrid approach was particularly apparent a couple of weeks ago. I was working on a penetration test for a long-time client’s cloud platform alongside another Praetorian security engineer. We took a few minutes to discuss some vulnerabilities he had discovered.
The conversation went something like this:
Peter: I heard you found a few vulnerabilities today. What are we looking at?
Engineer: Well, there’s a reflective cross-site scripting vulnerability, an issue related to CSRF token scoping, and the platform isn’t sending some user notification emails.
P: Nice work. What were you thinking of in terms of severity?
E: Well, reflective cross-site scripting is usually medium severity, CSRF token scoping issues are usually low severity, and so are user notification emails. But if you put them together, you can take over someone’s account. That’s high severity, for sure.
P: How’s that work?
E: See, after you exploit the reflective XSS, you can steal one of their CSRF tokens and then use that to add a new API token to the account, which gives you complete control. Since users don’t receive email notifications when you add a new API token, the victim never knows that anything’s wrong.
P: So you take a few vulnerabilities, one is medium severity, and two are low, but you add them together and get something high severity?
E: Exactly.
When we’re hacking on our clients’ products, we see this pretty frequently. It’s one of the reasons why we don’t just rely on CVSS scores to guide remediations. Under a typical vulnerability management plan, the product owner might be accountable for resolving any medium severity vulnerabilities within 60 days. Low severity vulnerabilities might be on a 90-day deadline or even dealt with “as resources allow” (which we all know is business lingo for “never”).
If all we can say about E’s three vulnerabilities is that one is at most medium severity, then nothing will change in the customer’s platform for about 60 days. In this case, that would be a mistake. Somebody needs to break at least one step in the high-risk attack chain as soon as possible.
This leads me to another core belief: as crucial as the vulnerabilities are in our work, they’re not the point of our penetration tests. At least, not on their own. The point is to try to help our customers understand where the most risk is by thinking about overall attack chains: how can we get from your highest-priority attack surface to your most critical assets?
Attack Chains: Greater Than the Sum of Their Parts
This often involves chaining a handful of vulnerabilities together, as in the previous example. The entire attack chain—where it leads, what we could do as we progress along it, and what we ultimately can access at the end of it—is what matters in terms of business impact and overall security for our clients. Sometimes, the chain of vulnerabilities will take us through several technology stack components.
Figure 1 shows another real-world example, this time from a cloud networking appliance that Praetorian tested last year.
Figure 1. An example of a multi-step attack vector exploited by Praetorian.
In this case, Praetorian had access to an administrative shell used by legitimate users to manage their network appliance. The administrative shell didn’t have full privileges, and we wanted to expand our access. Our attack chain of individual vulnerabilities looked something like this:
- We found a command injection vulnerability to run arbitrary commands as a low-privileged user.
- Then, we found a world-readable configuration script that revealed a particularly interesting network listener. This network listener was firewalled from external hosts and could only be accessed locally from the appliance communicating with itself.
- We found a lack of authorization controls on that local network listener allowing us to modify an authentication database.
- After modifying the authentication database, we elevated our privileges on the device so we could perform other destructive operations.
On their own, none of these things would have particularly high severity. (1) lets you run some additional commands beyond the standard set, but none of these commands should hand over sensitive data. (2) might not be considered a vulnerability at all. (3) is potentially harmful, but since it’s not externally exposed, it probably wouldn’t rise to the level of a high-severity vulnerability on its own.
The real problem is that vulnerabilities (1) and (2) give attackers a credible way of attacking (3). We used (3) to overwrite crucial credentials on the appliance and gain full access. After doing so, we could (4) install a backdoor on the device and override all its other security controls.
This is a pattern we see over and over. A handful of lower-severity vulnerabilities add up to an overall attack chain greater than the sum of its parts.
In both examples we’ve shown, the CISO’s vulnerability management dashboard might not show any high severity vulnerabilities. At best, there might be a couple of medium and low-severity vulnerabilities. That’s usually the point at which most organizations prioritize their limited remediation resources elsewhere.
Which Leads Us Back to Technology + People…
The figure 1 example also is a good case study for why automated tools, on their own, aren’t sufficient. Most static analysis tools could theoretically identify (1), assuming your engineers can tune out the false positives. (2) is probably a wash… But I’ve never seen an automated tool that could identify (3), simply because most network scanners work by connecting across the network, and this network listener isn’t accessible across the network. Rather, it is only accessible to an attacker who has already exploited (1) and (2).
Furthermore, most automated tools do not attempt to weave vulnerabilities together and state the value of the overall attack chain. Instead, they attach (at best) a CVSS score to each discrete vulnerability they find. If the worst vulnerability on that list has medium severity, you might be excused for the resulting false sense of security.
This is the point at which most security vendors draw a line in the sand and put the rest of the responsibility on their clients to figure out what really matters. That makes sense to a certain extent, but most security vendors could do a whole lot more to help articulate where the risk really is.
CVSS does support a notion of “environmental” metrics that account for the specific needs of the underlying product. For example, suppose a product has high confidentiality requirements. In that case, the CVSS environmental score can weigh threats to data confidentiality more heavily than threats to data integrity or availability (otherwise weighted equally). However, organizations rarely use this feature, from my anecdotal experience. Additionally, while CVSS environmental scores are a decent tool, they’re only a crude mechanism for adapting vulnerability severity scores to the specifics of the environment in which they exist. They simply don’t try to account for any vulnerability impacting any other vulnerability.
Chariot Applies Our Lessons Learned
Praetorian has over a decade of experience assessing clients’ cybersecurity vulnerabilities, which is why when we developed Chariot we accounted for the existence of attack chains like the ones discussed here. Chariot combines expertise with engineering to find high-risk attack chains even from lower-severity vulnerabilities. If that sounds interesting to you, take a few minutes to check it out.
