Presentation of SnakeGX presented at ACNS (short version)

1. SnakeGX: a sneaky attack
against SGX Enclaves
Flavio Toffalini - Singapore University of Technology and Design
Mariano Graziano - Cisco Systems, Inc.
Mauro Conti - University of Padua
Jianying Zhou - Singapore University of Technology and Design
ACNS - June 21-24, 2021
1

2. Overview
- SGX Introduction
- Problem description
- SnakeGX
- Evaluation
- Conclusion
2

3. SGX introduction
3
User-space
Kernel-space
Enclave
Intel Software Guard eXtention (SGX)
- Enclaves: isolated memory regions in
user-space
- Enclaves cannot interact with ring-0
software (i.e., no syscall)
- Enclaves can write/read in user-space
- User- and kernel-space cannot write/read
the enclave space
HOW IS THIS ENFORCED?
CPU/MMU/Microcode checks.
OS-independent design.

4. Problem description - SGX issues
4
User-space
Kernel-space
SGX assumes everything outside an Enclave is
malicious (e.g., the OS) [1]
Usually good, however, the OS must trust an
enclave contain bening software
A code-reuse attack could alter the enclave logic,
without breaking the isolation [2,3,4,5]
The OS is not aware of the attack
Enclave
?
? ?
[1] Iago Attacks: Why the System Call API is a Bad Untrusted RPC Interface (SIGARCH 2013)
[2] Hacking in Darkness: Return-oriented Programming against Secure Enclaves (Usenix 2017)
[3] The Guard's Dilemma: Efficient Code-Reuse Attacks Against Intel SGX (Usenix 2018)
[4] A Tale of Two Worlds: Assessing the Vulnerability of Enclave Shielding Runtimes (CCS 2019)
[5] Faulty Point Unit: ABI Poisoning Attacks on Intel SGX (ACSAC 2020)

5. Current memory attacks
State-of-the-art attacks:
5
Forces the enclave to crash and
restart multiple times to “guess”
the correct attack
Dark-ROP
(Usenix 2017)
Relies on code patterns, no
need to crash the enclave
It leaves many structures in
memory
Guard’s Dilemma
(Usenix 2018)
Introduces a new and unexpected
enclave in the system that attracts
the intention of the analyst
SGX-ROP
(Dimva 2019)
// not exactly an attack
Too noisy Too many
traces
Add unexpected
enclaves

6. SnakeGX
Research question:
Is it possible to attack an SGX enclave without being detected by the host OS?
Our proposal: a framework to implant a backdoor in legitimate SGX enclaves
How?
1) Exploiting SGX isolation to avoid memory-inspection
2) Leaving less traces as possible
6

7. Application
SnakeGX - The plan!
Install a backdoor in the victim enclave => add a malicious secure function
Enclave
Secure Function 1
Secure Function N
...
Backdoor
Safe code
Attacker
7

8. SnakeGX - The plan!
Properties:
- Persistent: remains inside the enclave
- Stateful: it saves date and takes decision
- Interactive: can invoke syscalls
Note: The backdoor is entirely composed by code-reuse
techniques (e.g., ROP-chains)
8
User-space
Kernel-space
Enclave
Backdoor
➊
➌
X := 10
➋
➊
➌
➋
More technical details in the paper..

9. User-space
Kernel-space
SnakeGX - Overview
9
Enclave
Backdoor
Payload Installation:
- Attack the enclave
- Install backdoor
- Leave enclave
“untouched”
Payload Triggering:
- Activate backdoor
➊
➋
More technical details in the paper..

10. SnakeGX - Advantages
10
User-space
Enclave
Backdoor
Attacker ORET
- No need to repeat the attack from scratch
- An analyst can found only the trigger, which
footprint is minimal
- Enclave interaction through valid APIs
Kernel-space
More technical details in the paper..

11. The Evaluation
- Use Case: StealthDB
- Trace measurements and comparison with SotA
11

12. Use Case: StealthDB
StealthDB1
is a PostgreSQL extension to perform homomorphic-like encryption by using
SGX enclaves
Application
Enclave
Secure Function
Backdoor
Safe code
Attacker
P_Key (AES key)
backdoor() {
if (P_Key is changed)
exfiltrate(P_Key)
}
ORET
ECALL
12
[1] https://github.com/cryptograph/stealthdb/

13. Use Case: StealthDB
13
Analysis Payload
P1
: checks status and in case
exfiltrates P_Key
Oc
: write P_Key on a socket
P2
: restores the payload for a next
execution
Application
Enclave
P1
Attacker
P_Key (AES key)
P1
() {
if (P_Key is changed)
exfiltrate(P_Key)
}
ORET
OC
P2
ORET
socket

14. Trace measurement
Payload:
Trigger:
14
Chain #functions/syscall #gadget Size [B]
P1
27 23 2816
Oc
13 7 1232
P2
4 20 312
sum 44 50 4360
Chain #functions/syscall #gadget Size [B]
trigger 0 4 56

15. Trace measurement
Payload:
Trigger:
15
Chain #functions/syscall #gadget Size [B]
P1
27 23 2816
Oc
13 7 1232
P2
4 20 312
sum 44 50 4360
Chain #functions/syscall #gadget Size [B]
trigger 0 4 56
Takeaway:
Payload size: 4360B
Trigger size: 56B
size(Trigger) << size(Payload)
Less traces to inspect through
memory-forensic techniques

16. Conclusion
Before
- Current SGX malware introduces unexpected enclaves in the system
- Current one-shot-attacks need to repeat the attack(and leave traces in memory)
Now
- Infecting legitimate enclaves (no new enclaves)
- SnakeGX hides most of the logic inside the enclave (more challenging to detect)
16

17. Thanks for
your attention
17
Have a look at our PoC: https://github.com/tregua87/snakegx