LOG4J Update: Mitigating, Scanners & More

Editor’s Note: J.R. Hernandez, Evolve Security’s Security Services Manager, says Log4j is going to be an ongoing threat to the growing number of JAVA users in all types of enterprises worldwide. The cybersecurity industry is now learning more about how Log4j can expose some of the world’s most popular applications and services to attack and result in a complete remote system takeover. Here are J.R.’s thoughts from a recent EvolveSec Meetup on the origin of Log4j, the threat, and current strategies for remediation.

What is Log4j?

Log4j is a lookup feature that has been common to most JAVA applications for quite some time. It is one of many functionalities that have been added to JAVA over the years to make it more useful for enterprises that have many internal and external networks connected to their operations. Its purpose is to help companies improve the context of their logs. Most companies keep logs in order to do lookups related to logins and security incidents. However, logs can be difficult to read and often lack information about how they were created. When Log4j is added to lookups it allows users to input information about which logs pertain to different containers.

Ali Baba security teams first reported a vulnerability caused by Log4j in November 2021. A patch was issued in December, but two other vulnerabilities quickly popped up leading to remote code execution problems. A fourth one has recently been discovered related to DNS and other outside directory logins.

Mitigating Log4J Risks

When attempting to mitigate the risks associated with Log4j, note that while the issue was found in a login library, it is still important to keep logs and not to disable logins. If a security incident arises, logs can be critical in locating the cause.

The following steps are recommended to help lessen some of the newer concerns about Log4j:

• Identify as many JAVA applications in your environment as possible. Then, do an audit for dependencies in libraries that each application uses.  
• Run multiple scans because vulnerabilities will not trigger until they are actually logged by log4j.  
• Run credentialed scans internally to add more authentication to security protocols

For users who do not have access to their external code base, it can be hard to detect all JAVA applications, because they are housed in libraries stored in jar files (similar to zip files) in the development system with all proprietary applications. To help with this, the information security community has “hashed” the log4j vulnerable library and created special scanners to look for these files. These scanners are publicly available online.  

Log4j Scanners

• https://github.com/CERTCC/CVE-2021-44228_scanner
• https://github.com/omrsafetyo/PowerShellSnippets/blob/master/Invoke-Log4ShellScan.ps1
• https://github.com/silentsignal/burp-log4shell
• https://github.com/PortSwigger/active-scan-plus-plus/blob/master/activeScan++.py
• https://github.com/Diverto/nse-log4shell
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/CVE-2021-44228
• https://github.com/Neo23x0/Fenrir

JNDI & Other Lookup Concerns

The patches have helped with the internal code execution problems. The greatest concerns now are about how Log4j uses the JNDI (Java Naming and Directory Interface) and other external lookups to create logs and allows users to create nested queries to lookup information from another server within a server.

The benefit of Log4j is that user agents can communicate and pull information from not only with variables in their own local boxes, but also with remote servers. The ability to lookup information from an external server helps to identify security incidents. Yet, if that server belongs to a malicious operator, the user agent is pulling information from a bad source. In addition, JNDI allows the JAVA application to communicate with other servers that communicate in active protocols (LDAP, DNS, NIS) This process can lead to leaked information from the original server to an outside source.

For companies that have JAVA applications that they have checked but want to make sure this vulnerability is not there, we can perform additional application security assessments which involve staging actual attacks to trigger vulnerabilities and identify them.  

What’s Next?

J.R. joined our Evolve team in 2021, bringing significant experience as a vulnerability researcher, offensive security consultant, and cyber threat intelligence analyst. He predicts that the Log4j vulnerability is opening people’s eyes to future issues with open-source libraries. He says that “many users believe that open-source libraries are secure because everyone can see the code. That is true to an extent, but if no one is looking at the code those vulnerabilities are still going to be there.” To learn more our technical cybersecurity services, start here.

‍