Wie die Cloud eines Startups durch ein einfaches Formular, das E-Mails versendet, übernommen wurde

Verhinderung der vollständigen Cloud-Übernahme mittels SSRF-Angriffen

Dies ist die Geschichte eines Angreifers, der über ein einfaches Formular, das eine E-Mail sendet, Zugriff auf die Amazon S3 Buckets, Umgebungsvariablen und verschiedene interne API-Secrets eines Startups erhielt. Auch wenn dies eine wahre Geschichte ist, halte ich den Namen des Startups geheim.

Wie sie eindrangen

Alles beginnt damit, dass eine PHP-Anwendung eine E-Mail versendet. Um einige der ansprechenden Bilder als Anhänge in die E-Mail zu laden, muss die Anwendung sie herunterladen. In PHP ist das einfach. Man verwendet die Funktion file_get_contents, und da beginnt der Spaß.

Natürlich wurde ein Teil der Nutzereingaben für diese E-Mail nicht vollständig überprüft oder HTML-kodiert, sodass ein Benutzer ein Bild wie dieses einfügen konnte: <img src=’evil.com’/>Nun, theoretisch ist das nicht allzu schlimm, aber leider ist diese PHP-Funktion sehr mächtig und kann viel mehr als Bilder über das Internet laden. Sie kann auch lokale Dateien und, was noch wichtiger ist, Dateien über das lokale Netzwerk anstelle des Internets lesen.

Anstelle von evil.com gab der Angreifer eine spezielle lokale URL ein. Sie können diese URL verwenden, um mit einer einfachen GET-Anfrage die IAM-Anmeldeinformationen zu erhalten, die mit der Rolle des von Ihnen betriebenen AWS EC2 Servers verknüpft sind.

<img src=’http://169.254.169.254/latest/meta-data/'>

Das Ergebnis war, dass der Angreifer eine E-Mail erhielt, die die IAM-Anmeldeinformationen für den EC2-Server als Anhang im Postfach enthielt. Diese Schlüssel ermöglichen es dem Angreifer, sich als dieser Server auszugeben, wenn er mit verschiedenen AWS-Diensten kommuniziert. Von da an geht es bergab...

Warum ist das überhaupt möglich?

Das System, das diese IAM-Schlüssel lädt, wird IMDSv1 genannt. Amazon hat 2019 eine neue Version namens IMDSv2 veröffentlicht. Mit IMDSv2 müssen Sie eine PUT-Anfrage mit einem speziellen Header senden, um Ihre IAM-Anmeldeinformationen zu erhalten. Das bedeutet, dass eine einfache GET-basierte URL-Ladefunktion wie file_get_contents nicht mehr so viel Schaden anrichten kann.

Es ist unklar, wie die Akzeptanz von IMDSv2 im Jahr 2023 aussieht, aber es ist offensichtlich, dass Amazon immer noch Maßnahmen ergreift, um die Akzeptanz zu erhöhen, und wir sehen, dass IMDSv1 immer noch in freier Wildbahn verwendet wird.

Die Kompromittierung der IAM-Schlüssel führt zu weiteren Kompromittierungen: Die S3-Buckets konnten aufgelistet und deren Inhalte gelesen werden. Erschwerend kam hinzu, dass einer der S3-Buckets eine CloudFormation-Vorlage enthielt, die sensible Umgebungsvariablen (z. B. Sendgrid API-Schlüssel) enthielt.

Wie verteidige ich meine Cloud-Infrastruktur dagegen?

Was könnte getan werden, um diesen totalen Datenverlust zu verhindern? Ihre Entwickelnde könnten besonders vorsichtig sein und darauf achten, eine Allowlist für die URLs zu verwenden, die sie an file_get_contents übergeben. Sie könnten sogar überprüfen, ob der empfangene Inhalt ein Bild ist, wenn sie ein Bild erwarten. Die Realität ist jedoch, dass solche Fehler für Entwickelnde schwer zu vermeiden sind.

Es wäre viel besser, sicherzustellen, dass Ihre Infrastruktur zusätzliche Abwehrmaßnahmen gegen diese Angriffe besitzt. Unsere neue Integration mit AWS innerhalb von Aikido Security wird Sie benachrichtigen, wenn Ihre Cloud keine der folgenden Maßnahmen aktiv ergreift. Jede dieser Maßnahmen hätte diesen speziellen Angriff für sich genommen gestoppt, aber wir empfehlen, alle zu implementieren. Nutzen Sie unser kostenloses Testkonto, um zu sehen, ob Ihre Cloud bereits gegen diese Bedrohungen verteidigt ist. Sehen Sie hier, wie Aikido Ihre App vor Schwachstellen schützt.

Maßnahmen:

1. Migrieren Sie Ihre bestehenden IMDSv1 EC2 Nodes zur Verwendung von IMDSv2
2. Speichern Sie überhaupt keine Secrets in der Umgebung Ihrer Webserver oder in CloudFormation-Templates. Verwenden Sie ein Tool wie AWS Secrets Manager, um die Secrets zur Laufzeit zu laden.
3. Stellen Sie beim Zuweisen von IAM-Rollen zu Ihren EC2-Servern sicher, dass diese zusätzliche Nebenbedingungen aufweisen, wie z. B. die Beschränkung, dass sie nur innerhalb Ihres lokalen AWS-Netzwerks (Ihrer VPC) nutzbar sind. Das folgende Beispiel erlaubt Ihrem Server, von S3 zu lesen, aber nur, wenn der EC2-Server über einen bestimmten VPC-Endpunkt kommuniziert. Dies ist nur innerhalb Ihres Netzwerks möglich, sodass der Angreifer von seinem lokalen Rechner aus nicht auf die S3-Buckets hätte zugreifen können.

{
"Version": "2012-10-17",
"Statement": [
       {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
               }
           }
       }
   ]
}

Über „The Kill Chain“

The Kill Chain ist eine Reihe von realen Geschichten, in denen Angreifer durch die Verkettung mehrerer Schwachstellen zu den Kronjuwelen von Softwareunternehmen gelangten. Geschrieben von Willem Delbare, der seine zehnjährige Erfahrung im Aufbau und der Unterstützung von SaaS-Startups als CTO einbringt. Die Geschichten stammen direkt aus Willems Netzwerk und sind alle wirklich passiert.