Brand-New Log4Shell Attack Vector Threatens Local Hosts

byAkram -
0

 

Description

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.

Using WebSockets for Malicious Gain

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

Local Attack Scenario for Log4Shell

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.

Detection and Remediation

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

You may like these posts

Post a Comment

Previous Post Next Post