지속적 통합 및 지속적 배포CI/CD) pipeline이러한 요소들은 효율적인 소프트웨어 개발을 촉진하는 데 중추적인 역할을 합니다. 그러나 이러한 요소들이 pipeline보안이 점점 더 중요해짐에 따라, 보안 취약점으로부터 이를 보호해야 할 필요성이 더욱 두드러지고 있습니다. 본 심층 조사에서는 OWASP Top-10에서 지적된 주요 위험 요소를 해결하는 데 초점을 맞춥니다. CI/CD 보안 위험: 독성 물질 Pipeline 실행(PPE).
무엇이 독살되었는가 Pipeline 실행(PPE)
OWASP Top-10에 따르면 CI/CD 보안 위험, “중독 Pipeline 실행 (PPE) 위험이란 소스 제어 시스템에는 접근할 수 있지만 빌드 환경에는 접근할 수 없는 공격자가 시스템을 공격할 수 있는 능력을 의미합니다. 빌드 과정에 악성 코드/명령어를 삽입하여 빌드 프로세스를 조작하는 행위 pipeline 구성, 본질적으로 '독살' pipeline 빌드 프로세스의 일부로 악성 코드를 실행하는 것"
간단히 말해서, 독살당했다 Pipeline 실행(PPE)은 다음과 같은 경우에 생성됩니다. 공격자는 수정할 수 있습니다. pipeline 논리.
두 가지가있다 변종:
- 다이렉트 PPE (디-PPE): D-PPE 시나리오에서, 공격자는 CI 설정 파일을 수정합니다. 접근 권한이 있는 저장소에서 변경 사항을 적용하려면, 저장소의 보호되지 않은 원격 브랜치에 직접 변경 사항을 푸시하거나, 브랜치 또는 포크에서 변경 사항이 포함된 PR을 제출하면 됩니다. CI 이후로 pipeline 실행은 수정된 CI 구성 파일의 명령에 의해 정의되며, 공격자의 악의적인 명령은 빌드가 완료되면 빌드 노드에서 최종적으로 실행됩니다. pipeline 트리거됩니다.
- 간접 개인보호장비 (I-PPE특정 경우에는 D-PPE에 접근할 수 있는 적이 D-PPE를 사용할 수 없는 경우가 있습니다. SCM 저장소(예: 만약 pipeline CI 구성 파일은 동일한 저장소 내의 별도 보호된 브랜치에서 가져오도록 구성되어 있습니다. 이러한 시나리오에서는 독을 넣는 것보다는 pipeline 공격자는 그 자체로 참조되는 파일에 악성 코드를 삽입합니다. pipeline (예: 내부에서 참조되는 스크립트) pipeline 설정 파일)
두 경우 모두 GitHub는 수정된 내용을 실행합니다. pipeline 사전 검토나 승인이 필요 없습니다..
개인보호장비(PPE)의 조기 발견
이러한 유형의 취약점을 어떻게 탐지할 수 있을까요?
이 예를 한번 봅시다. pipeline :
더미 셸 스크립트(runtests.sh)의 내용은 다음과 같습니다.
The pipeline 그 목적은 아주 간단합니다. 검토자에게 몇 가지 예비적인 힌트를 제공하는 것입니다. Pull Request (PR) 승인 절차:
- 그것은 다음에서 작동될 것입니다. 풀 리퀘스트 (즉, PR이 생성될 때마다)
- PR 코드(즉, 기여된 코드)를 확인합니다.
- 빌드를 만들 것입니다
- 이 프로그램은 제공된 코드에 대한 테스트를 실행합니다(예: 셸 스크립트 실행).
3단계(빌드 생성)와 4단계(테스트 실행)는 코드가 컴파일되지 않거나 테스트를 통과하지 못하면 실패합니다. 따라서 이 단계들은 PR을 승인하기 위한 필요조건이지만 충분조건은 아닙니다. 모든 단계가 성공적으로 완료되면 저장소 관리자는 제출된 코드를 검토하고, 그 결과를 바탕으로 PR을 승인/거부/댓글을 남깁니다.
자이제니 스캐너
제니 CLI를 제공합니다(“자이제니 스캐너”) 내장될 수 있는 pipeline 또는 명령줄에서 실행할 수 있습니다. Xygeni Scanner는 다음을 처리합니다. pipeline취약점을 확인하기 위한 도구이며, GitHub PAT가 제공된 경우 GitHub에 연결하여 조직/저장소 수준에서 취약점을 발견합니다.
Xygeni 인벤토리
이 저장소에 대해 Xygeni Scanner를 실행하면 유용한 자산 세트( Xygeni 인벤토리인벤토리에는 다양한 유형의 항목이 포함될 것입니다. CI/CD 자산같은 :
- The SCM 시스템 리포지토리가 저장된 위치
- The SCM 플러그인 설치됨/사용됨
- The 코드 저장소 그 자체
- The SCM 회사조직 해당 저장소가 속한 곳
- The CI/CD Pipelines와 일자리
- The CI/CD 시스템 실행 pipelines
- IaC 리소스 저장소에 정의됨
- 외부 종속성
- 기타..
예시에서처럼 특정 자산 유형별로 재고를 필터링할 수 있습니다.SCM- (그리고 CICD 관련 자산)을 통해 다음과 같은 사실을 알 수 있습니다.
- SCM 시스템은 GitHub Cloud입니다.
- 해당 저장소는 GitHub 클라우드에 저장되어 있으며 특정 GitHub 조직에 속합니다.
- 두 가지가있다 pipelineGitHub 기반 (CI/CD 체계)
- 모든 pipeline 하나의 구체적인 단계를 포함합니다
위 항목을 선택하시면 pipeline 몇 가지 취약점을 발견할 수 있습니다:
- At pipeline 수준이 낮으면 두 가지 모두에 취약합니다. 직접 간접 개인보호장비.
우리는 독살당한 사람들의 세부 정보를 볼 수 있습니다. Pipeline 실행 취약점
Xygeni는 그것이 D-PPE에 취약함 왜냐하면 그것은 ~에 의해 트리거되기 때문입니다 Pull Request 이벤트가 발생하며 추가적인 보안 제어가 없으므로 모든 저장소 사용자가 수정할 수 있습니다. pipeline 그리고 그러한 수정 사항은 어떠한 검토나 승인 없이 실행될 것입니다.
마찬가지로 Xygeni도 다음과 같은 사실을 감지합니다. 개인보호장비(I-PPE)에 취약함 셸 스크립트 호출 때문에 pipeline저장소 사용자는 누구나 셸 스크립트를 수정할 수 있으며, 수정 사항은 검토나 승인 없이 실행됩니다.
더 알고 싶으십니까?
개인보호장비 악용
개인보호장비(PPE)를 효과적으로 활용하기 위해 다음과 같은 시나리오를 생각해 보겠습니다. 두 종류의 저장소 사용자:
- An 내부 사용자 (해당 저장소를 담당하는 내부 개발자)이며, 저장소에 대한 쓰기 권한을 가지고 있습니다.
- An 외부 사용자 (외부 개발자가 해당 저장소를 담당하지만 읽기 권한만 가지고 있는 경우), 즉 저장소를 분기할 수 없고 포크된 저장소에서 작업해야 하는 상황입니다.
둘 다 악의적인 공격자(또는 악의적인 행위자에 의해 사칭된 사람)라고 가정해 봅시다. 저장소에는 비밀 정보가 포함되어 있으며 둘 다 해당 정보를 원합니다. 저장소 비밀을 훔치기 위해 그리고 그것을 해커가 제어하는 서버로 보냅니다. 이를 위해 그들은 Poisoned를 악용할 것입니다. Pipeline 실행 취약점 pipeline.
외부 사용자든 내부 사용자든 두 경우 모두 창을 엽니다. Pull Request 동일한 수정 사항을 적용하면 다음과 같습니다.
- The pipeline 그리고 셸 스크립트가 수정되었습니다. 에 비밀을 읽어보세요 환경으로부터 그리고 해커가 제어하는 서버로 전송합니다.
수정 사항은 다음과 같습니다.
두 사용자 모두 생성할 것입니다 Pull Request 수정 사항 포함보도자료가 작성되면, GitHub는 두 가지 수정 사항을 모두 실행합니다. (사전 검토나 승인이 필요 없음)그 결과 다음과 같은 상황이 발생했습니다.
쓰기 사용자와 읽기 사용자 모두 동일합니다. 두 경우 모두 D-PPE와 I-PPE가 실행됩니다.차이점은 다음과 같습니다. 읽기 권한 사용자는 비밀 정보에 접근할 수 없습니다. (!!!!)
이유는 다음과 같습니다. 포크에서 생성된 PR의 경우, GitHub는 저장소의 비밀 정보에 대한 접근을 허용하지 않습니다. 읽기 권한을 가진 사용자는 비밀 키를 읽을 수는 없지만 다른 프로그램은 실행할 수 있습니다. 일반적인 공격 예로는 암호화폐 채굴 프로그램을 다운로드하는 PR을 생성하는 것이 있는데, 이렇게 하면 GitHub 러너가 악성 PR을 실행할 때 암호화폐 채굴 프로그램도 함께 실행됩니다. pipeline.
여기는 당연히 안전한 환경이 아닙니다!! 저장소 관리자는 이를 방지하기 위해 무엇을 할 수 있을까요?
구글 검색을 좀 해본 후, 저장소 관리자는 수정하기로 결정합니다. pipeline ~에 의해 트리거될 것입니다 풀 리퀘스트 타겟 이벤트. 왜냐하면. pipelinepull_request_target에서 트리거된 s는 실행을 허용하지 않습니다. pipeline 수정즉, 사용자가 어떤 수정을 하더라도 "원본"은 그대로 유지됩니다. pipeline 실행됩니다.
우리의 예를 따르면 공격은 이전과 동일하게 진행될 것입니다. 그렇다면 그 후에는 무슨 일이 일어날까요? pipeline 가감?
예상대로, D-PPE는 실행되지 않습니다. 하지만, 개인보호장비(I-PPE)가 여전히 존재하기 때문에, 읽기 권한이 있는 사용자가 이제 저장소 비밀 키에 접근할 수 있습니다!!!
읽기 권한이 있는 사용자가 이제 비밀 정보에 접근할 수 있게 된 이유는 무엇입니까? pipeline 수정할 수 없지만, 셸 스크립트는 수정할 수 있습니다. 때 pipeline pull_request_target에서 트리거되면 특권 모드로 실행됩니다. so 이것은 셸 스크립트이기도 합니다.그 결과 셸 스크립트가 저장소의 비밀 정보에 접근할 수 있게 되었습니다!
예방 조치
GitHub는 악의적인 PR로부터 보호하기 위한 몇 가지 조치를 제공합니다.
지점 보호 규칙
GitHub를 사용하면 선택한 브랜치에 대한 브랜치 보호 규칙을 정의할 수 있습니다.
보호 대상 지점에 대해 다음과 같은 정책을 지정할 수 있습니다. ~이 필요하다. pull request 병합하기 전에 (필요한 승인 횟수, 코드 소유자의 검토 등과 같은 추가 조건도 포함됩니다.)
특별히 고려해야 할 몇 가지 조건은 다음과 같습니다.
- "지정된 행위자가 필수 요건을 우회할 수 있도록 허용합니다. pull requests".
- "위 설정값을 우회하는 것을 허용하지 마십시오."
대부분의 조건은 정책을 엄격하게 만드는 반면, 이러한 조건들은 정책을 완화시켜 악의적인 활동에 대한 문을 열어줄 수 있습니다. 예를 들어, "특권"을 가진 사용자가 자격 증명을 탈취하는 경우가 이에 해당합니다.
GITHUB_TOKEN 권한을 제한합니다(최소 권한 원칙).
GitHub 토큰에 필요한 권한만 부여하세요. 이렇게 하면 공격자가 계정을 해킹하는 데 성공하더라도 피해를 최소화할 수 있습니다. pipeline그들은 별다른 일을 할 수 없을 겁니다.
문자열 보간을 피하려면 다음을 사용하세요. pipeline 환경 변수
입력 변수를 사용할 때마다 pipeline다만, 이러한 데이터는 기본적으로 "신뢰할 수 없는" 데이터로 간주해야 한다는 점에 유의하십시오(콘텐츠는 최종 사용자가 제어합니다). 참조 신뢰할 수 없는 작업 및 워크플로 보안 GitHub Actions를 배우세요.
스크립트 내에 입력 변수를 삽입할 때는 문자열 보간 대신 항상 환경 변수를 사용해야 합니다.
워크플로 실행 및 승인 요구 사항
럭셔리 공개 GitHub에서는 저장소를 지정할 수 있습니다. 외부 PR을 처리하는 방법.
GitHub 조직 설정("조직 >> 설정 >> 작업 >> 일반")에서 외부 PR을 관리하는 방법을 지정할 수 있습니다.
GitHub는 기본적으로 처음 기여하는 사용자에게 PR 승인을 요구하므로 악의적인 요청 공격을 더욱 어렵게 만듭니다. 그럼에도 불구하고 공격자는 예를 들어 무해한 코드를 기여하는 방식으로 프로젝트 관리자의 신뢰를 얻을 수 있습니다. pull request 실제 공격이 시작되기 전.
이런 의미에서 세 번째 옵션(모든 외부 협력업체의 승인 요구)은 더 높은 수준의 통제를 제공합니다.
럭셔리 사설 GitHub는 저장소 관리뿐만 아니라 조직 수준과 저장소 수준 모두에서 유용한 제어 기능을 제공합니다.
"워크플로우 실행 Pull Requests(기본적으로 선택 해제됨) 이 옵션을 선택하면 사용자는 포크된 PR에서 워크플로우를 실행할 수 있습니다(읽기 전용 권한이 있고 비밀 정보에 접근할 수 없는 GITHUB_TOKEN 사용). 이 옵션을 마지막 옵션(“)과 함께 선택하면포크된 PR 워크플로에 대한 승인 요구 사항”), 위에서 설명한 것처럼 비공개 저장소와 유사한 정책을 적용할 수 있습니다.
읽기 전용 사용자의 PPE 취약점 공격 사례에서 보았듯이, 포크에서 워크플로우를 실행할 수 있도록 허용 pull requests 위험해요!!
나머지 옵션(“포크에서 워크플로우로 쓰기 토큰을 전송합니다. pull requests"및"워크플로에 비밀 키와 변수를 전송합니다. pull requests") 보안 수준을 낮추다 포크 PR에 적용됩니다.
포크 정책은 조직 수준 또는 저장소 수준에서 정의할 수 있습니다. 조직 수준에서 정책이 비활성화된 경우 저장소 수준에서는 활성화할 수 없습니다. 하지만 조직 수준에서 정책이 활성화된 경우 저장소 수준에서는 비활성화할 수 있습니다.
요점을 되풀이하다
우리는 여러분이 그러한 것들이 가져올 결과를 이해하셨기를 바랍니다. pipeline 독에 취약함 Pipeline 실행. 너무 쉽습니다. commit 취약한 pipeline그리고 안전한 해결책을 마련하기는 어렵습니다.
따라서 Xygeni Scanner를 사용하여 이러한 취약점을 파악하는 것은 매우 중요합니다.
취약점의 존재를 알지 못하면 해결할 수 없습니다!
하지만… 아직 해결되지 않은 질문이 하나 남아 있습니다… 개인보호장비(I-PPE) 착용을 피하는 방법은 무엇일까요?
이것이 바로 다음 게시글의 주제입니다 🙂 간접 중독 Pipeline 실행 (I-PPE) !!
