Python GitHub Token Leak Shows Binary Files Can Burn Developers Too (csoonline.com) 20
snydeq shares a report from CSO Online, written by Lucian Constantin: A personal GitHub access token with administrative privileges to the official repositories for the Python programming language and the Python Package Index (PyPI) was exposed for over a year. The access token belonged to the Python Software Foundation's director of infrastructure and was accidentally included in a compiled binary file that was published as part of a container image on Docker Hub. [...] The incident shows that scrubbing access tokens from source code only, which some development tools do automatically, is not enough to prevent potential security breaches. Sensitive credentials can also be included in environment variables, configuration files and even binary artifacts as a result of automated build processes and developer mistakes. "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," researchers from security firm JFrog, who found and reported the token, wrote in a report.
"If"? (Score:5, Informative)
It was there for a whole bloody year. You really should assume it did "fall into the wrong hands".
Re: (Score:2)
Eh, maybe not. This is one of those leaks where you only find if your looking for it. And I'd have to assume most hackers would have trusted that something so sensitive isn't gonna be likely.
I would not be surprised if you looked hard enough you find this particular type of leak frigging everywhere. God knows I've found enough dodgy looking crypto keys running the 'strings' command over downloaded binaries (I'm usually looking for GPL breaches, a pet hobby of mine, but other shit turns up. I usually just pr
Re: (Score:2)
"looking for it" is easy to automate, and computers don't get bored. There are 8 billion people in the world. All it takes is one of them wondering "What does it take to actually do that?" and deciding to spend a free afternoon on it.
Remember, we're the species that figured out that cashews are edible.
Re: (Score:2)
Re: (Score:2)
In reality you won't get false hits. GH tokens are deliberately designed with a recognizable structure to permit accurate identification when doing secret scanning. GH did this so that their own secret scanning could reliably identify tokens in repositories. Of course it works just as well for letting other parties do the same.
Re: (Score:2)
It very much will have. Or if not, some zero-day sellers will now curse themselves for not looking.
Incidentally, the incident also shows you should _never_ use life production tokens when developing software. Any kind of "scrubbing" just has too high a risk of going wrong. Seriously.
Not exactly rocket science (Score:2)
get ready (Score:3)
You can expect that someone is already searching other packages for the issue. Probably won't be long before some package is compromised.
Re: (Score:2)
Re: (Score:2)
Indeed. There is really no replacement for developers with an actual, real clue. The others do crap like this and do not even notice.
Ass clowns (Score:1)
The access token belonged to the Python Software Foundation's director of infrastructure
Is there anything about Python that's not terrible? The management is irresponsible and incompetent, the performance is abysmal, functional indentation is some punch card bullshit...
Batteries included == assault and battery (Score:2)
Free centralized repositories of useful libraries are a wonderful modern convenience.
Until they become a malware target. And the community-friendly nature of those repositories becomes a security liability.
I don't have any answers other than cryptographic validation and constant vigilance.
It's hard to get constant vigilance from unpaid volunteers, though...
Ken Thompson (Score:2)
This [cmu.edu] should be required reading for anyone writing and publishing code.
This type of vulnerability isn't new, and yes, good security is difficult.
It is akin to a password manager which encrypts your passwords stored on disk, but with a key also stored on that same disk. Anyone with the ability to dump your home directory can have access to your passwords in such a scenario.
No password/key expiration? (Score:2)
Re: (Score:2)
Periodic change requirements have been on the NIST "SHOULD NOT" list since 2017.
See here [nist.gov].
Specifically:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
Re: (Score:2)
Access tokens aren't 'memorized' though.
Re: (Score:1)
Periodic change requirements have been on the NIST "SHOULD NOT" list since 2017.
See here [nist.gov].
Specifically:
Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.
I'm pretty confident that Ee Durbin had not attempted to memorize the string 0d6a9bb5af126f73350a2afc058492765446aaad , which is the personal access token that leaked.
Access tokens != "memorized secrets"
Ah, yes? (Score:2)
Why was this even a question? Anything that can be executed or can hold data can burn you. Seriously.