My friends all hack Porsches—I must make amends.

For four months, Mercedes-Benz lost control of critical private data—including designs, security keys and source code. The culprit was a single developer who accidentally published a GitHub token in some public source.

That’s right: The data was stored in a GitHub repo unprotected by 2FA. In today’s SB Blogwatch, we wonder just how much trouble that dev is in.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Catalan Numbers.

Oh, Lord

What’s the craic? Carly Page broke the story—“Mistakenly published password exposed Mercedes-Benz source code”:

“Customer data”
Mercedes-Benz accidentally exposed a trove of internal data after leaving a private key online. … This token — an alternative to using a password for authenticating to GitHub — could grant anyone full access to Mercedes’s GitHub Enterprise Server, thus allowing the download of the company’s private … repositories.
…
The exposed repositories contained Microsoft Azure and Amazon Web Services (AWS) keys, a Postgres database, and Mercedes source code. It’s not known if any customer data was contained within [them]. Mercedes declined to say whether it is aware of any third-party access to the exposed data, [citing] unspecified security reasons, … or whether the company has the technical ability … to determine if there was any improper access.

PR spoke sounds sus. Pierluigi Paganini critiques the flack’s mumbo-jumbo—“Mercedes-Benz Accidentally Exposed Sensitive Data”:

“It remains unclear”
Mercedes spokesperson Katja Liesenfeld confirmed that the company “revoked the respective API token and removed the public repository immediately. … We can confirm that internal source code was published on a public GitHub repository by human error. … The security of our organization, products, and services is one of our top priorities. … We will continue to analyze this case according to our normal processes.”
…
Your sentence is well-written. However, for a slight improvement in clarity, you might consider the following revision: The investigation into the breach revealed that the token had been exposed online since late September 2023. However, it remains unclear whether other actors gained unauthorized access.

Horse’s mouth? Lohit Aravindan M. says it “Sparks Major Security Concerns”:

“Extremely serious”
We identified a GitHub token leaked by a Full Time Employee at Mercedes. … The compromised information included Database Connection Strings, Cloud Access Keys, Blueprints, Design Documents, SSO Passwords, API Keys, and Other Critical internal information.
…
The severity of this issue cannot be overstated, emphasizing the critical need for swift and comprehensive remediation efforts. … Delving into this source code could expose highly sensitive credentials, creating a breeding ground for an extremely serious data breach.

Here we go again. Use a proper credential store, rather than hiding keys in plain text! jamesrr39 suggests why this keeps happening:

Just guessing as an outsider, but it’s a big, conservative car company trying to do software development. Reasons could include:

• • Too much red tape/risk assessments/effort/time required to set up a credential store.
  • Devs working there may not know/understand the importance of it, and may not be up-to-date with modern software development practices.
  • Assumption that Github repo will always be private, correctly configured, never leaked.
  • Assumption that employee computers with code checked out will always be full disk encrypted and source code never read by a malicious program.

A credential store such as? ctilsie242 gives us a clue:

Stuff like Git tokens need to reside in a PAM, be it Hashicorp Vault, Thycotic/Delinea Secret Server, or some form of secured storage. Something that uses a HSM and has hardware protection, as well as solid authentication to whatever key:value pairs that are needed.
…
I have seen devs try to obfuscate these tokens or store them somewhere odd, like fetching them from a hidden Web server, but all an attacker needs to do is read the source code, find where the keys are, and go from there. With a PAM, even with the source code in Git, there is still the need to authenticate as the app somehow.

GitHub considered harmful? As jruohonen explains, it’s just the symptom of a wider problem:

We never learn. I wonder how many AWS buckets are still open, with or without GitHub leaks?

Tale as old as time? giuntag calls it, “The woe of modern development”:

The problem is that the issue is systemic, and it is disingenuous to blame it on developers. … A similar thing happened at company I was working for, which took pride in making its software Open Source: A dev commits an AWS key to a public github repo, and the next thing you know is you’re hit with a $50K bill of EC2 instances mining bitcoin.

Weird security disclosure method, though? As riedel explains, German law can get in the way:

It is … kind of a smart move if you do not want to pay for a lawyer and there is no bug bounty program with T&Cs: Journalists can protect their sources. However, you then somehow need to make sure that they waive potential hacking charges.

Still, panic over. Because Merc revoked the token, right? Right? mick232 eyerolls furiously:

Sorry Mercedes, but that’s not enough. The repository contained further “connection strings, cloud access keys, blueprints, design documents, … passwords, API Keys.” All of these will have to be changed, unless it can be proven that nobody accessed the repository.

Meanwhile, notso411 is not so happy with the researchers:

And they didn’t leak it. Bloody do-gooders. I want my heated seat unlock.

And Finally:

Sophie Maclean’s back to bend your brain again

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi, @richij or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: Marcel Strauß (via Unsplash; leveled and cropped)