gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2025-12-06 04:41:21 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat

Browse Source
This commit is contained in:
Translator
2025-09-29 22:38:45 +00:00
parent 4b11873aed
commit 70dee081a0
2 changed files with 45 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
View File

@@ -1,4 +1,4 @@
# AWS - STS ポストエクスプロイテーション
# AWS - STS Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
@@ -10,14 +10,14 @@
../aws-services/aws-iam-enum.md
{{#endref}}
### IAM クレデンシャルからコンソールへ
### From IAM Creds to Console
IAM クレデンシャルを取得できた場合、次のツールを使用して**ウェブコンソールにアクセスすること**に興味があるかもしれません。\
ユーザー/ロールは**`sts:GetFederationToken`**の権限を持っている必要があります。
もし IAM credentials を入手できた場合、以下のツールを使って **web console にアクセス** することに興味があるかもしれません。\
注意: ユーザー/ロールは **`sts:GetFederationToken`** の権限を持っている必要があります。
#### カスタムスクリプト
次のスクリプトは、デフォルトプロファイルとデフォルトの AWS ロケーション（政府および中国以外）を使用して、ウェブコンソールにログインするために使用できる署名付き URL を提供します:
以下のスクリプトはデフォルトプロファイルとデフォルトの AWS ロケーション（gov と cn 以外）を使用して、web console にログインするために使える署名付き 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
@@ -55,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
```
#### aws_consoler
**ウェブコンソールリンクを生成**できます [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) を使って **Web コンソールのリンクを生成できます**。
```bash
cd /tmp
python3 -m venv env
@@ -64,22 +64,22 @@ pip install aws-consoler
aws_consoler [params...] #This will generate a link to login into the console
```
> [!WARNING]
> IAMユーザーが `sts:GetFederationToken` 権限を持っていることを確認するか、引き受けるロールを提供してください。
> IAM user が `sts:GetFederationToken` 権限を持っていることを確認するか、assume する role を用意してください。
#### aws-vault
[**aws-vault**](https://github.com/99designs/aws-vault) は、開発環境でAWSの資格情報を安全に保存し、アクセスするためのツールです。
[**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]
> **aws-vault**を使用して**ブラウザコンソールセッション**を取得することもできます。
> また、**aws-vault** を使用して **ブラウザ コンソール セッション** を取得することもできます
### **PythonからのUser-Agent制限のバイパス**
### **Python からの User-Agent 制限のバイパス**
**ユーザーエージェント**に基づいて特定のアクションを実行する制限がある場合（ユーザーエージェントに基づいてpython boto3ライブラリの使用を制限するなど）、前述の技術を使用して**ブラウザ経由でウェブコンソールに接続**することが可能です。または、次のようにして**boto3のユーザーエージェントを直接変更**することもできます。
もし **User-Agent に基づいて特定の操作を行う制限がある**（例: User-Agent に基づいて python boto3 library の使用を制限するような場合）、前述の手法を使って **ブラウザ経由で web コンソールに接続する** ことが可能ですし、あるいは直接 **boto3 の User-Agent を変更する** と次のようにできます:
```bash
# Shared by ex16x41
# Create a client
@@ -92,4 +92,14 @@ client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda
# Perform the action
response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
```
### **`sts:GetFederationToken`**
この権限により、それを実行したユーザーのためのフェデレーテッドIDを作成できます。作成されるIDはそのユーザーが持つ権限に制限されます。
```bash
aws sts get-federation-token --name <username>
```
sts:GetFederationToken によって返されるトークンは、呼び出し元ユーザーのフェデレーテッドアイデンティティに属しますが、権限は制限されています。たとえユーザーが管理者権限を持っていても、IAM ユーザーの一覧表示やポリシーのアタッチなど、特定の操作はフェデレーテッドトークンでは実行できません。
さらに、この方法はややステルス性が高く、フェデレーテッドユーザーは AWS Portal に表示されないため、CloudTrail ログや監視ツールを通じてのみ確認できます。
{{#include ../../../banners/hacktricks-training.md}}

61
src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
View File

@@ -6,9 +6,9 @@
### `sts:AssumeRole`
すべてのロールは**ロール信頼ポリシー**で作成され、このポリシーは**誰が作成されたロールを引き受けることができるか**を示します。同じアカウントのロールが別のアカウントがそれを引き受けることができると言っている場合、そのアカウントはロールにアクセスできることを意味します（そして潜在的に**privesc**）。
すべてのロールは **role trust policy** とともに作成されます。このポリシーは **who can assume the created role** を示します。もし **same account** のロールがあるアカウントに対して assume を許可していると記述されている場合、そのアカウントはそのロールにアクセスでき（場合によっては **privesc** する可能性があります）。
例えば、以下のロール信頼ポリシーは誰でもそれを引き受けることができることを示しているため、**任意のユーザーがそのロールに関連付けられた権限にprivescできる**ことになります。
例えば、以下の role trust policy は誰でも assume できることを示しており、したがって **any user will be able to privesc** してそのロールに紐づく権限を取得できることになります。
```json
{
"Version": "2012-10-17",
@@ -23,41 +23,22 @@
]
}
```
ロールを偽装することができます:
次のコマンドを実行することでロールを偽装できます:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**潜在的な影響:** 役割への権限昇格。
**潜在的影響:** ロールに対するPrivesc。
> [!CAUTION]
> この場合、権限 `sts:AssumeRole` は **悪用する役割に明示されている必要があり**、攻撃者に属するポリシーには含まれていないことに注意してください。\
> 一つの例外を除き、**異なるアカウントから役割を引き受けるためには**、攻撃者アカウントもその役割に対して **`sts:AssumeRole`** を持っている必要があります。
> このケースでは、許可 `sts:AssumeRole` は**悪用対象のロールに明示されている必要があり**、攻撃者に属するポリシーではないことに注意してください。\
> 例外が1つありますが、**別アカウントのロールを引き受ける**ためには、攻撃者アカウントもそのロールに対して**`sts:AssumeRole`**を持っている必要があります。
### **`sts:GetFederationToken`**
この権限を持つことで、任意のユーザーを偽装するための資格情報を生成することが可能です：
```bash
aws sts get-federation-token --name <username>
```
この権限は、他のユーザーを偽装するアクセスを与えずに安全に付与することができます:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
}
]
}
```
### `sts:AssumeRoleWithSAML`
このロールを持つ信頼ポリシーは、**SAMLを介して認証されたユーザーにロールを偽装するアクセスを許可します。**
このロールの信頼ポリシーは、SAMLで認証された**ユーザーにロールをなりすますアクセスを付与する**。
この権限を持つ信頼ポリシーの例は次のとおりです:
An example of a trust policy with this permission is:
```json
{
"Version": "2012-10-17",
@@ -78,21 +59,21 @@ aws sts get-federation-token --name <username>
]
}
```
一般的に、ロールを偽装するための資格情報を生成するには、次のようなものを使用できます:
一般的に、そのロールをなりすますための認証情報を生成するには、次のようなものを使用できます:
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
しかし、**プロバイダー**は、[onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role)のように、これを簡単にするための**独自のツール**を持っているかもしれません。
ただし、**providers** はこれを簡単にするための **own tools** を持っているかもしれません。例えば [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
```
**潜在的な影響:** 役割への権限昇格。
**潜在的な影響:** Privesc to the role.
### `sts:AssumeRoleWithWebIdentity`
この権限は、**モバイル、ウェブアプリケーション、EKS...** でウェブアイデンティティプロバイダーによって認証されたユーザーのために、一連の一時的なセキュリティ資格情報を取得する権限を付与します。[詳細はこちら。](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
この権限は、web identity provider を使ってモバイルやウェブアプリケーション、EKS などで認証されたユーザーに対して、一時的なセキュリティ認証情報のセットを取得することを許可します。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
例えば、**EKSサービスアカウント**が**IAMロールを偽装**できる必要がある場合、**`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** にトークンがあり、次のようにして**ロールを引き受けて資格情報を取得**できます:
例えば、**EKS service account** が **impersonate an IAM role** できるようにする場合、トークンは **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** にあり、次のようにして **assume the role and get credentials** ことができます:
```bash
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --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
@@ -105,9 +86,9 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhereは、AWS外部のワークロードがX.509証明書を使用してIAMロールを引き受けることを可能にします。しかし、信頼ポリシーが適切にスコープされていない場合、特権昇格に悪用される可能性があります。
AWS IAM RolesAnywhere は、AWS 外のワークロードが X.509 certificates を使用して IAM roles を引き受けることを許可します。しかし、trust policies が適切にスコープ化（制限）されていない場合、これらは privilege escalation に悪用される可能性があります。
このポリシーは、どの信頼アンカーまたは証明書属性が許可されるかに制限がありません。その結果、アカウント内の任意の信頼アンカーに結びつけられた任意の証明書を使用してこのロールを引き受けることができます。
このポリシーは、どの trust anchor や certificate attributes が許可されるかについての制限を欠いています。その結果、アカウント内の任意の trust anchor に紐づく任意の certificate がこの role を assume するために使用できます。
```json
{
"Version": "2012-10-17",
@@ -127,9 +108,9 @@ AWS IAM RolesAnywhereは、AWS外部のワークロードがX.509証明書を使
}
```
プライベートエスカレーションには、https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html からの `aws_signing_helper` が必要です。
privesc を行うには、`aws_signing_helper` を https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html から取得する必要があります。
次に、有効な証明書を使用して、攻撃者はより高い権限のロールにピボットできます。
その後、有効な証明書を使うことで attacker はより高い権限の role に pivot できます。
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -138,7 +119,13 @@ aws_signing_helper credential-process \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
### 参考文献
trust anchor はクライアント証明書 `readonly.pem` が認可された CA から発行されたものかを検証します。trust anchor 作成時に CA の公開証明書が含まれており（現在は `readonly.pem` の検証に使用されています）。`readonly.pem` の中には公開鍵が含まれており、AWS はそれを使って署名が対応する秘密鍵 `readonly.key` によって作成されたことを確認します。
証明書はまた本人確認を行い、CN や OU のような属性を提供します。`default` プロファイルはこれらの属性をタグに変換し、ロールの trust policy がアクセス許可を決定する際に使用できます。もし trust policy に条件がなければ、それらのタグは無視され、有効な証明書を持つ誰でも通過が許可されます。
この攻撃を可能にするには、trust anchor と `default` プロファイルの両方が有効である必要があります。
### 参考
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)