cyber daily logo

Breaking news and updates daily. Subscribe to our Newsletter

Breaking news and updates daily. Subscribe to our Newsletter X facebook linkedin Instagram Instagram

New major Log4j attack vector found

Security firm Blumira has discovered that a basic Javascript WebSocket connection can trigger a local Log4j remote code attack via a drive-by compromise.

user iconReporter
Mon, 20 Dec 2021
New major Log4j attack vector found
expand image

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:

  • Update all local development efforts, internal applications, and internet-facing environments to Log4j 2.16 as soon as possible, before threat actors can weaponise this exploit further. This includes moving any custom applications in their dependency manifests to 2.16 as soon as possible to avoid incidental exploitation.
  • One should also look closely at their network firewall and egress filtering. The mission here is to restrict the callback required for the actual exploit to land. Significantly limiting the egress traffic of endpoints will reduce the risk as applications are patched. In particular, make sure that only certain machines can send out traffic over 53, 389, 636, and 1099 ports. All other ports should be blocked. Finally, since weaponised Log4j applications often attempt to call back home to their masters over random high ports, their access to such ports should be blocked.

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]

cyber daily subscribe
Be the first to hear the latest developments in the cyber industry.