Web-VPN hebelt Sicherheitsmodell der Browser aus
„Clientless SSL VPN“-Produkte zahlreicher Anbieter weisen eine Lücke im Sicherheitsmodell von Browsern auf, durch die sich Cookies und Zugangsdaten stehlen lassen. „Clientless SSL VPNs“ beruhen auf der sicheren Verbindung eines Webbrowsers über das Internet zu einem Webserver im Unternehmen, der diverse Anwendungen anbietet und den Zugriff auf weitere Dienste im Intranet ermöglicht. Da die Lösung keinen extra VPN-Client benötigt, spricht man auch von „Clientless“.
Damit bestimmte Ressourcen von außen per http bzw https verfügbar sind, muss die Web-VPN-Lösung URLs umschreiben, beispielsweise wird https://intranet.example.com/mail.html zu https://webvpnserver/intranet.example.com umgeschrieben. Letzlich beginnen in der Folge alle URLs immer mit der gleichen Domain, egal woher der ausgelieferte Inhalt aus dem Intranet stammt. Auch von den Webanwendungen ausgelieferte Cookies und Referenzen auf Objekte wie document.cookie werden von den VPN-Lösungen umgeschrieben. Damit hebeln die VPN-Produkte aber die „Same Origin Policy“ im Browser aus, wonach Objekte und Skripte keinen Zugriff auf Daten und Objekte haben, die aus anderen Domains geladen wurden. Grundlage dieser Policy ist der Domainname – und der ist wie im Beispiel immer webvpnserver.
Somit könnte ein Angreifer im Intranet eine HTML-Seite aufsetzen, die über das Objekt document.cookie sämtliche Cookies des Opfers ausliest. Allerdings müsste der Angreifer dafür verhindern, dass der VPN-Server dieses Objekt umschreibt. Dazu müsste er das Objekt im Quelltext verschleiern. Mit den Cookies könnte er anschließend alle Verbindungen des Opfers zu Intranetservern übernehmen.
Darüber hinaus soll es möglich sein, mit einem versteckten Frame die Tastatureingaben des Opfers in einem anderen Frame mitzulesen und an den Server des Angreifers zu senden. Besonders brisant wird das Problem, wenn das SSL-VPN nicht nur dem Zugriff aufs Intranet dient und dafür die URLs umschreibt, sondern auch für den Zugriff auf externe Webserver zuständig ist und dafür ebenfalls die Adressen ändert.
Eine Vielzahl an Hersteller sind davon betroffen. Bestätigt wurde das Problem bislang nur für Cisco, Juniper, SafeNet und SonicWall. Nicht betroffen sind unter anderem Extreme Networks, Kerio, McAfee und Novell. Der Rest der Hersteller hat offenkundig noch keine Rückmeldung gegeben. Grundsätzlich gibt es für betroffene Produkte auch keine schnelle Lösung. Der Fehlerbericht führt immerhin einige Workarounds auf, die helfen, das Problem einzudämmen: Administratoren sollten das Umschreiben der URLs nur für vertrauenswürdige Domains erlauben und den Zugriff auf wenige Domains beschränken. Zudem sollte man URL-Verschleierungsfunktionen (URL hiding features) deaktivieren.
siehe auch: https://www.kb.cert.org/vuls/id/261869
