We were inspired by a recent TestLabs post that outlined how to break into serverless applications on AWS. It’s an interesting read for hacking enthusiasts. It also reminds us of how fundamental security practices are always applicable, even as environments change.
Even when using newer technologies built with security in mind, like AWS, developers still need to be aware of security best practices and configuration settings for secure adoption.
Let’s dive into what TestLabs did to break into a serverless application, what the fundamentals of AWS security are, as we blogged about a while back, and how doing the basics goes a long way.
How TestLabs Exploited the Serverless Application
TestLabs lists the following attack vectors that helped them gain access to a serverless application in AWS:
- Badly configured API Gateway
- Event data injection
- Failure to configure exception handling
- Insecure configuration
- Excessive privileges
- Insecure dependencies
- Susceptibility to Denial of Service
First, there was no request validation configured on API Gateway. In this instance, TestLabs sent malformed data to the API Gateway and were able to retrieve verbose error messages with stack traces.
Once they received the error messages, they were able to reach the AWS Lambda code. They then used event data injection. Event data injection is a new class of vulnerability for serverless applications and is number one on the Serverless Security Top 10 Weaknesses Guide. This attack works by sending event data to a Lambda function that will lead to execution or evaluation.
In this case, TestLabs was able to use event data injection to pass OS commands which were evaluated, revealing the contents of the env environment variable, exposing AWS access keys and session tokens. The Lambda function had no input validation.
The information gathered from the event data injection also allowed TestLabs to download the entire contents of the application’s S3 buckets and DynamoDB database. Excessive privileges made this data readily available if you tried hard enough to find it. The S3 bucket was public, and the application had excessive privileges for DynamoDB.
Finally, a denial of service attack was performed on the Lambda function. Despite the promise of infinite scalability, in practice, there are limits set on each function. You don’t want one function to take up all of your allotted 1,000 concurrent executions per AWS account. In this case, the function in question was limited to 5 concurrent executions. Those were used up with a small piece of code that repeatedly called the API until it went down.
Don’t Forget Fundamental Security Practices
You likely recognize the attack vectors listed above. Event data injection is a new spin on the same injection (SQL, OS, etc) that has been used to break into countless applications. Other than that, there are the same attack vectors security professionals have seen for years.
Why do these problems keep creeping up? As we mentioned previously, there can be a false sense of security when using cloud providers like AWS to build applications. Developers may think that everything is handled for them. That’s not true.
As Security as a Service is coming to prominence, let’s review some of the key aspects of AWS security, starting with the shared responsibility model.
AWS Shared Responsibility Model
This is the most important concept to understand in AWS from a security standpoint. AWS is not responsible for 100% of the security when you use their services.
The level of security AWS is responsible for changes based on what services you use. It’s important to become familiar with this model so you know exactly what you’re responsible for.
In a nutshell, you are always responsible for your customer’s data. This includes secure S3 bucket configuration, database configuration, and following the principle of least privilege.
Your developers are responsible for writing secure code. The fact that the code sits in AWS Lambda doesn’t eliminate the need for input validation, at both the API Gateway and within the Lambda function itself. AWS gives you the infrastructure, but you still need to follow application security best practices.
Network Security in AWS
AWS offers many tools to help secure your network. VPCs and network ACLs are a must to control what computers are allowed to connect to one another. You’ll also want to closely guard which instances have access to the public Internet.
Use Security Groups to control what connections are allowed on your EC2 instances. Don’t leave your instances open to the entire world. Use VPC Flow Logs to understand what is happening in your network. Don’t allow employees to create instances in your production AWS environment. Use a build pipeline instead.
Logging and Monitoring
Although not the most exciting topic to most, logging and monitoring is a must in any cloud environment. The ease of use and flexibility found in cloud environments can create a “wild west” of EC2 instances popping up and disappearing–containers even more so.
AWS suggests centralizing your log management functions. A central place for your logs simplifies reporting and alerting. You’ll have one place to go to see what’s happening in your environment. You can also use a data visualization tool like Kibana to dive into the data even further.
Try to measure what “normal” is in your environment. Then trigger alerts when you notice something out of the ordinary. You’ll be able to respond quickly and repair any damage.
Old Is New Again: Security Fundamentals in a New Context
As technology continues changing at a staggering rate, developers will need to write code and deploy applications in new ways and in new places. The new context doesn’t change the old rules. Security fundamentals will always apply.
Hacker-powered security is table stakes for today’s fast-moving organizations. A diverse, talented group of hackers will constantly test your applications to find more impactful vulnerabilities with less effort than traditional pen tests.
Turn your security team into a competitive advantage and an enabler to the business. You’ll have eyes on all of your attack surfaces, including serverless applications. The fundamentals will be covered, and so will advanced vulnerabilities typical testing strategies may miss.
Common problems, such as improper access control and command injection, could lead to the exploitation of cloud-based applications. Check out our free on-demand webinar on the Top 15 Most Common Vulnerabilities for an overview of the kinds of vulnerabilities to beware of and how hacker-powered security can keep them out of your applications.
The world of cloud technologies is exciting and fast-paced. Use it responsibly and safely, and you’ll unlock its full power for your business.