Table of Content:
Cloud platforms are becoming extremely commonplace and popular due to the immense proportion of flexibility, scalability, and security that it provides over conventional platforms. The global cloud revenue was forecasted to reach $474 billion by the end of 2022, up from $408 billion in 2021. Gartner researchers predict that cloud revenue will overtake non-cloud revenue in relevant enterprise IT industries during the next few years.
Cloud-based enterprise data attracts security concerns from both outsiders and insiders within enterprises due to the magnitude of the target. A company could lose millions of dollars in revenue but also expose confidential consumer data to nefarious individuals. But who owes responsibility for the security of the information stored on the cloud?
Amazon Web Services(AWS), a popular cloud-service provider, has drawn a line in the sand on how far it will go to monitor and control security and compliance on behalf of its customers. To hold customers liable for closing the data security loop in their settings, AWS developed a shared responsibility model.
Amazon Web Services cannot guarantee complete security and compliance on its part, they have a Shared Responsibility Model. AWS and the customer share the security related to the application, DBS, infrastructure, network, and all other related paraphernalia.
To assure accountability, the Shared Responsibility Model is a paradigm for cloud security that prescribes the security responsibilities of cloud service providers and consumers.
Businesses' most significant problem is the misalignment of duties that might compromise security. This uncertainty creates a blind spot for hackers to exploit. Amazon Web Services created the AWS Shared Responsibility Model to define roles and provide clarity.
In this model, AWS undertakes the "Security of the Cloud," which includes safeguarding the infrastructure that powers all of the services provided by the AWS Cloud. The facilities, networking, hardware, and software used to run AWS Cloud services make up this infrastructure.
AWS has its physical devices and hardware in data centers across 20 countries and they take care of its security, such that no physical attacks on these data centers can happen, like fire accidents, unauthorized personnel access, etc. They ensure this by providing sufficient power backup, coolants, security persons, Biometric scanners, etc.
Apart from this, AWS also takes care of the following:
The customer's responsibilities towards ensuring cloud security include managing the guest operating system (including updates and security patches), any application software or utilities they install on the instances, and the configuration of the AWS-provided firewall on each instance when they deploy an Amazon EC2 instance.
Customers are also responsible for the following:
As per a recent survey, 79% of businesses have reported at least one cloud data breach; even more concerning, 43% have reported 10 or more breaches.
Given that 92% of enterprises presently host at least some of their IT environment on the cloud, the bulk of all businesses today have been breached.
It's easy to blame the cloud provider when there is a data breach, but through the AWS shared responsibility model, AWS also puts the onus of security on the customer. Cloud providers and users are both accountable for cloud security.
To better understand this concept, we can study the data breach that occurred in the financial institution Capital One.
System hacks involving cloud-based data are common. The Privacy Rights Clearinghouse (2021) reports that since 2010, there have been hundreds of data breaches. These breaches have affected every area of the US economy, including retail, health, the banking industry, and even local governments.
One similar incident happened at Capital One in 2019. Capital One specializes in financial accounts, auto loans, and credit cards. It stored financial and private information about its clients on AWS, which served as its cloud computing platform.
More than 100,000 Social Security numbers, bank account information and millions of credit card applications from US and Canadian users were exposed by the Capital One data breach. Applications and accounts from 2005 to early 2019 were exposed. The breach revealed names, addresses, dates of birth, credit scores, and transaction data. The AWS systems that a threat actor hacked housed all the information exposed in the breach.
A cloud firewall configuration vulnerability was one of the reasons for the compromise, which Capital One claimed had subsequently been remedied. Between March 22nd and 23rd, 2019, the unauthorized access occurred when an attacker took advantage of a firewall configuration error that allowed commands to get through to the vulnerable server.
The attack started on March 22-23 and took almost four months to be detected (July 19). At first, reports suggested that a zero-day attack had been deployed. A former AWS worker was ultimately detained for the data breach and charged with utilizing a server-side request forgery (SSRF) assault against the AWS infrastructure housing Capital One's customer data. Without a doubt, Capital One's market value and image were damaged.
What Happened
The company specializes in credit cards, car loans, and financial services. It was using AWS for cloud computing services to store clients' financial and personal data.
In 2019, the Capital one breach disclosed over 100,000 SSNs and nearly that many bank account numbers, along with millions of credit cards application from American and Canadian citizens.
An enormous amount of sensitive information such as name, address, date of birth, credit scores, and transaction data was exposed in the breach.
Key Events
The breach happened between March 22-23, 2019, and was detected after four months on July 19, 2019. It was initially termed a “Zero-day attack."
A zero-day attack means that the flaw was exploited recently. The system was compromised due to this initial flaw, and the developer has no immediate resolution as he is unaware of the attack and mitigation for it.
AWS employee was arrested for data breach and was accused of using SSRF - Sever side request forgery against the AWS infrastructure.
What did the customer do?
Even though Capital One fixed the SSRF issue and offered credit monitoring and identity protection for affected users, customers filed a lawsuit against Capital One, AWS, and GitHub.
Flaws in Capital One’s AWS ecosystem
As said earlier, the SSRF attack against its system hosted by AWS was the cause of the breach. An SSRF attack might cause the server to connect to internal-only services within the organization's infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials. These attacks can lead to unauthorized access to data within the targeted organization.
What was lacking in AWS?
The attacker connected to a targeted Capital One EC2 instance (AWS compute infrastructure resource) and accessed the AWS metadata service to obtain temporary login credentials via the Identity and Access Management service. The attacker was then able to download information stored in AWS.
Curl http://<ec2-ip>/latest/meta-data/iam/security-credentials/<ec2-role-> -H ‘Host:169.254.169.254’
Here we get the ec2 credentials which should not have been displayed.
Remediations
There are several configuration changes or technical implementations to prevent SSRF attacks, such as validation techniques to request the targeted application or server. AWS recommends implementing Instance Metadata Service (IMDS) version 2 from AWS. IMDS provides access to temporary credentials(those that are frequently rotated)
Background information on IMDSv1 and IMDSv2
We can only retrieve metadata of an EC2 instance from within the instance. Metadata can include identity credentials, IAM, metrics, public keys, security groups, and much more. This information is pretty sensitive and can easily be accessed if someone gets hold of the instance.
Problem with IMDSv1
Solution with IMDSv2
IMDSv2 is a new recommended security best practice to enable on your instances. It provides another layer of security to access your instance metadata.
Take Away
The Capital one breach highlights the need to properly assess the use of a public cloud storage provider and to ensure compliance with all security standards involved in its deployment.
AWS indicated, in the information provided to KrebsOnSecurity, that the problem stemmed from the poor configuration of the WAF, and not from the company’s infrastructure. AWS also highlighted the services it offers clients to mitigate possible risks like the ones in this case: Access Advisor, GuardDuty, the AWS, WAF (which, according to Amazon, would detect SSRF attacks), Amazon Macie (which detects, classifies and protects sensitive data).
After the data breach incident, Capital One immediately fixed the SSRF vulnerability leveraged in the attack.
The experts at We45 have proposed a security solution that companies should embrace to prevent such data breaches in the future:
AWS Web Application Firewall (AWS WAF) aids in defending against bots and common web attacks that might impair availability, jeopardize security, or use excessive resources. You can develop security rules with AWS WAF to regulate bot traffic and prevent widespread attacks like SQL injection and cross-site scripting (XSS). Its use cases include filtering web traffic, preventing account takeover fraud, and administering AWS WAF with APIs.
In AWS, the Instance Metadata Service (IMDS) offers "data about your instance that you can use to configure or manage the running instance. Instance metadata is divided into categories, for example, hostname, events, and security groups." Capital One used IMDSv1 during the 2019 breach, which used the request/response method. To decrease the danger of SSRF in the EC2 metadata service, AWS has implemented a solution called "session-based requests." The new service is designated as IMDSv2.
IMDSv2 requires session authentication for every request. A session starts and finishes a sequence of requests that the EC2 instance uses to obtain locally-stored metadata and credentials. A session begins with an HTTP PUT request to IMDSv2. IMDSv2 returns a secret token to EC2 software, which uses it as a password to obtain metadata and credentials. IMDSv2 never stores or retrieves the token; therefore, a session and its token are deleted when the process using it ends. Session tokens can only be used from the EC2 instance where the session originated for enhanced security.
To better support the new IMDSv2, AWS has also upgraded the existing SDKs and CLIs (Command Line interface). These new modifications defend against misconfigured-open website application firewalls, reverse proxies, unpatched SSRF vulnerabilities, and misconfigured-open layer-3 firewalls and network address translation.
To mitigate SSRF vulnerability, an application, not the underlying host, must be hardened. However, preemptive security controls can be implemented on the host server, like an AWS EC2 instance, to limit the blast radius in the event of an SSRF breach, as with the Capital One case.
You may enable your AWS account's operational and risk audits, governance, and compliance with AWS CloudTrail. The actions that a user, role, or AWS service has carried out are known as events in CloudTrail.
Examples of possible events include the AWS Management Console, AWS Command Line Interface, and AWS SDKs and APIs.
When you first create an AWS account, CloudTrail is already enabled. A CloudTrail event is created each time something happens in your AWS account. Selecting Event history in the CloudTrail console will allow you to quickly view recent events and logins. Create a trail to keep track of events and activities in your AWS account over time.
Performance, security, and scalability offered by an object storage service known as Amazon Simple Storage Service (Amazon S3) are unrivaled in the industry. Any quantity of data can be stored and protected by customers of all sizes and sectors for practically any use case, including data lakes, cloud-native applications, and mobile apps. Using cost-effective storage classes and simple administration tools, you may reduce expenses, organize data, and set up precise access controls to satisfy unique business, organizational, and compliance requirements.
Today, cloud infrastructure has become extremely commonplace, but cloud security breaches have also grown in tandem. Once customers know the AWS Shared Responsibility Model and how it pertains to cloud computing and cloud security, they must assess how it applies to their specific use case.
By looking into the Capital One breach, we could learn that the organization had misconfigured a software application that was installed. And as per AWS' shared responsibility model, customers must safeguard anything they operate in the cloud. Capital One's security team was also unaware of any unauthorized identities that were used to gain access to the AWS Management Console. The hacker could penetrate the environment due to this lack of awareness. Organizations using AWS should use AWS Identity and Access Management to monitor and maintain access control.
Customers' responsibilities vary depending on various factors, including the AWS services and Regions they select, the integration of those services into their IT ecosystem, and the rules and regulations that apply to their business and workload.
AWS is constantly upgrading its infrastructures and initiating policies like Shared Responsibility Model to tie every loose end, plug loopholes, and provide a wholesome experience to the end-users and businesses. To make the most of the offerings by AWS, you can learn more about AWS security courses on AppSecEngineer.
Rajesh Kanumuru works at we45 as a Cloud Security Lead. Rajesh is a builder and breaker of Cloud applications. He has created some pioneering works in the area of Cloud Security. He is actively researching the effects of emerging technologies on cloud security. Since 2020, Rajesh has mostly been involved with research, development and building solutions around we45 and AppSecEngineer's training offerings. He consults with organizations to help them implement Cloud Security successfully. Rajesh has co-authored and trained a course on Purple Team AWS that was delivered by we45 at BlackHat USA. When AFK, he can be found on the cricket pitch.
Contact Support
help@appsecengineer.com
1603 Capitol Avenue,
Suite 413A #2898,
Cheyenne, Wyoming 82001,
United States
.svg)
.png)
.png)
.png)
.png)
