Hardware that is vulnerable to the xAPIC and MMIO vulnerabilities is widely available. We purchased a machine that is specifically vulnerable to the xAPIC variant, and registered it on the Secret Network by following the "Full Node Setup" instructions, resulting in storing a sealed consensus seed on our node. Next, we exploited the vulnerability on our own node to extract the consesus seed during the unsealing process.

To understand the difficulty involved, it helps to think of the attack as having two phases, Prepare and Exploit. The Prepare phase is technically simple and just involves joining a new node to the network like an ordinary node operator. An attacker would have needed to obtain a vulnerable processor/BIOS configuration and complete the registration process before the Registration Freeze mitigation on Oct 4.

The Exploit phase is a offline computation attack carried out against the local sealed copy of the consensus seed, without any interaction on the network. While this step is technically-involved and likely requires an in-depth understanding of the xAPIC vulnerability, attackers who completed the Prepare phase prior to Oct 4 could complete this step at their leisure, even now or in the future.

To summarize, only the prepare phase of the attack was time critical, since joining a new vulnerable node to the network has not been possible since Oct 4. However, no expertise would have been needed, just acquiring an appropriate PC.

The primary mitigation was a “Registration Freeze,” enacted shortly after our disclosure, on October 4, 2022. This works by revoking the developer’s SPID key with Intel Attestation Services (IAS), blocking new node registration altogether. Anyone attempting to register a new platform on Secret Network would fail to obtain a signed attestation report from IAS, and would therefore see an error message.

After the initial Registration Freeze, the registration process has been gradually reopening. First, an allow-list was implemented so that non-vulnerable processor types can again join the network. Additionally, after SGX TCB Recovery, even previously-vulnerable hardware will be allowed to join the network as long as their microcode has been patched.

See also Secret's blog for more information.

• December 5, 2021: Initial private disclosure from AepicLeak authors between Intel.
• August 9, 2022: The AepicLeak vulnerability was publicly disclosed.
• October 1, 2022: We confirmed that AepicLeak applies to Secret Network and initiated our own vulnerability disclosure to Secret Network developers.
• October 4, 2022: Registration Freeze was implemented by Secret Network developers by revoking developer SPID keys.
• November 2, 2022: Registration is partially reopened by letting allow-listed (non-vulnerable) hardware to join.
• November 29, 2022: TCB Recovery: Registration can now be further relaxed to allow previously-vulnerable hardware to join, since remote attestation can ensure it has updated its microcode.

The most critical time window was therefore from August 9 to October 4. Any non-sophisticated attacker that began their attack in that time window by registering a vulnerable node on the network, would have completed the prepare phase of their attack in time, and would most likely succeed as the exploit phase eventually.

A list of processors affected by the xAPIC vulnerability can be found from Intel's SA-00657 advisory. We found a line of widely available inexpensive PCs that are affected by the xAPIC vulnerability and successfully pass Secret Network's attestation checks. Customers of a cloud service running nodes would not be able to mount the attack, though administrators at the cloud provider plausibly could. To summarize, motivated attackers could have easily obtain vulnerable hardware, and individual node operators may even have inadvertently registered vulnerable instances.

The main reason why devices already known to be vulnerable were allowed to join the network has to do with Intel's TCB Recovery timelines. Put simply, when an SGX vulnerability is made public, even if there are microcode patches available, IAS may not reject unpatched devices right away, so as to give vendors time to update their machines. In this case, even though the attack was known, the attack resulted in a complete compromise of enclave signing keys, and the source code to carry out the attack was publicly available, still the original TCB Recovery timeline was projected to take months.

The consensus seed can be used to derive decryption keys for the entire Secret Network. Breaching this enables decrypting all the encrypted messages that interact with smart contracts as well as all smart contract state. The most concerning application of this attack is bulk surveillance of Secret users’ personal finances. Other concerning applications are the breach of private metadata from secret NFTs, as well as front-running DeFi applications. Note that the integrity of the blockchain is still assured, so in general, funds are safe and only the privacy and confidentiality of the blockchain is threatened. However, any digital assets that rely on private metadata, such as NFTs exchanging secret authentication keys, would be at risk of theft.

Users relying on Secret for privacy or confidentiality should consider that the confidentiality of their past transactions is no longer guaranteed. Update your risk analysis with this potential data breach in mind. For node operators, applying software updates from the developers can further reduce the potential of a data breach.

We completed the Exploit phase of the attack using two approaches, initially working as two independent teams that joined up later. Team 1 made a specialized effort by applying the xAPIC vulnerability directly to Secret. Team 2 made use of a powerful generic tool, EGX, which is a scientific contribution central to the SGX.Fail research paper. Since EGX hasn’t been published until now, an attacker would not have had access to it. However, overall our experience suggests that any motivated security expert would eventually complete the Exploit phase of the attack. Again, regardless of how the Offline phase is completed, the only time-sensitive step was the Online Phase of registering a vulnerable node on the network.

Preparing the attack by following the ordinary documentation leaves a network trace, since a registration transaction containing an attestation reports must be submitted on-chain. Secret developers have estimated that 4% of nodes registered before October 4 were potentially vulnerable. However, it was also possible to prepare the attack in an offline way (without any registration transaction at all) that uses an existing non-vulnerable node and locally invokes the ecall_authenticate_new_node method to generate a sealed consensus seed for the vulnerable node. An attacker would still have needed to complete an IAS attestation prior to October 4, but they would not have needed to interact with the blockchain network. Thus the estimate based on registration data does not include deliberately-stealthy attackers.

Given the past history of SGX vulnerabilities and the process of TCB Recovery, it’s essential to anticipate potential future vulnerabilities and have a mitigation plan in place. For example, Secret Network could automatically enact a Registration Freeze immediately following a public disclosure or 0-day announcement.

Secret’s documentation should reconsider its claims about SGX vulnerabilities, such as that they are only theoretical or require a laboratory setting to carry out. Not only have we shown this is not accurate, but it wasn’t well justified given the past history of vulnerabilities either. Previous vulnerabilities like Foreshadow and CacheOut had similar consequences and timelines, hence we should anticipate the potential for future instances like this as well.

In Secret, clients who wish to send private messages to interact with smart contracts do so by first encrypting their messages, which are later decrypted inside of enclaves and processed. The way this works is there is a public value called the io_exchange_public_key which is a Curve25519 generator multiplied by an unknown scalar (the io_exchange_private_key, which is known to all enclaves). To encrypt a message to the network, a client samples their own private scalar and performs Diffie-Hellman key exchange against the io_exchange_public_key to derive a symmetric AES key. The message is encrypted under this key and the ciphertext is sent alongside the Curve25519 generator multiplied by their private scalar. Enclaves are able to parse this message, derive the same symmetric key, and decrypt and process the message.

In short, knowledge of the io_exchange_private_key is sufficient to decrypt all confidential transactions from outside of an enclave. Hence, the goal of this Proof of Compromise is to prove that we at one point knew this value.

The io_exchange_public_key for the Secret-4 mainnet is: 0x083b1a03661211d5a4cc8d39a77795795862f7730645573b2bcc2c1920c53c04

We have produced a signed message here under the Axolotl 25519 signature scheme, which can be verified under the io_exchange_public_key.

In the Proof of Compromise section, we provided a value which we claim is the io_exchange_public_key for the mainnet, under which we signed a "capture the flag" message. Here we provide an explanation of a possible method by which an interested reader can verify that we provided the correct value (as opposed to the public component of a keypair we generated ourselves).

If you have a working installation of secretd, run secretd query register secret-network-params followed by secretd parse ./io-master-cert.der.

Otherwise, follow Secret Network's tutorial for setting up the secretcli, and then run secretcli query register secret-network-params to get the io-master-cert. This can be parsed with OpenSSL to get a JSON blob from the Netscape Comment field. Base64 decode the "report" field of this blob to get another JSON blob, from which the "isvEnclaveQuoteBody" should be decoded from base64 into hex. The last 32 non-zero bytes of the hex will be the io_exchange_public_key. All of this can be done with the following command: openssl x509 -in ./io-master-cert.der -inform der -noout -text | grep -oP '(?<="report":")[^"]*' | base64 -d | grep -oP '(?<="isvEnclaveQuoteBody":")[^"]*' | base64 -d | od -tx -j 368 -N 32 -An --endian=big | tr -d ' ' | tr -d '\n'

We observed that PowerDVD can playback AACS2 content on an unpatched Intel Core i7-6820HQ (Skylake) that is vulnerable to the Foreshadow attack. We then mounted the Foreshadow attack and extracted the SGX attestation keys for this machine, which then allowed us to sign our own attestation reports. With the ability to sign our own attestation reports, we could then run CyberLink's enclaves outside of Intel SGX and fully reverse engineer them. More specifically, we ran the code that contacts the service to provision AACS2 keys outside of Intel SGX, which unable to distinguish our rogue implementation from a real one, provisions us with the AACS2 keys.

An operating system (OS) is system software responsible for managing your computer hardware by abstracting it through a common interface, which can be used by the software running on top of it.

Furthermore, the operating system decides how this hardware is shared by your software, and as such has access to all the data stored in your computer's memory. Thus, it is essential to isolate the operating system from other programs running on the same machine.

Unified Extensible Firmware Interface (UEFI) is a specification defining the software interface between the operating system and the platform firmware. UEFI generally refers to the platform firmware that is responsible for booting the system and any of its components before starting the operating system. This replaces the Basic Input/Output System (BIOS) that was originally used to boot IBM PC-compatible computers, and hence BIOS is still in common use to refer to the platform firmware.

CPU microcode forms the translation layer between the high-level standard CPU instructions coming from the software that the CPU has to interpret, and the low-level CPU operations specific to the particular CPU that the underlying hardware can actually execute. This microcode is first loaded by the CPU, and may later in the boot process be replaced by newer microcode updates through the BIOS/UEFI or the OS. Thus, a microcode update allows the CPU manufacturer to alter low-level behavior of a given CPU in the event that new bugs are discovered.

Intel Security Guard Extensions (SGX) offer an even stronger isolation guarantee that allows third parties to run their software in secure enclaves, with protection against a compromised operating system and/or hypervisor.

Intel SGX allows third-parties to run code on your machine with the guarantee that the code cannot be compromised. However, without the ability for the enclave to prove its genuineness to remote parties over the network, Intel SGX would be useless. This is where remote attestation comes into play, as it allows your computer to cryptographically prove that your information is protected by a genuine Intel machine.

Remote attestation in Intel SGX is interesting for many kinds of application where a third-party wants to run code on your machine with the guarantee that it cannot be compromised. Developers are slowly adopting Intel SGX to develop such applications, including blockchains, DRM and secure data storage for contacts and fingerprints.

In the context of Intel SGX, a Trusted Compute Base (TCB) is the collection of hardware, firmware and software components critical to the security of Intel SGX.

In the event that a vulnerability gets discovered allowing the compromise of SGX attestation keys, the currently deployed TCB can no longer be trusted. Thus, a TCB recovery is required to mitigate the vulnerability in the TCB and derive new SGX attestation keys to restore this trust.

We found that platforms affected by the xAPIC and MMIO issues, both disclosed on August 9, 2022, were still in TRUSTED state two months after this disclosure date. While the TCB recovery was originally planned to happen no later than March 7, 2023 for platforms using Intel EPID attestation, Intel changed this timeline to November 29, 2022 after our disclosure for some platforms, with popular SGX-enabled servers and desktop only being planned to go through TCB recovery in January 2023.

We provide an overview of existing SGX attacks in our paper, together with information for SGX developers on how they can mitigate these issues, and/or what Intel has done and can do to mitigate these issues. For future vulnerabilities, we also provide a study based on existing mitigation strategies to give developers an idea of what to expect when similar vulnerabilities get discovered and disclosed.

Furthermore, Intel maintains a table of known vulnerabilities and affected CPUs including brief summaries of the vulnerabilities, how to mitigate the vulnerability or how Intel is planning to mitigate the vulnerability. For any vulnerabilities affecting Intel SGX, Intel will indicate that a TCB recovery is required. Furthermore, some vulnerabilities may also include a deep dive, which is a more technical analysis of the vulnerability, especially in the event software hardening is required in addition to a TCB recovery.

Yes, with rights waived via CC0.

You can reach us via info@sgx.fail with any questions about SGX.Fail.