0.0.0.0 Day exploit

ziomarco · 2024-08-08 15:49:36

Is this exploit a really dangerous vulnerability?
They say there is no immediate fix in Firefox, on the contrary chrome patched .it

mpan · 2024-08-08 16:30:07

If you don’t have services listening on localhost: the attack does nothing.

If you have services listening on localhost, but they don’t expose interface over HTTP: only relevant if the service already has a critical vulnerability itself. The attack allows circumventing a firewall ~~running on a router~~,⁽¹⁾ which would otherwise shield the vulnerable service from external traffic. The attack itself, without the service being critically vulnerable already, does nothing.

If you have services listening on localhost, and they do expose authenticated interface over HTTP: only relevant if the service already has a critical vulnerability in requests handling logic. Similar to the previous point, it permits circumventing ~~the router-level~~⁽¹⁾ firewall. The difference is that the attack surface is much larger. While previous case requires a very specific and unlikely kind of vulnerability, here there is many more possibilities.

If you have services listening on localhost, and they do expose unauthenticated interface over HTTP: the attack is always relevant. But you should not have such services in the first place.
____
⁽¹⁾ Edit 2024-08-10: not only network-level, because of 127.0.0.0/8 and ::1.

Last edited by mpan (2024-08-10 18:24:45)

seth · 2024-08-08 20:08:45

To superficially check this

ss -lutn # w/ UDP being a massive stretch because it requires http/3

Then test http://0.0.0.0:<open port>

Eg. http://0.0.0.0:631/ would be cups and hopefully just tells you to gfy anywy.
http://127.0.0.1:631/ or http://localhost:631/ should work, your LAN IP (eg http://192.168.0.2:631 ) should NOT unless you're sharing the printer on the LAN.

Also and as mpan pointed out the exploit still needs
1. some service listening
2. that it can then exploit in some meaninful manner.
So even ifff eg. http://0.0.0.0:7634 would work, the offender would know the current temperature of my disk which, yeah, knock yourself out.

Port scanning might help to identify you, but normal browsers already expose A LOT of specific stuff that can be used for fingerprinting, even w/o javascript, which can be used to overcome hiding-behind-TOR efforts.
For the vast majority of users this isn't a realistic thread and to stress the our-cve-has-a-cool-name-for-cnn blog entry:
Firefox doesn't support PNA at all, so an attack on eg. 192.168.0.5:631 would have worked anyway - that's no news, they just noticed that the 0.0.0.0 IP isn't a loopback nor a private network segment and escaped the PNA spec from 2015.

And: this cannot be exploited cold, you've to go to www.pornandmalware.com to have the web page loaded in your browser to be able to use your browser against you.

progandy · 2024-08-08 22:34:16

seth wrote:

Firefox doesn't support PNA at all, so an attack on eg. 192.168.0.5:631 would have worked anyway - that's no news, they just noticed that the 0.0.0.0 IP isn't a loopback nor a private network segment and escaped the PNA spec from 2015.

You can try to use an uBlock filter list for that: https://github.com/uBlockOrigin/uAssets … -block.txt

ziomarco · 2024-08-09 09:01:03

thanks to you all for the explanations

Lone_Wolf · 2024-08-09 10:54:07

I occasionally run transmission using transmission-daemon as user from a terminal .
http://0.0.0.0:9091/ in firefox works, but transmission webinterface requires javascript which is blocked by the Noscript extension .

Could 0.0.0.0 be blocked in the hosts file ?

seth · 2024-08-09 11:02:24

transmission-daemon hast a couple of Options for the listening addresses that all Default to 0.0.0.0 - you could Set them to the loopback 127.0.0.1

Trilby · 2024-08-09 12:06:39

Lone_Wolf wrote:

Could 0.0.0.0 be blocked in the hosts file ?

/etc/hosts?? No. That's for mapping domain names to IP addresses, 0.0.0.0 is already the IP. In fact, common ad/host blocking strategies use /etc/hosts/ to map a wide range or "bad" domain names to 0.0.0.0.

Interestingly, that could be a source of a much wider attack surface for this exploit. On my laptop, there are over 600 thousand domain names in my /etc/hosts file that all are mapped to 0.0.0.0. So theoretically a website attempting to "phone home" to any of those bad-actor sites gets directed back to 0.0.0.0.

Am I worried? Nope.

Last edited by Trilby (2024-08-09 13:25:22)

cloverskull · 2024-08-09 17:34:39

@Trilby does your /etc/hosts file size cause any performance issues with domain resolution? 600k domains seems like a lot, so I'm curious

sekret · 2024-08-09 20:15:04

I seem to have the same hosts file Trilby has. Well, at least I don't feel any difference.

macromal · 2024-08-09 20:26:47

cloverskull wrote:

@Trilby does your /etc/hosts file size cause any performance issues with domain resolution? 600k domains seems like a lot, so I'm curious

Look this repository https://github.com/StevenBlack/hosts, contains hosts files for different purposes.

My simple /etc/hosts only blocks a few malicious sites:

# The following lines are desirable for IPv4 capable hosts
127.0.0.1       localhost
# 127.0.1.1 is often used for the FQDN of the machine
127.0.1.1       MAL.localdomain          MAL

# The following lines are desirable for IPv6 capable hosts
#::1             localhost ip6-localhost ip6-loopback
#ff02::1         ip6-allnodes
#ff02::2         ip6-allrouters

# Malicious sites
127.0.0.1       www.microsoft.com microsoft.com
127.0.0.1       www.google.com google.com

Trilby · 2024-08-09 21:35:50

Nope, no performance issues related to /etc/hosts size. When I was having some issues I explicitly tested that.

adventurer · 2024-08-10 15:55:49

There is an easy solution as already mentioned by @progandy: uBlock Origin comes with the "Block Outsider Intrusion into LAN" filterlist. Enable it in its settings and you're protected.

xerxes_ · 2024-08-10 16:06:25

For me 'ss -lutn' returns:

Netid             State              Recv-Q             Send-Q                                              Local Address:Port                         Peer Address:Port             
udp               UNCONN             0                  0                              [fe80::82fb:a22e:xxxx:xxxx]%enpxxx:546                                  [::]:*

This is some dhcpv6-client listening on port 546. Can it be dangerous?

I was trying to connect to it in Firefox in address bar like this: http://0.0.0.0:546 or 0.0.0.0:546, but it didn't worked: "Firefox can't connect to the server 0.0.0.0:546", but maybe I do something wrong...

Last edited by xerxes_ (2024-08-10 16:11:37)

mpan · 2024-08-10 16:29:24

I believe case #2 from my earlier response applies here and only under an additional condition.The adversary needs to force a browser to use HTTP/3.

xerxes_ · 2024-08-10 16:53:56

How do you know that attack need HTTP/3 ? Also, if I understand well, it needs javascript to be enabled (javascript request) ?

seth · 2024-08-10 16:56:48

http/2 over udp isn't a thing

mpan · 2024-08-10 18:44:19

xerxes_ wrote:

How do you know that attack need HTTP/3

HTTP/1.x and HTTP/2, with and without TLS, work over TCP. So any traffic they cause isn’t appearing at an UDP socket.

xerxes_ wrote:

Also, if I understand well, it needs javascript to be enabled (javascript request) ?

Being able to run code on the target machine makes the attack much easier and gives more options, but is not strictly necessary.

The first kind of attack (case #2) relies on improper handling of data in a TCP stream. If present, it is most likely to be triggered in the early part of the transmission. This is the same regardless of how the request is made. JavaScript APIs (like Fetch API), would affect the parts arriving much later. The other two cases are most likely to be triggered by GET or POST data, both of which can be sent without additional code.

However, without client-side code it’s going to be hard to exfiltrate data. It would require a Rube Goldberg level of machinery or something like Log4Shell.

Arch Linux

#1 2024-08-08 15:49:36

0.0.0.0 Day exploit

#2 2024-08-08 16:30:07

Re: 0.0.0.0 Day exploit

#3 2024-08-08 20:08:45

Re: 0.0.0.0 Day exploit

#4 2024-08-08 22:34:16

Re: 0.0.0.0 Day exploit

#5 2024-08-09 09:01:03

Re: 0.0.0.0 Day exploit

#6 2024-08-09 10:54:07

Re: 0.0.0.0 Day exploit

#7 2024-08-09 11:02:24

Re: 0.0.0.0 Day exploit

#8 2024-08-09 12:06:39

Re: 0.0.0.0 Day exploit

#9 2024-08-09 17:34:39

Re: 0.0.0.0 Day exploit

#10 2024-08-09 20:15:04

Re: 0.0.0.0 Day exploit

#11 2024-08-09 20:26:47

Re: 0.0.0.0 Day exploit

#12 2024-08-09 21:35:50

Re: 0.0.0.0 Day exploit

#13 2024-08-10 15:55:49

Re: 0.0.0.0 Day exploit

#14 2024-08-10 16:06:25

Re: 0.0.0.0 Day exploit

#15 2024-08-10 16:29:24

Re: 0.0.0.0 Day exploit

#16 2024-08-10 16:53:56

Re: 0.0.0.0 Day exploit

#17 2024-08-10 16:56:48

Re: 0.0.0.0 Day exploit

#18 2024-08-10 18:44:19

Re: 0.0.0.0 Day exploit

Board footer