Wie die Cloud eines Startups durch ein einfaches Formular zum Versenden von E-Mails übernommen wurde

Verhinderung der vollständigen Übernahme der Cloud durch SSRF-Angriffe

Dies ist die Geschichte eines Angreifers, der sich über ein einfaches E-Mail-Formular Zugang zu den Amazon S3-Buckets, Umgebungsvariablen und verschiedenen internen API-Geheimnissen eines Startups verschafft hat. Obwohl dies eine wahre Geschichte ist, halte ich den Namen des Startups geheim.

Wie sie hereinkamen

Alles beginnt damit, dass eine PHP-Anwendung eine E-Mail verschickt. Um einige der ausgefallenen Bilder als Anhänge in die E-Mail zu laden, muss die Anwendung sie herunterladen. In PHP ist das ganz einfach. Sie verwenden die Funktion file_get_contents und damit beginnt der Spaß.

Natürlich wurden einige der Benutzereingaben für diese E-Mail nicht vollständig überprüft oder HTML-kodiert, so dass ein Benutzer ein Bild einfügen konnte, wie <img src=’evil.com’/>. Theoretisch ist das nicht weiter schlimm, aber leider ist diese PHP-Funktion sehr leistungsfähig und kann viel mehr als nur Bilder über das Internet laden. Sie kann auch lokale Dateien lesen und was noch wichtiger ist: Dateien über das lokale Netzwerk statt über das Internet.

Anstelle von evil.com hat der Angreifer eine spezielle lokale URL eingegeben. Sie können diese URL verwenden, um die IAM-Anmeldeinformationen abzurufen, die mit der Rolle des AWS EC2-Servers verknüpft sind, den Sie mit einer einfachen GET-Anfrage ausführen.

<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 in einem Anhang in der Mailbox enthielt. Diese Schlüssel geben dem Angreifer die Möglichkeit, sich als dieser Server auszugeben, wenn er mit verschiedenen AWS-Diensten kommuniziert. Von da an ging es nur noch bergab...

Warum ist das überhaupt möglich?

Das System, das diese IAM-Schlüssel lädt, heißt IMDSv1 und Amazon hat 2019 eine neue Version namens IMDSv2 veröffentlicht. Mit IMDSv2 müssen Sie eine PUT-Anfrage mit einer speziellen Kopfzeile 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 hoch die Akzeptanz von IMDSv2 im Jahr 2023 ist, aber es ist klar, 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 ihre Inhalte gelesen werden. Erschwerend kommt hinzu, dass einer der S3-Buckets eine Cloudformation-Vorlage enthielt, die sensible Umgebungsvariablen (z. B. Sendgrid-API-Schlüssel) enthielt.

Wie kann ich meine Cloud-Infrastruktur dagegen schützen?

Was könnte man nun tun, um diesen totalen Datenverlust zu verhindern? Ihre Entwickler könnten besonders vorsichtig sein und darauf achten, dass sie für die URLs, die sie an file_get_contents weitergeben, eine allowlist verwenden. Sie könnten sogar überprüfen, ob es sich bei dem empfangenen Inhalt um ein Bild handelt, wenn sie ein Bild erwarten. In der Realität lassen sich solche Fehler als Entwickler jedoch kaum vermeiden.

Es wäre viel besser, Ihre Infrastruktur mit zusätzlichen Schutzmaßnahmen gegen diese Angriffe auszustatten. Unsere neue Integration mit AWS in Aikido Security warnt Sie, wenn Ihre Cloud nicht aktiv eine der folgenden Maßnahmen ergreift. Jede dieser Maßnahmen für sich allein hätte diesen speziellen Angriff gestoppt, aber wir empfehlen, sie alle zu implementieren. Nutzen Sie unser kostenloses Testkonto, um zu sehen, ob Ihre Cloud bereits gegen diese Bedrohungen geschützt ist. Sehen Sie hier, wie Aikdido Ihre App vor Sicherheitslücken schützt.

Zu unternehmende Schritte:

1. Migrieren Sie Ihre bestehenden IMDSv1 EC2-Knoten zur Verwendung von IMDSv2
2. Speichern Sie überhaupt keine Geheimnisse in der Umgebung Ihrer Webserver oder in Cloudformation-Vorlagen. Verwenden Sie ein Tool wie den AWS Secrets Manager, um die Geheimnisse zur Laufzeit zu laden.
3. Wenn Sie Ihren EC2-Servern IAM-Rollen zuweisen, stellen Sie sicher, dass sie zusätzliche Nebenbedingungen haben, wie z. B. die Einschränkung, dass sie nur innerhalb Ihres lokalen AWS-Netzwerks (Ihrer VPC) verwendet werden können. Im folgenden Beispiel kann Ihr Server aus S3 lesen, aber nur, wenn der EC2-Server über einen bestimmten VPC-Endpunkt kommuniziert. Das ist nur innerhalb Ihres Netzwerks möglich, so dass der Angreifer nicht in der Lage gewesen wäre, von seinem lokalen Rechner aus auf die S3-Buckets zuzugreifen.

{
"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 "Die Tötungskette"

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