Cyberbedrohungen
Die Rolle der API-Sicherheit im Gesamtschutz
Sicherheitsteams aber auch CTOs und DevOps müssen die Herausforderungen im Umgang mit API-Sicherheit kennen, um die Taktiken von Cyberkriminellen zu antizipieren und gegenzusteuern. Unsere Untersuchung der API-Schwachstellen und Risiken hilft dabei.
Verstehen Organisationen wirklich die Feinheiten der API-Sicherheit und wissen sie, dass die mangelnde Sicherung ihrer Systeme das gesamte Unternehmen gefährden könnte? Wir haben den Bereich der API-Sicherheit, auch anhand von zwei beliebten API-Gateways (APISIX und Kong) untersucht und zeigen im Detail auf, wo Risiken liegen und wie man damit umgehen kann. Die gesamte Analyse können Interessierte im Bericht „API Security Exposed: The Role of API Vulnerabilities in Real-World Data Breaches“ nachlesen.
Ein API-Gateway ist im Zeitalter der Cloud oft der Einstiegspunkt in das API-Ökosystem eines Unternehmens. Das Gateway leitet in der Regel eingehenden Datenverkehr an die entsprechenden Backends weiter, z. B. an Microservices, die in Containern in einem Cluster von Virtual Machines ausgeführt werden, die bereitgestellt werden. API-Gateways bieten jedoch mehr Funktionen als nur Routing. Damit entstehen zwar mehr Möglichkeiten, aber auch das Risiko, dass unachtsame Benutzer, verschiedene Fehlkonfigurationen einzuführen, die das gesamte System anfällig machen.
Zu den weiteren Funktionen gehören Autorisierung und Authentifizierung, Entlastung des Backends durch Delegierung von Aufgaben an das API-Gateway (statt Backend), TLS-Terminierung, Aggregation sowie Zentralisierung zum Single Point of Access.
Risiken
Als Beispiel für ein Risiko soll eine Konfiguration dienen, bei der das API-Gateway über eine Routing verfügt, das einen API-Schlüssel erfordert. Der Backend-Dienst wiederum benötigt jedoch keine Authentifizierung. Wer innerhalb des internen Netzwerks Zugriff auf den Backend-Dienst hat, benötigt also keine Authentifizierung. Die Konfiguration macht den Backend-Service anfällig für SSRF-Angriffe (Server-Side Request Forgery), wenn der Dienst innerhalb des internen Netzwerks erreichbar ist. Ein kompromittiertes internes Gerät, ein kompromittierter Container oder Dienst ermöglicht Bedrohungsakteuren freien Zugang und erlaubt ihnen, laterale Bewegungen durchzuführen.
Die TLS-Terminierung bringt zwar den Vorteil, den Performance-Overhead zu reduzieren, der erforderlich ist, um verschlüsselte Anfragen zu senden, sie am anderen Ende zu entschlüsseln und das Backend zu entlasten. Dies hat jedoch seinen Preis, da die Geheimnisse nach der TLS-Terminierung im Klartext gesendet werden. Ohne zusätzliche Sicherheitsmaßnahmen auf Netzwerkebene wird ein geschickter Angreifer versuchen, die Pakete abzufangen und die Geheimnisse zu enttarnen oder die Dienste zu manipulieren, indem er beispielsweise MITM-Angriffe in Umgebungen startet, in denen dies möglich ist. Benutzer sollten bei lokalen Workloads besonders vorsichtig sein.
Mit diesen Beispielen erhält man eine Vorstellung davon, warum Zugangskontrolle, TLS und die richtige Speicherung von Geheimnissen entscheidende Elemente für die Sicherheit sind nicht nur für den API-Gateway, sondern für das gesamte System.
Es ist nicht ungewöhnlich, dass Anwender benutzerdefinierte, verwaltete Dienste in Cloud-Umgebungen einsetzen. Zum Beispiel stellen sie ein API-Gateway in einer Elastic-Computing-Instanz bereit, wobei sie die Verantwortung letztlich vom Cloud-Service-Anbieter auf sich selbst übertragen. Der Benutzer hat die vollständige Konfigurationskontrolle. Die sichere Konfiguration liegt in seiner vollen Verantwortung. Fehlkonfigurationen gehören zu den häufigsten Bedrohungen für Software-Implementierungen, unabhängig vom Standort.
Wir haben unsere Untersuchung anhand des IPv4-Adressbereichs eines öffentlich bekannten CSP durchgeführt und nach den Fingerabdrücken von API-Gateways und zugehörigen Diensten, die in Cloud-Umgebungen laufen. Zu diesem Zweck haben wir zwei beliebte Gateways ausgewählt - APISIX und Kong. APISIX basiert auf dem NGINX-Webserver und dem OpenResty LUA-Erweiterungs-Framework, die als Kernkomponenten des Gateways dienen. Plug-ins erweitern die Funktionalität und fügen Funktionen für Beobachtbarkeit, Sicherheit, Verkehrssteuerung usw. hinzu. Ein optionales Dashboard ist ein separater Dienst, der direkt mit der Verwaltungs-API kommuniziert. Die ganze Untersuchung dieser speziellen API-Gateways enthält der Bericht, der zum Download bereit steht.
Missbrauch von API-Gateways
Missbrauch einer anfälligen Computerressource wie Fehlkonfigurationen der API-Gateway-Sicherheit, die kostenlos ist, ist eindeutig eine triftige Motivation für einen Bedrohungsakteur, etwa um Krypto-Jacking-Malware einzusetzen, mit der Einnahmen generiert werden können, einschließlich eines Bots, der sich einem großen Netzwerk anschließt, das für DDoS-Angriffe (Distributed Denial of Service) verwendet wird. Ein weiterer Grund ist die Verbreitung von Malware durch die Erstellung eigener Endpunkte, die Malware bereitstellen.
Gezielte Angriffe zu starten, könnte komplizierter sein, da API-Gateways als Backend-Service-Gateway fungieren und es unwahrscheinlich ist, dass sie als reine HTML-Ressource dienen. Vorstellbar wäre jedoch ein API-Dienst, der Software-Download-Links zurückgibt. In solchen Fällen können ausgenutzte API-Gateway-Instanzen so konfiguriert werden, dass sie als bösartige Links dienen, was zu einem Supply-Chain-Angriff führt.
Bei gezielteren Angriffen würden Bedrohungsakteure die API-Gateway-Funktionalität nutzen, um Anmeldeinformationen zu sammeln, sich als Benutzer auszugeben oder kritische Unternehmensinformationen zu erhalten, um sie zu verkaufen oder in zukünftigen Angriffen auszunutzen.
Häufige Fehlkonfigurationen
Fehlkonfiguration Nr. 1: Weiterleitung der Admin-API
In sichereren Implementierungen sollte die Admin-API nur localhost zugewiesen werden, ohne Weiterleitung von Administrations-Ports und ohne gemeinsame Nutzung des Netzwerks mit dem Host. Gateway-Administratoren können eine neue Route zur Schadensbegrenzung einrichten, für die Anmeldeinformationen erforderlich sind. Die Route kann auf die Administrations-API verweisen, so dass sie außerhalb eines Containers zugänglich ist. Ähnlich verhält es sich mit der Unternehmensversion des API-Gateways, RBAC, die eine Token-Authentifizierung erfordert.
Es besteht auch die Gefahr des Copy-and-Paste ohne zusätzliche Sicherheitsüberlegungen. Auch sind Einstellungen ein Sicherheitsrisiko, wenn ein Datenbankendpunkt aufgrund einer Fehlkonfiguration oder einer benachbarten Systemkompromittierung verfügbar wird. Dies bietet einen einfachen Weg, um Zugang zu vertraulichen Daten zu erhalten, ähnlich wie in Szenarien, in denen keine Anmeldeinformationen verwendet wurden.
Fehlkonfiguration Nr. 2: Fehlen von Firewall-Regeln
Eine öffentliche IP-Adresse ist wie eine Tür, jeder – auch ein Eindringlinge –kann wann immer darauf zugreifen. Daher sollte es selbstverständlich sein, dass für eine höhere Sicherheit Maßnahmen wie das Abschließen der Tür und die Weitergabe von Schlüsseln nur an vertrauenswürdige Personen unabdingbar sind.
Ebenso gehört dazu, dass nur autorisierte Stellen auf die Cloud-Instanz im Unternehmen zugreifen können. Die Beschränkung des Zugriffs nur bestimmter IP-Adressen oder Unternetze auf exponierte Ports in Verbindung mit einem Authentifizierungsmechanismus trägt zudem dazu bei, das Szenario zu entschärfen.
Besondere Vorsicht ist geboten bei Bereitstellungen, bei denen Personen mit dynamischen IP-Adressen auf die Anwendungen zugreifen. Verwenden Es sollten stattdessen zusätzliche Zugriffsvektoren wie virtuelle private Netzwerke (VPNs) genutzt werden.
Speichern von Geheimnissen
Normalerweise erfordert der Zugriff auf geschützte Ressourcen wie Verwaltungsebenen, API-Backends und serverlose Endpunkte einen Authentifizierungsmechanismus. Doch ist einer der Einsatzbereiche von API-Gateways die Vereinfachung der Authentifizierung mithilfe eines Identitätsanbieters, der gültige Token ausstellt, die vom API-Gateway akzeptiert werden. Dieses leitet dann eine Anfrage mithilfe eines zuvor gespeicherten Geheimnisses an die geschützte Ressource weiter. Die Konfiguration wirkt sich auf die Art und Weise aus, wie die Geheimnisse gespeichert werden, da sie im Arbeitsspeicher der bereitgestellten Anwendung oder in der Datenbank gespeichert werden können.
Die Sicherung dieser Geheimnisse ist daher für die Gesamtsicherheit des Systems von entscheidender Bedeutung, und mehrere Schritte können dabei helfen. Ein konkretes Beispiel liefert die Untersuchung des Kong API-Gateways.
- Zunächst darf der Datenspeicher nur über das API-Gateway zugänglich sein. Die Anmeldedaten für den Zugriff auf die Datenbank sollten nicht leicht zu erraten sein oder aus Standardkonfigurationen und -beispielen kopiert werden können.
- TLS als Schutzmaßnahme kann das Ausspähen des Netzwerks bei lokalen Bereitstellungen verhindern.
- Szenarien, in denen es nicht notwendig ist, ein Geheimnis weiterzugeben, z. B. bei der Konfiguration des API-Schlüssel- oder Token-Zugriffs auf Gateway-Routen, sollten vertrauliche Informationen nicht nur im Klartext oder verschlüsselt gespeichert werden, da dies die Wiederherstellung des Geheimnisses im Falle einer Offenlegung ermöglicht. Stattdessen kann ein Hashing-Mechanismus und Salting angewendet werden, wodurch es fast unmöglich wird, das ursprüngliche Geheimnis im Falle einer Datenbank-Offenlegung wiederherzustellen. Wo dies nicht anwendbar ist, sollte Verschlüsselung oder externe Tresorspeicherung zum Einsatz kommen.
Der Zugriff auf APIs und Webanwendungen ist eng mit Authentifizierung und Autorisierung verbunden. OAUTH 2.0 und OpenID connect sind Industriestandards geworden und werden in API-Gateways unterstützt. Korrekte Implementierungen dieser Abläufe sind entscheidend Elemente der API-Sicherheit.
Ein Versagen dieser Elemente kann zu einer erfolgreichen Benutzer-Identifizierung und einem nicht autorisierten Zugriff führen, der unter Umständen kaum zu erkennen ist. Auch ausgestellte Token und Einstellungen für den Autorisierungsprozess werden in der Datenbank oder in der Speicherkonfiguration gespeichert. Mangelhafte Sicherheit für das Verwaltungs-API oder die Datenbank kann sehr negative Folgen haben.
Die API-Probleme enden jedoch nicht hier. Unsere Analyse umfasst ebenso Micro-Services, die die API-Backends antreiben sowie offene Container-Image-Registries. Im zweiten Teil stellen wir die Ergebnisse dieser Untersuchung vor und bieten umsetzbare Lösungen und praktische Schritte zur Sicherung von API-Systemen an.
