WEBVTT 00:00.000 --> 00:02.140 Thank you everyone for tuning in. 00:02.140 --> 00:05.240 I'm super honored to be speaking here today at DEF CON. 00:05.240 --> 00:07.520 This is my first DEF CON talk. 00:07.520 --> 00:10.420 I'm super honored to be here today. 00:10.980 --> 00:22.240 And I wish that we can all have a normal DEF CON and we'd be able to meet everyone in person, but hopefully next year when life gets back to normal. 00:23.040 --> 00:25.180 Yeah, let's start. 00:25.320 --> 00:26.980 So who am I? 00:27.000 --> 00:28.340 I'm Mazen Ahmed. 00:28.340 --> 00:33.860 I'm a cyber security engineer and I specialize in offensive security and APSEC. 00:34.180 --> 00:36.500 I also founded Fullhunt. 00:36.500 --> 00:47.160 If you haven't heard about Fullhunt, it's the next generation assets discovery slash monitoring, slash scanning, slash a lot of cool things that are happening in the background. 00:47.980 --> 00:51.280 If you haven't tried it or checked it out, you should definitely do. 00:51.280 --> 00:55.840 It will be one of the coolest things in security one day soon. 00:57.160 --> 01:02.700 Before that, I worked in the security engineering of ProtonMail. 01:02.820 --> 01:17.540 I was also, I'm also a bounty participant where I reported security vulnerabilities to Facebook, to the Department of Defense, to Twitter, and many others. 01:18.080 --> 01:32.200 I'm interested in web, infra, mobile, and cloud security, life evasions, security automation, and DevSecOps, and many other cool things in security. 01:33.040 --> 01:40.000 And you can read more at mazenahmed.net and you can find my contact details there. 01:41.520 --> 01:43.260 And yeah, let's start. 01:43.260 --> 01:46.920 So the agenda for today, of course, we're talking about hacking Zoom. 01:47.000 --> 01:51.500 Before that, we need to have a quick intro about Zoom, just in case. 01:52.740 --> 02:08.880 And then we're gonna have a background, findings, a retrospective on the Zoom's last minute VDP, recommendations, final thoughts, and then we would have a room for Q&A. 02:10.300 --> 02:12.860 Zoom, everyone knows it today. 02:12.860 --> 02:14.380 Everyone is using it. 02:14.380 --> 02:16.980 It's literally in everywhere in the world. 02:16.980 --> 02:20.680 Every company, almost every company is using it. 02:20.680 --> 02:24.040 Governments use it too. 02:24.340 --> 02:36.900 We saw last week the hearing of the Twitter hack where the hearing was done via Zoom and that hack happened at the hearing live. 02:36.900 --> 02:39.180 It was quite bad, but yeah. 02:39.180 --> 02:42.420 So this proves that everyone is using it. 02:44.070 --> 02:51.620 In May, 2020, the market valuation for Zoom is 50 billion USD. 02:53.520 --> 02:56.720 I'd like to bring this chart here. 02:56.720 --> 03:08.040 This is a comparison between the market capital of Zoom against the top seven airlines in the world, including United and Delta. 03:09.740 --> 03:22.380 So combining the top seven airlines' market capital, they are either equal or have a higher market capital. 03:22.380 --> 03:27.140 This is crazy just to think about it, how Zoom became today. 03:29.600 --> 03:33.600 And the rise of Zoom started with the global pandemic. 03:33.600 --> 03:35.180 Everyone knows about that. 03:38.200 --> 03:45.880 So from a stock performance, almost all of the companies were in the same range as we can see here. 03:45.880 --> 03:54.740 And then it jumped, it actually skyrocketed by May with all what was happening. 03:54.740 --> 04:03.120 And meanwhile, all of these top airlines were quickly falling down, as we can see. 04:04.360 --> 04:08.820 For me, I just find this really interesting to imagine how Zoom became today. 04:10.900 --> 04:14.820 Yeah, and because how important is Zoom? 04:14.820 --> 04:17.120 This is where my research started. 04:19.000 --> 04:32.440 So in March, March 2020, Patrick Walder gave a talk at Opcode about the Zoom security and the state of security at Zoom. 04:32.540 --> 04:40.360 And he disclosed a number of security vulnerabilities in the Mac OS client of Zoom. 04:40.880 --> 04:47.120 And this brings a lot of attention to the media and to me personally. 04:47.860 --> 04:53.540 And from that, I got more interested and started my research from there. 04:54.360 --> 04:57.180 So what was tested before? 04:58.680 --> 05:02.720 The Zoom Mac OS app, it was tested. 05:02.720 --> 05:12.080 We can read about it in the media and we can read about it in researches done by Patrick Walder and many others. 05:12.080 --> 05:17.040 It was hacked, it was really bad, it was reusing really bad practices. 05:18.040 --> 05:29.720 There was a lot of Zoom privacy concerns and the way that Zoom is sharing data to Facebook and a lot of things we can also see. 05:30.660 --> 05:33.840 But what was not tested before? 05:33.840 --> 05:36.040 Of course, many things. 05:36.240 --> 05:42.420 This is, I can just share two, but many things has not been tested before. 05:42.800 --> 05:49.500 For me, I'm trying to take into a couple of things and that I will be showing now. 05:50.040 --> 05:54.620 One thing that was not tested was the Zoom Linux app. 05:54.800 --> 06:03.400 Nothing, I have tried to search about any research or disclosure for any vulnerability in the Zoom Linux client. 06:03.400 --> 06:04.800 I haven't seen anything. 06:05.240 --> 06:09.980 This is one thing that I wanted to see or to focus on. 06:10.760 --> 06:19.460 The Zoom external attack surface, Zoom became huge and there was no focus on the external attack surface of Zoom. 06:20.680 --> 06:28.480 The Zoom cloud infrastructure, how it's being set up and different things related to the infra. 06:29.220 --> 06:34.200 And of course, the Zoom's new end-to-end encryption implementation. 06:34.200 --> 06:35.880 We have seen it to the media. 06:35.880 --> 06:37.760 Did anyone test it? 06:38.000 --> 06:41.000 We can talk about that later. 06:41.020 --> 06:42.280 And of course, many. 06:42.620 --> 06:45.440 There are a lot of things, I only focused on these. 06:45.440 --> 06:49.200 Definitely, there is a lot of room for research in this area. 06:51.560 --> 06:57.680 So the findings agenda, I'm not gonna go to each one of them now. 06:57.680 --> 06:59.580 We will talk about them later. 06:59.580 --> 07:04.780 It's just here for people who are curious to see what we're gonna talk about. 07:07.730 --> 07:12.690 A quick disclaimer, the entire research is non-funded. 07:12.690 --> 07:14.290 This is a non-funded research. 07:14.290 --> 07:21.790 I have done everything here in my spare time, just to confirm that or state that. 07:23.150 --> 07:28.890 The research background, the first finding that I identified was in April, 2020. 07:29.590 --> 07:35.150 And my expectations did not match what I was seeing in the media. 07:35.450 --> 07:38.310 We will know how later. 07:38.870 --> 07:48.010 The first conclusive response for my finding that I reported in April, 2020, I got it in July. 07:49.070 --> 07:54.990 This wasn't a very pleasing experience. 07:55.430 --> 07:59.530 And this after a lot of follow-ups, of course, from my side. 07:59.530 --> 08:05.130 And after submitting the CFP to Defcon, the second round of research started. 08:05.130 --> 08:14.270 At that time, I identified additional six new different vulnerabilities and security-related issues. 08:14.570 --> 08:18.410 And of course, everything was reported to Zoom. 08:19.630 --> 08:24.430 And the reward was zero dollars. 08:24.430 --> 08:27.510 Yeah, I just want to say that. 08:30.880 --> 08:39.520 So the first step for doing any type of offensive research is the reconnaissance. 08:40.140 --> 08:43.060 Understanding the attack surface. 08:43.060 --> 08:45.480 And that's where I started with. 08:47.460 --> 08:51.660 I used full-hunt.io to get the Zoom details. 08:52.220 --> 08:56.100 API returned around 13 domains. 08:56.100 --> 09:01.160 And this is the list of domains that was discovered. 09:02.160 --> 09:06.700 I took a portion of them and analyzed them. 09:06.740 --> 09:09.480 The remaining are there. 09:09.480 --> 09:14.520 If anyone would like to have a test drive, feel free. 09:16.360 --> 09:19.080 And let's go to the findings. 09:22.790 --> 09:31.490 One thing that I noticed that there was two servers that are having a Kerberos service running. 09:32.450 --> 09:37.770 And when I saw that, I got interested to see what's happening there. 09:37.970 --> 09:48.870 Apparently, there was two exposed Kerberos servers that was exposed unintentionally to the internet and no one knew about them. 09:50.310 --> 09:59.170 So this one had also a web service running on port 80 and it was FreeIPA. 09:59.170 --> 10:06.070 If you don't know what's FreeIPA, it's an identity management solution that was developed by Red Hat. 10:07.230 --> 10:10.330 It's open source, you can check it out. 10:13.340 --> 10:17.700 And I started by testing the web interface. 10:17.880 --> 10:29.800 As you can see, this screenshot, when you are providing an invalid username, you can see that there is a Kerberos error that is telling you that. 10:29.800 --> 10:55.100 And one thing that I did not mention here, that whenever you see a Kerberos server running, by itself, it's not huge, but once you compromise it or you have a single credential that is valid, then this would open a crazy large amount of attack surface for you to attack. 10:55.160 --> 10:57.260 And that's what I was doing. 10:57.300 --> 11:02.540 I want to get initial foothold there and then go from there. 11:03.640 --> 11:06.980 So I started doing user enumeration there. 11:06.980 --> 11:13.260 And you can see here, the previous one was showing that there was an error. 11:13.260 --> 11:17.040 This user is not found by the client. 11:18.700 --> 11:31.980 And here it's saying that the authentication failed or the pre-authentication failed, which means that we are able to identify valid usernames. 11:33.240 --> 11:44.310 And then I started building word list based on different things to identify more usernames so that I can brute force them. 11:45.280 --> 11:51.680 I compiled the word list from the pattern that I have seen. 11:51.680 --> 12:01.740 So the pattern that I have seen for the Zoom emails are firstname.lastname at zoom.us. 12:01.760 --> 12:08.900 Also the common usernames that I was able to find to get and employee names, of course. 12:08.900 --> 12:14.580 I compiled them all and I did that for user enumeration. 12:14.580 --> 12:20.740 The only users that I found was admin at idm.mezoom.us. 12:21.450 --> 12:26.970 I then ran a number of brute force sessions on them. 12:27.560 --> 12:30.820 Nothing interesting happened. 12:31.100 --> 12:38.460 Then I saw that I'm hitting a rabbit hole and it's a dead end. 12:38.460 --> 12:43.350 So I just moved to another more interesting thing that I can find. 12:46.160 --> 12:50.060 And yeah, it was a good choice. 12:50.840 --> 12:56.100 So the discovery of a memory leak on our Zoom production server. 12:59.340 --> 13:05.820 Zoom allows uploading profile pictures on accounts, which is the typical thing. 13:06.720 --> 13:12.660 The process for that is first, the user uploads a profile image. 13:13.420 --> 13:20.140 And the profile image is either JPEG, GIF, or PNG. 13:20.840 --> 13:22.980 And this is the tricky one. 13:22.980 --> 13:28.660 If the image is PNG or GIF, it's converted to JPEG. 13:28.660 --> 13:35.860 And if the image is JPEG, the image conversion is not triggered. 13:37.520 --> 13:48.640 And there is another thing here that if the image contains an invalid image header, the updating profile API aborts the process. 13:48.640 --> 13:53.400 So there is a good check in that image header. 13:54.480 --> 13:59.600 And it's using, of course, magic bytes, by checking the magic bytes. 14:01.500 --> 14:07.620 I like to test image conversion or processing softwares. 14:07.620 --> 14:19.500 Or whenever I see an API that is utilizing that or using that, I know for a fact that there is a large potential of having something bad happening. 14:19.800 --> 14:34.770 And the reason is because image conversion is not a vital functionality in an infrastructure of a company or even a web startup. 14:36.520 --> 14:45.640 So what happens is it often gets forgotten and there's no security updates that are being applied there. 14:45.640 --> 14:47.880 As far as it's working, then it's fine. 14:47.880 --> 14:50.520 This is something that I have seen as a pattern. 14:51.140 --> 14:54.840 And that's why I started testing that or focused on that. 14:56.720 --> 15:09.400 So one cool exploit here or security vulnerability that was released in 2016, it was known as the ImageTragic exploit or vulnerability. 15:09.400 --> 15:22.260 And this vulnerability allowed having remote code execution into the instance that is running the image processing when providing certain payloads. 15:22.260 --> 15:25.940 You can read more about the CVE offline. 15:27.520 --> 15:33.780 So I have tested this one and they seem to have this one patched. 15:33.780 --> 15:38.080 So I moved to the next one, it did not work. 15:38.080 --> 15:40.900 So I moved to the next one. 15:44.900 --> 15:50.240 There is a vulnerability in ImageMagick that was reported in 2017. 15:50.700 --> 16:08.400 And it works by having, whenever the palette is uninitialized or not presented in the GIF file, basically, ImageMagick leaks portions of the memory to the generated or the rendered image. 16:09.800 --> 16:18.280 And this is the fix for the vulnerability that was issued at that time around July, 2017. 16:20.220 --> 16:30.220 I generated a payload that renders this way in a normal browser or normal software that is patched. 16:30.580 --> 16:37.780 But when I upload the payload to Zoom, it renders this way. 16:40.770 --> 16:51.550 But if you are reading the report for that CVE, this is the typical behavior of having the exploit being successful. 16:53.550 --> 17:10.930 And if you download this image and try to obtain the strings from it, you will find that it's taking some portions of the memory. 17:14.800 --> 17:30.240 Then I thought that maybe this is an, let's say, image processing software fault or best effort just to render the image that is corrupted. 17:30.240 --> 17:37.360 Or there is a problem that is happening because of rendering a black image. 17:37.360 --> 17:48.280 So I generated a new one that is not the, like the payload, it's not the one that, this one has initialized palettes. 17:49.360 --> 17:52.520 And when I report it, it renders normally. 17:53.300 --> 17:55.660 Okay, this sounds really interesting. 17:55.960 --> 17:59.220 We have a memory leak on Zoom production. 18:02.600 --> 18:06.820 Typical thing is to automate the exploitation for that. 18:06.820 --> 18:30.160 And the flow for that would be to generate a new unique payload, then to upload it to Zoom, wait for the rendering to happen, download the rendered file, extract the data from the corrupted file that was rendered by Zoom, repeat and store leaked memory portions. 18:32.340 --> 18:35.160 So this proof of concept does that. 18:36.000 --> 18:41.320 So I'm going to have a demo time, which is cool. 18:59.230 --> 19:03.990 Here it generated the image and uploaded it to Zoom. 19:08.480 --> 19:10.580 I'm downloading the image now. 19:11.700 --> 19:15.560 And here, recovering the dump. 19:43.780 --> 19:50.800 So here, a memory leak on Zoom production was not the end for that. 19:53.900 --> 20:06.860 I remember that in 2018, Travis Romande released a research on Ghostscript, which was used by ImageMagick. 20:07.020 --> 20:13.420 And his research revealed a number of critical vulnerabilities in Ghostscript. 20:13.680 --> 20:25.620 And the proof of concept that he shared in the research when doing image conversion can lead to a remote code execution. 20:25.700 --> 20:28.000 And it was really cool to see this. 20:28.000 --> 20:34.280 And what I did is I used the proof of concept that Travis wrote. 20:36.020 --> 20:40.460 And I will show you this thing first. 20:42.080 --> 20:50.960 So we know for a fact that the 2016 v7.1.4, the image Tragic is patched. 20:50.960 --> 21:00.660 But we kind of think that the ImageMagick memory leak is presented based on the proof of exploitation we had here. 21:02.720 --> 21:09.900 And that one was patched and released, the patch was released in May 2016. 21:09.900 --> 21:15.740 And the patch for the memory leak was released in July 2017. 21:15.940 --> 21:17.680 And it's not patched. 21:18.100 --> 21:27.640 Based on that, we can safely say that the Ghostscript ROC is not patched, right? 21:30.550 --> 21:40.550 So I wrote, like I brought the proof of concept from the research that Travis Sormandy wrote. 21:40.890 --> 21:57.830 And I replicated it locally with the same environment I assume Zoom have it on their setup with the same range of versions that Zoom is using mostly. 21:58.470 --> 22:00.780 And yeah, it's working. 22:04.490 --> 22:16.970 Unfortunately for, or fortunately, I'm not sure which one would suit that, that Zoom API slash p slash upload checks for magic bytes. 22:17.170 --> 22:20.790 Otherwise a full exploitation would have been possible. 22:21.730 --> 22:27.170 But still, this does not mean that like Zoom is safe. 22:27.170 --> 22:41.770 If there is any particular API that is utilizing the same functionality and it's not checking the magic bytes, this would lead to a full remote code execution. 22:42.110 --> 22:44.110 This doesn't sound nice. 22:44.110 --> 22:46.890 This doesn't sound good by any means. 22:50.920 --> 22:59.440 And I don't know how to say this, but the RCE vulnerability is probably still there on Zoom production. 23:04.400 --> 23:09.680 Another thing we have here is the shadow IT and Zoom. 23:14.240 --> 23:29.980 I have noticed that there is a number of instances or cases where Zoom have shadow IT servers running in different host names and are not properly configured. 23:29.980 --> 23:37.220 And they may be a good target for conducting a successful attack. 23:37.220 --> 23:40.000 I have seen this in multiple occasions. 23:40.000 --> 23:54.940 This example here is showing an instance that did not have any patches since, let me check, September 10th, 2019. 23:54.940 --> 24:04.600 I took this picture in July 4th, 2020, around 10 or nine months of timeframe. 24:04.600 --> 24:09.940 There was no patches on that server or all new builds. 24:11.200 --> 24:18.260 And we all know that there was plenty of security vulnerabilities that was reported to them. 24:18.260 --> 24:21.480 And yeah, you can imagine. 24:23.020 --> 24:31.040 Another cool thing here is the same host had nine active connections, including me. 24:31.700 --> 24:53.660 Makes it an excellent fit for doing any type of testing without triggering alerts, which is cool, so that you can test it and be safe in the part that won't be as detected or detectable as in testing zoom.us, the main website, or yeah. 24:55.930 --> 25:02.470 Enough about all this, and let's start to talk about the Zoom app for Linux. 25:06.990 --> 25:20.130 One cool finding here, Zoom Linux client, so the TLS is broken by design on Linux, and you're gonna see how that is happening. 25:20.510 --> 25:28.330 I don't see this as the best practice, especially for the Zoom, but we can talk about that. 25:28.330 --> 25:37.450 So whenever there is any traffic that is intercepted with a custom TLS certificate, Zoom prompts this message. 25:38.050 --> 25:41.070 While it looks normal, everything is fine here. 25:41.070 --> 25:55.790 And whenever you click Trust Anyway, then you would have the traffic going with that, like with this accepted certificate, which is the unlisted one. 25:59.840 --> 26:12.160 But what happens here is that this certificate, like the fingerprint for this certificate is saved locally with the same permissions of the user. 26:12.840 --> 26:39.360 And you can simply just plug in, like if you have a malware that is able to have access to your machine, this malware can safely or easily just plug in to the fingerprint of the certificate, and then all of the traffic that is going to Zoom can be intercepted, 26:39.360 --> 26:58.500 even if it's using SSL or TLS, because the certificate will be accepted without having to have this type of prompts, because it was added to the local database on the background. 26:59.160 --> 27:11.980 So I wrote a simple proof of concept as a sample of what a malware would look like as just in a way or another as a concept. 27:12.680 --> 27:25.800 And this particular part of the malware or the proof concept would get the fingerprints for all of the forged certificates that we have. 27:25.800 --> 27:50.660 And then it would add it to the Zoom database, local database, and once it's added, these certificates can be provided to Zoom and all the traffic would be passing without having any error like this. 27:50.660 --> 28:02.580 And yeah, all of the encrypted traffic could be intercepted when having a malware running on the same user access as this one. 28:04.860 --> 28:10.060 Well, I have to say, this is not a really bad vulnerability. 28:10.060 --> 28:14.760 It's just a little bit not the best practice to do that. 28:16.180 --> 28:22.260 But as we are going now, we're gonna see something that is really bad and we're gonna see it now. 28:23.740 --> 28:26.580 So I would start with this question. 28:27.580 --> 28:31.280 What's a bad design for an application launcher? 28:32.780 --> 28:33.880 Good question. 28:33.880 --> 28:35.700 And we're gonna know the answer. 28:35.700 --> 28:45.360 So userbin slash zoom is a summary of OPT slash Zoom slash Zoom launcher. 28:47.690 --> 29:01.590 And whenever Zoom is called, Zoom is printing the following logging logging data on the SCD out. 29:02.750 --> 29:15.070 And there is a part where you can see Zoom path is OPT Zoom and then Zoom not exist at current directory. 29:15.970 --> 29:18.570 Okay, this looks interesting already. 29:22.410 --> 29:24.790 What's happening in the background? 29:25.530 --> 29:29.010 Zoom checks for files within PWD. 29:29.760 --> 29:43.230 And if there is an executable called Zoom, literally, on PWD, it executes it as a chat process for userbin Zoom. 29:43.720 --> 29:45.860 I was mind blown when I saw that. 29:46.910 --> 29:50.090 Why would this be there? 29:50.190 --> 29:52.370 This is a proof concept. 29:53.040 --> 30:07.790 I created a file called Zoom and then Zoom checks on the PWD if there is a file called Zoom, literally, and executes it. 30:07.870 --> 30:13.070 Of course, it has to be with an executable for permission, but this is not a thing. 30:15.110 --> 30:21.550 So imagine this, you have application-wide listing. 30:21.590 --> 30:26.470 There are a lot of points that I can make here, to be honest. 30:26.470 --> 30:33.770 I can make a lot of things that would show how this old design is there for. 30:33.970 --> 30:51.570 And if there's anything related to application-wide listing and your wide listing Zoom, this would literally break that because this is executed as a child process of a trusted application, Zoom. 30:55.920 --> 31:00.800 And yeah, it's bad practice and bad design by all means. 31:00.800 --> 31:04.310 Like why would this be implemented this way? 31:07.870 --> 31:09.980 So that's my answer. 31:10.100 --> 31:16.880 If it was a bad design for an application launcher, I would be Zoom application launcher for Linux. 31:19.430 --> 31:21.920 Another bad thing happening here. 31:23.310 --> 31:32.220 So the Zoom local database implementation, you'll see now. 31:33.570 --> 31:46.310 So in the configuration files of the configuration directory of Zoom, there is this file, the local database is zoomus.db. 31:46.310 --> 31:52.410 This is the default database and a lot of other files that are there for Zoom. 31:53.310 --> 32:02.630 The most important file is the zoomus because it has the access tokens, it has all of the PII for the user and everything. 32:03.620 --> 32:13.930 And as we can see here in the screen, the file permission is 644. 32:14.680 --> 32:16.180 I'll show you this. 32:19.160 --> 32:20.580 644. 32:20.580 --> 32:26.960 This gives to the user a write and read access. 32:27.420 --> 32:29.700 Okay, sounds reasonable. 32:29.700 --> 32:32.270 Nothing bad on that. 32:33.270 --> 32:39.150 Group access to give it read access. 32:39.150 --> 32:40.750 Why? 32:40.870 --> 32:43.130 I really like, really? 32:43.130 --> 32:45.590 Are you sure about that? 32:46.830 --> 32:59.370 But everyone to have read access into the Zoom local database of the Zoom user. 32:59.890 --> 33:00.910 Why? 33:00.910 --> 33:03.410 Literally, that's what I had in mind. 33:06.280 --> 33:22.220 Any code on the user machine that have access to the, like any code that have access to the user machine can read and exfiltrate Zoom local database and configurations and more, of course. 33:22.860 --> 33:34.540 Because the permission or the file permission for the Zoom local database is set to be read by everyone. 33:37.800 --> 33:42.460 And, okay, another thing that is quite cool. 33:43.300 --> 33:46.460 Zoom is end-to-end encrypted. 33:46.860 --> 33:48.020 Is it? 33:48.940 --> 33:54.220 We can see later, but my answer is not fully. 33:55.860 --> 34:01.600 One awesome product by Zoom is Zoom chat. 34:01.600 --> 34:32.760 And it's advertised in the website and that we can see here as a platform that is, that makes work and collaboration much easier in mobile and desktop and with a really clean design and UI that looks kind of similar to what Slack is having. 34:32.860 --> 34:38.180 This is not the point, but it looks good as a product, right? 34:39.560 --> 34:44.380 And as we go back here is, yeah. 34:45.900 --> 34:50.140 There are so many cool things to read, but I would focus on the security part. 34:51.140 --> 35:01.660 As we can see in the security and archiving and in I-Code, Zoom encrypts data at all times. 35:01.980 --> 35:17.800 Again here, encryption of data in transit and at rest and then encryption for data and mobile devices. 35:18.640 --> 35:22.060 Your messages in this chat are secured. 35:22.080 --> 35:23.640 Another one. 35:23.940 --> 35:32.180 So there are a lot of advertisement that is going with how secure Zoom chat is happening. 35:32.300 --> 35:59.520 And by security, they don't really or necessarily talk about application security, level of security, but they are talking about how all of the data that are being passing here is encrypted both at rest and in transit, which is in transit, I assume they're saying that it goes in SSL. 35:59.520 --> 36:00.800 It's cool. 36:01.300 --> 36:06.780 But at rest, this means that they have full end-to-end encryption happening, right? 36:09.760 --> 36:13.520 And yeah, repeating again the same sentences. 36:15.740 --> 36:17.640 And let's pause this. 36:46.960 --> 36:49.580 I'm not sure. 36:51.060 --> 36:53.360 This way is fine. 36:53.580 --> 37:04.420 But on the right screen, we have Zoom chat running and I have my group chat that is clear with no messages. 37:04.420 --> 37:16.800 And then I'm sending some sort of an encrypted message that is here because Zoom is E2E by now, E2E encrypted by now. 37:17.700 --> 37:19.680 As advertised. 37:19.680 --> 37:33.320 And then on the left side, we can see the local database, a custom one that is made by Zoom that we can see that they have it. 37:33.320 --> 37:41.540 And I can just read what's happening there and what they are storing on your local device. 37:44.950 --> 37:51.810 So here I sent a message and it's saying that this is secret. 37:52.630 --> 37:55.770 Oh, well, just one second. 37:55.770 --> 37:57.190 I have to repeat that. 38:12.650 --> 38:20.370 The message is being stored locally at rest in clear text. 38:24.630 --> 38:43.950 And here, anyone who is able to have access to the user machine is able to pull a full archive of all messages that are being sent that were or are supposed to be end-to-end encrypted and it's saved in plain text. 38:45.450 --> 38:47.450 And yeah, this does not sound good. 38:47.450 --> 38:52.630 And it's not the one that you can have a record or a backup for your messages. 38:52.630 --> 39:03.230 It's just a debugging feature that they left open in production for the Linux build. 39:03.270 --> 39:15.990 I'm not sure if this is applicable in macOS or in Windows, but you can see if that's being applicable here in Linux. 39:18.450 --> 39:27.910 By the way, the fact that the same database that for messages is having the 644, where is it? 39:27.910 --> 39:45.690 The 644 user permission, which means that any code that is running despite what type of user permission is running is able to access this end-to-end encrypted chat archive. 39:45.910 --> 39:47.390 Doesn't sound good. 39:49.490 --> 40:03.370 Yeah, so of course I could have gone more and tested more, but at the end, this is just a time that I have spending just to fuzz around with Zoom. 40:03.370 --> 40:12.930 I did this for curiosity purposes mainly, but definitely I could have spent more time. 40:13.950 --> 40:24.390 But then, yeah, I jumped to the responsible disclosure now, and I started the experiment in around April. 40:24.410 --> 40:46.850 April 15, reported that in April 18, I contacted Lotus Security in Twitter, followed up with the vulnerability disclosure again on 26, couple of messages on the background. 40:46.850 --> 40:54.560 And May 5th of 2020, I received request closed to memory leak at Zoom.us. 40:55.670 --> 40:57.560 Yeah, here. 40:58.570 --> 41:00.680 So yeah, I wasn't happy. 41:05.420 --> 41:07.950 So what's next? 41:07.950 --> 41:10.200 Tweeted about that. 41:11.090 --> 41:23.950 And then I was asked to send it via HackerOne, turn on communication running to run my automated exploit for the memory leak. 41:24.430 --> 41:35.350 Then when nothing seems to be happening, I informed Zoom that I'm planning to present my ongoing research here at DEF CON. 41:36.250 --> 41:50.690 And then Zoom told me that they cannot assess the issue as there was no sensitive data seen despite the predictability of the vulnerability on the provided exploit. 41:51.730 --> 41:56.550 Then it was closed as not applicable. 41:58.410 --> 41:59.990 Sure. 42:02.520 --> 42:16.200 Then I sent on July 11th, my new research results, reporting new seven different security vulnerabilities, six to seven new vulnerabilities. 42:16.940 --> 42:20.660 I got an acknowledgement about receiving my report. 42:20.660 --> 42:27.400 By the way, this is the first conclusive response regarding the memory leak issue. 42:29.100 --> 42:35.100 By conclusive, I mean that they did a full analysis of what was happening. 42:35.100 --> 42:44.900 On the previous ones on HackerOne, they triggered it as valid, and then they were trying to run my exploit, and that's all. 42:45.060 --> 42:53.340 But this one, they researched more and analyzed more about how this is happening and what was the cause of the issue. 42:53.800 --> 42:59.570 And it was in like literally three months after I reported it. 43:00.800 --> 43:06.860 Then further explanation from Zoom regarding the vulnerability or the findings in general. 43:08.520 --> 43:21.080 Okay, now with what was happening and then from their explanation, and then my response regarding each analysis that they provided. 43:24.180 --> 43:30.600 So for the public authentication, yeah, you can see what's happening here, what they wrote. 43:31.200 --> 43:33.380 And well, yeah, for me, yeah. 43:33.380 --> 43:38.740 Well, again, this may be a forgotten server that was mistakenly exposed. 43:38.740 --> 43:46.500 I haven't seen any references of 2FA being implemented, but in all cases, it's down now, so it's great. 43:48.740 --> 43:54.300 Oh, wait, I think I messed up with the messages here. 43:54.380 --> 44:00.980 Anyway, so this is the same slide from the last one. 44:04.120 --> 44:17.360 So we did check that ImageMagick is not used for image conversions here, but wait, the same vulnerability is being reproduced. 44:17.360 --> 44:33.560 It's maybe a fork of ImageMagick or an image processing software that is vulnerable to the same CVE of not being able to parse GIF images that have an initialized palettes. 44:34.060 --> 44:37.180 This sounds reasonable. 44:37.180 --> 44:41.340 In all cases, it's clear that something is wrong, right? 44:44.660 --> 44:48.120 Shadow IT and Zoom. 44:48.120 --> 44:55.200 So these are non-sensitive information disclosure from a shared environment. 44:55.560 --> 45:00.820 Information hygiene is important to us and we appreciate you reporting this finding. 45:00.820 --> 45:01.900 So that's great. 45:01.900 --> 45:07.840 So Full Hunt can help here, probably the best product out there for mitigating shadow IT risks. 45:10.880 --> 45:27.180 Oh, I think part of the discussion regarding the image conversion is not placed on the slide, but please check my blog after that to have the full list of discussion. 45:27.640 --> 45:42.840 So for what was happening for the Linux app findings, yeah, they fixed it or patched it in 5.2.0 that was released in August 3rd, I think. 45:43.480 --> 45:50.120 They were supposed to patch or release it on August 2nd, but it was released on August 3rd. 45:50.120 --> 45:53.920 In all cases, I have read the change log. 45:53.920 --> 46:00.140 There was no mention whatsoever for any security patches. 46:00.140 --> 46:06.700 So clearly it was a silent fix, which it wasn't a nice thing. 46:06.700 --> 46:16.280 At least users should have some transparency of the state of security for the company that they use or trust. 46:24.490 --> 46:25.990 Yeah, the patches. 46:25.990 --> 46:34.240 I just told you about the patches for what happened for the Zoom Linux app. 46:35.390 --> 46:51.310 For what was happening with the image conversion, they decided to not patch it because they are not seeing sensitive data and then that are being exposed. 46:52.150 --> 47:08.310 Then what happened is they asked, they stated that they are not using image magic, but still the same behavior of the vulnerability is being reproduced as a result of the image conversion. 47:08.310 --> 47:19.310 So clearly something bad is happening, but I'm not a part of Zoom or I don't have a say on Zoom to have them fix that. 47:19.310 --> 47:29.630 So my responsibility is just to, as part of the research that I'm conducting, is to just let them know. 47:29.630 --> 47:30.710 And that's all. 47:31.690 --> 47:33.050 What else? 47:33.350 --> 47:43.450 The findings, the shadow IT, I'm not sure if they started reviewing all of their shadow IT instances. 47:43.450 --> 47:46.150 That's something that they are supposed to do. 47:46.150 --> 47:50.910 For the Kerberos server, they took it down, which is good, which is awesome. 47:52.630 --> 48:07.990 And yeah, they told us, they told me that they are patching all of the vulnerabilities for the Linux app on the release of August 2nd or August 3rd. 48:07.990 --> 48:15.570 It was released with no mention for any security fixes or updates. 48:18.260 --> 48:27.400 Yeah, for me, it was a difficult experience to be able to report these vulnerabilities to them. 48:27.400 --> 48:34.780 In the beginning, there was a lack of communication, despite all of what was happening or that I was hearing in the media. 48:35.900 --> 48:57.420 Every now and then, I see that Zoom has patched a critical or severe vulnerability that was even attacking things that are less riskier than what I have found, but it was generating a lot of media PR that is bad for or negative to Zoom. 48:57.420 --> 49:08.420 And I assume that was the reason why they are patching it that quickly, comparing to my experience to Zoom VDP. 49:10.080 --> 49:16.140 And yeah, of course, I did not release anything that I found before this talk. 49:17.880 --> 49:23.400 To other parties or unauthorized parties. 49:25.540 --> 49:29.140 And yeah, so it was not mentioned in the media before. 49:29.140 --> 49:31.340 I did not share it with anyone in the media. 49:31.340 --> 49:40.780 That's probably one reason it wasn't that fixed or my experience wasn't as the same as the vulnerabilities that was shared in the media. 49:41.280 --> 49:43.040 And that's one thing. 49:43.140 --> 49:54.220 I'm not sure, but I would be surprised if I'm the only researcher in the world that had this experience with Zoom security. 49:54.220 --> 49:56.740 I would be really surprised about that. 49:58.060 --> 50:03.400 Another part is the massive growth versus security. 50:04.820 --> 50:11.300 Zoom has massively grown in 2020 in a way that no one could have imagined. 50:11.820 --> 50:14.500 Zoom has been here forever. 50:14.500 --> 50:26.520 And what the growth that they got during 2020 was something that for me, it was like no one would have expected this to happen. 50:28.580 --> 50:32.100 And this reflected a lot on the security. 50:32.100 --> 50:40.100 A lot of people have a clear focus on the security of Zoom since it became a part of our lives. 50:40.820 --> 50:42.200 Everyone is using it. 50:42.200 --> 50:49.000 I use it, my company use it, everyone that I know use Zoom. 50:50.400 --> 50:55.000 And that's why security is extremely important now for Zoom. 50:55.100 --> 51:03.260 And the thing is having security means that you have to have a full security program running. 51:03.300 --> 51:06.540 It's not that easy to have a full security program. 51:06.540 --> 51:10.060 And there are a lot of things to consider when doing that. 51:10.560 --> 51:18.220 For me, when I build security programs in companies, I take a lot of time to do that. 51:18.220 --> 51:20.240 And this is a typical thing. 51:20.360 --> 51:35.340 Even if we have the highest budget, similar to what Zoom is having, it does not come to how much budget is allocated to Zoom, to Zoom security. 51:35.340 --> 51:41.620 It's about different processes that should have been already done before the pandemic. 51:42.840 --> 51:58.180 And having a last-minute security program or a last-minute VDP, Probability Disclosure Program, is not easy and can cause a lot of errors and mistakes happening. 51:59.060 --> 52:02.740 Lack of communications and focus. 52:02.740 --> 52:17.120 These type of patterns that I have seen with Zoom is something that are possibly happening to all of the researchers that have been reporting to Zoom responsibly. 52:18.500 --> 52:25.100 I'm just saying that there is a lot of work for the security program at Zoom to be done. 52:27.110 --> 52:28.490 The reward? 52:28.490 --> 52:30.070 Yeah, that's another thing. 52:32.050 --> 52:48.670 One thing that I also seen that Zoom accounts like have as advertised a bug bounty program and then have the reward for all of the research that they have conducted as zero USD. 52:48.930 --> 52:50.550 This is not a...