Trust no Origin: CORS-Umgehung im Azure-AKS-Ingress

Hinweis: Dieser Artikel beschreibt eine Schwachstelle, die zum Zeitpunkt der Veröffentlichung noch aktiv ausnutzbar ist. Die Reproduktion der betroffenen Konfiguration und die Verifikation der Schwachstelle wurden gemeinsam mit einem blacklens.io-Partner durchgeführt. Die Schwachstelle wurde im Rahmen eines Responsible-Disclosure-Prozesses zunächst an Microsoft (MSRC) gemeldet, und vor der Veröffentlichung wurde ausreichend Zeit zur Analyse eingeräumt.

Alles begann mit einem routinemäßigen Pentest. Nachdem zahlreiche andere Angriffsvektoren bereits untersucht und ausgeschlossen worden waren, rückte ein bestimmter Teil der Infrastruktur in den Fokus. Was zunächst unscheinbar wirkte, führte schließlich zur Entdeckung einer Schwachstelle – ohne verfügbaren Fix, in einem Produkt, das weiterhin ein weit verbreiteter Infrastrukturbaustein des Internets ist und in unzähligen Unternehmen genutzt wird. Möglicherweise noch für Jahre.

Was ist CORS – und warum ist es wichtig?

CORS (Cross-Origin Resource Sharing) ist ein Sicherheitsmechanismus, der Webservern hilft, den Zugriff auf bestimmte Ressourcen anhand der Herkunft einer Anfrage (des sogenannten Origin-Headers) zu erlauben oder zu verweigern. Diese Ressourcen können auch sensible Daten wie Tokens oder andere Secrets umfassen.

Das Risiko einer CORS-Schwachstelle hängt stark von der jeweiligen Implementierung und Architektur ab. Besonders gefährlich wird es, wenn CORS-Fehlkonfigurationen mit anderen Schwachstellen kombiniert werden – ein Umstand, der häufig unterschätzt wird.

Ein grundlegendes Prinzip sollte daher immer gelten: Sicherheit muss von Grund auf mitgedacht werden. Es ist keine gute Praxis, sich blind auf einzelne Sicherheitsmechanismen zu verlassen.

In einer idealen Welt könnte dieser Artikel an dieser Stelle enden. Leider ist das nicht der Fall.

Schwachstelle im Überblick

Das Verhalten entsteht durch die Art, wie das Azure Application Routing Add-on für Azure Kubernetes Service (AKS) den zugrunde liegenden ingress-nginx Controller konfiguriert und verwendet. Unter bestimmten Bedingungen ermöglicht das eine Umgehung der CORS-Origin-Prüfung. Ursache ist die fehlerhafte Validierung von Origin-Headern durch den verwalteten NGINX Ingress Controller. Moderne Browser behandeln die daraus entstehenden Antworten zum Glück korrekt, was die Schwere deutlich reduziert.

Azure Application Routing

Azure Application Routing stellt einen verwalteten NGINX Ingress Controller für AKS bereit. Wird dort CORS über die standardmäßigen Ingress-Annotations aktiviert, prüft der Controller eingehende Origin-Header, um zu entscheiden, welche Quellen Zugriff erhalten.

Das Problem entsteht, wenn der Origin-Header mehrere Werte enthält oder mehrfach gesetzt wird und die Reihenfolge der Werte passt. In solchen Fällen validiert der Ingress nicht korrekt, sondern reflektiert auch bösartige Origins in der Antwort.

Zunächst das korrekte Verhalten. Ein Angreifer kann beispielsweise eine Anfrage mit folgenden Headern senden:

Bösartige Anfrage – korrektes Verhalten

Der kritische Teil: Wie erwähnt, beeinflusst die Reihenfolge der Origins das Verhalten. Wird zuerst ein legitimer Origin-Wert übermittelt, lehnt der Ingress die Anfrage korrekt ab. Wird jedoch zuerst der bösartige Origin gesetzt und danach ein erlaubter, akzeptiert der Ingress den gesamten Header.

Bösartige Anfrage – falsches Verhalten

Das funktioniert alternativ auch mit zwei getrennt gesetzten Headern. Der Ingress akzeptiert in beiden Fällen die inkorrekte CORS-Anfrage und antwortet mit der geschützten Ressource – im Beispiel einem Secret.

Damit entsteht eine CORS-Antwort, die mehrere Origins enthält und nicht der W3C-Spezifikation entspricht, also nicht „Internet-konform“ ist. Dieses Verhalten deutet auf eine inkonsistente Validierungslogik im verwalteten Ingress hin.

Reale Auswirkung

Im Überblick zeigt der Ingress folgendes Fehlverhalten:

• Mehrere Origins werden reflektiert, auch eingeschleuste.
• Ein einziger eingebetteter vertrauenswürdiger Origin reicht, damit App Routing die ganze Liste akzeptiert.
• Authentifiziertes CORS ist möglich (falls aktiviert).
• Das System unterbindet den Zugriff nicht (in umgekehrter Reihenfolge dagegen korrekt).

Es handelt sich also um einen Fehler in der serverseitigen Validierung.

Während moderne Browser solche Antworten meist blockieren, kann die Schwachstelle in serverseitigen Trust-Modellen, Microservice-Architekturen oder z. B. API-Gateways zu schwerwiegenden Sicherheitsproblemen führen, wenn CORS nicht in einer weiteren Schicht erneut kontrolliert wird oder zusätzliche Sicherheitsmaßnahmen rechtzeitig greifen.

Aus bekannten CORS-Fällen ergeben sich in der Praxis unter anderem folgende Schwachstellen:

• Umgehung Origin-basierter Authentifizierung
• Umgehung von Cross-Tenant- oder Cross-Application-Vertrauensstellungen
• Unautorisierter API-Zugriff
• Token-Diebstahl in internen OAuth- und OIDC-Login-Flows
• Ausweitung von Berechtigungen in Microservice-Architekturen
• Falsche Weiterleitung oder Umgehung von Richtlinien in API-Gateways und Service-Meshes
• Falsche Vertrauensannahmen innerhalb von Unternehmensinfrastrukturen

Wohin es führt, wenn die Rolle von CORS unterschätzt wird, zeigt ein konkretes Azure-Beispiel: Die Schwachstelle EmojiDeploy führte zu Remote Code Execution in Azure-Webdiensten und brachte eine Bounty von 30.000 US-Dollar ein.

Quelle: The Hacker News

Was betroffene Unternehmen tun können

Der zugrunde liegende Ingress-NGINX-Stack erreicht voraussichtlich ab März 2026 schrittweise das Ende seiner Lebensdauer (Ankündigung des Kubernetes-Projekts), und der Azure-Support ist aktuell nur noch bis 30. November 2026 vorgesehen (Azure-Update). Betroffene Unternehmen sollten daher frühzeitig prüfen, ob eine Migration auf einen alternativen, nicht betroffenen Ingress-Stack oder auf die Gateway API sinnvoll ist.

Ein dauerhafter Weiterbetrieb bestehender Deployments ohne Anpassungen kann langfristig erhebliche Risiken bergen. In der Praxis bleiben viele Kubernetes-Cluster jedoch über Jahre auf ältere Komponentenversionen festgelegt (Version Pinning). Implementierungsschwachstellen bestehen dadurch auch lange nach dem offiziellen Support-Ende weiter und werden zu versteckten Risiken.

Unabhängig von dieser konkreten Schwachstelle gilt eine grundsätzliche Sicherheitsregel: Ein einzelner Sicherheitsmechanismus sollte niemals als alleinige Schutzmaßnahme dienen.

Gerade Mechanismen wie CORS werden in der Praxis häufig überschätzt oder falsch eingesetzt. In komplexen Cloud- und Microservice-Architekturen sollten daher immer mehrere Sicherheitsebenen kombiniert werden, beispielsweise:

• zusätzliche serverseitige Validierung von Origin und Access-Control-Allow-Origin
• konsequente Authentifizierung und Autorisierung unabhängig von HTTP-Headern
• zusätzliche Sicherheitskontrollen auf Ebene von API-Gateways oder Service-Meshes

Ob die eigene Infrastruktur oder ein eingesetzter Drittanbieter von solchen Implementierungsfehlern betroffen ist, lässt sich häufig erst durch gezielte Pentests oder Sicherheitsanalysen zuverlässig feststellen.

Wo blacklens.io ansetzt

Mit kontinuierlichem Scanning und optionalem Pentesting-as-a-Service hilft die Plattform, Schwachstellen in interner, externer und Cloud-Infrastruktur frühzeitig zu erkennen.

Ob Active-Directory-Fehlkonfigurationen, die laterale Bewegungen im Netzwerk ermöglichen, Fehlkonfigurationen in Azure und anderen Cloud-Umgebungen oder Schwachstellen in extern erreichbaren Diensten und Webanwendungen: blacklens.io schafft einen Überblick über Ihre gesamte Angriffsfläche und hilft Ihnen, die kritischsten Risiken zuerst zu priorisieren.

„Wir setzen in unseren Software-Lösungen konsequent auf Zero-Trust und etablierte DevSecOps-Methoden – auch wenn dieses Finding bei unseren Kundenlösungen für keine kritische Sicherheitslücke gesorgt hat, zeigt es uns, dass trotz größter Sorgfalt immer wieder externe Faktoren Angriffsfläche bieten können und regelmäßige manuelle Penetration-Tests zur Vermeidung blinder Flecken wichtig sind.“

– Mario te Best, WareTec IT Solutions GmbH

Technische Details

Betroffene Produkte und Konfiguration:

• Azure Kubernetes Service (AKS)
• Azure App Routing Add-on
• Managed NGINX Ingress Controller
• Ingress-Klasse webapprouting.kubernetes.azure.com
• Standardkonfiguration, erstellt wie unten beschrieben

Cluster erstellen

az aks create `
  --resource-group $ResourceGroupName `
  --name $ClusterName `
  --location $Location `
  --enable-app-routing `
  --generate-ssh-keys

Minimale Kubernetes-Konfiguration

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cors
  annotations:
    # Enable CORS
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, PATCH, OPTIONS"
    nginx.ingress.kubernetes.io/cors-allow-origin: "http://trusted-example.com, http://127.0.0.1"
    nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
    nginx.ingress.kubernetes.io/cors-allow-headers: "DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization"
    nginx.ingress.kubernetes.io/cors-expose-headers: "Content-Length,Content-Range"
    nginx.ingress.kubernetes.io/cors-max-age: "1728000"
    # Use custom response
    nginx.ingress.kubernetes.io/configuration-snippet: |
      default_type image/svg+xml;
      return 200 "<svg xmlns=\"http://www.w3.org/2000/svg\" width=\"200\" height=\"200\"><rect width=\"200\" height=\"200\" fill=\"blue\"/><text x=\"50%\" y=\"50%\" text-anchor=\"middle\" fill=\"white\" font-size=\"20\">CORS Test</text></svg>";
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  rules:
    - http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: does-not-exist
                port:
                  number: 3000

Beispielanfrage

Origin: https://attacker.com, http://trusted-example.com

Oder mit zwei getrennt gesetzten Headern:

Origin: https://attacker.com
Origin: http://trusted-example.com

Antwort des Ingress

Access-Control-Allow-Origin: https://attacker.com, http://trusted-example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Headers: DNT,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization
Access-Control-Expose-Headers: Content-Length,Content-Range
Access-Control-Max-Age: 1728000

Ablauf der Meldung an Microsoft

• 2. Dezember 2025: Report beim MSRC eingereicht
• 3. Dezember 2025: MSRC vergibt die Case-Nummer VULN-167454, der Status wechselt auf „Review/Repro“
• 19. Januar 2026: Anfrage zu Triage und Status
• 21. Januar 2026: MSRC teilt mit, dass die Techniker das Verhalten noch nachstellen; Bitte um Informationen zur geplanten Veröffentlichung
• 28. Januar 2026: MSRC über den laufenden Artikelentwurf informiert
• 2. Februar 2026: MSRC bestätigt und gibt die Informationen an die Techniker weiter
• 5. März 2026: Artikel fertiggestellt, MSRC informiert
• 9. März 2026: offizielle öffentliche Bekanntgabe

Referenzen

• PortSwigger: Exploiting CORS misconfigurations for Bitcoins and bounties
• HackerOne-Report 430249
• Identity-Aware-Proxy-Fehlkonfiguration in Google Cloud
• From discovery to exploit: a beginner's guide to CORS bugs

Fazit und Ausblick

Der Fall zeigt exemplarisch, wie selbst kleine Implementierungsdetails in weit verbreiteten Infrastrukturkomponenten zu sicherheitsrelevanten Problemen führen können.

Mit dem absehbaren End-of-Life des Ingress-NGINX Controllers werden viele bestehende Deployments weiter in Betrieb bleiben, obwohl ihre technische Basis nicht mehr aktiv weiterentwickelt wird. Schwachstellen in weltweit eingesetzten Ingress-Stacks können dadurch über Jahre in Produktionsumgebungen bestehen bleiben – und warten nur darauf, in Pentests oder von Angreifern entdeckt zu werden.

Gerade in modernen Cloud-Architekturen gilt deshalb eine einfache Regel: Trust no Origin.