Mistakenly Published Password Exposes Mercedes-Benz Source Code

An anonymous reader quotes a report from TechCrunch: Mercedes-Benz accidentally exposed a trove of internal data after leaving a private key online that gave "unrestricted access" to the company's source code, according to the security research firm that discovered it. Shubham Mittal, co-founder and chief technology officer of RedHunt Labs, alerted TechCrunch to the exposure and asked for help in disclosing to the car maker. The London-based cybersecurity company said it discovered a Mercedes employee's authentication token in a public GitHub repository during a routine internet scan in January. According to Mittal, 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 source code repositories.

"The GitHub token gave 'unrestricted' and 'unmonitored' access to the entire source code hosted at the internal GitHub Enterprise Server," Mittal explained in a report shared by TechCrunch. "The repositories include a large amount of intellectual property connection strings, cloud access keys, blueprints, design documents, [single sign-on] passwords, API Keys, and other critical internal information." Mittal provided TechCrunch with evidence that 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 the repositories. It's not known if anyone else besides Mittal discovered the exposed key, which was published in late-September 2023. A Mercedes spokesperson 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. Depending on this, we implement remedial measures."

MFA, and why wasn't the key passcode protected?

[Murdoch5]

The problem really isn't the key existed online, the problem is the key wasn't passcode protected. On top of that, why isn't MFA mandatory? Even if you could get the key to be accepted, you should be road blocked by a second factor, and I would go as far to use a third factor such as a password.

The argument is always users hate security, but who cares? I don't care that a user is annoyed or thinks logging on takes too long, because it's those users who leave the key in the source code, or, use OneDrive to manager files, but have the key in OneDrive.

Lazy, sloppy, unprofessional, clueless, mindless and retarded users will always have something to complain about, so just have them accept better security. It doesn't matter that submitting code, or checking it out, took 2 seconds longer for you, those 2 seconds, prevents millions in losses.

Of course being responsible you have PGP requirements on email right, to prevent phising? Let's not do a 1/2 ass job, but then realize due to laziness 98% of people (not confirmed), work like disgusting pigs.

MFA can't be used on non interactive api calls!

[Joe_Dragon]

MFA can't be used on non interactive api calls!

Re:

[Murdoch5]

That seems like a serious design flaw, if the system can only tolerate a single unprotected factor, then maybe switch platforms?

Re:

[crackerjack155]

Yes it can.

A simple example would be a phone app that starts a log in with a password, than receives a SMS OTP, sends the OTP, and finishes logging in.

Or having an API that requires a username, password, and including a digital signature signed by a crypto processor.

Re: MFA can't be used on non interactive api calls

[Tomahawk]

My app makes several thousand calls to an RDS database every second, using an AWS API key to authenticate.

Each of them required me to click "accept" on my phone...

Yes, I know there are other ways, but not all API keys can have MFA. Which is the reason we break developers fingers who check them into a GitHub repo.

Re:

[ffkom]

I hope you see how in both of your examples, an adversary has to compromise only one factor, which is the client phone/computer. True MFA requires two independently operating entities, both of which can establish a secure communication channel to the server that is tamper-proof even under the condition that the other entity has been compromised.
But yes, a lot of pseudo-MFA is going on these days, which is no more secure, but just security theater.

Re:

[ctilsie242]

This is a Git token. Basically a number that you hand over to Git, and it authenticates you. If this value is kept secure, brute forcing isn't going to happen. However, it wasn't kept secure and divulged, which gave the keys to the city.

Why wasn't this key stored in a PAM is the big thing. This key should have been stored in something like Hashicorp Vault, and then after the app authenticated itself somehow, would be able to access the key and go from there.

There is also privilege. Better to have multi

Re:

[Murdoch5]

Exactly, you're coming at the same solution from a different angle, the point is protect the living BLEEP out of the system. Accidents happen, and I'm sure we've all accidentally submitted a key here or there, but that should not bring down the security on its own. Good DevOps will catch 95% of the accidental key inclusions, but that 5% is important.

Re:

[mjwx]

Lazy, sloppy, unprofessional, clueless, mindless and retarded /quote> Ahh, I see you've met security experts in automotive design.

Re:

[Murdoch5]

Actually I have, worse than that, Military Automotive. It's funny that things with minor security implications get designed like they need world leading security in mind, and things where world-class security should be the name of the game, get the broken screen door treatment.

Let's not bother taking a look at server security, where everyone has sudo access, incorrectly configured, and where backups are a concept admins demand everyone follow, but where no critical system is backed up. (I've spent as l

The Best or Nothing

[fahrbot-bot]

Maybe it was only a really good key ... :-)

One has to be a serious fool...

[WCLPeter]

...to use their work credentials on a public site!

Seriously, what an idiot! Hell, for the place I work, I had sign a contract stating that I would use any passwords or secondary credentials used in my personal life to access company systems. I have a password system in place that I use only for work, and I never use that login / password combination anywhere 'cause I have zero desire to get sued into oblivion!

Moron...

Re:

[bleedingobvious]

...to use their work credentials on a public site!

Seriously, what an idiot!

Not what happened.

I'm curious as to why you are spouting this unrelated noise. Methinks you doth protest a little too much.

pink slip

[Tablizer]

That (ex) employee will be trading in their Benz for a Yugo.

Re:

[93 Escort Wagon]

That (ex) employee will be trading in their Benz for a Yugo.

Worse - it's a Trabant.

Re:

[bill_mcgonigle]

and a mansion in China.

'revoked the respective API token"

[mick232]

Sorry Mercedes, but that's not enough. The repository contained further "connection strings, cloud access keys, blueprints, design documents, [single sign-on] passwords, API Keys". All of these will have to be changed, unless it can be proven that nobody accessed the repository.

Re: 'revoked the respective API token"

[Tomahawk]

And the key used was "unmonitored", so good luck with that...

Re:

[ffkom]

I for one would be happy if Mercedes just built and sold cars, and not a single "API service". If I need anything requiring an Internet connection in a car, I'll gladly bring it with me when I enter the car, and I do not expect Mercedes to be involved with it, at all.

Re:

[sconeu]

Dude, that's most likely passwords/keys/whatever to internal stuff to build their automotive software.

Re: 'revoked the respective API token"

[LindleyF]

MB.OS maybe.

Time Mercedes considers a PAM service?

[ctilsie242]

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 by the application. 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. W

Re:

[coofercat]

Yeah, using a Vault would be a good start - it largely avoids the issue of keys going missing. I'm not sure it's possible in Github though - you can use Github secrets (which is sort of the same thing), which again is a good start.

Honestly though, I'm left wondering why someone the size of Mercedes doesn't run their own internal Git server on their own network and require VPNs to get to it (and then can use Vault or similar all they like). The VPN at least can require MFA, so a lost password isn't likely to

Re:

[ctilsie242]

A lot of companies do exactly this with GitHub Enterprise. Either it is on a VPN running as an appliance on VMWare or Hyper-V, or it is running as an image on AWS/GCP/Azure in a VPC. Either case, before one can access it, it takes getting past some gateways to access it.

Just using the cloud version of GitHub may work for some things, but there is a security level where GitHub needs to be moved to a private area, just as a way to keep all the scripts, bots, and other items from finding it and trying to pry

Security

[StormReaver]

The security of our organization, products, and services is one of our top priorities.

That's a lie. If they actually valued their security, they wouldn't have put their source code on a 3rd-party repository like github.

There is a reason I write my password on a post-it

[Askmum]

and glue it to my screen. So I don't fall into the problem of having my

intellectual property connection strings, cloud access keys, blueprints, design documents, [single sign-on] passwords, API Keys

be stolen online.

The woe of modern development

[giuntag]

The comments posted here so far seem to mostly agree on the moronic nature of the developer who committed the github token to the public repo.
But what about the fact that the other, private repos also contained a plethora of access tokens? Isn't it also a bad security practice?

The problem is that the issue is systemic, and it is disingenuous to blame it on developers.

Btw, 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

Re:

[Mr. Barky]

I agree with this completely... setting up proper infrastructure is quite difficult (and likely in the end will result in a different security problem). There's one more problem that I think is also quite significant: modern IDEs with git integrated actively encourage committing any changed/added file within the directory. I have seen A LOT of commits of files that should never have been added to git (e.g. files in the .vs directory). This problem seems to be in many IDEs (IntelliJ, VS Code, Visual Studio).

I wonder what we'll find...

[Petersko]

if (customer.hasWallet() && customer.allowsAnalRape()) {
      customer.getSubscriptions().addPackage(Package.HEATED_SEATS, PackageCosts.EXORBITANT);
}