In part 1, we discussed the various definitions of cloud and looked at cloud incidents related to data breaches, such as outages. In this part, we’re taking a close look at major cloud data breach incidents over the past few years. Are the majority of these breaches associated with sophisticated advanced attackers or malicious insiders? No, just like the other non-cloud breaches in the recent past, we see a lot of basic security control failures, like systems exposed with weak or no authentication due to configuration errors. These types of attackers are typically stealing access credentials with phishing or from repositories outside the cloud environment.

Examining the Capital One Cloud Breach

One breach stands out. It’s the one everyone has been talking about this summer: the Capital One cloud breach of the personal financial records of 106 million individuals. There are many factors in this case, and they are still trickling out months later. Capital One had a mature and multifaceted cloud security program, and it took a knowledgeable attacker to exploit its defenses. I see this as a good example of a Swiss-cheese incident, using many layers of imperfect barriers (Swiss cheese slices) in a series to prevent a penetration. But, in a large attack surface across a complex environment, there is a decent chance that a random set of holes in all the defensive layers will align all the way through. If any lessons can be gleaned from this regarding the cloud, they are: 1) cloud security can be large, complex, and opaque and 2) you should always assume breach. In the latter lesson, Capital One excelled, as the breach was quickly detected, reported, and the attacker apprehended. To date, no known fraud has been reported using any of the stolen data. Also, AWS has recently closed many of the holes exploited in this breach with Version 2 of their EC2 instance metadata which adds protection against server-side request forgery (SSRF) and some WAF penetrating attacks.

Cloud Provider Glitches

When you outsource a major part of your IT infrastructure to anyone, cloud or otherwise, you risk putting all your eggs in one basket. Sometimes that basket has a hole in a it. It’s rare, but it happens.

One of the most infamous cloud provider breaches happened in 2017 at Cloudflare. It was given the name Cloudbleed, which involved a vulnerability in how reverse proxies managed their buffer memory. This bug caused memory contents to leak, possibly exposing (the bleed part) private web session information, including authentication and session tracking details. Customers of Cloudflare services were urged to rotate their passwords. This came on the heels of Heartbleed, a similar memory-leaking vulnerability in OpenSSL software (not necessarily cloud-specific) and served as a reminder that cloud vendors are not security problems or software bugs.

Cloud providers can also susceptible be to ransomware, an ever-growing threat, striking organizations large and small over the past few years. Notably, there were two cloud-hosting firms suffered ransomware in 2019: ConnectWise and iNSYNQ, both of which locked up their cloud infrastructure and hindered customer operations.

Hacking the Cloud Itself

This section was going to be about all the various and unique ways attackers penetrate cloud-based infrastructure. I pulled up the new MITRE ATT&CK Framework matrices for cloud systems and got to work mapping incidents. Well, everything kept falling into the same ATT&CK categories: valid accounts, account manipulation, and trusted relationship. F5 Labs refers to these categories as “access attacks.” Access attacks involve subversion of authentication and authorization, such as phishing, credential stuffing, and credential theft from other systems. It’s no surprise that they are prominent in cloud attacks, as they are the number one way applications are penetrated, year after year.

In many ways, access attacks are the result of a defender’s success in hardening all other attack avenues. Access control is now one of the least protected areas of most organization’s defenses. The fact that the keys to the front door sit in the hands of every single user makes them a tempting target.

Let’s look at access attacks and their effects. Listing them all proved problematic, since many phishing and account takeover attacks did not specify the involved infrastructure, cloud or otherwise. We’re going to just focus on what we could confirm, and the relevant cloud technology interactions.

Access Attack: Cloud Account Takeover

Many unpleasant (and expensive) things can happen when attackers get their greasy paws on your cloud account credentials. At the simplest level, all those luscious cloud compute resources are perfect for cryptocurrency mining or running botnets. One person complained that their stolen AWS account racked up a $50,000 bill. A much more public spectacle occurred when Tesla’s web services cloud was hijacked via a Kubernetes console to run cryptocurrency mining malware,

Access Attack: Cloud Credentials Phished

If you’re going to hack someone, cloud or otherwise, a phishing attack is probably the first thing you’d try. As one of the most likely ways an organization is going to get breached, phishing is the blight of the Internet now. Numerous cloud apps, especially those used by medical and financial sectors, are heavily targeted by phishing. One of the most infamous cases of cloud phishing was when over 200 celebrities had their personal photographs and videos leaked through a phishing attack.

Access Attack: Cloud Credentials Stolen

There are many ways to steal authentication credentials beyond phishing. Sometimes the details aren’t given, such as the case with cloud solution provider PCM’s breach of administrative credentials to clients’ Office365 accounts. Sometimes login keys are left unencrypted sitting in code repositories, and specifically targeted for theft as was the case of the Uber breach of 57 million users, Because of the prevalence of accidental cloud key compromise in this manner, GitHub has taken steps to reduce this by proactively scanning and warning users. Sometimes credential keys are ripped off from cloud compute instances and used for all sorts of mayhem, as was the case with the Imperva Cloud WAF breach in October 2018.

Accidental Cloud Leaks

Outside of breaches from active hacks by malicious entities, there are numerous cloud security incidents traced back to configuration errors, user misunderstandings, and just embarrassing gaps in operational procedures. Sadly, this is a common problem associated with the cloud because such complexity is hidden within layers of abstraction and virtualization. It’s easy to tweak a single configuration and have access fall open somewhere unseen. It’s compounded by the fact that cloud deployments are being done more and more by users inexperienced in operations or IT security. These accidental leaks break down into a few major categories as well.

Cloud Database Leaks

It seems a lot of large databases of important things end up in the cloud without proper access controls put in place. Here are a few mishaps from 2017 through 2019:

AWS S3 Bucket Leaks

There have been 20 AWS S3 bucket storage leaks since 2017. Why so much AWS? It could be the immense popularity and powerful simplicity of both AWS and its S3 service. It could be the tendency of usage of AWS by users lacking in proper security and access control configuration skills. It could be the apparent simplicity of potentially complex cloud configurations that contributes to both configuration oversights, as well as blind spots. The truth is likely in the intersection. It’s such a prevalent problem that GrayhatWarfare has created a web search tool to scan open S3 buckets. Here is a listing of those notable S3 bucket leaks:

Azure Leaks

Microsoft Azure has its own share of accidental leaks, although they are far smaller in number than the AWS S3 bucket leaks. We found only two in recent history, though they are doozies. One was at an unidentified provider that leaked detailed demographic information on 80 million US households. The other was a leak in Tesco’s parking app that exposed tens of millions of photographs of British cars and visible number plates.

Operational Lapses in the Cloud will Continue

It should be no surprise that, as we’ve seen with non-cloud systems, operational lapses lead to security incidents. What’s different is that the cloud is more complex. Unlike than traditional IT systems, technical variances are cloaked by cloud user interfaces. It becomes easier, especially for untrained cloud administrators, to misconfigure access management policies for both users and systems, resulting in data leaks. These leaks seem especially prevalent when dealing with large databases or multi-tiered applications. Some organizations chose to “lift and shift,” which merely duplicates their on-premise configuration in the cloud. This strategy only drags along all their pre-cloud security problems, but also exposes them to the new problems created by the dissimilar operational model of cloud platforms. Gartner has predicted that, “Through 2025, 99 percent of cloud security failures will be the customer’s fault.”

Coming Up, Prevention

Now that we’ve looked at all the ways things have been going wrong with cloud security, in part 3 we’ll get into solutions and preventative measures.