Parameters in Lambda Functions that lead to XSS and Injection
ACM.56 How I might abuse your Lambda function on a pentest if you don’t properly secure your inputs
Part of my series on Automating Cybersecurity Metrics. Lambda. Application Security. Pentesting. The Code.
Free Content on Jobs in Cybersecurity | Sign up for the Email List
In the last post, we looked at how to get started with Python an Boto3.
Before that we looked at automating the deployment of a Lambda function.
One of the things we’re gong to need to modify in the Lambda function we just created earlier is the ability to pass in a parameter with the batch job name. Let’s look at how we can do that and what sort of security problems might ensue if we are not careful.
Create a New Test Event to Pass in a Batch Job Name
If you recall while testing our Lambda function in the console, we used the default test event configuration which was passing some values in the request to the Lambda function.
Return to the test Lambda we created earlier (the one we created manually, not the one we deployed with CloudFormation) or create a new one if you already deleted it.
Click on Test > Configure test event.
The defaults are some test values:
Click Create New Event. Name it. Change the test value as follows:
Click Save. Click Test again. Now you can see a new test and that it is active.
Alter the Lambda function code as follows:
Notice that two variables are passed into our lambda_handler: event and context. I want to print those out to see what they contain. I just commended out the earlier code because I’m going to use it again later.
Click Deploy. Then Test.
The Event contains the name and value we added to our test event and the context has some metadata about the Lambda function.
Alter the code to print out the BatchJobName contained in the event:
Deploy and Test:
Set the value of the batch job name to a variable and return it in the response.
Deploy. Test.
You have essentially created an API that takes a batch job name as input and returns a batch job name as output.
Reflection and Cross-Site Scripting (XSS)
Returning a value to a user exactly as it was entered is called reflection, and it’s not a good idea to allow people to insert whatever they want into your application and return it without checking that it doesn’t contain a malicious value. What could I do with this as a pentester or an attacker? Many, many things. Here’s one example.
Create a new file on your local laptop named test.html.
Enter this code into the file and save it:
<script>alert(1)</script>Double click on the file and you will see a popup box like this:
You’ve just written executable code that automatically runs in a browser. No big deal right?
Return to your test event and enter this value:
Test.
As you can see, we’ve just allowed users to insert executable code into our Lambda function. But we didn’t get a popup here so no big deal right? The code is not executing. That’s because AWS has taken steps to handle the values passed into Lambda functions in the AWS console securely.
Where might this be a problem? Read on…
Different methods for invoking Lambda Functions
Take a look at the AWS documentation for the different ways we can invoke a Lambda function. One is a Curl statement.
One option would be to use a curl statement which is a way to request a web page and get the results.
To request a web page with curl we need a URL. Let’s create one for our Lambda function.
Configure a URL for your Lambda Function
Configure a Function URL.
Choose None for Auth type and click Save.
Copy the URL for your function:
Alter your test file to invoke the function with the parameter
Edit the test file we created. Enter this value:
Now double click on your test file again. Bingo.
I, as a tester, could pass malicious code into your Lambda function that gets executed in a user’s browser. If this exists in your application there are so many ways I can abuse it. I might be able to steal cookies or data belonging to users on web pages they are visiting or cause them to take actions on pages — basically anything that you can do with JavaScript in a browser if you don’t have proper security controls on your web pages.
If you want to know more about secure programming I wrote about the most important things you need to know here and will be adding more soon as I’m working on a new book on secure coding based on this series:
From there you can dig into the details which are many, starting with this documentation from OWASP on how to prevent injection attacks:
If you want to see if your web application has the most very basic security flaws, enter this value into each and every text box:
<script>alert(1)</script>If you find that any text box pops up an alert box as shown in this post, please stop what you are doing right now and contact me on LinkedIn for a penetration test.
This is the most very basic form of testing for a cross-site scripting flaw and if this exists in your web application likely you have other issues that are easy for an attacker to exploit.
Internal web applications too!
Note that even if the application requires someone to login this can be abused by a malicious user or someone who steals the credentials or tricks the user into clicking a link. I wrote about how attackers used vendor credentials in the Target Breach and no, they did not break into an “HVAC system.” They used vendor credentials and flaws in the system that the vendor could log into.
When I perform a penetration test I get internal credentials from customers to ensure that no only the Internet-facing content is secure but all the applications behind login pages.
A cross-site scripting flaw on AWS
If you want to see another example of a cross-site scripting flaw I found on an AWS application penetration test — which may have been in AWS code — check out my presentation from RSA 2020. It’s the first presentation link on this page. I have some other videos and slides on cloud penetration testing in there as well:
Before I gave my presentation the customer told me the bug I found was in their own code. Even so, I reported it to AWS but did not follow up on it because I’m really busy. AWS does not have a bug bounty and I need to put my time mostly into paid work, other than what I write on this blog to help people out. It’s not like AWS can’t afford a bug bounty. #awswishlist.
But they don’t offer one for whatever reason, so I don’t spend a lot of time on the bugs I find. I do report them to security if they are blatant. AWS replied that this was a bug in a “beta service” but beyond that all I know is that there was a bug that allowed me to perform cross site scripting using a custom fuzzer I wrote to test APIs and obtain authentication credentials from an application. After my presentation my customer came back to me and said they thought the bug was in AWS code. I told the customer they should work with AWS to resolve the problem because if it was in AWS code that was their best recourse.
When I perform penetration tests I tell customers what the bugs are, how they can affect the customer, and how to fix them. Troubleshooting with a third-party vendor would be out of scope and I didn’t think paying me more would solve the problem any faster if it existed in AWS code. I’m not one for over-charging customers for services they don’t need, but I’m happy to help more if requested and needed.
XSS is one of the most common vulnerabilities I find and it can do a lot of damage. Make sure you properly validate any and all values that a client can manipulate in a web request. And I mean any. I have found cross site scripting in color pickers, HTTP headers, and almost any part of a web page you can think of. I’ve also been able to submit values to to web applications that perform cross-site scripting attacks later (known as a stored XSS vulnerability) that direct users to a web page of my choosing.
Now that I’ve shown you how to pass parameters to a Lambda function and what not to do, let’s see how we can use this to pass in a batch job name and use it in our system architecture. Follow for updates.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2022
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab