Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.
Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1.
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 on Friday rolled out version 2.17.0, which remediates a denial-of-service (DoS) vulnerability tracked as CVE-2021-45105 (CVSS score: 7.5), making it the third Log 4j2 flaw to come to light after CVE-2021-45046 and CVE-2021-44228.
The complete list of flaws discovered to date in the logging framework after the original Log4Shell remote code execution bug was disclosed is as follows —
“We shouldn’t be surprised that additional vulnerabilities were discovered in Log4j given the additional specific focus on the library,” Jake Williams, CTO and co-founder of incident response firm BreachQuest, said. “Similar to Log4j, this summer the original PrintNightmare vulnerability disclosure led to the discovery of multiple additional distinct vulnerabilities. The discovery of additional vulnerabilities in Log4j shouldn’t cause concern about the security of log4j itself. If anything, Log4j is more secure because of the additional attention paid by researchers.”
The latest development comes as a number of threat actors have piled on the Log4j flaws to mount a variety of attacks, including ransomware infections involving the Russia-based Conti group and a new ransomware strain named Khonsari. What’s more, the Log4j remote code execution flaw has also opened the door to a third ransomware family known as TellYouThePass that’s being used in attacks against Windows and Linux devices, according to researchers from Sangfor and Curated Intel.
The easily exploited, ubiquitous vulnerability, aside from spawning as many as 60 variations, has presented a perfect window of opportunity for adversaries, with Romanian cybersecurity firm Bitdefender noting that more than 50% of the attacks are leveraging the Tor anonymity service to mask their true origins.
“In other words, threat actors exploiting Log4j are routing their attacks through machines that are closer to their intended targets and just because we don’t see countries commonly associated with cybersecurity threats at the top of the list does not mean that attacks did not originate there,” Martin Zugec, technical solutions director at Bitdefender, said.
According to telemetry data collected between December 11 and December 15, Germany and the U.S. alone accounted for 60% of all the exploitation attempts. The most common attack targets during the observation period were the U.S., Canada, the U.K., Romania, Germany, Australia, France, the Netherlands, Brazil, and Italy.
The development also coincides with an analysis from Google’s Open Source Insights Team, which found that roughly 35,863 Java packages — accounting for over 8% of the Maven Central repository — use vulnerable versions of the Apache Log4j library. Of the affected artifacts, only around 7,000 packages have a direct dependency on Log4j.
“User’s lack of visibility into their dependencies and transitive dependencies has made patching difficult; it has also made it difficult to determine the full blast radius of this vulnerability,” Google’s James Wetter and Nicky Ringland said. But on the positive side of things, 2,620 of the impacted packages have already been fixed less than a week after disclosure.
“There will likely be some time before we understand the full fallout of the log4j vulnerability, but only because it’s embedded in so much software,” Williams said. “This has nothing to do with threat actor malware. It has to do with the difficulty in finding the myriad places the library is embedded. The vulnerability itself will provide initial access for threat actors who will later perform privilege escalation and lateral movement – that’s where the real risk is.”
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 over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process.”
Hideki Okamoto of Akamai Technologies and an anonymous vulnerability researcher have been credited with reporting the flaw. Log4j versions 1.x, however, are not affected by CVE-2021-45105.
It’s worth pointing out that 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,” corroborating a previous report from security researchers at Praetorian.
The project maintainers also noted that Log4j versions 1.x have reached end of life and are no longer supported, and that security flaws uncovered in the utility after August 2015 will not be fixed, urging users to upgrade to Log4j 2 to get the latest fixes.
The fixes are the latest in what’s a highly dynamic situation as the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued an emergency directive mandating federal civilian departments and agencies to immediately patch their internet-facing systems for the Apache Log4j vulnerabilities by December 23, 2021, citing that the weaknesses pose an “unacceptable risk.”
The development also comes as the Log4j flaws have emerged as a lucrative attack vector and a focal point for exploitation by multiple threat actors, including nation-backed hackers from the likes of China, Iran, North Korea, and Turkey as well as the Conti ransomware gang, to carry out an array of follow-on malicious activities. This marks the first time the vulnerability has come under the radar of a sophisticated crimeware cartel.
“The current exploitation led to multiple use cases through which the Conti group tested the possibilities of utilizing the Log4j 2 exploit,” AdvIntel researchers said. “the criminals pursued targeting specific vulnerable Log4j 2 VMware vCenter [servers] for lateral movement directly from the compromised network resulting in vCenter access affecting U.S. and European victim networks from the pre-existent Cobalt Strike sessions.”
Among the others to leverage the bug are cryptocurrency miners, botnets, remote access trojans, initial access brokers, and a new ransomware strain called Khonsari. Israeli security firm Check Point said it recorded over 3.7 million exploitation attempts to date, with 46% of those intrusions made by known malicious groups.
Versions of Apache Log4j impacted by CVE-2021-44228 which allow JNDI features used in configuration, log messages, and parameters, do not protect against attacker controlled LDAP and other JNDI related endpoints.
This module will scan an HTTP endpoint for the Log4Shell vulnerability by injecting a format message that will trigger an LDAP connection to Metasploit. This module is a generic scanner and is only capable of identifying instances that are vulnerable via one of the pre-determined HTTP request injection points.
This module has been successfully tested with:
Example usage:
msf6 > use auxiliary/scanner/http/log4shell_scanner
msf6 auxiliary(scanner/http/log4shell_scanner) > set RHOSTS 192.168.159.128
RHOSTS => 192.168.159.128
msf6 auxiliary(scanner/http/log4shell_scanner) > set SRVHOST 192.168.159.128
SRVHOST => 192.168.159.128
msf6 auxiliary(scanner/http/log4shell_scanner) > set RPORT 8080
RPORT => 8080
msf6 auxiliary(scanner/http/log4shell_scanner) > set TARGETURI /struts2-showcase/
TARGETURI => /struts2-showcase/
msf6 auxiliary(scanner/http/log4shell_scanner) > run
[*] Started service listener on 192.168.159.128:389
[+] Log4Shell found via /struts2-showcase/%24%7bjndi%3aldap%3a%24%7b%3a%3a-/%7d/192.168.159.128%3a389/r7yol50kgg7be/%24%7bsys%3ajava.vendor%7d_%24%7bsys%3ajava.version%7d%7d/ (java: BellSoft_11.0.13)
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf6 auxiliary(scanner/http/log4shell_scanner) >
For more details, please see the official Rapid7 Log4Shell CVE-2021-44228 analysis.
/wp-admin/options.php.
Additionally, several WordPress modules were updated to more
descriptively report which plugin they found as being vulnerable on a
given target.lib
folder have now been updated to declare Meterpreter compatibility
requirements, which will allow users to more easily determine when they
are using a library that the current session does not support.sessions --upgrade 1RHOSTS, which allows one to specify the username, password, and the port if it’s specified as a string such as tcp://user:a b c@example.com which would translate into the username user, password a b c, and host example.com on the default port used by the module in question.lib/msf/core/auxiliary/report.rb has been improved to fix an error whereby the report_vuln() would crash if vuln was nil prior to calling framework.db.report_vuln_attempt(). This has been fixed by checking the value of vuln and raising a ValidationError if it’s set to nil.creds -d command which crashed on some NTLM hashes.nil prior to being used when saving credentials with Kiwi. This has been addressed by adding improved error checking and handling.As always, you can update to the latest Metasploit Framework with msfupdate
and you can get more details on the changes since the last blog post from
GitHub:
If you are a git user, you can clone the Metasploit Framework repo (master branch) for the latest.
To install fresh without using git, you can use the open-source-only Nightly Installers or the
binary installers (which also include the commercial edition).
Defenders will once again be busy beavers this weekend: There’s an alternative attack vector for the ubiquitous Log4j vulnerability, which relies on a basic Javascript WebSocket connection to trigger remote code-execution (RCE) on servers locally, via drive-by compromise.
In other words, an exploit can affect services running as localhost in internal systems that are not exposed to any network.
That’s according to researchers at Blumira, who noted that the discovery eviscerates the notion that Log4Shell attacks are limited to exposed vulnerable web servers.
“This newly discovered attack vector means that anyone with a vulnerable Log4j version can be exploited through the path of a listening server on their machine, or local network through browsing to a website, and triggering the vulnerability,” researchers said in a Friday note to Threatpost.
Check out all of our Log4Shell coverage:
This means there are several new malicious use cases for an exploit, beyond the now-well-documented ability to open a shell with a single line of code to drop malware on internet-facing web servers.
“[New use cases include everything] from malvertisting to creating watering holes for drive-by attacks,” said Matthew Warner, CTO and co-founder of Blumira, in a technical post.
WebSockets enables communication between a web browser and web applications, like chats and alerting on websites. They generally allow the browser to quickly send data back and forth to these types of apps, but they’re also used for host-fingerprinting and port-scanning.
Warner explained in his posting that WebSockets is also fraught with security risk.
“WebSockets are not restricted by same-origin policies like a normal cross-domain HTTP request,” he explained. “They expect the server itself to validate the origin of the request. While they are useful, they also introduce a fair amount of risk as they do not include many security controls to limit their utilization.”
In the Log4j case, an attacker would make malicious requests via WebSockets to a potentially vulnerable localhost or local network server. The targets don’t have to be exposed to the internet.
“WebSockets have previously been used for port-scanning internal systems, but this represents one of the first remote code execution exploits being relayed by WebSockets,” said Jake Williams, co-founder and CTO at BreachQuest, via email. “This shouldn’t change anyone’s position on vulnerability management though. Organizations should be pushing to patch quickly and mitigate by preventing outbound connections from potentially vulnerable services where patching is not an option.”
Warner offered a detailed breakdown of his proof-of-concept (PoC) for the attack in the posting; below is a truncated explanation.
Step 1:From a watering-hole server with the affected Log4j2 vulnerability installed, an attacker would trigger a file path URL from the browser with a WebSocket connection. Blumira used a basic Javascript WebSocket connection in the PoC, but Warner noted that “this does not necessarily need to be localhost; WebSockets allow for connection to any IP and easily could iterate private IP space.”
Step 2: As the page loads, it will initiate a local WebSocket connection, connect to the vulnerable listening server, and connect out over an identified type of connection based on a Java Naming and Directory Interface (JNDI) connection string – a technique that’s similar to WebSockets’ localhost port-scanning used for fingerprinting hosts.
Step 3: Once the victim’s host connects to an open port to a local service or a service accessible to the host itself, an attacker can then drop an exploit string in path or parameters. “When this happens, the vulnerable host calls out to the exploit server, loads the attacker’s class, and executes it with java.exe as the parent process,” according to Warner.
The bad news is that this also a stealthy approach, according to the analysis: “WebSocket connections within the host can be difficult to gain deep visibility into, which increases the complexity of detection for this attack.” That’s because WebSocket connections silently initiate when a webpage loads, with no direct control by the client itself. However, Warner noted that there are ways to get around this.
To detect a possible attack, Warner recommended looking for instances of “.*/java.exe” being used as the parent process for “cmd.exe/powershell.exe.”
“This is potentially very noisy,” Warner said.
And finally, organizations should also make sure they’re set up to detect the presence of Cobalt Strike, TrickBot and related common attacker tools.
To identify where Log4j is used within local environments, there are publicly available scanning scripts, researchers noted, to identify the libraries used locally. Here are two:
To mitigate the risk completely, organizations should update all local development efforts, internal applications and internet-facing environments to Log4j 2.16 ASAP, including any custom applications.
In the meantime, users can implement egress filtering, which can restrict the callback required for the actual exploit to land, and can use tools like NoScript Java-blocker on untrusted external sites to avoid Javascript triggering WebSocket connections.
“This news does mean that relying on web application firewalls, or other network defenses, is no longer an effective mitigation,” John Bambenek, principal threat hunter at Netenrich, said via email. “Patching remains the single most important step an organization can take.”
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 Gabor said.
Even more troublingly, researchers at security firm Praetorian warned of a third separate security weakness in Log4j version 2.15.0 that can “allow for exfiltration of sensitive data in certain circumstances.” Additional technical details of the flaw have been withheld to prevent further exploitation, but it’s not immediately clear if this has been already addressed in version 2.16.0.
“2.16 disables JNDI lookups by default and — as a result — is the safest version of Log4j2 that we’re aware of,” Anthony Weems, principal security engineer at Praetorian, told The Hacker News. When reached for a response, the Apache Logging Services Project Management Committee (PMC) confirmed that “We have been in contact with the engineer from Praetorian to fully understand the nature and scope of the problem.”
The latest development comes as advanced persistent threat groups from China, Iran, North Korea, and Turkey, counting the likes of Hafnium and Phosphorus, have jumped into the fray to operationalize the vulnerability and discover and continue exploiting as many susceptible systems as possible for follow-on attacks. Over 1.8 million attempts to exploit the Log4j vulnerability have been recorded so far.
Microsoft Threat Intelligence Center (MSTIC) said it also observed access brokers leveraging the Log4Shell flaw to gain initial access to target networks that were then sold to other ransomware affiliates. In addition, dozens of malware families that run the gamut from cryptocurrency coin miners and remote access trojans to botnets and web shells have been identified taking advantage of this shortcoming to date.
While it’s common for threat actors to make efforts to exploit newly disclosed vulnerabilities before they’re remediated, the Log4j flaw underscores the risks arising from software supply chains when a key piece of software is used within a broad range of products across several vendors and deployed by their customers around the world.
“This cross-cutting vulnerability, which is vendor-agnostic and affects both proprietary and open-source software, will leave a wide swathe of industries exposed to remote exploitation, including electric power, water, food and beverage, manufacturing, transportation, and more,” industrial cybersecurity firm Dragos noted.
“As network defenders close off more simplistic exploit paths and advanced adversaries incorporate the vulnerability in their attacks, more sophisticated variations of Log4j exploits will emerge with a higher likelihood of directly impacting Operational Technology networks,” the company added.
Call it a “logjam” of threats: Attackers including nation-state actors have already targeted half of all corporate global networks in security companies’ telemetry using at least 70 distinct malware families — and the fallout from the Log4j vulnerability is just beginning.
Researchers manning keyboards all over the world have spent the past several days chasing attacks aimed at a now-infamous Log4j Java library bug, dubbed Log4Shell (CVE-2021-44228). Side note: Log4j is pronounced, “log forge” — although that’s disputed, because it’s also referred to in conversation as “log-four-jay.” Dealer’s choice there.
First discovered among Minecraft players last week, the newly discovered vulnerability has opened a massive opportunity for threat actors to hijack servers, mostly with coin miners and botnets, but also a cornucopia of other malware such as the StealthLoader trojan — and that’s just so far.
“We’ve seen a lot of chatter on Dark Web forums, including sharing scanners, bypasses and exploits,” Erick Galinkin, an artificial intelligence researcher at Rapid7, told Threatpost. “At this point, more than 70 distinct malware families have been identified by us and other security researchers.”
For instance, Bitdefender researchers this week discovered that threat actors are attempting to exploit Log4Shell to deliver a new ransomware called Khonsari to Windows machines.
Check Point research reported Wednesday that since last Friday, its team has detected 1.8 million Log4j exploit attempts on almost half of all corporate networks that they track.
These threat actors aren’t low-skilled hobbyists. Check Point added that as of Wednesday, Iranian hacking group Charming Kitten, also known as APT 35 and widely believed to be working as a nation-state actor, is actively targeting seven specific Israeli organizations across the government and business sectors.
“Our reports of the last 48 hours prove that both criminal-hacking groups and nation state actors are engaged in the exploration of this vulnerability, and we should all assume more such actors’ operations are to be revealed in the coming days,” Check Point added.
Microsoft meanwhile reported that nation-state groups Phosphorus (Iran) and Hafnium (China), as well as unnamed APTs from North Korea and Turkey are actively exploiting Log4Shell (CVE-2021-44228) in targeted attacks. Hafnium is known for targeting Exchange servers with the ProxyLogon zero-days back in March, while Phosphorus made headlines for targeting global summits and conferences in 2020.
“This activity ranges from experimentation during development, integration of the vulnerability to in-the-wild payload deployment and exploitation against targets to achieve the actor’s objectives,” the company said in a posting.
Researcher Greg Linares meanwhile has reported seeing evidence that a self-propagating worm is being developed and will likely emerge in a day or less.
#Log4J based on what I’ve seen, there is evidence that a worm will be developed for this in the next 24 to 48 hours.
Self propagating with the ability to stand up a self hosted server on compromised endpoints.
In addition to spraying traffic, dropping files, it will have c2c
— Greg Linares (@Laughing_Mantis) December 12, 2021
There is wide agreement within the cybersecurity community that he’s correct, but many experts don’t think the fallout will be as bad with Log4j as it was with past incidents like WannaCry or NotPetya.
“While it’s possible that we could see a worm developed to spread among susceptible Log4j devices, there hasn’t been any evidence to suggest this is a priority for threat actors at this time,” Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows, told Threatpost. “Developing malware of this nature takes a significant amount of time and effort.”
“This activity differs from the WannaCry incident, which saw a perfect storm of a highly exploitable vulnerability coinciding with an NSA-level exploit breach in EternalBlue,” Morgan added.
“It’s still very much early days with regards to Log4j,” Morgan said. “While many threat actors will likely be at different stages of the kill chain, most actors will likely still be scanning for susceptible systems, attempting to establish a foothold, and identifying further opportunities, depending on their motivations. Efforts among actors at this stage are rushing to exploit before companies have a chance to patch, rather than spending time developing a worm.”
The emergence of a Log4j worm isn’t the worst-case scenario, researchers like Yaniv Balmas from Salt Security explained to Threatpost.
“While not neglecting the impact of such a worm, that might not be the worst scenario because of the unbelievable easiness that this attack can be applied,” Balmas said. “Everyone with a basic computer and internet access could launch an attack against millions of online services within minutes. This achieves quite a similar impact as a worm – it is distributed and unpredictable, and the damage extent might even be higher than a worm since a worm works ‘blindly’ in an automated manner.”
He added, “in this other scenario, there are actual humans behind the attacks which may target specific entities or institutions and enable attackers to fine-tune their attacks as they progress.”
The tireless work being done by security teams to patch up Log4j against exploits is a big help against the development of any worms on the horizon, John Bambenek, principal threat hunter at Netenrich, told Threatpost.
“This vulnerability certainly looks wormable, however, the good news is we’ve already had almost a week to start dealing with detection, mitigation and patching,”Bambenek said. “There will be lots of vulnerable machines out there, but by now a good deal of the vulnerable machines have been handled and many more are protected with web application firewall (WAF) rules (for instance, Cloudflare deployed protection over the weekend). The worst case would have been a worm last week, we’re in a better place now.”
Beyond emergency patching measures, Galinkin explained to Threatpost that his concern is with lingering unpatched devices and systems that will be vulnerable long after Log4j has fallen out of the headlines, particularly in sectors like academia and healthcare.
“One crucial thing to note about this vulnerability is that it’s going to have an extremely long tail,” he said. “Hospitals tend to purchase software once, but sometimes the vendors become defunct — leading to unsupported software that will never receive a patch.”
He added, “in academia, loads of software is written once by grad students or professors, but those individuals may not be aware of the bug, or they simply no longer maintain the software — software that is in use in physics, pharmacology and bioinformatics. This suggests that we will continue to see exploitation of this vulnerability — potentially in isolated incidents — long into the future.”
121621 16:21 UPDATE: Corrected spelling of John Bambenek’s name.
