Community,
If have been out on a deserted island, there were a few NIST vulnerabilities reported that has impacted AppDynamics controllers (saas and on-prem) and a number of Java based agents.
The main reason why I am authoring this thread for the community is to hopefully offer my perspective but also humbly request that if I got something wrong or missed something, you take the five minutes to call it out and help myself/others understand better the nature of this beast.
Vulnerabilities seem to be falling into three buckets.
1. Directly - Has the Apache log4j jars (core) with a version that is impacted
2. Indirectly - A library jar has the log4j jars within it (nested jars)
3. Diverged - At some point the log4j source was branched and modified to a custom version
1. Case - machine agent within the <agent home>/lib/log4j-core-2.x.jar
2. Don't have a good example of this for AppDynamics
3. Case - machine agent within the <agent-home>/lib/singularity-log4j-1.2.15.6.jar within the
singularity-log4j-1.2.15.6.jar\com\singularity\util\org\apache\log4j\.
Within the third example there is a NOTICE file in the META-INF folder that has "Copyright 2017. AppDynamics modified from Log4j2. So the Log4J was after the end of life of 1.2.x and without a different detection method, we are unsure if the vulnerabilities that plague us are within this variant (yes, Loki reference)
Now we can get into the detection methods.
By File Name
For case 1, it is a simple directory listing and search for log4j*. Case 2 gets a bit messy since each of the JAR files have to be listed to search for Log4j. The third case, is much like case 2, but we get into a mess since as exampled above the file name is mauled up with "singularity".
By JVM Class presence
For each of the three cases, this method requires another Java class is injected into the JVM that can then attempt to access the log4j vulnerability, be that to execute a JNDI lookup or to capture and de-seralize a message packet.
By Directed Attack
Some of the vulnerabilities have exploits in the wild and those exploits have already been deployed against a number of targets with very destructive results.
Now the majority of the vulnerabilities scan vendors are continuing to fine tune their scan patterns but to be 100% sure, IMHO, there really needs to have a Java class injection that pulls the in memory Log4J class references and probes them, especially with the diverged variants.
------- Laundry list of vulnerabilities --------------
https://nvd.nist.gov/vuln/detail/CVE-2021-44228 10.0 Critical
Impacts log4J 2.x
https://nvd.nist.gov/vuln/detail/CVE-2021-45046 9.0 Critical
Impacts log4j 2.16.x
https://nvd.nist.gov/vuln/detail/CVE-2021-45105 5.8 Medium
Impacts log4j 2.17.x
https://nvd.nist.gov/vuln/detail/CVE-2021-4104 7.5 HIGH
Impacts log4j 1.2.x - basically 1.2 end of life in 2015 but there was another vulnerability found. "deserialization of untrusted data when the attacker has write access to the Log4j configuration"
Thank you,
Billy Cole
