how 3 cloud security incidents could have been avoided
Sam LozanoNov 21, 2023 1:22:45 PM6 min read

How 3 Cloud Security Incidents Could Have Been Avoided

A handful of common issues are particularly prevalent in public cloud environments, leading to significant breaches. These include exposure of sensitive data through publicly accessible storage buckets and databases, overly permissive firewall policies, and weak authentication mechanisms for privileged users. 

Haphazard storage of sensitive data compounds these challenges, with insufficient consideration of security controls. A significant time gap between the detection of security alerts and the subsequent response provides malicious actors with an ample window of opportunity to exploit these vulnerabilities and misconfigurations. The shared responsibility model helps with security control consideration, stating that security of the cloud is handled by the provider itself while security in the cloud is handled by the customer.

Addressing these vulnerabilities and understanding the shared responsibility model is paramount to fortify cloud operations, protect against threats, and mitigate misconfiguration of resources. Let’s take a look at 3 security incidents and how they could have been avoided.

Pegasus Airlines Exposes 6.6 TB of Sensitive Data

Pegasus Airlines, a Turkish low-cost carrier, suffered a significant data breach in February 2022. Researchers from Safety Detectives, a security vendor, found an Amazon S3 bucket that was configured to be publicly readable, leaving over 6.6 terabytes of sensitive data exposed to anonymous access. This data included flight data, passenger data, crew data, and proprietary source code. After several attempts to notify Pegasus Airlines, the bucket was finally disclosed on March 24th, 2022. This seemingly simple misconfiguration raised concerns about the airline's security practices and the potential impact on passengers and crew members.

This breach could have been prevented by implementing a few key controls for public buckets.

  1. Prevent. AWS provides a setting to "block all public access" for S3 buckets. When enabled, it prevents public access at the bucket and object level, except for cases where you explicitly override it.
  2. Enforce. An AWS Service Control Policy could deny changes to the “block public access” setting across all accounts.
  3. Detect. A Config rule could have been configured to identify and alert on public S3 buckets.

By establishing a comprehensive security strategy with preventive controls, detective controls, and a foundational incident response plan, this incident could have been avoided, safeguarding sensitive data and mitigating potential risks to passengers and crew members.

Attacker Gains Administrative Access to Uber’s Internal Systems

In September 2022, an attacker gained administrative permissions across several of Uber’s internal services. The attacker acquired the password for an Uber employee, tricked another Uber employee into approving multi-factor authentication notifications, and was able to access Uber’s internal network. 

With this access, the attacker found PowerShell scripts containing access credentials to Uber’s password storage tool. This contained the administrative access credentials for Uber's critical services, including AWS, GCP, Google Drive, Slack, and other internal services. Fortunately, the attacker decided not to use them for malicious purposes, instead choosing to flaunt by sharing screenshots of the access. Uber’s swift response contained the incident and prevented further impact.

This incident illustrates the asymmetry of cyber attacks vs. defense – while Uber had strong security controls established broadly across their environment, the attacker only needed to find a single chain of weaknesses to penetrate the system. Some controls that would have prevented this particular incident include:

  1. Secure Credential Storage. The most significant mistake was storing administrative credentials for the password vault hardcoded into a PowerShell script. This, of course, undermines the security value of using a password vault. Additionally, the credentials inside the password vault could have been stored in separate compartments, so a single user would not be able to access all of them.
  2. Awareness of MFA Fatigue. Multi-factor authentication is an effective technique, but there have been many cases where it has been bypassed simply by repeating the MFA request until the user is so annoyed that they accept. Broader awareness of this attack technique will hopefully reduce its effectiveness.
  3. Device-based Trust. With the stolen password and bypassed MFA, the attacker completed authentication of their user identity, but modern access management solutions like AWS Verified Access can incorporate device-based trust as well. This requires that the user’s device demonstrate compliance with established policies, like meeting endpoint protection requirements, before allowing access. This can prevent several unauthorized scenarios like attackers connecting from unmanaged devices, legitimate users connecting from a compromised-but-corporate device, or even former employees connecting with credentials that should have been revoked.

Gearbest Exposes Millions of Customers’ Personal Information

In March 2019, Gearbest, a Chinese e-commerce company, suffered a security incident that exposed the personal information of over 2 million customers. The incident was caused by an unsecured public AWS Elasticsearch instance. The exposed data included names, addresses, phone numbers, email addresses, order histories, and payment information. Security researcher Noam Rotem discovered the unsecured AWS Elasticsearch database and notified Gearbest of the issue.

While the obvious solution is to require authentication to Elasticsearch instances, additional security controls could have prevented this incident.

  1. Control creation of public resources. Prevent accidental creation of public resources using AWS Service Control Policies.
  2. Detect public resources. An AWS Config Rule could have identified the public instance and notified a security contact.
  3. Require authentication to access internal network services. You can prevent unauthorized users from even attempting to access internal services, so if they are inadvertently configured not to require authentication they aren’t accessible to public users. Traditionally this would have been accomplished using a VPN, but modern services like AWS Verified Access provide improved security posture and improved user experience. Using AWS Verified Access, traffic wouldn’t have reached the network without authentication and authorization.

ScaleSec Assesses and Builds Cloud Security Programs

In summary, the cloud has many benefits that attract customers of many sorts, with security being one of them. The need to maintain physical infrastructure is almost non-existent in a cloud environment, leading to the misunderstanding of the shared responsibility model. Along with this, insufficient security controls and the lack of foundational incident response plans tend to lead to the misconfiguration of resources, exposing personal data to the public. Setting proper detection and/or preventative controls along with an incident response plan would have led to faster recognition, or prevented entirely, of Uber’s hardcoded credentials, Pegasus Airlines’ open S3 bucket, and Gearbest’s public resources.

A complete cloud security program includes preventive controls, detective controls, and a foundational incident response plan across a comprehensive inventory of cloud resources. As obvious as this sounds, it’s not always cut-and-dry.  Sometimes people don't know what they have or they don't know how it is configured.  What’s more, it’s difficult to keep up with all of the best and most up-to-date methods for configuring a system seamlessly.  When a team faces these headwinds, it can mean they don't know how to sufficiently secure their ecosystem. At ScaleSec, our consultants are trained and certified to implement preventative controls, design detective controls and construct foundational incident response plans to empower our clients to operate securely in the cloud.  Contact ScaleSec today for an assessment of your readiness to defend your cloud environments.  Not ready to talk to us?  Take our free Self-Assessment to help jump-start the conversation.

Sources

RELATED ARTICLES

The information presented in this article is accurate as of 11/16/23. Follow the ScaleSec blog for new articles and updates.