IP-Adressen vertrauen

Als Office 365 Admin kennen sicher die von Microsoft veröffentlichten IP-Adressen. Aber können Sie diesen blind vertrauen? Ist denn sichergestellt, dass hinter den UDP-Servern von Microsoft Teams auch wirklich nur vertrauenswürdige Teams-Server auf Verbindungen warten?

In weniger als 24h nach dem diese Seite öffentlich war, habe ich folgende Antwort von Microsoft bekommen:
"Die Rückschlüsse zur Exklusivität des IP Ranges ist so leider nicht richtig. Alle Optimized-Kategorie Endpunkte sind garantiert exklusiv für den jeweiligen Service und kein anderer Dienst, selbst innerhalb von Microsoft, kann diesen allokieren. Richtig ist, dass Teams auf Azure gehosted ist, daher tauchen die Ranges in deren Listen auch auf. Aber keine VM oder anderer Azure Dienst außerhalb von Teams kann IPs aus der ID11 zugewiesen bekommen. Die sind fix allokiert und geblockt."

Damit sind meine Aussagen auf dieser Seite so nicht mehr richtig. Ich lasse Sie aber als grundsätzliche Betrachtung der Teams-Kommunikation dennoch online und addiere nur diesen Header und am Ende die Risikoabschätzung.

Beispiel Teams

Beim Zugriff auf Office 365 Dienste, die HTTPS über TLS 1.2 und früher als Protokoll nutzen, kann eine Firewall hat den TLS-Handshake betrachten und sowohl den angefragten Namen des Clients als auch das gelieferte Zertifikat des Servers analysieren und basierend darauf die Verbindung zulassen oder verhindern. Sie können die Pakete auch über einen HTTP-Proxy leiten, der die Verbindung sogar aufbrechen und dann den Inhalt analysieren kann. Das macht bei MAPI/HTTP naturgemäß wenig Sinn aber Zugriffe auf die Office 365 Dienste möchte man ja eh "schnell" vorbei lassen und gar nicht inspizieren.

Es geht um die anderen Verbindungen zu weniger bekannten Diensten oder Dienste, die kein HTTPS mit Zertifikat nutzen. Zu denen zählt z.B. Teams. Hier gibt es eine ganz wichtige Quelle


https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?#skype-for-business-online-and-microsoft-teams  

Gerade die Regel "ID=11" ist hier interessant, da Sie die erforderlichen Freischaltungen für Audio/Video beschreibt.

Sonderfall UDP

Fast alle anderen Regeln nutzen Port 80/HTTP oder 443/HTTPS aber hier kommt UDP zum Einsatz. Wer sich mit VoIP nicht auskennt, könnte fragen, warum hier das angeblich "unsichere" und von Firewall-Admins gehasste Protokoll UDP zum Einsatz kommt, wo doch TCP alle Vorzüge einer kontrollierten Verbindung bietet, z.B. bekommt der Empfänger die Pakete in der richtigen Reihenfolge und ohne Verluste übertragen.

Und nun denken Sie einmal an ein Meeting mit der Übertragung Audio oder Video. Natürlich verteilen YouTube, Netflix u.a. ihre Video-Streams per HTTPS/TCP, weil so die Kompatibilität maximiert ist. Allerdings geht es hier nicht um Realtime, was sie schon beim Fussball-gucken per IP-TV bemerken. Ihr Nachbar am analogen Radio jubelt schon, während Sie noch den Anstoß sehen. Streams lebt vom Zeitversatz und dass der Empfänger einige Sekunden oder mehr auf Vorrat puffert und so Schwankungen oder selbst kurze Unterbrechungen überbrückt. Betrachten Sie doch mal ein YouTube-Video und trenne Sie das Netzwerk. Bei mir läuft das Bild immer noch viele Sekunden weiter.

Das ist bei einer Teams-Konferenz natürlich Unfug. Hier macht es keinen Sinn, Audio- und Video-Pakete über eine TCP-Verbindung zu übertragen, die verlorene Pakete wieder nachfordert. Was bringt mit das Paket mit dem Ton-Ausschnitt oder dem Bildsegment, welches mittlerweile schon in der Vergangenheit liegt? Zudem kann die VoIP-Lösung so nicht erkennen, ob Pakete verloren gegangen sind und daraus Rückschlüsse auf die Bandbreite und Qualität ziehen und seine Bildraten anpassen.

Insofern sollte nun klar sein, dass für Audio/Video-Übertragungen in "Echtzeit" bevorzugt UDP zum Einsatz kommt. Teams ist natürlich pfiffig und wenn UDP nicht möglich ist, dann wird auch Teams versuche, die Informationen über HTTPS zu übertragen. Aber das dann natürlich nachteilige Effekte, die gerade bei schlechteren Verbindungen, speziell mit Paketverlusten, sich sogar verstärken.

Schnittstelle Firewall

Also schalten wir in der Firewall nun den Zugang entsprechend frei, z.B. mit Regeln wie.

SourceNet        DestinationNet    Proto  Port       Decision
10.0.0.0/8       13.107.64.0/18     UDP   3478-3481   Allow+NAT
10.0.0.0/8       52.112.0.0/14     UDP   3478-3481    Allow+NAT
10.0.0.0/8       52.120.0.0/14     UDP   3478-3481    Allow+NAT

Jede Firewall hat hier seine eigene Syntax aber die Denkweise ist deutlich. Die Client nutzen die Firewall als Default-Gateway und diese setzt ausgehende Pakete per NAT um. Bei Microsoft kommt dann das Paket mit einer offiziellen "IP-Adresse:Port" der Firewall an und die Rückantwort wird von der Firewall dann wieder an die interne IP-Adresse weiter gegeben.

Da es sich hierbei um UDP-Pakete handelt, in denen Sprache und Bilder per SRTP verschlüsselt übertragen werden, kann die Firewall nicht wirklich reinschauen. Sie kann natürlich das Paket als solches analysieren und erkennen, dass es SRTP ist und auch der Codec wird noch sichtbar aber die Payload ist unbekannt. Hier ein exemplarischer WireShark-Trace auf UDP 3479 (Audio):

Eine Firewall kann also schon das UDP-Paket anschauen und es als "STUN"-Paket erkennen

Aber weiter rein schauen, kann die Firewall nicht. Es gibt hier auf dem UDP-Kanal auch keinen "Handshake", bei dem Zertifikate oder Schlüssel ausgetauscht werden. Auch die TURN-Authentifizierung am Anfang ist ein Einmal-Kennwort, da Teams, wie auch Skype for Business, den eigentlichen Handshake in dem Signalisierungskanal (SIP oder HTTP).

Wer für die Sicherheit zuständig ist, weiß nun um die Payload bei diesen UDP-Ports und wenn die Firewall eine genauere Inspektion unterstützt, kann sie natürlich auch "STUN/TURN" als einzig erlaubtes Protokoll innerhalb dieser UDP-Verbindung erzwingen.

Teams-IP sind nicht exklusiv

Wenn ihre Firewall einen so erweiterten Schutz nicht unterstützt, dann könnten Sie sich allein auf die IP-Adressen beschränken. Schließlich veröffentlicht Microsoft ja diese Adressen für die Nutzung mit Teams. Allerdings ist das nicht die ganze Wahrheit, wenn diese Adressen werden natürlich von Teams genutzt. Aber andere Diensten könnten diese Adressen auch nutzen.

Microsoft veröffentlicht unter einer anderen URL auch noch die IP-Adressen die von Azure-Systemen genutzt werden.

Azure IP Ranges and Service Tags – Public Cloud
https://www.microsoft.com/en-us/download/confirmation.aspx?id=56519

Über diesen Download-Linke bekommen Sie eine JSON-Datei mit viel mehr IP-Adressen. Hier beschreibt Microsoft alle IP-Adressen der "Azure Public Cloud". Diese Adressen werden den verschiedenen Diensten in Azure zugewiesen. Natürlich laufen auch die Teams-TURN-Server auf Azure und daher erscheinen natürlich auch die IP-Bereiche der Teams Server in dieser Liste. Hier ein Auszug:

...
"name": "AzureCloud.brazilsouth",
"id": "AzureCloud.brazilsouth",
"properties": {​​​​​​​
   "changeNumber": 14,
   "region": "brazilsouth",
   "regionId": 9,
   "platform": "Azure",
   "systemService": "",
      "addressPrefixes": [
         "52.112.118.0/24",
         "52.113.132.0/24",
         "52.114.194.0/23",
         "52.114.196.0/22",
         "52.114.200.0/22", 
...

Wenn Sie nun genau hinschauen. dann sehen Sie hier Adressen , die eine Teilmenge des Teams-Bereichs "52.112.0.0/1" sind. Es gibt noch viel mehr Treffer und die Datei ist lange.

Ich interpretiere diese Liste aber so, dass z.B. der Adressbereich "52.112.0.0/1", den Microsoft für Teams veröffentlicht, nicht exklusiv für Teams reserviert ist

Auch andere Dienste können eine IP-Adresse aus dem Bereich bekommen. Nun ist es meiner Meinung nach nicht möglich, selbst eine öffentlichen IP-Adresse vorzugeben. Wenn ich als  Betreiber eines Service in Azure eine statische IP-Adresse möchte, dann kaufe ich diese und erhalte eine freie Adresse von Microsoft.

Es könnte theoretisch schon passieren, dass eine neue VM zufällig eine IP-Adresse bekommt, die auch im Bereich von Microsoft Teams liegt. Damit hätte dann auch dieses System einen "Vertrauensvorschuss" hinsichtlich des Protokolls UDP mit Port 3478-3481.

TLS statt UDP?

Wenn Sie nun glauben, dass der Verzicht auf UDP mit einem Wechsel auf TLS einen Vorteil bringt, dann schauen Sie sich diesen Trace an. Ich habe einfach ausgehende Pakete per 3478-3481/UDP auf der Firewall geblockt und natürlich konnte Teams dann diesen Weg nicht mehr nutzen. Als Fallback nutzt Teams dann TLS über 443/TCP. Sie sehen hier den SYNC/SYNCACK/ACK-Handshake am Anfang und das Client-Hello/Server-Hello. Allerdings sendet der Client-Hello keinen "Hostnamen" mit und auch im Server-Hello kommt nur ein Crypto-Verfahren ohne Zertifikat

Das kann eine Malware auch und bietet daher keinen weiteren Schutz. Hier könnte nur Microsoft den Schutz-Level anheben indem.

  • Der Client einen SNI-Feld beim Client-Hello sendet
  • Der Server beim Server-Hello seinen Namen mit Zertifikat bestätigt.
    So könnte die Firewall zuverlässig zumindest bis TLS 1.2 den Handshake begutachten

Fragen sie mich bitte nicht, warum Microsoft hier kein TLS 1.2 nutzt sondern noch TLS 1.0

Risikoeinschätzung

In weniger als 24h nach dem diese Seite öffentlich war, habe ich folgende Antwort von Microsoft bekommen:
"Die Rückschlüsse zur Exklusivität des IP Ranges ist so leider nicht richtig. Alle Optimized-Kategorie Endpunkte sind garantiert exklusiv für den jeweiligen Service und kein anderer Dienst, selbst innerhalb von Microsoft, kann diesen allokieren. Richtig ist, dass Teams auf Azure gehosted ist, daher tauchen die Ranges in deren Listen auch auf. Aber keine VM oder anderer Azure Dienst außerhalb von Teams kann IPs aus der ID11 zugewiesen bekommen. Die sind fix allokiert und geblockt."

Damit sind meine Aussagen auf dieser Seite so nicht mehr richtig. Ich lasse Sie aber als grundsätzliche Betrachtung der Teams-Kommunikation dennoch online und addiere nur diesen Header und am Ende die Risikoabschätzung.

Die IP-Adressbereiche für Teams Media sind sehr umfangreich und es daher durchaus realistisch, dass hier auch eine VM eines anderen aktiv ist. Allerdings wird kein Client je versuchen diese VM per 3478-3481 anzusprechen, da das System ja nicht durch die Signalisierungsplattform angeboten wird. Als Betreiber der VM habe Sie also damit erst einmal kein Problem.

Kritischer könnte es werden, wenn der Besitzer einer Azure-VM mit einer Adresse aus dem Bereich um diese Besonderheit der öffentlichen IP-Adresse weiß und dieses Wissen nun ausnutzt. Er könnte diesen Server z.B. als Command&Control-System (C&C) betreiben und seine Malware bei Firmen darauf auslegen, über UDP im Stiele einer VoIP-Anwendung zu kommunizieren. Wenn die Malware dann auch ein "STUN"-Paket aufbaut, wäre so ein transparenter Kanal denkbar.

Es bleibt, wie immer, ein Restrisiko, wenn Dienste aus der Cloud genutzt werden. Bei HTTPS kann ein Proxy oder eine Firewall noch den TLS-Handshake bis TLS 1.2 überprüfen aber bei TURN über UDP gibt es keine Möglichkeit das Ziel z.B.: per Zertifikat zu prüfen. Auch der Verzicht auf UDP hilft nicht weiter, da auch beim TLS-Handshake der TURN-Verbindung keine Zertifikate des Servers gesendet werden.

Sie sollten daher alle Möglichkeiten nutzen, auf dem Client solche Malware zu erkennen oder direkt zu verhindern. Lösungen gibt es dazu genug, z.B. Cloud App Security, Applocker u.a.

Weitere Links