1
00:00:13,800 --> 00:00:15,180
Come on in.

2
00:00:15,260 --> 00:00:16,800
Move to the center of the row.

3
00:00:16,800 --> 00:00:19,660
Make sure that you get every single seat filled.

4
00:00:19,660 --> 00:00:23,040
We want to make sure that we have enough room for everybody to get in.

5
00:00:23,040 --> 00:00:26,020
We want to make sure that everybody gets a seat.

6
00:00:26,020 --> 00:00:26,680
Get close.

7
00:00:26,680 --> 00:00:27,340
Get friendly.

8
00:00:27,340 --> 00:00:28,180
This is DEF CON.

9
00:00:28,180 --> 00:00:29,400
Make friends.

10
00:00:29,760 --> 00:00:32,940
Are some of the things that I wish I could be telling you right now.

11
00:00:34,740 --> 00:00:36,440
Unfortunately... yeah, we can't.

12
00:00:36,440 --> 00:00:40,000
I'm here and you guys are where you're at, respectively.

13
00:00:40,000 --> 00:00:47,800
So, with that said, we forage on and the second year of the AppSec Village continues on.

14
00:00:47,960 --> 00:00:59,220
For this talk, we've got Pedro Umberlino and Joao Maurice to talk about bug foraging in Android.

15
00:00:59,800 --> 00:01:04,060
Pedro is a security researcher by day and a Hackaday contributor by night.

16
00:01:04,060 --> 00:01:07,880
He messes around with computers, started on the Spectrum.

17
00:01:07,880 --> 00:01:10,020
He's been through the bulletin board age.

18
00:01:10,020 --> 00:01:14,960
He's been there for the drop of the internet and still roams around on IRC.

19
00:01:14,960 --> 00:01:17,780
He's known on the internet by his handle Cryptor.

20
00:01:18,060 --> 00:01:20,720
And he likes all sorts of hacks.

21
00:01:22,080 --> 00:01:27,220
Joao is a penetration tester and researcher that started with the blue team.

22
00:01:27,320 --> 00:01:30,280
Later was attracted to the red side of the force.

23
00:01:30,400 --> 00:01:37,040
Although there's more focused in application security, he's learned all sorts of attack vectors.

24
00:01:37,040 --> 00:01:44,440
So, if you would take some time, sit back, enjoy the talk and help me in welcoming these two fantastic presenters.

25
00:01:44,680 --> 00:01:47,720
Hello and welcome to the Android bug foraging session.

26
00:01:47,720 --> 00:01:51,640
It's great to be here at DefCon SafeMode AppSec Village giving this talk.

27
00:01:51,640 --> 00: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.

28
00:01:58,820 --> 00:02:00,380
My name is Pedro Umberlino.

29
00:02:00,380 --> 00:02:04,920
I'm a senior security researcher at Checkmark security research team.

30
00:02:04,920 --> 00:02:07,900
I'm also a security researcher at Chair49.

31
00:02:07,900 --> 00:02:10,300
Sometimes I write for Hackaday.

32
00:02:10,560 --> 00:02:16,200
One of my hobbies is to make hardware and my daytime job is to break software.

33
00:02:16,240 --> 00:02:19,620
I'm giving this talk with a friend of mine and colleague, Joao.

34
00:02:22,400 --> 00:02:23,760
Thank you, Pedro.

35
00:02:23,760 --> 00:02:24,700
Hello, everyone.

36
00:02:24,700 --> 00:02:26,460
Thanks for joining us here today.

37
00:02:26,460 --> 00:02:27,860
My name is Joao Moraes.

38
00:02:27,860 --> 00:02:31,060
I'm a penetration tester team lead for a multinational company.

39
00:02:31,060 --> 00:02:34,760
I also do pen testing and security research for other companies.

40
00:02:34,760 --> 00:02:39,140
I'm part of the Checkmarks and Chair49 security research team.

41
00:02:39,240 --> 00:02:41,080
So my background is very wide.

42
00:02:41,080 --> 00:02:44,860
I did many different things over the years, always related to security, though.

43
00:02:44,880 --> 00: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.

44
00:02:53,940 --> 00: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.

45
00:03:03,680 --> 00:03:04,740
Thanks, Joao.

46
00:03:04,740 --> 00:03:10,380
So foraging, foraging, the act of identifying and gathering wild food in nature.

47
00:03:10,920 --> 00:03:15,940
Bug foraging is like kind of the same, but you're not in nature.

48
00:03:15,940 --> 00:03:17,820
You're in the Android ecosystem.

49
00:03:17,820 --> 00:03:21,420
You're not hunting bugs to eat, but you eat because you hunt bugs.

50
00:03:21,420 --> 00:03:25,380
So, yeah, it's not the same, but, you know, you get the idea.

51
00:03:25,880 --> 00: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.

52
00:03:42,460 --> 00:03:50,580
We wanted to share with you our process of approaching and devising meaningful attack scenarios and proof of concepts.

53
00:03:50,580 --> 00:03:59,020
And in a nutshell, the overall experience that we have from first crash until disclosure process.

54
00:03:59,020 --> 00:04:08,080
And for that, we are going to use four different examples of vulnerabilities in four different apps that we found.

55
00:04:08,080 --> 00:04:14,280
Some of them are from our older work and some of them are going to be disclosed here firsthand.

56
00:04:14,280 --> 00:04:18,620
So Joao is going to talk a bit about which vulnerabilities we are going to talk about.

57
00:04:18,620 --> 00:04:19,700
So, Joao.

58
00:04:21,580 --> 00:04:22,720
Thank you, Pedro.

59
00:04:22,720 --> 00: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.

60
00:04:37,860 --> 00:04:43,160
And then final words, the main key takeaways from this bug foraging experience.

61
00:04:44,900 --> 00:04:48,080
Moving on to case one, the Tinder application.

62
00:04:48,620 --> 00:04:54,000
This is a very well known application that allows you to meet people and chat with them.

63
00:04:54,180 --> 00: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.

64
00:05:05,180 --> 00:05:11,420
And if they like you back, you'll have a match and then you can chat with them using the application.

65
00:05:12,100 --> 00:05:14,900
So let's start with what we did.

66
00:05:14,900 --> 00:05:21,760
We started by sniffing and collecting the traffic and we could see a lot of HTTP going on.

67
00:05:22,020 --> 00: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.

68
00:05:32,920 --> 00: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.

69
00:05:42,720 --> 00: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.

70
00:05:56,120 --> 00: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.

71
00:06:06,620 --> 00:06:11,340
So now we have a good visibility, a good invasion of privacy.

72
00:06:11,340 --> 00: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.

73
00:06:24,700 --> 00: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.

74
00:06:32,060 --> 00:06:37,280
So we could do a direct match between the actions of the user and the size of the payload.

75
00:06:37,280 --> 00: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.

76
00:06:49,400 --> 00: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.

77
00:06:59,280 --> 00: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,

78
00:07:21,860 --> 00:07:28,820
so they are being shown in his device, and also his actions, the NOPES, the LIKES, and the MATCHES.

79
00:07:28,900 --> 00:07:33,680
We also put some traffic down below for debugging purposes.

80
00:07:33,680 --> 00:07:38,080
But you can see this working now, in this quick video.

81
00:07:38,820 --> 00:07:42,420
This video is the Tinder Drift software demo.

82
00:07:42,520 --> 00: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.

83
00:07:53,260 --> 00:07:56,100
So, let's start the Tinder Drift for the demo.

84
00:07:56,100 --> 00:07:58,040
This is the app right here.

85
00:07:59,260 --> 00:08:07,080
It receives a PICAP file, it can be a live PICAP, and it still analyzes it.

86
00:08:07,080 --> 00: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.

87
00:08:24,670 --> 00: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.

88
00:08:38,830 --> 00: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.

89
00:08:53,090 --> 00:09:00,230
So, when the user swipes left or right, the app sends a request to the API server.

90
00:09:00,230 --> 00: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.

91
00:09:15,470 --> 00: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.

92
00:09:28,690 --> 00:09:31,210
For example, let's like this profile.

93
00:09:32,470 --> 00:09:41,850
When I swipe like, you can see here, in this corner, that the image was properly identified as a like.

94
00:09:41,850 --> 00:09:46,250
And if it's a no like, it's a nope.

95
00:09:46,250 --> 00:09:48,130
So, let's like this also.

96
00:09:52,050 --> 00:09:56,070
And you can see that the app updates.

97
00:09:56,590 --> 00:09:59,730
The software also supports multiple clients.

98
00:09:59,730 --> 00:10:03,650
For example, let's switch to an iPhone.

99
00:10:04,630 --> 00:10:11,490
The corporate response was quite fast, but they didn't consider this a big deal in the beginning.

100
00:10:11,490 --> 00: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.

101
00:10:22,090 --> 00:10:28,390
And, of course, that led to a very quick fix, and that was very positive.

102
00:10:28,790 --> 00:10:35,130
There was no bounty, because at the time, as far as I recall, there was no bounty problem.

103
00:10:36,810 --> 00:10:40,210
Let's move on to Case 2, the app X.

104
00:10:40,310 --> 00: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.

105
00:10:48,150 --> 00:10:52,550
But that won't be relevant for explaining the vulnerabilities.

106
00:10:53,270 --> 00:10:55,350
So, let's move on.

107
00:10:56,030 --> 00:11:04,070
Starting with what we did, we started by listing activities that could be used by other applications.

108
00:11:04,870 --> 00:11:10,470
And we found out that the MainActivity can actually load a malicious URL.

109
00:11:10,690 --> 00:11:16,850
And that's because there is some link validation, but it's not very strong.

110
00:11:16,850 --> 00:11:19,210
I mean, you can see the regex down there.

111
00:11:19,210 --> 00:11:25,590
If you have a slash, an L character, and a slash, your link is valid.

112
00:11:25,850 --> 00:11:28,550
And it will be loaded by the WebView.

113
00:11:28,610 --> 00:11:30,670
So, you'll end up with something like this.

114
00:11:30,670 --> 00: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.

115
00:11:41,430 --> 00:11:46,530
We tested that with the ActivityManager using ADP, and it works.

116
00:11:46,850 --> 00: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.

117
00:11:58,530 --> 00: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.

118
00:12:07,330 --> 00:12:12,010
And we could steal the credentials, and the application would still work smoothly.

119
00:12:14,190 --> 00:12:17,090
We tried to leverage these findings.

120
00:12:17,110 --> 00:12:21,570
We looked for other things, and we found several JavaScript interfaces.

121
00:12:21,570 --> 00: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.

122
00:12:29,970 --> 00:12:37,390
And this particular setBaseURLs function allows you to change the URL of the API.

123
00:12:37,570 --> 00:12:41,390
And we can replace it with our own URL.

124
00:12:42,170 --> 00:12:45,790
And when you do that, this change is permanent.

125
00:12:45,790 --> 00:12:51,150
Your application will contact our malicious API instead of the original API.

126
00:12:51,150 --> 00:12:57,070
The app has certificate pinning, and it works well, but it also supports plain HTTP.

127
00:12:57,070 --> 00: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.

128
00:13:06,450 --> 00: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.

129
00:13:15,670 --> 00:13:18,110
So, we tried to go deeper.

130
00:13:18,110 --> 00:13:21,770
We saw there were some deep links for this app.

131
00:13:21,770 --> 00:13:23,390
Let's consider this scheme.

132
00:13:23,390 --> 00:13:29,130
Of course, it's not the real scheme, the appX, just for clarity.

133
00:13:29,770 --> 00:13:33,010
And there is a messaging system in the application.

134
00:13:33,010 --> 00: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.

135
00:13:44,870 --> 00:13:51,010
So, the chat feature doesn't support deep links, but it supports regular web links.

136
00:13:51,410 --> 00: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.

137
00:14:01,030 --> 00:14:06,950
But how would we pass the parameter then to the main activity?

138
00:14:06,950 --> 00:14:16,990
But it would use the default HTML content, and we wanted to be able to pass it our malicious URL.

139
00:14:17,930 --> 00:14:20,050
So, we ended up with something like this.

140
00:14:20,050 --> 00:14:22,150
This is the full chain of events.

141
00:14:22,150 --> 00:14:26,170
You can see down there the full URI for the exploit.

142
00:14:26,350 --> 00: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.

143
00:14:35,550 --> 00:14:37,170
But let's start from the beginning.

144
00:14:37,170 --> 00:14:40,170
So, we don't need a malicious application anymore.

145
00:14:40,170 --> 00:14:44,690
We just need a message, and we'll send a message with a web link.

146
00:14:44,690 --> 00:14:48,330
As soon as the user opens the link, Google Chrome is called.

147
00:14:48,330 --> 00: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.

148
00:14:57,710 --> 00:15:01,390
So then, the Android knows that appX scheme.

149
00:15:01,390 --> 00:15:09,190
It will open the appX application, and the appX application will load our http attacking.site.com.

150
00:15:09,190 --> 00:15:12,570
Of course, that's a fake domain, just for demonstration purposes.

151
00:15:12,570 --> 00:15:19,210
You can see the slash L slash, so that it will pass the validation, and this will work.

152
00:15:19,210 --> 00:15:25,290
We have the full exploit, just like we did before, but without requiring a malicious application.

153
00:15:25,290 --> 00: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.

154
00:15:37,190 --> 00: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.

155
00:15:52,450 --> 00: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,

156
00:16:14,390 --> 00:16:15,790
and so on, and so on.

157
00:16:15,790 --> 00:16:19,770
So, becoming a sort of a wormable exploit.

158
00:16:19,770 --> 00: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.

159
00:16:29,010 --> 00: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.

160
00:16:39,610 --> 00:16:45,770
So, the response was good, it was fast, it was classified as a critical issue, it was fixed.

161
00:16:45,770 --> 00: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.

162
00:16:52,890 --> 00:17:01,030
This wasn't good, and we could avoid this, but we'll talk about this in the final words section.

163
00:17:01,090 --> 00:17:07,250
And now I'll hand over to Pedro, so that he'll talk to you about the Google Camera application.

164
00:17:07,690 --> 00:17:08,350
Pedro?

165
00:17:10,820 --> 00:17:11,820
Thanks, João.

166
00:17:11,900 --> 00:17:16,020
Now we are going to look into case number three, which is the Google Camera.

167
00:17:16,860 --> 00: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.

168
00:17:27,180 --> 00: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.

169
00:17:45,420 --> 00:17:49,180
And in this case, we were focusing on the Google Camera app.

170
00:17:49,180 --> 00:17:52,560
Now, the process is kind of the same.

171
00:17:52,560 --> 00: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.

172
00:18:01,120 --> 00:18:05,460
You reverse the APK, you analyze the traffic, you start reading the code.

173
00:18:05,460 --> 00:18:12,960
So , in this case, there was a lot of exported activities and defined actions inside the Google Camera app.

174
00:18:12,960 --> 00: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.

175
00:18:29,460 --> 00:18:37,440
So, we noticed that there's this action called Video Camera that starts the Google Camera app and immediately starts recording.

176
00:18:37,440 --> 00:18:44,500
And we found that interesting, because there's also this action Video Capture that does not start recording.

177
00:18:44,740 --> 00:18:47,340
So, why were there two different ones?

178
00:18:47,340 --> 00:18:52,500
Any other action would open the Google Camera in photo mode, but does not take a picture.

179
00:18:52,500 --> 00: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.

180
00:18:59,840 --> 00: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,

181
00:19:21,440 --> 00:19:21,820
right?

182
00:19:21,820 --> 00:19:25,460
So, we noticed at least three interesting extras.

183
00:19:25,460 --> 00: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.

184
00:19:36,400 --> 00:19:43,100
There was this Duration Seconds, which allows the camera to start the timer before taking a picture.

185
00:19:43,200 --> 00:19:49,220
And this obscure one called Extra Turn Screen On, which essentially does what it says it does.

186
00:19:49,220 --> 00:19:50,720
It turns the screen on.

187
00:19:50,720 --> 00:19:53,820
Now, why was this interesting?

188
00:19:53,820 --> 00:20:00,660
Because the Timer Duration Seconds, for example, starts the Google Camera app and also starts the timer.

189
00:20:00,660 --> 00: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.

190
00:20:09,100 --> 00:20:11,940
The minimum default timer is three seconds.

191
00:20:11,940 --> 00:20:13,040
It's hard-coded.

192
00:20:13,040 --> 00:20:16,560
But still, you can take photos without user interaction.

193
00:20:16,560 --> 00: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.

194
00:20:31,260 --> 00:20:39,140
So, you can actually start from the background, start the Google Camera and take a picture and record a video.

195
00:20:39,140 --> 00:20:40,780
Why is this interesting?

196
00:20:40,780 --> 00:20:46,480
Because usually the videos and the photos are stored in the SD card.

197
00:20:46,480 --> 00:20:54,280
And the SD card, as you know, it's easily accessible by other applications that have the read external storage permission.

198
00:20:54,280 --> 00:21:00,520
So, we started to think how can we leverage this in a meaningful attack scenario, right?

199
00:21:00,520 --> 00:21:04,000
So, we devised this combination.

200
00:21:04,000 --> 00: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.

201
00:21:11,760 --> 00:21:18,740
And the big problem here is that this rogue app does not need permissions, does not need camera permissions.

202
00:21:18,740 --> 00:21:27,380
It just abuses the Google Camera app to take these actions for himself.

203
00:21:27,380 --> 00:21:33,020
So, we devised a POC called Spixel.

204
00:21:33,100 --> 00:21:35,680
It's a client-server architecture.

205
00:21:35,680 --> 00:21:38,760
The client is a rogue weather app.

206
00:21:38,800 --> 00:21:46,620
It only needs the read external storage permissions and the internet permissions to communicate with the command-and-control server.

207
00:21:46,920 --> 00:21:54,180
The command-and-control server listens for every client and has a bunch of interesting features.

208
00:21:56,260 --> 00: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.

209
00:22:05,000 --> 00: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.

210
00:22:14,220 --> 00:22:18,220
We can mute all the audio streams.

211
00:22:18,220 --> 00: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.

212
00:22:30,560 --> 00:22:32,140
And it's another bug.

213
00:22:32,200 --> 00:22:37,880
We monitor the proximity sensor to know if the phone is upside down or not or you are on a call.

214
00:22:38,440 --> 00:22:41,880
We devised a feature called auto-record calls.

215
00:22:42,080 --> 00:22:46,840
When you answer the phone and you put the phone next to your face, it starts recording.

216
00:22:47,240 --> 00:22:51,600
And it's actually possible to listen to conversations on both sides.

217
00:22:52,120 --> 00:22:58,560
If EXIF data is on, you can grab the GPS locations and locate the user.

218
00:22:58,560 --> 00:23:06,580
You can issue the camera to take a photo and then parse the EXIF data and grab the GPS position.

219
00:23:06,580 --> 00: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.

220
00:23:19,560 --> 00:23:21,900
Now we are going to see a demo.

221
00:23:23,480 --> 00:23:28,420
This demo shows the auto-record feature when David answers.

222
00:23:31,560 --> 00:23:33,000
Hello?

223
00:23:33,800 --> 00:23:35,240
Hello?

224
00:23:35,380 --> 00:23:42,180
You can see on the right side the image from the camera, superimposed.

225
00:23:49,430 --> 00: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.

226
00:24:03,090 --> 00:24:11,450
The corporate response here was really, I think, standard for Google, which is really high for everyone else.

227
00:24:11,570 --> 00:24:15,970
We got a medium-fast response after the first report.

228
00:24:15,970 --> 00:24:18,650
This was classified as a medium-impact vulnerability.

229
00:24:19,190 --> 00:24:27,370
Then we shared our tool and an explanation of what we did and how our tool could bypass a locked phone.

230
00:24:27,370 --> 00:24:30,190
And then they classified it as a high-impact vulnerability.

231
00:24:30,190 --> 00:24:34,610
The response from then on was really, really fast.

232
00:24:34,610 --> 00:24:43,610
They contacted other vendors that were identified as using the Google Camera or a by-product of Google Camera, some derivative.

233
00:24:43,690 --> 00:24:46,350
There were also other companies affected.

234
00:24:46,390 --> 00:24:54,610
And in the end, Google granted a $75,000 USD bounty, which was really cool.

235
00:24:55,390 --> 00:25:00,370
So now we reach our last case, which is case number 4, Samsung Find My Mobile.

236
00:25:00,490 --> 00: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.

237
00:25:10,190 --> 00:25:14,130
You just log into the website, make the phone ring, and lock the phone and whatever.

238
00:25:14,130 --> 00: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.

239
00:25:26,090 --> 00: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.

240
00:25:38,890 --> 00:25:43,290
There was not much luck involved at first, but digging a bit deeper...

241
00:25:44,150 --> 00: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.

242
00:25:51,970 --> 00: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.

243
00:26:07,090 --> 00: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.

244
00:26:19,810 --> 00:26:26,190
There are going to be a lot of servers in this example, so the mg server is like the management server.

245
00:26:26,190 --> 00:26:31,790
And we can control it if we create this file and pass it a URL that you want.

246
00:26:31,810 --> 00:26:33,490
But creating this file is not enough.

247
00:26:33,490 --> 00:26:36,150
You must force fmm to assume this file.

248
00:26:36,150 --> 00:26:43,010
Usually this happens at bootup, but it's not really interesting if you cannot control it.

249
00:26:43,010 --> 00:26:46,110
So this was vulnerability number one.

250
00:26:46,110 --> 00:26:50,790
And now vulnerability number two comes from a broadcast receiver.

251
00:26:50,790 --> 00: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.

252
00:27:02,690 --> 00: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.

253
00:27:25,290 --> 00:27:32,590
And this mg server is the URL that we already under control in vulnerability number one.

254
00:27:32,590 --> 00: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.

255
00:27:45,430 --> 00:27:54,850
Because the phone contacts our own server, and then we can get the course location via IP address, registration ID, IMEI.

256
00:27:54,850 --> 00:27:59,130
There's a lot of information that comes with this registration request.

257
00:27:59,130 --> 00:28:08,250
And so joining these two vulnerabilities together, we can effectively found a way to monitor a user remotely.

258
00:28:08,250 --> 00:28:15,210
This all happens in background, and the user has no way of knowing this is happening.

259
00:28:15,550 --> 00:28:18,270
So, but this is kind of not enough.

260
00:28:18,270 --> 00:28:22,070
I didn't want just to monitor users, I want more.

261
00:28:22,070 --> 00:28:31,690
So, by analyzing the original mg server response, we can see that the response comes with a lot of different URLs.

262
00:28:31,690 --> 00:28:36,310
There's like this DM server, DS server, OSP server.

263
00:28:36,310 --> 00: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.

264
00:28:45,110 --> 00:28:52,310
But it was nice to see that we can also control the other endpoints.

265
00:28:52,350 --> 00:28:56,770
And this allows us to go and talk about vulnerability number three.

266
00:28:56,770 --> 00:29:02,410
Now, the vulnerability number three exists in another receiver called the SPP receiver.

267
00:29:02,410 --> 00:29:10,690
And there's this magic action that you can see there, that's FB0BD, so hexadecimal string.

268
00:29:10,690 --> 00:29:16,880
That indicates to FMM if there was a push message received.

269
00:29:17,410 --> 00:29:27,070
Now, by sending a broadcast with this magic action, we can additionally add an extra with the push messages.

270
00:29:27,550 --> 00:29:32,410
There was a lot of work involved in reversing these messages.

271
00:29:32,410 --> 00: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.

272
00:29:40,070 --> 00:29:46,310
And we don't even have to understand what are all these messages for.

273
00:29:46,870 --> 00: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.

274
00:29:53,410 --> 00: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.

275
00:30:10,090 --> 00:30:19,830
Now, the website, you can find it in findmymobile.samsung.com, has a map and has an overlay.

276
00:30:19,830 --> 00:30:24,730
The user can log in and perform, depending on the API level, you can perform a lot of actions.

277
00:30:24,730 --> 00: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.

278
00:30:40,530 --> 00: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.

279
00:30:51,210 --> 00: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.

280
00:31:11,770 --> 00:31:18,990
Now, this communication uses a proprietary SyncML implementation, which was a bit hard to figure out.

281
00:31:20,090 --> 00: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.

282
00:31:34,550 --> 00: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.

283
00:31:50,450 --> 00:31:59,830
And this is where you can come in, because of vulnerability number two, we actually control the DM server.

284
00:31:59,830 --> 00:32:02,310
We control the NG server and the DM server.

285
00:32:02,450 --> 00: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.

286
00:32:25,150 --> 00:32:33,290
So, now we are going into vulnerability number four, which is the SyncAuth MD5 algorithm.

287
00:32:33,510 --> 00:32:36,970
So, it has nothing to do with MD5 weaknesses.

288
00:32:37,270 --> 00: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.

289
00:32:47,210 --> 00:32:49,030
I assume this is a challenge.

290
00:32:49,030 --> 00: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.

291
00:33:05,490 --> 00:33:07,370
Why is this important?

292
00:33:07,490 --> 00: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.

293
00:33:18,670 --> 00:33:24,870
You don't even need to reverse the response verification mechanism to make this work.

294
00:33:24,870 --> 00: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.

295
00:33:45,110 --> 00:33:50,450
Putting it all together, if you put all these vulnerabilities together...

296
00:33:50,450 --> 00:33:59,850
With vulnerability number one, you can use the fmmprop file to change the MG server to your own server.

297
00:33:59,850 --> 00: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.

298
00:34:15,030 --> 00: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.

299
00:34:28,710 --> 00: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.

300
00:34:45,310 --> 00:34:49,450
And then the smartphone can actually execute whatever message you decide for it.

301
00:34:49,450 --> 00: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,

302
00:35:12,590 --> 00:35:17,810
which is one of the most common permissions, you can do whatever that FMM supports.

303
00:35:17,990 --> 00: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.

304
00:35:30,950 --> 00: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.

305
00:35:39,490 --> 00:35:44,210
So, here's the server configuration files.

306
00:35:44,830 --> 00:35:51,810
I'm going to switch my action to Nuke.

307
00:35:55,490 --> 00:36:06,790
This video is a bit sketchy, I'm sorry, but I cannot record the mobile phone screen at the same time.

308
00:36:07,950 --> 00:36:12,850
So, here's the Samsung S8.

309
00:36:13,850 --> 00:36:14,610
Unlock it.

310
00:36:14,610 --> 00:36:24,490
I'm going to start the POC, and over here I'm telling the logs of the rogue server.

311
00:36:24,710 --> 00:36:30,010
So, I'm going to do the exploit step by step.

312
00:36:30,530 --> 00:36:34,010
This is the first step, which changes the FMM prop.

313
00:36:34,370 --> 00:36:36,410
This is the second step.

314
00:36:36,410 --> 00:36:46,470
As you can see here, you can already watch that the rogue server receives the register requests.

315
00:36:46,470 --> 00:36:52,190
So, the URL endpoints now should already be taken over here.

316
00:36:52,190 --> 00:37:03,070
And now, when I'm going to do step 3, FMM is going to contact the sync server, the DM server.

317
00:37:03,270 --> 00:37:08,330
But it's already spoofed, so the reply will be Nuke.

318
00:37:08,330 --> 00:37:13,210
And you can see it happened in real time here.

319
00:37:13,670 --> 00:37:15,450
And kabam!

320
00:37:15,930 --> 00:37:19,290
Bye bye, dear S8.

321
00:37:19,290 --> 00:37:26,210
So, it's the same thing that happened on the other video, but the action is actually different.

322
00:37:26,210 --> 00:37:30,510
The action is the erase, so the phone gets erased.

323
00:37:30,510 --> 00:37:38,510
Also, the SD card is formatted, so all data in this phone is lost.

324
00:37:39,590 --> 00:37:41,290
That's it.

325
00:37:41,350 --> 00:37:46,190
Here you can see the different steps.

326
00:37:47,190 --> 00:37:55,610
So, over here there's step 1.

327
00:37:56,030 --> 00:38:04,670
This is where the authentication gets stolen from the server.

328
00:38:04,670 --> 00:38:14,070
The reply to the phone is injected with 2bwipe.

329
00:38:14,070 --> 00:38:18,150
It's hard to see here, but it's over here, 2bwipe.

330
00:38:18,150 --> 00:38:29,010
And then a series of steps that are needed to actually make the phone erased.

331
00:38:29,950 --> 00: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.

332
00:38:40,770 --> 00:38:43,990
This was classified as a high-impact vulnerability.

333
00:38:44,290 --> 00:38:49,370
And then we realized there was a lot more into it.

334
00:38:49,370 --> 00:38:57,790
This kind of behavior affects many different parts from the application part, the web server part.

335
00:38:57,790 --> 00:38:59,590
There were some things that needed to change.

336
00:38:59,590 --> 00:39:02,790
It took some time until they could issue a proper fix.

337
00:39:02,890 --> 00:39:06,510
And they granted a 10k USD bounty.

338
00:39:06,750 --> 00:39:14,410
And in addition, there were some closely related critical flaws that are not in the scope of this talk.

339
00:39:14,410 --> 00:39:16,970
It's not the application side.

340
00:39:16,970 --> 00:39:21,370
So, it was added a 25k USD bonus.

341
00:39:21,450 --> 00:39:24,250
So, in the end, it was very, very nice.

342
00:39:25,170 --> 00:39:27,770
So, this concludes our presentation.

343
00:39:27,870 --> 00: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.

344
00:39:42,190 --> 00:39:50,950
These are all different issues that sometimes are common to other applications or some of them are very Android specific.

345
00:39:51,170 --> 00:39:55,070
Before we go, we'd like to just say some words.

346
00:39:55,210 --> 00: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.

347
00:40:06,830 --> 00:40:12,890
Luckily, we are paid for this research and we're not depending on bounties.

348
00:40:12,890 --> 00:40:15,630
But, of course, they are always appreciated.

349
00:40:16,710 --> 00:40:26,090
It's interesting to note that the vulnerability complexity does not, you know, equal having a greater impact or more rewards.

350
00:40:26,090 --> 00:40:34,590
Sometimes you spend a lot of time trying to develop a POC or a working POC on a very complex issue.

351
00:40:34,590 --> 00: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.

352
00:40:46,890 --> 00:40:51,470
And the final word is that we are really a friend.

353
00:40:51,470 --> 00:40:52,530
We are not the enemy.

354
00:40:52,530 --> 00: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.

355
00:41:05,250 --> 00:41:10,270
And , you know, threats and liars, legal suits are really not necessary.

356
00:41:11,310 --> 00: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.

357
00:41:18,970 --> 00:41:27,750
So I think now we are going to be open for questions if anyone wants to ask something.

358
00:41:27,750 --> 00:41:28,950
Thank you.