Information security (infosec) is intrinsically related to mitigating risks: inappropriate access to data or services, or simply putting the system out of order. Paradoxically in some situations, infosec is actually the cause of disruption. What happens if you are unable to maintain or backup your own system because of security measures?
This became a common situation when copy protection got more and more advanced and prevented you from creating backup. The business rationale won over service availability and convenience.
The following article presents the study of an arcade system security architecture from hardware to software, highlighting the good ideas while pointing out what could have been improved. By the end of the journey, we should be able to backup our system for preservation in a durable and playable format. This case study will be extended to general infosec recommandations.
Our lab rat
Our lab rat is an arcade game system released in 2014. Like most modern systems, it is based on a x86/AMD64 PC architecture, making developing on it and porting from it easy and inexpensive. In our case study, the target system is a bulky industrial computer extracted from a 2*2.8 meters arcade shooting game.
From a security point of view, this system design is close to industrial standards, hence has some of their perks, which includes a strong cryptography along with security hardware devices.
Architecture details:
- CPU: Intel Core i5
- RAM: 8 GB to 16 GB DDR3
- GPU: NVIDIA GeForce GTX 6xx to 10xx
- Storage: SATA HDD or SSD
- Operating System: Windows Embedded Standard 7 / 10 IoT Enterprise 2016
This also includes:
- HASP HL USB dongle
- Trusted Platform Computing (TPM) chip
- Windows BitLocker
This is quite a strong setup but what’s even more interesting is that it embeds tools to assure platform integrity and full disk encryption. Having those features enabled makes backup irrelevant as any hardware change prevents boot. In terms of infosec, this puts a huge risk on availability — amplified by the lack of hardware redundancy.
To put it simply, would you accept the risk of relying solely on a HDD not crashing, without any means of replacing it?
Good
Relying on strong industry standards is a good practice in terms of security.
Bad
Designing a system with such an unbalanced CIA triad is preposterous.
→ A good architecture is always a matter of balancing.Building a system bound to unreliable and non redundant parts such as a mechanical drive can only end in tears.
→ Having a fallback mechanism and a recovery procedure is mandatory for a good architecture.
Security architecture
The most interesting feature is the use of hardware security processors. The first one is a TPM 1.2 chip from Infineon. It includes a non-volatile memory (NVRAM) and platform configuration registers (PCR), both used by Bitlocker on Windows, but also Linux Unified Key Setup (LUKS) and many embedded systems.
On boot, starting from the root of trust to the last element in the boot chain, the PCR value will be extended (ie: recalculated) by each step. At the end of the process the resulting hash is a unique identifier of hardware configuration, bios or bootloader tampering.
Without the correct result, the TPM won’t unseal the keys stored in NVRAM and without this key it makes the disk unusable.
The second security processor is located inside an USB key, also named security token or dongle. This security scheme is not new and has been used for ages as software protection. While the most advanced dongles feature cryptographic tools, in our case, it is merely a licence manager.
By the end of the article we’ll see it can be software emulated while not being a risk for system preservation.
In order to create a HDD backup copy or replace a hardware if a component was to fail, we simply need to suspend the trusted boot/bitlocker functionality resulting in disabling the boot chain verification and get the cryptographic key freely available.
This can be achieved by getting administrative access to the OS or a “write” access to the C: drive.
Potential attack methods
The first step is to list reliable and potential attack methods. This is very important when securing a system: knowing what might happen and being proactive is a key principle of infosec.
Remote access
A network scan of the host reveals an open service on port 1947. This port is used by HASP Sentinel Licence Manager.
A quick search for CVE returns many vulnerabilities with a 9.8 CVSS score:
- https://securelist.com/a-silver-bullet-for-the-attacker/83661/
- https://nvd.nist.gov/vuln/detail/CVE-2017-11496
- https://nvd.nist.gov/vuln/detail/CVE-2017-11497
- https://nvd.nist.gov/vuln/detail/CVE-2017-12821
However there is no public exploit available. This remains a good candidate for an intrusion test and it will need further investigation — as most attackers we will search for another yet simpler way to get inside.
Our second potential candidate is Windows Embedded 7 OS. This is an old version and we hoped to find a ready to use Metasploit exploit. We found many, like “Eternal blue” and “Double Pulsar” but all of them failed.
Good
Having a strong firewall setup mitigates risks inherited from other softwares.
Bad
Using components with known vulnerabilities, and failing to update them is a huge risk as public exploits will arise. It’s only a matter of time.
→ Having no way to update a production system is a massive flaw in architecture.
Physical access
Having physical and prolonged access to the target hardware makes it easier to attack. In terms of security, a radical approach to protect would be to “destroy” keys when the hardware is physically tampered with (such as opening the motherboard cage). Fortunately, such countermeasures weren’t in place.
Memory attack
Using DMA (direct memory access) we would be able to retrieve the cryptographic key directly from the RAM. Firewire interface allows such trickery but it needs to be enabled on the target system. Adding an expansion card would prevent booting.
Other memory access techniques like cold boot attack, although possible, would be impractical so we will leave it for now until there is no further option.
TPM brute forcing
Booting another OS is possible using an USB key. This is a risk as loading software on the platform might ease access to hardware, like the TPM. However the TPM features an anti-bruteforce mechanism and hammering to get keys would result in clearing the NVRAM.
The next step will dive into Bitlocker and boot workflow.
Bitlocker basics, and flaws
When you enable BitLocker with TPM (Trusted Platform Module) only, it boots without human intervention. The VMK (Volume Master Key) is unsealed by the TPM chip and delivered to the system on startup.
Why the need to use a password (the VMK) if the system types it automatically?
Because it relies on being confident enough that the OS will not be hacked while running and ensures it can’t be read or modified when turned off. In short, one cannot simply pull out the drive and play with it (or a copy of it) on another machine.
The TPM won’t unseal VMK unless the PCR (Platform Configuration Registers) registers have known values in them. As a result:
- You can’t boot another OS and hope it would unlock TPM.
- You can’t change hardware, bios settings or load any software beforehand (who said “rootkit” ?).
When decryption happens, the VMK is sent by TPM to the system using a clear channel. Indeed, our secure enclave is talking out loud without any encryption. The encryption exchange is part of the TPM 2.0 specification but not usually implemented.
Having the VMK will allow us to read and write a disk using Dislocker ( https://github.com/Aorimn/dislocker), a FUSE driver for the Bitlocker partition. This is the first step yet the biggest to achieve.
A look at TPM chip specifications (Infineon SLB9635) reveals that it uses the LPC bus for communication. Furthermore, Internet literature shows that we are not the first to try this:
Hector Martin (Marcan42) tweeted about this bad design in 2019:
Denis Andzakovic (Denandz) demonstrated the vulnerability using a logic analyzer and a FPGA dev stick:
A full in one solution has been derived by Matthias Deeg (mdeeg) from this tool
- https://www.youtube.com/watch?v=-Fj3SeZww3M
- https://github.com/SySS-Research/icestick-lpc-tpm-sniffer
Without going any further, we could states:
Good
Relying on strong cryptography schemes, leveraging industry standards is a good practice.
Disabling a lot of features, drivers, etc.
→ Reducing attack surface and available tools makes attack harder.Bad
Relying solely on security of one component to protect data confidentiality is a very bad move.
→ Defense in depth is both a mindset and an architecture concept to apply everywhere.Having a platform running with administrator privilege ease attacker work as there is no need for privilege escalation.
→ NEVER run as root/administrator !Having components with known vulnerabilities
→ Reducing attack surface and available tools makes attack harder.Not blocking common HID devices (keyboard & mouse) makes local control possible.
→ Reducing attack surface and available tools makes attack harder.
Practice
Roadmap
Our attack scheme is defined and we have some tools ready:
- Listen to key exchanges on an unsecured channel
- Use this key to gain write access to the filesystem
- Use this access to unlock administrative tools
- Suspend unwanted features
Hardware
Our SuperMicro motherboard with a soldered SLB9635B TPM chip, includes a 20-pins TPM header and good news: it’s populated with pins. This makes the attack solderless.
Figuring the pinout is easy, mostly a matter of an Internet document search, and help us to build a prototype wiring. The AOM-TPM module is an external TPM made for this kind of connector. Here are some more informations: https://www.supermicro.com/en/products/accessories/addon/AOM-TPM-9655V.php
The associated datasheet ( https://www.supermicro.com/manuals/other/datasheet_AOM-TPM-9655V.pdf ) shows this pinout, allowing us to build the right connector.
Our attack system is a Debian 11 laptop with an ICEstick FPGA board (40€), coupled with a cannibalized IDE ribbon. This makes the attack very cheap compared to the overall cost of the machine we want to backup (about 25k€).
Software
The build toolchain for FPGA is fully open source ( Yosys/NextPNR/Arachne-PNR/IceStorm ) and available in repositories.
The FPGA role is to listen to the LPC bus, then to decode messages and to transfer only those related to TPM. They are easily identified as TPM messages of interest:
- use a specific start header 0b0101: https://en.wikipedia.org/wiki/Low_Pin_Count#LPC_non-ISA_cycles
- are “read” command
- are on specific addresses (0x24) where we know the keys are stored
The USB interface is configured as a 2Mbps serial and communicating with a Python script to listen and search VMK patterns in the bit flow.
Both https://github.com/denandz/lpc_sniffer_tpm and https://github.com/SySS-Research/icestick-lpc-tpm-sniffer were tested, without success in extracting keys. Many github issues of these projects were related to specific TPM models not working properly.
Verilog code analysis reveals a “hacky” state machine with quick and dirty addendum to filter only TPM exchanges.
A couple of experiments later and a full rewrite of the state machine allowed us to figure out that some TPM are not addressing data the same way as others, spreading the keys on multiples addresses.
After fixing this issue, we got full TPM<>system talks sent through USB and our Python code identifies the VMK instantly.
Software, second step
Getting the key was the first step. Plugging the HDD to our Debian host and using dislocker gives us read/write access to C: partition. Other partitions remain locked as they use another key — which is not a concern as we only want access to the system.
No issue here and we start digging into OS.
More security features ?
As we now have access to the disk we can look at startup scripts, settings and installed softwares. Almost no security is preventing us from making modifications to the drive. This means that we can get full administrator privileges, disable network restriction, etc.
We also figured out that user and administrator passwords are available in clear text in provisioning scripts, mastering tools are still available on disk as well as development configuration. These vulnerabilities classify in the “Sensitive Data Exposure” category.
Our first (and only) action is to suspend Bitlocker. After a reboot we can confirm Bitlocker status is now suspended, allowing us to clone the hard drive and use this backup to run the game. This also allows us to change core components, either because they are faulty or because we want to upgrade specs.
One security feature remains: the HASP dongle. It’s not preventing us from backing up our drive, so it will be considered far beyond the scope of this article, but key emulator exists and key enforcement can be disabled with “one byte” edit in the right “.exe” file.
Once again, this security feature could have been defeated by a dead simple attack as it’s badly implemented. We expected the key to be mandatory for user logon and protect from file tampering but none of these were enabled.
It’s hard to give any good points there…
Conclusion
It’s always a pleasure to do an in-depth security trip and I would like to thank the engineers and programmers who designed this system. Of course, design flaws that could have been easily prevented exist and compared to OWASP Top 10 security standard the system fails on 4 rules:
- Sensitive data exposure
- Broken access control
- Security misconfiguration
- Using components with known vulnerabilities
The main pain point is the lack of security in depth and what appears to be a false sense of security because of the “TPM” / “Bitlocker” combo. As soon as this protection is broken, all the others flyby. The biggest advice we could give to designers is to never build security like a chain where only one weak link can fail and lead to a whole system being compromised.
This should remind us to take a step back and have a look at how we design our systems, not sacrificing any key principles (like availability) and letting open dead simple doors (like clear channel communication). Successful attacks are not necessarily the most sophisticated ones.
Reading
- Intel LPC Interface Specification
- RD1049 — LPC Bus Controller Reference Design
- Microsoft — Trusted Platform Module
- Microsoft — BitLocker Countermeasures
- TCG PC Client Specific TPM Interface Specification v1.3
- BitLocker Drive Encryption (BDE) format
- Extracting BitLocker keys from a TPM
