LiteLLM 1.107.0 PyPI 배포본에 자격증명 탈취기와 백도어가 심겨 있었음
- PyPI에 올라간 LiteLLM 1.107.0 배포본에 자격증명 탈취기와 원격 코드 실행 백도어가 들어 있음, GitHub 원본 소스에는 해당 코드가 없고 PyPI는 이후 해당 릴리스를 삭제함
- wheel 파일 세 개 모두 site-packages에 cook.pth, cook.py, sitecustomize.py를 설치하며, 이 중 두 파일은 litellm을 import하지 않는 Python 프로세스가 시작될 때도 실행됨
- 탈취기는 SSH 키, 클라우드 자격증명, CI/CD 시크릿, LiteLLM 프록시 DB의 LLM 제공자 키를 수집해 암호화한 뒤 www.litellm[.]dev로 전송함
- SafeDep는 sdist의 pyproject.toml에 data = "cook" 한 줄이 추가된 것을 확인했고, 태그 v1.107.0 커밋이 아닌 main 브랜치 커밋 a8113b0 기반으로 빌드된 것으로 분석함
- GitHub Actions 실행 기록 539건 중 이번 배포를 만든 공개 실행은 없었고, PyPI 업로드 약 10분 뒤 봇 계정이 GitHub 릴리스를 만들었음
Hacker News opinions
이번 주에만 Google Cloud 장애, eMudhra CA 개인키 유출, PingCap 10.6TB 유출, PHP2Shell 취약점까지 터졌는데 LiteLLM은 두 번째임. 이 정도면 진짜 지겹다.
LiteLLM 한 번 털렸으면 두 번째는 용서 안 되지. 두 번 당하면 그건 운영 실수임.
uv나 npm 기본값에 24~48시간 쿨다운을 넣는 게 답인 듯. 새 버전은 일부러 찾아서 설치하게 만들어야 함.
내부 PyPI 프록시에 7일 쿨다운 걸어놨더니 보안 패치까지 막혀서 예외 목록을 따로 관리 중임. 자동화 방법은 아직 못 찾음.
근데 쿨다운보다 배포 파이프라인에서 버전 고정을 안 하는 곳이 더 문제 같음.
조사 자료 보면 공급망 공격은 보통 몇 달에서 몇 년씩 숨어 있다가 발견되더라. 그럼 24~48시간 쿨다운은 별 효과 없다고 봄.
엔터프라이즈 고객한테만 패치를 먼저 준다는 얘기가 나와서 말이 많음. 근데 엔터프라이즈 빌드 경로는 이번 사고 영향이 없었다고 하더라.
LLM으로 코드 전체를 분석하면 잡히지 않냐는 질문인데, 전부 돌리면 비싸서 diff 휴리스틱으로 후보만 골라 돌리는 게 현실적임. 다만 새로운 공격은 놓칠 수 있음.