- Session-Hijacking
-
Session Hijacking (auf deutsch etwa: „Entführung einer Kommunikationssitzung“) ist ein Angriff auf eine verbindungsbehaftete Datenkommunikation zwischen zwei Computern. Während die Teilnehmer einer verbindungslosen Kommunikation Nachrichten ohne definierten Bezug zueinander austauschen, wird bei einer verbindungsbehafteten Kommunikation zunächst eine logische Verbindung (Sitzung, engl. Session) aufgebaut. Authentifiziert sich einer der Kommunikationspartner gegenüber dem anderen innerhalb der Sitzung, stellt diese eine Vertrauensstellung dar. Ziel des Angreifers ist es, durch die „Entführung“ dieser Sitzung die Vertrauensstellung auszunutzen, um dieselben Privilegien wie der rechtmäßig authentifizierte Benutzer zu erlangen.
Da die Kommunikation über Computernetzwerke in Schichten unterteilt ist, kann dieser Angriff auf jeder Schicht, die eine verbindungsbehaftete Kommunikation vorsieht, ausgeführt werden.
Session Hijacking ähnelt dem Spoofing-Angriff, allerdings stehen dem Angreifer zu dem Zeitpunkt schon alle notwendigen Informationen zur Verfügung.
Inhaltsverzeichnis
Methoden
Einem Session Hijacking geht zunächst ein passives Sniffing der Datenkommunikation voraus. Dabei sammelt der Angreifer die für den Angriff notwendigen Informationen. Werden diese über unverschlüsselte Protokolle wie HTTP, Telnet, FTP, POP3 usw. ausgetauscht, muss der Angreifer hierzu lediglich entweder direkten Zugriff auf den Physical Layer (Netzwerkkabel, WLAN-Wolke) erlangen oder die Kommunikation durch einen Man-In-The-Middle-Angriff über sich umleiten. Findet die Datenübertragung verschlüsselt statt, muss der Angreifer diese Verschlüsselung zunächst brechen.
Entführung von TCP-Sitzungen
Der rechtmäßige Benutzer baut eine TCP-Verbindung mittels Drei-Wege-Handshake auf. Der Angreifer versucht nach erfolgter Authentifizierung den Dialog zu übernehmen, indem er die Antwort-Pakete (ACK) manipuliert und schneller sendet, als der ursprünglich angesprochene Server oder Client.
Entführung von Web-Sitzungen
Grundsätzlich ist das HTTP ein verbindungsloses/zustandsloses Protokoll, da jede HTTP-Anfrage vom Webserver als neue Verbindung entgegengenommen, abgearbeitet und direkt danach wieder geschlossen wird. Da viele Webanwendungen aber darauf angewiesen sind, ihre Benutzer auch über die Dauer einer solchen Anfrage hinaus zuzuordnen, implementieren sie eine eigene Sitzungsverwaltung. Dazu wird zu Beginn jeder Sitzung eine eindeutige Sitzungs-ID generiert, die der Browser des Benutzers bei allen nachfolgenden Anfragen übermittelt, um sich damit bei dem Server zu identifizieren. Die Sitzungs-ID wird dabei über ein GET- oder POST-Argument oder – wie meistens – über ein Cookie übermittelt. Kann der Angreifer diese Sitzungs-ID mitlesen oder erraten, kann er sich durch das Mitsenden der Sitzungs-ID in eigenen Anfragen als der authentifizierte Benutzer ausgeben und die Sitzung somit übernehmen. Webanwendungen, die zum Ändern des Passwortes nicht das alte Passwort erfordern, begünstigen überdies, dass der legitime Benutzer aus seinem eigenen Zugang ausgesperrt wird (Account Lockout).
Gegenmaßnahmen
Grundsätzlich gibt es zwei Möglichkeiten, Session Hijacking zu verhindern: Erstens, indem man bereits das Ausschnüffeln der notwendigen Informationen durch verschlüsselte Übertragungen unterbindet oder zweitens, indem die Vertrauensstellung nicht auf der schwachen Sicherheit eines Shared-Secrets basiert, man also beispielsweise eine Challenge-Response-Authentifizierung einsetzt. So setzt beispielsweise HTTPS eine Authentifizierung des Servers gegenüber dem Client mittels eines Digitalen Zertifikates voraus und verschlüsselt anschließend die Nutzdaten der Verbindung. Wie bei jedem Einsatz von Kryptografie gilt auch hier: es genügt nicht, dass die Kryptografie in der Theorie sicher ist; auch die tatsächliche Implementierung muss es sein.
Viele Hijacking-Techniken erzeugen Anomalien im Netzwerkverkehr, welche von Intrusion Detection Systemen (IDS) erkannt werden können. Die Erkennung eines solchen Angriffes kann aber immer nur das erste Glied in einer Kette von Gegenmaßnahmen sein.
Web-spezifische Maßnahmen
Es sollte sicher gestellt werden, dass die entsprechende Webanwendung nicht anfällig für Cross-Site Scripting ist, da dies vermutlich eine der Hauptmethoden von Angreifern ist, um per Javascript das Objekt document.cookie auszulesen und somit die Sitzung zu kapern.
Programme
- Ettercap
- Juggernaut
- Hunt
- SMBRelay
Siehe auch
Weblinks
- Web Security Threat Classification (deutsch) PDF 432kb
- Session-Angriffe - eine Analyse (deutsch)
Wikimedia Foundation.
