[00:13.800 --> 00:19.660]  Come on in. Move to the center of the row. Make sure that you get every single seat filled.
[00:19.660 --> 00:23.040]  We want to make sure that we have enough room for everybody to get in.
[00:23.040 --> 00:26.020]  We want to make sure that everybody gets a seat.
[00:26.020 --> 00:29.400]  Get close. Get friendly. This is DEF CON. Make friends.
[00:29.760 --> 00:32.940]  Are some of the things that I wish I could be telling you right now.
[00:34.740 --> 00:36.440]  Unfortunately... yeah, we can't.
[00:36.440 --> 00:40.000]  I'm here and you guys are where you're at, respectively.
[00:40.000 --> 00:47.800]  So, with that said, we forage on and the second year of the AppSec Village continues on.
[00:47.960 --> 00:59.220]  For this talk, we've got Pedro Umberlino and Joao Maurice to talk about bug foraging in Android.
[00:59.800 --> 01:04.060]  Pedro is a security researcher by day and a Hackaday contributor by night.
[01:04.060 --> 01:07.880]  He messes around with computers, started on the Spectrum.
[01:07.880 --> 01:14.960]  He's been through the bulletin board age. He's been there for the drop of the internet and still roams around on IRC.
[01:14.960 --> 01:17.780]  He's known on the internet by his handle Cryptor.
[01:18.060 --> 01:20.720]  And he likes all sorts of hacks.
[01:22.080 --> 01:27.220]  Joao is a penetration tester and researcher that started with the blue team.
[01:27.320 --> 01:30.280]  Later was attracted to the red side of the force.
[01:30.400 --> 01:37.040]  Although there's more focused in application security, he's learned all sorts of attack vectors.
[01:37.040 --> 01:44.440]  So, if you would take some time, sit back, enjoy the talk and help me in welcoming these two fantastic presenters.
[01:44.680 --> 01:47.720]  Hello and welcome to the Android bug foraging session.
[01:47.720 --> 01:51.640]  It's great to be here at DefCon SafeMode AppSec Village giving this talk.
[01:51.640 --> 01:58.640]  Despite everything that's happening, it's really good to see the community coming together and make sure this kind of events still happen.
[01:58.820 --> 02:04.920]  My name is Pedro Umberlino. I'm a senior security researcher at Checkmark security research team.
[02:04.920 --> 02:10.300]  I'm also a security researcher at Chair49. Sometimes I write for Hackaday.
[02:10.560 --> 02:16.200]  One of my hobbies is to make hardware and my daytime job is to break software.
[02:16.240 --> 02:19.620]  I'm giving this talk with a friend of mine and colleague, Joao.
[02:22.400 --> 02:26.460]  Thank you, Pedro. Hello, everyone. Thanks for joining us here today.
[02:26.460 --> 02:31.060]  My name is Joao Moraes. I'm a penetration tester team lead for a multinational company.
[02:31.060 --> 02:34.760]  I also do pen testing and security research for other companies.
[02:34.760 --> 02:39.140]  I'm part of the Checkmarks and Chair49 security research team.
[02:39.240 --> 02:44.860]  So my background is very wide. I did many different things over the years, always related to security, though.
[02:44.880 --> 02:53.940]  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.
[02:53.940 --> 03:01.700]  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.
[03:03.680 --> 03:10.380]  Thanks, Joao. So foraging, foraging, the act of identifying and gathering wild food in nature.
[03:10.920 --> 03:15.940]  Bug foraging is like kind of the same, but you're not in nature.
[03:15.940 --> 03:21.420]  You're in the Android ecosystem. You're not hunting bugs to eat, but you eat because you hunt bugs.
[03:21.420 --> 03:25.380]  So, yeah, it's not the same, but, you know, you get the idea.
[03:25.880 --> 03:36.560]  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,
[03:36.560 --> 03:42.360]  we wanted to share our real life examples of vulnerabilities that we found in our analysis.
[03:42.460 --> 03:50.580]  We wanted to share with you our process of approaching and devising meaningful attack scenarios and proof of concepts.
[03:50.580 --> 03:59.020]  And in a nutshell, the overall experience that we have from first crash until disclosure process.
[03:59.020 --> 04:08.080]  And for that, we are going to use four different examples of vulnerabilities in four different apps that we found.
[04:08.080 --> 04:14.280]  Some of them are from our older work and some of them are going to be disclosed here firsthand.
[04:14.280 --> 04:18.620]  So Joao is going to talk a bit about which vulnerabilities we are going to talk about.
[04:18.620 --> 04:19.700]  So, Joao.
[04:21.580 --> 04:22.720]  Thank you, Pedro.
[04:22.720 --> 04:32.220]  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,
[04:32.220 --> 04:37.860]  Google Camera and Samsung Find My Mobile, the two really well known apps in the Android world.
[04:37.860 --> 04:43.160]  And then final words, the main key takeaways from this bug foraging experience.
[04:44.900 --> 04:48.080]  Moving on to case one, the Tinder application.
[04:48.620 --> 04:54.000]  This is a very well known application that allows you to meet people and chat with them.
[04:54.180 --> 05:01.300]  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
[05:01.300 --> 05:05.180]  and you'll actually be saying that you like them or dislike them.
[05:05.180 --> 05:11.420]  And if they like you back, you'll have a match and then you can chat with them using the application.
[05:12.100 --> 05:14.900]  So let's start with what we did.
[05:14.900 --> 05:21.760]  We started by sniffing and collecting the traffic and we could see a lot of HTTP going on.
[05:22.020 --> 05:32.540]  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.
[05:32.920 --> 05:42.720]  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.
[05:42.720 --> 05:50.240]  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
[05:50.240 --> 05:55.560]  or someone who's the victim, let's call it victim, is chatting with.
[05:56.120 --> 06:05.720]  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.
[06:06.620 --> 06:11.340]  So now we have a good visibility, a good invasion of privacy.
[06:11.340 --> 06:24.700]  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.
[06:24.700 --> 06:31.940]  And you can see that the size of the payload is very different, and that changes accordingly to the actions of the user.
[06:32.060 --> 06:37.280]  So we could do a direct match between the actions of the user and the size of the payload.
[06:37.280 --> 06:49.300]  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.
[06:49.400 --> 06:59.160]  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.
[06:59.280 --> 07:06.600]  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,
[07:06.600 --> 07:16.760]  you could easily identify users of the Tinder application, their MAC address and IP, you can see their picture on the top left,
[07:16.760 --> 07:24.680]  you can see in the center the pictures of users that are being suggested, so they are being shown in his device,
[07:24.680 --> 07:28.820]  and also his actions, the NOPES, the LIKES, and the MATCHES.
[07:28.900 --> 07:33.680]  We also put some traffic down below for debugging purposes.
[07:33.680 --> 07:38.080]  But you can see this working now, in this quick video.
[07:38.820 --> 07:42.420]  This video is the Tinder Drift software demo.
[07:42.520 --> 07:53.060]  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.
[07:53.260 --> 07:56.100]  So, let's start the Tinder Drift for the demo.
[07:56.100 --> 07:58.040]  This is the app right here.
[07:59.260 --> 08:07.080]  It receives a PICAP file, it can be a live PICAP, and it still analyzes it.
[08:07.080 --> 08:24.670]  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.
[08:24.670 --> 08:34.430]  So, Tinder Drift takes advantage of the fact that the Tinder app fetches profile images via a non-encrypted HTTP connection,
[08:34.430 --> 08:38.830]  and it associates that image, or those images, to a client.
[08:38.830 --> 08:45.950]  After that, it analyzes the HTTPS encrypted connections from the client to the Tinder API server,
[08:46.230 --> 08:53.090]  and infers the behavior of the client by the size of the server responses to that request.
[08:53.090 --> 09:00.230]  So, when the user swipes left or right, the app sends a request to the API server.
[09:00.230 --> 09:05.850]  The reply packet size can be used to determine which kind of action the user took,
[09:05.850 --> 09:13.670]  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.
[09:15.470 --> 09:28.690]  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.
[09:28.690 --> 09:31.210]  For example, let's like this profile.
[09:32.470 --> 09:41.850]  When I swipe like, you can see here, in this corner, that the image was properly identified as a like.
[09:41.850 --> 09:48.130]  And if it's a no like, it's a nope. So, let's like this also.
[09:52.050 --> 09:56.070]  And you can see that the app updates.
[09:56.590 --> 10:03.650]  The software also supports multiple clients. For example, let's switch to an iPhone.
[10:04.630 --> 10:11.490]  The corporate response was quite fast, but they didn't consider this a big deal in the beginning.
[10:11.490 --> 10:22.090]  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.
[10:22.090 --> 10:28.390]  And, of course, that led to a very quick fix, and that was very positive.
[10:28.790 --> 10:35.130]  There was no bounty, because at the time, as far as I recall, there was no bounty problem.
[10:36.810 --> 10:40.210]  Let's move on to Case 2, the app X.
[10:40.310 --> 10:48.150]  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.
[10:48.150 --> 10:52.550]  But that won't be relevant for explaining the vulnerabilities.
[10:53.270 --> 10:55.350]  So, let's move on.
[10:56.030 --> 11:04.070]  Starting with what we did, we started by listing activities that could be used by other applications.
[11:04.870 --> 11:10.470]  And we found out that the MainActivity can actually load a malicious URL.
[11:10.690 --> 11:16.850]  And that's because there is some link validation, but it's not very strong.
[11:16.850 --> 11:19.210]  I mean, you can see the regex down there.
[11:19.210 --> 11:25.590]  If you have a slash, an L character, and a slash, your link is valid.
[11:25.850 --> 11:28.550]  And it will be loaded by the WebView.
[11:28.610 --> 11:30.670]  So, you'll end up with something like this.
[11:30.670 --> 11:41.430]  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.
[11:41.430 --> 11:46.530]  We tested that with the ActivityManager using ADP, and it works.
[11:46.850 --> 11:58.530]  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.
[11:58.530 --> 12:07.330]  So, a user would not be able to distinguish between the original web page for logging in and our malicious page for logging in.
[12:07.330 --> 12:12.010]  And we could steal the credentials, and the application would still work smoothly.
[12:14.190 --> 12:17.090]  We tried to leverage these findings.
[12:17.110 --> 12:21.570]  We looked for other things, and we found several JavaScript interfaces.
[12:21.570 --> 12:29.970]  As you know, a JavaScript interface is an export of a native Java function, and allows the JavaScript in your WebView to use it.
[12:29.970 --> 12:37.390]  And this particular setBaseURLs function allows you to change the URL of the API.
[12:37.570 --> 12:41.390]  And we can replace it with our own URL.
[12:42.170 --> 12:45.790]  And when you do that, this change is permanent.
[12:45.790 --> 12:51.150]  Your application will contact our malicious API instead of the original API.
[12:51.150 --> 12:57.070]  The app has certificate pinning, and it works well, but it also supports plain HTTP.
[12:57.070 --> 13:06.450]  So, we can actually use an HTTP URL, and the same with the official API that works either in HTTPS or plain HTTP.
[13:06.450 --> 13:15.050]  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.
[13:15.670 --> 13:18.110]  So, we tried to go deeper.
[13:18.110 --> 13:21.770]  We saw there were some deep links for this app.
[13:21.770 --> 13:29.130]  Let's consider this scheme. Of course, it's not the real scheme, the appX, just for clarity.
[13:29.770 --> 13:33.010]  And there is a messaging system in the application.
[13:33.010 --> 13:44.870]  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.
[13:44.870 --> 13:51.010]  So, the chat feature doesn't support deep links, but it supports regular web links.
[13:51.410 --> 14:00.630]  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.
[14:01.030 --> 14:06.950]  But how would we pass the parameter then to the main activity?
[14:06.950 --> 14:16.990]  But it would use the default HTML content, and we wanted to be able to pass it our malicious URL.
[14:17.930 --> 14:22.150]  So, we ended up with something like this. This is the full chain of events.
[14:22.150 --> 14:26.170]  You can see down there the full URI for the exploit.
[14:26.350 --> 14:35.550]  The appX will open the application, and the af-dp parameter will allow us to inject that HTML in the web view.
[14:35.550 --> 14:40.170]  But let's start from the beginning. So, we don't need a malicious application anymore.
[14:40.170 --> 14:44.690]  We just need a message, and we'll send a message with a web link.
[14:44.690 --> 14:48.330]  As soon as the user opens the link, Google Chrome is called.
[14:48.330 --> 14:57.710]  It will request a malicious page to our server, and our server will redirect to that full URI that you see down there.
[14:57.710 --> 15:09.190]  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.
[15:09.190 --> 15:12.570]  Of course, that's a fake domain, just for demonstration purposes.
[15:12.570 --> 15:19.210]  You can see the slash L slash, so that it will pass the validation, and this will work.
[15:19.210 --> 15:25.290]  We have the full exploit, just like we did before, but without requiring a malicious application.
[15:25.290 --> 15:36.690]  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.
[15:37.190 --> 15:52.450]  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.
[15:52.450 --> 16:05.650]  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,
[16:05.650 --> 16:15.790]  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.
[16:15.790 --> 16:19.770]  So, becoming a sort of a wormable exploit.
[16:19.770 --> 16:28.030]  And consider that the application will always behave normally to the victim's eyes, so it won't know it's actually being hacked.
[16:29.010 --> 16:39.610]  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.
[16:39.610 --> 16:45.770]  So, the response was good, it was fast, it was classified as a critical issue, it was fixed.
[16:45.770 --> 16:52.890]  There was no bounty, because I think there was no bug bounty program at the time, but there was some legal issues.
[16:52.890 --> 17:01.030]  This wasn't good, and we could avoid this, but we'll talk about this in the final words section.
[17:01.090 --> 17:07.250]  And now I'll hand over to Pedro, so that he'll talk to you about the Google Camera application.
[17:07.690 --> 17:08.350]  Pedro?
[17:10.820 --> 17:11.820]  Thanks, João.
[17:11.900 --> 17:16.020]  Now we are going to look into case number three, which is the Google Camera.
[17:16.860 --> 17:27.180]  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.
[17:27.180 --> 17:39.980]  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,
[17:39.980 --> 17:45.420]  since this implies a bigger attack surface and more users that could be at risk.
[17:45.420 --> 17:49.180]  And in this case, we were focusing on the Google Camera app.
[17:49.180 --> 17:52.560]  Now, the process is kind of the same.
[17:52.560 --> 18:01.120]  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.
[18:01.120 --> 18:05.460]  You reverse the APK, you analyze the traffic, you start reading the code.
[18:05.460 --> 18:12.960]  So, in this case, there was a lot of exported activities and defined actions inside the Google Camera app.
[18:12.960 --> 18:18.900]  Now, we started to test the behavior of these activities and actions and look for interesting stuff,
[18:18.900 --> 18:29.460]  because sometimes it's easier just to start and test the behavior of the application instead of reading tons of reversed code, sometimes obfuscated.
[18:29.460 --> 18:37.440]  So, we noticed that there's this action called Video Camera that starts the Google Camera app and immediately starts recording.
[18:37.440 --> 18:44.500]  And we found that interesting, because there's also this action Video Capture that does not start recording.
[18:44.740 --> 18:47.340]  So, why were there two different ones?
[18:47.340 --> 18:52.500]  Any other action would open the Google Camera in photo mode, but does not take a picture.
[18:52.500 --> 18:59.840]  So, we are looking like the attack scenario here is a rogue application that's trying to control the Google Camera application.
[18:59.840 --> 19:11.640]  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
[19:11.640 --> 19:21.820]  that you can pass to the program and to the application and modifies the execution path or the behavior, right?
[19:21.820 --> 19:25.460]  So, we noticed at least three interesting extras.
[19:25.460 --> 19:36.400]  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.
[19:36.400 --> 19:43.100]  There was this Duration Seconds, which allows the camera to start the timer before taking a picture.
[19:43.200 --> 19:50.720]  And this obscure one called Extra Turn Screen On, which essentially does what it says it does. It turns the screen on.
[19:50.720 --> 19:53.820]  Now, why was this interesting?
[19:53.820 --> 20:00.660]  Because the Timer Duration Seconds, for example, starts the Google Camera app and also starts the timer.
[20:00.660 --> 20:09.100]  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.
[20:09.100 --> 20:16.560]  The minimum default timer is three seconds. It's hard-coded. But still, you can take photos without user interaction.
[20:16.560 --> 20:31.260]  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.
[20:31.260 --> 20:39.140]  So, you can actually start from the background, start the Google Camera and take a picture and record a video.
[20:39.140 --> 20:46.480]  Why is this interesting? Because usually the videos and the photos are stored in the SD card.
[20:46.480 --> 20:54.280]  And the SD card, as you know, it's easily accessible by other applications that have the read external storage permission.
[20:54.280 --> 21:00.520]  So, we started to think how can we leverage this in a meaningful attack scenario, right?
[21:00.520 --> 21:10.940]  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.
[21:11.760 --> 21:18.740]  And the big problem here is that this rogue app does not need permissions, does not need camera permissions.
[21:18.740 --> 21:27.380]  It just abuses the Google Camera app to take these actions for himself.
[21:27.380 --> 21:38.760]  So, we devised a POC called Spixel. It's a client-server architecture. The client is a rogue weather app.
[21:38.800 --> 21:46.620]  It only needs the read external storage permissions and the internet permissions to communicate with the command-and-control server.
[21:46.920 --> 21:54.180]  The command-and-control server listens for every client and has a bunch of interesting features.
[21:56.260 --> 22:05.000]  The command-and-control server can order the rogue app to take a photo or take a video from a chosen camera.
[22:05.000 --> 22:14.220]  It uses some stealth features that we developed to prevent that the Google Camera app is popping up or making a sound.
[22:14.220 --> 22:29.920]  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.
[22:30.560 --> 22:32.140]  And it's another bug.
[22:32.200 --> 22:37.880]  We monitor the proximity sensor to know if the phone is upside down or not or you are on a call.
[22:38.440 --> 22:41.880]  We devised a feature called auto-record calls.
[22:42.080 --> 22:46.840]  When you answer the phone and you put the phone next to your face, it starts recording.
[22:47.240 --> 22:51.600]  And it's actually possible to listen to conversations on both sides.
[22:52.120 --> 22:58.560]  If EXIF data is on, you can grab the GPS locations and locate the user.
[22:58.560 --> 23:06.580]  You can issue the camera to take a photo and then parse the EXIF data and grab the GPS position.
[23:06.580 --> 23:18.540]  This is not completely related to the vulnerability in itself, but we got creative and implemented this on the tool, among other features.
[23:19.560 --> 23:21.900]  Now we are going to see a demo.
[23:23.480 --> 23:28.420]  This demo shows the auto-record feature when David answers.
[23:31.560 --> 23:33.000]  Hello?
[23:33.800 --> 23:35.240]  Hello?
[23:35.380 --> 23:42.180]  You can see on the right side the image from the camera, superimposed.
[23:49.430 --> 24:01.430]  And this is the attacker side when it actually receives the video and plays it back to the attacker on the Spixel interface.
[24:03.090 --> 24:11.450]  The corporate response here was really, I think, standard for Google, which is really high for everyone else.
[24:11.570 --> 24:15.970]  We got a medium-fast response after the first report.
[24:15.970 --> 24:18.650]  This was classified as a medium-impact vulnerability.
[24:19.190 --> 24:27.370]  Then we shared our tool and an explanation of what we did and how our tool could bypass a locked phone.
[24:27.370 --> 24:30.190]  And then they classified it as a high-impact vulnerability.
[24:30.190 --> 24:34.610]  The response from then on was really, really fast.
[24:34.610 --> 24:43.610]  They contacted other vendors that were identified as using the Google Camera or a by-product of Google Camera, some derivative.
[24:43.690 --> 24:46.350]  There were also other companies affected.
[24:46.390 --> 24:54.610]  And in the end, Google granted a $75,000 USD bounty, which was really cool.
[24:55.390 --> 25:00.370]  So now we reach our last case, which is case number 4, Samsung Find My Mobile.
[25:00.490 --> 25:10.130]  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.
[25:10.190 --> 25:14.130]  You just log into the website, make the phone ring, and lock the phone and whatever.
[25:14.130 --> 25:25.770]  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.
[25:26.090 --> 25:38.890]  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.
[25:38.890 --> 25:43.290]  There was not much luck involved at first, but digging a bit deeper...
[25:44.150 --> 25:51.970]  There's some piece of code that didn't even decompile correctly that refers to a file in the SD card called fmm.prop.
[25:51.970 --> 26:07.090]  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.
[26:07.090 --> 26:19.810]  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.
[26:19.810 --> 26:26.190]  There are going to be a lot of servers in this example, so the mg server is like the management server.
[26:26.190 --> 26:31.790]  And we can control it if we create this file and pass it a URL that you want.
[26:31.810 --> 26:36.150]  But creating this file is not enough. You must force fmm to assume this file.
[26:36.150 --> 26:43.010]  Usually this happens at bootup, but it's not really interesting if you cannot control it.
[26:43.010 --> 26:46.110]  So this was vulnerability number one.
[26:46.110 --> 26:50.790]  And now vulnerability number two comes from a broadcast receiver.
[26:50.790 --> 27:02.690]  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.
[27:02.690 --> 27:19.550]  So what this means in practice is that by sending a broadcast message to this pcwreceiver, fmm gets signaled that the registration is completed,
[27:19.550 --> 27:25.290]  and then it contacts the mg server to perform this registration again.
[27:25.290 --> 27:32.590]  And this mg server is the URL that we already under control in vulnerability number one.
[27:32.590 --> 27:42.630]  Now, this is interesting because by pointing the mg URL to an attacker control server, enforcing this registration with vulnerability number two,
[27:42.630 --> 27:45.430]  we can get a lot of details about the user.
[27:45.430 --> 27:54.850]  Because the phone contacts our own server, and then we can get the course location via IP address, registration ID, IMEI.
[27:54.850 --> 27:59.130]  There's a lot of information that comes with this registration request.
[27:59.130 --> 28:08.250]  And so joining these two vulnerabilities together, we can effectively found a way to monitor a user remotely.
[28:08.250 --> 28:15.210]  This all happens in background, and the user has no way of knowing this is happening.
[28:15.550 --> 28:22.070]  So, but this is kind of not enough. I didn't want just to monitor users, I want more.
[28:22.070 --> 28:31.690]  So, by analyzing the original mg server response, we can see that the response comes with a lot of different URLs.
[28:31.690 --> 28:36.310]  There's like this DM server, DS server, OSP server.
[28:36.310 --> 28:45.110]  I didn't get to the, you know, the bottom of all servers, what they all work for, and what they are for.
[28:45.110 --> 28:52.310]  But it was nice to see that we can also control the other endpoints.
[28:52.350 --> 28:56.770]  And this allows us to go and talk about vulnerability number three.
[28:56.770 --> 29:02.410]  Now, the vulnerability number three exists in another receiver called the SPP receiver.
[29:02.410 --> 29:10.690]  And there's this magic action that you can see there, that's FB0BD, so hexadecimal string.
[29:10.690 --> 29:16.880]  That indicates to FMM if there was a push message received.
[29:17.410 --> 29:27.070]  Now, by sending a broadcast with this magic action, we can additionally add an extra with the push messages.
[29:27.550 --> 29:32.410]  There was a lot of work involved in reversing these messages.
[29:32.410 --> 29:40.070]  They are all encrypted, and it's kind of hard to read, but luckily the key was hard-coded in the code.
[29:40.070 --> 29:46.310]  And we don't even have to understand what are all these messages for.
[29:46.870 --> 29:53.410]  We just need to know if we can craft the proper message, then we can get FMM to talk with the DM server.
[29:53.410 --> 29:59.310]  Now, while the NG server seems for registration processes and delivering reports,
[29:59.310 --> 30:10.090]  the DM server actually stores the actions that the user performs when he logs into the website or to the web interface.
[30:10.090 --> 30:19.830]  Now, the website, you can find it in findmymobile.samsung.com, has a map and has an overlay.
[30:19.830 --> 30:24.730]  The user can log in and perform, depending on the API level, you can perform a lot of actions.
[30:24.730 --> 30:33.630]  You can ring the phone, you can lock the phone and leave a message, create a backup, retrieve call logs and SMSs,
[30:33.630 --> 30:40.450]  erase all data on the phone, so there's a lot of different actions that you can make on the web interface.
[30:40.530 --> 30:46.290]  Now, they are executed by the phone when the phone receives these messages,
[30:46.290 --> 30:51.210]  but the phone could be offline or somewhere without network access.
[30:51.210 --> 31:01.190]  So, it's possible for the attacker to send the broadcast to this SPP server that results in FMM contact this DM server
[31:01.190 --> 31:11.770]  and searches for pending actions that were taken and FMM didn't have network connectivity to perform those actions.
[31:11.770 --> 31:18.990]  Now, this communication uses a proprietary SyncML implementation, which was a bit hard to figure out.
[31:20.090 --> 31:29.770]  It's not like standard SyncML, to the best of my knowledge, and there's something called Auth MD5 on this communication,
[31:29.770 --> 31:33.790]  so I assume there was some kind of authentication going on and encryption.
[31:34.550 --> 31:43.770]  So, what happens is, when the FMM contacts the DM server, the DM server can just reply with an OK
[31:43.770 --> 31:50.450]  or the accumulated actions that were requested and missed while the smartphone was offline.
[31:50.450 --> 31:59.830]  And this is where you can come in, because of vulnerability number two, we actually control the DM server.
[31:59.830 --> 32:02.310]  We control the NG server and the DM server.
[32:02.450 --> 32:10.290]  But, to be able to perform something like closely, remotely resembling a man-in-the-middle attack,
[32:10.290 --> 32:16.010]  we need a valid certificate, you need to monitor the messages, you need to detect the message types,
[32:16.010 --> 32:23.830]  change the requests on the fly, and you have to bypass this SyncML Auth MD5 mechanism at the same time to make everything work.
[32:25.150 --> 32:33.290]  So, now we are going into vulnerability number four, which is the SyncAuth MD5 algorithm.
[32:33.510 --> 32:36.970]  So, it has nothing to do with MD5 weaknesses.
[32:37.270 --> 32:47.150]  The authentication protocol seems to be like the client connects to the server and sends a field SyncML Auth MD5 on the first request.
[32:47.210 --> 32:49.030]  I assume this is a challenge.
[32:49.030 --> 32:56.990]  The server responds with another Auth MD5 field, which only depends on the client challenge,
[32:56.990 --> 33:04.130]  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.
[33:05.490 --> 33:07.370]  Why is this important?
[33:07.490 --> 33:13.270]  It's because there is no message signing or any mechanism that prevents message modification,
[33:13.270 --> 33:16.670]  which is really great for an attacker in the man-in-the-middle position.
[33:18.670 --> 33:24.870]  You don't even need to reverse the response verification mechanism to make this work.
[33:24.870 --> 33:31.970]  You can just man-in-the-middle the connection and send the authentication, the challenge packet to the server,
[33:31.970 --> 33:37.950]  grab the response, send to the client, and then you can just use that token and communicate,
[33:37.950 --> 33:43.950]  because you can change the content of the packet because there was no message signing.
[33:45.110 --> 33:50.450]  Putting it all together, if you put all these vulnerabilities together...
[33:50.450 --> 33:59.850]  With vulnerability number one, you can use the fmmprop file to change the MG server to your own server.
[33:59.850 --> 34:09.630]  Then you send a broadcast to the PCW receiver, and then you can get the MG server that has all these actions stored
[34:10.630 --> 34:15.030]  and force the update via a spoofed response.
[34:15.030 --> 34:25.250]  Then you send another broadcast message to the SPP receiver that actually makes FMM contact the DM server
[34:25.250 --> 34:28.370]  and fetches any outstanding actions.
[34:28.710 --> 34:39.070]  You are in the middle of this connection, so you just forward the challenge packet to the original server,
[34:39.070 --> 34:45.310]  grab the response, and then inject your own actions in the client, since there's no message integrity here.
[34:45.310 --> 34:49.450]  And then the smartphone can actually execute whatever message you decide for it.
[34:49.450 --> 34:57.330]  So, you know, the too-long-didn't-read version is that any application could reset your phone,
[34:57.330 --> 35:05.410]  steal your messages, locate the user, anything that FMM supports, and depending on the API level,
[35:05.410 --> 35:14.710]  any application without permissions, except to actually use the SD card, which is one of the most common permissions,
[35:14.710 --> 35:17.810]  you can do whatever that FMM supports.
[35:17.990 --> 35:26.170]  It works on a wide range of devices, including the S7, the S8, the S9+, this was tested on a lot of devices,
[35:26.170 --> 35:29.990]  and we have a demo that we can show now.
[35:30.950 --> 35:39.470]  So, I can actually claim that I'm able to, you know, erase all contents of the phone without actually showing it.
[35:39.490 --> 35:44.210]  So, here's the server configuration files.
[35:44.830 --> 35:51.810]  I'm going to switch my action to Nuke.
[35:55.490 --> 36:06.790]  This video is a bit sketchy, I'm sorry, but I cannot record the mobile phone screen at the same time.
[36:07.950 --> 36:12.850]  So, here's the Samsung S8.
[36:13.850 --> 36:14.610]  Unlock it.
[36:14.610 --> 36:24.490]  I'm going to start the POC, and over here I'm telling the logs of the rogue server.
[36:24.710 --> 36:30.010]  So, I'm going to do the exploit step by step.
[36:30.530 --> 36:34.010]  This is the first step, which changes the FMM prop.
[36:34.370 --> 36:36.410]  This is the second step.
[36:36.410 --> 36:46.470]  As you can see here, you can already watch that the rogue server receives the register requests.
[36:46.470 --> 36:52.190]  So, the URL endpoints now should already be taken over here.
[36:52.190 --> 37:03.070]  And now, when I'm going to do step 3, FMM is going to contact the sync server, the DM server.
[37:03.270 --> 37:08.330]  But it's already spoofed, so the reply will be Nuke.
[37:08.330 --> 37:13.210]  And you can see it happened in real time here.
[37:13.670 --> 37:15.450]  And kabam!
[37:15.930 --> 37:19.290]  Bye bye, dear S8.
[37:19.290 --> 37:26.210]  So, it's the same thing that happened on the other video, but the action is actually different.
[37:26.210 --> 37:30.510]  The action is the erase, so the phone gets erased.
[37:30.510 --> 37:38.510]  Also, the SD card is formatted, so all data in this phone is lost.
[37:39.590 --> 37:41.290]  That's it.
[37:41.350 --> 37:46.190]  Here you can see the different steps.
[37:47.190 --> 37:55.610]  So, over here there's step 1.
[37:56.030 --> 38:04.670]  This is where the authentication gets stolen from the server.
[38:04.670 --> 38:14.070]  The reply to the phone is injected with 2bwipe.
[38:14.070 --> 38:18.150]  It's hard to see here, but it's over here, 2bwipe.
[38:18.150 --> 38:29.010]  And then a series of steps that are needed to actually make the phone erased.
[38:29.950 --> 38:40.770]  So, working with Samsung in the Samsung Bounty program, they are very organized and they issued a fast response after the first report.
[38:40.770 --> 38:43.990]  This was classified as a high-impact vulnerability.
[38:44.290 --> 38:49.370]  And then we realized there was a lot more into it.
[38:49.370 --> 38:57.790]  This kind of behavior affects many different parts from the application part, the web server part.
[38:57.790 --> 39:02.790]  There were some things that needed to change. It took some time until they could issue a proper fix.
[39:02.890 --> 39:06.510]  And they granted a 10k USD bounty.
[39:06.750 --> 39:14.410]  And in addition, there were some closely related critical flaws that are not in the scope of this talk.
[39:14.410 --> 39:16.970]  It's not the application side.
[39:16.970 --> 39:21.370]  So, it was added a 25k USD bonus.
[39:21.450 --> 39:24.250]  So, in the end, it was very, very nice.
[39:25.170 --> 39:27.770]  So, this concludes our presentation.
[39:27.870 --> 39:37.550]  We tried to give you a variety of examples of real applications that faced different problems like the lack of encryption,
[39:37.550 --> 39:42.190]  problems in the web views, legacy code, intents without permissions.
[39:42.190 --> 39:50.950]  These are all different issues that sometimes are common to other applications or some of them are very Android specific.
[39:51.170 --> 39:55.070]  Before we go, we'd like to just say some words.
[39:55.210 --> 40:02.450]  We really believe that we are trying to make the world just a slightly better place by, you know, identifying these vulnerabilities,
[40:02.450 --> 40:06.830]  making people overall a bit more safe while being online.
[40:06.830 --> 40:12.890]  Luckily, we are paid for this research and we're not depending on bounties.
[40:12.890 --> 40:15.630]  But, of course, they are always appreciated.
[40:16.710 --> 40:26.090]  It's interesting to note that the vulnerability complexity does not, you know, equal having a greater impact or more rewards.
[40:26.090 --> 40:34.590]  Sometimes you spend a lot of time trying to develop a POC or a working POC on a very complex issue.
[40:34.590 --> 40:46.630]  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.
[40:46.890 --> 40:52.530]  And the final word is that we are really a friend. We are not the enemy.
[40:52.530 --> 41:04.850]  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.
[41:05.250 --> 41:10.270]  And, you know, threats and liars, legal suits are really not necessary.
[41:11.310 --> 41:18.970]  We think of ourselves as friends and we are not trying to hurt the company's image or whatever in any way.
[41:18.970 --> 41:27.750]  So I think now we are going to be open for questions if anyone wants to ask something.
[41:27.750 --> 41:28.950]  Thank you.