A “0.0.0.0-Day” vulnerability affecting Chrome, Safari and Firefox can be – and has been – exploited by attackers to gain access to services on internal networks, Oligo Security researchers have revealed.
The vulnerability stems from how those popular browsers handle network requests from external, public websites, and may allow attackers to change settings, gain access to protected information, uploading malicious models, or even achieve remote code execution.
Attacks abusing it can succeed on vulnerable browsers on macOS and Linux, but not on Windows since it blocks the 0.0.0.0 IPv4 address.
The vulnerability
0.0.0.0-Day allows a malicious website to send off (via JavaScript) a request to the 0.0.0.0 IPv4 address and a specific port, and a vulnerable browser will forward that request to a service running on that port on the host (on the local network).
“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,” the researchers noted.
Their search for vulnerable local applications revealed several.
“To find a local application that would be vulnerable from the browser, first we needed an HTTP [i.e., web] Server that runs on a local port (localhost network interface),” they explained.
“To fully exploit that vulnerability by gaining remote code execution, we needed the service to have an HTTP route that could write, tweak, or modify files and configurations. Again, we were spoiled for choice: real-world applications have many endpoints, and local services do make those security compromises, which is great news—for attackers.”
Fixes are in the works
Browsers’ CORS (Cross Origin Resource Sharing) protections protects against cross-site request forgery (CSRF) attacks, “but its performance depends on the response content, so requests are still made and can still be sent,” the researchers noted.
“Opaque requests can be dispatched in mode ‘no-cors’ and reach the server successfully—if we don’t care about the responses.”
The Private Network Access (PNA) specification makes a distinction between public, private, and local networks, and prevents pages loaded under a less-secure context (public network) from communicating with more-secure contexts (private network, local device), but it does not work when the request is sent to the 0.0.0.0 address.
Why? For the simple reason that the list of IP segments that are considered private or local by the current PNA specification does not include 0.0.0.0:
PNA is used by Chrome and Safari but has never been implemented in Firefox. Since Oligo researchers flagging the flaw to the makers of those browsers:
- Google will start blocking access to 0.0.0.0 starting with Chromium 128 (currently in beta) and will complete the process by Chrome 133
- Apple has changed its WebKit browser engine to block access to 0.0.0.0 and will introduce the change in the new macOS version (remotely change settings, gain unauthorized access to protected information, and, in some cases, achieve remote code execution.)
- Mozilla has changed the Fetch specification to block 0.0.0.0 and, according to the researchers, “at an undetermined point in the future, 0.0.0.0 will be blocked by Firefox and will not depend on PNA implementation.”
In the meantime, developers should protect their local applications by implementing protections outlined by the researchers.
“It is worth noting that the percentage of websites that communicate 0.0.0.0 is on the rise, based on counters in Chromium. Those pages could be malicious, and currently the percentage stands at 0.015% of all websites. With 200 million websites in the world as of August 2024, as many as ~100K public websites may be communicating with 0.0.0.0,” they warned.