Daryl Hyland from Rapid7 and he's presenting his talk called
Internet of Vulnerabilities. So take it away. Thank you. Thank
you. How's everyone doing? Outstanding. So again my name is
Daryl Hyland. I'm the research lead for IoT technology at
Rapid7. And hopefully you guys will enjoy this presentation and
I'll be around after the presentation and clear until
Monday. So kind of grab me and we can grab a drink and have
some discussions. I'm always open to feedback. Stuff you're
working on and we can talk about stuff I'm working on that hasn't
been published yet. But not all the details. So it's kind of fun
and this is generally a presentation on some of the work
that I've done over the last 12, 14 months or something like
this. So some smaller items, kind of more of the junk hacking
but kind of looked at it from a, you know, what kind of privacy
issues maybe exist all the way up to enterprise level
technology. So it should be kind of fun. So from a
perspective of IoT research, when I came over at Rapid7 and
took over the position as the research lead, one of the first
questions I was asked was, now you're a research lead, what the
hell is IoT? And I said, well, I'm a research leader. So what's
IoT? And I think you all realize, you know, trying to
define a definition of what IoT is is very difficult. So instead
of doing that approach, I kind of tried to hit the 80-20 type
thing, but kind of frame it around how do we approach
looking at the security of IoT technology. And I kind of use
this model here. It's made up of three general pieces. You know,
we always have the, you know, the hardware aspect of IoT,
which is we're all into hacking the hardware. But the
hardware aspect is, you know, we're all into hacking the
hardware. But the hardware is only one small piece of the
overall puzzle. And some of the other pieces we often run into
are mobile, the mobile application aspects that
interface with this technology. The cloud services, cloud APIs.
So the ultimate goal was, as the research lead and as I drive
research and IoT testing within Rapid7 was, well, let's approach
this from an ecosystem, a full ecosystem of an IoT product. That
way we can examine the impact of one aspect of that ecosystem and
the other. What's the impact of hardware vulnerabilities to cloud
information, cloud data, cloud APIs? What's the impact of mobile
applications on the hardware or on the cloud APIs? And vice versa
across this. And that way, any time I approach a technology, I
look at the entire ecosystem, all the pieces. So in this talk,
we're going to, a lot of it's going to be covered. It's going
to be some of the outline pieces. It's not all going to be
hardware. We're going to talk about web, web API vulnerability
issues that are part of the product line. And we're going to
look at mobile application vulnerabilities. Generally the
most common one that they seem to find on everyone, which is
definitely one to get it fixed. Let's kind of, coming out of
that, we kind of build a methodology for approaching IoT
testing. And it covers these general areas, you know,
functional evaluation all the way down to examining the radio
RF. And the goal is to dive into each one of these in detail
across that ecosystem. If you do that, you're going to get a more
realistic view of the security of that technology, which makes it
all that much easier to actually get the technology fixed, which is
what we're all about. We're not, it's not about vulnerabilities.
It's about fixing the issues. So let's kind of move forward on
this and start talking about some of the IoT hacking. So what we're
going to talk about today is some vulnerability issues we found
around automated lighting solutions. We're going to talk
about BLE trackling dongos. And actually, I think this is a
really interesting story. So if you're actually using one back
here as part of the contest, it's actually, I believe, one of the
tracker, tracker are bravos. So we'll be talking about that one
specifically because it was like, had some serious problems,
especially with the cloud APIs. We're going to talk about
telepresence robots. I don't know if you've ever seen those
crazy freaking robots. It's like an iPad on a Segway. So we're
going to talk about issues discovered there. And then we're
also going to talk about a GPS panic button. And this one has a
really interesting story around it. So we're going to talk about
it. I think you guys will find maybe not funny, but at least
entertaining. So let's kind of move forward. So looking at
automated lighting solutions, and what we looked at was the
Sylvania products, the Lightify products. And there's two pieces
of the Lightify products. There is the home user modules, which
we have one here kind of all gutted out. And there was the
enterprise version. This is what's used in businesses,
organizations that can use to manage lighting within a
building. And then there's the enterprise version. This is
what we found. Things we found, you know, the common, unencrypted
storage of information, poor encryption in the communication,
unauthenticated controls, and embedded web bones. Remember, a
lot of this technology, especially as you move into the
enterprise stuff, all have web servers. And those web servers
are wrought with issues. So let's go ahead and start off. We'll
start off with, starting out with, I manned up and set up the
home Lightify system. And started with the home Lightify system.
And started looking at the mobile applications. And the
first thing I found was the WPA pre-shared keys actually stored
unencrypted on the device, whether it was an Android or IOT.
It was stored unencrypted. The crazy thing is, is this didn't
need to be stored there after the system was set up. But it
continued to store it there. You could log out. You could do
whatever you wanted to do. Reboot the device. And still,
this data was in there. And, you know, how often do we lose our,
like, phones? I guess if you're on IOS, it's a little more, a
little more security built in that. But if you're on Android,
oh, what security, okay? So, you know, you think about it. This
is a common vulnerability. I find this over and over and over
on probably 80% of the products I look at. I'm finding user
IDs, tokens, pre-shared keys, all the information
stored right there on the device, giving you the ability
to do anything from taking over the device, taking over the
home wireless to actually taking over all the cloud APIs and
controlling a person's entire home in some cases. And this is
definitely something we need to get fixed. So, so my goal is, is
if you're out there doing IoT research, look at this stuff.
Look at the mobile applications. Try to identify this stuff and
report it out there. I've already reported, you know, a
systemic issue across all the products. Now we need to get it
fixed. Because this is insane. There's solutions to prevent
this type of stuff. Moving from there, we started looking at the
home enterprise devices and how they have their use cases. And,
you know, I think the key to this is that we need a user name
and passwords for the Wi-Fi. So these devices often, when they
fire up, have a Wi-Fi solution that's actually available. You
connect to it. It's often used to configure the device. So we
started looking at that those defaults for that particular
device, their SSID and the WPA pre-shared keys that are
associated with the configuration of these devices
and go, well, how secure are these? So we jump over here on
the, this is the home, this is the home product, okay, right
here. And we can see it's 8 characters, alpha numeric, or 10
There's African American, upper, lower case.
Not perfect, but in reality, not that bad.
So I get the enterprise product, and I start looking at it.
Now, the big thing with the enterprise product is it actually has Ethernet on it.
It has Wi-Fi, so you can get access to it to Wi-Fi.
And then it can also integrate to your building or your internal Wi-Fi system.
So it has multiple ways for communication,
and literally all of them can function at the same time
based on how the device is configured.
So when we started looking at the actual WPA pre-shared key on this device here,
we noticed that it was only eight characters,
but I couldn't figure out, you know, is it alphanumeric, upper, lower case,
and all that type of stuff.
So I had them send me a second device.
Once I got the second device, the answer become clear.
It's actually hex, A through F, 0 through 9, eight characters only.
So instantly, we set this thing up like it was in an enterprise.
We hooked it on the Ethernet.
It's Wi-Fi came up running.
You could connect the management console into the Wi-Fi or the Ethernet.
But if you're connected through the Wi-Fi, a typical WPA pre-shared key attack.
You kick them off, they rejoin, you capture the data.
And apparently I don't have that slide in there anymore.
But the crack was using a really shitty GPU.
We cracked that in less, right around two hours.
So instantly, a device in an enterprise, not configured,
not shutting that stuff off, which may be very common,
using really bad pre-shared key, key space,
we quickly cracked this in two hours or less,
given an attacker to be able to gain access to an internal network fairly quickly.
So also, this device happened to have a web server.
We found a couple vulnerabilities on there.
So the first one was when I was logging onto the device,
I'm going down through the list,
and I go, security logs.
I always like something when it says security logs.
That's always the greatest thing.
So I go into the security logs,
and I notice it showed the username of my logon.
So I came back out and tried logging on with a bogus name,
went back into logs, and it had that name in there.
So I thought, oh, what the hell?
Cross-site scripting, persistent, in the security logs.
So I gave it a little present of a laughing skull.
So.
So also on the web server, we found some issues
in the configuration page, the management configuration page,
for the actual Wi-Fi setup.
And I don't know,
if you, when you're looking at a Wi-Fi configuration page,
and you see this page, what do you think?
I often ask this, well, what's the first thing
that goes through your head?
The first thing that goes through my head,
it's another injection point for actually injecting cross-site
scripting into a management console on a system.
But it's an out-of-band, which we often don't look at.
Because we're, you know, don't people don't think,
an SSID can be built, the SSID name can be built
to contain Java code.
It can be configured to make calls out to a server
and pull down Java code.
So I have a quick video here, a little bit for entertainment.
So I actually spoke at,
at Black Hat in 2013, and I presented a paper
on attacking embedded devices via SSIDs.
I don't know how well it's easy to see this, but.
So we come over here, and we go to the Wi-Fi configuration,
and we quickly see that,
that we can actually see the Wi-Fi access points
in close proximity.
So we just basically set up our little, own special SSID,
which is always fun.
So a soft access point, we fire it up,
so we can check to see what does the application do
when it interacts with a Wi-Fi injection.
.
.
.
So I've used this attack a number of times over the years.
So something to consider when you're engaged in this,
don't always think about just cross site scripting.
If you go back and look at the paper I published here
on this particular attack vector,
we actually found format string attacks
via this vector also.
So there's a number of things you can carry out
via SSIDs against embedded technologies
that contain web services.
So a number of the one of the things,
something to consider anytime you're testing
any kind of IoT technology,
you're used to testing it in all the normal conditions.
Well we also get to contest it
in what's considered abnormal conditions.
How does the equipment affect or act
when it loses access to its cloud APIs?
Often the technology, especially home automation,
will go into a local control mode.
Local control mode means there's gonna be
some kind of service exposed locally,
giving it the ability to connect to that device.
Often that is not authenticated or encrypted data.
And with that in mind,
it's the same way in this case.
It actually had port 4000 open.
So we're able to capture all the communication
and decode it and figure out how to control the device.
Now I do have a demo here and I'm not sure
how the whole Wi-Fi stuff's gonna work in here,
so it's liable to go to hell in a hand basket.
But either way, we can talk through it if it fails.
So a little bit of camera here.
So we have a device right here.
And I'm gonna go ahead and plug that in.
Let's see if we can get another,
see if we can double a couple screens up here.
So this will be a little difficult,
but let me see if we can do this.
So a couple interesting things you're gonna see here.
So you see the stuff in the background.
I want you to be able to see the bulb,
things start up.
Okay, cannot, let's fix that.
Okay.
Demo gods, man.
or my device died, one of the two. Well, we'll give it one more try and then we'll start to
verbalize it through it.
Well, unfortunately, apparently my Shikra just died. Life's a bitch, ain't it?
Let's see if this is the right one. Okay. So unfortunately, we can't do that live. What
I was hoping to do was show the one command, actually being able to make the device jump from
one access point to another access point with a command. So it was unauthenticated. But if you
watch this screen, there's a couple of interesting things to point out. This is the UART connection
on the device. So in this case, we don't get a full command shell. We get a small subset of
commands. But if you watch clearly, I'm hoping it will come up. It may not. But you'll see,
there it goes. Don't miss it.
Password, device key, product key. It's actually calling out to China. So it's going out to China
and connecting up. Looking at the data and what was being transferred, my best determination,
which was a good one, was that it was connecting out for validating firmwares. The particular
company that produces the underlying hardware here actually seems to be one of the better ones
I've seen so far from the China perspective. And I couldn't determine it doing anything else.
And couldn't figure out if they were doing anything else. It all seemed to be purely testing and
validating firmwares. So if your firmware was out of date, then it would send commands back via
those APIs to communicate to you to be able to upgrade your systems. So it would flag your system
and you'd start getting alerts to actually upgrade the firmware. And that was determined based on
that information there. But you can see there's a couple subsets. You can identify various ports and
stuff that are actually open on the network. And I'm happy to say that the most likely way to get a
the device. So looking at the hardware to be able to get
access, I mean, any time you open up a piece of hardware, if
you're anything like me, the first thing you look for is where
can I connect in and start looking at it. So we find these
small pads and these are .1 millimeter pitch pads. If you're
an old man like me, trying to solder those are a total bitch.
So you can see how big the connector pins are. It's like I
can't even see that good. So we got them soldered in pretty good
and like I tell everyone, I cheat. I use a microscope, which
works really good. And again, we can tap into those. So we step
back here. This one happened to be, in this case right here,
goes to the main processor on the device and would give us the
UART log dump, as we were seeing there. So we're going to
see what was going on. So you could do various things like if
my card hadn't failed on me for some reason, you'd be able to
actually see the device connect out to the Internet, to the
cloud, get the connection. You would also see how it handled
the command, incoming command, unauthenticated over port 4,000
and try to drop off that one and try to connect out to a third
party or to a different access point for control. So that's
pretty cool. And there's the whole rig with the Sheikra that
apparently just died. I actually have a couple spares, but we'll
see if time, time I can probably swap out. But we'll see. Let's
get through the presentation first and see if anyone has any
questions, because I could easily show this to you offline.
So the next one is the telepresence robot. And these
things are truly freaky if you've ever seen them running
around. Has anyone ever seen these running around in offices?
Yeah, it's pretty, pretty wild, you know. So I met a college professor at a university, and he said,
the first thing he asked me was, Daryl, have you ever seen these
new telepresence robots? So he starts telling me about it. He
says, well, I have one, but it wasn't the full one. He had the
desktop version. So he let me play around with it online and
see how it all worked. So I was talking to some people at Rapid
7 and going, you know, it would be really cool to look at these
things. And someone goes, you know, we like have two or three
of these in the Cambridge office. So instantly I start prodding
people. And they packed one up and shipped it to my house, which
was totally cool. So I got to play with it, run it around the
house. I wrecked it. First time I fired it up, it spun around and
run across my office. It hit a wall and then wrecked. Luckily I
didn't destroy it. I'm thinking, oh, shit, I'm going to send this
thing back in a paper bag. But luckily I sent it back fully
functional. So in the case here, we had a couple things. The point,
the first point is, I didn't cut it open, okay? I, I sat and spent
like three hours trying to figure out how to disassemble this thing.
How to safely do it without pulling the rotating wheels on
it to gain access to the locking bolts. And the last thing I
wanted to do was basically send back in a paper bag a $3,500
product that was actually being used by certain people in the
company. So I didn't really focus on digging into the
hardware and tearing it apart to see what I can get. But I did
look at some other things. I looked at the cloud APIs, the
communication. I looked at whether it handled Bluetooth
pairing properly, those type of things. So I looked at the
first thing. Started looking at the API. Man in the middle, the
connectivity from the head to the cloud. And started looking at
how this thing was communicating. And I instantly found out that
the APIs had no freaking authentication to them. Several
of them, no authentication. So you take this URL right here, and
it has this offset. If I set the offset at some astronomical
number, it would error message back to me. And so that's
invalid. The highest number is this.
So the first thing I did was, you know, I threw that higher
number in there. And I didn't know what the limit was. So I
set it at like 200 or 300. Just curious to see what would come
back. Thinking it would be my data and my data only. No, it
wasn't. It was all data. It was data for every robot that was
functioning that day. This particular data here is live
tracking data of session communication as it happens. On
the particular device. It's all recorded into a database. So
instantly I step back. You know, there's a whole ethical issue at
that point. I'm seeing other people's data. Step back. Had the
right legal conversations. We figured out how to appropriately
narrow it down so I can only look at my data and try to focus
on that. Because that's what we're after. We don't want other
people's data. We want to be able to look at our data and
consider the overall security of it. But if you set this offset
at one and set the limit at a million, you're going to have to
pull down all of the data for every robot since the thing was
put into place. For every robot on the face of the earth. And we
get the session data. The session data wouldn't give me the
ability to take full control because there was two
communication paths. One of them was encrypted and pinned
properly. And I couldn't break the pinning. I don't know what
they were doing weird. But I couldn't get in the middle. It
kept failing and causing the robot to fail. And so that was
the case. So looking at another AP, I'm going to look at the
API here. Very similar. That offset. You can set the number.
This was for every registered robot out there. And it would
return back installation key. But it also returned GPS
coordinates, the name of the device. So literally you could
dump all the data, gain access, GPS coordinates for every robot
that was issued in place functioning on the face of the
earth. The third item that I started to look at was dealing
with what's known as the robot key.
This is the key to the kingdom. This one was a little more
secure. You had to be able to be local enough to man in the
middle of the device, okay? But it turned out that once you
accomplished that, what the robot would do, would send out a
robot key information to the cloud, post it to the cloud. The
cloud would return to you the user name. Now, to start off
with, to make the robot function, the only thing that had
to be returned was the user name. Because it wouldn't
get into a menu system where you can say how many users and add
more users. So the only thing needed was the user name to be
returned. But when you put in the robot key, it returned
driver tokens. Driver tokens are nothing but session tokens
that are assigned to somebody forever. So that means they, if
they load the application on their laptop to be able to
control the robot, they would connect out there. And when
they logged in, this session token, or driver token, would
use for them to remote control the robot. So when you put this
thing out there, robot key to the cloud, no authentication, it
will return all the users and all the robot control keys for
every user. Basically meaning that you could become anybody.
So what I did here was out of curiosity, you know, like, okay,
how can I mimic this? So if I did this, let's say I got the
robot key, I go off over here, I post the robot key, it gives me
the list. I put the application in there, and then I put the
application on my machine. I log on out there, create myself a
count. It would give me an account with no control of a
robot. I would go into my session tokens, drop one of
these in there, and all the robots would show up. At that
point, giving me full control of the robots. So yes, a seriously
bad problem. Again, the customers were very receptive,
the vendor was very receptive to this, and we got these problems
fixed quickly. Now, which is always a plus.
So the next one we want to look at is the BLE dongles. Now, I
looked at, I looked at like four or five of these, you know, the
tile, this one, there's one called Nut, there was another one I was
looking at at that time. And I was curious, and this was driven
very much by the fact that I was seeing these people carrying these
around on their keychains all the time. Every time you turned
around, it's like, oh, they had this weird dongle, whether it was a
silver or a blue one or whatever the brand was. And I started thinking,
what kind of issues would be here? Obviously, I would consider
more of a privacy issue. So it was like unauthenticated access was
identified, weak BLE pairing, which is another common
vulnerability we encounter, information leakage, and
insecure cloud APIs. So what we want to do is actually have one
here. So my goal is, let's see if we can look at this and see, I'm
surprised no one's hacked me yet. So apparently they're not doing
anything good back there.
Let's see what we can do on these. Okay. No devices. There's no
devices because I plugged it in to plug this in. What's that? I can't
hear you. Oh, I'm sorry. Yeah, the purpose of the dongle,
uh, is to be able to find your keys when you lose them. Uh, and the
interesting thing with these devices, they use this thing called
crowd GPSing. And the way that works is when you purchase one of
these things and you set up the application on your phone, if you
lose, if you lose your device and you happen to lose it in the city
park, how the hell you find it? Uh, the way you find it is you look on
your phone and what it'll do is if anyone else running that
application passes within proximity of this, it's going to be able to
send the GPS data out to the cloud showing you where you actually lost
your device, taking advantage of everybody using the same product. And
that's how most of them work.
Not sure how well this will work on the screen here, but we'll see. So,
um,
first thing I want to do is turn Bluetooth on, which may be a mistake.
And so we're going to see a shitload of stuff show up here. All the
people that are either futzing with us are too stupid to turn their
devices off. So, the first thing I want to do is, uh, I'm going to
have this device here and we're going to jump over to another screen now that
that's turned on. Now, I don't know if anyone's ever used NRF Connect. Why
are you doing this? Been installed before?
Shit. What was there was? I didn't see it. Ah, thank you. My hand was over
top of it. So, let's do a scan. And this is going to detect Bluetooth low
energy, which is what this device is using. Let's flush this old data out of
here. So, we can see, uh, you can see all the people at DEF CON that didn't bother to turn the
off Bluetooth low energy. And the shit list goes on and on and on. So, let's see of my device
shows up, and see if I can find it in here.
So, this is the fear anytime you do these in large audiences and and music uh, they
Fuckin' piece of shit.
Let's try again.
There's a tile. You can see the tile. That's one of mine.
Okay.
Let's see.
Okay.
Well, the demo gods are being a total bitch today.
Because I don't even see the device back there.
Okay.
Let's see.
You got time.
Well, we're gonna jump on to something else.
Weston, can you jump up here?
Change the battery out on this.
There's some batteries right there in the top.
And there's a little black hole.
Yeah, it should be right there in the top.
In the case there, there's batteries.
So let's go ahead and move on from here.
Come back to that.
Check to see if it's a battery issue.
So what I was gonna show, maybe we're gonna show it at the end.
So basically, when we fire this device up,
so you understand the risk,
is we can actually see the device out there.
Obviously with Bluetooth low energy.
But in a crowd like this, I wouldn't know who was using that device.
But if we look at the actual device,
the device has a couple things.
It has a tracker ID.
The tracker ID is the company identifier.
It's like at four digit, 0000, whatever it is.
And the MAC address is backwards.
So that's the device identifier on this particular device.
Also, it doesn't have Bluetooth, BLE pairing properly.
So I can pair with the device and set the alarm off remotely.
So if you're in an audience and you identify someone using
one of these tracker devices, Bravo devices,
you can set the alarm off,
and now you know who the person is.
Because you look for that poor soul trying not to look stupid
as they try to figure out why their damn dongle is buzzing
and making a loud noise.
To go beyond that, we move from there
and started looking at the cloud APIs.
And it turned out that if we go out to the cloud API,
unauthenticated, and pass that identifier out there,
we could get GPS coordinates of the user.
So now, not only can I identify who's in the audience
with one of those devices,
I can proceed to track them at this point wherever they go.
I don't know about you, but to me,
that's somewhat of a serious issue.
Now again, I've had this conversation with media
and stuff like that.
We also got to put some kind of true risk behind it.
If you're most of us and you have this device,
that risk would not be that big.
Who wants to track me?
So it only becomes an issue if you're somebody important.
You're a politician, a movie star, something like that.
Then it probably would have been a really bad idea.
Or you have somebody that's a known stalker.
Then it becomes more of an issue.
But generally, I don't consider it the most critical issue,
but something that needs to be resolved.
The vendor quickly resolved this issue right here.
Now you have to be authenticated to be able to gain access to that.
You can't read that particular data.
I actually think in this case here,
they took that particular access to that API functionality
out of the system, so it is no longer viewable.
So you changed the battery on it?
Yeah.
Okay.
We'll look for it one more time.
If it's not there, then there it is.
So we can pair with the device.
A lot of times, these type of connectivities and communications
get messed up just based on the amount of Wi-Fi that's in the air.
So, I mean, it's still trying to pair with the device.
So you go to a quiet room, this works every time.
I'm surprised any of this technology works with as many devices
that are out there with all the noise.
So that's thinking about pairing with it.
So we're going to actually move on.
So the next device, this is a panic button, okay?
So the story goes, actual Associated Press came to us and goes,
the Colombian government, South America,
has recommended that we purchase these,
these batteries for protection from being kidnapped, okay?
And we really wonder, is this a good solution?
Is this a secure solution for moving forward?
So very interesting project.
So it's like, let's go ahead and take a look at it and see what's there.
I mean, we found a number of issues, literally just a poor design,
non-SSL communication, some balance check problems within the functionality,
and some real-time web server failures.
So let's look at this.
Let's start with the first total failure of the product.
I didn't even have to open it up, I just opened up the manual.
So we opened up the manual and we found out this thing,
the way this device works, it's configured and controlled via SMS messages.
So you can set a password on this device, a pass pin number,
that would add some level of security against the device
from someone able to get your GPS coordinates and mess with the device,
except for one command.
There's one command you do not have to have,
a passcode to gain access once it's configured.
Guess which one?
It's the reset command.
Reset the device back to factory level.
So basically, you press the button, it ain't calling nobody.
And I can still send an SMS message to you because now there's no password,
and it's going to send back to me your GPS coordinates.
Now if I'm in fear of being kidnapped, that just went to hell in a handbasket real quick.
So that was a vulnerability before we even opened the device up.
One other command they said didn't need a password was reboot.
That was not true.
Reboot would not work unless the passcode was actually put on the device.
But we did find some use for a version of the reboot.
Well, it turned out that this particular command,
reboot all capital, explanation point, was an undocumented command.
We pulled the firmware off the device and I went through the firmware,
and that's where I found that out.
The interesting thing with that was, well, anything,
anytime you send an SMS message to this thing and there is a password set on it,
you get no results back.
So my theory was, is there any way to war dial this thing,
war SMS message this thing?
So we found out with the reboot, it would return a format error.
So instantly, if I know all the reporters probably bought their phone from this location
and they're in this city here, and I wanted to gain access to the device
or figure out who had devices,
how hard would it be just to basically send an SMS message to every one of the phones
and then wait for the response back?
And if I receive a format error response back,
the odds are pretty high it's going to be one of these devices,
giving us the ability to basically do kind of a war dial type of tack on the device.
Moving from there, we also found some bounds check issues.
Didn't find any.
We found an effective way to exploit these,
but it was still something to make note of.
It turns out when you set up a command, when you set up the phone numbers,
there's three phone numbers you can set up on this device.
And you use A and then the phone number, B and the phone number,
and then C and the phone number.
We found out that if you actually put more characters than what's in the phone number,
it would actually overwrite a segment of the configuration on the actual flash device.
Now, I didn't do this to all of the commands.
The first time I did this, I did it to one command
and basically had to reboot the device like a dozen times
and then send a reset message to it to get it to even freaking work right properly after that.
So I never did quite figure out what I overwrote,
but apparently I overwrote something I shouldn't have.
But as an example, you can see here,
we send this command to set up the SMS message to set up the first phone number,
and we end up overwriting the second one, B,
and you see all the A's show up in B,
showing we're able to overwrite that.
Now, there's a whole bunch of commands,
and I went into the flash and I mapped out the structure on the flash
trying to find out if there was a possible way to overwrite some of the code.
And I didn't initially find that, so I don't think there was.
It was getting pretty close to it in the flash to overwrite the actual firmware,
but it didn't quite hit it.
The other thing was, and this was the actual web services,
and this was like totally bad.
So without any authentication, you can actually punch in the user IDs,
and this would return the phone's EMEI number,
which you could use later on to take over the device via the web application.
So all you had to do was start at 1
and increment up over the 66,
70, 80,000,
and basically gain access to all the identifier numbers for the actual devices.
Another attack we were actually able to do using that EMEI number
is you could actually poison the GPS data online.
So literally once you got that EMEI number,
you could make the device look like it was anywhere else on the face of the earth you want.
So of course I did.
So I live in Dayton, Ohio,
and instantly my device decided it was going to jump to Moscow.
So we were actually able to poison it.
And that went over, I'm trying to think of the port it went over,
2050 I think was the port that was actually open,
completely open in the cloud,
sent all the data you want to it.
Another potential attack point,
you know, what happens if I decide to send a number that's 40,000 characters long?
I did not own the web server,
nor was I doing vulnerability testing for the web server.
So in that case I was only able to focus on my particular data
and the impact on my data.
But again, you're able to actually gain a level of access to that data,
which I thought was pretty cool.
So let's check over here and see if the tracker device paired.
And it did not.
Okay.
It says it's pairing now.
Okay, that time it paired.
Apparently it didn't like me clicking on it last time.
No, wrong one.
So we actually were able to pair with the device.
Now let's see if we're lucky enough to actually find it out there in NRF Connect.
Okay, here it is.
Okay, so now we can see there's a number of services on this particular device.
And we can come down here and based on the previous screen,
or you can see it at the top, unfortunately you can't,
you can see the identifier.
So we'll drop back to the other screen.
From here you can easily just jump on alert, go alert,
select it to high alert.
Let's see if this demo fails like hell, Tim.
I hope you can hear that.
It's kind of high frequency.
So you can see without any level of authentication,
we can pair to the device that somebody's carrying.
And we can do, generally what's taking place is a DOS.
This battery ain't going to last long with it screaming like this.
And I assure you the person's going to be digging through their stuff.
This room's a little noisy.
But in most places, coffee shops, they're actually going to notice this fairly quick.
There, turn the alarm off.
So let's come back here.
Okay, if we come down here to this device, let me see.
Ours is already there.
Don't do that.
Okay.
So we can quickly see in here, well, I can see.
I'm not sure if you can.
I was hoping to have bigger screens.
But we can see the tracker ID here.
So we have the four digits, 000, company identifier.
And then we have this identifier here.
And this is the MAC address.
So if you just reverse the MAC address, you have the tracker identifier.
And it gave us the ability to, at that point, once we have identified somebody with the device,
to continue tracking them as long as they own that device.
And at bare minimum, you're going to be able to track them to their home if you want to know where they're living.
So a serious breach of privacy.
A potential serious breach of privacy.
Which I think is pretty serious.
And I think this is closing in on the end of the presentation.
There's my contact information.
Please reach out to me.
I'm always working on new stuff.
I'm always looking for feedback, knowledge.
You know, I think in this field, we're all kind of expanding and growing and learning new stuff.
I've been doing some really cool stuff lately.
Had some cool stuff coming out.
Probably in the next couple months.
I would say super great.
But some interesting, again, similar findings that really impact the overall security of some of these products.
Also some RF stuff we're messing with.
And been doing a lot of stuff with actually data recovery off IoT devices.
From being able to go in and pull the right chips and the right equipment and reading chips.
And doing some BGA.
And working on some BGA reballing techniques right now.
Which is kind of exciting.
Because every time I tear a device apart, the last thing I want to do is throw it in a dumpster.
I want to rebuild it.
And so far I'm pretty good at taking a device completely apart.
Pulling the chip.
Pulling what I need.
And putting the devices back into place.
But that's kind of the stuff I'm working on.
Always looking for new ideas.
New friends.
So any questions?
I guess not.
Well, I'll be around.
Please feel free to grab me if you have any questions.
You want to talk.
Again, thanks to the demo gods and my card dying on me.