Summary:
Attackers can leverage a critical flaw associated with the 0.0.0.0 IP address to remotely execute code on major web browsers, including Chrome, Safari, and Firefox. This vulnerability exposes users to risks such as data theft, malware installation, and other malicious activities. The flaw was discovered by researchers at Oligo Security, an open-source security firm, and has been dubbed "0.0.0.0 Day" due to the specific web address it exploits. The core of the vulnerability lies in the inconsistent implementation of security mechanisms across different browsers and the broader lack of standardization in the industry. This inconsistency allows attackers to bypass browser security controls and interact with services running on an organization’s local network from outside the network. Specifically, attackers can exploit localhost API’s from the browser, enabling a wide range of malicious activities.

Security Officer Comments:
To illustrate the potential impact of this vulnerability, Oligo researchers examined how the ShadowRay attack campaign could exploit the 0.0.0.0 flaw. ShadowRay enabled arbitrary code execution by targeting AI workloads through a browser, using 0.0.0.0 as its attack vector. This attack was particularly dangerous because it involved a private server that was unintentionally exposed to the internet and went undiscovered for nearly a year. By running a local Ray cluster on localhost and starting a socket to listen for new connections, the researchers were able to open a reverse shell on the victim’s machine when they clicked on a malicious link, effectively giving the attacker control over the victim’s system.

The researchers successfully demonstrated this proof of concept across multiple browsers, including Chromium, Safari, and Firefox, proving that ShadowRay could be executed from the browser. They also showed how similar attacks could be carried out via other previously identified campaigns, such as SeleniumGreed and ShellTorch, by exploiting public servers and services like Selenium Grid and PyTorch TorchServe.

Suggested Corrections:
Waiting for a browser fix isn’t ideal—so there are some things developers can do to protect local applications.

• Implement PNA headers
• Verify the HOST header of the request to protect against DNS rebinding attacks to localhost or 127.0.0.1.
• Don’t trust the localhost network because it is “local”—add a minimal layer of authorization, even when running on localhost. Jupyter Notebook developers did a great job at this, adding a token by default.
• Use HTTPS when possible.
• Implement CSRF tokens in your applications, even if they are local.
• Remember that browsers act as gateways, and they have routing capabilities to internal IP address spaces in many browsers.

Link(s):
https://www.darkreading.com/cyberat...s-chrome-firefox-mozilla-browsers-at-rce-risk


https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser