1
00:00:00,000 --> 00:00:01,290
- So today we have Slava Makkaveev

2
00:00:01,290 --> 00:00:03,120
talking to us about
digging into Xiaomi's Tee

3
00:00:03,120 --> 00:00:04,530
to get to Chinese money.

4
00:00:04,530 --> 00:00:06,900
It's Slava's fifth time
speaking at DEF CON.

5
00:00:06,900 --> 00:00:08,373
So please welcome him back.

6
00:00:09,208 --> 00:00:12,208
(audience applause)

7
00:00:16,020 --> 00:00:19,153
- Hello everyone, thank
you for that little talk.

8
00:00:19,153 --> 00:00:22,590
I'm Slava, I have been doing
mobile security research

9
00:00:22,590 --> 00:00:24,960
at Checkpoint for many years.

10
00:00:24,960 --> 00:00:28,950
Rivers engineering and build
research is my daily work.

11
00:00:28,950 --> 00:00:32,700
When I hear the phrase trust
zone or trusted environment,

12
00:00:32,700 --> 00:00:34,968
I imagine some secure place

13
00:00:34,968 --> 00:00:38,700
on a device where
cryptographic is passwords

14
00:00:38,700 --> 00:00:43,110
and as a security sensitive
information is stored, I imagine

15
00:00:43,110 --> 00:00:46,140
that protection is implemented
with hardware assistance

16
00:00:46,140 --> 00:00:50,580
and major mobile cheap
manufacturers, such as media tech

17
00:00:50,580 --> 00:00:53,253
and Qualcomm are responsible
for the business logic.

18
00:00:55,919 --> 00:00:56,752
Okay.

19
00:00:58,140 --> 00:01:01,740
In general, all my assumptions
are correct, but in fact

20
00:01:01,740 --> 00:01:03,870
and this surprises me a little

21
00:01:03,870 --> 00:01:07,410
not only cheap manufacturers
can change the logic

22
00:01:07,410 --> 00:01:10,680
of the trust in quote
running on a smartphone.

23
00:01:10,680 --> 00:01:14,290
Device manufacturers such as Xiaomi

24
00:01:15,330 --> 00:01:18,330
also have the ability

25
00:01:18,330 --> 00:01:21,933
to page the trusted
code and add new items.

26
00:01:23,190 --> 00:01:27,570
In my research, I consider
the trusted code provided

27
00:01:27,570 --> 00:01:29,370
by Xiaomi as a target for text.

28
00:01:29,370 --> 00:01:32,335
And I will show you
several vulnerabilities

29
00:01:32,335 --> 00:01:36,060
in Xiaomi trusted environment which rely

30
00:01:36,060 --> 00:01:37,710
on regular Android application

31
00:01:37,710 --> 00:01:40,593
to steal money from ordinary people.

32
00:01:42,660 --> 00:01:46,050
Well, according to the latest
statistics, the far east

33
00:01:46,050 --> 00:01:50,850
in China account for two sorts
of world's mobile payments

34
00:01:50,850 --> 00:01:53,250
and this is about 4 billion dollars

35
00:01:53,250 --> 00:01:55,623
in mobile wallet transactions.

36
00:01:57,000 --> 00:02:02,000
Let's zoom in, WeChat Pay and Alipay.

37
00:02:03,435 --> 00:02:05,400
are the largest players

38
00:02:05,400 --> 00:02:08,730
in the Chinese mobile payment
industry, to get the account

39
00:02:08,730 --> 00:02:13,730
for about 95% of the all
Chinese payment market.

40
00:02:14,580 --> 00:02:18,240
Each of these platforms
have over 1 billion users.

41
00:02:18,240 --> 00:02:21,150
So actually it's nice to hack only one

42
00:02:21,150 --> 00:02:22,203
of them to get rich.

43
00:02:24,840 --> 00:02:28,020
Today, I focus on a WeChat Pay

44
00:02:28,020 --> 00:02:32,130
built in Xiaomi devices
powered by MediaTek chip.

45
00:02:32,130 --> 00:02:33,630
Why is this particular combo?

46
00:02:33,630 --> 00:02:36,134
Because Xiaomi is the most popular Chinese

47
00:02:36,134 --> 00:02:38,534
smartphone manufacturer.

48
00:02:38,534 --> 00:02:41,820
MediaTek is the most popular
mobile chip manufacturer

49
00:02:41,820 --> 00:02:42,747
in the world.

50
00:02:42,747 --> 00:02:45,630
And WeChat Pay is the most
popular payment platform

51
00:02:45,630 --> 00:02:46,463
in China.

52
00:02:48,210 --> 00:02:50,430
Okay, now let's talk about
the Trusted Environment

53
00:02:50,430 --> 00:02:52,560
a.k.a TEE.

54
00:02:52,560 --> 00:02:55,140
As I mentioned, mobile payment signatures

55
00:02:55,140 --> 00:02:56,703
are carried out in the TEE.

56
00:02:58,029 --> 00:02:59,580
So as long

57
00:02:59,580 --> 00:03:03,273
as TEE is safe, so are your payments.

58
00:03:05,310 --> 00:03:07,830
On the internet, you can
easily find many articles

59
00:03:07,830 --> 00:03:09,960
about the TEE architecture

60
00:03:09,960 --> 00:03:12,407
so I know only

61
00:03:12,407 --> 00:03:14,850
the key points

62
00:03:14,850 --> 00:03:15,690
TEE creates a

63
00:03:15,690 --> 00:03:18,150
virtual security world mainly showed

64
00:03:18,150 --> 00:03:20,190
by a trusted operating system

65
00:03:20,190 --> 00:03:23,310
which runs the trusted applications.

66
00:03:23,310 --> 00:03:26,670
Each trusted application
implements a specific

67
00:03:26,670 --> 00:03:29,520
security feature and the normal world OS

68
00:03:29,520 --> 00:03:32,940
in our cases is Android can send a command

69
00:03:32,940 --> 00:03:36,033
to a trusted app and receive a response.

70
00:03:37,140 --> 00:03:41,430
Xiaomi devices empowered
by qualcomm chip sets and

71
00:03:41,430 --> 00:03:42,263
uses

72
00:03:44,100 --> 00:03:47,883
trusted OS and media tech
based devices use Kinibi.

73
00:03:49,170 --> 00:03:52,219
In both cases, Xiaomi can embed and sign

74
00:03:52,219 --> 00:03:57,219
their own trusted applications.

75
00:03:58,807 --> 00:04:01,120
On Xiaomi devices, you can easily find

76
00:04:02,940 --> 00:04:03,773
trusted apps

77
00:04:03,773 --> 00:04:05,790
in the directory

78
00:04:05,790 --> 00:04:08,940
Thh/ta. Each app is represented

79
00:04:08,940 --> 00:04:13,680
by an encrypted binary file and usually,

80
00:04:13,680 --> 00:04:17,620
trusted applications of the Kinibi OS

81
00:04:18,540 --> 00:04:21,000
have the MCLF file format.

82
00:04:21,000 --> 00:04:23,841
But Xiaomi decided to come up with

83
00:04:23,841 --> 00:04:27,180
one of their own. Actually,
we don't need even to

84
00:04:27,180 --> 00:04:31,390
understand all the format
fields because the initial part

85
00:04:32,555 --> 00:04:36,510
of the Xiaomi's trusted app is a file.

86
00:04:38,970 --> 00:04:42,030
Trusted applications can
have multiple signatures

87
00:04:42,030 --> 00:04:44,040
following the magic fields,

88
00:04:44,040 --> 00:04:46,140
and the magic fields are the same

89
00:04:46,140 --> 00:04:48,960
across all trusted apps on the device.

90
00:04:48,960 --> 00:04:50,703
More the same,

91
00:04:52,440 --> 00:04:53,940
same these apps fields,

92
00:04:53,940 --> 00:04:55,533
overall are the devices.

93
00:05:03,236 --> 00:05:07,440
As you see, the version
control field is emitted

94
00:05:07,440 --> 00:05:10,290
in the trusted apps file format.

95
00:05:10,290 --> 00:05:14,178
It means that in an attacker can transfer

96
00:05:14,178 --> 00:05:18,330
an old versions of the trusted
application to a device

97
00:05:18,330 --> 00:05:21,250
and use it to override the new app file.

98
00:05:22,185 --> 00:05:26,010
As the signature of the
old trusted app is correct,

99
00:05:26,010 --> 00:05:28,767
this app will be successfully
loaded by the GE.

100
00:05:29,717 --> 00:05:34,717
Knowing this an attacker
can bypass security features

101
00:05:36,570 --> 00:05:37,420
and pages

102
00:05:39,764 --> 00:05:41,254
of Xiaomi and MediaTek

103
00:05:41,254 --> 00:05:43,443
in the trusted applications by downgrading

104
00:05:43,443 --> 00:05:46,200
them to an unpatched version.

105
00:05:46,200 --> 00:05:48,453
I will use this vulnerability in my POC.

106
00:05:50,379 --> 00:05:51,715
Okay.

107
00:05:51,715 --> 00:05:54,840
Xiaomi fools the global
platform TEE client

108
00:05:54,840 --> 00:05:58,290
API specification, which
defined the interface

109
00:05:58,290 --> 00:06:01,770
between the client application
and the trusted environment.

110
00:06:01,770 --> 00:06:05,280
This API is implemented
in the libTEEcommon.so

111
00:06:05,280 --> 00:06:06,210
library

112
00:06:06,210 --> 00:06:11,210
and we can use it this library to access

113
00:06:11,477 --> 00:06:14,550
the trusted applications from an Android.

114
00:06:14,550 --> 00:06:17,220
But unfortunately in a
previous Android application

115
00:06:17,220 --> 00:06:19,717
has no permission to
communicate with the TEE.

116
00:06:21,000 --> 00:06:25,413
So Linux prevents access to
the correspondent, the driver,

117
00:06:26,829 --> 00:06:30,420
and it's possible to work
only from a limited number

118
00:06:30,420 --> 00:06:35,420
of produced users, such
as DRM and Media Product.

119
00:06:35,760 --> 00:06:37,590
To bypass we need to use vulnerability

120
00:06:37,590 --> 00:06:39,993
and I will show you one a bit later.

121
00:06:41,460 --> 00:06:43,500
On this slide you can see an example

122
00:06:43,500 --> 00:06:47,940
of how to call a trusted
application from Android.

123
00:06:47,940 --> 00:06:50,848
In this case, I sent a command

124
00:06:50,848 --> 00:06:53,486
to the TEE main trusted app.

125
00:06:53,486 --> 00:06:56,100
This app expects to
receive one input buffer

126
00:06:56,100 --> 00:06:58,971
and one output buffer as arguments.

127
00:06:58,971 --> 00:07:00,263
And the comment ID will be ignored.

128
00:07:01,590 --> 00:07:02,790
Okay,

129
00:07:02,790 --> 00:07:03,990
Trusted apps

130
00:07:03,990 --> 00:07:08,940
implement TA in all common
entry point function.

131
00:07:08,940 --> 00:07:11,640
It handles the command ID

132
00:07:11,640 --> 00:07:14,880
and buffers sent from the Android side.

133
00:07:14,880 --> 00:07:17,507
This function is a perfect
target for finding base on

134
00:07:17,507 --> 00:07:18,417
review to research

135
00:07:18,417 --> 00:07:21,240
And I use classic combination of a fail

136
00:07:21,240 --> 00:07:26,240
and renew emulator to fast
Xiaomi's trusted applications

137
00:07:26,590 --> 00:07:28,260
on to a (inaudible) machine.

138
00:07:28,260 --> 00:07:29,520
A bit, a little later,

139
00:07:29,520 --> 00:07:32,223
I'll show you vulnerability
related to mobile payment.

140
00:07:33,720 --> 00:07:35,182
Okay.

141
00:07:35,182 --> 00:07:38,340
Now we know what is Xiaomi's
trusted environment is.

142
00:07:38,340 --> 00:07:39,580
Let's talk about

143
00:07:40,440 --> 00:07:41,763
payment system. Okay.

144
00:07:42,780 --> 00:07:46,410
More Xiaomi devices have
an embedded mobile payment

145
00:07:46,410 --> 00:07:48,873
framework named Tencent Soter.

146
00:07:52,011 --> 00:07:55,410
Tencent Soter provides
an API to create, sign,

147
00:07:55,410 --> 00:07:59,040
and verify payment packages, transfer it

148
00:07:59,040 --> 00:08:00,750
between the mobile application

149
00:08:00,750 --> 00:08:03,180
and a remote backend server.

150
00:08:03,180 --> 00:08:06,033
WeChat Pay based on the Tencent Soter.

151
00:08:07,470 --> 00:08:10,800
On this slide, you can see
an Architecture of the Soter

152
00:08:10,800 --> 00:08:14,850
and this platform deals
these three levels of keys.

153
00:08:14,850 --> 00:08:18,149
This is device key ATTK,
application key ASK,

154
00:08:18,149 --> 00:08:20,580
business key AuthKey.

155
00:08:20,580 --> 00:08:21,540
Okay.

156
00:08:21,540 --> 00:08:24,330
They are all very safe keys.

157
00:08:24,330 --> 00:08:29,330
And the device key is generated
in the trusted environment

158
00:08:29,460 --> 00:08:31,680
before the device leaves the factory,

159
00:08:31,680 --> 00:08:35,670
and the ATTK public key is
safely transmitted by Xiaomi

160
00:08:35,670 --> 00:08:36,570
to the remote,

161
00:08:36,570 --> 00:08:39,213
to the Tencent TAM server.

162
00:08:40,170 --> 00:08:44,100
Third party, Android
application, such as WeChat

163
00:08:44,100 --> 00:08:46,020
can request to create an application key.

164
00:08:46,020 --> 00:08:51,020
In this case, the private
ASK key will be stored

165
00:08:51,090 --> 00:08:54,330
in the TEE and the public ASK key,

166
00:08:54,330 --> 00:08:59,220
and its device signature, will be uploaded

167
00:08:59,220 --> 00:09:01,830
to the apps backend server,

168
00:09:01,830 --> 00:09:04,780
which forward furthers to the

169
00:09:06,540 --> 00:09:08,010
TAM server

170
00:09:08,010 --> 00:09:11,640
for verification of device public key.

171
00:09:11,640 --> 00:09:16,290
In case if the ASK packet is legitimate

172
00:09:16,290 --> 00:09:19,350
third party store the
application public key

173
00:09:19,350 --> 00:09:22,980
on its remote server for futures.

174
00:09:22,980 --> 00:09:24,450
Okay.

175
00:09:24,450 --> 00:09:27,180
For each business scenario,
such as logging the business

176
00:09:27,180 --> 00:09:32,180
or payment business app,
should create a business key.

177
00:09:32,310 --> 00:09:33,630
The generator,

178
00:09:33,630 --> 00:09:35,430
the generation process is the same

179
00:09:35,430 --> 00:09:37,980
with the application key generation.

180
00:09:37,980 --> 00:09:38,813
Okay.

181
00:09:38,813 --> 00:09:41,980
To make a payment transaction,
an application ASK

182
00:09:43,290 --> 00:09:46,740
change factor from its
remote server, usually

183
00:09:46,740 --> 00:09:49,790
its random string as an object for sign in

184
00:09:51,074 --> 00:09:55,590
and after user fingerprint
authorization, application

185
00:09:55,590 --> 00:10:00,590
sends this challenge factor,
finger ID, device information,

186
00:10:01,680 --> 00:10:05,010
and payment data to the backend server.

187
00:10:05,010 --> 00:10:08,790
All this data is signed with
the business key in the TEE

188
00:10:08,790 --> 00:10:11,640
and the public business
key will be used to

189
00:10:11,640 --> 00:10:14,853
verify the transactions.

190
00:10:16,590 --> 00:10:21,213
Tencent Soter does not
provide a key related code.

191
00:10:23,880 --> 00:10:26,340
Tencent leaves the implementation

192
00:10:26,340 --> 00:10:27,886
to the cheap old device

193
00:10:27,886 --> 00:10:29,553
manufacturer.

194
00:10:30,480 --> 00:10:33,810
So Xiaomi implemented their own soter

195
00:10:33,810 --> 00:10:37,800
trusted application to store
keys and manage key operations.

196
00:10:37,800 --> 00:10:38,850
On this slide, you can see

197
00:10:38,850 --> 00:10:41,850
across snippet of the
soter trusted application.

198
00:10:41,850 --> 00:10:43,803
I just listed a few supported commands.

199
00:10:45,750 --> 00:10:49,020
To start the design session, soter trusted

200
00:10:49,020 --> 00:10:54,020
application exports a command
or function in its time

201
00:10:54,420 --> 00:10:57,150
which expects to receive
business key areas

202
00:10:57,150 --> 00:11:00,150
and change factor as argument.

203
00:11:00,150 --> 00:11:03,390
And this function creates a session ID

204
00:11:03,390 --> 00:11:05,850
by calculating both this string to

205
00:11:05,850 --> 00:11:09,430
and to heap based buffer

206
00:11:10,500 --> 00:11:11,333
without checking

207
00:11:11,333 --> 00:11:15,513
for overflow and an attacker
can provide arguments

208
00:11:16,380 --> 00:11:19,950
of such length that they
overflow the heap memory

209
00:11:19,950 --> 00:11:22,547
after the session buffer
is controlled to values.

210
00:11:24,252 --> 00:11:28,483
Xiaomi's trusted applications
don't have ASLR for protection

211
00:11:29,700 --> 00:11:31,983
so this vulnerability can be exploited.

212
00:11:33,660 --> 00:11:34,493
Okay.

213
00:11:34,493 --> 00:11:37,500
Now let's get back to
the Tencent Soter itself.

214
00:11:37,500 --> 00:11:39,240
And this slide you can
see its implementation

215
00:11:39,240 --> 00:11:40,623
on the Xiaomi devices.

216
00:11:41,670 --> 00:11:45,150
Soter server is system
application, Android

217
00:11:45,150 --> 00:11:50,150
application exports, I mean
fair for public Soter service.

218
00:11:52,110 --> 00:11:56,010
This soter service binds vendor
point, micro trust point,

219
00:11:56,010 --> 00:11:59,400
hardware point, soter system
service to communicate

220
00:11:59,400 --> 00:12:01,173
to use trusted environment.

221
00:12:02,040 --> 00:12:04,290
As I mentioned, an
operation rate application

222
00:12:04,290 --> 00:12:07,110
has no permission to communicate
with the TEE directly

223
00:12:07,110 --> 00:12:10,083
but it can use the soter
service as a proxy.

224
00:12:12,480 --> 00:12:16,800
This Java code binds the soter service

225
00:12:16,800 --> 00:12:21,409
and then calls the vulnerable
in its sign function.

226
00:12:21,409 --> 00:12:22,242
Okay.

227
00:12:22,242 --> 00:12:24,750
So Xiaomi didn't implement an Android

228
00:12:24,750 --> 00:12:26,973
permission to protect the soter API.

229
00:12:28,680 --> 00:12:31,740
Now I'll show you earlier, a simple demo

230
00:12:31,740 --> 00:12:34,893
when an unprivileged Android
application, is visible,

231
00:12:37,470 --> 00:12:39,347
an ability to pay in the WeChat.

232
00:12:40,290 --> 00:12:41,123
Okay.

233
00:12:41,123 --> 00:12:45,420
So on the right side, you see command line

234
00:12:45,420 --> 00:12:48,979
actually is just to show you what is going

235
00:12:48,979 --> 00:12:51,701
on and on the left side, this a telephone.

236
00:12:51,701 --> 00:12:53,000
Okay.

237
00:12:53,000 --> 00:12:54,933
So I implemented a simple tool.

238
00:12:57,660 --> 00:13:02,070
This name, soter holder. This tool I used

239
00:13:02,070 --> 00:13:05,130
just to send commands,
specific commands to

240
00:13:05,130 --> 00:13:08,070
the soter trusted application

241
00:13:08,070 --> 00:13:11,370
and output will build the store

242
00:13:11,370 --> 00:13:15,870
in some files provided
in the command line.

243
00:13:15,870 --> 00:13:18,220
So first of all, I just want to show you

244
00:13:19,994 --> 00:13:23,447
that soter, tencent soter,
is okay, it works and

245
00:13:23,447 --> 00:13:25,200
return some results.

246
00:13:25,200 --> 00:13:27,810
For example, using this command

247
00:13:27,810 --> 00:13:32,810
I ask to generate ASK application command.

248
00:13:32,953 --> 00:13:35,430
And after that, and in signed

249
00:13:35,430 --> 00:13:36,903
so we have two results.

250
00:13:39,525 --> 00:13:41,820
And also, in the Android kernel log,

251
00:13:41,820 --> 00:13:45,000
we see that everything is okay

252
00:13:45,000 --> 00:13:50,000
so tencent soter responded to our request.

253
00:13:50,880 --> 00:13:55,023
Now I just opened an
unprivileged Android application.

254
00:13:56,580 --> 00:13:58,980
So this is a malware.

255
00:13:58,980 --> 00:14:03,030
This application can be
downloaded from play store.

256
00:14:03,030 --> 00:14:07,110
And moment of launching when

257
00:14:07,110 --> 00:14:10,350
I implemented a button

258
00:14:10,350 --> 00:14:12,180
block payments.

259
00:14:12,180 --> 00:14:14,940
So in this moment, when you
press an unblock payment

260
00:14:14,940 --> 00:14:18,570
I just sent a used chain

261
00:14:18,570 --> 00:14:22,920
of vulnerabilities to
break the tencent soter.

262
00:14:22,920 --> 00:14:24,003
And it's mean,

263
00:14:25,770 --> 00:14:27,060
as you see on the right side.

264
00:14:27,060 --> 00:14:29,400
So I tried again to send a command

265
00:14:29,400 --> 00:14:32,343
to the soter and we see the target death.

266
00:14:34,816 --> 00:14:38,400
And the same situation in the kernel log.

267
00:14:38,400 --> 00:14:40,770
So it means that nothing happened.

268
00:14:40,770 --> 00:14:44,580
So we can't open a session
with the tencent soter.

269
00:14:44,580 --> 00:14:46,200
It means that at this moment

270
00:14:46,200 --> 00:14:50,250
if we're trying to open WeChat
application, when we open it

271
00:14:50,250 --> 00:14:54,210
we see that it tries to create a session,

272
00:14:54,210 --> 00:14:57,840
open a session with a
soter twice actually, and

273
00:14:57,840 --> 00:15:01,890
but soter is dead and means
that WeChat pay application,

274
00:15:04,860 --> 00:15:06,960
WeChat application,
does not provide actual

275
00:15:06,960 --> 00:15:10,440
button to make a payment.

276
00:15:10,440 --> 00:15:11,273
That's all.

277
00:15:11,273 --> 00:15:12,106
So it means

278
00:15:13,189 --> 00:15:16,800
that malware application
can close the ability to pay

279
00:15:16,800 --> 00:15:17,657
in the WeChat.

280
00:15:20,250 --> 00:15:25,250
Okay, but actually we don't
want to block payment.

281
00:15:25,500 --> 00:15:29,968
We want to extract a private pay because

282
00:15:29,968 --> 00:15:32,040
(inaudible) completely

283
00:15:32,040 --> 00:15:35,940
compromised the sorter platform allowing

284
00:15:35,940 --> 00:15:40,623
to unauthorized users to
sign fake payment packages.

285
00:15:41,910 --> 00:15:44,595
To steal one of the private keys, I use an

286
00:15:44,595 --> 00:15:47,960
add vulnerability is this
is (inaudible) vulnerability

287
00:15:47,960 --> 00:15:52,320
in the old version of the
sorter trusted application.

288
00:15:52,320 --> 00:15:54,013
If you remember, we can

289
00:15:54,013 --> 00:15:58,743
can downgrade the trusted
application on Xiaomi devices.

290
00:16:01,050 --> 00:16:03,587
Let's see in the TEEc operation argument

291
00:16:03,587 --> 00:16:06,180
of the Invoke Command function

292
00:16:06,180 --> 00:16:11,013
which we used to call soter
trusted app from Android.

293
00:16:12,480 --> 00:16:16,470
The caller can provide
up to four arguments

294
00:16:16,470 --> 00:16:19,500
such as a number or buffer

295
00:16:19,500 --> 00:16:22,860
to the trusted application for processing

296
00:16:22,860 --> 00:16:27,123
and the common types I encoded
in the param types field.

297
00:16:28,260 --> 00:16:32,010
Each trusted application must
ensure that the data sent

298
00:16:32,010 --> 00:16:37,010
from the insecure side matches
the expectation of this app.

299
00:16:37,650 --> 00:16:38,950
What happens if

300
00:16:40,523 --> 00:16:42,330
an trusted application
expects to receive a point

301
00:16:42,330 --> 00:16:45,330
or two buffer, but we provide a number.

302
00:16:45,330 --> 00:16:49,080
In this case, if this application
does not check the type

303
00:16:49,080 --> 00:16:51,240
of incoming parameter.

304
00:16:51,240 --> 00:16:55,953
So our number will be recognized
as, is a virtual address.

305
00:16:57,056 --> 00:17:00,420
And soter application we will read

306
00:17:00,420 --> 00:17:02,817
or write to the memory (inaudible).

307
00:17:04,380 --> 00:17:05,213
Okay.

308
00:17:07,104 --> 00:17:08,400
So I found that one

309
00:17:08,400 --> 00:17:13,270
of the old versions of the
soter trusted application locks

310
00:17:13,270 --> 00:17:15,720
checking for incoming parameters,

311
00:17:15,720 --> 00:17:18,093
and we can use this to,

312
00:17:19,525 --> 00:17:23,820
we can use it to achieve a better memory.

313
00:17:23,820 --> 00:17:27,720
So if we hold the target
device in our hand, we can send

314
00:17:27,720 --> 00:17:31,800
HAS_AUTH_KEY command and specify

315
00:17:31,800 --> 00:17:36,800
the address we're interested
in as the second argument.

316
00:17:37,170 --> 00:17:39,720
And in this case, we will see a content

317
00:17:39,720 --> 00:17:42,660
of this address in the Android kernel log.

318
00:17:42,660 --> 00:17:44,250
So on the slide.

319
00:17:44,250 --> 00:17:46,530
If we don't, don't want to deal

320
00:17:46,530 --> 00:17:49,323
with kernel log and just want

321
00:17:50,803 --> 00:17:54,000
to get information from our code,

322
00:17:54,000 --> 00:17:55,470
we need to send

323
00:17:55,470 --> 00:18:00,470
has our generate HAS_AUTH_KEY
command and define

324
00:18:01,020 --> 00:18:03,610
the target address, again,
as a second argument

325
00:18:05,254 --> 00:18:09,000
and soter trust application
generate the business key

326
00:18:09,000 --> 00:18:14,000
based on the content of the
address that we specified.

327
00:18:14,040 --> 00:18:16,991
And after that we can use HAS_AUTH_KEY

328
00:18:16,991 --> 00:18:21,582
HAS_AUTH KEY command many
times to find the value

329
00:18:21,582 --> 00:18:22,960
which match

330
00:18:24,687 --> 00:18:27,333
the generated key.

331
00:18:29,010 --> 00:18:32,070
Okay. So we have a read vulnerability.

332
00:18:32,070 --> 00:18:34,020
In addition, there is no a SLR.

333
00:18:34,020 --> 00:18:38,280
So all we need to steal the
data is just to shape the heap.

334
00:18:38,280 --> 00:18:42,270
Okay. I just want to note here that the,

335
00:18:42,270 --> 00:18:44,670
to force load

336
00:18:44,670 --> 00:18:49,670
for example, private device
key, we need to send export

337
00:18:49,927 --> 00:18:53,190
ASK_KEY command to the
trusted applications.

338
00:18:53,190 --> 00:18:55,590
And in this case, this public key

339
00:18:55,590 --> 00:18:58,390
will be loaded from the security storage

340
00:18:59,992 --> 00:19:03,457
to the heap of the soter trust tech.

341
00:19:03,457 --> 00:19:07,140
Okay. Now I'll show you POC.

342
00:19:07,140 --> 00:19:09,273
How, how to extract,

343
00:19:11,370 --> 00:19:14,043
how to extract device private key.

344
00:19:15,540 --> 00:19:17,853
Oops. Okay.

345
00:19:19,410 --> 00:19:20,403
Just a second.

346
00:19:22,200 --> 00:19:25,950
So it's, it's already technical.

347
00:19:25,950 --> 00:19:26,827
Sorry for this.

348
00:19:26,827 --> 00:19:30,030
So I will use the same
tools that I implement.

349
00:19:30,030 --> 00:19:32,977
It's really simple too, just to provide

350
00:19:32,977 --> 00:19:35,220
to send some information.

351
00:19:35,220 --> 00:19:38,010
First of all, we doing downgrade attack.

352
00:19:38,010 --> 00:19:41,831
So we override the

353
00:19:41,831 --> 00:19:42,664
new version

354
00:19:42,664 --> 00:19:45,164
of the soter trusted
application with the old one.

355
00:19:46,080 --> 00:19:47,430
This is the first step.

356
00:19:47,430 --> 00:19:48,867
After that,

357
00:19:48,867 --> 00:19:52,765
we sent form export ATTK key

358
00:19:52,765 --> 00:19:56,310
this comment to ASK

359
00:19:56,310 --> 00:19:58,710
official public device key.

360
00:19:58,710 --> 00:19:59,940
This is a public key.

361
00:19:59,940 --> 00:20:01,920
Just, I want to save it

362
00:20:01,920 --> 00:20:06,873
in the sound file to
validate the transactions.

363
00:20:08,075 --> 00:20:13,075
This, after that, I ask, use
the export ASK key command

364
00:20:13,710 --> 00:20:17,043
give me please identification,

365
00:20:18,270 --> 00:20:21,840
application key, and
signature application key.

366
00:20:21,840 --> 00:20:26,370
And again, we store it in specific files.

367
00:20:26,370 --> 00:20:31,370
Next step we use readability
to extract private key.

368
00:20:31,860 --> 00:20:33,550
Actually this key

369
00:20:35,550 --> 00:20:36,420
is represented

370
00:20:36,420 --> 00:20:41,057
by say private exponent
and (inaudible) models.

371
00:20:44,469 --> 00:20:46,590
And so now we have all
the information we need.

372
00:20:46,590 --> 00:20:49,590
We extracted private
key, public key, packet,

373
00:20:49,590 --> 00:20:52,530
and we just need to validate this.

374
00:20:52,530 --> 00:20:54,750
Our signature is correct.

375
00:20:54,750 --> 00:20:56,370
How we can do it.

376
00:20:56,370 --> 00:20:57,513
We can use open S.

377
00:20:58,585 --> 00:21:02,680
So using this command, I
just validate the public key

378
00:21:03,970 --> 00:21:08,490
and signature of the
regional packet is correct.

379
00:21:08,490 --> 00:21:09,450
It should be correct

380
00:21:09,450 --> 00:21:13,053
because we didn't fix any data.

381
00:21:13,950 --> 00:21:15,090
Verified, okay.

382
00:21:15,090 --> 00:21:18,810
Next we're going to patch packet.

383
00:21:18,810 --> 00:21:19,830
This is ASK packet.

384
00:21:19,830 --> 00:21:20,663
Okay. This we're.

385
00:21:20,663 --> 00:21:22,530
We are going to patch some key

386
00:21:22,530 --> 00:21:25,260
some packet this with any data.

387
00:21:25,260 --> 00:21:28,083
And after that, we are going to sign

388
00:21:28,083 --> 00:21:32,370
this packet with extracted private key.

389
00:21:32,370 --> 00:21:33,960
We can use open S here

390
00:21:33,960 --> 00:21:38,760
because open S' doesn't
know how to proceed

391
00:21:38,760 --> 00:21:43,110
with private exponent and modules, but

392
00:21:43,110 --> 00:21:44,463
metrics as a cell, no.

393
00:21:45,750 --> 00:21:48,123
This is open source too,
metrics are the same.

394
00:21:49,053 --> 00:21:50,490
So we sign packet.

395
00:21:50,490 --> 00:21:52,200
And the last one, again

396
00:21:52,200 --> 00:21:57,200
we use an open S to validate
that the new package packet

397
00:21:57,660 --> 00:21:58,560
which we fixed

398
00:22:01,903 --> 00:22:04,350
is correct and signature is correct.

399
00:22:04,350 --> 00:22:05,804
So verified.

400
00:22:05,804 --> 00:22:08,270
It means that we extracted private key.

401
00:22:08,270 --> 00:22:11,040
We use it to sign and actually it means

402
00:22:11,040 --> 00:22:15,222
that we can sign any packet we want.

403
00:22:15,222 --> 00:22:16,055
Okay.

404
00:22:17,940 --> 00:22:18,773
Thank you

405
00:22:20,850 --> 00:22:22,113
To summarize, okay.

406
00:22:23,340 --> 00:22:24,630
OEM

407
00:22:24,630 --> 00:22:27,164
provided TEEs

408
00:22:27,164 --> 00:22:28,830
a very promising area
for security research

409
00:22:28,830 --> 00:22:31,860
because many security
critical features implemented

410
00:22:31,860 --> 00:22:35,130
by OEMs and not by cheap manufacturers.

411
00:22:35,130 --> 00:22:39,780
To prove this, we analyze the
tencent total platform built

412
00:22:39,780 --> 00:22:41,610
in the Xiaomi devices

413
00:22:41,610 --> 00:22:44,700
and found two ways to attack WeChat app.

414
00:22:44,700 --> 00:22:47,760
One is from an unprivileged
Android application

415
00:22:47,760 --> 00:22:52,680
by exploiting the overflow
vulnerability, and the second one

416
00:22:52,680 --> 00:22:56,900
by downgrading the soter
trust attack, okay.

417
00:22:56,900 --> 00:22:59,440
Xiaomi has fixed most of the

418
00:23:01,710 --> 00:23:02,730
vulnerabilities

419
00:23:02,730 --> 00:23:05,220
we reported two months ago.

420
00:23:05,220 --> 00:23:06,420
So thank you for your attention.

421
00:23:06,420 --> 00:23:08,520
You can find a lot of
good security research

422
00:23:08,520 --> 00:23:10,199
on our research board.

423
00:23:10,199 --> 00:23:13,199
(audience applause)

424
00:23:15,000 --> 00:23:15,833
Thank you.