There has been a whopping increase in supply chain attacks aimed at upstream open-source libraries and software components. Interestingly, despite the risk, the trend in the industry shows a strong growth in the supply and demand of open-source software.
The most recent exploit on the Java logging library (log4j) has shaken the IT industry due to its wide usage and ease of exploitation. This vulnerability (CVE-2021-44228) allows an attacker to execute arbitrary code in the remote server. The code is triggered when a specially crafted payload is provided by the attacker within the HTTP request and is then processed by the vulnerable Log4j 2.x element.
Vulnerable Log4j2 libraries present various risks to many organizations and its users. This includes, but not limited to, remote code execution, unauthorized access to organization’s data and compromise of systems’ availability.
Version 2 of Log4j between versions 2.0-beta-9 and 2.14.1 are affected by this vulnerability. This vulnerability is patched in 2.15.0 & 2.16.0
The Log4j2 vulnerability is applicable to systems including Java-based applications and underlying infrastructure which utilize vulnerable versions of the Log4j library.
Organizations rely on development of custom-built applications by in-house and/or third party MSPs to conduct business. These applications often utilize Open-Source Software (OSS) components / libraries such as Log4J for software development.
If the organization provides a centralized repository for open-source libraries, this repository must be scanned using open-source library scanners.
In addition, the platforms such as web servers should be scanned using platform scanners such as Qualys/Nessus or any other open-source scanner to detect the presence of vulnerable Log4j libraries.
Organizations acquire many COTS and SaaS applications to facilitate business needs. These applications are usually hosted either on-premise, third-party hosting providers, or in the cloud.
As COTS applications do not provide access to their source code, the product owners can determine whether their COTS or SaaS product is vulnerable by reviewing the list of impacted applications
In addition, the product owners should communicate with third parties/vendors to confirm their acknowledgement of CVE-2021-44228 and if they are affected. Getting a patching timeline will also help with scoping the attack surface.
To mitigate the vulnerability, one or more options may be applied:
log4j2.formatMsgNoLookups=true
Additionally, an environment variable may be set for these same affected versions:
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
This can be done in an automated way using the this Script
3. Remove the JndiLookup class from the classpath of log4j-core. For example:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
4. Disable suspicious outbound traffic, such as LDAP and RMI on the server and on the Firewall.
Image credit: https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
The School of Information Security is determined to produce quality cyber security experts in the industry with their cutting edge live-online Web Application Penetration Testing training program. As more vulnerabilities arise in applications, the demand to hire application security experts will continue to rise. The School of Information Security’s job-oriented training program provides individuals with core knowledge along with hands-on labs to be successful in their cyber security career.
Author: Faisal (Moe) Askari, CISSP, CISM
