Leaked GitHub Python Token

Here’s a disaster that didn’t happen:

Cybersecurity researchers from JFrog recently discovered a GitHub Personal Access Token in a public Docker container hosted on Docker Hub, which granted elevated access to the GitHub repositories of the Python language, Python Package Index (PyPI), and the Python Software Foundation (PSF).

JFrog discussed what could have happened:

The implications of someone finding this leaked token could be extremely severe. The holder of such a token would have had administrator access to all of Python’s, PyPI’s and Python Software Foundation’s repositories, supposedly making it possible to carry out an extremely large scale supply chain attack.

Various forms of supply chain attacks were possible in this scenario. One such possible attack would be hiding malicious code in CPython, which is a repository of some of the basic libraries which stand at the core of the Python programming language and are compiled from C code. Due to the popularity of Python, inserting malicious code that would eventually end up in Python’s distributables could mean spreading your backdoor to tens of millions of machines worldwide!

Tags: leaks, security analysis, supply chain

Posted on August 2, 2024 at 7:01 AM • 10 Comments

Comments

Tom • August 2, 2024 8:07 AM

So… why are we so confident this didn’t happen? If the key was exposed for months – long enough that it’s not possible to say when it was issued because the logs aren’t kept that long – how can we tell that it hasn’t been used to upload malicious code? Presumably someone can tell which account the compromised key was associated with; at a minimum, every action by that account needs auditing. Or is it an account that hasn’t actually been used for anything? In which case, why does it have such elevated access?

wiredog • August 2, 2024 11:15 AM

Both of the write-ups say they found the token in a Docker container in a compiled Python file. I think they meant they found the token in a compiled python file which was in the Docker container. Because otherwise why is a Docker container inside the pyc file?

David in Toronto • August 2, 2024 12:39 PM

And there is this design feature of GitHub that has been known for a few years.

https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github

lurker • August 2, 2024 2:58 PM

@wiredog

“Both writeups” = plagiarism? Perhaps, perhaps not, since jfrog has a comma after “Docker container” which adds a little sense to the meaning. Badly written stuff like that is hard to read, so the real meaning can be missed.

@Tom
“So… why are we so confident this didn’t happen?”

Because nothing bad has happened, yet?
The upload account should be easily identifiable, does it follow that the token belongs to that account? That’s certainly a juicy load of admin access from a single token. And they keep whining at us mortals to use a different password for every account …

Clive Robinson • August 2, 2024 3:34 PM

@ ALL,

With regards,

“Here’s a disaster that didn’t happen:”

Hmm,

“didn’t happen”

is not the wording I’d use,

“has not yet been found to have happened”

might be more accurate.

But that is still just “playing with words” and not the real issue that needs to be considered.

The real problem is that certain types of security are extremely fragile.

When it comes to “Authenication”(AuthN), “Authorization”(AuthZ), or most forms of proof by shared secret we call a “root of trust”, by habit we use the most brittle way there is to establish a valid relationship in the ICT industry.

We’ve know this is a serious problem for six decades or more, we’ve also come up with ways to partially mitigate the problem… but by apparent preference we chose to do things the most fragile ways imaginable.

The question that should be upper most in most peoples minds should be,

“Why?”

Chelloveck • August 2, 2024 3:44 PM

@wiredog: “The authentication token was found inside a Docker container, in a compiled Python file – pycache/build.cpython-311.pyc”

The sentence is a little ambiguous, but they’re saying that the token is inside the compiled file, which is inside the Docker container. If they were trying to say that the other way around they would have omitted the comma.

Anonymous Coward • August 2, 2024 7:10 PM

@wiredog,

The next time my husband says my keys are in the bedroom on the nightstand, I’m going to ask him whose bright idea it was to build a bedroom on top of a nightstand.

Chris W. • August 3, 2024 6:57 AM

PyPi should implement the same publishing process that Maven uses in Java. This is an authority that reviews code, flags vulnerabilities, and ensures security of a huge library of reusable code. PyPi is such a great resource, it would be ashame for it to fall victim to an oversight like this one.

Clive Robinson • August 3, 2024 10:02 PM

@ Chris W., ALL,

Re : All information object supply chains are vulnerable.

Saying,

“This is an authority that reviews code, flags vulnerabilities, and ensures security of a huge library of reusable code.”

Might sound like it is impressive defence… but it’s actually a method that is guaranteed to fail, and has done under a different name for quite some time now.

Basically it’s the same idea behind the Application “walled Gardens” of Google and Apple. Neither of whom have had any real success in keeping malicious code out of their repositories.

In fact there is sufficient proof from papers in the early 1930’s that say that it can not actually be done.

If you look back on this blog I’ve indicated in the past that the,

1, What you are
2, What you have
3, What you know

“Authentication factors” are insufficient. And indicated that “What you know” should also include the temporal “A time you act” and geospatial “A place you act”.

Well one of the latest tricks to get around automated vulnerability checking is to “geo-fence” the places that are known to do automated vulnerability testing,

https://9to5mac.com/2024/08/02/developers-trick-app-store-review/

Something I mentioned just a few hours ago over at,

https://www.schneier.com/blog/archives/2024/08/education-in-secure-software-development.html/#comment-439792

So as malware developers read this site, do not be surprised if you get to hear in the near future about “temporal-fencing” being used to hide malware if it’s “9 to 5” or similar “work hours” where vulnerability testing is known to get carried out…

Scott Cantor • August 5, 2024 11:07 AM

@ Chriw W

I don’t know what you’re referring to re: Maven, but there is most certainly no such “authority” in the Java or Maven world. If you mean Maven Central, they take no resonsibility for any code in that repository, nor do they have any real procedures in place that prevent the code there from being uploaded by the wrong people. I know that to be true because my own project ended up there, with modified jars, from a source that wasn’t my project.

Nor, BTW, does Maven itself implement any actual verification of either itself, its own plugins, or the artifacts it pulls into a build. You need a whole other custom layer of code to do that, even if you used the Maven pgp plugin, which isn’t really a workable solution to begin with.

Python’s supply chain is broken, but so is every other supply chain.

Leaked GitHub Python Token

Comments

Leave a comment Cancel reply