 This is Patrick Wordle, and his talk is You're Muted, a scratch that rooted. Aloha and welcome to my talk on exploiting Zoom. My name is Patrick. I am the founder of the Objective C Foundation, free open source Mac security tools, write some books on Mac malware, and organize the Objective by the Sea Mac security conference. Today we're going to learn about local privilege escalation vulnerabilities impacting Zoom's Mac OS clients. Bugs that allowed a local attacker or an unprivileged piece of malware, the ability to gain root. We'll start the talk highlighting some previous but relevant research, and also talk about an interesting new feature that was introduced recently in Zoom. We'll then discuss a crypto bug, a downgrade attack, and then end the talk talking about how Zoom fixed these vulnerabilities. Now besides learning about these bugs, I also hope that this talk highlights the techniques and approaches I use to find vulnerabilities on Mac OS that maybe you can apply to your own research as well. So let's start the talk by looking at some relevant background information, some previous research, as well as highlighting a new feature that was recently added to Zoom, a feature that is central to all the new bugs you'll be learning about today. So if you are at Defcon 25 in 2017, you might have seen in my talk on installers. The TLDR of that talk was basically as follows. Installers often run as root, but with these elevated privileges perform unsafe actions that would allow a local attacker or unprivileged malware. The opportunity to surreptitiously subvert the install process to gain root access. So for example, as we can see on the slide, an installer will authenticate with the user and then maybe drop a file to a temporary location or some other world-rideable location. It will then execute sometime thereafter this file. So obviously there's a window where a local attacker or unprivileged malware could go in and subvert that file because it's world-rideable, add some malicious commands, and then when the installer comes to complete the install, it will execute those additional commands giving the attacker root. More recently, in 2020, kind of the beginning of the pandemic when Zoom was really blowing up in terms of popularity, I dug around in Zoom and the motivation for that and also the other bugs we're talking today is I'm a user of Zoom and if it's running on my system, I want to make sure that it's reasonably safe and not opening up my computer to a large amount of attacks. So I was digging around in its installer code and I found exactly the type of flaw that I talked about at my DEF CON presentation. So we can see on the slide, I ran a process monitor to see exactly what the Zoom installer was doing behind the scenes and we can see that it's executing a script called run with root. If we look at the UUID, the UID, we can see it's zero, which means it's actually, yes, executing as root. However, if we look at the permissions of this file, we can see it's world-rideable, it's owned by the user, even though it's being executed by root. So you've got a local attacker who could very easily modify this file and then when the installer comes along and runs it with root privileges, whatever the attacker has added will be executed, giving the attacker the ability to elevate their privileges to root. So coming on, end of last year, this is where we're kind of transitioning to the new research, I noticed a new feature in Zoom. Unsurprisingly, when you either install Zoom or uninstall Zoom, it will prompt you for a password, as we can see on the slide. This makes sense as the installer and conversely the uninstaller need to perform privilege actions. However, there was a new feature I noticed, an auto update, which is enabled by default. And it appeared to be able to install new updates without requiring any user interaction, no password, no need to authenticate. Now this is obviously neat from a usability point of view, but from a security point of view, this really piqued my interest. I was like, how is this working? What's going on? So let's dig into this a little more because we need to gain a fundamental understanding of how this new feature works in order to understand the bugs we will talk about shortly thereafter. So again, if we fire up a process monitor, we can watch what's going on behind the scenes. I'd like to start with a file monitor, process monitor, before jumping into disassembly or debugging, because oftentimes you can get a very good insight into what is going on without actually having to do a lot of work. So we can see that the Zoom application executes an updater application called zoomautoupdater.app. And I've highlighted two things about it. We can see the path to the application and also the fact that it contains or rather takes a myriad of command line options. And one of these options is the path to the update package containing the new code. So now let's do some disassembly. If we disassemble the updater app, we can see it making an XPC connection to a mock service named uszoom.zoomdaemon. This is just kind of like an IPC mechanism, one process connecting to another. So that was interesting. It was like, what's going on here? So I did a little more research and I found this maps to a privilege Zoom daemon that runs with root privileges. If we look at the daemon's property list, we can see, as is shown on the slide, the path to the binary of this daemon. And it exists or lives in the protected privilege helper tool directory. So let's dig a little deeper into this binary. Again, this appeared to be a new binary and it's running as root. So from a security point of view, always good to audit those. So the first thing I did, I used a tool called class dump which allows you to dump classes and methods implemented in this privileged Zoom daemon. Here's a snippet from that output and it includes an XPC protocol class and its method. And one of the methods that stood out to me was something called install new package. And as we'll see on the next slide, this is what was invoked by the Zoom clients to perform a privileged install. Without the need for a password. So if we step back to the updater application, looking more at its disassembly, we can see it connecting to the privileged Zoom daemon and then invoking that aforementioned install new package method. Really neat feature of Objective-C is processes can actually invoke other methods in a remote process. So that's exactly what's going on here. So once the updater application calls into the daemon to install a new package, the install is completed when the daemon actually executes macOS's built-in installer binary, along with the update package. And as this Zoom daemon is running with elevated privileges, right, it's running as root, the installer that it spawns also runs with root. So this is why the user does not have to type or re-enter their password when an auto update or a new install is performed. So now we know how updates can be installed without the need for a user's password. Now this privileged daemon, as I mentioned, was new, kind of a new attack surface. So as a Zoom user, my first question was, is this secure? Or is this opening up my system to new vulnerabilities? And well, the good news was, at first glance, the answer appeared to be yes. Zoom was doing two important things to ensure, or at least try to ensure, that the security of this privileged daemon. So first, they implement some code, and we'll look at this on the next slide, to only allow privileged and authenticated Zoom clients to talk to the daemon. This is really good. You don't want random binaries connecting to your privileged daemon and invoking its method. Secondly, it also appeared that Zoom was validating the cryptographic signatures of the update package. Again, this is a great idea. You don't want the Zoom updater running arbitrary packages. Again, it's root. So let's take a closer look at both of these. First up, in the privileged Zoom daemon, there's a method called isValidConnection, which is invoked automatically any time a client attempts to connect to the daemon, and then execute its privileged methods. So as we can see on the slide, the Zoom daemon will validate the cryptographic signature of the client that is trying to connect to it and only allow that connection if it has been signed by Zoom proper. So this code looks solid. This all looks really great. The second security check, the Zoom daemon also checks, as I mentioned, the signature of the package that it's about to install, the auto-update package. And it does this in a method called checkPKGPackageAuthority. And what we can see if we look at the disassembly is that it actually executes a built-in command-line utility from macOS called packageUtil with the checkSignature flag. And then it grabs the output from this, looks for the certificate authority chain to make sure that the package that it's about to install is installed by Zoom proper. So, so far so good, right? Well, unfortunately not. So we just showed that the Zoom daemon checks the signature of any installer update package in an attempt to ensure that only Zoom packages are executed. As I mentioned, obviously this is a good idea, but as is the case almost always, the security or the insecurity of a good idea comes down to the implementation. So we noted that Zoom executes macOS PKG utility with the checkSignature flag. This will check that the package is validly signed and then also extract the certificate chain. We can see this on the slide. For example, if you execute the PKG utility yourself and give it a package, you can kind of see the output, right? So we see things like the certificate chain. Using the PKG utility is fine, right? That code is solid, but we need to take a closer look at how Zoom then ingests and processes the output from this utility. So on the slide we have the disassembly from the daemons checkPKG authority method and we can see that after they execute the PKG utility they open a pipe and read all its input, rather all its output from standard out and then look for the strings in the certificate authority chain that match Zoom. Now the rather hilarious flaw, the issue is that Zoom looks for the certificate strings in the entire output from PKG utility. And guess what else is included in the output from the PKG utility? The name of the package, such fail. So what we can do is we can just rename any package, even malicious ones, Zoom Video Communications, Inc., Developer ID, Certificate Authority, ApplerootCA.PKG and bypass the verification. So we can see on the slide, again, this is because that the name is first printed out by the PKG utility, meaning that the strings Zoom is looking for, because again they're looking for the strings in the entire output from PKG utility will be found. We can confirm this by popping into a debugger, specifically we debug the checkPKG authority method in the daemon. So on the slide, note that the package we're asking Zoom to install is named in that malicious manner, essentially put the strings it's looking for in the certificate chain in the name of the package. And then we can see the verification method at the bottom of the slide is returning one, or true, meaning it thinks that the package has been signed by Zoom, even though obviously it has not. Now around the time I found this bug, I was really stoked, but that same week Zoom pushed out an unrelated security update, which actually meant that I had to find another bug for a full exploit chain. But it turns out that wasn't a problem. So Zoom version 5.9 was released with security enhancements, and one of these enhancements impacted the exploitation of this package rename check I just talked about. Though Zoom didn't fix the buggy package validation, they still executed the PKG utility, read all the output, look for the strings. Another part of their security enhancement logic meant that they now rename the package before doing the verification. So unfortunately, that means when they rename the package, if we have a package with the certificate authorities in the name, that doesn't matter anymore because Zoom is gonna rename the package first, essentially wiping out those strings. Now I noted the check is still done via the PKG utility, so they're still looking for those strings. So it did appear that there's perhaps other ways to still exploit that. Perhaps you could get a certificate that had all those strings in one name or something. But now it was definitely harder. So I was kind of pondering this in the shower, as one does, and I had this like shower thought, and I was like, wait a minute. So yeah, it sucks that Zoom pushed out this update, but can I ask Zoom just to install an older version of itself, one that doesn't have these additional security checks? So I went back to the installer and I looked at its update logic in the daemon and we can see that there was no check on the version that they are installing. So this means it will gladly and naively install any version of Zoom, even older buggy ones, as long as they are still signed by Zoom and they all still are. So armed with these bugs, now let's talk about exploiting Zoom from Zoom to Root. First though, we kind of have an issue that I've ignored or glossed over so far. So recall that Zoom, the privileged Zoom daemon, only allows validly signed Zoom clients to talk to this. So does this mean that we can't trigger the bug at any time, right? Do we have to wait until there's a legitimate install that comes down for Zoom and then, you know, hopefully pop in at the right time? That would suck, right? Well, while we were reversing the auto update process, we saw that the update request to the update daemon was triggered by a standalone application, the Zoom auto update application. And if we reverse-engineer that, we see that the updater application takes a myriad of arguments, including as I mentioned before, the path to the install package. Now as the Zoom auto update application is obviously signed by Zoom, it is a trusted client. So that means we can trigger an update any time by just manually executing the Zoom auto update application ourselves. All right, so now I'm gonna do a brief demo. It's always a good idea to do live demos, right? We're just gonna show the fact that we can trigger an install of Zoom at any time. So this isn't an exploit. I'm basically just gonna tell the privileged daemon, hey, I have an update for you, and I'm gonna give it a real version of Zoom. So the first thing I wanna show you on the slide, we've run the PKG utility and the package I'm going to update is signed by Zoom. So I execute this, this is obviously gonna work. I'm just telling the daemon, oh, sorry, we lost the monitors, thank you. Maybe if I turn off mirroring. Okay, let's try this again. Okay, so now we have the, let me make this a little bigger. We can see again, we run the PKG utility on the package. I'm going to tell Zoom to upgrade to. Again, this is a legitimate version of Zoom. I'm not doing any exploit at this point. I'm basically running the auto update application. We can see here's the prompt from Zoom, and this is gonna just install a version of Zoom. Hooray. So again, this just shows that at any time we can tell the update or daemon that, hey, just to let you know, we can trigger an update. Okay, let's continue this. Okay, so now what we wanna do is we want to exploit to gain root. So we can do this in two steps. The first thing we do is we execute the auto update application that we just demoed, and we give it an older version of Zoom. This is a validly signed version of Zoom, but it doesn't have the additional security enhancements that break the name trick. Once this has completed, we then execute the update application again, this time with our malicious package that we've renamed so that it finds the certificate authority strings in the package name. And result will have a root shell. So here is a prerecorded demo. We can see we're gonna first execute the update installer, just like we did in the other demo. This is going to install an old version of Zoom. Once this is done, we're just gonna execute the auto update application again. This time though, you'll see the name of the package has this long name with all the certificate authority strings that Zoom is looking for, right there. And then this is gonna be executed and pops this root shell. So who right? We, but wait, we can make this better. In the video, the demo, we saw there was a big pop up saying Zoom is updating. If you're an attacker, that's not good news. So I said, okay, how can we make this better? So I continue to reverse engineer the auto update application, and as I mentioned, it takes a myriad of arguments. Two of these arguments control the UI, the user interface of the upgrade. Specifically, the fifth and sixth, RGB six and RGB five arguments. If you set those to zero or false, this tells the updater to perform with no alerts, silently. So this makes our exploit now 100% invisible. Hooray. So now let's talk about how Zoom fixed these bugs. I'm always interested in what they did. So first off, they assigned a CDE for the downgrade attack. This was fixed in version 59.6, which was released in April of this year. Took about four months to fix that. And they gave out a nice bug bounty for that. This is the kind of security details from now. So let's dive now into the disassembly to see how they patch this. So this patch exists in the privileged Zoom daemon that's running with root privileges. And now what we can see is they're checking the version to make sure that whatever version is about to be installed is in fact an equal or an upgrade. So it's not a downgrade. So they do this by unzipping the package, extracting the version number, and then doing a comparison. The very bottom of the slide, we can see where they do the comparison. And again, this ensures that the update version is indeed either equal to or greater than the currently installed version. So now if we try to perform the downgrade attack as we can see on the slide, this is gonna fail. Basically let's say GTFO, this is an old version, I'm not gonna install this anymore. So that's great. The package validation vulnerability took a little longer to fix, about seven months, but again, they paid out a nice bug bounty for that. This was fixed in July, 2022. And if we look at how they do this, we can figure out the new implementation to see how they securely patch and check the verification of packages. So if we use the O-Tool utility to dump the dependencies and then the NM-Tool to look at the new imports and methods, we can see that they're now leveraging some new cryptographic APIs. So instead of executing the PKG utility, they're now using various cryptographic APIs to check the code signing certificates of the package securely. So again, this is a sufficient fix, and we can see that when we execute now a unsigned package or a package that has been signed by anybody, but Zoom, this will fail. A better option, in my opinion, would be do exactly what PKG utility does. So what I did is I reversed PKG utility and found the private framework it utilizes, and in that framework are some very powerful APIs that can check the digital certificate of any PKG for you. And so I released some code. This is actually how I verify packages in my tool. I mentioned it's a private framework, but other than that, that's exactly how Apple goes about doing it, so I figured, hey, why not be inspired by them? This is open source. If you pop on GitHub, you can check out how to securely validate packages using the same technique that Apple's PKG utility does. So that was my DEF CON talk up to about a week ago. And I was like, okay, it's a solid talk, some neat bugs, everything's fixed. We talked about it from reverse engineering, but I thought, you know, this is DEF CON. DEF CON demands great talks, so I wanted to dig a little bit more. And again, I was in the shower pondering life now and just getting, I was pondering Zoom, and I was like, there's still something that isn't quite sitting right with me. So now let's talk about another flaw that currently exists even in the latest version of Zoom. So this is currently a zero-day vulnerability. Recall that the update package is moved and renamed and then validated. And again, this was part of a security enhancement that broke my initial bug indirectly. So if we look at this a little closer, we can see the name of the package is always gonna be zoomtmp.pkg, this is what Zoom renames it to. If we look in a debugger, we can see the copy operation is performing. And what they're doing is they're copying it into a directory that is owned by root, specifically the library application support zoom.us. Once the package is copied into this directory, it is then verified correctly now using the more secure APIs. And if and only if it passes the verification, it's executed. So again, if we look at this, it's like, okay, this is great, directory is owned by root. This means users just can't create new files, can't delete files. They're using the new APIs, everything's great. But, and this is a big but, there's a very nuanced issue here. So I mentioned the directory is owned by root. The problem is that when Zoom copies in the update package, they don't change the permissions. So even though it exists in a root-owned directory, the update package is still world writable. This means any local attacker, unprivileged malware, can surreptitiously modify the update package. This is a classic time to check, time to use race condition. Basically what happens as I mentioned is Zoom, the privileged daemon comes along and copies, renames the application into the root directory, it verifies the signature, unzips it, and then installs it as root. So again, if we're correctly timed, is there an opportunity for us to surreptitiously pop in and modify this after the verification, but before the application is installed? It's a great question. The good news is, this race window is rather large. And this is because that Zoom performs many other very expensive and slow operations after they have verified the package, but before they install it. Specifically, they unzip the package as part of the version check, and they do that by spawning additional processes, which is a very expensive and slow operation. So basically, we have a very large window. So here's the exploit, it's about 10 lines of code, as I mentioned, works on the latest version of Zoom. So if you're running Zoom, lucky you. And we can see it basically does three things. We execute the Zoom auto update application. Again, this allows us to trigger an update. We have to give it a validly signed package from Zoom. So we just grabbed the latest version. We don't actually care what it's installing. We just need to trigger any installation logic. And again, we can do this because the auto update utility is allowed to talk to the Zoom client, and the package we're telling Zoom to install is initially a valid Zoom client. We then wait until the copy of the package comes along, wait an additional millisecond or two, and again, because Zoom forgot to update permissions of this package, we can now, with no privileges, modify that package. As long as you do it before the installer is invoked, when the installer comes along with root privileges, it will then install our package. All right, I'm gonna say a prayer to the demo gods, because we're gonna try to do a live demo of a race condition. Okay, here we go. So what we're gonna do, and we'll look at the exploit code shortly, is we're going to perform those three steps. This is obviously gonna work. So first we see the installation coming along. Uh-oh, I totally jinxed myself. Wait for it, wait for it. I didn't actually say a prayer, so maybe that was the problem. Sometimes it takes a while. All right, let's try this again. So let me just maybe see if the installer is running. No, let's see if we can come over here and do the auto update. Might need to reinstall Zoom. I did make a video of this, so if this fails, we'll just look at that. So I'm just gonna reinstall Zoom, kind of get a base condition. Come on, let me look at one more thing. Okay, maybe we'll try this again at the end. Okay, well, clearly I broke something. Maybe Zoom's asking me to install one. So let me try one more thing, and if not, we will move on. Okay, lots of Zoom things running. Let me just kill these quickly. Appreciate your patience. Maybe I tried the demo too many times. Kill-9, and is that all of them? Oh wow, three more. I guess I should've just done a kill all. All right, one more time for good measure. Let's come over here until Zoom to update itself just to get a clean version. Okay, say another prayer. Come back to the exploit, run it. Okay, hooray, that worked, woo! Mahalo for your patience. All right, so now we have a nice exploit, but again, I mentioned that, or as you saw, there was a bunch of pop-up windows, and so if you're trying to exploit this locally and there's a user on the system, it's a dead giveaway. So let's see if we can improve this. So let's close this root terminal, pop in here, pop into Vim and modify the exploit. And I mentioned that the auto-update application utility takes a large number of command line arguments, and one of those controls the user interface. So what we're gonna do is we're just going to update the exploit and say, don't show a user interface. So that one's gonna be command argument number six. So I'm gonna change that to zero. Ooh, how do you exit Vim? Kidding. And now we're gonna run the exploit again. And hooray, now we have a root shell, but with no other alerts. Now, since everything's working, I mentioned this is a race condition, so one of the parameters that the exploit takes is how long to wait. I've hard-coded this for this, or I know the value for my particular system. Obviously, if you're exploiting this in the wild, you're gonna have to do a little bit of playing around. For example, if you do zero, we're gonna see that's way too fast. And let me go back and turn the UI on again. Okay, we're popping root shells all over. So since it's a race condition, right, you have to kind of get the timing correct. So if I come back to here, and just anything other than zero, and we tell it to do exploit zero, this should probably fail, right? It says, fails with error code zero zero seven. If you look up what this error code means, it means that verification failed. So remember, the first thing it does is it copies it and verifies it. So if we jump in too fast and replace the package, the verification is gonna fail. It's gonna see that it's not signed by Zoom. So we have to wait a little bit. Conversely, if we wait too long, like two seconds or something, the installation is gonna install the legitimate version of Zoom. And so we basically missed our opportunity window, right? So Zoom, in this case, grabbed the package, installed it, we replaced it, but it already had gone too long. So you kind of do some playing around, but again, as I mentioned, you can do this silently by changing that flag. So you could execute this as many times as you want on a live system or a target system, changing that until you get the right time and win the race. So again, 0.1 seems to work pretty well. And we get lots of root shells. So, okay, that was stressful. Life lesson, don't give up. All right, so it's a very nuanced bog. It's a very subtle bog. It's a great bog, but it also has a trivial fix. So again, recall, the fact, the bog, is Zoom simply forgot to change the permissions when they copied the upgrade package into the root-owned directory. All they have to do to fix this is to update the permissions once they've copied this in before they verify this. Again, the directory they copy it into is owned by root. So if they change the permissions on the package and then do all their verifications, that would thwart any local attacker because the local attacker then would not be able to modify either anything in that directory or the PKG itself. So there's a single line, a single API call you can call in Objective-C. You could also use C, do this in Swift, and simply change the permissions on the file. So I've gone ahead and done this manually and we basically changed the permissions of that Zoom TMP PKG, the update package, and we set it to be the owner of the directory, which is root and wheel. Once we've done this, our exploit will now fail because when it goes to try to modify the package, it doesn't have the permission because again, we're running with lower privileges, we're trying to get root. So hopefully Zoom will push out a fix for this. Again, pretty simple fix. All right, so let's end with some conclusions, some takeaways. First and foremost, be very, very careful choosing usability over security. And this applies not just to Zoom, but to everyone. If I have a critique of Zoom, it's that they continually choose usability over security. And who can blame them? That's what we, that's what users want, right? That wasn't the case, maybe this wouldn't be the reality. In this case, if Zoom had simply asked the user for their password and then used the installer every time an update came along, I wouldn't be here. None of these bugs would have existed. Again, that's a little more problematic for the user. I mean, it inconvenienced them slightly. So again, from purely a usability point of view, I understand what Zoom did. But from a security point of view, they opened up this huge attack surface, which in retrospect, I really don't think was a good idea. Second, the fact that installers have problems is not a new, it's not a new thing, right? I talked about this at DEF CON. Zoom had already three, four, five, six other bugs in their installer code. This was all really talked about in my and other people's talks. So watch DEF CON talks. And then finally, and this is another kind of critique I have about Zoom is, and also applies to other software, where there are bugs, several bugs, there's likely to be more, right? I looked at the installer. Every time I look at an installer, there's new bugs. So this is a little, again, disappointing, but from a security research point of view, if you wanna find a lot of bugs, find an area that it's new or has other vulnerabilities and you will likely find more. I also briefly wanna mention, if you're interested, if you enjoyed this talk, you're interested in reverse engineering, debugging, Mac analysis. I've written a free book on Mac malware analysis that covers a lot of the topics. You can grab a digital copy for free. It's also sold by NoStarch Press, so check that out. I also want to briefly thank the companies that support the Objective C Foundation, as I mentioned, that's the foundation I founded and worked for. I also wanna thank, obviously, the amazing DEF CON conference. It's incredible to be back at full energy. I'm sure you're all stoked as well. And also, I wanna thank all of you for attending my talk. So I think we have a few minutes for questions and answers. So if there's any questions, let me know. I'll also be here after the talk, so we can talk more. Yes, in the front. Yes. Is it? No, no, no. Oh, man. Okay, let me do this in the fast way. Think it's here. Okay, yes. Take a picture. Again, pretty straightforward. We basically just wait for that package to be, we trigger an update request, wait for the package, and then replace it. So, again, this is not some incredibly sophisticated exploit. It's a pretty standard race condition that, again, is pretty winnable. Yeah, another question. Great question. So the question was, what are my tools for reverse engineering? I wrote some of my own tools, the file and process monitors. If you go to objective-cse.org, you can grab those. Those are free open source. For reverse engineering, I use the Hopper disassembler. It's about 99 bucks, so I think it's good. It's also very Mac OS specific, and the developer is very responsive to bug requests. So, it's just my tool of choice. Ghidra, IDA would probably work as well. And then for debugging, I use LLDB, which is Mac OS' Apple's built-in debugger. The question was, have I tried this exploit on any other apps? I have not. Also, this one is obviously specific to Mac OS. That, having been said, the downgrade attack also impacted Windows. This again is something of a little bit of a critique of Zoom as well. I didn't even think to check Windows. I just reported, hey, your Mac client is vulnerable to a downgrade attack. And then like four months later, someone from Google Project Zero was like, the Windows version is vulnerable to a downgrade attack. And I was like, can I get that money? Not really, but the thought was, if I reported this bug to Zoom, you would have thought it would be like, okay, downgrade attack on the Mac client, maybe the other OS's are vulnerable as well. And so that was really my biggest disappointment was that they themselves didn't take the initiative to say, hey, maybe we should check this. And so nothing against Google Project Zero, kudos. And I didn't even look, the bug might've been totally different, but again, from a conceptual point of view, since it impacted Mac OS, it also impacted their other operating systems. And they didn't again kind of take the initiative to figure that out once the initial bug was reported. Yes. Yeah. And here's Patrick dropping Zoom zero days. Wow. Great question. So the question was, what can Zoom do to improve this? So first of all, I have actually a lot of really good friends that work at Zoom and I have a ton of respect for them. They are brilliant researchers and I do feel a little bit bad for dropping zero days at them, but you know, come on, this is DEF CON. Also, you know, as I mentioned, a lot of the other bugs I reported to Zoom really took a very long time to get fixed. And in the meantime, users were vulnerable or exposed. I'd be very naive to assume that just because I can find these bugs, nobody else could. That's very arrogant. Yes, I have a propensity for finding them, but any other security researcher who's looking at this code would likely find these bugs as well, especially nation states, hacker groups, et cetera, et cetera. So I think one of the issues is that we as users are not demanding this. I mean, Zoom has a huge market share. It's really popular. If everyone was like, we're gonna stop using Zoom until they get their security act together, that would change it. Yeah, so maybe the government can jump in. I mean, this is a great question and I think it applies to any company. Traditionally, usability is, I think, prioritized, especially by startups. I mean, you can't blame Zoom. They made a gazillion dollars. So, and their shareholders are demanding that they make money. And security, unfortunately, isn't necessarily incentivized. So until that changes, and again, not picking on Zoom, like this is what most companies do, it's kind of like following the money. So I think if there's more regulations, or I remember when Mr. Musk was like, no Zoom at Tesla or whatever it was when some of these bugs were coming out, I think those are the things that change that. So I think Zoom is definitely taking steps in the right direction, but I think there's some responsibility from us to also demand more. And so maybe us pushing for regulations or talking about these problems at DEF CON, bringing more awareness is ultimately how we kind of change the priorities. Because until the priorities change, companies, including Zoom, are probably not super motivated to go after security. It's not sexy. Doesn't really cost them a lot of money, at least traditionally. So like, why would they? Maybe I'm jaded. Any other questions? Yes. Yeah, the question was, do I have copies of my book here? NoStarchPress has a table in the vendor area. So you can swing by there. They have a discount. I also will be doing a book signing tomorrow, which is like a big exciting event for me. So feel free to swing by. I'll sign a book and we'll talk nerdy and that would be awesome. All right. Thank you again so much.