How Ledger Hacked an HSM

Graham Steel
June 8, 2019

The announcement yesterday of this talk about HSM hacking on the BlackHat 2019 program has caused a stir, and for good reason: the authors claim to have discovered remote unauthenticated attacks giving full control of an HSM and complete access to keys and secrets stored on it. At the moment very few details are available in English about how this attack by researchers from Ledger was carried out, but fortunately for Francophones, this work was presented in detail earlier this week at the annual French security conference SSTIC. French speakers can watch the video or read the paper in the proceedings.

A brief summary

For the not-so-Francophone, the bilingual team at Cryptosense have translated a brief summary of what the Ledger researchers Gabriel Campana and Jean-Baptiste Bédrune did. There were plenty of technical challenges to solve along the way, in what was clearly a thorough and professional piece of vulnerability research:

  1. They started by using legitimate SDK access to their test HSM to upload a firmware module that would give them a shell inside the HSM. Note that this SDK access was used to discover the attacks, but is not necessary to exploit them.
  2. They then used the shell to run a fuzzer on the internal implementation of PKCS#11 commands to find reliable, exploitable buffer overflows.
  3. They checked they could exploit these buffer overflows from outside the HSM, i.e. by just calling the PKCS#11 driver from the host machine
  4. They then wrote a payload that would override access control and, via another issue in the HSM, allow them to upload arbitrary (unsigned) firmware. It's important to note that this backdoor is persistent - a subsequent update will not fix it.
  5. They then wrote a module that would dump all the HSM secrets, and uploaded it to the HSM.

The article in the SSTIC proceedings gives plenty more information (and a recommendation to read the Cryptosense HSM security whitepaper - thanks :-) ). It includes cryptographic attacks (flaws in PKCS#1v1.5 signature verification) and other goodies. It'll be well worth attending the talk at Blackhat in August.

What next?

The vulnerabilities have now been patched. The manufacturer is not named in the presentation, but it may be possible to work it out by, for example, looking at the recent security announcements of large HSM manufacturers. Update: on June 10th Gemalto added an update to confirm that the affected HSM is the Safenet Protect Server PSI-E2/PSE2.

Could the vulnerability have been exploited?

Certainly well-funded vulnerability research teams at state-level intelligence agencies could have carried out similar work and discovered this attack. The disruption caused to a target country's financial system by revealing certain secret keys would be pretty interesting to those looking to carry out cyber warfare. Perhaps the most concerning part of the attack is that the firmware update backdoor is persistent. There could be live HSMs deployed in critical infrastructure now containing similar backdoors.

What about other HSMs?

As an easy first step, HSM users can check for buffer overflows that can be exploited from outside the HSM (step 3 of the "kill chain" above) using our PKCS#11 fuzzer. In order to detect internal memory corruption, we recently added an option to stop the fuzzing when the API gives a result inconsistent with a previous one - this was a result of direct requests from our users who were encountering such issues with multiple manufacturers' products. While this is only one step in the chain, it is the only one amenable to repeatable, automated testing without access to HSM internals. Perhaps one day NIST certifications will require HSMs to resist the kind of attack described here, but today you have to either do the vulnerability research yourself (maybe with the help of our tools), or just keep your fingers crossed.Read more about HSM attacks in our Whitepaper.