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.
Watch this page for updates | Click the 3-dot menu upper right, then Subscribe
We will further update this guidance as we continue to learn from our investigation.
Revised December 23, 2021
On December 9, 2021, a vulnerability CVE-2021-44228 in the Apache Log4j Java logging library was disclosed, which could result in remote code execution. On December 14, 2021, another Log4j vulnerability CVE-2021-45046 was disclosed, which could result in a denial of service. CVE-2021-45105, affecting Java 8 and higher environments, was released on December 17.
As an immediate response, the AppDynamics team confirmed the capabilities of Cisco Secure Application to help our customers investigate these Log4j related vulnerabilities, detect them, and block exploits.
Following, we will cover how our customers using Cisco Secure Application can:
Cisco Secure Application is uniquely capable of enforcing a single policy across all applications that blocks vulnerable Java classes from establishing any network connection regardless of the application interface with negligible performance impacts and is impervious to obfuscation.
It does this all with the operational benefit of being integrated into the AppDynamics APM Java Agent to provide simplified deployment and code-level application context. This combination of ease of use, precision, and performance is an essential addition to a defense-in-depth strategy to protect your applications in production.
NOTE | In order to use AppDynamics with Cisco Secure Application to protect your applications, ensure that all steps from the Getting Started documentation are completed.
NOTE | In this example, we used the CVE-2021-44228, otherwise known as the Apache Log4j2 JNDI vulnerability, where malicious individuals can backdoor-execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled (which was the default.)
Please refer to the Apache Security Vulnerabilities page for more details. https://logging.apache.org/log4j/2.x/security.html
Another way to view and determine where vulnerabilities lie is by looking at global libraries. Here we’ve looked for which libraries contain Log4j.
See indication of remediation, which in the CVE-2021-44228 example is the 2.15.0 version of Log4j. However, remediation of CVE-2021-45046 requires 2.16.0.
Now that we have identified the vulnerability and affected libraries, as well as the status, we must create a policy to further protect any new application or use of the library in our environment.
If this is a new policy, select Network or socket access name, and continue with the following steps for updating existing policies.
NOTE | The action that you specify within the rule supersedes the default action specified in Default Action.
|Name||Network or socket access (NETWORK)|
|Rules||If stack trace contains org.apache.logging.log4j.core.net.JndiManager.lookup, then Block
Use the Search filter to confirm that no other Network or socket access policies exist which would supersede the newly defined policy.
It’s essential to review whether someone exploited this vulnerability, which could lead to them taking complete control of your application and underlying systems. In these steps, you’ll look for exploits of CVE-2021-44228 that resulted in shell command execution. You’ll also search for a blocked attack attempt.