Pentesting CI/CD Methodology

Tip

AWS 해킹 학습 및 실습:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 학습 및 실습: HackTricks Training GCP Red Team Expert (GRTE)
Az 해킹 학습 및 실습: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

VCS

VCS는 Version Control System의 약자이며, 이 시스템은 개발자가 source code를 관리할 수 있게 해줍니다. 가장 흔한 것은 git이며, 보통 기업은 다음 platforms 중 하나를 사용합니다:

  • Github
  • Gitlab
  • Bitbucket
  • Gitea
  • Gitblit
  • Cloud providers (자체 VCS platforms 제공)

CI/CD Pipelines

CI/CD pipelines는 개발자가 빌드, 테스트, 배포를 포함한 다양한 목적의 code 실행을 자동화할 수 있게 해줍니다. 이러한 자동화된 워크플로는 code push, pull request, 예약 작업 같은 특정 액션에 의해 트리거됩니다. 이는 development에서 production까지의 과정을 간소화하는 데 유용합니다.

하지만 이러한 시스템은 어딘가에서 실행되어야 하며, 보통 code를 deploy하거나 민감한 정보에 접근하기 위한 privileged credentials가 필요합니다.

VCS Pentesting Methodology

Note

일부 VCS platforms는 이 섹션을 위해 pipelines 생성도 허용하지만, 여기서는 source code 통제에 대한 잠재적 공격만 분석합니다.

프로젝트의 source code를 담고 있는 platforms에는 민감한 정보가 포함되며, 이 platform 내부에서 부여된 permissions에는 매우 주의해야 합니다. attacker가 악용할 수 있는 VCS platforms 전반의 흔한 문제는 다음과 같습니다:

  • Leaks: code에 commits 안의 leaks가 포함되어 있고 attacker가 repo에 접근할 수 있다면(공개되어 있거나 접근 권한이 있기 때문), leaks를 발견할 수 있습니다.
  • Access: attacker가 VCS platform 내부의 account에 접근할 수 있다면 더 많은 가시성과 permissions을 얻을 수 있습니다.
  • Register: 일부 platforms는 외부 사용자가 그냥 account를 만들 수 있게 허용합니다.
  • SSO: 일부 platforms는 사용자의 직접 등록은 허용하지 않지만, 유효한 SSO가 있으면 누구나 접근할 수 있게 허용합니다(예: attacker가 자신의 github account로 들어갈 수 있음).
  • Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies… repo에 어떤 식으로든 접근하기 위해 사용자가 훔칠 수 있는 token 종류는 여러 가지가 있습니다.
  • Webhooks: VCS platforms는 webhooks 생성을 허용합니다. 만약 이것들이 보이지 않는 secrets로 보호되지 않으면 attacker가 악용할 수 있습니다.
  • secret이 없다면, attacker는 third party platform의 webhook을 악용할 수 있습니다
  • secret이 URL에 있다면, 같은 일이 발생하고 attacker도 secret을 갖게 됩니다
  • Code compromise: 악의적인 행위자가 repos에 대해 어떤 형태의 write access를 가지고 있다면, malicious code를 주입하려 시도할 수 있습니다. 성공하려면 branch protections를 우회해야 할 수도 있습니다. 이러한 행위는 mid에 다른 목표를 가지고 수행될 수 있습니다:
  • main branch를 compromise하여 production을 compromise.
  • main(또는 다른 branches)을 compromise하여 developers machines를 compromise(보통 개발자들이 자신의 머신에서 repo 내부의 test, terraform 또는 다른 것들을 실행하기 때문).
  • pipeline을 compromise(다음 섹션 참조)

Pipelines Pentesting Methodology

pipeline을 정의하는 가장 일반적인 방법은 pipeline이 빌드하는 repository에 호스팅된 CI configuration file을 사용하는 것입니다. 이 파일은 실행되는 jobs의 순서, 흐름에 영향을 주는 조건, build environment settings를 설명합니다.
이러한 파일들은 보통 일정한 이름과 형식을 가집니다. 예를 들어 Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), 그리고 .github/workflows 아래에 있는 GitHub Actions YAML files가 있습니다. 트리거되면 pipeline job은 선택된 source(예: commit / branch)에서 code를 가져와, 해당 code에 대해 CI configuration file에 지정된 commands를 실행합니다.

따라서 attacker의 궁극적인 목표는 어떻게든 이러한 configuration files 또는 그들이 실행하는 commands를 compromise하는 것입니다.

Tip

일부 hosted builders는 contributors가 Docker build context와 Dockerfile path를 선택하게 해줍니다. context가 attacker-controlled라면, build 중 host files를 ingest하고 secrets를 exfiltrate하기 위해 repo 밖(예: “..”)으로 설정할 수 있습니다. 다음을 참조하세요:

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

PPE - Poisoned Pipeline Execution

Poisoned Pipeline Execution (PPE) 경로는 SCM repository의 permissions를 악용해 CI pipeline을 조작하고 harmful commands를 실행합니다. 필요한 permissions가 있는 사용자는 CI configuration files 또는 pipeline job이 사용하는 다른 파일을 수정하여 malicious commands를 포함시킬 수 있습니다. 이렇게 CI pipeline이 “poison“되면 이러한 malicious commands가 실행됩니다.

malicious actor가 PPE attack을 성공적으로 수행하려면 다음이 가능해야 합니다:

  • 보통 pipelines는 push나 pull request가 수행될 때 트리거되므로, VCS platform에 write access가 있어야 합니다. (접근 권한을 얻는 방법의 요약은 VCS pentesting methodology를 확인하세요).
  • 때로는 external PR이 “write access“로 간주된다는 점에 유의하세요.
  • write permissions가 있더라도, CI config file 또는 config가 의존하는 다른 파일을 수정할 수 있어야 합니다.
  • 이를 위해 branch protections를 우회해야 할 수도 있습니다.

PPE에는 3가지 flavor가 있습니다:

  • D-PPE: actor가 실행될 CI config file을 수정할 때 발생하는 Direct PPE attack입니다.
  • I-DDE: actor가 실행될 CI config file이 의존하는 file(예: make file 또는 terraform config)을 수정할 때 발생하는 Indirect PPE attack입니다.
  • Public PPE or 3PE: 어떤 경우에는 repo에 write access가 없는 사용자(심지어 org의 일부도 아닐 수 있음)도 PR을 보낼 수 있으므로 pipelines가 트리거될 수 있습니다.
  • 3PE Command Injection: 보통 CI/CD pipelines는 PR에 대한 정보로 environment variables를 설정합니다. 그 값이 attacker가 제어할 수 있고(PR title 같은), 위험한 위치(예: sh commands 실행)에서 사용된다면 attacker가 그곳에 commands를 주입할 수 있습니다.

Exploitation Benefits

pipeline을 poison하는 3가지 flavor를 알았으니, 성공적인 exploitation 후 attacker가 얻을 수 있는 것을 살펴봅시다:

  • Secrets: 앞서 언급했듯이, pipelines는 jobs를 수행하기 위해 privileges가 필요하며(코드 가져오기, 빌드, 배포 등), 이러한 privileges는 보통 secrets 안에 있습니다. 이러한 secrets는 보통 env variables 또는 시스템 내부 파일을 통해 접근할 수 있습니다. 따라서 attacker는 항상 가능한 한 많은 secrets를 exfiltrate하려 할 것입니다.
  • pipeline platform에 따라 attacker가 config에 secrets를 지정해야 할 수도 있습니다. 이는 attacker가 CI configuration pipeline(I-PPE 같은)을 수정할 수 없다면, 그 pipeline이 가진 secrets만 exfiltrate할 수 있음을 의미합니다.
  • Computation: code는 어딘가에서 실행되며, 실행 위치에 따라 attacker가 더 깊게 pivot할 수 있습니다.
  • On-Premises: pipelines가 on premises에서 실행된다면, attacker는 더 많은 resources에 접근할 수 있는 internal network에 도달할 수 있습니다.
  • Cloud: attacker는 다른 cloud machine들에 접근할 수 있을 뿐 아니라, IAM roles/service accounts tokens를 exfiltrate하여 cloud 내부에서 추가 접근을 얻을 수도 있습니다.
  • Platforms machine: 때때로 jobs는 pipelines platform machines 내부에서 실행되며, 보통 이는 더 이상의 access가 없는 cloud 안에 있습니다.
  • Select it: 때때로 pipelines platform이 여러 machines를 설정해 두며, CI configuration file을 수정할 수 있다면 malicious code를 어디서 실행할지 지정할 수 있습니다. 이 상황에서는 attacker가 각 machine에서 reverse shell을 실행해 추가 exploitation을 시도할 가능성이 큽니다.
  • Compromise production: pipeline 내부에 있고 최종 버전이 여기서 빌드 및 배포된다면, production에서 실행될 code를 compromise할 수 있습니다.

Dependency & Registry Supply-Chain Abuse

CI/CD pipeline을 compromise하거나 거기서 credentials를 훔치면, attacker는 dependencies나 release tooling을 backdoor하여 pipeline execution에서 ecosystem-wide code execution으로 이동할 수 있습니다:

  • Install-time code execution via package hooks: preinstall, postinstall, prepare 또는 유사한 hooks를 추가한 package version을 publish하여, dependency installation 중 developer workstations와 CI runners에서 payload가 자동으로 실행되게 합니다.
  • Secondary execution paths: 대상이 --ignore-scripts로 설치하더라도, malicious package는 여전히 bin field에 common CLI name을 등록할 수 있으므로 attacker-controlled wrapper가 PATH에 symlink되고 나중에 command가 사용될 때 실행됩니다.
  • Runtime bootstrapping: 작은 installer가 설치 중 두 번째 runtime 또는 toolchain을 다운로드할 수 있습니다(예: Bun 또는 packed interpreter). 그런 다음 그것으로 main payload를 launch하여 local dependency requirements를 피할 수 있습니다.
  • Credential harvesting from build environments: code가 CI 내부에서 실행되면 environment variables, ~/.npmrc, ~/.git-credentials, SSH keys, cloud CLI configs, 그리고 gh auth token 같은 local tooling을 확인하세요. GitHub Actions에서는 runner-specific secrets와 artifacts도 찾아보세요.
  • Workflow injection with stolen GitHub tokens: repo + workflow permissions가 있는 token이면 branch를 만들고, .github/workflows/ 안에 malicious file을 commit하고, 트리거한 뒤, 생성된 artifacts/logs를 수집하고, trace를 줄이기 위해 임시 branch/workflow run을 삭제할 수 있습니다.
  • Wormable registry propagation: 훔친 npm tokens가 publish permissions가 있는지, 그리고 2FA를 우회하는지 검증해야 합니다. 가능하다면 writable packages를 열거하고, tarballs를 다운로드한 뒤, setup.mjs 같은 loader를 주입하고, preinstall이 이를 실행하도록 설정한 다음, patch version을 올리고 republish하세요. 이렇게 하면 하나의 CI compromise가 다른 환경들에서 downstream auto-execution으로 이어집니다.

Practical checks during an assessment

  • package.json에 추가된 package-manager hooks, 예상치 못한 bin entries, 또는 release artifact만 수정하는 version bumps에 대해 release automation을 검토하세요.
  • CI가 short-lived OIDC나 trusted publishing 대신 ~/.npmrc 같은 plaintext files에 long-lived registry credentials를 저장하는지 확인하세요.
  • CI에서 사용 가능한 GitHub tokens가 workflow files를 쓸 수 있는지 또는 branches/tags를 생성할 수 있는지 검증하세요.
  • compromised package가 의심되면, Git repository뿐 아니라 published tarball도 확인하세요. malicious loader/runtime는 published artifact에만 존재할 수 있습니다.
  • CI 내부에서 npm install 대신 npm ci 사용, 예상치 못한 Bun downloads/execution, 또는 transient branches에서 생성된 새로운 workflow artifacts 같은 비정상적인 package-manager execution을 찾아보세요.

More relevant info

Tools & CIS Benchmark

  • Chain-bench is an open-source tool for auditing your software supply chain stack for security compliance based on a new CIS Software Supply Chain benchmark. The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time.

Top 10 CI/CD Security Risk

Check this interesting article about the top 10 CI/CD risks according to Cider: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

Automatic Tools

  • Checkov: Checkov is a static code analysis tool for infrastructure-as-code.

References

Tip

AWS 해킹 학습 및 실습:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 학습 및 실습: HackTricks Training GCP Red Team Expert (GRTE)
Az 해킹 학습 및 실습: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기