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

This commit is contained in:
Translator
2025-09-30 19:17:29 +00:00
parent 1a9662913b
commit 773b8dd296

View File

@@ -6,9 +6,9 @@
### `sts:AssumeRole`
すべてのロールは **role trust policy** とともに作成されます。このポリシーは **who can assume the created role** を示します。もし **same account** のロールがあるアカウントに対して assume を許可していると記述されている場合、そのアカウントはそのロールにアクセスでき(場合によっては **privesc** する可能性があります)。
すべてのロールは **ロール信頼ポリシー(role trust policy** とともに作成されます。このポリシーは、**どの主体が作成されたロールを引き受けることができるか** を示します。もし同一アカウント(**same account**のロールがあるアカウントに対して引き受けを許可している場合、そのアカウントはそのロールにアクセスでき(そして場合によっては **privesc** する可能性があります)。
例えば、以下の role trust policy は誰でも assume できることを示しており、したがって **any user will be able to privesc** してそのロールに紐づく権限を取得できることになります
例えば、次のロール信頼ポリシーは誰でもそのロールを引き受けられることを示しており、したがって **任意のユーザーがそのロールに関連付けられた権限へprivescできる**
```json
{
"Version": "2012-10-17",
@@ -23,22 +23,21 @@
]
}
```
次のコマンドを実行することでロールを偽装できます:
次のコマンドを実行してロールをなりすますことができます:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**潜在的影響:** ロールに対するPrivesc。
**潜在的影響:** ロールへのPrivesc。
> [!CAUTION]
> このケースでは、許可 `sts:AssumeRole` は**悪用対象のロールに明示されている必要があり**、攻撃者に属するポリシーではないことに注意してください。\
> 例外が1つありますが、**別アカウントのロールを引き受ける**ためには、攻撃者アカウントそのロールに対して**`sts:AssumeRole`**を持っている必要があります。
> この場合、権限 `sts:AssumeRole` は悪用対象のロールに**明示されている必要があり**、攻撃者に属するポリシーには必要ないことに注意してください。\
> ただし例外がつあり、**別アカウントのロールをassumeするためには**、攻撃者アカウントそのロールに対して**`sts:AssumeRole`**を**も持っている必要があります**
### `sts:AssumeRoleWithSAML`
このロールの信頼ポリシーは、SAMLで認証された**ユーザーにロールをなりすますアクセスを付与する**
このロールの信頼ポリシーは、**SAML で認証されたユーザーにロールを偽装するアクセスを付与します。**
An example of a trust policy with this permission is:
この権限を持つ信頼ポリシーの例は次のとおりです:
```json
{
"Version": "2012-10-17",
@@ -59,21 +58,21 @@ An example of a trust policy with this permission is:
]
}
```
一般的に、そのロールをなりすますための認証情報を生成するには、次のようなものを使用できます:
一般的に role を成りすますための認証情報を生成するには、次のようなものを使用できます:
```bash
aws sts assume-role-with-saml --role-arn <value> --principal-arn <value>
```
ただし、**providers** はこれを簡単にするための **own tools** を持っているかもしれません。例えば [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
```
**潜在的な影響:** Privesc to the role.
**Potential Impact:** ロールへのPrivesc.
### `sts:AssumeRoleWithWebIdentity`
この権限は、web identity provider を使ってモバイルやウェブアプリケーション、EKS などで認証されたユーザーに対して、一時的なセキュリティ認証情報のセットを取得することを許可します。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
この権限は、web identity provider を使ってmobile、web application、EKS... などで認証されたユーザーが一連の一時的なセキュリティ認証情報を取得することを許可します。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
例えば、**EKS service account** が **impersonate an IAM role** できるようにする場合、トークンは **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** にあり、次のようにして **assume the role and get credentials** ことができます:
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:
```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
@@ -86,9 +85,13 @@ aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/
### IAM Roles Anywhere Privesc
AWS IAM RolesAnywhere は、AWS 外のワークロードが X.509 certificates を使用して IAM roles を引き受けることを可します。しかし、trust policies が適切にスコープ化(制限)されていない場合、これらは privilege escalation に悪用される可能性があります。
AWS IAM RolesAnywhere は、AWS 外のワークロードが X.509 証明書を使って IAM ロールを引き受けることを可能にします。しかし、trust policies が適切にスコープされていない場合、これが権限昇格のために悪用されることがあります。
このポリシーは、どの trust anchor や certificate attributes が許可されるかについての制限を欠いています。その結果、アカウント内の任意の trust anchor に紐づく任意の certificate がこの role を assume するために使用できます。
この攻撃を理解するには、trust anchorトラストアンカーが何かを説明する必要があります。AWS IAM RolesAnywhere における trust anchor は信頼の根幹となるエンティティで、アカウントに登録された Certificate Authority (CA) の公開証明書を含み、AWS が提示された X.509 証明書を検証できるようにします。つまり、クライアント証明書がその CA によって発行され、かつ trust anchor が有効であれば、AWS はそれを有効な証明書として認識します。
また、profile は X.509 証明書のどの属性CN、OU、SAN など)を session tags に変換するかを定義する設定で、これらのタグは後に trust policy の条件と照合されます。
このポリシーには、どの trust anchor や証明書属性が許可されるかについての制限が欠けています。その結果、アカウント内の任意の trust anchor に紐づく任意の証明書がこのロールを引き受けるために使用できてしまいます。
```json
{
"Version": "2012-10-17",
@@ -108,9 +111,9 @@ AWS IAM RolesAnywhere は、AWS 外のワークロードが X.509 certificates
}
```
privesc を行うには、`aws_signing_helper` を https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html から取得する必要があります。
privescするには、`aws_signing_helper` を https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html から入手する必要があります。
その後、有効な証明書を使うことで attacker はより高い権限の role に pivot できます。
その後、有効な証明書を使用することで、攻撃者はより高い権限のロールにpivotできます。
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
@@ -119,13 +122,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` によって作成されたことを確認します。
トラストアンカーはクライアント`readonly.pem`証明書が許可されたCAから発行されたことを検証し、その`readonly.pem`証明書には署名が対応する秘密鍵`readonly.key`で行われたことをAWSが検証するために使用する公開鍵が含まれています。
証明書はまた本人確認を行い、CN や OU のような属性を提供します。`default` プロファイルこれらの属性をタグに変換しロールの trust policy がアクセス許可を決定する際に使用できます。もし trust policy に条件がなければ、それらのタグは無視され、有効な証明書を持つ誰でも通過が許可されます。
証明書はまた、CNやOUなどの属性を提供し`default`プロファイルこれらをタグに変換します。ロールのトラストポリシーはこれらのタグを使ってアクセス許可を判断できます。トラストポリシーに条件が設定されていない場合、これらのタグは意味を持たず、有効な証明書を持つ誰でもアクセスが付与されます。
この攻撃可能にするには、trust anchor と `default` プロファイルの両方が有効である必要があります。
この攻撃可能になるためには、トラストアンカーと`default`プロファイルの両方が有効である必要があります。
### 参考
### References
- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)