.svg){kind=icon}
.svg){kind=icon}
In the past few months, I’ve hosted several sessions on serverless security for serverless developers and DevOps folks. What I’ve realized during these sessions is that there are quite a few inaccurate assumptions that developers are making.
Most of the developers I interacted with **assumed that **their serverless applications are secure by default because:
-
There is no managed server
-
The Serverless App uses HTTPS
-
The Serverless Provider takes care of security
Is that really true? Just because the application doesn’t use a managed server, means its secure?
The answer to this is — No. Serverless applications impose similar risks as traditional web applications. As there is no managed server, it minimizes vulnerability management/patching of managed server part but rest risks are applicable.
Let’s understand the attack scenarios with 4 practical examples:
[**Note: **All the below attacks are performed in the test AWS account. Do not set up vulnerable apps/setups in prod AWS accounts. Read more about AWS Pentesting best practices here.]
1. Information Gathering
The first step is knowing that the application you are accessing is serverless! While performing a pentest, check for default exceptions thrown by the application. In the below screenshot, you can see the default exception at **/var/task **which is a location for the lambda functions at the server-side.
Another example could be fuzzing endpoints through burp suite/proxy tool as below:
The above screenshots throw default exceptions and give us details about serverless / lambda service at server-side. Next step is exploiting it:
2. Reverse Engineering Lambda Function
The server-side code / Lambda function could be accessed from the end-user by exploiting the injection attacks at the application layer.
Below is one example of accessing Lambda Function from the end-user side:
3. Broken Authentication
Have you ever found a lack of rate-limiting protection in a web application? If yes, then you might observe the same in a serverless application as well!
The below screenshot shows a successful brute force attack on a serverless app endpoint for credit card numbers:
4. Listing IAM Users / Compromising AWS Account
Using a command injection vulnerability, it’s also possible to dump environment variables as shown below:
Once you get the Session Token, Secret Access Key, and Access Key, you can configure them in your system using ‘export’ command and then use **AWS CLI **(AWS Command Line Interface) to make AWS calls.
Now you can use #aws sts get-caller-identity to get role information. If roles are not properly defined or have extra permissions, then you can try out other commands like #aws iam list-users
The demonstrated attacks above are just a high-level overview of serverless exploitation. There could be multiple attack vectors and entry points based on the type of application.
Conclusion
Just because it is a serverless application doesn’t mean that it is secure! If you take a look at **OWASP Serverless Top 10, **you will notice that all attacks applicable to traditional web applications are also applicable to the serverless apps.
So it's important to follow security best practices while developing a serverless application and make sure that your app is regularly reviewed by security teams.
Read more on this topic and see a real world example of how pentesting can support a cloud environment's security.
References
