Gebührenbetrug und Phishing durch Schwachstelle in Microsoft Teams

Durch eine Schwachstelle in MS Teams können Angreifer Firmen unter anderem um Telefoniegebühren betrügen. Administratoren können sich jedoch gezielt schützen.

In Pocket speichern vorlesen Druckansicht 11 Kommentare lesen
Münzfernsprecher dessen Gehäuse fehlt, so dass die Innereien sichtbar sind

(Bild: Daniel AJ Sokolov)

Lesezeit: 4 Min.
Von
  • Benjamin Pfister

Eine Schwachstelle in der Telefonieintegration Direct Routing von Microsoft Teams hat der deutsche IT-Security-Consultant Moritz Abrell von der Firma SySS gefunden: Aufgrund unzureichender Authentifizierungsmethoden von Seiten Microsoft ist die Software anfällig für Gebührenbetrug. Die Schwachstelle wurde auf der diesjährigen DEF CON präsentiert.

MS Teams umfasst mit der passenden Lizenz und einem zertifizierten Enterprise Session Border Controller, also einer Sicherheits- und Steuerungskomponente für VoIP-Netzwerke, eine Integration ins öffentliche Telefonnetz. Häufig genutzte Enterprise Session Border Controller (E-SBC) sind die Produktreihe Mediant des Herstellers Audiocodes. Mit ihr konnte Abrell die Schwachstelle aufdecken.

Möchte ein Teams-Nutzer des Unternehmens mit einer externen Rufnummer telefonieren, sendet die Software über einen zuvor konfigurierten SIP-Trunk, also eine logische Verbindung für multiple Anrufe zwischen SIP-Endpunkten, den Anruf an den E-SBC. Er prüft den eingehenden Anruf durch eine sogenannte Klassifizierung und leitet ihn gemäß der konfigurierten Anrufrouting-Regeln weiter. Jedoch sollte sichergestellt sein, dass der Anruf ausschließlich aus einer vertrauenswürdigen Quelle angenommen und weitergeleitet wird. Als Prüfregel empfahl der Hersteller laut Abrell zunächst nur, dass der Ziel-FQDN im SIP-Request dem des SBCs entspricht und dass im SIP Contact Header pstnhub.microsoft.com steht. Diese Daten sind jedoch leicht manipulierbar: Prüfungen des Common-Name- oder Subject-Alternative-Name-Attributs des Zertifikats des SBCs über Tools wie OpenSSL stellen diese Informationen einfach zur Verfügung.

Mit einem selbstsignierten Zertifikat und dem korrekten Setzen von Header-Daten gelang es Abrell, sich als valider SIP-Request von MS Teams auszugeben und in Folge externe Telefongespräche zu führen. Bei der Anwahl von Mehrwertrufnummern, die gegebenenfalls vom Angreifer kontrolliert werden, oder Auslandstelefonaten könnte dies zu einem Gebührenbetrug führen. Aber auch Phishing-Attacken über die Vortäuschung anderer Quellrufnummern könnten die Folge sein.

Im Responsible-Disclosure-Verfahren ergänzte der Hersteller gemäß Erläuterungen von SySS seine Sicherheitsempfehlungen um einen IP-Filter für die Quell-IP-Adressen von MS Teams zum Klassifizieren von Anrufen, bevor eine Weiterleitung an den Telefonie-Provider erfolgt. Jedoch enthielt die Empfehlung den großen IPv4-Adressblock 52.0.0.0/8 von AWS, der auch viele weitere Software neben Teams enthält. Zusätzlich gab es die Empfehlung einer bidirektionalen TLS-Authentifizierung der SIP-Nachrichten, was grundsätzlich eine gute Idee ist.

Jedoch muss der SBC dazu zwei Stammzertifizierungsstellen vertrauen: DigiCert Global Root G2 und Baltimore CyberTrust Root. Es reicht, ein Zertifikat für einen beliebigen FQDN von diesen Zertifizierungsstellen vorzuweisen. Somit wäre die Attacke immer noch möglich, wenn man lediglich ein Zertifikat für Domains unter eigener Kontrolle von einer der genannten Root CAs vorweisen kann. Ein Filter auf Zertifikate mit FQDNs von MS Teams im CN oder SAN Attribut wäre hier angebrachter, jedoch nicht mit allen Produkten umsetzbar. Eine dedizierte CA wäre eine zusätzliche Alternative.

Filter auf bestimmte Quellnummern sollen laut Herstellerempfehlung weitere Absicherung bringen. Jedoch lassen sich die Quellnummern auch häufig aus Webseiten oder öffentlichen Telefonverzeichnissen auslesen. AudioCodes fügte laut Abrell im Nachgang an das Responsible Disclosure noch eine verschärfte eingehende Firewall-Regel für den E-SBC für SIP und die IPv4-Adressblöcke 52.112.0.0/14 und 52.120.0.0/14 in seine Sicherheitsempfehlungen ein.

Um die eigene Infrastruktur vor der Schwachstelle zu schützen, sollten Teams-Administratoren jetzt folgende Gegenmaßnahmen treffen:

  • Eingehende restriktive IP-Filter auf die IP-Adressblöcke 52.112.0.0/14 & 52.120.0.0/14 für die SIP-Kommunikation mit Teams Direct Routing
  • Einsatz von Mutual TLS Authentication und falls möglich Filter auf den Subject Alternative Name sip.pstnhub.microsoft.com im Zertifikat
  • Limitieren der maximalen Anrufdauer (mit Unternehmensbedürfnissen abgleichen)
  • Restriktive Rechtevergabe für Anrufe zu Mehrwert- und Auslandsrufnummern
  • Quellrufnummernvalidierung durchführen
  • Regelmäßiges Auswerten von Logs auf Anomalien

Weitere technische Details zur Schwachstelle finden sich im Vortrag Abrells auf der DEF CON sowie im Blogeintrag von SySS.

(fo)