# AWS - STS Privesc

{{#include ../../../../banners/hacktricks-training.md}}

## STS

### `sts:AssumeRole`

すべてのロールは **role trust policy** によって作成されます。このポリシーは **誰が作成されたロールを引き受けられるか** を示します。もし **同一アカウント** のロールがあるアカウントに引き受けを許可している場合、そのアカウントはそのロールにアクセスでき（場合によっては **privesc**）ということを意味します。

例えば、次の role trust policy は誰でもそのロールを引き受けられることを示しており、したがって **任意のユーザーがそのロールに紐づく権限へ privesc できる** ことを意味します。
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}
```
次のコマンドを実行してロールを引き受けることができます:
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**潜在的な影響:** Privesc to the role.

> [!CAUTION]
> この場合、許可 `sts:AssumeRole` は悪用対象のロールに**記載されている必要があり**、攻撃者のポリシーに含まれていてはいけないことに注意してください。\
> 例外が1つありますが、別アカウントのロールを**引き受ける**には、攻撃者アカウント**もまた**そのロールに対して**`sts:AssumeRole`**を持っている必要があります。


### `sts:AssumeRoleWithSAML`

このロールの信頼ポリシーは、**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"
}
}
}
]
}
```
ロールを偽装するための認証情報を生成するには、一般的に次のようなものを使用できます:
```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):
```bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
```
**Potential Impact:** ロールへのPrivesc。

### `sts:AssumeRoleWithWebIdentity`

この権限は、web identity provider を通じて、**mobile、web application、EKS...で認証されたユーザー** のために一時的なセキュリティ認証情報のセットを取得することを許可します。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)

例えば、**EKS service account** が **IAM role をなりすます** ことができるようにする場合、**`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** にトークンを持ち、次のようにして **ロールを引き受けて資格情報を取得する** ことができます:
```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
```
### Federation Abuse

{{#ref}}
../../aws-basic-information/aws-federation-abuse.md
{{#endref}}

### IAM Roles Anywhere Privesc

AWS IAM RolesAnywhere は、AWS 外のワークロードが X.509 certificates を使って IAM ロールを引き受けることを可能にします。しかし、trust policies が適切にスコープされていないと、privilege escalation に悪用される可能性があります。

この攻撃を理解するには、trust anchor が何であるかを説明する必要があります。AWS IAM Roles Anywhere における trust anchor は信頼のルートとなるエンティティで、アカウントに登録された Certificate Authority (CA) の公開証明書を含み、AWS が提示された X.509 certificates を検証できるようにします。こうして、クライアント証明書がその CA によって発行され、かつ trust anchor が有効であれば、AWS はそれを有効と認識します。

さらに、profile は X.509 certificate のどの属性（CN、OU、SAN など）をセッションタグに変換するかを定義する設定で、これらのタグは後で trust policy の条件と比較されます。

この trust policy には、どの trust anchor や証明書属性が許可されるかに関する制限が欠けています。その結果、アカウント内の任意の trust anchor に紐付いた任意の証明書が、このロールを assume するために使用できてしまいます。
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rolesanywhere.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity",
"sts:TagSession"
]
}
]
}

```
privesc を行うには、`aws_signing_helper` を https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html から入手する必要があります。

その後、有効な証明書を使用すると、攻撃者はより高い特権のロールにpivotできます。
```bash
aws_signing_helper credential-process \
--certificate readonly.pem \
--private-key readonly.key \
--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
--role-arn arn:aws:iam::123456789012:role/Admin
```
トラストアンカーはクライアントの `readonly.pem` 証明書が正規の CA から発行されたものであることを検証し、この `readonly.pem` 証明書内には署名が対応する秘密鍵 `readonly.key` で作成されたことを AWS が検証するための公開鍵が含まれています。

証明書はまた、CN や OU のような属性を提供し、`default` プロファイルがそれらをタグに変換します。ロールのトラストポリシーはこれらのタグを用いてアクセスを許可するかどうかを判断できます。トラストポリシーに条件がない場合、それらのタグは意味を持たず、有効な証明書を持つ誰にでもアクセスが許可されます。

この攻撃が可能であるためには、トラストアンカーと `default` プロファイルの両方が有効でなければなりません。

### 参考

- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)

{{#include ../../../../banners/hacktricks-training.md}}
