Dec. 29: Updated to cover three additional CVEs: CVE-2021-4104, CVE-2021-44832, and CVE-2021-42550 (in logback as opposed to log4j).
Dec. 22: A joint Cybersecurity Advisory was issued by multiple national cybersecurity agencies providing mitigation guidance on addressing vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105.
Dec. 17: Please note the emergency directive from CISA on Log4j. The ED requires action for federal civilian agencies to mitigate these vulnerabilities. CISA encourages all organizations to take similar steps.
Dec. 16: Additional ModSecurity rules for Log4j CVE-2021-45046 were added. Additional Trustwave product information was added.
Dec. 15: TrustKeeper Scan Engine Update information was included. Statement on MailMarshal and associated features not being affected also included.
Dec. 14: Updated with information on IDS updates and MailMarshal Email filter updates.
Dec. 12: Updated with information on ModSecurity rules for Log4j zero-day exploits and the latest mitigation steps from CISA.
Dec. 10: Trustwave MDR Advanced customers provided vulnerability details and emerging threat intelligence utilizing Fusion security incidents and notifications. Security incident tickets begin to be sent to customer incident contacts using Fusion platform where actionable behaviors are identified through hunt processes.
Dec. 10: Fusion detection content created and updated provided vulnerability details and emerging threat intelligence. Security incident tickets and notifications begin to be sent to customer incident contacts using Fusion platform where actionable behaviors are identified through detection and response processes. Ongoing action as vendors release updates for variants and additional policy updates.
Dec. 10: Trustwave initiates work with STM vendors on affected platform assessment and initiates software and policy updates to protect and detect exploitation of CVE-2021-45046 for customers. Ongoing action as vendors release updates for variants and additional policy updates. Activity communicated to customers through Fusion cases and change tickets.
------------------------------------------
Trustwave security and engineering teams became aware of the Log4j zero-day CVE-2021-44228 overnight on December 9 and CVE-2021-45046 on December 14. We immediately investigated the vulnerabilities and potential exploits and continue to monitor the situation as new Log4j vulnerabilities are released.
Trustwave infrastructure has not been adversely affected by the vulnerability / exploit. Where there was potential for abuse via the exploit, we have remedied this in our environments. We are taking a proactive response and actively hunting for the presence of attacks via Log4j.
We are diligently watching over our customers for exposure and associated attacks, as we are able to detect the exploits in the wild. We are taking action with approved mitigation efforts.
Trustwave MDR Advanced Clients:
Trustwave MDR Advanced clients have been advised of the active threat hunt activity that has occurred via Fusion and standard processes.
Trustwave Product Information:
CVE-2021-44228: In Apache Log4j2 versions up to and including 2.14.1 (excluding security release 2.12.2), the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP, DNS and other JNDI related endpoints.
An attacker who can control log messages or log message parameters can execute arbitrary code loaded from malicious servers when message lookup substitution is enabled.
CVE-2021-45046: It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete for 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 (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.
Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default. Note that previous mitigations involving configuration such as to set the system property log4j2.formatMsgNoLookups to true do NOT mitigate this specific vulnerability.
CVE-2021-45105: This vulnerability was disclosed on December 16 and carries a CVSS base score of 7.5, or a high rating, and affects all versions of Log4j from 2.0-beta9 to 2.16.0, excluding 2.12.3. Log4j 1.x is not impacted by this vulnerability.
The vulnerability enables a remote attacker to cause a DoS condition or other effects in certain non-default configurations, the joint advisory said. Apache noted in an advisory that 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. In response, Apache released Log4j version 2.17.0 (Java 8).
CVE-2021-4104: Similar to the original RCE in CVE-2021-44228, but affects Log4j version 1.x Since this version in End of Life, the only patch available is to upgrade to Log4j 2.x.
CVE-2021-44832: An RCE vulnerability in non-default configurations that affects Log4j 2.17.0. This issue can be mitigated by upgrading to version Log4j 2.17.1.
CVE-2021-42550: (in logback as opposed to log4j): This vulnerability is not in Log4j, but rather in an alternative java logging package called "logback."
Information provided by the Apache security advisory.
Apache Log4j versions 2.17.0 and lower are vulnerable to multiple vulnerabilities including RCE and DoS.
The Apache Foundation issued a critical advisory and recommends users install the latest version, Log4j 2.17.1, and apply mitigations.
For more information on mitigations, please visit:
An assume-breach mindset is critical to adopt in the age of rampant zero-days. As with all zero-day vulnerabilities, there are basic steps an organization can take to protect itself before and after such a flaw is uncovered.