For testing purposes, the BurpSuite Collaborator will be used. Now, let’s dive a bit more into the source code in order to identify the problem.
Specifically, two of these currently available extenders are the followingĪlso, a crucial point to the identification process is to regularly review SIEM logs, endpoint logs, or network traffic to identify matching patterns of potential exploitation attempts. These tools are, OWASP Dependency Check and OWASP Dependency Track which can detect the vulnerable libraries used in early phases of the development process.įurthermore, application penetration tests could be executed through the use of the BurpSuite professional tool, that has specific extenders which can be downloaded and used in order to identify the vulnerability. Moreover, regarding the versions of each library, and, in every development lifecycle, no matter the development methodology and approach, there are some tools that must be considered valuable to use before the release and deployment actions taking place. So, a crucial point is to determine the scope of the applications and the dependent services that are using the Log4j library.Ī good start to detect and handle the problem is by using internal and external vulnerability scanning tools (e.g., Tenable, Rapid7, Qualys, WhiteSource, etc.).Īnother interesting way to detect this issue is to use EDR tools to scan for JAR files (e.g., log4j-core or log4j-api), class files (e.g., JndiLookup.class), or process execution events associated with Log4j. The identification phase of this vulnerability is considered a time-consuming process as the log4j library can be found in many applications and third-party libraries across an organization. The following table is showing the impacted versions of the log4j library as per CVE, as well as the recommended versions that mitigate these issues.
As an example, the following payload format can be used in order to trigger the JNDI remote class loader into fetching and executing malicious commands from the context of the vulnerable Web service through a loaded serialized object This vulnerability resides in the way the Log4j parser handles special crafted log messages. However, this functionality may expose Web applications into a critical situation which provokes the potential of remote command execution.
In detail, Log4j provides a ‘Java Naming and Directory Interface'(JNDI) functionality used to retrieve variables and keys from JNDI resources using the jndiLookup class. Specifically, as per CVE-2021-44228, Apache Log4j2 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. This article presents a widespread critical issue that affects many Java applications.
0 kommentar(er)
