By Thyaga Vasudevan - VP of Product Management, Skyhigh Security
March 22, 2022 5 Minute Read
Moving to a cloud-native architecture for your enterprise applications can deliver tremendous business value, adding scale and agility while off-loading onerous tasks like patching and upgrading server infrastructure.
However, in every cloud environment, whether Amazon Web Services (AWS), Azure, or Google Cloud, there is a new category of risk. Cloud-native threats stem from the new context and configuration requirements you have in a cloud environment. Historically, default settings like public access to storage objects have left sensitive data out in the open, easy to steal by anyone crawling for these weaknesses.
It’s easy to make mistakes in a new environment, with new settings introduced continuously as new capabilities are added by cloud providers. The configuration of your cloud environment is always your responsibility. AWS and others have no control over how you use their services. They are a template for you to build from.
Not understanding the outcome of your configurations and how you build cloud-native applications can have catastrophic consequences. And even the savviest cloud customers can suffer from these consequences.
Case in point is the breach that Capital One suffered almost three years ago where an attacker had access to social security numbers from 100 million US individuals and social insurance numbers from 6 million Canadian individuals. The attacker used several techniques to get access to the data, but a key learning from the attack was that a security feature designed to protect access to virtual machines – Elastic Compute Cloud or EC instances – added the attacker. The feature is called the Instance Metadata service or IMDS.
Instance Metadata Attacks
Version 1 of IMDS (IMDSv1) was released in 2012 to allow a more secure way for EC2 instances to interact with other AWS services. Instead of leaving AWS keys on the instance, customers could now have the EC2 instance query the metadata service to obtain credentials and make AWS API calls to other AWS services. For example, if an EC2 instance got some customer data, it could use IMDSv1 to store that data in an Amazon Simple Storage Service (S3) bucket. It was this exact capability that the attacker used to pull down sensitive information from an S3 bucket used to store information about Capital One customers.
In our own testing we were able to duplicate how this extraction of data could work in any application. In our example a team of epidemiologists built a cloud-native application in AWS with a public dashboard to visually represent data showing their progress analyzing a virus genome.
During the development phase of this application, the team ran into a challenge. Most of the resources in their Virtual Private Cloud (VPC) were supposed to be hidden from the internet. The only resource in their VPC intended for public view was the dashboard.
The S3 bucket hosting their data needed to stay private. To pull data from S3 to the public dashboard, they added a reverse proxy, acting as a middleman. All it took was a quick Google search, and a few lines of code to add this to their application.
For the team of epidemiologists, the reverse proxy was a basic, elegant solution that functioned perfectly for their use case. What they didn’t realize is that it set them up for a massive breach.
The compute instance running the reverse proxy had been assigned an IAM role with permission to access their private S3 bucket. Credentials for the reverse proxy to access S3 were obtained from Instance Metadata.
An attacker visiting the site and interested in their data noticed the team had referenced the reverse proxy’s IP address in the dashboard. The attacker then checked to see if they could connect to it. After confirming their connectivity, the attacker then checked to see if they could access Instance Metadata through the reverse proxy. Success.
Through the reverse proxy and from the Instance Metadata, the attacker uncovered credentials to the team’s private S3 storage bucket.
Now, with access to the S3 bucket, the attacker could steal highly sensitive data the team had stored for their application. The attacker simply synced the target S3 bucket to their own S3 bucket in another AWS account, and the data was theirs.
This type of attack is just one of 43 techniques described by MITRE in their ATT&CK framework for cloud environments: https://attack.mitre.org/matrices/enterprise/cloud/
How AWS Mitigates Instance Metadata Attacks
To improve the security of this service, AWS released IMDSv2, which adds several new layers of protection.
In IMDSv2, external users are blocked from receiving credentials, allowing only application resources to receive them. Read more about this layer of protection and IMDSv2 here: https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
However, the challenge remains that IMDSv1 still lives on. There’s nothing in AWS that prevents customers from using IMDSv1, and you can still use it by default for all your EC2 instances. Like we mentioned before, it’s not AWS’ responsibility to make sure you’re using the cloud securely. That responsibility falls solely on the customer.
In the attack we just described, the reverse proxy was misconfigured to allow external requests to reach internal resources. If the team had configured their compute instance to use IMDSv2, unauthorized access by the external threat actor would have been blocked.
How Skyhigh Cloud Native Application Protection Can Help
At Skyhigh Security, we have several approaches which can help you detect and prevent attacks like this. Skyhigh Cloud Native Application Protection Platform (CNAPP) is our cloud-native security platform that allows you to monitor and update configurations in AWS, Azure, GCP along with a wide range of additional security measures you can read about here.
Using a direct API-integration with AWS, Skyhigh CNAPP continuously monitors Amazon CloudWatch – an application and infrastructure monitoring service – to indicate which version of IMDS you’re using in every EC2 instance.
When CloudWatch logs an instance actively using IMDSv1, Skyhigh CNAPP generates a security incident, notifying you to update your configuration to IMDSv2, which will prevent unauthorized access to your credentials by external users.
Skyhigh CNAPP policy incidents for IMDS version configuration
It is best practice to enforce IMDSv2 on your EC2 instances for all local code and users. Once you specify that IMDSv2 must be used, IMDSv1 will no longer function. AWS has step by step instructions on how to configure your instances to use IMDSv2 here.
Beyond this attack example, Skyhigh CNAPP allows you to implement a series of best practices to protect your cloud-native applications:
- Continuously audit your configurations. With Skyhigh CNAPP you can scan AWS CloudFormation templates before they enter production, and then detect any “drift” in your configurations over time. This allows you to detect misconfigurations and enforce a least-privilege model for resource permission.
- Enforce Zero-Trust. Use zero-trust as a methodology, where only specific resources are allowed to run and communicate with each other. Everything else is blocked.
- Scan for code vulnerabilities. Particularly with open software distribution models like Docker, it is important to monitor your application resources for vulnerabilities on a continuous basis.
- Detect anomalies and threats. With User and Entity Behavior Analytics (UEBA), you can assess millions of cloud events to uncover anomalous activity and real threats like credential theft.
- Run DLP on storage objects. Just like any other cloud service you sanction, your network, or endpoints, within AWS you can and should classify your data within S3 and run data loss prevention to stop exfiltration attempts.
Get in touch with us to talk about implementing these measures at your own organization.
Back to Blogs