Cloud concerns
Many organizations use some form of cloud infrastructure. In fact, according to IBM’s “Cost of a Data Breach Report 2022,” 72% of respondents use cloud infrastructure somewhere within their organization’s IT operating model. The same report found that data breaches occurred within the cloud 45% of the time – nearly half of all compromises. The most common technical failure in these breaches? Misconfigurations. Customer errors in configuring cloud environments were the third most frequent initial access vector. On average, these incidents cost organizations $4.14 million. And according to Snyk's 2022 “State of Cloud Security” report, 58% of respondents see this threat increasing over the next year. While cloud providers offer a range of security controls, such as Amazon Web Services™ (AWS) hardening, Microsoft Azure™ cloud security, and other cloud controls, most cloud incidents occur due to user error rather than due to platform weaknesses.
Given the complexity of cloud environments, exacerbated by differences across cloud vendors, it is easy for organizations to make small, nearly invisible mistakes with staggering costs down the line. Luckily, red teams have an ace up their sleeves: an attacker's mindset. By leveraging the same tools and techniques of real-world threats, red teams can intercept and remediate misconfigurations before any damage is done. This support empowers and guides the blue team toward discovering lurking risks and "unknown unknowns."
Privilege escalation from the attacker’s point of view
One of the most perilous consequences of a cloud misconfiguration in an AWS environment is privilege escalation. Approaching the concept of privilege escalation from the perspective of an attacker offers insight and helps organizations identify and close security gaps.
Privilege escalation refers to the stage of an attack when an attacker moves from an unprivileged user account to one with greater permissions, such as an administrator or root account. In other words, privilege escalation is the critical point at which an attacker goes from having minimal control over a system to having dangerous levels of control. Accordingly, the Open Web Application Security Project’s Top 10 document considers privilege escalation, or broken access control, as the number one web application security risk.
Cloud privilege escalation and IAM in an AWS environment
Any conversation about permissions in AWS will generally focus on identity and access management (IAM). IAM is not exclusive to AWS, but IAM is central to all conversations about AWS security. The critical role of IAM in AWS access control makes it a major attack surface, as demonstrated by Bishop Fox's "IAM Vulnerable" test environment, the 2019 Capital One breach, or even the recent leak of the Transportation Security Administration’s No-Fly List in January 2023.
IAM in AWS revolves around the interactions between principals and resources. Critical terms as defined by AWS documentation include:
- Principals. Principals are human users or machine users that can request an action on a resource.
- Resources. Resources can be any AWS object, such as servers, storage locations, or even users.
- Actions. Actions can include viewing, editing, creating, or deleting resources.
IAM weaves authentication and authorization between the actions principals would like to take and the resources being acted on. For example, following the principle of least privilege, most users in an organization shouldn't have permission to edit the entire company's financial records, nor should most users be able to view customer payment information. But the finance department should probably be able to update the financial records, and billing services will need access to that payment information.
Privilege escalation typically occurs when the relationships between principals and resources are overly permissive. CyberArk, an identity security company, coined the concept of "shadow admins" to refer to accounts that effectively hold administrator permissions whilst remaining inconspicuous: "Despite the appearance of limited permissions, a Shadow Admin with just a single permission has the ability to gain the equivalent power of a full admin."
To illustrate the concept, let's explore how red teamers would leverage a shadow admin in an AWS environment.
Shadow shenanigans
Building on the idea of shadow admin accounts, Rhino Security Labs published a list of 21 possible privilege escalation paths within AWS environments, which includes an example shadow admin path that results when two IAM privileges are paired together, specifically iam:PassRole and ec2:RunInstances.
First, let's examine what these privileges allow you to do. With iam:PassRole, a principal can pass a predefined role to a resource; this privilege is often necessary for setting up new services. With ec2:RunInstances, a principal can launch a new Amazon Elastic Compute Cloud™ (EC2) instance, essentially a host in the cloud.
Consider this sample attack scenario: An attacker has successfully phished valid credentials from an intern, Bob. The company Bob works for has followed the principle of least privilege, and as an intern, Bob's privileges are indeed least. Last month, however, he was tasked with creating a new server that would send customers a coupon on their birthdays. To fetch a customer's birthday, the server needed to communicate with an S3 bucket containing customer information. Bob's security-conscientious manager, Alice, knew that Bob shouldn't have direct access to that data. Instead, she gave him the iam:PassRole permission, allowing him to pass a role called "s3admin." This allowed Bob to configure the new server so that it had access to the S3 bucket without him ever assuming the s3admin role himself.
Or at least, supposedly he wouldn't have it. The attacker, however, recognizes a path to privilege escalation. In fact, only four steps are required:
- Launch a new EC2 instance with the s3admin role
- Copy a new secure shell (SSH) key to the EC2 instance
- Push SSH into the instance as the default EC2 user
- Query the EC2 instance for its assigned credentials, such as s3admin
The attack path
By the end of these four steps, which could be accomplished in just a few minutes, the attacker has acquired credentials for the s3admin role and is able to dump the entire contents of the customer data bucket.
The attacker’s toolkit
To carry out this attack, red teamers could use Rhino Security Labs' Pacu. Let’s demonstrate usage of Pacu within Bishop Fox’s IAM Vulnerable test environment. Pacu self-describes as an AWS exploitation framework, containing an array of attack modules for reconnaissance, privilege escalation, and back-dooring. Pacu contains an "iam__privesc_scan" scan module, which identifies users within an AWS environment possessing shadow admin privileges.
For example, to detect the scenario described here, one could run the following command:
When run without the --scan-only flag, Pacu also offers auto exploitation:
And here, the red team has successfully hijacked a privileged role:
Remediating and mitigating cloud privilege escalation
The attack scenario could have been avoided by further limiting Bob’s permissions. For example, Bob could have been given a more limited role to pass, or, alternatively, would not have been able to create an instance for which he had the ability to query credentials. Notably, however, Alice tried to implement the principle of least privilege, but made an error based on a limited understanding of cloud nuances. While there is no replacement for cloud expertise, blue team tools exist for detecting and responding to AWS security misconfigurations.
For example, see Palo Alto's iam-deescalate, which uses Pmapper to build a node-based graph of principles and permissions to identify privilege escalation vulnerabilities. Helpfully, iam-deescalate also suggests precisely which permissions should be revoked to remediate the vulnerability in question.
Here’s an example of iam-deescalate listing privilege escalation risks:
For more conventional tooling, Splunk used findings from Rhino Security Labs and Bishop Fox to develop detection queries specifically tuned toward detecting privilege escalation in AWS environments. They offer a collection of relevant searches in the form of an “analytic story” with general detection documentation.
Strengthening the cloud environment
In addition to mitigating the risk of privilege escalation, organizations should strengthen their cloud environments and overall security controls. Implementing and enforcing separation of duties, applying the principle of least privilege, requiring multifactor authentication and complex password controls, reducing administrative accounts, encrypting data at rest and in transit, and geoblocking devices and access outside of approved locations are some steps that can help shore up security.
Organizations should also continually evaluate their cloud security controls to stay current with security best practices. The implementation of a continuous monitoring strategy aids organizations by keeping up to date with the release of new cloud security controls. Strategies include:
- Monitoring new product and software releases from cloud providers, typically via email
- Periodically evaluating best-practice configurations and benchmarks released by authoritative vendors such as the Cybersecurity and Infrastructure Security Agency and the Center for Internet Security
- Integrating security control evaluations for new or major enhancements within the project management office
Closing the gaps
The many complexities involved in protecting cloud resources can be daunting, particularly for organizations without domain expertise. However, by relying on both red and blue team strategies, organizations can proactively identify and close security gaps.
