Teams Cookie Leak

Im August 2022 wurde eine vermeintliche Sicherheitslücke des Microsoft Teams Client gemeldet, dass Angreifer die Zugangsdaten abgreifen und sich als Anwender anmelden könnten.

Gefunden

Auf die Problematik bin ich selbst aufmerksam geworden, als ich im Rahmen meiner Arbeit zu Teams Client Update auch Zugriffe auf die Datei %appdata%\Microsoft\Teams\cookies gesehen habe.

Ein erster Blick mit Notepad zeigte nicht nur die URLs für Updates, sondern auch den String "Bearer", der bei mir immer die Alarmglocken schrillen lässt.

Solche Tokens können sehr einfach für den Zugriff auf die entsprechenden APIs genutzt werden und sind einige Zeit gültig. Sie sind z.B. wie ein Bahn-Ticket anzusehen, welches aber einfach kopiert werden kann und solange niemand im Backend die Verwendung prüft, können auch verschiedene Personen mit dem gleichen Ticket unterwegs sein. Die Datei lässt sich zudem auch bei einem laufenden Teams/WindowsClient kopieren und berechtigt sind regulär nur der Anwender selbst und natürlich die Administratoren.

Aber eine Malware auf dem PC könnte damit schon diese Datei lesen und die Information "ausleiten".

SQLite Einblick

Der String "SQLite format 3" am Anfang verrät, dass es eine SQLite-Datei ist und dazu gibt es eine Portable-Version von "DB Browser for SQLite (https://sqlitebrowser.org/)" zur Anzeige. Wir finden eine Tabelle mit Spalten wie "host_key", "name", "value" und hier ist unter dem Namen "authtoken" auch das Bearertoken auslesbar.

Ich habe das Token einfach kopiert und mittels https://jwt.io  oder https://jwt.ms decodiert.

{
  "aud": "https://api.spaces.skype.com",
  "iss": "https://sts.windows.net/de21c301-a4xxxxxxxxxx/",
  "iat": 1671662868,
  "nbf": 1671662868,
  "exp": 1671740125,
  "acct": 0,
  "acr": "1",
  "aio": "AUQAu/8TAAAAxxxxxx==",
  "amr": [
    "rsa",
    "mfa"
  ],
  "appid": "1fec8exxxxxxxxxxxx",
  "appidacr": "0",
  "auth_time": 1671643016,
  "cnf": {
    "tbh": "+BA+lyl8JqTxxxxxxxxxxxxx="
  },
  "deviceid": "7e2f367a-7087-43c9-867d-9ea1b71b7709",
  "family_name": "Bearer",
  "given_name": "Coocie",
  "ipaddr": "94.31.88.213",
  "name": "BearerCoockie",
  "oid": "b39bb717-ea64-46cd-ab57-00186effe82c",
  "onprem_sid": "S-1-5-21-11949449-304xxxx17519-xxxx-xxxx",
  "puid": "10033FFF814B5F32",
  "pwd_url": "https://portal.microsoftonline.com/ChangePassword.aspx",
  "rh": "0.xxxxxxxxxxxxx.",
  "scp": "user_impersonation",
  "sid": "af478a06-9069-4b78-xxxxx-xxxxxxx",
  "signin_state": [
    "dvc_mngd",
    "dvc_cmp",
    "dvc_dmjd"
  ],
  "sub": "4TdG2Loakpxxxxxxxxx",
  "tid": "de21c301-xxxxxxxxxxx",
  "unique_name": "bearercookie@msxfaq.net",
  "upn": "bearercookie@msxfaq.net",
  "uti": "DkBJeplNEE2ONL-L6mb6AA",
  "ver": "1.0",
  "wids": [
    "790c1fb9-xxxxxxxxxxxxx",
    "b79fbf4d-xxxxxxxx"
  ],
  "xms_cc": [
    "CP1"
  ],
  "xms_ssm": "1"
}

Es ist also ein Token, welche mir die Rechte zum Zugriff auf "api.spaces.skype.com" mittels "Impersonation" gewährt. Wer immer dieses Token hat, kann sich als die Person ausgeben.

Warum?

Wenn Sie ihren PC neu starten oder Teams neu starten, dann greift es anonym auf https://teams.microsoft.com zu und bekommt eine Umleitung auf den Authentication Service von Microsoft. Nach der Anmeldung per Benutzername/Kennwort, ggfls. MFA und Conditional Access wird ein Ticket ausgestellt und der Client kann weiter arbeiten. Aber was passiert, wenn der Anmeldedienste nicht verfügbar wäre aber das Teams Backend schon? Das ist z.B. am 28. Sep 2020 auch schon mal passiert, dass der Azure Authentifizierungsdienst nicht verfügbar war.

Summary of Impact: Between approximately 21:25 UTC on September 28, 2020 and 00:23 UTC on September 29, 2020, customers may have encountered errors performing authentication operations for all Microsoft and third-party applications and services that depend on Azure Active Directory (Azure AD) for authentication. Applications using Azure AD B2C for authentication were also impacted. Users who were not already authenticated to cloud services using Azure AD were more likely to experience issues and may have seen multiple authentication request failures corresponding to the average availability numbers shown below. These have been aggregated across different customers and workloads.
Europe: 81% success rate for the duration of the incident.
Americas: 17% success rate for the duration of the incident, improving to 37% just before mitigation.
Asia: 72% success rate in the first 120 minutes of the incident. As business-hours peak traffic started, availability dropped to 32% at its lowest.
Australia: 37% success rate for the duration of the incident.
Quelle: RCA - Authentication errors across multiple Microsoft services and Azure Active Directory integrated applications (Tracking ID SM79-F88) https://status.azure.com/en-us/status/history/

Es kann also schon durchaus passieren und hier steht auch, dass nur Neuanmeldungen das Problem waren. Wer schon ein "Ticket" hatte, konnte entsprechend weiter arbeiten. Wenn ein Ticket aber z.B. 6h oder 24h Gültigkeit hat, dann kann man als Entwickler natürlich auf die Idee kommen, das Ticket lokale zu "cachen", um nach einem Neustarte der Applikation das frühere Ticket weiter zu verwenden, solange es noch gültig ist. Der Start ist schneller, da der Umweg über den Authentication Service wegfällt und der Benutzer muss sich auch nicht mehr erneut anmelden. Das Vorhalten des Ticket im RAM des Browsers oder der App reicht dazu nicht aus.

Das dürfte ein Grund sein, warum Microsoft das Ticket und andere Informationen auf dem Client als Datei abgelegt hat.

Und im Browser?

Die diversen Ratschläge in den unten verlinkten Artikeln raten dazu, statt der Teams Windows App einfach Teams im Browser zu starten. Das ist technisch problemlos möglich aber einige Funktionen sind im Browser leider nicht nutzbar wie z.B. Direct Routing und Media Bypass, Call Queues in Kanälen, VDI auf TerminalServer etc. Aber warum sollte sich ein Browser hinsichtlich der Speicherung von Cookies anders verhalten?. Einmal F12 gedrückt und unter "Application" die Cookies angezeigt und schon habe ich auch hier Zugriff auf das "authtoken"

Da sind die Ratschläge wohl etwas zu kurz gesprungen, denn auch hier speichert natürlich der Browser das AuthToken und es ist kein Problem, diese Daten als authentifizierter Benutzer auch auszulesen. Es gibt jede Menge Tools genau dies zu erreichen und wenn ein Schad-Code als "Benutzer" ausgeführt wird, liegen die Daten offen und Beispiele sind sogar von Microsoft dokumentiert:

Fremdverwendung

Natürlich habe ich das Token mal in eine Datei gespeichert und per PowerShell eine API aufgerufen und per Graph dann einen Zugriff auf die verschiedenen APIs versucht. Wie nicht anders zu erwarten, hat mit die Cloud natürlich geantwortet. Sie konnte ja auch nicht unterscheiden, ob das nun mein PowerShell-Skript oder ein JavaScript gewesen ist.

Einschätzung

Nun muss man natürlich wissen, dass die Firma "vectra" eine Software entwickelt, die Einbrüche erkennen und Sicherheit erhöhen soll und damit ein Interesse an einer möglichst breiten Veröffentlichung hat. Daher ist auch zu erklären, dass sie sehr viele Gazetten solche einen Aufmacher gerne übernommen haben, zumal Microsoft Teams ist ja auch das Flaggschiff ist und eine echte schwere Lücke bringt viel Sichtbarkeit und damit Werbe-Klicks.

Natürlich ist es unschön, wenn Zugangsdaten auf einem PC so vorliegen, dass ein berechtigter Benutzerkreis darauf zugreifen kann. Da ist es auch nur ein schwacher Trost, dass so ein Ticket nur eine begrenzte Zeit gültig ist. Auf der anderen Seite sollten Sie wissen, dass ein externer oder fremder Zugriff auf diese Datei nur durch einen Administrator oder ein anderes vom Anwender gestartetes Programm oder eine generelle Sicherheitslücke im Betriebssystem möglich wäre.

Sollte mein Client aber dahingehend schon so kompromittiert sein, dass jemand unter meinem Namen ein Programm starten kann, dann gibt es viel interessantere Ziele und Möglichkeiten, z.B. sich im LAN weiter umzuschauen, sich Kerberos-Tickets oder NTLM-Hashes für andere Server zu beschaffen oder sogar eine Rechteausweitung zu erreichen. Der eingeschränkte Zugriff als Benutzer auf die APIs ist natürlich ein Problem und so könnte eine Chat-Nachricht an andere Personen eine Phishing-Möglichkeit sein aber das ist kein grundlegendes Problem von Microsoft Teams.

Die Empfehlung nur noch per Browser auf Teams zuzugreifen ist zu kurz gesprungen, denn natürlich kann auch ein Browser "ferngesteuert" werden. Die meisten Menschen haben im Browser wissentlich oder unwissentlich verschiedene AddOns (AD-Blocker, Password Speicher etc.), die auch den kompletten entschlüsselten Datenstrom lesen und abgreifen könnten.

Das Risiko ist aus meiner Sicht nicht so groß, wie es anfangs ausgesehen hat und vielleicht erklärt dies auch die Reaktion von Microsoft, dass dies nicht "kritisch" genug ist, um es umgehend zu fixen oder als CVE zu listen.

"This attack does not require special permissions or advanced malware to get away with major internal damage,"
Quelle: Connor Peoples

Es wäre sicher einfach für Microsoft diese Tokens erst einmal ohne Datenbank zu arbeiten sondern die Daten nur im RAM zu halten und hier vielleicht noch unkenntlich zu machen. Verschlüsseln geht leider nicht so einfach, weil der ganze Code ja eh "JavaScript" ist und dieser im Chromium-Debugger einfach einzusehen ist.

Und dann mal ehrlich: Viele Menschen speichern ihre Kennworte im Browser oder Windows Tresor, wo doch auch klar ist, dass diese einfach ausgelesen werden können!

Ich habe in den Links verschiedene Quellen angegeben, die dieses "Problem" teils sehr reißerisch beschreiben aber im Grunde alle nur voneinander abgeschrieben haben. Viele Artikel sind sich doch sehr ähnlich.

Weitere Links