Leaked admin access token to Python, PyPI, and PSF GitHub repos
jfrog.com
jfrog.com
As a community service, the JFrog Security Research team continuously scans public repositories such as Docker Hub, NPM, and PyPI to identify malicious packages and leaked secrets. The team reports any findings to the relevant maintainers before attackers can take advantage of them. Although we encounter many secrets that are leaked in the same manner, this case was exceptional because it is difficult to overestimate the potential consequences if it had fallen into the wrong hands – one could supposedly inject malicious code into PyPI packages (imagine replacing all Python packages with malicious ones), and even to the Python language itself!
The JFrog Security Research team identified the leaked secret and immediately reported it to PyPI’s security team, who revoked the token within a mere 17 minutes!
This post will explain how we found a GitHub PAT that provided access to the entire Python infrastructure and prevented a supply chain disaster. Using this case, we will discuss the importance of (also) shifting right in secrets detection – searching for secrets in binaries and production artifacts, not just on source code.
> 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
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 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.
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.
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.
On the other hand, a 15 months old token that's still alive... that's pretty damn incompetent.
"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...
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.
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.
Heck there's a few pieces of software I work on that I can't build locally, I just push WIPs to CI/CD.
I could try to setup a CI/CD pipeline of my own, but it isn't worth the time.
Sure, its not always perfect, and getting say, blobless, is a challenge of its own, but no distro in their right mind for example, would ship arbitrary .o or ld.so objects in source packages.