Lab Walkthrough - Command Injection
What is Command Injection?
A cyberattack known as command injection includes running unauthorized commands on the host operating system. Usually, the threat actor inserts the orders by taking advantage of an application flaw, like inadequate input validation.
Serverless Architecture is said to be more secure compared to traditional architecture. However, this does not mean attacks cannot be performed on it.
In this article, we will learn how a vulnerable lambda function can be leveraged to get hold of temporary access credentials and interact with the S3 buckets on the AWS account.
In this lab, we will learn how a vulnerable lambda function can be leveraged to perform a privileged operation.
Objective: Identify the command Injection vulnerability, leverage it to get hold of temporary access credentials and interact with the S3 buckets on the AWS account.
Step 1: Start our lab to interact with the web application we built for you!
Step 2: Navigate to a file that you want to upload and simply drag that file and drop it onto the web application.
As you can see, we got an error while uploading the file.
Step 3: To remove the error we got in the above step, we need to configure our web browser to use a proxy.
Step 4: Start OWASP ZAP and upload the file again to capture the request.
In this article, we will be using zap. So, start OWASP ZAP and turn on the intercept to capture the request.
NOTE: You can use any software, Burp Suite or ZAP just make sure that the intercept is turned on.
After starting the ZAP and turning the intercept on, you will be able to upload the file and capture the request.
Now, simply drag and drop the file to upload it onto the web application. And navigate back to the ZAP.
Step 5: Turn off the intercept and open the request with the Request Editor.
In the next step, with the help of the Request Editor, we will make some changes to the request.
Step 6: Finally, we will perform the command injection attack, and to do that, just add the payload (given below) at the end of line 1 before HTTP/1.1 as shown in the figure.
After adding the payload, send the request to get the response.
In the response we can see that, we successfully received environment variables.
Step 7: Check the bucket name in environment variables and try to access the bucket.
Now, search for the bucket name in the response that we got in the above step. And use the below-mentioned URL format to access the S3 bucket.
As you can see, the access was denied! And that is because the bucket cannot be accessed publicly.
Step 8: Use access keys and session tokens from environment variables to access the bucket.
Now, we will use the credentials that we got in step 6 and set the environment variables using those credentials.
export AWS_ACCESS_KEY_ID=<Access Key value>export AWS_SECRET_ACCESS_KEY=<Secret Key value>export AWS_SESSION_TOKEN=<Session token value>
Step 9: To check whether we got access to the S3 bucket or not, let’s try to list the files in the bucket.
aws s3 ls s3://temporary-public-image-store
We can see that we successfully listed the files present in the S3 bucket. (That means we got the S3 bucket access!)
Step 10: Download the bucket object.
aws s3 cp s3://temporary-public-image-store/flag.txt ./
After successfully downloading the bucket object, let’s print the content of the flag.txt file to get the flag.
Voila! We successfully retrieved the flag.
- AWS CLI (https://docs.aws.amazon.com/cli/latest/reference/)
- OWASP ZAP (https://owasp.org/www-project-zap/)
In this article, we saw how we can leverage the vulnerable lambda function to perform a privileged operation and get hold of temporary access credentials and interact with the S3 buckets on the AWS account. I hope you enjoyed this article. Happy learning!