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.
- Relentless Log4j Attacks Include State Actors, Possible Worm
- What the Log4Shell Bug Means for SMBs: Experts Weigh In
- How to Buy Precious Patching Time as Log4j Exploits Fly (Podcast)
- Apache’s Fix for Log4Shell Can Lead to DoS Attacks
- Where the Latest Log4Shell Attacks Are Coming From
- Log4Shell Is Spawning Even Nastier Mutations
- SAP Kicks Log4Shell Vulnerability Out of 20 Apps
- Zero Day in Ubiquitous Apache Log4j Tool Under Active Attack
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.”
Check out our free upcoming live and on-demand online town halls – unique, dynamic discussions with cybersecurity experts and the Threatpost community.
