Hitting PaaS on Inadvertent Cloud Database Exposure
As we hit the third installment in our Top 10 Cloud Attack Killchains series you’re probably starting to notice that none of these attacks take a rocket scientist to pull off. If you’ve read the first two posts, but the time you finish this one it will be blazingly obvious that these attacks are enabled due to complications of visibility and control, not complexity. Don’t worry, a couple of the killchains require a more sophisticated attacker, but fewer than we’d like.
The massively scaling nature of cloud deployments is itself a complicated security management challenge – that’s actually the larger point driven home by these examples. Unlike dealing with an unknown vulnerability or malicious insider, most leading cloud security problems can be attributed to a lack of proper oversight and simple configuration errors.
The upside is that most of these issues can be effectively tackled through use of best practices and supporting tooling. If you’re looking for more information on the former, I’d highly recommend the Cloud Security Alliance. There’s a ton of great information resident in the CSA’s research library and it has been a guiding influence on my work (and we’ve contributed a lot to it ourselves).
Our killchain for today is another simple one we see all the time- Compromised Database via Inadvertent Exposure. There are actually two attack paths here; one taking advantage of misconfigured network security, and the other a misconfigured cloud management plane.
As with the issue of Compromised Server via Exposed Remote Access Ports, the problem is that when developers are running fast spinning up services in support of their pressing objectives, it’s easy to overlook some path to an underlying database open to the Internet, or on a subnet. Or a non-network PaaS is given overly-open permissions. Both are scenarios of expediency winning out over caution.
Image 1 – Attack Parameters
In terms of the related killchains, in this instance we see two unique but parallel paths. The first scenario, which we see all the time, is a database that’s merely exposed by a common port. Again, this is very similar to the Compromised Server via Exposed Remote Access Ports example. Like an overly permissive firewall policy, a lack of insight into the configuration leaves you open to attack.
The second, more interesting example, involves Platform as a Service (PaaS) database exposure. In this case the oversight often involves a developer mistakenly failing to uncheck a “make it public” button while creating new services. Or, it may involve overly permissive IAM settings around the involved APIs. There are literally tons of these exposures.
Image 2 – Two Parallel Killchains
From standpoint of an attacker, in the first scenario, the common method is to locate an Internet-facing database, perform privilege escalation and then move to steal data. In the PaaS scenario, the involved techniques are a little more complicated, as once the attacker get in they’ll need to operate more on the cloud management plane.
While getting their hands on the needed credentials relates directly to the first killchain we discussed in this series – Static API Credential Exposure to Account Hijack – execution usually involves a few more steps. Namely, rather than directly assailing the involved database, it’s often easier to create a snapshot and make that public to go ahead and attempt data exfiltration. Rumor is this is the favorite of one particular APT group.
Image 3 – Mitigation Killchains
Again, mitigation and prevention of these scenarios centers on best practices, largely around continuous assessment and guardrails. From implementing and enforcing more stringent security group rules, setting up Service Control Policies or Azure Policies to prevent public exposures, to ensuring appropriate vulnerability management, and invoking database and IAM least privilege practices, much of the involved risk can be effectively addressed.
For common database port exposures, you simply have to maintain rigorous testing; you’re not going to catch everything, but consistent monitoring goes a long way. However, in the case of the PaaS scenario, simple security group configuration assessments or port scanning won’t necessarily help you locate the risk. These approaches miss exposed public snapshots or storage accounts. You’ll need to utilize some of the more intensive assessment tools, and there are a lot of them, including DisruptOps and tools from your cloud provider.
In terms of proactive prevention, within AWS, you need to focus on proper setting of configuration rules and service control policies to limit public exposure, along with practicing least privilege IAM.
In Azure, when utilizing the network group policies, we’d recommend use of the available detection controls around any IP address that is not coming from your tier accessing your [SQL] PaaS. Proper ACL whitelisting also helps ensure authorized path and avoid cloud piercing – wherein attackers go straight to a particular resource versus taking an authorized path through the front-end services or API gateways.
As my colleague Shawn Harris noted in our RSA presentation, with SQL PaaS, having firewalls configured such that authorized path is being actively enforced is very beneficial in preventing this scenario. And watch any sort of guest access in your Azure RBAC.
So there you have it, another pervasive cloud security issue addressable via relatively straightforward best practices. However, we here at DisruptOps clearly recognize, the real challenge is in gaining an ability for your security organizations to scale these practices, if not issues of outright complexity.