Live data from Hacker News

Toyota suffered a data breach by accidentally exposing a secret key on GitHub

blog.gitguardian.com

81–90 of 272 posts

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#81
post #38

It can actually be comical just how _bad_ things can be at large orgs. Anyone have details, theories, or a book on how such inefficiencies come about? I can't speak to tech-oriented large orgs but I've worked with others and its just... I'm not shocked at all. I've seen public facing API keys in HTML, private SSH keys that do god knows what in plaintext on FTP servers... I just don't understand how they seem to care…

The reality is that most companies can't afford an IT budget it would require to implement, and then force adherence to, a standard set of best practices for much of anything.

As another commenter said, though, this is not the case in regulated industries, in the parts of those companies dealing with regulated processes, controls and data access.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#82

Earlier quoted context omitted.

Surgeons have a practiced ritual ("scrubbing") to prep for surgery. Do you practice a credential-scanning ritual before saving (committing) your code or pushing your code to a remote repo? I have git hooks to lint code syntax, but nothing for scanning for leaked credentials. Looking @ TruffleHog now, mentioned by another poster.

A nice approach, if you have sufficient control over the form of your secrets, is to prefix each secret with "MY_COMPANY_SECRET_DO_NOT_COMMIT:". Then you can add a commit hook that refuses to commit if any committed file contains that substring, etc. etc.

Great idea, but hard to enforce. Just use a scanning CLI like TruffleHog, Gitleaks, or ggshield from GitGuardian to catch all sorts of hardcoded secrets.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#83

Earlier quoted context omitted.

Add "failure to rotate TLS certs before they expire."

My company has monitoring for this, but it still seems to be a law of nature that, 1. someone adds new service/server/infra in a submarine manner 2. it goes to prod 3. the cert expires and outage begins 4. my team is asked what to do, because "we're the cert experts" 5. we add it to the monitoring So it only happens once … per service. Which isn't great. But how do you get people to slow down and do simple shit, like…

1. Clearly describe the correct process in your other process documentation.

2. Email everyone who might be involved a note about this and a link to the documentation and why it is important.

3. Next time someone ignores it, rip them and their manager a new orifice.

4. Wait for word of #3 to spread.

Might help...

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#84
post #2

"Production keys in source control" is right up there with "mistaken routing table entry" and "fat-fingered DNS config" on the list of critical company-breaking mistakes that you'd think would be easy to avoid, but aren't.

I committed my google maps api key to a public github repository recently and github immediately sent me a warning about it. The thing is, I did it intentionally. The key is used on my website and the website is served by github pages. Now, it's an embedded maps api key, there's no cost to use it, nobody can use it from a domain other than mine, and it's easily visible in the page source if someone views that, so the…

I could run your site locally with a customized host file so the referers all come from your domain. I don’t think it’s that much of a risk but I wouldn’t want to use a key associated with something that can bill me.

You could use Google actions to build your pages site injecting the api key at build time. It’s stored a repo secret rather than in code. Of course since you deploy the site publicly, the key will still be visible.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#85
post #80
post #11

Hah. Yeah. Found a bunch of ssh keys, passwords, etc for Comcast years back which turned into a shitshow when I tried to report it. Once I found the right people to talk to things got better, but the entire experience was really reflective of how bad large orgs are with security. A friend once told me he was having a hard time getting a client to take his security concerns seriously. So I went on github and found a c…

I've never had an outright bad experience reporting a security issue, but some companies definitely aren't geared up to handle reports. I found that an energy provider's API would give usage information for past addresses and eventually I think the right team got told, but it was a nightmare trying to find someone to actually report the issue to.

It's hit and miss. Sometimes they want to throw you under the bus. Sometimes they want you to sign affidavits. I've never been asked to sign an NDA or anything like that. Sometimes they threaten with criminal charges. DoJ recently released some guidance about good-faith security reporting, so it might be easier these days. Doubt that affects active litigation/prosecution or vindictive orgs, though.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#86
post #76
post #36

Earlier quoted context omitted.

You can invite by email addr, so the workaround here is only invite corporate email addresses. If the target user hasn't added their corp email to their profile then they can't be part of the org.

This is what I do but I really wish there was a better integration with auth providers and could use it for the invite. Would be nice to search my directory to type the email and confirm the name matches the email. This is what GitLab does with their hosted AD/LDAP connector. I’m in fear of mistyping something and inviting the wrong person.

So never type an email address in at all. Go to an extent email message, copy the bloke's email address, then paste it into the Github interface.

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#88

Earlier quoted context omitted.

Add "failure to rotate TLS certs before they expire."

My company has monitoring for this, but it still seems to be a law of nature that, 1. someone adds new service/server/infra in a submarine manner 2. it goes to prod 3. the cert expires and outage begins 4. my team is asked what to do, because "we're the cert experts" 5. we add it to the monitoring So it only happens once … per service. Which isn't great. But how do you get people to slow down and do simple shit, like…

Can you check with dns for new entries and check 443 for a couple weeks to see if there’s a tls cert there?

Re: Toyota suffered a data breach by accidentally exposing a secret key on GitHub

#90
post #23
post #11

Hah. Yeah. Found a bunch of ssh keys, passwords, etc for Comcast years back which turned into a shitshow when I tried to report it. Once I found the right people to talk to things got better, but the entire experience was really reflective of how bad large orgs are with security. A friend once told me he was having a hard time getting a client to take his security concerns seriously. So I went on github and found a c…

This shit happens all the time. Old school one when I was a security consultant for a bit (pre-automated pentest scammers). Medium size regulated fintech. Domain admin passwords and admin accounts were stuck on post it notes on a board in the machine room. If you went over the road to the college, asked to use the toilet, which they seemed fine with, and poked your 200mm lens out of the bathroom window you could snap…

In fact we now have even better camera lenses!
Post reply on HN