Regarding "Inferring and hijacking VPN-tunneled TCP connections"

Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Jason A. Donenfeld]

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Vasili Pupkin]

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.

On 05.12.2019 22:13, Jason A. Donenfeld wrote:
> 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
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[zrm]

On 12/5/19 14:13, Jason A. Donenfeld wrote:
> 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
> WireGuard@lists.zx2c4.com
> 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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Jason A. Donenfeld]

Hey Vasili,

On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin <diggest@gmail.com> wrote:
> 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.
>

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Vasili Pupkin]

On 05.12.2019 23:24, Jason A. Donenfeld wrote:
> Hey Vasili,
>
> On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin <diggest@gmail.com> wrote:
>> 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.
>>
> 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
>
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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[William J. Tolley]

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.


On Thu, 2019-12-05 at 21:24 +0100, Jason A. Donenfeld wrote:
> Hey Vasili,
> 
> On Thu, Dec 5, 2019 at 8:50 PM Vasili Pupkin <diggest@gmail.com>
> wrote:
> > 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.
> > 
> 
> 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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Jordan Glover]

On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:

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

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

Jordan
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Jason A. Donenfeld]

On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
>
> On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> >
> > If we can make nft coexistance work reliably, perhaps we can run the
> > nft rule on systems where the nft binary simply exists.
> >
>
> Will this work correctly on systems where nft binary exist but only
> iptables rules are used?

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

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Jason A. Donenfeld]

Hi Vasili,

On Thu, Dec 5, 2019 at 10:28 PM Vasili Pupkin <diggest@gmail.com> wrote:
> 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

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?

>  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

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Vasili Pupkin]

On 06.12.2019 18:08, Jason A. Donenfeld wrote:
> On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>> On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>>
>>> If we can make nft coexistance work reliably, perhaps we can run the
>>> nft rule on systems where the nft binary simply exists.
>>>
>> Will this work correctly on systems where nft binary exist but only
>> iptables rules are used?
> That's what I meant by, "if we can make nft coexistance work reliably."
>

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Jordan Glover]

On Friday, December 6, 2019 4:03 PM, Vasili Pupkin <diggest@gmail.com> wrote:

> On 06.12.2019 18:08, Jason A. Donenfeld wrote:
>
> > On Fri, Dec 6, 2019 at 4:06 PM Jordan Glover
> > Golden_Miller83@protonmail.ch wrote:
> >
> > > On Thursday, December 5, 2019 8:24 PM, Jason A. Donenfeld Jason@zx2c4.com wrote:
> > >
> > > > If we can make nft coexistance work reliably, perhaps we can run the
> > > > nft rule on systems where the nft binary simply exists.
> > >
> > > Will this work correctly on systems where nft binary exist but only
> > > iptables rules are used?
> > > That's what I meant by, "if we can make nft coexistance work reliably."
>
> 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.

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Vasili Pupkin]

On 06.12.2019 19:12, Jordan Glover wrote:
> 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.
>

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Vasili Pupkin]

On 06.12.2019 18:18, Jason A. Donenfeld wrote:
>
>>   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
> 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.

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Regarding "Inferring and hijacking VPN-tunneled TCP connections"

[Lonnie Abelbeck]

> On Dec 6, 2019, at 9:18 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> Hi Vasili,
> 
> On Thu, Dec 5, 2019 at 10:28 PM Vasili Pupkin <diggest@gmail.com> wrote:
>> 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
> 
> 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?

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
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard