iscover
Share this article on:
Powered by
MOMENTUM
MEDIA
Security firm Blumira has discovered that a basic Javascript WebSocket connection can trigger a local Log4j remote code attack via a drive-by compromise.
According to Blumira, this newly discovered Javascript WebSocket attack vector can be exploited through the path of a listening server on their machine or local network.
An attacker can simply navigate to a website and trigger the vulnerability. The WebSocket connections within the host can be difficult to gain deep visibility into, that means it's even harder to detect this vulnerability and attacks using it.
This vector significantly expands the attack surface. How much so? It can be used on services running as localhost, which are not exposed to a network. This is what is likely called a "shoot me now" kind of problem.
The client itself has no direct control over WebSocket connections. These can silently start when a webpage loads.
WebSockets are in almost all modern web browsers, and commonly used for two-way communication functions such as website chat and alerts. These are designed to pass timely information back to the browser and allow the browser to quickly send data back and forth.
Unfortunately, WebSockets have their own security risks as these aren't restricted by same-origin policies like a normal cross-domain HTTP request. Instead, WebSockets expect the webserver to validate a request's origin which means these don't come with much in the way of built-in security measures.
WebSockets have been used to attack cable modems by sending malicious requests. It's also used by hackers for host fingerprinting and port scanning.
In their proof-of-concept attack, Blumira found that by using one of the many Java Naming and Directory Interface (JNDI) exploits that they could trigger via a file path URL using a WebSocket connection to machines with an installed vulnerable Log4j2 library.
All that was needed to trigger success was a path request that was started on the web page load.
Additionally, it doesn't need to be localhost. WebSockets allow for connections to any IP. For emphasis, "any IP" and that includes private IP space.
Next, as the page loads, it will initiate a local WebSocket connection, hit the vulnerable listening server, and connect out over the identified type of connection based on the JNDI connection string.
The Blumira researchers saw the most success utilising Java Remote Method Invocation (RMI). default port 1099, although custom ports are the ones often seen being used.
Port scanning, a technique already in the WebSocket hacker handbook, was the easiest path to a successful attack. Making detection of such attacks even harder, Blumira researchers found "specific patterns should not be expected as it is easy to trigger traffic passively in the background".
Then, an open port to a local service or a service accessible to the host is found, it can then drop the JNDI 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 Blumira. Then the attacker can run whatever they want.
To boost security against the Log4j attack vector, Blumira suggests the following:
Reportedly, state-sponsored hackers from China, Iran, North Korea and Turkey; Cobalt Strike; and many others are also exploiting Log4j vulnerabilities. This latest vulnerability simply opens the doors even wider for would-be attackers.
[Related: Emerging security threats in the cloud expose supply chain risks]
Be the first to hear the latest developments in the cyber industry.
