▲
GN⁺ 2달전 | parent | ★ favorite | on: LiteLLM 1.82.7 및 1.82.8 PyPI 패키지 침해 사건(github.com/BerriAI)
Hacker News 의견들

  • LiteLLM의 메인테이너임. 현재 상황은 아직 조사 중이지만, 지금까지 파악된 내용은 다음과 같음

    1. 문제는 CI/CD에서 사용된 trivy에서 비롯된 것으로 보임 (관련 검색 링크, 분석 글)
    2. proxy docker를 사용하는 경우 영향 없음. requirements.txt에서 버전을 고정했기 때문임
    3. PyPI에서 해당 패키지를 격리 조치하여 다운로드가 차단됨
      현재 원인 분석과 보안 강화 방안을 검토 중이며, 불편을 끼쳐 죄송함
    • 영향을 받은 버전(v1.82.7, v1.82.8)은 PyPI에서 삭제했음. 모든 maintainer 계정과 키(GitHub, Docker, CircleCI, pip)를 교체함. 여전히 프로젝트 전체를 스캔 중이며, 보안 전문가의 도움을 환영함 (연락: krrish@berri.ai)
    • 누군가 내 개인 GitHub 계정도 침해된 것 같다고 함. 검색 결과에서 관련 흔적이 보인다고 함
    • “미안하다”는 내 표현이 인간적이었다고 말해줘서 고마움. 형식적인 사과문 대신 진심을 담은 대응이 낫다는 피드백이 힘이 됨
    • 왜 자격 증명 회전이 즉시 이루어지지 않았는지 묻는 질문이 있었음. 짧은 시간 내에 인지하지 못한 이유를 설명해야 할 듯함
    • 누군가 자신의 시스템에서 설치된 litellm 버전을 찾는 간단한 스크립트를 만들어 공유함 (스크립트 링크). 완벽하진 않지만 conda, .venv, uv, 시스템 환경을 빠르게 스캔할 수 있다고 함

  • 우리는 여전히 의존성과 개발 환경을 신뢰할 수 없음. dev container는 격리가 부족하고 사용성도 떨어짐. 이제는 sandbox 기반의 개발 환경으로 전환해야 함. VM 수준의 격리, egress 필터, seccomp, gVisor 같은 방어 계층을 갖춘 환경이 필요함. 이런 환경이라면 침해가 발생해도 컨테이너가 바로 종료되고, 문제를 쉽게 식별할 수 있음

    • 지난 50년간의 보안 단축 습관이 결국 부메랑이 되어 돌아온 것 같음. 이제는 신뢰 기반의 개발 문화가 끝나가고 있음. 단순한 샌드박싱을 넘어 보안 모델 자체의 재설계가 필요함
    • 이제는 “예전처럼”이라는 말이 통하지 않음. 암호학적으로 검증 가능한 안전성이 필수임. Red Hat의 DISA STIG처럼 외부 저장소 사용을 금지하는 방향으로 가야 함
    • 자격 증명을 컨테이너로부터 격리하는 내 프로젝트에 대한 의견을 구함 (tightbeam, airlock)
    • 나는 smolvm이라는 오픈소스 프로젝트를 개발 중임 (링크). VM 수준의 격리와 컨테이너 지원을 결합한 기술로, 완전한 가상 머신 단위 배포를 목표로 함. 함께 협력할 사람을 찾고 있음
    • 최근의 공급망 공격 중 dev container 탈출이 실제로 있었는지 궁금하다는 질문이 나옴

  • macOS용으로 만든 canary 도구를 소개함 (링크). 패키지가 접근해서는 안 될 파일을 탐지하는 간단한 Go 바이너리임. WebDAV나 NFS로 가짜 비밀 정보를 노출하고, 접근 시 알림을 보냄. honeypot 접근법으로 이상 행위를 감지할 수 있음

  • 최근 몇 주간의 TeamPCP 활동과 관련된 사건임. 내가 정리한 타임라인이 도움이 될 것 같음

    • 훌륭한 정리라는 피드백을 받음. 다만 “플레이리스트”가 인상적이었다는 농담도 있었음
    • TeamPCP 이름은 여러 곳에서 봤지만, 이렇게 한눈에 정리된 건 처음이라는 반응이 있었음
    • 업데이트를 이렇게 빠르게 유지하는 방법이 궁금하다는 질문이 있었음

  • GitHub의 스팸 탐지 시스템이 너무 약하다는 지적이 있었음. litellm 이슈에 170개 이상의 스팸 댓글이 달렸다고 함

    • 며칠 전 trivy 저장소에서도 같은 일이 있었음. 해킹 관련 토론이 닫히자 700개 이상의 스팸 댓글이 달림. 일부는 실제 활동 이력이 있는 계정이었음. 자격 증명 탈취형 공격이 광범위하게 퍼진 것 같음. 여러 계정이 2월에 “Update workflow configuration”이라는 커밋으로 CI에 credential stealer를 심은 흔적이 있음
    • GitHub에서 스팸을 신고하려면 여러 단계를 거쳐야 해서 비효율적이라는 불만이 있었음
    • 일부는 단순한 봇 계정일 가능성도 언급됨

  • 이런 일이 언젠가 일어날 거라 예상했음. 의존성 버전 고정을 통해 방어하려 했지만, 그마저도 완벽하지 않음. 오픈소스의 공급망 복잡성 때문에 모든 코드를 검증하는 건 불가능함. LLM 덕분에 악성 코드가 대량으로 퍼질 위험이 100배는 커졌음

    • Rust 생태계는 의존성 트리가 너무 깊어서 검증이 어렵다는 의견이 있었음. Rust, Node, Python 모두 비슷한 문제를 겪고 있음. 반면 C/C++은 시스템 패키지 매니저를 쓰기 때문에 의존성 추가 비용이 높아 상대적으로 안전함

  • 만약 AI가 작성한 코드가 LLVM이나 Linux에 침투한다면, 우리는 진정으로 “trusting trust” 문제를 마주하게 될 것임

    • “Trusting Trust” 문제는 이미 Diverse Double-Compiling 방식으로 해결책이 제시된 바 있음. 하지만 공급망 공격은 여전히 어려운 과제임. AI는 단지 공격의 규모를 키우는 도구일 뿐임
    • 이제는 모든 것이 불안함. airgap 환경만이 안전할지도 모름. 하지만 대부분의 데이터는 클라우드에 있고, 우리는 그 백업조차 통제할 수 없음
    • 결정적 빌드 체인을 통해 완전히 검증 가능한 소프트웨어를 만드는 시도가 진행 중임. Debian의 93% 패키지가 재현 가능한 빌드임. 하지만 여전히 많은 개발자가 “curl | bash”를 아무렇지 않게 실행함. XZ 백도어 사건은 이런 현실을 일깨워준 사례였음
    • LLM이 커널 코드를 학습하지 못하도록 내부 API를 자주 변경하는 것이 유일한 방어책이라는 의견도 있었음
    • 만약 이런 공격이 현실화된다면, 정부 서버나 클라우드 인프라가 대규모 피해를 입을 수 있음. 특히 국가 단위의 해킹이 결합되면 피해 규모는 수조 달러에 이를 수 있음. 그래도 Linux는 상대적으로 안전하다고 생각함

  • LiteLLM의 SOC2 감사기관이 Delve였다는 사실이 언급됨.

    • 하지만 SOC2 인증이 이런 공격을 막을 수 있었을지는 의문임. 실제로 SOC2는 완전한 방패가 되지 못한다는 경험담이 공유됨

  • Harbor를 설치했더니 CPU가 100%로 치솟으며 시스템이 멈췄음. grep -r rpcuser\rpcpassword 프로세스가 암호화폐 지갑 탐색을 시도한 것으로 보임. 다행히 백도어는 설치되지 않았음

    • browser-use에서도 같은 경험을 했다는 사람이 있었음. litellm이 종속성으로 설치되었고, 시스템이 멈췄음. GitHub과 HuggingFace 토큰을 무효화했지만, OS 재설치가 필요할지 물어봄
    • “프로세스를 어떻게 그렇게 빨리 확인했냐”는 질문이 있었음. Activity Monitor를 항상 켜두는지 궁금하다고 함
    • “Harness가 뭐냐”는 질문도 나옴

  • 이번 사건은 Trivy를 해킹한 TeamPCP와 동일한 공격 그룹의 소행으로 보임. 이슈에 봇 댓글이 넘쳐나는 것도 같은 패턴임. LLM을 활용한 자동화 공격일 가능성이 높음

    • 공격자가 왜 봇 댓글을 달아 이슈를 도배하는지 궁금하다는 질문이 있었음. 아마도 혼란 유발과 대응 지연이 목적일 것 같음