Check Point Harmony Sase – fremde Cookies naschen

Geschätzte Lesezeit: 3 Minuten

Die technische Abteilung der NetUSE AG identifizierte eine kritische Schwachstelle in Check Point Harmony SASE, die durch unzureichende Domain-Isolierung den Zugriff auf Authentifizierungs-Token ermöglichte. Der Vorfall verdeutlicht die Notwendigkeit strikter Client-Side-Isolation und korrekten Cookie-Scopings in Multi-Tenant-Cloud-Architekturen.

Inhaltsverzeichnis

Im Rahmen einer Sicherheitsanalyse identifizierte das NetUSE Research Team eine kritische Sicherheitslücke in Check Point Harmony SASE, die auf architektonischen Designentscheidungen im Bereich Cookie-Handling beruhte. Die Schwachstelle betraf die SaaS-Lösung Harmony SASE, welche 2023 durch Check Point gekauft wurde. Bei der Integration in das Portfolio von Check Point kam es zu unerwarteten Fehlern, da die kundeneigene Applikationen und herstellerseitige Management-Portale nicht ausreichend voneinander isoliert waren. Das Szenario ermöglichte es potenziell bösartigen Mandanten, Authentifizierungs-Token aus dem Parent-Namespace zu extrahieren, ohne kryptografische Verfahren brechen zu müssen. Mit diesen Token wäre ein weitreichender Zugriff auf weitere Ressourcen bei Check Point, wie z. B. dem Usercenter, möglich gewesen. NetUSE meldete das Problem via Responsible Disclosure Prozess, woraufhin der Hersteller entsprechende Patches zur Wiederherstellung der Integrität implementierte.

Analyse der Harmony SASE Schwachstelle im Detail

Die von NetUSE dokumentierte Harmony SASE Schwachstelle resultierte aus der Nutzung einer gemeinsamen Parent-Domain (checkpoint.com) für sowohl mandantenspezifische Subdomains als auch zentrale Authentifizierungsdienste. Ein Real-World-Beispiel verdeutlicht die Problematik: Eine Kunden-Applikation war unter https://tenant-id.eu.zta-sase.checkpoint.com erreichbar, während kritische Portale wie portal.checkpoint.com oder usercenter.checkpoint.com im gleichen Domain-Scope operierten.

Das Problem war hierbei ist das Fehlen einer strikten Abgrenzung zwischen den verschiedenen Subdomains. Fehlt ein expliziter Eintrag in der Public Suffix List (PSL), betrachten Browser Subdomains als verwandt und erlauben, je nach Konfiguration, den Zugriff auf Cookies, die für die Parent-Domain gesetzt wurden. Im hier geschilderten Fall konnte ein Script auf einer Subdomain auf Cookies zugreifen, die mit dem Attribut Domain=.checkpoint.com gesetzt wurden. Diese Schwachstelle verdeutlicht, dass DNS-Namensräume in Multi-Tenant-Umgebungen als direkte Sicherheitsgrenze betrachtet werden müssen. Als technische Handlungsempfehlung sollten Architekten von SaaS-Plattformen User-Content strikt auf dedizierte Top-Level-Domains (z.B. sase-apps.io statt sase.vendor.com) auslagern oder __Host- Cookie-Präfixe erzwingen, um Scope-Leaking zuverlässig zu verhindern.

Ein Cookie Scoping Fehler tritt auf, wenn Browser-Sicherheitsmechanismen wie die Same-Origin Policy durch zu weit gefasste Domain-Scope-Attribute umgangen werden können. Im vorliegenden Fall nutzte die Architektur die hierarchische Natur des DNS, ohne die Risiken von Untrusted Code auf Subdomains in die Risikobetrachtung einzubeziehen. In diesem Beispiel war es mögich, dass Angreifer ohne Restriktion lesend auf Cookies zugreifen konnten, die für .checkpoint.com gültig waren, anstatt auf die spezifische Subdomain der eigenen SASE-Lösung beschränkt zu sein.

Diese Art von typischer Fehlkonfiguration entsteht oft aus Bequemlichkeit: Entwickler setzen Cookies mit Domain=.example.com, um SSO (Single Sign-On) über mehrere Portale zu erleichtern. Sie übersehen dabei, dass dies auch jede Sicherheitsprüfung für Subdomains aushebelt, die nicht unter ihrer Kontrolle stehen. Dies ist besonders kritisch, wenn der Browser Cookies automatisch an verwandte Domains sendet. Korrektes Cookie Scoping und Einträge in der public_suffix_list.dat sind essenziell, um browserseitiges Leaking über Mandantengrenzen hinweg zu unterbinden. Die technische Handlungsempfehlung umfasst die Implementierung des HttpOnly und Secure Flags in Kombination mit der strikten Vermeidung von Wildcard-Domain-Attributen für Session-Cookies in Shared-Hosting-Umgebungen.

Angriffszenario durch Umgehung der Domain Isolation Browser

Wenn die Domain Isolation Browser-seitig versagt, können Angreifer legitime Funktionen nutzen, um Session Hijacking Angriffe durchzuführen. Die Ausnutzung erfordert hierbei keine Zero-Day-Exploits im Browsercode, sondern basiert auf logischen Fehlern in der Vertrauensstellung der Domains.

Ein mögliches Angriffsmuster für diesen Fall wäre zum Beispiel folgender: Ein Angreifer erstellt eine bösartige „Voucher-App“ oder ein „Rabatt-Portal“ innerhalb seines eigenen SASE-Tenants und verbreitet den Link via Social Engineering an Mitarbeiter anderer Firmen. Das Opfer loggt sich in das vermeintliche Portal ein (authentifizierter Kontext); im Hintergrund exfiltriert die Applikation existierende Session-Cookies des usercenter-Portals. Der Angreifer kann damit auf das Usercenter des Opfers zugreifen. Das Incident Pattern zeigt, dass die Authentifizierung technisch valide ist, der Zugriffskontext jedoch missbraucht wird.

Dieses Angriffszenario zeigt die Gefahr von Logic Bugs, die lediglich Standard-Browserverhalten gegen den Nutzer wenden. Zur Mitigation empfiehlt sich neben der Architekturhärtung der Einsatz von Content Security Policy (CSP) Headern und Referrer-Policies, um ausgehenden Traffic und Datenexfiltration an externe C2-Server zu beschränken.

Zeitachse der gemeldeten Sicherheitslücke

12.05.2025 – Erster Fund der Sicherheitslücke
12.05.2025 – Ticket beim Check Point SASE Support-Team eröffnet
12.05.2025 – Erste Antwort des Check Point SASE Support-Teams: Ablehnung der Existenz der Sicherheitslücke
12.05.2025 – Antwort von NetUSE mit detaillierter Beschreibung des Szenarios
12.05.2025 – Check Point SASE Support-Team antwortet, dass das Problem unter „Social Engineering/Phishing“ falle
12.05.2025 – NetUSE bietet an, einen Proof of Concept (PoC) zu demonstrieren
13.05.2025 – Check Point SASE Support-Team versichert, dass die Anfrage überprüft wird
13.05.2025 – NetUSE‑Geschäftsführung eskaliert das Problem an das Check Point Management-Team
13.05.2025 – Check Point Management‑Team informiert, dass das R&D‑Team den Vorfall prüfen wird
22.07.2025 – Check Point informiert, dass ein Fix in der kommenden H‑SASE Core‑Version geplant ist (Zieltermin: 03.08.2025)
09.09.2025 – Check Point hat die Sicherheitslücke behoben

Fazit und Lessons Learned aus der Offenlegung

Die Analyse demonstriert, dass Sicherheitsgrenzen in der Cloud nicht nur durch Firewalls, sondern maßgeblich durch Browser-Policies und DNS-Strukturen definiert werden. Durch die schnelle Reaktion des Herstellers auf die von NetUSE gemeldete Lücke konnte die Integrität der Plattform ohne bekannte Ausnutzung wiederhergestellt werden. Service Provider und Administratoren müssen Cookie Scoping und Domain-Strukturen als kritische Assets betrachten, die regelmäßigen Audits unterzogen werden müssen. Responsible Disclosure und der ethische Austausch zwischen Sicherheitsforschern und Herstellern bleiben essenzielle Bausteine der IT-Sicherheit, um Logikfehler in komplexen Multi-Cloud-Umgebungen proaktiv zu schließen.

Veröffentlicht am

Veröffentlicht in