How to find a major security breach at Facebook

Facebook offers a bounty for bugs, but Facebook did not play fair on this one. Instead, Facebook immediately reached out to the hacker’s employer and accused the hacker of unethical behavior. The Facebook CSO later offered the cheap excuse that the hacker might have been working in an official capacity for the employer. The more likely story is that Facebook was embarrassed and wanted this story to be remain hidden. Interesting:

With the newly obtained AWS key, I browsed several buckets. There appeared to be a lot of potentially sensitive content, but a lot of it was just more versioned tar archives of tools and web applications. I queued up several buckets to download, and went to bed for the night.

The next day, I began to go through some of what I’d downloaded, and some of the remaining buckets. There were quite a few S3 buckets dedicated to storing users’ Instagram images, both pre and post processing. Since the Faceboook Whitehat rules state that researchers need to “make a good faith effort to avoid privacy violations”, I avoided downloading any content from those buckets. The remaining buckets however proved to be extremely valuable.

The following is the types of data that was available all using one AWS keypair, although the data was spread across multiple buckets:

Static content for Instagram.com websites. Write access was not tested, but seemed likely.
Source code for fairly recent versions of the Instagram server backend, covering all API endpoints, some image processing libraries, etc.

SSL certificates and private keys, including both instagram.com and *.instagram.com

Secret keys used to sign authentication cookies for Instagram

OAuth and other Instagram API keys

Email server credentials

iOS and Android app signing keys

iOS Push Notifications keys

Twitter API keys

Facebook API keys

Flickr API keys

Tumblr API keys

Foursquare API keys

Recaptcha key-pair

To say that I had gained access to basically all of Instagram’s secret key material would probably be a fair statement. With the keys I obtained, I could now easily impersonate Instagram, or impersonate any valid user or staff member. While out of scope, I would have easily been able to gain full access to any user’s account, private pictures and data. It is unclear how easy it would be to use the information I gained to then compromise the underlying servers, but it definitely opened up a lot of opportunities.

My vulnerability submission for this third finding included 7 different issues, all of which contributed to how much data I could access. These were:

AWS credentials accessible to unprivileged user on Sensu system.

AWS bucket contain credentials for other buckets (specifically autoscale-kitchen). This is a classic privilege escalation weakness

No access segregation on AWS credentials. Using one set of AWS keys I was able to access all S3 buckets.

“Secret keys” stored throughout S3 buckets. This is furthered by the fact that some buckets no longer contain keys in their latest application version, but the bucket contains all previous application versions. These keys do not appear to be separated properly so that one application can only access keys appropriate to its application, but they are spread out across multiple buckets

Files stored in some buckets are encrypted to passwords also stored in the same bucket (or accessible via the same AWS key)

AWS keys can be used from any remote IP.

If audit logging takes place, it is not monitored in any way as none of my access was detected (as far as I am aware).