How were these leaked in this specific example? Am I right in assuming it was more user-error than malicious intent, and - if so, shouldn't this be a resolvable problem for the back-end as far as coding practices concerning public vs private keys and such? (note I am by no means an expert on coding or security)
back
1 comments
The article has answers
> It seems that the original author
> - Briefly added the authorization token to their source code
> - Ran the source code (Python script), which got compiled into a .pyc binary with the auth token
> - Removed the authorization token from the source code, but didn’t clean the .pyc
> - Pushed both the clean source code and the unclean .pyc binary into the docker image
> - Pushed both the clean source code and the unclean .pyc binary into the docker image
Oof.
Honestly, I can't blame the guy for a mistake like this, it's just so easy to make. But then again, deploying images built on a development laptop is generally an error-prone activity. This is why build and deployment servers exist.
Why does one person have admin on all those repos?
Why is Python still running any classic access tokens?
Why is the access token EVER in the source code?
What other stuff is “running on their laptop”?
No pass!
People with access to the repos shouldn’t also have access to push bits to the world. It puts those people with that access in grave physical danger.
Edit, https://blog.pypi.org/posts/2024-07-08-incident-report-leake...
This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.
> This token has been in the wild for 15 months! The JFrog post cannot say that disaster was averted because we do not know.
"Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine"
The above comment from them sounds as weird, as the whole ecosystem security based out of a developer laptop...
This is the correct set of questions to be asking. I’m a little more than surprised there aren’t some defined processes and automation around high viz workflows/stuff like this. When are people going to take cybersec and opsec seriously? Esp. In big projects?
Computer security requires humans to do 500,000 things perfectly, and one slip up means everything they did was worthless. It turns out, humans aren't perfect. The result is inevitable: there is no such thing as computer security.
On the one hand, yes.
On the other hand, a 15 months old token that's still alive... that's pretty damn incompetent.
Yeah but my point is they probably did the other 499,990 things right, but will get no credit for it.
And the logs are gone for both GitHub and docker hub. We should assume anything that could get compromised is compromised.
...There is a reason why those crazies that tell you to build everything from source you personally audit, and to read everything exist.
Y'all want the convenience of "can't someone else just gimme something that works"? Which is fine, but you have to verify the thing is what the other person claims it is. It's the curse of high-trust systems. They are only as trustworthy as the least trustworthy member.
We've done everything we can to rope in everybody. Everybody includes people who are actively malicious to the ecosystem as a whole. Thus the high-trust system has raced to the bottom in transitioning through a low-trust system, to eventually zero-trust; as computer networks in all their forms are just too juicy a set of targets to leave untapped by malicious/selfish actors. The only defense is everyone looking out for themselves on top of everyone else. It's fcking hard. It's a slog. It makes the act of maintaining computing systems that much less sexy. It's also what keeps you* safe from the wolves in sheep's clothing.
My journey in computing has branched out far and wide, only to crunch back to a narrow set of tools that I can vouch for personally. My trust of the denizens of the Net has plummeted, if only because the spaces in the cracks where belief rather than knowledge lie are just such fertile ground for skulduggery now.
I think the inefficency of zero-trust can be applied to many other things in life.
Like
> The only defense is everyone looking out for themselves on top of everyone else. It's fcking hard. It's a slog. It makes the act of maintaining relationships that much less sexy.
Exactly. More than one bad practice in there. note the secret was never in the repo though. Only in the container image.
That token gives admin access to all the repos they have access to.
It's probably a good idea for Python developers to disable pyc files in their development environments with PYTHONDONTWRITEBYTECODE=1 in their shell profile, dotenv file, or otherwise. In this case, perhaps it should also be set in the Dockerfile along with entries in .dockerignore to exclude pyc files and __pycache__ directories.
Or just have a good `.dockerignore`
When I create a project now I automatically place a catch all ignore for both git and docker.
Binaries, .env files have a far lower chance to end up tracked in a repo or copied over to a container image.
Or just use CI/CD on a build server to create release artifacts and a proper security setup (no PAT's, or use short living one)
That's why I consider writing any secrets into code base a security malpractice.
Just for a minute or I am sure I won't commit it, is not an excuse.
Use environment variables or better yet - store the secret on the disk outside of your repo and make the code read it. It's a one liner in plenty of languages.
Great reply thank you. This is totally relatable even to me, as a non-coder. He essentially crafted a shortcut to bypass redundancies, but with the foresight to go back and remove what he thought were all references to that shortcut. He was unaware or forgot there was one last reference and BOOM