[HN Gopher] Leaked admin access token to Python, PyPI, and PSF G...
___________________________________________________________________
Leaked admin access token to Python, PyPI, and PSF GitHub repos
Author : elchief
Score : 62 points
Date : 2024-07-12 00:34 UTC (22 hours ago)
(HTM) web link (jfrog.com)
(TXT) w3m dump (jfrog.com)
| elchief wrote:
| 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.
| sans_souse wrote:
| 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)
| ketch wrote:
| 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
| bheadmaster wrote:
| > - 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.
| sitkack wrote:
| 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.
| andrewSC wrote:
| 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?
| sitkack wrote:
| And the logs are gone for both GitHub and docker hub. We
| should assume anything that could get compromised is
| compromised.
| salawat wrote:
| ...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 f _cking 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.
| coldpie wrote:
| 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.
| x0x0 wrote:
| On the one hand, yes.
|
| On the other hand, a 15 months old token that's still
| alive... that's pretty damn incompetent.
| coldpie wrote:
| Yeah but my point is they probably did the other 499,990
| things right, but will get no credit for it.
| sitkack wrote:
| 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).
| x0x0 wrote:
| Not allowing long-lived, powerful tokens is so basic that
| I'm skeptical they did very much right.
| belter wrote:
| > 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...
| hirako2000 wrote:
| Exactly. More than one bad practice in there. note the
| secret was never in the repo though. Only in the
| container image.
| sitkack wrote:
| That token gives admin access to all the repos _they_
| have access to.
| js2 wrote:
| 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.
| hirako2000 wrote:
| 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.
| zihotki wrote:
| 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)
| js2 wrote:
| I mentioned `.dockerignore` in my comment.
| playingalong wrote:
| 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.
| oakpond wrote:
| Yikes, TIL: never build production artifacts from a development
| checkout?
| ilc wrote:
| There is a reason CI/CD servers exist.
|
| 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.
| vetrom wrote:
| This, in part, is why distributions like Debian go to the
| trouble they do to build everything from more-or-less isolated
| sourcecode artifacts.
|
| 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.
| throwaway81523 wrote:
| Why did a leakable token this powerful even exist?
___________________________________________________________________
(page generated 2024-07-12 23:02 UTC)