Live data from Hacker News

Remote Code Execution on a Facebook server

blog.scrt.ch

181–190 of 207 posts

Re: Remote Code Execution on a Facebook server

#181
post #127

Earlier quoted context omitted.

From the HN guidelines: Please don't insinuate that someone hasn't read an article.

To be fair, it's a hard rule to follow sometimes when someone makes it painfully clear that they didn't actually read the article.

It's not a hard rule to follow. You can just say 'The article says X'.

Re: Remote Code Execution on a Facebook server

#182
post #28

Earlier quoted context omitted.

I mean the fix is toggling a single environmental variable from True to False, on a system that isn't normally accessed by customers, so the risk is really small in rolling out the change.

Facebook deploy updates in their prod 10-20 or even more, times a day

They could deploy continuously, but deploying to PROD doesn't include minutes/hours/days/weeks/months of investigation, testing, documentation, verification...

Re: Remote Code Execution on a Facebook server

#183
post #175

Earlier quoted context omitted.

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

Im in the US - and I exclusively use YYYY.MM.DD since its the only thing that sorts properly in a filesystem

Re: Remote Code Execution on a Facebook server

#184
post #61

Earlier quoted context omitted.

Funnily enough, it is mostly .NET applications running in production that I see stack-traces from these days.

If you even know something is a .Net app then the developer is likely terrible, so it is a self-selecting sample. You don't know most of the .Net MVC apps you interact with because there's no reason to know that.

> If you even know something is a .Net app then the developer is likely terrible

For sake of argument, this is pretty easy to do just by looking at job postings.

Re: Remote Code Execution on a Facebook server

#185

Some surprising takeaways for me; Facebook uses a Django app in their infrastructure. That app was in debug mode, revealing server secrets. That app was also configured to use the Pickle based session storage, leading to one of the few serious RCE vulnerabilities in Django. I'll have to remember this next time I think an exploit scenario is too unlikely.

Facebook runs the largest deployment of Django in the world -- Instagram.

https://instagram-engineering.com/web-service-efficiency-at-...

Re: Remote Code Execution on a Facebook server

#186

Earlier quoted context omitted.

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 Privi…

Not to mention the part where he engaged the researchers boss who was completely not a part of this research.

Re: Remote Code Execution on a Facebook server

#187
post #163

This is why you (looking at frameworks) should never use a format that may contain code to store data, especially when the client has control over that data (even if signed). The same vulnerability has occurred in almost every language/framework that does this, including Rails and Java-based ones. Just use something like JSON, which completely avoids code execution vulnerabilities like this. Except of course for the…

I also don't understand why frameworks insist on returning debug data as part of the response. If you are working on something in a development cycle and need debug information, surely you have access to the server that's running in your console. I've always printed debug information there and then send the response. That prevents these kinds of leaks if the server is deployed with debug turned on.

1. Pretty formatting of stack traces and other info, including making use of CSS and Javascript. For an extreme example, consider Werkzeug which allows stack frames to be inspected interactively in the tendered stack trace.

2. There are many situations where the person who we want to see the stack trace and debug output does not have access to the console output. E.g. hosting the service internally for a QA team.

In general, it is an error often made by people who focus on security to think that security considerations always trump convenience. In fact, it is a trade off like any other.

Re: Remote Code Execution on a Facebook server

#188

Earlier quoted context omitted.

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 Privi…

Look, this is Hacker News, I know you can come up with 1,000 different random arguments for why Facebook was wrong and this guy was right. What I can tell you with confidence is that if you did what this researcher did as a contract pentester, you'd get your firm permanently fired from Facebook (or virtually any other major site you might have been testing), and would probably be immediately fired yourself. What he did was very much outside the norm for testing sites.

Remember, he didn't simply pivot. He back-pocketed credentials, didn't tell anyone he had them, and used them later to hit out-of-scope systems. Nobody is OK with that.

Re: Remote Code Execution on a Facebook server

#189

Earlier quoted context omitted.

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 Privi…

Not to mention the part where he engaged the researchers boss who was completely not a part of this research.

If you read Stamos' post more carefully, he explains exactly why he did that, and given that his alternative was to engage Facebook legal directly, the researcher should probably be glad that's what ended up happening.

Re: Remote Code Execution on a Facebook server

#190

Earlier quoted context omitted.

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 Privi…

Look, this is Hacker News, I know you can come up with 1,000 different random arguments for why Facebook was wrong and this guy was right. What I can tell you with confidence is that if you did what this researcher did as a contract pentester, you'd get your firm permanently fired from Facebook (or virtually any other major site you might have been testing), and would probably be immediately fired yourself. What he d…

Makes sense; I don't know the pentesting industry too well, nor the norms of bug bounty programs. Certainly his sort of behavior would give me the heebie-jeebies if I ran security at a firm like that. Thinking more on it, I think he was edging black hat and used the rules lawyering as an excuse for pushing past an ethical limit.

You've changed my view.

Post reply on HN