YT YouTube2Text

YouTube2Text → Transcripts → 004 Security Source Code Audit of Mullvad VPN by X41

004 Security Source Code Audit of Mullvad VPN by X41 — Transcript

by Open Source Technology Improvement Fund (OSTIF) · 6,342 words · 895 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Um I'm Marcus Vier. I'm yeah doing
0:03security for I don't know last 20 years.
0:06I've been part together with Eric. um uh
0:10in the this this review of Mulvat and
0:13yeah we thought that we bring this to uh
0:16the OST um because yeah it's also let's
0:20say open source uh open source project
0:23and I think it fits very well um into
0:26the topic of how to audit really complex
0:30um applications that are crucial for
0:32internet infrastructure and security um
0:36of everybody. But um yeah, let me pass
0:38on to Eric to also introduce yourself.
0:42Yeah, hi, I'm Eric. Um I only took a
0:45minor part, minor role in this audit. Um
0:49but yeah, I'm happy to present a bit
0:51with Marcus. Um we had two other team
0:53members um JJ and Robio who were part of
0:58this
0:59um and yeah, glad to be here.
1:05Okay, then um yeah, I guess we're going
1:07to jump right into it. Um I hope you can
1:11um all see uh the uh my screen share my
1:16slides. Yeah. Um so yeah, we're going to
1:19talk about the security audit of
1:21MulvatVPN and uh in particular about the
1:23client applications. Um and yeah to us
1:27has been mean very interesting audit as
1:29I said before um because it's uh it's an
1:34it's an application stack that is across
1:35multiple platforms it had been audited
1:38before um because that's what they do um
1:42I think every two years at least and um
1:46yeah the audit was I mean still kind of
1:48recent end of last year um as as Eric
1:52said team of um team of
1:56uh four people um and yeah in October
2:00November and um of course I want to say
2:02everything that we present here is
2:04already addressed so Mulvat addressed
2:06the issue swiftly and yeah was very
2:08cooperative in the audit uh which is I
2:12think one of the main points even
2:14today. So the scope or what we uh what
2:19we were kind of asked to review are um
2:23the client applications for different
2:25platforms and um the there are a bunch
2:28of them. Yeah. So you have Linux uh
2:32Linux clients, you have Mac OS, you have
2:34Windows, Android, iOS and um we reviewed
2:38uh my client applications in particular
2:42um kind of a shared codebase and demon
2:45services. Uh we reviewed graphical user
2:48interfaces, command line interfaces and
2:51configuration. Um what was out of scope
2:54of this audit were all the servers back
2:57end and infrastructure
2:59um and also most of the dependencies
3:02because I mean as you will see there's a
3:04lot of them um but we focused on really
3:07critical ones um in the set check um
3:12yeah the code is um yeah open source you
3:14can um find it on GitHub
3:17uh in this link slides will be shared
3:22Sure. Okay. Um yeah, on the bottom right
3:26you will see why we didn't uh review all
3:29the dependencies because there's a lot
3:31of them. Yeah. Um there's also a huge
3:34amount of code. Yeah. If you look at the
3:36commits even over time um uh there's a
3:40crazy amount of code that
3:44um um yeah uh this is kind of scary.
3:48Yeah. If you look at it and also the the
3:50rate that the that the code is being
3:52developed at I mean you can see as well
3:55is uh super
3:58high. Um yeah the codebase is uh mostly
4:03written in Rust. Yeah memory safe
4:06language uh also
4:08crossplatform. Um so Android, Linux,
4:11Windows and OSX or Mac OS nowadays is
4:14covered but um there's also iOS. So
4:17there was also a bit of swift code.
4:18Yeah. And also of course um dependencies
4:21and so forth. Uh so there was a huge zoo
4:24of different programming languages, code
4:28and so forth and um I mean as you can
4:31imagine full source code review that was
4:33completely out of the question even due
4:35to the size of that code base due to the
4:37complexity and um also because uh by
4:41nature the interaction of these
4:44applications is high with system
4:47operating system other systems back end
4:51and different photos.
4:54So naturally this led us to an approach
4:59that is not let's say the typical source
5:01code review. Yeah. Because it's just
5:03like impossible to review all that
5:05source code. Um which is more aligned to
5:09yeah a white box pentest with source
5:12code access. Um I have to say that uh
5:15our team focused um a lot or a lot of
5:19the efforts on actually reviewing source
5:21code. Um but uh we based that on a
5:26threat model that we developed um
5:29beforehand and also agreed upon with uh
5:31with the project. Yeah. And um yeah,
5:36doing that we applied a lot of manual
5:38code review, static code analysis and
5:40but also a lot of dynamic testing and
5:42also always came back to the threat
5:44model.
5:49Yeah. Um Eric, do you want to say
5:51something about threat modeling? Yeah.
5:54Um the the idea about the threat model
5:56is to better understand um the attack
5:59surface and um where the threats
6:02actually might come from. And
6:05um sometimes when when working with open
6:08source projects, you are lucky and
6:09people already have something like a
6:11threat model. Um with Matum, I think
6:13some parts were already there um from
6:16from former audits. Um quite often you
6:20don't have anything um from the project
6:23itself, right? Um so you start to look
6:27at the documentation um and get some
6:30pointers from there. Um some things that
6:33you can base your thread model on is
6:36like common sense. Um and you can also
6:39look at similar products. I mean um
6:41there are other VPN products out there
6:44as well. So you could look at them and
6:46see what are their assumptions and can
6:49we transfer them to to
6:51Mulvat and um in the end make sure that
6:55you agree with the thread model that
6:57it's there because um sometimes
7:00developers might have a completely
7:02different use case in mind than their
7:03users and um they they might have a
7:06thread model for one scenario but the
7:08way the users are actually using the
7:10product is um um different from what the
7:15developer thinks and that's quite often
7:17the case with privacy products I guess.
7:20Um and yeah in in this case um we made
7:23sure that the shrap model is something
7:25that Mulvat and we agreed on. Um next
7:29slide please.
7:34And um this um uh yeah, we made sure to
7:37do this by having several online
7:40meetings um where we um went back and
7:43forth on the threat model and um we even
7:48um made sure that we have time in the in
7:50the project to create a full thread
7:53model. Um quite often you do it like
7:56quickly before even writing the offer
7:59because um once you know the threat
8:02model you know what you have to look for
8:03right you know um do you need to look at
8:06the dependencies is there another way to
8:08target the application
8:12um and this might um influence the
8:15amount of time you need. In this case,
8:17the threat model was part of the
8:19project. Um, so we could spend a bit
8:22more time on that and uh um made it u
8:28like not completely formal but um still
8:32detailed enough uh so we could work with
8:35it. Next slide.
8:39And um when you look at the VPN client
8:42um at least one part for the thread
8:44model becomes quite quite clear um once
8:48you start drawing a diagram that shows
8:50you the actors involved right you have
8:51your client that wants to connect to to
8:55a peer that's um the um the the item on
8:59the right and it wants to connect to
9:03that pier through the tunnel. So you
9:05have the client, the peer and the mat
9:07relay that terminates the VPN, but you
9:11also have um the internet provider
9:14involved. You have um some third parties
9:17involved that do the routing. So you can
9:21get some parts of the shred model
9:22already quite easily from um your
9:25network diagram.
9:27Um but there are other parties that
9:29might be involved that um are not as um
9:32easy to to see. Um and one party might
9:37be another person on the client
9:39computer, right? If there's a second
9:40user account that might be
9:42compromised, is that something that you
9:44would um consider as a tech surface? And
9:48for move, this was quite clear. um the
9:51the target audience for the product is
9:54end users and they're um they they they
9:59can safely assume that there's only a
10:00single user in most cases and um all
10:04users on the computers are trusted
10:06anyhow. So they they clearly define that
10:10um a compromised second user on that
10:13machine or a compromised client is
10:16outside of the threat model. Um, another
10:19thing that's
10:21um that uh you might want to look at is
10:24um what about um malicious people at
10:27Mulvad, right? Um so what what kind of
10:32attacks could they perform? But that's
10:34also something that when you talk to the
10:36projects um you can see whether that's
10:39something they want to protect against
10:40or not. And um in this case it's also
10:44something that will be regulated in a
10:46nontechnical way, right? I mean
10:48um um
10:51the yeah if you have in a kind of supply
10:55chain or something that's nothing that
10:56you can prevent by modifying your code
10:59base right so these were not the things
11:01we were looking for um but we were
11:04looking for data leaking into the
11:07internet um can attackers on the local
11:10network perform attacks that might leak
11:12data
11:14um these were the kinds of attacks that
11:16were defined in the strat
11:19model. Next slide.
11:23Yeah. Um uh that's something that uh I
11:28want to stress uh that in this order um
11:32was was say very helpful and I I feel
11:36like now I I sound a bit nostalgic but
11:39um that has been a bit lost I think
11:40after co is that in this audit we kind
11:44of went onsite and um nowadays uh
11:48meaning 24 25 um most code reviews I
11:52think for most of the audit firms are
11:54performed remote and um that's uh it's
11:59fine. Yeah. And because also many of the
12:01teams are remote and everybody's used to
12:03working remotely together in video
12:05calls, chat and everything.
12:07Um in this case the the the MVA team
12:11there was in one place so in Gutenborg
12:14in Sweden and uh this is of course also
12:16fine but what is even better is that um
12:19we had two auditors was Robia and me
12:23that could visit them and um this was
12:27really really helpful um because uh the
12:32interaction with the developers on a
12:34personal level but also let's say the
12:37easiness of uh asking questions or
12:41talking about things uh with with
12:44developers maybe not with one but maybe
12:46a talk with two or three that helps a
12:49lot. So um and this is something that I
12:53I want to stress and this is something
12:55that I think um could be something for
12:58larger open source project as well.
13:00Yeah, just just a suggestion that
13:03um this kind of local interaction at
13:06least for a few days um uh yeah would be
13:09very beneficial and we um uh we did not
13:13do the full audit on site but we
13:15basically were one week together with
13:17the actual developing team and um yeah
13:22and the side effect also is that
13:25um um the auditors are also in one
13:28place. Yeah. meaning that even some
13:30after after after hours you have some
13:32discussions and that also helps with
13:34really deeper understanding for complex
13:36audits and this audit definitely was a
13:38complex audit. Um and there it is it is
13:42really good also to yeah to be to be
13:44kind of slow to
13:46that.
13:48Um yeah if uh Eric said about the threat
13:52model
13:54um it might sound a bit boring. Yeah,
13:56for some people that say like, yeah, I
13:58want to find bugs and I want to go right
14:00into it and I would call this is more
14:02the buck bounty approach. Yeah, which is
14:04also legit. However, if you review a
14:08complex product and you want to interact
14:10with people about this product and you
14:12want to also uh report valid bugs only.
14:17Yeah. Um then um you need to do a proper
14:20discussion about this threat model if
14:22nothing if none exists before. Yeah. So
14:26um you should do that of course with
14:28your co- auditors so you're also all
14:30aligned on the thr model with the actual
14:32developers of course and project
14:34managers but I mean also with yourself
14:38um especially discussing it with the
14:40developers is very often super fruitful
14:43because um in most cases you get the
14:45first few bucks for free um because um
14:49you're challenging the beliefs that the
14:50developers have about the threat model
14:53and quite often um that's when they
14:56recognize they they have some
14:58architectural or design issues in their
15:00code and um when when you ask about
15:03specific implementation syncs during
15:05this discussion um you quite often also
15:07get something like yeah we didn't do it
15:11that way but this way which is not good
15:14and if it's not good there it's also
15:15probably buggy in these other three
15:17cases and you can already start writing
15:20the report right it's um always
15:22useful Yeah. Yeah. Yeah. And um it's
15:26also good to to talk about the threat
15:28model and yeah, as Eric said, challenge
15:31it.
15:32Um and uh that also helps you a bit as a
15:36kind of reality check. Yeah. When you
15:37dive deep into the technical details or
15:40into bugs, but um I mean the threat
15:43model actually starts not at the
15:45technical level. And it's also a bit of
15:46a reality check if it's done right.
15:48Yeah. I mean there can be invalid threat
15:50models that excludes stuff that
15:52shouldn't be excluded but on the other
15:55hand um I mean as Eric said yeah before
15:58we uh for example had to decide our
16:01local users a problem or not yeah um can
16:04they just uh can they just pull the
16:06network plug yeah then um if they're if
16:09they are local user um or physical have
16:12physical access but maybe denied of
16:15service on the software level there is
16:17not that that bad So um or maybe it is
16:21so and that's what you what you
16:23discussed but I mean the most important
16:24thing is what must never happen. So
16:27that's actually a question that
16:28everybody even the most technical person
16:31uh and the least technical person at the
16:33same time they all should ask this
16:36question. So and um uh what is also
16:41important of course is past
16:42vulnerabilities and their impact because
16:44then you can also see how is the
16:46understanding of the of the project um
16:50uh in general or so far. Yeah. Um about
16:54certain things
16:58um yeah and then I mean at the end what
17:01you want to find of course is security
17:03defects and vulnerabilities. Yeah.
17:05That's your job as a as a code auditor
17:07there. And um for that one um and then
17:11also to avoid the discussions the threat
17:13model again is um is important. Yeah,
17:16discussions can can unfold with the
17:20developers. Yeah, if you are not on the
17:21same page about what is a bug and what's
17:23not. Uh or of course the internet and
17:26especially in the case here of the OS
17:27tiff where a lot of reports are
17:30published. Uh what you definitely want
17:32to avoid is um controversial let's say
17:35discussions about are these bugs valid
17:38or not. Yeah. So so that's important.
17:41Get familiar with your target and also
17:43um draft the threatment and write it
17:45down and also discuss it and um that's
17:49um that's uh yeah reality to check it as
17:52well. And usually um these discussions
17:56are in the form that people want to
17:58downgrade issues you find and somehow
18:01define that they are outside of the
18:03threat model. And if you define the
18:04threat model beforehand that's this is
18:06way easier to agree upon whether
18:08something is inside or outside. Um in
18:11the case of Mulvet we had the other uh
18:15situation where we said okay we found
18:17something that's outside of the thread
18:18model and they asked us to still include
18:21it and rate it as a high finding which
18:23is um I guess a nice approach um to see
18:26that the vendor is not trying to
18:28downplay bucks but to um yeah actually
18:31rate them as they are and make sure that
18:33they are addressed properly.
18:37Yes. And yeah, the findings um are the
18:42yeah they were distributed the following
18:43way. So we had three high findings, two
18:46medium, one low and then we had three
18:48informationals. Um I mean you can see
18:50the absolute number of findings is quite
18:52high especially if you is quite low.
18:55Absolute number of findings is quite
18:56low. Uh especially compared to the size
18:59of the code base. Um and that can be in
19:03our mind attributed to a very high
19:05baseline security. Um um and also on the
19:08focus uh on let's say maybe deeper
19:12deeper bugs um that require um more yeah
19:16focus. And that's also something audit
19:19teams talk about if you do audits talk
19:21about that with the audit team if they
19:24should go deeper or if they if it's more
19:27about broad u broad. So if the if the
19:31resources are limited uh for sure do
19:33that. Um we also always rate the finance
19:36by CWE and I mean you can see here that
19:39the distribution except for one I don't
19:42know that by heart but appeared two
19:44times they were all let's say kind of
19:47different types of issues.
19:50Um yeah, let's go to the first um
19:54finding. Um
19:56um we don't have enough time to go
19:58through all the technical details, so
20:00let's speed run a bit uh through it.
20:02This was a very interesting one because
20:04it um it was the one that um um crashed
20:10or that uh that that is an issue that um
20:14happened even though uh for example I
20:17would claim that nearly everything was
20:20done right in the Rust uh code meaning
20:23yeah that it was memory safety was of
20:27high value and I don't think we found
20:29any kind of memory corruption Um also uh
20:34I mean but um we found a corner case and
20:38that is that a signal handers alternate
20:41stack was too small and what that means
20:43I want to and that that was uh present
20:46in the mold demon. Yeah. Um and it was
20:50present in the crash handler. So uh what
20:53that means is that there was a crash
20:55handler installed that was getting
20:58installed and catching sigb 6 fp six ill
21:02sixes uh signals. Um these signals are
21:07when an application is crashing they are
21:09triggered and if a signal handler is
21:12installed then um these uh the signal
21:15hand is run it usually it should do
21:17something like um lock the arrow or
21:21gracefully exit and so forth. Yeah. Um
21:26um not all of them and you see here six
21:28segmentation fault. Okay. If you have a
21:30segmentation fault it's kind of a hard
21:31crash and might also be a security
21:33issue. Um uh but there's also others
21:36yeah s FP that could happen with
21:39division by zero depending on yeah uh
21:42some conditions and how how things are
21:45compiled but yeah anyhow uh things can
21:48these crashes can happen. Now we have to
21:51say that we didn't find a way to trigger
21:53them. Um but um if it was triggered.
21:57Yeah. Um the interesting point was okay
22:00then here the signal handler is
22:02installed. There's no way around using
22:05safe rust to install that signal
22:06handler. Yeah. Because by this is a
22:09low-level operation. Yeah. Just just
22:11just for the record. Um so but what
22:15happened is that signal handers they
22:17need to have their own stack. Why do
22:19they need to have their own stack? Yeah,
22:20because they uh run when something has
22:23crashed. So the original stack might be
22:25corrupted. So um yeah, the data of that
22:29signal handler needs to be stored in a
22:30location that is kind of clean. And for
22:33that one um here the developers um use a
22:38heap buffer. Yeah. Uh and in a vector in
22:41Rust um they um Yeah. I mean it's very
22:46an innocent bug. Yeah. So uh I think
22:50really everybody could have made that uh
22:52that mistake. Uh so the they used the
22:55lip six stack size. Yeah, this is like a
22:58default size. I think it's four in on
23:01x8664 it was 4 kilobytes. So page size
23:06and um they use that buffer and say like
23:09this is now a new stack. Yeah. And um
23:11you have to call the s stack. Yeah.
23:14because you have to um have to have to
23:17um yeah let's set that stack on that
23:19process.
23:21Now the problem is that this stack was
23:24too small for all cases. Uh meaning that
23:28if a signal is actually triggered um the
23:31stack could actually corrupt the heap
23:34and um um that uh is of course pretty
23:38bad. Uh yeah because st on the heap uh
23:41because then with a normal crash you
23:44can't get an exploit potentially
23:46exploitable condition.
23:49Um yeah, so there was a pretty
23:51interesting bug because it went kind of
23:53under the radar of the normal threat
23:54model, especially if you write a Rust
23:56application that you don't uh basically
23:58think about something could corrupt the
24:00heap. Um if you didn't do anything
24:04unsafe, obviously
24:06unsafe, but yes, your crash handler
24:09would kind of crash again potentially.
24:13uh uh I think it's something that that's
24:15not not expected for for most people. Um
24:19there was another issue uh which I think
24:22then the there was bit of a different um
24:26um let's say uh um or there's debate
24:31about it if this is uh how exploitable
24:34these conditions are but I mean we went
24:36with the this is undefined behavior
24:39there's um signal hander was using non
24:41async safe functions and non uh
24:44reentrren functions um meaning that this
24:49is uh the signal handler here and as I
24:51said the signal handler um should kind
24:54of print a back trace some lock. The
24:57problem is a signalander might be
24:59invoked in um an operation let's say in
25:03a lock
25:04operation and if then from this lock
25:09operation a s um inside the lock is
25:13called again logging
25:16um there might be invalid states. Yeah,
25:18because some of these functions output
25:20buffering and so forth, they have like
25:22internal buffers or internal states or
25:25pointers and so forth that
25:28um are not uh safe for um being caught
25:33again while they are running. Yeah. And
25:37um that uh is undefined behavior. Um
25:41um it might be hard to exploit or even
25:44trigger. Yeah. But uh this is still
25:47unrefined behavior and I mean as I said
25:49there could be uh things happening yeah
25:52corruption of pointers or other things
25:54depending on the function that is used.
25:56I think here the most of the issues
25:58should be output buffering. Um but even
26:01then yeah beta better be safe than
26:04sorry. So
26:08um Eric do you want to explain that one
26:10the site loading? Yeah I think from a
26:12technical point of view it's not that
26:14interesting. Um it's quite similar to DL
26:17site loading. Um the the Windows
26:20installer um is picking up an executable
26:23that's in the same um file directory and
26:27if it's there it will start executing
26:29it. And um this is um the the issue
26:34which for us was outside of the threat
26:37model because um if an attacker is able
26:39to write an executable um to a certain
26:42fast um it the the client machine um
26:47then I would consider that machine
26:48compromised right
26:51um there are these other examples where
26:54the installer might be on the file share
26:57and the attacker is able to access the
26:59file share And right but um this is
27:02something where we would have said um
27:04okay with the strap model given we would
27:07only do that um or only write it down as
27:10anformational
27:12um but requested us to um rate it
27:15properly um because it was an issue for
27:18them.
27:20Yeah. And um I I want to say that this
27:24is really a good example for
27:27um um for
27:31um a sensible approach uh to to real
27:34world security because uh theoretically
27:38um yeah I mean if an attacker places uh
27:41my manages files on your system and then
27:43somehow it's executed might yeah might
27:46say this there has been a problem before
27:48the execution. However,
27:52um yeah, if you visit a website and you
27:55download this
27:57taskill.exe or maybe the website has
27:59auto download and downloads it. Yeah.
28:01And it sits in your download folder and
28:03you didn't execute it, but then you
28:06download the trustworthy installer of
28:08your favorite VPN uh client. Um and then
28:11you execute that exter, uh unknowingly
28:14to you, it would execute also this
28:16malicious file. Um I mean there can be
28:20practical attacks obviously. Yeah. So um
28:22and that has happened before with DL
28:24site loading as well. Um or if you think
28:27about the installer sits on a network
28:30drive and there's also this weird task
28:33killi that you won't never execute but
28:36you execute the installer then um also
28:39that's um yeah kind of a practical
28:42attack that is uh in our mind also
28:46realistic.
28:50So um the next one is uh medium severity
28:55only. However, it was still an
28:57interesting one because it also cuts
29:00into this
29:02uh domain of operating system and um how
29:06networking works for example. Um so we
29:09found a leak of the virtual IP address
29:11of the um tunnel device. Meaning that if
29:15you have VPN tunnel inside the tunnel
29:18you have let's say an internet protocol
29:20address that um is is um yeah inside the
29:24tunnel and uh not visible normally to
29:27the outside. um in most VPN scenarios
29:31maybe it doesn't matter if it would be
29:33visible or not but in the case of a
29:36privacy um let's say preserving VPN use
29:40case
29:42um knowing that IP address and if it
29:45doesn't change that often might give you
29:49yeah some some evidence that a certain
29:51user is is you could kind of learn
29:55something about the user
29:56identity and This affected Linux and
29:59Android and um what happened is that the
30:03the Linux kernel um we found a quirk
30:06kind of in the Linux kernel network
30:08stack. I wouldn't say that is a bug
30:11because probably there's some kind of
30:13use case for it. But uh the point is
30:16that the Linux kernel if you have
30:17multiple network interfaces it will and
30:21you will ask on one interface for a
30:23certain IP address like do you have that
30:25IP address? Um
30:28then um it will answer even if the IP
30:31address is on another interface. Yeah.
30:33That you're not even that that's
30:34unrelated to it. Um you use this ARP
30:38address resolution protocol for that. Um
30:41and that's broadcast. It's super old
30:44protocol. I mean based off all
30:47the discovery
30:50um of of local devices IPS and um so you
30:54could we we found that we you could just
30:56query for um the the Mulvat range uh on
31:00and eventually you would get a response
31:02and then you like aha this
31:04user on that system is using MulvatVPN
31:07and also aha this is probably this user
31:10or it's the same user as
31:13yesterday and
31:15Um yeah, I'm not that great at doing
31:18diagrams, but um so this is uh if you
31:21imagine there's a victim device, uh it
31:23has a VPN connection with encrypted
31:26traffic and the attacker can just query
31:28that device and say like hey do you have
31:31that VPN IP that is I should be inside
31:34here. Yeah. So the uh interface on the
31:37right unrelated to the interface on the
31:39left but the Linux kernel would still uh
31:42let's say answer that and um in the
31:44report you find kernel setting to turn
31:46that off. So at least and I think uh
31:49move also filed like a um kind of a so
31:53submitted that to Android because
31:55Android by default also does that and it
31:58also affects of course other VPNs and
32:02devices.
32:05Um yeah so uh the next one um that's um
32:10also medium severity but also a very
32:12interesting one. It's a bit more
32:14complex. So let me start with some kind
32:17of preconditions
32:20um that uh also JJ asked me to to put in
32:25because a lot of people don't realize
32:27that
32:29um uh there's certain conditions when a
32:33VPN setup is is kind of in danger uh
32:36because if a network if an attacker has
32:39two critical network positions and these
32:42positions are they can observe serve or
32:45even inject into adjacent uh networks to
32:49the VPN client. Yeah. Where they can see
32:52the encrypted VPN traffic but right at
32:55the source. Yeah. They might not know
32:57which user that is or whatever but they
32:59can see there's somebody using a VPN and
33:02then they they generate and receive and
33:04submit traffic. Yeah. And then at the
33:07same time they are also able to see the
33:10tunnel exits. t exits or
33:14um even um the the the target of the
33:17communication. If you think about the
33:19the one of the first slides, this
33:22diagram. So, and if they can see both of
33:24them, then you can do things such as
33:27traffic correlation, but also there's an
33:30interesting injection attack that we
33:32that we found. Um I have to say that
33:35this was found is also by others a bit
33:38before a few years before. Um but yeah,
33:42we kind of want to feature it and I
33:44think we added some some aspects to
33:46that. So I uh painted this uh great
33:50diagram. So imagine you have a mullet
33:52client and they have a VPN connection
33:56with the Mulvat back end or a VPN back
33:59end and um they have an internal IP. So
34:04if they have an internal VPM IP, of
34:06course, there needs to be not network
34:07address translation. And so let's say
34:10they want to contact google.com. So what
34:12happens is they go over the VPN, the
34:16VPN, they go out of the VPN, but the VPN
34:20of course change their um uh change
34:22their IP address. So nobody knows that
34:24it's this client. So they go to
34:26google.com. Google says like, "Okay, I
34:28have a request here from this exit IP."
34:31and um they sent back sent back. So
34:34everything's great, right? Everything's
34:35protected.
34:37However,
34:39um if an attacker kind of assumes that
34:43there's a molvat user that is um talking
34:46to
34:47google.com and because um uh nowadays uh
34:52quick and other protocols use
34:54UDP you know there's a state on mobile
34:57that says like okay if the UDP packet
34:59comes from
35:00google.com I will forward it exactly to
35:02this client. I mean must be right how
35:05how else do you receive the response? So
35:08if the attacker knows that or wants to
35:10know google.com they can kind of flood
35:12and they can like fake the IP of
35:15google.com fake the answer. Yeah. And
35:18they flood the u the exit relay with
35:22different with UDP packets with
35:24different source ports until they hit
35:25one. And if they hit the right one then
35:29this traffic
35:31will be delivered to that client here.
35:35So now if the attacker can also observe
35:37how much traffic happens here on this um
35:40VPN uh tunnel at the client they can
35:43kind of easily correlate and say like
35:45okay there's um I send a lot of UDP
35:48packets and then there's a lot of
35:50traffic here. Yeah. So this is a kind of
35:52de anonymization attack that
35:56is not really a fault of move or any of
36:00the others. It's just how not and how
36:02this networking stuff works. Yeah. Um
36:07um so so I would call maybe design
36:09weakness or something that is the limit
36:11of
36:12what maybe the VPN in this way can
36:16provide. Um and um that's yeah that's
36:21that's a pretty interesting attack that
36:22we found. Uh it was found before or at
36:26least a variation of that uh called
36:29serverside attacks in us paper blind in
36:32on path attacks applications on two
36:34VPNs. Yeah. Um so that's uh after
36:39researching for for previous uh work
36:42then we found that as well. Yeah. We
36:44didn't know that before.
36:46Um what we found is that with increasing
36:51um usage of modern web protocols HTTP3
36:54quick and quick relies on UDP um you can
36:59also run this attack with TCP under some
37:02conditions but um yeah and uh present
37:05conditions is of course are of course to
37:07reiterate attacker can observe uh the
37:09network traffic of that client just not
37:11decrypt it just observe it and they have
37:15a list of potent potential move at exit
37:16IPs and they have the ability to spoof
37:19IP packets with a source IP of something
37:23on the clarinet some interesting site.
37:25Yeah, let's say you are let's say in a
37:26country that doesn't like you to visit a
37:29certain website and uh the the
37:33authorities there want you to want to um
37:36know if you did that they could try to
37:39run this attack. Yeah, because they
37:41usually also control all the ISPs and
37:43everything.
37:46Yeah. Um there's um uh a slight counter
37:52to that. Uh Mulvat has something called
37:55data and that is uh traffic generation.
37:57So they kind of generate random traffic
38:00um on your VPN connection that is kind
38:03of fake. Yeah. And that can at least
38:05partly mitigate it um I mean you could
38:09probably run some
38:11statistical attacks. Yeah.
38:13um or analysis on that but at least it
38:16will partly mitigate it uh by having
38:18this kind of decoy traffic. Yeah,
38:21there's a similar um one that we don't
38:25go into detail but by varying the MTU on
38:29the path uh between um the um the the
38:34exit and the um the target internet host
38:38and there you can uh the maximum
38:40transfer unit. You can also see if data
38:42is not used in normal VPN. You can see
38:45like wire guard. You can see that the
38:47sizes of the VPN packets change also.
38:50And then you can also dean anonymize
38:52kind of the user. Um same print
38:54positions as before the one
38:58before. Yes. So
39:00um uh some recommendations I mean you
39:04can read the report in detail on all the
39:06that it's public on the website of Tiff
39:08and also X41. Um so for the high
39:11security issues uh we uh I mean the
39:15increasing the stack size for the signal
39:17hers will mitigate this corruption. Um
39:21uh also not doing complex task in signal
39:25handlers is also something that um yeah
39:29um as it is from a security perspective
39:31advised. Yeah. um and only use async
39:34safe functions and um you can find that
39:37in man pages uh on at least on Linux um
39:41uh there's there's a there's an there's
39:44a dedicated man page for this one yeah
39:47and um um yeah for the site loading of
39:51course restricting execution of
39:54utilities to trusted code path
39:57um the medium severity ones uh if you
40:00randomize the virtual IP addresses per
40:02connection. I think that was done. Um of
40:05course this kind of leakage attack
40:07against the identity of pseudonym of
40:10that user is not possible. Um and um
40:15also this kind of obuscation techniques
40:17to mitigate this not based
40:19generalization
40:21um can help. Um we think that it's
40:26important that users know these
40:28limitations. Yeah. Um even the tour
40:31network has a similar kind of uh
40:34limitation. Yeah. If you have a um if
40:37you if you monitor let's say hidden
40:39service and then also a toll user and
40:42you suspect they using that service you
40:44can run similar attacks. So um so it's I
40:48think awareness is the key and yeah for
40:50the low severity issues um um I mean
40:54it's it's the same as for the other one
40:56uh MTEU um related. So that could be um
41:00could be mitigated by petting uh
41:05packets. Yeah. Um coming to the
41:07conclusion um yeah uh the target
41:10application demonstrated a high level of
41:12security that what made that's what made
41:14it um let's say um interesting audit
41:18because we had time to focus on um the
41:21non standard stuff and um that's
41:27contributes also to overall security of
41:29everybody. Yeah. So and uh I mean you
41:31could positive observations definitely
41:33you could see safe coding patterns and
41:34design patterns also having an effect
41:37positive effect on security uh also
41:40regular audits I mean they they writ out
41:43all the standard things yeah on the
41:45other hand of course there's always
41:46something to find yeah even due to
41:49changing the world is always changing
41:51and also something just that is let's
41:53say uh yeah was hidden for a while and
41:58um yeah I think having a good baseline
42:00security level uh which is something
42:02that the US tiff here is also uh what we
42:05like about the USF is um also the key to
42:09advancing security on the non-trivial
42:11stuff and to to go for deeper issues and
42:15uh enhance the security of protocols and
42:17also the awareness and about secure
42:20design. Eric, anything you have to you
42:23want to add? No, I think you summed it
42:27up quite nicely.
42:30Okay. And then I guess u that's the
42:34presentation part.

About this transcript

This page contains the full transcript of 004 Security Source Code Audit of Mullvad VPN by X41 by Open Source Technology Improvement Fund (OSTIF), generated from the public captions YouTube serves with the video. The transcript has 6,342 words across 895 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.