Teams Malware

Es gibt so Seiten, die wollte ich schon immer schreiben aber dann ist es ein externer Blog-Artikel, der dann das Vorhaben etwas beschleunigt. Hier war es ein Artikel, der "Teams als Risiko" beschreibt und dass Malware-Autoren über Teams sehr problemlos Millionen von Anwendern angreifen können und eine bekannte deutsche Computerzeitung das relativ unreflektiert nacherzählt hat.

Technisch ist es aber nicht mehr, als dass ein Endanwender eine Malware-EXE-Datei ausführt, weil er Teams vertraut.

Risiko Zusammenarbeit

Niemand wird abstreiten, dass bei dem Austausch von Informationen auch bösartige Komponenten übertragen werden können. Allerdings ist es schon ein Unterschied, ob so eine Malware ohne Authentifizierung und Mithilfe des Empfängers ausgeführt werden kann (Siehe Hafnium Exploit oder Log4Shell) oder ob die Mithilfe eines authentifizierten Empfängers erforderlich ist. Beim Thema Emil kennen wir seit Jahrzehnten das Thema "Spam" und dass ein Betrieb eines Mailservers ohne entsprechende Filter nicht mehr möglich ist. In der Cloud gibt es Exchange Online Protection und natürlich gibt es 3rd Party Tools wie NoSpamProxy u.a.

Bei Teams gibt es aber keine Möglichkeit, einen "Transportscanner" zwischen meinen Tenant und alle anderen Tenants zu bringen. ich kann nur Federation ganz abschalten oder auf gewisse Domänen einschränken. Siehe auch Teams Privacy. Das würde aber bedeuten, dass sich alle Firmen bei der Einführung von Office 365/Microsoft 365 und insbesondere Microsoft Teams darüber auch Gedanken gemacht und Entscheidungen gefällt und diese in der Konfiguration umgesetzt haben.

Davon sollten Sie nicht ausgehen und die "Defaults" von Microsoft Teams sind nun mal schon auf Kommunikation und leichte Nutzung aller Funktionen eingestellt.

Insofern gibt es natürlich nicht nur viele Tenants, die diesbezüglich "erreichbar" sind sondern noch viel mehr Anwender, die von ihrer Firma nicht entsprechend unterwiesen sind. Wenn ein Anwender das erste Mal einen "PC-Anruf" von einem externen Partnerunternehmen bekommt und den Status der Kommunikationspartner in Outlook einfach so sieht, ist die Überraschung groß. Allerdings ist es doch relativ wenig wahrscheinlich, dass der erste Kontakt mit diesem Medium ausgerechnet ein "Böser Absender" ist. Viele Mitarbeiter haben sich daher vermutlich schon selbst "geschult" und ihre Erfahrungen gemacht.

Für unerwünschte Chat-Nachrichten gibt es schon lange den Begriff SPIM - Spam via IM

Dateien per Teams

Der oben aufgeführte Artikel von Avanan beschreibt ja sehr ausführlich, dass ein böser Absender einem unbedarften Benutzer eine Datei mit dem Namen "UserCentric.exe" senden kann, die der Anwender dann ausführt. Diese "Böse Datei" kann dann in der Registrierung schreiben, DLLs auspacken und Shortcuts anlegen. Da beschreibt der Autor aber nur die gängigen Dinge, denn wenn ich Angreifer wäre und ein Ziel würde meine Software unbedarft ausführen, dann würde ich eine versteckte Shell zu einem C&C-Server aufbauen, weitere Malware nachladen, das Netzwerk auf Schwachstellen durchsuchen und vieles mehr.

Das geht aber alles nur, wenn ein Anwender eine Datei bekommt und startet. Das ist aber erst einmal gar nicht so einfach, denn anders, als im Artikel beschrieben, kann ich per Teams gar keine Dateien senden. Sie haben richtig gelesen, denn das Senden von Dateien, wie wir es von Emails oder auch Skype for Business Chats kennen, ist in Microsoft Teams so gar nicht vorgesehen. Das widerspricht dem Ansatz des "Sharing" und ein Versenden und Empfangen von Dateien würde zwangsläufig zu weiteren Kopien und Versionen führen.

Stattdessen pflegt Teams den Ansatz eines "Sharings". Hier gibt es dann folgende Risiken:

  • Datei im 1:1 Chat
    Der böse Absender kann eine Datei im Chat bereitstellen, aber technisch legt er die Datei in seinem eigenen OneDrive unter "Teams Chat-Datein" ab und der Empfänger greift auf diese Datei über die URL https:<absender-tenantname>-my.sharepoint.com zu. Es ist nur für den Anwender nicht offensichtlich aber für den Administrator ist es nur ein weiterer Download einer Datei von einer fremden URL. Es ist ja nicht der eigene Tenant, zumindest wenn der Angreifer nicht ein Konto in der Firma gekapert hat (Phsihing)
  • Link im 1:1 Chat
    Ein Angreifer kann natürlich auch einen Link zu einer beliebigen anderen Seite im Chat senden, z.B. auf Dropbox oder eine der vielen unsicheren Wordpress-Seiten. Anwender, die dieses Risiko nicht einschätzen können, sind schon seit der Erfindung von Email ein Risiko. Wobei bei Email ein Spamfilter solche URLs teils abwehren kann, während des in Teams keine Filterfunktion gibt.
  • Datei im Teams Kanal
    Der dritte Ansatz ist die Ablage von Malware in einem gemeinsamen Ablageorder eines Teams. Das ist aber keine Federation sondern dazu muss der der Angreifer entweder "Gastbenutzer" oder B2B-ExternalAccess im Shared Channel sein. Hier sollte der Teams-Besitzer natürlich wissen, wen er als Gast einlädt.

Generell ist es natürlich ein Problem, wenn ein Angreifer einen Weg gefunden hat, als authentifizierter Benutzer zu arbeiten. Dann wäre aber Microsoft Teams eine kleinere Sorge. Als "Domain Benutzer" in einem Netzwerk kann ich ganz andere Dinge anstellen und versuchen, ohne Mithilfe eines Anwenders mehr Berechtigungen zu erlangen. Die Kommunikation in Teams ist ja nicht "anonym" und ein aufmerksamer Mitarbeiter könnte meine Kommunikation durchschauen und Alarm schlagen.

Schutz in Teams

Aktuell ist es aber so, dass es keinen Schutz oder Filter gegen unerwünschte Nachrichten in Teams gibt. Bei Skype for Business/Lync (On-Premises) gab es sogar einige Lync Virenscanner, die über die Lync Server API - MSPL jede SIP-Nachricht analysiert und ggfls. unterbunden haben. Diese Funktion gibt es aktuell nicht. Das bedeutet aber nicht, dass Teams gänzlich ungeschützt ist, denn gegenüber einer Mail per SMTP, wo jede IP-Adresse im Internet ein mögliche Absender ist, muss der Angreifer in Teams entweder selbst ein Teams Konto besitzen oder zugriff auf ein fremdes Konto haben. Das ist zumindest eine kleine Hürde. Teams kann auch mit Skype und anderen Diensten per Federation kommunizieren aber hier kommt dann eine Rückfrage an den Anwender, ob er die Kommunikation annehmen will.

Diese Anfrage kommt allerdings nicht, wenn die andere Seite selbst auch Microsoft Teams nutzt. Wenn ein Angreifer ein fremdes Konto nutzt, welches sogar mit dem Empfänger schon in Kontakt stand, dann fallen mehr Anwender darauf herein.

Daher ist es so wichtig, dass alle Benutzer mit Conditional Access und Multi Faktor Authentifizierung (MFA) arbeiten. Benutzername und Kennwort sind einfach nicht mehr ausreichend.

Ich bin auch ziemlich sicher, dass sich Microsoft die Situation sehr genau beobachtet und gegensteuert. Anscheinend ist aber SPIM und Malware über Teams noch kein Thread

Wenn ich die Variante mit einem Link auf eine externe Quelle weglasse, dann liegen in Teams bereitgestellte Dateien im OneDrive des Absenders oder im SharePoint des Teams. Ich weiß auch, dass ein Virenscanner keinen 100%-Schutz liefern kann und speziell individuelle Malware oft erst nach Entdeckung und einem Patternupdates und damit verspätet erkannt wird. Aber OneDrive und Sharepoint sind ja dennoch nicht ungeschützt

Die Risiken über per OneDrive geteilte Dateien sind übrigens nicht neu und wenn ein Link sogar Consent anfordert, dann ist das Risiko noch deutlich höher.

Neben dem immer erforderlichen Virenschutz gibt es aber im Werkzeugkasten der Endpoint Security noch einige weitere Gegenmaßnahmen. Aus meiner Sicht ist z.B. Applocker ein sehr gutes Hilfsmittel die weniger versierten Anwender zu schützen. Oft nutzen diese sowieso nur einen klar bekannten Satz von Programmen, die zentrale vorinstalliert sind. Hier bietet es sich dann an per Allowlist jeden anderen Code zu blockieren. Damit wird die Ausführung von nicht explizit freigegebenen Programme sicher verhindert.

Einschätzung

Es ist was dran, dass es mit Teams und Chats per Federation oder von kompromittierten Konten ein neues Einfallstor für Angreifer gibt, die unbedarfte oder wenig sensibilisierte Anwender vielleicht überrumpeln können. Es gibt aber sehr viele Optionen, diese Fehler durch Anwender zu erschweren und das Risiko zu minimieren. Wie so oft muss aber der Anwender mitspielen und die IT die vorhandenen Hilfsmittel auch einsetzten. Vielleicht arbeiten Sie ja mal meine Checkliste Tenant Einrichtung durch.

Microsoft kann man aktuell vielleicht vorwerfen, dass die Default-Konfiguration zu Federation zu freizügig ist und auch Test-Tenants sehr einfach zu erlangen sind. Aber das Problem haben viele Cloud-Anbieter, die mit Test-Versionen werben und die Identifizierung nicht 100% wasserdicht haben.

Ich will das Thema nicht verharmlosen aber so kritisch oder neu schätz ich das nicht ein. Klingt mir eher nach ClickBait und Quotenhascherei. Ein großes Thema oder das "nächste große Cloud-Risiko" kann ich hierbei aber nicht sehen und eine "Sicherheitslücke" ist es auch nicht. Ich konnte zumindest keinen CVE-Bericht finden.

Weitere Links