Session Cookie Security

Auf dieser Seite beschreibe ich einen Angriffsvektor, der einem Angreifer die Übernahme einer Sitzung erlaubt und gegen den selbst Multifaktor-Authentifizierung wirkungslos ist.

Anmeldung und Sitzung

Historisch kennen wir alle das Vorgehen, dass wir zum Zugriff auf einen Service und mit einem Benutzernamen und einen Kennwort anmelden müssen. Mittlerweile ist klar, dass dies allein nicht mehr sicher genug ist und weitere Faktoren, z.B. Fido2, SMS, etc. zur Absicherung erfolgen. Für die weitere Betrachtung ist es auch nicht wichtig zu unterscheiden, ob Sie ihre Anmeldedaten direkt an den Dienst senden oder z.B. per OAUTH/Federation erst zu einem Authentication Server gesendet werden, der ihnen ein Service-Ticket ausstellt und sie damit auf den eigentlichen Dienst zugreifen. Wir nehmen nun an, dass Sie erfolgreich angemeldet sind.

Nun ist es aber so, dass ein Client ja nicht nur eine Verbindung sondern z.B. mehrere Verbindungen in unterschiedlichen Fenstern öffnen kann. Auch könnte sich die IP-Adresse des Clients ändern oder sie verlieren mal kurz die Netzwerkverbindungen im WLAN und kommen wieder zurück. Natürlich erwarten sie zurecht, dass Sie sich nicht immer neu anmelden müssen. Und dazu gibt es nun mehrere Optionen, wie ein Entwickler dies umsetzen kann.

  • Authentifizierung im Browser
    Wenn Sie sich z.B. bei einer Webseite mit dem Webbrowser klassisch anmelden, dann hat ihr Webbrowser ihre Kennwort Daten und kann diese mit jedem Request als "Authentication Header" mitsenden. Dies war früher durchaus üblich aber jedes mal musste der Webserver dann natürlich die Authentifizierung durchführen und wenn jemand als "Man in the Middle" mitliest, kann er vielleicht die nativen Zugangsdaten auslesen. Daher möchte man das eigentlich nicht mehr. Zudem ist ein richtiges "Abmelden" an einer Webseite damit nicht einfach, da die meisten Browser die einmal eingegebenen Credentials erst vergessen, wenn sie geschlossen werden. Ein Druck auf "zurück" bringt sie also wieder als angemeldeten Benutzer zurück.
  • Cookie
    Daher gab und gibt es da gängige Verfahren, dass der Webserver nach der einmal erfolgen Anmeldung dem Client einen "Session-Cookie" übergibt. Der Browser sendet diesen Cookie mit jeden Request wieder an den Server, der den Inhalt versteht. Cookies können für vielerlei Zwecke eingesetzt werden und ein Grund könnte die Speicherung der Identitäten und einer Session sein. Idealerweise wird der Cookie noch etwas "verschlüsselt" und mit einer Gültigkeitsdauer versehen. Mit einem Druck auf "Abmelden", kann der Webserver den Cookie beim Client löschen lassen und bei sich aus dem Speicher entfernen.
  • Bearer-Token
    Durch den Einsatz von OAUTH hat sich das Anmeldeverfahren "Bearer" durchgesetzt, bei dem ein Authentifizierungsdienst eine kryptografisch gesicherte Information an den Client ausliefert, die neben der Identität des Anwender auch dessen Berechtigungen oder Rollen und natürlich einen Gültigkeitszeitraum enthält. Auch dieses Token kann der Client mit jeden Request an den Server senden, der lokal direkt die Gültigkeit prüfen und von den Inhalten die Berechtigungen ableiten. Meist kommen hier sogar zwei oder mehr Tokens zum Einsatz. Ein Ticket zum Anfordern von Service Tokens und dann das Service Token selbst.
  • Gespeicherte Kennworte
    Zuletzt gibt es natürlich noch die Kennwortspeicher im Betriebssystem, im Browser oder speziellen Passwordspeicher-Apps, die Formulare auf Webseiten automatisch mit Benutzernamen und Kennworten ausfüllen.

Ich gehe weiter unten noch darauf ein, welche Dienste mit welchen Verfahren arbeiten.

Risiko

Das Risiko besteht nun darin, dass eine Malware auf dem Computer gezielt nach diesen Informationen Ausschau hält und diese dann "ausleitet". Da solcher Code sich selbst ja nicht "verteilt" oder Dateien verschlüsselt oder sonst groß auffällt, kann er oft nur sehr mühsam erkannt werden. Klassische Virenscanner tun sich naturgemäß damit eher schwer. Hinzu kommt, dass viele Benutzer ja sogar selbst solche Programme unbedarft installieren, weil Sie sich einen anderen Mehrwert erwarten.

  • Alternative Browser und Quellen
    Wir kennen alle Edge, Chrome und Firefox. Es gibt aber noch jede menge andere Browser wie Opera, Brave Maxthon etc., die oft auch die Chromium-Engine nutzen oder ein Aufsatz eines bestehenden Browsers sind. Dabei wird gerne übersehe, dass dieser Code die komplette Kommunikation natürlich einsehen kann. Schließlich ist er für die Anzeige der Ausgaben und Eingaben des Benutzers zuständig. Wir müssen daher schon ein Stück weit "vertrauen". Das gilt insbesondere für alternative Download-Quelle, von denen es immer wieder welche gibt und nur vorgeben, das Original zu sein.
  • Browser PlugIns
    Ich nutze selbst auch die ein oder anderen Plugins im Browser aber diese haben fast alle gemein, dass Sie sich umfangreiche Rechte einräumen, um z.B. Cookies, JavaScript, Werbung etc. zu optimieren oder gleich weg zu filtern. Technisch verändern Sie dazu die vom Webserver gelieferte Webseite und entfernen Teile davon. Das geht nur, wenn Sie die Rohdaten nicht nur einsehen sondern auch ändern können. Also kommen die meisten Plugins auch an Cookies und Bearer-Token heran. Andere AddOns nutzen z.B.: die Funktion, sich als HTTPProxy dazwischen zu schalten, um die Daten dann über einen VPN-Provider oder Tor-Knoten zu routen. Das ist nicht grundsätzlich falsch aber soll Sie für die Risiken sensibilisieren.
  • Klassische Malware
    Natürlich kann auch eine Malware sich an einen bestehenden Prozess "anheften" von quasi von außen den Browser steuern und die Daten mitlesen. Übrigens gibt es diese Tickets natürlich auch bei Windows in Form von "Kerberos Tickets". Auch diese nimmt eine Malware gerne.
  • "Modern Apps"
    Eine besondere Problematik können moderne Apps sein, die als JavaScript im Browser ausgeführt werden, z.B. Teams aber auch viele andere Apps. Diese benötigen ein OAuth-Token, welches sie im Auftrag des Anwender anfordern und ggfls. muss, der Benutzer seine Zustimmung (Consent) erteilen, wenn der Administrator die App nicht pauschal zugelassen hat. Sie vertrauen dann schon der App, dass Sie das Token nicht zum "Hersteller" ausleitet, der dann auch ohne Mithilfe des Anwenders auf die Daten gemäß der Zustimmung zugreifen kann. Daher ist es ja wichtig, dass Sie als Anwender nicht jeder App blind vertrauen oder der Administrator die "User kann Consent erteilen"-Funktion möglichst deaktiviert.

Wenn eine Software dann einmal den Zugriff auf die entsprechende Information hat, dann wartet sie einfach darauf bis der Anwender sich an den entsprechenden Diensten angemeldet hat. Der Anwender kann dabei sein Konto und seinen Zugang durchaus über weitere Faktoren (2FA/MFA) abgesichert haben. Der Schadode kann natürlich das eingegeben Kennwort auch ausleiten. Vielleicht ist der Anwender ja so unvorsichtig, und nutzt das gleiche Kennwort auch bei anderen Diensten ohne 2FA. Ansonsten leitet die Software nach der Anmeldung das Bearer-Token bzw. den Session Cookie aus.

Cookie und 2FA, Fido, Kennwortsafe ua.

Wenn Sie nun glauben, dass sie mit Multifaktor-Authentifizierung oder Conditional Access auf der sicheren Seite sind, dann muss ich sie leider enttäuschen. Es sind gerade diese Cookies oder Session-Tickets, die eine Nutzung für den Anwender nach der erfolgten 2FA-Anmeldung vereinfachen. Starten Sie z.B. OWA im Browser oder Outlook oder OneDrive, Microsoft Teams o..ä. und legen Sie dann ihren PC schlafen und wecken Sie ihn einige Zeit später z.B. in einem anderen Netzwerk wieder auf. Sehr oft bekommen Sie keine erneute Anmeldungsabfrage, da die Authentifizierungsinformationen immer noch gültig sind und sogar der Wechsel einer IP-Adresse das Ticket per Se erst einmal nicht ungültig macht. Wenn ein Angreifer ihnen aus einer laufenden Sitzung das Ticket "kopiert", dann kann umgeht er 2FA.

Es wird sogar noch schlimmer, denn Sie können bei der Anmeldung per 2FA bei der ein oder anderen Plattform sogar ankreuze, dass dieser PC oder dieser Browser "vertrauenswürdig" ist und daher zukünftig eine 2FA-Anfrage seltener oder gar nicht mehr angefordert werden soll. Auch diese Information muss ja auf dem Endgerät irgendwie gespeichert werden. Damit ist auch klar, dass ein Angreifer dieses Kennzeichen gerne kopieren möchte.

Ich bin mit sehr sicher, dass Malware auch schon ihre Kennwortdatenbanken von KeePass, BItwarden, 1pass u.a. "auf Vorrat" kopiert für denn Fall, dass ihr Kennwort später doch mal bekannt wird oder eine Lücke in der Software bekannt wird. Auch die Browser-Addons, die für Sie das Kennwort "eintippen" werden sicher schon analysiert.

Ein ein Angreifer nach einer 2FA die Authentication-Information kopieren kann, hat er die gleichen Berechtigungen.

Erweiterter Schutz

Mit einer gestohlenen Authentication-Information kann der Angreifer nun auf die gleichen Dienste zugreifen, auf die auch der legitime Benutzer zugreift. Allerdings wird er dazu eher nicht auch den gleichen Computer nutzen. Das kann sich nun der Service zu nutze machen und z.B. die Source-IP-Adresse des Clients mit berücksichtigen. Allerdings muss der Service hier wieder ein Overblocking verhindern, denn ein Client kann ja durchaus auch die IP-Adresse wechseln. Dies ist insbesondere bei Smartphone der Fall, wenn diese zwischen dem WLAN zuhause und dem 4G/5G Internet im Garten wechseln. Hier jedes Mal eine Authentifizierung zu verlangen, würde die Akzeptanz sinken lassen.

Es gibt mittlerweile aber auch immer mehr lokale Schutzlösungen und Virenscanner, die genau dieses Verhalten einer Malware erkennen sollen. Der Zugriff auf solche Browser-Dateien durch fremde Prozesse oder wenn ein DUMP eines Speichers abgezogen wird, sind untrügliche Zeichen für unerwünschte Aktivitäten.

Auf jeden Fall sollte ein Service bei besonderen Aktionen, z.B. Ändern der Stammdaten, Zustelladresse, 2FA-Tokens oder Auslösen einer Bestellung noch einmal sicherstellen, dass die Aktion wirklich vom regulären Anwender und nicht einem Angreifer durchgeführt wird.

Ich gehe nun nicht weiter auf den Code ein, wie ich in einem Browser oder Desktop diese schützenswerte Information auslesen kann. Der Code muss einfach wissen, wo der Browser oder fragliche Software diese Informationen vorhält. Ungeschützte Dateien können einfach gelesen werden und auch der Hauptspeicher ist nicht gegen einen "Dump" gefeit. Dies betrifft übrigens auch Kennwort-Archive

Beispiel Microsoft 365 Portal

Auch ohne ein Hacker sein zu wollen, können Sie heute bei jedem Browser mit "F12" die Debuggertools wechseln und den Speicher der Session inspizieren oder den Netzwerkverkehr mitschneiden. Die Daten kann auch ein Browser AddOn abgreifen und wer den Proxy umstellen kann, kann auch mit Fiddler, CharlesProxy o.a. die Daten mitschneiden. Im F12 Debugger sehe ich beim einem Zugriff auf eines der Microsoft Portale sehr schön ein paar interessante Cookies.

Die Cookies "x-ms-RefreshTokenCredential" und "x-ms-RefreshTokenCredential1" starten mit der für ein OAUTH Token typisches "eyJ" und können z.B. auf https://jwt.io decodiert werden. Aber für einen Angriff wichtiger ist das Cookie "ESTSAUTHPERISTENT". Wenn ein Angreifer diesen Cookie extrahieren und in eine eigene Session einbinden kann, dann kann Azure dies nicht unterscheiden.

Attack Tutorial: Pass the Cookie
https://www.youtube.com/watch?v=MDiwkAZ-854

Wenn ich mit die Netzwerkanmeldung anschaue, dann sehe ich auch die Übersendung eines "Bearer-Token", welches ebenfalls "mitgeschnitten" und decodiert werden kann.

Das per https://jwt.io  decodierte Token zeigt hier nur ein relativ ungefährliches "User-Read"-Recht an.

Aber an anderer Stelle gibt es durchaus Tokens mit einem "Impersonate" oder anderen Berechtigungen. Schließlich war ich hier als Global Admin an meinem Developer Tenant angemeldet und könnte alle Einstellungen ändern. All diese Informationen kann eine Malware problemlos mitschneiden und hier schützt auch 2FA nicht, denn die Anmeldung per App, FIDO2 o.ä. ist davor erfolgt. Sie können sogar ihr Kennwort ändern ohne, dass das Ticket sofort ungültig wird.

Sie haben sicher auch schon das folgende Fenster gesehen:

Wenn Sie hier "ja" auswählen, dann speichert Microsoft auf ihrem Client als Cookie die Einstellung und wenn Sie den Browser schließen und neu öffnen, sind sie weiter angemeldet. Das ist bequem aber unsicher, denn ihnen sollte schon klar sein, dass die erforderlichen Zugangsdaten "irgendwo" in ihrem Benutzerprofil gespeichert sind.

YouTube

Wenn sie glauben, das dies vielleicht etwas weit hergeholt ist, dann schauen Sie sich einfach das ein oder andere YouTube-Video und weitere dann vorgeschlagene Videos an.

Attack Tutorial: Pass the Cookie
https://www.youtube.com/watch?v=MDiwkAZ-854
Cookie aus Chrome exportieren und in anderem Client und Browser

Attack Tutorial: How the Kerberoasting Attack Works
https://www.youtube.com/watch?v=u6GwzBps6Lo
Kerberos-Ticket mit Mimikatz extrahieren und passendes Kennwort ermitteln.

Linus Tech Tips: My Channel Was Deleted Last Night
https://www.youtube.com/watch?v=yGXaAWbzl5A
Bericht eines bekannten YouTube Autors, wie dessen Kanal "übernommen" wurde.

Lösung?

Sie können gerne ihr Konto und Adminkonten mit 2FA u.a. Verfahren absichern und sie sollten das auch tun. Aber nach der erfolgreichen Anmeldung muss der Schutz des Systems, auf dem sie arbeiten, ihr Ziel sein. Niemand sollte eben diese Cookies oder andere Tokens mitlesen, ersetzen oder ihre Sitzung kapern können. Aktuelles Windows, Virenscanner die auch solche Spionageprogramme erkennen oder Applocker zur Beschränkung der ausführbaren Programmen. Letztlich sollten Sie Systeme, auf denen Sie sich als Administrator anmelden, besonders schützen. Einige Überlegungen habe ich auf PAW – Priviledged Admin Workstation beschrieben.

Weitere Links