Blinder Alarm: Kontext als Schlüssel zur sicheren Cloud

Security bedarf im Zeitalter der Cloud besonderer Sorgfalt – muss aber mit der Entwicklungsgeschwindigkeit schritthalten. Was sind die richtigen Prioritäten?

Lesezeit: 17 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen

(Bild: wk1003mike/Shutterstock.com)

Von
  • Johannes Späth
  • Andreas Dann
  • Manuel Benz
Inhaltsverzeichnis

Mit Cloud-Technologien wie Serverless, Kubernetes oder Terraform ist das Versprechen verbunden, skalierbare Applikationen einfach und mit minimalem Aufwand zu implementieren. Statt eigenständige Anwendungen einzeln einzubinden, nutzt eine Cloud-native-Anwendung vorgefertigte Services der Cloud-Provider, die sie zu einem Ganzen kombiniert.

Young Professionals schreiben für Young Professionals

Dieser Beitrag ist Teil einer Artikelserie, zu der heise Developer junge Entwickler:innen einlädt – um über aktuelle Trends, Entwicklungen und persönliche Erfahrungen zu informieren. Die Reihe "Young Professionals" erscheint im monatlichen Rhythmus. Bist du selbst ein "Young Professional" und willst einen (ersten) Artikel schreiben? Schicke deinen Vorschlag an die Redaktion: developer@heise.de. Wir stehen dir beim Schreiben zur Seite.

Alle typischen Anwendungsfälle von User Management verwalteten NoSQL- und SQL-Datenbanken bis hin zu Engines für Machine Learning gibt es in Form von Microservices in der Cloud. Weitere spezifische Business-Logik einer Anwendung lässt sich in selbst entwickelten und gewarteten Komponenten umsetzen und zumeist über virtuelle Maschinen (VMs), Docker-Container oder Serverless Functions an die Cloud-native Infrastruktur anbinden.

Die gesamte Anwendung läuft auf Ressourcen des Cloud-Providers. Ein Vorteil ist dabei, dass Unternehmen sich den Betrieb im eigenen Rechenzentrum (on Premises) sparen und mühsame Wartungsarbeiten einer eigenen IT-Infrastruktur entfallen. Sie können sich auf die Umsetzung der Geschäftslogik ihrer Applikation konzentrieren, lautet ein Werbeargument der Anbieter von Clouddiensten.

Dass Cloud-Applikationen sicherer seien, da sich der Provider um die Security kümmert, ist jedoch ein Fehlschluss: Sicherheit in der Cloud bleibt eine geteilte Verantwortung zwischen dem Provider und den Anwendern. Die Provider nutzen das Shared-Responsibility-Modell. Demzufolge sind sie unter anderem verantwortlich für die physische Sicherheit der Hardware oder die Aktualität der Treiber, für das Betriebssystem, die Laufzeitumgebungen oder auch die physische Absicherung des Netzwerks. Cloud-Anwender stehen jedoch ihren Kunden gegenüber weiterhin für die Anwendungssicherheit und für die korrekte Konfiguration der Cloud-Umgebung gerade.

Auf Anwendungsebene liegen insbesondere Sicherheitslücken im selbst entwickelten Code, in eingebundenen Bibliotheken oder in Docker-Images in der Verantwortung von Cloud-Anwendern. Die richtige Konfiguration der Cloud-Accounts und dort enthaltenen verwalteten Ressourcen, die VPN-Konfiguration, die Nutzerverwaltung und die Zugriffsrechte liegen ebenfalls in seiner Verantwortung. Abhängig von den Cloud-Techniken variiert die Sicherheits-Verantwortung der Anwender zwischen 8 und 52 Prozent in Bezug auf die Gesamtverantwortung, schätzt Ory Segal von Palo Alto Networks (8 Prozent bei einer Applikation, die hauptsächlich auf VMs setzt, 52 Prozent bei modernen, vollständigen Serverless-Implementierungen).

Dass Cloud-Anwendungen nicht per se sicher sind, haben mehrere Angriffe in der Vergangenheit gezeigt. Ein Beispiel ist der Capital-One-Hack aus dem Jahr 2019, über den ausführliche Informationen vorliegen. Angreifern gelang es, in den Besitz der Identitäts-, Bonitäts- und Kreditkartendaten sowie Sozialversicherungsnummern von insgesamt über 100 Millionen Kunden der US-amerikanischen Bank zu kommen. Dem Unternehmen wurden im Anschluss fehlende Sicherheitsmaßnahmen vorgeworfen und der Hack kostete die Bank 80 Millionen Dollar an Schadensersatz, wie die New York Times berichteten. Ursache war eine Verkettung zweier Sicherheitslücken: eine Fehlkonfiguration in der Web-Application-Firewall (WAF) und eine überprivilegierte virtuelle Maschine in der Cloud, eine sogenannte Elastic-Cloud-Computing-Instanz (EC2).

Der Capital One wurde zum Verhängnis, dass eine Web-Application-Firewall, die eigentlich für zusätzliche Sicherheit sorgt, überprivilegierte Rechte hatte (Abb. 1).

(Bild: nach Neto/Madnick/de Paula/Borges, A Case Study of the Capital One Data Breach, MIT Management Sloan School 2020, S. 8 (Abb. 2).)

Der Angriff verlief in mehreren Schritten (s. Abb. 1). Die folgende Kurzbeschreibung basiert auf einem Bericht des Massachusetts Institute of Technology ("A Case Study of the Capital One Data Breach", MIT Management Sloan School 2020):

  1. Das FBI und Capital One entdeckten mehrere Zugriffe auf die AWS-Cloud der Bank. Die IP-Adressen stammten aus dem Tor-Netzwerk und waren mit einem VPN-Service (IPredator) weiter verschleiert.
  2. Den Angreifern gelang es, mit einem Server-Side-Request-Forgery-Angriff (SSRF) eine Rechteerhöhung (Privilege Escalation) zu provozieren. Damit ließen sich Daten von beliebigen URLs innerhalb der AWS-Cloud mit den Rechten des Servers abgreifen und an die externen Angreifer zurücksenden. Ermöglicht hat das eine fehlkonfigurierte Web-Application-Firewall (WAF), die die Anfrage nicht auf unzulässige URLs für den Download interner Dateien überprüfte.
  3. Die Angreifer lenkten die Serverfunktion zum Datei-Download auf einen Metadaten-Service von AWS um (erreichbar über den Permalink mit der URL http://169.254.169.254). Dieser Dienst liefert temporäre Sicherheitsschlüssel, die sich von der Instanz nutzen lassen.
  4. Durch die Kombination des SSRF-Angriffs auf die fehlkonfigurierte WAF und eine überpriviligierte EC2-Instanz gelang es den Angreifern, über die URL http://169.254.169.254/iam/security-credentials die Schlüssel der EC2-Instanz (AccessKeyId und SecretAccessKey) herunterzuladen und damit vollen Zugriff auf die AWS-Umgebung zu erlangen.
  5. Mithilfe der Zugangsschlüssel war es den Angreifern nun per AWS-Kommandozeile möglich, eine komplette Liste aller S3-Buckets zu erhalten und knapp 30 GByte an vertraulichen Kreditantragsdaten von mehr als 700 Buckets abzugreifen.

Der Capital-One-Hack entspricht dem typischen Muster von Cyber-Angriffen. Häufig nutzen die Angreifer mehrere Schwachstellen gleichzeitig aus, um sich Zugang zu einem System zu verschaffen.

Mehr zum Thema im Sonderheft "Sichere Software entwickeln"

Wenn beispielsweise eine Elastic-Cloud-Computing-Instanz (EC2) Zugriff auf unzählige S3-Buckets und die darin enthaltenen Daten hat, wurde das "Principle of Least Privilege" nicht optimal umgesetzt. Komponenten sollten immer nur Zugriff auf die minimal notwendigen Daten haben. Eine strengere Zugriffskontrolle hätte den Schaden, den der Angriff anrichtete, deutlich reduzieren können. Um solche Schwachstellen im Cloud-Umfeld zu verhindern, gibt es Best Practices und Cloud-Security-Tools, die die Richtlinien frühzeitig und kontinuierlich überprüfen.

Im Beispiel des Capital-One-Hacks hätte ein Werkzeug für das Cloud Security Posture Management (kurz CSPM) in Kombination mit einem Tool zum Static Application Security Testing (kurz SAST) die beiden Schwachstellen frühzeitig aufgedeckt und den Angriff verhindern können.

Ein CSPM-Werkzeug findet Fehlkonfigurationen innerhalb des Accounts. Es überprüft alle Cloud-Ressourcen auf ihre Konformität mit gängigen Regelkatalogen wie dem Payment Card Industry Data Security Standard (PCI DSS), der Service Organization Control 2 (SOC2) oder den Benchmarks des Center of Internet Security, kurz CIS. Zu den gängigen Regeln in den Benchmarks gehören typische Fehler, unter anderem offene Wartungsports mit SSH, fehlende Datenverschlüsselung ("in transit" und "at rest") oder öffentlich verfügbare Ressourcen wie S3-Buckets und Datenbanken.

Tatsächlich zählen unabsichtlich öffentliche S3-Buckets zu den am häufigsten ausgenutzten Sicherheitslücken. Weitere Regeln, die das CSPM überprüft, sind typische Schwachstellen in Netzwerken oder Firewalls, die aus unsicheren Default-Einstellungen resultieren. Sie sind meist für den jeweils aktuellen Anwendungsfall unzulänglich konfiguriert und bieten nicht die nötige Sicherheit. Weiterhin gehören auch schwache Passwortrichtlinien, die nicht aktivierte Zwei-Faktor-Authentifizierung oder unzureichendes Event-Logging zu den Fehlern, die CSPM-Werkzeuge erkennen.

Im Fall des Capital-One-Hacks waren die Privilegien des Servers und damit der WAF unzureichend beschränkt und ermöglichten es den Angreifern, den EC2-Metadaten-Service von AWS zu erreichen. Das auf IT spezialisierte Marktforschungsunternehmen Gartner prognostiziert, dass solche Fehlkonfigurationen von Ressourcen eine der größten Quellen für Sicherheitslücken in der Cloud werden: Bis 2025 werden wohl 99 Prozent der erfolgreichen Cloud-Angriffe darauf und allgemein auf menschliches Versagen zurückzuführen sein.

Auch moderne Cloud-Anwendungen müssen nach wie vor die eigene Businesslogik auf der Anwendungsebene modellieren und enthalten auch vom Hersteller entwickelte Software – meist in einem Docker-Container oder in Form einer Serverless-Funktion. Diese Komponenten gilt es auf Sicherheitslücken zu überprüfen. Hierfür kommen klassischerweise statische Codeprüfungen wie eine Datenflussanalyse infrage. Sie überprüft den Anwendungscode als Source- oder Bytecode, testet alle potenziellen Pfade der Anwendung und stellt fest, ob extern modifizierbarer Input eine kritische Operation auslösen kann. Eine solche Analyse kann beispielsweise eine SSRF-Schwachstelle erkennen, wie sie im Capital-One-Hack ausgenutzt wurde.