SoK How Not to Architect Your Next-Generation TEE Malware

2025-04-24 0 0 647.5KB 10 页 10玖币

侵权投诉

SoK: How Not to Architect Your Next-Generation TEE Malware?

Kubilay Ahmet Küçük∗

kucuk@cs.ox.ac.uk

Cyber Security Centre,

University of Oxford, UK

Steve Moyle

steve.moyle@cs.ox.ac.uk

Cyber Security Centre,

University of Oxford, UK

Andrew Martin

andrew.martin@cs.ox.ac.uk

Cyber Security Centre,

University of Oxford, UK

Alexandru Mereacre

mereacre@nquiringminds.com

Nquiringminds

Southampton, UK

Nicholas Allott

nick@nquiringminds.com

Nquiringminds

Southampton, UK

ABSTRACT

Besides Intel’s SGX technology, there are long-running discussions

on how trusted computing technologies can be used to cloak mal-

ware. Past research showed example methods of malicious activities

utilising Flicker, Trusted Platform Module, and recently integrating

with enclaves. We observe two ambiguous methodologies of mal-

ware 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 aecting 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; re-

maining 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 misconcep-

tions (myths) outlining how an overt-malware using SGX weakens

malware’s existing abilities. We nd the dierences 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.

CCS CONCEPTS

•Security and privacy →Security in hardware

;Malware and

its mitigation; Software security engineering; Security requirements.

KEYWORDS

Malware in commodity systems, Malware in Enclave, Software

Guard eXtensions (SGX), Trusted Execution Environments (TEE),

Evil Light Bulb (ELB) in IoT

Author’s Manuscript. Open Access, Non-Commercial Version.

This manuscript is accepted on 20 September 2022 for publication.

Kubilay Ahmet Küçük, Steve Moyle, Andrew Martin, Alexandru Mereacre,

and Nicholas Allott. 2022. SoK: How Not to Architect Your Next-Generation

TEE Malware?. In Hardware and Architectural Support for Security and

Privacy (HASP 22).

∗

Corresponding Author, reachable at kucuk@acm.org after the expiry of the institu-

tional aliations.

1 INTRODUCTION

Today it is highly likely that the majority of commodity systems

are exposed to malicious software due to their highly complicated

software stack. One of the revolutionising techniques in ghting

malware is to utilise trusted hardware enclaves. However, using

enclaves has also provoked discussions, and misconceptions leading

to myths about whether attackers can utilise these enclaves for

adversarial purposes. Similar to end-user computers, home IoT

deployments suer from the same problem. Nowadays, most home

Internet of Things (IoT) deployments contain insecure, untrusted,

outdated devices installed in houses, permanently spying on users.

We consider the malware living in commodity systems and home

IoT deployments as the malware in the wild.

An example of malware in the wild is a light bulb in a smart

house. The light bulb may contain a full Linux software stack, al-

ways online in the network, sning and spying on the home WiFi

network, and constantly leaking user assets. We group these types

of harmful IoT devices as Evil Light Bulbs (ELB), as the malware

living in a highly noisy commodity environment. Trusted hard-

ware technologies, e.g., Trusted Execution Environments (TEE),

also ght back against ELB by securing the IoT deployments

We examine whether malware in ELB can utilise trusted hardware

to be more powerful in attacks towards industrial IoT and smart

home IoT deployments. Our arguments and the misconceptions

discussed in Section 3 for wild malware and enclave-based malware

in computers are also valid for ELB in IoT deployments.

Paper Structure:

We structured this paper into four main cate-

gories. First, we describe the frequently seen characteristics of an

ideal malware. Second, we demonstrate existing malware evasion

techniques and high-scale, eortless malware distribution tech-

niques. We show non-TEE malware evasion techniques and a de-

livery campaign for two reasons; (1) to dene the assumptions

and review the scope of malware detection, (2) to demonstrate a

real-world scenario on scalable infection to give readers an under-

standing of malware in the wild. Third, we systematically evaluate

twelve misconceptions on malware in TEE and present why these

myths are far from the truth in practice. Finally, we compare the

malware in the wild with enclave-based malware and see if utilising

enclaves provides any additional benets to malware in practice.

Theme:

The theme of this paper is to evaluate TEE-assisted

malware development from the perspective of malware developers

(bad actors), understand malware characteristics and requirements,

https://www.iotsecurityfoundation.org/best-practice-guide-articles/device-secure-

boot/

arXiv:2210.06792v2 [cs.CR] 31 Oct 2022

Küçük et al.

and evaluate systematically whether TEE assistance can fulll the

implementation details of a stronger malware. Section 4 relates

to this theme by comparing a TEE assisted malware with wild

malware in a system. The relation of Section 5 to the paper’s theme

is to discuss the remaining aspects potentially being abused by

bad actors, and how these aspects should be considered in future

trusted hardware designs. We do not intend to discuss how attackers

should be developing malware in next-generation TEE. We show

why attackers would nd developing malware with TEE infeasible.

We hypothesise that malware in TEE gives no new advantages

to attackers; we will discuss how it brings disadvantages in some

cases.

Contributions:

This study presents the most comprehensive

collection of misconceptions about malware in enclaves to date.

Our novel contribution is that we systematically show why mal-

ware becomes weaker due to trusted hardware. We also clarify the

ambiguity of malware in an SGX-enclave and the malware in the

core SGX ecosystem.

Concepts:

Throughout the paper, we may use the following

synonyms. Wild malware refers to malware in commodity sys-

tems, malware in the untrusted world, ELB in IoT deployments, or

malware in a highly noisy system. Enclave-based malware refers

to a malicious code placed in a custom developed enclave, SGX-

malware, SGX-based malware, malware based on trusted hardware,

or malware in TEE. In order to distinguish the core SGX ecosystem

from custom developed enclaves, we provide a detailed denition

in Section 1.3.

1.1 Scope of Malware

Malware presence can be in various forms; virus, worm, trojan,

zombie/botnet, phishing/spam, spyware, keylogger, snier and ran-

somware. Throughout this paper, we refer to this section for the

precise scope of the malware. We take into account specically the

malicious software targeting Windows PCs. Nevertheless, most of

our systematisation can also be valid for Linux distributions and OS

X systems (Intel, non-ARM). Malware targeting other commodity

operating systems, advanced persistent threats (APT), and other rel-

atively harmful software can be explored outside of this paper. We

keep relatively badly behaving software outside of the malware def-

inition. A bad program is one, when found and analysed by an AV

company, is subsequently detected by their malware detection sys-

tems. Finally, we consider malware as malicious software tailored

for disruption, damage and unauthorised access to the commodity

computer system. We describe the characteristics of malware in

more detail in Section 1.2. Similar to malware in a single computer,

an IoT deployment with tens of devices in a house suers from the

same problems due to ELB.

1.2 Characteristics of Malware

The ideal malware must

have the characteristics listed below for

a successful malware campaign. However, one of the fundamental

issues is that these characteristics can also be seen in benign and

legitimate software. Having these characteristics in benign soft-

ware makes malware detection a challenging task for anti-malware

mechanisms.

Others may structure these characteristics or malware patterns in an alternative way.

1.2.1

Persistence across boot cycles/load at startup

.The mal-

ware must be able to reload itself whenever the system is available.

This can be done via scheduled events, registry entries, drivers and

functions in other processes. Section 3.5 presents the persistence

aspect of enclave-assisted malware.

1.2.2

Communication on demand

.Ideally, the malware must

be able to communicate with the author to receive commands or

leak information whenever required. Communication might be nec-

essary for reselling the network of victims, fetching a new payload

or ready-to-use new exploits, or equipping malware with up-to-date

zero days to be exploited. A secure communication channel is also

required for the key management; whether the keys are managed

locally or through external servers, the malware must have a direct

or indirect key management channel. We present the communica-

tion aspects in Section 3.3 and Section 3.6, and key management

aspects in Section 3.2 and Section 3.4.

1.2.3

Full Un-Detection (FUD)

.The malware must remain fully

undetected throughout its life cycle against any possible detection

mechanisms. At a minimum, this can be done via resilience to all

anti-virus software products in the market. FUD checks can be done

oine via automated environments without leaking the know-how

of malware. We present the arguments on detection in Section 3.1

and Section 3.7.

1.2.4

Access to system calls/APIs

.Ideal malware must be able

to access kernel functionalities, system calls, and Application Pro-

gramming Interfaces (APIs) present for low-level operations. Access

to the full system is especially necessary for targeted attacks where

a victim user’s core assets are extracted. Section 3.8 presents the

arguments on syscalls.

1.2.5

The highest possible privileges

.The malware must es-

calate into privilege levels present in a system as high as possible.

Most attacks may begin at the lowest level of permissions; however,

successful malware must be equipped with the necessary payloads

to exploit the rest of the system. Section 3.5 and Section 3.9 present

the arguments on malware privileges.

1.2.6

Unrestricted resources and assets

.Ideally, malware must

be able to use all system resources without restrictions. Resources

may refer to all devices/components other than computational abil-

ities and full memory access. These resources may also contain the

target user assets and valuable information. We present the argu-

ments on resources in Section 3.10 and on user assets in Section 3.4.

1.2.7

Infect more targets, audience and availability

.Ideally,

malware must aim to infect more victims in a campaign. Infection

rate can be a success measure for malware. A malicious attack

targeting one specic system might fall into the APT category. For

compatibility, the target system must full the requirements of

the malware at infection time. Further, if the malware has specic

dependencies to operate, these dependencies must continue to be

available. We present the arguments on target victims in Section 3.11

and malware availability in Section 3.3.

1.2.8

Maximise revenue/profit and long-term maintenance

The goal of malware should be to increase its prot above all. The

monetisation of a campaign might be a way to see the prot, but the

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

SoK:HowNottoArchitectYourNext-GenerationTEEMalware?KubilayAhmetKüçük∗kucuk@cs.ox.ac.ukCyberSecurityCentre,UniversityofOxford,UKSteveMoylesteve.moyle@cs.ox.ac.ukCyberSecurityCentre,UniversityofOxford,UKAndrewMartinandrew.martin@cs.ox.ac.ukCyberSecurityCentre,UniversityofOxford,UKAlexandruMereacremere...

展开>> 收起<<

SoK How Not to Architect Your Next-Generation TEE Malware.pdf

共10页,预览2页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

SoK How Not to Architect Your Next-Generation TEE Malware

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: