Your secret files are mine: Bug finding and exploit techniques on file transfer app of all top android vendors
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 335 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/48424 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Heat transferComputer fileData miningHeat transferExploit (computer security)Multiplication signMobile appInformation securityAndroid (robot)Software bugGoodness of fitClassical physicsLetterpress printingHypermedia
01:42
Information securityHypermediaSocial softwareExploit (computer security)Demo (music)Content (media)SurfaceData transmissionDirected setAndroid (robot)Drop (liquid)Android (robot)Information securityHypermediaSurfaceShared memoryMobile WebDemo (music)Presentation of a groupPhysical systemMobile appVulnerability (computing)Kernel (computing)Software developerExploit (computer security)Data transmissionPlastikkarteInternet der DingeMereologyHeat transferWindowLetterpress printingForm (programming)Computer animation
03:07
Heat transferMobile appAndroid (robot)Axiom of choiceTheory of relativity2 (number)NumberSmartphoneShared memoryAndroid (robot)Heat transferWindowMobile appUsability
04:31
Android (robot)Mobile appAndroid (robot)outputMobile appProfil (magazine)TouchscreenComputer animation
05:15
Mobile appAndroid (robot)CodeGame theoryMaizeDifferent (Kate Ryan album)Information securityHeat transferHeat transferMobile appMultiplication signQR codeComputer animation
05:42
Android (robot)Mobile appData typeProcess (computing)Computer fileProcess (computing)Mobile appShared memoryMultilaterationThumbnailConnected spaceKey (cryptography)Type theorySoftwareHeat transferComputer animation
06:28
SurfaceComputer fileInformationLink (knot theory)Data transmissionServer (computing)Computer networkPasswordEncryptionAuthenticationRemote procedure callPasswordMobile appSoftwareCodeInformation securitySpywareConnected spaceHeat transferSchlüsselverteilungInformationLink (knot theory)Real numberDirection (geometry)SurfaceEncryptionCASE <Informatik>Metropolitan area networkComputer animation
08:27
Level (video gaming)InformationDirectory serviceServer (computing)Component-based software engineeringGoogolReverse engineeringInformation securityAndroid (robot)Android (robot)Demo (music)InformationServer (computing)SurfaceMobile appWeb 2.0Shared memoryConnectivity (graph theory)Vulnerability (computing)Connected spaceSource codeComputer animation
09:38
Android (robot)Mobile appCategory of beingLogicAndroid (robot)Mobile appFocus (optics)Vulnerability (computing)CodeNumberLatent heatLogicShared memoryCategory of beingBuildingSmartphoneWindowCovering spaceFlow separationPlastikkarteMetropolitan area networkComputer animation
11:14
Mobile appMotion capturePasswordPeer-to-peerSchlüsselverteilungProcess (computing)outputFood energyInformation securityHeat transferComputer animation
11:53
Food energyRevision controlInterface (computing)Frame problemComputer wormEmailDependent and independent variablesAddress spaceInformationPort scannerDependent and independent variablesEncryptionMotion captureFlagComputer animationSource code
12:26
Communications protocolAttribute grammarDependent and independent variablesFrame problemWritingOpcodeData transmissionMultiplication signConnected spaceMobile appDifferent (Kate Ryan album)CryptographyCore dumpAlgorithmComputer animation
12:59
Reverse engineeringFluid staticsBarrelled spaceOvalMotion blurNP-hardConvex hullRevision controlAlgorithmProcess (computing)CryptographyEncryptionFunctional (mathematics)Computer animation
13:27
Revision controlException handlingEncryptionFunctional (mathematics)Electric generatorLogicEncryptionInformation securityRevision controlKey (cryptography)Loop (music)InformationSlide ruleRootSource codeComputer animation
14:01
Advanced Encryption StandardException handlingEncryptionRevision controlString (computer science)EncryptionFunctional (mathematics)Context awarenessInformation securityDirection (geometry)Key (cryptography)Data recoveryString (computer science)RandomizationRandom number generationSource codeMobile appRevision controlControl flowProcess (computing)
14:56
EncryptionRootDirected setPasswordReverse engineeringMedical imagingRevision controlProcess (computing)Function (mathematics)Information
15:24
EncryptionInformationDirected setPasswordRevision controlCryptographyLattice (order)Local GroupRevision controlPasswordRight angleSource code
15:51
NeuroinformatikRight angleProcess (computing)InformationDigital photographyComputer animation
16:48
Demo (music)Computer animation
17:25
MIDIInformation securityDemo (music)Mobile appVideoconferencingRevision controlHeat transferShared memorySource codeComputer animation
17:53
Demo (music)Mobile appDigital photographyLeakInformationCategory of beingVulnerability (computing)Shared memoryWindowStandard deviationComputer animation
18:21
Identity managementComputer iconProfil (magazine)Uniform resource locatorSlide ruleMobile appPort scannerDependent and independent variablesComputer animation
19:09
Port scannerDependent and independent variablesAsynchronous Transfer ModeMessage passingBlock (periodic table)Metropolitan area networkMessage passingHoaxDependent and independent variablesProcess (computing)Identical particlesAsynchronous Transfer ModeComputer animation
20:22
Inclusion mapLogicLimit (category theory)Category of beingMultiplication signDemo (music)Identical particles
21:21
Demo (music)LogicProcess (computing)Link (knot theory)Vulnerability (computing)LogicConnected spaceProcess (computing)SubsetLink (knot theory)Arithmetic meanSoftware developerShared memoryMobile appComputer animation
22:19
Peer-to-peerSurfaceSoftware developerThumbnailDoubling the cubeConnected spaceInformation securityInsertion lossCommunications protocolSurfaceOpen setMedical imagingVulnerability (computing)Computer animation
23:06
Computer networkCASE <Informatik>SpywareSlide ruleHeat transferSoftwareComputer animation
23:34
Server (computing)Computer networkServer (computing)Mobile appDemo (music)SoftwareInternetworkingCAN busConnected spaceInteractive televisionSpyware
24:30
Demo (music)Mobile appInternetworkingWeb browserTouchscreenHeat transferDemo (music)Computer animation
25:25
Directory serviceZugriffskontrolleoutputPasswordVulnerability (computing)Mobile appRemote procedure callTraverse (surveying)Directory serviceData managementCASE <Informatik>Communications protocolPasswordConnected spaceComputer animation
26:03
Communications protocolAuthenticationDirectory serviceInformationDirection (geometry)Vulnerability (computing)2 (number)LogicTraverse (surveying)Directory serviceServer (computing)Demo (music)Heat transferUniform resource locatorWeb 2.0Data storage deviceCASE <Informatik>Computer animation
26:49
Demo (music)Data managementComputerWide area networkMedical imagingCASE <Informatik>Shared memoryNeuroinformatikLocal area networkData managementMobile appSmartphoneVulnerability (computing)Server (computing)Computer animation
27:31
AuthenticationMobile appVulnerability (computing)Near-ringLocal area networkShared memoryConnected spacePattern language
28:16
Mobile appArchaeological field surveyInformation securityAuthenticationMobile appInformation securityCategory of beingShared memoryMeasurementVulnerability (computing)Archaeological field surveyGame controllerGreen's functionArithmetic meanComputer animation
28:58
Mobile appMobile appShared memoryAndroid (robot)ResultantServer (computing)Software testingInformation securityConnected spaceArchaeological field surveyPasswordComputer animation
29:54
EncryptionKey (cryptography)Heat transferPublic key certificateMechanism designPersonal identification numberPrimary biliary cirrhosisInternetworkingAuthenticationUniqueness quantificationServer (computing)Computer networkIdentifiabilityFrequencyDefault (computer science)Key (cryptography)Information securityEncryptionInternetworkingMultiplication signUniqueness quantificationPublic key certificateConnected spaceCorrespondence (mathematics)Server (computing)Default (computer science)Filesharing-SystemMobile appSoftwareMechanism designAxiom of choiceSchlüsselverteilungHeat transferContext awarenessPersonal identification numberAuthenticationGoodness of fitCodeInternational Date LineTransport Layer SecuritySign (mathematics)Public-key cryptographyFrequencyState of matterComputer animation
32:37
Inclusion mapServer (computing)Key (cryptography)AuthenticationEncryptionLoginComputer networkMobile appPrimary biliary cirrhosisServer (computing)Information securityInternetworkingPersonal identification numberPeer-to-peerVector spaceKey (cryptography)Measurement
33:18
Mobile appVector graphicsShared memoryVulnerability (computing)Vector spaceFlow separationSound effectMobile app
33:50
Mobile appComputer animation
Transcript: English(auto-generated)
00:00
We have a talk today from Liu Huimin about bug finding and exploit techniques for file transfer apps on Android phones. So, if you've have your file transfer apps open at DefCon, really? But if, if so, this might be a good time to turn it off. This is Liu's, uh, first
00:24
time speaking at DefCon although he has given talks at CanSecWest, Black Hat 8, basically all over the world he's given this so, uh, give him a welcome and we're going to give him a classic DefCon welcome with, uh, the speaker shots. Cheers. Good morning everyone. My
00:57
name is Liu Huimin and Zhang Xiangchen is my colleague but he won't come here
01:02
because I'm beside you so, uh, I will do this, I will do this talk alone. Yeah. Uh, now we will show, print you a comprehensive research about, uh, exploits or nearby file transfer apps. The title is Your Secret File Mine and bug finding and exploit techniques on all
01:28
transfer apps or all top Android phones. First, let's introduce ourselves briefly. We are from Advanced Technology Research Team or Tencent Security Xianwu Lab. Tencent is the
01:42
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, uh, many fancy attacks and we have presented many, uh, slides like this. Uh, this is our presentation online. First, we will
02:09
give an introduction about the nearby sharing technologies and talk about our motivation to do this talk. Secondly, we will present, uh, attack surfaces and some
02:22
previous work. Next, we will show you the real vulnerabilities and exploit and the demos. Uh, next we will show you the real, uh, then we will talk about the mitigation method. Uh, okay. Finally, it's, it will be our conclusion. Now, let's begin our part
02:45
one, introduction. There are many nearby transform, uh, transmission technologies such as Bluetooth, Android Beam, Wi-Fi direct, but we focused our research on nearby sharing apps on Android including, uh, smart phone, Windows built-in apps and third party
03:04
developers apps. Many users want nearby firing, uh, file sharing apps. Why? We believe that, uh, uh, Bluetooth and Android Beam based on NFC have two weaknesses. First, not user friendly enough and sec- secondly, not fast enough. When you want to
03:26
share a picture to your friend, it, uh, usually takes seconds or minutes to transfer a big picture. But, uh, this technology based on Wi-Fi technology will be transferred, uh,
03:41
fastly. When we want to send or receive a Blu-ray movie, it will be not capable at all. So, nearby transfer apps that are based on Wi-Fi related technology are people's new choice. Based on our research, we found that nearly all top smart phone vendors have their,
04:02
uh, sharing, sharing apps. So, uh, based on the IDC's data, we can find that the shipment last year is, uh, nearly a billion phones. A billion within a single year, that's a
04:20
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's, it is, uh, a little like the AirDrop on the, uh, iOS and, uh, iPhone that. There are several ways to connect
04:45
and send files on Android. In this example, when the both sides are all active status, the sender just select a file and the receiver will be shown on the screen and then the receiver
05:01
can tap the, uh, tap the profile picture of the receiver and, uh, 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
05:23
receiver and 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, uh, to transfer files or, uh, shake the phones at the same time. On the other hand, many nearby file sharing apps will
05:47
show the thumbnail. This will introduce a new attack vector, we will detail it later. Yeah. The sharing process or nearby sharing apps are shown here. In general, there are 4 steps. First, discover a BL advertising name, ID, ID device, ID device type and so on.
06:08
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 network.
06:23
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, uh, the, uh, the adversaries are nearby. The, the, the attackers can be SNF and sender or Bluetooth and Wi-Fi
06:43
packets. Then, what the attackers can eventually get when attack succeeded. First, the attacker can get the transfer files and more, such as hijack and the traffic, hijack the traffic, getting more information and even remote code execution. Here, the attack
07:11
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
07:28
join to a network without user's permission. On the other hand, attacker may obtain the established network's password because of unsecure connection. When files are transferring, there may be no encryption at all, so we can get the file directly. And
07:46
sometimes, the key exchange are not safe, so attackers can recover all the real file from the encrypted traffic. Next, device and ID spoofing. Uh, the, uh, uh, uh, uh, uh, uh, uh, device and ID spoofing. Many apps fail to authenticate the real device or users. For
08:05
example, when Alice wants to send the Bob file, then the attacker can collect all the Bobs, the, the, the advertised information and advertise themselves to create a fake Bob. In this case, many apps fail to distinguish between the fake and the real Bob. We
08:25
call it device and ID spoofing. Based on the device spoofing, the attackers may accomplish main the middle attack so the normal user will feel nothing. We'll show the demo later but the technique details will be explained later too. What's more, we found some other
08:44
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 decoder we can't even think about it. And Android components related to attack surfaces. Uh we are not the
09:05
first researchers to uh notify uh notice the near nearby communi-communication apps. We research about the zero conf on OS 10 and iOS, research by Xiao Long, Excelto, analyzed the AirDrop and found some vulnerabilities. And on the 19th some, some
09:23
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
09:46
nearby sharing apps. We analyzed many related apps include pre-installed and third party apps. And we found a lot of vulnerabilities in these apps. And then we arranged them in
10:02
several common attack methods. Um here let's show you some the real vulnerabilities. Notice that in this talk we will focus on the specific uh we won't focus on specific apps
10:23
or vendors. Uh so I will cover all the vendors and uh apps name here uh for just for uh security. Yeah. Besides there are huge number of users will be affected. Uh so uh I will
10:41
cover all the all the critical code too. Yeah. Some of the vulnerabilities are not fixed here so. We will present four vulnerabilities categories. Sniffer attack related vulnerabilities. To the main the middle attack related vulnerabilities. Then we will
11:00
talk about logic vulnerabilities. Finally we will present all the uh other vulnerabilities here. First let's talk about sniff attack. This is a building app or smart phone and we will take it as our example. This three picture shows a normal file sharing process. The
11:24
receiver don't need to input any password. Or something uh else. The whole process is totally automatic. However more convenience can often means less security. This app use Bluetooth low energy to advertise and discover other peers and transfer files by Wi-Fi P2P. Can
11:48
it accomplish a secure key exchange here to capture Bluetooth data? We can use a Bluetooth sniffer such as Ubertooth, NRF, File 1 and so on. This is a BLE package we
12:05
captured. It is a scan response packet which is send when someone some other person scanning. It contains your ID, device name and some other information such as some flags and spotted cipher, spotted cipher variants. The packet is a advertising packet which is
12:24
often easy to understand. And this is a BLE data packet. The BLE send data in 37, 38, 39 channels but Ubertooth can only sniff one channel at a time. So we need to sniff several times to get the data packet. The picture shows encrypted data transfer when
12:44
establishing connection between different variant 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 um obfuscated
13:06
badly so uh but we managed to recover a function which mainly rely rely on an AES crypto and some other transform- transformational data. Uh to make it more clear we can show you
13:20
an older version which is different but without any obfuscation but the whole process is just the same. In this older version there are nothing but an AES encryption which was different from the new version. But the overall logic was still the same. Yeah. So the P2P info is uh P2P info you can see in the slide is the encrypted information. And the P2P
13:48
CFGX 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 particular
14:03
shows a decrypt function which we can see the AES decryption here. Yeah. To decrypt the data we need to get the AES encryption keys which rely on the source string array and the M secure random. A secure string array can be gotten from the BLE packet. What about the M
14:25
secure random? It's it's name contains random. However we think that uh it must must not be the random number because the sender and receiver must be uh have the same uh number of this. So we found that it was stored in some XML file and it is fixed. That's
14:48
interesting here. So now the whole encryption can be break and we can recover data directly. This is a decrypt process for older version of the app. The latest version was
15:02
far more complicated. But we managed to reverse enjoy it. But uh it is similar in the design. We break it too and we will show you the output. The upper image shows a recovered P2P info old version. The second image here shows a recovered P2P info new
15:28
latest version so we can see the SSID and password are golden bars. So everything they transferred will be get directed by us. Based on the recovered password we can join
15:41
the network and get the transferred files through ARP spoofing. And let's show you two demos. Here the right phone take picture. Then here we will send the picture to the
16:05
left phone. And the computer act as an attacker. So we can see that info's are working. Collected there. Then the left phone got uh uh notification and then when he click the
16:29
accept here we can see that the computer will get it too. And this is a full photo we
16:47
just take picture of that. There. Here is demo two. It is the process is a little
17:02
different but there are some more interesting here. Some something very interesting I think. The left phone want to share a picture to the right phone. And we can see that
17:24
the picture was golden bars. Can see that pop out on the computer. We checked it it's a latest uh uh when we recorded the video. And when transfer apps actually uh they see
17:42
the picture here. And this shows that what using uh what all apps you installed on your phone. When sharing apps uh want to uh sharing uh photo here. Here we will send all
18:01
you installed all the apps you installed on your phone to the other phone. Uh it's a terrible info leak here I think. Next let's move on to the stack in the category. Main and middle attack related vulnerability. In nearby sharing apps, Windows standards
18:25
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 receiver by use a BLE scan
18:46
sender app to send advertising and scan response packets. The left phone shows uh uh profile picture of someone but uh it is actually uh um BLE sender app. Yeah. Then the
19:07
receiver will be shown on the sender screen. And in this picture we modify a real device to spoof another device. There are two active receivers here but the senders can only see one
19:20
device. So when he 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 attack when emulated a fake receiver and a fake sender. And we can secure if A send B a file there will be 50 percent chance that the file will be sent to
19:44
the attacker and chances can be improved by many ways. Now perfect main and middle attack can be designed like this. Uh A can find the uh uh 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
20:05
in discovery mode. Then and then the attacker can distinguish between A and fake A, B and B. Because he can't choose to block or receive any message. So the normal user A and B can
20:21
fill anything. Uh this is a demo. We didn't implement the whole process or the main and middle here due to time limitation. In this demo we just verify that the sender can distinguish between the real and fake receiver. So our main and middle attack will work
20:40
properly. Here we can see the normal user send the file and sometimes the users, the normal user get the file and sometimes the attackers will get the file. So here the
21:17
attacker will get the file here. Oh yeah now let's go to the third category. Logic
21:31
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
21:45
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
22:03
nearby sharing apps will establish the Wi-Fi connection as soon as the sender A just sends the request. But why the app developers choose an un- an secure way? We think that they might have their own consideration here. Mm more clicks often means less
22:24
convenience. So the developers don't want their users to double confirm. And the receiver uh often want to steal a thumbnail about the file to decide whether or not the accept the file or not. So convenience wins and sometimes security lose. Firstly the
22:45
non-confirmed 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 door for attacks to exploit other vulnerabilities and even choose zero click attack here.
23:04
Just exploit the uh fi- file image protocol here. Secondly we can hijack the victims network. In these two cases shown on this slide we can see that when transfer uh transfer
23:21
files that one device creates a Wi-Fi hotspot and the other device connect to it directly. However it is not this 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
23:45
found it 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
24:05
a connection. Android 7 is always the server because some compatibility issues here. Secondly we will make the other user to connect to my Wi-Fi without without
24:22
interaction. Can we do that? We found yes because it was designed like this. Yeah. Let's show a demo here. The victim just check his internet access and he just open the uh
24:45
file transfer apps and just leave it here or make it in background or turn turn the off turn the screen off here. The attacker request to send him file and then when victims
25:10
open his browser and he'll be hijacked. Yeah. Finally it's our fourth category, other
25:30
vulnerabilities. We will share three examples here. One, accept automatically via Wi-Fi P2P. Two, directory traversal. And three, remote code, remote file
25:47
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 pro-
26:01
pro- 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 we won't feel anything. So we'll get the file directly. The
26:21
second logic vulnerability example. And in this case, it is a directory traversal vulnerability. The file transfer was accomplished by web server. So the uh senders may create a web server and send the receiver a URL to get. Then, mmm, the receiver can
26:44
modify it to get any files here. Let's show the demo here. The right phone is the sender. Then he got a secret image. But he want to send another normal image to the left
27:04
phone. But here, the left phone will get anything he want. And in this case, we will share a file management related vulnerabilities. If an app want to open the active FCP server,
27:25
computer within the same local area network can manage the file in smart phone. We found that many apps didn't have any authentication here and secure design. Any users have read
27:42
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-confirm before Wi-Fi connection established. Two, no well protected
28:01
access to Wi-Fi or Wi-Fi P2P. Three, unsecure transport. And finally, no anti-spooting 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
28:24
story about nearby sharing apps. With uh, the red X mean no security measures at all. A yellow O means have security measures but can be bypassed here. There are no one green
28:41
here. But I will show no one here. There are little security measures such as access control when Wi-Fi uh was established here. Then we have the security measures, then we did a security survey for top 10 third party nearby sharing apps. And the results are
29:07
shown here. Uh most of them are vulnerable too. Only 20% of them can prevent sniffer attack and only 10% of them can prevent spoofing. And notice that this is a test result on
29:23
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 uh uh hotspot with their self-defined password on
29:41
Android 7. So when Android 7 and Android 8 were connection, make a connection, the Android 7 will always uh be the star and will be vulnerable. Yeah. Finally, let's talk about the mitigation. This is our four devices uh uh devices about mitigation.
30:06
Sorry. First, we need more secure Wi-Fi and Wi-Fi P2P key exchange. And two, we need, we need transport encryption. And three, it must designed to pro- prevent spoofing. And
30:25
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 channel such as NFC,
30:41
certificate based key exchange mechanism and the internet. On the other hand, the ping 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, we
31:05
recommend HTTP and transferring keys over internet security or pre-exchange keys for contacts. It is not very easy to prevent spoofing. We prevent a method here, we
31:23
prevent here but uh we use the certificate based authentication. When the app launch for the first time, it will get a unique ID dis- dis- distributed by the server and corresponded certificate signed with predefined trust anchor. So attacker can't sign the
31:44
unique ID correctly. We can make sure that the device had- can distinguish between the real user and the attackers. Hm, there are some other tips. First, we must prevent attacker
32:03
from joining the network and state file sharing turned off by default. We must and turned off the uh by- turned off them and after a period of idle time. And confirm before connection established. And finally, do not establish connection
32:23
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
32:42
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 DB human here uh
33:05
is easy to deploy and um have some uh security measure here but it is not very recommended because it can prevent main and middle attack. Now, this is our
33:22
conclusion. We analyze the attacker vectors on nearby sharing apps and did the first comp- comprehensive research about them. And we found many vulnerabilities here and we categorized in several common attack methods. And finally, we present some
33:46
effective mitigation methods here. Thank you. Now, the mitigations will be deployed on many
34:06
apps here but we can't tell which app uh is secure because the vendor didn't want to say that. Sorry about that.