The discovery, which affects services running as localhost that aren’t exposed to any network or the internet, vastly widens the scope of attack possibilities.

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

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:

• Windows PoSh – https://github.com/N-able/ScriptsAndAutomationPolicies/blob/master/Vulnerability%20-%20CVE-2021-44228%20(Log4j)/get-log4jrcevulnerability.ps1
• Cross platform – https://github.com/hillu/local-log4j-vuln-scanner/releases

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