자바스크립트 공급망 조작

이 블로그 글의 AI 요약으로 바로 가기

공포 영화에서 가장 무서운 위협은 현관문을 발로 차고 들어오는 존재가 아니라, 이미 집 안에 숨어 있는 것들, 즉 아무도 눈치채지 못한 채 벽 속에 숨어 있는 유령들이다.

현대적인 소프트웨어 공급망도 마찬가지입니다.오늘날 애플리케이션을 개발하고 배포할 때, 우리는 팀과 의도적으로 설치한 라이브러리를 신뢰하는 경향이 있습니다.

B하지만 package.json 거대하고 보이지 않는 코드의 빙산이 자리 잡고 있습니다.이것이 바로 전달적 종속성의 세계이며, 바로 이곳에서 수많은 현대적인 공급망 공격이 시작됩니다.

통제의 환상: 직접 종속성

다음 명령어를 실행하면 npm install명령어를 실행하면, 여러분이 알고 있고 신뢰하는 5~10개의 라이브러리를 추가하게 될 수 있습니다. 이것이 바로 직접 의존성입니다. 여러분은 해당 라이브러리의 GitHub 별점도 확인하고, 유지보수 빈도도 점검했으며, 그 신뢰성에 확신을 가지고 있습니다.

하지만 이 다섯 가지 라이브러리 각각이 또 다른 열 가지 라이브러리에 의존할 수 있습니다. 그리고 그 열 가지 라이브러리 역시 또 다른 열 가지 라이브러리에 의존하죠. 어느새 ‘간단한’ 웹 앱이 순식간에 1,000개가 넘는 패키지로 불어나 node_modules 디렉토리에 쌓이게 됩니다. 이것이 바로 전이적 의존성, 즉 “패키지의 패키지”이며, 이는 여러분이 실제로 프로덕션에 배포하는 코드의 대부분을 차지합니다.

`package.json` 파일을 직접 열지 않고도 설치된 직접 종속성이 무엇인지 확인하고 싶다면 package.json를 열지 않고도 설치된 직접 종속성을 확인하고 싶다면, 다음 명령어를 실행하면 됩니다. npm ls를 실행하면 됩니다. 이 명령어를 실행하면 터미널에 설치된 직접 종속성 목록이 표시됩니다.

왜 전이적 종속성이 완벽한 ‘유령’인가

전이적 의존성의 위험성은 일반적인 개발자 워크플로우에서는 이를 거의 파악하기 어렵다는 점에 있습니다. 우리는 의존성 트리의 3단계나 4단계까지 점검하는 경우가 거의 없습니다. 공격자들은 이 점을 잘 알고 있으며, 세 가지 구체적인 ‘취약점’을 악용하기 위해 전술을 바꿨습니다.

오타 스쿼팅:

인기 있는 패키지 이름과 거의 똑같이 보이는 이름을 등록하는 행위(예: lodash 대 lodas_h). 하위 레벨 의존성에서 사소한 오타 하나만 있어도 빌드 파이프라인에서 악성 스크립트가 실행될 수 있습니다.

예를 들어, 다음을 설치하고 싶다고 가정해 봅시다 express 를 설치해 API나 백엔드 서비스를 구축하려고 한다고 가정해 봅시다. 습관적으로 터미널을 열어 `express`를 설치하려다 보니, `npm install express`라고 입력해야 할 곳을 `npm install expres`라고 입력해 버립니다. 차이점은 단어에 있는 두 번째 's'를 빠뜨렸다는 것입니다. 아마도 node_modules 폴더를 확인하지 않고, 패키지가 제대로 설치되었다고 그냥 믿어버릴 가능성이 큽니다. 바로 여기서 문제가 시작될 수 있습니다.

설치하는 패키지가 무엇인지 항상 확인하십시오. 가능하면 범위 지정된 패키지를를 우선적으로 선택하십시오. 범위 지정 패키지는 대개 비공개 또는 조직이 관리하는 레지스트리에서 가져오기 때문에 신뢰성을 한층 더 높여줍니다.

의존성 혼동

빌드 시스템이 내부용 “비공개” 버전 대신 악의적인 “공개” 버전의 패키지를 가져오도록 속이는 행위입니다. 범위 지정 패키지는 종속성 혼동 공격을 완화하는 데 도움이 됩니다. 범위 지정 패키지는 대략 다음과 같은 형식을 띱니다. `@scope/your-awesome-package`.

조직이 비공개(내부) 레지스트리와 공개(npm) 레지스트리를 모두 사용하는 경우, 공격자는 비공개 패키지와 이름이 같지만 버전 번호가 더 높은 공개 패키지를 게시합니다. 다음 자료에 따르면 Spectral에 따르면, “조직의 약 49%가 종속성 혼동 공격의 위험에 노출되어 있습니다.”

“저주받은” 업데이트

공격자가 주요 프레임워크의 종속성으로 사용되는 합법적인 소형 유틸리티 라이브러리에 접근합니다. 소형 유틸리티의 예로는 `@ctrl/tinycolor` 패키지가 있습니다. 최근의 사례로는 Shai-Hulid 공급망 공격가 있는데, 이 사건에서는 해킹당한 유틸리티 라이브러리가 악성 코드를 유포하는 데 사용되었습니다. 공격자는 백도어가 포함된 “패치”를 배포합니다. 그러자 단 한 명의 개발자도 자신의 package.json을 수정하지 않았음에도 불구하고, 하룻밤 사이에 수천 개의 앱이 “장악”당하게 됩니다.

백도어(원래는 트랩도어라고 불림)는 일반적인 인증 절차를 우회하여 시스템에 대한 관리자 권한을 획득하는 은밀한 방법입니다. Malwarebytes 에는 백도어에 관한 훌륭한 기사가 있는데, 다음 인용문이 이를 아주 잘 요약하고 있습니다.

“백도어란 권한이 있는 사용자든 없는 사용자든 상관없이, 일반적인 보안 조치를 우회하여 컴퓨터 시스템, 네트워크 또는 소프트웨어 애플리케이션에서 최고 수준의 사용자 권한(일명 루트 권한)을 획득할 수 있게 해주는 모든 방법을 말합니다.”

백도어의 역사

백도어(backdoor) 또는 트랩도어(trapdoor)는 1960~1970년대에 처음 등장했습니다. 백도어가 처음 만들어진 목적은 합법적인 소프트웨어 개발자들이 시스템 개발 및 수정 과정에서 유지보수, 문제 해결을 수행하고 인증 절차를 우회할 수 있도록 하기 위함이었습니다.

백도어는 1980년대에 등장하기 시작했습니다. 이후 백도어는 악의적인 활동에 이용되기 시작했습니다. 1980년대의 가장 유명한 사건 중 하나는 1988년 모리스 웜(Morris Worm)으로, 초기 인터넷 전반에 걸쳐 시스템을 감염시켰습니다. 로버트 모리스는 1988년 모리스 웜을 제작했습니다. 이 웜은 NASA, 하버드, 스탠포드를 포함한 인터넷 전반의 여러 시스템을 감염시켰습니다. 모리스는 1986년 컴퓨터 사기 및 남용 방지법(Computer and Fraud Abuse Act)을 위반했으나, 유죄 판결을 받았음에도 불구하고 실형을 선고받지는 않았습니다.

1990년대에는 정부가 백도어를 더욱 적극적으로 활용하기 시작했다. 클리퍼 칩 은 통신 내용을 도청하려는 시도로, 결국 실패로 끝났다. 단 한 대의 전화기만 출시되었고, 1996년에 이 프로젝트는 중단되었다.

2000년대부터 2020년대까지 이어져 온 해커들의 활동은 웹 전반에 걸쳐 백도어를 이용한 본격적인 공격으로 이어지고 있습니다. 심지어 클라우드와 IoT 기기까지 침투하기 시작했습니다.

백도어 공격의 영향

백도어는 숨겨져 있다는 점에서 위험합니다. 대중문화에서는 오랫동안 백도어를 다뤄왔는데, 1983년 영화 《워게임》에는 숨겨진 접근 방식이 어떻게 작동하는지 설명하는 장면이 등장하기도 합니다. 때로는 백도어가 너무 깊숙이 숨겨져 있어 이를 발견하는 데 몇 달, 심지어 몇 년이 걸리기도 합니다.

Beyond npm audit

다음과 같은 도구들 npm audit 와 같은 도구는 좋은 첫걸음이지만, 종종 이미 문제를 일으킨 유령들만 찾아낼 뿐입니다. 공급망을 진정으로 안전하게 만들기 위해서는 사후 대응 방식에서 선제적 방식으로 전환해야 합니다.

락파일 무결성

다음 파일을 package-lock.json 또는 yarn.lock 파일을 보호 대상 문서로 취급하십시오. 이 파일의 변경 사항을 절대 무시하지 말고, CI/CD 파이프라인이 해당 버전을 엄격하게 준수하도록 해야 합니다. 한 가지 유의할 점은 락 파일을 항상 커밋해야 한다는 것입니다. 락 파일을 커밋하면 설치된 패키지의 버전을 '고정'하게 되어, 팀원 모두가 정확히 동일한 버전을 사용하게 됩니다.

그러나 무결성은 단순히 버전 번호가 일치하는 것 이상의 의미를 지닙니다. 잠금 파일에는 해결된 URL과 무결성 해시(보통 SHA-512)를 포함하고 있습니다. 이 해시는 “레지스트리 포이즌링”에 대한 주요 방어 수단입니다. 레지스트리가 침해되어 공격자가 정상 패키지를 동일한 버전의 악성 패키지로 대체하면 해시 값이 변경됩니다. npm clean-install (또는 npm ci)을 사용하면, 다운로드된 패키지의 해시가 락파일과 일치하지 않을 경우 설치가 실패합니다. 이는 코드의 “디지털 지문”과 같은 역할을 합니다. 지문이 일치하지 않으면, 유령이 파일을 조작했다는 것을 알 수 있습니다.

또한, “Lockfile Injection” 공격에 각별히 주의해야 합니다. 이는 악의적인 기여자가 단순한 종속성 업데이트처럼 보이는 Pull Request를 제출하지만, 그 안에 전이적 종속성에 대한 악성 URL을 가리키는 수정된 lockfile을 포함시키는 공격 방식입니다. 소스 코드를 검토할 때와 마찬가지로, lockfile 변경 사항도 항상 철저히 검토해야 합니다. PR이 “사소한 패치”를 명목으로 락파일에 5,000줄을 추가한다면, 의문을 제기해야 할 때입니다.

SBOM(소프트웨어 부품 목록)

<br />

자신의 “의존성 생태계”에 무엇이 포함되어 있는지 모른다면, 이를 보호할 수 없습니다. SBOM을 생성하면 소프트웨어 공급망에 포함된 모든 구성 요소에 대한 명확한 목록을 확보할 수 있습니다. SBOM을 다음과 같이 생각하십시오. 냉동 피자 뒷면에 적힌 이라고 생각하십시오. 나중에 “적색 40호”가 유독하다는 사실을 알게 된다면, 식료품 저장실을 확인하여 어떤 품목을 버려야 할지 즉시 알 수 있습니다. 소프트웨어에서 깊은 전이적 종속성에 대한 새로운 CVE(공통 취약점 및 노출)가 발표될 때, SBOM을 사용하면 모든 프로젝트를 수동으로 감사하는 대신 몇 초 만에 전체 생태계를 검색할 수 있습니다.

SBOM에 관한 주요 산업 표준은 두 가지가 있습니다: SPDX(Software Package Data Exchange) 와 CycloneDX가 있습니다. SPDX는 라이선싱 및 규정 준수를 위해 자주 선호되는 ISO 표준인 반면, CycloneDX는 애플리케이션 보안 및 공급망 분석을 위해 특별히 설계된 경량형 “보안 우선” 형식입니다.

진정으로 성숙한 보안 체계는 단순히 SBOM을 생성하는 데 그치지 않고, 이를 VEX(Vulnerability Exploitability eXchange)와 함께 활용합니다. VEX는 SBOM에서 발견된 취약점이 실제로 “도달 가능”한지, 아니면 “악용 가능”한지를 알려주는 보조 문서입니다. 이를 통해 400개의 “고(High)” 등급 경고를 마주했을 때, 무엇부터 해결해야 할지 몰라 압도되는 “취약점 피로감”을 방지할 수 있습니다. SBOM과 VEX를 결합하면, 사용 중인 라이브러리에 “유령”이 숨어 있을지라도, 그 유령은 누구에게도 해를 끼칠 수 없는 방에 갇혀 있다는 사실을 사용자에게 입증할 수 있습니다.