Top 5 scary AWS misconfigurations

Written by:

Shilpi Bhattacharjee

October 31, 2022

0 mins read

In 2022, AWS (Amazon Web Services) remains one of the dominant cloud platforms and continues to be recognized as a leader in Cloud Infrastructure and Platform Services.AWS accounts for 34% of the cloud infrastructure service providers, so many organizations today have either all, most, or at least some of their infrastructure on AWS.

Whilst migrating to a cloud provider, including AWS, offers substantial benefits to its customers — including potential cost savings, scalability, competitive advantage, enhanced security, and opportunities for collaboration amongst others — setup must be done correctly to prevent potential security breaches.

Here are the top five AWS misconfigurations you should be aware of to prevent potential security gaps in your infrastructure:

AWS Cloud Trail misconfiguration

wordpress-sync/blog-aws-misconfig-cloudtrail

The first scary business configuration is probably the most important. The AWS Cloud Trail misconfiguration stems from the AWS monitoring service, which should be enabled in your AWS organization and all AWS accounts. Even if it isn’t enabled in your AWS accounts, it should be enabled for all regions and logd should be stored in a separate S3 bucket. These security measures are critical because without them, an attacker could gain access to your AWS account.

In the event of a security breach, you would have no way to identify what the attacker did in the AWS account — because that's what Cloud Trail does. By identifying what an AWS IAM user is doing, Cloud Trail allows you to follow the breadcrumbs left by a malicious user, and uncover what was changed during the breach. Enabling AWS Cloud Trail gives you the tools and intelligence to ensure that your incident response plan works.

AWS IAM misconfiguration

The second AWS misconfiguration is the AWS IAM (Identity and Access Management) misconfiguration. Identity is the most important thing in a cloud, so losing access to your credentials, leaving them hard recorded in secrets around GitHub or other storage services, or using IAM users in AWS without MFA or as the root account user leads to a severe misconfiguration.

This is dangerous because giving users access to your root account as well as your IAM user with MFA means that an attacker who gets access to those hardcoded credentials can use them to log in, and potentially do anything they want on the AWS account that they've been given access to.

AWS S3 Bucket misconfiguration

The next AWS misconfiguration to look out for is the S3 bucket misconfiguration, which is when an S3 bucket is left accessible without proper authorization controls.

Remember the cloud trail bucket that we mentioned above. If you give access to anyone and everyone in your organization, and an attacker was able to access internal credentials, they can delete your cloud trail logs — keeping you from ever finding out what happened.

AWS EC2 misconfiguration

The fourth AWS misconfiguration is the AWS EC2 (Elastic Compute Cloud) misconfiguration. The common AWS EC2 misconfiguration essentially opens your EC2-hosted application to the internet. If your application is vulnerable, it could potentially be attacked by malicious users if its firewall rule, aka AWS security group, is open to the internet. Using an IAM instance profile with access to everything in your organization also creates a security risk.

This is so concerning because it can provide a starting point for a potential data breach. Once a malicious user has access to one EC2 instance, they can use that to potentially access everything in their account, depending on the severity of your AWS misconfigurations.

AWS RDS misconfiguration

Even though this is a managed service from AWS, there could still be misconfigurations. For example, you could leave your RDS instance accessible from the internet and have a security group or firewall rule, which opens to the internet with a default port so people know exactly what port to search for. You also make your snapshot of backups for your virtual machines and RDS instances open to the internet, so people can see what data that you had before and not have authentication around on the database as well.

This is risky because it's a database, so it potentially has access to information like your personal data and customer data. However, you can prevent potential breaches and denial service attacks with the proper controls and AWS configurations for your application. To stay up to date on any known vulnerabilities in AWS, and learn more about how to configure your AWS accounts to optimize security, check out the resources below.