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.
Remote Code Execution on a Facebook server
181–190 of 207 posts
Re: Remote Code Execution on a Facebook server
#182Earlier 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
Re: Remote Code Execution on a Facebook server
#183Earlier 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
Re: Remote Code Execution on a Facebook server
#184Earlier 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.
For sake of argument, this is pretty easy to do just by looking at job postings.
Re: Remote Code Execution on a Facebook server
#185Some 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.
https://instagram-engineering.com/web-service-efficiency-at-...
Re: Remote Code Execution on a Facebook server
#186Earlier 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…
Re: Remote Code Execution on a Facebook server
#187This 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.
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
#188Earlier 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…
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
#189Earlier 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.
Re: Remote Code Execution on a Facebook server
#190Earlier 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…
You've changed my view.