Mit Cisco bestätigt erstmals ein großer Hersteller von IPsec-Lösungen mit XAUTH-Erweiterung, daß diese Protokollerweiterung in vielen Anwendungen unsicher ist.

Betroffene Systeme

• Cisco VPN Concentrator
• weitere IPsec-Gateways anderer Hersteller, die ebenfalls XAUTH implementieren

Einfallstor
Manipulation von IKE-Paketen (UDP-Port 500)

Auswirkung
Ein Angreifer, der daß XAUTH-Gruppenpaßwort aus Phase 1 kennt, kann sich selbst als VPN-Gateway ausgeben. Mittelbar ist so möglich, Paßworte anderer Nutzer zu erhalten und IPsec-Verbindungen zu entschlüsseln und mitzuschneiden.
(authentication data compromise)

Typ der Verwundbarkeit
design flaw

Gefahrenpotential
sehr hoch (Versagen einer Sicherheitskomponente)
(Hinweise zur Einstufung des Gefahrenpotentials.)

Kontext
XAUTH ist eine Erweiterung des Internet Key Exchange von IPsec, um Nutzer anhand eines Paßwortes an einem VPN-Gateway zu authentifizieren. In einer weitverbreiteten XAUTH-Variante wird das VPN-Gateway selbst über ein Gruppenpaßwort authentifiziert, welches allen Gateway-Benutzern bekannt ist.

Neben XAUTH gibt es auch die Standardverfahren für Authentifizierung (benutzerspezifische Preshared Keys, Zertifikate). Sie sind von der hier beschriebenen Problematik nicht betroffen.

Beschreibung
Da das Gruppenpaßwort zwangsläufig allen Gateway-Benutzern bekannt ist, kann jeder Benutzer das Gateway selbst impersonifizieren. Häufig wird das Gruppenpaßwort auch weltweit veröffentlicht, so daß auch jemand, der nicht Benutzer ist, Kenntnis von ihm erlangen kann. Wenn zusätzlich noch eine Möglichkeit besteht, den Verkehr zum VPN-Gateway auf ein eigenes System umzuleiten, kann ein Angreifer mit dem bekannten Gruppenpaßwort sich gegenüber VPN-Benutzern als Gateway ausgeben. Dadurch ist es mittelbar möglich, deren Paßwörter zu erlangen und den IPsec-Verkehr unverschlüsselt mitzuschneiden. Das Opfer merkt von diesen Angriffen nichts, wenn sie sorgfältig genug durchgeführt werden.

Insbesondere wenn IPsec mit XAUTH zur Absicherung eines WLANs eingesetzt wird, ist das beschriebene Angriffsszenario äußerst relevant. Besonders kritisch wird das Problem, wenn die Paßwort-Datenbank, die für XAUTH eingesetzt wird, auch für andere Dienste genutzt wird (Rechnerpool-Logins, Mail-Paßwort usw.). In diesem Fall kann ein Angreifer zusätzliche Privilegien erlangen.

Diese Design-Schwäche ist seit über vier Jahren in der IPsec-Gemeinde bekannt. Sie verhinderte damals die Standardisierung von XAUTH im Rahmen der IETF. Dies hielt jedoch einige Hersteller (zunächst vor allem Cisco) nicht davon ab, auf XAUTH basierende Produkte zu vertreiben und XAUTH auch für den Einsatz in besonders gefährdeten Umgebungen (wie WLANs) ausdrücklich zu empfehlen.

Die XAUTH-Problematik ist Cisco seit spätestens April 2003 bekannt. Damals stellte Cisco die Art und Bedeutung des Problems allerdings sehr schwer verständlich dar. Im Dezember 2003 wurde von Cisco erstmals das Vorhandensein eines prinzipiellen Problems bestätigt, das aber immer noch nicht als Design-Schwäche in den eigenen Produkten verstanden wurde:

Issue #2: This is a widely known common aspect of the Pre Shared Keys (PSK) authentication mechanism since 1999. With PSK, there is no way for a client to identify what is on the other side of the connection except that the other side has the same PSK.

The use of Digital Certificates as part of PKI for authentication or per user PSK are the only current solution to this aspect of using PSKs. It is a choice which network administrators must make between ease of use versus stronger security.

Auch im Dezember 2003 wurde kein Advisory veröffentlicht. Dies geschieht erst jetzt (April 2004). Gegenmaßnahmen werden derzeit von Cisco nicht angeboten.

XAUTH mit benutzerspezifischen Preshared Keys oder Zertifikaten ist von der Schwachstelle in XAUTH nicht betroffen.

Workaround

• Ein Verzicht von XAUTH, wie von Cisco nahegelegt, ist vermutlich in in vielen Fällen nicht praktikabel. XAUTH ist bei vielen Installationen ein wesentliches Argument für eine IPsec-Lösung von Cisco, gerade weil der Aufwand zum Betrieb einer CA zu hoch erscheint.
• Um die Auswirkung von Paßwort-Lecks zu mindern, sollten für XAUTH getrennte Paßwörter eingesetzt werden.
• Karl Gaissmaier von der Universität Ulm stellt eine Anleitung zur Verfügung, wie das Gruppenpaßwort von XAUTH durch eine Mini-CA ersetzt werden kann (die lediglich zwei Zertifkate ausstellt und keine benutzerspezifischen Zertifikate). Dieser Lösungsansatz muß sich jedoch noch in der Praxis bewähren, insbesondere da dieser Betriebsmodus nicht von Cisco vorgesehen ist.

Gegenmaßnahmen
Derzeit (2004-04-15) gibt es laut Cisco keine Gegenmaßnahmen für diese Schwachstelle.

Credits
Karl Gaissmaier von der Universität Ulm hat dieses Problem ausführlich untersucht und mit Cisco diskutiert. Das RUS-CERT dankt ihm an dieser Stelle ausdrücklich, sein Einsatz hat dazu geführt, daß diese Schwachstelle von Cisco nun entsprechend dokumentiert wird.

Weitere Information zu diesem Thema

• Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets (John Pliam, Oktober 1999)
• Cisco Response to Internet Key Exchange Issue (Cisco, April 2003)
• Multiple vulnerabilites in vendor IKE implementations, including Cisco (Thor Lancelot Simon, Dezember 2003 via BUGTRAQ)
• Re: Multiple vulnerabilites in vendor IKE implementations, including Cisco (Cisco, Dezember 2003 via BUGTRAQ)

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/