LiteLLM 1.107.0 설치했다면 pip로 점검하지 마세요

10월 23일 LiteLLM이 악성 코드가 포함된 1.107.0의 배포 경위를 공개했습니다. 같은 날 마이크로소프트는 해당 버전이 설치된 환경에서 LiteLLM을 불러오지 않아도 Python이나 pip 실행만으로 자격 증명 수집기가 작동할 수 있다고 경고했습니다.

1.107.0 외에 당시 latest 태그도 영향

영향받은 배포물은 10월 21일 PyPI에 올라온 LiteLLM 1.107.0 휠 7개와 공식 Docker Hub·GHCR의 일부 이미지입니다. 컨테이너에서는 v1.107.0뿐 아니라 사고 당시 latest, main-latest, main-stable 태그도 대상에 포함됐습니다.

문제 배포물은 내려갔거나 태그가 정상 이미지로 바뀌었지만, 이것이 이미 설치된 환경까지 정리해 주지는 않습니다. LiteLLM 측은 비공개 기업용 레지스트리에서 제공한 릴리스는 영향을 받지 않았다고 밝혔습니다.

LiteLLM의 최종 조사에 따르면, 5월 27일 공개 저장소에 노출된 내부 Agent Platform 마스터 키가 폐기되지 않은 것이 공격의 출발점이었습니다. 공격자는 10월 10일 이 키로 플랫폼에 접근해 GitHub 조직 소유자의 토큰을 얻었고, CI에서도 추가 토큰을 탈취했습니다. 이후 릴리스 작업이 유사 이름의 공격자 저장소를 사용하도록 바꿔 악성 배포물을 서명·게시했습니다.

LiteLLM 폴더 밖에 놓인 악성 시작 파일

마이크로소프트에 따르면 악성 시작 파일은 일반 litellm 폴더 밖, 해당 환경의 Python 라이브러리 경로에 설치됐습니다. Python이 시작할 때 처리하는 파일이어서 litellm 폴더만 삭제하면 악성 구성요소가 남을 수 있습니다.

수집 대상에는 해당 프로세스가 읽을 수 있는 AI 모델 서비스의 API 키, 클라우드·소스 관리 토큰, SSH 키, 브라우저 데이터와 프로세스 환경변수가 포함됐습니다. Unix 계열에서는 추가 코드를 받아 실행하는 로더 기능도 발견됐지만, 실제 후속 코드 다운로드나 실행은 확인되지 않았습니다.

점검은 의심 환경 밖에서

마이크로소프트는 의심 시스템을 격리하고, 정상 상태가 확인된 별도 환경에서 신뢰할 수 있는 도구로 점검하라고 권고합니다. 이때 영향받은 인터프리터를 실행하는 Python·pip 명령은 피해야 합니다. 담당 관리자는 서비스 영향을 살펴 실행 중인 Python 프로세스를 중지하고 자동 재시작도 막아야 합니다.

가상환경과 컨테이너 이미지는 깨끗한 것으로 확인된 배포물로 다시 구축하고, 남아 있는 악성 시작 파일과 프로세스도 처리해야 합니다. 영향받은 환경이 접근할 수 있었던 키와 토큰은 별도의 깨끗한 기기에서 교체하고, 관련 인증 세션도 폐기해야 합니다.

해당 패키지가 있었다는 사실만으로 모든 자격 증명이 유출됐다고 단정할 수는 없습니다. 파일·프로세스·네트워크·인증 활동을 함께 살펴야 하며, 흔적 파일이 보이지 않는 것만으로 안전하다고 판단해서도 안 됩니다.