Atlantis Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Atlantisは基本的に、あなたのgitサーバーからのプルリクエストからterraformを実行するのを助けます。
https://github.com/runatlantis/atlantis/releasesのatlantisリリースページに行き、あなたに合ったものをダウンロードします。
githubユーザーの個人トークン（リポジトリアクセス付き）を作成します。
./atlantis testdriveを実行すると、atlantisと対話するために使用できるデモリポジトリが作成されます。
127.0.0.1:4141でウェブページにアクセスできます。
AtlantisはGithub、Gitlab、Bitbucket、Azure DevOpsなどの複数のgitホストをサポートしています。 ただし、これらのプラットフォームのリポジトリにアクセスし、アクションを実行するには、いくつかの特権アクセスが付与される必要があります（少なくとも書き込み権限）。 ドキュメントでは、Atlantis専用のユーザーをこれらのプラットフォームで作成することを推奨していますが、個人アカウントを使用する人もいるかもしれません。
いずれにせよ、攻撃者の視点から見ると、Atlantisアカウントは非常に興味深い****攻撃対象となるでしょう。
AtlantisはオプションでWebhook secretsを使用して、あなたのGitホストから受信するwebhooksが正当であることを検証します。
これを確認する方法の一つは、GitホストのIPからのみリクエストを許可することですが、より簡単な方法はWebhook Secretを使用することです。
プライベートなgithubやbitbucketサーバーを使用しない限り、webhookエンドポイントをインターネットに公開する必要があることに注意してください。
Atlantisはwebhooksを公開するため、gitサーバーが情報を送信できるようにします。攻撃者の視点からは、メッセージを送信できるかどうかを知ることが興味深いでしょう。
Atlantisは、サーバーAtlantisがホストされている上で単に**terraform planとapply**コマンドを実行することでTerraformを実行します。ローカルでTerraformを実行するのと同様に、Atlantisは特定のプロバイダーのための資格情報が必要です。
あなたがAtlantisに特定のプロバイダーのための資格情報を提供する方法はあなた次第です：
AtlantisのHelm ChartとAWS Fargate Moduleには、プロバイダー資格情報のための独自のメカニズムがあります。彼らのドキュメントを読んでください。
クラウドでAtlantisを実行している場合、多くのクラウドには、そこに実行されているアプリケーションにクラウドAPIアクセスを提供する方法があります。例：
AWS EC2 Roles（「EC2 Role」を検索）
多くのユーザーは、Atlantisが実行されている場所で環境変数を設定します。例：AWS_ACCESS_KEY
他のユーザーは、Atlantisが実行されている場所で必要な設定ファイルを作成します。例：~/.aws/credentials
HashiCorp Vault Providerを使用してプロバイダー資格情報を取得します。
Atlantisが 実行されている コンテナには、AtlantisがTerraformを介して管理しているプロバイダー（AWS、GCP、Githubなど）への特権資格情報が含まれている可能性が非常に高いです。
デフォルトでは、Atlantisはlocalhostのポート4141でウェブページを実行します。このページでは、atlantis applyを有効/無効にし、リポジトリのプランステータスを確認し、ロックを解除することができます（変更を加えることはできないため、それほど便利ではありません）。
インターネットに公開されていることはないと思いますが、デフォルトではアクセスするために資格情報は必要ないようです（必要な場合はatlantis:atlantisがデフォルトです）。
atlantis serverの設定は、コマンドラインフラグ、環境変数、設定ファイル、またはその3つの組み合わせを介して指定できます。
Atlantisサーバーがサポートするフラグのリストをここで見つけることができます。
設定オプションを環境変数に変換する方法をここで見つけることができます。
値はこの順序で選択されます：
フラグ
環境変数
設定ファイル
設定の中には、トークンやパスワードなどの興味深い値が含まれている可能性があることに注意してください。
いくつかの設定はリポジトリの管理方法に影響します。ただし、各リポジトリが異なる設定を必要とする可能性があるため、各リポジトリを指定する方法があります。これが優先順位です：
リポジトリ/atlantis.ymlファイル。このファイルは、atlantisがリポジトリをどのように扱うべきかを指定するために使用できます。ただし、デフォルトでは、いくつかのキーはここで指定できず、それを許可するフラグが必要です。
おそらくallowed_overridesやallow_custom_workflowsのようなフラグによって許可される必要があります。
サーバーサイド設定：フラグ--repo-configで渡すことができ、各リポジトリの新しい設定を構成するyamlです（正規表現がサポートされています）。
デフォルト値
PR Protections
Atlantisは、PRが誰かによって**承認されることを望むかどうか（ブランチ保護に設定されていなくても）や、マージ可能（ブランチ保護が通過した）であることを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を与えることになります。
Conftest ポリシーのチェック
Atlantis は、プラン出力に対して サーバーサイド conftest ポリシー を実行することをサポートしています。このステップを使用する一般的なユースケースには以下が含まれます：
モジュールのリストの使用を拒否する
リソースの作成時に属性を主張する
意図しないリソースの削除をキャッチする
セキュリティリスクを防ぐ（例：安全なポートを公開すること）
ドキュメントで設定方法を確認できます。
ドキュメントには、Atlantis を実行するために使用できるオプションが記載されています：
もしエクスプロイト中にこのエラーが表示された場合: Error: Error acquiring the state lock
次のコマンドを実行することで修正できます:
リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。もし**atlantis planを実行できる**（または自動的に実行されるかもしれません）場合、Atlantisサーバー内でRCEを実行できるようになります。
これは、Atlantisに外部データソースを読み込ませることで実現できます。次のようなペイロードをmain.tfファイルに入れるだけです：
ステルス攻撃
この攻撃をよりステルス的な方法で実行するには、次の提案に従ってください：
revシェルを直接terraformファイルに追加する代わりに、revシェルを含む外部リソースを読み込むことができます：
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をmasterに作成する代わりに、2つのブランチ（test1とtest2）を作成し、一方からもう一方へのPRを作成します。攻撃が完了したら、PRとブランチを削除します。
atlantis plan（terraform plan）を実行することで、terraformで使用される秘密をダンプできます。terraformファイルに次のようなものを入れます：
リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。atlantis applyを実行できる場合、Atlantisサーバー内でRCEを実行できるようになります。
ただし、通常はいくつかの保護を回避する必要があります：
マージ可能: この保護がAtlantisに設定されている場合、PRがマージ可能な場合にのみatlantis applyを実行できます（つまり、ブランチ保護を回避する必要があります）。
潜在的なブランチ保護の回避策を確認してください。
承認済み: この保護がAtlantisに設定されている場合、atlantis applyを実行する前に他のユーザーがPRを承認する必要があります。
デフォルトでは、Gitbotトークンを悪用してこの保護を回避できます。
悪意のあるTerraformファイルで**terraform applyを実行するには**、local-execを使用します。
main.tfファイルに以下のようなペイロードが含まれていることを確認する必要があります：
前の技術からの提案に従って、この攻撃をより隠密に実行します。
atlantis plan または atlantis apply を実行すると、terraform が内部で実行されます。atlantis から terraform にコマンドを渡すには、次のようにコメントします:
何かを渡すことができるのは、いくつかの保護を回避するのに役立つかもしれないenv変数です。terraform env varsを確認してください https://www.terraform.io/cli/config/environment-variables
atlantis.yamlファイルに指定された悪意のあるカスタムビルドコマンドを実行します。Atlantisはプルリクエストブランチのatlantis.yamlファイルを使用し、masterのものではありません。
この可能性は前のセクションで言及されました：
サーバーサイド設定フラグallow_custom_workflowsがTrueに設定されている場合、ワークフローは各リポジトリの**atlantis.yamlファイルに指定できます。また、allowed_overridesがワークフローをオーバーライドする**ために指定されることも潜在的に必要です。
これにより、そのリポジトリにアクセスできる任意のユーザーにAtlantisサーバーでのRCEが与えられます。
もしサーバーサイド設定フラグallowed_overridesがapply_requirementsを設定している場合、リポジトリはプラン/適用保護を変更してバイパスすることが可能です。
もし誰かがあなたの有効なプルリクエストに**atlantis plan/apply**のコメントを送信すると、望まないタイミングでterraformが実行されます。
さらに、新しいコミットがプッシュされたときにすべてのPRを再評価するようにブランチ保護が設定されていない場合、誰かがterraform設定に悪意のある設定を書き込み（前のシナリオを確認）、atlantis plan/applyを実行してRCEを得ることができます。
これがGithubブランチ保護の設定です：
もしあなたが使用されているwebhook secretを盗むことができた場合、またはwebhook secretが使用されていない場合、あなたはAtlantis webhookを呼び出し、atlantisコマンドを直接実行することができます。
Bitbucket Cloudはwebhook secretsをサポートしていません。これにより攻撃者がBitbucketからのリクエストを偽装することが可能になります。BitbucketのIPのみを許可していることを確認してください。
これは、攻撃者がBitbucketから来ているように見える偽のリクエストをAtlantisに送信できることを意味します。
--repo-allowlistを指定している場合、彼らはそのリポジトリに関連するリクエストのみを偽装できるため、最も大きな被害はあなた自身のリポジトリでのplan/applyになります。
これを防ぐために、BitbucketのIPアドレスを許可リストに追加してください（Outbound IPv4 addressesを参照）。
サーバーへのアクセスを得た場合、または少なくとも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のコマンドライン（機密データを含む可能性があります）
誰でも公共のプルリクエストにコメントできるため、すべてのセキュリティ対策が利用可能であっても、適切なセキュリティ設定の構成なしに公共のリポジトリでAtlantisを実行することは依然として危険です。
--allow-fork-prs公共のリポジトリで実行している場合（推奨されません、上記を参照）、--allow-fork-prsを設定すべきではありません（デフォルトはfalse）なぜなら、誰でも自分のフォークからあなたのリポジトリにプルリクエストを開くことができるからです。
--repo-allowlistAtlantisは、--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を参照してください。
攻撃者が悪意のあるTerraformコードを含むプルリクエストを提出することが脅威モデルに含まれている場合、terraform applyの承認だけでは不十分であることを認識する必要があります。terraform planで悪意のあるコードを実行することが可能であり、externalデータソースを使用するか、悪意のあるプロバイダーを指定することができます。このコードは、あなたの資格情報を外部に流出させる可能性があります。
これを防ぐために、次のことができます：
プロバイダーをAtlantisイメージに組み込むか、ホストして本番環境での出口を拒否します。
プロバイダー登録プロトコルを内部で実装し、公共の出口を拒否します。そうすれば、誰がレジストリへの書き込みアクセスを持っているかを制御できます。
サーバー側リポジトリ設定のplanステップを変更して、許可されていないプロバイダーやデータソース、許可されていないユーザーからのPRの使用を検証します。この時点で、PRがplanを続行する前に「いいね」を要求するなどの追加の検証を追加することもできます。Conftestが役立つかもしれません。
Atlantisは、$ATLANTIS_GH_WEBHOOK_SECRET/$ATLANTIS_GITLAB_WEBHOOK_SECRET環境変数を介してWebhookシークレットを設定して実行する必要があります。--repo-allowlistフラグが設定されていても、webhook secretがないと、攻撃者は許可リストに載っているリポジトリを装ってAtlantisにリクエストを送信することができます。Webhookシークレットは、webhookリクエストが実際にあなたのVCSプロバイダー（GitHubまたはGitLab）から来ていることを保証します。
Azure DevOpsを使用している場合、webhookシークレットの代わりに基本的なユーザー名とパスワードを追加してください。
Azure DevOpsは、すべてのwebhookイベントで基本認証ヘッダーを送信することをサポートしています。これには、webhookの場所にHTTPS URLを使用する必要があります。
webhookシークレットを使用しているが、トラフィックがHTTP上である場合、webhookシークレットが盗まれる可能性があります。--ssl-cert-fileおよび--ssl-key-fileフラグを使用してSSL/HTTPSを有効にしてください。
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として渡すこともできます。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
