Search results for log4j latest version | Breaking Cybersecurity News | The Hacker News

Cybersecurity researchers have discovered an entirely new attack vector that enables adversaries to exploit the Log4Shell vulnerability on servers locally by using a JavaScript WebSocket connection. "This newly-discovered attack vector means that anyone with a vulnerable Log4j version on their machine or local private network can browse a website and potentially trigger the vulnerability," Matthew Warner, CTO of Blumira,  said . "At this point, there is no proof of active exploitation. This vector significantly expands the attack surface and can impact services even running as localhost which were not exposed to any network." WebSockets  allow for two-way communications between a web browser (or other client application) and a server, unlike HTTP, which is unidirectional where the client sends the request and the server sends the response. While the issue can be resolved by updating all local development and internet-facing environments to Log4j 2.16.0, Apache o...

Web infrastructure company Cloudflare on Wednesday revealed that threat actors are actively attempting to exploit a  second bug  disclosed in the widely used Log4j logging utility, making it imperative that customers move quickly to install the latest version as a barrage of attacks continues to pummel unpatched systems with a variety of malware. The new vulnerability, assigned the identifier  CVE-2021-45046 , makes it possible for adversaries to carry out denial-of-service (DoS) attacks and follows disclosure from the Apache Software Foundation (ASF) that the original fix for the remote code execution bug — CVE-2021-44228 aka Log4Shell — was "incomplete in certain non-default configurations." The issue has since been addressed in Log4j version 2.16.0. "This vulnerability is actively being exploited and anyone using Log4j should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0," Cloudflare's Andre Bluehs and Gabriel ...

With the last month of 2021 dominated by the log4J vulnerabilities discovery, publication, and patches popping up in rapid succession, odds are you have patched your system against Log4J exploitation attempts. At least some systems, if not all. You might even have installed the latest patch – at the time of writing, that is 2.17.1, but, if the last rapid patching cycle persists, it might have changed by the time this is published. In the meantime, defenders might have been working overtime to plug Log4J born security gaps, but so did cyber-attackers. Log4J's well-deserved fame also alerted cyber-attackers to a potential entry pathway into their target. And, while log4J will hopefully vanish from the headlines,  cyber-attackers are likely to continue trying to exploit it  in the hope of finding unpatched or incompletely patched targets. As human error still accounts  for 95% of all security breaches , cyber-attackers actively rely on these human errors to exploit them a...

The Apache Software Foundation (ASF) on Tuesday rolled out fresh patches to contain an arbitrary code execution flaw in Log4j that could be abused by threat actors to run malicious code on affected systems, making it the fifth security shortcoming to be discovered in the tool in the span of a month. Tracked as  CVE-2021-44832 , the vulnerability is rated 6.6 in severity on a scale of 10 and impacts all versions of the logging library from 2.0-alpha7 to 2.17.0 with the exception of 2.3.2 and 2.12.4. While Log4j versions 1.x are not affected, users are recommended to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). "Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JND...

UPDATE — The severity score of CVE-2021-45046, originally classified as a DoS bug, has since been revised from 3.7 to 9.0, to reflect the fact that an attacker could abuse the vulnerability to send a specially crafted string that leads to "information leak and remote code execution in some environments and local code execution in all environments." The Apache Software Foundation (ASF) has pushed out a new fix for the Log4j logging utility after the previous patch for the recently disclosed  Log4Shell  exploit was deemed as "incomplete in certain non-default configurations." The second vulnerability — tracked as  CVE-2021-45046  — is rated 3.7 out of a maximum of 10 on the CVSS rating system and affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0, which the project maintainers shipped last week to address a critical remote code execution vulnerability (CVE-2021-44228) that could be abused to infiltrate and take over systems. ...

The issues with Log4j continued to stack up as the Apache Software Foundation (ASF) on Friday rolled out yet another patch — version 2.17.0 — for the widely used logging library that could be exploited by malicious actors to stage a denial-of-service (DoS) attack. Tracked as  CVE-2021-45105  (CVSS score: 7.5), the new vulnerability affects all versions of the tool from 2.0-beta9 to 2.16.0, which the open-source nonprofit shipped earlier this week to remediate a second flaw that could result in remote code execution ( CVE-2021-45046 ), which, in turn, stemmed from an "incomplete" fix for  CVE-2021-44228 , otherwise called the Log4Shell vulnerability. "Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups," the ASF  explained  in a revised advisory. "When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control o...

Threat actors are actively weaponizing unpatched servers affected by the newly identified " Log4Shell " vulnerability in Log4j to install cryptocurrency miners, Cobalt Strike, and recruit the devices into a botnet, even as telemetry signs point to exploitation of the flaw nine days before it even came to light. Netlab, the networking security division of Chinese tech giant Qihoo 360,  disclosed  threats such as  Mirai  and  Muhstik  (aka Tsunami) are setting their sights on vulnerable systems to spread the infection and grow its computing power to orchestrate distributed denial-of-service (DDoS) attacks with the goal of overwhelming a target and rendering it unusable. Muhstik was previously spotted exploiting a critical security flaw in Atlassian Confluence ( CVE-2021-26084 , CVSS score: 9.8) earlier this September. The latest development comes as it has emerged that the vulnerability has been under attack for at least more than a week prior to its pub...

As software supply chain security becomes more and more crucial, security, DevSecOps, and DevOps teams are more challenged than ever to build transparent trust in the software they deliver or use. In fact, in Gartner recently published their 2022 cybersecurity predictions - not only do they anticipate the continued expansion of attack surfaces in the near future, they also list digital supply chain as a major rising attack surface and one of the top trends to follow in 2022. After all, any software is only as secure as the weakest link in its supply chain. One bad component, any malicious access to your development environment—or any vulnerability in your software's delivery life cycle—and you risk your code's integrity, your customers, and your reputation.  Scribe Security  recently launched a new platform that claims to address these urgent needs by enabling its users to build trust in their software across teams and organizations. According to Scribe Security, SBOM is a ...

Muhstik, a botnet infamous for propagating via web application exploits, has been observed targeting Redis servers using a recently disclosed vulnerability in the database system. The vulnerability relates to  CVE-2022-0543 , a  Lua sandbox escape flaw  in the open-source, in-memory, key-value data store that could be abused to achieve remote code execution on the underlying machine. The vulnerability is rated 10 out of 10 for severity. "Due to a packaging issue, a remote attacker with the ability to execute arbitrary Lua scripts could possibly escape the Lua sandbox and execute arbitrary code on the host," Ubuntu noted in an advisory released last month. According to  telemetry data  gathered by Juniper Threat Labs, the attacks leveraging the new flaw are said to have commenced on March 11, 2022, leading to the retrieval of a malicious shell script ("russia.sh") from a remote server, which is then utilized to fetch and execute the botnet binaries from anoth...

The heightened regulatory and legal pressure on software-producing organizations to secure their supply chains and ensure the integrity of their software should come as no surprise. In the last several years, the software supply chain has become an increasingly attractive target for attackers who see opportunities to force-multiply their attacks by orders of magnitude. For example, look no further than 2021's Log4j breach, where Log4j (an open-source logging framework maintained by Apache and used in a myriad of different applications) was the root of exploits that put thousands of systems at risk.  Log4j's communication functionality was vulnerable and thus provided an opening for an attacker to inject malicious code into the logs which could then be executed on the system. After its discovery, security researchers saw millions of attempted exploits, many of which turned into successful denial-of-service (DoS) attacks. According to some of the latest research by Gartner, close t...