You need to block 0.0.0.0.

Trenix25

Active Member
Joined
Aug 15, 2017
Messages
291
Reaction score
123
Credits
2,633
I just read a cybersecurity article that exposed a security vulnerability that affects Linux systems. It says a remote website can access services that are locally running on your Linux computer by accessing ports on 0.0.0.0 when you access the remote web site with a web browser. This should not be possible, but it is. I ran a port scan and found that my ftp server and my web server were accessible on 0.0.0.0. Of course the web server would still return an error since I don't have a virtual server listening at that address. Make sure to block all input and output traffic for 0.0.0.0 as either a source or destination address to prevent this.

Signed,

Matthew Campbell
 


Install uBlock origin if possible. Go to settings, then Filter Lists and expand Privacy branch and check Block Outsider Intrusion into LAN. That is all. Works for FF.

Also, create FF profiles (one secure for general secure browsing and one permissive for specific sites) or force https and add exceptions. I think that chrome/ium is in the worst situation. Apple (I think) solved this already.
 
Last edited:
Make sure to block all input and output traffic for 0.0.0.0 as either a source or destination address to prevent this.
And then you'll also block DHCP as well as any protocols which depend on 0.0.0.0.

0.0.0.0 address is not routable so don't know what these experts from article really mean.

It says a remote website can access services that are locally running on your Linux computer by accessing ports on 0.0.0.0 when you access the remote web site with a web browser.

Go ahead and run sudo ss -lntup and you'll see none of the services on your PC listen on 0.0.0.0, so how the heck could anyone access them on that address?
That article must be an elaborate hoax.
 
I believe this is the relevant article:

The observations that occurred to me were that there was no mention of root access, that commonly home users don't have ports open, and that the investigators referred to the exploit as a "logical vulnerability" which suggested that it hadn't been much exploited if at all, but was possible. I can't say more since I'm not well versed in this area. Nevertheless, the sort of work that such organisations do I regard as important and am very grateful for.
 
I believe this is the relevant article:
Thanks, I've read the article and will re-read again because it's very concerning, very interesting and very bad news, it's even more bad that we can't configure firewall simply.

Thankfully my firewall already drops 0.0.0.0 implicitly and prevents port scanning including on local network and localhost, I've already shared sample code below, although it's not complete but now I'll work on this more:
 
Ublock Origin already has a setting to block LAN.
Under Privacy select:
Code:
Block Outsider Intrusion into LAN

Default firewall settings on most distros are similar to:
Code:
$ sudo ufw status verbose
Status: active
Logging: off
Default: deny (incoming), allow (outgoing), disabled (routed)
 
Ublock Origin already has a setting to block LAN.
Under Privacy select:
NoScript also has this option:

lan.png


LAN - whether this site is allowed to make requests to resources on your local network, e.g. localhost or private IP addresses, when this site is not itself hosted on your local network

Which also according to wikipedia does not imply 0.0.0.0

Default firewall settings on most distros are similar to:
Sadly firewalls do not block 0.0.0.0 either. :(
 
So I use Pale Moon as my browser, and uBlock Origin for Pale Moon does not have Block Outsider Intrusion into LAN. Is there a way to manually install this?
 
Sadly firewalls do not block 0.0.0.0 either

firewalld does: https://linuxhandbook.com/firewalld-cmd/

sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="0.0.0.0" accept'

brian@brian-desktop:~$
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="0.0.0.0" accept'
[sudo] password for brian:
success
brian@brian-desktop:~$
 
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="0.0.0.0" accept'
Good luck with that because it won't block 0.0.0.0, hostile websites use 0.0.0.0 as target IP and source IP ;)
And also it applies to public zone.

Also your rule needs to do this in prerouting before stateful filtering because otherwise it will be interpreted as "established" or "related" and then again it will let attacker pass trough.
 
Firewalld is available in the Linux Mint Software Manager.....also on the website

if you are unsure of firewalld's capabilities, read the manual



What is firewalld?​

Firewalld is a dynamic firewall by Red Hat for Linux systems. This is a powerful tool that allows you to control network traffic entering and exiting your system. In other words, Firewalld acts as a security barrier that filters network connections, allowing only authorized ones and blocking potentially dangerous ones.
 
Firewall will not protect against this attack as browser connection is established already.
I mentioned uBlock origin in my previous posts.
As the other options too.
 
Firewall will not protect against this attack as browser connection is established already.
It will if you set the rule in pre-routing chain which is processed prior stateful filtering is done.
Simply drop inbound toward 0.0.0.0 in pre-routing unless target port is 67 to let DHCP work.

Rule in stateful filter chain or later will not work because the attacking site already has established connection and so can bypass firewall and attack local services.
 
And then you'll also block DHCP as well as any protocols which depend on 0.0.0.0.

0.0.0.0 address is not routable so don't know what these experts from article really mean.



Go ahead and run sudo ss -lntup and you'll see none of the services on your PC listen on 0.0.0.0, so how the heck could anyone access them on that address?
That article must be an elaborate hoax.
I use static IPv4 addresses. It really didn't look like a hoax.

Signed,

Matthew Campbell
 
I set the mentioned setting in uBlock Origin. I would have to create a new table to get the firewall to block it in prerouting. I block 0.0.0.0 before allowing access to established or related so the drop should take effect first. The order of the firewall rules is important. I use drop as the default input policy. I blocked all of 0.0.0.0 with four lines. I use nftables.

The article was published by the Hacker News.

Signed,

Matthew Campbell
 
I would have to create a new table to get the firewall to block it in prerouting. I block 0.0.0.0 before allowing access to established or related so the drop should take effect first.
I blocked all of 0.0.0.0 with four lines. I use nftables.
Yes this will work too, but you only need 2 lines in input chain but not in output, that is for input TCP and UDP.

Reason why I set it in prerouting is because of port scanner rules which are best placed there.
Without anti-port scanning rules websites will still be able to detect local services on your system and could exploit them without probing to 0.0.0.0.

For instance they could still scan, probe or connect to normal localhost 127.0.0.1 which I'm sure your firewall allows?
So just blocking 0.0.0.0 is not enough.
 
I also block access to the web server on all other possible addresses too. It has one valid address and only that address is allowed. I block input and output for 0.0.0.0. One for the source address and one for the destination address. Incidentally, I also block all IPv6 link local addresses too, both ways. I don't mind if they know that a service is running, as long as they can't access it. All they'd see is a dropped probe. If you really wanted to screw with them you could drop probes on a handful of other ports too, just to get them wondering.

Signed,

Matthew Campbell
 
I don't mind if they know that a service is running, as long as they can't access it.
If they can learn which service is running then they can also connect to it and exploit it, and according to article they can do this by connecting to 127.0.0.1, simply by replacing 0.0.0.0 with localhost address.

Since in nftables you absolutely need loopback allow rules (otherwise there are software issues) this means without port scanning rules in prerouting (that is prior loopback allow rules) they pretty much can exploit local services regardless of any rules added at later stage.

There is no way to 100% prevent this, if you want to be 100% sure then in addition to the above you also need to disable local services which you don't need to further reduce attack surface.

run sudo ss -tunlp and disable unneeded services, such as MTA or avahi daemon or tor daemon or kdeconnectd etc.
 
If they can learn which service is running then they can also connect to it and exploit it, and according to article they can do this by connecting to 127.0.0.1, simply by replacing 0.0.0.0 with localhost address.

Since in nftables you absolutely need loopback allow rules (otherwise there are software issues) this means without port scanning rules in prerouting (that is prior loopback allow rules) they pretty much can exploit local services regardless of any rules added at later stage.

There is no way to 100% prevent this, if you want to be 100% sure then in addition to the above you also need to disable local services which you don't need to further reduce attack surface.

run sudo ss -tunlp and disable unneeded services, such as MTA or avahi daemon or tor daemon or kdeconnectd etc.
The firewall will block access to 127.0.0.0:80/8 and any other ports used by the web server. The web server is only available at the correct address. I block unwanted access before allowing access to anything. Drop before accept works. I shut down kdeconnectd. SMTP is the only thing left that really needs localhost and soon that will require group membership.

Signed,

Matthew Campbell
 

Staff online

Members online


Latest posts

Top