Do These 8 Vulnerabilities Affect Your Infrastructure’s AWS Security?

by Hannah Grace Holladay / November 10th, 2021

AWS Vulnerabilities

Amazon Web Services (AWS) dominates the enterprise cloud landscape. Around two-thirds of business cloud users host infrastructure on AWS.  That includes many of the biggest companies in the world and small and medium businesses in the tens of thousands. AWS’s popularity makes it a tempting target for cybercriminals: AWS vulnerabilities could let them steal data from thousands of businesses.

Amazon regularly finds and fixes vulnerabilities in the platform’s code and networks. However, many common AWS vulnerabilities originate with users.  AWS provides tools to help cloud users secure their data and infrastructure, but it is a complex cloud platform. Inexperienced users often misconfigure cloud resources, creating security vulnerabilities. 

This article will help you understand frequently exploited AWS vulnerabilities and how to guard against them. 

AWS Root Account Credential Leaks

The AWS root account controls every aspect of your AWS environment. The root account can add new users, modify user permissions,  create and destroy cloud resources, and access all of your data.  It’s important to have a root account. Without it, you would not be able to set up your AWS environment in the first place. But if it leaks, that environment has no protection. 

You should share the root account’s credentials only with trusted senior employees who need root access. It should not be widely shared within your organization, and it should not be used during the day-to-day operation of your AWS environment. Use the root account to set up IAM users with appropriate permissions, then rely on the new user accounts going forward. To further improve AWS security, activate two-factor authentication on the root account and disable the account’s API access key. 

Exposed AWS Access Keys

AWS access keys are credentials used for programmatic access to AWS APIs. Your code can use access keys to carry out tasks that the associated user has permission to perform. For example, your app might use access keys to deploy EC2 instances or store data in an S3 bucket. 

Misused access keys can create an AWS vulnerability. They are often embedded in code, which is then uploaded to a version control system like GitHub. Bad actors frequently target businesses that upload access keys to public repositories. But it is also dangerous to store keys in private repositories. Just like usernames and passwords, access keys should not be shared widely within your organization. If you put them in a private repository, anyone with access to the repository can see the keys. 

We explored how businesses can better protect their AWS access keys in How to Keep AWS Access Keys and Other Secrets Safe.

Sensitive Resources on Public Subnets

Amazon Virtual Private Cloud (VPC) allows businesses to create virtual network environments. VPC gives AWS users control over their network, including network security, routing, resource deployment, and subnets. 

Subnets are one of VPC’s biggest security and availability advantages. Businesses can create logically isolated subnets with traffic screening and access restrictions. For example, they can deploy public subnets connected to an internet gateway and private subnets that are not accessible from the internet. Private subnets can only be accessed by internal resources, making them an excellent option for database servers and other resources that should be hidden from the internet.

When you first provision a VPC, it contains a default public subnet. Unfortunately, many users do not change the original configuration. They deploy servers and databases to the default subnet, exposing them to the internet and creating a dangerous security vulnerability. 

Overly Broad IAM Permissions

AWS Identity and Access Management (IAM) allows businesses to specify user access permissions, groups, and roles. IAM permissions limit the actions these entities can take and the resources they can access.  Permissions should be limited to provide only the access an entity needs. 

Businesses often fail to set permissions correctly, configuring overly broad permissions or failing to re-assess permissions over time. If credentials leak, an attacker gains more access than they otherwise would have. But even if the credentials don’t leak, internal users may access sensitive resources and cause security and availability issues. 

Public Access to Origin Databases

Origin databases should be hidden from the internet. These databases support your apps and services. They may need to be accessible to web servers and other public-facing resources. But there is rarely a good reason to expose their IP address to external connections. 

An exposed origin database IP allows attackers to exploit other vulnerabilities. For example, an attacker could connect and exfiltrate data if the database’s access permissions are not correctly configured. This type of vulnerability has been the root cause of numerous data leaks.

Permissive Security Groups Rules

Security groups are AWS’s virtual firewall. They allow businesses to restrict traffic to and from AWS resources. The user creates a security group and configures inbound and outbound traffic rules. They can then assign the security group to other resources, such as EC2 instances. Security groups are highly flexible, empowering users to create custom firewalls for different scenarios. 

All AWS accounts have a default security group. The default group has permissive rules: it allows inbound traffic on all ports from network interfaces and instances within the same security group. It also allows all outbound traffic. The default group is automatically used for new resources when a custom group is not specified. 

If you don’t adjust the default security group’s rules or create and assign custom groups, instances and other resources are deployed with broad permissions. Many businesses fail to do so. Consequently, instances are often deployed with vulnerable ports that are accessible from the internet. 

We covered AWS security in greater detail in 10 Top Tips For Better AWS Security Today?

Server-Side Request Forgery

In 2019, the Capital One credit card company leaked customer details from 100 million accounts exposing AWS vulnerabilities. The attack was later found to have exploited Server-Side Request Forgery (SSRF). SSRF turns a business’s cloud infrastructure against it.  

Imagine a business that stores sensitive information in a database. The database is hosted on a cloud server without an external IP. The attacker can’t connect to it directly. But they may be able to connect to an internet-facing server with permission to access the database. In an SSRF attack, the attacker exploits a vulnerability in the internet-facing server and uses the server to send hostile requests to the target database. 

For that to work, a resource on an external IP must be improperly configured. In the Capital One case, the attackers exploited overly broad Web Application Firewall (WAF) rules—similar to the situation described in the previous section. However, many different configuration errors might open the door to an SSRF attack. 

Misconfigured S3 Storage Buckets 

We have left one of the most common AWS vulnerabilities until last. AWS S3 is a popular block storage service used by thousands of businesses. S3 stores data in buckets with flexible access permissions. Misconfiguring those permissions may allow malicious third parties to access sensitive data.

A huge number of businesses have been caught out in this way. They deliberately or unintentionally configure S3 buckets for public access. Bad actors scan for misconfigured buckets and exfiltrate the data. Victims of this AWS vulnerability include Twilio, BHIM, Attunity, and dozens more. 

How KirkpatrickPrice Helps

KirkpatrickPrice is a licensed CPA firm specializing in information security. We provide services to help clients secure their cloud infrastructure and comply with information security and privacy regulations, including:

Contact us today to begin your journey to improved AWS security.

Share Tweet Share Email

Related Posts