Cloud Storage - Konfigurationsschwachstellen

Cloud Storage

Konfigurationsschwachstellen

Andrea Hauser
von Andrea Hauser
am 17. Mai 2018
Lesezeit: 13 Minuten

Keypoints

  • Cloud Storage Services bieten das Speichern von Daten an einem Remote-Standort an
  • Die Vergabe von Berechtigungen für solche Cloud Storage Services wird teilweise immer noch falsch gemacht, obwohl es sich dabei nicht um ein neues Thema handelt
  • Sowohl Google Cloud Storage Buckest als auch Amazon S3 Buckets haben einen eindeutigen Identifizierer, mit dem man einen Bucket auffinden kann
  • Amazon S3 Buckets und Google Cloud Storage Buckets kennen beide das Konzept von Freigaben für "alle Benutzer" oder "alle authentifizierten Benutzer", dabei handelt es sich um gefährliche Konzepte

Bei Cloud Storage Services werden die Daten an einem Remote-Standort abgelegt und verwaltet. Die Daten stehen den Benutzern über ein Netzwerk, zum Beispiel das Internet, zur Verfügung. Es handelt sich bei Cloud Storage Konfigurationsschwachstellen nicht um ein neuartiges Problem. Schon im Jahr 2011 wurden Berichte und Auswertungen dazu veröffentlicht. Allerdings sind Databreaches im Zusammenhang mit Cloud Storage Providern momentan wieder vermehrt in den Medien aufzufinden. Bei der Auswertung solcher Medienberichte wird klar, dass sowohl private Firmen als auch Regierungen Probleme mit der richtigen Konfiguration von Cloud Storage Services haben.

Die meisten Artikel, welche sich mit diesem Thema befassen, beinhalten bekannt gewordene Datenlecks bei Amazon S3 Buckets. Doch es sind auch Meldungen zu Google Cloud Storage auffindbar. Der Artikel konzentriert sich auf die Auswertung von Amazon S3 Buckets sowie Google Cloud Storage. Dabei wird zuerst aufgezeigt wie ein solcher Cloud Storage Datenkontainer (Bucket genannt) gefunden werden kann. In einem weiteren Schritt wird auf verschiedene Möglichkeiten von Fehlkonfigurationen eingegangen und wie diese ausgenutzt werden können. Zum Schluss soll aufgezeigt werden, wie die Konfiguration überprüft und auf einen sicheren Stand gebracht werden kann.

Amazon S3 Buckets

Techniken zum Auffinden eines Amazon S3 Buckets

Jeder Amazon S3 Bucket hat einen einzigartigen Namen. Wie dieser herausgefunden werden kann, wird zu einem späteren Zeitpunkt erklärt. Wenn dieser Name bekannt ist, kann in einem ersten Schritt wie folgt versucht werden auf den Bucket zuzugreifen:

http://<bucketname>.s3.amazonaws.com

Falls der Name existiert und die Berechtigungen so gesetzt sind, dass alle den Inhalt lesen können, erhält man eine Antwort, die in etwa wie folgt aussieht:

Erfolgreicher Zugriff auf den Bucket http://flaws.cloud.s3.amazonaws.com

Im Falle eines vorhandenen Buckets mit unzureichender Berechtigung erscheint folgende Fehlermeldung:

Bucket vorhanden, aber Zugriff nicht erlaubt

Schlussendlich existiert die Möglichkeit, dass ein Bucket unter dem angegebenen Namen nicht existiert. Dies wird mit folgender Fehlermeldung angezeigt:

Kein Bucket mit dem angegebenen Namen existiert

Um Buckets eines Unternehmens zu finden, kann mit personalisierten Wortlisten die URL mit der Struktur <wort>.s3.amazonaws.com aufgerufen werden. Eine weitere Möglichkeit besteht darin, existierende Subdomains zu suchen und diese als Ausgangslage für allfällige S3 Bucket Namen zu nutzen. Die Certificate Transparency Logs können die Suche nach Subdomains stark vereinfachen.

Mögliche Fehlkonfigurationen eines Amazon S3 Buckets

In der Standartkonfiguration ist ein Amazon S3 Bucket nicht öffentlich zugänglich und der Zugriff muss explizit gewährt werden. Es werden folgende Berechtigungen unterschieden:

Berechtigung Beschreibung
READ Jemand mit READ Berechtigung kann alle Objekte im Bucket auflisten.
WRITE Mit der WRITE Berechtigung können Objekte im Bucket erstellt, überschrieben oder gelöscht werden.
READ_ACP Mit dieser Berechtigung können die Bucket-Zugriffskontrolllisten gelesen werden.
WRITE_ACP WRITE_ACP erlaubt die Zugriffskontrollliste eines Buckets zu schreiben.
FULL_CONTROL Damit werden die Berechtigungen READ, WRITE, READ_ACP und WRITE_ACP vergeben.

Die oben beschriebenen Berechtigungen können an spezifische Amazon Web Services-Konten (AWS-Konten) oder vordefinierte Amazon S3-Gruppen vergeben werden. Bei den wichtigsten Amazon S3 Gruppen handelt es sich um Authentifizierte Benutzer und um Alle Benutzer.

Die Gruppe Alle Benutzer schränkt die Benutzer nicht ein. Zum Beispiel erlaubt man mit der Gewährung von Lese- und Schreibzugriff (READ + WRITE) für diese Gruppe der ganzen Welt, die Inhalte dieses Buckets herunterzuladen und Inhalte hochzuladen.

Die Gruppe Authentifizierte Benutzer beinhaltet sämtliche Benutzer, die ein AWS-Konto besitzen. Ein solches Konto kann mit der Option Free Tier kostenfrei erstellt werden. Dementsprechend handelt es sich bei der Einschränkung der Berechtigungen auf diese Gruppe nur um eine kleine Hürde. Das Auflisten der Inhalte eines Buckets über den Browser ist ohne Konto zwar nicht mehr möglich, aber mit der Nutzung des AWS CLI kann ohne weiteres auf einen solchen Bucket zugegriffen werden. Der CLI-Befehl für die Abfrage eines Buckets sieht wie folgt aus:

aws s3 ls s3://<bucketname>

Für jeden, der das Auffinden von S3 Buckets selber ausprobieren möchte, empfehle ich die Webseite flaws.cloud. Dort werden die oben aufgeführten Fälle und weitergehende Beispiele auf eine spielerische Art aufgezeigt.

Konfiguration überprüfen

Amazon bietet seit Ende Februar 2018 das Tool Trusted Advisor zur Überprüfung von Berechtigungen und Konfigurationen allen Kunden kostenfrei an. Es wird empfohlen die bestehenden Buckets damit zu überprüfen. Wenn möglich sollten an die Gruppen Alle Benutzer und Authentifizierte Benutzer keine Berechtigungen vergeben werden. Es wird empfohlen, die Rechte so weit wie möglich einzuschränken und eine allfällige Delegierung von Berechtigungen nur an spezifische AWS-Konten vorzunehmen.

Google Cloud Storage

Techniken zum Auffinden eines Google Cloud Storage Bucket

Ähnlich wie bei Amazon S3 Buckets besteht auch bei Google Cloud Storage eine einzigartige URL pro Storage Container. Diese lautet http://storage.googleapis.com/<bucketname>/.

Bei einem Zugriff auf einen Bucket, bei dem alle den Inhalt lesen können, erhält man folgende Antwort:

Erfolgreicher Zugriff auf den Bucket http://storage.googleapis.com/gcp-public-data-landsat/

Beim Zugriff mit einem gültigen Bucket Namen aber unzureichenden Berechtigungen wird folgender Fehler ausgegeben:

Bucket ist vorhanden, allerdings bestehen keine Auflistungsberechtigungen

Es gibt allerdings noch eine zweite Art, wie auf die Google Cloud Buckets zugegriffen werden kann. Dabei wird die URL https://console.cloud.google.com/storage/<bucketname>/ genutzt. Um auf eine solche URL zugreifen zu können, muss man jedoch mit einem Google-Konto angemeldet sein. Da ein solches Konto ohne weiteres kostenfrei erstellt werden kann, ist dies jedoch kein Hindernis.

Im Falle eines existierenden Buckets mit öffentlichen Daten wird eine Ansicht ähnlich der folgenden angezeigt:

Erfolgreicher Zugriff auf https://console.cloud.google.com/storage/gcp-public-data-landsat

Im Falle eines nicht vorhandenen Buckets oder eines Buckets, bei dem der Zugriff nicht erlaubt ist, wird in der Ansicht von console.cloud.google.com folgende Fehlermeldung ausgegeben:

Sie brauchen die Berechtigung storage.objects.list, um Objekte in diesem Bucket aufzulisten. Bitten Sie einen Projekt- oder Bucket-Inhaber, Ihnen diese Berechtigungen zu erteilen, und versuchen Sie es dann noch einmal.

Mögliche Fehlkonfigurationen eines Google Cloud Storage Buckets

Wie bei Amazon ist bei Google Cloud Storage Buckets der Zugriff nicht öffentlich und muss zuerst vergeben werden. Rollen können für spezifische Google-Konten, für allAuthenticatedUsers oder für allUsers vergeben werden. Bei allAuthenticatedUser handelt es sich um sämtliche Benutzer, die sich mit einem Google-Konto authentifizieren können. AllUsers umfasst sämtliche Benutzer, egal ob authentifiziert oder nicht.

Bei Google Cloud Storage können die Berechtigungen für Buckets sowohl über die Identitäts- und Zugriffsverwaltung als auch über Zugriffssteuerungslisten vergeben werden. Wenn die Rollen jedoch über Zugriffssteuerungslisten vergeben werden, wird auch eine entsprechende Rolle in der Identitäts- und Zugriffsverwaltung erstellt. Im folgenden Abschnitt werden dementsprechend nur die Identitäts- und Zugriffsverwaltungsrollen beschrieben. Inhalte, welche sich in einem Bucket befinden, werden als Objekte bezeichnet.

Rollen Beschreibung
storage.objectCreator Damit können neue Objekte erstellt werden. Es ist allerdings nicht möglich bestehende Objekte anzusehen, zu bearbeiten oder zu löschen.
storage.objectViewer Storage.objectViewer erlaubt es Inhalte anzusehen und Inhalte in einem Bucket aufzulisten.
storage.objectAdmin Damit besteht vollständige Kontrolle über Objekte. Allerdings können Bucket-Metadaten nicht gelesen oder bearbeitet werden.
storage.admin Es besteht vollständige Kontrolle über den Bucket und alle vorhandenen Objekte.
Viewer Ein Benutzer mit dieser Berechtigung kann Buckets auflisten.
Editor Mit dieser Berechtigung kann ein Bucket erstellt, bearbeitet oder gelöscht werden.
Owner Mit dieser Berechtigung kann ein Bucket erstellt, bearbeitet oder gelöscht werden.
legacyBucketReader Damit können die Inhalte eines Buckets aufgelistet werden und Metadaten zum Bucket angezeigt werden.
legacyBucketWriter Zusätzlich zum Lesen der Inhalte eines Buckets können die Inhalte auch erstellt, überschrieben oder gelöscht werden.
legacyBucketOwner In dieser Rolle sind sämtliche Rechte von legacyBucketWriter beinhaltet. Dazu kommt noch die Berechtigung Identitäts- und Zugriffsverwaltungsrichtlinien zu erstellen und zu bearbeiten.

Sobald eine dieser Rollen an allAuthenticatedUser oder allUser vergeben wird, kann es sich dabei um eine mögliche Fehlkonfiguration handeln. Bei der Vergabe von Berechtigungen sollte man sich bewusst sein, was dies für Auswirkungen hat und wer danach auf die Daten zugreifen oder sie allenfalls sogar ändern kann.

Fazit

Die Vergabe von Berechtigungen sollte bewusst vorgenommen werden. Grundsätzlich sollte die Freigabe von Lese- und Schreibrechten auf Buckets möglichst restriktiv vorgenommen werden. Es empfiehlt sich bereits bestehende Buckets von Online Cloud Storage Diensten nochmals auf ihre Berechtigungen zu überprüfen, damit nicht ausversehen Zugriffe und Änderungen möglich sind, die nicht angedacht waren. Wo vorhanden sollten bestehende Ressourcen genutzt werden, um die Überprüfung von Berechtigungen zu vereinfachen.

Über die Autorin

Andrea Hauser

Andrea Hauser hat ihren Bachelor of Science FHO in Informatik an der Hochschule für Technik Rapperswil abgeschlossen. Sie setzt sich im offensiven Bereich in erster Linie mit Web Application Security Testing und der Umsetzung von Social Engineering Kampagnen auseinander. Zudem ist sie in der Forschung zum Thema Deepfakes tätig. (ORCID 0000-0002-5161-8658)

Links

Sie brauchen hilfe beim Absichern Ihrer Cloud?

Unsere Spezialisten kontaktieren Sie gern!

×
GraphQL

GraphQL

Andrea Hauser

Server-Side-Request-Forgery

Server-Side-Request-Forgery

Andrea Hauser

Policy Analyzer

Policy Analyzer

Andrea Hauser

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen hilfe beim Absichern Ihrer Cloud?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv