TECH 으로 돌아가기
TECH HACKER NEWS 오늘 7분 읽기 30 READS

LiteLLM 1.107.0 PyPI 오염 사건: API 키가 모이는 AI 게이트웨이를 노린 공급망 공격, 지금 확인할 것들

LiteLLM 1.107.0 PyPI 오염 사건: API 키가 모이는 AI 게이트웨이를 노린 공급망 공격, 지금 확인할 것들
SOURCE IMAGE · HACKER NEWS
LiteLLM 1.107.0 PyPI 오염 사건: API 키가 모이는 AI 게이트웨이를 노린 공급망 공격, 지금 확인할 것들

무슨 일이 있었나요?

LLM으로 개발하는 분들이라면 한 번쯤 써봤을 파이썬 라이브러리 LiteLLM의 PyPI 배포판 중 1.107.0 버전이 오염된 채로 올라왔다는 분석을 보안 업체 SafeDep이 내놨어요. 이 버전을 설치하면 자격 증명(API 키, 클라우드 인증 정보 등)을 훔쳐 가는 코드와 백도어가 함께 깔린다는 내용이에요.

공급망 공격(supply chain attack) 소식은 이제 익숙하지만 이번 건은 특히 무겁게 봐야 해요. LiteLLM이 무슨 일을 하는 라이브러리인지 알면 바로 이해가 되실 거예요.

LiteLLM이 뭐길래

LiteLLM은 OpenAI, Anthropic, Google, AWS Bedrock, Azure 같은 수많은 LLM API를 하나의 인터페이스로 묶어주는 라이브러리이자 프록시 서버예요. 모델마다 다른 API 형식을 OpenAI 스타일 하나로 맞춰주니까, 모델을 바꿔도 코드를 거의 안 고쳐도 돼요. 그래서 사내 'AI 게이트웨이'로 LiteLLM 프록시를 띄워놓고 팀별 사용량 제한이나 비용 추적을 하는 회사도 많아요.

문제는 이 장점이 그대로 공격자에게 매력적인 표적이 된다는 거예요. LiteLLM이 깔린 환경에는 여러 회사의 API 키가 한곳에 모여 있을 가능성이 아주 높거든요. 건물 전체 열쇠를 모아둔 관리실 열쇠함 같은 거예요. 게다가 여러 AI 에이전트 프레임워크가 LiteLLM을 의존성으로 끌어오는 경우도 있어서, 내가 직접 설치한 적이 없어도 다른 패키지를 따라 들어와 있을 수 있어요.

이런 공격은 어떻게 동작할까요?

이번 건이 정확히 어디로 침투해서 어떻게 실행되는지는 원문 분석을 꼭 확인하셔야 해요. 다만 PyPI 공급망 공격의 일반적인 패턴을 알아두면 대응할 때 도움이 돼요.

먼저 공격자는 진짜 패키지 이름 그대로 새 버전을 올려요. 이름을 비슷하게 지은 가짜 패키지(타이포스쿼팅)랑은 달라요. 메인테이너 계정이나 배포용 토큰, CI 파이프라인을 탈취해서 정식 버전인 척 배포하는 거라, pip install -U litellm 한 번이면 그대로 설치돼요.

파이썬 패키지는 악성 코드를 실행할 기회가 여러 번 있어요. 설치할 때 도는 빌드 스크립트도 있고, 라이브러리를 import하는 순간도 있고요. 그중에서도 까다로운 게 .pth 파일이에요. site-packages 폴더에 있는 .pth 파일에서 import로 시작하는 줄은 파이썬 인터프리터가 켜질 때마다 자동으로 실행돼요. 그러니까 코드에서 그 라이브러리를 한 번도 안 불러도, 파이썬을 실행하기만 하면 악성 코드가 돌아가는 거죠.

자격 증명 탈취 코드는 보통 환경 변수, .env 파일, ~/.aws/credentials, ~/.ssh, ~/.kube/config, 클라우드 메타데이터 엔드포인트 같은 곳을 뒤져서 외부 서버로 빼돌려요. 백도어는 여기서 한 발 더 나가서, 나중에 공격자가 원격으로 명령을 내릴 수 있는 통로를 심어두고요.

지금 바로 확인할 것

1. 설치 여부 확인: pip show litellm이나 uv pip list로 버전을 확인하세요. requirements*.txt, poetry.lock, uv.lock 같은 잠금 파일에 1.107.0이 있는지도 찾아보시고요. CI 빌드 로그와 Docker 이미지도 빠뜨리면 안 돼요.

2. 설치된 적이 있다면 패키지 삭제로 끝나지 않아요. 그 환경에서 접근할 수 있었던 모든 비밀 값을 교체(rotate)해야 해요. LLM API 키, 클라우드 키, DB 비밀번호, GitHub 토큰까지 전부요. 클라우드 감사 로그에 이상한 호출이 없었는지 보시고, 가능하면 해당 머신이나 컨테이너는 아예 새로 만드는 게 안전해요.

3. 사내 패키지 미러 점검: Nexus나 Artifactory 같은 사내 PyPI 미러를 쓰고 있다면 해당 버전이 캐시돼 있지 않은지 확인하고 막아두세요.

계속 반복되는 공급망 공격, 어떻게 막을까

npm의 event-stream과 ua-parser-js, 리눅스 생태계를 뒤흔든 xz-utils 백도어, GitHub Actions를 거쳐 오염됐던 Ultralytics PyPI 패키지, npm을 휩쓴 Shai-Hulud 웜까지 공급망 공격은 이제 매년 터지는 일이 됐어요. AI 관련 패키지는 업데이트가 워낙 잦고 다들 최신 버전을 빨리 받는 편이라 노리기가 더 쉬워요.

효과적인 예방책도 몇 가지 있어요. 잠금 파일과 해시 검증으로 검증된 버전만 설치하는 게 기본이에요. 새 버전이 나와도 며칠 기다렸다 받는 쿨다운 정책(uv의 --exclude-newer, Dependabot의 cooldown 설정 등)도 좋아요. 오염된 버전은 대개 며칠 안에 발견돼서 내려가거든요. 그리고 장기 유효한 키를 환경 변수에 잔뜩 넣어두기보다는 비밀 관리 도구와 수명이 짧은 토큰을 쓰세요. 서버가 외부와 통신하는 경로(egress)를 꼭 필요한 곳으로만 제한해 두면 피해를 크게 줄일 수 있어요.

마무리

한 줄 정리: API 키가 모이는 곳이 제일 먼저 털려요. 오늘 우리 환경의 LiteLLM 버전부터 확인하세요.

여러분 팀은 의존성 업데이트를 어떤 기준으로 받고 계신가요? 쿨다운이나 해시 고정을 실제로 운영해 보신 분들 경험이 궁금해요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://safedep.io/litellm-pypi-compromise-credential-steale...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...