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

1–10 of 207 posts

Re: Remote Code Execution on a Facebook server

#2

Post by exikyut »

So, this was simply taking advantage of a crash-prone webapp running on a debug-enabled Django instance using Pickle session serialization, and more specifically this was only possible because _Django didn't redact the stored secret key used to sign serialized inputs out of the crashdump information!_

Did the author tell Django about this yet, or is this a (possibly unintentional) 0-day?

Besides the above interestingness, the morals of this story I get are

- Stay persistent and leave your scanners running; you never know what new things will turn up.

- Crashdumps _are_ interesting

- Yay, $5,000!

- Middleware and frameworks will always clash in useful and interesting ways?

Re: Remote Code Execution on a Facebook server

#3

Post by ch0wn »

exikyut wrote: post #2

So, this was simply taking advantage of a crash-prone webapp running on a debug-enabled Django instance using Pickle session serialization, and more specifically this was only possible because _Django didn't redact the stored secret key used to sign serialized inputs out of the crashdump information!_ Did the author tell Django about this yet, or is this a (possibly unintentional) 0-day? Besides the above interesting…

If I remember correctly, Django only shows these information if left in debug mode. Needless to say, this should never be used in production.

Re: Remote Code Execution on a Facebook server

#4

Post by acidburnNSA »

exikyut wrote: post #2

So, this was simply taking advantage of a crash-prone webapp running on a debug-enabled Django instance using Pickle session serialization, and more specifically this was only possible because _Django didn't redact the stored secret key used to sign serialized inputs out of the crashdump information!_ Did the author tell Django about this yet, or is this a (possibly unintentional) 0-day? Besides the above interesting…

Django is pretty serious about warning you of the risks of this [1]. I think in this case the key was in some third party options variable so the bug is there. The sentry thing sounds like an internal bug to Facebook rather than a django issue.

[1] https://docs.djangoproject.com/en/2.1/topics/http/sessions/#...

Re: Remote Code Execution on a Facebook server

#5

Post by Alex3917 »

In contrast, I submitted a bad vulnerability in Facebook’s password reset feature yesterday that lets attacker’s send password reset PIN numbers to email addresses the user doesn’t necessarily control. The security team said to works as designed so they’re not going to fix it.

Basically if someone requests a password reset on your account then the PIN number gets sent to all email addresses associated with your account, not only the primary one. This is an issue because many people have one locked down email address for things like registering accounts, but others they use to talk with people, delegate to their staff, use with CRM apps, etc. (But you still need your everyday email addresses linked to your account so that people can find you by email, see your email on your profile, etc.)

The FB security team just says that delegating your email address isn’t secure so it’s not their problem. Like no shit, that’s why it’s a vulnerability. But for some reason the FB security team thinks it’s a good idea to let anyone immediately bypass 2FA and hijack your account.

Re: Remote Code Execution on a Facebook server

#10

Post by ssebastianj »

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!

Luckily, Django provides checks to avoid this kind of leakage before hitting production with https://docs.djangoproject.com/en/2.1/howto/deployment/check...
Post reply on HN