Back
5 Apache Log4j Discovery Tips
The first step to remediating Log4j vulnerabilities? Discovery.
Identifying Apache Log4j usage at scale in any environment can be a challenge. Generally, we’re seeing companies struggle to develop comprehensive strategies to identify the vulnerability accurately across their entire environment. Getting real coverage involves reviewing all assets from both an authenticated and unauthenticated perspective, and often requires additional collaboration with business units and development teams. In some cases, this can be a challenge when there are “black boxes” on their networks that have no clear owner.
To help you get started, we’ve pulled together five discovery tips to identify vulnerable instances of Log4j. For additional detail and best practices for discovery, download our tip sheet: 5 Strategies for Log4j Vulnerability Identification.
- Perform both internal and external network scanning using common vulnerabilities scanners, such as Nmap or Nessus. Most of the Apache Log4j plugins used by vulnerability scanners only test a small subset of common HTTP headers, but they still provide basic coverage. To provide more comprehensive coverage, also perform focused web application testing. Create an inventory of externally and internally available web applications.
- Leverage existing security or configuration management tooling to search systems for files that are unique to Log4j. Then, follow up on positive matches to determine if they are running a vulnerable version of Apache Log4j. The files can be downloaded online: https://logging.apache.org/log4j/2.x/index.html.
- Reach out to vendors to determine if vulnerable Apache Log4j versions are being used for applications that were not developed by your company that have already been deployed to the environment.
- Collaborate with internal business units and development groups to determine if vulnerable Apache Log4j versions are being used by internally developed applications.
- Prioritize additional testing based on company defined risk. Testing should focus on mapping the web applications attack surface and testing all identifiable dynamic elements such common HTTP headers, parameters (GET, POST, JSON), and cookies.
Log4j is another example of attackers targeting software that’s integrated into core IT supply chains. However, Log4j represents a much greater risk than some of its predecessors, because it’s widely associated with multiple operating systems and websites exposed to the internet. As a result, attackers are scrambling to use it as quickly as possible to gain a foothold in environments and leverage it to deploy sophisticated attacks, such as ransomware. I think this will be the first of many breakouts that target, not common software packages, but their dependencies/third party components.
Time is critical in this situation, and vulnerability discovery is the first step to protecting your organization from exploitation. Connect with NetSPI to learn how we can help you with our Log4j Vulnerability Assessment: https://www.netspi.com/contact-us/.
