REMOTE CODE EXECUTION VULNERABILITY IN LOG4J LIBRARY

See latest update

Summary

An unauthenticated remote code execution exists in the popular Java library ‘Apache Log4j 2’. This library is used by many Java-based applications for logging purposes. The vulnerability allows an attacker to execute arbitrary code within the Java process.

In short: applications that are remotely accessible, can handle user-input and use Log4j (version lower than 2.16.0) to log this input are potentially vulnerable.

If an attacker is successful in exploiting the vulnerability, they are able to execute arbitrary code and subsequently take over the server running the vulnerable application. The entire attack can be carried out remotely and without requiring authentication. From the vulnerable server, the attacker can obtain access to the rest of the network. Because of these reasons, we classify the impact of this vulnerability as high.

What can you do

What steps to take next

Northwave published a guide on the steps to take next. This guide can be found on https://northwave-security.com/log4j-what-steps-to-take-next/

Mitigation

A new version of Log4j, version 2.16.0, is available at this moment https://logging.apache.org/log4j/2.x/download.html.

If any of the applications you have built yourself contain the Log4j package, we urgently advise to upgrade to the newest version and deploy the new package.

For third-party applications you are using, we advise to contact the vendor for any updates.

If, at this very moment, upgrading is not possible, there are the following mitigation alternatives:

  1. All versions:
    1. Removal of the class “JndiLookup” from the Java Classpath (e.g.: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class )
  2. All versions < 2.16
    1. Consider taking the applications offline

Detection

The only method to determine with reasonable certainty whether you have vulnerable versions of Log4j is to recursively scan the filesystem, including unpacking JAR files and other archives. A local scanner written by Lunasec can be found on Github https://github.com/lunasec-io/lunasec/releases. DTACT has released a  local scanner that has the capability to detect Log4j in docker images. This scanner can be found on the following Github https://github.com/dtact/divd-2021-00038–log4j-scanner.

For urgent support, you can involve the Northwave CERT through 0800-1744 / +31 850 437 909

Important links:

Updates:

DATE: 17-12-2021

Update: What steps to take next

Northwave has published a guide on how to prepare for any Log4j related impact.

See: https://northwave-security.com/log4j-what-steps-to-take-next/

DATE: 17-12-2021

Update: CVE-2021-45046 upgraded to CVSS 9.0

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This results in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on macOS but no other tested environments.

See: https://logging.apache.org/log4j/2.x/security.html

DATE: 16-12-2021

Update: VCENTER WORKAROUND

Our Threat Responses previously mentioned that the VMware workaround instructions for vCenter 6.7 were insufficient. Further investigation together with VMware shows that our conclusions about the Update Manager mitigation steps were incorrect. Sine the workaround instructions by VMware have been subject to change in the past few days based on new insights, we recommend VMware customers to double-check whether they performed all of the current instructions as referenced in VMSA-2021-0028.3.

Northwave Threat Response: https://northwave-security.com/threat-response-update-2-threat-response-remote-code-execution-vulnerability-in-java-log4j-library/

VMware: https://www.vmware.com/security/advisories/VMSA-2021-0028.html

DATE: 15-12-2021

Update: Earlier mitigations and updating to Log4J 2.15 could be insufficient

According to Lunasec, due to the newly found vulnerability tracked under CVE-2021-45046 versions below 2.15 with the noMsgFormatLookups=true mitigation are vulnerable in certain cases.
Lunasec also mentions that while this CVE only mentions a denial of service attack. It could be possible that a potential remote code execution is found for version 2.15.

Therefore it is important to upgrade to Log4j version 2.16.0.

See: https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/

DATE: 14-12-2021

Update: Log4j 2.16.0 released

log4j 2.16.0 is out which now completely disables JNDI by default and removes support for Message Lookups. If possible, upgrade log4j to version 2.16.0.

See https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

DATE: 13-12-2021

Update: Cisco Talos observes email based exploitation attempts

The following email based exploitation attempt was observed by Cisco Talos.

See https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html

DATE: 13-12-2021

Update: Java version update is not sufficient.

Update Log4j to the latest version as updating the java version alone will not mitigate this exploit.

See: https://twitter.com/marcioalm/status/1470361495405875200

DATE: 13-12-2021

Update: Botnets adopt Log4j vulnerability

The MIRAI and Mushtik botnets are actively abusing the Log4j vulnerability.

See: https://blog.netlab.360.com/threat-alert-log4j-vulnerability-has-been-adopted-by-two-linux-botnets/

DATE: 13-12-2021 | TIME: 07:02

Update: First known ransomware using Log4j

https://twitter.com/80vul/status/1470272820571963392

DATE: 12-12-2021 | TIME: 07:02

Update: First signs of exploitation seen on December first.

According to the CEO of Cloudflare,the first signs of exploitation can be traced back to December first.

https://twitter.com/eastdakota/status/1469800951351427073

DATE: 12-12-2021 | TIME: 16:00

Update: NCSC releases maintained list of vulnerable applications

https://www.ncsc.nl/actueel/nieuws/2021/december/12/kwetsbare-log4j-applicaties-en-te-nemen-stappen

https://github.com/NCSC-NL/log4shell

DATE: 12-12-2021 | TIME: 16:00

Update: Cloudflare deploys mitigation for all cloudflare services

Cloudflare will now actively block any detected exploit attempt.

See:https://blog.cloudflare.com/actual-cve-2021-44228-payloads-captured-in-the-wild/

DATE: 10-12-2021

Update: Northwave releases online Log4j vulnerability checker.

https://github.com/NorthwaveSecurity/log4jcheck/

DATE: 09-12-2021

Update: Lunasec releases vulnerability

https://www.lunasec.io/docs/blog/log4j-zero-day/

Heeft u vragen? Of kunnen wij u ergens anders mee helpen, neem dan contact met ons op.

Neem contact op
12
12
123

Contact

Tel: +31 (0)30 303 1240
E-mail: [email protected]

Van Deventerlaan 31-51
3528 AG Utrecht

PO 1305, 3430 BH, Nieuwegein

—

Locatie België:

A. Reyerslaan 80, 1030  Brussel

SECURITY & PRIVACY OFFICE

Security Office as a Service
Privacy Office as a Service
State of Security Assessment
Consultancy & Audits

BUSINESS

Security & Privacy Policies
ISO 27001
AVG Compliance
Cyber Resilience

BYTES

Red Team
Penetration Testing
Vulnerability Management
SIEM  & SOC
End Point Detection & Response
Cyber Threat Intelligence
CERT Forensic Investigations

BEHAVIOUR

Security Awareness
Online Learning By Doing
Phishing
Cyber Crisis Exercises
Security Training

Responsible Disclosure

Privacyverklaring

Meldregeling

Threat Response: Remote Code Execution vulnerability in Log4J libraryThreat Response – Update: Remote Code Execution vulnerability in Java...