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

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.

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!

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

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).

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.

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!

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

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 )

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

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:

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).

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.

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.

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!

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.

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.

RFID Feature:

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.

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

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).

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.

• 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:

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.