Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.gitguardian.com

Post reply on HN
Print view View original

111–120 of 272 posts

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

#111

Post by chaps »

ethbr0 wrote: post #96
gw99 wrote: post #23

Earlier quoted context omitted.

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…

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.

Heh, sometimes, sure. In a separate comment I mention a company with whiteboard passwords. What I didn't mention is that they had a glass wall that you could look into from a well-traffick'd hallway. One of the larger companies that worked at the office (not any longer) rhymes with loinbase.

Also, I no-joke heard of a company that absolutely, unironically, did the webcam thing with RSA tokens.

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

#113

Post by hnick »

crazygringo wrote: post #106
fny wrote: post #104

Is there any reason why keys don't constantly update? It seems like a service could exist where every five minutes a rotation occurs across services with decaying privileges. For example, the 5 minute old key still works, but the 10 minute woman has completely expired.

How would you update the keys every 5 min? Either you'd use an encryption algorithm that depended on a "deeper" key... or you'd fetch the new key while authenticated with, you guessed it, another "deeper" key. It's keys all the way down. Every key you use, it's your responsibility to keep it private. (Unless you want to be dealing with physical hardware dongles that generate keys, but those aren't exactly easily port…

Not exactly the same but I had to integrate with a payments API which required one call to an auth endpoint with user/password under HTTP basic auth to get an access token. The actual calls to calculate and execute payments used this access token instead as a bearer token. Those ones expired.

I'm not sure I really see the point, but I guess you could lock down the main call on another system, store the temporary token somewhere, and have the other systems use it.

As you say, you still need the top level credentials somewhere to get a new token.

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

#114

Post by tialaramex »

tough wrote: post #102
greysteil wrote: post #56

Earlier quoted context omitted.

GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you. https://docs.github.com/en/code-security/secret-scanning/sec...

Is this really expensive? We're a small startup providing API keys, to our customers.

I would imagine the main expense for you will be your implementation cost:

https://docs.github.com/en/developers/overview/secret-scanni...

Your dev team would probably be able to give that a glance and estimate the work.

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

#115

Post by kadoban »

fiddlerwoaroof wrote: post #103
greysteil wrote: post #56

Earlier quoted context omitted.

GitHub PM here. Glad that was a good experience! We work with ~50 partners (details in the link below) to notify them when tokens for their service are exposed in public repos, so that they can notify you. https://docs.github.com/en/code-security/secret-scanning/sec...

I wish I could set this up to block pushes proactively instead of reacting to pushed secrets.

You could set up something like https://github.com/godaddy/tartufo in a pre-commit hook. Not sure if github has a way to hook into the push hooks on server side, they might though.

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

#116

Post by alfalfasprout »

lumberjack24 wrote: post #3

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

Not really? You shouldn't be checking in secrets, period.

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

#117

Post by alfalfasprout »

tester756 wrote: post #4
lumberjack24 wrote: post #3

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

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

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

#118

Post by jaywalk »

gumby wrote: post #112

Why would Toyota need to have that info to provide service? We need to get PII as a liability on companies’ balance sheets to get them to take it seriously and to collect only the minim viable data.

Why would they need to have

> customer identification numbers and emails

to provide service? Seriously?

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

#119

Post by tialaramex »

deathanatos wrote: post #29
ElevenLathe wrote: post #5

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…

Pit of success. Make it so that the Right Thing™ is super easy, whereas the Wrong Thing™ is frustrating and keeps pushing people towards the Right Thing. Humans are lazy, use that to your advantage.

For example it's one line for me to configure a new machine infrastructure built to have a certificate for myservice.myorg.example, and there's a Wiki page reminding me what the line is, or I can look at lots of services which already work. If I do that, the automation happens from the outset, my service never has a custom cert or lacks monitoring, it has monitoring from day zero and its certificates are automated. I happen to really care about ACME and the Web PKI and so on - and would have gone the extra mile to do this, but I was astonished on Week One at my current employer to realise oh, this is just how everything works here, the Right Thing™ is just easier.

Does your company have a Wiki page saying how to do it wrong? After writing the page about the right way, update the bad wiki page with a link to your new page, and cross through all the previous text, or even just delete it.

If you have firewall rules or a proxy, block random unauthorised stuff. This is probably a reasonable strategy anyway. Now they come to you to unblock their "submarine" service, and before you do that's the opportunity to insist on proper certificate behaviour.

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

#120

Post by alfalfasprout »

robswc wrote: 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…

Because the importance of security isn't respected until it's too late. At any medium to large company in your team's planning process you always need to justify the business or customer impact (even on infra teams). And security related efforts are much harder to sell because the impact is a "what if" and not $$ saved, products being easier/faster to develop, or customers benefiting in some way.

Also basic security knowledge isn't screened for in hiring nor is it really taught in most orgs (aside from trainings that people skip or optional stuff).

Post reply on HN