 So today we have Slava Makheev talking to us about digging into Xiaomi's tea to get to Chinese money. It's Slava's fifth time speaking at DEF CON, so please welcome him back. Hello, everyone. Thank you for taking the talk. I'm Slava. I have been doing mobile security research at Checkpoint for many years. Reverse engineering and vulnerability research is my daily work. When I hear the praise, trust zone or trusted environment, I imagine some secure place on a device where cryptography, keys, passwords, and other security sensitive information are stored. I imagine that protection is implemented with hardware systems and major mobile chip manufacturers, such as MediaTek and Qualcomm, are responsible for the business logic. In general, all my assumptions are correct, but in fact, and this surprises me a little, not only chip manufacturers can change the logic of the trusted code running on a smartphone. Device manufacturers, such as Xiaomi, also have the ability to page the trusted code and add new items. In my research, I consider the trusted code provided by Xiaomi as a target for techs, and I will show you several vulnerabilities in the Xiaomi's trusted environment, which align with an average Android application to steal money from ordinary people. Well, according to the latest statistics, the Far East in China account for two thirds of the world's mobile payments. And this is about four billion dollars in mobile wallet transactions. Let's zoom in, WeChat Pay and Alipay are the largest players in the Chinese mobile payment industry, together they account for about 95% of the old Chinese payment market. Each of these platforms have over one billion users, so actually it's enough to hug only one of them to get rich. Today I focus on WeChat Pay built in Xiaomi devices powered by MediaTek chip. Why is this particular combo? Because Xiaomi is the most popular Chinese smartphone manufacturer, MediaTek is the most popular mobile chip manufacturer in the world, and WeChat Pay is the most popular payment platform in China. Okay, now let's talk about the trusted environment, aka TE. As I mentioned, mobile payment signatures are carried out in the TE, so as long as TE is safe, so are your payments. On the internet, you can easily find many articles about the TE architecture, so I note only the key points. TE creates a virtual security world managed by a trusted operating system, which runs the trusted applications. Each trusted application implements a specific security feature, and the normal world OS, in our case, uses Android, can send a command to a trusted app and receive a response. Xiaomi devices powered by Qualcomm chipsets use QC, trusted OS, and MediaTek-based devices uses KINIBI. In both cases, Xiaomi can embed and sign the open trusted applications. On Xiaomi devices, you can easily find trusted apps in the directory Vendor Theta. Each app is represented by an unencrypted binary file, and usually trusted applications of the KINIBI OS have the MCLF file format, but Xiaomi decided to come up with one of the oven. Actually, we don't need even to understand all the format fields, because the initial part of the Xiaomi's trusted app is the ELF file. Trusted applications can have multiple signatures following the magic fields, and the magic fields are the same across all trusted apps on the device. Moreover, the same with the app's fields of all other devices. As you see, the version control field is omitted in the trusted apps file format. It means that in attacker can transfer an old versions of the trusted application to a device and use it to overwrite the new app file. As the signature of the old trusted app is correct, this app will be successfully loaded by the TE. None of these and the attacker can bypass security features and patches of Xiaomi and MediaTek in the trusted applications by downgrading them to an unpatched version. I will use this vulnerability in my PC. Okay, Xiaomi fools the global platform to client API specification, which define the interface between the client application and the trusted environment. This API is implemented in the LibTE common SO library, and we can use it, this library, to access the trusted applications from an Android. But unfortunately, an unprivileged Android application has no permission to communicate with the TE. SLE Nooks prevents access to the corresponding driver, and it's possible to work only from a limited number of privileged users, such as DRM and MediaCodec. To bypass, we need to use the vulnerability, and I will show you one a bit later. On this slide, you can see an example of how to call a trusted application from Android. In this case, I sent a comment to the THH admin trusted app. This app expects to receive one input buffer and one output buffer as arguments, and the comment ID will be ignored. Okay, trusted apps implement TA, invoke comment entry point function. It handles the comment ID, and buffers sent from the Android side. This function is a perfect target for fuzzing-based vulnerability research, and I use a classic combination of FAIL and QMU emulator to fuzz Shoyomist trusted applications on a Ubuntu machine. A bit later, I will show you vulnerability related to mobile payment. Okay, now we know what the Shoyomist trusted environment is. Let's talk about payment system. Okay, modern Shoyomist devices have an embedded mobile payment framework named Tencent Sotr. Tencent Sotr provides an API to create, sign, and verify payment packages, transfer it between a mobile application and a remote backend server, which it pay based on the Tencent Sotr. On this slide, you can see an architecture of the Sotr and this platform deals with three levels of keys. This is device key, ATTK, application key, ask, and business key, ALUS key. Okay, they are all asymmetric Earth Day keys, and the device key is generated in the trusted environment before the device leaves the factory, and the ATTK public key is safely transmitted by Shoyomi to the Tencent TAM server. Third-party Android application, such as VChat, can request to create an application key. In this case, the private ask key will be stored in the TE, and the public ask key and its device signature will be uploaded to the app's backend server, which forward them further to the TAM server for verification with the device public key. In case if the ask packet is legitimate, third-party store the application public key on its remote server for future use. Okay, for each business scenario, such as logging the business or payment business, app should create a business key. The generation process is the same with the application key generation. Okay, to make a payment transaction and application, ask a challenge factor from its remote server, usually it's random string as the object for signing, and after user fingerprint authorization, application sends this challenge factor, finger ID, device information, and payment data to the backend server. All this data is signed with the business key in the TE, and the public business key will be used to verify the transactions. Tense and Sorter does not provide TE-related code. Tense and leaves the implementation to the chip or device manufacturer, so Xiaomi implemented their own Sorter trusted application to store keys and manage key operations. On this slide, you can see a code snippet of the Sorter trusted application. I just listed a few supported comments. To start the sign session, Sorter trusted application exports a comment or function in its sign, which expects to receive business key alias and a challenge factor as arguments, and this function creates a session ID by concatenating both these strings to a heap-based buffer without checking for overflow, and an attacker can provide arguments of such length that they overflow the heap memory after the session buffer is controlled to alias. Xiaomi's trusted applications don't have SLR protection, so this vulnerability can be exploited. Okay, now let's get back to the Tense and Sorter itself. On this slide, you can see its implementation on the Xiaomi devices. Sorter server system application, Android application, exports, I mean share for public, Sorter service. This Sorter service binds vendor point, micro trust point, hardware point, Sorter system service to communicate with the trusted environment. As I mentioned, an unprovisioned Android application has no permission to communicate with the DE directly, but it can use the Sorter service as a proxy. This Java code binds the Sorter service and then calls the vulnerable in its sign function, okay. So, Xiaomi did not implement an Android permission to protect the Sorter API. Now I will show you a really simple demo when an unprovisioned Android application did disable an ability to pay in the VChat. Okay, so, on the right side, you see common line actually is just to show you what is going on and on the left side is the telephone. Okay, so I implemented a simple tool with name Sorter Polar. This tool, I used just to send a comment, specific comment to the Sorter trusted application and output will be stored in some files, provided in the common line. So, first of all, I just want to show you that Sorter, Tencent Sorter is okay. It works and returns some results. For example, using this comment, I asked to generate ask application comment and after that, and then sign it. So, we have two results. And also, in the Android kernel log, we see that everything is okay. So, Tencent Sorter responded to our request. Now, I just opened an unprivileged Android application. So, this is a malware. This application can be downloaded from Play Store. And moment of launching, or I implemented a button block payments. So, in this moment, when you press on a block payment, I just sent a used chain of vulnerabilities to break the Tencent Sorter. And it's mean, as you see on the right side, so I tried again to send a comment to the Sorter and we see that the target debt. And the same situation in the kernel log, so it means that nothing happened. So, we can't open a session with the Tencent Sorter. It means that in this moment, if we're trying to open VChat application, when we open it, we see that it tries to create a session, open a session with the Sorter twice, actually, but Sorter is dead. And it means that VChat application does not provide actually button to make a payment. That's all. So, it means that a malware application can close the ability to pay in the VChat, okay. But actually, we don't want to block payment. We want to extract a private key because key leak completely compromised the Sorter platform, allowing to unauthorized users to sign fake payment packages. Okay, to steal one of the private keys I use another vulnerability. This is arbitrary memory rate vulnerability in the old version of the Sorter trusted application. If you remember, we can downgrade trusted application on Xiaomi devices. Let's see in the TEC operation argument of the invoke command function, which we used to call Sorter trusted app from Android. The caller can provide up to four arguments, such as a number or a buffer to the trusted application for processing. And the common types are encoded in the param types field. Each trusted application must ensure that the data sent from the insecure side matches the expectation of this app. What happens if a trusted application expects to receive a pointer to buffer, but we provide a number. In this case, if this application does not check the type of incoming parameters, so our number will be recognized as a virtual address and Sorter application will read or write to the memory with its file. So I found that one of the old versions of the Sorter trusted application lacks checking of incoming parameters and we can use this to achieve arbitrary memory read. So if we hold the target device in our hand, we can send Heth Auski command and specify the address we're interested in as the second argument. And in this case, we will see a content of this address in the Android kernel log as shown on the slide. If we don't want to deal with kernel log and just want to get information from our code, we need to send Heth generate Auski command and specify the target address again as the second argument. And Sorter trusted application will generate the business key based on the content of the address that we specified. And after that, we can use Heth Auski command many times to find the value which matches the generated key. Okay, so we have read vulnerability. In the digital, there is no ACLR, so all we need to steal the data is just to shape the heap. Okay, I just want to note here to force load, for example, a private device key, we need to send export Auski command to the trusted applications. And in this case, this public key will be loaded from the security storage to the heap of the Sorter trusted app. Okay, now I'll show you, you see how to extract device private key. Okay, just a second. So it's already technical, sorry for this. So I will use the same tools that I implemented. It's really simple tool just to send some information. First of all, we're doing downgrade attack. So we overwrite the new version of the Sorter trusted application with the old one. This is the first step. After that, we send command to export ATK key. This command to ask official public device key. This is a public key. Just, I want to save it in the sound file to validate the transactions. After that, I ask, using the export Auski command, give me please authentication application key and signature application key. And again, we store it in specific files. Next step, we use arbitrary read vulnerability to extract private key. Actually this key is represented by RSA private exponent and RSA modules. And so now we have all the information we need. We extracted private key, public key, packet and we just need to validate that our signature is correct. How we can do it? We can use open SSL. So using this command, I just validate that the public key and signature of the original packet is correct. It should be correct because we didn't fix any data. Verify it okay. Next, we're going to patch packet. This is ask packet. Okay, we're going to patch some key, some packet with any data. And after that, we're going to sign this packet with the extracted private key. We can use open SSL here because open SSL doesn't know how to proceed with private exponent and modules, but matrix SSL no. This is open source to matrix SSL. So we sign packet and the last one, again, we use an open SSL to validate that the new packet which we fixed is correct and signature is correct. So verify it. It means that we extracted private key. We use it to sign and actually it means that we can sign any packet we want. Okay, thank you. To summarize, okay, OEM provided TEs are very promising area for security research because many security critical features are implemented by OEMs and not by cheap manufacturers. To prove this, we analyze the Tencent's total platform built in the Xiaomi devices and found two ways to attack Vichitec. One is from an unprivileged Android application by exploiting the overflow vulnerability. And the second one by downgrading the SOTR trust that have, okay. Xiaomi has fixed most of the vulnerabilities we reported two months ago. So thank you for your attention. You can find a lot of good security research on our point research board. Thank you.