[CICD-Goat] 2. Mad Hatter

개인적으로 침투테스트 시 내부망에 액세스하면 우선 순위로 내부에서 사용중인 CI/CD 툴인 jenkins, gitlab, bitbucket 등을 탐색한다. 발견 이후에도 알려진 CVE가 모두 패치된 버전을 사용하여 익스하지 못한 경험이 있는데, 추후 이런 상황에서 좀더 스마트하게 내부 시스템을 장악하고자 취약한 환경의 CI/CD 환경인 cicd-goat을 통해 CI/CD pipeline에서 발생할 수 있는 11가지의 취약점 시나리오를 CTF 형태로 진행한다.

이번 포스트에서는 Easy 단계의 Mad Hatter을 진행한다.

이번 문제는 이전 문제인 White Rabbit와 비슷하게 Wonderland/mad-hatter 레포지토리의 권한을 이용하여 flag3를 획득하는것이 목표다.

이전 문제와 다르게 Wonderland/mad-hatter의 레포지토리에는 Jenkinsfile이 포함되어있지 않고 별도의 레포(Wonderland
/mad-hatter-pipeline)에 Jenkinsfile이 구성되어있다.

Jenkinsfile 내 stage('make')부분을 보면 Crendentials Store에 저장된 flag3를 FLAG라는 환경변수로 저장하고 make 명령을 수행한다.

pipeline {
    agent any
    environment {
        PROJECT = "yagmail"
    }
    stages {
        stage ('Install_Requirements') {
            steps {
                sh """
                    virtualenv venv
                    pip3 install -r requirements.txt || true
                """
            }
        }
        stage ('Lint') {
            steps {
                sh "pylint ${PROJECT} || true"
            }
        }
        stage ('Unit Tests') {
            steps {
                sh "pytest || true"
            }
        }
        stage('make'){
            steps {
              withCredentials([usernamePassword(credentialsId: 'flag3', usernameVariable: 'USERNAME', passwordVariable: 'FLAG')]) {
                sh 'make || true'
              }
            }           
        }
    }
    post { 
        always { 
            cleanWs()
        }
    }
}

그렇다면 Wonderland/mad-hatter-pipeline 레포의 Jenkinsfile의 make stage의 step에서 sh 부분에 echo "${FLAG}" | base64를 삽입하고 pull request를 생성하여 Jenkins에서 build history에서 flag3를 확인할 수 있지않을까?

git clone http://localhost:3000/Wonderland/mad-hatter-pipeline.git
cd mad-hatter-pipeline
# Jenkinsfile 수정...
git add Jenkinsfile
git commit -m "show me the flag!"
git push

안타깝게도 mad-hatter-pipeline 레포의 main branch에 push 권한이 없는것같다.

remote: Gitea: User permission denied for writing.

그렇다면 이전 문제와 비슷하게 새로운 branch를 생성하여 push하면 어떨까?

git checkout -b hacker_branch
git add Jenkinsfile
git commit -m "show me the flag"
git push --set-upstream origin hacker_branch

동일하게 권한이 없는것을 확인할 수 있다. 결과적으로 어떤 방법으로도 Jenkinsfile은 수정할 수 없다.

Wonderland/mad-hatter에서 Makefile을 보면 Authorization 헤더에 위에서 저장한 환경변수의 FLAG를 사용한다. 전체적인 상황을 보았을때 이전 문제에서는 Direct-PPE 공격이 가능했다면 이번 문제에서는 Indirect-PPE 공격이가능하다.

실제 mad-hatter가 make될때 mad-hatter-pipeline과 동일한 환경의 메모리에서 진행된다면 Makefile에 FLAG 환경변수를 출력하는 명령을 추가하여 flag를 탈취할 수 있을 것이다.

공격 방식은 비슷하다. 이전 문제에서는 Jenkinsfile을 수정했지만 이번 문제에서는 파이프라인 레포에서 확인한 Jenkinsfile 내 FLAG 환경변수를 사용할 수 있는 Makefile을 수정하고 push한다.

git clone http://localhost:3000/Wonderland/mad-hatter.git
cd mad-hatter
# Makefile 수정...
git add Makefile
git commit -m "show me the flag"
git push

하지만 Jenkins에서는 별다른 반응을 확인할 수 없다.

그렇다면 1번 문제와 동일하게 새로운 branch를 생성하여 pull request를 생성하는 방식으로 진행해본다면 어떨까?

git checkout -b hacker_branch
git add Makefile
git commit -m "show me the flag2"
git push --set-upstream origin hacker_branch

push한 hacker_branch가 빌드 큐에 들어간걸 확인할 수 있다!

Jenkins에서 wonderland-mad-hatter를 보면 pipeline을 통해 빌드가 진행된것을 확인할 수 있다.

build history에서 make stage쪽 로그를 보면 우리가 mad-hatter 레포의 Makefile을 수정해서 FLAG 환경 변수를 출력하도록 변경한것이 적용되어 base64로 감싸진 flag를 확인할 수 있다.

이전 문제에서는 Direct PPE 공격이 가능했고, 이번 문제에선 Indirect PPE 공격이 가능했다. 결과적으로 파이프라인을 통해 빌드과정에서 동일한 컨택스트에서 메모리를 공유하고있어 mad-hatter-pipeline 레포에서 정의된 Jenkinsfile의 환경변수를 mad-hatter 레포의 Makefile에서 출력할 수 있었다.