종속성-혼란-버전-고정

버전 고정 부족 및 종속성 혼란

소프트웨어 개발에서는 자체 구성 요소와 타사 구성 요소 또는 산출물 모두에 의존합니다. 유연한 의존성 관리는 현대 소프트웨어 개발에 필수적입니다. NPM과 같은 패키지 관리자는 이러한 의존성 관리를 지원합니다. 메이븐삐악 삐악 울다 or NuGet 이러한 도구들은 소프트웨어 종속성을 지정하는 데 자주 사용됩니다. 이러한 도구들은 보안보다는 편의성과 사용 편의성을 염두에 두고 설계되었습니다.

 

문제

문제는 개발자에게 유연성과 사용 편의성을 제공한다는 점이 악의적인 공격자들을 끌어들이는 요인이 된다는 것입니다. 이들은 소프트웨어 의존성을 자신들의 사업에 매우 매력적인 요소로 여깁니다. 그 결과, 악의적인 공격자들은 여기에 제시된 모든 가능한 공격 경로를 동원했습니다. 출처: "배신자의 칼 컬렉션: 오픈 소스 소프트웨어 공급망 공격 검토"

이 글에서는 다운로드할 버전이 고정되어 있지 않고 특정 범위 내에 있어야 하는 개방형 버전 선언의 사용에 대해 살펴보겠습니다. 빌드 시 패키지 관리자는 지정된 버전 범위와 호환되는 가장 높은 버전을 선택하여 다운로드/설치합니다.

서로 다른 패키지 관리자의 의존성 선언에서 개방형 선언을 예시로 들어 보겠습니다.

      • 국립민간정비협회(NPM): package.json

    {

     

       ...

       "종속성": {
          ...
          "허용": ">=1.3.8",
          “lodash”: “~4.16.0”,
          ...
       },
       ...
    }

    accepts 패키지의 현재 버전 중 1.3.8 이상인 가장 큰 버전과 lodash의 4.16.x 범위에 있는 가장 큰 '패치' 업데이트가 설치됩니다.

        • 메이븐 : pom.xml

      ...

      ...

           commons-io
           commons-io
           풀어 주다

      ...

      ...

      commons-io의 최신 릴리스(jar 파일)가 종속성으로 추가됩니다.

          • 씨: setup.py

        ...
        설정(
            ...
            install_requires=['peppercorn', 'launchpadlib'],
            ...
        )
        ...

        이러한 개방형 버전 체계에는 장단점이 있습니다. 장점은 최신 버전이 더 빨리 출시된다는 점입니다. 보통 기능 및 품질 개선, 버그 수정, 보안 패치가 포함되어 있으며 자동으로 업그레이드됩니다. 대부분의 실제 프로젝트에서는 심각한 보안 취약점을 제외하고는 이전 마이너 릴리스에 수정 사항이 백포트되지 않는다는 점에 유의하십시오. 오픈 소스 버전은 라이브러리에서 모든 종속성을 해결할 때 설치해야 하는 버전 수를 줄이는 데에도 유용합니다.

        하지만 개방형 버전 범위에는 단점이 있습니다. 빌드 시 어떤 버전이 설치될지 정확히 알 수 없고, 빌드를 반복할 수 없습니다. 또한 다음과 같은 문제점도 있습니다. 어두운 오픈 버전 정책을 지지하는 것이 좋습니다. 악의적인 공격자가 공개 저장소에 높은 버전의 악성 구성 요소를 게시하여 오픈 버전 범위와 호환되도록 만들면, 다음 빌드에 해당 악성 구성 요소가 포함될 수 있으며, 심지어 자동으로 실행되는 설치 스크립트에서 악성코드가 실행될 수도 있습니다. 공격 페이로드를 난독화하는 것은 일종의 기술입니다.

        이것은 버전 고정 기능 부족 발행물.

        악의적인 공격자들은 항상 인기 있는 오픈 소스 패키지의 악성 버전을 배포하려고 시도합니다. 이들은 비밀 유출을 통해 패키지 저장소의 키에 접근하거나, 사회 공학적 기법을 사용하거나, 겉보기에 유용한 패키지에 악성 종속성을 숨기는 등의 방법을 사용합니다. pull request심지어 일부 작가들조차 어느 날 세상이 불공평하다고 생각하여 고객들에게 등을 돌리기도 합니다. 시위용품 개별 포장 그대로!

        이제 여러분이 내부 구성 요소와 오픈 소스 구성 요소를 함께 사용하는 조직에서 일하고 있다고 상상해 보세요.
        악의적인 공격자가 이러한 내부 구성 요소의 이름을 알고 있다면, 동일한 이름의 구성 요소를 공개 저장소에 게시할 수 있습니다. 대부분의 패키지 관리자는 공개 구성 요소를 먼저 가져오고, 버전이 제대로 선택되었고 선언된 종속성의 버전이 오픈 소스인 경우, 문제가 발생합니다! 이 문제는 바로 이러한 맥락에서 명명되었습니다. 의존성 혼란.

        예를 들어 보겠습니다. 우리 NPM 프로젝트에 비공개 컴포넌트에 대한 의존성이 있다고 가정해 봅시다.

            • 국립민간정비협회(NPM): package.json

          {
            "이름": "내 프로젝트",

           

            ...
            "종속성": {

              ...
              “my-private-dep”: “>=1.0.0”,

              ...

             }

             ...

          }

           

          공격자는 my-private-dep의 높은 주 버전(예: 99.0.0)을 생성하여 가짜 계정으로 공개 npm 저장소에 게시할 수 있습니다(공격자는 내 조직과 아무런 관련이 없습니다). NPM 패키지 관리자는 악성 종속성을 설치하며, 이는 종종 심각한 결과를 초래합니다.

          해법

          소프트웨어 빌드 프로세스에서 이러한 문제를 방지하려면 사용되는 기술에 따라 달라지는 구성 요소 버전을 선언하는 방법에 대한 엄격한 규범을 따라야 합니다. 중요한 것은 저장소에 게시된 패키지의 특정 버전은 변경 불가능해야 한다는 것입니다(보안상의 이유뿐만 아니라 종속성 문제를 방지하기 위해서도).

          일반적인 아이디어는 고정시키는 것입니다.) 버전을 검사하고, 구성 요소의 고정 버전(모든 전이적 종속성을 포함)에 악성코드가 없는지 항상 확인하며, 이는 다음 덕분에 가능합니다. 잠금 파일 많은 패키지 관리자가 제공하는 기능입니다. 다양한 패키지 관리자에서 버전 고정이 어떻게 작동하는지 살펴보겠습니다. 여기에는 미묘한 균형점이 있습니다. 잦은 버전 업데이트 알려진 취약점을 수정하기 위해 버전 고정 비결정적 빌드 및 잠재적인 공급망 공격을 방지하기 위해서입니다.

              • NPM:
                npm 또는 yarn 패키지 관리자는 모든 직접 및 간접 종속성에 대한 고정 버전을 나열하는 서로 다른 잠금 파일(각각 npm-shrinkwrap.json/package-lock.json 또는 yarn.lock)을 사용합니다. 이러한 잠금 파일은 버전 관리 시스템에 포함되어야 하며, 그렇지 않으면 다른 개발자나 빌드 노드에서 서로 다른 버전이 사용될 수 있습니다. 개발 환경에서 종속성을 업데이트해야 하는 경우(예: 보안 패치 설치)를 제외하고는 npm install 사용을 피하십시오. 일반적으로 보다 결정적인 npm ci(클린 설치)를 사용하는 것이 좋습니다. 이렇게 하면 패키지 관리자가 잠금 파일을 사용하거나, 잠금 파일이 없거나 package.json과 일치하지 않으면 오류를 발생시키며 종료됩니다. 나열된 버전이 악성코드 검사를 거친 경우, 잠금 파일은 빌드 시 문제가 발생하지 않도록 보장합니다.

                내부 구성 요소의 경우 생성을 권장합니다. NPM 범위 조직에서 관리하는 범위(예: @myorg)를 사용하고, 해당 범위를 종속성(예: @myorg/my-private-dep)에 적용하여 비공개로만 볼 수 있도록 할 수 있습니다. 이렇게 하면 차단됩니다. 의존성 혼란 쓰기 권한이 있는 조직 구성원만 해당 범위로 패키지를 게시할 수 있으므로 공격에 취약합니다.

              • 메이븐:
                Maven/Gradle에는 잠금 파일이 없습니다(하지만 다음을 참조하세요). 이 StackOverflow 게시글).

                Maven/Gradle에서는 다른 생태계만큼 버전 범위를 많이 사용하지 않습니다. 따라서 버전 범위 사용을 피하는 것이 좋습니다. 버전 범위 최신 또는 릴리스 메타 버전을 확인하세요. 간접 버전도 확인해야 합니다. 버전 Maven 플러그인 버전 관리에 유용한 도구입니다.

                참고로 Maven은 항상 조직 범위(의존성의 groupId 부분)라는 개념을 가지고 있었으며, 해당 생태계에서는 의존성 혼동이 전혀 문제가 되지 않는 것 같습니다.

              • 삐악 삐악 울다:
                파이썬에는 잠금 파일을 처리하는 다양한 도구가 있습니다.

                피펜이는 Pipfile.lock 잠금 파일을 생성합니다.
                이는 poetry.lock 파일을 생성합니다.
                피프 동결`pip install -r requirements.txt` 명령어는 잠금 파일 역할을 하는 `requirements.txt` 파일을 생성합니다. `==` 연산자를 사용하여 모든 종속성이 고정된 버전을 사용하는지 확인합니다. 그런 다음 `pip install -r requirements.txt` 명령어를 실행하면 고정된 종속성이 사용됩니다.

            위의 잠금 파일은 버전 관리 대상이어야 하며, 선택한 빌드 명령은 해당 잠금 파일을 사용해야 한다는 점을 다시 한번 알려드립니다.

            pip에서 일반적으로 사용되는 패키지 저장소(PyPI)는 명명 범위가 없으므로 종속성 혼동 공격에 취약합니다. 파이썬 생태계에서 의존성 혼동을 피하는 방법 이는 쉽지 않으며, 일부 저자는 PyPI에서 가져온 공개 종속성에 대한 프록시 역할을 하는 내부 저장소를 사용하되, 비공개 종속성은 먼저 내부 저장소에서 가져오는 것을 권장합니다(-index-url은 PyPI가 아닌 내부 저장소를 가리켜야 하며, –extra-index-url은 제거해야 합니다).

            실제 공격 몇 건

            Getcookies 공격: 공격자 dustin87은 인기 있는 npm 메일파서 패키지에 RCE 백도어가 포함된 악성 패키지(gCOMMANDhDATAi)에 대한 간접적인 종속성을 추가했습니다.

            JSON.stringify(req.headers).replace(/g([a-f0-9]{4})h((?:[a-f0-9]{2})+)i/gi, (o, p, v) => {})

            검토자도 없이 사용이 중단된 상태였음에도 불구하고, mailparser는 여전히 매주 약 64,000건의 다운로드를 기록했습니다. 이는 원격 코드 실행(RCE) 공격이 실제로 실행되지는 않았지만, 아슬아슬하게 공격을 피한 사례였습니다.cis에디션.

            NPM이 게시함 이 게시물에 getcookies 공격에 대한 자세한 내용입니다.

            의존성 혼란:

            알렉스 비르산은 2021년에 의존성 혼동 문제를 발견하고 "애플, 마이크로소프트, 그리고 수십 개의 다른 회사들을 해킹한 방법".

            npm에서 `@myorg`와 같은 조직 범위는 예약되어 있어야 하며, 내부 패키지는 해당 범위를 사용하도록 수정해야 한다는 점을 기억하세요.

            pip를 사용하는 경우, 일반적인 공개 레지스트리인 PyPI에는 스코프/네임스페이스가 없습니다. 각 비공개 패키지는 내부 패키지와 동일한 이름을 가진 비어 있는 공개 패키지 스쿼트를 가질 수 있으며, 사용 시 오류를 발생시켜 실수로 다운로드되었을 경우 식별할 수 있습니다.

            노드-ipc:

            러시아-우크라이나 전쟁이 발발했을 때, 해당 패키지 소유자는 러시아와 벨라루스 호스트에 설치될 경우 임의의 파일을 삭제하는 악성 코드를 삽입했습니다. ssl-geospec.js 파일이 바로 그러한 지리적 구분 작업을 수행했습니다.

            흥미롭게도, 인기 있는 Vue.js 프레임워크와 같은 다른 패키지들은 node-ipc 종속성에 대해 오픈 소스 버전을 사용했고, 해당 프레임워크의 관리자들은 보상을 받았습니다. 긴급 항소 노드-IPC 종속성을 안전한 버전으로 고정합니다.

            이 게시글에 더 자세한 내용이 있습니다 이번 사보타주는 다른 사보타주보다 한 단계 더 나아간 것입니다. 프로테스트웨어 문제.

             

            끝 맺는 말

            오픈 버전은 다음과 같아야 합니다. 못 통합 소프트웨어 프로젝트에서 사용될 수 있습니다. 하지만 빌드를 재현할 수 없게 만들고, 공격자는 이를 악용하여 앞서 언급한 종속성 혼란과 같은 종속성 트리에 대한 공격을 통해 악성코드를 주입할 수 있습니다.

            잘못된 설정과 같은 것들 오픈 버전, 버전 고정 부족 또는 범위가 지정되지 않은 내부 구성 요소 이러한 문제는 피해야 합니다. 우선 이러한 문제를 감지하고, 발견 시 빌드를 차단하는 등의 조치를 취하며, 표준화된 프로토콜을 마련해야 합니다.

            종속성에서 발생하는 결함 및 잘못된 구성을 자동으로 감지하고, 특정 공급망 공격에 취약할 수 있는 의심스러운 종속성을 보고합니다. 의존성 혼란실행 가능한 해결 도구를 모두 갖추는 것이 주요 목표 중 하나입니다. Xygeni 플랫폼.

            더 읽으려면
            Ohm M., Plate H., Sykosch A., Meier M.: “배신자의 칼 컬렉션: 오픈 소스 소프트웨어 공급망 공격 검토”. DIMVA 2020. 컴퓨터 과학 강의록, 12223권. Springer – 2020 (의존성 공격 트리 그림의 출처).
            @adam-npm: “악성 모듈로 신고됨: getcookies“. npm 블로그 (보관됨) – 2018년 5월 2일.
            알렉스 버산: “애플, 마이크로소프트, 그리고 수십 개의 다른 회사들을 해킹한 방법". Medium – 2021년 2월 9일.
            액스 샤르마: “대규모 방해 공작: 유명 npm 패키지가 우크라이나 전쟁에 항의하기 위해 파일을 삭제했습니다.블리핑컴퓨터 - 2022년 3월 17일

            sca-tools-software-composition-analysis-tools
            소프트웨어 위험을 우선순위화하고, 해결하고, 보호하십시오.
            무료 계정을 만드세요.
            신용 카드가 필요하지 않습니다.

            소프트웨어 개발 및 제공을 안전하게 보호하세요

            Xygeni 제품군과 함께