SoK: How Not to Architect Your Next−Generation TEE Malware?
Kubilay Ahmet Küçük‚ Steve Moyle‚ Andrew Martin‚ Alexandru Mereacre and Nicholas Allott
Abstract
Besides Intel's SGX technology, there are long-running discussions on how trusted computing technologies can be used to cloak malware. Past research showed example methods of malicious activities utilising Flicker, Trusted Platform Module, and recently integrating with enclaves. We observe two ambiguous methodologies of malware development being associated with SGX, and it is crucial to systematise their details. One methodology is to use the core SGX ecosystem to cloak malware; potentially affecting a large number of systems. The second methodology is to create a custom enclave not adhering to base assumptions of SGX, creating a demonstration code of malware behaviour with these incorrect assumptions; remaining local without any impact. We examine what malware aims to do in real-world scenarios and state-of-art techniques in malware evasion. We present multiple limitations of maintaining the SGX-assisted malware and evading it from anti-malware mechanisms. The limitations make SGX enclaves a poor choice for achieving a successful malware campaign. We systematise twelve misconceptions (myths) outlining how an overfit-malware using SGX weakens malware's existing abilities. We find the differences by comparing SGX assistance for malware with non-SGX malware (i.e., malware in the wild in our paper). We conclude that the use of hardware enclaves does not increase the preexisting attack surface, enables no new infection vector, and does not contribute any new methods to the stealthiness of malware.
Journal
Hardware and Architectural Support for Security and Privacy (HASP 22)
Keywords
malware‚ trusted execution environment‚ tee‚ sgx‚ software guard extensions‚ ransomware
Note
Besides Intel's SGX technology‚ there are long−running discussions on how trusted computing technologies can be used to cloak malware. Past research showed example methods of malicious activities utilising Flicker‚ Trusted Platform Module‚ and recently integrating with enclaves. We observe two ambiguous methodologies of malware development being associated with SGX‚ and it is crucial to systematise their details. One methodology is to use the core SGX ecosystem to cloak malware; potentially affecting a large number of systems. The second methodology is to create a custom enclave not adhering to base assumptions of SGX‚ creating a demonstration code of malware behaviour with these incorrect assumptions; remaining local without any impact. We examine what malware aims to do in real−world scenarios and state−of−art techniques in malware evasion. We present multiple limitations of maintaining the SGX−assisted malware and evading it from anti−malware mechanisms. The limitations make SGX enclaves a poor choice for achieving a successful malware campaign. We systematise twelve misconceptions (myths) outlining how an overfit−malware using SGX weakens malware's existing abilities. We find the differences by comparing SGX assistance for malware with non−SGX malware (i.e.‚ malware in the wild in our paper). We conclude that the use of hardware enclaves does not increase the preexisting attack surface‚ enables no new infection vector‚ and does not contribute any new methods to the stealthiness of malware.
