Facebook – Private Image – No Authentication Required to View

[FBSecuritySux]

What's funny is Facebook -> 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 "guessable" URL, ergo security through obscurity was their "security method" 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'll see the image is COMPLETELY public -> meaning no authentication is required.

They refused to acknowledge this as a "security risk". I laughed, then was really pissed that a PRIVATE image shared between two parties can be viewed w/o authentication above it.

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 → BoorishBears]

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 → meric]

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.