SBC Absicherung

Auf der DEVON 2022 wurde demonstriert, wie ein nicht ausreichend abgesicherter Session Border Controller missbraucht werden kann. Um die erhoffte Aufmerksamkeit zu erreichen, lautete der Vortragstitel auf der Devon " Phreaking 2.0 Abusing Microsoft Teams Direct Routing" und die Heise-Überschrift gleich "Gebührenbetrug und Phishing durch Schwachstelle in Microsoft Teams". Schade nur, dass sich die Autoren damit eher selbst beschädigenm denn es gibt wohlgemerkt diesmal keine Lücke in Microsoft Teams selbst und es wurde auch nicht Direct Routing von Microsoft sondern ein vom Kunden oder Provider selbst bereitgestellter und schwach konfigurierter SBC missbraucht.

Wer einen SBC mit Port 5061 ins Internet stellt und nicht ausreichend absichert und überwacht, sollte sich nicht über fremde Nutzung beschweren.

Die Umgebung

Wer mit Microsoft Teams telefonieren möchte, muss nicht nur eine Microsoft Teams Lizenz mit dem "Phone System"-Zusatz sein eigen nennen, sondern auch eine "Amtsverbindung bereitstellen. Das kann Microsoft über Dialpläne (Calling Pläne) in ausgewählten Ländern machen oder sie bringen ihren eigenen SIP-Trunk mit. Dazu können Sie selbst einen kompatiblen SBC verwenden oder über Dienstleister bereitstellen lassen (Siehe Direct Routing) oder der Dienstleister stellt gleich die komplette Topologie bereit. Siehe Operator Connect.

Eine klassische "Direct Connect"-Verbindung hat folgende Komponenten:

Die Herausforderung dabei ist das Internet, denn weder bei Direct Routing noch Operator Connect können sie ihren SBC in eine private Location bei Microsoft stellen. Die Verbindung zwischen dem Teams SBC und dem Kunden/Provider-SBC erfolgt über das Internet. Die gelbe SIP-Verbindung ist dabei bidirektional:

Angriffsvektor

Im Bild sehen sie schon, an welcher Stelle eine Lücke existieren kann, aber nicht muss. Schauen wir uns die beiden Verbindungsrichtungen an:

  • Eingehende Anrufe
    Der Telefonanruf auf eine "Nummer" landet beim Kunden/Provider-SBC, der dann ein SIP/TLS-Verbindung zur Microsoft Gegenstelle startet und dabei natürlich das Zertifikat prüft. Der Anruf kommt dann bei Teams an. Hier ist die Verbindung sicher, da der anrufende SBC das Zertifikat der Gegenseite prüfen kann (und sollte) und sich auch gegenüber Microsoft mit seinem eigenen Zertifikat ausweist.
  • Ausgehende Anrufe
    Wenn Sie nun von Microsoft Teams einen Anruf in die Welt starten, dann verbindet sich Microsoft Teams über seinen SBC (Links) ebenfalls per SIP/TLS mit dem SBC des Kunden/Providers. Microsoft prüft natürlich das Zertifikat des Kunden-SBC, damit sich da niemand einschmuggelt. Die Frage ist aber ob und wie der Kunden/Provider-SBC sich absichert, dass die Verbindung wirklich von Microsoft kommt.

Wenn der Kunden-SBC nicht sicher konfiguriert ist, dann kann auch ein Angreifer versuchen diese SIP-Verbindung zu missbrauchen.

Das Risiko ist nicht neu und es wäre nicht die erste SIP-Vermittlungsstelle, die mit einem Bein im Internet seht und z.B.: Default Credentials für die Verwaltung genutzt werden oder SIP-Anwender nur schwache Zugangsdaten haben.

Mit DirektRouting muss ein Angreifer also irgendwie ermitteln, wo der SBC des Kunden/Providers steht. Das ist nicht sonderlich schwer, wenn die Standardeinstellungen genutzt werden. Ein Subnet-Scan auf das vermutete Zielnetzwerk und Pot 5061 (SIP/TLS) offenbart sehr schnell "offene" SIP-Systeme. Da liefert schon Shodan (https://www.shodan.io/search?query=port%3A5061) sehr schnell viele Treffer. Selbst wenn Sie einen anderen abweichen Port nutzen, dauert es nur wenig länger, bis ein Scanner auch diesen Zugang findet und verschiedene Protokolle ausführt. Die meisten SBCs erlauben auch OPTIONS oder versuchen einfach einen anonymen INVITE. Wer seinen SBC überwacht, kann solche Versuche genauso gut erkennen, wie Angriffe auf Webserver (Siehe Webserver Hacking).

Der Vortrag auf der DEVCON zeigt genau das: Der Angreifer nutzt SIP um über einen nicht sicher konfigurierten SBC auf fremde Kosten eine Verbindung zu einer Rufnummer aufzubauen. Solcher Missbrauch ist seit Jahren unter der Bezeichnung Phreaking bekannt

Zu Zeiten des Impulswählverfahren konnten geschickte "Hacker" teilweise über den Gabelumschalter eine Rufnummer anwählen. Wenn Sie nun nichts verstanden haben, dann sind sie vermutlich unter 50 Jahre :-). Damals hat man sich dann kostenfreie Ferngespräche oder internationale Verbindungen erschlichen. Heute würde so ein Angreifer natürlich eher "Premium"-Nummern anrufen und gemeinsame Sache mit dem Betreiber machen.

Phreaking 2.0 Abusing Microsoft Teams Direct Routing
https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20presentations/Moritz%20Abrell%20-%20Phreaking%202.0%20-%20Abusing%20Microsoft%20Teams%20Direct%20Routing.pdf

Dieser Missbrauchsvektor ist eigentlich so naheliegend, dass dies noch keiner früher beschrieben hat.

Dennoch ist das Risiko vorhanden und muss beseitigt werden. Es ist ja "nur" ein Konfigurationsfehler.

Absicherung IP-Adresse

Leider macht es Microsoft uns nicht ganz so einfach, da bei Teams sehr viele SBCs betrieben werden die zudem kein gemeinsames Zertifikat nutzen. Ich kann auf meinem SBC daher nicht mal einfach MTLS für SIP erzwingen und das von der Gegenseite vorgewiesene Zertifikat überprüfen. Microsoft scheint sogar verschiedene RootCAs als Aussteller für die Zertifikate zu nutzen und ändert die auch immer mal wieder. Zudem sind die von Microsoft genutzten IP-Adressen recht umfangreich. Dennoch können Sie ihren Service besser absichern, als der verwundbare SBC aus dem DEVCON Vortrag:

Microsoft empfiehlt die Beschränkung des SIP-Zugriffs auf ihren SBC auf zwei Quell-IP-Adressen:

Quelle: https://docs.microsoft.com/de-de/microsoftteams/direct-routing-plan

Auf der "What's New" Seite vom August 2022 stand auch die Empfehlung, diese Adressen in ACL-Regeln einzubauen.

Verwenden Sie die empfohlenen Subnetze (52.112.0.0/14 und 52.120.0.0/14) für alle Klassifizierungs- oder ACL-Regeln.
Quelle: le: https://docs.microsoft.com/de-de/microsoftteams/direct-routing-whats-new

Die gleichen IP-Adressen hat auch Audiocodes in seiner Dokumentation veröffentlicht. Sie können Audiocodes nun natürlich vorwerfen, dass diese zusätzliche Konfiguration nur als "Optional" in der Überschrift gekennzeichnet ist:


Quelle: https://www.audiocodes.com/media/13253/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-enterprise-model-configuration-note.pdf Seite 46

Zusätzlich war der Fehler des zu großen Subnetz natürlich noch in den Classification Rules beschrieben:


Quelle: https://www.audiocodes.com/media/13253/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-enterprise-model-configuration-note.pdf Seite 44

Bei dem SBC im DEVCON-Vortrag war im SBC der Adressbereich von 52.0.0.0/8 zugelassen, so dass der Angreifer einfach eine VM in Amazon AWS mit einer IP-Adresse aus dem Bereich nutzen konnte, um eine TCP-Verbindung aufzubauen. Wenn der SBC dann nicht noch das Zertifikat angefordert und überprüft hat, konnte eine fremde Person darüber telefonieren

Ich hoffe doch, dass sie ihren SBC mit engen IP-Restrictions betreiben und MTLS erzwingen. Dies kann der SBC selbst oder auch eine vorgelagerte Firewall für sie übernehmen.

Update Audiocodes

Am 13. Sep wurde ich von Audiocodes angeschrieben und darüber informiert, dass Audiocodes eine Classification Rule für den SBC veröffentlicht, um eine Nutzung aus anderen 52er Subnetzen zu unterbinden.

[ Classification ]
FORMAT Classification_Index = Classification_ClassificationName, Classification_MessageConditionName, Classification_SRDName, Classification_SrcSIPInterfaceName, Classification_SrcAddress, Classification_SrcUsernamePrefix, Classification_SrcHost, Classification_DestUsernamePrefix, Classification_DestHost, Classification_ActionType, Classification_SrcIPGroupName;
Classification 1 = "Teams_52_112", "Teams-Contact", defaultSRD, sipInterface1, "52.112.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
Classification 2 = "Teams_52_113", "Teams-Contact", defaultSRD, sipInterface1, "52.113.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
Classification 3 = "Teams_52_114", "Teams-Contact", defaultSRD, sipInterface1, "52.114.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
Classification 4 = "Teams_52_115", "Teams-Contact", defaultSRD, sipInterface1, "52.115.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
Classification 5 = "Teams_52_120", "Teams-Contact", defaultSRD, sipInterface1, "52.120.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
Classification 6 = "Teams_52_121", "Teams-Contact", defaultSRD, sipInterface1, "52.121.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
Classification 7 = "Teams_52_122", "Teams-Contact", defaultSRD, sipInterface1, "52.122.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
Classification 8 = "Teams_52_123", "Teams-Contact", defaultSRD, sipInterface1, "52.123.*.*", "*", "*", "*", "teams-sbc.your.domain.com", 1, "Teams";
[ \Classification ]

Zudem werden die Konfigurationsanleitungen kurzfristig überarbeitet, so dass auch dort die engeren Netzwerke nur nur aufgeführt, sondern auch nicht mehr "optional" sind. Allerdings muss der Administrator dies dann immer noch umsetzen.

Absicherung TLS

Die zweite Schutzfunktion besteht bei der strengen Prüfung der aus Sicht des Kunden/Provider-SBC von Teams eingehenden Verbindung mittels MTLS. Wenn Microsoft anhand des Zertifikats ihres SBC die Zuordnung zum Tenant macht, dann können Sie in die Gegenrichtung auch von Microsoft verlangen, dass Sie per SIP/MTLS nachweisen, dass hier wirklich Microsoft Teams eine Verbindung aufbaut. Sie sollten dennoch zusätzlich die IP-Beschränkung nutzen, einfach um Störer sehr früh ins Leere laufen zu lassen. Damit das aber funktioniert, muss ihr SBC natürlich der RootCA vertrauen.

If Mutual TLS (MTLS) support is enabled for the Teams connection on the SBC, then you must install the Baltimore CyberTrust Root and the DigiCert Global Root G2 certificates in the SBC Trusted Root Store of the Teams TLS context. (This is because the Microsoft service certificates use one of these two root certificates.) To download these root certificates, see Office 365 Encryption chains
https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#public-trusted-certificate-for-the-sbc

Passend schreibt Audiocodes dazu, dass in der Konfiguration natürlich MTLS zu aktivieren ist.


Quelle: Connecting AudioCodes' SBC to Microsoft Teams Direct Routing
https://www.audiocodes.com/media/13161/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-hosting-model-configuration-note.pdf Seite 28

 

Auch hier beschreibt der DEVCON-Autor, dass diese beiden RootCAs natürlich sehr weitläufig verwendet werden und es auch in der Vergangenheit schon passiert ist, dass eine der Issuing-CAs bei der Überprüfung geschlampt hat. Theoretisch könnte ein Angreifer also versuchen, ein Zertifikat für den Namen "sip.pstnhub.microsoft.com" zu erhalten.

Das "Problem" ist aber genereller Natur und dann würde ich vielleicht diese PKI-Schwäche für andere lohnendere Angriffe (Code Signing, Banking-Webseiten etc.) verwenden.

Leider ist es nicht so einfach, die von Microsoft bei SIP/MTLS verwendeten Zertifikat über Certificate-Pinning zu binden. Auch veröffentlicht Microsoft die genutzten Zertifikate bzw. deren Hashwerte nicht per

DNSSEC und DANE/TLSA aber der Aufwand wäre zu hoch und zudem müsste ein SBC dann DNSSEC nutzen und die komplette Topologie vorhanden sein.

Aber wenn ihr SBC eine Prüfung des CN/SAN-Eintrag leisten kann, dann sollten Sie nach folgendem Namen suchen.

sip.pstnhub.microsoft.com

Die Sicherheit könnte man etwas erhöhen, wenn der SBC nicht der RootCA sondern nur der Issuing-CA vertraut. Das ist aber ein unübliches Verhalten, das Gültigkeitsdauer einer IssuingCA meist kürzer ist. Sollte also jemand ein Zertifikat mit dem Namen unrechtmäßig erhalten, dann fällt dies schnell auf und die IssuingCA kann das Zertifikat zurückziehen oder die RootCA beendet das Geschäftsmodell der IssuingCA. In der Vergangenheit ist das auch schon passiert.

Connecting AudioCodes' SBC to Microsoft Teams Direct Routing
https://www.audiocodes.com/media/13161/connecting-audiocodes-sbc-to-microsoft-teams-direct-routing-hosting-model-configuration-note.pdf

Nummernsperrung

Losgelöst von der IP-Adress- und TLS-Thematik können Sie natürlich auch überlegen, gewisse Rufnummern pauschal zu sperren. So sind teure Anrufe zu "Televoting"- oder "Premium"-Nummern" im In- und Ausland meist keine legitimen Ziele. Auch Schiffsfunk und Satelliten-Rufnummern werden von Firmen eher selten angerufen. In den Sonderfällen kann auch ein Mobiltelefon genutzt werden. So können Sie aber im SBC die Anwahl solcher Rufnummern über Regeln entweder unterbinden oder auf eine eigene Rufnummer umschreiben. So können sie sehr schnell mitbekommen, wenn jemand solche Rufnummern anrufen möchte.

Logging/Reporting/Monitoring

Generell ist es natürlich eine wichtige Funktion, ihre Systeme aktiv zu überwachen. Bei einem SBC sind Werte wie "Anrufe pro Zeiteinheit" oder "Gesprächsminuten pro Zeiteinheit", "Anzahl der Gespräche länger als z.B. 4 Stunden" gut geeignete Counter, um ungewöhnliches Verhalten früh zu erkennen. Ihre Monitoring-Lösung muss nur die "üblichen Werte" nach Tageszeit und Wochentag ermitteln und bei Abweichungen alarmieren.

 

Auch eine Protokollierung der CDR-Datensätze z.B. per SYSLOG ist ein billiger und einfacher Weg, Missbrauch nachzuvollziehen. Da bei dem oben beschrieben Angriff die Verbindung nicht im Teams CQD-Reporting erscheinen, müssen Sie auf die Einzelverbindungsnachweise ihres TK-Providers oder des SBCs setzen.

Einschätzung

Wenn Sie ihre SBC Konfiguration mit Umsicht umsetzen und die nur als optional gekennzeichneten Firewall-Filter umsetzen, dann sollte ihnen nichts passieren. Aber gegen Fehlkonfigurationen und unsicheren Regeln in einem SBC hilft nur ein sorgfältiges Design und Audit. Versetzen Sie sich auch einmal in die Rolle eines Angreifers: Wo würden Sie versuchen ihren Vorteil zu erhalten?

Eine Sicherheitslücke würde ich weder bei Microsoft noch Audiocodes sehen aber es kann ein Weckruf sein, die Konfiguration zu prüfen und das Monitoring zu erweitern. Vielleicht kommt doch einmal eine Lücke, die heute noch nicht erkannt ist. Die Lücke betrifft übrigens alle mit DirectRouting nutzbaren SBCs und nicht nur Audiocodes. Die Empfehlungen einer zusätzlichen Authentication würde ich nicht mitgehen, denn MTLS ist im Prinzip sicher. Dann würde ich eher das Prinzip der PKIs in Frage stellen und mich Richtung DNSSEC und DANE/TLSA bewegen.

Weitere Links