AWS Secrets Manager enumeration: Risiken und Angriffsvektoren in der Praxis

Cloud-Sicherheitsbewertungen beginnen oft mit einer zentralen Phase: der Enumeration. Dabei analysieren Sicherheitsverantwortliche Berechtigungen, identifizieren Angriffsflächen und prüfen auf mögliche Fehlkonfigurationen. Ein aktuelles Labor von cybr.com demonstriert, wie Angreifer mit einfachen AWS-CLI-Befehlen sensible Geheimnisse aus Secrets Manager extrahieren – und welche Konsequenzen dies für Unternehmen haben kann.

Die erste Phase: Identitätsvalidierung im AWS-Ökosystem

Jede Sicherheitsanalyse beginnt mit der Frage: Wer hat Zugriff auf die Umgebung? Nach dem Erwerb von AWS-Zugangsdaten wird zunächst der aktuelle Identitätskontext abgefragt. Dies geschieht mit einem einfachen Befehl über die AWS CLI:

aws sts get-caller-identity --profile SecretsManagerEnum

Die Antwort liefert ein JSON-Objekt mit den relevanten Metadaten:

{
  "UserId": "AIDAQGYBPW3JHDS5K4A75",
  "Account": "014498641618",
  "Arn": "arn:aws:iam::014498641618:user/Julie"
}

Die Ausgabe bestätigt, dass die Berechtigungen einer IAM-Benutzerin namens Julie in einem bestimmten AWS-Konto zugeordnet sind. Dieser Schritt ist entscheidend, um den Umfang möglicher Zugriffsrechte zu verstehen.

Berechtigungsanalyse: Welche Aktionen sind erlaubt?

Nach der Identitätsbestätigung folgt die Überprüfung der tatsächlichen Berechtigungen. Dazu werden die direkt an die Benutzerin geknüpften IAM-Richtlinien analysiert. Ein erster Befehl listet die vorhandenen Richtlinien auf:

aws iam list-user-policies --user-name julie --profile SecretsManagerEnum

Die Antwort zeigt eine Richtlinie mit dem Namen AllowReadSecretsManager. Um die genauen Zugriffsrechte zu prüfen, wird der Inhalt dieser Richtlinie ausgelesen:

aws iam get-user-policy --user-name julie --policy-name AllowReadSecretsManager --profile SecretsManagerEnum

Die Richtlinie setzt sich aus drei zentralen Blöcken zusammen:

• AllowIAMActions: Erlaubt das Lesen von IAM-Profilen und Richtlinien – eine typische Konfiguration für Diagnosezwecke.
• AllowListSecrets: Gewährt den Zugriff auf Metadaten aller Geheimnisse im Konto, unabhängig vom Speicherort.
• AllowSecretsManagerActions: Beschränkt die Extraktion von Geheimnissen auf zwei spezifische Präfixe: sm-enumerate-password* und sm-enumerate-api-key*.

Diese Aufteilung zeigt ein häufiges Missverständnis: Während die Auflistung von Geheimnissen global erlaubt ist, gilt dies nicht für deren Inhalte.

Geheimnisse aufspüren: Die Enumeration von Secrets Manager

Mit der Berechtigung secretsmanager:ListSecrets kann nun eine vollständige Übersicht aller im Konto gespeicherten Geheimnisse erstellt werden:

aws secretsmanager list-secrets --profile SecretsManagerEnum

Die Ausgabe identifiziert zwei Geheimnisse, die den in der Richtlinie definierten Beschränkungen entsprechen:

• sm-enumerate-password: Enthält ein Passwort
• sm-enumerate-api-key: Enthält einen API-Schlüssel

Beide Geheimnisse folgen dem geforderten Namensmuster und sind damit potenziell angreifbar.

Sensible Daten extrahieren: Vom Geheimnis zum Klartext

Die Richtlinie erlaubt die Extraktion dieser beiden konkreten Geheimnisse. Zunächst wird das Passwort abgerufen:

aws secretsmanager get-secret-value --secret-id sm-enumerate-password --profile SecretsManagerEnum

Die Antwort enthält die geheimen Daten im Feld SecretString:

{
  "ARN": "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-password-cSojGz",
  "Name": "sm-enumerate-password",
  "SecretString": "{\"password\":\"cybr-labs-are-super-fun-2211\"}"
}

Analog wird der API-Schlüssel extrahiert:

aws secretsmanager get-secret-value --secret-id sm-enumerate-api-key --profile SecretsManagerEnum

Die Ausgabe zeigt einen Base64-codierten Wert:

{
  "ARN": "arn:aws:secretsmanager:us-east-1:014498641618:secret:sm-enumerate-api-key-zShLNz",
  "Name": "sm-enumerate-api-key",
  "SecretString": "{\"secret-api-key\":\"Y3lici1sYWJzLWZha2UtYXBpLWtleS0xMTIy\"}"
}

Um den Klartext zu erhalten, wird die Base64-Kodierung mit einem einfachen Linux-Befehl decodiert:

echo "Y3lici1sYWJzLWZha2UtYXBpLWtleS0xMTIy" | base64 -d

Das Ergebnis ist ein lesbarer API-Schlüssel: cybr-labs-fake-api-key-1122.

Lehren aus dem Labor: Wie man solche Schwachstellen verhindert

Die Demonstration von cybr.com zeigt eindrücklich, wie leicht sensible Daten durch unsachgemäße Konfiguration von Secrets Manager exponiert werden können. Unternehmen sollten folgende Maßnahmen ergreifen:

• Granulare Berechtigungen: Vermeiden Sie globale ListSecrets-Zugriffe. Beschränken Sie Geheimnisse auf spezifische Teammitglieder oder Rollen.
• Namenskonventionen: Nutzen Sie präzise Namensmuster und verweigern Sie Berechtigungen für Wildcards wie *.
• Regelmäßige Audits: Überprüfen Sie regelmäßig IAM-Richtlinien und Secrets Manager-Konfigurationen auf Fehlkonfigurationen.
• Multi-Faktor-Authentifizierung: Erzwingen Sie zusätzliche Sicherheitsstufen für den Zugriff auf sensible Geheimnisse.

Die Cloud bietet enorme Flexibilität – doch ohne strenge Sicherheitsvorkehrungen können scheinbar harmlose Einstellungen zu schwerwiegenden Datenlecks führen. Regelmäßige Sicherheitsbewertungen und das Prinzip der minimalen Berechtigungen sind der Schlüssel, um solche Risiken zu minimieren.