Many transgressions come from "very large companies that have robust security teams":
Despite more than a decade of reminding, prodding, and downright nagging, a surprising number of developers still can't bring themselves to keep their code free of credentials that provide the keys to their kingdoms to anyone who takes the time to look for them.
The lapse stems from immature coding practices in which developers embed cryptographic keys, security tokens, passwords, and other forms of credentials directly into the source code they write. The credentials make it easy for the underlying program to access databases or cloud services necessary for it to work as intended. I published one such PSA in 2013 after discovering simple searches that turned up dozens of accounts that appeared to expose credentials securing computer-to-server SSH accounts. One of the credentials appeared to grant access to an account on Chromium.org, the repository that stores the source code for Google's open source browser.
In 2015, Uber learned the hard way just how damaging the practice can be. One or more developers for the ride service had embedded a unique security key into code and then shared that code on a public GitHub page. Hackers then copied the key and used it to access an internal Uber database and, from there, steal sensitive data belonging to 50,000 Uber drivers.
Uber lawyers argued at the time that "the contents of these internal database files are closely guarded by Uber," but that contention is undermined by means the company took in safeguarding the data, which was no better than stashing a house key under a door mat.
[...] Researchers from security firm GitGuardian this week reported finding almost 4,000 unique secrets stashed inside a total of 450,000 projects submitted to PyPI, the official code repository for the Python programming language. Nearly 3,000 projects contained at least one unique secret. Many secrets were leaked more than once, bringing the total number of exposed secrets to almost 57,000.
[...] The credentials exposed provided access to a range of resources, including Microsoft Active Directory servers that provision and manage accounts in enterprise networks, OAuth servers allowing single sign-on, SSH servers, and third-party services for customer communications and cryptocurrencies. [...]
Also included in the haul were API keys for interacting with various Google Cloud services, database credentials, and tokens controlling Telegram bots, which automate processes on the messenger service. This week's report said that exposures in all three categories have steadily increased in the past year or two.
The secrets were exposed in various types of files published to PyPI. They included primary .py files, README files, and test folders.
[...] There are no good reasons to expose credentials in code. The report said the most common cause is by accident.
(Score: 0) by melyan on Saturday November 18 2023, @12:10AM
Ego motivation blinds them.
(Score: 3, Funny) by crafoo on Saturday November 18 2023, @01:01AM
you know who I'm talking about. what could go wrong? Those ex-contractors for Boeing's flight control computers had to go get new work somewhere.
(Score: 4, Insightful) by SomeGuy on Saturday November 18 2023, @02:17AM (2 children)
In totally unrelated news, developers cant seem to get enough time or resources to code things the right way, because it would hurt their higher-up's huge bonuses. When shit hits the fan, put the developers through the jet engine. Even bigger bonuses for increasing security by getting rid of those "sloppy" coders!
(Score: 2) by Opportunist on Saturday November 18 2023, @11:10PM (1 child)
In even more unrelated news, managers hire the cheapest code monkeys instead of developers who "code" by copy/pasting from Stockexchange where security isn't even an afterthought.
(Score: 2) by gnuman on Tuesday November 21 2023, @09:10PM
In even more unrelated news, devs are suppose to do 10 things at a time because there is never a budget for anything... I remember hardware supplier begging us, a much smaller company, to help with enablement of their hardware because they have no resources to do it themselves.... and we also can't hire anyone because *reasons* and do more with less... blah blah...
And this reflects pretty much any business out there with exceptions of some monster FAANG companies who can choose and pick what they support or not. Mostly not.
(Score: 4, Insightful) by driverless on Saturday November 18 2023, @08:39AM (8 children)
In some cases this is due to laziness but in others it's because a lot of the time you need to hardcode credentials in order to automate a task. Without hardcoded credentials, half the Internet would grind to a halt. So, how do you fix this?
And before anyone jumps in with their favourite buzzword solution, anything that boils down to hardcoded credentials but with an additional level of indirection somewhere doesn't count.
(Score: 2) by kazzie on Saturday November 18 2023, @09:11AM (2 children)
I was just wondering this, too. The only idea I could think of was to put the credentials in a file that is blacklisted from git syncronisation, but that's a slip-up just waiting to happen...
(Score: 4, Insightful) by driverless on Saturday November 18 2023, @12:43PM
Even if you do this and don't slip up, the fact that the Magic Thing that makes everything work will be missing means, if the code is public, you're going to get a million support requests complaining that it doesn't work. So it's not just a case of making sure the Magic Thing isn't uploaded, you need a mechanism to know about and install someone else's Magic Thing in order to make it work. And if they fork the repo and their own Magic Thing ends up embedded in it followed by a PR...
One possibility here is for each type of credential-consuming system to publish test credentials that get you access to a no-op account, usable for testing but nothing else. That'd fill the "insert credentials here" hole while also making it obvious to anyone using them that they need to replace them with their own credentials. And security scanners could check for the test credentials and warn about public repos containing non-test credentials.
(Score: 2) by ledow on Monday November 20 2023, @02:47PM
No you put the credentials in a permissioned file outside of the working projects - even on a network path.
If it's not in the git tree, it can't get commited.
If it's not readable, it can't get committed even if it somehow gets added.
If it's on a network device, the code to read the credential will not work outside your development environment.
In your production environment you can have the same setup, but with a different set of keys.
It's all just carelessness - designing "security" into the system as an afterthought after everything else is written, trying to go back and review that code later, trying to cleanse it of privileged information of references.... NO. Stop.
Just design it from day one so that coders have a secure repository location that's NOT accessible outside, is PERMISSIONED correctly and CANNOT be committed by any source-code control program (have git binaries always run as a particular user/container and prevent any access from that container to the credential repository), and where explicit code has to be written to pick up the credentials. A system firewalled, audited, monitored, etc. to protect those credentials. Where the credentials can be short-lived and expire and updated regularly by the people responsible for securing them WITHOUT AFFECTING ANYONE.
You can't bolt-on security to a system that was designed insecurely. It's like trying to put a bank vault door on a garden shed.
Programmers should not be let anywhere near, have access to, or be responsible for managing tokens, API keys and credentials like this. They have code, that code picks up from the credential storage, and someone manages development/production/etc. so it all "just works". But then you absolutely put in alerts, blacklist, notification, permission denial, etc. to ever commit any kind of token, or operate any kind of hand-crafted code that connects to services. Literally guard against all uses of the function that connects, so that the only valid way to do so is to include the corporate headers that strictly use only credentials gained legitimately from the system you've put in place (so programmers can't just "hardcode" a test key into their code without triggering all kinds of problems for themselves).
If you don't treat your code security like you would in a basic military cybersecurity department, then your system is going to be insecure and fail.
And security is, always has been, and will always be "inconvenient". That's literally by design. Stop letting your programmers work around that.
(Score: 3, Interesting) by looorg on Saturday November 18 2023, @12:26PM
I think we all done that one more often then not, hardcoding in the account and password to some db etc. It's the easiest and fastest solution.
Some cases? I would think it's in almost all cases. People are lazy and lax and are sharing or storing way to much things on Github, and similar sites, and just not thinking about it. To much sharing. Instead of doing something and then if you share it you have to go thru it all, pack it and up and put it up someplace. More care, but not much more, sort of went thru it before. Now you have more or less automated the task so people just don't even think about it. Just send it to the repository for all to see.
(Score: 2) by stormreaver on Sunday November 19 2023, @10:27PM (3 children)
How about a credentials server? It would record the login credentials for all the accounts needed for a requesting server's IP/MAC combination, so the requesting server wouldn't need o hardcode credentials. The requesting server would say, "I need the login for service X", and the credentials server would return all the login information needed for that service.
(Score: 2) by stormreaver on Sunday November 19 2023, @10:46PM
Forget about the MAC address, as that's not accessible to the credentials server. But the general idea is to tie the request to something keyed to the requesting server that resides outside any developer's code repository. An LDAP for credentials, that doesn't require credentials to access, but that can be access restricted.
This isn't my area of expertise, so I'm just throwing it out to see if it's feasible or not.
(Score: 2) by driverless on Sunday November 19 2023, @11:54PM (1 child)
That's the one-level-of-indirection solution. It invariably ends up as some sort of homebrew candy machine system that hands out credentials to anything that asks for them.
Or we could get someone like the IETF to standardise the process, meaning you'd either get told that the perfect solution, $auth-buzzword-du-jour, already exists and you need to change all your systems to use it, or after five years effort someone comes up with a standard that requires all of IPsec, TLS, X.509 certificates, XML, YAML, MQTT, SOAP, and OAuth in order to hand out a password, and it'll be rewritten every 1-2 years because the current version is never cromulent enough.
(Score: 2) by stormreaver on Monday November 20 2023, @01:23PM
Yes it is, and there is no way around the problem without one level of indirection.
It hands out credentials to specific services on specific devices that have pre-registered to receive them.
(Score: 2) by gnuman on Sunday November 19 2023, @07:49PM
after I uploaded a private RSA key to github. Got email. Though it was just a unit test :P