WEBVTT 00:00.000 --> 00:12.240 Thank you very much for having me and today I will be talking about protecting VPNs 00:12.240 --> 00:19.240 against decloking. It's just a little bit background about myself, so currently I'm a manager 00:19.240 --> 00:24.720 for development and quality engineering and the network management team at Red Hat. So 00:24.720 --> 00:29.560 we are responsible for network manager and them state network system all in some related 00:29.560 --> 00:36.440 projects. Before that I was a software engineer, basically working in the team and even 00:36.440 --> 00:41.820 before that I was actually a penetration test. So therefore like I have the history of 00:41.820 --> 00:48.640 breaking software and I have to fix it. This is quite useful to understand what security 00:48.640 --> 00:56.640 issues. I understand the security perspective and the developers perspective as well. 00:56.640 --> 01:03.320 So today as I said we will be talking about VPN decloking, decloking how to prevent 01:03.320 --> 01:09.080 this. So this is something a term that was coined by the VATons security with the 01:09.080 --> 01:18.760 CVE last year called Carnivision and the idea is that it's possible to manipulate 01:18.760 --> 01:26.280 the system so that it sends a packet to an attack instead of the VPN. Anyone heard 01:26.280 --> 01:31.080 of Carnivision before? Who has heard of this? 01:31.240 --> 01:40.120 If you. Okay. So this is the type of the title of their blog post where they describe 01:40.120 --> 01:45.880 that already gives some insights about the components that are required. So the title was 01:45.880 --> 01:55.040 how attackers can decloking or watching based VPNs for a total VPN dec. And so what are 01:55.080 --> 02:00.840 the key components that we will be talking about from tunnel vision perspective? So there's 02:00.840 --> 02:10.320 ones. There's DHCP dynamic cross configuration protocol. We doesn't know what this is. Perfect. 02:10.320 --> 02:17.880 Makes me save some time and so this is there to create the network to send the network 02:17.880 --> 02:25.440 configuration to the house and watching both VPNs. So who knows what's watching based 02:25.440 --> 02:31.440 VPN? Like what's the specific about watching based? A few. So that's good then because 02:31.440 --> 02:42.080 I will explain it. So in general like VPN is there. So you can connect to remote network 02:42.080 --> 02:49.520 from locally and there you. So you want your packets that you send locally to end up in 02:49.520 --> 02:55.760 the remote network and there's like the different techniques like one. For example that we 02:55.760 --> 03:04.600 want. Look into this IPSEC policy mode where you just encrypt the packet itself and then 03:04.640 --> 03:11.440 you can send it everywhere or what you're looking here as a watching based VPNs and there 03:11.440 --> 03:18.920 you have a watching tab on this system that defines that that graduates send the packets. 03:18.920 --> 03:25.920 Quickly mind about watching tablets. So this is like a very minimum example. It says like 03:25.920 --> 03:37.280 at the beginning or packets should be sent to the gateway that's ending in 23. So this one. 03:37.280 --> 03:43.840 So you can like reach the internet or any other house that's not local and to reach local 03:43.840 --> 03:49.360 like house locally to you. You have the other wall that just says like all IP addresses 03:49.360 --> 04:00.640 here you can reach on this device directly. And then like if you use a VPN, watching 04:00.640 --> 04:07.480 based VPN. So here at the top you see the old configuration that we are and now that we have 04:07.480 --> 04:15.160 two more walls like that in this case we use the whole 10 slash eight IP address space for 04:15.160 --> 04:21.800 the VPN. So in the internet work is this one and we reach this wire gateway inside the 04:21.800 --> 04:27.640 virtual private network and to reach this gateway and the other house could we have a second 04:27.640 --> 04:36.200 route. And what this makes this security relevant configuration because that's basically 04:36.200 --> 04:43.200 the policy to be encrypted packet to be not encrypted packet. So therefore it should be protected. 04:43.200 --> 04:55.520 The problem is or the problem that deviate and security raised with tunnel version is that 04:55.520 --> 05:02.480 DHCP that we talked about that that's local configuration system supports changing the 05:02.480 --> 05:14.880 routing table. There's this option 121 classed stage word option and this means the DHCP server 05:15.920 --> 05:24.560 can tell the system to use words like this. And the thing is I forgot to mention this before. 05:24.560 --> 05:36.320 So let's. So we have like this routing table how do you use this? It means like by default 05:36.320 --> 05:42.160 it goes there but how does this system to decide when to use this word instead? And that's the 05:42.160 --> 05:50.240 prefix thing you know here by 24. So the most specific the word is that word wins in the end. 05:50.240 --> 06:05.680 So I mean this so what what we have here we have at the top is see fs-8 vpn network and here we have 06:05.680 --> 06:15.120 a lot more specific words from the attacker and instead of using the vpn device tan 0 which means 06:15.120 --> 06:22.080 it's protected. We use the wireless device. It's like whenever the house tries to reach 06:22.080 --> 06:30.800 my peer address from the system the packets will be sent unencrypted locally. Any questions 06:30.800 --> 06:41.360 about this so far? Perfect. So this like originally this was reported 06:41.680 --> 06:49.920 so when a vulnerability in DHCP and what's your opinion is it one? 06:52.320 --> 06:58.960 So like it's property of the yeah the configuration of the vpn yeah I agree it's a good response 06:59.680 --> 07:06.560 yes so that if you look at the cvd page it currently says like the problem is from the vendor 07:06.560 --> 07:14.320 IETF and the product DHCP so so I will mention this later again because also fast like the 07:14.320 --> 07:20.640 maintainer or developers of network manager the good thing that it was reported as this was 07:20.640 --> 07:26.800 that it actually ended on our heads because we implemented DHCP with network manager or on 07:26.800 --> 07:36.480 internal clients so we became aware of this and then yeah one team member started looking into this 07:36.720 --> 07:43.200 in considering like some fixes so what do we do about this? Like there are some nodes in the 07:43.200 --> 07:49.520 description that said for example Android is not affected by tunnel vision because they do not 07:49.520 --> 07:57.280 support DHCP option one to one. So first thought is okay let's add an option to network manager 07:57.280 --> 08:02.960 that we can ignore this option as well so you just can configure this system so it doesn't break anymore. 08:03.440 --> 08:13.120 So we talked about this and like we did not really come to an agreement does this make sense? 08:13.120 --> 08:18.800 Is it the right solution? Is it not? There are some other options in software that you can use 08:19.440 --> 08:26.480 that are going to that network namespaces for example that allows to do some separation 08:27.440 --> 08:35.040 that's more than what we what I will describe later here but it's a lot more complicated to implement 08:35.040 --> 08:41.520 and network manager does not have support for network namespaces yet so it means it's a really 08:41.520 --> 08:48.320 big undertaking to change this directly network manager and so only that so currently we only had 08:48.320 --> 08:56.880 this solution ignore the DHCP option but then so I said no I'm a manager I'm not a developer 08:56.880 --> 09:03.200 anymore so I checked on this and then I said okay now that's to our point into annoying so 09:03.200 --> 09:07.920 I said then you go for the team this needs to be done differently because for example you need to 09:08.640 --> 09:12.960 like with this solution you would have to change like whenever you have a configuration for DHCP 09:13.520 --> 09:18.880 to ignore this option even the weather note you have VPN already configured because you might 09:18.880 --> 09:26.560 edit later so like my goal as manager was now we need to make it possible for the users to 09:26.560 --> 09:32.160 change the VPN configuration instead of the DHCP configuration but then with this solution again 09:32.160 --> 09:39.280 it becomes complicated because you're now affecting from the VPN configuration that is to peak configuration 09:40.160 --> 09:46.640 so the interface becomes really odd that we want to change this for all the 09:46.640 --> 09:51.120 like interface or not then need to configure in the VPN configuration only for this interface 09:51.120 --> 09:59.120 but not for this so still to complicated and then luckily the the one of my teammates in 09:59.120 --> 10:03.920 you go it sits right over there so yeah it's a great idea that we're going to use 10:04.800 --> 10:12.480 policy routing do you know what's policy routing who doesn't okay so that's expanded 10:14.480 --> 10:20.240 so first I said like they are routing tables that is that's head of the decisions where to put 10:20.240 --> 10:27.040 packets but that's not the whole two there's actually more than one routing table you know 10:27.920 --> 10:33.760 actually I wanted to check it like how many there could be maybe 32,000 maybe six probably 10:33.760 --> 10:41.200 something about 64,000 looking at this number and the one routing table that we looked to far 10:41.200 --> 10:47.520 was the main routing table so here in this policy let's look at the priority well I would 10:47.520 --> 10:52.560 rather like originally it's called priority but smaller like a look up order because like those 10:52.560 --> 10:58.560 number it's not the highest priority those numbers looked up first then we have some kind of policies 10:58.560 --> 11:03.680 for example in this case very simple from all so just effects everything and then look up 11:03.680 --> 11:12.560 the routing table and the one that we looked at so far was the main routing table 11:13.200 --> 11:28.560 and the idea to prevent that to change this to mitigate the tunnel vision attack is to introduce 11:28.560 --> 11:38.880 another routing table in this case you see it here it's called VPN and it has a priority value that 11:38.880 --> 11:47.440 makes it looked up before the main table and then you can add the routes that are meant for the VPN 11:47.440 --> 11:58.560 policy so like the whole network 10 slash 8 in this table and then it will be looked up first so 12:00.160 --> 12:06.160 like whatever options DHCP puts into the main what DHCP puts into the main table doesn't 12:06.160 --> 12:15.520 matter anymore because the VPN table will take care of this but then like we're in a security 12:15.520 --> 12:20.880 platform so what do you need in a security presentation you need some zero days what do you think so 12:23.120 --> 12:33.200 so the good thing like the method already prevents against other attacks and so on so kind of like 12:33.200 --> 12:43.040 the zero days will already be mitigated by this and then like when we looked at this for like initially 12:43.040 --> 12:48.080 like we also start okay DHCP is insecure you can configure things why is it even a security 12:48.080 --> 12:53.680 vulnerability then we thought about some other attack vectors for example what if the local 12:54.720 --> 13:02.320 network is already it has the same IP address range at the VPN so then you don't need the DHCP 13:02.400 --> 13:09.040 option one to one because they're all good already be the same and like some other similar attacks 13:09.040 --> 13:14.080 and then we found out there is actually this was actually reported 13:15.040 --> 13:18.880 a year before tunnel vision as well like there are some related attacks 13:20.480 --> 13:26.160 around this so that's called tunnel track and they split it in local net and server IP 13:27.040 --> 13:37.520 attacks that they're mostly targeting DHCP as well but also DNS because that if you think about it 13:37.520 --> 13:44.720 DHCP can come it's an untrusted protocol that can change something DNS at the same time 13:44.720 --> 13:53.520 is also not really very dated and if you have if you configure your VPN end point using a 13:53.520 --> 14:00.160 house name then like if the attacker controls the local network they can also change the 14:00.720 --> 14:06.960 reported IP address then again you can use this information to have too many played the 14:06.960 --> 14:17.680 watching table okay so maybe no zero days but that's not true because 14:18.560 --> 14:26.320 like we have in my team I really have very qualified engineers and another one the one who 14:26.320 --> 14:28.160 initially looked at this 14:31.040 --> 14:37.840 at this problem because we implemented it we did not only break it and in fact there are two more 14:37.840 --> 14:43.680 DHCP options where it can configure about so that like we only talk about one to one but there's 14:43.680 --> 14:50.160 also like the older one option 33 it's not as powerful as the other one because we can only 14:51.360 --> 14:58.240 configure this based on the historical classes of networks so that they're class ABC networks 14:58.240 --> 15:06.000 depending on the prefix thing but if you think about like some attack scenarios like where you 15:06.000 --> 15:11.600 want to just tunnel everything to your VPN so you just have the default wood then it's specific 15:12.240 --> 15:19.840 test ABC what is still more specific than the default wood so you still have similar attack 15:19.840 --> 15:26.720 vectors in this case and then Microsoft also has their own option as well that like we 15:26.720 --> 15:32.160 are getting support so we also knew about this so should this be two more zero days thank you 15:32.160 --> 15:42.480 we have also I don't know tunnel with and tunnel drift or something and there's even another zero day 15:43.920 --> 15:49.600 I just call it zero day for fun but I don't really think it's another vulnerability because 15:49.600 --> 15:54.880 like they were already sub-NCVs around the different aspects and like this is a topic 15:55.760 --> 15:59.360 this is something that has been often a topic at first and as well so I was wondering 16:00.160 --> 16:04.640 if anyone has a guess what it could be if you think about what we saw so far 16:08.000 --> 16:13.520 I wonder what happens if the local IP address in the network the entrusted network 16:13.520 --> 16:18.480 you're connecting to classes with the one you want to connect to yeah yeah I think that that's 16:18.480 --> 16:24.240 basically the local net like it's I would call it like a variant of the local net at 16:24.240 --> 16:30.400 fact because it assumes that you use the same local network as the VPN but if just the gateway is the 16:30.400 --> 16:37.040 same so you have like at least one house that could be the same the VPN anything like what 16:37.040 --> 16:46.800 innovation did be up in the network it forced them yeah IPv6 exactly so like all the examples 16:46.800 --> 16:56.560 let me saw only IPv4 and in what's the IPv6 so like there's also DHCPv6 but it doesn't 16:56.560 --> 17:03.040 support walls so is it safe or not no it's not because there's the status address out of 17:03.040 --> 17:10.320 configuration so water by default like everyone who supports IPv6 will accept routes that are 17:10.320 --> 17:15.840 announced by the water as well so in the end you you can do the same attack that's where but 17:16.640 --> 17:23.360 is this really big problem luckily not because Linux spots these wild policies 17:23.360 --> 17:29.120 modern type adjusts the same with IPv6 to the IPv4 so same solution you just need to remember 17:29.120 --> 17:39.040 that's also IPv6 coming or at first unless already there so what does it look like with net 17:39.040 --> 17:45.840 back manager currently so it's like the command line to it so there you can modify VPN 17:45.840 --> 17:51.200 connections and then specify about table so network manager doesn't support names for 17:51.200 --> 17:57.360 WhatsApp on the IDs because the name to ID mapping is something that's in user space that's 17:57.360 --> 18:04.640 not like an official API of the kernel so network manager cannot really rely on this and 18:05.440 --> 18:14.160 yeah do this for IPv4 IPv6 and then you can easily set things up and this seems to be like the 18:14.160 --> 18:19.520 first practical device how you can actually do this because like if you look at what should I do 18:19.520 --> 18:25.760 there's this there are a lot of theories like user different or I mean like the first solution is 18:25.760 --> 18:32.240 don't use DHCP okay and you add the hotel so you can choose this then you can use you can bring 18:32.240 --> 18:38.560 a second water so that also separates the entrusted network from the network that you want to use 18:39.120 --> 18:45.520 still you need additional hardware next thing you use a virtual machine basically the same thing 18:45.520 --> 18:49.200 but log on your machine for a little bit unconventional because now you have to work 18:49.200 --> 18:57.520 the virtual machine instead of your analysis and then kind of getting closer now we have 18:57.520 --> 19:06.640 the routing table which is just under system helps there mostly as well so sorry I forgot but 19:06.640 --> 19:12.400 then like the next abstraction is the network name spaces so it's also kind of a separation 19:13.120 --> 19:18.000 another layer on top of the routing tables we can have different routing tables for different 19:18.000 --> 19:23.440 processes or different containers which basically name space still a little bit more complicated to 19:23.440 --> 19:29.600 set up but now like we have this even easier solution it's just the routing table and you have 19:29.600 --> 19:37.280 like a generic solution both network manager we can just configure this for UVPN and it works 19:37.280 --> 19:43.200 more or less for UVPN plugins directly because network manager gets the route set up moves them to the 19:43.200 --> 19:55.120 right table so what should be the takeaways from this presentation so if you use water VPNs this 19:55.120 --> 20:00.320 means you're watching table becomes part of the VPN configuration so it's now security relevant 20:00.320 --> 20:08.240 setting if you think about security and so security users don't let DHCP and other protocols like 20:08.880 --> 20:17.600 SLag is the IPv6 configuration protocol or DNS which is also on on protocol change the VPN configuration 20:18.560 --> 20:27.360 and if it's going to be accepted there will be a presentation about improving 20:27.360 --> 20:33.440 configuring encrypted DNS with network manager as a lighting truck I think there will be 20:33.440 --> 20:39.920 tomorrow so if you want to follow up on this there's something and the other thing is about CVEs there's 20:39.920 --> 20:46.880 also problem with the reporting how you do this for this kind of vulnerabilities because like the 20:48.240 --> 20:56.000 CVEs might be too specific for example like the television just set you have option 1 to 1 it's problem 20:56.720 --> 21:04.880 okay I don't support option 1 to 1 now I'm safe but the concept of the problem is that you use 21:06.160 --> 21:15.120 that you have this untrusted protocol that now can configure your trusted settings because 21:15.120 --> 21:20.560 that what happens if I mean the option 1 to 1 exists for a reason because some people need this 21:20.640 --> 21:28.560 so eventually it could be added to the DHCP client as well also then another thing for example 21:28.560 --> 21:35.680 like what we did notice tunnel crack the order vulnerability or reported vulnerabilities about this 21:35.680 --> 21:43.920 was because they mentioned only specific VPN providers instead of making it a global like a generic 21:43.920 --> 21:50.320 conceptual problem so in man care I'm not using I don't know whatever VPN software there was 21:50.320 --> 22:00.880 so I'm safe again it's not really clear what to use and then yeah at the same time 22:00.880 --> 22:07.520 there is also two words like when you have like tunnel vision originally ietf as the window 22:07.520 --> 22:15.440 DHCP as the protocol but I know it works as specified as the problem and then so there's the 22:16.240 --> 22:21.760 outlook unfortunately there's there's some attack vectors in the configuration network so it's 22:21.760 --> 22:26.800 complicated to get this right I will follow up on this at some other point because we are in the 22:26.800 --> 22:32.720 auto time then for network manager we have to think about that I currently it's still a 22:32.720 --> 22:38.560 configuration option that you need to set but should this be the default or not so that's again 22:38.560 --> 22:44.560 like with this big other things where you're not so if anyone of you has any ideas about this we 22:44.560 --> 22:53.760 also have a network manager community meet up in the few hours and yeah document this thank you very much 22:53.760 --> 22:59.280 natural do we have time for questions or not okay yes or no