WEBVTT 00:13.800 --> 00:15.180 Come on in. 00:15.260 --> 00:16.800 Move to the center of the row. 00:16.800 --> 00:19.660 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:26.680 Get close. 00:26.680 --> 00:27.340 Get friendly. 00:27.340 --> 00:28.180 This is DEF CON. 00:28.180 --> 00:29.400 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:10.020 He's been through the bulletin board age. 01:10.020 --> 01:14.960 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:00.380 My name is Pedro Umberlino. 02:00.380 --> 02:04.920 I'm a senior security researcher at Checkmark security research team. 02:04.920 --> 02:07.900 I'm also a security researcher at Chair49. 02:07.900 --> 02:10.300 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:23.760 Thank you, Pedro. 02:23.760 --> 02:24.700 Hello, everyone. 02:24.700 --> 02:26.460 Thanks for joining us here today. 02:26.460 --> 02:27.860 My name is Joao Moraes. 02:27.860 --> 02:31.060 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:41.080 So my background is very wide. 02:41.080 --> 02:44.860 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:04.740 Thanks, Joao. 03:04.740 --> 03:10.380 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:17.820 You're in the Android ecosystem. 03:17.820 --> 03:21.420 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:42.360 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, 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:37.860 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, 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:05.180 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 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:55.560 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 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:21.860 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, you could easily identify users of the Tinder application, their MAC address and IP, you can see their picture on the top left, you can see in the center the pictures of users that are being suggested, 07:21.860 --> 07:28.820 so they are being shown in his device, 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:38.830 So, Tinder Drift takes advantage of the fact that the Tinder app fetches profile images via a non-encrypted HTTP connection, and it associates that image, or those images, to a client. 08:38.830 --> 08:53.090 After that, it analyzes the HTTPS encrypted connections from the client to the Tinder API server, 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:13.670 The reply packet size can be used to determine which kind of action the user took, 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:46.250 And if it's a no like, it's a nope. 09:46.250 --> 09:48.130 So, let's like this also. 09:52.050 --> 09:56.070 And you can see that the app updates. 09:56.590 --> 09:59.730 The software also supports multiple clients. 09:59.730 --> 10:03.650 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:23.390 Let's consider this scheme. 13:23.390 --> 13:29.130 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:20.050 So, we ended up with something like this. 14:20.050 --> 14:22.150 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:37.170 But let's start from the beginning. 14:37.170 --> 14:40.170 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:01.390 So then, the Android knows that appX scheme. 15:01.390 --> 15:09.190 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:14.390 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, and by each contact that presses on the link, it will send it to all the contacts of that contact, 16:14.390 --> 16:15.790 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:45.420 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, 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:29.460 Now, we started to test the behavior of these activities and actions and look for interesting stuff, 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:21.440 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 that you can pass to the program and to the application and modifies the execution path or the behavior, 19:21.440 --> 19:21.820 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:49.220 And this obscure one called Extra Turn Screen On, which essentially does what it says it does. 19:49.220 --> 19:50.720 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:11.940 The minimum default timer is three seconds. 20:11.940 --> 20:13.040 It's hard-coded. 20:13.040 --> 20:16.560 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:40.780 Why is this interesting? 20:40.780 --> 20:46.480 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:04.000 So, we devised this combination. 21:04.000 --> 21:10.940 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:33.020 So, we devised a POC called Spixel. 21:33.100 --> 21:35.680 It's a client-server architecture. 21:35.680 --> 21:38.760 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:18.220 We can mute all the audio streams. 22:18.220 --> 22:29.920 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:33.490 But creating this file is not enough. 26:33.490 --> 26:36.150 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:25.290 So what this means in practice is that by sending a broadcast message to this pcwreceiver, fmm gets signaled that the registration is completed, 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:45.430 Now, this is interesting because by pointing the mg URL to an attacker control server, enforcing this registration with vulnerability number two, 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:18.270 So, but this is kind of not enough. 28:18.270 --> 28:22.070 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 --> 30:10.090 Now, while the NG server seems for registration processes and delivering reports, 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:40.450 You can ring the phone, you can lock the phone and leave a message, create a backup, retrieve call logs and SMSs, 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:51.210 Now, they are executed by the phone when the phone receives these messages, but the phone could be offline or somewhere without network access. 30:51.210 --> 31:11.770 So , it's possible for the attacker to send the broadcast to this SPP server that results in FMM contact this DM server 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:33.790 It's not like standard SyncML, to the best of my knowledge, and there's something called Auth MD5 on this communication, so I assume there was some kind of authentication going on and encryption. 31:34.550 --> 31:50.450 So, what happens is, when the FMM contacts the DM server, the DM server can just reply with an OK 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:23.830 But, to be able to perform something like closely, remotely resembling a man-in-the-middle attack, we need a valid certificate, you need to monitor the messages, you need to detect the message types, 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 --> 33:04.130 The server responds with another Auth MD5 field, which only depends on the client challenge, 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:16.670 It's because there is no message signing or any mechanism that prevents message modification, 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:43.950 You can just man-in-the-middle the connection and send the authentication, the challenge packet to the server, grab the response, send to the client, and then you can just use that token and communicate, 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:15.030 Then you send a broadcast to the PCW receiver, and then you can get the MG server that has all these actions stored and force the update via a spoofed response. 34:15.030 --> 34:28.370 Then you send another broadcast message to the SPP receiver that actually makes FMM contact the DM server and fetches any outstanding actions. 34:28.710 --> 34:45.310 You are in the middle of this connection, so you just forward the challenge packet to the original server, 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 --> 35:12.590 So, you know, the too-long-didn't-read version is that any application could reset your phone, steal your messages, locate the user, anything that FMM supports, and depending on the API level, any application without permissions, except to actually use the SD card, 35:12.590 --> 35:17.810 which is one of the most common permissions, you can do whatever that FMM supports. 35:17.990 --> 35:29.990 It works on a wide range of devices, including the S7, the S8, the S9+, this was tested on a lot of devices, 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 --> 38:59.590 There were some things that needed to change. 38:59.590 --> 39:02.790 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:42.190 We tried to give you a variety of examples of real applications that faced different problems like the lack of encryption, 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:06.830 We really believe that we are trying to make the world just a slightly better place by, you know, identifying these vulnerabilities, 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:51.470 And the final word is that we are really a friend. 40:51.470 --> 40:52.530 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.