Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote Code Execution on a Facebook server

blog.scrt.ch

Post reply on HN
Print view View original

171–180 of 207 posts

Re: Remote Code Execution on a Facebook server

#171

Post by brainkim »

chias wrote: post #115
0x8BADF00D wrote: post #71

Earlier quoted context omitted.

He should have gone to the black market, better yet sat on it. How long did it take Facebook to come forward with its user privacy violations?

What would you guess the going rate on the black market would be for an RCE on some error-log collection box that happens to be in use by Facebook? My guess is "less than $5000".

The only code they executed was "sleep(100)" If they started dumping env variables/snooping around they would have done a lot more than $5000 worth of damage.

Re: Remote Code Execution on a Facebook server

#173

Post by tluyben2 »

panopticon wrote: post #143
wereHamster wrote: post #95

Earlier quoted context omitted.

I don't know what the standard way is to deploy django or .net apps, but nodejs apps are often packaged into a docker container, or cloud function, that run independently, not on any particular machine that you designate as 'production'. So 'system-wide' settings don't really exist because there is no concept of a machine. With nodejs in a docker contianer for example you specify whether the server is designated for…

I think you're a little over-confident in the Node community; I've seen a lot of Node apps deployed the same as any other (just tar'ed up and deployed via some kind of script or other deployment tool).

Seems a bit of the HN echo chamber; people here seem to think, because of the high quality stories and comments, that the entire world uses best practices for everything; containers, code reviews, versioning, test coverage, CI, automated deployments, etc. While in reality I think most places are not doing that. This is anecdotal ofcourse but most (large and small) companies I have worked with (as clients or partners) are in fact doing none of these things.

Re: Remote Code Execution on a Facebook server

#176

Post by throwawaymath »

brainkim wrote: post #171
chias wrote: post #115

Earlier quoted context omitted.

What would you guess the going rate on the black market would be for an RCE on some error-log collection box that happens to be in use by Facebook? My guess is "less than $5000".

The only code they executed was "sleep(100)" If they started dumping env variables/snooping around they would have done a lot more than $5000 worth of damage.

How are you quantifying that?

Re: Remote Code Execution on a Facebook server

#177

Post by s-shellfish »

gandreani wrote: post #6

Nice job! I also really appreciate the lack of memes and very concise format of this blog post

The internet IS serious business. Combining it so much with popular culture just dilutes understanding and destroys standards.

Dijkstra framed it best:

https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...

Re: Remote Code Execution on a Facebook server

#178

Post by Deathmax »

anonu wrote: post #175
gandreani wrote: post #6

Nice job! I also really appreciate the lack of memes and very concise format of this blog post

totally agreed. my only pet peeve was the DD.MM.YYYY date format at the end of the post. Who does that?

Outside of the US, very few places use MM/DD/YY. https://en.wikipedia.org/wiki/Date_format_by_country

Re: Remote Code Execution on a Facebook server

#179

Post by mattrobenolt »

Hey, developer of Sentry here. We're submitting a patch that prevents showing any settings on this DEBUG page.

I'd like to mention that we never suggest running Sentry in DEBUG mode, nor do we document how to do this. Sentry does use Django, so it's pretty easy to put pieces together and figure out how to do it.

So while we can help obfuscate this specific issue, running in DEBUG mode always has the potential to surface insecure information due to the nature of it.

Our patch to suppress this information entirely can be found here: https://github.com/getsentry/sentry/pull/9516

Re: Remote Code Execution on a Facebook server

#180

Post by sterlind »

tptacek wrote: post #158
sterlind wrote: post #156

Earlier quoted context omitted.

Do you know the rest? That seems pretty damning. The researcher followed the bug bounty rules to the letter and Facebook applied a different set of rules, then intimidated his employer. It's also duplicitous for them to claim his bug as inconsequential, and his access as a huge privacy violation. If Facebook wanted to discourage pivoting access, they should have clearly stated so as Google and Microsoft have.

The researcher did not follow the rules to the letter. They found an in-scope RCE vulnerability, then dumped and saved the filesystem contents and used them, after reporting the bug , to compromise Facebook's AWS configuration. You would get in trouble for doing that even on a contracted penetration test, let alone a bug bounty. To make matters worse, the researcher did all this in a fit of pique about not being awar…

The researcher's blog contains a reasonable rebuttal of Alex's write-up:

>In the case of Facebook, the rules can be seen at https://www.facebook.com/whitehat. There is no rule which states what to do when a vulnerability is discovered, but there are several which imply that my testing was valid. These include: Report a bug that could ... enable access to a system within our infrastructure Remote Code Execution Privilege Escalation Provisioning Errors

We both agree the initial RCE was in-scope. The researcher reported the RCE immediately, then reported the privilege escalation by weak user passwords, then reported the API key escalation.

Moreover, you're factually incorrect about the "fit of pique." The researcher stopped poking around immediately after receiving the email; he simply continued before Facebook contacted him. When Alex said,

Please be mindful that taking additional action after locating a bug violates our bounty policy.

There was no reference whatsoever to that policy in the official Bug Bounty guidelines. Alex fibbed. Indeed, how is a canonically "in-scope" privilege escalation supposed to work if researchers are to stop at the first bug?

Lastly, if Facebook's idea of defense-in-depth is a master API key to all Instagram S3 buckets, accessible from a simple diagnostic panel, any bug bounty program is merely window-dressing.

Post reply on HN