Teams Device Security

Wer mit Teams auf dem PC telefoniert, kann über Windows Update, Intune, Windows Defender und andere Tools die Sicherheit des Clients verwalten. Auf dieser Seite geht es um sie Sicherheit der andere Teams-Clients, die es noch gibt. Insbesondere beim Einsatz von Teams Telefonen und Konferenzsystemen mit Ethernet-Anschluss stellt sich diese Frage. Headsets oder andere nur per USB angebundene Geräte sind nicht relevant.

Es gibt Geräte, die nicht nur mit Teams sondern auch mit einer Firmware für WebEx, generische SIP-Konfiguration oder eine Provierbranding (z.B. Telekom) versehen werden können. Ich behandle hier nur die Teams-Version.

Geräteklassen

Der klassische Teams Client wird von Microsoft als Teil des Service entwickelt und primäre für Windows, Mac und Browser bereitgestellt. Microsoft nutzt dazu das Electron-Framework als Plattform bzw. JavaScript/CSS/HTML/WebRTC beim Browser. Hier müssen Sie einfach glauben, dass Microsoft seine Versprechen erfüllt. Die Teams Geräte bekommen vom jeweiligen Hersteller ihre Firmware, z.B. den Android-Unterbau, auf den der Teams-Client von Microsoft integriert wird. Interessant sind alle Geräteklassen, die einen Zugang zum Netzwerk und eine IP-Adresse  bekommen, sei es per Ethernet oder WLAN:

  • Teams Telefone
    Audiocodes, Poly, Yealink sind bekannte Hersteller von "Tischtelefonen". Warum auch immer werde ich speziell bei dem chinesischen Hersteller "Yealink" immer mal wieder gefragt, ob man den Geräten überhaupt trauen kann.
  • Teams Konferenz-Geräte (Android)
    Die meisten Konferenz-Bars nutzen heute Android als Unterbau für den Microsoft Teams Clients.
  • Teams Konferenz-Geräte (Windows)
    Einige Geräte basieren auf Windows 10/11 und der Teams Client "erkennt", diese besonderen Geräte und verhält sich anders.
  • Teams Konferenz-Geräte (sonstige)
    WebRTC und Browser sind ja erst einmal keine Besonderheiten und ich erwarte durchaus auch Konferenzsysteme anderer Hersteller, die vielleicht auch Linux als Basis setzen.
  • Teams Panels
    Die z.B. außen am Raum als Anzeige und Reservierungsterminal genutzt werden

Bei all den Geräten ist natürlich ein mehr oder weniger "vollwertiges" Betriebssystem installiert. Noch gibt es den Teams Client nicht als hardwareoptimierte Software wie z.B. Chrome auf Crhomebooks. Damit stellt sich auch die Frage, welche zusätzlichen Prozesse oder Angriffsvektoren sich hier für Angreifer eröffnen.

Firmware Updates

Sollte ein Gerät die Möglichkeit zum Spionieren haben, dann müsste sich der Code entweder in der Firmware selbst oder einer Applikation neben dem Teams Client befinden. Um die Firmware kümmert sich aktuell jeder Hersteller selbst, der ja auch die Hardware entwickelt und liefert auch einen von Microsoft bereitgestellten Teams Client mit. Ein Update kann über eigene Provisioning-Server des Herstellers als auch das Teams Admin Center (TAC) erfolgen.

Diese Hersteller-Updates kommen aber weniger oft und daher kann Microsoft über das TAC auch einen neueren Teams Client separat für die Geräte bereitstellen, der fast immer neuer ist. Der Teams Client kann also unabhängig von der Firmware aktualisiert werden, der meist sogar ein Firmwareupdate mit älterem Client übersteht.

Alle Teams Geräte werden im "Teams Admin Center (TAC)" verwaltet. Microsoft hat für diese speziellen Geräte einen eigenen Update-Service bereitgestellt. Die Geräte tauchen daher aktuell auch nicht in Intune oder anderen Plattformen auf. Hier am Beispiel von Teams Phones im Admin Portal.


https://admin.teams.microsoft.com/devices/ipphones

Das bedeutet aber nicht, dass die darunter liegende Firmware immer die aktuellste Version mit einem entsprechenden Patchstand ist. Speziell auf Android basierende Systeme sind teils mehrere Versionen hinter dem Stand, den Sie von ihrem aktuellen Smartphone kennen.

Das ist aber nicht zwingend schlecht, denn diese Android-Versionen sind für ihren Einsatzzweck optimiert und da eh nur der Teams Client starten sollte, gibt es für den Hersteller auch einen Vorteil weitere Apps zu installieren.

Dennoch kann ja auch in der Firmware ein Bug, eine vergessen Routine, ein nicht deaktivierter SSH-Zugang o.ä. lauern. Microsoft pflegt eine Liste der Geräte und dem Datum des Support-Ende.

Vielleicht gibt es von Microsoft zukünftig ja auch wieder eine Referenzimplementierung von Teams mit Android auf Qualcomm, so dass noch mehr Hersteller eigene "Gehäuse" drum herum bauen können. Bei Lync gab es das ja auch schon.

MTRW - Microsoft Room Systems on Windows

Ein Sonderfall sind die Raumsysteme, die auf Windows basieren. Lösen Sie sich dabei von dem Gedanken, dass es es sich um "Windows" handelt. Die MTRW-Systeme nutzen ein Windows 10/11 Enterprise IoT, welches sehr stark modifiziert und auf Teams optimiert ist. Sie können kein MTR mit eigener Hardware und Windows 11 bauen. Der Teams Client "erkennt" anhand des Windows Unterbaus, welches zertifizierte Geräte es ist und startet nur dann den Raumsystem-Mode. Hier sind sie auf "zertifizierte Partner" angewiesen.

Die Teams App wird hier über den Windows Store verteilt und Betriebssystemupdates über Windows Update. Allerdings unterscheidet sich auch hier ein MTRW von einem normalen Windows, da die MTRW-Geräte von Windows Update erkannt und mit eigenen Versionen versehen werden.

Netzwerk und Firewall

Teams Telefone und Konferenzsysteme sind in Bezug auf ihre Kommunikation sehr einfach zu erklären:

Teams Geräte sind "Cloud Native"-Geräte, die eigentlich nur mit Microsoft Teams im Internet kommunizieren müssen.

Dies gilt umso mehr für Konferenzsysteme, die nicht für 1:1-Calls zu anderen internen Teams-Teilnehmern oder Telefonanschlüsse kommunizieren müssen.

Sie machen nichts falsch, wenn Sie die Geräte vor der Firewall zum Internet platzieren und gar nicht in ihr internes Netzwerk aufnehmen.

Aus Sicht von Microsoft Teams ist es bis auf wenige Ausnahmen nicht erforderlich, dass eine Verbindung von irgendwo zu einem dieser Geräte aufgebaut wird. Alle Geräte sind "Clients", die eine Verbindung von sich aus zu bekannten Gegenstellen starten und dann nur Rückantworten auf bestehende Verbindungen annehmen müssen.

Allerdings kann es schon für den ein oder anderen Sonderfall erforderlich sein, doch eine Verbindung vom Geräte zum internen Netzwerk oder auch von intern zum Gerät zuzulassen.

  • Audio Local Media Optimization (RTP)
    Für die Übertragung von Audio bei 1:1 Verbindungen sollten Sie darüber nachdenken, diese UDP-Verbindungen auf bestimmten Ports (50000-50019/UDP und ggfls. zum lokalen SBC) auch eingehend zu erlauben. Ist diese Verbindung nicht möglich, dann funktioniert Audio dennoch über den Umweg des Media-Relay in der Cloud, was allerdings durch den Umweg über die Internetanmeldung mehr Bandbreite und höhere Latenzzeit bedeutet.
  • Verbindung zur Soundbar, Bedienteile
    Einige Konferenzsysteme können Verbindungen zu Tochtergeräten aufbauen. Wenn diese, warum auch immer, im Hausnetzwerk sind, dann müssen Sie ggfls. diese Paarungen zulassen.
  • Management
    Es mag vielleicht zukünftig auch Managementzugänge zur Verwaltung z.B. per Browsern, SNMP  o.ä. für Sonderfälle geben.

Dies ist aber optional, da sich bislang jedes "Teams Device" auch über das Teams Device Management in der Cloud verwalten lässt.

Diese gesonderten Verbindungen müssen Sie natürlich auch hinsichtlich der Sicherheit betrachten aber das Teams Device selbst ist weiterhin außerhalb des Firmennetzwerks und daher ohne Zugriff auf ihre internen vitalen Daten

Hier eine Auslistung der Verbindungen und Kommunikationen eines Teams Devices.

Service Ziel Ziel-Port Beschreibung

DHCP

DHCP-Server oder DHCP-Relay im Subnetz

DHCP

Ich habe keinen Kunden, der IP-Adressen statisch in VoIP-Geräten oder Konferenzgeräten verwaltet. IP-Adressen und Konfiguration werden durch DHCP-Server verwaltet und vergeben. Technisch ist dies natürlich ein Broadcast und nachfolgende ARP-Pakete im LAN.

DNS

DNS-Server

53/UDP

Das System muss natürlich ausgewählte Namen auflösen können. Wer es ganz streng macht, könne bei DNS-Anfragen alle anderen Namen unterbinden um C&C-Kommunikation über DNS zu unterbinden.

LLDP
CDP

Switch

<Ethernet>

Einige Telefone unterstützen LLDP und/oder CDP, um dem Switch ihren Strombedarf und andere Daten mitzuteilen, damit sich das Netzwerk darauf einstellen kann, z.B. alleine anhand der Information, dass es ein Telefone ist, dieses in ein anderes VLAN zu konfigurieren.

HTTPS

AzureAD

443/HTTPS

Die komplette Datenkommunikation

  • Anmeldung (https://login.microsoftonline.com u.a.)
    Der Teams Client muss verschiedene URLs in der Cloud erreichen, um z.B. OAUTH-Tokens zu erhalten.
  • Signalisierung (https://teams.microsoft.com)
    Über diesen Kanal kommuniziert der Teams Client mit dem Backend, überträgt Chats u.a., startet Telefonanrufe, aktualisierte Präsenzstatus greift auf Teams und Kanäle zu.
  • Exchange Online
    Speziell Teams Room Systems greifen auch z.B. auf ihre Exchange Online Raumpostfach zu, um Termine zu nutzen.
  • Whiteboard, PowerPoint, anderer Content
    In Meetings gibt es weitere URLs z.B. zum Whiteboard, PowerPoint Live etc

Alle URls sind aber im Microsoft Ökosystem zu finden und auf den meisten Firewalls und Proxy-Servern einfach zu konfigurieren.

RTP

IP-Range bei Microsoft

 3478-3481/UDP
443/TCP

Alle Teams Meetings und die meisten VoIP-Verbindungen nutzen die Teams Media-Relay von Microsoft, welche idealerweise per UDP erreichbar sind und die IP-Bereiche sind bekannt:

RTP

Lokale Teams Client

 Audio:50000-50019
Video:50020-50039

Wenn ein Anwender ein Teams Telefon nutzt und einen anderen Anwender an einem PC anruft, die in unterschiedlichen aber per IP-Routing erreichbaren Netzwerken beheimatet sind, dann versuchen diese beiden Kommunikationspartner direkt eine RTP-Verbindung aufzubauen. Wenn dies nicht möglich ist, dann kommunizieren die Teilnehmer natürlich über das Media Relay in der Cloud

RTP

lokaler SBC

SBC-Abhängig

Speziell für Telefone mit einem lokalen SBC kann es erwünscht sein, dass die RTP-Pakete nicht über ein Media Relay in der Cloud laufen. Sie können dazu Teams Local Media Optimization einrichten, so dass der Teams Client direkt mit dem lokalen SBC kommuniziert. Dies funktioniert aber nur für "Telefongespräche" über den lokalen SBC und hat keinen Einfluss auf Meetings oder Teams 1:1-Calls mit anderen anderen Teams Teilnehmern.

SBA

SBA /SBC Survivability

 3443
4444
8443

Diese besonderen Ports werden genutzt, wenn die Telefone mit einem lokalen SBC/SBA eine Basisfunktion bei Telefonie aufrecht erhalten sollen, wenn die Cloud wirklich einmal entfallen wäre.

Das macht es auch für den Administrator eines Netzwerks relativ einfach, diese Geräte in ein eigenes Subnetz zu verlagern und nur die erforderlichen Verbindungen sowohl von den Geräten ausgehend als eingehend zu erlauben. So können Sie die Konferenz-Systeme und Teams-Telefone zuverlässig gegen Angriffe von innen und erst recht aus dem Internet schützen. Direkte Verbindungen von einem Tischtelefone zu einem Tisch-Computer (Siehe BToE - Better together over Ethernet) gibt es mit Teams aktuell nicht.

Sie sehen sehr gut, dass die "Teams Device"-Zone nur eine überschaubare Anzahl an Verbindungen braucht und die gelben Verbindungen sogar "optional" sind, wenn für 1:1 Verbindungen das Media Relay in der Cloud genutzt werden soll. Bei Meetings gehen alle RTP-Daten sowieso über die MCU in der Cloud.

Ein Angreifer könnte natürlich sich auch die Microsoft 365-Systeme als "C&C-Server" nutzen, wenn er z.B. die Firmware so verändert, dass die gleichen Wege genutzt werden.

Device Scan ThinkSmart View

Wenn das Gerät eine IP-Adresse hat, dann muss es auch auf auf ARP-Request antworten und vielleicht sogar auf PING-Pakete. Mein Lenovo ThinkSmart View lässt sich im LAN sehr einfach finden und reagiert sogar auf PING-Anfragen. Also habe ich einen NMAP auf das Device losgelassen.

nmap -p 1-65535 -T4 -A -v 192.168.178.127

Die Ausgabe eines Scans über alle TCP-Ports ergab keinen offenen Port:

Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-26 00:38 Mitteleuropäische Sommerzeit
NSE: Loaded 151 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 00:38
Completed NSE at 00:38, 0.00s elapsed
Initiating NSE at 00:38
Completed NSE at 00:38, 0.00s elapsed
Initiating NSE at 00:38
Completed NSE at 00:38, 0.00s elapsed
Initiating ARP Ping Scan at 00:38
Scanning 192.168.178.127 [1 port]
Completed ARP Ping Scan at 00:38, 0.34s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 00:38
Completed Parallel DNS resolution of 1 host. at 00:38, 11.00s elapsed
Initiating SYN Stealth Scan at 00:38
Scanning kingston.fritz.box (192.168.178.127) [65535 ports]
Completed SYN Stealth Scan at 00:38, 20.38s elapsed (65535 total ports)
Initiating Service scan at 00:38
Initiating OS detection (try #1) against kingston.fritz.box (192.168.178.127)
Retrying OS detection (try #2) against kingston.fritz.box (192.168.178.127)
NSE: Script scanning 192.168.178.127.
Initiating NSE at 00:39
Completed NSE at 00:39, 0.00s elapsed
Initiating NSE at 00:39
Completed NSE at 00:39, 0.00s elapsed
Initiating NSE at 00:39
Completed NSE at 00:39, 0.00s elapsed
Nmap scan report for kingston.fritz.box (192.168.178.127)
Host is up (0.027s latency).
All 65535 scanned ports on kingston.fritz.box (192.168.178.127) are closed
MAC Address: 80:30:49:CD:DD:23 (Unknown)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

TRACEROUTE
HOP RTT      ADDRESS
1   27.27 ms kingston.fritz.box (192.168.178.127)

NSE: Script Post-scanning.
Initiating NSE at 00:39
Completed NSE at 00:39, 0.00s elapsed
Initiating NSE at 00:39
Completed NSE at 00:39, 0.00s elapsed
Initiating NSE at 00:39
Completed NSE at 00:39, 0.00s elapsed
Read data files from: C:\Program Files (x86)\Nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 36.81 seconds
           Raw packets sent: 65559 (2.887MB) | Rcvd: 65590 (2.627MB)

Das muss nun aber nicht heißen, dass es keine Türen gibt. Eine Hintertür kann sich durchaus hinter "Port Knocking"-Techniken oder Source-IP-Filter verbergen. Zudem ist dies kein Freibrief für generell alle Teams Endgeräte aller Hersteller, Betriebssysteme und Firmware-Stände.

Eine etwas ausführlichere Analyse habe ich mit Wireshark und einem Poly CCX500-Telefon gestartet:

Teams Device Security -CCX500

SIP Allgemein

Auch wenn ich auf dieser Seite primäre die Teams-Endgeräte besprochen habe, so gelten die gleichen Ansätze auch für andere VoIP-Lösungen. Sie können auch hier die Telefone und Konferenzsysteme über eigene Subnetze mit Firewalls von den Client und insbesondere den Servern trennen oder nur ausgewählte Verbindungen, z.B. LDAP-Suche, RTP-Audio, etc. erlauben. Wer eine lokale SIP-Umgebung betreibt, kann die Gerät vermutlich gänzlich ohne Internetzugriff betreiben. Beim Einsatz einer "CloudPBX" sollte der Anbieter auch die erforderlichen IP-Bereiche aufführen können, so dass sie die Kommunikation darauf beschränken.

BSI Grundschutz: NET.4.2: VoIP
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs_2021/09_NET_Netze_und_Kommunikation/NET_4_2_VoIP_Edition_2021.pdf?__blob=publicationFile&v=2

BSI – Technische Leitlinie Technische Leitlinie für organisationsinterne Telekommunikationssysteme mit erhöhtem Schutzbedarf Teil 2: Sicherheitskonzepte
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeLeitlinien/TKAnlagen/TLSTK_II-Teil_2%E2%80%93Sicherheitskonzepte.pdf?__blob=publicationFile&v=1

SIP Phone Security White Paper
https://www.yealink.com/website-service/attachment/system/documents/20220607/2022060703235317851aaa15840bf96676b8cabb42b9a.pdf

Zusammenfassung

Nach Betrachtung der obigen Punkte können wir zwar immer noch nicht sicher sein, dass z.B. mit einem Teams Telefon nicht doch eine "Wanze" den Weg in unser Netzwerk findet, aber sie können das Risiko durchaus minimieren, indem Sie die Kommunikation dieser Geräte auf die relevanten Gegenstellen beschränken und durch ein Intrusion Detection System das Verhalten überwachen, so dass "unerwartete Kommunikationen" auffallen.

Ich denke, dass kein Hersteller hier sich absichtlich in das Risiko begeben würde, eine Hintertür einzubauen. Irgendwann würde sie sicher entdeckt und der wirtschaftliche Schaden dürfte ausreichend abschrecken. Ein höheres Risiko sind eher die unbemerkten Sicherheitslücken, die es in jeder Software gibt. Hier haben solche Geräte aber einen Vorteil gegenüber einem "vollwertigen Windows Desktop", da Sie in ihrer Funktion naturgemäß eingeschränkt sind und die Kommunikationsbeziehungen limitiert werden können.

In dem Zuge finde ich Desktops viel kritischer, auf denen eine Malware nicht nur mit viel mehr CPU und RAM auf einer viel größeren Anzahl an potentiellen Computern mit den Berechtigungen des Benutzers an essentielle Firmendaten kommen kann und dazu noch viel umfangreicher nach extern kommunizieren kann.

Wer die Sicherheit erhöhen will, kann und sollte die Konferenzsysteme einfach in ein eigenes VLAN stecken, so diese weder ihre lokalen Server noch fremde Cloud-Dienste erreichen können, sondern nur mit den Microsoft Teams Endpunkten in Microsoft 365 kommunizieren und für Audio/Video per UDP über die bekannten Ports. Eine Firewall kann diese Kommunikation mit überschaubarem Aufwand reglementieren und vielleicht entdecken Sie ja das erste Gerät, welches unerlaubt zu anderen Systemen eine Verbindung aufbaut. So eine Konfiguration sollte "inaktive Hintertüren" unbrauchbar machen, die erst bei Bedarf aktiviert würden.

Wenn Sie aber wissen, mit welchen Gegenstellen ihre Endgeräte, Teams oder SIP o.ä.) kommunizieren und sie eine entsprechende Firewall nutzen können, dann ist es einfach nur legitime Verbindungen zu erlauben und unerwünschte Kommunikation zu erkennen und zu unterbinden. Kniffliger ist es natürlich für Systeme im Homeoffice, denn die meisten SoHo-Router haben keine ausgehende Firewall oder eigene VoIP-Subnetze.

Was sie natürlich auch nicht wirklich erkennen können, sind Hintertüren auf VoIP-Basis. Ob ein Angreifer einen "besonderen" SIP-INVITE zu einem Telefon senden kann und das Telefon die Verbindung still automatisch annimmt und über das Mikrofon ein "Mithören" im Raum erlaubt, entzieht sich meiner Kenntnis. Diverse DECT-Systeme haben so eine Funktion in Form eines "Babyphones", um mal schnell zuhause ohne klingeln anzurufen. 100% Sicherheit gibt es hier also nicht. Viele Business-Kameras und Laptops haben mittweile Hardwareschalter oder Schieber, um die Linse abzudecken. Aber bei Mikrofonen ist es ungleich schwerer.

Weitere Links

Version 1.1: Schadhafte Version der 3CX Desktop App im Umlauf
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2023/2023-214778-1032.pdf

SIP Phone Security White Paper
https://www.yealink.com/website-service/attachment/system/documents/20220607/2022060703235317851aaa15840bf96676b8cabb42b9a.pdf