Most active commenters
  • sitkack(4)

←back to thread

Leaked admin access token to Python, PyPI, and PSF GitHub repos

(jfrog.com)
114 points elchief | 14 comments | 12 Jul 24 00:34 UTC | HN request time: 0.991s | source | bottom
Show context
elchief ◴[12 Jul 24 00:34 UTC] No.40941810[source]▶
The JFrog Security Research team has recently discovered and reported a leaked access token with administrator access to Python’s, PyPI’s and Python Software Foundation’s GitHub repositories, which was leaked in a public Docker container hosted on Docker Hub.

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.

replies(1): >>40944046 #
sans_souse ◴[12 Jul 24 09:35 UTC] No.40944046[source]▶
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)
replies(2): >>40944799 #>>40944800 #
ketch ◴[12 Jul 24 12:11 UTC] No.40944800[source]▶
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

replies(4): >>40945411 #>>40946267 #>>40948927 #>>40961218 #
1. bheadmaster ◴[12 Jul 24 13:31 UTC] No.40945411[source]▶
> - 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.

replies(1): >>40945505 #
2. sitkack ◴[12 Jul 24 13:42 UTC] No.40945505[source]▶
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.

replies(3): >>40946106 #>>40947616 #>>40948391 #
3. andrewSC ◴[12 Jul 24 14:48 UTC] No.40946106[source]▶
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?
replies(2): >>40947106 #>>40948470 #
4. sitkack ◴[12 Jul 24 16:34 UTC] No.40947106{3}[source]▶
And the logs are gone for both GitHub and docker hub. We should assume anything that could get compromised is compromised.
replies(1): >>40947938 #
5. belter ◴[12 Jul 24 17:31 UTC] No.40947616[source]▶
> 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...

6. salawat ◴[12 Jul 24 18:05 UTC] No.40947938{4}[source]▶
...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.

replies(1): >>40954770 #
7. hirako2000 ◴[12 Jul 24 18:58 UTC] No.40948391[source]▶
Exactly. More than one bad practice in there. note the secret was never in the repo though. Only in the container image.
replies(1): >>40948678 #
8. coldpie ◴[12 Jul 24 19:09 UTC] No.40948470{3}[source]▶
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.
replies(1): >>40948920 #
9. sitkack ◴[12 Jul 24 19:36 UTC] No.40948678{3}[source]▶
That token gives admin access to all the repos they have access to.
10. x0x0 ◴[12 Jul 24 20:07 UTC] No.40948920{4}[source]▶
On the one hand, yes.

On the other hand, a 15 months old token that's still alive... that's pretty damn incompetent.

replies(1): >>40949090 #
11. coldpie ◴[12 Jul 24 20:26 UTC] No.40949090{5}[source]▶
Yeah but my point is they probably did the other 499,990 things right, but will get no credit for it.
replies(2): >>40949159 #>>40949638 #
12. sitkack ◴[12 Jul 24 20:35 UTC] No.40949159{6}[source]▶
This isn't an individual issue, this is an organizational systemic issue. It isn't on the individual to "do better" or not make mistakes. Even if they had made a PAT, there should be an org level policy that PAT tokens can only last x-days where x is very short (as an example, PAT tokens should be banned).
13. x0x0 ◴[12 Jul 24 21:31 UTC] No.40949638{6}[source]▶
Not allowing long-lived, powerful tokens is so basic that I'm skeptical they did very much right.
14. yupyupyups ◴[13 Jul 24 15:54 UTC] No.40954770{5}[source]▶
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.