5 AWS Misconfigurations That May Be Increasing Your Attack Surface
Reading time: 12 minutes
Not all data breaches are created equal.
While many remain the product of technical prowess so often associated with malicious actors, a burgeoning amount can be attributed to security misconfigurations and overly-permissive entitlements plaguing cloud ecosystems around the globe.
Furthermore, with the exponential expansion of cloud-native applications and similar undertakings, many organizations often rush to deployment overlooking critical security cross checks that expose a greater attack surface than most stakeholders are willing to admit. These largely unforeseen areas can quickly become the Achilles' heel of any security program as traditional endpoint protection solutions and other security measures remain largely impervious to their presence.
In this blog post, we will explore five of the most common (and likely most damaging) misconfiguration errors associated with popular services featured by Amazon's AWS cloud offering. For this purpose, we examine them in light of what AWS considers best practices surrounding the proper use of these technologies, showcased by a handful of breach reports that attest to their undisciplined provision.
Misunderstanding the shared responsibility model
AWS's shared responsibility model is the foundational agreement between the cloud service provider and its customers that defines the distribution of responsibilities associated with security and compliance.
Following this model, customers are relieved of the operational burden of maintaining and securing the controls and components below the operating system and virtualization layers, diminishing the possibility of a security breach due to potential hardware vulnerabilities. This is commonly referred to as "Security of the Cloud'', in stark contrast to "Security in the Cloud'', which establishes that customers are ultimately responsible for additional services such as application software and any related security group firewalls.
In addition, AWS has further divided the model into three distinct categories:
- Infrastructure services
- Container services
- Abstract services
Unfortunately, adhering to any one of these categories is no easy task. According to Cloud Security Alliance, the "trick" is to understand where your service provider's responsibilities end and where yours begin. Failure to properly identify these subtleties is certainly a recipe for disaster; one that can severely impact IT operations and even put your entire enterprise at risk.
Take for example container services, a category that shifts focus away from infrastructure as a service (IaaS) towards platform as a service (PaaS), moving the responsibility model in the direction of the service provider and partially adding to their bucket important considerations (should a data breach ever occur) such as incident response and cyber forensics. As part of the tradeoff, however, the customer is still responsible for access management using the control plane to secure any related applications, data, and user activity.
In addition to the direct connection between AWS and customers, the shared responsibility model may need to account for differences within a specific organization—particularly those involving third-party vendors and similar entities with access to develop, manage or secure aspects of the cloud environment. All this added complexity leaves ample room for ambiguity, but at the same time, it provides an opportunity to highlight potential areas of the business in desperate need of gap analysis.
Without further ado, here are the top 5 misconfigurations.
### 1. To encrypt or not to encrypt
Encryption is paramount to confidentiality and integrity; two of the most important tenets of adequate data protection, whether in-transit or at-rest. Everyone in this industry knows that—or should. Yet many organizations fail to realize the importance of implementing relevant encryption models around their most sensitive assets.
AWS cloud solutions are not exempt from this daily reality. Misconfigurations that entail accidental (or not-so-accidental) information disclosure are quite commonplace throughout organizations of all shapes and sizes.
Server-side encryption (SSE) is one of those notoriously overlooked features that provide protection for data at rest. Contrary to client-side encryption, which takes place prior to objects being uploaded to S3 buckets, for example, server-side encryption does the heavy lifting by allowing stored objects to be protected with a unique key using MFA—a concept known as envelope encryption. Should faulty permissions and/or other access misconfigurations result in unauthorized access, encryption can provide that additional and final layer of protection capable of rendering any information obtained useless.
A significant caveat, however, comes from the fact that enabling encryption on a particular bucket has a frontward nature; that is, only newly added objects will be assured encryption and not pre-existing ones. Organizations looking to correct this can resort to methods such as batch operations using AWS Lambda functions, but these can be both cumbersome and error prone.
2. The leaky bucket
Amazon S3 buckets, as they are usually referred to, are a form of Simple Storage Service (the S3 part) solution akin to variants such as Google Drive or Microsoft's OneDrive. Although their design aspects and other intricacies have never been publicly released by the company, everyone who has used them can attest to both their efficacy and ease of use.
From simple file hosting to more advanced use cases that involve storage classes capable of managing automated storage tiering (think "hot" storage) or even database concurrency needs, S3 buckets are exceptionally capable of providing a wide range of services. They are designed to be highly resilient (eleven 9's of durability) when it comes to data protection, with an average availability rate of 99.99% over a given year. But the real question at hand is:
Are S3 buckets secure?
The short answer is... yes. S3 buckets are one of Amazon's longest-standing cloud-based virtual storage offerings; this has allowed the product to adequately mature through a series of iterative improvements backed by some of the best security experts the company can afford.
However, with each passing week, news of yet another sensitive data exposure involving S3 buckets continues to rock the -infosec milieu—spanning entire industries and exposing data as varied as fingerprint scans, adult site memberships, and medical records. It is, however, deceptively tempting to attribute all these exposures to sheer human negligence; the reality is, there are subtle complexities involving the proper securing of S3 buckets that can potentially lead to a healthy dose of misconfiguration mishaps.
To begin with, all S3 buckets are private and can be accessed only by users that are explicitly granted access. This approach is no different from the standard ACL (access control list) rules method ubiquitous across the industry, where permissions to a certain resource are granted according to specific roles or access levels. After all, AWS emphatically reminds its customers that security continues to be a shared responsibility. Nevertheless, partially configured or altogether misconfigured bucket ACLs are at the heart of so many unintended exposures.
Enter S3 objects
To make matters worse, S3's version of storage atomicity comes in the form of an object—a file, with any associated metadata, that can be accessed independently from its parent bucket. Thus, a secure bucket can in fact contain a number of potentially insecure object files, opening an additional window of exposure that can easily go undetected. S3 consumers are also encouraged to leverage Identity And Access Management (IAM) policies to properly handle access to a single AWS account and any given resources from multiple users and groups.
3. IAM woes
Behind Every Cloud Environment's Identity and Access Management (IAM) System is the Concept of the Policy—the Backdrop of Fine-grained Access Controls Based on Roles that Explicitly Allow Users and Services to Carry Certain Actions Over Specific Resources. One policy, for example, can describe how users should conduct authentication, while another policy may limit a mobile app to a finite set of allowed requests on the backend. Additionally, AWS IAM offers features such as:
· Identity federation: Access to AWS resources based on a system of trust between different identity providers
· Multi-factor authentication (MFA): A security mechanism that requires at least two pieces of distinctive origin to authenticate users
· Eventual consistency: The achieving of convergence using reliable large-scale data replication models that deliver the expected amount of availability and performance that IAM operations require
However, as many AWS IAM administrators and security practitioners can easily attest, the tool's excellent level of granularity can also be its downfall. To illustrate this idea, let's start with one of the most dangerous, soon-to-be-ubiquitous misconfiguration snafus across cloud providers: inadequate role assignments.
Getting role assignments wrong can result from a chain reaction of privilege escalation events leading up to "AdministratorAccess"—a full access user that can delegate permissions to every service and resource in AWS. Some of the conditions that can lead to, or exacerbate, this sort of administrative doomsday scenario include:
-
Failure to apply the concept of least privilege using IAM roles to manage permissions between AWS accounts within the organization
-
Failure to remove unused or expired accounts, roles, passwords and access keys when users no longer need access or are simply no longer part of the organization
-
Failure to implement strong password policies, key rotation, and/or MFA for privileged IAM users with access to sensitive resources
-
Failure to monitor for account changes and API usage on a regular basis to identify suspicious activity, using compliance tools such as CloudTrail
The concept of authorization and its relation to AWS IAM policies [Source: cloudonaut.io]
AWS IAM security is a complex topic. Different policy types can be inadvertently combined into a risky, nebulous mix of misconfigurations. Overly permissive trust settings and roles can quickly poke a hole in an otherwise security-conscious deployment. Last but not least, organizations in dire need of competitive advantage often decompose applications by business capability and other factors in search of better scalability and fault isolation. This forces identity services to quickly adapt to secure an ever-growing number of application derivatives with equally increasing data security requirements.
4. EBS, the lesser-known treasure cove
One particular AWS offering that has attracted recent attention due to a number of data exposure incidents is known as Elastic Block Store, or EBS. EBS storage volumes are flexible, unformatted block-level devices ranging from 1 GB to 16 TB in size that can be attached to instances (e.g., EC2) or mounted for various other purposes. For example, they can be used as primary storage for file systems or by throughput-intensive applications that perform continuous disk scans, reads, and writes—think databases.
EBS snapshots are also block-level volumes that can persist independently and even behave as a form of incremental backup if need be. As in the case of S3 buckets, EBS volumes and snapshots are not encrypted by default (adding fuel to the fire) and can be shared publicly for other AWS accounts to use in what is basically known as "public" access mode.
Now imagine the risks involved by having an entire snapshot mounted by an attacker-controlled VM, or inadvertently exposed and available for browsing just as any other file sharing system. This was precisely what took place in 2019 when Ben Morris, a senior analyst with offensive security firm Bishop Fox, discovered a treasure cove of EBS snapshots containing everything from customer information in the form of PII (personally identifiable information) to encryption keys, in what the Defcon associate characterized as "petabytes of data" just waiting to be grabbed during an interview with TechCrunch.
When the dust settled, it had taken Mr. Morris about two months, a few hundred dollars in AWS infrastructure and a custom application to accomplish his objective. "When you get rid of the hard disk for your computer, you know, you usually shred it or wipe it completely", he explained, arguing that "these public EBS volumes are just left for anyone to take and start poking at."
5. CloudTrail
CloudTrail delivers an important subset of governance and auditing monitoring capabilities related to AWS accounts. In essence, the web-based tool centers on round-the-clock visibility and logging of any user or service activity related to API usage, including actions taken via the AWS Management Console or the command line ecosystem.
Organizations focused on enabling key compliance and risk auditing actions should find in CloudTrail the perfect ally when it comes to having clear insight into management events such as account creation, modification or deletion. As far as security analysis is concerned, this level of control and visibility over user behavior (e.g., logins) and API usage patterns can only result in better detection and prevention initiatives, if properly understood.
The most important feature of CloudTrail is based on the concept of a trail—a setting that collects events for a particular region and sends them to a specified S3 bucket for storage and retention reasons. In turn, these log files can be sent to one or multiple recipients for further analysis and processing.
According to Trend Micro, CloudTrail can easily fail to accomplish this very purpose when delivery errors and other misconfigurations prevent these event streams from getting to their intended destination, resulting in the absence of data for future security audits. As mentioned, trails are region-independent, and consequently it is easy for an organization to miss critical changes and other events by not enabling multi-region coverage across the board. This is typically the case of those organizations rushing to complete a new migration or rapidly scaling existing infrastructure against an approaching deadline.
Summary
Configuration errors, whether in the cloud or on-premises, are likely to remain with us for the foreseeable future. There is also very little doubt that the self-service, agile and feature-rich nature of the public cloud will continue to attract more and more businesses seeking to remain competitive—even if it means forgoing proper governance or even regulatory compliance in the process.
With an ever-increasing number of cloud-native applications bestowed with shrinking time-to-market deadlines and an equally wide range of job roles required to support them, security practitioners have no other option but to race ahead of the pack to identify areas of potential exposure before the bad actors do.
Now you know the top AWS misconfigurations in order to prevent those, however, even with best practices and guidelines, humans are always the weakest link of the chain.
It's easy to forget about old dev instances, configurations and databases.
Here at SecurityTrails we are committed to helping you reduce your attack surface. Attack Surface Reduction lets you detect exposed assets, discover newly added subdomains, unveil open ports, monitor SSL certificates expiration, and much more.
