Is My Information Secure in the Cloud?
How secure is your data when it’s stored in the cloud? As cloud storage becomes more common on a daily basis, protecting the information is an increasing concern. In this post, we will discuss which are the main threats in a production cloud deployment and how we can prevent or detect them.
Moving the information to the cloud does not mean that it is already safe and secure. You might be familiar with the shared-responsibility model in the cloud. In its simplest terms, it denotes that cloud providers (or CSP) are responsible for the security of the cloud, while users should be responsible for securing their data. So, security is as well a shared-responsibility model.
Image Source: AWS Shared Responsability Model
As can be seen in the image above, the cloud user, as well as all the application and network configurations, are responsible for managing access to data and cloud services. For this reason, it increases the complexity of the user policies and the governance model used.
The truth of the matter is that it is more likely to find permissive policies that give more privileges to the user than those needed, increasing the impact of any compromise, as we are going to see in the next section.
Real Cloud Breach in Detail
We have seen many examples where production cloud environments have been compromised, but we are going to focus on the most recent one affecting Capital One in AWS.
In March 2019, Capital One suffered a cloud breach, where 140,000 Social Security numbers, 1 million Canadian Social Insurance numbers, and 80,000 linked bank account numbers were exposed (see NYTimes ).
In the following diagram, you will find a summary of all the steps involved:
Capital One Breach Phases
As the first step of the compromise, a misconfigured reverse proxy was exposed to the Internet. A reverse proxy server is a type of proxy server that retrieves resources on behalf of a client from one or more servers commonly used to redirect requests to other backend servers not accessible directly from the Internet. So, through this misconfigured proxy, it is possible to make arbitrary requests to other endpoints in the network, which is known as a Server Side Request Forgery (SSRF) vulnerability.
In the case of the Capital One breach, the attacker gained access to a set of AWS access keys stored in the EC2 Instance Metadata service. The Instance Metadata service is a mechanism provided by AWS in order to store information related to EC2 instances. This information can be the instance type, VPC or subnet information, or the credentials used to assume the role attached.
How was the attacker able to access the credentials stored in Metadata? It was possible because the Metadata Service is accessible using the following endpoint only from within the instance:
And using the SSRF vulnerability, the attacker could redirect a request from the Internet to this endpoint, as if the origin of the request was the EC2 instance. Therefore, the attacker is granted access to the Metadata service and obtains the corresponding AWS Access Key.
Architecture using a reverse proxy for internal service
Creating The Environment to Simulate The Cloud Breach
To simulate the breach in our lab environment, we created a vulnerable infrastructure using CloudGoat.
By way of example, we have launched an EC2 instance in our lab account and assigned a role to this instance. This instance has a misconfigured nginx server installed as a reverse proxy. The proxy is used to proxify requests to internal services not accessible from the Internet. It has the following configuration:
Nginx misconfiguration file
The proxy will redirect any request based on the arguments passed in the URL, so the user has control of which domain or parameters are sent by the proxy, as it is shown below:
But if the attacker modifies the request using the Metadata service as it was an internal endpoint, he could access the AWS credentials using, for example, the following URL:
Access to Metadata service credentials through a misconfigured reverse proxy
If we add these credentials to our environment, we can see how it is possible to interact with the account with the privileges assigned to the compromised role, having access to all the information stored in the S3 service.
Access to S3 data using stolen credentials
Cloud Breach Simulation using AIQ Platform
Credential compromise is an important concern for anyone operating in the cloud. The associated impacts vary widely, but as shown in the previous section, it can lead to access and theft of important corporate information. There are many security controls that should be enabled in your cloud accounts but, how do you know if they are working effectively?
In order to understand your security posture, it is necessary to simulate threats continuously to identify if they are detected or not. You can simulate the threat manually, as we did in the previous section, or use a platform that allows you to automate all the processes.
With the AttackIQ Platform, it is possible to automate the process using our scheduled assessments. In this case, we already have a predefined “Cloud Infrastructure Breach” assessment, where we provide the scenarios to simulate a credential theft in your EC2 instances as well as unauthorized access to your S3 buckets.
Cloud Infrastructure Breach assessment
In this execution, the scenario stealing the credentials from Metadata Service and the unauthorized access to S3 are shown as not prevented.
Assessment results
If you have any accessible credential in the Metadata Service of your EC2 instances, the scenario will access them and show the role assigned. In this example, the attacker would have the privileges assigned to the role named “cg-banking-WAF-Role-cgidtvi9sneccn” as shown below:
Credential Harversing through Metadata Service Scenario results
The next scenario will try to download information from S3 buckets using the credentials previously stolen. In its configuration, you can define to which buckets you want to simulate the unauthorized access, or if you prefer, you can download the information from all the buckets accessible using the stolen credentials.
In our example, we are only downloading the sensitive information stored in the bucket with the name “cg-banking-WAF-Role-cgidtvi9sneccn”, and the scenario is able to download all the files stored there.
Download files from S3 Buckets Scenario results
Tracing The Breach
Logs are needed to trace any malicious activity in your cloud account. Bearing this in mind, it is recommended to enable CloudTrail in all the regions.
We have enabled CloudTrail in our region to record any read or write operation done to our monitored bucket with the name “cg-cardholder-data-bucket-cgidtvi9sneccn”.
Enable logging for a S3 bucket
Through CloudWatch , we are able to look at the CloudTrail logs to verify the bucket interaction carried out by the scenario.
View access logs to a monitored S3 bucket using CloudWatch
With this information, we can now implement some security controls in order to detect any unexpected access to the information contained in the S3 buckets. We will talk about that in the next posts.
Summary
In this post, we’ve shared a way to simulate Cloud threats in an infrastructure in order to generate logs and traces to verify if your implemented security controls are working.
Cloud infrastructures are continuously changing, so there is still a need to automate the process to execute your assessments periodically.
In the next posts you will see how through using the logs triggered it is possible to implement security mechanisms to allow us to detect and prevent this kind of threat.
References
- Cloudgoat:
https://github.com/RhinoSecurityLabs/cloudgoat - AWS Shared responsibility model:
https://aws.amazon.com/compliance/shared-responsibility-model/ - Enabling object-level logs in S3:
https://docs.aws.amazon.com/AmazonS3/latest/user-guide/enable-cloudtrail-events.html - Capital One Data Breach Compromises Data of Over 100 Million:
https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
