[Full-Disclosure] HideezKey 2 FAIL: How a good idea turns into a SPF (Security Product Failure)

Click the icon to Follow me:- twitterTelegramRedditDiscord

HideezKey- This is a deep-dive into a nice concept for a security token & password manager that turned into a horrible product due to lack of proper R&D and Threat Modeling.

63731f cd39ec68dedb4e7fbd4e8e39c611d1d3~mv2

Prologue: After my first success in bypassing APPROTECT readout protection of the NRF52-based Slok smartlock with #PocketGlitcher (i.e. video below), I started looking around for more interesting and concerning (from a security point of view) NRF52-based products.

And here it comes the #HideezKey 2!

file
63731f cd4af68bdeb44d6e8b62abb883016adc~mv2

To give you a quick overview of this piece of hardware, check out their video intro:

Now that you got the point of this product. You will agree with me that the concept is very interesting, let’s now see if its implementation into a real product matches the expectations.

I will divide my investigation in paragraphs to keep everything as linear as possible.

Passive Recon & OSINT:

First of all (even without attempting to open the token) we can immediately notice our best-hardware-hacking-friend: the FCC ID. In this case: 2AQ5UHIDEEZKEY2

file
63731f 732bd36070f7405fa89a3d4f08b2a461~mv2

This leads us to the first set of OSINT information regarding how the PCB looks like, what MCU is used and which frequency is in use by the DUT (Device Under Test).

file
63731f ad664502902549e89bf6674dd8bd3a2e~mv2

The Internal Photos PDF from the FCC database is particularly useful in case the DUT’s PCB would have been buried under a hard layer of epoxy. This would have helped us to plan in advance where to start scraping out the epoxy and how to approach the opening of the case and how to reach the MCU. Luckily for us, there was none of these anti-tampering measures in place.

Overall, most of the information gathered so far is matching Hideez’ manual specs.

file
63731f fb0f9b5c46b7491498dccf1a2599984c~mv2

While keeping looking around the cyberspace for more information about the DUT, I quickly discovered a funny thing: there is a repo on Github that contains a lot of juicy stuff! 🍬🍭🧁🍰

gif

Among them… the schematics, the BoM (Bill of Material) and even the goddam CAD files of the PCB!

file
63731f c98488d5be6e44a6ab1115d6fd1b7680~mv2

In practice, I had access to everything I needed to easily figure out where the NRF52’s SWD pins are located, without even messing with Microscope, GIMP and Multimeter in continuity mode. (Thanks Hideez ❤)

file
63731f 784535afaa114e89aa06a07028dcd19c~mv2
file
63731f 7feca28bd62141af8359f027e948d9d8~mv2

Looking closer with Altium on the CAD files, I easily figured out the SWD’s pinout:

file
63731f c84f6110e3ca4a6883dedf87ae0575e4~mv2

Note, at this point in time I was also looking for an better location where to probe the DEC1 and RESET pins coming out from the NRF52 in order to use them later on to conduct the Fault Injection Attack with my #PocketGlitcher:

file
63731f f7d8bbaad53e4e18ad012833ad95c482~mv2

Even though, at the end, I won’t even need them. 🙃

Conclusion, always do your homework before putting your hands on the target: FCC database, Google, and Chinese search engines are your best friend when doing a hardware hacking research!

Setting Up The Device: Before starting the Active Recon Phase and, in order to replicate a real scenario, I decided to install the Hideez App on both laptop and iPhone. Subsequently I filled it with a bunch of dummy credentials. This will help me later in the case I will be able to obtain a firmware that eventually is encrypted (i.e. known-plaintext attack).

file
63731f f5a90f843c0e4a9e9812b53909632533~mv2
file
63731f 6c060818069d4d459b31b365069b6115~mv2
file
63731f 2cf46421c08547ae8cfec738c36cd889~mv2

Active Recon:

Now that we have a working Hideez Key 2 with some passwords in it, when can start opening it and checking if what we found during the Recon Phase matches the reality.

file
63731f dbce3f015e514914aea51e209c7ae420~mv2

As expected, from a closer look with my microscope, the PCB looks matching the schematics and the CAD design. Cool!

Just to be 100% sure I won’t fry the board while attempting the firmware dump, I double-checked with the multimeter that the pinout of the SWD interface was still correct. And indeed it was!

Dumping Firmware over SWD Interface:

In order to prove how easy would be for a real threat actor to dump the firmware in couple of minutes (i.e. #evilmaid attack) without leaving traces on the PCB itself, I decided to use my PCB workstation with nano probes.

file
63731f a6c7a5d51f3b4d15bbcb2b0146906f34~mv2
file
63731f 1020f8b840e9494eaeca03da04420ba3~mv2

With everything properly setup and connected to my J-link debugger, it literally took (with my extreme surprise, considering is a security token used as 2FA & password manager) 60 seconds to dump the firmware! 😱😱😱

file
63731f 51baa257ad5a44e1bddc3f6124c3d01c~mv2

Firmware Analysis:

Passed the initial shock, I thought the data inside the dump would have been still encrypted in some way. Therefore I was mentally prepared to play with #CyberChef‘s features in order to crack the sh*t out if this security token.

Well… I was wrong.

The credentials, both existing and also the ones that were “deleted” by the user, are there! In PLAINTEXT.

file
63731f 9f3667a8c3c84dfeb05519cca3047dae~mv2

Everything! The Cloud Password that allows to login on Hideez’s website, Laptop’s credentials, Website login user and password are ALL IN PLAINTEXT!

At this point, I will let the good-old Arny express my feelings.

gif

RFID Feature:

file
63731f 3bc24ce42940438eb88553d10ddce874~mv2

One clue still left (from a hardware security POV) was about the RFID tag. From the opening of the case, it was visibly obvious that the RFID feature advertised by Hideez was not related to the NRF52, but was rather just a standalone re-writable tag. (meh…)

That’s kind-of pity since the NRF52 is supposed to support NFC protocol as you can see from the Nordic’s NRF52-DK prototyping/evaluation board.

file
63731f 537c79d3f23d427d86db334869904706~mv2

Anyway, long-story-short, I wanted to check with my Proxmark what tag is that: it appears being a classic T55xx re-writable tag.

file
63731f aec996f3a9a047dd86d72e121e43277d~mv2
file
63731f 3ae054ac91cd4e5693e46f0581f0d11a~mv2

Sadly, this tag, as all the 125KHz vulnerable ones like EM4xxx or HID Proxcard, etc… are quite easy to clone from distance with a weaponized long-range reader (see below couple of examples).

file
63731f 1c85a1fc59e640cd8d6a654c73033bab~mv2
file
63731f 8504421caafe480faf32aecc86477632~mv2

Security Remarks:

The lack of proper security R&D and Threat Modeling is obviously the root-cause of this product failure. In particular I would have spent more time looking for:

  • A proper MCU with a security enclave that makes harder for anyone to extract the firmware (i.e. glitching-resistant). And I would enable the readout protection!
  • A better case design in order to still allow battery replacement but avoid full access to the PCB. With of course, an active anti-tamper detection mechanism that will void the encrypted content.
  • An eventual level of encryption on the top of the security enclave in order to slow-down eventual threat actors with unlimited access time to the stolen token.

Considering I didn’t have time yet to dig into the mobile app, APIs endpoint and BLE communication protocol, I can’t say exactly what could have been improved there. Though, I would definitely not forget doing a proper threat modeling in there too. 😉

Future Work:

Finally, the investigation is not over, there are some aspects of this DUT that I’d like to check out (time permitting):

  • APK Static Reverse Engineering

Hunting for usual hardcoded keys, backdoors, hidden APIs endpoints, etc.

file
63731f 73f292eb06594ba4889ad5258b47178f~mv2
file
63731f ecb9bfb776e247df9e89a9174abbb094~mv2
  • APIs Endpoint Testing

Through Certificate Pinning Bypass and MiTM Traffic Analysis

  • BLE Protocol Analysis

Through both Passive and MiTM attacks

Therefore, stay tuned and follow:

file
63731f 81b146507ffe43d5b57aba317e2cf5bc~mv2

Author Biography:Luca Bongiorni is working as Head of Offensive Security. He is also actively involved in InfoSec where his main fields of research are: Radio Networks, Reverse Engineering, Hardware Hacking, Internet of Things, and Physical Security. He also loves to share his knowledge and present some cool projects at security conferences around the globe.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, HideezKey)

The post [Full-Disclosure] HideezKey 2 FAIL: How a good idea turns into a SPF (Security Product Failure) appeared first on Security Affairs.

If you like the site, please consider joining the telegram channel or supporting us on Patreon using the button below.

Discord

Original Source
Available for Amazon Prime