Serie

Dies ist der Auftaktartikel einer zweiteiligen Serie zur Sicherheit von STUN und TURN und beschäftigt sich mit dem Thema der Identifikation von anfälligen Systemen und deren Absicherung.

Datenschutz und Selbstbestimmung über die eigenen Daten sind in Deutschland und Europa ein sehr hoch angesehenes und wichtiges Gut. Unter anderem aus diesem Grund setzen hierzulande seit 2020 immer mehr Unternehmen auf selbst gehostete Videokonferenzsysteme, statt auf meist amerikanische Anbieter wie Cisco Webex oder Microsoft Teams. Insbesondere die Open Source Software Jitsi Meet hat sich hervorgetan und wird oft als Standalone-Lösung oder aber kombiniert mit weiterer Software wie zum Beispiel Matrix genutzt. Damit die Nutzung für jeden jedoch einwandfrei funktioniert, sind meist auch sog. TURN-Server konfiguriert.

Was ist TURN? Und warum kann ein TURN-Server ein Einfallstor sein?

TURN (Traversal Using Relays around NAT) ist eine Erweiterung des STUN-Protokolls. TURN ermöglicht die Kommunikation zwischen zwei Systemen im Internet, die sich nicht direkt erreichen können, z.B. auf Grund von Firewalls oder Routern mit aktiviertem NAT. Dies ist zum Beispiel der Fall, wenn sich der Jitsi Meet Server im internen Netzwerk befindet, und nicht direkt aus dem Internet erreichbar ist, sich jedoch ein Teilnehmer einer Videokonferenz aus dem Internet einwählen möchte. Der TURN-Server nimmt dabei die Position eines Relays (Mittelsmanns) ein. Er ist direkt aus dem Internet erreichbar, und kann zudem den internen Server erreichen. So kann die Verbindung zwischen Teilnehmer und internem Server hergestellt werden.

Position eines TURN-Servers in der DMZ (Quelle: eigene Darstellung)

TURN-Server werden insbesondere für Dienste, die auf WebRTC aufbauen, benötigt. Das sind häufig Anwendungen wie Videotelefone und IP-Telefonanlagen. Folgende Software wird besonders häufig in Kombination mit einem TURN-Server eingesetzt:

  • Jitsi Meet
  • Matrix
  • Nextcloud
  • Big Blue Button
  • Asterisk IP-Telefonanlage

Da TURN eine Erweiterung des STUN-Protokolls ist, wird es in den allermeisten Fällen auf dem STUN-Port 3478 betrieben. Mit dem Online-Dienst Shodan lassen sich so über 100.000 IP-Adressen weltweit mit einem offenen STUN-Port finden, in Deutschland selber über 20.000, von denen über 17.000 die TURN-Erweiterung anbieten. Die Dunkelziffer kann dabei nochmals größer sein, da manche auch den STUN/TURN-Dienst auf einem anderen Port betreiben.

Scan-Ergebnisse für TCP-Port 3478 auf Shodan (Quelle: shodan.io – https://www.shodan.io/search/report?query=port:3478)

Betrachten wir die genutzte Software für TURN-Dienste in Deutschland genauer, fällt auf, dass insbesondere zwei Open-Source-Programme einen Großteil der eingesetzten Software für TURN und STUN ausmachen, Coturn und eturnal:

Eingesetzte TURN-Server-Software laut Banner (Quelle: eigene Recherche, eigene Darstellung)

Die Konfiguration der Software-Lösung von Coturn weist jedoch Fallstricke in der Standard-Konfiguration auf, die, falls nicht abgeändert, zu einem kritischen Einfallstor führen können. Und zwar wird in der Standard-Konfiguration von Coturn auf Github standardmäßig keine Sperrliste für verbotene interne IP-Adressen gesetzt ist. Die werkseitige Konfiguration von eturnal hingegen setzt standardmäßig eine Blacklist, um den Zugriff auf sensible interne Subnetze zu unterbinden.

Diese Standard-Konfiguration von Coturn führt dazu, dass jedes System über den TURN-Server nicht nur mit dem internen Jitsi oder Nextcloud Server kommunizieren kann, sondern mit jedem vom TURN-Server direkt erreichbaren System. Im schlimmsten Fall stellt er also eine direkte Verbindung in das interne, potentiell sensible Netzwerk bereit. Also genau das Herzstück eines Unternehmens, dort, wo Mitarbeiter-PCs sind, vertrauliche Unternehmensdaten liegen und Backup-Systeme und Archive sind.

Normalerweise ist die Kommunikation mit dem TURN-Server nur Systemen mit Zugangsdaten gestattet, wobei auch theoretisch eine anonyme Anmeldung, also ohne Nutzername und Passwort, möglich ist. Die Zugangsdaten verteilt das Video-Konferenzsystem oder andere mit dem TURN-Server kombinierte Software normalerweise automatisch. Das heißt, ein potenzieller Angreifer braucht nichts weiter, als z.B. eine Einladung in eine Videokonferenz, um die Zugangsdaten zum TURN-Server, und damit potenziell die Schlüssel in das interne Unternehmensnetzwerk, ausgehändigt zu bekommen.

Bei genauerer Betrachtung der Konfiguration, welche IP-Adresse der TURN-Server als seine eigene meldet, ist ersichtlich, dass mehrere tausend Systeme in Deutschland einen TURN-Dienst nutzen, der eine interne IP-Adresse hat. Der Dienst verfügt also über einen Zugang in das interne Netzwerk und einen in das Internet. Die Dunkelziffer kann dabei nochmals höher sein, da nur knapp 15.000 der 17.000 deutschen TURN-Server ihre IP-Adresse preisgeben.

Interne IP-Adresse des TURN-Servers laut Banner (Quelle: eigene Recherche, eigene Darstellung)

Wie verhindere ich einen solchen Angriff?

Coturn selber wird in der Regel über eine Datei namens turnserver.conf konfiguriert. Dort sind verschiedenste Flags und Einstellungsmöglichkeiten genannt, um coturn den eigenen Wünschen und Anforderungen entsprechend anzupassen. Die Beispieldatei selbst ist auf dem offiziellen Github-Repository von coturn verfügbar.

In dieser Konfigurationsdatei gibt es zwei Optionen, um IP-Adressen und IP-Adressbereiche zu blocken, oder aber freizugeben, zu denen Coturn hin verbinden darf. Diese Option ist jedoch standardmäßig nicht aktiv und stattdessen auskommentiert, was dazu führt, dass alle Adressen über den TURN-Server aufrufbar sind. Folgende Parameter für die Konfigurationsdatei aktiviert das Blocken von IP-Adressen:

Copy to Clipboard

Die in dem oben beschriebenen Ausschnitt konfigurierten Parameter blockieren das Verbinden von coturn zu ausnahmslos allen IP-Adressen (denied-peer-ip), und fügt im nächsten Schritt nur genaue Definitionen für den ausgewählten Server hinzu, mit dem coturn kommunizieren darf (allowed-peer-ip). Mit dieser Einstellung wird die Sicherheit des TURN-Servers stark erhöht, und die Kommunikation in das interne Netzwerk unterbunden.

Die hier genannte Konfiguration sollte jedoch vor dem produktiven Einsatz ausgiebig in einer sicheren Umgebung getestet werden.

Teil 2

Im zweiten Artikel, der in den kommenden Tagen erscheinen wird, werden wir einen vollständigen Angriff auf einen unsicher konfigurierten TURN-Server vorstellen.

Sollten Sie weitere Fragen haben oder Unterstützung benötigen, kommen Sie gerne auf uns zu.

NSIDE kann Sie zu diesem Thema mit folgenden Dienstleistungen unterstützen:

  • Passive und nicht-intrusive Sicherheitsanalysen (OSINT/Recon)
  • Penetrationstests der öffentlichen Systeme wie STUN/TURN-Server
  • Sicherheitsanalyse der Konfiguration des TURN-Servers
  • Unterstützung bei der sicheren Konfiguration der TURN-Server & Infrastruktur
  • Penetrationstests der externen und internen Infrastruktur