 Hello, IoT Village, first and foremost, what it be, what it do, I'm Mark and boy have I got some zero days for you. Now, the reason why I call this talk Assembly Voluntron isn't just because I'm hacking a robot and it's a cool name and incredibly clever too, but also because there's four unique CVEs in this target and when they work together they kind of create something that's greater than the sum of its parts, just like a mech you might have heard of. So, the next thing you might be wondering is who are you and why should we care what we have to say. Well, to start off, like I said, I'm Mark, which is really only one natural response. And you can find me on Twitter at Ropsicle. And I'm a currently security researcher from McAfee's advanced threat research team, which I'll be referring to as ATR from now on because it's kind of a mouthful. Now, my focus has been on finding zero-day vulnerabilities, particularly in embedded systems. So, this talk is really on-brand for me, so to speak. Now, as for previous experience, I spoke at the last year's DEF CON and ICS Village, so I'm basically a celebrity. Now, for hobbies, I really only do two things. I hack and I squat. Now, depending on how nice you guys are to me and the Discord channel after, I might add streaming to that list, but for now, it's just those two. Okay, so let's move on to the target. Temi or Timi or however you want to pronounce it. The fact is, it's actually a pretty cutting-edge piece of tech. So, the marketing describes it as the world's first truly intelligent, mobile, personal robot for your home. That's a lot of qualifiers. As you can see here, it's actually a pretty small device. It's about four feet tall and it's got kind of like an Android brain. That's like an Android tablet at the top with a camera and a microphone and a fully functioning touchscreen. Now, this device was created by a Robotemi Global LTD and they're sort of like a startup company. This is their first venture into the consumer space. It's actually spun off of a parent company called Roboteam, which is the military robotics based out of Israel. Now, this thing isn't cheap. It's going to set you back about two grand, but you do get a lot of hardware for that price point. So you get, it has the ability to do remote teleconferencing thanks to its camera and microphone. But more importantly, it also has an autonomous movement and obstacle detection thanks to the various sensors it features and also the 360 LiDAR. And finally, as you'd expect, it has a Alexa and smart device integration being a smart IoT device. And you get all the standard things you'd expect from an Android tablet, Wi-Fi, Bluetooth. It even has a wireless charging pad on the back that doubles as a coaster, at least for us. So although Robotemi likes to advertise their robot as being sort of a consumer device, the reality is that it's actually seen a lot of use outside of that space. So I think one of the biggest things we've seen recently is that it's used sort of as a mobile kiosk. So in places like the Mall of America and the Nautilus Hotel and even in certain corporate environments like Transfighter Corporate Offices, you'll see that it serves as an informational kiosk that has the advantage of being able to show people around. So instead of just telling people where to find, you know, like Jimmy John's in the mall, for example, it can actually navigate them there. But perhaps the most important and impactful application of this robot is in healthcare, especially given the recent pandemic. So with doctors visits becoming more and more, you know, the standards becoming more remote visits and remote, you know, teleconferencing for doctors appointments, this has actually seen a lot of pickup in the healthcare space. So already we're seeing it being used by places like Trillium Health Resources. In fact, it's also been picked up by the Israel's Ministry of Defense as like the de facto us teleconferencing solution for the medical wards throughout Israel. And we also see a lot of applications in Southeast Asia of all places with places like China and South Korea, you know, ordering hundreds of these units for their nursing homes and medical institutions. And to accommodate this increased demand, Robo Temi has actually increased production of these units to about a thousand a month, I believe, to just to meet this growing demand in the medical space. So now that we know what Temi is, what it's capable of and where it's being used, it's important for us to sort of draw a box about what the normal operations that look like. So then we can have a lot of fun breaking that box. So to start off, normal operation of the Temi is done through a use of its smartphone app, and this is both on Android and iOS. So you can call the Temi from it, you remotely control it that way, that sort of thing. And the registration process for using this app is basically just put in your phone number and it verifies it, and that's how it identifies you. So if you reinstall the app and use the same phone number, it'll still find up your account details. Now upon first booting up the robot, which already was a super fun experience in boxing this thing, but we are prompted to scan a QR code. And this basically just turns whatever user scans that QR code into the de facto admin of that Temi robot. And the admin is only one per Temi, and they have sort of the highest privileges for that robot. Now it doesn't mean that other people can't call your robot or even use it. Phone contacts that they use the Temi app, so phone contacts in like your smartphone. If they have the Temi app installed, they're synced automatically, and this can be done one of two ways. If the admin has phone contacts that have the Temi app, they'll be synced automatically to the robot, and the robot will be aware of them. Alternatively, if you're just a regular user of the phone app, they don't own a Temi, but you have a friend that does, for example, and they're in your phone contacts list, you'll be able to call your friends Temi robot from the app. And we can sort of show you how that works. So once you boot up the app, if it finds a contact that owns a Temi, they'll show up down here on the left under your contacts list. So here we have a lab phone as one of the contacts that owns a Temi. And by selecting this contact, you can see the Temi robot associated with it and even has a button that lets you just call it straight from the screen. And then once a call is actually initiated, this is sort of the interface you're presented with. You can drive the robot around, control your audio options, pretty standard stuff. Now calling is very much so the primo functionality of this robot. And really, callers get a lot of control over the device during the call. They get audio and video feeds from the Temi, but they also have control of its movement, which they can control manually using the little D-pad you saw, but also has access to all of its saved locations. So this immediately became a very interesting potential attack vector to us. Now the Temi does ring when someone besides its admin calls it. So in that sense, if you just added someone's phone number that they don't know you, it turns into basically just trying to cold call a cell phone. There is one exception to this and that admins can actually grant certain users in their contacts less special privileges to bypass this limitation. So if you have like a family that always the same robot and you can't be bothered with having to pick up on the other end each time, an admin can grant several other users the ability to call in without having it ring. And this is also done through the phone app. You can just invite new members and then select whatever contacts you want to be able to control the robot, whatever they want. So now that we have a good grasp of what the normal operation of this device looks like, we can sort of get into the spirit of trying to hack this thing. Now, although this attack is pretty novel and cutting edge in a lot of ways, the approach we took to reconnaissance was fairly standard and typical. So we started with trying to get a local shell on the device. This was actually super easy and short circuited by the fact that the device comes with developer options, which include ADB or Android debug bridge, which allows you to remotely connect to it like you would an SSH session. So that already made our lives a lot easier for moving files around and accessing the device at startup. The next thing we tried to do is actually capture traffic on the device using wire shark. And during stuff like boot up and during phone calls, we saw three IPs being hit pretty frequently. One of these mapped to a Yahoo URL. So this is probably being used for its news app. And then two more mapped to Amazon AWS instances, which while not surprising, don't really reveal much either. The next thing we did was used our ADB shell to actually run and not ADB, that's a little later. We ran an end map scan, port scan on the device to see what ports it was listening on. Another standard thing you'd do for attack vectors. And the only port it identified as being open was the port 4443, which end map classified as being used for the service pharaohs, which is actually related to printing. So this is probably a false classification. It's more likely that this port is being used as an alternative to the standard 4443 you'd see used for HTTPS. Now, to verify that, we actually use the ADB shell we had to the device to run a net stat and actually found that the service associated with this port is something called ComRoboteamTVUSA, which looks a lot more like an Android application than it does a standard Linux binary. And sure enough, that was the case. By parsing the list of installed packages on the device, we actually found the APK associated with this Android application. And using our ADB shell, it was trivial to pull this APK off and start examining the software. So now that we had access to the software, and we also had access to the phone app software at this stage as well, because we could just download the APK from the Play Store, it's completely free, and you don't even need to own a Temi to run it. So we could start looking at both of those at the same time. Now, the rest of this is really going to be like 80% reversing and static analysis. That's just sort of the nature of this project. Now, why might you ask why? Well, the great man once said, the road to exploitation is paved with months of staring at decompiled Java code. That man's name? Albert Einstein. So who am I to argue with that? Now, once we actually got to decompiling the code, we decided to use a program called JADX. And JADX was sort of a favorite of ours because it has the functionality of being able to right-click on any symbol and click on it to find usage, which became really important later on. From there, we had to pick a vector. Now, I don't know how many of you have actually looked at reversing a full Android app, but they have massive code bases frequently, and Temi was no exception. After groping in the dark, we decided that we needed to sort of hone in on a specific subset of the code to refine our search. In our case, we were already interested in the calling functionality of the robot, since that would grant us the greatest level of control entirely remotely. So we began digging through the different libraries that are part of the APK. After googling around a bit, the one that jumped out at us particularly was something called the LibAgora. And this is actually a binary related to the Agora video SDK, which is a third-party library used specifically for video calling functionality. Okay, that's perfect. That's exactly what we're interested in. So from there, we needed to find an entry point related to the attack vector. And you can sort of imagine this as being like a strand on like a wool sweater, the thing you start pulling on to really unravel the whole thing. So we began by actually pulling up this library in Ida and looking at its exports and immediately the function native join channel jumped out at us. It looked like something related to joining a chat room, for example. Opening up the APK now, we saw the same function with the same signature appear in the decompiled app. So that was a good sign. So from there, we could use JADX's find usage feature like about 600 times to sort of begin tracing the code path taken to for starting video calls. Now, at this stage, there really is no more advice or cool shortcuts. It really is, you just have to draw the rest of the L. You really have to just put in the legwork to trace the different function calls that are being made in order to get a better understanding of how the code works. But the fruits of our labor in this case was actually pretty impressive. It's sort of like staring at the sun, so I'll only show it briefly. Did you catch that? All right, let's take a closer look at it. So highlighted in the different colors near the top are the different entry points for the calling code. So there's four ways to initiate a call from the phone app and that correlates to these four. You can call a phone contact. You can call a robot contact. You can call either contact from the recent calls list. And if you happen to be a Temi Admin, you can also call your specific robot. Moreover, we decided to segregate these based on the code flow that's either for outgoing calls indicated in red or incoming calls indicated in blue. And I'm not going to go through this too deeply because it's sort of massive, but this did serve as a good reference point for a lot of the reversing we had to do later. Okay, so we have four vulnerabilities to get through, so let's just jump right into it. The very first one, both chronologically and in terms of complexity, is the CVE ending in 7.0. And we can see here that it categorizes being a use of hard-coded credentials. And as present in the Temi Android app. Now, to have a better understanding of what this vulnerability entails, let's go through the process we used to actually discover it. So this really consisted of four easy steps. R, T, F, and M. And I do mean that pretty literally, like just by looking through the Agora documentation for their video calling API, we were able to get 80% of the way to find this vulnerability. So specifically, we decided to take a second look at that join channel function we saw earlier. According to the Agora documentation, it has two required parameters and two optional ones. And this is really all that's needed to join an existing video call. Now, the first one is something called a token. And it seems that a token, if the user uses a static app ID, the token is also optional. It can be set as null. This was interesting to us. And the second required parameter for joining a channel is a channel name. This is something you will touch on a bit later. For now, we were interested in the static app ID and whether the Temi was using a token at all. Taking a look at the same function in the code, we found that it is indeed setting that token parameter to null, which means that it's likely using a static app ID as indicated in the documentation. Okay, so then we decided to start looking for this static app ID. Where could it be found? Referring back to the Agora documentation, we found the one function, or the one API call that actually uses it as a parameter. And that's the RTC engine.create function. And it uses it as a parameter. And it describes it as being an app ID issued by Agora to the developers, which is sort of vague. But after some more digging, we sort of discovered that this is used as a sort of name space that segregates different users or different implementations on the Agora remote servers. So what it means is that you have a set static app ID that's shared amongst all Temi robots and Temi phone app users. And the app ID ensures that users of that service can only call other Temi users. They can't call an arbitrary Agora client. So this is actually a pretty important credential to have access to. Well, since we knew the function that takes it as an argument, we decided to look for this function in the Temi's decompiled code. And sure enough, there was the app ID hard coded directly into the app. That's freely accessible at the Play Store. I'm fairly trivial to decompile. So this is already a good start. But really to exploit this as a vulnerability, we needed not only the app ID, but also the channel name so we could actually join an existing call potentially. So if we still needed the channel name, how could we get it? Well, by going through that nice little graph I showed earlier, we were able to trace down what function actually generates the channel name. And here it's being called a session ID, but they're really the same thing. And as you can see, this is doing something not too complicated. It's actually just generating a random six digit value. Now, this is important because, you know, 900,000 possibilities may seem like a lot, but it's well within the range of brute-forceable attack vectors. So in theory, an attacker could use the hard-coded app ID, the extracted from downloading the app, which is shared amongst all Temi installs. And then they could just use a brute-force method to try and guess every single possible channel name. And by doing so, they could potentially intercept every ongoing Temi call used by any Temi install. Now, obviously, we couldn't test such a brute-force attack vector against a live production server. But what we could do is we could create a custom Agora app to join a Temi call just launched locally. And we did this by logging the channel name using ADB. And sure enough, using this custom app, we were able to join the existing call and essentially spy on the other two call members. So thereby proving this is a legitimate attack vector. So the next vulnerability I'm going to discuss is sort of a helper vulnerability. It is classified as an origin validation error and it is also present in the Temi Android app. Now, the reason why we call this a helper vulnerability is that it actually is related to the fact that you can modify the Temi app and it still has full access to all the remote services it uses. It doesn't perform any kind of tamper checking to make sure that it's not running on a rooted device, that the code for the app hasn't been modified in any way, it just isn't aware of that. And the reason we were motivated to even pursue this as an attack vector is that it's much easier to modify an existing code than to start from scratch. But more importantly, the Temi Android app already has access to all those remote services, which requires some degree of authentication. So instead of trying to extract the keys it's using and whatever other authentication mechanisms from the app and trying to make it our own, we just leverage the existing app and inject our malicious code into it. So the way we'd accomplish this is by first unpacking the APK, which we can do using APK tool. Next, we would search for the particular piece of code that we want to modify. This could be either through the decompiled code or through the various resource files included with the APK. As a proof of concept, we decided to try and change the text for the call button, which we found through some grabbing. Okay, so now that we knew which part of the APK we wanted to change, the next thing was to simply make that modification. And that was as simple as pulling it up in a text editor and replacing the string with what we wanted. In this case, we decided to rename it Pound, give it a little more spice. And the last but not least, we had to repack but also re-sign the app. And the reason why we need to re-sign is Android does not allow apps that are not signed to be installed on the device. And by modifying the existing app's contents, we invalidated the existing signature. But no worries, since the signature is not being checked by the device, there's no reason why we can't just create our own signature and use that. So the repacking process is once again done using APK tool. And then we create a signature using a combination of key tool and jar signer as shown here. And the end result was that we were able to successfully change the string on this call button. And perhaps more importantly, modifying the app in this way proved not to impact this functionality in the least. Meaning that we could potentially make non-trivial changes and still be able to perform things like calling. Now, exploitation of this vulnerability is a little tricky without spoiling the rest of the presentation. Because really, its main application is used to help exploit the next two vulnerabilities. So we'll save that discussion for them. No spoilers. Okay. Vulnerability numero trace. So this one is actually missing authentication for a critical function. A little more serious than the last two. And this is actually present in Temi's MQTT broker. Which, if you don't know what MQTT is, I'm going to give you guys a real quick crash course on it, just we're all on the same page. So MQTT is a published subscribe messaging protocol that's specifically designed for IoT and other lightweight devices. So it's not too surprising to see Temi using it. Now the way it works is that clients will publish messages to certain topics. And then subscribers to those topics then receive the messages. You can think of it as sort of being like subscribing to a YouTube channel. And then receiving notifications whenever your favorite YouTubers upload, for example. And then the topics themselves are strings that are organized into a hierarchy. And the hierarchy itself is delineated much in the same way that a UNIX file system is. So just forward slashes. Now in terms of the Temi, it uses MQTT for basically all communication between itself, the phone app and the various cloud services. So you see it being used for things like video call invitations, syncing contacts from the admin, and even most importantly privilege management. Which is something we'll delve into in the next vulnerability. So, let's get into the discovery and exploitation of this vulnerability. How are we using MQTT and what authentication is not being implemented? Well, we started by looking at the code that was used by the app to subscribe to this call invite topic. After all, we're all interested first and foremost in the calling functionality. This is just a topic that either a phone app or a robot will listen on when it receives phone calls. And then the person creating a call for that user will publish a message to that same topic. So in our case, it takes the form, you can see it being invoked here on line 408. That's the actual function that is used to subscribe to that topic. And the topic sharing itself takes the form client something followed by invite. And that's something in the middle is a client ID or an MQTT client ID rather. And an MQTT client ID is just a unique identifier for a specific client that's connected to the same MQTT broker. It's just a way to identify different users. So this actually gave us an idea. If could we subscribe to someone else's call invite topic if we're able to modify the app? Well, in order to do that, we would need to know their client ID. So we would need to somehow get this information. But how are these client IDs even assigned? Well, looking back at how recent calls are initiated actually gave us a clue. So if you try to initiate a call from the recent calls list, this is the call code that gets executed. Invokes a function called telepresentservice.initiateCall. And the first parameter is actually an identifier for the contact you're trying to initiate a call with. In this case, it gets that ID by invoking a function called getMD5PhoneNumber. At this point, we were thinking is it possible that the client ID is just an MD5 hash of the phone number? The user used to register? We decided to verify this theory. So we did this simply by taking the Google Voice number we used for our Temi admin, computing the MD5 hash, and then searching for that exact hash in all the various Temi files we had. And sure enough, we got a hit in one of the logs we recorded during a call. And it classifies it right there as client ID. Seems pretty straightforward to me. Now, at this stage, we decided to modify the app taking advantage of the previous vulnerability we outlined. And using this technique, we were able to successfully subscribe to another user's call invite topic instead of our own. Which basically meant that every single time they received a call, we would get that same call. And the only thing we needed to make this happen is the victim's phone number, which telemarketers will constantly remind us is not a high bar. Okay, so getting to the last and easily the most impactful vulnerability. This one is an authentication bypass using an alternate path or channel. And this is present in the Temi's REST API, which is something we'll cover as well. Now, in order to understand the authentication bypass, we first need to understand the authentication. And this is related to the Temi's privilege management system, which is something we've already sort of touched on with the admin versus regular context thing. So, we already know about admins. That's just the person that first registers with the QR code. But there's also two other types of privilege levels. Another one is contacts, which are just the default permissions given to a user. It's also the lowest level. Now, there are two ways to become a contact. The first is simply by cold calling the Temi. And the other is through the Temi admin syncing context to the robot. We'll be focusing on this latter use case. So, the Temi robot actually listens on the topic sync contacts and then followed by its MQTT client ID or its robot ID. That is the same thing for requests from the admin to sync contacts, as we can see here. Now, the requests themselves have the following structure. It uses an object of type sync contacts message. And all this contains is a list of contacts and the client ID of the person sending the request. And then the contact list is just a tuples of MQTT client IDs and the display names. Pretty straightforward. And the reason why the sender client ID is included is because the Temi locally ensures that the sender is equivalent to the ID of its admin. Just as a sanity check. Okay, so that's contacts. The third privilege level that's possible is something called an owner. And owners are actually related to that functionality I showed earlier where you can add certain users as an admin and let them call into the Temi remotely without having it ring. So a Temi admin can send request. Now, sorry, let me back up a bit here. This is actually a little bit different from adding contacts because while adding a contact is pretty straightforward. Adding owners is a little more complex because the request sent by the admin from the phone app is actually quite a bit different than what the Temi expects on the receiving end. So the admin sends its request to a REST API at the following URL, as we can see here. And the request themselves have the following structure. They contain an inner request and also a signature that's basically generated using the client's private key. It's a way to identify who the origin is. And then the inner request consists the list of users, the list of users that we want to promote to owners, the ID of the robot that we're sending the request for, the source of the request, a timestamp, and then finally a type, which is simply adding an owner or removing. Now, how is this different from what the Temi expects to receive on the other end? Well, it's quite a bit different. First of all, the Temi is listening on an entirely different channel. While the admin is sending its request to a REST API, the Temi robot is listening on an MQTT topic, this one specifically. And also the structure of the request has also changed. It seems to be a subset of the request that the admin is sending, where it still has the list of owner IDs and the type, but has been stripped of its signature, its timestamp, and its source. Now, at this point we speculated that the reason for this is because the REST API itself is being used as an authentication mechanism for adding owners. This is sort of a sensitive privilege escalation type of deal. And so what the REST API would do is it verifies the request by checking the signature, and then it strips out all that verified information before sending it off to the Temi's MQTT topic. Essentially serving as like a middleman. So that means that our flowchart sort of looks like this. And presumably if the verification server deems the signature invalid, nothing happens. Okay, so these privilege levels mostly have utility in how calling works. So when a Temi receives a call from a user, if that caller is either an admin or an owner, the Temi will pick up the call automatically. On the other hand, if the caller is a contact, it'll ring. So unfortunately, as an attacker, if we just tried to cold call the Temi, we would become a contact and the Temi would ring. What do we want? Well, we want to be able to call the Temi and have it pick up automatically. This is because calling is sort of like the end game, you know, you get full control of the Temi's movement and also audio and video feeds to it. So what do we already know? And what do we already have that can help us get there? Well, we do know that the Temi uses MQTT for calling and privilege management. And we know that we can subscribe to arbitrary topics like we showed when we subscribe to someone else's call invite topic. So our next question was, can we also publish to arbitrary topics? Because if we could, we may be able to escalate our privilege by publishing the owner's message that the Temi expects to get from the authentication server directly and just publish it right to that MQTT topic it's listening on. Thereby bypassing that authentication middleman entirely. Well, this all sounds well and good, but there was a slight caveat here. And that was the Temi will only process privilege escalation requests for existing contacts. And why is this a problem? Well, there's only two ways to become a contact, one of which is the cold called the Temi, which is far from ideal because that might arouse suspicion for various reasons. If you have some stranger calling your robot. And then the other way is to have an admin send the syncs contacts message with you on it. Those are really the only two ways. Well, the solution is actually trying is that's the letter. What we can do is we can actually spoof the admin sync contacts message by simply setting the sender client ID to the admins client ID. Since the Temi just implicitly trust that this value is accurate. In this way we can send the sync contacts message first, followed by an ad owner's message, and then finally initiate the call of the robot. So this is sort of what the same functionality looks like after we've modified the app in the following ways. We can see already that it's a lot simpler. And in order to become a contact, we just send the malformed request in order to escalate to becoming an owner, we just send another malformed MQTT request. And then finally, unlike before, now that we have owner privileges, the Temi will pick up the call automatically. Now, just as a quick recap of what these vulnerabilities can do together. We have a recipe for disaster, and the recipe includes these following steps. First, you find a vulnerability in the Temi, and then you just find three more. And here's a completely unrelated graphic of a bucket with holes. I just like buckets. Now the ingredients for this recipe involved just the user's phone number and honestly not much else. And what this produces is the ability to spy on calls, the ability to intercept calls intended for other users, and most importantly, the ability to remotely control the robot and see through its eyes and hear through its ears. Now, I've been teasing you guys enough. So at this point, I think it's a good time to show you guys a demo of how this all works. So on the left, we have the Temi Admin. On the right, we have the attacker's phone. And we can see that I've already added the Admin as a phone contact, thereby syncing it to the Temi's contact list. And the first thing I'm going to do is I'm going to install the Temi app normally, unmodified, just straight from the Play Store, just to show that there's no smoke and mirrors involved. We'll later be using the modified app of the exact same credentials and going through the same registration process to show you that it really is the vulnerabilities that give us the greater privileges. So once we're done registering it, we're just going to attempt a cold call to Temi. And you can see the Temi screen in the bottom center there. Now, as expected, the Temi rings, so does not pick up automatically. This is because we only have contact privileges at this stage. The Admin hasn't granted us any special rights. Okay, now that we know what the normal operation looks like, let's go ahead and install our custom modified app that leverages these vulnerabilities. And right off the bat, you'll see this actually looks very similar to the original app. We only modified what we needed to do. It's not until we initiate a call that we'll see how different it is. So as I stated previously, we'll be using the exact same credentials to register. And in theory, we should have the same privileges. All right, now the registration's done. We'll try initiating the call again. Except this time, it says PON instead of CALL, so you know it's not working. This time, the Temi picks up the call automatically. And the attacker now has full access to the Temi's movement, its camera, and its microphone. Now the first thing an attacker might do is actually mute their microphone, and turn off their camera thereby essentially remaining anonymous as they do this. And you can start driving around whatever location it's in, or looking around at whiteboards and other sensitive information. And you can also modify its volume to annoy people. But more importantly, you can actually navigate to its various saved locations. So here we're going to navigate back to its home base just so it doesn't run out of battery. So that attack vector leveraged that last vulnerability it described, which gives us owner privileges. Let's look at how we can exploit the previous vulnerability, which had to do with intercepting calls. So first we'll begin by starting a call from the Temi for its admin. And as normal, you know, all as well as the world, the admin gets the call, but the attacker doesn't. This is expected behavior. But from the hacked app with a simple button press, we can change this entirely. By subscribing to the admin's call invite topic, now when the Temi calls it again, both the attacker and the admin will receive the call. And the attacker is free to pick up this call and gain the same control over the robot it did with the other attack. Got a couple slides to finish off. So let's talk about the vendor's response to our research. So we disclosed all four vulnerabilities to Robotemi Global LTD on March 5th. They responded very quickly, and they were very receptive to all the suggested mitigations for these vulnerabilities that we outlined in our report. But perhaps most importantly, they maintained constant communication throughout the process, working with us to mitigate the vulnerabilities. Speaking of which, all four CVEs are actually patched as of July 15th. And McAfee ATR, my team, has reviewed the patches and has confirmed that they successfully mitigate all four CVEs. Now, all code shown as a result is from the older, vulnerable versions of the APKs. In fact, the code is now heavily obfuscated and much harder to parse. And this is sort of what the gold standard we seek out in security researcher and vendor relationships, where it's a mutually beneficial thing, where the vendor responds quickly and we're able to get these things patched as soon as possible, ultimately resulting in a safer product for everyone. Now, before I let you guys go, I do want to discuss really briefly the various impact scenarios you might see used for these vulnerabilities. I think the biggest one is healthcare. There's obvious privacy concerns whenever you spy on a potential medical appointment or anything to do with health information. That's why HIPAA is such a big deal. But another potential attack vector might be using it as a sort of espionage for getting the status or location of persons of interest within a hospital. That might be something a nation-state actor might be interested in. Another attack scenario I want to have you guys think about is the enterprise one. We've already seen that these robots are being used in corporate offices. Now, this actually would grant an attacker access to certain information that simply isn't accessible from a network-based attack scenario. Things like information posted on bulletin boards, on post-its, on computers. I hope it wouldn't be a password, but who knows. Network diagrams on whiteboards and other sensitive information. And perhaps more obviously, the ability to spy on boardroom meetings. What kind of sensitive information or trade secrets could be listened through. It's not too surprising to see a teleconference robot being used in a room for teleconferencing. And if that's said, that concludes my talk. I will be a president in the Discord server to answer any questions you guys have. And thanks for tuning in.