Teams Device Security CCX500

Auf der Seite Teams Device Security bin ich allgemein auf die Sicherheit von Teams Devices eingegangen. Diese Seite beschreibt eine Analyse des Poly CCX500 Teams Phone

Poly CCX500

Natürlich habe dem ein oder anderen Telefon mal auf die Finger geschaut. Ich bin nun kein zertifizierter Security Auditor und haben die Tests nicht für alle Geräte und alle Firmware-Stände wiederholt. Aber ich kann auf meinem Switch problemlos ein "Port Mirroring" einrichten, damit alle Pakete zum und vom fraglichen Endgerät auch an einen Analyse-System gesendet werden, welches z.B. per WireShark oder Packetbeat auch einige Zeit lang aufzeichnen kann, mit welcher Gegenstelle das Telefon kommuniziert.

CCX 500/505

Firmware: 7.0.3.0228
Geräteeinstellungen 2.0.5
Partner-Agent 1.0.21
Teams-Version 1449/1.0.942021022403

Diese Firmware ist mittlerweile deutlich zu alt.

Über einen Zeitraum von 24h habe ich alle Pakete des Telefons über einen Portmirroring im Switch zu einer Wireshark-Instanz dupliziert.

Die meisten Pakete wurden über TCP übertragen. Ich habe mir aber zuerst einmal die UDP-Pakete angeschaut, bei denen ich vier Typen ermitteln konnte:

Bootvorgang

Noch ehe das Telefone überhaupt eine IP-Adresse bekommen hat, hat es schon seine Existenz quasi dem Switch verraten. Dank LLDP und CDP kann das Telefon dem Switch einige Informationen mitgeben und vom Switch erhalten, z.B.: den Standort u.a.

  • LLDP / 802.1ab
    Zuerst sehe ich die LLDP-Anfragen des Clients an die LLDP-MAC-Adresse mit Details zum Endgerät

    LLDP funktioniert hier auf MAC-Level und verlässt daher das Subnetz nicht. Das Telefon hat auch noch keine IP-Adresse o.ä.
  • CDP - Cisco Discovery Protocol
    Kurz danach sendet es noch per CDP seine Informationen ebenfalls per MAC-Adresse an (01:00:0c:cc:cc:cc) und damit jedes System im LAN, welches dieses Paket empfängt.

DHCP

Erst dann startet das Poly eine DHCP-Anfrage nach diversen Daten

Über den Discover fragt das Telefon nach einer IP-Adresse und fordert folgende Parameter an:

Meine Fritz!Box liefert nur folgende Daten

NTP

Eine aktuelle Uhrzeit ist speziell für die Überprüfung von Zertifikaten natürlich wichtig. Daher holgt sich das Telefon seine Uhrzeit über den angebotenen NTP-Server (meine Fritz!Box), von der es auch per DHCP die IP-Adresse und weitere Details wie DNS-Server und Default Gateway bekommen hat.

Interessanterweise zeigt das Telefon im Display allerdings andere NTP-Server an.

Aber ich habe keine Kommunikation zu diesen Servern per NTP gefunden.

Device Management

Der direkt nächste Schritt noch vor einer Anmeldung oder Provisionierung ist der Zugriff auf "teams-devicemgmt-global.azureedge.net".

Auch wenn ich den TLS-Stream nun nicht aufgebrochen habe, tippe ich erst einmal auf einen Update-Check, in dem das Gerät seine ID zu Microsoft sendet und dann ein eventuell erforderliches Updates ausgeliefert wird.

Anmeldung

Hier war dann erst einmal etwas "Pause", denn das Telefon erwartet nun eine Anmeldung durch den Anwender. Ich habe mich dann auf dem Telefon interaktiv angemeldet und dann das Telefon einige Stunden im angemeldeten Zustand stehen lassen. Gegen Ende habe ich dann vom Telefon aus einen Anruf zu einem anderen Teams-Anwender gestartet und nach all diesen Paketen die Auswertung fortgesetzt.

DNS

Zuerst habe ich mir einmal die DNS-Anfragen angeschaut. Natürlich kann eine Hintertür oder eine Malware auch über IP-Adressen gehen, aber damit wäre die Funktion nicht immer gewährleistet. Eine DNS-Anfrage nach einem TXT-Record, CNAME o.ä., ist viel zuverlässiger und wird meist nicht bemerkt.

Count Name
----- ----
   60 teams.microsoft.com
   56 config.teams.microsoft.com
   52 api.flightproxy.teams.microsoft.com
   42 r3-api.flightproxy.teams.microsoft.com
   41 api3.cc.skype.com
   30 ic3.events.data.microsoft.com
   25 mobile.pipe.aria.microsoft.com
   12 teams.events.data.microsoft.com
   11 emea.ng.msg.teams.microsoft.com
    8 outlook.office.com
    8 login.microsoftonline.com
    7 presence.teams.microsoft.com
    6 trouter2-azsc-sece-7-a.trouter.teams.microsoft.com
    4 ukwest-prod.notifications.teams.microsoft.com
    4 euaz.relay.teams.microsoft.com
    4 authsvc.teams.microsoft.com
    4 whiteboard.microsoft.com
    3 go.trouter.teams.microsoft.com
    3 in.appcenter.ms
    2 fef.msub02.manage.microsoft.com
    1 mamservice.manage.microsoft.com
    1 euwe-1.api.microsoftstream.com
    1 eu-mobile.events.data.microsoft.com
    1 clientservices.googleapis.com
    1 api.microsoftstream.com
    1 aadcdn.msauth.net
    1 52.114.229.8.fritz.box
    1 52.114.229.8
    1 52.114.225.56.fritz.box
    1 52.114.225.56
    1 52.114.225.43.fritz.box
    1 go.microsoft.com
    1 52.114.225.43

Eigentlich alle Dienste haben mit Microsoft etwas zu tun. Allerdings kann ich mir noch keinen Reim auf die Anfrage nach "clientservices.googleapis.com" machen, der auf "142.250.185.227" aufgelöst wurde. Effektiv übertragen wurden ca. 800 Bytes. Die Latenzzeit war mit 13ms kurz genug um einen Zugriff außerhalb von Europa auszuschließen.

TCP

Bei der Analyse der TCP-Verbindungen sehen wir dann ausschließlich Verbindungen per HTTPS auf Port 443 verschiedener Gegenstellen:

IP-Adresse IP-Netz IP-Range ASN Inhaber

13.89.179.0, 13.69.116.0, 13.107.246.0

13.64.0.0/11

13.64.0.0 - 13.107.255.255

AS8075

Microsoft

20.44.10.0, 20.42.73.0, 20.42.65.0, 20.38.81.0

20.40.0.0/13

20.33.0.0 - 20.128.255.255

AS8075

Microsoft

20.190.159.0, 20.189.173.0

20.184.0.0/13

20.180.0.0 - 20.191.255.255

AS8075

Microsoft

40.74.98.0, 40.79.141.0, 40.74.98.0, 40.70.161.0, 40.126.32.0, 40.126.31.0

40.74.0.0/15

40.74.0.0 - 40.125.127.255

AS8075

Microsoft

51.132.193.0

51.132.0.0/16

51.132.0.0 - 51.132.255.255

AS8075

Microsoft

51.104.15.0, 51.105.71.0

51.104.0.0/15

51.104.0.0 - 51.105.255.255

AS8075

Microsoft
52.97.189.0, 52.98.232.0,
52.112.238.0, 52.112.124.0, 52.112.120.0,
52.113.194.0,
52.114.92.0, 52.114.76.0, 52.114.229.0, 52.114.225.0

52.96.0.0/14

52.96.0.0 - 52.115.255.255

AS8075

Microsoft

52.123.240.0, 52.123.159.0, 52.123.144.0, 52.123.136.0, 52.123.134.0

52.120.0.0/14

52.120.0.0 - 52.123.255.255

AS8075

Microsoft

52.168.112.0, 52.182.143.0, 52.157.250.0, 52.168.117.0, 52.157.250.0

52.160.0.0/11

52.145.0.0 - 52.191.255.255

AS8075

Microsoft

52.236.189.0

52.224.0.0/11

52.224.0.0 - 52.255.255.255

AS8075

Microsoft

94.31.84.0

94.31.80.0/20

94.31.80.0 - 94.31.95.255 

AS60294

Deutsche Glasfaser

104.40.187.0, 104.208.16.0, 104.103.200.0

104.40.0.0/13

104.40.0.0 - 104.47.255.255

AS8075

Microsoft

142.250.185.0

142.250.185.0/24

142.250.0.0 - 142.251.255.255

AS15169

Google LLC

192.168.178.0, 192.168.102.0

192.168.0.0/16

192.168.0.0 - 192.168.255.255

privat

privat

Wenn ich die IP-Adressen auf Provider zuordne, dann landen diese bis auf wenige Ausnahmen bei Microsoft. Ich habe nun nicht die per DNS aufgelösten Adressen auf diese IP-Adressen zugeordnet. Die Verbindung zu Google könnte eine Grundfunktion von Android sein.

UDP

Die Analyse der UDP-Verbindungen ist schneller erfolgt. ich habe danach ein VoIP-Telefonat von einem User1@tenant1 zu User2@tenant2 per VoIP geführt, die aber beide im gleichen LAN waren. Entsprechend konnten die Pakete per UDP klar erkannt werden. Die Audioverbindungen fanden zwischen 192.168.178.31 und 192.168.178.181 statt.

Sie sehen aber auch, dass ein paar Pakete zum Internet zu 52.114.x.x und 94.31.84.x gehen. Das sind Subnetze von Microsoft und Deutsche Glasfaser

IP-Adresse IP-Netz IP-Range ASN Inhaber

52.114.229.8, 52.114.225.67, 52.114.225.69

52.96.0.0/14

52.96.0.0 - 52.115.255.255

AS8075

Microsoft

52.123.159.15

52.120.0.0/14

52.120.0.0 - 52.123.255.255

AS8075

Microsoft

94.31.84.213

94.31.80.0/20

94.31.80.0 - 94.31.95.255 

AS60294

Deutsche Glasfaser

Auch wenn die 52.114.0.0 in "Hongkong" verortet ist, können Sie alleine anhand der Antwortzeit schon sehen, dass das Paket sicher in Europa beantwortet wurde:

88368,209 - 88368,173 = 36ms und damit definitiv zu schnell um nach Asien übertragen zu werden.

Die Adresse im 94er Bereich gehören zu meinen ISP (Deutsche Glasfaser) und dürften meine STUN-Adressen sein, die hier ebenfalls angesprochen werden.

Übrigens hat das Telefone keinerlei IPv6-Paket genutzt, obwohl ich native IPv6 bereitgestellt habe.

SYSLOG

Interessant fand ich, dass das Telefon auch Meldungen per SYSLOG an meinen internen SYSLOG-Server gesendet hat. Es waren aber nur wenige Meldungen:

Anscheinend versucht das Telefon auch einen internen Poly Provisioning-Server anzusprechen und Protokolle dort hin zu senden. So ganz "Teams Only" scheint die Firmware noch nicht zu sein.

Poly Lens Tutorial - Cloud Based Provisioning Server, MS Teams SIP Gateway, and Custom Ringtones
https://www.youtube.com/watch?v=8vyJWRa7JDw

Device Scan

Wie schon beim Lenovo ThinkSmart View auf der Seite Teams Device Security habe ich auch gegen das Poly CCX500 einen einfachen NMAP laufen lassen.

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

Im Gegensatz zum Lenovo ThinSmart View habe ich hier aber zwei Ports gefunden

Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-29 02:02 Mitteleuropäische Sommerzeit
NSE: Loaded 151 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 02:02
Completed NSE at 02:02, 0.00s elapsed
Initiating NSE at 02:02
Completed NSE at 02:02, 0.00s elapsed
Initiating NSE at 02:02
Completed NSE at 02:02, 0.00s elapsed
Initiating ARP Ping Scan at 02:02
Scanning 192.168.178.31 [1 port]
Completed ARP Ping Scan at 02:02, 0.19s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 02:02
Completed Parallel DNS resolution of 1 host. at 02:03, 11.02s elapsed
Initiating SYN Stealth Scan at 02:03
Scanning Poly64167fxxxxxx.fritz.box (192.168.178.31) [65535 ports]
Discovered open port 443/tcp on 192.168.178.31
Discovered open port 10010/tcp on 192.168.178.31
Completed SYN Stealth Scan at 02:03, 7.90s elapsed (65535 total ports)
Initiating Service scan at 02:03
Scanning 2 services on Poly64167fxxxxxx.fritz.box (192.168.178.31)
Service scan Timing: About 50.00% done; ETC: 02:04 (0:00:43 remaining)
Completed Service scan at 02:04, 60.90s elapsed (2 services on 1 host)
Initiating OS detection (try #1) against Poly64167fxxxxxx.fritz.box (192.168.178.31)
Retrying OS detection (try #2) against Poly64167fxxxxxx.fritz.box (192.168.178.31)
Retrying OS detection (try #3) against Poly64167fxxxxxx.fritz.box (192.168.178.31)
Retrying OS detection (try #4) against Poly64167fxxxxxx.fritz.box (192.168.178.31)
Retrying OS detection (try #5) against Poly64167fxxxxxx.fritz.box (192.168.178.31)
NSE: Script scanning 192.168.178.31.
Initiating NSE at 02:04
Completed NSE at 02:04, 12.22s elapsed
Initiating NSE at 02:04
Completed NSE at 02:04, 7.05s elapsed
Initiating NSE at 02:04
Completed NSE at 02:04, 0.00s elapsed
Nmap scan report for Poly64167fxxxxxx.fritz.box (192.168.178.31)
Host is up (0.0022s latency).
Not shown: 65533 closed ports
PORT      STATE SERVICE    VERSION
443/tcp   open  ssl/http   Polycom VVX VoIP phone http config
|_http-favicon: Unknown favicon MD5: 861EB7C7E50D176CA2D63F1C667BF956
| ssl-cert: Subject: commonName=64167FDEE066/organizationName=Polycom Inc.
| Issuer: commonName=Polycom Equipment Issuing CA 2
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-12-17T05:42:24
| Not valid after:  2034-12-17T05:52:24
| MD5:   7236 898c ee31 efe6 b097 82dd dc23 1549
|_SHA-1: a84f 81bf 8ca4 6ec8 e59f 5915 44d7 271f 0341 6fe9
|_ssl-date: 2023-07-29T00:04:42+00:00; -2s from scanner time.
10010/tcp open  ssl/rxapi?
| ssl-cert: Subject: commonName=64167FDEE066/organizationName=Polycom Inc.
| Issuer: commonName=Polycom Equipment Issuing CA 2
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2019-12-17T05:42:24
| Not valid after:  2034-12-17T05:52:24
| MD5:   7236 898c ee31 efe6 b097 82dd dc23 1549
|_SHA-1: a84f 81bf 8ca4 6ec8 e59f 5915 44d7 271f 0341 6fe9
|_ssl-date: 2023-07-29T00:04:39+00:00; -2s from scanner time.

Der Standardport 443 ist die Weboberfläche zur Verwaltung:

Eine kurze Suche im Internet liefert:

Note the default admin password for these phones is ‘456’ and you should be changing this, which is easily done automatically via a Teams Configuration Profile
How to (really) factory reset a Poly CCX 500
https://www.adamfowlerit.com/2021/03/how-to-really-factory-reset-a-poly-ccx-500/#:~:text=Quick%20one%20here%2C,the%20LCD%20display.

Andere Geräte haben vielleicht noch andere Kennworte.

By default, the password is the 14-digit system serial number. You can find the serial number on the label on the back panel of the power data box, as shown in the following figure.
"DEFAULT CONTROL PANEL SOFTWARE PASSWORD FOR THE CX5100 / CX5500 "
https://support.poly.com/support/s/article/knova-19296-default-control-panel-software-password-for-the-cx5100-cx5500#:~:text=In%20order%20to%20make%20changes%20to%20the%20Polycom,the%20password%20is%20the%2014-digit%20system%20serial%20number

Ein Zugriff auf den Port 10010 liefert nur, dass keine Daten gesendet wurden. Laut Internet ist der Port 10010 dem Service "Object REXX" zugewiesen

Welche Funktion dieser erreichbare Port auf dem Telefon hat, konnte ich noch nicht ausfindig machen.

Aber allein die Erreichbarkeit wäre für mich ein Argument, die System in einem VLAN zu verbannen, damit sie nicht von Client oder anderen Systemen erreichbar sind. Für die Funktion mit Microsoft Teams müssen die Endgeräte nicht erreichbar sein.

Zusammenfassung

Beim Poly CCX500 in Verbindung mit einem Teams Benutzer sind mir während der kompletten Zeit keine unerwarteten Verbindungen aufgefallen, die auf eine "Calling Home"-Funktion hinweisen könnten. Sicher wäre zu klären, warum auch der Name "clientservices.googleapis.com" aufgelöst werden muss und warum zwei TCP-Ports erreichbar sind. Dafür gibt es eigentlich keine Begründung.

Das ist natürlich keine Dauerüberwachung oder tiefe Analyse der Firmware auf Lücken und Hintertüren. Sie sollten dennoch die Ratschläge auf Teams Device Security individuell bewerten und die einfache Separierung der Geräte in ein Subnetz mit Access-Policies trennt diese Systeme zuverlässig von ihrem "Datennetzwerk" und kann eine Kommunikation zu unbekannten externen Diensten unterbinden.

Weitere Links