LiteLLM PyPI 패키지 공급망 공격, TeamPCP가 노린 새로운 사이버 위협의 실태와 교훈

핵심 정리

  • LiteLLM PyPI 패키지가 TeamPCP 해킹 그룹에 의해 공급망 공격을 당해, 악성코드가 삽입된 버전이 유포됨
  • 크리덴셜 탈취, Kubernetes 네트워크 조작, 백도어 등 주요 위협이 포함돼 DevOps 환경에 직접적인 영향을 줌
  • 체계적 패키지 검증, 자동화된 보안진단, 개발자 인식 개선 등 오픈소스 공급망 보안 강화가 필수적임

“오픈소스의 신뢰는 관리와 협력, 그리고 끊임없는 경계에서 시작된다.”

서론: LiteLLM 패키지 및 PyPI 생태계의 의미

Python 패키지 저장소(PyPI)는 전 세계 개발자들이 Python 프로젝트를 위해 의존하는 핵심 인프라입니다. 수십만 개의 패키지가 등록되어 있으며, 매일 수백만 건의 다운로드가 발생합니다. LiteLLM은 대형 언어 모델(LLM) 호출을 위한 표준화된 오픈소스 라이브러리로, AI 애플리케이션 개발자들에게 널리 사용됩니다.

하지만 중앙화된 패키지 생태계는 사이버 공격자에게 매우 매력적인 표적이 됩니다. 단일 취약점만으로 수천, 수백만 명의 개발자와 그들이 만든 소프트웨어에까지 영향을 미칠 수 있기 때문입니다.

사건 개요: TeamPCP의 공급망 공격 전개

2024년 6월 5일, PyPI의 인기 라이브러리 LiteLLM이 TeamPCP라는 해킹 그룹에 의해 악성코드가 삽입되어 유포된 공급망 공격 사건이 공식적으로 확인되었습니다. 해당 공격자는 LiteLLM의 1.82.7, 1.82.8 두 개 버전에 악성 코드를 추가하여 배포했습니다.

TeamPCP는 과거에도 여러 차례 공급망 공격을 일으킨 그룹으로 알려져 있습니다. 이번 사건은 DevOps/CI 도구(예: Trivy)의 취약점, 자동화된 패키지 배포 환경의 보안 허점을 노린 정황이 포착되었습니다.

악성코드 분석: 삽입된 코드와 주요 위협

LiteLLM 1.82.7, 1.82.8 버전에는 다음과 같은 주요 악성 기능이 포함되었습니다.

  • 크리덴셜 탈취: 환경 변수와 설정 파일에서 API 키, 비밀키, 데이터베이스 접속 정보 등 민감 정보를 수집하여 탈취합니다.
  • Kubernetes 네트워크 조작: Kubernetes 환경의 네트워크 라우팅을 조작할 수 있는 기능이 내장돼 있어, 클러스터 내에서 공격자의 권한을 확장할 수 있습니다.
  • 백도어: 공격자가 시스템에 재접근할 수 있도록 하는 백도어 기능이 존재해, 최초 침입 이후에도 지속적인 위협이 이어질 수 있습니다.

이 악성 코드는 패키지 설치와 동시에 자동으로 실행되어, 개발환경과 서버에 즉각적인 위협을 가합니다.

DevOps/CI 환경의 공급망 보안 취약지점

이번 LiteLLM 사건은 DevOps와 CI/CD 환경이 갖는 공급망 보안 취약점을 여실히 보여줍니다.

자동 패키지 배포의 위험: 많은 조직이 CI/CD 파이프라인을 통해 패키지 빌드와 배포를 자동화하고 있습니다. 이 과정에서 단 하나의 취약점 혹은 검증 미비가 전체 환경을 위험에 빠뜨릴 수 있습니다.

의존성 신뢰와 검토 부족: 개발자들은 종종 외부 패키지를 신뢰해 상세한 검토 없이 설치하는 경향이 있습니다. LiteLLM처럼 유명한 패키지일수록 노출 위험이 커집니다.

보안 도구의 오용 가능성: 심지어 보안점검을 위한 외부 도구(Trivy 등)도 보안적으로 잘 관리되지 않으면 오히려 공격에 악용될 수 있음을 이번 사건은 시사합니다.

실제 영향 및 피해 현황

TeamPCP는 이번 공격을 통해 “수십만 대 기기(Hundreds of thousands devices)”에서 민감 정보를 탈취했다고 주장합니다. 그러나 실제 피해 규모는 독립적인 검증이 필요합니다.

LiteLLM 의존도가 높은 AI/LLM 개발기업, 스타트업, 데이터 사이언스 조직, 연구기관 등 다양한 곳이 잠재적 피해자로 분류됩니다. 특히 Kubernetes 환경에서 LiteLLM을 사용할 경우, 클러스터 내로 위협이 확대될 수 있습니다.

긴급 대응 방법 및 재발 방지책

  • 빠른 버전 확인: LiteLLM 1.82.7, 1.82.8 사용 여부를 즉시 점검하고, 해당되는 경우 빠른 업그레이드 또는 이전 버전으로 전환해야 합니다.
  • 최신 보안 패치 적용: 공식 보안 공지사항을 확인하고, 신속히 보안 패치를 적용해야 합니다.
  • 전체 파이프라인 점검: 소스코드 저장소, CI/CD 파이프라인에도 악성코드가 남아있는지 점검이 필요합니다.
  • 자격 증명 전면 교체: 의심스러운 활동이 발견됐다면, API 키, 비밀키, 데이터베이스 접속 정보 등을 모두 즉시 변경해야 합니다.
  • 의존성 스캐닝과 검증 강화: 패키지 설치 전후로 보안 스캐닝 및 서명 검증 등 절차를 엄격히 해야 하며, 자동화된 점검 단계도 도입하는 것이 좋습니다.

오픈소스 생태계 보안 강화의 시사점

이번 LiteLLM 공급망 공격은 오픈소스 생태계 전반에 경고 신호를 보내고 있습니다.

  • 패키지 게시자에 대한 2단계 인증 도입: 모든 패키지 게시자 계정에 대해 멀티 팩터 인증(2FA, MFA)을 의무화해 계정 탈취를 방지해야 합니다.
  • 패키지 서명 및 유효성 검증 체계 강화: 패키지 서명 도입과 배포 전 사전 검증을 철저히 할 필요가 있습니다.
  • 자동화된 악성행위 탐지 체계 구축: 이상행위를 탐지하는 실시간 모니터링 시스템 운영이 필수입니다.
  • 개발자 보안교육 강화: 공급망 공격의 위험성과 안전한 패키지 설치 및 관리법에 대한 꾸준한 교육이 중요합니다.

결론

LiteLLM 공급망 공격은 현대 소프트웨어 개발이 안고 있는 심각한 취약점을 드러내는 사건입니다. 자동화와 오픈소스 의존성이 효율성을 높이는 반면, 대규모 공격의 표적이 될 수 있다는 경고입니다.

앞으로도 이 같은 공급망 공격은 계속될 것으로 보이므로, 개발자 및 조직 모두 주기적인 버전 점검과 보안 관행 재정비, 그리고 공급망 보안 역량 강화를 게을리해선 안 됩니다.

오픈소스의 안전은 개발자와 조직, 그리고 레포지토리 운영자와 보안 커뮤니티가 힘을 모아 신뢰할 수 있는 생태계를 지속적으로 구축해야만 지킬 수 있습니다.

  • 공개 패키지 공급망 보안 사고는 개발자와 조직에 실질적 피해를 줄 수 있음에 유의해야 한다.
  • 주요 오픈소스 사용 전후로 반드시 취약점 점검 및 검증 절차를 구축해야 위험을 차단할 수 있다.
  • 신뢰할 수 있는 패키지 배포와 자동화된 모니터링 시스템이 오픈소스 생태계의 기본이 되어야 한다.

TAG : LiteLLM, PyPI, TeamPCP, 공급망공격, 크리덴셜탈취, Kubernetes, DevOps, 오픈소스보안, 백도어, 패키지서명

댓글 남기기