[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAAN-QwQs-yXHH5nx=NyWJH2u-+NOErmwu=f=vD6cqGeHp2or0g@mail.gmail.com>
Date: Wed, 17 Jul 2024 17:50:14 +0300
From: "Andrii Polkovnychenko [EXT]" <andreyp@...og.com>
To: oss-security@...ts.openwall.com
Subject: Python Infrastructure Admin Token Leaked Through Docker Hub
Hello all,
My name is Andrey Polkovnychenko and I’m part of JFrog’s security
research team. We recently detected and disclosed a critical leaked
Python infrastructure access token, and we were encouraged by several
oss-security members to post the technical details here as well.
On June 28, 2024 JFrog’s security research team detected a "classic"
GitHub personal access token (PAT) in the public Docker Hub repository
“cabotage/cabotage-app”, in tags v3.0.0b35 and v3.0.0b110. This token
had admin access to several GitHub organizations, including
github.com/psf, github.com/pypi, github.com/python, and
github.com/pypa.
The token was found in a **compiled** Python file located at
cabotage/celery/tasks/pycache/build.cpython-311.pyc. The matching
source code file (build.cpython-311.py) was present in the Docker
image, but did not contain the token. A comparison between the
original (.py) and decompiled (.pyc) versions revealed that the token
was used to call the GitHub API in several places:
diff --git a/build_without_token.py b/build_with_token.py
index 66e9189..1c2d02e 100644
--- a/build_without_token.py
+++ b/build_with_token.py
xw @@ -355,7 +355,6 @@ def
_fetch_github_file(github_repository="owner/repo", ref="main", access_token=
headers = {
'Accept': 'application/vnd.github+json',
'X-GitHub-Api-Version': '2022-11-28',
- 'Authorization': 'Bearer 0d6a9bb5af126f73350a2afc058492765446aaad',
}
if access_token is not None:
headers['Authorization'] = f'token {access_token}'
@@ -379,7 +378,6 @@ def
_fetch_commit_sha_for_ref(github_repository="owner/repo", ref="main", access
headers = {
'Accept': 'application/vnd.github+json',
'X-GitHub-Api-Version': '2022-11-28',
- 'Authorization': 'Bearer 0d6a9bb5af126f73350a2afc058492765446aaad',
}
if access_token is not None:
headers['Authorization'] = f'token {access_token}'
@@ -496,9 +494,7 @@ def build_image_buildkit(image=None):
"--opt",
f"filename=./{dockerfile_name}",
"--opt",
…
-f"context=
https://x-access-token:0d6a9bb5af126f73350a2afc058492765446aaad@...hub.com/{image.application.github_repository}.git#{image.commit_sha}
",
According to the incident report of the Python administrator whose
token was the one that was leakedPython admin’s own account, they used
the token during local testing and included it in a script to build
the Docker image locally. Before the build, the developer executed
the git stash command in order to remove local changes.
#!/bin/bash
generation=$(cat generation)
git stash
docker buildx build --platform linux/amd64,linux/arm64 -t
cabotage/cabotage-app:v3.0.0b${generation} --push .
kubectl -n cabotage set image deployment/cabotage-app
cabotage-app=cabotage/cabotage-app:v3.0.0b${generation}
cabotage-app-worker=cabotage/cabotage-app:v3.0.0b${generation}
cabotage-app-beat=cabotage/cabotage-app:v3.0.0b${generation}
git stash pop
echo $((generation + 1)) > generation
This command restored the source files but **left the compiled .pyc
files untouched**, resulting in their inclusion in the Docker image.
The token was created at the beginning of 2023 and first appeared in the
DockerHub repository in March 2023. The JFrog security team discovered
and reported the token on June 28, 2024. It was then immediately revoked,
within 17 minutes. The PyPI administrators have stated that the GitHub
audit
logs found no indicators of malicious activity related to the token.
Some “reminder” recommendations after this incident -
1. Create Tokens with the least amount of privileges needed
2. Set an expiration date for your Tokens (this token was 1.5 years
old when we detected it)
3. Never put hardcoded tokens into source code (even temporarily)
since they may propagate into other files as part of the build
process. Prefer ephemeral sources such as environment variables
4. Perform builds on automated systems from clean source code only.
Avoid pushing to production from a local build.
More details can be found in JFrog’s blog and PyPI incident response posts:
https://jfrog.com/blog/leaked-pypi-secret-token-revealed-in-binary-preventing-suppy-chain-attack/
https://blog.pypi.org/posts/2024-07-08-incident-report-leaked-admin-personal-access-token/
--
<https://jfrog.com/resources/upcoming-webinars/?utm_source=email&utm_medium=signature_banner&utm_campaign=upcoming_webinarshttp://>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
