Blinder Alarm: Kontext als Schlüssel zur sicheren Cloud
(Bild: wk1003mike/Shutterstock.com)
Security bedarf im Zeitalter der Cloud besonderer Sorgfalt – muss aber mit der Entwicklungsgeschwindigkeit schritthalten. Was sind die richtigen Prioritäten?
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.
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.
Trügerisches Sicherheitsgefühl
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 [8], 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).
Capital One: größter Hack in der Geschichte der US-Finanzbranche
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 [9]. 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).
(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 [10]", MIT Management Sloan School 2020):
- 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.
- 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.
- 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.
- 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.
- Mithilfe der Zugangsschlüssel war es den Angreifern nun per AWS-Kommandozeile möglich, eine komplette Liste aller S3-Buckets zu erhalten [11] 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.
Best Practices in der Cloud-Security: Principle of Least Privilege
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 [12]. 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.
Öffentliche S3-Buckets sind ein Sicherheitsproblem
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 [13]: 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.
Weitere Best Practices: CIEM und SCA
Es gibt noch mehr Maßnahmen, unbefugten Zugriff auf die Cloud-Anwendungen und -Accounts abzuwenden. Hierzu zählen das Cloud Infrastructure Entitlements Management (CIEM) und die Software Composition Analysis (SCA).
Das Zugriffsmanagement ist ein wesentliches Security-Thema und dient dazu, den Zugriff auf Services und Ressourcen zu verwalten. Neben den einzelnen Cloud-Ressourcen wie virtuellen Maschinen (VM), Containern, Serverless-Funktionen, Datenbanken und S3-Buckets, die untereinander kommunizieren, gilt es, Nutzerkonten in der Cloud zu verwalten. Die Zugriffsberechtigungen für einzelne Accounts auf die Ressourcen sind im Sinne des Principle of Least Privilege minimal zu halten. Anderenfalls können Angreifer durch das unbefugte Annehmen einer höher privilegierten Rolle (Privilege Escalation) den Zugriff auf interne Daten erhalten oder tiefer in das System eindringen. Gefährdet sind dabei sensible Unternehmensdaten wie Datenbankinhalte, Kostenabrechnungen der Cloud-Accounts und vieles mehr. Wichtig ist, das Risiko von Insidern im Blick zu behalten, die aus dem Inneren des Unternehmens heraus ihre Rechte missbrauchen (zum Beispiel ehemalige Mitarbeiter).
CIEM-Werkzeuge geben einen Überblick über die Zugriffsberechtigungen innerhalb des Accounts und stellen grafisch dar, wer auf welche Ressourcen und Informationen in der Cloud zugreifen kann. Aus Organisationssicht lassen sich damit die Rechte der einzelnen Nutzer und Ressourcen korrekt verwalten und einschränken.
Qualitäts- und Sicherheitschecks auf der Anwendungsseite
Neben dem oben erwähnten Static Application Security Testing (SAST) gibt es auf der Anwendungsebene einer Cloud-Applikation weitere Qualitäts- und Sicherheitschecks. Hierzu zählt die Software Composition Analysis (SCA), die in einem gut strukturierten Software Development Lifecycle (SDLC) nicht fehlen sollte. Sie untersucht, welche Drittanbieterbibliotheken in einer Applikation enthalten sind. Das ist notwendig, um existierende Sicherheitslücken in den Fremdbibliotheken, besser bekannt als CVEs (Common Vulnerabilities and Exposures), oder auch Lizenzverletzungen zu erkennen. Die Software Composition Analysis ist in den letzten Jahren ein unumgängliches Werkzeug zum Durchsetzen der Anwendungssicherheit geworden. Das liegt vor allem daran, dass Software heutzutage ausgiebig Gebrauch bestehender Features macht, statt das Rad jedes Mal neu zu erfinden. Eine wissenschaftliche Untersuchung der Queen’s University Belfast zum Aufspüren von Schwachstellen in Open-Source-Software stellte bereits 2017 bis zu 80 Prozent Fremdcodeanteile in quelloffenen Anwendungen fest [14].
Eine solche Analyse der Softwarezusammensetzung untersucht zudem die Applikationsumgebung. Beispielsweise geht es darum, welche Applikationen und Shared Libraries in einer virtuellen Maschine oder einem Docker-Container installiert sind und ob sie bekannte Sicherheitslücken enthalten. Aktuelle Analysen umfassen auch Dockerfiles und bemerken, wenn sich Container mit Root-Rechten ausführen lassen oder wenn bestimmte bei Angreifern beliebte Ports wie der SSH-Port 22 offen sind.
Einige Scanner untersuchen auch die Docker- und VM-Images auf unsichere Konfigurationsdateien, obwohl das nicht zur Kernaufgabe der Software-Composition-Analyse gehört. So lässt sich unter anderem eine unsichere SSH-Konfiguration oder gelegentlich sogar eine SSH-Schlüsseldatei in den Images finden. Fehlkonfigurationen wie die der Apache-Web-Application-Firewall (WAF) beim Capital-One-Hack lassen sich hier unter Umständen von einigen Tools finden, sofern sie die zugehörigen Konfigurationsfiles interpretieren können.
Unzählige Werkzeuge, Unmengen an Warnungen – und fehlender Kontext
Zur Absicherung einer Cloud-Umgebung sind die genannten Werkzeuge (CIEM, CSPM, SAST und SCA) unerlässlich. Fehler in der Cloud-Konfiguration können leicht Türen für Angreifer öffnen, die sich anschließend über drastischere Sicherheitslücken in der Anwendung weiter ausnutzen lassen.
In einer idealen Welt schließen Sicherheitsteams alle gefunden Schwachstellen in vollem Umfang – die Praxis sieht jedoch anders aus. Der Sicherheitsbereich ist den DevOps-Teams hinsichtlich Personal und verfügbare Ressourcen meist deutlich unterbesetzt – auf Dutzende DevOps-Mitarbeiter kommt meistens nur eine Security-Fachkraft, ein klares Missverhältnis. Die Ressourcen der Security-Abteilung sind außerdem beschränkt und stehen einer kontinuierlichen Weiterentwicklung der Cloud-Umgebungen gegenüber, die sich häufig mehrmals in der Woche oder gar täglich aktualisieren. Um dem gewachsen zu sein, müssten die verwendeten Sicherheitswerkzeuge ebenfalls kontinuierlich zum Einsatz kommen.
Allerdings müssen die Security-Teams ihre Ressourcen auf die kritischsten Probleme konzentrieren, um mit der großen Anzahl an Warnungen der verschiedenen Werkzeuge mithalten zu können [15] (hier sammeln sich leicht Tausende von Meldungen an). Häufig wird dabei die Gewichtung (Severity), die die Tools den Warnungen zuordnen, oder die Severity-Definition der Benchmarks übernommen. Die Security-Teams beheben dann nur solche Probleme, die aus Sicht der Werkzeuge am kritischsten sind.
Warnungen um Warnungen: den Wald vor lauter Bäumen nicht sehen
Das Problem dabei ist, dass die Werkzeuge die Cloud-Konstellation der Komponenten vernachlässigen, in denen Sicherheitslücken auftreten, und den eigentlichen Anwendungskontext nicht betrachten. Die Ergebnisse beziehen sich nur auf isolierte Komponenten. Das kann dazu führen, dass Sicherheitsteams ihre begrenzte Zeit mit dem Bearbeiten automatisch erzeugter Warnungen verbringen, die im Kontext der Cloud eigentlich unproblematisch sind, weil beispielsweise die betroffene Komponente von außen gar nicht erreichbar ist oder keinen Zugriff auf schützenswerte Daten hat. Die wirklich kritischen Warnungen gehen im ständigen Rauschen der Alarme unter und die Cloud-Anwendung bleibt angreifbar.
Security-Experten müssen also entscheiden, welche Schwachstelle zuerst anzugehen ist. Sind Anmeldedaten im Klartext in Umgebungsvariablen einer Komponente kritischer als ein offener SSH-Port 22 bei einer virtuellen Maschine? Zum einen benötigt diese Entscheidung Rücksprache mit dem Entwicklungsteam, zum anderen ist sie nicht immer eindeutig. Nimmt man hier die CIS-Benchmark als Grundlage einer Priorisierung, ist der offene Port das kritischere Problem – Klartext-Anmeldedaten hingegen fließen nicht einmal in den CIS-Score mit ein.
Severity als Gradmesser führt zu Fehleinschätzungen
Ausschließlich anhand der vorgeschlagenen Severity der Schwachstelle zu urteilen, würde hier leicht zu einer Fehleinschätzung führen. Bei der betroffenen virtuellen Maschine kann es sich beispielsweise um einen nicht genutzten Testserver handeln, der von außen nicht erreichbar ist und keinen Zugriff auf schützenswerte Daten hat. Somit wäre die Priorität dieser Schwachstelle im Vergleich zu den Klartext-Anmeldedaten niedrig.
Um eine verlässliche Bewertung des Risikos der Warnungen zu erhalten, sind die Warnungen unbedingt im Cloud-Kontext zu betrachten: Ist die betroffene Komponente von außen erreichbar und hat sie Zugriff auf sensible Daten? Diese Bewertung ist nach wie vor manuell durchzuführen.
Sicherheitsteams sollten entsprechend vorsichtig sein bei der Ressourcenplanung und Warnungen im Kontext der Applikation interpretieren, statt einzig auf Severity-Scores oder Guidelines wie den CIS-Benchmark zu vertrauen. Sie müssen sich ein Bild der gesamten Anwendungsstruktur machen und überprüfen, welche Sicherheitslücken akut von außen erreichbar sind und welche Lücken Zugriff auf sensible oder kritische Daten ermöglichen.
Schweregrad im Gesamtbild der Warnungen
Wie der Capital-One-Hack zeigt, beruhen Angriffe in der Cloud fast immer auf dem Zusammentreffen mehrerer Sicherheitslücken in verschiedenen Komponenten. Um diese nach ihrem tatsächlichen Schweregrad zu gewichten, ist es von Bedeutung, welche anderen Schwachstellen im Kontext der Komponente erreichbar und somit gemeinsam ausnutzbar sind.
Für die meisten CSPM- und CIEM-Werkzeuge ist es jedoch unmöglich zu beurteilen, ob eine inkorrekte Cloud-Konfiguration erst im Zusammenhang mit einer weiteren Sicherheitslücke kritisch sein kann. Die unverschlüsselte Datenablage in einem privaten Bereich ist folgenlos, sofern nicht zusätzlich eine Schwachstelle existiert, die den vermeintlich privaten Bereich kompromittiert.
Einzelne Fehlkonfigurationen oder falsche Berechtigungen können für sich genommen zunächst harmlos sein. Erst ihre Kombination ergibt ein mögliches Angriffsszenario. Hier ist es nötig, sich eine Verkettung von Rechten, Datenflüssen und den eigentlichen Auswirkungen im Falle eines Angriffs anzusehen. Daher ist es notwendig, die Warnungen aller genannten Werkzeuge (CSPM, CIEM, SCA und SAST) insgesamt zu betrachten.
Cloud-Sicherheit durch automatisiertes Kontextualisieren
Moderne Cloud-Technologien bieten viele Vorteile, sie beschleunigen den Entwicklungsprozess und reduzieren dabei die Kosten für das Betreiben der Software. Durch die schnellere Entwicklung haben sich allerdings auch die Anforderungen an die Sicherheit stark geändert. Um aktuellen Best Practices zu folgen, gibt es unterschiedliche Werkzeuge wie CSPM, CIEM, SAST und SCA, die kontinuierlich während des Softwareentwickelns die Sicherheit bewerten.
Für eine präzise und effektive Priorisierung der Warnungen ist es notwendig, den Kontext der Warnungen in der Cloud zu betrachten und Warnhinweise zueinander in Bezug zu setzen. Für Security-Fachkräfte ergibt sich dadurch ein unabdingbarer Mehraufwand für eine sichere Softwareentwicklung. Moderne Cloud-Security-Werkzeuge bieten erste Maßnahmen, diesen Mehraufwand durch eine automatisierte Kontextualisierung zu reduzieren.
Dieser Artikel stammt aus dem Sonderheft "Sichere Software entwickeln [16]". Ressourcen und weiterführende Quellen zum Artikel finden sich auch gesammelt unter ix.de/zb98 [17].
Dr. Johannes Späth
ist Co-Founder und CEO von CodeShield [18] und hat Industrie- und Forschungserfahrung im Bereich SAST.
Manuel Benz
ist Co-Founder und CTO von CodeShield und bringt mehrjährige Erfahrung in IT-Security und dynamischer Codeanalyse mit.
Andreas Dann
ist Experte im Bereich SCA und ist seit 2020 Mitgründer sowie COO von CodeShield.
(sih [19])
URL dieses Artikels:
https://www.heise.de/-6336036
Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/KI-in-DevSecOps-Vom-Copiloten-zum-Autopiloten-9640331.html
[2] https://www.heise.de/hintergrund/Chancen-fuer-Quereinsteiger-wie-IT-Neulinge-und-erste-Projekte-zusammenfinden-9590255.html
[3] https://www.heise.de/news/We-Are-Developers-Das-Herbstmagazin-2023-kostenlos-herunterladen-9570659.html
[4] https://www.heise.de/hintergrund/Praktische-Barrierefreiheit-in-der-Webentwicklung-9279097.html
[5] https://www.heise.de/news/We-Are-Developers-Die-englische-Ausgabe-2023-ist-kostenfrei-verfuegbar-9201013.html
[6] https://www.heise.de/hintergrund/Webentwicklung-Detaillierte-Linkvorschauen-von-Websites-automatisiert-erstellen-7770614.html
[7] https://www.heise.de/developer/young-professionals-6065678.html
[8] https://medium.com/@ory_51733/serverless-and-the-evolution-in-cloud-security-how-faas-differs-from-iaas-4ea8bc7b1dff
[9] https://www.nytimes.com/2020/08/06/business/capital-one-hack-settlement.html
[10] http://web.mit.edu/smadnick/www/wp/2020-16.pdf
[11] https://businessinsights.bitdefender.com/worst-amazon-breaches
[12] https://www.cisecurity.org/cis-benchmarks/
[13] https://www.gartner.com/smarterwithgartner/is-the-cloud-secure
[14] https://pureadmin.qub.ac.uk/ws/portalfiles/portal/128394396/SMillar_13616005_VulnerabilityDetectionInOSS.pdf
[15] https://research.esg-global.com/reportaction/CybersecurityAnalyticsandOperationsJuly17/Marketing
[16] https://www.heise.de/news/iX-Developer-Sonderheft-Sichere-Software-entwickeln-ab-sofort-am-Kiosk-6276533.html
[17] https://www.heise.de/select/ix-special/2021/16/softlinks/zb98?wt_mc=pred.red.ix.ix162021.044.softlink.softlink
[18] https://codeshield.io/
[19] mailto:sih@ix.de
Copyright © 2022 Heise Medien