A popular way to learn something is to learn from your mistakes. But what if you could learn from someone else’s mistakes instead?
Irrespective of how much we rely on AWS in our digital ecosystem, a skilled cloud engineer needs to know how to protect their site infrastructure from leaking sensitive information and getting compromised.
So, what are the common AWS security pitfalls and how do you secure yourself from them?
If you’d like to skip ahead to one of the sections in particular, just use the clickable menu:
- What is AWS?
- Eight common AWS security pitfalls
- Misconfigured S3 buckets
- Lack of horizontal access control on S3 objects
- Dangling S3 subdomain takeover
- Lack of logging
- No custom IAM users and roles for specific actions with minimal privileges
- No custom security groups for resources that need to communicate with each other
- Unnecessary open ports on resources and security groups
- Insecure/Unauthenticated Lambdas
- How to learn AWS
- Final thoughts
Are you ready? Then let’s get into it!
1. What is AWS?
The popularity of Amazon Web Services (AWS) as a cloud computing platform speaks for itself.
Starting back in the early 2000s as a subsidiary of the e-commerce empire, AWS has become a global player in the cloud computing industry since then.
As well as being incredibly reliable, it’s also relatively affordable and has enough services in its ecosystem that can run pretty much anything—Netflix is hosted there, for example.
If you’d like to learn more about the platform from a general point of view and how it works, we’ve created a complete beginner’s guide to cloud computing with AWS.
2. Eight common AWS security pitfalls
Now that we’ve reminded ourselves about what AWS is and how much of a big deal it is, let’s take a look at how you can ensure that your work with the cloud platform is as secure as possible.
We’ll go through each common issue, and then include our recommendation for resolving or avoiding them.
Misconfigured S3 buckets
One of the most common issues is, unsurprisingly, open or misconfigured AWS S3 buckets.
During development, it’s common to use open buckets in order not to have to bother with authentication practices, like creating temporary access keys for objects, as well as access control for users and their respective static assets.
Common misconfiguration issues include:
- Enabling directory listing for everyone
- Using bad ACLs (Access Control Lists)
- Lack of horizontal access control (one user can access all other users’ files)
Recommendations for avoiding this pitfall:
- Disable directory listing for all users
- Use a specialized user who is the owner of all objects, instead of using ACLs
- Application should proxy file access so that no-one can directly touch the S3 bucket objects
Lack of horizontal access control on S3 objects
Another common S3 issue is having no control over which user can access what resources.
In this case, if a profile picture of a user is hosted at <s3-bucket>/profile-picture/1234.jpg then there’s nothing stopping the user from accessing a picture hosted at <s3-bucket>/profile-picture/5678.jpg.
This is a problem, especially for personal data, like pictures, invoices, or user uploads like file submissions.
Recommendations for avoiding this pitfall:
- Proxy all requests to S3 through a service that checks the user’s ownership of the requested static resource
- Randomize the file names and paths such that enumerating is impossible
- Avoid exposing database indexes or other schema information in filenames (user-submission/1234/exercise/1.1/solution.pdf)
- Always set a base path for the uploaded file to prevent malicious users from overwriting other users’ files.
Dangling S3 subdomain takeover
Many times we create new resources when experimenting.
For example, a developer might create a subdomain and point it to an S3 bucket or Elastic Compute Cloud (EC2) instance. Quite often, these experiments aren’t cleaned up properly.
In this attack scenario, the S3 bucket might’ve been deleted without removing the CNAME record from DNS, allowing any malicious user to create a new bucket with the same name and take over control of the subdomain and serve malicious files.
Recommendations for avoiding this pitfall:
- Removal of unused DNS records and other allocated resources should be part of the project’s scope
Lack of logging
Logging is a critical component of incident forensics.
It’s any organization’s responsibility to let their users know when their data is compromised and what exactly is compromised.
But it isn’t possible to do that if the organization doesn’t have that data themselves, or doesn’t store it in a way that it’s easy to retrieve.
Recommendations for avoiding this pitfall:
- Use AWS CloudTrail to monitor and keep track of critical events
- Studying and practicing the procedure for when there is a security incident. The AWS Security Incident Response Guide is a great place to start
No custom IAM users and roles for specific actions with minimal privileges
It’s easy and tempting to use a common AWS IAM user for unrelated actions, since you already have the credentials for a user.
However, this is a security risk and it increases the damage surface an attacker can do if the credentials land in their possession.
Recommendations for avoiding this pitfall:
- Create a new IAM user account for every new action and only enable key access for programmatic accounts
- For user accounts used by real people, enable 2FA (2-factor authentification) by default
- Grant least privileges for an account to work, and add privileges as and when required
- Log IAM admin login and other critical events
No custom security groups for resources that need to communicate with each other
Naturally, your AWS resources sometimes need to communicate with other AWS resources.
For example, a firm’s CMS platform’s EC2 server needs to speak with an RDS instance and a Memcached instance.
A poorly configured system would just have one security group that all resources get added to, allowing a potential attacker to access all AWS resources if they get hold of one.
Recommendations for avoiding this pitfall:
- Create custom security groups such that resources get only the minimal access that’s needed for them to function properly. For example, an EC2, RDS, and Memcached instance can live in a security group.
Unnecessary open ports on resources and security groups
As part of their day-to-day functioning, web services make use of TCP or UDP ports with a port number.
Client applications need to connect to this port for communication to happen and for data to transfer. For example, port 22 is used for SSH sessions and port 80 for HTTP traffic, while port 443 for HTTPS traffic.
These are default ports, and nothing prevents us from reassigning them (although it will break compatibility for clients who are unaware of the change).
However, these ports are open to potential misconfigurations which can be bad for your AWS security.
Examples of these are:
- Ports left open to the internet can be used to gather information about the services running
- Outdated services frequently contain security bugs that can be exploited
Recommendations for avoiding this pitfall:
- Only open ports on a case-by-case basis
- Disable banner exposure on internet facing applications
- If the application exposed via an open port isn’t updated automatically (for example a package manually installed on an EC2 server), it’s important to keep it updated as part of what I like to call greenkeeping. Essentially, greenkeeping is regular code and code dependency maintenance.
Insecure/Unauthenticated Lambdas
AWS Lambda are serverless functions—standalone services that don’t share the same authentication mechanisms as a Ruby on Rails app, for example.
A consequence of this could be that your company’s web developers forget to implement any sort of meaningful authentication on the Lambdas.
This leads to the following issues:
- Lambdas use insecure or worse, no authentication to service requests
- Lambdas use flat key authentication, allowing users to make requests on other user’s behalf
Recommendations for avoiding this pitfall:
- Have an authentication scheme per user for AWS Lambdas
- Check for file upload vulnerabilities, especially if uploading files based on location sent from the frontend.
Hopefully by having learned these, you’ll be ahead of the curve in ensuring that you AWS security will be as tight as possible, meaning that your customers can use the services in total confidence.
Now that we’ve seen how important it is to have knowledge and training in securing your services on the AWS platform, let’s look at how you can go about learning to use it.
3. How to learn AWS
Due to its popularity and ubiquity, there are many different ways to learn how to get to grips with Amazon Web Services.
Some of these are offered by Amazon themselves, but there are also a host of other providers as well providing education in the platform.
The range of trainings available completely depends on what you’re looking for—whether you’d like a general introduction to how to manage AWS, or for specific tools such as the AWS Virtual Private Cloud (VPC).
General AWS courses
These days there is a growing variety of ways for developers to learn how AWS works in general. Among these are the likes of CareerFoundry’s Cloud Computing for developers course.
This flexibly paced course is a great way to start getting to grips with not just AWS security and the wider Web Services platform, but cloud computing in general. Starting with the fundamentals of the cloud, it will have you deploying a web app on AWS, an ideal project for your developer portfolio.
You’ll gain hands-on practical experience with some widely-used AWS tools, such as EC2, Simple Storage Service (S3), the VPC, Lambda, and Identity and Access Management (IAM), as well as AWS security best practices.
Offering developers a basic to intermediate level of deploying web applications on AWS cloud services, this course can be taken by itself, or as part of the Full-Stack Development Program.
AWS security certification
More experienced developers, IT security professionals, and cloud engineers seeking to add a qualification to their tool belt, should definitely consider the AWS Certified Security Specialty exam.
Costing $300, the exam is offered in a variety of languages and will involve a considerable amount of preparatory work.
If you’d like to start off at an earlier level, Amazon offers a variety of free and paid courses as part of the AWS Skill Builder platform.
4. Final thoughts
So there you have it—eight of the most common AWS security issues people are likely to fall into.
The best way to educate yourself about these things is to consider all of these scenarios and then work to prevent them from happening.
If you’d like to read more about the world of web development, check out these articles: