How a Recent AWS Information Leakage Vulnerability May Be Putting Your Data at Risk

A recent AWS information leakage vulnerability may put your digital information at risk of exposure.

Palo Alto Networks recently released information discovered by Unit 42 researchers that outlined the discovery of an information leakage vulnerability associated with AWS Resource-Based Policy application programming interfaces (APIs). The report listed 22 APIs across 16 different AWS services that could be exploited, causing leakage of sensitive user and roles data in AWS accounts.

Commonly used AWS services exposed to this vulnerability include Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS), and Amazon Simple Queue Service (SQS). Exploiting this vulnerability can allow threat actors to obtain sensitive information including a list of users and roles associated with your AWS account. With that information, the threat actor can launch targeted attacks against your AWS infrastructure, including but not limited to, resource enumeration, Lambda function invocation, and remote code execution via identity access management (IAM) role assumption.

In an effort to simulate a successful exploit of this vulnerability, Unit 42 researchers conducted a white hat penetration test for a customer armed with the credentials related to a developer’s role they were able to successfully compromise a customer’s AWS account. The testers were able to obtain admin permissions to the account. The researchers were able to show proof of compromise by obtaining user credentials, code repositories, and even located further misconfigurations across both the development and production environment. That level of compromise had the potential to cause harm to the customer, including but not limited to, stealing sensitive customer data, altering server-side code, and wiping out the customer’s entire infrastructure.

How does this matter to your organization?

AWS security is structured around a shared responsibility model dividing the security responsibilities between the cloud service provider and the customer. AWS is typically responsible for securing the infrastructure of the Cloud including the hardware, software, networking, and facilities that run cloud services. The customer is responsible for data “in” the cloud. The “in” the cloud scope is determined by the purchased services.

For example, a service such as Amazon Elastic Compute Cloud (Amazon EC2) is categorized as Infrastructure as a Service (IaaS) and the customer would be responsible for performing all of the security configuration and management tasks associated with that service such as management of the operating system (including updates and security patches), any application software or utilities installed on the instances, and the configuration of the security group on each instance. For managed services, such as Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data. For managed services, the customer would be responsible for managing their data (including encryption options), classifying their assets, and using IAM tools to apply the appropriate permissions.

What does this mean for information leakage vulnerability?

In examining the Unit 42 exploit, the vulnerability was in the AWS controlled, backend infrastructure that falls under the AWS portion of the shared responsibility model. The technical details related to this attack are associated with the AWS process to validate the resource-based policy creation requests.

If the API call to create a policy contains an invalid principle, an error message is returned. Threat actors can use this as a means to identify valid users and roles in the customer’s account by repeatedly invoking these requests to span a wide range of possible principal inputs. The targeted account will have no indicators of attack as the error messages will only be visible to the attacker’s account.

A best practice would be to give a generic error message indicating the policy could not be set and redact any further specifics to the reasoning for the error. Since AWS manages the error reporting configuration the customer has no control of controlling this vulnerability.

What can you do to address the vulnerability?

Since AWS controls the infrastructure that is vulnerable, what can you do as the customer to limit the risk associated with this vulnerability? There are system hardening efforts that we, as customers, can undertake to minimize our exposure to this attack such as:

1. Shrink the attack surface by removing unused or no longer used users and roles. This will minimize the number of user accounts that pose a risk of compromise.
2. Add complexity to user/role identities to protect against the automated enumeration efforts of the threat actor. This can be random characters or any combination of obfuscation similar to salting hashes. This will make it difficult for the threat actor to use exploit attempts such as password cracking to exploit an identified user account.
3. Use IAM identity providers to reduce the user information obtained by the threat actor by managing your user identities outside of AWS. This allows your external users to sign in with corporate user directory or with 3^rd party providers like Amazon, Facebook, or Google. You can give those external identities permission to use AWS resources in your account.
4. Proactively monitor all the identity authentication activities. An example of this would be to create a CloudWatch rule to detect and Alert on the identified vulnerable API calls.
5. Enable two-factor authentication (2FA) for every user and IAM role. MFA adds extra security requiring users to provide unique authentication specific to something they “know” or “have” in their possession. This will protect the user account identified by the threat actor’s enumeration attempts being compromised by means of password cracking or social engineering a password guess.

How do you know if your security configurations are adequate to protect you against these types of vulnerabilities? If you wanted to take a proactive approach to testing your security posture against a possible user account mapping incident you could manually test your exposure to enumeration attempts with a well-known open-source AWS exploitation framework.

Let us know if would like to hear more about how we can help secure your cloud infrastructure feel free to reaching out to me directly at cphipps@uncomn.com or UNCOMN at info@uncomn.com.