Regarding "Inferring and hijacking VPN-tunneled TCP connections"

Hey folks,

William unembargoed his nice vuln this week: https://seclists.org/oss-sec/2019/q4/122

It appears to affect basically most common unix network stacks. This isn't a WireGuard vulnerability, but rather something in the routing table code and/or TCP code on affected operating systems. However, it does affect us, since WireGuard exists on those affected OSes.

Some might chalk it up to just a configuration error, dismissing it as, "well, if you configure your networking stack poorly, bad things will happen," but I don't really buy that: the network setups affected by this vulnerability are pretty much the norm everywhere.

And it turns out that we actually are in the business of properly configuring people's networking stacks. Specifically, the tools we ship come with the little bash script, wg-quick(8), which is a popular way of automating some common tasks. We've started looking at kernel-level mitigations within the Linux networking stack, but before those are ready, I thought it would be prudent to put some first-level defenses into wg-quick(8) itself.

For that reason, since November, wg-quick(8) has added a few iptables(8) rules. I really dislike having wg-quick(8) grow any sort of dependency on iptables(8) (and eventually on nftables(8)), but at the moment, I don't see a viable alternative. Suggestions are welcome. In particular, we're adding a rule that is something like:

    iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP

where wg0 is the WireGuard interface and 10.182.12.8 is the local IP of the interface.

This says to drop all packets that are sent to that IP address that aren't coming from the WireGuard interface. And it's done very early in Netfilter, in the "raw" table. The researchers have confirmed that this mitigates the issue.

Adding iptables(8) into wg-quick(8) has been predictably problematic, and it'll probably be at least another snapshot until we get things bug-free on all the different variations of the utility that distros ship, but we'll get there. In the meantime, I'd certainly appreciate patches to do the same with nftables(8), as well as some fresh thoughts on how to accomplish this same thing _without_ the firewall. (In the process of writing this email, for example, I had an idea regarding ip-rule(8) that might work out, but I haven't tried yet.) We also have some non-Linux operating systems to consider.

Feedback welcome.

Regards,
Jason
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Isn't it enough to just enforce Strong Host Model, i.e. a host won't respond from it's IP that is not facing the interface. If a host is connected to two subnets 10.1.x.x and 10.2.x.x and have two IP 10.1.0.1 and 10.2.0.1, it will just drop all the packets sent to 10.1.0.1 that came from the interface 10.2.0.1 and vice verse. This model can be emulated using the FIB lookup feature of NFT with this one liner:

nft add rule inet filter input fib daddr . iif type != { local, broadcast, multicast } drop

this also works for both IP4 and IP6. This mode can be safely enabled on most setups not breaking things. Enabling it is a good precaution measure anyway and it is a shame that it is not widely assumed as default and standard.

Doing the same with just iptables isn't easy and can't be accomplished with one liner but nft perfectly coexist with iptables.

_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Hey Vasili,

That actually appears to work pretty well in my quick bootleg setup. Thanks. I'm adding William to the email chain -- perhaps he can try this and report back with his attack rig?

If we can make nft coexistance work reliably, perhaps we can run the nft rule on systems where the nft binary simply exists.

For cleanup, we'll need some way of marking that rule as belonging to wg-quick(8) for our interface. The iptables magic currently uses --comment for that.

There's also the issue with nft not having default table and chain names. Perhaps it'd be cleanest to just ad a new table and chain with a given name, and set that as a high priority input hook?

We'll also probably want to make this only apply to our interface, and not others, if that's possible.

Any downsides I'm overlooking?

William -- you might want to subscribe to follow along better:
https://lists.zx2c4.com/pipermail/wireguard/2019-December/004679.html
https://lists.zx2c4.com/mailman/listinfo/wireguard
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

I've just figured out that the same effect can also be achieved with iptables:
iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type LOCAL -j DROP

So it is very similar to your solution. It is not exactly the same to nft oneliner, because it drops multicast and broadcast packets, this can probably be fixed though the multiple -j jumps, I am not an expert in this though:
iptables -t filter -N NOTLOCAL
iptables -t filter -I INPUT -m addrtype --limit-iface-in ! --dst-type LOCAL -j NOTLOCAL
iptables -t filter -I NOTLOCAL -m addrtype --limit-iface-in ! --dst-type MULTICAST -j DROP

It should also be dubbed with ip6tables command to also filter IP6 packets.

There can possibly be systems where only nftables is installed and there is no iptables though.

In any case you can limit it to just one wireguard interface. It is a good precaution measure to enable it systemwide and rule out the CVE-2019-14899 completely and many other possible attacks. The weak host model used in linux by default is literally weak and a good system administrator should avoid it by all means. But for the sake of wg-quick the filter can be enables for wireguard interface only to be sure it wouldn't break anything else and in this case you can probably also ignore multicasts and broadcasts.

One can possibly has a sophisticated firewall rule that only accept some packets and his firewall will unintentionally dodge packets around our rules and I don't see how this can be avoided.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Hi Vasili,

Neat trick, but it still requires this to run on all incoming packets from all interfaces, right? In other words, it enables a strong host model for the whole system instead of just with regards to addresses "owned" by the WireGuard interface. Adding support for the latter would get us back to the original rule we're using right now, right?

How do you propose this works? That'd require adding -d, right? In that case we're back to more or less the original rule. If you do it with -i, then it fails to filter the bad packets that we want to be filtering.

Jason
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Actually it appears to be harder than I first think

The -d option will let broadcast addresses to pass the rule. Is it a problem here? In the original bulletin authors talk about TCP. Testing for interface name doesn't make much sense either, as you said...
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

For what its worth, if some sort of basic firewall with conntrack is enabled, Step 1 of the attack is blocked with a "ctstate INVALID" rule.

Per testing in the lab, using attack "nping --tcp --flags SA ..."

For Example, VALID_CHK in the (external facing) INPUT and FORWARD chains:
--
-A VALID_CHK -m conntrack --ctstate INVALID -j DROP
--
for both iptables and ip6tables filter tables.

Is it common some sort of basic firewall with conntrack is not enabled ?

Lonnie

_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Will this work correctly on systems where nft binary exist but only iptables rules are used?

Jordan
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

That's what I meant by, "if we can make nft coexistance work reliably."
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Take a look at the table on the bottom of this page
https://wiki.nftables.org/wiki-nftables/index.php/Troubleshooting#Question_4._How_do_nftables_and_iptables_interact_when_used_on_the_same_system.3F

On my system their rules coexist fine. Both nftables and iptables are just high level interfaces to kernel netfilter hooks after all, if either of them drop the packet then the packet is dropped. It is also possible to write the same filter using iptables, not as easy and not as beautiful as nft though. Finally wireguard can do this directly interacting with netfilter as the last resort.

I'd like if kernel developers reconsider the default system behavior on this... It is so stupid that the system expose all its IPs on all interfaces by default. But Linus don't like patches that break things and this will break some bad network setups, yes weak and insecure but still.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

But nft rule won't be visible from iptables tools like iptables-save, right? This may be confusing for people who still use iptables for setting up firewall on their systems.

Jordan
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Right. And for those using NFT, they will see a strange rule in their default inet filter table. Also nft users may delete this table or its input chain or alter the chain hook specification before calling wg-quick and in this case the magic command will crash. So it should be added to wireguard specific table instead of inet filter and this is actually the only easy way to revert the ruleset in nft, you should delete your table to revert the changes.

nft add table inet $table
nft add chain inet $table input {' type filter hook input priority 0; policy accept; '} nft add rule inet $table input fib daddr . iif type != { local, broadcast, multicast } drop

and then:

nft delete table inet $table

when we are done.
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

Hi all,

So the nft rule worked flawlessly on our Ubuntu machines, but I'm having trouble applying the rule in Manjaro (undoubtedly user error). I'll try again on some different machines in the lab.

Addressing zrm's question about carrying out the first two parts of the attack with rp_filter is strict mode - it should have been clarified that, as far as we know, this only affects certain systems with sufficiently complicated and/or misconfigured routing rules using connmarks and fwmarks, such as Android.

The patch was issued for Android in the September security update, however, I can still perform the attack without any modification. The difference now is that if I manually set rp_filter to strict on Android I can prevent the attack for IPv4 etc. Before this update, it would basically respond to any spoofed
packets addressed to the virtual interface IP on the wireless and/or mobile interface(s). This is CVE-2019-9461.

Thanks,

Wm.

_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard

One possibility that comes to mind is to add a new rpfilter mode between loose and strict that accepts packets from any interface with a route to that destination (like "loose"), but only if the route prefix is the same as the route that would be used for outgoing packets. That captures nearly the entire use case for "loose" (specifically the major case of multiple default routes) but then if you have a more specific route to a destination via a VPN interface, packets from that subnet are not accepted via a different interface just because that interface has a default route.

That leaves the case where the route through the VPN interface *is* a default route, but that could be solved by making it the *only* default route, which is desirable in general so that if the VPN interface is temporarily offline packets meant to be sent via the VPN don't use some other interface.

What's left of the attack after that is being able to determine the IP address assigned to another interface like the VPN interface. That one's hard because it's often legitimate -- if you have a multi-homed router and an internal host tries to connect to the public address of the external interface, you generally want it to actually work. It's also not clear if it's a huge problem on its own, particularly since you can still solve it with a firewall rule in cases where it's considered problematic.

Although we do have this text from the announcement: "Also,
even with reverse path filtering on strict mode, the first two parts of
the attack can be completed, allowing the AP to make inferences about
active connections, and we believe it may be possible to carry out the
entire attack, but haven’t accomplished this yet." Does anybody see how that would work? In rpfilter strict mode a spoofed packet for a connection routed via the VPN interface which is received via some other interface should be dropped before giving any indication whether it's for an active connection, shouldn't it?
_______________________________________________
WireGuard mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard