Trustwave's Action Response: Multiple Log4j Zero-Day Vulnerabilities

Updates:

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.

------------------------------------------

Summary of Trustwave Actions:

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:​

• The vulnerabilities CVE-2021-44228 and CVE-2021-45046 cannot affect MailMarshal (premise or cloud), WebMarshal, Marshal Reporting Console, or any of the premise Marshal plugins provided through Trustwave. None of these products or features use the affected module of Log4j.
• Currently shipping Trustwave AppDetectivePRO is unaffected by this vulnerability. AppDetectivePRO is a standalone application on Windows, not accessible from outside the host. There is an optional component offering a preview of Web application vulnerability scanning that bundles, but does not use, Log4j. Customers who would like to remove this optional component can contact our Product Support team for guidance.
• Trustwave DbProtect does use Log4j and our Product Support team can provide our customers with guidance on how to mitigate the issue until an update to the product is released in the coming weeks.

What are the Log4j CVEs?

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.

How To Identify if Your Organization Is at Risk:

Apache Log4j versions 2.17.0 and lower are vulnerable to multiple vulnerabilities including RCE and DoS.

Advisories and Mitigations for the Log4j Vulnerabilities:

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:

• Cybersecurity Infrastructure Security Agency (CISA)
• New Zealand's national Computer Emergency Response Team (CERT NZ)
• Emergency Directive from Cybersecurity Infrastructure Security Agency (CISA)

Trustwave Product Protections Issued:

• Trustwave has released ModSecurity rules to catch Log4j zero-day exploits:
  • Apache Log4j2 <= 2.14.1 JNDI RCE and DOS in Headers CVE-2021-44228 and CVE-2021-45046
  • Apache Log4j2 <= 2.14.1 JNDI RCE and DOS in URI CVE-2021-44228 and CVE-2021-45046
  • Apache Log4j2 <= 2.14.1 JNDI RCE and DOS in request body CVE-2021-44228 and CVE-2021-45046
• Trustwave has released an IDS update with detections for the Log4j zero-day exploits.
• Trustwave has pushed vulnerability detections in an update to MailMarshal Email Threats/KnownThreatsZero Day filter version 1912.
• TrustKeeper Scan Engine Update for December 15, 2021
  • New Vulnerability Test Highlights
    • Log4shell vulnerability detection active check.
    • Credentialed checks detecting Log4J2 on CentOS, Debian, Fedora, FreeBSD, RedHat and Ubuntu.

General Guidance on How to Mitigate Zero-Days Moving Forward:

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.

• Manage Your Assets: Depending on the software you are running, not every instance of a zero-day will affect you. An organization should conduct ongoing asset inventory and vulnerability assessments. Then uninstall any software that is no longer needed and on software still required disable any features that are not necessary. This action will decrease your potential attack surface and may eliminate the impact of certain zero-days that target the removed software or the disabled features.
• Break the Attack Kill Chain: A successful compromise involves many phases, which is good news for you because it gives opportunities to thwart an incursion before it can inflict maximum damage. To accomplish this, however, organizations must continuously monitor their network. Monitoring can be conducted by deploying a full stack of intelligent security products, using generic, behavior, and heuristic-based approaches to threat visibility and detection. Next, utilize threat hunting to search systems for vulnerabilities actively. This activity will help prevent attackers that use zero-day vulnerabilities from gaining initial entry and residing for extended periods in a network.
• Patch, Patch and Patch: Patching after a zero-day has impacted an organization may not stop that attack, but it's still important to ensure all available fixes have been applied. The zero-day may rely on other components to complete its attack. For example, a local privilege-escalation zero-day may exist, but if the system is patched against a remote-code execution vulnerability that is used in tandem with the zero-day, major harm will be avoided. In addition, remember that once the zero-day receives a fix, attackers will still exploit it - and those that are tardy to the patch party may be in for a rude surprise.
• Stay Informed: System Admins need to keep an eye on not only their systems but on the news as zero-day activity, along with other types of attacks, often make headlines. In addition, employees must be trained and made aware that their actions can have negative consequences. This includes clicking on a malicious link that could trigger a zero-day. While perfect behavior is impossible, it's still important to rely on workers, especially if the security products in place do not provide the proactive defense needed to address today's threats. And remember, security awareness programs don't need to be agonizingly boring - effective lessons get creative and use stories to motivate the troops.