How WAPPLES Protects Against Log4j Vulnerability
What Is Apache Log 4j?
Log4j is an open-source data logging package developed by Apache for the Java platform. It is one of the most popular Java logging frameworks; the other two being Java Logging API made in-house by Java, and Java Commons Logging (JCL), another open-source logging package made by Apache.
A data logging package is essential for web applications, enabling application programs to record activities so that developers can retrieve them from the logging library when needed. It is usually built into programs for logging error messages, troubleshooting, auditing, and data tracking. Any application that connects to a web server is likely to use Log4j directly or contain third-party plugins that use Log4j. Large corporations like Google, Apple, Amazon, IBM, Oracle, and Cisco, all have applications that use Log4j.
So What Is the Log4j Vulnerability?
The Log4j vulnerability – also named Log4Shell, LogJam, or CVE-2021-44228 – was first disclosed by Apache on December 9, 2021. It is essentially a flaw that allows hackers to launch remote code execution (RCE) attacks against web applications and install malware onto the web servers.
To understand the vulnerability, it is important to know where the problem arose. Log4j requires directory services to perform lookups to locate specific data from its library. To enable directory services, a plugin called “JNDI (Java Naming and Directory Interface) Lookup” was added to the Log4j package in 2013 (version 2.0.beta.9). JNDI contains SPIs (Service Provider Interfaces) that enable it to utilize a variety of directory services, including LDAP (Lightweight Directory Access Protocol), Java RMI Registry, and COBRA COS. The SPIs are central to this vulnerability, with LDAP being the most exploited path.
Here is where the vulnerability occurs. Note that the directory services do not have to be run on the same server as the application. In fact, they can be run anywhere on the Internet. All it needs is for JNDI to call the LDAP server by entering an LDAP URL via the SPI, after which the application program loads the directory from that remote server. Log4Shell allows hackers to edit the LDAP URL so that they can trigger the application to load a directory (containing malicious code) from their own server, the exact scenario of a remote code execution (RCE) attack.
“Worst Vulnerability of the Decade”
Due to the wide use of Log4j, the vulnerability quickly gained the global spotlight, attracting virtually all hackers around the world. Only one day after the disclosure, exploitation attempts reached over 5,000 requests per minute, and quickly skyrocketed to more than 20,000 requests per minute. Within a week, Log4Shell was characterized by many cybersecurity experts as the “worst vulnerability of the decade”. Since Apache acts as a crucial bridge between applications and their servers, the vulnerability has the potential to affect many applications that we use on a daily basis. Exploiting Log4j could endanger all the digital infrastructure downstream, leading to a massive supply chain crisis.
Security intelligence companies like Microsoft have already discovered that state-backed threat actors in China, North Korea, Iran, and Turkey, as well as the world’s most sophisticated ransomware gangs, are racing the clock to exploit the vulnerability. In less than two weeks, Russian-based Conti ransomware gang has successfully built up an attack chain through Log4Shell. At the same time, the Belgian Ministry of Defence confirmed suffering a cyberattack that originated from the vulnerability.
Cybersecurity experts also raised concern for the potential emergence of a worm. A worm is an automated vulnerability exploitation tool that spreads like a virus, having the potential to cause tremendous damage worldwide. Even though it is unclear whether a worm can be made for this particular flaw, it is a legitimate concern.
How to Mitigate Log4Shell?
Log4Shell affects all the Log4j versions between 2.0.beta.9 and 2.14.1. Apache has released a patch to Log4Shell in the latest version of Log4j (version 2.15.0). Having a quick fix is relieving, but does not mark the end of the crisis as it might take companies days to months to implement the update to all their application programs. In the meantime, downstream users of these applications remain at risk in the coming months.
Respond with WAPPLES
A more reliable defence against Log4Shell exploits is to use a logic-based web application firewall (WAF) like WAPPLES. WAPPLES itself is free from Log4Shell as none of its versions contain Log4j, and as soon as the vulnerability was reported on December 9, Penta Security’s R&D team responded immediately by introducing a new attack pattern that enables the COCEPTM detection engine to identify CVE-2021-44228. WAPPLES users can add the pattern to their security policy by registering either user-defined patterns or custom rules. The configuration process varies depending on the version of WAPPLES, and a detailed manual was provided for all WAPPLES users. Penta Security is closely monitoring the latest exploitation attempts and updates the manual as needed for its users.
Need for Holistic Security
As mentioned before, this vulnerability will keep many companies and their IT departments busy for the foreseeable future, and it points to a crucial fact that many companies still lack understanding of: security is an ongoing process. Enterprises need to prioritize security and regularly check for updates to the guidelines to prevent vulnerabilities and breaches.
For more information on a holistic security approach, check out Penta Security’s product lines:
Web Application Firewall: WAPPLES
Database Encryption: D’Amo
Identity and Access Management: iSIGN+
Car, Energy, Factory, City Solutions: Penta IoT Security