Übersicht
Im August 2022 identifizierte das Vectra-Team eine Post-Exploitation-Möglichkeit, die es böswilligen Akteuren mit ausreichendem lokalen oder entfernten Dateisystemzugriff ermöglicht, gültige Benutzeranmeldedaten von Microsoft Teams zu stehlen, da diese im Klartext auf der Festplatte gespeichert sind. Es wurde festgestellt, dass diese Klartext-Anmeldedatenverwaltung alle kommerziellen und GCC Desktop Teams-Clients für Windows, Mac und Linux betrifft.
Während das Sammeln von Anmeldedaten aus dem Speicher ein üblicher Schritt nach einem Angriff ist, glauben wir, dass die Senkung der Hürde für das Sammeln von Anmeldedaten auf einen einfachen Lesezugriff auf das Dateisystem die Möglichkeiten für einen Angreifer erweitert, seine Aufgabe vereinfacht und besonders interessant ist, wenn gestohlene Anmeldedaten die Möglichkeit bieten, den Benutzerzugriff ohne die sonst lästigen Hindernisse der Multi-Faktor-Authentifizierung (MFA) zu erhalten.
Mit diesen Token können Angreifer die Identität des Token-Inhabers für alle Aktionen annehmen, die über den Microsoft Teams-Client möglich sind, einschließlich der Verwendung dieses Tokens für den Zugriff auf Microsoft Graph API-Funktionen vom System eines Angreifers aus. Darüber hinaus sind diese Token auch für MFA-aktivierte Konten gültig, wodurch MFA-Prüfungen während der laufenden Nutzung umgangen werden können.
Microsoft ist sich dieses Problems bewusst, gab aber an, dass es nicht die Kriterien für eine sofortige Behebung erfüllt. Bis Microsoft die Teams-Desktop-Anwendung aktualisiert, sollten sich Kunden der Risiken bewusst sein, die mit der Speicherung von Klartext-Token verbunden sind, und dieses Risiko mindern, indem sie die Überwachung auf ungewöhnliche Dateizugriffe oder Änderungen an Dateisystem-ACLs einrichten.
Die Entstehungsgeschichte der Jagd
Die Untersuchung begann, als sich ein Vectra-Kunde darüber beschwerte, wie Microsoft Teams deaktivierte Identitäten verwaltet. Endbenutzer können deaktivierte Konten nicht über die Benutzeroberfläche entfernen, da die Teams-Anwendung erfordert, dass das Konto angemeldet ist, um es aus dem Client zu entfernen. Natürlich können Benutzer dies nicht tun, wenn ihr Benutzerkonto deaktiviert ist. Um dieses Problem zu lösen, haben wir uns die lokalen Konfigurationsdaten innerhalb des Teams-Clients angesehen und herausgefunden, wie sie funktionieren.
Electron - ein Sicherheitsnegativ
Microsoft Teams ist eine Electron-basierte Anwendung. Mit Electron wird eine Webanwendung erstellt, die über einen angepassten Browser ausgeführt wird. Dies ist sehr praktisch und macht die Entwicklung schnell und einfach. Die Ausführung eines Webbrowsers im Kontext einer Anwendung erfordert jedoch herkömmliche Browserdaten wie Cookies, Sitzungszeichenfolgen und Protokolle.
Hier liegt die Wurzel des Problems, denn Electron unterstützt keine Standard-Browserkontrollen wie Verschlüsselung, und systemgeschützte Dateispeicherorte werden von Electron nicht standardmäßig unterstützt, sondern müssen effektiv verwaltet werden, um sicher zu bleiben. Daher bietet die Funktionsweise von Electron standardmäßig Anreize für die Erstellung übermäßig transparenter Anwendungen. Da Electron die Komplexität der Anwendungserstellung verschleiert, kann man davon ausgehen, dass sich einige Entwickler der Auswirkungen ihrer Designentscheidungen nicht bewusst sind, und es ist üblich, dass Forscher, die sich mit der Sicherheit von Anwendungen befassen, die Verwendung dieses Frameworks aufgrund kritischer Sicherheitsmängel beklagen.
Eintauchen in die Struktur
Wir begannen damit, Methoden zu erforschen, um alle Verweise auf das/die angemeldete(n) Konto/Konten zu löschen. Unser Ziel war es, die alten Konten zu entfernen und Teams zu zwingen, so zu arbeiten, als wären sie nicht mehr vorhanden. Mehrere Versuche, die Konfigurationsdatei und die Erstausführungsdateien zu ändern, blieben erfolglos. Wir suchten nach dem bekannten Hauptbenutzernamen und erhielten zwei wichtige Dateien.
Die erste wichtige Datei war eine ldb-Datei mit Zugriffstoken im Klartext. Bei der Überprüfung wurde festgestellt, dass diese Zugriffstoken aktiv waren und nicht versehentlich von einem früheren Fehler stammten. Diese Zugriffstoken ermöglichten uns den Zugriff auf die Outlook- und Skype-APIs. Es ist wichtig zu wissen, dass die Microsoft Teams-Architektur ein Konglomerat aus einer Vielzahl von M365-Diensten ist, die auf Skype, SharePoint und Outlook angewiesen sind, um zu funktionieren - dies erklärt das Vorhandensein dieser Token.
Die nächste Datei ist eine Browser-Cookie-Datenbank wie die "Cookies", denen wir auf jeder Website zustimmen (danke, GDPR). Cookies speichern Daten wie Sitzungsinformationen, Marketing-Tags, Kontoinformationen und in einigen Fällen Zugriffstoken. (Un)glücklicherweise speichert die Teams Desktop-Anwendung die Token auch hier.
Der beste Weg, die Cookie-DB zu lesen, ist die Verwendung eines sqlite3-Datenbankclients. Mit diesem Client können wir nur die Werte extrahieren, die wir benötigen. Die folgende Abfrage gibt den Namen des Tokens und den Wert des Tokens zurück.
Wir haben jedes Token mit dem Microsoft jwt-Validierungsdienst https://jwt.ms überprüft. Jedes gefundene Token war aktiv und funktionierte, ohne dass eine zusätzliche Authentifizierung erforderlich war. Es wurde uns klar, dass das anfängliche Problem, Teams neu installieren zu müssen, ein viel kleineres Problem war als die Möglichkeit des Identitätsmissbrauchs, die sich im Microsoft Teams-Client abzeichnete.
Lasst uns etwas tun
Mit diesem Wissen machte sich das Team an die Arbeit und begann mit der Entwicklung von Werkzeugen, die diese ungeschützten Anmeldeinformationen ausnutzen. Nachdem wir mehrere Optionen in Betracht gezogen hatten, kamen wir zu dem Schluss, dass das Senden einer Nachricht an das Konto des Berechtigungsinhabers über Teams mit einem Zugriffstoken angemessen wäre. Mit diesem Ziel vor Augen starteten wir den Teams-Client im Browser, um die API-Aufrufe beim Senden von Nachrichten zu verfolgen, und fanden dieses Schmuckstück:
https://amer.ng.msg.teams.microsoft.com/v1/users/ME/conversations/48:notes/messages
Mit dieser API endpoint können wir Nachrichten an uns selbst senden, und wir müssen uns nicht mit der Aufzählung von Konten herumärgern. Als Nächstes benötigten wir das Zugriffstoken. Wir haben die SQLite-Engine verwendet. Da SQLite nicht installiert werden muss, lädt das Tool SQLite in einen lokalen Ordner herunter und führt es aus, um die Cookies-DB zu lesen, aus der wir das für den Nachrichtenversand erforderliche Skype-Zugangs-Token extrahieren.
Mit dem Token in der Hand und unserem Ziel vor Augen mussten wir als letztes eine Nachricht zusammenstellen. Es dauerte einige Zeit, bis der Anfragetext funktionierte, aber schließlich gelang es uns. Wir haben die Nachricht so eingestellt, dass sie mit dem Kennzeichen für hohe Wichtigkeit und der Betreffzeile "You've Been PWND" gesendet wird. Die Nachricht selbst ist das Skype-Zugangs-Token.
Das Tool sendet die Nachricht zu diesem Zeitpunkt, und wir können überprüfen, ob sich das Zugriffstoken in unserem persönlichen Chat befindet.
Gar nicht so schlecht für einen Vormittag Arbeit.
Die Auswirkungen ungesicherter Berechtigungsnachweise
Microsoft speichert diese Anmeldedaten, um ein nahtloses Single Sign-On-Erlebnis innerhalb der Desktop-Anwendung zu schaffen. Durch die Implementierung dieser Sicherheitsoptionen wird die Messlatte jedoch niedriger gelegt.
Jeder, der den Microsoft Teams-Client in diesem Zustand installiert und verwendet, speichert die Anmeldeinformationen, die erforderlich sind, um alle über die Teams-Benutzeroberfläche möglichen Aktionen durchzuführen, selbst wenn Teams heruntergefahren ist. Wenn diese Token gestohlen werden, können Angreifer SharePoint-Dateien, Outlook-Mails und -Kalender sowie Teams-Chatdateien ändern. Angreifer können die legitime Kommunikation innerhalb eines Unternehmens manipulieren, indem sie selektiv zerstören, exfiltrieren oder gezielte phishing Angriffe durchführen.
Der große Schreck - Die ultimative Phish
Was uns hier wirklich Angst macht, ist die Verbreitung von Post-MFA-Benutzertokens in einer Umgebung - sie ermöglicht nachfolgende Angriffe, die keine zusätzlichen speziellen Berechtigungen oder fortgeschrittene malware benötigen, um mit großen internen Schäden davonzukommen. Mit genügend kompromittierten Rechnern können Angreifer die Kommunikation innerhalb einer Organisation steuern. Wenn Angreifer die volle Kontrolle über kritische Arbeitsplätze übernehmen, wie z. B. den technischen Leiter, den CEO oder den CFO eines Unternehmens, können sie Benutzer davon überzeugen, Aufgaben auszuführen, die dem Unternehmen schaden. Wie üben Sie Phish-Tests für diesen Fall?
Empfehlungen
An Administratoren
Baseline-Teams, Verwaltung von Konfigurationen und Überwachung von ACL-Änderungen
Behandeln Sie Teams als eine kritische Anwendung und setzen Sie die ACLs, die sie schützen, durch. Eine Änderung dieser ACLs zur Ausweitung des Lesezugriffs auf Dateien außerhalb des vorgesehenen Benutzers führt dazu, dass die Anmeldedaten dieses Benutzers für alle oben genannten böswilligen Aktionen offengelegt werden.
Sobald Microsoft die Electron Teams-Anwendungen aktualisiert hat, ist es immer noch entscheidend, zu einem Modell mit hohen Restriktionen überzugehen, um die Installation von nicht autorisierten Teams-Apps, Bots, Konnektoren usw. zu verhindern.
Dateizugriff verfolgen
Erstellen Sie eine Systemüberwachungsregel, um die Prozesse zu identifizieren, die auf diese sensiblen Dateien zugreifen. Es gibt zwei spezifische Empfehlungen für Dateien/Ordner:
- [Windows] %AppData%\Microsoft\Teams\Cookies
- [Windows] %AppData%\Microsoft\Teams\Lokaler Speicher\leveldb
- macOS] ~/Library/Application Support/Microsoft/Teams/Cookies
- macOS] ~/Library/Application Support/Microsoft/Teams/Local Storage/leveldb
- [Linux] ~/.config/Microsoft/Microsoft Teams/Cookies
- [Linux] ~/.config/Microsoft/Microsoft Teams/Lokaler Speicher/leveldb
Wenn ein anderer Prozess als Teams.exe auf diese Dateien zugreift, bedeutet dies, dass der Zugriff auf die gespeicherten Daten außerhalb des Kontexts der Teams-Anwendung erfolgt.
Betrachten Sie die Web-App als eine Alternative
Wenn Baselining und Überwachung unpraktisch sind, sollten Sie den webbasierten Teams-Client in Microsoft Edge verwenden, der über mehrere Kontrollen auf Betriebssystemebene verfügt, um Token-Lecks zu verhindern. Glücklicherweise ist die Teams-Webanwendung robust und unterstützt die meisten Funktionen, die über den Desktop-Client aktiviert sind, sodass die Auswirkungen auf die Produktivität des Unternehmens minimal sind.
Für Linux-Benutzer ist dies der empfohlene Weg, da Microsoft das Ende der Lebensdauer von Teams für Linux für Dezember 2022 angekündigt hat.
An Entwickler
Wenn Sie Electron für Ihre Anwendung verwenden müssen, stellen Sie sicher, dass Sie OAuth-Tokens sicher speichern. Eine solche Methode zur Speicherung von Geheimnissen ist die Verwendung des Pakets KeyTar, das die lokalen Sicherheitsmechanismen des Betriebssystems für die Verwaltung von Geheimnissen nutzt.
Wie man sensible Informationen in Electron mit node-keytar sicher speichert | von Cameron Nokes | Cameron Nokes | Medium
An Microsoft
Wenn Sie die Token speichern müssen, tun Sie dies in verschlüsselter Form und legen Sie die Messlatte von einem einfachen Lesezugriff auf das Dateisystem höher, so dass ein ständiger Zugriff auf den Speicher erforderlich ist. Und bitte lassen Sie uns deaktivierte Konten aus der/den Teams-App(s) entfernen, ohne eine vollständige Deinstallation/Neuinstallation durchführen zu müssen.
An Security Teams
Um einen Angreifer zu stoppen, der diese Art von Exploit ausnutzt, sollten Teams in Bedrohungserkennungs- und Reaktionslösungen investieren, die die Art von Aktionen vor und nach der Ausnutzung des Exploits erkennen können. Die Bedrohungserkennungs- und Reaktionsplattform von Vectra würde Befehls- und Kontrolltaktiken erkennen, die vor diesem Exploit zu erwarten wären, sowie jegliche Netzwerkaufklärung, seitliche Bewegungen oder Exfiltration, die nach dem Exploit stattfinden würden. Unter cloud würde Vectra vor den Aktivitäten des Angreifers warnen, der die kompromittierten Anmeldeinformationen in Azure AD verwendet, einschließlich privilegierter Angriffe in Azure AD, umfassender Angriffe auf verbundene cloud Dienstanbieter wie AWS und Angriffe auf andere Microsoft 365-Anwendungen, einschließlich Exchange, SharePoint und Power Automate.
Erkennung von und Reaktion auf Bedrohungen für Ihr Azure AD
Um mehr darüber zu erfahren, wie Vectra Bedrohungen erkennen und stoppen kann, besuchen Sie bitte: https://www.vectra.ai/products/platform