Cyberbedrohungen
API-Sicherheit: Gefahren im Registry
Nicht nur API-Gateways stellen ein Risiko dar, auch etwa Container-Image-Registries, eine kritische Komponente der containerisierten Infrastruktur, bieten häufig Angriffspunkte. Wir zeigen mit unserer Analyse, wo die liegen und was zu tun ist.
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. 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 sollte. Bereits der erste Teil der Vorstellung unserer Untersuchung zeigt, dass Administratoren sichere Konfiguration gewährleisten müssen, die Umleitungsangriffe vermeidet und nur vertrauenswürdige Identitätsanbieter zulässt Die gesamte Analyse können Interessierte im Bericht „API Security Exposed: The Role of API Vulnerabilities in Real-World Data Breaches“ nachlesen.
Die API-Probleme enden jedoch nicht damit. Unsere Analyse umfasst ebenso Microservices, die die API-Backends antreiben sowie offen zugängliche Container-Image-Registries und Schwachstellen im Azure Service Fabric.
Durch die Möglichkeiten der Isolierung, Portabilität und Einheitlichkeit ermöglichen Container eine schnelle Skalierung und effiziente Integration in Cloud-Umgebungen. Doch dahinter steht ein ganzes API-Ökosystem, das unter anderem für das Erstellen eines Docker-Containers oder für die Bereitstellung eines Containers innerhalb eines Clusters erforderlich ist.
Ein wesentlicher Aspekt bei der Arbeit mit Containern ist die Speicherung und Verwaltung der Container-Images, die zur Kapselung von Anwendungen verwendet werden. Dafür bieten Cloud-Service-Provider (CSPs) inzwischen Registry-Services an, die als Image-Repositorys fungieren und es Entwicklern ermöglichen, Anwendungen in verschiedenen Umgebungen gemeinsam zu nutzen und bereitzustellen. Darüber hinaus können Unternehmen ihre Container-Image-Registries entweder vor Ort oder innerhalb von Cloud-Computing-Instanzen (Workloads) ausführen.
Container-Image-Registrys sind mehr als nur Speicherorte. Die dort liegenden Container-Images umfassen statische Dateien und die Ebenen mit vorinstallierten Anwendungen und deren Abhängigkeiten sowie Umgebungs-Setups mit Anwendungscodes, Bibliotheken, Systemtools und Einstellungen. Jede Ebene eines Container-Images stellt eine Änderung am Image dar. Sie sind gestapelt, um das endgültige Image zu bilden. Beim Erstellen eines Images werden nur die geänderten Schichten aktualisiert.
Die Registry dient als Verteilungspunkt, das heißt ein Image kann bei Bedarf abgerufen werden. Dies ist ein entscheidender Aspekt des Container-Lebenszyklus, da er sicherstellt, dass verschiedene Versionen von Anwendungen konsistent und zuverlässig in verschiedenen Umgebungen bereitgestellt werden können. Aus diesem Grund sind die Sicherheit und Zuverlässigkeit der Registry von äußerster Bedeutung. Ist eine Registry kompromittiert, kann dies zum Einsatz kompromittierter Images führen, was weitreichende Auswirkungen auf die Sicherheit haben kann. Registrys verwalten auch Image-Versionen und behalten den Überblick über verschiedene Image-Varianten.
Wir haben manuelle Container-Registry-Bereitstellungen innerhalb von Cloud-Workloads untersucht, da diese von Natur aus anfälliger für Fehlkonfigurationen sind und einen beliebten Angriffsvektor für Bedrohungsakteure darstellen.
Offen liegende Image Registrys
Bei unserer Analyse offener privater Registrys stellten wir fest, dass eine beträchtliche Anzahl von ihnen bei einem großen Cloud-Service-Anbieter gehostet wird. Diese Registrys besaßen keine Authentifizierung, sodass eine Verbindung hergestellt und der Inhalt der Registry heruntergeladen werden konnte, ohne auf Brute-Force-Methoden zurückgreifen zu müssen.
Wir fanden
- 31 TB heruntergeladener Images
- 197 einzigartige Registries sowie
- 20.503 Images
Eine weitere Recherche in den offenen Registrys offenbarte eine Fülle an Informationen. Auch waren mehrere Unternehmen betroffen. Die Daten umfassen alles von API-Schlüsseln für die Integration von Drittanbietersystemen bis hin zu ganzen Codebasen, die alle zum Download zur Verfügung stehen.
Zunächst fiel uns auf, dass einige dieser privaten Registrys als Versionsverwalter verwendet wurden: eine Sicherung zahlreicher Versionen desselben Image für entwickelte Produkte. Das lässt vermuten, dass die die tatsächlichen Zahlen exponentiell höher sein könnten.
Image-Analyse
Eine weitere beunruhigende Erkenntnis ist das Leakage von Quellcode. Dieses schwerwiegende Sicherheitsproblem zeigt Konfigurationen auf, die es Angreifern ermöglichen, gültige Token oder offene Autorisierungsgeheimnisse (OAuth) zu generieren, um unbefugten Zugriff auf Systeme und Daten zu erhalten. Die Verfügbarkeit des Quellcodes erlaubt es einem böswilligen Akteur, sich als Anwendungs-User auszugeben und damit den Schaden weiter zu vergrößern – kurz: die Möglichkeit der API-Nutzung, der Struktur und Mechanismus zur Erzeugung von Geheimnissen durch Dritte.
Die besorniserregendste Entdeckung aber war das Durchsickern sensibler Informationen, einschließlich Geheimnissen im Dateisystem und Container-Image-Metadaten, die Umgebungsvariablen mithilfe von Umgebungsanweisungen spezifizieren. Die Liste im Whitepaper zeigt die Arten von sensiblen Daten, die wir in den Images gefunden haben: CSP Access Keys, .Env, Dockerfile und andere.
Sicherheitsempfehlungen für Container-Image-Registrys
Probleme mit der Sicherheit gibt es nicht nur bei frei zugänglichen Container-Registrys, auch bei Entwicklungsvorgängen müssen Risiken berücksichtigt werden. Wir empfehlen Folgendes, um Sicherheitsrisiken zu minimieren:
- Geheimnisse nicht in Dateien innerhalb von Container-Images fest zu codieren, sie in Tresoren zu speichern und auf sie zu verweisen.
- Werden Umgebungsvariablen für Geheimnisse verwendet, diese nicht in Dockerfiles oder .env-Dateien zu speichern, sondern sie stattdessen zur Containerlaufzeit einzufügen.
- Sicherstellen, dass private Container Registrys nicht öffentlich zugänglich sind.
- Verschlüsseln der Container-Images.
Container-Image-Registrys sollten regelmäßig auf Fehlkonfigurationen überprüft und ständig auf Schwachstellen, Malware und Geheimnisse gescannt werden. Eine einfache und sichere Möglichkeit, Anwendungen auszuführen, ist distroless14 und die Verwendung eines Geheimnismanagers, um Geheimnisse in Container-Laufzeiten einzufügen.
Azure WA Agent und Service Fabric
Es wäre kurzsichtig zu glauben, dass die Cloud API-Sicherheitsbedenken löst, da wir kritische Sicherheitslücken in Azure-Diensten gefunden haben, die es Angreifern ermöglichen, ganze Cluster von nur einem kompromittierten Container aus zu übernehmen. Selbst Technologiegiganten wie Microsoft können kritische Sicherheitslücken übersehen.
Azure bietet zwei Arten von Service Fabric-Diensten an: Managed Services legen die Verantwortung für Konfiguration und Wartung der Nodes in die Hände des CSPs, während nicht gemanagte Dienste in der Verantwortung des Nutzers bleiben. Der WA Agent ist die Standardkomponente, die das Remote-Management von VM-Instanzen erlaubt. Die Bereitstellung umfasst auch Services Fabric, da der Cluster aus Azure-VMs besteht. Der Agent kommuniziert über seine HTTP-Endpunkte mit einem „Wire-Server“.
Bereits früher hatten Forscher von Intezer17 eine Privilege Escalation-Schwachstelle gefunden, die es nicht privilegierten Benutzern ermöglicht, sich als Root zu betätigen. Die Lücke konnte ausgenutzt werden, weil zugehörige Zertifikate, die zur Verschlüsselung sensibler Informationen in WA-Agent-Erweiterungen verwendet werden, undicht waren. Diese Sicherheitslücke sollte zum Zeitpunkt der Bekanntgabe (Mai 2021) behoben sein. Da sich die Schwachstelle jedoch auf nicht privilegierte Benutzer bezog, die sich selbst zu Root auf Azure VM machen konnten, dachte niemand an die Auswirkungen auf die Service Fabric, was zur Entdeckung von CVE-2023-21531 (Azure Service Fabric Container Elevation of Privilege Vulnerability) führte. Einzelheiten zu der Lücke finden Interessierte im Original-Paper.
Interne APIs
APIs wurden als interne Kommunikationsmechanismen zwischen verschiedenen Softwareschichten und Microservices eingeführt und nicht müssen nicht unbedingt vom Benutzer aufgerufen werden. Benutzer sollten sich darüber im Klaren sein, dass eine fehlende Authentifizierung oder Autorisierung dazu führt, dass jeder in der Lage ist, die API-Anfrage auszuführen und die interne Implementierung auszunutzen, wie im Fall des Wire-Servers.
Das andere Problem liegt in der Lösung. Anstatt einen ordnungsgemäßen Autorisierungsmechanismus auf der Serverseite zu implementieren, wurde eine Abkürzung verwendet, indem eine Firewall-Regel auf dem Host erstellt wurde, die aber((fig eine Ausnutzung in Service Fabric ermöglicht.
Verwaltete Identitäten und Token-Bereiche
Verwaltete Identitäten stellen ein weiteres Beispiel für ein internes API-Sicherheitsrisiko dar, das in der Azure Cloud existiert. Verwaltete Identitäten ermöglichen es Benutzern, Dienste zu authentifizieren, die in der Azure Cloud verfügbar sind. Sie bieten eine Schnittstelle, um dynamisch ein Token zu erhalten, der dann der Authentifizierung dient.
Der Benutzer sendet eine API-Anfrage an einen Managed Identity-Dienst, um ein Token zu erhalten. Bei der Analyse der Binärdatei des Dienstes stellten wir fest, dass die Anfrage an den öffentlich zugänglichen Endpunkt weitergeleitet und mithilfe eines Client-Zertifikats authentifiziert wird. Das Zertifikat selbst wird zusammen mit anderen erforderlichen Parametern mithilfe von Umgebungsvariablen injiziert und von der Binärdatei verwendet. Während das Zertifikat selbst in dem verschlüsselten Blob verborgen ist, besteht das Problem darin, dass der Entschlüsselungs-Key auch in Umgebungsvariablen in Klartextform vorhanden war. Dadurch konnten wir den gesamten verschlüsselten Kontext entschlüsseln, einschließlich des Client-Zertifikats und aller notwendigen Parameter für den öffentlichen Proxy. Wir haben festgestellt, dass keine dieser Variablen in der Umgebung notwendig war.
Durch ihre Offenlegung konnten wir ein gültiges Managed Identity-Token außerhalb der Azure-Umgebung erhalten. Ein ähnliches Problem gibt es auch im Azure Machine Learning-Service. Einzelheiten dazu im Paper.
Darüber hinaus lassen sich die durch eine böswillige Aktivität generierten Logs nicht von regulären Aktivitäten unterscheiden, da handlungsrelevante Indikatoren für den Standort (z. B. IP-Adresse) fehlen, um festzustellen, woher die Anfrage stammt. Solche ungeprüften Grenzfälle in internen Cloud-Agenten-APIs führen dazu, dass Fehler auftreten, die es Angreifern ermöglichen, unerkannt in Cloud-Umgebungen zu verweilen, selbst wenn die Cloud-native Protokollierung aktiviert ist. Das zeigt, wie wichtig die Validität des Tokens ist, und deshalb sollte man darüber nachdenken, in welchem Bereich das Token gültig ist.
DevOps-Server
Schließlich ging es in der Untersuchung noch um den Azure DevOps Server als Alternative zu bestehenden CI/CD-Lösungen. Diese benötigt man für die Ausführung von Jobs, wie das Extrahieren von Sourcecode aus dem SCM. Ein API ist dazu erforderlich. Das HTTP-Protokoll wird für die Verbindung zum Server standardmäßig verwendet, d. h. der Datenverkehr wird unverschlüsselt übertragen, so dass er gekapert werden kann, insbesondere in lokalen Netzwerken bei On-premise-Installationen. Auch dazu liefert das Paper Einzelheiten.
Dafür ist es sinnvoll, bereits verifizierte und gut implementierte Lösungen wie TLS on HTTP, auch bekannt als HTTPS, einzusetzen, um Sicherheitsprobleme zu vermeiden.
Die Hauptprobleme bei der HHTP-Implementierung sind:
- Der Agent überprüft nicht, ob die Antwort vom legitimen Server stammt oder nicht.
- Der AES-Schlüssel, der zur Verschlüsselung einer Auftragsspezifikation verwendet wird, kann erfolgreich durch einen benutzerdefinierten AES-Schlüssel ersetzt werden, indem die „verschlüsselt“ auf „falsch“ gesetzt wird. Der Agent ist nun gezwungen, die unverschlüsselte benutzerdefinierte Version des AES-Schlüssels zu akzeptieren. Selbst wenn diese Funktion nicht vorhanden ist, kann der Angreifer eine Übertragung eines öffentlichen Schlüssels ausspähen, während der Agent konfiguriert wird, und ihn zur Verschlüsselung seines eigenen AES-Schlüssels
Letztendlich wissen wir, dass es nicht ausreicht, die Probleme aufzuzeigen. Stattdessen bieten wir umsetzbare Lösungen und praktische Schritte zur Sicherung von API-Systemen an. Wenn Sie sich in die Denkweise eines Angreifers versetzen, können Sie Ihre Authentifizierung, Protokollierung, Geheimhaltung und Ihre gesamte DevOps-Pipeline neu bewerten, um eine robuste API-Sicherheitsstrategie zu gewährleisten.
