This is a security vulnerability in the Log4j logging utility that affects versions 2.0-beta9 through 2.14.1. Basically, it allows you to send a specific message that the targeted server will log. Message that activates the flaw, so that the server, via the JNDI API (connection to directories), contacts another where it retrieves the malicious code.

The level of risk is not the same depending on the version of Java. The main attack vector (LDAP) does not seem to be usable from 6u211, 7u201, 8u191 and 11.0.1. Other protocols (HTTP / S, DNS, etc.) can however still be used to load the code.

Who Raised The Alert?

The Apache Foundation – which manages Log4j – has pulled the alarm bell on 9 December. Since then, PoCs have multiplied . And a nickname emerged for the flaw: Log4Shell.
Atlassian, Boomi, Cisco, Docker, ESET have also issued alerts relating to Log4j in recent days .
The active business evidence has also accumulated. Among them, the dissemination of the Mirai and Muhstik botnets , known to convey in particular ransomware and cryptocurrency miners.

What Are The Risks?

• There are many risks for the Java applications that use it. They go as far as injecting – and executing – unwanted code remotely .
• Attacks are likely to bypass solutions, especially firewalls, both by exploiting alternative ports and by implementing obfuscation techniques.
• Cisco identifies around thirty affected departments. The Webex Meetings server is part of it… unlike the client. The projects of the Apache Foundation are not spared either. On the list there are, among others, Druid, Flink and Struts2.
• The implementation of attacks sometimes appears elementary. Changing the name of an iPhone has hit the mark on iCloud servers. Ditto for the Minecraft cat who uses the Java edition.
• It also seems possible to exploit existing code on the server even with the remote execution vector.

How To Protect Yourself?

Log4j 2.15.0   provides corrections to “padlock” JDNI by limiting both the usable protocols and the classes accessible via LDAP. For those who do not have the possibility to update, there are several workarounds which have in common to deactivate the StrLookup interface (thanks to which we can modify the configuration of Log4j).

• From Log4j 2.10, set to “true” the property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS
• On 2.7 and later, modify all logging schemes to eliminate lookups (by replacing% m by% m {nolookups})
• From 2.0-beta9 to 2.10.0, remove the JndiLookup class from the zip classpath -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup.class; or substitute a non-vulnerable implementation

The CERT-FR alert bulletin emphasizes these obfuscation techniques. In the background, a recommendation to companies: perform a deep analysis of their network logs, looking for the character strings used to trigger the attack. And, if possible, correlate it with the DNS logs . Then, at the affected software level, filter and log the outgoing flows while checking the availability of patches. Developers will take care to upgrade to Log4j 2.15. See version 2.16. Published the day before yesterday, it completes the correction by disabling the JNDI API and the lookup function by default .

What Are The Results Of The Attacks?

At its last score Check Point recorded more than a million attempts to exploit Log4Shell. And provided a “raw” indicator: globally, 44% of corporate networks were affected. Main objective of the attackers: the mining of cryptocurrencies, assured the American group.

Also Read: Cisco Prime Collaboration Dashboards – Monitor your voice and video network easily

The post Log4Shell What You Need To Know About The Panicking Java Flaw appeared first on Web Updates Daily.