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, to which there's really only one natural response.
And you can find me on Twitter, at Ropsicle. And I'm currently a security researcher for
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 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 in 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. Temmie or Teemee, 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. And 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
like a camera and a microphone and a fully functioning touchscreen. Now, this device
was created by RoboTemmie Global LTD, and they're sort of like a startup company. This is their
first venture into the consumer space. But they actually spun off of a parent company called
RoboTeam, which did 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, it has the ability to do remote teleconferencing, thanks to its camera and microphone.
But more importantly, it also has 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 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 RoboTaming likes to advertise their
robot as being, you know, 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 Israel's Ministry of Defense as, like, the de facto
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, RoboTemy has actually increased production of these units
to about a thousand a month, I believe, just to meet this growing demand in the medical space.
So, now that we know what Temy 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 of it look like,
so then we can have a lot of fun breaking that box. So, to start off, normal operation of the Temy
is done through a use of its smartphone app, and this is both on Android and iOS.
So, you can call the Temy from it, you remotely control it that way, that sort of thing. And the
registration process for using this app is, basically, you 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 unboxing 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 Temy robot. And the admin is only one per Temy,
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 use the Temy app, so phone contacts in, like, your smartphone,
if they have the Temy app installed, they're synced automatically. And this can be done
one of two ways. If the admin has phone contacts that have the Temy 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, you don't own a Temy,
but you have a friend that does, for example, and they're in your phone contacts list,
you'll be able to call your friend's Temy 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 Temy, 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 Temy. And by selecting this contact,
you can see the Temy 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 Temy, 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 Temy 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 the admins can actually
grant certain users in their contacts list special privileges to bypass this limitation.
So if you have like a family that all uses 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. Now, although
this tech is pretty novel and cutting edge in a lot of ways, the approach we took to ReconnaSense
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 was actually capture
traffic on the device using Wireshark. 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... sorry, not ADB, that's a little later. We ran an Nmap port scan on the device
to see what the 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 Nmap classified as
being used for the service Feros, 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 443 you'd see used for HTTPS. Now, to verify that, we actually used the ADB shell we
had to the device to run Netstat, and actually found that the service associated with this port
is something called com-roboteam-teamy-usa, which looks a lot more like an Android application than
it does, you know, 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, you know, 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, you might
ask, why? Well, a great man once said, the road to exploitation is paved with months of staring
a 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 a 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 in a full Android app, but they have massive code bases frequently,
and Temi was no exception. Instead of 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 Lib
Agora. 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 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 70. And we can see here that it's categorized as being a use of hard-coded
credentials. And it's 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.
Just by looking through the Agora documentation for their video calling API, we were able to get
80% of the way to finding 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 and 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
we'll 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 rtcengine.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 namespace 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
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 and fairly trivial to decompile.
So this was 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
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 they extracted from downloading the app,
which is shared amongst all Temmie 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 Temmie call used by any Temmie 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 Temmie 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 Temmie 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 Temmie 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 Temmie
Android app already has access to all those remote services, which requires some degree of authentication.
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
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 grepping. 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 Pwn, 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 it 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 the discussion for that.
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 so we're all on the same page. So MQTT is a publish-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 its call
invite topic. After all, we are interested first and foremost in the calling functionality.
This is just the 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 string itself takes
the form client something followed by invite. And that 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 a way to identify different users.
So this actually gave us an idea. 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. It invokes a function called telepresence
service dot initiate call. 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 get MD5 phone number. 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 Temi's privilege management system,
which is something I've already sort of touched on with the admin versus regular contacts 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 contacts 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.
They're the same thing. For requests from the admin to sync contacts, as we can see here.
Now, the requests themselves have the following structure.
They're called... 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... 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 requests 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 of the list of the 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 a 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 the endgame. 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 subscribed 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. Now, why is this a problem? Well, there's only two ways to become
a contact, one of which is the cold call to 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 sync's contacts message with you on it. Those are really the only
two ways. Well, the solution is actually trying... is that's the latter. What we can do is we can
actually spoof the admin's sync contacts message by simply setting the sender client ID to the
admin's client ID, since the Temi just implicitly trusts that this value is accurate. In this way,
we can send a sync contacts message first, followed by an add 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 a 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,
it's sort of 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.
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, Shane or Sam, if you guys could queue up the video. Hopefully.
Demo is playing.
Okay. So, on the left, we have the Temi admin. And 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
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 with the exact
same credentials and going through the same registration process to show you that it
really is the vulnerabilities that gives us the greater privileges.
So, once we're done registering it, we're just going to attempt to cold call the Temi.
And you can see the Temi screen in the bottom center there.
Now, as expected, the Temi rings. It 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 is done, we'll try initiating the call again.
Except this time, it says Pwn instead of Call, so you know it's going to work.
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 the microphone, their microphone,
I mean, and turn off their camera, thereby essentially remaining anonymous as they do this.
And you can start driving around whatever location it's in, looking around at whiteboards
and other sensitive information. And you can also, you know, modify its volume to annoy people.
But more importantly, you can actually navigate to its various save 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's well with the world,
the admin gets the call, but the attacker doesn't. This is expected behavior.
But from the HackDAF, 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
and gain the same control over the robot it did with the other attack vector.
All right, that concludes the demo. 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 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, you know, 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, you know, 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, you know, this actually would grant an attacker access to certain
information that simply isn't accessible from a network-based attack scenario. Things like, you
know, 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? And it's
not too surprising to see a teleconference robot being used in a room for teleconferencing.
And with that said, that concludes my talk. I will be present in the Discord server to
answer any questions you guys have. And thanks for tuning in.