Summary

Teri Radichel discusses the importance of parsing and validating lambda parameters, headers, and variables to mitigate injection attacks, emphasizing the use of a validation function and the security testing of open-source libraries like jq.

Abstract

In the provided content, Teri Radichel focuses on the security aspects of handling input parameters within AWS Lambda functions. She highlights the risks associated with injection attacks and demonstrates how to use a validation function to ensure that only alphanumeric values are processed. Radichel illustrates the use of jq for parsing JSON event data and stresses the necessity of sanitizing inputs to prevent malicious payloads from being executed. She also underscores the importance of using trusted and up-to-date versions of open-source libraries, advocating for thorough security testing to achieve code coverage for the specific code paths in use. The article concludes with Radichel's plans to dynamically validate AWS-related variables and the intention to address AWS CodeCommit credentials and Multi-Factor Authentication (MFA) in future work.

Opinions

The author believes that proper validation of inputs is crucial in preventing injection attacks, which can lead to Cross-Site Scripting (XSS) and other security vulnerabilities.
Radichel suggests that developers should not only validate inputs but also ensure that the tools they use, such as jq, are secure and free from vulnerabilities that could be exploited.
She emphasizes the need for understanding the libraries in use, ensuring they are the correct and most secure versions, and verifying that they have been adequately security tested.
The author expresses a proactive approach to security by planning to create multiple validation functions for different variables and by intending to address the security of AWS CodeCommit credentials and MFA in subsequent articles.
Radichel implies that while jq is a useful tool for parsing JSON, its use should be accompanied by security checks to mitigate potential risks associated with its execution within a Lambda function.
She acknowledges the potential for environment variables to be exploited and suggests that these too should be validated to enhance the overall security posture of the application.

Parsing and Validating Lambda Parameters, Headers, and Variables

ACM.325 Creating a Validation Function to Mitigate Injection Attacks

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Lambda | Container Security | Application Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post we pulled values from Secrets Manager to use in our function and then cleaned up afterwards to mitigate the chance of a credential leak.

Mirroring a GitHub Repository to GitHub with AWS Secrets Manager

ACM.324 Creating a common function to retrieve a secret value used by all Lambda functions to retrieve their own…

medium.com

In this post, I want to get the repository name from a parameter, but I want to make sure it doesn’t have some nasty characters embedded into it.

Recall that we’re passing in the value of the repository when we run the function. You can do that from the AWS console by passing in test values as I showed you already:

You can also pass in the parameters when invoking the function on the command line like this for local testing:

Either way the value shows up in the events passed into the function by our Bash custom Lambda runtime.

We can echo out the event data to see what’s getting passed in:

Here you can see we get some json in our event data:

To parse the event JSON I’m going to use a program called jq which I installed in the Dockerfile and wrote about in the last post.

RUN yum install jq -y

We used jq to get our secret value like this:

Our secrets are going to be in a common format but our event data could be anything really, and is very function-specific. I’m going to simply add a new bash function to the handler.js file to get the repository from the event.

It’s super simple:

Now I can call this from my function and return after just to verify I’m getting the correct repository name:

And we do. So we’re done right? No.

Take a minute to ponder the injection attacks I wrote about here:

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

medium.com

What can I pass into that Lambda function? Well, just about anything. And depending on how that value gets used, the code I’m executing could end up parsing the value in some appropriate way and taking some unwanted action. The attack string would be passed into the github command and perhaps GitHub or that git command has a vulnerability. Or perhaps the attacker tries to terminate the command and run something different after that command executes. The possibilities are endless…for now.

Let’s fix that.

Let’s say someone entered ;

We want to reject that.

I showed you how I fixed some odd value coming out of the AWS ARN from the RIE. Perhaps it was extra spaces or quotes or who knows. I just eradicated whatever it was with his line of code:

I used sed at the end to remove all but the alpha characters and an underscore or a dash. I mentioned we might want to make that generic and that’s what we’re going to do now.

I’m going to make a file called validate.js.

I’m going to create a function to validate a string is only contains alphanumeric values

Invoke the function with the expected value.

Now run the function with our bad value:

We get a very nice message that tells us exactly what the problem is.

Does this fix our problem? Maybe, maybe not. It depends on if someone could insert a value that gets processed. Look at our function to retrieve the value.

What if the invalid value could somehow disrupt the processing performed by jq? If jq has a vulnerability then I could insert something that would cause jq to do something unexpected and unwanted.

That’s why we need to make sure:

We are using the trusted version of jq.
jq can be trusted — meaning it doesn’t have any vulnerabilities that could be exploited here.

Have you tested jq for security errors? Who has? Are you using it? Do you know?

This is where validation of the open source libraries we use is very important. You have to understand:

Which libraries you use.
If they are the correct libraries.
If they are up to date.
If they have been tested by a security researcher or penetration tester.
And how much code coverage those tests achieved — were the specific code paths you are using tested?

Maybe I’ll get around to testing jq later or looking into what testing has been performed on it. For now I’m moving on.

Just two other notes while we are here.

I read up and cannot seem to find what the version in the AWS CodeCommit repo is used for just yet, so I’m going to leave that hardcoded for now as v1. If I find it needs to change later I’ll adjust it and make it dynamic.

I can get the current region in use from the environment variable AWS_DEFAULT_REGION which is set in the local environment when we apply our local credentials or by the Lambda service when running in that environment. So I have the following variables set now:

I’ll go back and move the validation code for the ARN to my validate.js file.

As you can imagine, I could create many different validation functions in my validate.js file. For example, I could validate that AWS_DEFULT_REGION was set to a proper AWS region by validating that value against a list of valid region strings. The more we validate our values, the less chance that an attack string can slip through.

And I’ll deal with the AWS CodeCommit credentials and hopefully MFA in the next post if nothing else stymies me along the way.

Follow for updates.

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 Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow 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