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

131–140 of 207 posts

Re: Remote Code Execution on a Facebook server

#131

Post by Grue3 »

throwawaymath wrote: post #74
green_on_black wrote: post #69

He got $5k for an arbitrary remote execution bug? What a rip-off.

He received $5,000 for remote code execution on a server in a separate VLAN and containing no user data. Barring another vulnerability to commit something like server-side request forgery across the VLAN, that significantly reduces the actual severity of the vulnerability. You wouldn't be able to chain this execution to impact user accounts or other Facebook servers. You also wouldn't be able to exfiltrate sensitive…

I remember the guy who broke into a Facebook server then used the information stored on that server to get onto a more important server with user data. He either didn't receive a bounty or got a reduced bounty because the server he accessed was deemed unimportant and chaining hacks is against the rules or something.

Think it was this one: http://exfiltrated.com/research-Instagram-RCE.php (actually it's even worse than I thought with Facebook threatening legal action against him)

Re: Remote Code Execution on a Facebook server

#133

Post by cat199 »

kashyapc wrote: post #66
alrs wrote: post #47

Earlier quoted context omitted.

Those kinds of titles are really tired, but clickbait is unfair. "X For Fun and Profit" can be found in g-files back to the late '80s, a time well before clicking. http://www.textfiles.com/phreak/

The point is, "for fun and profit" is such an overused and utterly boring cliché. Meaningful titles are pleasant to read and shows that the writer has put some effort to bring clarity into what they're trying to convey. (As someone who sits on a major open source conference talk panel, I cringe when I see one of these clichés slapped into the title without much thought. I politely suggest to rephrase to convey more "…

Perhaps you should start a panel -

MODCON: Revenge of the Boring Moderator

Re: Remote Code Execution on a Facebook server

#134

Post by GordonS »

Someone1234 wrote: post #29
Areading314 wrote: post #7

This is a great concrete example why you should never run debug mode on a public server. Django can only do so much for redacting private info. This is also a great example of how insecure pickle is!

I know this is going to get some jeering, but that's one nice thing about .Net's machine.config , you designate the machine itself as a non-development environment and tracing, debug output, and so on are disabled for all .Net/ASP.Net applications. That might not work for all edge cases, but broadly there's a lot of machines which are only for non-development/production code, and a system-wide setting makes you a lot…

I guess that's .NET Framework only - is there something similar for .NET Core?

Re: Remote Code Execution on a Facebook server

#135

Post by smsm42 »

Polycryptus wrote: post #129
Grollicus wrote: post #120

This is a good example why you need regular pentests in big companies. Everyone (should) know that using pickle is insecure and everyone (should) know that django debug should be False in production. Still, if the numbers get large enough someone will miss something.

The use of Pickle isn't uncommon for session cookies in Python apps, from what I've seen. Pickle isn't really a problem unless you end up unserializing untrusted data... which a sign+encrypt scheme is supposed to ensure doesn't happen. You just can't leak the secret key or you're in trouble. Though, there's no excuse for leaving Django debug on in production.

I'd say it's a bad idea anyway - why you need to trust the user with anything that needs pickle (as opposed to much more primitive format) to unserialize? If you ever have a reason for non-opaque-id cookies at all, it should be very simple. If you stuff very complex objects that require native serialization into user-side storage, it's probably bad idea regardless of security implications.

Re: Remote Code Execution on a Facebook server

#136

Post by GordonS »

tptacek wrote: post #55
srcmap wrote: post #23

Other than fixing the Django source code , is there any OS level mitigation techniques that can detect and prevent such security vulnerabilities? I am thinking something like selinux, docker or chroot - a bit like internal firewall for Django (or any other webapp). Any suggestions on the links to latest best practices?

Of course. You can lock the process down so that it can't make unexpected system calls. If you deploy in a modern container environment, you can also use container networking to drastically limit what the application environment can talk to on the network. Though it's a less potent mitigation than seccomp and container isolation (and one you get for free once you deploy in a container), you can also limit filesystem…

> You can lock the process down so that it can't make unexpected system calls

Huh, this isn't something I've ever come across before.

Off the top of my head, I guess it would be possible on Windows using a kernel mode driver, but that's pretty hardcore, and really easy to get wrong.

I know you can easily audit syscalls on Linux with auditd, but haven't seen preventing them before.

Is this an option on both Linux and Windows, and is it commonly used? Interested to know more!

Re: Remote Code Execution on a Facebook server

#137

Post by tptacek »

meowface wrote: post #90
green_on_black wrote: post #69

He got $5k for an arbitrary remote execution bug? What a rip-off.

I agree he deserves a higher payout, but it was on a segmented server that seems like it didn't have any customer data or other important data. If he were a real attacker, who knows where else he could've pivoted from this server (perhaps it wasn't quite as segmented as Facebook thought). But assuming it truly was pretty isolated, compromising it probably wouldn't have caused any damage. Regardless, I feel like he de…

Where are you pulling that number out of?

Re: Remote Code Execution on a Facebook server

#139

Post by tptacek »

Grue3 wrote: post #131
throwawaymath wrote: post #74

Earlier quoted context omitted.

He received $5,000 for remote code execution on a server in a separate VLAN and containing no user data. Barring another vulnerability to commit something like server-side request forgery across the VLAN, that significantly reduces the actual severity of the vulnerability. You wouldn't be able to chain this execution to impact user accounts or other Facebook servers. You also wouldn't be able to exfiltrate sensitive…

I remember the guy who broke into a Facebook server then used the information stored on that server to get onto a more important server with user data. He either didn't receive a bounty or got a reduced bounty because the server he accessed was deemed unimportant and chaining hacks is against the rules or something. Think it was this one: http://exfiltrated.com/research-Instagram-RCE.php (actually it's even worse tha…

That's not at all the whole story.

Re: Remote Code Execution on a Facebook server

#140

Post by TheDong »

smsm42 wrote: post #126

So, summarily we have: 1. Enabling debug mode in production 2. Running publicly-accessible app with publicly-accessible crash screens without any monitoring system noticing it's happening 3. Relying on auto-cleaning in debug facilities to sanitize security information (never works) 4. Using over-powered serialization protocol which allows for code execution for storing user-accessible data 5. Thinking that merely sig…

Note that 5 is true though. Using a secret to sign or encrypt a cookie does normally work, and it's a common practice. Usually the impact of the secret leaking is that you can impersonate anyone, not that you can run arbitrary code, but the practice of using a session secret is common and not a bad practice nor broken inherently.

3 as well I think is unfair. That isn't something facebook implemented or is relying on; it's just the default behavior of django's debug stack. That's entirely on django to do that and lull people into a false sense of security in some cases (though it also probably helps in many cases too, so it might be okay).

The real issues are 1 (leaving debug mode on by accident), 2 (not noticing 1), and 4 (which is a django issue I think, not a facebook one).

Post reply on HN