Azure Airflow: Ein Cluster auf dünnem Eis : Kritische RBAC-Schwachstellen in Azure Airflow
In der Apache Airflow-Integration von Azure Data Factory wurden drei Sicherheitslücken entdeckt. Ein Angreifer könnte diese Lücken bei erfolgreicher Ausnutzung für verdeckte Aktionen nutzen. Dazu zählen die Exfiltration von Daten und die Verbreitung von Malware.
Palo Alto Networks Unit 42 veröffentlichte kürzlich eine sehr interessante Analyse über Apache Airflow. Darin warnt das Unternehmen, dass Angreifer die neu entdeckten Sicherheitslücken ausnutzen könnten. Dadurch wäre dauerhafter Zugriff auf den gesamten Airflow Azure Kubernetes Service Cluster möglich. Die Angreifer könnten dabei als sogenannte „Schatten-Administratoren“ auftreten.
Es handelt es sich um folgende Schwachstellen – Microsoft stuft sie als nicht sonderlich kritisch ein:
- Fehlkonfiguration der Kubernetes-Rollen- und Rechteverwaltung (RBAC) im Airflow-Cluster
- Fehlerhafte Handhabung von geheimen Zugangsdaten im internen Azure-Dienst Geneva
- Schwache Authentifizierung für den Geneva-Dienst
Im Geneva-Dienst könnten Angreifer die Schwachstellen nutzen, um Protokolldaten zu ändern oder falsche Protokolle zu senden. So könnten sie etwa neue Benutzerkonten oder Kubernetes-Pods erstellen, ohne Verdacht zu erregen.
Wie die Angriffskette aufgebaut ist
Der erste Schritt des Angriffs besteht darin, eine sogenannte DAG-Datei (Directed Acyclic Graph) zu erstellen, oder eine bereits vorhandene Datei zu manipulieren. Diese Datei wird anschließend in ein privates GitHub-Repository hochgeladen, das mit dem Airflow-Cluster verbunden ist. Das Ziel dabei ist es, eine sogenannte Reverse Shell zu einem externen Server herzustellen, sobald die Datei vom Cluster importiert wird. Eine Reverse Shell ermöglicht es dem Angreifer, vom Zielsystem aus eine Verbindung zu seinem eigenen Server aufzubauen und so Zugriff auf das System zu erhalten.
Um diesen Angriff durchzuführen, muss der Angreifer zunächst Schreibrechte für das Speicherkonto erlangen, in dem die DAG-Dateien abgelegt sind. Dies kann beispielsweise durch die Verwendung eines gestohlenen Service Principal oder eines kompromittierten SAS-Tokens (Shared Access Signature) geschehen. Eine weitere Möglichkeit besteht darin, in ein verknüpftes GitHub-Repository einzudringen, indem die Zugangsdaten ausgespäht werden.
Die so erlangte Shell lief zunächst mit den eingeschränkten Rechten des Airflow-Benutzers in einem Kubernetes-Pod. Bei weiterer Untersuchung wurde jedoch festgestellt, dass ein mit dem Airflow-Runner-Pod verbundenes Dienstkonto über Administratorrechte für den gesamten Cluster verfügte.
Durch diese Fehlkonfiguration und die Tatsache, dass der Pod über das Internet erreichbar war, konnte der Angreifer das Kubernetes-Tool kubectl herunterladen. Damit war er in der Lage, einen privilegierten Pod bereitzustellen und aus diesem Pod auf die zugrunde liegende virtuelle Maschine zuzugreifen. Dadurch erhielt der Angreifer vollständige Kontrolle über den gesamten Cluster.
Über den vollständigen Zugriff auf die virtuelle Maschine (VM) des Hosts ist es dem Angreifer möglich, um tiefer in die Cloud-Umgebung vorzudringen. Dadurch würde er unbefugt auf interne Ressourcen von Azure zugreifen können, darunter auch den internen Dienst Geneva. Einige dieser Ressourcen erlauben Schreibzugriff auf Speicherkonten oder Event-Hubs, was schwerwiegende Folgen haben könnte.
„Das bedeutet, dass ein geschickter Angreifer eine verwundbare Airflow-Umgebung manipulieren könnte“, erklärten die Sicherheitsexperten Ofir Balassiano und David Orlovsky. „Ein solcher Angreifer könnte beispielsweise neue Kubernetes-Pods oder neue Dienstkonten erstellen. Außerdem könnte er Veränderungen an den Clusterknoten vornehmen und gefälschte Protokolle an den Geneva-Dienst senden, ohne dass Sicherheitsalarme ausgelöst werden.“
Das Problem verdeutlicht, wie wichtig eine sorgfältige Verwaltung von Dienstberechtigungen ist, um unbefugten Zugriff zu verhindern. Es zeigt auch, wie es entscheidend ist, den Betrieb von kritischen Diensten Dritter fortlaufend zu überwachen, um potenzielle Angriffe frühzeitig zu erkennen und zu verhindern.
Weitere Cloud-Schwachstellen entdeckt
Die Enthüllung kommt, nachdem die Datadog Security Labs auf eine Schwachstelle im Umgang mit Berechtigungen in Azure Key Vault hingewiesen haben. Die Sicherheitsforscher erklärten, dass Benutzer mit der Rolle Key Vault Contributor möglicherweise Zugriff auf sensible Inhalte wie API-Schlüssel, Passwörter, Authentifizierungszertifikate und Azure Storage SAS-Tokens erlangen könnten, selbst wenn sie ursprünglich keinen direkten Zugriff auf diese Daten hatten.
Benutzer mit der Rolle „Key Vault Contributor“ haben normalerweise keinen direkten Zugriff auf die Daten im Key Vault, wenn dieser durch Zugriffsrichtlinien geschützt ist. Allerdings – und hier liegt das Problem – können sie sich selbst in diese Zugriffsrichtlinien eintragen. Damit umgehen sie die Beschränkungen und erhalten trotzdem Zugriff auf die sensiblen Daten im Key Vault.
„Ein Benutzer kann die Zugriffsregeln im Key Vault ändern und sich dadurch Berechtigungen geben, um die darin gespeicherten Daten zu lesen, zu bearbeiten oder zu verwalten“, so die Sicherheitsexpertin Katie Knowles. „Das bedeutet, dass jemand mit der Rolle ´Key Vault Contributor´ auf alle Daten zugreifen kann – selbst dann, wenn er laut Sicherheitsvorgaben eigentlich keinen Zugriff haben dürfte.“
Microsoft hat inzwischen reagiert und die eigene Dokumentation aktualisiert, um auf diese Schwachstelle hinzuweisen. Es wird nun empfohlen, den Zugriff von Contributor-Rollen auf Key Vaults im Rahmen des Zugriffsrichtlinienmodells stärker einzuschränken. Microsoft betont, dass es entscheidend ist, diese Rolle so zu verwalten, dass sie keinen unbefugten Zugriff auf sensible Schlüssel, Geheimnisse und Zertifikate ermöglicht.
Parallel dazu entdeckten Forscher von Sysdig ein weiteres Sicherheitsproblem bei Amazon Bedrock. Die CloudTrail-Protokollierung, die Sicherheitsvorfälle erfassen soll, macht es schwer, bösartige von normalen Anfragen an große Sprachmodelle zu unterscheiden. Dadurch könnten Angreifer unbemerkt nach Schwachstellen suchen.
„Ein Problem war, dass erfolgreiche und fehlgeschlagene API-Anfragen gleich protokolliert wurden“, so der Sysdig-Experte Alessandro Brucato. „Ohne spezielle Fehlercodes könnten Sicherheitslösungen normale Aktionen fälschlicherweise als gefährlich einstufen. Das führt zu vielen Fehlalarmen, während echte Bedrohungen unbemerkt bleiben.“