←back to thread

114 points elchief | 3 comments | | HN request time: 0.016s | source
Show context
elchief ◴[] 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 ◴[] 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 ◴[] 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 #
js2 ◴[] No.40946267[source]
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.
replies(1): >>40948365 #
1. hirako2000 ◴[] No.40948365[source]
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.

replies(2): >>40949353 #>>40950095 #
2. zihotki ◴[] No.40949353[source]
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)
3. ◴[] No.40950095[source]