Pentesting CI/CD Methodology

Reading time: 7 minutes

VCS

VCS stands for Version Control System, 이 시스템은 개발자가 소스 코드를 관리할 수 있게 해준다. 가장 흔한 것은 git이며, 보통 기업들은 다음과 같은 플랫폼 중 하나를 사용한다:

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

CI/CD Pipelines

CI/CD pipelines는 개발자가 애플리케이션을 빌드, 테스트, 배포하는 등 다양한 목적을 위해 코드 실행을 자동화할 수 있게 해준다. 이러한 자동화된 워크플로우는 코드 푸시, pull requests, 스케줄된 작업 등 특정 액션에 의해 트리거된다. 개발에서 운영까지의 과정을 간소화하는 데 유용하다.

다만 이러한 시스템들은 어딘가에서 실행될 필요가 있으며, 보통은 코드를 배포하거나 민감한 정보에 접근하기 위한 권한 있는 자격증명을 필요로 한다.

VCS Pentesting 방법론

프로젝트의 소스 코드를 포함하는 플랫폼에는 민감한 정보가 포함될 수 있으므로 내부 권한 관리에 각별히 주의해야 한다. 공격자가 악용할 수 있는 VCS 플랫폼 전반의 일반적인 문제는 다음과 같다:

• Leaks: 코드에 leak가 커밋에 포함되어 있고 공격자가 해당 리포지토리에 접근할 수 있다면(퍼블릭이거나 접근 권한이 있는 경우) 해당 leak를 발견할 수 있다.
• Access: 공격자가 VCS 플랫폼 내의 계정에 접근할 수 있다면, 더 많은 가시성 및 권한을 얻을 수 있다.
• Register: 일부 플랫폼은 외부 사용자가 계정을 생성하는 것을 허용한다.
• SSO: 일부 플랫폼은 사용자의 직접 등록을 허용하지 않지만 유효한 SSO로는 누구나 접근할 수 있게 하는 경우가 있다(예: 공격자가 자신의 github 계정으로 접근).
• Credentials: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies 등 다양한 종류의 토큰을 탈취하여 리포지토리에 접근할 수 있다.
• Webhooks: VCS 플랫폼은 Webhooks를 생성할 수 있게 한다. 이들이 눈에 보이지 않는 비밀로 보호되어 있지 않다면 공격자가 이를 악용할 수 있다.
• 비밀이 없는 경우 공격자는 서드파티 플랫폼의 webhook을 악용할 수 있다.
• 비밀이 URL에 포함되어 있다면 동일하게 공격자가 그 비밀을 함께 얻게 된다.
• Code compromise: 악성 행위자가 리포지토리에 대한 **쓰기 권한(write)**을 갖고 있다면 악의적인 코드를 주입하려 할 수 있다. 성공하려면 브랜치 보호를 우회해야 할 수도 있다. 이런 행위의 목적은 다양하다:
  • 메인 브랜치를 손상시켜 production을 침해.
  • 메인(또는 기타) 브랜치를 손상시켜 개발자 머신을 침해(개발자들이 로컬에서 테스트, terraform 등 리포지토리 내 작업을 수행하기 때문).
  • 파이프라인을 침해 (다음 섹션 참조)

Pipelines Pentesting 방법론

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

따라서 공격자의 궁극적 목표는 이들 구성 파일 또는 이들이 실행하는 명령어들을 어떻게든 손상시키는 것이다.

PPE - Poisoned Pipeline Execution

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

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

• 보통 파이프라인은 push나 pull request가 수행될 때 트리거되므로 VCS 플랫폼에 대한 write access를 가지고 있어야 한다. (접근을 얻는 방법은 VCS pentesting 방법론 섹션을 참조).
• 때로는 외부 PR도 "write access"로 간주될 수 있다.
• 쓰기 권한이 있더라도 CI 구성 파일이나 구성에서 의존하는 다른 파일을 수정할 수 있는지 확실히 해야 한다.
• 이를 위해 브랜치 보호를 우회할 수 있어야 할 수도 있다.

PPE에는 3가지 형태가 있다:

• D-PPE: Direct PPE — 행위자가 실행될 CI 구성 파일을 직접 수정할 때 발생한다.
• I-DDE: Indirect PPE — 행위자가 CI 구성 파일이 의존하는 파일(예: Makefile, terraform 구성 등)을 수정할 때 발생한다.
• Public PPE or 3PE: 경우에 따라 파이프라인은 리포지토리에 write access가 없는 사용자(조직 소속이 아닐 수도 있는)가 PR을 보낼 수 있기 때문에 그러한 유저에 의해 트리거될 수 있다.
• 3PE Command Injection: 일반적으로 CI/CD 파이프라인은 PR에 대한 정보를 env variables로 설정한다. 만약 그 값(예: PR의 제목)을 공격자가 제어할 수 있고 그 값이 위험한 위치(예: sh 명령 실행)에 사용된다면, 공격자는 그 안에 명령을 주입할 수 있다.

Exploitation Benefits

세 가지 PPE 형태를 알았으니, 공격자가 성공적으로 침투했을 때 얻을 수 있는 것들을 살펴보자:

• Secrets: 앞서 언급했듯이 파이프라인 작업은 코드 조회, 빌드, 배포 등을 위해 권한을 필요로 하며 이 권한들은 보통 secrets로 부여된다. 이 secrets는 보통 env variables나 시스템 내부의 파일을 통해 접근 가능하다. 따라서 공격자는 가능한 한 많은 secrets를 탈취하려 할 것이다.
• 파이프라인 플랫폼에 따라 공격자는 구성 파일에 secrets를 명시해야 하는 경우가 있다. 즉 공격자가 CI 구성 파일 자체를 수정할 수 없다면(I-PPE 같은 경우), 그는 그 파이프라인이 이미 가진 secrets만 탈취할 수 있다.
• Computation: 코드가 어딘가에서 실행되므로 실행 위치에 따라 공격자는 추가적인 피벗이 가능할 수 있다.
• On-Premises: 파이프라인이 온프레미스에서 실행된다면 공격자는 내부 네트워크에 도달해 더 많은 리소스에 접근할 수 있다.
• Cloud: 공격자는 클라우드 내 다른 머신에 접근하거나 IAM 역할/서비스 계정 토큰을 탈취해 클라우드 내부에서 추가 권한을 얻을 수 있다.
• Platforms machine: 때때로 작업은 파이프라인 플랫폼의 머신 내에서 실행되며, 이 머신들은 보통 더 이상의 액세스가 없는 클라우드 환경에 존재한다.
• Select it: 일부 파이프라인 플랫폼은 여러 머신을 구성해두고, CI 구성 파일을 수정할 수 있다면 어떤 머신에서 악성 코드를 실행할지 지정할 수 있다. 이런 경우 공격자는 가능한 각 머신에 리버스 셸을 띄워 추가 공격을 시도할 것이다.
• Compromise production: 파이프라인 내부에 침투해 최종 버전이 파이프라인에서 빌드되어 배포된다면, 운영 환경에서 실행될 코드를 침해할 수 있다.

More relevant info

Tools & CIS Benchmark

• Chain-bench 은 소프트웨어 공급망 스택을 감사하여 새로운 CIS Software Supply Chain benchmark 기준에 따라 보안 컴플라이언스를 확인하는 오픈소스 도구다. 이 감사는 전체 SDLC 프로세스에 초점을 맞추며, 코드 시점부터 배포 시점까지의 리스크를 드러낼 수 있다.

Top 10 CI/CD Security Risk

Cider가 정리한 CI/CD 상위 10가지 리스크에 대한 흥미로운 글을 확인하라: https://www.cidersecurity.io/top-10-cicd-security-risks/

Labs

• 로컬에서 실행할 수 있는 각 플랫폼별로 로컬 런칭 방법이 제공되어 원하는 대로 구성하여 테스트할 수 있다.
• Gitea + Jenkins lab: https://github.com/cider-security-research/cicd-goat

Automatic Tools

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

References

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