Tracking Down Log4j: Where to Start . Device42 recommends a prioritized approach to identify targets with recently discovered log4j vulnerability.
- Priority 1: Check public-facing servers
- Priority 2: Check applications with sensitive information and/or those with known vulnerabilities
- Priority 3: Check all other servers with possible vulnerabilities in command arguments, package managers, and/or vulnerable JDK versions
To make sure you don’t miss any instances of these vulnerabilities, we highly recommend that you use code scanning tools and other methods to find Log4j
Where to Begin
On December 10, we learned about a critical vulnerability in Apache Log4j. Researchers have since discovered second and third vulnerabilities that affect many different software products. Attacks have already started. We discussed this important issue and how you can start identifying it with the help of Device42 in a previous blog entry. However, many questions remain.
For complex/Hybrid IT environments, a big question is how to prioritize what machines to target for remediation first?
Here’s our take on prioritization, along with examples of some of the reports Device42 provides to help you discover and understand the underlying infrastructure.
Priority 1:
- Evaluate all public-facing servers (internet connected)
This is where you should start focused efforts because Log4j’s LogShell bug (CVE-2021-44228) allows for remote code execution on vulnerable servers. These internet connections are the channels for this dangerous remote control, which can include the deployment of ransomware and malware. By checking all these connections first and remediating the Log4j problems here, you can start building a virtual wall around your IT enterprise that prevents potential remote code execution at the source.
Device42’s application dependency mapping (ADM) query function gives you the information you need to do this successfully. Use it to filter discovered communications by public IP connections to the server or behind an F5 with a public IP connection. Device42 features dashboard report templates that make finding this information easy.
We have prepared some Device42 object query language reports that can be executed to provide a report of vulnerable software and the servers in which the software is running. These queries can be found on the Device42 Github here:
- Report for Software Packages of Vulnerable Vendors
- Report for Application Components with Log4j in the Parameters
We have also created PowerBI dashboards to show you potentially vulnerable servers. The Device42 Log4j Dashboards can be found on the Device42 Github here.
We have also made reports available for our Advanced Reporting, available for download on our Github here.
Detailed instructions on how to add these reports to your own instance of Device42 are in the previous blog.
Here’s what the public and private communication dashboard looks like.
Log4j Public and Private Communication Dashboard
This dashboard shows infrastructure within your network that has connections to the public internet. Client systems show who is sending the most number of connections to the internet. Listener systems show who receives the most connections to the internet. This dashboard and others are available on the Device42 Github here.
Priority 2:
- Assess all applications and servers with database access to sensitive or personally identifiable information (PII) and software that is known to have the vulnerabilities.
This is the next priority because, aside from enabling hackers to take control of resources in your enterprise, Log4j can also give them access to your most sensitive data. According to Microsoft, hackers are actively using, “credential theft and lateral movement, and exfiltrating data from compromised systems.” To prevent this, you need to know where you’re exposed.
You can find these potential targets by using Device42’s ADM query function, but this time filter the query by the application’s connection to a database application one or two layers down in the stack. For defined Business Applications, do the same query across selected Business Applications. See our previous blog for details on using Device42 to find vulnerabilities in applications known to have them.
Below is an example of our CISO Compliance Dashboard.
Log4j CISO Compliance Dashboard
This dashboard shows system infrastructure points that may be susceptible to attackers. It indicates production systems with connections to non-production environments and port communications that are commonly exploit. This dashboard and others are available on the Device42 Github here.
Priority 3:
- Check other servers with possible vulnerabilities in detected command arguments, Log4j installed through package managers, and/or vulnerable JDK versions installed through package managers.
Finally, you should be vigilant about finding vulnerabilities hidden throughout your enterprise. It’s a pervasive Java library that affects a long list of big-name enterprise applications, custom apps, and cloud computing services.
Use the Device42 report for Application Components with Log4j in the Parameters to help identify these potential risks.
Remember that Device42 does not scan code or find instances of log4j that are not install using a package manager. You’ll also need to use code scanning tools or tools of your choice to find all instances of Log4j.
Resource : Tracking Down Log4j: Where to Start (device42.com)
Software Asset Management CyberSecurity Consultants in the Middle East (gcst.ae)