Pentesting CI/CD Methodology

Reading time: 7 minutes

VCS

VCS는 버전 관리 시스템을 의미하며, 이 시스템은 개발자가 소스 코드를 관리할 수 있도록 합니다. 가장 일반적인 것은 git이며, 기업들은 보통 다음 플랫폼 중 하나에서 이를 사용합니다:

• Github
• Gitlab
• Bitbucket
• Gitea
• 클라우드 제공업체 (자체 VCS 플랫폼 제공)

CI/CD Pipelines

CI/CD 파이프라인은 개발자가 코드 실행을 자동화할 수 있도록 하여, 애플리케이션을 빌드, 테스트 및 배포하는 다양한 목적을 수행합니다. 이러한 자동화된 워크플로우는 특정 작업(예: 코드 푸시, 풀 리퀘스트 또는 예약된 작업)에 의해 트리거됩니다. 이는 개발에서 프로덕션으로의 과정을 간소화하는 데 유용합니다.

그러나 이러한 시스템은 어딘가에서 실행되어야 하며, 보통 코드를 배포하거나 민감한 정보에 접근하기 위해 권한이 있는 자격 증명이 필요합니다.

VCS Pentesting Methodology

프로젝트의 소스 코드를 포함하는 플랫폼은 민감한 정보를 포함하고 있으며, 사람들은 이 플랫폼 내에서 부여된 권한에 대해 매우 조심해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼의 일반적인 문제는 다음과 같습니다:

• 리크: 코드에 커밋에서 리크가 포함되어 있고 공격자가 레포에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우), 그는 리크를 발견할 수 있습니다.
• 접근: 공격자가 VCS 플랫폼 내 계정에 접근할 수 있다면, 그는 더 많은 가시성과 권한을 얻을 수 있습니다.
• 등록: 일부 플랫폼은 외부 사용자가 계정을 생성하는 것을 허용합니다.
• SSO: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만, 유효한 SSO로 접근하는 것은 허용합니다(예: 공격자가 자신의 github 계정을 사용하여 접근할 수 있습니다).
• 자격 증명: 사용자 이름+비밀번호, 개인 토큰, ssh 키, Oauth 토큰, 쿠키... 사용자가 어떤 방식으로든 레포에 접근하기 위해 훔칠 수 있는 여러 종류의 토큰이 있습니다.
• 웹훅: VCS 플랫폼은 웹훅 생성을 허용합니다. 만약 이들이 보이지 않는 비밀로 보호되지 않는다면, 공격자가 이를 악용할 수 있습니다.
• 비밀이 없다면, 공격자는 제3자 플랫폼의 웹훅을 악용할 수 있습니다.
• 비밀이 URL에 있다면, 동일한 일이 발생하며 공격자는 비밀을 가집니다.
• 코드 손상: 악의적인 행위자가 레포에 대해 어떤 종류의 쓰기 접근 권한을 가지고 있다면, 그는 악성 코드를 주입하려고 시도할 수 있습니다. 성공하기 위해 그는 브랜치 보호를 우회해야 할 수도 있습니다. 이러한 행동은 다양한 목표를 가지고 수행될 수 있습니다:
  • 메인 브랜치를 손상시켜 프로덕션을 손상시키기.
  • 메인(또는 다른 브랜치)을 손상시켜 개발자 머신을 손상시키기(개발자들이 보통 테스트, 테라폼 또는 다른 작업을 자신의 머신에서 실행하기 때문).
  • 파이프라인 손상(다음 섹션 참조)

Pipelines Pentesting Methodology

파이프라인을 정의하는 가장 일반적인 방법은 레포지토리에 호스팅된 CI 구성 파일을 사용하는 것입니다. 이 파일은 실행되는 작업의 순서, 흐름에 영향을 미치는 조건 및 빌드 환경 설정을 설명합니다.
이 파일들은 일반적으로 일관된 이름과 형식을 가지며, 예를 들어 — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 및 .github/workflows 아래에 위치한 GitHub Actions YAML 파일이 있습니다. 트리거되면, 파이프라인 작업은 선택된 소스(예: 커밋 / 브랜치)에서 코드를 가져오고, CI 구성 파일에 지정된 명령을 해당 코드에 대해 실행합니다.

따라서 공격자의 궁극적인 목표는 어떤 식으로든 이 구성 파일을 손상시키거나 그들이 실행하는 명령을 손상시키는 것입니다.

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) 경로는 SCM 레포지토리의 권한을 악용하여 CI 파이프라인을 조작하고 해로운 명령을 실행합니다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 작업에서 사용하는 다른 파일을 수정하여 악성 명령을 포함할 수 있습니다. 이는 CI 파이프라인을 "오염"시켜 이러한 악성 명령의 실행으로 이어집니다.

악의적인 행위자가 PPE 공격을 성공적으로 수행하기 위해서는 다음을 할 수 있어야 합니다:

• VCS 플랫폼에 대한 쓰기 접근 권한을 가져야 하며, 보통 파이프라인은 푸시 또는 풀 리퀘스트가 수행될 때 트리거됩니다. (접근 권한을 얻는 방법에 대한 요약은 VCS 펜테스팅 방법론을 참조하십시오).
• 때때로 외부 PR이 "쓰기 접근"으로 간주된다는 점에 유의해야 합니다.
• 쓰기 권한이 있더라도, 그는 CI 구성 파일이나 구성에 의존하는 다른 파일을 수정할 수 있는지 확인해야 합니다.
• 이를 위해 그는 브랜치 보호를 우회할 수 있어야 할 수도 있습니다.

PPE에는 3가지 변형이 있습니다:

• D-PPE: 직접 PPE 공격은 행위자가 실행될 CI 구성 파일을 수정할 때 발생합니다.
• I-DDE: 간접 PPE 공격은 행위자가 실행될 CI 구성 파일이 의존하는 파일을 수정할 때 발생합니다(예: 메이크 파일 또는 테라폼 구성).
• 공개 PPE 또는 3PE: 경우에 따라 파이프라인은 레포에 쓰기 접근 권한이 없는 사용자에 의해 트리거될 수 있습니다(그들이 PR을 보낼 수 있기 때문).
• 3PE 명령 주입: 일반적으로 CI/CD 파이프라인은 PR에 대한 정보로 환경 변수를 설정합니다. 만약 그 값이 공격자에 의해 제어될 수 있고(예: PR의 제목) 위험한 장소에서 사용된다면(예: sh 명령 실행), 공격자는 거기에 명령을 주입할 수 있습니다.

Exploitation Benefits

파이프라인을 오염시키는 3가지 변형을 알고 나면, 공격자가 성공적인 악용 후 얻을 수 있는 것들을 살펴보겠습니다:

• 비밀: 앞서 언급했듯이, 파이프라인은 작업을 수행하기 위해 권한이 필요하며(코드를 검색하고, 빌드하고, 배포하는 등), 이러한 권한은 보통 비밀로 부여됩니다. 이러한 비밀은 일반적으로 환경 변수나 시스템 내 파일을 통해 접근할 수 있습니다. 따라서 공격자는 항상 가능한 한 많은 비밀을 유출하려고 할 것입니다.
• 파이프라인 플랫폼에 따라 공격자는 구성에서 비밀을 지정해야 할 수도 있습니다. 이는 공격자가 CI 구성 파이프라인을 수정할 수 없다면(I-PPE 예를 들어), 그는 그 파이프라인이 가진 비밀만 유출할 수 있다는 것을 의미합니다.
• 계산: 코드는 어딘가에서 실행되며, 실행되는 위치에 따라 공격자는 더 나아가서 피벗할 수 있습니다.
• 온프레미스: 파이프라인이 온프레미스에서 실행된다면, 공격자는 더 많은 리소스에 접근할 수 있는 내부 네트워크에 도달할 수 있습니다.
• 클라우드: 공격자는 클라우드의 다른 머신에 접근할 수 있지만, 또한 IAM 역할/서비스 계정의 토큰을 유출하여 클라우드 내에서 추가 접근을 얻을 수 있습니다.
• 플랫폼 머신: 때때로 작업은 파이프라인 플랫폼 머신 내에서 실행되며, 이는 보통 더 이상의 접근이 없는 클라우드 내에 있습니다.
• 선택: 때때로 파이프라인 플랫폼은 여러 머신을 구성하고 있으며, 만약 CI 구성 파일을 수정할 수 있다면, 악성 코드를 실행할 위치를 지정할 수 있습니다. 이 경우, 공격자는 아마도 각 가능한 머신에서 리버스 쉘을 실행하여 더 나아가서 악용하려고 할 것입니다.
• 프로덕션 손상: 만약 당신이 파이프라인 내에 있고 최종 버전이 그로부터 빌드되고 배포된다면, 당신은 프로덕션에서 실행될 코드를 손상시킬 수 있습니다.

More relevant info

Tools & CIS Benchmark

• Chain-bench는 새로운 CIS 소프트웨어 공급망 벤치마크를 기반으로 보안 준수를 위해 소프트웨어 공급망 스택을 감사하는 오픈 소스 도구입니다. 감사는 전체 SDLC 프로세스에 초점을 맞추며, 코드 시간에서 배포 시간까지의 위험을 드러낼 수 있습니다.

Top 10 CI/CD Security Risk

Cider에 따르면 상위 10개 CI/CD 위험에 대한 흥미로운 기사를 확인하십시오: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• 로컬에서 실행할 수 있는 각 플랫폼에서 로컬로 실행하는 방법을 찾아서 원하는 대로 구성하여 테스트할 수 있습니다.
• Gitea + Jenkins 실험실: https://github.com/cider-security-research/cicd-goat

Automatic Tools

• Checkov: Checkov는 인프라스트럭처-코드에 대한 정적 코드 분석 도구입니다.

References

• https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422