Search This Blog

Powered by Blogger.

Blog Archive

Labels

Showing posts with label Safety. Security. Show all posts

18-Year-Old Vulnerability in Firefox and Chrome Actively Exploited in Cyber Attacks

 

A security vulnerability, identified 18 years ago and known as "0.0.0.0 Day," has been discovered to allow malicious websites to bypass security measures in Google Chrome, Mozilla Firefox, and Apple Safari. This vulnerability enables these websites to interact with services on a local network, posing significant risks.

It is important to note that this vulnerability affects only Linux and macOS devices and does not impact Windows systems. On the affected devices, attackers can exploit this flaw to remotely change settings, gain unauthorized access to protected information, and, in some cases, execute remote code. Despite being reported in 2008, this issue remains unresolved in Chrome, Firefox, and Safari, although all three browsers have acknowledged the problem and are working on a fix. Researchers at Oligo Security have observed multiple threat actors exploiting this vulnerability as part of their attack strategies.

The 0.0.0.0 Day vulnerability arises from inconsistent security mechanisms across different browsers and the lack of standardization, which allows public websites to communicate with local network services using the "wildcard" IP address 0.0.0.0. Typically, this IP address represents all IP addresses on the local machine or all network interfaces on the host. It can also be used as a placeholder address in DHCP requests or interpreted as the localhost (127.0.0.1) in local networking. Malicious websites can send HTTP requests to 0.0.0.0 targeting services running on the user's local machine. Due to inconsistent security, these requests are often processed.

Existing protection mechanisms like Cross-Origin Resource Sharing (CORS) and Private Network Access (PNA) fail to prevent this risky activity, according to Oligo. Web browsers typically prevent websites from making requests to third-party sites and using the returned information to protect against malicious websites connecting to other URLs in a visitor's web browser where they may be authenticated, such as online banking portals or email servers.

Unfortunately, the risk isn't just theoretical. Oligo Security has identified several cases where the 0.0.0.0 Day vulnerability is actively exploited. One such case is the ShadowRay campaign, documented last March, targeting AI workloads running locally on developers' machines. The attack begins when a victim clicks on a link that triggers JavaScript to send an HTTP request to 'http://0[.]0[.]0[.]0:8265', typically used by Ray. 

These requests reach the local Ray cluster, leading to scenarios of arbitrary code execution, reverse shells, and configuration alterations. Another campaign targeting Selenium Grid was discovered by Wiz, where attackers use JavaScript on a public domain to send requests to 'http://0[.]0[.]0[.]0:4444.' These requests are routed to the Selenium Grid servers, enabling code execution or network reconnaissance. The "ShellTorch" vulnerability, reported by Oligo in October 2023, involves the TorchServe web panel being bound to the 0.0.0.0 IP address by default, exposing it to malicious requests.

In response to Oligo's disclosure, web browser developers are starting to take action. Google Chrome, the world's most popular web browser, plans to block access to 0.0.0.0 via a gradual rollout from version 128 to version 133. Mozilla Firefox, which does not yet implement PNA, has set the development of this feature as a high priority and has initiated temporary fixes, though no rollout dates have been provided. Apple has implemented additional IP checks on Safari and will block access to 0.0.0.0 in version 18, introduced with macOS Sequoia.

Until browser fixes are fully implemented, Oligo recommends that app developers take the following security measures:

- Implement PNA headers.
- Verify HOST headers to protect against DNS rebinding attacks.
- Do not trust localhost—add authorization, even locally.
- Use HTTPS whenever possible.
- Implement CSRF tokens, even for local apps.

Most importantly, developers should be aware that until these fixes are rolled out, it is still possible for malicious websites to route HTTP requests to internal IP addresses. This security consideration should be kept in mind when developing apps.