이전 게시물에서는 우리는 직접 중독을 감지하고 예방하는 방법을 살펴보았습니다. Pipeline 실행(D-PPE). 또한 해당 취약점을 탐지하는 방법도 살펴보았습니다. 자이제니 스캐너또한 몇 가지 보호 메커니즘도 포함되어 있습니다.
중독 Pipeline 실행 (PPE)는 공격자가 수정할 수 있을 때 발생합니다. pipeline 논리는 다음 두 가지 방식 중 하나로 해석될 수 있습니다.
- CI 설정 파일을 수정함으로써 ( pipeline) -> 직접 개인보호장비(D-PPE)
- 참조하는 파일을 수정함으로써 pipeline (예: 내부에서 참조되는 스크립트) pipeline 설정 파일) -> 간접 개인보호장비(I-PPE)
이번 글에서는 간접 PPE에 대해 자세히 살펴보겠습니다. 하지만 그 전에, 이전 글의 보충 설명으로 GitHub가 실행을 어떻게 관리하는지 먼저 알아보겠습니다. pipeline그리고 D-PPE에 대한 보호 메커니즘은 무엇입니까?
GitHub는 실행을 어떻게 보호합니까? pipelinePR에서 오는 건가요?
GitHub는 수정된 코드 실행과 관련하여 어떤 방식으로 작동하나요? pipelines?
수정 pipelines는 푸시 또는 Pull Requests (홍보). 주요 권장 사항 중 하나는 보호된 브랜치에 직접 "푸시"하는 것을 피하고 다른 방법을 사용하는 것입니다. Pull Requests 기여된 코드를 수락하기 전에 검토 절차를 강제하는 메커니즘으로 사용됩니다.
Pull Requests 두 가지 다른 출처에서 발생할 수 있습니다.
- PR이 오는 곳 포크
- PR이 오는 곳 가지
PR에서 포크 다음 중 하나에서 나올 수 있습니다. 공개 or 사설 리포지토리.
우리는 PPE(독성 물질)를 다루고 있기 때문에 Pipeline (실행 측면에서) 우리의 핵심은 PR의 "승인"이 아니라 수정된 PR의 실행입니다. pipeline PR의 승인/허가 과정 중에 발생합니다. PPE 공격의 핵심은 악의적으로 수정된 코드가 의도치 않게 실행되는 것입니다. 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 사전 검토나 승인이 필요 없습니다..
포크에서 가져온 PR 공개 repos
GitHub는 처리 시 동작을 구성할 수 있도록 합니다. 공개 저장소의 포크에서 나오는 PR.
포크에서 생성된 PR의 경우, GitHub는 실행 전에 항상 일정 수준의 "승인" 절차를 거칩니다. pipeline PR과 관련된이러한 승인 수준은 약한 승인에서 엄격한 승인으로의 전환을 의미합니다.
At 조직 수준 (조직>>설정>>작업>>일반)에서 여러 가지 "승인" 옵션 중에서 선택할 수 있습니다.
가장 엄격한 것은 마지막 항목입니다.모든 외부 협력업체의 승인을 받아야 합니다.GitHub는 외부 협력자의 포크에서 온 PR의 경우 항상 승인을 요구하기 때문입니다.
하지만 이처럼 엄격한 경우에도 다음과 같은 것들이 존재합니다. 읽기 및 쓰기 권한을 가진 공동 작업자 간의 차이점.
- 홍보 자료가 ~로부터 온 경우 읽기 사용자는 의 실행 pipeline 정지되었습니다 변경 사항에 대한 승인이 있을 때까지입니다. 승인이 나면 수정된 내용이 적용됩니다. pipeline 실행됩니다.
- 홍보 자료가 ~로부터 온 경우 쓰다 사용자는 승인이 필요하지 않으며 수정된 내용입니다. pipeline 항상 실행됩니다!!
결론적으로, 공개 저장소의 포크에서 생성된 PR은 PPE(개인 정보 보호)에 대한 보호 수준이 낮습니다. 외부(읽기) 사용자에 대한 보호는 어느 정도 이루어지지만, 내부(쓰기) 사용자에 대한 보호는 전혀 없습니다.
는 어때 비공개 저장소의 포크에서 나온 PR?
포크에서 가져온 PR 사설 repos
이 시나리오에서 GitHub는 몇 가지 유용한 구성 설정을 제공합니다.
위 설정은 다음에서 구성할 수 있습니다. 기관 또는에서 레포 수평.
인셀덤 공식 판매점인 어떤 옵션도 선택되지 않았습니다., GitHub는 승인을 요청하세요 수정된 내용은 실행되지 않습니다. pipeline이것이 가장 안전한 구성입니다!!
The 가장 안전하지 않은 구성 때입니다 "포크에서 워크플로우를 실행하세요 pull request"가 선택됨"이 경우 읽기 사용자와 쓰기 사용자 모두에게 동일하게 적용되며, GitHub는 수정된 내용을 자동으로 실행합니다. pipeline그리고 이런 상황은 더욱 심각해질 수도 있습니다!! 악화되는 만약에 "포크에서 워크플로우로 쓰기 토큰을 전송합니다. pull requests"및"포크에서 워크플로우로 비밀 키와 변수를 전송합니다. pull requests"확인" 항목이 있습니다. 명확한 이유가 없는 한 이렇게 하지 마십시오!
만약 "포크하려면 승인이 필요합니다 pull request 워크 플로우"확인"을 선택하면 위 상황이 다소 악화됩니다. GitHub는 승인을 요청하고 수정된 내용을 실행하지 않습니다. pipeline 읽기 전용 사용자에게는 실행되지 않지만, 쓰기 전용 사용자에게도 실행됩니다.
포크가 보이네요, 그럼 어때요? 지점에서 오는 PR?
PR에서 가지
이러한 상황을 보호하려면 다음 사항에 의존해야 합니다. 지점 보호 규칙.
리포지토리 수준에서 모든 브랜치에 대한 브랜치 보호 규칙을 만들 수 있습니다. 이러한 규칙은 몇 가지 추가 기능을 제공합니다. 보호된 분기 수정에 대한 제약 조건.
규칙을 다음과 같이 설정하더라도요구 pull request 병합하기 전에"및"승인 필요" 수정된 pipeline PR 생성 시 자동으로 실행됩니다."승인"은 병합 작업에만 적용됩니다.
간접 중독은 어떻습니까? Pipeline 실행
위에서 살펴본 바와 같이, D-PPE는 다음과 같은 방법으로 완화될 수 있습니다. 풀 리퀘스트 타겟, 그러나 그것 개인보호장비(I-PPE)에는 적용되지 않습니다..
`pull_request_target`을 사용하면 기본적으로 기본 코드가 체크아웃됩니다. 하지만 기여된 코드(PR 코드)에 대한 특정 검사를 수행하려면 PR 코드를 명시적으로 체크아웃해야 합니다. 따라서 PR 코드가 `pull_request_target`에서 호출되는 셸 스크립트를 수정했다면, 해당 코드를 체크아웃해야 합니다. pipeline"기반"(안전한) pipeline "수정된" 셸 스크립트를 실행합니다 → 간접 PPE!!
이 문제에 대한 해결책은 다소 복잡합니다(pull_request_target처럼 만능 해결책은 없습니다).
pipeline pull_request_target을 사용하기 때문에 D-PPE에는 안전하지만, I-PPE에는 여전히 취약합니다.
저희 테스트 예시에서는 빌드를 생성하기 위해 기본적으로 PR 코드를 체크아웃해야 하지만, 테스트는 빌드 결과로 생성된 아티팩트에서 실행됩니다.
그래서 .. 두 코드베이스 모두 확인해 보는 건 어때요?
- PR 코드를 확인해 보세요. 우리가 빌드하고 테스트하려는 코드가 바로 그 기여된 코드입니다.
- 원본 버전을 실행하려면 기본 코드를 확인하세요. pipeline 그리고 빌드/테스트 스크립트
이것은 다음과 같은 방법으로 이루어질 수 있습니다. 해당 코드베이스들을 다른 폴더로 옮기는 것기본 코드는 루트 폴더에 체크아웃하고, PR은 다른 폴더에 체크아웃할 수 있습니다. 이 경우 루트 폴더의 빌드 및 테스트 스크립트를 실행하여 새 폴더에 있는 코드를 대상으로 테스트합니다.
물론 이것은 쉬운 해결책입니다!! 하지만 학습 목적으로 꽤 흥미로운 변형 방법을 소개하고 싶습니다. (…)
GitHub의 워크플로우 실행 트리거 이벤트
게다가 풀 리퀘스트 타겟GitHub는 또 다른 트리거 이벤트를 제공합니다. 워크플로우 실행이 이벤트는 허용합니다. 실행 pipeline 다른 것에 조건화됨 pipeline'의 처형.
워크플로우 실행 풀 리퀘스트 타겟 트리거는 한 가지 측면에서 유사합니다. 둘 다 특권 모드로 실행되며, 홍보 수정에도 불구하고, 기본은 pipeline 처형될 것이다!!
현재 상황을 살펴보겠습니다. pipeline:
제작 구역은 D-PPE 착용 시 안전하지만, 테스트 구역은 I-PPE 착용 시에도 여전히 위험할 수 있습니다.
The pipeline 그 자체는 D-PPE에 안전합니다. 왜냐하면 풀 리퀘스트 타겟 트리거입니다. 하지만 테스트 단계는 외부 셸 스크립트를 호출하기 때문에 여전히 I-PPE에 취약합니다.
개인보호장비(PPE) 착용 피하기
위의 목적은 pipeline 기여된 코드를 빌드하고 테스트하는 것이며, 개인 보호 장비(PPE)를 안전하게 착용해야 합니다.
그래서 .. 왜 나누지 않나요? pipeline 둘로 나누는 건 어때요? 하나는 구축용이고 다른 하나는 테스트용입니다...
- 1st pipeline (CI 빌드) 일 것이다 PR 코드(빌드용)를 확인해 보세요.빌드를 수행하고 아티팩트를 생성합니다.
- 2nd pipeline (테스트 CI) 일 것이다 (셸 스크립트 수정을 피하기 위해) 기본 코드를 확인하세요. 그리고 아티팩트에 대해 원래 스크립트를 실행합니다.
- 테스트 CI를 동기화하려면 pipeline CI 빌드 후에 실행 pipeline, 우리는 워크플로우 실행 방아쇠.
이런 식으로:
- pipeline CI 빌드 is 가장 안전한 따뜻함 두 사람에게 디-PPE (때문에 풀 리퀘스트 타겟) and I-PPE (셸 스크립트를 더 이상 실행하지 않기 때문입니다.)
- pipeline 테스트 CI 또한 가장 안전한 따뜻함 두 사람에게 디-PPE (때문에 워크플로우 실행) and I-PPE (기본 코드를 확인하여 원래 셸 스크립트를 가져오기 때문입니다.)
두 코드 모두 살펴보겠습니다. pipeline이러한 수정 사항에 따르면…
1st pipeline (CI 빌드):
2nd pipeline (테스트 CI):
와… 멋진 해결책이네요!! 하지만… 안전한 걸까요? 아마 아닐 것 같아요 😭
새로운 취약점을 발견했습니다!! 어떤 취약점인지 궁금하시다면 다음 게시글에서 자세히 알려드리겠습니다 🙂 … 기대해주세요!!
추신: 죄송해요, 가만히 있을 수가 없네요 🤐 ..혹시 들어보셨나요? 유물 중독 ? 😂
