1 00:00:00,000 --> 00:00:02,140 Thank you everyone for tuning in. 2 00:00:02,140 --> 00:00:05,240 I'm super honored to be speaking here today at DEF CON. 3 00:00:05,240 --> 00:00:07,520 This is my first DEF CON talk. 4 00:00:07,520 --> 00:00:10,420 I'm super honored to be here today. 5 00:00:10,980 --> 00: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. 6 00:00:23,040 --> 00:00:25,180 Yeah, let's start. 7 00:00:25,320 --> 00:00:26,980 So who am I? 8 00:00:27,000 --> 00:00:28,340 I'm Mazen Ahmed. 9 00:00:28,340 --> 00:00:33,860 I'm a cyber security engineer and I specialize in offensive security and APSEC. 10 00:00:34,180 --> 00:00:36,500 I also founded Fullhunt. 11 00:00:36,500 --> 00: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. 12 00:00:47,980 --> 00:00:51,280 If you haven't tried it or checked it out, you should definitely do. 13 00:00:51,280 --> 00:00:55,840 It will be one of the coolest things in security one day soon. 14 00:00:57,160 --> 00:01:02,700 Before that, I worked in the security engineering of ProtonMail. 15 00:01:02,820 --> 00: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. 16 00:01:18,080 --> 00: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. 17 00:01:33,040 --> 00:01:40,000 And you can read more at mazenahmed.net and you can find my contact details there. 18 00:01:41,520 --> 00:01:43,260 And yeah, let's start. 19 00:01:43,260 --> 00:01:46,920 So the agenda for today, of course, we're talking about hacking Zoom. 20 00:01:47,000 --> 00:01:51,500 Before that, we need to have a quick intro about Zoom, just in case. 21 00:01:52,740 --> 00: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. 22 00:02:10,300 --> 00:02:12,860 Zoom, everyone knows it today. 23 00:02:12,860 --> 00:02:14,380 Everyone is using it. 24 00:02:14,380 --> 00:02:16,980 It's literally in everywhere in the world. 25 00:02:16,980 --> 00:02:20,680 Every company, almost every company is using it. 26 00:02:20,680 --> 00:02:24,040 Governments use it too. 27 00:02:24,340 --> 00: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. 28 00:02:36,900 --> 00:02:39,180 It was quite bad, but yeah. 29 00:02:39,180 --> 00:02:42,420 So this proves that everyone is using it. 30 00:02:44,070 --> 00:02:51,620 In May, 2020, the market valuation for Zoom is 50 billion USD. 31 00:02:53,520 --> 00:02:56,720 I'd like to bring this chart here. 32 00:02:56,720 --> 00: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. 33 00:03:09,740 --> 00:03:22,380 So combining the top seven airlines' market capital, they are either equal or have a higher market capital. 34 00:03:22,380 --> 00:03:27,140 This is crazy just to think about it, how Zoom became today. 35 00:03:29,600 --> 00:03:33,600 And the rise of Zoom started with the global pandemic. 36 00:03:33,600 --> 00:03:35,180 Everyone knows about that. 37 00:03:38,200 --> 00:03:45,880 So from a stock performance, almost all of the companies were in the same range as we can see here. 38 00:03:45,880 --> 00:03:54,740 And then it jumped, it actually skyrocketed by May with all what was happening. 39 00:03:54,740 --> 00:04:03,120 And meanwhile, all of these top airlines were quickly falling down, as we can see. 40 00:04:04,360 --> 00:04:08,820 For me, I just find this really interesting to imagine how Zoom became today. 41 00:04:10,900 --> 00:04:14,820 Yeah, and because how important is Zoom? 42 00:04:14,820 --> 00:04:17,120 This is where my research started. 43 00:04:19,000 --> 00: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. 44 00:04:32,540 --> 00:04:40,360 And he disclosed a number of security vulnerabilities in the Mac OS client of Zoom. 45 00:04:40,880 --> 00:04:47,120 And this brings a lot of attention to the media and to me personally. 46 00:04:47,860 --> 00:04:53,540 And from that, I got more interested and started my research from there. 47 00:04:54,360 --> 00:04:57,180 So what was tested before? 48 00:04:58,680 --> 00:05:02,720 The Zoom Mac OS app, it was tested. 49 00:05:02,720 --> 00: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. 50 00:05:12,080 --> 00:05:17,040 It was hacked, it was really bad, it was reusing really bad practices. 51 00:05:18,040 --> 00: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. 52 00:05:30,660 --> 00:05:33,840 But what was not tested before? 53 00:05:33,840 --> 00:05:36,040 Of course, many things. 54 00:05:36,240 --> 00:05:42,420 This is, I can just share two, but many things has not been tested before. 55 00:05:42,800 --> 00:05:49,500 For me, I'm trying to take into a couple of things and that I will be showing now. 56 00:05:50,040 --> 00:05:54,620 One thing that was not tested was the Zoom Linux app. 57 00:05:54,800 --> 00:06:03,400 Nothing, I have tried to search about any research or disclosure for any vulnerability in the Zoom Linux client. 58 00:06:03,400 --> 00:06:04,800 I haven't seen anything. 59 00:06:05,240 --> 00:06:09,980 This is one thing that I wanted to see or to focus on. 60 00:06:10,760 --> 00:06:19,460 The Zoom external attack surface, Zoom became huge and there was no focus on the external attack surface of Zoom. 61 00:06:20,680 --> 00:06:28,480 The Zoom cloud infrastructure, how it's being set up and different things related to the infra. 62 00:06:29,220 --> 00:06:34,200 And of course, the Zoom's new end-to-end encryption implementation. 63 00:06:34,200 --> 00:06:35,880 We have seen it to the media. 64 00:06:35,880 --> 00:06:37,760 Did anyone test it? 65 00:06:38,000 --> 00:06:41,000 We can talk about that later. 66 00:06:41,020 --> 00:06:42,280 And of course, many. 67 00:06:42,620 --> 00:06:45,440 There are a lot of things, I only focused on these. 68 00:06:45,440 --> 00:06:49,200 Definitely, there is a lot of room for research in this area. 69 00:06:51,560 --> 00:06:57,680 So the findings agenda, I'm not gonna go to each one of them now. 70 00:06:57,680 --> 00:06:59,580 We will talk about them later. 71 00:06:59,580 --> 00:07:04,780 It's just here for people who are curious to see what we're gonna talk about. 72 00:07:07,730 --> 00:07:12,690 A quick disclaimer, the entire research is non-funded. 73 00:07:12,690 --> 00:07:14,290 This is a non-funded research. 74 00:07:14,290 --> 00:07:21,790 I have done everything here in my spare time, just to confirm that or state that. 75 00:07:23,150 --> 00:07:28,890 The research background, the first finding that I identified was in April, 2020. 76 00:07:29,590 --> 00:07:35,150 And my expectations did not match what I was seeing in the media. 77 00:07:35,450 --> 00:07:38,310 We will know how later. 78 00:07:38,870 --> 00:07:48,010 The first conclusive response for my finding that I reported in April, 2020, I got it in July. 79 00:07:49,070 --> 00:07:54,990 This wasn't a very pleasing experience. 80 00:07:55,430 --> 00:07:59,530 And this after a lot of follow-ups, of course, from my side. 81 00:07:59,530 --> 00:08:05,130 And after submitting the CFP to Defcon, the second round of research started. 82 00:08:05,130 --> 00:08:14,270 At that time, I identified additional six new different vulnerabilities and security-related issues. 83 00:08:14,570 --> 00:08:18,410 And of course, everything was reported to Zoom. 84 00:08:19,630 --> 00:08:24,430 And the reward was zero dollars. 85 00:08:24,430 --> 00:08:27,510 Yeah, I just want to say that. 86 00:08:30,880 --> 00:08:39,520 So the first step for doing any type of offensive research is the reconnaissance. 87 00:08:40,140 --> 00:08:43,060 Understanding the attack surface. 88 00:08:43,060 --> 00:08:45,480 And that's where I started with. 89 00:08:47,460 --> 00:08:51,660 I used full-hunt.io to get the Zoom details. 90 00:08:52,220 --> 00:08:56,100 API returned around 13 domains. 91 00:08:56,100 --> 00:09:01,160 And this is the list of domains that was discovered. 92 00:09:02,160 --> 00:09:06,700 I took a portion of them and analyzed them. 93 00:09:06,740 --> 00:09:09,480 The remaining are there. 94 00:09:09,480 --> 00:09:14,520 If anyone would like to have a test drive, feel free. 95 00:09:16,360 --> 00:09:19,080 And let's go to the findings. 96 00:09:22,790 --> 00:09:31,490 One thing that I noticed that there was two servers that are having a Kerberos service running. 97 00:09:32,450 --> 00:09:37,770 And when I saw that, I got interested to see what's happening there. 98 00:09:37,970 --> 00:09:48,870 Apparently, there was two exposed Kerberos servers that was exposed unintentionally to the internet and no one knew about them. 99 00:09:50,310 --> 00:09:59,170 So this one had also a web service running on port 80 and it was FreeIPA. 100 00:09:59,170 --> 00:10:06,070 If you don't know what's FreeIPA, it's an identity management solution that was developed by Red Hat. 101 00:10:07,230 --> 00:10:10,330 It's open source, you can check it out. 102 00:10:13,340 --> 00:10:17,700 And I started by testing the web interface. 103 00:10:17,880 --> 00: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. 104 00:10:29,800 --> 00: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. 105 00:10:55,160 --> 00:10:57,260 And that's what I was doing. 106 00:10:57,300 --> 00:11:02,540 I want to get initial foothold there and then go from there. 107 00:11:03,640 --> 00:11:06,980 So I started doing user enumeration there. 108 00:11:06,980 --> 00:11:13,260 And you can see here, the previous one was showing that there was an error. 109 00:11:13,260 --> 00:11:17,040 This user is not found by the client. 110 00:11:18,700 --> 00: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. 111 00:11:33,240 --> 00: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. 112 00:11:45,280 --> 00:11:51,680 I compiled the word list from the pattern that I have seen. 113 00:11:51,680 --> 00:12:01,740 So the pattern that I have seen for the Zoom emails are firstname.lastname at zoom.us. 114 00:12:01,760 --> 00:12:08,900 Also the common usernames that I was able to find to get and employee names, of course. 115 00:12:08,900 --> 00:12:14,580 I compiled them all and I did that for user enumeration. 116 00:12:14,580 --> 00:12:20,740 The only users that I found was admin at idm.mezoom.us. 117 00:12:21,450 --> 00:12:26,970 I then ran a number of brute force sessions on them. 118 00:12:27,560 --> 00:12:30,820 Nothing interesting happened. 119 00:12:31,100 --> 00:12:38,460 Then I saw that I'm hitting a rabbit hole and it's a dead end. 120 00:12:38,460 --> 00:12:43,350 So I just moved to another more interesting thing that I can find. 121 00:12:46,160 --> 00:12:50,060 And yeah, it was a good choice. 122 00:12:50,840 --> 00:12:56,100 So the discovery of a memory leak on our Zoom production server. 123 00:12:59,340 --> 00:13:05,820 Zoom allows uploading profile pictures on accounts, which is the typical thing. 124 00:13:06,720 --> 00:13:12,660 The process for that is first, the user uploads a profile image. 125 00:13:13,420 --> 00:13:20,140 And the profile image is either JPEG, GIF, or PNG. 126 00:13:20,840 --> 00:13:22,980 And this is the tricky one. 127 00:13:22,980 --> 00:13:28,660 If the image is PNG or GIF, it's converted to JPEG. 128 00:13:28,660 --> 00:13:35,860 And if the image is JPEG, the image conversion is not triggered. 129 00:13:37,520 --> 00: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. 130 00:13:48,640 --> 00:13:53,400 So there is a good check in that image header. 131 00:13:54,480 --> 00:13:59,600 And it's using, of course, magic bytes, by checking the magic bytes. 132 00:14:01,500 --> 00:14:07,620 I like to test image conversion or processing softwares. 133 00:14:07,620 --> 00: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. 134 00:14:19,800 --> 00: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. 135 00:14:36,520 --> 00:14:45,640 So what happens is it often gets forgotten and there's no security updates that are being applied there. 136 00:14:45,640 --> 00:14:47,880 As far as it's working, then it's fine. 137 00:14:47,880 --> 00:14:50,520 This is something that I have seen as a pattern. 138 00:14:51,140 --> 00:14:54,840 And that's why I started testing that or focused on that. 139 00:14:56,720 --> 00: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. 140 00:15:09,400 --> 00:15:22,260 And this vulnerability allowed having remote code execution into the instance that is running the image processing when providing certain payloads. 141 00:15:22,260 --> 00:15:25,940 You can read more about the CVE offline. 142 00:15:27,520 --> 00:15:33,780 So I have tested this one and they seem to have this one patched. 143 00:15:33,780 --> 00:15:38,080 So I moved to the next one, it did not work. 144 00:15:38,080 --> 00:15:40,900 So I moved to the next one. 145 00:15:44,900 --> 00:15:50,240 There is a vulnerability in ImageMagick that was reported in 2017. 146 00:15:50,700 --> 00: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. 147 00:16:09,800 --> 00:16:18,280 And this is the fix for the vulnerability that was issued at that time around July, 2017. 148 00:16:20,220 --> 00:16:30,220 I generated a payload that renders this way in a normal browser or normal software that is patched. 149 00:16:30,580 --> 00:16:37,780 But when I upload the payload to Zoom, it renders this way. 150 00:16:40,770 --> 00:16:51,550 But if you are reading the report for that CVE, this is the typical behavior of having the exploit being successful. 151 00:16:53,550 --> 00: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. 152 00:17:14,800 --> 00: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. 153 00:17:30,240 --> 00:17:37,360 Or there is a problem that is happening because of rendering a black image. 154 00:17:37,360 --> 00: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. 155 00:17:49,360 --> 00:17:52,520 And when I report it, it renders normally. 156 00:17:53,300 --> 00:17:55,660 Okay, this sounds really interesting. 157 00:17:55,960 --> 00:17:59,220 We have a memory leak on Zoom production. 158 00:18:02,600 --> 00:18:06,820 Typical thing is to automate the exploitation for that. 159 00:18:06,820 --> 00: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. 160 00:18:32,340 --> 00:18:35,160 So this proof of concept does that. 161 00:18:36,000 --> 00:18:41,320 So I'm going to have a demo time, which is cool. 162 00:18:59,230 --> 00:19:03,990 Here it generated the image and uploaded it to Zoom. 163 00:19:08,480 --> 00:19:10,580 I'm downloading the image now. 164 00:19:11,700 --> 00:19:15,560 And here, recovering the dump. 165 00:19:43,780 --> 00:19:50,800 So here, a memory leak on Zoom production was not the end for that. 166 00:19:53,900 --> 00:20:06,860 I remember that in 2018, Travis Romande released a research on Ghostscript, which was used by ImageMagick. 167 00:20:07,020 --> 00:20:13,420 And his research revealed a number of critical vulnerabilities in Ghostscript. 168 00:20:13,680 --> 00: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. 169 00:20:25,700 --> 00:20:28,000 And it was really cool to see this. 170 00:20:28,000 --> 00:20:34,280 And what I did is I used the proof of concept that Travis wrote. 171 00:20:36,020 --> 00:20:40,460 And I will show you this thing first. 172 00:20:42,080 --> 00:20:50,960 So we know for a fact that the 2016 v7.1.4, the image Tragic is patched. 173 00:20:50,960 --> 00:21:00,660 But we kind of think that the ImageMagick memory leak is presented based on the proof of exploitation we had here. 174 00:21:02,720 --> 00:21:09,900 And that one was patched and released, the patch was released in May 2016. 175 00:21:09,900 --> 00:21:15,740 And the patch for the memory leak was released in July 2017. 176 00:21:15,940 --> 00:21:17,680 And it's not patched. 177 00:21:18,100 --> 00:21:27,640 Based on that, we can safely say that the Ghostscript ROC is not patched, right? 178 00:21:30,550 --> 00:21:40,550 So I wrote, like I brought the proof of concept from the research that Travis Sormandy wrote. 179 00:21:40,890 --> 00: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. 180 00:21:58,470 --> 00:22:00,780 And yeah, it's working. 181 00:22:04,490 --> 00: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. 182 00:22:17,170 --> 00:22:20,790 Otherwise a full exploitation would have been possible. 183 00:22:21,730 --> 00:22:27,170 But still, this does not mean that like Zoom is safe. 184 00:22:27,170 --> 00: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. 185 00:22:42,110 --> 00:22:44,110 This doesn't sound nice. 186 00:22:44,110 --> 00:22:46,890 This doesn't sound good by any means. 187 00:22:50,920 --> 00:22:59,440 And I don't know how to say this, but the RCE vulnerability is probably still there on Zoom production. 188 00:23:04,400 --> 00:23:09,680 Another thing we have here is the shadow IT and Zoom. 189 00:23:14,240 --> 00: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. 190 00:23:29,980 --> 00:23:37,220 And they may be a good target for conducting a successful attack. 191 00:23:37,220 --> 00:23:40,000 I have seen this in multiple occasions. 192 00:23:40,000 --> 00:23:54,940 This example here is showing an instance that did not have any patches since, let me check, September 10th, 2019. 193 00:23:54,940 --> 00:24:04,600 I took this picture in July 4th, 2020, around 10 or nine months of timeframe. 194 00:24:04,600 --> 00:24:09,940 There was no patches on that server or all new builds. 195 00:24:11,200 --> 00:24:18,260 And we all know that there was plenty of security vulnerabilities that was reported to them. 196 00:24:18,260 --> 00:24:21,480 And yeah, you can imagine. 197 00:24:23,020 --> 00:24:31,040 Another cool thing here is the same host had nine active connections, including me. 198 00:24:31,700 --> 00: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. 199 00:24:55,930 --> 00:25:02,470 Enough about all this, and let's start to talk about the Zoom app for Linux. 200 00:25:06,990 --> 00: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. 201 00:25:20,510 --> 00:25:28,330 I don't see this as the best practice, especially for the Zoom, but we can talk about that. 202 00:25:28,330 --> 00:25:37,450 So whenever there is any traffic that is intercepted with a custom TLS certificate, Zoom prompts this message. 203 00:25:38,050 --> 00:25:41,070 While it looks normal, everything is fine here. 204 00:25:41,070 --> 00: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. 205 00:25:59,840 --> 00: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. 206 00:26:12,840 --> 00: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, 207 00:26:39,360 --> 00: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. 208 00:26:59,160 --> 00: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. 209 00:27:12,680 --> 00: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. 210 00:27:25,800 --> 00: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. 211 00:27:50,660 --> 00: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. 212 00:28:04,860 --> 00:28:10,060 Well, I have to say, this is not a really bad vulnerability. 213 00:28:10,060 --> 00:28:14,760 It's just a little bit not the best practice to do that. 214 00:28:16,180 --> 00: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. 215 00:28:23,740 --> 00:28:26,580 So I would start with this question. 216 00:28:27,580 --> 00:28:31,280 What's a bad design for an application launcher? 217 00:28:32,780 --> 00:28:33,880 Good question. 218 00:28:33,880 --> 00:28:35,700 And we're gonna know the answer. 219 00:28:35,700 --> 00:28:45,360 So userbin slash zoom is a summary of OPT slash Zoom slash Zoom launcher. 220 00:28:47,690 --> 00:29:01,590 And whenever Zoom is called, Zoom is printing the following logging logging data on the SCD out. 221 00:29:02,750 --> 00: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. 222 00:29:15,970 --> 00:29:18,570 Okay, this looks interesting already. 223 00:29:22,410 --> 00:29:24,790 What's happening in the background? 224 00:29:25,530 --> 00:29:29,010 Zoom checks for files within PWD. 225 00:29:29,760 --> 00:29:43,230 And if there is an executable called Zoom, literally, on PWD, it executes it as a chat process for userbin Zoom. 226 00:29:43,720 --> 00:29:45,860 I was mind blown when I saw that. 227 00:29:46,910 --> 00:29:50,090 Why would this be there? 228 00:29:50,190 --> 00:29:52,370 This is a proof concept. 229 00:29:53,040 --> 00: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. 230 00:30:07,870 --> 00:30:13,070 Of course, it has to be with an executable for permission, but this is not a thing. 231 00:30:15,110 --> 00:30:21,550 So imagine this, you have application-wide listing. 232 00:30:21,590 --> 00:30:26,470 There are a lot of points that I can make here, to be honest. 233 00:30:26,470 --> 00:30:33,770 I can make a lot of things that would show how this old design is there for. 234 00:30:33,970 --> 00: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. 235 00:30:55,920 --> 00:31:00,800 And yeah, it's bad practice and bad design by all means. 236 00:31:00,800 --> 00:31:04,310 Like why would this be implemented this way? 237 00:31:07,870 --> 00:31:09,980 So that's my answer. 238 00:31:10,100 --> 00:31:16,880 If it was a bad design for an application launcher, I would be Zoom application launcher for Linux. 239 00:31:19,430 --> 00:31:21,920 Another bad thing happening here. 240 00:31:23,310 --> 00:31:32,220 So the Zoom local database implementation, you'll see now. 241 00:31:33,570 --> 00:31:46,310 So in the configuration files of the configuration directory of Zoom, there is this file, the local database is zoomus.db. 242 00:31:46,310 --> 00:31:52,410 This is the default database and a lot of other files that are there for Zoom. 243 00:31:53,310 --> 00: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. 244 00:32:03,620 --> 00:32:13,930 And as we can see here in the screen, the file permission is 644. 245 00:32:14,680 --> 00:32:16,180 I'll show you this. 246 00:32:19,160 --> 00:32:20,580 644. 247 00:32:20,580 --> 00:32:26,960 This gives to the user a write and read access. 248 00:32:27,420 --> 00:32:29,700 Okay, sounds reasonable. 249 00:32:29,700 --> 00:32:32,270 Nothing bad on that. 250 00:32:33,270 --> 00:32:39,150 Group access to give it read access. 251 00:32:39,150 --> 00:32:40,750 Why? 252 00:32:40,870 --> 00:32:43,130 I really like, really? 253 00:32:43,130 --> 00:32:45,590 Are you sure about that? 254 00:32:46,830 --> 00:32:59,370 But everyone to have read access into the Zoom local database of the Zoom user. 255 00:32:59,890 --> 00:33:00,910 Why? 256 00:33:00,910 --> 00:33:03,410 Literally, that's what I had in mind. 257 00:33:06,280 --> 00: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. 258 00:33:22,860 --> 00:33:34,540 Because the permission or the file permission for the Zoom local database is set to be read by everyone. 259 00:33:37,800 --> 00:33:42,460 And, okay, another thing that is quite cool. 260 00:33:43,300 --> 00:33:46,460 Zoom is end-to-end encrypted. 261 00:33:46,860 --> 00:33:48,020 Is it? 262 00:33:48,940 --> 00:33:54,220 We can see later, but my answer is not fully. 263 00:33:55,860 --> 00:34:01,600 One awesome product by Zoom is Zoom chat. 264 00:34:01,600 --> 00: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. 265 00:34:32,860 --> 00:34:38,180 This is not the point, but it looks good as a product, right? 266 00:34:39,560 --> 00:34:44,380 And as we go back here is, yeah. 267 00:34:45,900 --> 00:34:50,140 There are so many cool things to read, but I would focus on the security part. 268 00:34:51,140 --> 00:35:01,660 As we can see in the security and archiving and in I-Code, Zoom encrypts data at all times. 269 00:35:01,980 --> 00:35:17,800 Again here, encryption of data in transit and at rest and then encryption for data and mobile devices. 270 00:35:18,640 --> 00:35:22,060 Your messages in this chat are secured. 271 00:35:22,080 --> 00:35:23,640 Another one. 272 00:35:23,940 --> 00:35:32,180 So there are a lot of advertisement that is going with how secure Zoom chat is happening. 273 00:35:32,300 --> 00: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. 274 00:35:59,520 --> 00:36:00,800 It's cool. 275 00:36:01,300 --> 00:36:06,780 But at rest, this means that they have full end-to-end encryption happening, right? 276 00:36:09,760 --> 00:36:13,520 And yeah, repeating again the same sentences. 277 00:36:15,740 --> 00:36:17,640 And let's pause this. 278 00:36:46,960 --> 00:36:49,580 I'm not sure. 279 00:36:51,060 --> 00:36:53,360 This way is fine. 280 00:36:53,580 --> 00: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. 281 00:37:04,420 --> 00: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. 282 00:37:17,700 --> 00:37:19,680 As advertised. 283 00:37:19,680 --> 00: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. 284 00:37:33,320 --> 00:37:41,540 And I can just read what's happening there and what they are storing on your local device. 285 00:37:44,950 --> 00:37:51,810 So here I sent a message and it's saying that this is secret. 286 00:37:52,630 --> 00:37:55,770 Oh, well, just one second. 287 00:37:55,770 --> 00:37:57,190 I have to repeat that. 288 00:38:12,650 --> 00:38:20,370 The message is being stored locally at rest in clear text. 289 00:38:24,630 --> 00: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. 290 00:38:45,450 --> 00:38:47,450 And yeah, this does not sound good. 291 00:38:47,450 --> 00:38:52,630 And it's not the one that you can have a record or a backup for your messages. 292 00:38:52,630 --> 00:39:03,230 It's just a debugging feature that they left open in production for the Linux build. 293 00:39:03,270 --> 00: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. 294 00:39:18,450 --> 00:39:27,910 By the way, the fact that the same database that for messages is having the 644, where is it? 295 00:39:27,910 --> 00: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. 296 00:39:45,910 --> 00:39:47,390 Doesn't sound good. 297 00:39:49,490 --> 00: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. 298 00:40:03,370 --> 00:40:12,930 I did this for curiosity purposes mainly, but definitely I could have spent more time. 299 00:40:13,950 --> 00:40:24,390 But then, yeah, I jumped to the responsible disclosure now, and I started the experiment in around April. 300 00:40:24,410 --> 00: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. 301 00:40:46,850 --> 00:40:54,560 And May 5th of 2020, I received request closed to memory leak at Zoom.us. 302 00:40:55,670 --> 00:40:57,560 Yeah, here. 303 00:40:58,570 --> 00:41:00,680 So yeah, I wasn't happy. 304 00:41:05,420 --> 00:41:07,950 So what's next? 305 00:41:07,950 --> 00:41:10,200 Tweeted about that. 306 00:41:11,090 --> 00: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. 307 00:41:24,430 --> 00: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. 308 00:41:36,250 --> 00: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. 309 00:41:51,730 --> 00:41:56,550 Then it was closed as not applicable. 310 00:41:58,410 --> 00:41:59,990 Sure. 311 00:42:02,520 --> 00:42:16,200 Then I sent on July 11th, my new research results, reporting new seven different security vulnerabilities, six to seven new vulnerabilities. 312 00:42:16,940 --> 00:42:20,660 I got an acknowledgement about receiving my report. 313 00:42:20,660 --> 00:42:27,400 By the way, this is the first conclusive response regarding the memory leak issue. 314 00:42:29,100 --> 00:42:35,100 By conclusive, I mean that they did a full analysis of what was happening. 315 00:42:35,100 --> 00: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. 316 00:42:45,060 --> 00: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. 317 00:42:53,800 --> 00:42:59,570 And it was in like literally three months after I reported it. 318 00:43:00,800 --> 00:43:06,860 Then further explanation from Zoom regarding the vulnerability or the findings in general. 319 00:43:08,520 --> 00:43:21,080 Okay, now with what was happening and then from their explanation, and then my response regarding each analysis that they provided. 320 00:43:24,180 --> 00:43:30,600 So for the public authentication, yeah, you can see what's happening here, what they wrote. 321 00:43:31,200 --> 00:43:33,380 And well, yeah, for me, yeah. 322 00:43:33,380 --> 00:43:38,740 Well, again, this may be a forgotten server that was mistakenly exposed. 323 00:43:38,740 --> 00: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. 324 00:43:48,740 --> 00:43:54,300 Oh, wait, I think I messed up with the messages here. 325 00:43:54,380 --> 00:44:00,980 Anyway, so this is the same slide from the last one. 326 00:44:04,120 --> 00:44:17,360 So we did check that ImageMagick is not used for image conversions here, but wait, the same vulnerability is being reproduced. 327 00:44:17,360 --> 00: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. 328 00:44:34,060 --> 00:44:37,180 This sounds reasonable. 329 00:44:37,180 --> 00:44:41,340 In all cases, it's clear that something is wrong, right? 330 00:44:44,660 --> 00:44:48,120 Shadow IT and Zoom. 331 00:44:48,120 --> 00:44:55,200 So these are non-sensitive information disclosure from a shared environment. 332 00:44:55,560 --> 00:45:00,820 Information hygiene is important to us and we appreciate you reporting this finding. 333 00:45:00,820 --> 00:45:01,900 So that's great. 334 00:45:01,900 --> 00:45:07,840 So Full Hunt can help here, probably the best product out there for mitigating shadow IT risks. 335 00:45:10,880 --> 00: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. 336 00:45:27,640 --> 00: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. 337 00:45:43,480 --> 00:45:50,120 They were supposed to patch or release it on August 2nd, but it was released on August 3rd. 338 00:45:50,120 --> 00:45:53,920 In all cases, I have read the change log. 339 00:45:53,920 --> 00:46:00,140 There was no mention whatsoever for any security patches. 340 00:46:00,140 --> 00:46:06,700 So clearly it was a silent fix, which it wasn't a nice thing. 341 00:46:06,700 --> 00:46:16,280 At least users should have some transparency of the state of security for the company that they use or trust. 342 00:46:24,490 --> 00:46:25,990 Yeah, the patches. 343 00:46:25,990 --> 00:46:34,240 I just told you about the patches for what happened for the Zoom Linux app. 344 00:46:35,390 --> 00: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. 345 00:46:52,150 --> 00: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. 346 00:47:08,310 --> 00: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. 347 00:47:19,310 --> 00:47:29,630 So my responsibility is just to, as part of the research that I'm conducting, is to just let them know. 348 00:47:29,630 --> 00:47:30,710 And that's all. 349 00:47:31,690 --> 00:47:33,050 What else? 350 00:47:33,350 --> 00:47:43,450 The findings, the shadow IT, I'm not sure if they started reviewing all of their shadow IT instances. 351 00:47:43,450 --> 00:47:46,150 That's something that they are supposed to do. 352 00:47:46,150 --> 00:47:50,910 For the Kerberos server, they took it down, which is good, which is awesome. 353 00:47:52,630 --> 00: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. 354 00:48:07,990 --> 00:48:15,570 It was released with no mention for any security fixes or updates. 355 00:48:18,260 --> 00:48:27,400 Yeah, for me, it was a difficult experience to be able to report these vulnerabilities to them. 356 00:48:27,400 --> 00: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. 357 00:48:35,900 --> 00: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. 358 00:48:57,420 --> 00:49:08,420 And I assume that was the reason why they are patching it that quickly, comparing to my experience to Zoom VDP. 359 00:49:10,080 --> 00:49:16,140 And yeah, of course, I did not release anything that I found before this talk. 360 00:49:17,880 --> 00:49:23,400 To other parties or unauthorized parties. 361 00:49:25,540 --> 00:49:29,140 And yeah, so it was not mentioned in the media before. 362 00:49:29,140 --> 00:49:31,340 I did not share it with anyone in the media. 363 00:49:31,340 --> 00: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. 364 00:49:41,280 --> 00:49:43,040 And that's one thing. 365 00:49:43,140 --> 00: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. 366 00:49:54,220 --> 00:49:56,740 I would be really surprised about that. 367 00:49:58,060 --> 00:50:03,400 Another part is the massive growth versus security. 368 00:50:04,820 --> 00:50:11,300 Zoom has massively grown in 2020 in a way that no one could have imagined. 369 00:50:11,820 --> 00:50:14,500 Zoom has been here forever. 370 00:50:14,500 --> 00: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. 371 00:50:28,580 --> 00:50:32,100 And this reflected a lot on the security. 372 00:50:32,100 --> 00:50:40,100 A lot of people have a clear focus on the security of Zoom since it became a part of our lives. 373 00:50:40,820 --> 00:50:42,200 Everyone is using it. 374 00:50:42,200 --> 00:50:49,000 I use it, my company use it, everyone that I know use Zoom. 375 00:50:50,400 --> 00:50:55,000 And that's why security is extremely important now for Zoom. 376 00:50:55,100 --> 00:51:03,260 And the thing is having security means that you have to have a full security program running. 377 00:51:03,300 --> 00:51:06,540 It's not that easy to have a full security program. 378 00:51:06,540 --> 00:51:10,060 And there are a lot of things to consider when doing that. 379 00:51:10,560 --> 00:51:18,220 For me, when I build security programs in companies, I take a lot of time to do that. 380 00:51:18,220 --> 00:51:20,240 And this is a typical thing. 381 00:51:20,360 --> 00: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. 382 00:51:35,340 --> 00:51:41,620 It's about different processes that should have been already done before the pandemic. 383 00:51:42,840 --> 00: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. 384 00:51:59,060 --> 00:52:02,740 Lack of communications and focus. 385 00:52:02,740 --> 00: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. 386 00:52:18,500 --> 00:52:25,100 I'm just saying that there is a lot of work for the security program at Zoom to be done. 387 00:52:27,110 --> 00:52:28,490 The reward? 388 00:52:28,490 --> 00:52:30,070 Yeah, that's another thing. 389 00:52:32,050 --> 00: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. 390 00:52:48,930 --> 00:52:50,550 This is not a...