1
00:00:00,000 --> 00:00:03,880
Good afternoon everyone and today's the next talk is how to

2
00:00:03,880 --> 00:00:06,860
obtain 100 Facebook accounts per day through Internet searches

3
00:00:07,360 --> 00:00:11,060
and the speakers will be Guillermo and Yael, right? The

4
00:00:11,060 --> 00:00:13,860
both of them are pen testers and security researchers and they

5
00:00:13,860 --> 00:00:16,020
will be sharing the experience with you. Thank you. Over to

6
00:00:16,020 --> 00:00:23,020
you. Hello everybody. Thanks for coming. I'm Guillermo and this

7
00:00:23,020 --> 00:00:27,900
is Yael and we are present. How obtain 100 Facebook account

8
00:00:27,900 --> 00:00:34,740
search per day through Internet searches. This is our

9
00:00:34,740 --> 00:00:35,280
disclaimer.

10
00:00:51,380 --> 00:00:54,400
And this is the agenda.

11
00:01:12,780 --> 00:01:18,740
Hello. Hi. Well, in this talk we will talk about vulnerability

12
00:01:18,740 --> 00:01:24,160
we found last year within the Facebook platform, specifically

13
00:01:24,500 --> 00:01:26,360
the mobile Facebook application.

14
00:01:26,360 --> 00:01:31,460
And we will talk about how we discovered it, how we reported

15
00:01:31,460 --> 00:01:36,620
it, and we got rewarded by it. So we'll talk about the

16
00:01:36,620 --> 00:01:42,440
remediation Facebook implemented and possible next steps to test

17
00:01:42,900 --> 00:01:52,080
another vulnerable application. Okay. This is about us. We are

18
00:01:52,080 --> 00:01:56,120
members of the Lloyd's cybersecurity team in Mexico City. Both are

19
00:01:56,120 --> 00:02:00,880
as a penetration tester. And this is our first serious research.

20
00:02:01,140 --> 00:02:05,120
We love security, learn interesting things, and breaking things for

21
00:02:05,120 --> 00:02:10,940
fun. So we are into book bounties and participate into CTFs for

22
00:02:10,940 --> 00:02:24,440
hobby. Yeah. Well, first of all, you all seem good. Okay. First

23
00:02:24,440 --> 00:02:26,100
of all, the issue is that we have a lot of data. We have a lot of data.

24
00:02:26,120 --> 00:02:29,920
So we found a huge issue. This was found in the Instant Articles

25
00:02:29,920 --> 00:02:35,340
functionality back in 2016. Facebook implemented this functionality

26
00:02:35,340 --> 00:02:40,560
where you can view content directly within the API, which is the application

27
00:02:40,560 --> 00:02:44,800
of Facebook, without opening the content in another browser, for instance.

28
00:02:45,100 --> 00:02:49,060
You can view this content, share it, and copy it, and whatever.

29
00:02:50,840 --> 00:02:54,820
With this functionality we found a social hijacking vulnerability.

30
00:02:54,820 --> 00:03:12,620
and we inform it to Facebook. Okay. And how it works. We

31
00:03:12,620 --> 00:03:15,240
detect a vulnerability when shared links from Facebook

32
00:03:15,240 --> 00:03:18,400
mobile application. This vulnerability is caused to do

33
00:03:18,400 --> 00:03:22,260
lack of proper validation in WhatsApp pin logic. When

34
00:03:22,260 --> 00:03:28,180
created URL shortened from Facebook articles, you can see

35
00:03:28,180 --> 00:03:40,360
in this image, how some person shared a link in Facebook. It

36
00:03:40,360 --> 00:03:44,520
was observed that some links are shared with a session key

37
00:03:44,520 --> 00:03:49,320
and a P key which allows a third party to steal a session when

38
00:03:49,320 --> 00:03:51,320
opening the link in a browser.

39
00:03:51,620 --> 00:03:52,240
See how it works.

40
00:03:52,260 --> 00:03:56,180
Since the browser asked to initiate session as the user

41
00:03:56,180 --> 00:03:58,660
then initially shared the link.

42
00:04:01,980 --> 00:04:05,800
The proof of concept we performed was more or less

43
00:04:05,800 --> 00:04:10,920
what Guillermo has already explained. The process is as follows.

44
00:04:11,420 --> 00:04:16,340
A legitimate user using his mobile Facebook application is

45
00:04:16,340 --> 00:04:20,080
searching content. He observes something that he likes and he

46
00:04:20,080 --> 00:04:22,080
opens the... The camera is your part.

47
00:04:22,080 --> 00:04:22,820
It's an article.

48
00:04:22,980 --> 00:04:29,940
He starts opening it in the browser. He clicks on the options button.

49
00:04:30,780 --> 00:04:37,400
He can then copy the link, share it, open it in the browser and whatever.

50
00:04:37,800 --> 00:04:45,180
But if this user shares the link through any content media or any message,

51
00:04:45,360 --> 00:04:52,060
for instance, WhatsApp this time, a malicious user can open the link.

52
00:04:52,060 --> 00:04:55,420
He clicks on this link and another phone, for instance,

53
00:04:55,560 --> 00:04:59,560
or another computer and the browser asks immediately to

54
00:05:00,820 --> 00:05:05,340
initiate session as the first user initially shared the link.

55
00:05:05,760 --> 00:05:10,080
This happens because of the functionality of one tap loading

56
00:05:10,080 --> 00:05:12,680
from Facebook. The problem was when

57
00:05:12,680 --> 00:05:17,400
a instance article creates the shortened link

58
00:05:17,700 --> 00:05:20,680
to share the media, it contains a

59
00:05:20,680 --> 00:05:24,260
a valid session from the first user.

60
00:05:24,540 --> 00:05:28,180
So by clicking just in OK

61
00:05:28,180 --> 00:05:32,260
in the browser, the malicious user can access

62
00:05:32,260 --> 00:05:35,400
the account of the first user.

63
00:05:36,440 --> 00:05:40,080
Okay, and how to exploit this vulnerability en masse?

64
00:05:43,840 --> 00:05:44,980
It was

65
00:05:47,840 --> 00:05:49,440
not easy

66
00:05:49,440 --> 00:05:52,080
to test this issue when we identified the vulnerability

67
00:05:52,980 --> 00:05:56,420
because it's not always present when sharing a link from

68
00:05:56,680 --> 00:05:59,540
the Facebook mobile application. However,

69
00:06:01,020 --> 00:06:04,940
we already knew how these sheltered links were constructed

70
00:06:04,940 --> 00:06:09,020
and its content. So if you

71
00:06:09,020 --> 00:06:13,080
see, this is the structure of a vulnerability link.

72
00:06:13,280 --> 00:06:14,180
You can see

73
00:06:14,980 --> 00:06:17,200
API key and session key.

74
00:06:19,000 --> 00:06:22,200
So, the solution, it was

75
00:06:23,240 --> 00:06:26,800
the internet. It was

76
00:06:26,800 --> 00:06:30,780
possible to replicate this issue several times with a lot of Facebook accounts

77
00:06:30,780 --> 00:06:34,760
on the web. First, by searching in Google, it was

78
00:06:34,760 --> 00:06:38,120
possible to observe that it's quite common to share links on hardware

79
00:06:38,800 --> 00:06:42,800
that can be used to validate sessions from Facebook

80
00:06:42,800 --> 00:06:43,220
accounts.

81
00:06:47,680 --> 00:06:48,740
This is an

82
00:06:48,740 --> 00:06:52,900
index search in Google. You can see

83
00:06:52,900 --> 00:06:56,980
a lot of links, but we had

84
00:06:56,980 --> 00:06:58,060
a problem with this.

85
00:07:02,780 --> 00:07:04,860
Work 5, some links

86
00:07:04,860 --> 00:07:08,880
passed six months, but other links were too old.

87
00:07:10,040 --> 00:07:10,680
So,

88
00:07:10,680 --> 00:07:14,580
we need

89
00:07:14,580 --> 00:07:16,220
some recent stuff and

90
00:07:16,220 --> 00:07:18,220
before, we used a real-time

91
00:07:18,220 --> 00:07:19,340
search in Twitter.

92
00:07:25,740 --> 00:07:28,240
When we use a real-time

93
00:07:28,240 --> 00:07:30,360
Twitter indexing searches,

94
00:07:30,700 --> 00:07:32,500
we obtain a lot of valid links.

95
00:07:32,960 --> 00:07:33,600
Around

96
00:07:34,420 --> 00:07:36,140
100 links

97
00:07:36,400 --> 00:07:37,300
valid per day.

98
00:07:37,700 --> 00:07:40,400
The problem with these kind of links

99
00:07:40,680 --> 00:07:42,500
is that they not always

100
00:07:42,500 --> 00:07:44,240
work. They

101
00:07:45,060 --> 00:07:46,440
has an expiration

102
00:07:47,260 --> 00:07:47,940
issue.

103
00:07:48,280 --> 00:07:50,640
So, we need to look for them

104
00:07:50,640 --> 00:07:52,640
in kind of real-time

105
00:07:52,640 --> 00:07:54,560
through searches. This time

106
00:07:54,560 --> 00:07:55,280
using Twitter.

107
00:07:55,900 --> 00:07:58,700
But, not all of the links

108
00:07:58,700 --> 00:08:00,260
were valid to

109
00:08:00,260 --> 00:08:00,880
SEO session.

110
00:08:02,300 --> 00:08:04,120
However, we found

111
00:08:04,120 --> 00:08:06,400
a lot, really a lot

112
00:08:06,400 --> 00:08:08,580
links that were actually valid.

113
00:08:08,820 --> 00:08:10,500
And these kind of links into

114
00:08:10,680 --> 00:08:12,260
all kind of people.

115
00:08:12,580 --> 00:08:14,660
From users

116
00:08:14,660 --> 00:08:16,780
to politicians even.

117
00:08:17,400 --> 00:08:18,240
Okay.

118
00:08:20,260 --> 00:08:21,360
And now,

119
00:08:21,560 --> 00:08:23,520
a couple of

120
00:08:23,520 --> 00:08:24,960
videos from this

121
00:08:24,960 --> 00:08:25,240
vulnerability.

122
00:08:27,040 --> 00:08:27,880
First,

123
00:08:28,680 --> 00:08:30,480
we see

124
00:08:30,480 --> 00:08:32,060
how to search a vulnerability

125
00:08:32,060 --> 00:08:32,600
links.

126
00:08:41,180 --> 00:08:42,380
We use

127
00:08:42,380 --> 00:08:44,500
Twitter in order to get

128
00:08:44,500 --> 00:08:46,280
these links that were

129
00:08:46,280 --> 00:08:47,260
shared like

130
00:08:47,260 --> 00:08:50,080
within one, two days.

131
00:08:50,380 --> 00:08:52,380
And even

132
00:08:52,380 --> 00:08:54,360
those links were not always

133
00:08:54,360 --> 00:08:55,660
valid. However,

134
00:08:55,880 --> 00:08:57,920
you can find them

135
00:08:58,680 --> 00:08:59,380
like

136
00:09:00,520 --> 00:09:02,340
a lot within the

137
00:09:02,340 --> 00:09:02,820
application.

138
00:09:04,500 --> 00:09:06,400
We used Twitter to

139
00:09:06,400 --> 00:09:07,780
look for this kind of

140
00:09:08,310 --> 00:09:08,700
URLs.

141
00:09:13,540 --> 00:09:14,820
In this moment,

142
00:09:14,980 --> 00:09:16,680
always searching

143
00:09:17,280 --> 00:09:18,320
in Twitter.

144
00:09:20,320 --> 00:09:21,340
Only the

145
00:09:21,340 --> 00:09:23,160
structure facebook.com

146
00:09:23,160 --> 00:09:25,160
slash out dot

147
00:09:25,160 --> 00:09:26,180
php.

148
00:09:26,440 --> 00:09:28,960
And we found

149
00:09:28,960 --> 00:09:29,820
a lot of

150
00:09:30,440 --> 00:09:31,900
links with this structure.

151
00:09:32,360 --> 00:09:33,940
The first link, for instance,

152
00:09:34,060 --> 00:09:34,900
was not valid.

153
00:09:35,080 --> 00:09:36,440
It didn't open

154
00:09:36,440 --> 00:09:40,000
and even

155
00:09:40,680 --> 00:09:41,420
without the content.

156
00:09:44,100 --> 00:09:45,300
But this one

157
00:09:49,480 --> 00:09:50,440
was indeed

158
00:09:50,440 --> 00:09:50,780
valid.

159
00:09:52,260 --> 00:09:53,560
So by clicking

160
00:09:53,560 --> 00:09:53,900
okay,

161
00:09:54,200 --> 00:09:55,760
we could have

162
00:09:55,760 --> 00:09:57,440
the account of this person.

163
00:09:57,720 --> 00:09:58,940
The next video,

164
00:09:59,700 --> 00:10:01,400
we see how to obtain

165
00:10:01,400 --> 00:10:02,260
a valid session

166
00:10:02,260 --> 00:10:04,280
with these links.

167
00:10:13,400 --> 00:10:15,400
Here is the proof of

168
00:10:15,400 --> 00:10:15,700
content.

169
00:10:17,680 --> 00:10:18,700
When we

170
00:10:19,940 --> 00:10:20,620
percolate

171
00:10:20,620 --> 00:10:22,340
a user, we can

172
00:10:22,340 --> 00:10:24,320
look for this kind of

173
00:10:24,320 --> 00:10:26,100
URLs within his content

174
00:10:26,100 --> 00:10:28,160
media. It can be Twitter,

175
00:10:28,360 --> 00:10:30,500
Facebook, through Google

176
00:10:30,500 --> 00:10:31,660
searches or wherever.

177
00:10:33,060 --> 00:10:34,040
We found

178
00:10:34,040 --> 00:10:36,400
the link that has this

179
00:10:36,400 --> 00:10:37,220
kind of structure.

180
00:10:51,240 --> 00:10:52,420
This user

181
00:10:52,420 --> 00:10:53,220
share

182
00:10:54,280 --> 00:10:55,040
a

183
00:10:57,220 --> 00:10:57,980
link,

184
00:11:00,140 --> 00:11:00,560
a valid

185
00:11:00,560 --> 00:11:00,880
link.

186
00:11:01,260 --> 00:11:02,320
But in this moment,

187
00:11:02,500 --> 00:11:05,180
I delete

188
00:11:05,180 --> 00:11:06,040
my cache

189
00:11:06,040 --> 00:11:07,580
in my browser.

190
00:11:09,860 --> 00:11:10,620
And

191
00:11:10,620 --> 00:11:10,660
this

192
00:11:12,480 --> 00:11:12,860
user

193
00:11:13,240 --> 00:11:13,540
And then

194
00:11:13,540 --> 00:11:14,820
I open

195
00:11:14,820 --> 00:11:16,440
the link again.

196
00:11:19,260 --> 00:11:20,380
We obtain

197
00:11:20,380 --> 00:11:21,300
one type

198
00:11:21,300 --> 00:11:21,580
login,

199
00:11:21,900 --> 00:11:22,540
and then

200
00:11:22,540 --> 00:11:23,780
we obtain

201
00:11:23,780 --> 00:11:25,980
a valid session

202
00:11:25,980 --> 00:11:27,320
for that user.

203
00:11:48,180 --> 00:11:49,280
Now we

204
00:11:49,280 --> 00:11:49,760
are inside

205
00:11:49,760 --> 00:11:50,600
the account

206
00:11:50,600 --> 00:11:51,000
of the

207
00:11:51,000 --> 00:11:51,220
people.

208
00:11:57,560 --> 00:11:58,360
.

209
00:11:59,260 --> 00:12:00,060
.

210
00:12:00,060 --> 00:12:00,080
.

211
00:12:00,080 --> 00:12:00,560
.

212
00:12:00,560 --> 00:12:01,080
.

213
00:12:01,080 --> 00:12:01,220
.

214
00:12:02,840 --> 00:12:03,640
.

215
00:12:04,460 --> 00:12:04,860
.

216
00:12:04,860 --> 00:12:04,960
.

217
00:12:11,180 --> 00:12:11,820
.

218
00:12:19,240 --> 00:12:19,880
.

219
00:12:19,880 --> 00:12:20,060
.

220
00:12:20,060 --> 00:12:20,080
.

221
00:12:20,400 --> 00:12:20,720
.

222
00:12:20,720 --> 00:12:20,820
.

223
00:12:20,820 --> 00:12:20,900
.

224
00:12:20,900 --> 00:12:21,540
.

225
00:12:21,540 --> 00:12:22,000
.

226
00:12:22,000 --> 00:12:22,040
.

227
00:12:22,040 --> 00:12:22,060
.

228
00:12:40,020 --> 00:12:40,660
.

229
00:12:40,680 --> 00:12:42,960
.

230
00:12:48,260 --> 00:12:49,660
.

231
00:12:52,460 --> 00:12:53,860
.

232
00:12:53,860 --> 00:12:56,440
.

233
00:12:56,440 --> 00:12:57,980
.

234
00:12:57,980 --> 00:12:58,020
.

235
00:12:58,020 --> 00:13:00,300
.

236
00:13:00,300 --> 00:13:01,540
.

237
00:13:01,540 --> 00:13:01,560
.

238
00:13:04,440 --> 00:13:05,840
.

239
00:13:05,840 --> 00:13:05,860
.

240
00:13:05,860 --> 00:13:05,900
.

241
00:13:05,900 --> 00:13:05,980
.

242
00:13:05,980 --> 00:13:07,980
.

243
00:13:11,840 --> 00:13:13,200
.

244
00:13:21,720 --> 00:13:23,080
.

245
00:13:23,080 --> 00:13:24,140
.

246
00:13:24,140 --> 00:13:24,520
.

247
00:13:24,520 --> 00:13:25,200
.

248
00:13:25,200 --> 00:13:25,220
.

249
00:13:29,700 --> 00:13:31,060
.

250
00:13:31,060 --> 00:13:33,440
.

251
00:13:33,440 --> 00:13:33,500
.

252
00:13:33,500 --> 00:13:34,920
.

253
00:13:34,920 --> 00:13:35,060
.

254
00:13:35,060 --> 00:13:35,080
.

255
00:13:35,080 --> 00:13:35,100
.

256
00:13:40,680 --> 00:13:41,600
.

257
00:13:49,060 --> 00:13:50,380
.

258
00:13:50,380 --> 00:13:51,040
.

259
00:13:51,040 --> 00:13:51,100
.

260
00:13:51,100 --> 00:13:51,180
.

261
00:13:51,180 --> 00:13:52,760
.

262
00:13:52,760 --> 00:13:52,780
.

263
00:14:06,680 --> 00:14:07,500
.

264
00:14:07,500 --> 00:14:07,680
.

265
00:14:12,000 --> 00:14:13,400
.

266
00:14:20,200 --> 00:14:21,600
.

267
00:14:25,580 --> 00:14:26,980
.

268
00:14:26,980 --> 00:14:29,200
.

269
00:14:30,680 --> 00:14:31,460
.

270
00:14:31,460 --> 00:14:32,500
.

271
00:14:32,500 --> 00:14:33,020
.

272
00:14:33,020 --> 00:14:33,340
.

273
00:14:33,340 --> 00:14:33,380
.

274
00:14:38,820 --> 00:14:40,220
.

275
00:14:53,200 --> 00:14:59,540
And this is the part of how Facebook remediated this vulnerability.

276
00:15:01,500 --> 00:15:06,060
Facebook didn't mitigate this vulnerability URL shortened error.

277
00:15:06,060 --> 00:15:10,600
Instead, they have mitigated the vulnerability present in one-tap login.

278
00:15:11,040 --> 00:15:19,420
A redirection in the URL with the vulnerability was implemented, facebook.com slash out.php,

279
00:15:19,500 --> 00:15:23,460
so that is no longer possible to steal a valid session from them.

280
00:15:24,320 --> 00:15:28,480
This is a video of how Facebook mitigated this vulnerability.

281
00:15:30,280 --> 00:15:35,300
In this moment, if you search these vulnerability links,

282
00:15:35,300 --> 00:15:38,120
you can see many of them.

283
00:15:38,260 --> 00:15:47,480
But if you open these links, redirection mitigate, you pass the one-tap login.

284
00:15:48,640 --> 00:15:55,440
But if you search in this moment facebook.com slash out.php,

285
00:15:55,620 --> 00:15:57,780
you can find a lot of links.

286
00:15:57,980 --> 00:16:01,420
Are they still generating the link the same way?

287
00:16:01,600 --> 00:16:05,280
The remediation was to implement the redirection.

288
00:16:05,300 --> 00:16:11,220
So when you click on it, you are redirected directly to the content media,

289
00:16:11,340 --> 00:16:13,080
instead of the one-tap login, you know?

290
00:16:14,740 --> 00:16:15,260
Yep.

291
00:16:17,380 --> 00:16:20,300
So in the experiment links,

292
00:16:20,300 --> 00:16:25,700
Facebook is still putting people's session tweets in the URL when you generate the link?

293
00:16:25,860 --> 00:16:29,500
Yeah, some of them have special value.

294
00:16:29,660 --> 00:16:32,860
We will see in the next slide.

295
00:16:37,460 --> 00:16:38,940
So what's next?

296
00:16:40,260 --> 00:16:42,260
Those are the next steps.

297
00:16:42,520 --> 00:16:50,920
We have found that effectively this content is still shared with some values that can be hacked.

298
00:16:52,300 --> 00:16:58,060
This time we found this kind of URL with an SSO request field.

299
00:17:00,080 --> 00:17:04,260
However, this kind of URL was not that easy to tell,

300
00:17:04,260 --> 00:17:08,380
because it has an expiration time really, really short.

301
00:17:09,040 --> 00:17:15,240
So within real-time searches within Twilio, for instance,

302
00:17:15,460 --> 00:17:21,360
it was not the same to test it, because a lot of them are already expired.

303
00:17:22,300 --> 00:17:27,620
Our solution could be an automatic tool

304
00:17:29,120 --> 00:17:33,460
in order to look for this kind of link in real-time,

305
00:17:33,460 --> 00:17:34,980
and test it immediately.

306
00:17:35,400 --> 00:17:41,060
And we have a video showing this new vulnerability

307
00:17:41,060 --> 00:17:45,580
and how we can abuse it in order to get a valid session from my user.

308
00:17:45,840 --> 00:17:47,740
It's just the same way as previously.

309
00:17:48,340 --> 00:17:55,700
In this first video, you can see how to search these other tokens.

310
00:17:58,740 --> 00:18:01,560
And this kind of links are shared.

311
00:18:12,320 --> 00:18:17,780
The problem with this is when you open these links,

312
00:18:17,840 --> 00:18:22,440
the session was expired in all of this.

313
00:18:24,080 --> 00:18:24,880
.

314
00:18:29,320 --> 00:18:36,100
But we have a video with a valid session from that link.

315
00:18:39,510 --> 00:18:46,940
And this is how could we exploit SSO requests in my account.

316
00:18:49,160 --> 00:18:50,060
.

317
00:18:50,060 --> 00:18:50,080
.

318
00:19:02,600 --> 00:19:08,600
First, we check if it have another session from Facebook.

319
00:19:10,840 --> 00:19:11,960
.

320
00:19:11,960 --> 00:19:12,480
.

321
00:19:19,080 --> 00:19:23,220
You can see the structure of the URL.

322
00:19:23,960 --> 00:19:28,800
It has a value hash very long.

323
00:19:30,800 --> 00:19:31,560
.

324
00:19:41,420 --> 00:19:42,120
.

325
00:19:45,340 --> 00:19:46,740
.

326
00:19:46,740 --> 00:19:48,160
.

327
00:19:48,160 --> 00:19:48,540
.

328
00:19:48,540 --> 00:19:49,140
.

329
00:19:50,940 --> 00:19:52,340
.

330
00:19:52,340 --> 00:19:52,360
.

331
00:19:53,980 --> 00:19:55,060
.

332
00:19:55,060 --> 00:19:55,600
.

333
00:19:56,840 --> 00:20:00,460
And in this moment, you have a valid session.

334
00:20:05,100 --> 00:20:05,640
.

335
00:20:07,100 --> 00:20:08,180
.

336
00:20:11,100 --> 00:20:12,180
.

337
00:20:12,180 --> 00:20:12,740
.

338
00:20:12,740 --> 00:20:13,160
.

339
00:20:13,160 --> 00:20:13,740
.

340
00:20:13,740 --> 00:20:14,280
.

341
00:20:14,280 --> 00:20:20,120
We have it inside our DOS, the ISO request, and the previous one with the app key and

342
00:20:20,120 --> 00:20:20,660
the session key.

343
00:20:21,640 --> 00:20:21,940
Yeah.

344
00:20:23,220 --> 00:20:32,780
The problem with these links, if you reply the link, the link was expired.

345
00:20:33,140 --> 00:20:39,420
Did you try to replicate this issue immediately with the same URL?

346
00:20:39,700 --> 00:20:41,540
It didn't work at all.

347
00:20:41,540 --> 00:20:44,980
This is the problem for this vulnerability.

348
00:20:46,680 --> 00:20:48,660
However, there it is.

349
00:20:49,180 --> 00:21:00,940
The problem here is that the app is still generating this kind of URLs with private fields with content that it shouldn't have.

350
00:21:01,560 --> 00:21:09,980
So even though Facebook has implemented this redirection, it's not the solution to the real problem.

351
00:21:10,360 --> 00:21:11,500
So there are...

352
00:21:14,480 --> 00:21:17,280
Thank you.

353
00:21:17,400 --> 00:21:18,460
Thank you.

354
00:21:18,580 --> 00:21:20,940
Thank you.