Good afternoon everyone and today's the next talk is how to
obtain 100 Facebook accounts per day through Internet searches
and the speakers will be Guillermo and Yael, right? The
both of them are pen testers and security researchers and they
will be sharing the experience with you. Thank you. Over to
you. Hello everybody. Thanks for coming. I'm Guillermo and this
is Yael and we are present. How obtain 100 Facebook account
search per day through Internet searches. This is our
disclaimer.
And this is the agenda.
Hello. Hi. Well, in this talk we will talk about vulnerability
we found last year within the Facebook platform, specifically
the mobile Facebook application.
And we will talk about how we discovered it, how we reported
it, and we got rewarded by it. So we'll talk about the
remediation Facebook implemented and possible next steps to test
another vulnerable application. Okay. This is about us. We are
members of the Lloyd's cybersecurity team in Mexico City. Both are
as a penetration tester. And this is our first serious research.
We love security, learn interesting things, and breaking things for
fun. So we are into book bounties and participate into CTFs for
hobby. Yeah. Well, first of all, you all seem good. Okay. First
of all, the issue is that we have a lot of data. We have a lot of data.
So we found a huge issue. This was found in the Instant Articles
functionality back in 2016. Facebook implemented this functionality
where you can view content directly within the API, which is the application
of Facebook, without opening the content in another browser, for instance.
You can view this content, share it, and copy it, and whatever.
With this functionality we found a social hijacking vulnerability.
and we inform it to Facebook. Okay. And how it works. We
detect a vulnerability when shared links from Facebook
mobile application. This vulnerability is caused to do
lack of proper validation in WhatsApp pin logic. When
created URL shortened from Facebook articles, you can see
in this image, how some person shared a link in Facebook. It
was observed that some links are shared with a session key
and a P key which allows a third party to steal a session when
opening the link in a browser.
See how it works.
Since the browser asked to initiate session as the user
then initially shared the link.
The proof of concept we performed was more or less
what Guillermo has already explained. The process is as follows.
A legitimate user using his mobile Facebook application is
searching content. He observes something that he likes and he
opens the... The camera is your part.
It's an article.
He starts opening it in the browser. He clicks on the options button.
He can then copy the link, share it, open it in the browser and whatever.
But if this user shares the link through any content media or any message,
for instance, WhatsApp this time, a malicious user can open the link.
He clicks on this link and another phone, for instance,
or another computer and the browser asks immediately to
initiate session as the first user initially shared the link.
This happens because of the functionality of one tap loading
from Facebook. The problem was when
a instance article creates the shortened link
to share the media, it contains a
a valid session from the first user.
So by clicking just in OK
in the browser, the malicious user can access
the account of the first user.
Okay, and how to exploit this vulnerability en masse?
It was
not easy
to test this issue when we identified the vulnerability
because it's not always present when sharing a link from
the Facebook mobile application. However,
we already knew how these sheltered links were constructed
and its content. So if you
see, this is the structure of a vulnerability link.
You can see
API key and session key.
So, the solution, it was
the internet. It was
possible to replicate this issue several times with a lot of Facebook accounts
on the web. First, by searching in Google, it was
possible to observe that it's quite common to share links on hardware
that can be used to validate sessions from Facebook
accounts.
This is an
index search in Google. You can see
a lot of links, but we had
a problem with this.
Work 5, some links
passed six months, but other links were too old.
So,
we need
some recent stuff and
before, we used a real-time
search in Twitter.
When we use a real-time
Twitter indexing searches,
we obtain a lot of valid links.
Around
100 links
valid per day.
The problem with these kind of links
is that they not always
work. They
has an expiration
issue.
So, we need to look for them
in kind of real-time
through searches. This time
using Twitter.
But, not all of the links
were valid to
SEO session.
However, we found
a lot, really a lot
links that were actually valid.
And these kind of links into
all kind of people.
From users
to politicians even.
Okay.
And now,
a couple of
videos from this
vulnerability.
First,
we see
how to search a vulnerability
links.
We use
Twitter in order to get
these links that were
shared like
within one, two days.
And even
those links were not always
valid. However,
you can find them
like
a lot within the
application.
We used Twitter to
look for this kind of
URLs.
In this moment,
always searching
in Twitter.
Only the
structure facebook.com
slash out dot
php.
And we found
a lot of
links with this structure.
The first link, for instance,
was not valid.
It didn't open
and even
without the content.
But this one
was indeed
valid.
So by clicking
okay,
we could have
the account of this person.
The next video,
we see how to obtain
a valid session
with these links.
Here is the proof of
content.
When we
percolate
a user, we can
look for this kind of
URLs within his content
media. It can be Twitter,
Facebook, through Google
searches or wherever.
We found
the link that has this
kind of structure.
This user
share
a
link,
a valid
link.
But in this moment,
I delete
my cache
in my browser.
And
this
user
And then
I open
the link again.
We obtain
one type
login,
and then
we obtain
a valid session
for that user.
Now we
are inside
the account
of the
people.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
And this is the part of how Facebook remediated this vulnerability.
Facebook didn't mitigate this vulnerability URL shortened error.
Instead, they have mitigated the vulnerability present in one-tap login.
A redirection in the URL with the vulnerability was implemented, facebook.com slash out.php,
so that is no longer possible to steal a valid session from them.
This is a video of how Facebook mitigated this vulnerability.
In this moment, if you search these vulnerability links,
you can see many of them.
But if you open these links, redirection mitigate, you pass the one-tap login.
But if you search in this moment facebook.com slash out.php,
you can find a lot of links.
Are they still generating the link the same way?
The remediation was to implement the redirection.
So when you click on it, you are redirected directly to the content media,
instead of the one-tap login, you know?
Yep.
So in the experiment links,
Facebook is still putting people's session tweets in the URL when you generate the link?
Yeah, some of them have special value.
We will see in the next slide.
So what's next?
Those are the next steps.
We have found that effectively this content is still shared with some values that can be hacked.
This time we found this kind of URL with an SSO request field.
However, this kind of URL was not that easy to tell,
because it has an expiration time really, really short.
So within real-time searches within Twilio, for instance,
it was not the same to test it, because a lot of them are already expired.
Our solution could be an automatic tool
in order to look for this kind of link in real-time,
and test it immediately.
And we have a video showing this new vulnerability
and how we can abuse it in order to get a valid session from my user.
It's just the same way as previously.
In this first video, you can see how to search these other tokens.
And this kind of links are shared.
The problem with this is when you open these links,
the session was expired in all of this.
.
But we have a video with a valid session from that link.
And this is how could we exploit SSO requests in my account.
.
.
First, we check if it have another session from Facebook.
.
.
You can see the structure of the URL.
It has a value hash very long.
.
.
.
.
.
.
.
.
.
.
And in this moment, you have a valid session.
.
.
.
.
.
.
.
We have it inside our DOS, the ISO request, and the previous one with the app key and
the session key.
Yeah.
The problem with these links, if you reply the link, the link was expired.
Did you try to replicate this issue immediately with the same URL?
It didn't work at all.
This is the problem for this vulnerability.
However, there it is.
The problem here is that the app is still generating this kind of URLs with private fields with content that it shouldn't have.
So even though Facebook has implemented this redirection, it's not the solution to the real problem.
So there are...
Thank you.
Thank you.
Thank you.