
Facebook – Private Image – No Authentication Required to View - FBSecuritySux
What&#x27;s funny is Facebook -&gt; has a publically faced image server that has NO authentication required to see even private messages. When FB Security was contacted ... they say it was not a &quot;guessable&quot; URL, ergo security through obscurity was their &quot;security method&quot; of choice. This was two days ago.
If anyone wants to test this theory - setup 2 FB accounts, message an image one FB account to the other. Click on the image with the second account (to bring up the lightbox custom thingy they have). Drag that image into notepad (to get the URL)... then try and logout of both accounts, clear your cache, and you&#x27;ll see the image is COMPLETELY public -&gt; meaning no authentication is required.<p>They refused to acknowledge this as a &quot;security risk&quot;. I laughed, then was really pissed that a PRIVATE image shared between two parties can be viewed w&#x2F;o authentication above it.<p>WTF?
======
simon_acca
So, let's calculate this: I pulled an image from a private facebook group, and
the URL is of this form (although this particular URL is bogus, of course):

    
    
      https://scontent-abc2-1.xx.fbcdn.net/v/t1.0-0/p600x600/35938454_4896129300617330_9044691654193995233_n.jpg?oh=cbfe497e1191ff4669103957691ba34b3&oe=92AC4028
    

We have a section of length 43 that can vary in the range [0-9] (that is, 10
possible values):

    
    
      35938454_4896129300617330_9044691654193995233
    

A section of length 33 that appears to be in the range [0-9a-f] (that is, 16
possible values):

    
    
      cbfe497e1191ff4669103957691ba34b3
    

A section of length 8 in the range [0-9A-F] (that is, 16 possible values):

    
    
      92AC4028
    
    

So how many different URLs are possible?

    
    
      10 ^ 43 * 16 ^ 33 * 16 ^ 8 = ~ 10 ^ 92 ~ 2 ^ 306
    
    

This is a HUGE space, just to get a sense of it, adding 100 billion images a
day, it would take ~ 10 ^ 80 YEARS for facebook to exhaust it!

By the way, that's also how much it would take you to examine all of it while
hunting for user's images (assuming this facebook endpoint does not even have
rate limiting on it, which it almost certainly does).

------
BoorishBears
Do you call a password "security by obscurity" because it can be guessed?

How long is the identifier in question?

Edit:

It sounds like they're not trying to protect the person sending the image,
they're assuming Bob and Alice trust each other not to send the link where
it's not intended, but want to enable Bob and Alice to share the image with
Joe if he's trusted by the receiver.

~~~
meric
Yes, the trusted party could always upload the image to imgur instead of copy
and pasting the URL to an untrustworthy party. Imagine a URL that contains the
entire image data and passing that around, for example.

~~~
dsacco
Information security typically models risk assessments with two axes for
severity, not one. They are not purely consequential; rather, they are both
consequential and probabilistic. If you have a 10% chance of SQL injection
being present in your application but a 50% chance of it being devastating,
and a 90% chance of CSRF being present with a 50% chance of it being
devastating, you want to prioritize the CSRF vulnerabilities first.

Similarly, yes, it would be really crappy to have a private photo published on
Imgur, but from an application security perspective the probability (and thus,
risk-adjusted severity) of that is absurdly unrealistic. From a risk policy
standpoint, the context of Facebook makes sense for implicitly trusting
friends with photos. It's not terribly important or strategic data, and since
you're starting from "only a subset of people I select can view this", not
"only I can view this", it becomes difficult to design a better policy than
what already exists.

Even with a much more stringent ACL in place, your friends could just download
the file when they view it and distribute it from there, bypassing the link
altogether. This is a rabbit hole.

------
jklein11
Putting aside this being a potential security vulnerability it seems like an
easy way to get free image hosting. I wonder if you could use this by changing
the file extension of a .zip to.jpg

------
tedmiston
Just to be clear, this is how it's always worked. While I don't think it's
ideal either and I'd rather have it more locked down, it's also not something
that they've changed. A lot of apps use this pattern of secret vs truly
private.

------
dsacco
To be honest with you, I'm not even sure where to start with your rant. I'm
normally pretty open minded on HN but this is just frustrating to read.

They refused to acknowledge this as a security risk because it's not a
security risk. In fact, they specifically call this particular topic out on
their Whitehat page under the _Ineligible Reports and False Positives_
heading. They have called attention to this topic as ineligible for a bounty
for _at least_ the last two years on that page, because 1) it's not indicative
of an application security failure and 2) they receive a vast number of
invalid reports about it.

Let's talk about "security through obscurity", a term that has become a hand-
wavy way of saying, "I don't really agree with how they're doing this because
it seems theoretically imperfect, but I can't really explain why." A series of
strings in a URL that are securely generated and infeasible to brute-force do
not constitute actual security through obscurity. Security through obscurity
is setting SSH to a port other than 22 (and let's be clear - security through
obscurity is not a bad thing when it's coupled with best practices). A vast
foundation of information security as a discipline relies upon the security of
things that are infeasible for a computer to brute-force. Cryptography is a
science predicated on the idea that making things extremely work-intensive is
an acceptable substitute for information-theoretic security, which is
generally unreasonable or redundant in practice.

Each portion of a Facebook CDN image URL is designed with an access and
authorization policy in mind. The fbid URL parameter _alone_ is a 64-bit
number, and that is only _one_ of the parameters you would need to
successfully brute-force in order to correctly identify a valid image URL. How
long do you suppose it would take your computer (hell, let's give you 100,
each with different IP addresses) to process 9,223,372,036,854,775,807
requests for a particular image URL on the Facebook CDN? But wait, let's not
forget, this is not offline cracking - you are making requests to Facebook's
servers, where they are free to rate-limit you at the slightest sign of
suspicious or abusive activity.

Now let's talk about this model of security at a higher level. Facebook uses a
very robust ACL to discriminate between users that are and are not authorized
to view a specific resource on facebook.com, before the user can be sent the
CDN link. This ACL guarantees that parameters such as the fbid need to be
correct before the CDN link will be granted, at which point those parameters
are "inherited" by the CDN URL. The CDN uses a capability model, not unlike
Imgur's "Private" albums or Google's published, non-public Docs links. If
someone has a direct link to the resource, the URL parameters inherent to that
link almost certainly suggest that the user is authorized to view it, because
it acts as a gate before they could have been redirected to the CDN in the
first place. The only other options are 1) a user brute-forced an image URL
(good luck!) or 2) someone who was authorized passed the link on to someone
who was not authorized.

Seeing that case #2 is the only realistic risk for an image URL compromise,
let's continue with that. Is case #2 a problem? From an application security
perspective, no, because it doesn't constitute a technical software
vulnerability. From a risk assessment perspective, maybe? I agree with
Facebook in that if you trust someone with a URL, you implicitly trust them to
be prudent in passing that along (at least, in the context of Facebook). But
this is a good juncture to talk about risk as a dimension of information
security's business process. The context of this discussion is not a military
staging server, nor is it even a HIPAA compliant database. This is a CDN for
people to store photos on that are _inherently designed to be shared with the
world._ From a risk assessment standpoint, these photos are only designed to
be shared with friends. Could your friends do something vindictive with the
links? Sure, but in the context of Facebook it's (reasonably!) assumed that
you trust your friends enough to not use that access against you. From that
perspective, the security measures are optimized for ensuring that only a
subset of people (based on the ACL policy) are authorized to view them, not
"no one but me." Let's also not forget that even if Facebook designed a much
more stringent ACL, your vindictive friends could simply download the image
after they are able to view it, and distribute it that way.

Security vulnerabilities do not exist in isolation. They are logical failures
between a software's design and implementation, or they are risk failures in a
software's design. And even if this presented an issue from a risk assessment
perspective, this still does not constitute an application security
vulnerability, which means it's not eligible for a bug bounty anyway. In
short, you have quite a few bars to pass in order to demonstrate that this is
an issue at all.

Finally, I'd like to hear from you what you would do differently. How would
you design a CDN for Facebook with a superior security model that matches the
same scale and usability requirements?

------
rnovak
I'm confused as to why _anyone_ would think facebook's security is good? Their
entire profit model is based entirely on sharing information that most people
would consider private (and have no clue is being sold to third parties).

Furthermore, however, how would _you_ design a Content Delivery system that
was performant that also had the level of security/privacy that you'd consider
appropriate? keep in mind that cookie/session based security requires extra
network traffic and coordination, whereas a simple GET request is pretty
simple.

Considering the _massive_ amount of traffic they deal with (nearly 1B people,
right?), I think their use of UUID type strings (though I don't think they're
specifically UUIDs) is pretty appropriate.

I guess let me ask it this way: what threat do you feel they've left you open
to?

------
jayajay
Post an example link, or it didn't happen.

