How I Hacked Facebook’s Secure Files Transfer Service for Employees
nirgoldshlager.com
nirgoldshlager.com
1) Identified a badly protected side entrance to use rather than the front door
2) Painstakingly researched the third party product (similarly one could investigate a third party library used in a bespoke codebase)
3) Figured out the adaptations the target organisation had made to it and guessed some mistakes they'd made
4) Eventually hit on a cookie modification attack made possible by limitations found in that publicly-available codebase.
Smart.
Does he just mean "this version doesn't have a readily available dissassembler yet"? Even if they chose the path of compiling to native code, if you own the box, it can't be that hard to get the code.
I'm also curious if there's a way to dump 'disassembled' PHP after it's been loaded into the PHP processor. If it's going through eval() at the end, then shouldn't the plain-text source be available in a string somewhere?
Figuring out the encoding scheme is probably a lot of boring disassembly work, which in the end just lets you decode a bunch of PHP opcodes which themselves would take a lot of work to make sense of.
But perhaps the Vulcan Logic Dumper could help out a little bit. http://derickrethans.nl/projects.html#vld
'Still alive these day?'?
It's useful for what it does, always has been, never been a security feature.
People unfortunately have used it as a security feature in the past.
Anyway, I have seen sites where it was used as a security measure. Or so the authors thought I guess. Storing login password in url parameter? Seems safe if it is encoded.. But it was years ago.
Both ; and = are perfectly valid.
There's nothing wrong w/ base64 encoding; however, one needs to apply it to the correct context like applying it to: hashes, avoid text collision/escaping chars, or just embedding plain old non-sensitive binary data in text.
It's very easy to Google and see tons of sites using it. Many sites using it got serous security flaws.
Surely it is cheaper to buy an off-the-shelf solution, instead of spending a lot of money on wasting engineering time building and supporting a product that is not core to their mission.
What is this "Password Recovery" page? Is this for emailing a person a reset link to a password? Is it for changing your password? What is the cookie used for? What is the flawed logic in the system?
Can anyone explain this more clearly please?
How you should just "take the hit" (the cost is trivial) and store a randomly generated nounce in your database rather then do shenanigans like encoding user information in the url with secrets and bad cryptography and what not.
See? We listen! :)
1) user creates account (which generates nounce)
2) when password resetting via email auth via nounce.
3) when password is reset regen nounce
Is that right? Just trying to better understand what appears to be a good approach to password resets.
I got it from a quick 'password reset' search here, I recall a lot of these discussions, if you're curios click around on a few more results. :)
I was under the impression that best practice was a link with a randomly generated key that has an expiration date (and is expired as soon as it is used). The only security hole here is if the email is intercepted (and you've got other problems at that point).
the implicit (worse) alternative is that you encrypt or sign additional state in the url (and in this case, base64 was the "encryption").
> It seems that Facebook was trying to avoid the creation of accounts in Accellion after removing the register form from the pageview
> I discovered that if you know the direct location of the form (/courier/web/1000@/wmReg.html), You can easily bypass that protection and create an account in files.fb.com,
Once he created his own accounts, he could test out his exploit code on his created accounts.
hrm?
O_o