cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Not a customer? Start a free trial

Click the Start a free trial link to start a 15-day SaaS trial of our product and join our community as a trial user. If you are an existing customer do not start a free trial.

AppDynamics customers and established members should click the sign in button to authenticate.

Java (Java Agent, Installation, JVM, and Controller Installation)

Log4j - vulnerabilities - version 2.17.1 and before

Billy.Cole
Producer

Log4j - vulnerabilities - version 2.17.1 and before

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

By replying you agree to the Terms and Conditions of the AppDynamics Community.
Log4j - vulnerabilities - version 2.17.1 and before
2 REPLIES 2
Billy.Cole
Producer

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"

 

This Log4J instance is within the singularity jars, and that version of Log4j was code branched in 2017 and does not include the JMSAppender which is the affected class for this vulnerability.

 

Machine Agent is NOT vulnerable to this CVE because the singularity0log4j doesn’t bundle JMSAppender.”

Tags (1)
Ryan.Paredez
Community Manager

Hi @Billy.Cole,

 

Thanks for sharing all this wonderful info on the Community!

We'd like to note and share some additional resources for yourself or anyone else who comes across this post.

 
  1. Link to the Security Advisory: Apache Log4j Vulnerability
  2. Security Advisory: CVE-2021-45105 in Apache Log4j
  3. Community News & Announcements Privacy and Security label (which has current info about Log4j)

Feel free to comment on any of those existing pieces of content as well. 

 

Thanks again for sharing!


Thanks,
Ryan, AppDynamics Community Manager



Found something helpful? Click the Accept as Solution button to help others find answers faster.
Liked something? Click the Thumbs Up button.