Pentesting CI/CD Methodology

Reading time: 7 minutes

tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

VCS

VCS는 Version Control System의 약자로, 이 시스템은 개발자가 source code를 관리할 수 있게 해줍니다. 가장 일반적인 것은 git이며, 회사들은 보통 다음과 같은 platforms 중 하나를 사용합니다:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (they offer their own VCS platforms)

CI/CD Pipelines

CI/CD pipelines는 개발자가 빌드, 테스트, 배포 등 다양한 목적을 위해 코드 실행을 자동화할 수 있게 해줍니다. 이러한 자동화된 워크플로우는 코드 푸시, pull requests, 또는 예약 작업과 같은 특정 동작에 의해 트리거됩니다. 이는 개발에서 프로덕션으로 가는 과정을 간소화하는 데 유용합니다.

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

VCS Pentesting Methodology

note

Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.

프로젝트의 source code를 포함하는 플랫폼에는 민감한 정보가 들어있으며, 이 플랫폼 내에서 부여되는 권한을 매우 신중하게 관리해야 합니다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제는 다음과 같습니다:

  • Leaks: 코드에 commits에 leaks가 포함되어 있고 공격자가 repo에 접근할 수 있다면(공개이거나 접근 권한이 있는 경우) 그 leaks를 발견할 수 있습니다.
  • Access: 공격자가 VCS platform 내의 계정에 접근할 수 있다면 더 많은 가시성 및 권한을 얻을 수 있습니다.
  • Register: 일부 플랫폼은 외부 사용자가 계정을 생성하도록 허용합니다.
  • SSO: 일부 플랫폼은 사용자가 등록하는 것을 허용하지 않지만 유효한 SSO로 누구나 접근할 수 있게 허용합니다(예: 공격자가 자신의 github 계정으로 접근할 수 있음).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies 등 리포지토리에 접근하기 위해 탈취될 수 있는 여러 종류의 토큰이 있습니다.
  • Webhooks: VCS 플랫폼은 webhooks를 생성할 수 있게 합니다. 만약 webhooks가 보이지 않는 비밀로 보호되고 있지 않다면 공격자가 악용할 수 있습니다.
  • If no secret is in place, the attacker could abuse the webhook of the third party platform
  • If the secret is in the URL, the same happens and the attacker also have the secret
  • Code compromise: 악의적인 행위자가 리포지토리에 대한 write 권한을 가지고 있다면, 그는 악성 코드 삽입을 시도할 수 있습니다. 성공하려면 branch protections을 우회해야 할 수도 있습니다. 이러한 행위는 다양한 목적을 가질 수 있습니다:
    • main branch를 손상시켜 production을 침해.
    • main(또는 다른) branch를 손상시켜 개발자 머신을 침해(개발자들이 리포에서 테스트, terraform 등 작업을 실행하는 경우).
  • Compromise the pipeline (check next section)

Pipelines Pentesting Methodology

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

따라서 공격자의 궁극적인 목표는 어떻게든 이러한 구성 파일들이나 실행하는 명령들을 compromise하는 것입니다.

tip

Some hosted builders let contributors choose the Docker build context and Dockerfile path. If the context is attacker-controlled, you may set it outside the repo (e.g., "..") to ingest host files during build and exfiltrate secrets. See:

{{#ref}} docker-build-context-abuse.md {{#endref}}

PPE - Poisoned Pipeline Execution

The Poisoned Pipeline Execution (PPE) 경로는 SCM 리포지토리의 권한을 악용하여 CI 파이프라인을 조작하고 유해한 명령을 실행하게 합니다. 필요한 권한을 가진 사용자는 CI 구성 파일이나 파이프라인 job에서 사용하는 다른 파일을 수정하여 악성 명령을 포함시킬 수 있습니다. 이렇게 CI 파이프라인을 "poison"하면 이 악성 명령들이 실행됩니다.

공격자가 PPE 공격을 성공적으로 수행하려면 다음이 필요합니다:

  • VCS platform에 대한 write access를 가지고 있어야 합니다. 보통 파이프라인은 push나 pull request가 발생하면 트리거되기 때문입니다. (VCS pentesting methodology를 참조하세요.)
  • 외부 PR이 때때로 "write access"로 간주되기도 한다는 점에 유의하세요.
  • 설령 write 권한이 있더라도, 그는 CI config 파일이나 config가 의존하는 다른 파일들을 수정할 수 있는지 확신해야 합니다.
  • 이를 위해서는 branch protections을 우회할 수 있어야 할 수도 있습니다.

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

  • D-PPE: Direct PPE 공격은 행위자가 실행될 CI config 파일을 직접 수정할 때 발생합니다.
  • I-DDE: Indirect PPE 공격은 행위자가 CI config가 의존하는 파일(예: make file이나 terraform 구성)을 수정할 때 발생합니다.
  • Public PPE or 3PE: 경우에 따라 파이프라인은 repo에 write access가 없는 사용자(조직의 일원이 아닐 수도 있음)가 보낸 PR에 의해 트리거될 수 있습니다.
  • 3PE Command Injection: 일반적으로 CI/CD 파이프라인은 PR에 대한 정보를 환경 변수로 설정합니다. 만약 그 값이 공격자에 의해 제어될 수 있고(예: PR 제목) 위험한 위치(예: sh 명령 실행)에 사용된다면, 공격자는 그 안에 명령 주입을 할 수 있습니다.

Exploitation Benefits

세 가지 PPE 변형을 알았으니, 성공적인 exploitation 후 공격자가 얻을 수 있는 것을 살펴봅시다:

  • Secrets: 앞서 언급했듯이 파이프라인은 코드 검색, 빌드, 배포 등을 위해 privileges를 필요로 하며 이 권한들은 보통 secrets로 부여됩니다. 이러한 secrets는 보통 env variables나 시스템 내부의 파일로 접근 가능합니다. 따라서 공격자는 가능한 많은 secrets를 항상 탈취하려고 할 것입니다.
  • 파이프라인 플랫폼에 따라 공격자는 config에 secrets를 명시해야 하는 경우가 있습니다. 즉, 공격자가 CI 구성 파이프라인 자체를 수정할 수 없다면(I-PPE 같은 경우), 그는 그 파이프라인이 가진 secrets만 탈취할 수 있습니다.
  • Computation: 코드가 어딘가에서 실행되므로, 실행 위치에 따라 공격자는 추가적인 피벗을 시도할 수 있습니다.
  • On-Premises: 파이프라인이 온프레미스에서 실행된다면, 공격자는 내부 네트워크에 접근하여 더 많은 자원에 접근할 수 있습니다.
  • Cloud: 공격자는 클라우드 내의 다른 머신에 접근하거나 IAM roles/service accounts tokens를 탈취하여 클라우드 내부에서 추가 접근 권한을 획득할 수 있습니다.
  • Platforms machine: 때때로 job은 pipelines platform machines 내부에서 실행되며, 이들은 보통 추가 접근 권한이 없는 클라우드 내의 머신일 수 있습니다.
  • Select it: 때때로 pipelines platform은 여러 머신을 구성해 두고 있으며, CI 구성 파일을 수정할 수 있다면 악성 코드를 어느 머신에서 실행할지 지정할 수 있습니다. 이런 경우 공격자는 가능한 각 머신에 대해 리버스 쉘을 실행하여 추가 취약점을 노릴 것입니다.
  • Compromise production: 파이프라인 내부에 있고 최종 버전이 거기서 빌드되어 배포된다면, 프로덕션에서 실행될 코드를 침해할 수 있습니다.

More relevant info

Tools & CIS Benchmark

  • Chain-bench 는 새로운 CIS Software Supply Chain benchmark를 기반으로 소프트웨어 공급망 스택의 보안 컴플라이언스를 감사하는 오픈소스 도구입니다. 이 감사는 전체 SDLC 프로세스에 초점을 맞추며, 코드 단계에서 배포 단계까지의 위험을 드러낼 수 있습니다.

Top 10 CI/CD Security Risk

Cider에 따른 top 10 CI/CD 위험에 관한 흥미로운 글을 확인하세요: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov는 infrastructure-as-code에 대한 정적 코드 분석 도구입니다.

References

tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기