Help, I've got ANTs!!!
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 93 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/36291 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 2420 / 93
4
6
7
11
15
20
26
33
34
35
36
39
40
46
49
53
58
62
63
66
68
72
79
90
92
93
00:00
Hill-DifferentialgleichungComputersicherheitLeistung <Physik>ZahlenbereichStreaming <Kommunikationstechnik>SpieltheorieSoftwareProtokoll <Datenverarbeitungssystem>NeuroinformatikComputersicherheitHackerVererbungshierarchieBitMeterBitrateSchlüsselverwaltungMAPEinflussgrößeFrequenzDreiecksfreier GraphMultiplikationFehlermeldungKategorie <Mathematik>Internet der DingeHumanoider RoboterRechenschieberUmsetzung <Informatik>ZentralisatorSoftwareentwicklerSoftwaretestInterface <Schaltung>Regulärer GraphWeb-SeiteTopologieVermaschtes NetzWeg <Topologie>Public-Key-KryptosystemUnrundheitKartesische KoordinatenImplementierungDruckverlaufEINKAUF <Programm>Gewicht <Ausgleichsrechnung>Chatten <Kommunikation>Zentrische StreckungSystemzusammenbruchHilfesystemVorlesung/Konferenz
06:01
BildschirmfensterVideokonferenzElektronische PublikationMetropolitan area networkMIDI <Musikelektronik>MeterLeistung <Physik>SoftwareDatensichtgerätComputersicherheitComputeranimation
06:54
ComputersicherheitWärmeübergangE-MailDatensatzDateiformatNeuroinformatikMailing-ListeFrequenzSchnittmengeInhalt <Mathematik>Einfach zusammenhängender RaumWeg <Topologie>Profil <Aerodynamik>SynchronisierungCharakteristisches PolynomLoginQuellcodeBildschirmmaskeSystemzusammenbruchSpeicherbereichsnetzwerkMultiplikationsoperatorComputersicherheitGrenzschichtablösungDatenloggerElektronische PublikationChiffrierungDateiverwaltungDruckverlaufEnergiedichteMultiplikationExploitStreaming <Kommunikationstechnik>Disjunktion <Logik>HalbleiterspeicherWärmeübergangEinflussgrößeSoftwareschwachstelleInklusion <Mathematik>BitrateProtokoll <Datenverarbeitungssystem>SichtenkonzeptFitnessfunktionInformationDämpfungFirmwareATMComputeranimation
11:10
WärmeübergangSystemzusammenbruchWeb logPatch <Software>ATMATMClientMechanismus-Design-TheorieZweiSerielle SchnittstelleInteraktives FernsehenStreaming <Kommunikationstechnik>Elektronische PublikationInformationAuthentifikationComputersicherheitProtokoll <Datenverarbeitungssystem>FreewareEinflussgrößeChiffrierungMultiplikationFiletransferprotokollSoftwaretestImplementierungElektronisches ForumWeb logSchlüsselverwaltungTLSDateiformatEinfach zusammenhängender RaumZahlenbereichInformationsspeicherungBitrateDatensichtgerätFormation <Mathematik>Firmware
15:34
Software RadioFunktion <Mathematik>Mailing-ListeGamecontrollerBitProgrammierungp-BlockBeweistheorieSoftwareentwicklerHackerDigitale PhotographieFunktionalVerschiebungsoperatorKryptologieDatenfeldProtokoll <Datenverarbeitungssystem>Funktion <Mathematik>Formation <Mathematik>DateiformatUnternehmensarchitekturBeobachtungsstudieCodierung <Programmierung>DifferenteUmsetzung <Informatik>ChiffrierungRechenschieberErwartungswertSechseck
17:47
Service providerHardwareSoftware RadioOISCVirtuelle RealitätElektronische PublikationVideokonferenzClientUmsetzung <Informatik>HardwareVideokonferenzVirtuelle MaschineClientProgramm/QuellcodeComputeranimation
18:20
VideokonferenzElektronische PublikationBildschirmfensterDigitale Photographiep-BlockClientSerielle SchnittstelleFrequenzZahlenbereichRückkopplungMailing-ListeVerzeichnisdienstQuellcodeExogene VariableTelekommunikationVerschlingungComputeranimation
19:49
WärmeübergangNotebook-ComputerGamecontrollerVideokonferenzRechnernetzStreaming <Kommunikationstechnik>HypermediaAuthentifikationZahlenbereichSerielle SchnittstelleMessage-PassingSchlüsselverwaltungLoginProzess <Informatik>GeradeClientMechanismus-Design-TheorieFunktionalReelle ZahlQuellcodeMultiplikationsoperatorCodePatch <Software>Streaming <Kommunikationstechnik>DatenstrukturATMVerzeichnisdienstInterface <Schaltung>SchnelltasteProgrammbibliothekMetropolitan area networkAlgorithmusComputeranimationVorlesung/Konferenz
22:25
BildschirmfensterVideokonferenzElektronische PublikationZahlenbereichSerielle SchnittstelleClientInformationProtokoll <Datenverarbeitungssystem>Computeranimation
23:15
BildschirmfensterVideokonferenzElektronische PublikationClientAuthentifikationDatenerfassungClientMereologieElektronische PublikationMessage-PassingArithmetischer AusdruckNeuroinformatikSchlüsselverwaltungDatenloggerGeradeComputeranimation
24:02
BildschirmfensterElektronische PublikationBroadcastingverfahrenDrahtloses lokales NetzHill-DifferentialgleichungInklusion <Mathematik>RechenwerkEreignishorizontMenütechnikVideokonferenzDemo <Programm>StabGeradeDickeInteraktives FernsehenDatenstrukturClientVerzeichnisdienstMetropolitan area networkElektronische PublikationAuthentifikationComputeranimationProgramm/Quellcode
25:12
MIDI <Musikelektronik>RechnernetzLESSchlüsselverwaltungMereologieSoftwareAuthentifikationStreaming <Kommunikationstechnik>ATMImplementierungEinfach zusammenhängender RaumMAPFehlermeldungProtokoll <Datenverarbeitungssystem>SchlüsselverwaltungComputersicherheitMessage-PassingQuantisierung <Physik>Computeranimation
26:33
BildschirmfensterVideokonferenzATMDatenstrukturSkriptspracheElektronische PublikationVerzeichnisdienstAuthentifikationPi <Zahl>SoftwaretestBeweistheorieMessage-PassingSkalarproduktHacker
27:25
Demo <Programm>Elektronische PublikationHypermediaBildschirmfensterSchlüsselverwaltungATMBitrateStreaming <Kommunikationstechnik>Hidden-Markov-ModellTelekommunikationRechenschieberFaktor <Algebra>CASE <Informatik>Arithmetischer AusdruckDienst <Informatik>FirmwareReverse EngineeringMessage-PassingSchlüsselverwaltungComputeranimation
29:33
VideokonferenzElektronische PublikationBildschirmfensterClientEinfach zusammenhängender RaumZahlenbereichSerielle SchnittstelleElektronische PublikationSchlüsselverwaltungComputeranimation
30:13
HypermediaSpieltheorieRechnernetzFirmwareCodeInformationElektronische PublikationIntegralTabelleFirmwareAdressraumHalbleiterspeicherResultanteDatensatzFunktionalVerzeichnisdienstZahlenbereichAutomatische IndexierungSummierbarkeitSerielle SchnittstelleZyklische RedundanzprüfungAlgorithmusComputeranimation
32:52
VideokonferenzBildschirmfensterElektronische PublikationFirmwareCASE <Informatik>Automatische IndexierungDefaultInteraktives FernsehenATMZeichenketteDemo <Programm>Pi <Zahl>DateiformatFirmwareProtokoll <Datenverarbeitungssystem>Elektronische Publikation
34:58
Elektronische PublikationExogene VariableSoftwareschwachstelleZeichenketteKartesische KoordinatenHumanoider RoboterReverse EngineeringProzess <Informatik>FunktionalServerParametersystemEinfach zusammenhängender RaumFirmwareComputeranimation
36:35
KonstanteElektronische PublikationVideokonferenzSoftwareschwachstelleNetzadresseMailing-ListeVerzeichnisdienstComputersicherheitDienst <Informatik>SkriptspracheEinfach zusammenhängender RaumSchnittmengeAppletInternetworkingFirmwareVolumenvisualisierungServerWeg <Topologie>Demo <Programm>Metropolitan area network
Transkript: Englisch(automatisch erzeugt)
00:00
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 gonna hear about um speedometers. Right? We're talking about speedometers and things that you can put on to your put on put onto your bike. This is gonna be really cool. Um let's give speaker give our next speaker a big round of applause. Hi everybody. Uh thank you for
00:30
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
00:43
regular speaker at uh Hacktivity. Central Europe's biggest hacker conversion. And I also gave a talk uh about uh insecure game scripting engines last year here at DevCon. So the title of my talk is help I've got the Ants. What are we doing with the Ants? Uh last year
01:03
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 slowly. Uh and uh while creating this slide I've just realized that all of my
01:20
hobbies includes crashing. Uh so mountain biking, computer security, flight simulators and recently drones. There's a lot of crashing there. I don't know about this. Okay so. So mountain biking and Ants. Uh what what does what do Ants have to do
01:43
with mountain biking? Uh there's a lots of gadgets that uh lots of equipments uh involved in sports involved in mountain biking and in cycling in general. And uh old school speedometers got replaced by powerful fairly powerful computers. Computers that talk to various sensors like speed sensors, power meters, heart rate monitors, et cetera
02:06
et cetera. And also uh talk to uh mobile phones or even your PC. And here is where Ants came in the picture because uh Ant is a protocol uh that these devices speak. Uh it is
02:23
not just used by uh sports equipment but uh weight scales but blood pressure monitors or there are even there is even a chat application that uses it to create mesh network on Android. It's called fire chat. So in this talk uh I will uh introduce you
02:45
to Ant and plus and the AntFS protocols and I show you some uh protocol level design errors and uh after that some implementation errors in various Garmin devices. So uh Ant.
03:01
Ant is a wireless protocol created by Dynastream and uh it is designed for low power devices. Uh you can create uh any kind of network topologies and the participants are called nodes. They are slave and master nodes. Uh and these nodes are com-
03:20
communicating via uh mutually established channels. Uh channels are defined by lots and lots of frequency uh or the channel ID but the most important for us uh from a security
03:40
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's a
04:01
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 network ste- uh network key uh then the
04:23
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
04:43
or Ant FS and uh these 2 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
05:04
other security measures in Ant. There's a pairing bit. Uh it works like this. 2 nodes can communicate with each other only if the pairing bit uh is the same for the 2 nodes. So it does not have to be on it just have to be the same on on 2 nodes. Uh
05:22
this is fairly easy to circumvent because you can open 2 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
05:46
heart rate 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
06:09
up my uh Freaton XT to use a power meter and I'm gonna use uh Simulant Plus which is a software released by Dynastream to simulate a power sensor. Just creating the power
06:28
sensor. Setting a sensor uh data value that it will transmit. Turn it on and the watch should just pick up that signal and display uh that value and yeah it did. So uh without
06:47
any pairing it is the simple spoof uh Ant sensor data. Okay back to uh Ant security
07:02
measures uh there are these things called inclusion exclusion list and uh white blacklist. They are uh essentially the same uh one for the slave notes one the other for the uh master notes. Mmm they could be useful but there's a problem with them they
07:22
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 AES CTR but there are some problems with these two. Uh you can't use them with shared
07:47
channels uh which makes it uh harder to implement uh uh uh uh uh uh uh uh uh uh implemented to to have for example one by computer with uh multiple sensors. And also uh it
08:02
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 this have uh another bigger problem too. Uh encryption can't be used with Ant Plus. Uh if you use encryption then
08:23
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 on top of Ant and it basically just uh
08:46
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
09:06
characteristics of the Ant connection like uh frequency, channel period and data formats. Uh a few example of uh these device profiles this is a bicycle rear view radar that uses the radar and uh light device profiles. The dropper seat post that uses the seat
09:27
post device profile. Uh bicycle headlight obviously the light profile and the blood pressure monitor that uses the blood pressure device profile. Okay one of these device
09:41
profiles uh is called SYNC 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. It's
10:00
the file system file format for uh NFS. 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
10:22
anything really so. Uh they store um recorded tracks, your settings, your name etcetera in these uh FIT files. The reason I'm talking about uh FIT files is that my first attempt to uh hack my Freaton XT was to uh try to find some memory corruption uh
10:45
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
11:03
them uh to my Freaton XT nevertheless because I was hoping for some uh crash damps or crash locks or some useful information but I did not get uh either. So uh I tried to get nothing. Uh the watch did not crash. And uh this got me thinking uh not this uh the N
11:25
protocol stack became unavailable for a few minutes and that got me thinking that maybe the N protocol stack the NFS protocol stack is implemented uh in the N chip and not the uh actual Garmin firmware. So I have to uh try to find out what happened to the
11:45
exploit 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 N. Uh if you
12:04
Google Garmin plus N then you will find 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
12:26
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 see anyone that uses uh this
12:41
encryption feature. The other security uh measure in NTFS is that it employs uh multiple authentication mechanisms. We will see about them. There are three uh authentication mechanisms. The first being the pass through mode. It's not really an authentication
13:03
mechanisms because it works like this. The host just asks 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
13:24
important thing is that it is there and uh you can use it. The second uh authentication mechanism is uh called paring mode. Uh don't confuse this with the N paring bit. It's an entirely different uh concept. Uh it requires user interaction. Uh the
13:46
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
14:04
the client to the host. The host stores the passkey and uses it for any further connections so this paring has to be uh only once. Okay what's wrong with paring mode? Obviously if you are a malicious host then you can send any serial numbers or any
14:24
friendly names to a client so you can maybe get the user to accept the connection. Uh this is one one way to attack paring mode. The other is that uh after successful paring the passkey is sent from client to host and it can be sniffed. How do we sniff ANT? Uh the
14:50
ANT chips that the majority of these devices use are NRF24AP1 and AP2 and these are based on the very well known NRF24L01 plus chips. So they work in the 2.4 gigahertz ISM
15:04
band. They have a 1 megabits per second 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 bursts so I just went
15:23
with that. But I only had an RTL-SDR which is not capable of sniffing 2.4 gigahertz but uh luckily I found this uh blog post where this guy sniffs uh NRF24L01 packets with uh an
15:42
RTL-SDR and an MMDS down converter so I uh ordered an MMDS down com- converter uh set this all up and try 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 uh
16:06
very dumb and they use a brand new highly sophisticated encryption algorithm where the crypt uh where they just uh multiply the plaintext 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
16:23
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 it turned out that there is a shock burst protocol. The two uh the
16:47
packet called called uh packet control field uh and it's being nine bits so it can happen that if you try to interpret a shock burst packet as an enhanced shock burst
17:01
packet that there is a one bit left shift which is uh multiplying with two. So uh it seemed uh reasonable uh solution so I uh implemented shock burst decoding uh I've implemented it as a C uh program and uh which uh outputs um hex spares and I've also
17:25
written an entity that's pi which interprets these uh hex spares as NTFS packets. This worked nicely uh as a proof of concept but I wanted something uh cleaner so I've implemented these uh functionalities in uh Potosver as uh two Potosver blocks. Uh if you
17:46
don't know Potosver it's uh very similar to uh GNU radio com- companion. I just uh like to use it more. Okay I have video of these two. So this is the hardware, the MMDS down
18:02
converter, the RTL-SDR and I'm using a virtual machine with two anti USB sticks here. Uh one for the NTFS host and the other for the NTFS 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
18:21
sniff them uh using these Potos uh blocks. Yeah it's starting. Uh so this one is the shock burst decoder and the NTFS uh decoder. I'm opening the uh client channel uh the
18:44
client beacons. We can already see the client beacons and I will just try to search for the client on the host and uh when the host finds the client uh it sends a link
19:02
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
19:27
beacons and when we try to download the directory uh listing it's also filed uh there's download request response. Pack it and uh this is actually the uh directory listing
19:43
it's not uh yet parsed. And this is where my uh USB stack comes in. Okay so uh it did not uh like all those data. Okay so we've talked uh about two uh authentication
20:08
mechanisms so far. Uh the last one is the passkey mode. Uh passkeys are up to 255 bytes long uh so brute forcing them is uh impractical but uh as I've told you earlier
20:24
after a successful pairing the host remembers the passkey uh and the passkeys are stored in a directory structure so uh there's a client serial number and the corresponding uh passkey another serial number another passkey and so on and so on. And when the the host
20:45
encounters a client with a known serial then it tries to uh authenticate uh with the stored passkey. This whole process could be uh man in the middle uh by first posing uh as an
21:02
interface host uh acquiring the client serial number then spoofing the serial number acting as a client uh the host will send us the passkey and we can then use this passkey to authenticate to the client. Uh I've tried to use NTFS PC 2 to
21:24
use for this uh and I've expected to to to find the passkey in the debug logs but the actual passkey algorithm made it impossible because the host checks the uh passkey lines uh and if it does not match the stored uh lines then it aborts the authentication
21:46
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
22:02
wrapped lib dot DLL contains the code pass uh for for this functionality. I've almost started to bind the patchy but noticed just in time that uh Dynastream actually released the source code so I just have to modify the C code and recompile the uh
22:24
DLL to do this attack. So as 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 I've also used
22:49
my uh Freeton XT for this. The host is searching for the client and we should get the client information soon. Yeah it's not the uh not the fastest protocol but we yeah we we've
23:08
got the uh device ID which will be needed so with that device ID we can start an NTFS PC client and impersonate that client. Okay I'm just skipping some parts. Yep so uh
23:34
started the client and I'm starting Garmin Express on my other computer uh where this
23:42
uh Freeton XT is already registered and because Garmin Express thinks that this NTFS PC client is this watch uh it will send the passkey to it and we can see it in the debug logs. Opening the log files and uh these lines with uh starting with ACK and those are
24:14
the uh patched in uh staff. There's the passkey length and the passkey itself and now
24:22
we can use that passkey uh to authenticate to the watch and download the files from it. Uh yeah I'm just uh copy pasting that passkey starting the channel starting
24:49
searching for the client and uh you can see that there is no user interaction on the client side. This passkey succeeded and we can download the directory structure uh
25:07
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 errors, the
25:29
protocol level errors so uh I 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
25:44
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 interoperate with uh other Ant Plus devices and also you have to use uh fairly recent Ant chips. So uh moving on to uh
26:06
implementation errors. I'm going to show you uh implementation errors in Garmin devices uh simply because I have those Garmin devices because of quantum biking so I don't have anything against Garmin. I just use their stuff. Okay uh the first authentication method
26:29
was 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
26:47
called hack Ant dot pie and I've tried it uh with both my Garmin uh Freton XT and with my VivoFit uh and it worked. So it means that you can uh access all the files on
27:07
just using the pass through mode. Uh I'm showing showing you this by downloading the directory structure uh from a VivoFit using this pass through mode and uh yeah it
27:21
succeeded. Oh sorry. Uh if this was not enough there's another mode uh which you can
27:41
access uh I assume all Garmin devices. I could access uh every Garmin devices I have to tried with this uh and it works like uh this um I'm sorry. Okay so uh I'm just confused
28:09
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 method
28:26
so firmware updates have to be done via Ant. Uh the firmware update method is uh pretty well documented by by DynoStream 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
28:48
but I've got distracted. I've got distracted by these two uh methods. The first being compute factory paired device pass key and the other being has factory paired device pass
29:00
key. I've assumed that uh they are using these for uh bundled uh devices so you you can uh buy a watch and a 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
29:21
paired device pass key method in uh Hackens.py 2 and I've tried it with the Friton XT and VivoFit 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
29:48
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 and it worked. Uh you can
30:02
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 Garmin devices. Uh one more thing about it this uh is
30:24
that you uh don't have to pose as a host to get the serial number and the 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
30:41
later. 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 RGN files with uh
31:01
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. Uh it's that simple. Of course I've tried to uh upload uh
31:23
firmware's 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 2 CRC 16 tables and 2 CRC 16 functions. But it turned out that uh these were not used for
31:48
uh firmware integrity checking but finding them was uh still useful. And I love this about hacking that uh there there's a lot of scenarios where you go down one road uh
32:02
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
32:25
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
32:43
there's just a requirement that the sum of all bytes have to be 0. It's fairly easy to calculate. So I've also uh implemented this feature uh in hackent dot buy and I show
33:05
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
33:21
sleep with uh another string uh hacked. Okay saving the file uh fixing the CRC and uh uploading uh it to the device using hackent dot buy. Uploading it to the first
33:46
index as a device file type. And uh as you can see uh in the case of the VivoFit it actually requires user interaction because uh the and protocol stack is uh off by default
34:06
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 VivoFit for this demo because it's uh a
34:21
much simpler device and a much cheaper device so it's uh not that much 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 hacked instead of sleep. And yeah it does. So
34:48
thanks. Thanks. Okay so it was a very little modification but uh you can imagine that
35:05
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 and related but I found this issue while
35:22
doing this research. Uh in the VivoFit firmware I have found an XMS string uh which kinda looks like uh some kind of uh device descriptor file. And I've tried to reverse engineer the Garmin connect uh Android application to see see uh what this file is. And
35:46
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 uh a few years ago I've reported uh a some XXE vulnerabilities to Garmin. At least I tried to report them. Uh got no response.
36:07
So the first thought was that maybe this is XXE able too. Uh I was thinking about uh attacking my phone via a modified firmware VivoFit using XXE. So I've just uh replaced
36:25
the XML string with the next XXE tab 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
36:43
tried to connect it to my phone. Uh and yeah it's uh I 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 the have these uh uh screenshots. But the important thing is that uh when I try to uh connect my VivoFit
37:08
to my uh mobile phone the connection came to my server. But the connection did not come from my mobile phone. It was not my IP address but uh after looking it up it was a
37:22
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 XXE. Uh and you can see it's even
37:44
Java so you can uh do directory listings and stuff like that. And 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 this was the last thing I uh wanted to
38:07
show you guys. Uh small summary and it's 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
38:22
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 settings data or your files uh that are on these devices. Or or even it is even possible to update to
38:42
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
39:00
the tools I've mentioned that I have written uh will be available on my GitHub uh later today. Uh thank you very much for uh listening to this talk. Bye bye. Thank you very much.