Hardware Security Modules (HSMs) are tamper-resistant special-purpose computers that protect the most sensitive cryptographic key material in an organisation. They are used for security-critical applications such as electronic payment, PKI, inter-bank transfers, and PIN management in the cash machine network.
At Cryptosense we produce software to audit the application programme interfaces (APIs) of these devices and find security flaws. A natural question is: do these systems really ever suffer breaches? Don't attacks happen elsewhere?
In this article, we'll look at two major breaches of critical applications secured by HSMs for which the details have become more or less public, the Dutch Certification Authority (CA) DigiNotar, and the payment processor RBS Worldpay.
DigiNotar
In July 2011, Diginotar staff detected that the serial numbers of certificates issued did not match those in their logs in a routine test. An internal investigation followed and they thought the damage had been limited. However, in August a rogue DigiNotar-signed certificate for *.google.com was used in a large scale man-in-the-middle attack on google users in Iran. The reports from Iranian users that brought the attack to light (thanks to certificate pinning in Chrome) are fascinating, and as is well-known, the incident eventually lead to DigiNotar going bust in September 2011. The revocation for DigiNotar certs caused a massive headache for the Dutch government. But how did the breach actually occur?
While some details have remained confidential, a public report by Fox-IT gives plenty of information and is worth reading in full. We'll highlight just two aspects: the tunnelling to the internal network, and the interaction with the HSM.
DigiNotar's HSMs were, as is standard practice, connected to an isolated internal network "SecureNet" with tightly controlled access to the rest of the office network "OfficeNet", which was itself isolated from the external-facing webservers in the DMZ.The intruder compromised a webserver in the DMZ on June 17th 2011. Between June 17th and June 29th, he compromised machines on OfficeNet, and by July 1st, he had reached the SecureNet and the HSMs. At this point, he should still not have been able to issue certificates because the private keys in the HSM should only be active when a particular smartcard is inserted into the slot in the front of the HSM. However, DigiNotar were not able to account for the location of all except one of the smartcards during the period of the breach. Intriguingly, it appears the intruder also tampered with the DLLs used to provide API access to the HSMs, later substituting them with the originals but without changing the creation time. Log files associated with the DLLs were also altered.
The report in not conclusive about how exactly the 500+ rogue certificates were produced, but indicates that "These traces on the DLLs and logs could indicate that the intruder had tried to use the netHSM and its stored private keys directly." In any case, we conclude that attackers of this level of sophistication are quite capable of tunnelling from external-facing networks to internal ones if they are not fully air-gapped, and seem to be aware of attack vectors on HSMs that include exploiting their APIs.
RBS Worldpay
The grand jury indictment of Pleshcuk et al that followed the $9.4M RBS Worldpay breach in November 2008 indicates that the attackers got hold of more than 40 pairs of PIN codes and debit card account numbers. Part of the attack was to increase the account limits of the debit cards. Another part was to decrypt the encrypted PIN blocks. The keys that protect the PIN blocks are stored in HSMs, so this should be impossible. How did they do it?
A 2009 Wired Article featuring an interview with Brian Sartyn, a Verizon security researcher reveals some of the details. In the indictment in a previous case involving attacks on TJX, Albert Gonzalez reveals the hackers sought expert advice from an unnamed co-conspirator who helped them decrypt their pirated PIN blocks using access to an HSM. Sartyn says "This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device." For example, a misconfigured HSM allowing clear PINs to be circuitously encrypted under the same keys as live PIN blocks (so allowing a dictionary attack) may have been to blame in this case.
Conclusion
These major breaches were one of the main motivations for us in developing software that can analyse the security of an HSM API, taking into account all the possible sequences of commands and parameters that a sophisticated attacker could use to try to break security. For more on protecting yourself against PKCS#11 implementation errors, read our white paper.