LiteLLM PyPI 공급망 공격 - 악성 코드 삽입 보안 사건 분석
목차
개요
2026년 3월 24일, Python LLM 프록시 라이브러리인 LiteLLM의 PyPI 패키지가 공급망 공격(Supply Chain Attack)을 당했다. litellm 버전 1.82.7과 1.82.8에 악성 코드가 삽입되어 배포되었으며, 설치된 시스템의 민감한 자격 증명을 탈취하고 지속적인 백도어를 설치하는 심각한 보안 사건이었다. 이 글에서는 공격의 타임라인, 기술적 세부사항, 영향 범위, 그리고 대응 방안을 정리한다.
배경
LiteLLM은 다양한 LLM API를 통합 관리할 수 있는 Python 라이브러리로, DSPy, CrewAI, Airflow 등 628개 이상의 프로젝트가 의존하고 있는 핵심 패키지이다. 이번 공격은 PyPI에 게시된 패키지 자체가 변조된 공급망 공격으로, 단순히 LiteLLM을 설치하는 것만으로도 악성 코드가 실행되는 구조였다. 특히 FutureSearch에서 Cursor의 전이 의존성(transitive dependency)으로 LiteLLM이 설치되는 과정에서 이 공격을 최초 발견했다.
핵심 내용
공격 타임라인
| 시각 (UTC) | 사건 |
|---|---|
| 3월 24일 10:52 | 악성 버전 1.82.8이 PyPI에 게시됨 |
| 3월 24일 12:30 | 버전 1.82.7도 변조된 것으로 확인됨 |
| 3월 24일 13:03 | GitHub 이슈가 “not planned”으로 종료됨 - 메인테이너 계정이 완전히 탈취된 것으로 추정 |
| 3월 24일 20:15 | 변조된 버전이 PyPI에서 제거(yank)되고 격리 해제됨 |
공격자는 약 9시간 동안 악성 패키지를 배포할 수 있었으며, 메인테이너 계정까지 탈취하여 보안 이슈 보고를 차단했다.
기술적 분석
공격의 핵심 벡터는 악성 litellm_init.pth 파일이었다. Python의 .pth 파일은 패키지가 설치된 상태에서 모든 Python 프로세스 시작 시 자동으로 실행되는 특성을 가지고 있다. 즉, LiteLLM을 import하지 않더라도 해당 환경에서 Python을 실행하는 것만으로 악성 코드가 동작했다.
3단계 페이로드
공격은 세 단계로 구성된 정교한 페이로드를 사용했다.
| 단계 | 동작 | 상세 내용 |
|---|---|---|
| 1단계 - 수집 | 민감 정보 수집 | SSH 키, .env 파일, 클라우드 자격 증명(AWS/GCP/Azure), Kubernetes 설정, 데이터베이스 비밀번호, 셸 히스토리, 지갑 파일 등 |
| 2단계 - 유출 | 암호화 후 전송 | AES-256-CBC + 4096비트 RSA 공개키로 암호화하여 https://models.litellm.cloud/ (정상 도메인이 아님)로 전송 |
| 3단계 - 횡적 이동 | 지속적 백도어 설치 | Kubernetes 서비스 어카운트 토큰을 악용하여 kube-system 네임스페이스에 권한 상승된 Pod 생성, /root/.config/sysmon/sysmon.py에 영구 백도어 설치 |
수집 대상이 매우 광범위하여, 개발 환경뿐 아니라 프로덕션 환경의 클라우드 인프라까지 침해할 수 있는 구조였다.
포크 폭탄 버그
흥미로운 점은 악성 코드에 버그가 있었다는 것이다. malware가 subprocess.Popen을 통해 자식 프로세스를 생성하는데, .pth 파일의 자동 실행 특성 때문에 자식 프로세스에서도 다시 .pth가 실행된다. 이로 인해 재귀적 .pth 실행이 발생하여 지수적 포크 폭탄(fork bomb)이 되어 시스템이 크래시되는 현상이 나타났다. 역설적으로 이 버그가 일부 시스템에서 악성 활동을 조기에 발견하는 데 도움이 되었을 수 있다.
영향 범위와 대응 방안
LiteLLM에 직접 또는 간접적으로 의존하는 628개 이상의 프로젝트가 잠재적 영향권에 있었다. DSPy, CrewAI, Airflow 등 주요 AI/ML 프레임워크가 포함되어 있다. 또한 보안 스캐너인 Trivy도 유사한 공격을 당해 2차 공격 벡터로 활용되었다.
감염 여부 확인 및 대응을 위한 권장 조치는 다음과 같다.
| 조치 | 명령어 또는 방법 |
|---|---|
| 버전 확인 | pip show litellm |
| 패키지 제거 및 캐시 정리 | 패키지 삭제 후 pip 캐시 완전 삭제 |
| 지속성 검사 | ~/.config/sysmon/ 디렉토리 및 의심스러운 K8s Pod 확인 |
| 자격 증명 교체 | 모든 SSH 키, 클라우드 자격 증명, DB 비밀번호 등 로테이션 |
특히 해당 기간에 litellm이 설치된 환경에서는 모든 자격 증명이 유출되었을 가능성을 전제하고 전수 교체를 권장한다.
의미와 시사점
이번 사건은 PyPI 공급망 공격의 위험성을 다시 한번 보여주었다. .pth 파일을 통한 자동 실행이라는 Python의 구조적 특성이 공격에 악용되었다는 점에서, 패키지 설치만으로도 전체 시스템이 침해될 수 있음을 경고한다. 메인테이너 계정 탈취를 통해 보안 이슈 보고 자체를 차단한 것은 공격의 정교함을 보여준다. 전이 의존성을 통한 간접 감염 경로는 직접 사용하지 않는 패키지로부터도 위험이 발생할 수 있음을 시사한다. 패키지 버전 고정(pinning), 의존성 감사(audit), 그리고 설치 전 해시 검증 등의 보안 관행이 더욱 중요해졌다.
결론
LiteLLM PyPI 공급망 공격은 AI/ML 생태계의 핵심 인프라가 공급망 공격에 취약할 수 있음을 명확히 드러낸 사건이다. 약 9시간 동안 악성 패키지가 배포되었고, 3단계 페이로드를 통해 자격 증명 탈취부터 Kubernetes 횡적 이동까지 시도했다. 개발자와 운영팀은 의존성 관리에 대한 보안 인식을 높이고, 패키지 설치 시 출처 검증과 버전 고정을 철저히 해야 한다. 특히 CI/CD 파이프라인과 프로덕션 환경에서의 의존성 설치는 더욱 신중하게 관리해야 할 것이다.