It's also interesting that Facebook developers are using Pastebin for things such as this. I would assume that they'd have an internal wiki, or gist-like app.
It's also noteworthy to see how they set up their accounts: first initial, full lastname—same standard as many other companies. But seeing it laid out can help in the guessing of other names (or common name occurances, as you don't even need a full first name).
While some leaks may not even be effective outside Facebook's internal network (things such as database credentials, network shares… hopefully), having actual code that may be in production does pose a risk. The possiblity to see where, for instance, data isn't fully sanitized, or where information being fetched might not require proper authentication[1] is more worrying. Facebook is known for promoting "move fast and break things". Hopefully they have good QA and SDET teams to catch these things.
[2] One code snippet features the following:
> // TODO: add privacy checks!
I'm not surprised they don't have a gist/pastebin like app. When I interned at Amazon this summer, they were just developing one, and it was still pretty alpha (persistence was buggy and lost me an entire design review of notes). Facebook is younger, so it seems fair that they don't have one.
Speaking of the TODO, I particularly liked how the diff suggests removing it ;-) That said, it did appear to be some kind of "enterprise" version maybe?
We have an internal pastebin, it's built into Phabricator.
There is no preset format for unixnames. Most people use their names but I've seen many pseudonyms. One intern famously broke some internal tools by requesting her initials, which were "www".
Pastebin has TONS of stuff lying around, it's pretty fascinating. I've always wanted to spend some time digging around there, but haven't gotten around to it.
even if they have 2-step auth setup, people choose "complete the email address" as a form of authentication which you can most likely get from their github profile.
the moral of the story here is - if you do not want someone to find it - do not publish it online
I understand you're just showing how easy it is to find email/password combinations, but maybe it isn't the best idea to post an example link on how to do it?
Shoot. I guess I shouldn't post the advanced search I just tried. Let's just say I had 12,875 search results for a common CMS' configuration files ... it was scary how easy it was, actually, to filter the results down to what I was looking for. Github ought to put up a warning saying, "you have a wp-config.php file, you know this is public right? Here's how to use .gitignore" and a link, or something.
Im not a hacker/cracker or whatever but I am curious would it be illegal to use one of those usernames and passwords to see if it actually worked for an account?
edit: I know that it is not ethical and I am only slightly tempted to do it but is it actually illegal to use open source code in that way?
Depends on the jurisdiction, but generally yes it'd be illegal.
You can compare it to opening someone's home because he left his key in a public place unbeknownst to him.
You generally couldn't make the argument that 'he may have wanted people to have the key, that's why he left it in a public/open source place'. Firstly, one can't assume that, so we must hear it explicitly before it's true. And secondly, if universal open-source access was provided, there wouldn't be a key to find as there wouldn't be a lock in the first place to allow specific access. The whole point of a password or key means you do not want fully open access to all, meaning any password or key in an open-source project is likely unintentional, a mistake, and thus you'd be entering without permission which is illegal in most jurisdictions.
I'd say this crosses the line, in a day and age where using CURL can land jail time (e.g. AT&T "leak"). Guessing a password doesn't legally grant you the right to enter a server, either. That'd be like saying you had a right to trespass because someone left the gate open or didn't build it high enough. It doesn't work that way. I really think Github needs better protections for this. Consider a search for "export GITHUB_SECRET" ;-)
Yeah it's crazy. Just last week I caught myself just in time. I was developing an API for this website and was testing the user login with my own credentials which I saved in a variable so I wouldn't have to retype it all the time as I tested API login functions. I finished some things and pressed the 'commit' button (commit plugin in Brackets ftw) but cancelled it when I realized I was committing an admin credential to a public repository. The next step would've been to push it.
Reminds me of a story where a hosted bitcoin wallet was open-sourced right after they shut down. It was completely uploaded to github, including credentials that indirectly allowed access to an exchange where they stored a lot of their funds. It was a stupid company ran by careless people in the first place (they got hacked 2-3 times before open-sourcing an API key that was the same as a LastPass password that held their exchange password). About $350k was stolen. ($14 million by today's standards.)
This was someone's attempt at a bitcoin public challenge: https://news.ycombinator.com/item?id=6765801 (Get a wallet's passphrase which was the username of someone in the Hacker News top 100, minus 2 characters).
Was amused to click through and see it was my username involved.
Mostly as I gave up ever trying to do anything with Bitcoin because I simply can't get my head around any of the practicalities, lol, so it definitely wasn't anything of mine! ;-)
Tangentially related, I'd like an opinion on this:
>Okay, so it's not the most secure password. But Facebook's database servers are heavily firewalled. Though if you do manage to break in to Facebook's servers, there's the password.
What is the point on even having a database password? The application itself needs access to the database, so the application needs to know the password.
That means that an attacker who gains access to the application can easily just look at the file where the password is stored and then use that to access the database.
Even if you'd go great lengths at keeping asking for the password at server start and only keeping it in memory - once an attacker is on the application server, the password is in memory and can be snooped.
So the question is: Why even use a password for the web application? In my case, I'll just let the application servers connect to the database without password.
Yes. But I'm talking about the password for the account that the web application itself is using. That one IMHO is superflous. Other access levels, of course, might require a password.
A password means you can't access the database server from a mail server or file server. Complex environments have more than just a database server and a few web servers.
Bingo. And in the MSSQL world it's common to also have Active Directory and use that for authentication (each server automatically has a unique "account", and SQL login permission can be granted using that).
>What is the point on even having a database password?
Fuck-ups happen, and an insecure password does a good job of preventing any activity that doesn't explicitly include the password.
Like, suppose you have some dev tool that does things to a database. If your local dev environment does not have a password on the db, and the application environment does, odds are your tool is going to work locally but not in the application environment.
Basically, it can be a form of "type 'password1' if you are sure you want to do things to prod".
Oracle enterprise edition had (and probably has today too) a feature to link a pl/sql procedure to a table such that this procedure is called every time a query is ran on that table.
This procedure then can apply additional predicates to the query.
When this procedure belongs to the schema that is not directly accessible to the user, then it would be possible to create a filter such that only logged in user can see the records and only her records.
Among other reasons: setting different passwords for different staging levels or databases reduces the chances of accidentally shooting yourself in the foot.
"Oh, our staging code references the prod DB password. Wups!"
Passwords can also be changed and rotated with some frequency, though that's more often observed in the breech.
I found an interesting post from "karthimx" [1] made on Jun 30, 2010.
It too contains the password "e5p0nd4". This user didn't do any hacking or googling but got this error browsing facebook. He says "Suddenly I got this error message in Facebook" (so apparently inside the production environment, wtf?).
52 comments
[ 3.5 ms ] story [ 130 ms ] threadIt's also interesting that Facebook developers are using Pastebin for things such as this. I would assume that they'd have an internal wiki, or gist-like app.
It's also noteworthy to see how they set up their accounts: first initial, full lastname—same standard as many other companies. But seeing it laid out can help in the guessing of other names (or common name occurances, as you don't even need a full first name).
While some leaks may not even be effective outside Facebook's internal network (things such as database credentials, network shares… hopefully), having actual code that may be in production does pose a risk. The possiblity to see where, for instance, data isn't fully sanitized, or where information being fetched might not require proper authentication[1] is more worrying. Facebook is known for promoting "move fast and break things". Hopefully they have good QA and SDET teams to catch these things.
[2] One code snippet features the following: > // TODO: add privacy checks!
There is no preset format for unixnames. Most people use their names but I've seen many pseudonyms. One intern famously broke some internal tools by requesting her initials, which were "www".
More like exposed implementation and/or design flaws in internal tools.
EDIT - there is - i had no clue: http://pastebin.com/api#1
https://github.com/search?p=96&q=gmail+password&ref=searchre...
even if they have 2-step auth setup, people choose "complete the email address" as a form of authentication which you can most likely get from their github profile.
the moral of the story here is - if you do not want someone to find it - do not publish it online
edit: I know that it is not ethical and I am only slightly tempted to do it but is it actually illegal to use open source code in that way?
You can compare it to opening someone's home because he left his key in a public place unbeknownst to him.
You generally couldn't make the argument that 'he may have wanted people to have the key, that's why he left it in a public/open source place'. Firstly, one can't assume that, so we must hear it explicitly before it's true. And secondly, if universal open-source access was provided, there wouldn't be a key to find as there wouldn't be a lock in the first place to allow specific access. The whole point of a password or key means you do not want fully open access to all, meaning any password or key in an open-source project is likely unintentional, a mistake, and thus you'd be entering without permission which is illegal in most jurisdictions.
Reminds me of a story where a hosted bitcoin wallet was open-sourced right after they shut down. It was completely uploaded to github, including credentials that indirectly allowed access to an exchange where they stored a lot of their funds. It was a stupid company ran by careless people in the first place (they got hacked 2-3 times before open-sourcing an API key that was the same as a LastPass password that held their exchange password). About $350k was stolen. ($14 million by today's standards.)
https://github.com/search?p=4&q=extension%3A.key+BEGIN+RSA+P...
https://github.com/Dao007forever/Linux-settings/blob/master/...
https://github.com/Dao007forever/Linux-settings/blob/master/...
https://github.com/Dao007forever/Linux-settings/blob/master/...
> the moral of the story here is - if you do not want someone to find it - do not publish it online
I doubt it's intentional. I will note that on Windows, if you're using ActiveDirectory, it's much more difficult to make this kind of mistake.
http://pastebin.com/6GeZnS9b
Mostly as I gave up ever trying to do anything with Bitcoin because I simply can't get my head around any of the practicalities, lol, so it definitely wasn't anything of mine! ;-)
>Okay, so it's not the most secure password. But Facebook's database servers are heavily firewalled. Though if you do manage to break in to Facebook's servers, there's the password.
What is the point on even having a database password? The application itself needs access to the database, so the application needs to know the password.
That means that an attacker who gains access to the application can easily just look at the file where the password is stored and then use that to access the database.
Even if you'd go great lengths at keeping asking for the password at server start and only keeping it in memory - once an attacker is on the application server, the password is in memory and can be snooped.
So the question is: Why even use a password for the web application? In my case, I'll just let the application servers connect to the database without password.
Auditing (per tool)?
Not all attackers come "through the front door"
Fuck-ups happen, and an insecure password does a good job of preventing any activity that doesn't explicitly include the password.
Like, suppose you have some dev tool that does things to a database. If your local dev environment does not have a password on the db, and the application environment does, odds are your tool is going to work locally but not in the application environment.
Basically, it can be a form of "type 'password1' if you are sure you want to do things to prod".
This procedure then can apply additional predicates to the query.
When this procedure belongs to the schema that is not directly accessible to the user, then it would be possible to create a filter such that only logged in user can see the records and only her records.
"Oh, our staging code references the prod DB password. Wups!"
Passwords can also be changed and rotated with some frequency, though that's more often observed in the breech.
Preferably not the data breech.
It too contains the password "e5p0nd4". This user didn't do any hacking or googling but got this error browsing facebook. He says "Suddenly I got this error message in Facebook" (so apparently inside the production environment, wtf?).
[1] https://forums.digitalpoint.com/threads/facebook-error-messa...
[2] http://www.zyngaplayerforums.com/archive/index.php/t-545034-... - Another one from 2010!