Over 10,000 Docker Hub Images Found Leaking Credentials, Auth Keys (bleepingcomputer.com) 18
joshuark shares a report from BleepingComputer: More than 10,000 Docker Hub container images expose data that should be protected, including live credentials to production systems, CI/CD databases, or LLM model keys. After scanning container images uploaded to Docker Hub in November, security researchers at threat intelligence company Flare found that 10,456 of them exposed one or more keys. The most frequent secrets were access tokens for various AI models (OpenAI, HuggingFace, Anthropic, Gemini, Groq). In total, the researchers found 4,000 such keys. "These multi-secret exposures represent critical risks, as they often provide full access to cloud environments, Git repositories, CI/CD systems, payment integrations, and other core infrastructure components," Flare notes. [...]
Additionally, they found hardcoded API tokens for AI services being hardcoded in Python application files, config.json files, YAML configs, GitHub tokens, and credentials for multiple internal environments. Some of the sensitive data was present in the manifest of Docker images, a file that provides details about the image.Flare notes that roughly 25% of developers who accidentally exposed secrets on Docker Hub realized the mistake and removed the leaked secret from the container or manifest file within 48 hours. However, in 75% of these cases, the leaked key was not revoked, meaning that anyone who stole it during the exposure period could still use it later to mount attacks.
Flare suggests that developers avoid storing secrets in container images, stop using static, long-lived credentials, and centralize their secrets management using a dedicated vault or secrets manager. Organizations should implement active scanning across the entire software development life cycle and revoke exposed secrets and invalidate old sessions immediately.
Additionally, they found hardcoded API tokens for AI services being hardcoded in Python application files, config.json files, YAML configs, GitHub tokens, and credentials for multiple internal environments. Some of the sensitive data was present in the manifest of Docker images, a file that provides details about the image.Flare notes that roughly 25% of developers who accidentally exposed secrets on Docker Hub realized the mistake and removed the leaked secret from the container or manifest file within 48 hours. However, in 75% of these cases, the leaked key was not revoked, meaning that anyone who stole it during the exposure period could still use it later to mount attacks.
Flare suggests that developers avoid storing secrets in container images, stop using static, long-lived credentials, and centralize their secrets management using a dedicated vault or secrets manager. Organizations should implement active scanning across the entire software development life cycle and revoke exposed secrets and invalidate old sessions immediately.
Demographic stats would be nice (Score:4, Interesting)
It'd be great to know who and why still ends up committing or pushing secrets in containers. As a software professional, I haven't seen anyone do it for a decade now. Am I lucky to just work at places that good code practices or is there some sort of a parallel, underground development universe I don't know about?
It would also be good to know if there are any geographical patterns (yes, I'm looking at you, South Asia), or how much of that code was pushed by security-oblivious AI.
Re: (Score:3)
Yeah... like dudes, go look up "Heroku 12 factor" and memorize it and live it. Its a *really useful* guide to building scalable app without having to degenerate into hellish lambda messes or whatever.
And one central key to it is;- Dont put config in the container! Inject it on deploy!
We knew this at least a decade ago, at least.
Re: (Score:2)
I simply put all sensitive files and even some IDE specific files in .gitignore then I have a folder examplefilesgitignore with the same structure as the root folder where I put example files without anything sensitive into them.
Re: (Score:2)
Honestly? Everybody, including every software team of any significant size. Likely even your own.
I work in big tech, and it wasn’t for pre-commit and pre-receive hooks, a secret would get committed to GitHub every single day. This has been the case at every large tech company I’ve worked at for the last decade.
Re: Demographic stats would be nice (Score:2)
Indeed, the companies that were already using docker when I joined them all had hardcoded credentials in the layers, or metadata of the images.
At each one of them one of the first thing I did was to re-implement the image build process to no longer embed credentials, then rotate the credentials. Once you have that add CI checks to scan for the credentials.
The problem comes when you have rogue teams that then decide to build their own CI/CD systems in order to work faster. These teams get rewarded for moving
Re: (Score:2)
> big tech... github
IME big tech has in-house git servers...
Re: Demographic stats would be nice (Score:2)
Run.
Re: (Score:3)
Re: (Score:2)
Commit .env to git repos you mean? I do it all the time - but if it makes you feel better it's only for private repos that I don't share with anyone and I always feel vaguely guilty about it.
Impressive (Score:2)
And not in a good way. Looks like a rather large number of people seriously do not know what they are doing.
Say it isn't so... (Score:2)
No way. The guys that can't manage to manage a real machine, can't understand how things work, and farming out thought also can't figure out their container shouldn't have hard coded creds?
Too bad they've all been drained already... (Score:2)
I could use a free OpenAI api key.
Containers (Score:4, Insightful)
Containers are for lazy developers who can't be bothered to actually make software that works without a shed load of libraries sucked in.
It makes their lives easy, and the sysadmin's life far more difficult (especially given the range of potential docker formats).
Hey, the sysadmin won't let us spin up virtual machines, so we'll create fake miniature virtual machines that all include massive amounts of out-of-date dependencies in an independent manner so that they're obfuscated, locked into older version that we're "not allowed to run", and which become a management nightmare the second one of them needs updating globally.
But, hey, at least we don't have to comply with "IT" and their ridiculous security protocols.
Re:Containers (Score:4, Insightful)
What about..? (Score:3)
Lots of buggy containers. Sure. There are likely tens of thousands more that didn't get detected.
But, let's talk about the intentionally malicious or rooted containers. I know that they are there. The entire container repository system makes it way too easy to plant malicious containers and everyone blindly downloads and executes this shit as root all day long.
How come no one talks about the disastrous lack of security in the way that everyone uses containers? How many compromised containers are sitting on Docker Hub?
Tried to Get OpenFoam Off Docker (Score:2)
But it's containerized! (Score:4, Interesting)
Installing someone's system image instead of just a software was a dumb idea from the very first docker release on. We are lucky if people are able to build secure software, but docker requires them to also build secure system images. It also discourages people from running updates, saying "you can just deploy the new image in no time". Yeah, but I'd rather update when my OS has the update, not when some random guy uploading stuff to dockerhub finally gets around to rebuild the image.
123456 (Score:2)
There, that's the password. Don't tell anyone!