CVE-2021-44228: Critical vulnerability in Apache Log4j library [Live Updates]

What’s at stake

Log4j is a java library used broadly in enterprise system and web applications, reportedly affecting servers operated by Apple iCloud, Cisco, Microsoft (Minecraft), Cloudflare, Twitter, Tencent and other major service providers. The Log4j vulnerability, also known as Log4shell, is caused by a bug in the Log4j library that can allow attackers to gain control over log messages to execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. The remote code execution (RCE) vulnerability CVE-2021-44228 affects versions from Log4j 2.0-beta9 to 2.14.1 and received a maximum CVSS rating of 10. Once weaponized it could allow a complete takeover of vulnerable systems from a remote and unauthenticated attacker.

Mitigating the Log4j vulnerability

According to ASF, Log4j version 2.15.0 has been released to address this flaw. The first step is to scan your environment and check if you are using vulnerable Log4j versions. If a vulnerable version is detected, update to the latest version as soon as possible. If update is not possible this behavior can be mitigated with workarounds in system property setting.

This vulnerability is in its nature somewhat different and behave similar to Apache Struts – it’s hard to determine what products and applications are affected from the outside. For this reason, we will be releasing several detections over this week, to enhance testing for the vulnerability itself, as well as to detect affected products as vendors disclose impact and their mitigations. It is important that you keep regular vulnerability checks configured and running, and ensure authenticated scan is used where possible to check directly on any potentially affected systems.

For Outpost24 customers

Netsec products – OUTSCAN and HIAB – The Outpost24 Vulnerability Research Team are releasing checks on an ongoing basis as vendors release information on how they are affected, detection is available for system packages that are vulnerable. Our first detections went out on Friday December 10th, and we have continued to release updated detections throughout the weekend. More file system-based check to detect affected JAR-files are being released over this week, so please look out for the Support Portal announcements or check back here for any updates.

• Outpost24 has released an authenticated vulnerability check which scans through the file system of Linux/Unix based systems and their present JAR files to identify vulnerable versions of the Log4j component. This is an in depth scanning feature which will detect vulnerable components which would be impossible to detect without authentication. [Updated 13 Dec 19:02 CET] 
• Outpost24 has released an authenticated vulnerability check which scans through the file system of Microsoft based systems and their present JAR files to identify vulnerable versions of the Log4j component. This is an in depth scanning feature which will detect vulnerable components which would be impossible to detect without authentication. [Updated 14 Dec 01:20 CET]

Just days after the critical vulnerability was disclosed, another Apache Log4j vulnerability CVE-2021-45046 was found, affecting all versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0, with a much lower CVSS score at 3.7. It found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allow attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup or a Thread Context Map pattern to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. Outpost24 has released authenticated vulnerability checks to detect this - for use in HIAB, an update is required; for Outscan, scaningless scans have been triggered for scans that already ran and found the version. [Updated 15 Dec 10:23 CET]

On 18 December, another DOS vulnerability CVE-2021-45105 was disclosed in Log4j. In a statement they explain "Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack." Outpost24 has released authenticated vulnerability checks to detect this - for use in HIAB, an update is required; If you have run a scan since Friday 17 December, the systems will be able to match the rule against known facts and no rescan is needed. [Updated 20 Dec 12:10 CET]

On 28 December, ASF rolled out fresh patches to contain an arbitrary code execution flaw in Log4j that could be used to run malicious code on affected systems, making it the 5th security vulnerability disclosed in a month. The latest CVE-2021-44832 is rated with a CVSS 6.6 and impacts all versions of the logging library from 2.0-alpha7 to 2.17.0 with the exception of 2.3.2 and 2.12.4. While Log4j versions 1.x are not affected, users are recommended to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). Outpost24 have prepared new vulnerability definitions and are deploying those at the moment, the updated definitions will work with ScanningLess Scanning (SLS). While this vulnerability is a remote code execution based on the same method as earlier, it require an attackers ability to make changes to the connector for the Log4J tooling and are substantially harder to exploit due to this pre-condition. However, even though the same method used for remote inclusion is utilized, earlier workarounds do not mitigate this risk as the directive to not include remote content is not checked by the vulnerable code.. [Updated 28 Dec 11.10 CET]

Appsec products – SWAT/SNAPSHOT/ASSURE – The teams have created tooling for checking web applications we have under service. This is platform agnostic but rely on the ability of getting callbacks from the audited systems during the security checks. The checks will be adapted as needed throughout the coming days to reflect the collective efforts of the security community in enhancing this form of detections.

To help our customers get ahead of the vulnerability, we have proactively reviewed the environments of all Outpost24 customers with premium Appsec services. Affected customers can see their finding in the portal and will be notified directly. [Updated 13 Dec 15:15 CET] 

Outpost24 environments and products – We have reviewed our platforms HIAB and OUTSCAN, which are not affected. This include Netsec, Compliance, Appsec, Managed Service reporting platform, Offensive Security reporting platform, Cloudsec, in their different distribution forms. We have identified third party components not related to the operations environments and performed patching and will continue to monitor it internally.

Outpost24 Outscan performance - As a result of the many Log4j detections we have released since Friday, use of our Outscan product has increased dramatically. This is in part due to active customers initiating comprehensive scanning to determine their risk posture, as well as the Scanless scanning feature being triggered on each new detection we release. This combination of usage has created peak loads and slow response times. Users may see a scan pending completion with a message "Waiting for report". To correct this situation, we have scaled up additional scanning capacity in our network and made several operational adjustments to reduce performance bottlenecks.  These changes are yielding performance improvements but we expect continued heavy loads in the near future. We are monitoring Outscan operation closely and will make further adjustments as needed. [Updated 16 Dec 21:56 CET] 

Outscan has been performing as normal since 17 December [Updated 17 December 14:10 CET] 

Outscan performance has remained stable since [Updated 18 December 08:10 CET]

At Outpost24 we'll continue to monitor the vulnerability and the threat landscape to provide more updates as the situation develops. If you require further assistant in the meantime please contact customer support.