Alert Logic is actively investigating a new remote code execution (RCE) vulnerability, CVE-2021-44228, within Java logging library Apache Log4j 2. Log4j 2 is an open-source Java package that can be used for logging in many applications such as Apache Solr and Apache Struts, as well as many SaaS services, such as Steam, Apple iCloud, Twitter, and Minecraft.
Since the discovery of CVE-2021-44228, three related vulnerabilities of lower severity have been announced: CVE-2021-45046, CVE-2021-45105, and CVE-2021-4104.
It is recommended for customers running Log4j 2 versions 2.0 to 2.16.0 to upgrade to version 2.17.0 to mitigate these vulnerabilities. CVE-2021-4104 affects an older version of Log4j (1.2) and will not be patched. For more information about mitigation, refer to the Recommendations for Mitigation section in this article.
Alert Logic products, including appliances and agents, are not affected by these vulnerabilities. Additionally, Alert Logic internal infrastructure has not been impacted.
Vulnerability Description
Dubbed as Log4Shell, CVE-2021-44228 can exploit any application that is utilizing Log4j 2 if it allows a remote connection to supply arbitrary data written to log files. Log4Shell can be exploited easily and without authentication by malicious attackers. This vulnerability impacts a wide variety of applications and services that use Log4j 2 for logging. Additionally, any products that are bundled with Log4j 2, such as Apache Solr and Apache Struts, are also affected.
This vulnerability has been given a maximum CVSS score of 10. Alert Logic has published a blog post with a deeper dive into this vulnerability and how attackers exploit it. Additionally, more information on this vulnerability can be found on the National Vulnerability Database page for CVE-2021-44228.
Since the discovery of this vulnerability, the following additional vulnerabilities have been announced.
- CVE-2021-45046: Under specific non-default configurations of Apache Log4j, this vulnerability allows an attacker that crafts a JNDI lookup using malicious input data to cause a Denial of Service (DoS) condition or achieve RCE on a vulnerable server.
- CVE-2021-45105: Also in non-default configurations, this vulnerability allows an attacker to send a crafted request that contains a recursive lookup and cause a DoS condition.
- CVE-2021-4104: This vulnerability is similar to CVE-2021-44228 but occurs in an older version of Log4j – version 1.2. Version 1.2 is not vulnerable by default, and requires some very specific local changes to exploit. Successful exploitation of this vulnerability can be detected by the same signatures designed to detect exploitation of CVE-2021-44228.
More information about these vulnerabilities is available in Apache's security vulnerability documentation.
Alert Logic Coverage
Vulnerability Scanning: Alert Logic has released authenticated scan coverage to identify this vulnerability in protected assets. Additionally, Alert Logic has released unauthenticated detection through PCI scanning.
Network IDS: Alert Logic has deployed over 100 signatures designed to detect attacks targeting this vulnerability. These signatures are designed to catch:
- Initial attack traffic targeting the vulnerability
- Evasions in the attack traffic
- Initial indications of a successful attack, including cases where the targeted system reaches out to the internet
- Post-compromise activity associated with the attack
- Suspicious behavior associated with hosts known to be involved with the attack
Web Application Firewall: As this exploit continues to evolve, Alert Logic has taken the following actions:
- Standard signatures have been updated to include detection for CVE-2021-44228.
- A new signature has been developed to detect CVE-2021-45046 and CVE-2024-45105 that can be applied to your device upon request. If you are concerned about DoS attacks due to these vulnerabilities, submit a ticket to the Alert Logic Security Operations Center to request this signature.
Log Management: Alert Logic has released telemetry signatures to help our Security Operations Center monitor customer environments for exploitation of this vulnerability.
Recommendations for Mitigation
Alert Logic recommends that all customers upgrade to version 2.17.1 of Apache Log4j 2, which will mitigate both these vulnerabilities and the newly CVE-2021-44832 being released. If customers are unable to upgrade, customers should follow the guidance from Apache based on their version.
For more information, refer to the guidelines in Apache's security vulnerability documentation.
Updates
This section will be updated with new information about this vulnerability and related Alert Logic coverage as it becomes available. To follow updates for this vulnerability, click FOLLOW at the top of this article. You must be signed in to the Support Center using your Alert Logic product credentials to follow this article.
12/11/2021: Alert Logic released authenticated scan coverage to identify this vulnerability in protected assets.
12/14/2021: On December 13 and 14, Alert Logic released several specific IDS signatures to detect attacks targeted at exploiting this vulnerability.
12/14/2021: Apache has updated their guidance for mitigating this vulnerability. It is now recommended to update to Apache Log4j 2.16.0. More details are available in Apache's security vulnerability documentation.
12/14/2021: Alert Logic released unauthenticated detection through PCI scanning.
12/18/2021: Apache has updated their guidance for mitigating this vulnerability. It is now recommended to update to Apache Log4j 2.17.0 due to related additional vulnerabilities. More details are available in Apache's security vulnerability documentation.
12/21/2021: This article has been significantly updated to include information about additional, less critical CVEs discovered in Apache Log4j after the initial discovery of CVE-2021-44228. Additionally, more context has been added to the article about Alert Logic's detection capabilities through network IDS and web application firewall.
Comments
21 comments
To be frank having a software/library manifest (e.g. from Software Composite Analysis tools - Snyk etc) will be more useful in identifying vulnerable versions of log4j. For most this is a 'challenge' to tackle with the Dev/DevOps folks rather than Infrastructure.... Then there is a massive log tail of packaged software updates and notifications from SaaS suppliers (who may be using log4j). For those who haven't already seen this, it might be useful: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Hi Steven Damiani - If a scan finds that one of your protected assets is vulnerable to CVE-2021-44228, a new exposure will be listed on the Exposures page in the Alert Logic console. You can search on the Exposures page by the CVE to see if you are vulnerable.
Hi Anwar Hayath - The detection was pushed to appliances on Friday at midnight, so your appliance should already have it.
Otto Aulicino - We are still researching and testing our agent-based scanning capabilities in regards to this particular vulnerability. I will keep you posted here as I learn more. The recommendation for now is to run an authenticated internal scan for the most accurate detection.
Kirsten Flores, thank you. In our testing it appears there are some shadows with detections. It would appear to be more successful, it's going to need to look within the JAR files and/or their manifests to extract enough information for complete results. Hopefully the scanning approach can continue to mature.
@... - Sorry, I think I only half answered your question. In addition to the authenticated scanning for internal scans, we also can detect vulnerable versions via unauthenticated (non-credentialed) PCI scans.
Hi @... - You can schedule external, internal, PCI scans in the Alert Logic console, all within the Scan Schedules feature. If your standard scan schedules are internal scans, our scanning coverage will detect vulnerable versions of Apache Log4j for any in-scope assets as long as you have added credentials for the scan, making it an authenticated scan. If a vulnerable version is found, an exposure will be raised on the Exposures page in the Alert Logic console.
So we have PCI scanning detection, but what about the standard scan schedules? Are these different?
This article has been significantly updated to include information about additional, less critical CVEs discovered in Apache Log4j after the initial discovery of CVE-2021-44228. Additionally, more context has been added to the article about Alert Logic's detection capabilities through network IDS and web application firewall.
Apache has updated their guidance for mitigating this vulnerability. It is now recommended to update to Apache Log4j 2.17.0 due to related additional vulnerabilities. More details are available in Apache's security vulnerability documentation.
On December 14, 2021, Alert Logic released unauthenticated detection through PCI scanning.
Apache has updated their guidance for mitigating this vulnerability. It is now recommended to update to Apache Log4j 2.16.0. More details are available in Apache's security vulnerability documentation.
Additionally, on December 13 and 14, Alert Logic released several specific IDS signatures to detect attacks targeted at exploiting this vulnerability.
Jason Lebaron - Thank you for your feedback. I will definitely pass on your comments to our scan team. If you have any immediate concerns about your scans and detecting log4j versions, please let me know and I'd be happy to start a ticket for you for further investigation.
On December 11, 2021. Alert Logic released scan coverage to identify this vulnerability in protected assets.
Kristen, will the agent-based vulnerability scan also do the job, in the absence of a successful vulnerability scan?
Hi Jason Lebaron - The authenticated scan determines the version by logging into the host and running a command that lists all packages.
Kirsten Flores, is it looking within the various JAR files for that version, or just specific files? Or logs? Thank you
Hi Otto Aulicino - An authenticaed scan (a scan with credentials) will check for the version of Apache log4j. An exposure will be raised if the version of Apache log4j is between 2.0-beta 9 and 2.14.1.
Is it possible to know what is the signature checking for, specifically for the vulnerability scanning?
How to confirm if the detection is made available on our appliance. Is there a way to force update the detection/signature on appliances, to ensure it uses the latest detection. Dont want to run scan and later to find out appliance was missing this detection.
please let me know if the scan against protect assets should use the cve-2021-44228 and or a different search criteria, thank you
Please sign in to leave a comment.