Live data from Hacker News

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

blog.gitguardian.com

241–250 of 272 posts

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

#241
post #83

Earlier quoted context omitted.

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...

Sounds like a quick trip to getting fired?

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

#242

Earlier quoted context omitted.

Awesome feature. Saved the day for us some months back when an AWS token was accidentally committed and pushed. (AWS itself also immediately notified us.)

Rant time: this isn’t directed at you. I am just replying to your comment because you said something that triggered me. Also the “you” below is the generic you - not you personally. Disclaimer: I work at AWS in Professional Services, all rants are my own. Now with that out of the way, I hate the fact that there are way too many code samples floating around on the internet that have you explicitly put your access key…

100% agree. We always keep all tokens (not just AWS secret keys) in a separate file that is never checked into the repo and are passed into the CloudFormation template at deployment. (The error in this case was a new repo hastily pushed and .gitignore wasn't properly updated to exclude the file with the keys.) But we've since switched to using AWS Secrets which is a much better solution.

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

#243

Earlier quoted context omitted.

Rant time: this isn’t directed at you. I am just replying to your comment because you said something that triggered me. Also the “you” below is the generic you - not you personally. Disclaimer: I work at AWS in Professional Services, all rants are my own. Now with that out of the way, I hate the fact that there are way too many code samples floating around on the internet that have you explicitly put your access key…

I deal with this by having a directory in my development tree, named ”doNotCheckThisIntoSourceControl” , and I add a wildcard of it to my global .gitignore. I’ll put things like server secrets and whatnot, there. Of course, I need to make sure the local directory is backed up, on this end, since it is not stored in git. Works a treat.

Try AWS Secrets

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

#244

Earlier quoted context omitted.

Rant time: this isn’t directed at you. I am just replying to your comment because you said something that triggered me. Also the “you” below is the generic you - not you personally. Disclaimer: I work at AWS in Professional Services, all rants are my own. Now with that out of the way, I hate the fact that there are way too many code samples floating around on the internet that have you explicitly put your access key…

100% agree. We always keep all tokens (not just AWS secret keys) in a separate file that is never checked into the repo and are passed into the CloudFormation template at deployment. (The error in this case was a new repo hastily pushed and .gitignore wasn't properly updated to exclude the file with the keys.) But we've since switched to using AWS Secrets which is a much better solution.

Yeah that’s not good either. Your keys never need to be in a local file. Just put them in Parameter Store/Secrets Manager and you can reference those values in CF.

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

#245

Earlier quoted context omitted.

I don't think it is flawed. You cannot access org's repos without VPN if you create a new repo by mistake outside your org, then uhh..., it's crazy? it's like sending email with credentials to people outside your org

On github.com you don't need VPN to access your org's repos. You're referring to github enterprise (the self hosted version).

I do use github.com and I cannot access some repos unless I connect to VPN

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

#246

Earlier quoted context omitted.

> Note: the invite input box actually autocompletes ALL github usernames. I'm sorry, but that's wild. That's like, not even an easy engineering problem to solve necessarily, given their size!

Sorry, but string prefix search over a few hundred million entries is something you can do with the same performance using just postgres on a single server with just a few hours of dev time. I've done it before, it's not as impressive as it seems. With trigrams you can even do precise substring search on this scale with good performance. If you'd like, I can build a small demo.

Lol no thanks, once you hit the server I’m good, it’s more about the UI for me.

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

#247
post #9

The access model on platforms like GitHub is flawed, a single account can be used for both professional and personal projects/repositories, leading to “fat finger” errors like this one here...

Oh yes this. It's so easy to critically fuck up an invite into an organisation. If you get typo the username you are potentially compromised. I've seen a couple of near misses on this already. Note: the invite input box actually autocompletes ALL github usernames.

Org can be configured with SSO which would require Org members to login with your Co auth in order to access the Org.

Though it would still allow "collaborators" which don't have SSO requirement.

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

#248

Earlier quoted context omitted.

Awesome feature. Saved the day for us some months back when an AWS token was accidentally committed and pushed. (AWS itself also immediately notified us.)

Rant time: this isn’t directed at you. I am just replying to your comment because you said something that triggered me. Also the “you” below is the generic you - not you personally. Disclaimer: I work at AWS in Professional Services, all rants are my own. Now with that out of the way, I hate the fact that there are way too many code samples floating around on the internet that have you explicitly put your access key…

No post body was provided.

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

#249
post #88

Earlier quoted context omitted.

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?

You can't enumerate DNS entries. (And not even privately: some of our (DNS) entries are wildcards, CNAMEs, etc. all make that hard.)

We do (now) follow the CT logs for ourselves. That catches some cases, but not everything.

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

#250
post #101
post #96

Earlier quoted context omitted.

Everyone complains about post-it notes, but the physical proximity requirement to read them isn't nothing. E.g. compared to network-accessible files. At least, until you have a network-attached webcam pointed at your whiteboard. But the solution to the webcam problem is to write its access credentials on your whiteboard, thus forming a circular and perfectly secure loop.

Just stick an Amazon t shirt on, a reflective yellow waistcoat and a box and you can walk into most SMEs without anyone blinking an eye. I've seen it done hundreds of times...

Why would you have seen it done 100s of times. Are you a professional thief?
Post reply on HN