Hacker News Reader

Comment by cyberferret | Hacker News Reader

Ok, so the breach was via an employee's Github account that wasn't secured with 2FA. I understand that would have given them access to the source code for 8tracks, but HOW did they get access to database credentials?? I would have assumed best practice would dictate that database server IP addresses and access credentials would have been in a configuration file that is NOT checked into version control??

Most companies go to great lengths to extract credentials, keys and other sensitive information into some sort of environment file, don't they?

Unless they had a copy of their database in text/JSON/XML format uploaded to version control as well??

View on HN

> However, it did allow access to a system containing a backup of database tables, including this user data.

Sounds like they store backups with git and push them to GitHub (presumably Git LFS). Someone should tell them that Git is not a backup solution. It's also possible they were using some backup service that uses GitHub SSO (not sure if that's better or worse).

It's good to see they finally took advantage of GitHub's feature that restricts user access to an organisation if they don't have 2FA. Every organisation should enforce that.

The backups could have been stored in a system protected by github SSO perhaps.

Ah, I hadn't thought of that. Makes sense that this could have been the case.

8tracks could have a backup system that uses Github as the identity provider, the backup data wouldn't have to reside in a repo on Github. As a PSA to others using Github organizations and allowing login via Github, there is a setting you can turn on to require MFA for all the members of the org.

https://help.github.com/articles/requiring-two-factor-authen...

They don't explain exactly how, but yes the attacker did find a database backup. Apparently the production systems were not accessed.

FYI, you can limit access to repos to accounts that have 2FA enabled. I'm encouraging clients to enable that option. Users can't accept an invite to the repo until they turn on 2FA.

It's perfectly reasonable to put your credentials and configuration into a VCS if any secrets are in ansible vault or something similar.

I reckon they either stuffed it all in as plain text or someone got hold of their source code and found a stupid hole in it and just read the database file off the front end somewhere. It's not unusual for the unclued to stick a database dump on a front facing web server with a "secret url" and just pull that down with curl or something.

It's really never reasonable. Even if your VCS is already secure, inserting credentials means bringing it up to spec with actual credential storage policy, even if that means inconvenience to the developers - and if it's not inconvenient, your policy is probably too lax in the first place. There should be a total separation of concern between your code and user credentials.

Ansible vault, separate repository to the code and you're fine. You're up shit creek if you lose your code too unless you're 100% perfect so there is no distinction in policy.

Hell if you're using vault you might as well chuck the config in with the code. The vault key distribution is what needs to be controlled.

There is a real difference in company impact between leaking your code and your credentials. If your code and credential policies are the same, your company has a serious problem of priorities, since it's either not protecting credentials enough, or it's slowing down developers too much.

The trick is to make sure that if the credentials do leak they are useless.

I have never seen a company that didn't store some credentials in their VCS.

To the point where you see weekly TIFU /r/cscareerquestions post on a junior using training material and then accidentally trashing the production db.

That doesn't happen because you don't let them have the credential vault keys. In fact no humans get them; just the build and deployment pipeline.

Reply on news.ycombinator.com