Intel SGX Malware

SGX Basics:

Intel SGX is designed to let software run on untrusted systems while keeping its secrets safe.
It does so by having having untrusted environments for general use by the host applications and
trusted enclaves that handle sensitive operations for the host applications. In SGX, the Intel
hardware prevents any outside access to the enclave code and data. However, a potential concern
for this system is whether or not an attacker could use the enclave to hide malware from the rest
of the system.

General Idea/Threat Model:

A general threat model for SGX-based malware is as follows:

Attacker: Controls enclave used by host application and puts their malware inside
it so it cannot be seen by the outside world

Victim: Uses malicious third party enclave with benign arbitrary host application

Potential scenarios where this might occur:

An attacker advertises their enclave as doing an interesting decryption or other
security operation needed by an application and tricks the user into using it or
an application that uses it.

A government requires use of its enclave for digital signatures and inserts their
hidden code into the enclave where it can go undetected.

Getting Around Enclave Restrictions:

However, there is a potential problem with enclave-based malware: the strict Intel launch process,
which in most cases prevents suspicious or malicious code from being able to be launched because
of its lack of verified signature key. Researchers have found 4 ways to get around this issue and
they are described below: 

-Verify a benign looking enclave that decrypts malicious payloads at runtime

-Intel white lists signature keys to be used by enclave developers basically at
will and it is relatively easy to get a key through Intel’s process, so an attacker
could obtain a key as a developer in this fashion.

-SGXv2 has the option to bypass Intel verification when launching altogether 

-Attackers could target enclave vendors to either take their keys or insert malware
into their benign enclaves

Is Enclave Malware a Big Deal?

If you are familiar with SGX, one of your first thoughts may be that enclave malware shouldn’t
be worse than regular malware because of the limitations of enclave execution, even though it
is hidden. Additionally, the enclave should not be able to perform more privileged operations than
the host program in the first place. However, researchers have found a way to stealthily bypass its
host application to gain arbitrary code execution by escaping the limited SGX execution
environment. In essence, this comes down to a Threat Model problem: Intel SGX only considers
the case of trusted enclaves running on untrusted hosts. Enclaves are assumed by default to be
trustworthy and fall outside of the threat model described by Intel. Researchers are essentially
flipping this threat model around, with a malicious enclave taking advantage of its host. 

Enclave malware, however, turns out to be noteworthy because it allows attackers to spread
zero day exploit code without revealing it, and trigger it all at once when it has been distributed.

How It Works: Attack Overview

Overview

The attack starts within the malicious enclave environment. With no access to syscalls
or the host application memory, the enclave essentially starts out blind. But, researchers
have developed read and write primitives within the SGX environment using TSX that allow
it to search for ROP gadgets. This process will be explained in more detail later on. After
finding the gadgets, it writes them and other code and data to locations it found to be writable
using the write primitive called caves. Finally, the enclave creates a ROP chain from the gadgets
it has written into memory and transfers control to the ROP chain to achieve its desired outcome.
The ROP chain will run with host privileges and context by default, but there are ways to execute
arbitrary code by making code written into caves executable. After execution, the program can
hide its tracks and continue normal execution. 

Importantly, the malicious enclave does not rely on any assumptions made about the host
application besides it calling the enclave, and bypasses ASLR and other common stack protections
like stack canaries in its methodology.

Attack Components In Detail:

ROP (return oriented programming):

ROP is the method by which an attacker uses existing code snippets in libraries or other locations
to piece together assembly code and achieve their desired outcome without needing to be able to
write or execute their own assembly. Code snippets in ROP are called gadgets.

TSX (Transactional Synchronization eXtensions):

TSX implements transactional memory using CPU cache for Intel. This system marks cache lines (64 B) as part of either the read set or the write set, and throws its own exceptions or flags if a line is marked as belonging to both sets. Transactional memory can be used as a security feature for detection of rootkits or protecting cryptographic keys on untrusted systems, but in this case especially can open new attack vectors as seen in the next section.

TAP (TSX-based Address Probing):

Researchers found that by wrapping a memory access in a TSX transaction, TSX catches potential
exceptions without triggering any alarms and reports them back to the caller. This allows for
attackers to find what sections of memory they can read without notifying the OS, enabling the
gadget search portion of this attack to execute stealthily.

Diverting Control Flow:

The enclave can write into host application space as detailed below, allowing it to do the following:

CLAW (Checking Located Addresses for Writability):

CLAW uses TSX to check if the memory section is writable and all 0’s, if so it is assumed safe
for attacking purposes and will be 0’d out after use. The sections found by CLAW that have these
properties are used to create data caves that store malicious code and data for the ROP chain to
call and use.

Attack/Exploit PoC:

Researchers have created a proof of concept for this attack method that is hosted on
github and linked in the sources. The flow of this PoC is as follows:

1. Start with host application with malicious enclave
2. Host application enters/calls the enclave
3. Enclave uses TAP and CLAW to find gadgets it needs to find data cave candidates and write code and data to them
4. Enclave uses TAP to create a ROP chain, in this case creating a file and displaying a ransom message
1. Note that a real attack would encrypt files instead of making one
5. Divert control flow to let host application execute ROP chain
6. Clean up and continue normal execution

This PoC exploit only takes 20.8 seconds on average as reported by researchers, which is relatively
fast considering the amount of random memory searching it is doing. In this example the malware
within the enclave is ransomware, however researchers also note that the malware could take other
forms such as being used in a DDoS attack or to send phishing emails among others.

Sample PoC Program Output from Github:

Intel’s Response:

Intel responded to this research with this statement: 

“Intel is aware of this research which is based upon assumptions that are outside the
threat model for Intel SGX. The value of Intel SGX is to execute code in a protected
enclave; however, Intel SGX does not guarantee that the code executed in the enclave
is from a trusted source. In all cases, we recommend utilizing programs, files, apps, and
plugins from trusted sources. Protecting customers continues to be a critical priority for
us and we would like to thank Michael Schwarz, Samuel Weiser, and Daniel Grus for
their ongoing research and for working with Intel on coordinated vulnerability disclosure.”

Their response gets back to some of the core issues of security: Threat Modeling and Issues with
Trust. Intel does not consider the enclave based malware developed by researchers to be within their
Threat Model, and thus ignore it. Additionally, while the Intel SGX model handles trusted code
execution on untrusted systems, it does not handle the issue of what code to trust and leaves that
to the users.

Sources

https://arxiv.org/pdf/1902.03256.pdf - attack paper

https://github.com/IAIK/sgxrop - attack github poc code

https://www.zdnet.com/article/researchers-hide-malware-in-intel-sgx-enclaves/ - attack article on paper

https://www.theregister.co.uk/2019/02/12/intel_sgx_hacked/ - another attack article on same paper

https://eprint.iacr.org/2016/086.pdf - sgx paper

https://www.youtube.com/watch?v=zRI8diZTEB0 - ROP image