▲

GitHub, 악성 VSCode 확장을 통한 3,800개 저장소 침해 확인

 (bleepingcomputer.com)
1P by GN⁺ 18시간전 | ★ favorite | 댓글 1개
  • GitHub 내부 저장소 약 3,800개가 직원 1명의 악성 VS Code 확장 설치 뒤 침해됐으며, 현재 평가는 유출 범위를 내부 저장소로 한정함
  • GitHub는 트로이목마화된 확장을 VS Code Marketplace에서 제거하고 감염 엔드포인트를 격리했으며, 즉각적인 사고 대응에 착수함
  • TeamPCP는 GitHub 소스 코드와 비공개 코드 약 4,000개 저장소 접근을 주장하며, 탈취 데이터에 최소 5만 달러를 요구함
  • VS Code 확장은 공식 스토어에서 설치되는 플러그인이지만, 과거에도 자격 증명 탈취, 채굴기, 랜섬웨어 기능, 암호화폐 탈취 확장이 발견됨
  • GitHub는 영향을 받은 저장소 밖의 고객 데이터 침해 증거는 없다고 밝혔고, 플랫폼은 1억8,000만 명 이상 개발자가 사용함

GitHub 침해 확인과 대응

  • GitHub는 직원 1명이 악성 VS Code 확장을 설치한 뒤 내부 저장소 약 3,800개가 침해됐다고 확인함
  • 이름이 공개되지 않은 트로이목마화 확장은 VS Code Marketplace에서 제거됐고, 침해된 기기는 보호 조치됨
  • GitHub는 X 게시물에서 “오염된 VS Code 확장과 관련된 직원 기기 침해를 탐지하고 차단했다”며, 악성 확장 버전 제거, 엔드포인트 격리, 즉각적인 사고 대응 착수를 밝힘
  • 현재 평가는 활동 범위가 GitHub 내부 저장소 유출에 한정되며, 공격자가 주장한 약 3,800개 저장소 규모가 조사 결과와 대체로 일치함
  • GitHub는 전날 BleepingComputer에 내부 저장소 무단 접근 주장 조사를 진행 중이라고 밝혔고, 영향을 받은 저장소 밖에 저장된 고객 데이터가 침해됐다는 증거는 없다고 덧붙임

TeamPCP 주장과 VS Code 확장 위험

  • TeamPCP 해커 그룹은 Breached 사이버범죄 포럼에서 GitHub 소스 코드와 “비공개 코드 약 4,000개 저장소” 접근을 주장하며, 탈취 데이터에 최소 5만 달러를 요구함
  • TeamPCP는 “랜섬은 아니며 GitHub를 갈취하는 데 관심이 없다”고 했고, 구매자 1명에게 판매한 뒤 보유 데이터를 삭제하겠다고 밝힘
  • TeamPCP는 개발자 코드 플랫폼을 겨냥한 대규모 공급망 공격과 연결된 바 있으며, 대상에는 GitHub, PyPI, NPM, Docker가 포함됨
  • TeamPCP는 최근 두 명의 OpenAI 직원에게도 영향을 준 “Mini Shai-Hulud” 공급망 캠페인과도 연결됨
  • VS Code 확장은 Microsoft 코드 편집기에 기능을 추가하거나 도구를 통합하기 위해 공식 스토어인 VS Code Marketplace에서 설치하는 플러그인임
  • VS Code Marketplace에서는 과거에도 개발자 자격 증명과 민감 데이터를 훔치는 악성 확장이 반복적으로 발견됨
  • 지난해에는 설치 수 900만 회 규모의 VSCode 확장들이 보안 위험으로 제거됐고, 합법적인 개발 도구처럼 위장한 10개 확장이 XMRig 암호화폐 채굴기로 사용자를 감염시킴
  • 이후 기본적인 랜섬웨어 기능을 가진 악성 확장이 VS Code Marketplace에 올라왔고, WhiteCobra라는 위협 행위자는 암호화폐 탈취 확장 24개를 등록함
  • 올해 1월에는 AI 기반 코딩 도우미로 홍보된 설치 수 150만 회 규모의 악성 확장 2개가 감염된 개발자 시스템에서 중국 서버로 데이터를 유출함
  • GitHub 클라우드 플랫폼은 현재 400만 개 이상 조직, Fortune 100의 90%, 1억8,000만 명 이상 개발자가 사용하며, 4억2,000만 개 이상 코드 저장소에 기여하고 있음

함께 보면 좋은 글 β

▲
GN⁺ 18시간전  [-]
Hacker News 의견들

  • VSCode를 만든 회사, NPM을 가진 회사, GitHub를 가진 회사가 한자리에 모여 이 문제의 해법을 찾을 수만 있다면 좋겠음

    • Microsoft 조직도 만화가 왜 맞는지 완벽하게 보여줌

      https://bonkersworld.net/organizational-charts

    • 이런 뻔한 위험에 대해 경고가 부족했던 건 확실히 아니었음

      https://github.com/microsoft/vscode/issues/52116

    • Microsoft는 NuGet도 가진 회사임

      1년 전에 뭘 했는지 보면, NuGet에서 패키지 700개가량을 선제적으로 제거했는데 결국 오탐으로 드러났음
      올바른 일을 하기가 쉽지 않음

    • 농담이 아니라, 이런 생태계는 애초에 침해되기 쉬운 오물통처럼 설계된 셈임
      기여가 엄격히 검토되지 않는 완전 개방 생태계라면 모두 이런 문제에 노출됨
      싫다면 편집기 확장을 쓰지 말고, 제대로 감사를 받은 편집기를 쓰면 됨

      확장이나 node 패키지, PyPI 패키지를 자세히 검토하지 않고 쓰는 건 기술 부채를 쌓는 일임
      빠르게 출시하기 위해 위험을 떠안는 것이고, 나중에 통제된 방식으로 갚거나 이자가 청구될 때 감당해야 함

  • VS Code 확장은 오래전부터 무서웠고, 너무나 명백한 공격 경로였음
    특정 파일 형식을 인식했다며 확장을 설치하라는 팝업이 VSCode에 계속 뜨는데, 그 확장이 회사 소유인지 아무 개발자 소유인지 반반임
    설치 수가 수백만인 확장 중에도 처음 보면 공식 회사 확장처럼 보이는 것들이 있음
    이제는 공식 회사 소유 확장만 설치하려고 하지만, 그것조차 속는 게 아닌지 확신하기 어려운 상태라 씁쓸함

    • 이 문제는 VS Code를 훨씬 넘어섬
      모든 확장과 실행 가능한 코드가 같은 문제를 갖고 있음
      Disney가 직원이 악성코드가 포함된 BeamNG 모드를 설치해서 해킹당한 사례도 있었음

      보안을 유지하려는 회사라면 소프트웨어 설치에 엄격한 제한을 둬야 함
      예를 들어 내부에서 사전 승인된 저장소의 npm 패키지와 플러그인만 설치하게 하는 식임

    • VSCode에 중독된 사람들에게 종종 비웃음을 받으면서도 Sublime을 계속 써왔음
      “VSCode는 완벽하다”고 무비판적으로 믿던 사람들이 당하는 걸 보는 게 즐거움

    • 나도 VSCode 확장에 대해 비슷하게 편집증적으로 조심하게 됐음
      예전에는 Brackets, JetBrains, Sublime Text, Bluefish 같은 IDE에서 개발에 필요한 믿을 만한 확장 몇 개만 쓰면 됐던 기억이 남
      지금은 뭘 하든 누군가나 어떤 회사가 그 작업 전용 확장을 만들어둔 것처럼 보임

      이제는 최소한의 확장으로 최대한 많은 일을 하려고 함
      그리고 내 코드의 나머지를 GitHub에서 빼내는 것도 같이 하려 함

    • 데스크톱을 몇 초마다 스크린샷으로 찍고 OCR을 돌린 뒤, 결과를 암호화하지 않은 평문으로 디스크에 저장하자는 발상을 했던 공급업체라면 이 정도 소프트웨어 보안 수준은 예상 가능함

    • 게다가 그 확장들은 전부 자동 업데이트도 하고 싶어 함

  • 해커들이 이걸 할 만큼 충분히 긴 가동 시간을 찾아냈다는 게 더 놀라움

    • 농담을 못 알아본 사람들을 위해 말하자면, GitHub는 Microsoft가 인수한 뒤로 스스로를 안정적으로 운영하는 데 점점 더 어려움을 겪어왔음

      최근에는 다운타임이 늘면서 더 심해졌고 뉴스도 됐음

  • 이전 관련 스레드:

    GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - 2026년 5월, 댓글 321개

  • 어제 나를 당하게 한 nx console 확장이 침해된 건지 궁금함
    타이밍이 거의 똑같아 보임
    https://github.com/nrwl/nx-console/security/advisories/GHSA-... 참고

  • 이 일로 Microsoft가 VS Code 확장에 명시적인 권한 시스템을 추가하고, 개발 컨테이너 보안도 개선했으면 좋겠음

    • 오히려 사용자들, 여기서는 개발자와 유지보수자들이 Microsoft 의존도를 줄이고 특히 보안을 Microsoft에 외주 주는 일을 그만두게 되는 계기가 됐으면 함

      이제 vscode에서 벗어나야 함

    • 큰 기대는 안 함
      이 이슈는 2018년부터 열려 있음: https://github.com/microsoft/vscode/issues/52116

  • VS Code는 Electron 위에 만들어졌고, Electron에는 SUID 샌드박스 도우미가 있었거나 있어서 샌드박스화가 골치 아픔
    샌드박스 안에서 SUID 바이너리를 쉽게 실행할 수 없기 때문임
    Linux에서 샌드박싱은 극도로 어려운 작업임

    • “샌드박스가 작동하려면 Chrome에 SUID Root를 줘야 한다”는 식의 메시지를 보면 기분이 정말 나쁨
      웹 브라우저에 SUID Root를 설정하는 건 예전에는 무지한 사용자를 놀리는 농담이었고, 상상 가능한 최악의 보안 실수였음
    • 그렇다면 IDE를 Electron 위에 만들지 말아야 함
    • podman은 루트 없는 네임스페이스를 꽤 잘 처리하는 것 같음
      약간의 성능 오버헤드가 있긴 하지만 세상이 끝날 일은 아님

  • 내가 뭔가 너무 당연한 걸 놓친 걸 수도 있지만, 저장소 3,800개라니 놀랍긴 함
    그렇게 많을 줄은 몰랐음

    • 다른 사람들이 말했듯 그건 일부일 뿐임
      중간 규모의 기술 관련 회사에 있는데 GitHub 조직 하나에 7,500개 넘는 저장소가 있음
      조직이 두 개라 합치면 쉽게 1만 개를 넘김
      물론 대부분은 오래됐거나, 폐기됐거나, 샌드박스이거나, 개인 도구 같은 것들임
      GitHub라면 내부 저장소가 10만 개 이상이거나 그보다 더 많아도 놀랍지 않음

    • 예전에 다섯 or 여섯 개 GitHub 조직에 걸쳐 최소 5,000개 저장소가 있고, Perforce에도 더 많은 코드가 있던 회사에서 일한 적이 있음

      오래된 실험도 있었겠지만, 회사가 여러 영역에 발을 걸치고 있었고 몇몇 부서는 문제 하나를 해결하려고 또 다른 서비스를 만드는 걸 개의치 않았음

      내 부서의 오래된 것들은 확실히 아카이브했음
      우리는 저장소가 8개였고, 세 명이 쓰기엔 그것만으로도 충분하다고 느꼈음

    • Uber는 한때 엔지니어 2,000명에 저장소 8,000개가 있었음 - https://highscalability.com/lessons-learned-from-scaling-ube...

    • 예전에 식품 소매점에서 일한 적이 있음
      첫날에는 밖에서 보기엔 단순한 웹사이트처럼 보이니 얼마나 어렵겠냐고 생각했음
      그런데 주문용 웹사이트가 300개 넘는 저장소가 합쳐진 결과물이었음
      이번 침해에서 GitHub가 잃은 것보다 적었음
      규모가 커질수록 단순함을 유지하려면 정말 많은 노력이 듦

    • GitHub에서 일하면서 늘 좋게 봤던 점 중 하나는 회사의 많은 부분이 실제로 GitHub 위에서 운영된다는 점임
      기술팀이 아닌 팀들도 전통적인 지식노동 회사가 SharePoint를 쓰듯, 문서/SOP/디자인 등을 정리하려고 자기 저장소를 갖고 있는 경우가 많음

  • 오픈소스로 만드는 방법도 여러 가지임

    • 내부 고발을 하거나 비공개 정보를 유출하고 싶다면, 이건 꽤 좋은 방법일 수 있음
      자기 사용자 계정으로 대놓고 스크립트를 실행하지 말고, 스크래핑과 쓸모없는 기능을 같이 하는 플러그인으로 익명 업로드하면 됨
      예를 들어 어떤 부동소수점 숫자가 짝수인지 알려주는 기능 같은 것임
      물론 그런 숫자는 없음
      그다음 그걸 실행하고 피해자인 척하면 됨

  • “어제 우리는 오염된 VS Code 확장과 관련된 직원 기기 침해를 탐지하고 차단했습니다. 악성 확장 버전을 제거하고, 엔드포인트를 격리했으며, 즉시 사고 대응을 시작했습니다”

    확장을 제거했다니 참 훌륭함
    자기 직원이 감염된 뒤에야 그렇게 하는 건가?
    그리고 왜 확장 이름을 밝히지 않는 거지?

답변달기