[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:14.940] And I wish that we can all have a normal DEF CON [00:15.760 --> 00:18.440] and we'd be able to meet everyone in person, [00:18.440 --> 00:22.240] 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:29.780] I'm a cyber security engineer [00:30.430 --> 00:33.860] and I specialize in offensive security and APSEC. [00:34.180 --> 00:36.500] I also founded Fullhunt. [00:36.500 --> 00:37.940] If you haven't heard about Fullhunt, [00:37.940 --> 00:40.920] it's the next generation assets discovery [00:40.920 --> 00:43.900] slash monitoring, slash scanning, [00:43.900 --> 00:45.280] slash a lot of cool things [00:45.280 --> 00:47.160] that are happening in the background. [00:47.980 --> 00:50.160] If you haven't tried it or checked it out, [00:50.160 --> 00:51.280] you should definitely do. [00:51.280 --> 00:53.080] It will be one of the coolest things [00:53.080 --> 00:55.840] in security one day soon. [00:57.160 --> 01:00.000] Before that, I worked in the security engineering [01:00.000 --> 01:02.700] of ProtonMail. [01:02.820 --> 01:06.740] I was also, I'm also a bounty participant [01:07.320 --> 01:11.760] where I reported security vulnerabilities to Facebook, [01:11.760 --> 01:17.540] to the Department of Defense, to Twitter, and many others. [01:18.080 --> 01:22.740] I'm interested in web, infra, mobile, [01:22.740 --> 01:27.520] and cloud security, life evasions, security automation, [01:27.520 --> 01:32.200] and DevSecOps, and many other cool things in security. [01:33.040 --> 01:36.460] And you can read more at mazenahmed.net [01:36.460 --> 01:40.000] and you can find my contact details there. [01:41.520 --> 01:43.260] And yeah, let's start. [01:43.260 --> 01:44.660] So the agenda for today, [01:44.660 --> 01:46.920] of course, we're talking about hacking Zoom. [01:47.000 --> 01:50.500] Before that, we need to have a quick intro about Zoom, [01:50.500 --> 01:51.500] just in case. [01:52.740 --> 01:56.880] And then we're gonna have a background, findings, [01:56.960 --> 02:01.840] a retrospective on the Zoom's last minute VDP, [02:01.840 --> 02:04.560] recommendations, final thoughts, [02:05.040 --> 02:08.880] 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:27.520] We saw last week the hearing of the Twitter hack [02:27.520 --> 02:31.380] where the hearing was done via Zoom [02:31.380 --> 02:36.900] 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:47.540] In May, 2020, the market valuation for Zoom [02:47.540 --> 02:51.620] is 50 billion USD. [02:53.520 --> 02:56.720] I'd like to bring this chart here. [02:56.720 --> 03:00.880] This is a comparison between the market capital of Zoom [03:00.880 --> 03:05.380] against the top seven airlines in the world, [03:05.380 --> 03:08.040] including United and Delta. [03:09.740 --> 03:16.800] So combining the top seven airlines' market capital, [03:16.800 --> 03:22.380] they are either equal or have a higher market capital. [03:22.380 --> 03:25.300] This is crazy just to think about it, [03:25.300 --> 03:27.140] 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:41.620] So from a stock performance, [03:41.620 --> 03:44.300] almost all of the companies were in the same range [03:44.300 --> 03:45.880] as we can see here. [03:45.880 --> 03:52.360] And then it jumped, it actually skyrocketed by May [03:52.360 --> 03:54.740] with all what was happening. [03:54.740 --> 03:58.460] And meanwhile, all of these top airlines [03:58.460 --> 04:03.120] were quickly falling down, as we can see. [04:04.360 --> 04:06.300] For me, I just find this really interesting [04:06.300 --> 04:08.820] 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:23.620] So in March, March 2020, [04:23.620 --> 04:26.580] Patrick Walder gave a talk at Opcode [04:26.580 --> 04:32.440] about the Zoom security and the state of security at Zoom. [04:32.540 --> 04:35.760] And he disclosed a number of security vulnerabilities [04:35.760 --> 04:40.360] in the Mac OS client of Zoom. [04:40.880 --> 04:44.240] And this brings a lot of attention [04:44.240 --> 04:47.120] to the media and to me personally. [04:47.860 --> 04:49.960] And from that, I got more interested [04:49.960 --> 04:53.540] 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:05.140] We can read about it in the media [05:05.140 --> 05:08.320] and we can read about it in researches [05:08.320 --> 05:12.080] done by Patrick Walder and many others. [05:12.080 --> 05:14.660] It was hacked, it was really bad, [05:14.660 --> 05:17.040] it was reusing really bad practices. [05:18.040 --> 05:20.940] There was a lot of Zoom privacy concerns [05:21.560 --> 05:26.640] and the way that Zoom is sharing data to Facebook [05:27.010 --> 05:29.720] 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:39.540] This is, I can just share two, [05:39.540 --> 05:42.420] but many things has not been tested before. [05:42.800 --> 05:47.280] For me, I'm trying to take into a couple of things [05:47.280 --> 05:49.500] 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 --> 05:59.080] Nothing, I have tried to search about any research [05:59.080 --> 06:03.400] 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:07.560] This is one thing that I wanted to see [06:07.560 --> 06:09.980] or to focus on. [06:10.760 --> 06:14.620] The Zoom external attack surface, Zoom became huge [06:14.620 --> 06:18.420] and there was no focus on the external attack surface [06:18.420 --> 06:19.460] of Zoom. [06:20.680 --> 06:24.760] The Zoom cloud infrastructure, how it's being set up [06:24.760 --> 06:28.480] and different things related to the infra. [06:29.220 --> 06:31.680] And of course, the Zoom's new end-to-end [06:31.680 --> 06:34.200] 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:47.840] Definitely, there is a lot of room for research [06:47.840 --> 06:49.200] in this area. [06:51.560 --> 06:55.900] So the findings agenda, I'm not gonna go [06:55.900 --> 06:57.680] to each one of them now. [06:57.680 --> 06:59.580] We will talk about them later. [06:59.580 --> 07:02.040] It's just here for people who are curious [07:02.040 --> 07:04.780] 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:17.270] I have done everything here in my spare time, [07:17.730 --> 07:21.790] just to confirm that or state that. [07:23.150 --> 07:25.990] The research background, the first finding [07:25.990 --> 07:28.890] that I identified was in April, 2020. [07:29.590 --> 07:33.810] And my expectations did not match what I was seeing [07:33.810 --> 07:35.150] in the media. [07:35.450 --> 07:38.310] We will know how later. [07:38.870 --> 07:41.930] The first conclusive response for my finding [07:41.930 --> 07:48.010] 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:02.130] And after submitting the CFP to Defcon, [08:02.130 --> 08:05.130] the second round of research started. [08:05.130 --> 08:08.550] At that time, I identified additional [08:08.550 --> 08:10.350] six new different vulnerabilities [08:11.070 --> 08:14.270] 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:34.720] So the first step for doing any type [08:34.720 --> 08:39.520] 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:26.670] One thing that I noticed that there was two servers [09:26.670 --> 09:31.490] that are having a Kerberos service running. [09:32.450 --> 09:33.990] And when I saw that, [09:33.990 --> 09:37.770] I got interested to see what's happening there. [09:37.970 --> 09:42.650] Apparently, there was two exposed Kerberos servers [09:42.650 --> 09:45.890] that was exposed unintentionally to the internet [09:46.330 --> 09:48.870] and no one knew about them. [09:50.310 --> 09:56.930] So this one had also a web service running on port 80 [09:56.930 --> 09:59.170] and it was FreeIPA. [09:59.170 --> 10:01.190] If you don't know what's FreeIPA, [10:01.190 --> 10:03.370] it's an identity management solution [10:03.800 --> 10:06.070] 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:20.600] As you can see, this screenshot, [10:20.600 --> 10:24.420] when you are providing an invalid username, [10:24.420 --> 10:27.980] you can see that there is a Kerberos error [10:27.980 --> 10:29.800] that is telling you that. [10:29.800 --> 10:32.320] And one thing that I did not mention here, [10:32.320 --> 10:35.420] that whenever you see a Kerberos server running, [10:36.840 --> 10:39.780] by itself, it's not huge, [10:39.780 --> 10:41.560] but once you compromise it [10:41.560 --> 10:45.400] or you have a single credential that is valid, [10:46.820 --> 10:51.900] then this would open a crazy large amount [10:51.900 --> 10:55.100] of attack surface for you to attack. [10:55.160 --> 10:57.260] And that's what I was doing. [10:57.300 --> 10:59.460] I want to get initial foothold there [10:59.460 --> 11:02.540] and then go from there. [11:03.640 --> 11:06.980] So I started doing user enumeration there. [11:06.980 --> 11:09.980] And you can see here, [11:09.980 --> 11:13.260] 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:21.520] And here it's saying that the authentication failed [11:21.520 --> 11:23.380] or the pre-authentication failed, [11:23.380 --> 11:29.440] which means that we are able to identify [11:29.970 --> 11:31.980] valid usernames. [11:33.240 --> 11:36.720] And then I started building word list [11:36.720 --> 11:40.460] based on different things to identify more usernames [11:40.750 --> 11:44.310] 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 --> 11:56.500] So the pattern that I have seen for the Zoom emails [11:56.500 --> 12:01.740] are firstname.lastname at zoom.us. [12:01.760 --> 12:06.760] Also the common usernames that I was able to find to get [12:06.760 --> 12:08.900] 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:36.160] Then I saw that I'm hitting a rabbit hole [12:36.160 --> 12:38.460] and it's a dead end. [12:38.460 --> 12:42.060] So I just moved to another more interesting thing [12:42.060 --> 12:43.350] that I can find. [12:46.160 --> 12:50.060] And yeah, it was a good choice. [12:50.840 --> 12:53.020] So the discovery of a memory leak [12:53.020 --> 12:56.100] on our Zoom production server. [12:59.340 --> 13:03.920] Zoom allows uploading profile pictures on accounts, [13:03.920 --> 13:05.820] which is the typical thing. [13:06.720 --> 13:10.200] The process for that is first, [13:10.200 --> 13:12.660] 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:32.180] And if the image is JPEG, [13:32.920 --> 13:35.860] the image conversion is not triggered. [13:37.520 --> 13:40.260] And there is another thing here [13:40.260 --> 13:44.160] that if the image contains an invalid image header, [13:44.160 --> 13:48.640] 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:56.680] And it's using, of course, magic bytes, [13:57.000 --> 13:59.600] by checking the magic bytes. [14:01.500 --> 14:07.620] I like to test image conversion or processing softwares. [14:07.620 --> 14:10.860] Or whenever I see an API that is utilizing that [14:11.380 --> 14:15.760] or using that, I know for a fact that there is a large [14:16.330 --> 14:19.500] potential of having something bad happening. [14:19.800 --> 14:24.220] And the reason is because image conversion [14:24.220 --> 14:29.440] is not a vital functionality in an infrastructure [14:29.440 --> 14:34.770] of a company or even a web startup. [14:36.520 --> 14:41.780] So what happens is it often gets forgotten [14:41.780 --> 14:43.880] and there's no security updates [14:43.880 --> 14:45.640] 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:00.320] So one cool exploit here or security vulnerability [15:00.780 --> 15:03.720] that was released in 2016, [15:03.720 --> 15:09.400] it was known as the ImageTragic exploit or vulnerability. [15:09.400 --> 15:13.620] And this vulnerability allowed having remote code execution [15:13.620 --> 15:18.880] into the instance that is running the image processing [15:18.880 --> 15:22.260] when providing certain payloads. [15:22.260 --> 15:25.940] You can read more about the CVE offline. [15:27.520 --> 15:29.660] So I have tested this one [15:29.660 --> 15:33.780] 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:47.780] There is a vulnerability in ImageMagick [15:47.780 --> 15:50.240] that was reported in 2017. [15:50.700 --> 15:52.680] And it works by having, [15:52.680 --> 15:56.340] whenever the palette is uninitialized [15:57.380 --> 16:00.600] or not presented in the GIF file, basically, [16:02.860 --> 16:05.460] ImageMagick leaks portions of the memory [16:05.800 --> 16:08.400] to the generated or the rendered image. [16:09.800 --> 16:13.220] And this is the fix for the vulnerability [16:13.480 --> 16:18.280] that was issued at that time around July, 2017. [16:20.220 --> 16:23.740] I generated a payload that renders this way [16:24.320 --> 16:30.220] in a normal browser or normal software that is patched. [16:30.580 --> 16:35.400] But when I upload the payload to Zoom, [16:35.460 --> 16:37.780] it renders this way. [16:40.770 --> 16:44.490] But if you are reading the report for that CVE, [16:44.490 --> 16:47.150] this is the typical behavior [16:47.150 --> 16:51.550] of having the exploit being successful. [16:53.550 --> 16:57.430] And if you download this image [16:57.430 --> 17:06.290] and try to obtain the strings from it, [17:06.510 --> 17:10.930] you will find that it's taking some portions of the memory. [17:14.800 --> 17:19.660] Then I thought that maybe this is an, [17:19.660 --> 17:24.160] let's say, image processing software fault [17:24.600 --> 17:30.840] or best effort just to render the image that is corrupted. [17:30.840 --> 17:34.280] Or there is a problem that is happening [17:34.280 --> 17:37.360] because of rendering a black image. [17:37.360 --> 17:41.460] So I generated a new one that is not the, [17:41.460 --> 17:44.860] like the payload, it's not the one that, [17:44.860 --> 17:48.280] 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:09.900] And the flow for that would be [18:09.900 --> 18:12.920] to generate a new unique payload, [18:12.920 --> 18:15.340] then to upload it to Zoom, [18:15.340 --> 18:18.260] wait for the rendering to happen, [18:18.260 --> 18:21.220] download the rendered file, [18:21.220 --> 18:23.620] extract the data from the corrupted file [18:23.620 --> 18:25.960] that was rendered by Zoom, [18:25.960 --> 18:30.160] 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:48.160] So here, a memory leak on Zoom production [19:48.620 --> 19:50.800] was not the end for that. [19:53.900 --> 19:58.320] I remember that in 2018, [19:58.320 --> 20:03.020] Travis Romande released a research on Ghostscript, [20:03.020 --> 20:06.860] which was used by ImageMagick. [20:07.020 --> 20:11.380] And his research revealed a number of critical vulnerabilities [20:11.380 --> 20:13.420] in Ghostscript. [20:13.680 --> 20:17.940] And the proof of concept that he shared in the research [20:17.940 --> 20:19.880] when doing image conversion [20:20.470 --> 20:25.620] 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:31.320] And what I did is I used the proof of concept [20:31.320 --> 20:34.280] that Travis wrote. [20:36.020 --> 20:40.460] And I will show you this thing first. [20:42.080 --> 20:48.500] So we know for a fact that the 2016 v7.1.4, [20:48.500 --> 20:50.960] the image Tragic is patched. [20:50.960 --> 20:54.200] But we kind of think that the ImageMagick memory leak [20:54.200 --> 21:00.660] is presented based on the proof of exploitation we had here. [21:02.720 --> 21:06.780] And that one was patched and released, [21:06.780 --> 21:09.900] 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:22.220] Based on that, we can safely say that [21:24.580 --> 21:27.640] the Ghostscript ROC is not patched, right? [21:30.550 --> 21:36.330] So I wrote, like I brought the proof of concept [21:36.330 --> 21:40.550] from the research that Travis Sormandy wrote. [21:40.890 --> 21:46.250] And I replicated it locally with the same environment [21:46.250 --> 21:48.670] I assume Zoom have it on their setup [21:48.670 --> 21:57.830] 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:08.490] Unfortunately for, or fortunately, [22:08.490 --> 22:11.010] I'm not sure which one would suit that, [22:11.010 --> 22:16.970] 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:30.590] If there is any particular API [22:30.590 --> 22:32.890] that is utilizing the same functionality [22:34.250 --> 22:37.070] and it's not checking the magic bytes, [22:38.170 --> 22:41.770] 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:53.680] And I don't know how to say this, [22:53.680 --> 22:57.660] but the RCE vulnerability is probably still there [22:57.660 --> 22:59.440] on Zoom production. [23:04.400 --> 23:09.680] Another thing we have here is the shadow IT and Zoom. [23:14.240 --> 23:18.560] I have noticed that there is a number of instances [23:18.560 --> 23:23.340] or cases where Zoom have shadow IT servers [23:23.340 --> 23:26.060] running in different host names [23:27.300 --> 23:29.980] and are not properly configured. [23:29.980 --> 23:33.620] And they may be a good target [23:33.620 --> 23:37.220] for conducting a successful attack. [23:37.220 --> 23:40.000] I have seen this in multiple occasions. [23:40.000 --> 23:44.780] This example here is showing an instance [23:45.900 --> 23:50.440] that did not have any patches since, [23:50.820 --> 23:54.940] let me check, September 10th, 2019. [23:54.940 --> 23:58.740] I took this picture in July 4th, 2020, [23:58.740 --> 24:04.600] 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:15.540] And we all know that there was plenty of security vulnerabilities [24:15.540 --> 24:18.260] that was reported to them. [24:18.260 --> 24:21.480] And yeah, you can imagine. [24:23.020 --> 24:26.680] Another cool thing here is the same host [24:26.680 --> 24:31.040] had nine active connections, including me. [24:31.700 --> 24:35.820] Makes it an excellent fit for doing any type of testing [24:35.820 --> 24:39.080] without triggering alerts, which is cool, [24:39.080 --> 24:43.400] so that you can test it and be safe in the part [24:43.400 --> 24:47.640] that won't be as detected or detectable [24:47.640 --> 24:53.660] as in testing zoom.us, the main website, or yeah. [24:55.930 --> 24:58.330] Enough about all this, [24:58.330 --> 25:02.470] and let's start to talk about the Zoom app for Linux. [25:06.990 --> 25:12.730] One cool finding here, Zoom Linux client, [25:12.730 --> 25:17.410] so the TLS is broken by design on Linux, [25:17.410 --> 25:20.130] and you're gonna see how that is happening. [25:20.510 --> 25:23.090] I don't see this as the best practice, [25:23.090 --> 25:28.330] especially for the Zoom, but we can talk about that. [25:28.330 --> 25:31.270] So whenever there is any traffic that is intercepted [25:31.270 --> 25:37.450] 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:43.850] And whenever you click Trust Anyway, [25:43.850 --> 25:50.530] then you would have the traffic going with that, [25:50.530 --> 25:52.790] like with this accepted certificate, [25:53.710 --> 25:55.790] which is the unlisted one. [25:59.840 --> 26:04.020] But what happens here is that this certificate, [26:04.020 --> 26:07.040] like the fingerprint for this certificate [26:07.440 --> 26:12.160] is saved locally with the same permissions of the user. [26:12.840 --> 26:17.920] And you can simply just plug in, [26:17.920 --> 26:22.920] like if you have a malware that is able to have access [26:23.660 --> 26:28.300] to your machine, this malware can safely or easily [26:28.780 --> 26:34.280] just plug in to the fingerprint of the certificate, [26:34.280 --> 26:36.880] and then all of the traffic that is going to Zoom [26:36.880 --> 26:42.800] can be intercepted, even if it's using SSL or TLS, [26:42.800 --> 26:47.560] because the certificate will be accepted [26:47.560 --> 26:50.760] without having to have this type of prompts, [26:50.760 --> 26:54.680] because it was added to the local database [26:56.040 --> 26:58.500] on the background. [26:59.160 --> 27:02.240] So I wrote a simple proof of concept [27:02.240 --> 27:06.900] as a sample of what a malware would look like [27:06.900 --> 27:11.980] as just in a way or another as a concept. [27:12.680 --> 27:16.580] And this particular part of the malware [27:17.000 --> 27:21.320] or the proof concept would get the fingerprints [27:21.320 --> 27:25.800] for all of the forged certificates that we have. [27:25.800 --> 27:30.800] And then it would add it to the Zoom database, [27:30.800 --> 27:34.940] local database, and once it's added, [27:34.940 --> 27:41.000] these certificates can be provided to Zoom [27:41.380 --> 27:45.960] and all the traffic would be passing [27:47.040 --> 27:50.660] without having any error like this. [27:50.660 --> 27:53.760] And yeah, all of the encrypted traffic [27:53.760 --> 27:58.460] could be intercepted when having a malware [27:58.460 --> 28:02.580] 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:18.260] But as we are going now, [28:18.260 --> 28:20.100] we're gonna see something that is really bad [28:20.620 --> 28:22.260] 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:41.800] So userbin slash zoom is a summary of OPT [28:41.800 --> 28:45.360] slash Zoom slash Zoom launcher. [28:47.690 --> 28:50.790] And whenever Zoom is called, [28:52.390 --> 28:56.170] Zoom is printing the following logging [28:58.450 --> 29:01.590] logging data on the SCD out. [29:02.750 --> 29:05.630] And there is a part where you can see [29:06.650 --> 29:11.490] Zoom path is OPT Zoom [29:11.490 --> 29:15.070] 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:34.740] And if there is an executable called Zoom, literally, [29:35.770 --> 29:40.130] on PWD, it executes it as a chat process [29:40.860 --> 29:43.230] 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 --> 29:56.990] I created a file called Zoom [29:57.590 --> 30:01.750] and then Zoom checks on the PWD [30:01.750 --> 30:05.170] if there is a file called Zoom, literally, [30:05.870 --> 30:07.790] and executes it. [30:07.870 --> 30:10.870] Of course, it has to be with an executable for permission, [30:10.870 --> 30:13.070] but this is not a thing. [30:15.110 --> 30:21.550] So imagine this, you have application-wide listing. [30:21.590 --> 30:25.450] There are a lot of points that I can make here, [30:25.450 --> 30:26.470] to be honest. [30:26.470 --> 30:29.770] I can make a lot of things that would show [30:29.770 --> 30:33.770] how this old design is there for. [30:33.970 --> 30:38.210] And if there's anything related to application-wide listing [30:38.210 --> 30:40.430] and your wide listing Zoom, [30:41.290 --> 30:43.470] this would literally break that [30:44.150 --> 30:48.450] because this is executed as a child process [30:48.450 --> 30:51.570] of a trusted application, Zoom. [30:55.920 --> 30:58.700] And yeah, it's bad practice and bad design [30:58.700 --> 31:00.800] 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:12.860] If it was a bad design for an application launcher, [31:12.860 --> 31:16.880] I would be Zoom application launcher for Linux. [31:19.430 --> 31:21.920] Another bad thing happening here. [31:23.310 --> 31:27.990] So the Zoom local database implementation, [31:30.610 --> 31:32.220] you'll see now. [31:33.570 --> 31:35.870] So in the configuration files [31:35.870 --> 31:38.890] of the configuration directory of Zoom, [31:40.210 --> 31:42.450] there is this file, [31:42.450 --> 31:46.310] the local database is zoomus.db. [31:46.310 --> 31:48.450] This is the default database [31:48.450 --> 31:52.410] and a lot of other files that are there for Zoom. [31:53.310 --> 31:56.270] The most important file is the zoomus [31:56.270 --> 31:58.390] because it has the access tokens, [31:58.390 --> 32:02.630] it has all of the PII for the user and everything. [32:03.620 --> 32:07.260] And as we can see here in the screen, [32:07.870 --> 32:13.930] 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:51.930] But everyone to have read access [32:51.930 --> 32:56.570] into the Zoom local database [32:56.570 --> 32:59.370] 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:10.240] Any code on the user machine that have access to the, [33:10.240 --> 33:12.740] like any code that have access to the user machine [33:12.740 --> 33:17.220] can read and exfiltrate Zoom local database [33:17.220 --> 33:22.220] and configurations and more, of course. [33:22.860 --> 33:27.420] Because the permission or the file permission [33:27.420 --> 33:34.540] 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:05.860] And it's advertised in the website [34:05.860 --> 34:10.230] and that we can see here [34:12.000 --> 34:15.780] as a platform that is, [34:15.780 --> 34:20.280] that makes work and collaboration much easier [34:20.280 --> 34:22.180] in mobile and desktop [34:22.180 --> 34:27.260] and with a really clean design and UI [34:27.920 --> 34:32.760] that looks kind of similar to what Slack is having. [34:32.860 --> 34:34.500] This is not the point, [34:34.500 --> 34:38.180] 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:47.980] There are so many cool things to read, [34:47.980 --> 34:50.140] but I would focus on the security part. [34:51.140 --> 34:55.160] As we can see in the security and archiving and in I-Code, [34:55.160 --> 35:01.660] Zoom encrypts data at all times. [35:01.980 --> 35:06.800] Again here, [35:06.800 --> 35:11.640] encryption of data in transit and at rest [35:11.640 --> 35:17.800] 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:27.060] So there are a lot of advertisement [35:27.060 --> 35:32.180] that is going with how secure Zoom chat is happening. [35:32.300 --> 35:35.200] And by security, they don't really [35:35.200 --> 35:38.660] or necessarily talk about application security, [35:38.660 --> 35:41.480] level of security, [35:42.420 --> 35:45.700] but they are talking about how all of the data [35:45.700 --> 35:49.240] that are being passing here is encrypted [35:49.240 --> 35:52.020] both at rest and in transit, [35:52.840 --> 35:56.980] which is in transit, I assume they're saying [35:56.980 --> 35:59.520] that it goes in SSL. [35:59.520 --> 36:00.800] It's cool. [36:01.300 --> 36:04.280] But at rest, this means that they have full [36:04.280 --> 36:06.780] 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 --> 36:56.740] But on the right screen, we have Zoom chat running [36:56.740 --> 37:04.420] and I have my group chat that is clear with no messages. [37:04.420 --> 37:07.800] And then I'm sending some sort of an encrypted message [37:08.600 --> 37:14.080] that is here because Zoom is E2E by now, [37:14.860 --> 37:16.800] E2E encrypted by now. [37:17.700 --> 37:19.680] As advertised. [37:19.680 --> 37:24.340] And then on the left side, we can see the local database, [37:25.800 --> 37:28.400] a custom one that is made by Zoom [37:29.580 --> 37:33.320] that we can see that they have it. [37:33.320 --> 37:37.180] And I can just read what's happening there [37:37.530 --> 37:41.540] and what they are storing on your local device. [37:44.950 --> 37:47.230] So here I sent a message [37:47.230 --> 37:51.810] 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:29.130] And here, anyone who is able to have access [38:29.130 --> 38:32.570] to the user machine is able to pull a full archive [38:32.570 --> 38:35.410] of all messages that are being sent [38:35.990 --> 38:40.830] that were or are supposed to be end-to-end encrypted [38:40.830 --> 38:43.950] and it's saved in plain text. [38:45.450 --> 38:47.450] And yeah, this does not sound good. [38:47.450 --> 38:51.010] And it's not the one that you can have a record [38:51.010 --> 38:52.630] or a backup for your messages. [38:52.630 --> 38:58.050] It's just a debugging feature that they left open [38:58.780 --> 39:03.230] in production for the Linux build. [39:03.270 --> 39:08.490] I'm not sure if this is applicable in macOS or in Windows, [39:08.490 --> 39:15.990] but you can see if that's being applicable here in Linux. [39:18.450 --> 39:22.270] By the way, the fact that the same database [39:22.270 --> 39:26.280] that for messages is having the 644, [39:26.750 --> 39:27.910] where is it? [39:27.910 --> 39:31.110] The 644 user permission, [39:31.110 --> 39:34.390] which means that any code that is running [39:34.390 --> 39:38.810] despite what type of user permission is running [39:38.810 --> 39:45.690] is able to access this end-to-end encrypted chat archive. [39:45.910 --> 39:47.390] Doesn't sound good. [39:49.490 --> 39:54.410] Yeah, so of course I could have gone more and tested more, [39:54.410 --> 39:57.950] but at the end, this is just a time [39:57.950 --> 40:03.370] that I have spending just to fuzz around with Zoom. [40:03.370 --> 40:08.670] I did this for curiosity purposes mainly, [40:09.530 --> 40:12.930] but definitely I could have spent more time. [40:13.950 --> 40:18.850] But then, yeah, I jumped to the responsible disclosure now, [40:18.850 --> 40:24.390] and I started the experiment in around April. [40:24.410 --> 40:29.010] April 15, reported that in April 18, [40:29.010 --> 40:32.910] I contacted Lotus Security in Twitter, [40:33.570 --> 40:41.670] followed up with the vulnerability disclosure again on 26, [40:41.670 --> 40:46.850] couple of messages on the background. [40:46.850 --> 40:50.570] And May 5th of 2020, [40:50.570 --> 40:54.560] 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:16.370] And then I was asked to send it via HackerOne, [41:16.370 --> 41:20.930] turn on communication running to run my automated exploit [41:20.930 --> 41:23.950] for the memory leak. [41:24.430 --> 41:29.630] Then when nothing seems to be happening, [41:29.630 --> 41:32.010] I informed Zoom that I'm planning to present [41:32.010 --> 41:35.350] my ongoing research here at DEF CON. [41:36.250 --> 41:42.050] And then Zoom told me that they cannot assess the issue [41:42.050 --> 41:45.450] as there was no sensitive data seen [41:46.490 --> 41:49.130] despite the predictability of the vulnerability [41:49.130 --> 41:50.690] 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:06.180] Then I sent on July 11th, [42:06.180 --> 42:08.680] my new research results, [42:08.680 --> 42:12.480] reporting new seven different security vulnerabilities, [42:13.360 --> 42:16.200] six to seven new vulnerabilities. [42:16.940 --> 42:20.660] I got an acknowledgement about receiving my report. [42:20.660 --> 42:24.700] By the way, this is the first conclusive response [42:24.700 --> 42:27.400] regarding the memory leak issue. [42:29.100 --> 42:33.640] By conclusive, I mean that they did a full analysis [42:33.640 --> 42:35.100] of what was happening. [42:35.100 --> 42:37.700] On the previous ones on HackerOne, [42:37.700 --> 42:40.520] they triggered it as valid, [42:40.520 --> 42:43.260] and then they were trying to run my exploit, [42:43.260 --> 42:44.900] and that's all. [42:45.060 --> 42:49.740] But this one, they researched more and analyzed more [42:49.740 --> 42:51.040] about how this is happening [42:51.040 --> 42:53.340] and what was the cause of the issue. [42:53.800 --> 42:57.720] And it was in like literally three months [42:57.720 --> 42:59.570] after I reported it. [43:00.800 --> 43:03.200] Then further explanation from Zoom [43:03.200 --> 43:06.860] regarding the vulnerability or the findings in general. [43:08.520 --> 43:12.500] Okay, now with what was happening [43:12.500 --> 43:15.960] and then from their explanation, [43:15.960 --> 43:19.540] and then my response regarding each analysis [43:19.540 --> 43:21.080] that they provided. [43:24.180 --> 43:26.700] So for the public authentication, [43:26.700 --> 43:28.600] yeah, you can see what's happening here, [43:28.600 --> 43:30.600] what they wrote. [43:31.200 --> 43:33.380] And well, yeah, for me, yeah. [43:33.380 --> 43:36.260] Well, again, this may be a forgotten server [43:36.260 --> 43:38.740] that was mistakenly exposed. [43:38.740 --> 43:42.780] I haven't seen any references of 2FA being implemented, [43:43.820 --> 43:46.500] 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:07.480] So we did check that ImageMagick [44:08.680 --> 44:11.980] is not used for image conversions here, [44:13.080 --> 44:17.360] but wait, the same vulnerability is being reproduced. [44:17.360 --> 44:19.200] It's maybe a fork of ImageMagick [44:19.710 --> 44:21.680] or an image processing software [44:21.680 --> 44:24.020] that is vulnerable to the same CVE [44:25.160 --> 44:29.360] of not being able to parse GIF images [44:29.770 --> 44:33.560] 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:53.200] So these are non-sensitive information disclosure [44:53.200 --> 44:55.200] from a shared environment. [44:55.560 --> 44:57.940] Information hygiene is important to us [44:57.940 --> 45:00.820] and we appreciate you reporting this finding. [45:00.820 --> 45:01.900] So that's great. [45:01.900 --> 45:03.640] So Full Hunt can help here, [45:03.640 --> 45:05.160] probably the best product out there [45:05.160 --> 45:07.840] for mitigating shadow IT risks. [45:10.880 --> 45:14.900] Oh, I think part of the discussion [45:14.900 --> 45:17.880] regarding the image conversion [45:17.880 --> 45:21.080] is not placed on the slide, [45:21.080 --> 45:23.180] but please check my blog after that [45:23.180 --> 45:27.180] to have the full list of discussion. [45:27.640 --> 45:33.020] So for what was happening for the Linux app findings, [45:33.020 --> 45:38.410] yeah, they fixed it or patched it in 5.2.0 [45:38.760 --> 45:42.840] that was released in August 3rd, I think. [45:43.480 --> 45:47.360] They were supposed to patch or release it on August 2nd, [45:47.360 --> 45:50.120] 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:03.600] So clearly it was a silent fix, [46:03.600 --> 46:06.700] which it wasn't a nice thing. [46:06.700 --> 46:11.020] At least users should have some transparency [46:11.020 --> 46:13.980] of the state of security for the company [46:13.980 --> 46:16.280] that they use or trust. [46:24.490 --> 46:25.990] Yeah, the patches. [46:25.990 --> 46:30.150] I just told you about the patches [46:30.150 --> 46:34.240] for what happened for the Zoom Linux app. [46:35.390 --> 46:40.680] For what was happening with the image conversion, [46:41.170 --> 46:43.470] they decided to not patch it [46:43.470 --> 46:46.250] because they are not seeing sensitive data [46:46.250 --> 46:51.310] and then that are being exposed. [46:52.150 --> 46:55.660] Then what happened is they asked, [46:56.550 --> 47:00.430] they stated that they are not using image magic, [47:00.430 --> 47:05.030] but still the same behavior of the vulnerability [47:05.030 --> 47:08.310] is being reproduced as a result of the image conversion. [47:08.310 --> 47:11.330] So clearly something bad is happening, [47:11.330 --> 47:14.630] but I'm not a part of Zoom [47:15.120 --> 47:19.310] or I don't have a say on Zoom to have them fix that. [47:19.310 --> 47:24.310] So my responsibility is just to, [47:24.310 --> 47:27.190] as part of the research that I'm conducting, [47:27.190 --> 47:29.630] 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:35.510] The findings, the shadow IT, [47:35.510 --> 47:40.510] I'm not sure if they started reviewing [47:41.270 --> 47:43.450] 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:48.830] For the Kerberos server, they took it down, [47:48.830 --> 47:50.910] which is good, which is awesome. [47:52.630 --> 47:56.430] And yeah, they told us, [47:56.430 --> 47:58.570] they told me that they are patching [47:58.570 --> 48:01.330] all of the vulnerabilities for the Linux app [48:01.330 --> 48:07.990] on the release of August 2nd or August 3rd. [48:07.990 --> 48:11.270] It was released with no mention [48:11.270 --> 48:15.570] for any security fixes or updates. [48:18.260 --> 48:22.780] Yeah, for me, it was a difficult experience [48:22.780 --> 48:27.400] to be able to report these vulnerabilities to them. [48:27.400 --> 48:30.260] In the beginning, there was a lack of communication, [48:30.260 --> 48:31.820] despite all of what was happening [48:31.820 --> 48:34.780] or that I was hearing in the media. [48:35.900 --> 48:39.040] Every now and then, I see that Zoom has patched [48:39.620 --> 48:41.280] a critical or severe vulnerability [48:41.280 --> 48:47.020] that was even attacking things that are less riskier [48:47.020 --> 48:48.680] than what I have found, [48:48.680 --> 48:53.840] but it was generating a lot of media PR [48:53.840 --> 48:57.420] that is bad for or negative to Zoom. [48:57.420 --> 49:00.460] And I assume that was the reason [49:00.460 --> 49:03.140] why they are patching it that quickly, [49:03.800 --> 49:08.420] comparing to my experience to Zoom VDP. [49:10.080 --> 49:13.340] And yeah, of course, I did not release anything [49:13.340 --> 49:16.140] 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:35.360] That's probably one reason it wasn't that fixed [49:35.360 --> 49:37.420] or my experience wasn't as the same [49:37.420 --> 49:40.780] as the vulnerabilities that was shared in the media. [49:41.280 --> 49:43.040] And that's one thing. [49:43.140 --> 49:45.920] I'm not sure, but I would be surprised [49:45.920 --> 49:50.040] if I'm the only researcher in the world [49:50.040 --> 49:54.220] 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:08.160] Zoom has massively grown in 2020 [50:08.480 --> 50:11.300] in a way that no one could have imagined. [50:11.820 --> 50:14.500] Zoom has been here forever. [50:14.500 --> 50:18.780] And what the growth that they got during 2020 [50:20.160 --> 50:23.440] was something that for me, [50:23.440 --> 50:26.520] 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:36.620] A lot of people have a clear focus on the security of Zoom [50:36.620 --> 50:40.100] since it became a part of our lives. [50:40.820 --> 50:42.200] Everyone is using it. [50:42.200 --> 50:45.760] I use it, my company use it, [50:45.760 --> 50:49.000] 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:00.040] And the thing is having security means [51:00.040 --> 51:03.260] 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:14.260] For me, when I build security programs in companies, [51:14.260 --> 51:18.220] 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:23.280] Even if we have the highest budget, [51:24.600 --> 51:26.780] similar to what Zoom is having, [51:26.780 --> 51:33.520] it does not come to how much budget is allocated to Zoom, [51:34.120 --> 51:35.340] to Zoom security. [51:35.340 --> 51:37.680] It's about different processes [51:37.680 --> 51:41.620] that should have been already done before the pandemic. [51:42.840 --> 51:45.540] And having a last-minute security program [51:45.540 --> 51:48.100] or a last-minute VDP, [51:48.600 --> 51:50.520] Probability Disclosure Program, [51:51.500 --> 51:55.820] is not easy and can cause a lot of errors [51:55.820 --> 51:58.180] and mistakes happening. [51:59.060 --> 52:02.740] Lack of communications and focus. [52:02.740 --> 52:06.820] These type of patterns that I have seen with Zoom [52:06.820 --> 52:09.440] is something that are possibly happening [52:09.440 --> 52:11.020] to all of the researchers [52:11.720 --> 52:17.120] that have been reporting to Zoom responsibly. [52:18.500 --> 52:21.480] I'm just saying that there is a lot of work [52:21.480 --> 52:25.100] 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:35.150] One thing that I also seen that Zoom accounts [52:35.780 --> 52:39.550] like have as advertised a bug bounty program [52:40.440 --> 52:44.370] and then have the reward for all of the research [52:44.370 --> 52:48.670] that they have conducted as zero USD. [52:48.930 --> 52:50.550] This is not a...