start	end	text
13800	19660	Come on in. Move to the center of the row. Make sure that you get every single seat filled.
19660	23040	We want to make sure that we have enough room for everybody to get in.
23040	26020	We want to make sure that everybody gets a seat.
26020	29400	Get close. Get friendly. This is DEF CON. Make friends.
29760	32940	Are some of the things that I wish I could be telling you right now.
34740	36440	Unfortunately... yeah, we can't.
36440	40000	I'm here and you guys are where you're at, respectively.
40000	47800	So, with that said, we forage on and the second year of the AppSec Village continues on.
47960	59220	For this talk, we've got Pedro Umberlino and Joao Maurice to talk about bug foraging in Android.
59800	64060	Pedro is a security researcher by day and a Hackaday contributor by night.
64060	67880	He messes around with computers, started on the Spectrum.
67880	74960	He's been through the bulletin board age. He's been there for the drop of the internet and still roams around on IRC.
74960	77780	He's known on the internet by his handle Cryptor.
78060	80720	And he likes all sorts of hacks.
82080	87220	Joao is a penetration tester and researcher that started with the blue team.
87320	90280	Later was attracted to the red side of the force.
90400	97040	Although there's more focused in application security, he's learned all sorts of attack vectors.
97040	104440	So, if you would take some time, sit back, enjoy the talk and help me in welcoming these two fantastic presenters.
104680	107720	Hello and welcome to the Android bug foraging session.
107720	111640	It's great to be here at DefCon SafeMode AppSec Village giving this talk.
111640	118640	Despite everything that's happening, it's really good to see the community coming together and make sure this kind of events still happen.
118820	124920	My name is Pedro Umberlino. I'm a senior security researcher at Checkmark security research team.
124920	130300	I'm also a security researcher at Chair49. Sometimes I write for Hackaday.
130560	136200	One of my hobbies is to make hardware and my daytime job is to break software.
136240	139620	I'm giving this talk with a friend of mine and colleague, Joao.
142400	146460	Thank you, Pedro. Hello, everyone. Thanks for joining us here today.
146460	151060	My name is Joao Moraes. I'm a penetration tester team lead for a multinational company.
151060	154760	I also do pen testing and security research for other companies.
154760	159140	I'm part of the Checkmarks and Chair49 security research team.
159240	164860	So my background is very wide. I did many different things over the years, always related to security, though.
164880	173940	But in the last two years, I've been more focused in application security and mobile security, which is exactly what we brought here today for you.
173940	181700	So, yeah, we'll hand over the mic to Pedro now so that he can talk to you a little bit about this bug foraging concept.
183680	190380	Thanks, Joao. So foraging, foraging, the act of identifying and gathering wild food in nature.
190920	195940	Bug foraging is like kind of the same, but you're not in nature.
195940	201420	You're in the Android ecosystem. You're not hunting bugs to eat, but you eat because you hunt bugs.
201420	205380	So, yeah, it's not the same, but, you know, you get the idea.
205880	216560	So our motivation to do this talk, we wanted to, instead of having like a theoretical approach and shared practices in Android development and so forth,
216560	222360	we wanted to share our real life examples of vulnerabilities that we found in our analysis.
222460	230580	We wanted to share with you our process of approaching and devising meaningful attack scenarios and proof of concepts.
230580	239020	And in a nutshell, the overall experience that we have from first crash until disclosure process.
239020	248080	And for that, we are going to use four different examples of vulnerabilities in four different apps that we found.
248080	254280	Some of them are from our older work and some of them are going to be disclosed here firsthand.
254280	258620	So Joao is going to talk a bit about which vulnerabilities we are going to talk about.
258620	259700	So, Joao.
261580	262720	Thank you, Pedro.
262720	272220	Moving on to the agenda, we're going to present to you four cases, starting with Tinder, the app X, which is an app that we cannot say its real name,
272220	277860	Google Camera and Samsung Find My Mobile, the two really well known apps in the Android world.
277860	283160	And then final words, the main key takeaways from this bug foraging experience.
284900	288080	Moving on to case one, the Tinder application.
288620	294000	This is a very well known application that allows you to meet people and chat with them.
294180	301300	The only basic knowledge you need to have about this application is that it will show you pictures of people and you can swipe left or swipe right
301300	305180	and you'll actually be saying that you like them or dislike them.
305180	311420	And if they like you back, you'll have a match and then you can chat with them using the application.
312100	314900	So let's start with what we did.
314900	321760	We started by sniffing and collecting the traffic and we could see a lot of HTTP going on.
322020	332540	HTTP would allow us immediately to know that a certain IP and MAC address was using the application and also allowed us to know more.
332920	342720	It allowed us to match images with user IDs, because you can see there in green, that is actually the user ID that is shown in the URL.
342720	350240	Also, the image resolution is present, you can see in yellow, and will allow you to know if that image belongs to the user of the app
350240	355560	or someone who's the victim, let's call it victim, is chatting with.
356120	365720	And also allows you to see other users, so they are in the discovery, so other users that are being suggested to you for you to like or dislike them.
366620	371340	So now we have a good visibility, a good invasion of privacy.
371340	384700	But going a little bit deeper, we can see that in the HTTPS replies from the API, that's why you see the 443 part in the source, that's actually the reply from the API.
384700	391940	And you can see that the size of the payload is very different, and that changes accordingly to the actions of the user.
392060	397280	So we could do a direct match between the actions of the user and the size of the payload.
397280	409300	Of course, we put more 10 or 20 bytes in our parser, but it was around 278 for a NOPE, 374 for a LIKE, and 581 for a MATCH.
409400	419160	So now we could put all of this together, and we ended up with this application, the Tinder Drift, which is based or inspired in the DriftNet.
419280	426600	And if you have a man-in-the-middle attack going on, or if you have some sort of access to the traffic in your network,
426600	436760	you could easily identify users of the Tinder application, their MAC address and IP, you can see their picture on the top left,
436760	444680	you can see in the center the pictures of users that are being suggested, so they are being shown in his device,
444680	448820	and also his actions, the NOPES, the LIKES, and the MATCHES.
448900	453680	We also put some traffic down below for debugging purposes.
453680	458080	But you can see this working now, in this quick video.
458820	462420	This video is the Tinder Drift software demo.
462520	473060	Tinder Drift was inspired by DriftNet, and it's a software that passively analyzes network traffic, and is able to identify and profile Tinder app clients.
473260	476100	So, let's start the Tinder Drift for the demo.
476100	478040	This is the app right here.
479260	487080	It receives a PICAP file, it can be a live PICAP, and it still analyzes it.
487080	504670	So, on our mobile phone, we are starting Tinder, and after a while, you can see that we already detected which image am I seeing.
504670	514430	So, Tinder Drift takes advantage of the fact that the Tinder app fetches profile images via a non-encrypted HTTP connection,
514430	518830	and it associates that image, or those images, to a client.
518830	525950	After that, it analyzes the HTTPS encrypted connections from the client to the Tinder API server,
526230	533090	and infers the behavior of the client by the size of the server responses to that request.
533090	540230	So, when the user swipes left or right, the app sends a request to the API server.
540230	545850	The reply packet size can be used to determine which kind of action the user took,
545850	553670	if it's a like, a didn't like, or even if it's a like and it's a match, or if it's a super like.
555470	568690	So, you can see that it takes some time to stabilize, and after that, the software is able to identify which action the user took.
568690	571210	For example, let's like this profile.
572470	581850	When I swipe like, you can see here, in this corner, that the image was properly identified as a like.
581850	588130	And if it's a no like, it's a nope. So, let's like this also.
592050	596070	And you can see that the app updates.
596590	603650	The software also supports multiple clients. For example, let's switch to an iPhone.
604630	611490	The corporate response was quite fast, but they didn't consider this a big deal in the beginning.
611490	622090	This ended up in the news, where a massive media storm came, and that culminated with a US senator saying publicly that Tinder was vulnerable.
622090	628390	And, of course, that led to a very quick fix, and that was very positive.
628790	635130	There was no bounty, because at the time, as far as I recall, there was no bounty problem.
636810	640210	Let's move on to Case 2, the app X.
640310	648150	This is not really its name, it's just a name we made up, because we are not allowed to say its name legally, we can't do it.
648150	652550	But that won't be relevant for explaining the vulnerabilities.
653270	655350	So, let's move on.
656030	664070	Starting with what we did, we started by listing activities that could be used by other applications.
664870	670470	And we found out that the MainActivity can actually load a malicious URL.
670690	676850	And that's because there is some link validation, but it's not very strong.
676850	679210	I mean, you can see the regex down there.
679210	685590	If you have a slash, an L character, and a slash, your link is valid.
685850	688550	And it will be loaded by the WebView.
688610	690670	So, you'll end up with something like this.
690670	701430	If you have an attacking application, it can create an intent that will then open the app X, which will then load your malicious content in the WebView.
701430	706530	We tested that with the ActivityManager using ADP, and it works.
706850	718530	So, we did actually create an attacking application, and we did as well create an HTML page, which was exactly the same as the original login page for the app.
718530	727330	So, a user would not be able to distinguish between the original web page for logging in and our malicious page for logging in.
727330	732010	And we could steal the credentials, and the application would still work smoothly.
734190	737090	We tried to leverage these findings.
737110	741570	We looked for other things, and we found several JavaScript interfaces.
741570	749970	As you know, a JavaScript interface is an export of a native Java function, and allows the JavaScript in your WebView to use it.
749970	757390	And this particular setBaseURLs function allows you to change the URL of the API.
757570	761390	And we can replace it with our own URL.
762170	765790	And when you do that, this change is permanent.
765790	771150	Your application will contact our malicious API instead of the original API.
771150	777070	The app has certificate pinning, and it works well, but it also supports plain HTTP.
777070	786450	So, we can actually use an HTTP URL, and the same with the official API that works either in HTTPS or plain HTTP.
786450	795050	So, this was the perfect scenario for a man-in-the-middle attack, although we still need to trick the victim into installing a malicious app.
795670	798110	So, we tried to go deeper.
798110	801770	We saw there were some deep links for this app.
801770	809130	Let's consider this scheme. Of course, it's not the real scheme, the appX, just for clarity.
809770	813010	And there is a messaging system in the application.
813010	824870	So, we were trying to think of a way to send a link in which we could exploit this exactly in the same way, but without requiring a malicious application.
824870	831010	So, the chat feature doesn't support deep links, but it supports regular web links.
831410	840630	And we could actually send a regular web link, the browser would open it, we could redirect to a deep link to the appX schema.
841030	846950	But how would we pass the parameter then to the main activity?
846950	856990	But it would use the default HTML content, and we wanted to be able to pass it our malicious URL.
857930	862150	So, we ended up with something like this. This is the full chain of events.
862150	866170	You can see down there the full URI for the exploit.
866350	875550	The appX will open the application, and the af-dp parameter will allow us to inject that HTML in the web view.
875550	880170	But let's start from the beginning. So, we don't need a malicious application anymore.
880170	884690	We just need a message, and we'll send a message with a web link.
884690	888330	As soon as the user opens the link, Google Chrome is called.
888330	897710	It will request a malicious page to our server, and our server will redirect to that full URI that you see down there.
897710	909190	So then, the Android knows that appX scheme. It will open the appX application, and the appX application will load our http attacking.site.com.
909190	912570	Of course, that's a fake domain, just for demonstration purposes.
912570	919210	You can see the slash L slash, so that it will pass the validation, and this will work.
919210	925290	We have the full exploit, just like we did before, but without requiring a malicious application.
925290	936690	Now, the af underscore dp parameter is something that we found via reverse engineering, and you can see there its content will be loaded in the web view.
937190	952450	So, summing this up, when the victim clicks in the link, the attacker can steal its cookies, impersonate, take over account, monitor all the application activity, read private messages.
952450	965650	It can track the victim to its geographic location, because the app has this feature, and it can also create a wormable exploit, where all the contacts will receive a malicious link,
965650	975790	and by each contact that presses on the link, it will send it to all the contacts of that contact, and so on, and so on.
975790	979770	So, becoming a sort of a wormable exploit.
979770	988030	And consider that the application will always behave normally to the victim's eyes, so it won't know it's actually being hacked.
989010	999610	I was going to show you a quick video demonstrating, but there was some crash on our VLC player, so I'll just move on to the corporate response.
999610	1005770	So, the response was good, it was fast, it was classified as a critical issue, it was fixed.
1005770	1012890	There was no bounty, because I think there was no bug bounty program at the time, but there was some legal issues.
1012890	1021030	This wasn't good, and we could avoid this, but we'll talk about this in the final words section.
1021090	1027250	And now I'll hand over to Pedro, so that he'll talk to you about the Google Camera application.
1027690	1028350	Pedro?
1030820	1031820	Thanks, João.
1031900	1036020	Now we are going to look into case number three, which is the Google Camera.
1036860	1047180	The Google Camera app comes installed on millions of different devices, and this was a research that comes in the context of an audit to the Pixel 3.
1047180	1059980	Sometimes, instead of looking into a specific application, we just choose a vendor and buy the latest phone and start to look into the pre-installed applications that come,
1059980	1065420	since this implies a bigger attack surface and more users that could be at risk.
1065420	1069180	And in this case, we were focusing on the Google Camera app.
1069180	1072560	Now, the process is kind of the same.
1072560	1081120	When you do Android reversing for a while, you just list the activities and broadcast receivers and so forth that you can call without permissions.
1081120	1085460	You reverse the APK, you analyze the traffic, you start reading the code.
1085460	1092960	So, in this case, there was a lot of exported activities and defined actions inside the Google Camera app.
1092960	1098900	Now, we started to test the behavior of these activities and actions and look for interesting stuff,
1098900	1109460	because sometimes it's easier just to start and test the behavior of the application instead of reading tons of reversed code, sometimes obfuscated.
1109460	1117440	So, we noticed that there's this action called Video Camera that starts the Google Camera app and immediately starts recording.
1117440	1124500	And we found that interesting, because there's also this action Video Capture that does not start recording.
1124740	1127340	So, why were there two different ones?
1127340	1132500	Any other action would open the Google Camera in photo mode, but does not take a picture.
1132500	1139840	So, we are looking like the attack scenario here is a rogue application that's trying to control the Google Camera application.
1139840	1151640	So, we map out which classes handle which intents and which actions, and then you start reading the code and try to figure out if there's any extras or data or actions
1151640	1161820	that you can pass to the program and to the application and modifies the execution path or the behavior, right?
1161820	1165460	So, we noticed at least three interesting extras.
1165460	1176400	The first one is called Use Front Camera, which allows the controller app to choose if the Google Camera is going to use the front camera or the back camera.
1176400	1183100	There was this Duration Seconds, which allows the camera to start the timer before taking a picture.
1183200	1190720	And this obscure one called Extra Turn Screen On, which essentially does what it says it does. It turns the screen on.
1190720	1193820	Now, why was this interesting?
1193820	1200660	Because the Timer Duration Seconds, for example, starts the Google Camera app and also starts the timer.
1200660	1209100	So, you could take video without user interaction, and now we figure out a way to take a photo without user interaction if you use a timer.
1209100	1216560	The minimum default timer is three seconds. It's hard-coded. But still, you can take photos without user interaction.
1216560	1231260	And the Extra Turn Screen On was very interesting because it makes the camera app to open even if the phone is on standby or even if the smartphone is locked with a PIN number.
1231260	1239140	So, you can actually start from the background, start the Google Camera and take a picture and record a video.
1239140	1246480	Why is this interesting? Because usually the videos and the photos are stored in the SD card.
1246480	1254280	And the SD card, as you know, it's easily accessible by other applications that have the read external storage permission.
1254280	1260520	So, we started to think how can we leverage this in a meaningful attack scenario, right?
1260520	1270940	So, we devised this combination. Now, you can make a rogue app, you know, take a picture, record a video without user interaction even if the phone is locked.
1271760	1278740	And the big problem here is that this rogue app does not need permissions, does not need camera permissions.
1278740	1287380	It just abuses the Google Camera app to take these actions for himself.
1287380	1298760	So, we devised a POC called Spixel. It's a client-server architecture. The client is a rogue weather app.
1298800	1306620	It only needs the read external storage permissions and the internet permissions to communicate with the command-and-control server.
1306920	1314180	The command-and-control server listens for every client and has a bunch of interesting features.
1316260	1325000	The command-and-control server can order the rogue app to take a photo or take a video from a chosen camera.
1325000	1334220	It uses some stealth features that we developed to prevent that the Google Camera app is popping up or making a sound.
1334220	1349920	We can mute all the audio streams. This was actually another topic that we submitted to Google because it was not supposed to be possible to mute the phone without permissions to do so.
1350560	1352140	And it's another bug.
1352200	1357880	We monitor the proximity sensor to know if the phone is upside down or not or you are on a call.
1358440	1361880	We devised a feature called auto-record calls.
1362080	1366840	When you answer the phone and you put the phone next to your face, it starts recording.
1367240	1371600	And it's actually possible to listen to conversations on both sides.
1372120	1378560	If EXIF data is on, you can grab the GPS locations and locate the user.
1378560	1386580	You can issue the camera to take a photo and then parse the EXIF data and grab the GPS position.
1386580	1398540	This is not completely related to the vulnerability in itself, but we got creative and implemented this on the tool, among other features.
1399560	1401900	Now we are going to see a demo.
1403480	1408420	This demo shows the auto-record feature when David answers.
1411560	1413000	Hello?
1413800	1415240	Hello?
1415380	1422180	You can see on the right side the image from the camera, superimposed.
1429430	1441430	And this is the attacker side when it actually receives the video and plays it back to the attacker on the Spixel interface.
1443090	1451450	The corporate response here was really, I think, standard for Google, which is really high for everyone else.
1451570	1455970	We got a medium-fast response after the first report.
1455970	1458650	This was classified as a medium-impact vulnerability.
1459190	1467370	Then we shared our tool and an explanation of what we did and how our tool could bypass a locked phone.
1467370	1470190	And then they classified it as a high-impact vulnerability.
1470190	1474610	The response from then on was really, really fast.
1474610	1483610	They contacted other vendors that were identified as using the Google Camera or a by-product of Google Camera, some derivative.
1483690	1486350	There were also other companies affected.
1486390	1494610	And in the end, Google granted a $75,000 USD bounty, which was really cool.
1495390	1500370	So now we reach our last case, which is case number 4, Samsung Find My Mobile.
1500490	1510130	Now, Find My Mobile is an application that works together with a website that a Samsung account owner can use to locate his phone if it's lost.
1510190	1514130	You just log into the website, make the phone ring, and lock the phone and whatever.
1514130	1525770	So this was research in the context of an audit to a Samsung S8, also looking into default install applications and trying to figure out if there are some vulnerabilities there.
1526090	1538890	Now, the process is kind of the same, just list the activities, try to find some things that are reachable by other applications without permissions, reverse the APK, analyze traffic, and so forth.
1538890	1543290	There was not much luck involved at first, but digging a bit deeper...
1544150	1551970	There's some piece of code that didn't even decompile correctly that refers to a file in the SD card called fmm.prop.
1551970	1567090	Now, this was an interesting file to know, and after reversing, it was possible to understand that the program would load the mg.url and dive.url from this file if the file existed.
1567090	1579810	So this location, since it lives on the SD card, allows a malicious application to create this file, and fmm will use it and will communicate with the backend mg server.
1579810	1586190	There are going to be a lot of servers in this example, so the mg server is like the management server.
1586190	1591790	And we can control it if we create this file and pass it a URL that you want.
1591810	1596150	But creating this file is not enough. You must force fmm to assume this file.
1596150	1603010	Usually this happens at bootup, but it's not really interesting if you cannot control it.
1603010	1606110	So this was vulnerability number one.
1606110	1610790	And now vulnerability number two comes from a broadcast receiver.
1610790	1622690	So there's this broadcast receiver called pcwreceiver, that when it receives the action that registration was completed, it will proceed to update the URLs.
1622690	1639550	So what this means in practice is that by sending a broadcast message to this pcwreceiver, fmm gets signaled that the registration is completed,
1639550	1645290	and then it contacts the mg server to perform this registration again.
1645290	1652590	And this mg server is the URL that we already under control in vulnerability number one.
1652590	1662630	Now, this is interesting because by pointing the mg URL to an attacker control server, enforcing this registration with vulnerability number two,
1662630	1665430	we can get a lot of details about the user.
1665430	1674850	Because the phone contacts our own server, and then we can get the course location via IP address, registration ID, IMEI.
1674850	1679130	There's a lot of information that comes with this registration request.
1679130	1688250	And so joining these two vulnerabilities together, we can effectively found a way to monitor a user remotely.
1688250	1695210	This all happens in background, and the user has no way of knowing this is happening.
1695550	1702070	So, but this is kind of not enough. I didn't want just to monitor users, I want more.
1702070	1711690	So, by analyzing the original mg server response, we can see that the response comes with a lot of different URLs.
1711690	1716310	There's like this DM server, DS server, OSP server.
1716310	1725110	I didn't get to the, you know, the bottom of all servers, what they all work for, and what they are for.
1725110	1732310	But it was nice to see that we can also control the other endpoints.
1732350	1736770	And this allows us to go and talk about vulnerability number three.
1736770	1742410	Now, the vulnerability number three exists in another receiver called the SPP receiver.
1742410	1750690	And there's this magic action that you can see there, that's FB0BD, so hexadecimal string.
1750690	1756880	That indicates to FMM if there was a push message received.
1757410	1767070	Now, by sending a broadcast with this magic action, we can additionally add an extra with the push messages.
1767550	1772410	There was a lot of work involved in reversing these messages.
1772410	1780070	They are all encrypted, and it's kind of hard to read, but luckily the key was hard-coded in the code.
1780070	1786310	And we don't even have to understand what are all these messages for.
1786870	1793410	We just need to know if we can craft the proper message, then we can get FMM to talk with the DM server.
1793410	1799310	Now, while the NG server seems for registration processes and delivering reports,
1799310	1810090	the DM server actually stores the actions that the user performs when he logs into the website or to the web interface.
1810090	1819830	Now, the website, you can find it in findmymobile.samsung.com, has a map and has an overlay.
1819830	1824730	The user can log in and perform, depending on the API level, you can perform a lot of actions.
1824730	1833630	You can ring the phone, you can lock the phone and leave a message, create a backup, retrieve call logs and SMSs,
1833630	1840450	erase all data on the phone, so there's a lot of different actions that you can make on the web interface.
1840530	1846290	Now, they are executed by the phone when the phone receives these messages,
1846290	1851210	but the phone could be offline or somewhere without network access.
1851210	1861190	So, it's possible for the attacker to send the broadcast to this SPP server that results in FMM contact this DM server
1861190	1871770	and searches for pending actions that were taken and FMM didn't have network connectivity to perform those actions.
1871770	1878990	Now, this communication uses a proprietary SyncML implementation, which was a bit hard to figure out.
1880090	1889770	It's not like standard SyncML, to the best of my knowledge, and there's something called Auth MD5 on this communication,
1889770	1893790	so I assume there was some kind of authentication going on and encryption.
1894550	1903770	So, what happens is, when the FMM contacts the DM server, the DM server can just reply with an OK
1903770	1910450	or the accumulated actions that were requested and missed while the smartphone was offline.
1910450	1919830	And this is where you can come in, because of vulnerability number two, we actually control the DM server.
1919830	1922310	We control the NG server and the DM server.
1922450	1930290	But, to be able to perform something like closely, remotely resembling a man-in-the-middle attack,
1930290	1936010	we need a valid certificate, you need to monitor the messages, you need to detect the message types,
1936010	1943830	change the requests on the fly, and you have to bypass this SyncML Auth MD5 mechanism at the same time to make everything work.
1945150	1953290	So, now we are going into vulnerability number four, which is the SyncAuth MD5 algorithm.
1953510	1956970	So, it has nothing to do with MD5 weaknesses.
1957270	1967150	The authentication protocol seems to be like the client connects to the server and sends a field SyncML Auth MD5 on the first request.
1967210	1969030	I assume this is a challenge.
1969030	1976990	The server responds with another Auth MD5 field, which only depends on the client challenge,
1976990	1984130	the original client challenge in the IMA, which I assume is the response, and then the client now accepts all server replies from now on.
1985490	1987370	Why is this important?
1987490	1993270	It's because there is no message signing or any mechanism that prevents message modification,
1993270	1996670	which is really great for an attacker in the man-in-the-middle position.
1998670	2004870	You don't even need to reverse the response verification mechanism to make this work.
2004870	2011970	You can just man-in-the-middle the connection and send the authentication, the challenge packet to the server,
2011970	2017950	grab the response, send to the client, and then you can just use that token and communicate,
2017950	2023950	because you can change the content of the packet because there was no message signing.
2025110	2030450	Putting it all together, if you put all these vulnerabilities together...
2030450	2039850	With vulnerability number one, you can use the fmmprop file to change the MG server to your own server.
2039850	2049630	Then you send a broadcast to the PCW receiver, and then you can get the MG server that has all these actions stored
2050630	2055030	and force the update via a spoofed response.
2055030	2065250	Then you send another broadcast message to the SPP receiver that actually makes FMM contact the DM server
2065250	2068370	and fetches any outstanding actions.
2068710	2079070	You are in the middle of this connection, so you just forward the challenge packet to the original server,
2079070	2085310	grab the response, and then inject your own actions in the client, since there's no message integrity here.
2085310	2089450	And then the smartphone can actually execute whatever message you decide for it.
2089450	2097330	So, you know, the too-long-didn't-read version is that any application could reset your phone,
2097330	2105410	steal your messages, locate the user, anything that FMM supports, and depending on the API level,
2105410	2114710	any application without permissions, except to actually use the SD card, which is one of the most common permissions,
2114710	2117810	you can do whatever that FMM supports.
2117990	2126170	It works on a wide range of devices, including the S7, the S8, the S9+, this was tested on a lot of devices,
2126170	2129990	and we have a demo that we can show now.
2130950	2139470	So, I can actually claim that I'm able to, you know, erase all contents of the phone without actually showing it.
2139490	2144210	So, here's the server configuration files.
2144830	2151810	I'm going to switch my action to Nuke.
2155490	2166790	This video is a bit sketchy, I'm sorry, but I cannot record the mobile phone screen at the same time.
2167950	2172850	So, here's the Samsung S8.
2173850	2174610	Unlock it.
2174610	2184490	I'm going to start the POC, and over here I'm telling the logs of the rogue server.
2184710	2190010	So, I'm going to do the exploit step by step.
2190530	2194010	This is the first step, which changes the FMM prop.
2194370	2196410	This is the second step.
2196410	2206470	As you can see here, you can already watch that the rogue server receives the register requests.
2206470	2212190	So, the URL endpoints now should already be taken over here.
2212190	2223070	And now, when I'm going to do step 3, FMM is going to contact the sync server, the DM server.
2223270	2228330	But it's already spoofed, so the reply will be Nuke.
2228330	2233210	And you can see it happened in real time here.
2233670	2235450	And kabam!
2235930	2239290	Bye bye, dear S8.
2239290	2246210	So, it's the same thing that happened on the other video, but the action is actually different.
2246210	2250510	The action is the erase, so the phone gets erased.
2250510	2258510	Also, the SD card is formatted, so all data in this phone is lost.
2259590	2261290	That's it.
2261350	2266190	Here you can see the different steps.
2267190	2275610	So, over here there's step 1.
2276030	2284670	This is where the authentication gets stolen from the server.
2284670	2294070	The reply to the phone is injected with 2bwipe.
2294070	2298150	It's hard to see here, but it's over here, 2bwipe.
2298150	2309010	And then a series of steps that are needed to actually make the phone erased.
2309950	2320770	So, working with Samsung in the Samsung Bounty program, they are very organized and they issued a fast response after the first report.
2320770	2323990	This was classified as a high-impact vulnerability.
2324290	2329370	And then we realized there was a lot more into it.
2329370	2337790	This kind of behavior affects many different parts from the application part, the web server part.
2337790	2342790	There were some things that needed to change. It took some time until they could issue a proper fix.
2342890	2346510	And they granted a 10k USD bounty.
2346750	2354410	And in addition, there were some closely related critical flaws that are not in the scope of this talk.
2354410	2356970	It's not the application side.
2356970	2361370	So, it was added a 25k USD bonus.
2361450	2364250	So, in the end, it was very, very nice.
2365170	2367770	So, this concludes our presentation.
2367870	2377550	We tried to give you a variety of examples of real applications that faced different problems like the lack of encryption,
2377550	2382190	problems in the web views, legacy code, intents without permissions.
2382190	2390950	These are all different issues that sometimes are common to other applications or some of them are very Android specific.
2391170	2395070	Before we go, we'd like to just say some words.
2395210	2402450	We really believe that we are trying to make the world just a slightly better place by, you know, identifying these vulnerabilities,
2402450	2406830	making people overall a bit more safe while being online.
2406830	2412890	Luckily, we are paid for this research and we're not depending on bounties.
2412890	2415630	But, of course, they are always appreciated.
2416710	2426090	It's interesting to note that the vulnerability complexity does not, you know, equal having a greater impact or more rewards.
2426090	2434590	Sometimes you spend a lot of time trying to develop a POC or a working POC on a very complex issue.
2434590	2446630	Other times you just find a very simple bug that has a lot of impact and you can usually get a higher reward if you are in it for the bounties.
2446890	2452530	And the final word is that we are really a friend. We are not the enemy.
2452530	2464850	We are trying to help companies making a better product, sometimes products that we actually use and we have a complete interest in making the product better.
2465250	2470270	And, you know, threats and liars, legal suits are really not necessary.
2471310	2478970	We think of ourselves as friends and we are not trying to hurt the company's image or whatever in any way.
2478970	2487750	So I think now we are going to be open for questions if anyone wants to ask something.
2487750	2488950	Thank you.