LiteLLM 1.107.0 침해 — Python이 뜰 때마다 도는 자격증명 탈취기, 공식 파이프라인으로 배포됐다

SafeDep의 분석입니다. LiteLLM은 여러 LLM 제공사를 하나의 API로 묶는 Python 라이브러리이자 프록시 서버입니다. 3월에 1.82.7·1.82.8이 침해된 적이 있고, 이번이 두 번째입니다.

타임라인 (10월 21일, UTC)

시각	내용
10:08	공격자가 브랜치 보호 무력화, 릴리스 워크플로 변경
10:46	유사 이름 저장소 `Berri-AI/litellm`에서 스테이징 빌드
11:39~40	악성 휠 7개 PyPI 업로드
11:46	악성 Docker 이미지 게시
13:23	PyPI에서 1.107.0 제거
13:40	공격자 GitHub 계정 `letters9813` 404
14:20	Docker Hub 태그 제거·재지정

PyPI 노출 약 1시간 45분, Docker 약 2시간 반.

침해 경로

LiteLLM 보고서에 따르면 공격자는 개발자 3명의 GitHub CLI 자격증명을 확보했습니다. 인터넷에 노출된 내부 배포의 로그에서 가져갔을 것으로 LiteLLM은 추정합니다. 조직 owner 토큰으로 브랜치 보호를 우회하고, 릴리스 워크플로가 유사 이름 저장소를 가리키게 바꾼 뒤, 두 번째 개발자 자격증명으로 승인 게이트를 통과했습니다. 공식 파이프라인이 빌드하고 서명하고 배포했습니다. 서명 검증은 이걸 못 잡습니다.

sdist의 pyproject.toml에 [tool.maturin] data = "cook" 한 줄이 추가돼 휠에 cook/ 폴더가 들어갔습니다.

악성 코드

cook.pth → Python 시작 시마다 cook.py 실행. 탈취기.
sitecustomize.py → 백그라운드 데몬. 백도어.
litellm을 import하지 않는 프로세스에서도 돕니다. .pth와 sitecustomize는 인터프리터 시작 시 무조건 로드됩니다.

탈취 대상: 호스트·네트워크 정보, Chromium·Firefox 저장 비밀번호와 방문 기록, ~/.ssh/*, bash·zsh·PowerShell 기록, AWS·Azure·gcloud·kubeconfig·Docker config·gh hosts.yml·netrc, .pem/.key/.pfx/.p12·GPG·TLS 키, GitLab runner·Jenkins·Vault·Terraform 설정, Claude Code·Cursor·Copilot·Codex·Gemini CLI·Hugging Face 토큰, 자기 프로세스와 /proc/<pid>/environ의 환경변수, DATABASE_URL로 접속한 LiteLLM 프록시 DB의 제공사 API 키 테이블, AWS IMDS 인스턴스 자격증명.

AES-256-CBC로 암호화해 www.litellm[.]dev/healthcheck로 POST. 호스트당 1회(/tmp/.pc_once_... 마커).

백도어: 1시간마다 GitHub raw의 domain.txt에서 도메인을 읽고, 탈취기를 재실행하고, http://<domain>/codepy를 받아 exec(). 13:40에 계정이 사라져 지금은 동작하지 않지만, 그 전에 데몬이 뜬 호스트는 2차 코드를 받았을 수 있습니다. SafeDep은 서버 주소를 복구하지 못했습니다.

영향 범위

악성: litellm==1.107.0 전체(휠 7개 + sdist), Docker v1.107.0, latest, main-latest, main-stable
정상: 1.106.2, 1.107.0rc1, rc2, 고정된 litellm-proxy-extras==0.4.110, litellm-enterprise==0.1.78

실무에서 할 일

확인: site-packages에 cook.pth, cook.py, sitecustomize.py가 있는지. /tmp/.pc_once_72129118c59f5636c0bb, /tmp/remote_code_loader.lock, 환경변수 PRIVCOLLECT_ACTIVE. 부모 PID 1에 작업 디렉터리 /인 Python 데몬. Docker면 이미지 digest sha256:1bbcb14….

감염됐다면: 삭제가 아니라 교체입니다. 그 머신에 있던 SSH 키, 클라우드 자격증명, CI 토큰, AI 도구 토큰, 그리고 LiteLLM 프록시 DB에 있던 모든 제공사 키. latest 태그로 프록시를 돌리던 곳은 DB의 키가 통째로 나갔다고 봐야 합니다.

모두에게: latest 태그를 프로덕션에 쓰지 마세요. 버전을 고정하고, 새 버전은 며칠 묵힌 뒤 올리세요. 이번 악성 버전의 수명은 2시간이 안 됐습니다 — 하루만 기다렸어도 피해갔습니다.