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

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가 인수한 뒤로 스스로를 안정적으로 운영하는 데 점점 더 어려움을 겪어왔음

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개였고, 세 명이 쓰기엔 그것만으로도 충분하다고 느꼈음

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

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

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

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

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

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