Eine technische Analyse des Cloud-Fehlkonfigurationsvorfalls bei Capital One

UPDATE: 26. August 2019

Seit der Veröffentlichung dieses Beitrags hat AWS einige öffentliche Stellungnahmen zum Vorfall abgegeben, die Aufschluss darüber geben, was wahrscheinlich passiert ist. In der Antwort an Senator Ron Wyden erklärte AWS:

„Wie Capital One in seiner öffentlichen Mitteilung dargelegt hat, erfolgte der Angriff aufgrund eines Konfigurationsfehlers auf der Anwendungsebene einer von Capital One installierten Firewall, verschärft durch Berechtigungen, die Capital One festgelegt hatte und die wahrscheinlich weiter gefasst waren als beabsichtigt. Nachdem der Zugriff über die falsch konfigurierte Firewall erlangt worden war und weiter reichende Berechtigungen den Zugriff auf Ressourcen ermöglichten, gehen wir davon aus, dass ein SSRF-Angriff eingesetzt wurde (eine von mehreren Möglichkeiten, wie ein Angreifer nach dem Eindringen über die falsch konfigurierte Firewall möglicherweise auf Daten zugreifen konnte).“

„Wie oben erläutert, war SSRF nicht der Hauptfaktor bei dem Angriff. Uns sind keine anderen nennenswerten SSRF-Angriffe auf AWS-Kunden bekannt.“

Der wahrscheinliche SSRF-Aspekt des Vorfalls hat viel Aufmerksamkeit erhalten. AWS stellt jedoch klar, dass dies nicht der Hauptfaktor des Angriffs war. Entscheidend war vielmehr eine zu großzügige Konfiguration der Cloud-Ressourcen. In diesem Beitrag beschreibe ich ausführlich, wie diese Ressourcen möglicherweise falsch konfiguriert und die Fehlkonfigurationen ausgenutzt wurden.

URSPRÜNGLICHER BEITRAG: 1. August 2019

Diese technische Untersuchung zeigt anhand der Beweise aus der Strafanzeige, wie es möglicherweise zum Vorfall bei Capital One gekommen ist. Zunächst möchte ich sagen, dass ich großen Respekt vor dem Cloud-Team von Capital One habe und dort Freunde habe. Das Team war führend im Cloud-Computing, und was ihm passiert ist, hätte fast jedem passieren können. Ich kritisiere auch Amazon Web Services (AWS) nicht – meinen früheren Arbeitgeber. AWS bietet sichere Services, und ich habe nichts als Respekt für das Unternehmen. Mit diesem Beitrag möchte ich eine Kombination aus Firewall-, IAM- und S3-Angriff untersuchen, um einige der Gefahren von Cloud-Fehlkonfigurationen zu veranschaulichen, die jede Organisation in der Cloud ernst nehmen sollte.

Für diesen Beitrag habe ich die technischen Details der FBI-Beschwerde analysiert und anschließend eine Hypothese dazu entwickelt, wie der Angriff abgelaufen sein könnte. Danach habe ich den Angriff in meinem Entwicklungskonto simuliert, um in diesem Beitrag konkrete Details nennen zu können.

Die bekannten Fakten

Aus der FBI-Beschwerde und Beiträgen der mutmaßlichen Angreiferin in sozialen Medien liegen uns einige Informationen über den Angriff vor. Offenbar nutzte die Angreiferin Tor und IPredator, um ihre Identität zu verschleiern, und entdeckte über diese Dienste eine falsch konfigurierte Firewall in der AWS-Umgebung von Capital One. Unklar ist, ob es sich um einen gezielten Angriff auf Capital One handelte oder um einen opportunistischen Angriff, nachdem die Fehlkonfiguration entdeckt worden war.

Viele Artikel befassen sich mit den möglichen Beweggründen und der Biografie der Angreiferin. Darauf möchte ich nicht eingehen, sondern mich auf die technischen Einzelheiten konzentrieren. Uns sind vier verschiedene Elemente des Angriffs bekannt:

• Falsch konfigurierte Firewall

• Zugriff auf eine EC2-Instance erlangen

• Über eine IAM-Rolle Zugriff auf S3 erlangen

• S3-Buckets entdecken und kopieren.

Auf die einzelnen Punkte gehe ich im Folgenden genauer ein.

Wie der Angriff abgelaufen sein könnte

Wir kennen einige Details, aber nicht besonders viele. Deshalb musste ich einen beträchtlichen Teil der Fakten interpretieren und Vermutungen anstellen. Im Folgenden kennzeichne ich klar, wenn ich spekuliere. Das Diagramm unten zeigt meine Sandbox-Umgebung, in der ich einige Aspekte des Vorfalls bei Capital One simuliert habe.

Die Umgebung umfasst:

1. ein einfaches VPC-Netzwerk

2. eine Security Group, die HTTP(S) und SSH zulässt

3. einen privaten S3-Bucket

4. zwei IAM-Rollen – eine mit S3-Zugriff und eine ohne

5. eine EC2-Instance mit öffentlicher IP-Adresse und einer IAM-Rolle ohne S3-Zugriff

Mein Ziel war es, vom Shell-Zugriff auf die EC2-Instance zum Zugriff auf die S3-Daten in den privaten Buckets und deren Kopie zu gelangen.

Bevor wir uns die einzelnen Schritte genauer ansehen, ist erwähnenswert, dass das FBI durch einen Hinweis auf eine auf GitHub gehostete Datei auf den Fall aufmerksam wurde. Die Datei enthielt die IP-Adresse eines Servers und drei Befehle:

„Capital One stellte fest, dass die Datei vom 21. April Code für drei Befehle sowie eine Liste mit mehr als 700 Ordnern oder Daten-Buckets enthielt.“ Wir gehen auf jeden dieser Befehle ein und darauf, was sie gewesen sein könnten und welche Strategie die Angreiferin möglicherweise verfolgt hat.

Schritt eins: falsch konfigurierte Firewall

Laut FBI-Beschwerde: „Eine Fehlkonfiguration der Firewall ermöglichte es, Befehle an den Server zu senden und dort auszuführen. Dadurch wurde der Zugriff auf Ordner oder Buckets ermöglicht … (III.A.10)“

Das deutet darauf hin, dass die Firewall extern und nicht lokal auf dem Server eingerichtet war, auch wenn dies nicht ausdrücklich gesagt wird. Für AWS sind zahlreiche virtuelle Firewall-Appliances verfügbar, aber üblicherweise würde es sich um eine Security Group handeln. Offenbar war bei der verwendeten Firewall ein gefährlicher Port geöffnet, was den Angriff möglicherweise erst ermöglichte. Vielleicht war ein SSH-Port für Wartungsarbeiten vorübergehend geöffnet worden, oder der betreffende Server stammte noch aus der Entwicklungsphase und wurde nicht mehr verwendet. Eine andere Möglichkeit ist, dass auf dem Server eine Anwendung wie MongoDB oder ElasticSearch lief, die einen offenen Port benötigt, aber niemals über die Firewall dem Internet hätte ausgesetzt werden dürfen. Wie auch immer die genauen Umstände aussahen: Die Angreiferin fand einen Weg in die Cloud-Computing-Infrastruktur von Capital One.

Schritt zwei: Zugriff auf eine EC2-Instance erlangen

Da die FBI-Beschwerde die kompromittierte Entität als „Server“ beschreibt und die Angreiferin daraus IAM-Anmeldedaten extrahieren konnte, scheint anschließend eine EC2-Instance kompromittiert worden zu sein. Möglicherweise lag eine Schwachstelle in einer Anwendung oder im Betriebssystem vor – wir wissen es schlicht nicht. Für meine Simulation des Angriffs habe ich angenommen, dass die Angreiferin Shell-Zugriff, aber keinen Root-Zugriff auf die Instance erlangte, da für alle weiteren Schritte einfacher Shell-Zugriff ausreicht.

Schritt drei: über eine IAM-Rolle Zugriff auf S3 erlangen

… „Capital One stellte fest, dass der erste Befehl bei seiner Ausführung die Sicherheitsanmeldedaten für ein Konto namens ***-WAF-Role abrief. Dieses ermöglichte wiederum den Zugriff auf bestimmte Ordner von Capital One beim Cloud-Computing-Anbieter. (III.A.11)“

Ein großer Teil des „Geschehens“ bei diesem Vorfall drehte sich um den Zugriff über eine IAM-Rolle auf private S3-Buckets, offenbar mithilfe von AWS-CLI-Befehlen auf dem kompromittierten Server. In der Presse wurde der Name der Rolle bisher ausführlich diskutiert, aber es gibt keine eindeutigen Belege dafür, dass dieser Server selbst eine WAF war. In dynamischen AWS-Umgebungen ist es üblich, IAM-Rollen „auszuleihen“ (keine gute Praxis, aber durchaus verbreitet). Wie das folgende Beispiel zeigt, lassen sich außerdem Richtlinienzuordnungen ändern, und häufig enthalten sie „Role“ im Namen. Vielleicht war dieser Server einfach übrig geblieben und nicht mit Tags versehen, sodass er in Verwaltungs-Dashboards nicht auftauchte. Ich habe nur selten ein größeres AWS-Konto ohne verwaiste Ressourcen hier oder dort gesehen.

Falls der Server tatsächlich eine WAF war und absichtlich Lese- und Schreibzugriff auf Buckets und darin enthaltene Objekte mit personenbezogenen Daten (PII) hatte, wäre das aus naheliegenden Gründen eine naive Verteidigungsstrategie gewesen: Eine einzige Fehlkonfiguration der Firewall hätte sämtliche architektonischen Schutzmaßnahmen für sensible Daten umgehen können. Das ist jedoch nicht die einzige mögliche Erklärung für den Vorfall. Ich vermute, dass mehr dahintersteckte und IAM- sowie EC2-Funktionen genutzt wurden, die für Flexibilität entwickelt wurden, aber möglicherweise missbräuchlich zum Gewähren zusätzlicher Berechtigungen eingesetzt wurden.

Da von dem „ersten Befehl“ die Rede ist, halte ich es für plausibel, dass damit ein AWS-CLI-Skript gemeint ist. Wenn die EC2-Instance bereits Zugriff auf S3 hatte, hätte die Angreiferin lediglich etwas wie Folgendes ausführen müssen:

> curl http://169.254.169.254/latest/meta-data/iam/security-credentials/DemonstrationEC2Role

Mit diesem Befehl werden die aktuellen temporären IAM-Anmeldedaten der Rolle aus den Metadaten der EC2-Instance abgerufen. Die Ausgabe sieht so aus:

{

  "Code" : "Success",

  "LastUpdated" : "2019-07-31T19:41:16Z",

  "Type" : "AWS-HMAC",

  "AccessKeyId" : "***************",

  "SecretAccessKey" : "**************************",

  "Token" : "AgoJb3JpZ2luX2VjEDQaCXVzLWVhc3QtMiJGMEQCIG9qFNkzROR8KaLKTTxaWYpxuE1J8ogMUWLF6EhddivjAiB84nwhPoUQl4IIWb5oGfXjc3QzRTP7nm/fG8ANqGnrJyrjAwit//////////Hpraage6UuR7XmrrdM09c9thue+fbUjYYGFHtiun96KrcDeZrJXwV/Dj8+pbn2Ivw0UydaC7Jj+XUkr8izWG7h/Hpraage6UuR7XmrrdM09c9thue++IaAjZPsutjIhkDEuggqriQCdA/4QwHgXFAjs0VzgFly9l29EVWMzvIncKQEIGFxofqwhMcOpN4uP7wseMctpqVfUfjumC/EisdYFUo8UaDctYObXBCk8tL/HvvMmJrF0aDYmcsaQ8Geu67X9LQk45xr/Hpraage6UuR7XmrrdM09c9thue+qy0evQBJbqmfrhg1bZktctodqOkngdyFN/CYDu3jVIyiLxH/3PmGedzkjJ+julYzunhj9i8V5ej4UIyGDU2KOORaRosLM+lFDJSZDfiihWvfXYYDDJkLX+tJel9qFYTqDcppVTcIjJO8yJQOYRBAvk32nu1mdkQMmafl+CwxMfppbsrja9c6A/c16tv/WcPrCzmJiu6yqbk+4QwHgXFAjs0VzgFly9l29EVWMzvIncKQEIGFxofqwhMcOpN4uP7wseMctpqVfUfjumC+Hpraage6UuR7XmrrdM09c9thue/9ZmdktOg6HAtI89GOP10OE2gJ0Pq4Er/+hUh/+LOmi3QSoALCitT2d09o/iCcXY/zzCT3ofqBTq1AQ5XbIYPbAZiKVyquo2M6EYqiODBNsSQLiMBJgZldv8LOhYOgIxz302gTBvSr7zl2vWrm5gEr9twKx1ApMkaMY0h1kNTgwTsBHm9hVdvidN3QhBzt3s7u2nvcGx5r+dWDkTQ3BI6fD31tdDKOtm7fZO9ziSgFu8U3o3ncAytioWYGXXtZN2FLzBtqp+mq6E8gc1lZnoCGkGApXltdJVSC2+tkXQJLYyF1Ubd00GH+QV8cxE/zr4=",

  "Expiration" : "2019-08-01T02:17:11Z"

}

Where the access key and secret access key are replaced with *'s and the token corrupted to protect the innocent.

Damit wäre alles Nötige vorhanden, um auf die S3-Buckets und ihre Inhalte zuzugreifen.

Es gibt jedoch noch eine andere Möglichkeit, was dieser „erste Befehl“ bewirkt haben könnte. Alle, die AWS nutzen, sollten sie kennen. Wenn der kompromittierte Server keinen Zugriff auf die privaten S3-Buckets hatte, aber berechtigt war, IAM-Richtlinien aufzulisten und anzuhängen, hätte die Angreiferin diese Möglichkeiten nutzen können, um gewissermaßen nach passenden Anmeldedaten zu suchen. Da IAM-Berechtigungen häufig nicht an IP-basierte Netzwerkzugriffskontrollen gebunden sind und AWS-Services über IAM miteinander kommunizieren, bilden diese Rollen und Richtlinien eine Art alternatives Netzwerk, das ebenso geschützt werden muss wie ein herkömmliches Netzwerk. IAM wird so zu einem wichtigen Mittel für die „laterale Bewegung“ innerhalb der Cloud-Umgebung.

Der folgende Befehl ersetzt beispielsweise einen Satz von IAM-Berechtigungen durch einen anderen:

> aws ec2 replace-iam-instance-profile-association --association-id iip-assoc-00facaf2870f3bcc9 --iam-instance-profile Name=DemonstrationEC2Role

Dabei wird Folgendes ausgegeben. Das zeigt, dass ich die vorhandenen IAM-Berechtigungen erfolgreich durch die der Richtlinie DemonstrationEC2Role ersetzt habe:

{

    "IamInstanceProfileAssociation": {

        "InstanceId": "i-0f566edb3389ac1f7",

        "State": "associated",

        "AssociationId": "iip-assoc-00facaf2870f3bcc9",

        "IamInstanceProfile": {

            "Id": "AIPA6MYZKKFJL2Y2G5UPO",

            "Arn": "arn:aws:iam::989506195794:instance-profile/DemonstrationEC2Role"

        }

    }

}

Weitere nützliche Befehle für eine solche Suche sind:

> aws iam list-roles

> aws iam list-policies

> aws iam list-instance-profiles

Diese Befehle tun genau das, was ihr Name vermuten lässt: Sie listen alle verfügbaren IAM-Ressourcen auf, die für einen Angreifer interessant sein könnten, sobald er Shell-Zugriff auf eine EC2-Instance hat.

In diesem Beispiel habe ich ein eingeschränktes IAM-Profil durch eines mit zusätzlichen Berechtigungen für S3 ersetzt. Wir können nicht ausschließen, dass die Angreiferin beim Vorfall bei Capital One ähnlich vorgegangen ist. Unabhängig davon, ob das tatsächlich der Fall war, sollten Sie diese wichtige Funktion unbedingt berücksichtigen, wenn Sie IAM-Rollen für Ihre EC2-Instances konfigurieren – insbesondere für öffentlich zugängliche. IAM-Berechtigungen können den Zugriff auf private Ressourcen in Ihrer Umgebung faktisch „überbrücken“.

In beiden Szenarien erlangte die Angreiferin die nötigen Anmeldedaten, um Informationen aus S3 abzurufen und zu kopieren.

Schritt vier: S3-Buckets entdecken und kopieren

„Capital One stellte fest, dass der dritte Befehl (der „Sync-Befehl“) bei seiner Ausführung die ***-WAF-Role verwendete, um Daten aus den Ordnern oder Buckets im Speicher von Capital One zu extrahieren oder zu kopieren, für die das Konto ***-WAF-Role über die erforderlichen Berechtigungen verfügte. (III.A.11)“

Das deutet darauf hin, dass der AWS-CLI-Befehl `aws s3 sync` verwendet wurde. Für mich ist das ein weiterer Beleg dafür, dass die Angreiferin Shell-Zugriff auf die EC2-Instance erlangte und die AWS CLI für diese Befehle nutzte. Laut der Beschwerde des Justizministeriums listete die Angreiferin mit dem zweiten Befehl die S3-Buckets auf. Das deutet darauf hin, dass die verwendete IAM-Rolle sowohl über S3-Auflistungs- als auch Lesezugriff verfügte. Das verdeutlicht die Gefahr, die von einer einzelnen IAM-Rolle mit derart umfassenden S3-Berechtigungen ausgeht: Selbst zu diesem Zeitpunkt hätte die Angreiferin wahrscheinlich keine oder nur wenige Daten erfassen können, wenn sie die Ziel-Buckets nicht hätte entdecken können.

Empfehlungen

1. Überwachen Sie fortlaufend Security Groups mit übermäßig großzügigen Berechtigungen sowie alle anderen Zugriffsmechanismen, die den Zugriff von 0.0.0.0/0 erlauben. Die Konfiguration bei der Bereitstellung zu überprüfen ist notwendig, reicht aber bei Weitem nicht aus. Cloud-Infrastruktur wird über APIs erstellt und geändert. Daher weicht ihre Konfiguration im Laufe der Zeit häufig vom ursprünglichen Zustand ab, wenn verschiedene Teams und Personen damit arbeiten.

2. Wenden Sie das Prinzip der geringsten Berechtigungen an und beschränken Sie IAM-Rollen konsequent auf das, was die geschäftliche Funktion der jeweiligen Ressource unbedingt erfordert. Für S3 könnten Sie unterschiedliche öffentliche Endpunkte für Lese- und Schreibvorgänge sowie separate IAM-Rollen verwenden, die jeweils nicht die andere Funktion ausführen können. Vermeiden Sie in Produktionsumgebungen sämtliche Anwendungsfälle, bei denen S3-Buckets aufgelistet werden können, und setzen Sie stattdessen auf gemeinsam genutzte Geheimnisse oder andere Mechanismen.

3. Erlauben Sie EC2-Instances in Produktionsumgebungen keine IAM-Rollen, mit denen Rollenrichtlinien angehängt oder ersetzt werden können.

4. Räumen Sie ungenutzte Cloud-Ressourcen, insbesondere Server und S3-Buckets, konsequent auf, wenn sie aus früheren Entwicklungsarbeiten oder dem Debugging von Produktionsumgebungen übrig geblieben sind.

5. Beziehen Sie Fehlkonfigurationen der Cloud-Infrastruktur in Ihre Penetrationstests ein. Ziehen Sie externe Penetrationstester hinzu und stellen Sie sicher, dass sie wissen, wie sich Fehlkonfigurationen in der Cloud aufspüren und ausnutzen lassen.