Serverless application (FaaS - Function as a Service) development and use of microservices model are emerging in next generation applications and architecture. It is becoming easier to maintain and cost effective in the days of DevOps era. It is imperative to do a quick testing of these functions from security standpoint and look for common vulnerabilities like injections. Amazon provides Lambda functions for serverless architecture whereas Google and Azure also implemented these types of support and having FaaS in their own portfolio. As shown in the below figure, lambda function is created and deployed on amazon and can be triggered by set of events like HTTP gateway, S3 bucket and number of other events. At the end, the functions are being “invoked” and executed by the end client (Browser, mobile or API users). The challenge from security standpoint is to fuzz these inputs going to functions and identifies any defect in the code via error or behavioural observations (purely DAST approach).
Figure 1 - Lambda invoke and integration
To address the issue of fuzzing, we can leverage AWS client (command-line) directly and interact with functions without going through the actual events as shown in the above diagram. It is possible to test these functions if developer provides right environment along with credentials to the pentester. We can set up AWS client and run some quick tests to discover vulnerabilities and weakness.
One needs to setup AWS client and you can find guideline over here - https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html
First, one needs to setup the access for the environment by given keys from developers as shown below. It is quick process and needs basic detail.
$ aws configure
AWS Access Key ID [None]: …
AWS Secret Access Key [None]: …
Default region name [None]: …
Default output format [None]: …
Once it is set, we can go ahead and enumerate the functions deployed on the server as below by using “list-function” option. It helps in enumerating all functions deployed with some basic information including permissions.
As shown above, we get list of all the functions. Next, we can enumerate the functions in more detail. For example, getting configuration and actual location (code) as shown below.
One can get location of the code by following call, “Location” attribute give the code for review if required.
Now, we can get into the most critical part of the testing. We can invoke the function and start interacting with it as shown below over AWS APIs without actual event. Event can be coming from any source but we are keeping focus on directly testing the function.
In above case, we invoked “login” function with “payload”. We directed out to the file and can see the results.
Now, we can just go ahead and start manipulating “payload” with all different values from DAST/Blackbox standpoint. We can fuzz the payload and start injecting values to discover vulnerabilities within lambda functions.
In a nutshell, it is easy to fuzz lambda functions and test them thoroughly. It is possible to add them into DevOps pipe. AWS client can be used with different languages as well to automate the process. For example following code with python and boto3 client helps in automate fuzzing.
Here, we are passing ‘john OR 1=1’ as payload to invoke the function. We are getting following response.
We get “Error in fetching value from table” as status message. It implies something to do with SQL injection. Again, we need to dive deep and find exact payload. We can automate the script and start fuzzing the lambda functions.
Article by Amish Shah & Shreeraj Shah
Figure 1 - Lambda invoke and integration
To address the issue of fuzzing, we can leverage AWS client (command-line) directly and interact with functions without going through the actual events as shown in the above diagram. It is possible to test these functions if developer provides right environment along with credentials to the pentester. We can set up AWS client and run some quick tests to discover vulnerabilities and weakness.
One needs to setup AWS client and you can find guideline over here - https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html
First, one needs to setup the access for the environment by given keys from developers as shown below. It is quick process and needs basic detail.
$ aws configure
AWS Access Key ID [None]: …
AWS Secret Access Key [None]: …
Default region name [None]: …
Default output format [None]: …
Once it is set, we can go ahead and enumerate the functions deployed on the server as below by using “list-function” option. It helps in enumerating all functions deployed with some basic information including permissions.
As shown above, we get list of all the functions. Next, we can enumerate the functions in more detail. For example, getting configuration and actual location (code) as shown below.
One can get location of the code by following call, “Location” attribute give the code for review if required.
Now, we can get into the most critical part of the testing. We can invoke the function and start interacting with it as shown below over AWS APIs without actual event. Event can be coming from any source but we are keeping focus on directly testing the function.
In above case, we invoked “login” function with “payload”. We directed out to the file and can see the results.
Now, we can just go ahead and start manipulating “payload” with all different values from DAST/Blackbox standpoint. We can fuzz the payload and start injecting values to discover vulnerabilities within lambda functions.
In a nutshell, it is easy to fuzz lambda functions and test them thoroughly. It is possible to add them into DevOps pipe. AWS client can be used with different languages as well to automate the process. For example following code with python and boto3 client helps in automate fuzzing.
Here, we are passing ‘john OR 1=1’ as payload to invoke the function. We are getting following response.
We get “Error in fetching value from table” as status message. It implies something to do with SQL injection. Again, we need to dive deep and find exact payload. We can automate the script and start fuzzing the lambda functions.
Article by Amish Shah & Shreeraj Shah