I have a question regarding Parrot OS and the security of the default network configuration in regards to VPNs. The release of CVE-2019-14899 earlier this week asserts that there is a technique that can work against OpenVPN, WireGuard, and IKEv2/IPSec by exploiting some Linux distributions default network configuration.
Here is a link describing the issue.
To quote from the link, “This attack did not work against any Linux distribution we tested until the release of Ubuntu 19.10, and we noticed that the rp_filter settings were set to “loose” mode. We see that the default settings in sysctl.d/50-default.conf in the systemd repository were changed from “strict” to “loose” mode on November 28, 2018, so distributions using a version of systemd without modified configurations after this date are now vulnerable. Most Linux distributions we tested which use other init systems leave the value as 0, the default for the Linux kernel.”
Since this issue relates to the default network configuration, rp_filter, and effects many distros, I wonder if Parrot is effected by this?
Would editing sysctl.conf and uncommenting the lines regarding rp_filter offer protection and harden the default network configuration against this?
You can check the status of sysctl parameters by executing something similar to the the following (use your parameter): sudo sysctl net.ipv4.conf.default.rp_filter
If this returns 1, then it is enabled.
Yes, editing sysctl.conf and adjusting some default values can give you added protections. There are a fair amount of guides around, but use caution when editing sysctl.conf without knowing what you are adding to it.
If you edit the sysctl.conf file, make sure to run sudo sysctl -p after to apply changes. I have noticed some settings related to disabling ipv6 do not stick after reboot.
They offer 3 mitigation’s, the easiest being enabling rp filtering. But…
“Also, it isn’t clear that this is actually a solution since it
appears to work in other OSes with different networking stacks. Also,
even with reverse path filtering on strict mode, the first two parts of
the attack can be completed”
You can see all the different rp_filter options using
sysctl -ar '.rp_filter'
0 = none
1 = strict
2 = loose
I do look forward to the paper they release though
“We have prepared a paper for publication concerning this
vulnerability and the related implications, but intend to keep it
embargoed until we have found a satisfactory workaround.”
So far, any changes I’ve made to sysctl.conf, in regards to both ipv6 and rp_filter, have persisted after reboot on Parrot when installed to a HDD. Somewhat unrelated, the same goes for custom DNS entries written to dhclient.conf. My vague understanding of why those settings might not stick after reboot on Parrot is that the default implementation of anonsurf may have need to rewrite those entries? I have not used anonsurf in relation to the Parrot install that I have been testing yet. I have only used anonsurf on a live environment, in which I did not alter the defaults in sysctl.conf, or dhclient.conf for that matter. I plan on continuing to experiment with this, as I am more familiar with vanilla Debian then the way in which Parrot OS is configured.
I imagine that it would be possible for a VPN user, concerned about DNS leaks via ipv6 and this developing situation regarding the vulnerability of tunnled vpn connections, to write up a fairly simple script to set sysctl.conf to their preferred values regarding ipvs and rp_filter, should they also use anonsurf and are concerned with a conflict arising there.
@KidKlown I also look forward to reading this paper when it is released.
Thanks for mentioning that rp filtering may not be a silver bullet in this case. Also, I believe that in some situations strict rp filtering can cause problems, depending on the users network configuration. I have yet to notice any issues when rp filtering is enabled on something like a simple wifi connection, but this is, of course, user and case specific. As for a firewall based solution, perhaps this is still a work in progress?
Here is a link to some discussion regarding this developing issue, as it relates to WireGuard and possible mitigation via iptables and nftables.
I find the timing of the release of this vulnerability superficially interesting for a couple of unrelated reasons that may or may not be worth mentioning here. First, as can be seen in the link relating to wireguard, we are now in an era where both iptables and nftables must be considered. For some, this might complicate matters. Second, as this vulnerability is being disclosed, Debian developers are currently holding an open vote regarding alternatives to systemd.
Granted, this recently disclosed vulnerability is not necessarily systemd specific, as it seems to be a problem with nix network stacks in general, but the discovery of this vulnerability seems to have been noticed due to a change in the way in which systemd was implemented.