AWS - S3 Post Exploitation

Reading time: 4 minutes

S3

Für weitere Informationen siehe:

AWS - S3, Athena & Glacier Enum

Sensitive Informationen

Manchmal findest du sensible Informationen, die in den Buckets lesbar sind. Zum Beispiel terraform state secrets.

Pivoting

Verschiedene Plattformen könnten S3 verwenden, um sensible Assets zu speichern.
Zum Beispiel könnte airflow dort DAGs code ablegen, oder web pages könnten direkt von S3 ausgeliefert werden. Ein Angreifer mit Schreibrechten könnte den Inhalt des Buckets modify the code um auf andere Plattformen zu pivot, oder durch das Modifizieren von JS-Dateien takeover accounts.

S3 Ransomware

In diesem Szenario erstellt der Angreifer einen KMS (Key Management Service) key in seinem eigenen AWS-Konto oder in einem anderen kompromittierten Konto. Anschließend macht er diesen key weltweit für jedermann zugänglich, sodass jeder AWS-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem key verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.

Der Angreifer identifiziert einen Ziel-S3 bucket und erhält Schreibzugriff darauf, indem er verschiedene Methoden einsetzt. Dies kann an einer schlechten Bucket-Konfiguration liegen, die ihn öffentlich zugänglich macht, oder daran, dass der Angreifer Zugang zur AWS-Umgebung selbst erlangt hat. Typischerweise zielt der Angreifer auf Buckets ab, die sensible Informationen wie personally identifiable information (PII), protected health information (PHI), Logs, Backups und Ähnliches enthalten.

Um zu bestimmen, ob der Bucket für Ransomware angegriffen werden kann, prüft der Angreifer dessen Konfiguration. Dazu gehört zu überprüfen, ob S3 Object Versioning aktiviert ist und ob multi-factor authentication delete (MFA delete) aktiviert ist. Ist Object Versioning nicht aktiviert, kann der Angreifer fortfahren. Ist Object Versioning aktiviert, aber MFA delete deaktiviert, kann der Angreifer Object Versioning deaktivieren. Sind sowohl Object Versioning als auch MFA delete aktiviert, wird es für den Angreifer deutlich schwieriger, diesen spezifischen Bucket mit Ransomware zu belegen.

Mit der AWS API ersetzt der Angreifer jedes Objekt im Bucket durch eine mit seinem KMS key verschlüsselte Kopie. Dadurch werden die Daten im Bucket effektiv verschlüsselt und ohne den key unzugänglich.

Um zusätzlichen Druck aufzubauen, plant der Angreifer die Löschung des in der Attacke verwendeten KMS keys. Dadurch erhält das Ziel ein 7-tägiges Zeitfenster, um seine Daten wiederherzustellen, bevor der key gelöscht wird und die Daten dauerhaft verloren sind.

Abschließend kann der Angreifer eine letzte Datei hochladen, üblicherweise mit dem Namen "ransom-note.txt", die Anweisungen für das Ziel enthält, wie es seine Dateien zurückerlangen kann. Diese Datei wird unverschlüsselt hochgeladen, vermutlich um die Aufmerksamkeit des Ziels zu erregen und auf den Ransomware-Angriff hinzuweisen.

For more info check the original research.