Cisco Secure Boot is a secure startup process that ensures the integrity of the firmware running on Cisco hardware devices. To perform this validation each time the device resets, Cisco developed a separate, special-purpose hardware device, known as the Trust Anchor module (TAm), as a root of trust for the secure boot process. After system power-on, the TAm runs the first instructions, which immediately verify the integrity of the bootloader. Should any failure be detected, the device alerts the user and reboots the device, thus preventing the device from executing the modified bootloader.
How is Cisco’s Trust Anchor implemented?
At the design level, the hardware anchor is implemented using an external FPGA. After initial power-on, the FPGA loads an unencrypted bitstream implementing the hardware Trust Anchor to provide root of trust functionality from a dedicated Serial Peripheral Interface (SPI) flash chip. Once the bitstream is loaded, the FPGA performs integrity verification of the pre-boot environment, before the microloader is delivered to the main processor. The FPGA anchor is connected to the main processor via its south bridge and controls the reset pin of the processor. If the FPGA anchor detects any integrity violations in the pre-boot environment, the anchor halts and reboots the system.
What is the vulnerability in Cisco’s Trust Anchor?
An attacker with root privileges on the device can modify the contents of the FPGA anchor bitstream, which is stored unprotected in flash memory. Elements of this bitstream can be modified to disable critical functionality in the TAm. Successful modification of the bitstream is persistent, and the Trust Anchor will be disabled in subsequent boot sequences. It is also possible to lock out any software updates to the TAm’s bitstream.
On what device(s) did you demonstrate the vulnerability?
The vulnerability was demonstrated on a Cisco ASR 1001-X router, but we believe it to affect a number of other systems that also feature TAm implementations.
How widespread is this?
This vulnerability affects Cisco products with an FPGA based TAm. Please refer to Cisco’s website for specific models and versions.
Are there available tools to detect if someone has used this exploit against me?
There is no such tool available at the moment. We will present our detection and mitigation technique in a talk at BlackHat USA 2019.
Can IDS/IPS detect or block this attack?
Does this vulnerability apply only to Cisco’s products?
Yes, this vulnerability is specific to Cisco’s proprietary FPGA-based hardware Trust Anchor implementations.
What are the implications of demonstrating modification of the FPGA bitstream?
Our findings support the practical exploitation of FPGA-based devices via direct bitstream analysis and modification. Through our research we developed a series of techniques to reliably add, subtract, and alter FPGA behavior without any need to perform register-transfer level (RTL) reconstruction. By demonstrating successful FPGA modification on the Xilinx Spartan 6 LX45T, we find that our bitstream manipulation techniques present a range of potential applications for persistent FPGA implants, physical destruction of embedded systems, and attacks against FPGA-based systems, such as software-defined radios, advanced automotive driver assist modules, weapon guidance systems, and more.
Have these vulnerabilities been exploited in the wild?
We are unaware of any use of this exploit in the wild, but the potential danger is severe.
Who discovered these vulnerabilities?
The Cisco Trust Anchor vulnerability was discovered by Jatin Kataria, Richard Housley, and Ang Cui of Red Balloon Security, Inc. The remote command injection vulnerability against Cisco IOS XE 16 was discovered by James Chambers, also of Red Balloon Security.
Who coordinates a response to these vulnerabilities?
Following our discovery of these two vulnerabilities, we reported them to the Cisco Product Security Incident Response Team (PSIRT) on November 8, 2018. We have worked with PSIRT since then to coordinate the public disclosure.
What action can be taken?
Please consult Cisco’s official security advisory. We did not receive early access to Cisco’s security patch, and will be analyzing the patches as they are made publicly available. Since 😾😾😾 is fundamentally a hardware design flaw, we believe it will be very difficult, if not impossible to fully resolve this vulnerability via a software patch.
How do you describe the meaning of this vulnerability name?
We chose to communicate 😾😾😾 through a visual representation of symbols, rather than “words.” Naming vulnerabilities using emoji sequences instead of other pronounceable natural languages have several advantages. First, emoji sequences are universally understood across nearly all natural languages. Choosing 😾😾😾 instead of a name rooted in any one language ensures that the technical contents of our research can be discussed democratically and without latent cultural or linguistic bias. Second, emojis are indexical to the digital age. Third, clear communication is the foundation of friendship, and such a foundation must begin with proper ontological agreement. Just as the universal language of mathematics is largely expressed through interlinguistic symbology, so too is 😾😾😾. Fourth, cats are seen as almost paradoxical beings. While they exist in our lives as the ultimate creatures of leisure, cats are also fierce predators. “Cats are the most highly specialized of the terrestrial flesh-eating mammals. They are powerfully built, with a large brain and strong teeth. The teeth are adapted to three functions: stabbing (canines), anchoring (canines), and cutting (carnassial molars).” ( Lariviere, Serge; Stains, Howard James. “Feline.” Encyclopedia Britannica. Feline). For an incomplete list of felines in various mythologies, see this webpage.
How do you pronounce this vulnerability name?
There is no phonetic transcription for this specific sequence of repeated emojis, and the pronunciation is open to interpretation. We suggest “Thrangrycat” as a suitable enunciation.