So we're coming down to the end. We haven't had any kind of internet of things talks in this
track before so I'm kind of excited to hear about this. Uh we're going to hear about um
speedometers. Right? We're going to talk about speedometers and things that you can put
onto your put on put onto your bike. This is going to be really cool. Um let's give the
speaker give our next speaker a big round of applause.
Hi everybody. Uh thank you for being here on a Sunday afternoon. Uh I'm Toma. I'm from
Hungary and I work for a small IT security company as a pen tester developer. The company
called PR Audit. Uh I'm a regular speaker at uh Hacktivity, Central Europe's biggest
hacker convention. And I also gave a talk uh uh about uh security and security and security
about uh insecure game scripting engines last year here at DEF CON. So the title of my talk
is Help I've Got Ants. What are we doing with ants? Uh last year I've targeted one of my
hobbies uh flight simulators so I thought it would be appropriate to uh target one of my other
hobbies this year, mountain biking. And uh sorry uh and uh while creating this slide I've just
told you is that all of my hobbies includes crashing. Ha ha so. Mountain
biking, computer security, flight simulators and recently drones. There's a lot of
crashing yet. I don't know about this. Ha. Okay, so. So mountain biking and ants uh what
does what what do ants have to do with mountain biking? Uh there's a lots of uh uh address. There's
uh lots of equipment involved in sports involved in mountain biking and ants. Uh yeah and uh this is an
�
cycling in general. And uh old school speedometers got replaced by powerful very powerful
computers. Computers that talk to various sensors uh like speed sensors, uh power meters,
heart rate monitors, et cetera, et cetera. And also uh talk to uh mobile phones or even your
PC. And here is where Ant came in the picture because uh Ant is a protocol uh that these
devices speak. Uh it is not just used by uh sports equipment but uh weight scales, blood
blood pressure monitors or um there are even there is even a chat application that uses it to
create mesh network on Android. It's called FireChat. So in this talk uh I will uh introduce
you to Ant, Ant Plus and the AntFS protocols and I'll show you some of the features that
they have. So Ant should be used for this type of system uh protocol level design errors
and uh after that some implementation errors in various garmin devices. So uh Ant. Ant is
a wireless protocol created by Dynastream and uh it is designed for low powered devices.
Uh you can create uh any kind of network topologies and the participants are called
notes. There are slave and master notes uh and these notes are uh it's a device it's
com- communicating via uh mutually established channels.
Uh channels are um defined by lots and lots of uh properties
like uh frequency uh or um the channel ID but the most
important for us uh from a security standpoint is the
network ID because it contains an 8 byte uh long number called
network key which according to Dynastream is a security measure.
It's a security measure because uh only nodes with the same
network key can communicate with each other. It sounds good but
there are some problems. Uh network keys are managed uh by
Dynastream and if you want your uh want a network key for
yourself then you have to uh purchase one from Dynastream. Uh
and if you use an invalid networks uh network key uh then
the protocol stack will just default to the public key which
is uh public. You can download it from uh Dynastream's uh
webpage. There's another problem with the network key uh it is
being that uh the majority of devices that use Ant actually
use uh Ant plus or AntFS and uh these two protocols have
their own uh network key uh and these network keys are also
public. They can also be downloaded from Dynastream. So
it's uh not much uh security measure because everybody
everybody knows those keys. Okay other security measures in
Ant. There's a pairing bit. Uh it works like this. Two nodes
can communicate with each other only if the pairing bit uh is
the same for the two nodes. So if you have a network key and
it does not have to be on it just have to be the same on on
two nodes. Uh this is fairly easy to circumvent because you
can open two channels. One with the pairing bit off and the
other with the pairing bit on and one of these channels will
succeed. I have first uh noticed that there's something uh fishy
with this uh pairing bit when I came home from a mountain bike
trip and realized that that uh there are some heart rate uh uh
data on my charts uh despite I don't have a heart rate monitor
so it must have picked up picked it up from another cyclist or or
something like that. Okay I'm gonna show you how easy it is to
spoof uh Ant sensor data. I'm just gonna uh set up my uh
Friton XT to use a power meter and I'm gonna use uh uh my uh
Simulant Plus which is a software released by DynaStream to simulate
a power sensor. Just creating the power sensor. Setting the sensor
uh data value that it will transmit. Turn it on and the watch
should just pick up that signal and display uh that's why you and
yeah it did. So uh what I'm gonna do is I'm gonna uh I'm gonna
uh use my 你自己的戴罗线
Okay back to uh Ant security measures uh there are these
things called inclusion exclusion list and uh white black
list. They are uh essentially the same uh one for the slave notes
one the other for the uh master notes and uh forдata for the uh master notes and one more is a it's a
mhm they could be useful but there's a problem with them they are uh only available on fairly
recent Ant chips so uh none of my Garmin devices uh can use these features. Okay another
security measure uh Ant channels can be encrypted with uh A A E S C T R but there are some
problems with these too. Uh you can't use them with shared channels uh which makes it uh
harder to implement uh s- uh implement it to to have for example one bi-computer with uh
multiple sensors and also uh it requires advanced burst data mode which is highly energy
inefficient and it's kind of a problem with low energy devices. So uh these are
problems but these have uh another bigger problem too uh encryption can't be used with Ant
plus. Uh if you use encryption then you are not uh Ant plus compliant and you can't
interoperate with other uh Ant plus devices. Okay so I've mentioned uh this Ant plus uh
several times already but I did not tell you uh what it is. It's a protocol built in
top of Ant and it basically just uh specified so- specifies uh so-called device profiles so
there's a device profile for uh speed sensors, a device profile for uh heart rate monitors,
and so on and so on. Uh these device profiles are uh managed by DynaStream and they basically
uh just govern some characteristics of the Ant connection like uh frequency, channel period,
and data formats. So uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh the uh
few examples of uh these device profiles this is uh bicycle rear view radar that uses the radar
and the light device profiles, the dropper seat post that uses the seat post device
profile, uh bicycle headlight of this light profile, and the blood pressure monitor uh that uses
the blood pressure device profile. Okay one of these device profiles is called command responding
and uh it allows you to uh collect and transfer uh sensor
data in the form of FIT files. So FIT uh is basically a file
system uh yep a file system is a file file system file format
for uh NTFS uh the files are fairly simple they have a 14
bytes uh header some data records and the 2 bytes CRC and
all data records have their own uh records header it's a 1 byte
header and some record content it it can be anything really so
uh they store um recorded tracks your settings your name
etcetera in in these uh FIT files. The reason I'm talking
about uh FIT files is that my first attempt to uh record a
file to uh hack my Friten XT was to uh try to find some memory
corruption uh vulnerabilities in the firmware and I did that by
uh fuzzing the FIT SDK with AFL and uh I did uh get some crashes
but they all seemed uh non exploitable. I've tried to
upload them uh to my Friten XT nevertheless because I was
hoping for some uh crashes but uh I didn't get any uh crashes
dams or crash logs or some useful information but I did not
get uh either so I I got nothing. Uh the watch did not
crash. And uh this got me thinking uh not this uh the ant
protocol stack became unavailable for a few minutes
and that got me thinking that maybe the ant protocol stack the
NTFS protocol stack is implemented uh in the ant chip and
not the uh actual Garmin firmware. So I have to uh explore
this further uh it might be interesting. Okay back to
NTFS. Uh according to DynaStream NTFS is a secure and reliable
file transfer protocol built on top of ant. Uh if you google
Garmin plus ant then you will uh find something like this. Uh
some uh rants on various forums about how reliable this stuff is
and I do question the security. Uh there are two major security
features according to DynaStream. One is the built in
encryption. Uh so you can encrypt uh your files and they
are also encrypted uh while on the air. It sounds nice but I've
seen some NTFS implementations but I did not uh understand the
security features. The other security uh measure in ant FS is
that it employs uh multiple authentication mechanisms. We'll
see about them. There are three uh authentication mechanisms.
The first being the pass-through mode. It's not really
an authentication mechanisms because it works like this. The host just asks to be able to use the
client if it can connect and the client just says yes why not. So uh no information needed
to to connect. I don't know uh why they did implement this maybe some uh maybe for some
testing purposes but the important thing is that it is there and uh you can use it. The
second uh authentication mechanism is uh called pairing mode. Uh don't confuse this with the
end uh pairing bit. It's an entirely different uh concept. Uh it requires user interaction uh
the host sends a serial number and a friendly name to the client. The client device displays
this information uh to the user and the user can uh decide if she accepts the connection or not.
If the user accepts the connection uh then a passkey is sent from the client to the host. The
host stores the passkey to the host and then the host sends the passkey to the client. So
the host stores the passkey and uses it for any further connections. So this pairing has to be
uh only once. Okay what's wrong with pairing mode? Uh obviously if you are uh malicious host
then you can send any serial numbers or any friendly names to a client so you can maybe get
the user to accept the connection. Uh this is one one way to attack pairing mode. The other is
that uh after a successful pairing the passkey is sent from client to host and it can be sniffed.
How do we sniff ant? Uh the ant chips that the majority of these devices use are NRF twenty four
AP one and AP two. And these are based on the very well known NRF twenty four L zero one
plus chips. So they work in the two point four gigahertz ISM band they have a uh with the uh
one megabits per secundum uh on our data rate. They use uh GFS key uh modulation but the
actual packet format is not really clear from the documentations. One of the papers
mentioned uh enhanced shock burst so I just went with that. But I only had an RTL SDR
which is not capable of uh sniffing 2.4 gigahertz but uh luckily I found this uh blog post
where this guy sniffs uh NRF 24L01 packets with uh an RTL SDR and an MMDS down converter.
So I uh ordered an MMDS down co-converter uh set this all up and tried to decode RTL FM
output as enhanced shock burst packets. It seemed to almost work but every byte was the
double of the ex-expected. So either they they are, they are, they are, they are, they are
uh very dumb and they use a brand new highly sophisticated encryption algorithm where the
crypt uh where they just uh multiply the plain text with two. Uh I've seen some pretty dumb
shit from developers but this would have been a bit much of a stretch so I just went with
another idea that the documentation slide and uh the packet format is not really enhanced
shock burst. Uh I started reading about uh enhanced shock burst and uh surprise surprise, a
surprise it turned out that there is a shock burst protocol. The two uh the difference between
the two uh is a 9 bit field called called uh package control field uh and it's being 9 bits so
it can happen that if you try to interpret a shock burst packet as an enhanced shock burst
packet that there is a 1 bit left shift which is the same as an enhanced shock burst packet. So
it is uh multiplying with 2. So uh it seemed uh reasonable uh solution so I uh implemented
shock burst decoding. I've implemented it as a C uh program and uh which uh outputs um hex
pairs and I've also written an anti-terr dot pi which interprets these uh hex pairs as
NFS packets. Um this worked out nicely uh as a proof of concept and uh it's uh it's uh it's uh a
concept but I wanted something uh cleaner so I've implemented these uh functionalities in uh
POTOSWR as uh two POTOSWR blocks. Uh if you don't know POTOSWR it's uh very similar to uh GNU
radio com companion I just uh like to use it more. Okay I have video of this too. So this is
the hardware. The MMDS down converter, the RTL SDR and I'm using uh the uh the uh the uh the uh
virtual machine with two anti-USB sticks here. Uh one for the NFS host and the other for the
NFS client. So there will be a host and the client on the same machine and they will talk to
each other. And we are going to sniff them uh using these POTOS uh blocks. Yeah it's
starting. Uh so this one is the shock burst decoder and the uh NFS uh interface. Uh so this one
decoder. I'm opening the uh client channel uh the client
beacons we can already see the client beacons and I will just
try to search uh for the client on the host and uh when the host
finds the client uh it sends a link command which changes the
uh communication frequency uh and this is why this uh feedback
from the NTFS decoder to the SDR source is there uh so it can
change the uh SDR source's frequency. Okay uh there's some
serial number request uh responses some more beacons and
when we try to download the directory uh listing uh the
thing it's also file uh there's download request response like it
and uh this is actually the uh directory listing it's not uh
yet parsed and this is where my uh USB stack failed me. Uh it did
not uh like all those data. Okay so we've talked uh about
two uh authentication mechanisms so far. Uh the last one is the pass key
mode. Uh pass keys are up to two hundred and fifty five bytes
long uh so brute forcing them is uh impractical but uh as I've told
you earlier uh after a successful pairing the host remembers the pass
key uh and the pass keys are stored in a directory structure so uh there's uh a
client serial number and the corresponding uh um pass key another serial number
another pass key and so on and so on. And when they the host encounters a client with a
known serial then it tries to uh authenticate uh with the stored pass key. This whole
process could be uh man in the middle uh by first posing uh as an NTFS host uh uh uh
acquiring the client serial number then spoofing the serial number acting as a client
uh the host will send us the pass key and we can then use this pass key to authenticate to the
client. Uh I've tried to use NTFS PC 2s for this uh and I've expected to s to to find the pass
key in the debug logs but the actual pass key algorithm made it impossible for uh the pass key to
because the host checks the uh passkey lines uh and if it does not match the stored uh
lines then it aborts the authentication process. But since uh we are the host in step
two uh we can patch these uh functionality uh and and still get the passkey. I found out
that uh the ant uh wrapped lib dot DLL contains the code pass uh for for this functionality.
I've almost uh started to binary patch it but noticed just in time that uh uh Dynastream
actually released the source code so I just have to modify the C code and recompile the uh DLL
to do this attack. So as you can see the uh the uh the uh the uh the uh the uh the uh the uh the
first step we are going to uh pause as a host and get the client serial number. I'm just
setting up some things here. Okay. And uh I've also used used my uh Freeton XT for this.
The host is searching for the client and we should get the client information soon. So
yeah it's not the uh not the fastest protocol but we yeah we we've got the uh device ID which
will be needed. So with that device ID we can start an NFS PC client and impersonate
that client. Okay I'm just skipping some parts. Okay so now we have the uh the uh the uh the
NFS PC client. Yep so uh started the client and I'm starting Garmin Express on my other
computer uh where this uh Freeton XT is already registered and because Garmin Express thinks
that this NFS PC client is this watch uh it will send the pass key to it. And we can see it in
the the backlogs.
Okay opening the log files. And uh these lines with uh starting with ACK um those are the uh
patched in uh stuff. There's the passkey length and the passkey itself. And now we can use that
passkey uh to authenticate to the watch and download the files from it. Okay so uh this is uh
uh yeah I'm just uh copy pasting that passkey and uh starting the uh channel starting searching
for the client and uh you can see that uh there is no user interaction on the client side.
This passkey succeeded and we can download the directory structure uh without uh any user
interaction from the client side. So this is how uh this man in the middle attack works.
Okay so uh this was the part about the uh design arrows, the protocol level and uh the uh the uh
roles so I'll just uh recap it uh and ask the question is it all crap? And yeah I have to say
it uh pretty much is uh it is possible to uh create uh secure ant connection but you have to
purchase your own uh network key from DynaStream. You can't use uh ant plus so you won't be able
to inter-operate with uh other end-plus devices. And also you have to use uh fairly large amount of
recent ant chips. So uh moving on to uh implementation errors. I'm going to show you uh
implementation errors in Garmin devices uh simply because I have those Garmin devices
because of mountain biking so I don't have anything against Garmin. I just use their stuff.
Okay. Uh the first authentication method was uh uh uh uh uh uh uh uh uh uh uh uh uh the
pass through mode. And I've uh assumed that it is only used for uh testing or something like
that. But of course I've implemented it uh in a little proof of concept script called hack ant dot
pi and I've tried it uh with both my Garmin uh free 10 XT and with my vivo fit uh and it worked.
So it means that you can uh use uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
access all the files on these devices without any authentication with just using the pass
through mode. Uh I'm showing showing you this by downloading directory structure uh from a vivo fit
using this pass through mode. And uh yeah it succeeded. Okay. So uh uh uh uh uh uh uh uh
sorry. Uh if this was not enough there's an other mode uh with you can access uh I assume all
Garmin devices. I could access uh every Garmin devices I've tried with this. Uh and it works
like uh this. Um I'm sorry. Uh I'm sorry. Uh I'm sorry. Uh I'm sorry. Uh I'm sorry. Uh I'm
sorry. Uh I'm sorry. Uh I'm sorry. Uh I'm sorry. Uh I'm sorry. Uh I'm sorry. Uh I'm sorry.
Okay so uh I'm just confused the uh slides. Okay uh so uh there's a feature called uh OTA
firmware updates. There are lots and lots of uh devices that uh don't even have any other
uh communication um method than ant. So firmware updates have to be done via ant. Uh so uh
the firmware update method is uh pretty well documented but by Dynastream. But of course
Garmin does not use this method. So I've started to uh reverse engineer the Garmin Express
services to learn how it actually works. But I've got distracted. I've got distracted by
these two uh methods. The first being compute factory part uh device passkey and the other being
has factory part device passkey. So I've got distracted by the two methods. The first being
I've assumed that uh they are using these for uh bundled uh
devices so you you can uh buy uh watch and heart rate monitor
together and they are factory uh paired so you don't have to do
that but of course I've implemented uh this compute
factory pair device pass key method in uh hackends dot pi 2
and I've tried it with the Freeton XT and Vivo Fit and it
worked in both cases. So it basically computes a pass key
from the device's serial number and uses it for connection. The
serial number as I've shown you earlier can be uh obtained by uh
posing as a host and we are posing as a host because we are
trying to uh download files from a client. So uh the uh the
what we chose to uh source is that. And it worked. You can see
that uh here's the uh device ID the serial number and the
computed pass key. So this is another method to access uh
uh Garmin devices. Uh one more thing about it this uh is that
you uh don't have to pose as a host to get the serial number uh
because they are uh printed on the device itself and also on
the packaging so you can just walk into Best Buy write down a
lot of uh serial numbers and then hack the devices later.
So okay so I've started talking about uh over the uh firmware
updates uh and uh it works like this with uh Garmin uh gadgets.
The firmware updates are uh RGM files with uh which are so called
region wrapped uh firmware files. They have to be unwrapped
and these unwrapped firmware file has to be uploaded to the
NTFS directory uh to the first index of the
NTFS directory. So uh this is the first index of the NTFS
directory. Uh it's that simple. Of course I've tried to uh upload
uh firmwares that are modified but at first I did not succeed.
So uh it was clear that there is some uh firmware checking
algorithm and uh in the VivoFit firmware I found uh two CRC 16
tables and two CRC 16 functions. But it turns out that
uh these were not used for uh firmware integrity checking but
finding them was uh still useful. And I love this about
hacking that uh there's a lot of scenarios where you go down
one road uh one road and you expect some result uh and you
don't get that result but what you get is still useful. So what
what was useful about this is uh
these functions used direct addresses uh to the uh CRC 16
tables which made it possible to deduce uh on what address the
firmware is actually loaded in memory. So it was useful for me.
But the actual uh firmware integrity checking algorithm was
much much simpler than CRC 16. Uh it was there's just a requirement
that the sum of all bytes have to be zero. It's fairly easy to
calculate. So I've also uh implemented this feature uh in
hackant dot by and I show you this by upgrading the VivoFit
firmware after slightly modifying it. So first uh unwrapping the
uh firmware file. Uh modifying it uh I'm just gonna
replace the string sleep with uh another string uh hacked. Okay
saving the file uh fixing the CRC. And uh uploading uh it to
the device using hackant dot by. Uploading it to the device using
first index as a device file type. And uh as you can see uh
in the case of the vivo fit it actually requires uh user
interaction because uh the ant protocol stack is uh off by
default for the reason of preserving battery but you can
do this with the free 10 XT and uh it requires no user
interaction. I'm using the vivo fit for this demo because it's
uh a much simpler device and a much cheaper device so it's uh
not that much of a pain if I uh break it somehow. Okay so the
firmware update succeeded and uh now we try to enter sleep mode
and it should display uh the uh the uh the uh the uh the uh the
uh the vulnerable empty Hacked instead of sleep and yeah it
does. So thanks, thanks. Stop stop stop. Okay so it was uh
very little modification but uh you can imagine that uh there's
a lot of stuff that can be done uh with this. Okay I have
one other thing to uh show you uh and it's it is not uh strictly ant related but I found this
issue while doing this research uh in the VivoFit firmware I have found an XML string uh
which kinda looked like uh some kind of uh device descriptor file and I've tried to reverse
engineered the Garmin connect uh android application to see see uh what this file is and
I have found some functions that download this file and process this file uh from the device. A
few years ago I've reported uh some XXC vulnerabilities to Garmin at least I tried to
report them uh got no response. So the first thing I did was I uh I found a file that was
thought was that maybe this is XXC able too. Uh I was thinking about uh uh attacking my
phone via a modified firmware VivoFit using XXE. So I've just uh replaced the XML string with an
XXC stub that uh uses a uh external parameter entity to connect back to one of my servers. Uh
uploaded this firmware to the uh VivoFit and tried to connect it to my phone. Uh and yeah it's
uh I I'm going to disappoint you guys here because I don't have a video or a live demo of this.
I've just had have these uh uh screenshots. But the important thing is that uh when I try to uh
uh, connect my VivoFit to my, uh, mobile phone, a connection came to my server. But the
connection did not came from my mobile phone. It was not my IP address, but, uh, after
looking it up, it was a Garmin IP address. So, what's happened is the mobile phone
downloaded the XML file from the, uh, VivoFit and, uh, sent it directly without any
modifications to a Garmin service. And the Garmin service was susceptible to XXC. Uh, and
you can see it's even Java. So, you can, uh, do directory listings and stuff like that. And, uh,
I think it's, uh, really complicated, but really nice way to find, uh, a vulnerability like
this in, in a major vendors, uh, internet accessible services. Okay. So, uh, the
last thing I, uh, wanted to show you guys, uh, small summary. Ant is bad. Uh, I'm using it
because I, I'm, I have these devices, but it's really easy to sniff, really easy to, uh, man in
the middle. The security features are not really security features. They, they are fairly
easy to circumvent. Uh, so, it is really easy to steal your track data, your, uh, your data. Uh,
your settings data, all your files, uh, that are on these devices. Uh, or even, it is even
possible to update, to replace, uh, the firmware on your device without your knowledge, uh,
remotely. Okay. So, uh, if you have, uh, any questions, you can contact me in, uh, these
channels and the, uh, scripts and, uh, tools I've mentioned that I have written, uh, will be, uh,
will be available on my GitHub, uh, later today. Uh, thank you very much for, uh, listening to
this talk. Bye bye.