LiteLLM 1.82.7 및 1.82.8 PyPI 패키지 침해 사건

- 널리 사용되는 LLM 통합 라이브러리 LiteLLM의 PyPI 패키지 두 버전(1.82.7, 1.82.8)에 악성 페이로드가 삽입되어 배포되었으며, 설치 시 시스템 인증 정보를 탈취하는 공격이 발생 - 공격 원인은 CI/CD 보안 스캐닝 도구 Trivy의 공급망 침해에서 비롯되었으며, CircleCI 인증 정보가 유출되어 PyPI 퍼블리시 토큰과 GitHub PAT가 탈취됨 - 공식 LiteLLM Proxy Docker 이미지 사용자는 requirements.txt에 버전 고정이 되어 있어 영향을 받지 않았으나, PyPI에서 직접 pip install한 환경은 즉각적인 점검 필요 - GitHub 이슈 스레드에 수백 개의 봇 스팸 댓글이 쏟아져 실질적 논의를 방해했으며, 이는 공격자가 의도적으로 대응 커뮤니케이션을 교란한 것으로 확인 - DSPy, CrewAI 등 LiteLLM을 의존성으로 사용하는 다수 프로젝트에도 파급 영향이 있어, 소프트웨어 공급망 보안의 근본적 취약성을 다시 한 번 부각 사건 개요 및 발견 경위 - 새 프로젝트 설정 중 시스템이 비정상적으로 동작하며 RAM이 소진되고 포크봄 형태의 프로세스가 실행됨 - 조사 결과 proxy_server.py 에 base64로 인코딩된 악성 블롭이 추가되어 있었고, 이를 디코딩하여 별도 파일을 생성한 뒤 실행하는 구조 - 1.82.7 버전은 litellm/proxy/proxy_server.py 에 페이로드가 포함되어 import litellm.proxy 시 실행 - 1.82.8 버전은 추가로 litellm_init.pth 파일을 포함하여, 패키지가 설치만 되어도 Python 시작 시 자동으로 악성코드 실행 - .pth 파일은 Python의 site 모듈이 시작 시 자동 실행하는 메커니즘으로, import 키워드 뒤에 임의 코드 실행 가능 - 이 메커니즘은 Python 2.1부터 존재했으며, 별도 PEP 없이 도입됨 - FutureSearch 팀이 최초 피해를 보고: uvx가 자동으로 최신 litellm(버전 미고정)을 설치한 뒤, Cursor가 로컬 MCP 서버를 자동 로드하면서 감염 발생 공격 경로 및 TeamPCP 연관 - 공격은 최근 Trivy를 침해한 TeamPCP 그룹과 동일한 공격자로 확인 - 침해 경로: Trivy 해킹 → CircleCI 인증 정보 전체 유출 → PyPI 퍼블리시 토큰 + GitHub PAT 탈취 → 악성 패키지 배포 - LiteLLM CEO/CTO의 GitHub 계정도 완전히 탈취되어, 개인 저장소 설명이 모두 "teampcp owns BerriAI"로 변경되었고 이슈가 닫히는 등의 행위 발생 - PYPI_PUBLISH 토큰이 GitHub 프로젝트의 환경 변수로 저장되어 있었고, 이것이 Trivy를 통해 유출됨 - 계정에는 2FA가 설정되어 있었으나, 토큰 자체가 탈취되어 우회됨 - 공격자는 GitHub 이슈에 수백 개의 봇 계정으로 동일 문구를 반복 게시하여 실질적 논의를 방해 - Trivy 저장소에서도 동일한 패턴으로 700개 이상의 스팸 댓글 확인 - 스팸 계정 중 일부는 실제 기여 이력이 있는 GitHub 사용자로, 2월부터 "Update workflow configuration" 커밋으로 CI 워크플로에 인증 정보 탈취기를 삽입한 이력 확인 - Trivy 침해는 최소 5일 전에 발생했으며, 최신 공격 공지가 바로 전날 나왔기 때문에 메인테이너가 인지하지 못한 상태에서 피해 발생 가능 - 공격자는 Internet Computer Protocol(ICP) Canisters를 페이로드 전달에도 활용, DNS 차단만으로는 방어 불가 악성 페이로드 동작 방식 - 백그라운드 Python 프로세스를 생성하고 내장된 스테이지를 디코딩하여 실행 - 인증 정보 수집기가 실행되며, 데이터 수집 성공 시 공격자의 RSA 공개키로 AES 키를 암호화하고, 탈취 데이터를 원격 호스트로 전송 - 악성코드에서 발견된 URL: checkmarx.zone/raw 와 models.litellm.cloud - 주로 ~/.git-credentials 의 SSH 키와 크립토 지갑 정보를 탈취 대상으로 삼음 - CPU 집약적 작업으로 인해 시스템이 과부하되어 오히려 발견이 용이했으며, 팬 소음으로 이상을 감지한 사례도 보고됨 - Harbor 설치 시에도 동일한 증상 발생: grep -r rpcuser\rpcpassword 프로세스가 포크봄 형태로 실행되어 크립토 지갑 탐색 시도 LiteLLM 팀 대응 - 영향받은 버전(v1.82.7, v1.82.8)은 PyPI에서 삭제 완료 - 모든 메인테이너 계정의 비밀번호 변경, GitHub/Docker/CircleCI/pip의 모든 키 삭제 및 교체 - 새 메인테이너 계정은 @krrish-berri-2와 @ishaan-berri로 교체 - PyPI에서 전체 패키지가 일시 격리(quarantine) 처리되었다가, 감염 버전 제거 후 해제 - 모든 신규 릴리스를 중단하고 공급망 전체 리뷰 완료 전까지 배포 동결 - Google의 Mandiant 보안 팀과 협력하여 조사 및 복구 진행 중 - Trivy는 마지막 안전 버전인 v0.35.0으로 고정 (초기 v0.69.3 고정에서 커뮤니티 피드백 반영하여 변경) - 향후 Trusted Publishing(JWT 토큰 기반 OIDC) 전환, 별도 PyPI 계정 사용 등 보안 강화 검토 - 악성 버전의 최초 게시 시각은 약 UTC 8:30, PyPI 격리 처리는 약 UTC 11:25 영향 범위 및 다운스트림 프로젝트 - LiteLLM은 DSPy의 유일한 LLM 프로바이더 호출 라이브러리이며, CrewAI도 폴백으로 사용 - Airflow, Dagster, Unsloth.ai, Polar, nanobot 등도 LiteLLM에 의존 - GitHub 검색 기준, requirements.txt에 LiteLLM을 버전 미고정으로 포함한 프로젝트가 628건 이상 확인 - 공식 Proxy Docker 배포 경로 사용자는 requirements.txt에 버전 고정이 되어 있어 영향 없음 - Docker 배포의 경우, 호스트 파일시스템과 환경변수에 접근이 제한되어 상대적으로 안전하나, 마운트된 인증 정보는 여전히 위험 - 공격자의 주요 목표는 개인 SSH 키이며, LLM 키 접근은 부차적 - Harbor, browser-use 등 LiteLLM을 의존성으로 자동 설치하는 도구 사용자도 간접 피해 보고 - CrewAI는 litellm을 1.82.6(마지막 안전 버전)으로 고정했으나 커밋 메시지에 침해 관련 언급 없음 - DSPy는 공개적으로 이슈를 생성하여 대응 중 - LangChain은 자체 LLM 프로바이더 호출 레이어를 보유하고 있어 이번 공급망 침해에 직접 영향 없음 (선택적 langchain-litellm 패키지 사용 시 제외) 커뮤니티 논의: 공급망 보안 및 샌드박싱 - 의존성과 개발 환경을 더 이상 신뢰할 수 없으며, VM 격리 + 컨테이너 프리미티브 + 허용 목록 + egress 필터 + seccomp + gVisor 등 다층 방어(defense in depth) 필요 - 과거 50년간의 보안 편의주의가 되돌아오는 상황이며, 전체 보안 모델의 재설계 필요 - 프로그래밍 언어 수준에서 모듈별 샌드박싱 필요하다는 의견 - Java는 1990년대 v1.2부터 이 기능이 있었으나 사용성 문제로 폐기됨 - Capability 기반 언어의 개발 적기라는 의견 - Cloudflare의 workerd 런타임이 모듈 격리 가능한 기존 솔루션으로 언급 - OpenBSD의 pledge/unveil, Linux의 chroot/namespace/cgroup, FreeBSD의 Capsicum 등 OS 수준 격리 도구가 이미 존재 - Guix는 몇 초 만에 격리된 컨테이너를 생성하여 $HOME에 접근하지 않고 의존성 설치 가능 - Firejail과 bwrap 등 사용자 공간 격리 도구의 적극 활용 필요 - 모바일 앱의 샌드박싱 + 권한 모델(Intents) 이 이미 존재하지만, 데스크톱 환경에서는 일반 연산 제한에 대한 반감이 강함 - 이에 대해, Apple/Meta 등의 앱 스토어 폐쇄성과 보안 샌드박싱은 별개 문제이며, 사용자에게 제어권을 주면서도 보안을 확보하는 도구 구축 가능 - macOS용 canary/honeypot 도구 공개 (github.com/dweinstein/canary): 가짜 시크릿을 WebDAV/NFS에 마운트하여 비정상 접근 탐지 - 패키지 발행과 퍼블릭 저장소 사이에 벽을 세워야 한다는 의견: 퍼블릭 저장소를 직접 Trusted Publisher로 설정하면 공격 표면이 넓어짐 - 반론으로, Trusted Publishing의 본래 목적은 소스와 게시 아티팩트 간의 감사 가능한 연결을 제공하는 것이므로 프라이빗 저장소 경유는 후퇴 실무 보안 권고 사항 - 의존성은 SHA256 체크섬과 함께 버전 고정 필수 - 내부 패키지 미러 운영으로 최신 버전 직접 사용 방지 - 빌드 아티팩트를 사용하고 uv run 등으로 배포 시 즉석 설치에 의존하지 말 것 - PyPI 장애 시 시스템이 중단되는 구조적 위험도 제거 - 배포 가능한 아티팩트의 장점: 감사 가능성, 빠른 롤백, 아웃바운드 네트워크의 위험 엔드포인트 차단 가능 - uv의 exclude-newer 설정으로 일정 기간 이내 신규 패키지 제외 가능 - pyproject.toml에 [tool.uv] exclude-newer = "5 days" 설정 가능 - CI/CD에서 퍼블리시 토큰은 OIDC 기반 워크플로로 전환하여 토큰 자체를 제거하는 것이 근본적 해결 - GitHub과 PyPI 모두 OIDC 지원: 퍼블리시 작업에만 OIDC 엔드포인트 접근 권한 부여하면 Trivy 작업에서 탈취할 토큰 자체가 없음 - Trivy 등 보안 스캐닝 도구는 퍼블리시 권한이 없는 별도 워커에서 실행해야 함 - lockfile 관리 및 주간 단위 업데이트로 최신 버전 즉시 채택 회피 - Python의 .pth 파일은 자동 코드 실행이 가능하므로, -S 옵션으로 site import를 억제할 수 있으나 호환성 문제 있음 - osv-scanner 등을 활용한 프로젝트 전체 의존성 스캔 권장 - 감염 여부 확인 명령어: - fi