Azure DevOps, eine Plattform von Microsoft für die kontinuierliche Integration und Bereitstellung von Software, ist für viele Unternehmen ein zentraler Bestandteil ihrer Entwicklungsprozesse. Doch trotz der soliden Infrastruktur und umfangreichen Sicherheitsmechanismen haben Experten immer wieder Sicherheitslücken aufgedeckt. Insbesondere Server-Side Request Forgery (SSRF) stellt eine wiederkehrende Bedrohung dar, die es Angreifern ermöglicht, den Server dazu zu bringen, Anfragen an interne oder externe Dienste zu senden, die eigentlich nicht erreichbar sein sollten. In einer aktuellen Untersuchung hat das Sicherheitsteam von Binary Security weitere SSRF-Schwachstellen in Azure DevOps entdeckt und dokumentiert, die bedeutende Auswirkungen auf die Systemsicherheit haben können. Die nachfolgende Analyse vertieft sich in die Details dieser Sicherheitslücken, die Entdeckungsschritte, sowie die von Microsoft ergriffenen Maßnahmen und Workarounds der Forscher.
Die Grundlage für die Untersuchung bildet besonders die API-Schnittstelle /serviceendpoint/endpointproxy, welche für das Anlegen von Service-Verbindungen und die Integration von Ressourcen in Pipelines verantwortlich ist. Angreifer können durch gezielte Manipulationen der Parameter dieser API bestimmte Serveranfragen initiieren. Im Fokus stehen dabei vor allem zwei Parameter: serviceEndpointDetails.url und dataSourceDetails.dataSourceUrl.
Während der ersterer einen Callback vom Server an eine beliebige URL auslösen kann, existieren Einschränkungen bei der Nutzung von IP-Adressen, die dem internen Netzwerk oder speziell der Azure-Metadatenadresse 169.254.169.254 zugeordnet sind. Um diese Beschränkungen zu umgehen, haben die Forscher raffinierte Methoden entwickelt, darunter der sogenannte DNS-Rebinding-Angriff, der in der Lage ist, die IP-Filterung zu unterlaufen und Serveranfragen an eigentlich verbotene interne Dienste zu ermöglichen.
Die verwendete Technik setzt auf die Manipulation von DNS-Antworten bei mehreren schnellen Anfragen, wodurch unter Umständen der gleiche Hostname auf verschiedene IP-Adressen aufgelöst wird. Das eröffnet Angreifern die Möglichkeit, in einem ersten Schritt eine erlaubte IP zu nutzen, um die Filter zu passieren, und im Anschluss intern eine unerlaubte IP-Adresse anzusprechen. Ein weiterer interessanter Aspekt der Untersuchung ist die Templating-Engine in Azure DevOps, die beim Parsen von Vorlagen für URLs zur Anwendung kommt. Diese Engine basiert auf dem Mustache-Template-System, welches eigentlich für seine Logikfreiheit bekannt ist. Dennoch wurde entdeckt, dass durch Registrierung eigener Helferfunktionen beziehungsweise Helper sogenannte Gadgets implementiert sind, die komplexere Anfragen ermöglichen.
Ein Beispiel hierfür ist der GetFileContentHelper: Er erlaubt es, von einem Server eine Dateiinhalt-Anfrage zu stellen, indem er eine HttpWebRequest ausführt und die Antwort in Base64-kodierter Form zurückliefert. Obwohl dieses Feature durch Whitelisting der erlaubten Hostnamen und Protokolle eingeschränkt ist, ergeben sich hierdurch zusätzliche Angriffsvektoren. Diese erlauben sogenannte "inner requests", bei denen ein Startserver eine Anfrage an eine erlaubte Adresse stellt, die dann auf unerlaubte oder gar interne IPs weiterleitet. Insbesondere werden dabei auch HTTP-Redirects von der Applikation bei inneren Anfragen akzeptiert, wodurch es möglich ist, URLs zu verwenden, die auf interne, eigentlich geschützte Ressourcen umleiten. Die Ausgabe der Antwort wird schließlich über eine weitere Anfrage von der ursprünglichen URL an einen Angreifer-Server exfiltriert.
Die Forscher konnten diesen Mechanismus für eine SSRF auf die Azure-Metadaten-Adressierung ausnutzen und damit beispielsweise die interne Cloud-Infrastruktur beziehungsweise Metadaten auslesen. Dabei wurden auf internen Endpunkten Informationen wie Instanz-Details erbeutet, die sensible Einblicke in die Cloud-Umgebung von Azure DevOps gewähren. Microsoft reagierte auf die Meldungen der Forscher im Rahmen des Azure DevOps Bug-Bounty-Programms und implementierte zunächst eine Sperrung von Redirect-Responses. Allerdings konnten die Forscher erneut mittels DNS-Rebinding diese Schutzmaßnahme umgehen und eine erneute Schwachstelle nachweisen. Insgesamt zeigt sich, dass die komplexe Struktur von API-Abfragen in Verbindung mit flexiblen Template-Systemen durchaus ein hohes Risiko für SSRF-Angriffe birgt.
Aus Sicherheitsaspekten ergibt sich daraus die dringende Notwendigkeit, whitelisting-Mechanismen nicht nur für äußere Anfragen, sondern auch für weitergeleitete und Redirect-URLs durchzusetzen. Ebenso ist eine gründliche Überprüfung aller Template-Helper und eingebauten Gadgets von enormer Bedeutung, da diese als ungewollte Backdoors für Angreifer dienen können. Die Fallstudie zu Azure DevOps macht deutlich, wie gut integrierte Sicherheit nur durch konsequente und holistische Betrachtung aller Komponenten gewährleistet werden kann. Ein besonderer Aufschluss ergibt sich aus der parallelen Betrachtung der on-premises Version von Azure DevOps, die in C# veröffentlicht ist und somit leicht dekompiliert und untersucht werden kann. Der Einblick in den tatsächlichen Programmcode erlaubte den Forschern nicht nur eine einfache Identifikation von potenziellen Schwachstellen, sondern auch eine genaue Analyse des Verhaltens der Mustache-Templates und der HTTP-Request-Mechanismen.
Auf diese Weise konnten nicht nur bestehende Lücken nachvollzogen werden, sondern auch neue Angriffswege entworfen werden, die durch die reine Analyse von Cloud-APIs so nicht möglich gewesen wären. Insgesamt führten diese Erkenntnisse dazu, dass Microsoft im Verlauf von wenigen Monaten mehrere Updates releasede, um die entdeckten Schwachstellen nach und nach zu beheben. Die Trigger hierfür waren präzise Recherchen, Proof-of-Concept Exploits und eine engagierte Zusammenarbeit zwischen den Sicherheitsteams von Binary Security und Microsoft. Für bestehende Nutzer von Azure DevOps empfiehlt es sich dringend, die entsprechenden Updates und Security-Patches umzusetzen. Denn SSRF ist eine Angriffsform, die sich häufig nicht direkt mit offensichtlichen Schäden zeigt, aber durch das Ausnutzen von Metadaten- und internen APIs tiefgreifende Sicherheitsverstöße ermöglichen kann.
Unternehmen und Entwickler sollten ferner prüfen, wie sie in ihren eigenen Applikationen Template-Funktionen absichern und Remote-Requests robust kontrollieren können, um ähnliche Angriffe zu verhindern. Das Beispiel von Azure DevOps verdeutlicht, dass Angriffsmuster oft iterativ weiterentwickelt werden, selbst wenn vermeintliche Schutzmaßnahmen greifen. Der Umgang mit DNS-Rebinding-Techniken zeigt, wie wichtig eine ganzheitliche Abwehrstrategie ist, die sich auch verteilte Netzwerkanfragen, Session-Handling und DNS-Auflösungsmechanismen in einer Angriffsanalyse widmet. Abschließend bleibt anzumerken, dass die stetige Zusammenarbeit zwischen Sicherheitsexperten und Softwareherstellern der Schlüssel zu stabilen und sicheren Cloud-Diensten ist. Nur so können komplexe Angriffsszenarien frühzeitig erkannt und behoben werden, bevor sie im großen Maßstab Schaden anrichten.
Die fundierte Arbeit von Binary Security und deren detaillierte Dokumentation der SSRF-Problematiken in Azure DevOps bieten wertvolle Einblicke für Entwickler, Admins und Security Teams, um die eigene Infrastruktur noch effektiver schützen zu können.
