Five Common Cloud Security Threats and Data Breaches

15 July, 2021 | 8 Min Read

In November 2020, an outage of Amazon Web Services (AWS) in the us-east-1 region rendered Roomba vacuum cleaners, Ring doorbells, and even Christmas lights dysfunctional for thousands of people in the US. For one full day, popular websites like Flickr, Adobe, and the Washington Post were unreachable.¹

It didn’t take long for people to tweet about the issue :)

My f—ing doorbell doesn’t work because AWS us-east-1 is having issues

I… can’t vacuum… because us-east-1 is down

While this incident might seem funny at first, it is also a true testament of how extremely dependent we are on cloud computing nowadays. In fact, within the last 15 years, cloud computing has become a must-have for almost every company developing or using software.
As an increasing number of organizations rely on cloud services or even start to go full cloud-native, cloud security has become a hot topic in the security community. Unfortunately, the amount of cyber-attacks targeting cloud systems has also increased.

To raise awareness of the threats that lurk in the cloud world, below we present five common security threats in the cloud and illustrate their risks with real-world examples. The five identified threats are based on the Cloud Security Alliance Report Top Threats to Cloud Computing - The Egregious 11², the OWASP Serverless Top 10³, and the Cloud Native Computing Foundation Security Whitepaper⁴:

Cloud-(Security)-Misconfigurations

A leading cause of data breaches are cloud (security) misconfigurations, enabling data breaches, or the corruption of company networks. Cloud resources like micro-services, object and database storage solutions, or networking components are the subject of such misconfiguration. Typical examples of misconfigurations are:

unencrypted data storage
publicly accessible data storage
open SSH or database ports
using default credentials
too open firewall and security group settings
deactivated security controls

Such issues are a concern in cloud environments as in any other architecture. Nevertheless, the fast pace at which cloud infrastructure regularly changes, makes it difficult to find and control these issues. Whereas in traditional applications changes in the infrastructure and assets involved multiple roles and approvals to reach production, the cloud infrastructure is much more flexible and dynamic. Modern technologies and tools for provisioning, maintaining, and changing an infrastructure like Infrastructure-as-Code enable rapid changes in the infrastructure.

The use of multiple cloud providers and the combination of private and public clouds, surely does not make tracking down misconfigurations easy.

Since misconfigurations are easy to make but difficult to spot in complex cloud environments, they are the root cause of several recent and massive data breaches. In the following, we can only present a small subset of data breaches showing the impact of misconfigurations.

In 2018, an unsecured Elasticsearch database of the marketing company Exactis exposed nearly 340 million individual records containing personal information of American adults as well as millions of businesses. The database server was erroneously configured to be publicly accessible.⁵
In 2019, the personal information of thousands of hotel guests including members of the US government and military was publicly exposed due to an open Elasticsearch database of AutClerk, which is a combined reservations system for hotels, accommodation providers, travel agencies.⁶
In 2020, the personal and payment information of 7 million users of the mobile payment app Bharat Interface Money (BHIM) was exposed. The breach was caused by a misconfigured AWS S3 bucket. In fact, user data was stored unencrypted on a publicly accessible S3 bucket, making it vulnerable to misuse for frauds and theft.⁷
In 2020, the companies Advantage Capital Funding and Argus Capital Funding didn’t set up encryption, authentication, or access credentials for their database, which contained highly sensitive financial and personal data. As a result, almost half a million gigabytes of confidential legal and financial documents were leaked.⁸

Over-Permissioned Cloud Resources

Even a simple cloud-native application can consist of dozens or hundreds of micro-services. Each reading, writing, and updating different databases, object storage, data streams, and APIs. A secure orchestration of the micro-services and assets requires a careful access control configuration for each of the resources, which is tedious. However, attackers target over-permissioned cloud resources to escalate their privileges and to gain unauthorized access to other resources in the account rather than having control over these resources directly. Unnecessary cloud resources or excessive permissions on resources are a potential backdoor that can lead to data leakage from not only the over-permissioned resources themselves but also from their related resources. And, in the worst-case, they may even give an attacker full control over cloud resources or the whole account.

An example in which an over-permissioned cloud resource caused a massive data breach is the Capital One hack. In 2019, an attacker gained access to 80,000 account numbers, 140,000 Social Security numbers, and 1 million Canadian Social Insurance Numbers by abusing an over-permissioned web application firewall (WAF).

By abusing the over-permissioned WAF the attacker could craft a Server-Side-Request Forgery (SSRF) attack to steal the data.

The attack involved multiple steps visualized in the figure and described in a report of the MIT⁹, which we cite here:

The FBI and Capital One identified several accesses through anonymizing services such as TOR Network and VPN service provider IPredator, both used to hide the source IP address of the malicious accesses;
The SSRF attack allowed the criminal to trick the server into executing commands as a remote user, which gave the attacker access to a private server.
The WAF misconfiguration allowed the intruder to trick the firewall into relaying commands to a default back-end resource on the AWS platform, known as the metadata service with temporary credentials for such environment (accessed through the URL http://169.254.169.254);
By combining the SSRF attack and the WAF misconfiguration, the attacker used the URL “http://169.254.169.254/iam/security-credentials” to obtain the AccessKeyId and SecretAccessKey credentials from a role described in the FBI indictment as “*****-WAF-Role” (name was partially redacted). The resulting temporary credentials allowed the criminal to run commands in AWS environment via API, CLI or SDK;
By using the credentials, the attacker ran the “ls” command7 multiple times, which returned a complete list of all AWS S3 Buckets of the compromised Capital One account ("$ aws s3 ls");
Lastly, the attacker used the AWS “sync” command8 to copy nearly 30 GB of Capital One credit application data from these buckets to the local machine of the attacker ("$ aws s3 sync s3://bucketone."). This command gave the attacker access to more than 700 buckets, according to the FBI report. ⁹

Insufficient Credential Management

One of the biggest threats to cloud security is human error when handling credentials or sensitive information. Sensitive data like secrets, access tokens, and passwords can be accidentally uploaded to a Git repo, put on a public bucket, or even hard-coded in application code. Since cloud systems are often globally and publicly available, stolen credentials can be easily abused by attackers. Typical examples are:

Insufficient protection of credentials, like encryption
Use of weak passwords
No automatic rotation of keys, passwords, and certificates
No use of multi-factor authentication
Storing credentials in Version Control Systems, Source-Code, or Environment Variables

In 2014, attackers scraped public GitHub repositories for cloud service credentials and hijacked accounts to mine cryptocurrency at other people’s expense. The attackers were able to discover and misuse the cloud service provider credentials within 36 hours of the credentials being pushed to GitHub accidentally.¹⁰

Insecure APIs

Almost every cloud application exposes its services in the form of APIs or UIs. Since they act as the front door of the system, they are attacked and scanned continuously. Thus, the API of each system must follow established security guidelines and all APIs must be protected by adequate means of authentication and authorization.

In 2018, Facebook experienced a breach that was the result of a credential theft vulnerability introduced as a feature back in 2017. This breach affected more than 50 million accounts. Facebook admitted that it didn’t know what information was stolen, nor how many user accounts were compromised.

Using Components with Known Vulnerabilities

This threat is neither bound to cloud applications nor cloud environments, but a general threat every application developer and security expert should be aware of. Nowadays, applications are not re-written from scratch but contain a sustainable amount of third-party/open-source libraries and frameworks to execute the desired tasks. Even for commercial applications easily as much as 75% of the code comes from open-source libraries and frameworks.¹¹ Vulnerabilities in the used (open-source) components are a common risk and attackers target applications that make use of vulnerabilities in included open-source components, as they are easy to exploit - often even publicly accessible exploits exist.

An (in)famous example, which shows the impact of vulnerable libraries, is the data breach of the largest consumer credit reporting agency Equifax in 2017.¹²¹³ Attackers exploited a vulnerability (CVE-2017-5638) in the open-source framework Apache Struts2 - which had already been patched but not updated on Equifax’s server - to gain access to the corporate network. The attackers pulled personal data including Social Security numbers, birth dates, and residential addresses of an estimated 152 million American, 44 million British, and 8000 Canadian residents. In the end, the data breach cost Equifax more than 1.7 billion US dollar and Equifax’s Chief Security Officer (CSO) and Chief Information Officer (CIO) resigned.