Search

Log4J – leverantörsinformation

Här kan ni hitta en sammanställning över länkar från leverantörer med information kring  Log4J (CVE-2021-44228)

 

Log4J – leverantörsinformation, listan kommer att uppdateras.

Axonius

Have provided some queries for finding software using Log4j -> https://www.axonius.com/blog/tracking-log4shell-and-related-applications-with-axonius

 

CheckPoint

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk176865

https://blog.checkpoint.com/2021/12/11/protecting-against-cve-2021-44228-apache-log4j2-versions-2-14-1/

 

Cybereason

The Cybereason research team has developed the following code that exploits the same vulnerability and the payload therein forces the logger to reconfigure itself with the vulnerable setting disabled – this effectively blocks any further attempt to exploit Log4Shell on this server.

Link about the “vaccine”: https://github.com/Cybereason/Logout4Shell

Cybereason is aware of the vulnerability and has completed verification that this issue does not affect Cybereason products or services.

https://nest.cybereason.com/niyusu/cve-2021-44228-apache-log4j-vulnerability

F5

https://support.f5.com/csp/article/K19026212

 

Microsoft

https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

 

Okta

https://sec.okta.com/articles/2021/12/log4shell

 

PaloAlto

https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/

A remote code execution (RCE) vulnerability in Apache log4j2 was identified being exploited in the wild. Public proof of concept (PoC) code was released and subsequent investigation revealed that exploitation was incredibly easy to perform. By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload. Due to the discovery of this exploit being so recent, there are still many servers, both on-premises and within cloud environments, that have yet to be patched. Like many high severity RCE exploits, thus far, massive scanning activity for CVE-2021-44228 has begun on the internet with the intent of seeking out and exploiting unpatched systems. We highly recommend that organizations upgrade to the latest version (2.15.0-rc2) of Apache log4j 2 for all systems.

Affected Version: Apache Log4j 2.x <= 2.15.0-rc1

See the Unit 42 threat brief for additional details on the attack, product updates, and courses of action.

 

BEST PRACTICE: Palo Alto Networks strongly recommends that organizations upgrade to the latest version (2.15.0-rc2) of Apache log4j 2 for all systems.

The Cortex XDR research team has investigated the above vulnerability and we are happy to announce that Cortex XDR linux agent running on version 7.0 and above, will block the known POCs our research team investigated of CVE-2021-44228*.

 

To ensure you are receiving alerts and monitoring any exploitation attempts:

  • Upgrade Cortex XDR linux agent to version 7.0 or higher
  • Verify that your agent is on content update 290-78377
  • Do an agent check-in
  • Restart every service that might have java in it and specifically: 
    • Apache Struts
    • Apache Solr
    • Apache Druid
    • Apache Flink
    • ElasticSearch
    • Flume
    • Dubbo
    • Logstash
    • Kafka
    • Spring-Boot-starter-log4j2
  • Suggested to restart the entire server for the protection to work on all services
  • The exploit attempt will be blocked by the Java Deserialization Exploit protection module which is automatically activated when you enable Known Vulnerable Processes Protection in the Linux Exploit Security profile. We highly recommend making sure the Known Vulnerable Processes Protection module is set to block (which is the default configuration). Once the module is set to block (which is the default configuration) Cortex XDR agent will block this activity and raise a Suspicious Input Deserialization alert.

*Notice that alpine environments using musl instead of libc are not covered by the java deserialization module and have coverage of some post-exploitation techniques leveraging this exploit using Behavioral Threat Prevention. Scanning attempts will not be prevented, only a full exploit chain. SElinux enabled or permissive mode hosts do not have the Java Deserialization Module and are not protected.

 

Splunk

https://www.splunk.com/en_us/blog/bulletins/splunk-security-advisory-for-apache-log4j-cve-2021-44228.html

 

Other great resources:

Incident Response Hotline

Facing cyber incidents right now?

Contact our 24/7/365 world wide service incident response hotline.