The Log4j flaw (also now known as "Log4Shell"), is a zero-day vulnerability (CVE-2021-44228) that came to light on December 9, allowing almost anyone to remotely execute malicious code against organizations who have certain configurations enabled, with little effort, given the highest CVSS score of 10.
As I write this blog, and this very moment you’re reading it, hackers are making tens of thousands of attempts to exploit this critical security vulnerability in Java logging library Apache Log4j. . If your organization uses Java, there is a good chance it’s exposed to this vulnerability.
It would be wrong to think that your software is not at risk, just because it is not running on a standard platform. Log4j is a very common open-source software, used by many organizations that use Java, including cloud platforms, web applications, IoT devices and more. In other words, there's a wide range of software that could be at risk from attempts to exploit the vulnerability.
We took the exploit for a spin on AWS Lambda functions, to check if they are vulnerable too. It seems that while AWS Lambda is rolling out this hot-patch at runtime, it does not cover all cases. And as you could see in the video below, Meir Benayoun, Sr Innovation Engineer in the Cloud Native team at Contrast Security shows it is still possible to exploit Lambda functions which uses Log4J with a simple injection, leading to an exfiltration of the Lambda’s keys.
If these keys end up in the hands of hackers, they could very easily use them to further exfiltrate data from your cloud account. All they need to do is copy those keys and run AWS commands from any workstation to interact with your cloud account. The impact would depend on the permissions given to the exploited Lambda function. So, if your Lambda function has permissions to read data from the database, so does the hacker. If your function can access files on your S3 buckets, then these files are equally exposed to the hacker.
Want to give it a try? You can get the setup we used to validate this vulnerability here.
So, what should we do? If your organization is running Java-based Lambda functions, you should verify if you have Log4J enabled in them and make sure they are patched. But don’t worry if you are unable to get to everything immediately, we’re here to help.
Contrast Serverless Applications Security, a 3-click, no touch security tool for Lambda functions, can not only detect Lambda functions with vulnerable versions of this library but can also verify whether these functions are vulnerable to Log4Shell. We’re doing that by simulating these attacks on your Lambda functions and then verifying whether it was successful or not.
Many organizations are having a hard time discovering their vulnerable applications and deciding which one should be fixed in priority.
Contrast Serverless Application Security not only helps detect which Lambda functions contain a vulnerable version of Log4j, but also spots the ones for which a successful exploit has been verified and must be fixed urgently.
Here is a demonstration of the Contrast Serverless Application Security statically identifying a Lambda function with a vulnerable library and then dynamically testing it, to verify the exploit. As you could see, within a few seconds you can tell whether your functions are at risk.
Not only that, the Contrast Serverless security tool can also scan all your functions to provide you a “Least Privilege” policy for each within seconds, limiting your attack surface and impact in the case of a successful attack. This means that your functions will be restricted to only do what they are actually required to do in the cloud, limiting the impact of any future zero-day.
Don’t stay idle, waiting for something to go wrong, make sure your Serverless application is secure. Get secure with Contrast Serverless Application Security in just a few clicks.