Summary: Researchers have identified a vulnerability dubbed “0.0.0.0 Day,” which allows attackers to exploit the 0.0.0.0 IP address to remotely execute code across multiple web browsers, posing significant risks for data theft and malware. The flaw arises from inconsistent security implementations among browsers, enabling malicious interactions with local services.
Threat Actor: Attackers | attackers
Victim: Users of affected browsers | users of affected browsers
Key Point :
- Attackers can exploit the 0.0.0.0 IP address to interact with local services, bypassing browser security.
- The vulnerability is due to a lack of standardization in security mechanisms across different browsers.
- Private Network Access (PNA) was intended to mitigate such attacks but was found to be ineffective against requests to 0.0.0.0.
- Oligo Security demonstrated that a single HTTP request could lead to arbitrary code execution on a victim’s machine.
- Mitigation strategies include implementing PNA headers, verifying HOST headers, and using HTTPS over HTTP.
Attackers can use a flaw that exploits the 0.0.0.0 IP address to remotely execute code on various Web browsers — Chrome, Safari, Firefox, and others — putting users at risk for data theft, malware, and other malicious activity.
Researchers at open source security firm Oligo Security have discovered a way to bypass browser security and interact with services running on an organization’s local network from outside the network, that they are calling “0.0.0.0 Day,” because of the Web address it exploits.
The vulnerability exists due to “the inconsistent implementation of security mechanisms across different browsers, along with a lack of standardization in the browser industry,” Avi Lumesky, an Oligo AI security researcher, revealed in a blog post published this week.
Attackers can use the flaw to exploit localhost application programming interfaces (APIs) from the browser, thus performing a range of malicious activities.
“As a result, the seemingly innocuous IP address, 0.0.0.0, can become a powerful tool for attackers to exploit local services, including those used for development, operating systems, and even internal networks,” Lumesky wrote.
Breaking Down the Flaw
The flaw lies in the ability by design of browsers for services to send a request to almost any HTTP server using JavaScript; a browser’s key job is to focus on delivering the correct response, either by serving up a valid response to a request or an error.
While browsers are generally supposed to prevent errant or malicious requests from getting through via their responses, there has been a lack of streamlined security in handling requests across browsers since their inception.
“For a long time, it was not clear how browsers should behave when they make requests to local or internal networks from less-private contexts,” Lumesky explained in the post.
While most browsers have relied on CORS, or Cross-Origin Resource Sharing — a standard defining a way for client Web applications that are loaded in one domain to interact with resources in a different domain — “its performance depends on the response content, so requests are still made and can still be sent,” Lumesky noted.
“This is simply not good enough,” he wrote. “History proved that a single HTTP request can attack a home router — and if that’s all it takes, every user needs to be able to prevent this request from happening at all.”
PNA Bypass
Chrome’s introduction of Private Network Access (PNA) — which goes beyond CORS — should, in theory, protect websites from the 0.0.0.0 day bug. PNA proposes distinguishing between public, private, and local networks, ensuring that “pages loaded under a less-secure context will not be able to communicate with more-secure contexts,” Lumesky wrote.
However, Oligo researchers discovered that website requests sent to 0.0.0.0, which should be blocked under PNA, were actually received and processed by local servers. “This means public websites can access any open port on your host without the ability to see the response,” Lumesky wrote.
To prove their point, the attackers investigated how ShadowRay, a recent attack campaign its researchers discovered targeting AI workloads, could execute its attack from the browser using 0.0.0.0 as its attack vector.
ShadowRay enabled arbitrary code execution when a private server was unintentionally exposed to the Internet, and went undiscovered for nearly a year. To prove their concept, Oligo researchers ran a local Ray cluster on localhost, then started a socket that is listening to new connections to open a reverse shell.
“Then, the victim clicks on the link in the email, which runs the exploit,” Lumesky explained. “The exploit opens a reverse shell for the attacker on the visitor’s machine.”
The researchers proved the concept within Chromium, Safari, and Firefox to execute ShadowRay from the browser in “one of an undoubtedly huge number of remote code execution attacks enabled by this approach,” Lumesky noted. They also proved the attack via Selenium Grid public servers and PyTorch TorchServe via respective previously identified attack campaigns SeleniumGreed and ShellTorch.
Ultimately, the researchers demonstrated how by using 0.0.0.0 together with mode “no-cors,” attackers “can use public domains to attack services running on localhost and even gain arbitrary code execution, all using a single HTTP request,” Lumeksy explained.
How Defenders Can Mitigate Attacks
Oligo disclosed the findings to the relevant browser owners — including Google, Apple, and Mozilla — which responded by making fixes in their browsers to block 0.0.0.0 as a target IP, according to Oligo.
Meanwhile, as the companies in charge work to streamline security standards across browser offerings, there are other technical mitigations that network administrators can use to thwart attacks using the vector, Lumesky said.
They include implementing PNA headers, verifying the HOST header of the network request to protect against DNS rebinding attacks to localhost or 127.0.0.1, and generally mistrusting localhost networks just because they are “local.” “Add a minimal layer of authorization, even when running on localhost,” he advised.
Network administrators should also use HTTPS over HTTP whenever possible and implement CSRF tokens in your applications, even if they are local.