 We have a talk today from Liu Huiming about bug finding and exploit techniques for file transfer apps on Android phones. So if you have your file transfer apps open at DEF CON, really? But if so, this might be a good time to turn it off. This is Liu's first time speaking at DEF CON, although he has given talks at CanSec West, Black Hat Aid. Basically all over the world he's given this. So give him a welcome and we're going to give him a classic DEF CON welcome with the speaker shots. Cheers. Good morning everyone. My name is Liu Huiming and Zhang Xiangqian in my colleague, but he won't come here because I'm visa issue, so I will do this talk alone. Yeah. Now I will show you a comprehensive research about exploit or nearby file transfer apps. The title is your secret file, am I? And bug finding and exploit techniques on all transfer apps or all top Android phones. First, let's introduce ourselves briefly. We are from advanced technology research team of Tencent Security Shen Wu Lab. Tencent is the largest social media and entertainment company in China and we focus on mobile security and IoT security and we found many Android kernel and system security vulnerabilities and accomplished many fancy attacks and we have presented many slides like this. This is our presentation outline. First, we will give an introduction about the nearby sharing technologies and talk about our motivation to do this talk. Secondly, we will present a text surfaces and some previous work. Next, we will show you the real vulnerabilities and the exploit and the demos. Next, we will show you the real, then we will talk about the mitigation method. Finally, it will be our conclusion. Now, let's begin our part one introduction. There are many nearby transmission technologies such as Bluetooth, Android Beam, Wi-Fi Direct, but we focused on research on nearby sharing apps on Android, including smart phone, Windows built-in apps, and third party developers apps. Many users on nearby file sharing apps, why? We believe that Bluetooth and Android Beam based on NFC have two weaknesses. First, not user friendly enough and secondly, not fast enough. When you want to share a picture to your friend, it usually takes seconds or minutes to transfer a big picture, but this technology based on Wi-Fi technology will be transferred quickly. When we want to send or receive a Blu-ray movie, it will be not capable at all. So nearby transfer apps that based on Wi-Fi related technology are people's new choice. Based on our research, we found that nearly all top smart phone, Windows have their sharing apps. So based on the IDC's data, we can find that the shipment last year is nearly a billion phones, a billion within a single year. That's a big number. If they are vulnerable, a huge number of people will be affected. So we began our research. This is what the Android sharing apps look like. It is a little like the AirDrop on the iOS and iPhone. There are several ways to connect and send files on Android. In this example, when the both sides are all active status, the sender just select the file and the receiver will be shown on the screen and then the receiver can tap the profile picture of the receiver. And the receiver will click the accept, just like the AirDrop. Then the file will be transferred. Some apps use another approach. The receiver clicks the receive button and then the sender can see the receiver and they establish the link and accomplish the file transferring. There are little difference here, but there are many difference in the security design. There are some other ways such as scanning the QR code to transfer apps, to transfer files, or shake the phones at the same time. On the other hand, many nearby file sharing apps will show the thumbnail. This will introduce a new attack vector. We will detail it later, yeah. The sharing process of nearby sharing apps are shown here. In general, there are four steps. First, discover by BL yet of targeting. Name, ID device type and so on. Secondly, we can pair, so most apps pair and exchange keys automatically, which is very convenient, but it is vulnerable. Thirdly, connect via Wi-Fi or Wi-Fi P2P. Finally, we can transfer files such as pictures, APKs and so on. Since we know the general sharing process, let's analyze the attack surfaces. First, the adversary a nearby, the attackers can be sniff and sender or Bluetooth and Wi-Fi packets. Then, what are the attackers can eventually get when attack succeeded? First, the attacker can get to transfer files and more, such as hijack and the traffic, hijack traffic, getting more information and even remote code execution. Here, attack surface are as follows. Link establishing, secure transmission, device and ID spoofing, main and middle and others. First, when link is establishing automatically, attackers may join to the network without users permission. On the other hand, attackers may obtain the established networks password because of a secure connection. When files are transferring, there may be no encryption at all, so we can get the file directly. And sometimes the key exchange are not safe, so attackers can recover all the real files from the encrypted traffic. Next, device and ID spoofing. Many apps fail to authenticate the real device or users. For example, when Alice wants to send a Bob file, then the attacker can collect all the Bob's advertised information and advertise themself to create a fake Bob. In this case, many apps fail to distinguish between the fake and the real one. We call it device and ID spoofing. Based on the device spoofing, the attackers may accomplish the main and middle attack, so the normal user will feel nothing. We'll show the demo later, but the technical details will be explained later too. What's more, we found some other interesting attack surfaces. For example, some sharing apps will start a web server, which will open more doors for attackers. And there are other information declares we can't even think about it. And Android components relate to attack surfaces. We are now the first researchers to notify, notice the nearby communication apps. We're researching about the zero-conf on OS 10 and iOS, research by Xiao Long, et cetera, analyzed the airdrop and found some vulnerabilities. And in the 19-some, some researchers analyzed the Google Nearby Connection API. However, there are nothing about file sharing apps on Android. My colleague and I will present this on this talk. To the best of our knowledge, our research is the first comprehensive research about Android Nearby Sharing Apps. We analyzed many related apps, including pre-installed and third-party apps. And we found a lot of vulnerabilities in these apps. And then we arranged them in several common attack methods. Here, let's show you some of the real vulnerabilities. Notice that in this talk, we will focus on the specific, we won't focus on specific apps or vendors. So I will cover all the vendors and the apps name here for just for security, yeah. Besides, there are a huge number of users who will be affected. So I will cover all the critical code too, yeah. Some of the vulnerabilities are not fixed here. So we will print four vulnerabilities categories. Sneafar attack related vulnerabilities. Two, the middle attack related vulnerabilities. Then we will talk about logic vulnerabilities. Finally, we will print our other vulnerabilities here. First, let's talk about Sneaf attack. This is a building app or a smartphone and we will take it as our example. This three picture shows a normal file sharing process. The receiver don't need to input any password. Or something else, yeah. The whole process is totally automatic. However, more convenience can often means less security. This app uses Bluetooth low energy to advertise and discover other peers and transfer files by Wi-Fi P2P. Can it accomplish a secure key exchange here to capture Bluetooth data? We can use the Bluetooth Sneafar such as Uber tools, NLF, FireOne and so on. This is a BLE package we captured. It is a scan response packet which is sent when someone, some other device are scanning. It contains your ID, device name, and some other information such as some flags and spotted cyphers, spotted cyphers variants. The packet is an advertising packet which is often easy to understand. And this is a BLE data packet. The BLE send data in 37, 38, 39 channels but Uber tools can only sniff one channel at a time. So we need to sniff several times to get the data packet. The picture shows an encrypted data transfer when establishing connection between different variable apps. So we extracted the data here and it looks like this. What does it mean? The answer lies in the app itself. So we reverse engineering app. This is a core crypto algorithm. We can see that it is obfuscated badly. So, but we managed to recover a function which mainly rely on an ES crypto and some other transformation of data. To make it more clear we can show you an older variant which is different but without any obfuscation. But the whole process is just the same. In the older variant there are nothing but an ES encryption which was different from the new variant. But the overall logic was still the same. So the P2P info is a P2P info you can see in the slide is encrypted information. And the P2P CFDEX here is a plain text decryption by calling decrypt function. And the key was generated by the function generate secure key and generate root key. This picture shows a decrypt function which we can see the EX decryption here. To decrypt the data we need to get the ES encryption keys which rely on the source string array and the msql random. A secure string array can be gotten from the BLE packet. What about the msql random? It's name contains random. However, we think that it must not be the random number because the standard and receiver must have the same number of this. So we found that it was stored in some XML file and it is fixed. That's interesting, yeah. So now the whole encryption can be break and we can recover data directly. This is a decrypt process for the older version of the app. The latest version was far more complicated. But we managed to reverse-engineer it. But it is similar in the design. We break it too and we will show you the output. The upper image shows that we covered P2P info or the latest version. The second image here shows that we covered P2P info or the latest version so we can see the SSID and password are gotten by us. So everything they transferred will get directly by us. Based on the recovered password we can join the network and get the transferred files through ARP spoofing. And let's show you two demos. Here, a red phone take picture and then he will send the picture to the left phone and the computer act as an attacker so we can see the info that were collected there. Then the left phone got a notification and then when he click the accept here, we can see that the computer will get it too and this is the phone photo. We just take picture that, yeah. Here is demo two. It is, the process is a little different but there are some more interesting here. Some, something very interesting I think. The left phone want to sharing a picture to the right phone and we can see that the picture was gotten by us. You can see that pop out on the computer. We checked it's latest variant when we recorded the video. When transfer apps, actually they see the picture, yeah. And this shows that what you're using, all the apps you installed on your phone. When sharing apps want to sharing a photo here, he will send all your installed, all the apps you installed on your phone to the other phone. It's a terrible info leak here, I think. Next, let's move on to the second category. Main and middle are tags related vulnerability. In nearby sharing apps, when the standards want to select a receiver, he can see profile picture, device name, URL ID and so on. Our question is, how can you authenticate that it is a real one? We found that it is very tricky. In this slide, we can see that we can emulate as a receiver by use a BLE scan standard app to send advertising and scan response packets. The left phone shows a profile picture of someone, but it is actually a BLE standard app, yeah. Then the receiver will be shown on the standard screen. And in this picture, we modify a real device to spoof another device. There are two active receivers here, but the standards can only see one device. So when we want to send a file, he will never know which device it will be sent to. Now, we can spoof another real device. Then the attacker can accomplish perfect main and middle tag when emulated a fake receiver and a fake sender. As we can see here, if A sent B a file, there will be 50% chance that the file will be sent to the attacker, and chances can be improved by many ways. Now, perfect main and middle tag can be designed like this. A can find that the attacker because the attacker will not send a scan response to A by our design. B can't find the attacker because B is not in discovery mode. Then the attacker can distinguish between A and fake A, B and fake B, because he can choose to block or receive any message. So the normal user A and B can feel anything. This is a demo. We didn't implement the whole process of the main and middle here due to time limitation. In this demo, we just verify that the sender can distinguish between a real and a fake receiver. So our main and middle attack will work properly. Here we can see the normal user sender file, and sometimes the users, the normal user get the file, and sometimes the attackers will get the file. So here, the attacker will get the file here. Oh, yeah. Now let's go to the start category, logic vulnerabilities. First, let's think about a question. How to design a secure process to establish connection between sender A and the receiver B? We think it should be like this. User A request to send and B accept, and then the link will be established. Then A send the file and B will receive it successfully. But actually, most near-brush only apps will establish a Wi-Fi connection as soon as the sender A just send the request. But why the app developers choose an unscure way? We think that they might have their own consideration here. More clicks often means less convenience, so the developers don't want their users to double confirm. And the receiver often want to steal a thumbnail about the file to decide whether accept the file or not. So convenience wins and sometimes security loses. Firstly, the non-confirm connection brings more attack surface here and the attackers can now establish the Wi-Fi or Wi-Fi P2P connection without any interaction. It will open for attacks to exploit other vulnerabilities and even choose zero click attack here. Just a plot the file image protocol, yeah. Secondly, we can hijack the victim's network. In these two cases shown on this slide, we can see that when transfer files that one device creates a Wi-Fi hotspot and the other device connect to it directly. However, it is not as easy to hijack network successfully. First, if attackers want to hijack the network, they must be the hotspot server. Can we choose to be a server? We found it's where that we can. For some apps, the senders are definitely the server creator, it is okay because here we attackers are always senders. For many other apps, we found that when an app running on Android 7 and another app running on Android 8 want to establish a connection, Android 7 is always a server because some compatibility issues here. Secondly, we will make the other user to connect to Wi-Fi without interacting. Can we do that? We found yes, because it was designed like this, yeah. Let's show the demo here. The victim just check his internet access and he just open the file transfer apps and just leave it here or make it in background or turn the screen off here. The attacker request to send him file and then when victims open his browser, he'll be hijacked, yeah. Finally, it's our fourth category, other vulnerabilities. We will share three examples here. One, accept automatically via Wi-Fi P2P, two, directory traversal, and three, remote file management vulnerabilities. In this case, when sharing files, this app will establish a Wi-Fi P2P connection. We can see that when other device want to join them, it will need to provide the correct password. However, when we use Wi-Fi P2P protocol to directly connect it, we found that anyone can join them without any confirmation here and the normal users won't feel anything, so we'll get the file directly. This is the second logic vulnerability example and in this case, it is a directory traversal vulnerability. The file transfer was accomplished by web server so the senders may create a web server and send the receiver a URL to get. Then the receiver can modify it to get any files here. Let's show the demo here. The right phone is a sender. Then he got a secret image. But he want to send another normal image to the left phone. But here, the left phone will get anything he wants. And in this case, we will share a file management-related vulnerabilities. If an app want to open the FTP server computer within the same local area network can manage the file in smartphone. We found that many apps didn't have any authentication here and secure design. Any users have read and write permissions here. So if the attackers are in the same length, they can get and write all your files here. This is a summary of vulnerabilities in nearby sharing apps. First, non-confirmed before Wi-Fi connection is established. Two, no well-protected access to Wi-Fi or Wi-Fi P2P. Three, unsecured transport. And finally, no anti-spoofing at all. Those vulnerabilities patterns affect nearly all the nearby sharing apps. We finished our four common vulnerability categories and now we present you our security survey about nearby sharing apps. The red X means no security measures at all. The yellow O means have security measures but can be bypassed here. There are no one green here. But I assume no one here. There are little security measures such as access control when Wi-Fi was established here. Then we did a security survey for top 10 startup party nearby sharing apps. And the results are shown here. Most of them are vulnerable too. Only 20% of them can prevent a sniffer attack and only 10% of them can prevent spoofing. And notice that this is the test results on Android 8. If we test them on Android 7 or lower, nearly all of them will be vulnerable because Android allow the app to create a hotspot with their self-defined password on Android 7. So when Android 7 and Android 8 make a connection, the Android 7 will always be the server and will be vulnerable. Finally, let's talk about the mitigation. This is our four advices about mitigations, sorry. First, we need more secure Wi-Fi and Wi-Fi P2P key exchange. And two, we need transport encryption. And three, it must design to prevent spoofing. And finally, there are other small tips. First, the app must have secure Wi-Fi and Wi-Fi P2P key exchange. So we recommend that the app transfer the key over secure channels such as NFC, certificate-based key exchange mechanism and the internet. On the other hand, the pin code is a good choice too. Now nearly all apps transfer files without any transport layer encryption. When we recommended that the app use TLS HTTPS instead of TCP HTTP and transferring keys over the internet securely or play exchange keys for contacts. It is not very easy to prevent spoofing. We prevent a method here, we present here, but we use the certificate-based authentication. When the app launch for the first time, it will get a unique ID distributed by server and corresponding certificate signed with predefined trust anchor. So attacker can't sign the unique ID correctly. We can make sure that the device can distinguish between the real user and the attackers. There are some other tips. First, we must prevent attacker from joining the network and state file sharing turned off by default and turned off them after a period of idle time. And confirm before connection established. And finally, do not establish connection automatically with users who are not familiar. This is our recommended design. When users are logged in, we recommended pre-exchange public keys and authenticate automatically for contacts. And exchange keys through the server when they are internet access for other peers. When your users are not logged in or have no internet access at all, we recommended PIN code NFC to exchange keys. PBC and DVHillman here is easy to deploy and have some security measures here, but it is not very recommended because it can prevent major middle attack. Now, this is our conclusion. We analyze the attacker vectors or nearby sharing apps and did the first comprehensive research about them. And we found many vulnerabilities here and we categorized in several common attack methods. And finally, we present some effective mitigation methods here. Thank you. Now the mitigations will be deployed on many apps here, but we can't tell which app is secure because the vendor didn't want to say that. Sorry about that.