Serie

Dies ist der weiterführende Artikel einer zweiteiligen Serie zur Sicherheit von STUN und TURN und beschäftigt sich mit dem Thema eines Beispiel-Angriffs auf ein anfälliges System und die möglichen Auswirkungen. Den ersten Teil finden Sie hier.

TURN-Server sind in unserer modernen Zeit kaum mehr wegzudenken. Für viele aktuelle Softwareprodukte die auf WebRTC setzen, werden TURN-Server als Komponente eingesetzt, um die Kommunikation von Client und Servern über NAT-Grenzen hinweg zu realisieren. So werden TURN-Server oft in Kombination mit Nextcloud Talk, Jitsi Meet, Matrix, SIP-Telefonanlagen und vielen weiteren Produkten betrieben. Ein TURN-Server kann dabei jedoch bei einer Fehlkonfiguration eine potenzielle Schwachstelle darstellen, wie in Teil 1 der Artikel-Reihe bereits dargestellt wurde. In dem ersten Teil können Sie zudem eine Anleitung zur Vermeidung der Schwachstelle anhand des Beispiels des Open-Source TURN-Server Coturn finden.

In diesem Artikel wird anhand eines Beispiel-Servers dargestellt, wie ein potenzieller Angriff auf einen TURN-Server aussehen kann, und warum genau dies so kritisch ist.

Hinweis

Der Test wurde in einer dedizierten Test-Umgebung durchgeführt. Angriffe auf Systeme ohne vorherige Erlaubnis sind illegal und dürfen nicht durchgeführt werden.

Szenario: Jitsi Meet mit TURN-Server

Als Ausgangspunkt dient uns ein Jitsi Meet Server, den wir in unserem hypothetischen Szenario über OSINT (Open Source Intelligence), z.B. via Shodan, über offene Web-Ports, als auch einen offenen STUN-/TURN-Service und einem DNS-Eintrag mit „Jitsi“ im Namen identifiziert haben. Wenn wir die Webseite aufrufen, werden wir mit einer einfachen Jitsi-Startseite begrüßt.

Auf der Seite selber treten wir nun einem Raum bei, in diesem Fall können wir uns selber einen Raum, z.B. „plasticfork“, erstellen und beitreten. Manchmal ist Jitsi allerdings auch so konfiguriert, dass wir nur mit Anmeldedaten, bzw. Einladung einem Raum beitreten können. Doch auch in so einem Fall kann der Angriff erfolgen, da wir zum Erlangen der Zugangsdaten zum TURN-Server nur den Raum betreten müssen. Anschließend können wir mit einem Interception-Proxy, z.B. mit der Burp Suite von Portswigger, die Zugangsdaten einsehen (hier gelb hinterlegt).

Diese Zugangsdaten für den TURN-Server können wir nun für unseren Angriff auf die internen Systeme nutzen. Zwar sind die Zugangsdaten nur zeitlich begrenzt gültig, in diesem Fall 12h, danach können einfach neue generiert werden. Um TURN-Server zu testen, gibt es verschiedene Tools mit unterschiedlichen Funktionsumfängen. Wir setzen in diesem Fall auf das Open Source Tool „Stunner“ des Entwicklers FireFart, welches über das offizielle Github-Repository bezogen werden kann.

Das Tool Stunner

Stunner selber verfügt über verschiedene Modi, um den großen Funktionsumfang auszunutzen. Die Modi werden direkt als erstes Argument angegeben. In der Regel werden valide Zugangsdaten benötigt. Folgende Optionen bietet Stunner an:

  • info: Gibt bei erfolgreicher Verbindung Informationen über den STUN-/TURN-Server zurück, wie z.B. die unterstützten Funktionen
  • brute-transport: Enumeriert alle verfügbaren Protokolle zu internen Systemen, die vom Server unterstützt werden.
  • brute-password: Passwort-Bruteforce-Angriff für den angegebenen Usernamen gegen den Server
  • memoryleak: Exploit für einen Datenleak in Ciscos TURN-Software.
  • range-scan: Test, Verbindungen zu internen und limitierten IP-Adressen aufzubauen. Ist eine IP erreichbar, erlaubt der Server die Weiterleitung des Traffics an diese IP.
  • socks: Sehr spannender Modus, der einen lokalen socks5-Proxy startet, und durch den eingehenden TCP-Traffic über den TURN-Server geleitet wird. Damit kann mit verschiedenen Tools direkt auf interne Adressen zugegriffen werden.
  • udp-scanner: Scannt DNS und SNMP-Ports angegebener Ziele durch den TURN-Server. Für SNMP wird ein Community-String benötigt.
  • tcp-scannner: Scannt angegebene Ziele und Ports durch den TURN-Server mittels HTTP-Request. HTTPS wird dabei nicht unterstützt.

Der Angriff über den TURN-Server

Was uns jetzt noch für einen Angriff fehlt, ist eine erreichbare interne Adresse. Dies können wir zum Beispiel mittels Stunner, und zwar entweder per Info-Modul oder per Range-Scan-Modul, oder auch mit OSINT herausfinden. In unserem Fall reichte das Info-Modul von Stunner aus, da darüber unter „RESPONSE-ORIGIN“ die STUN-Server oft ihre interne IP zurückgeben.

Jetzt, wo wir alle Informationen zusammen haben, können wir Stunner starten. Zuerst fangen wir mit einem TCP-Scan an, um zu schauen, ob alles funktioniert, und typische Ports offen sind.

Es scheint soweit alles zu funktionieren, wir können das interne System und Ports dort über den TURN-Server erreichen. Als nächstes starten wir Stunner dann mit dem mächtigen Socks-Modul, um das wahre Potenzial von Stunner voll auszuschöpfen.

Um den Socks-Proxy zu nutzen passen wir unsere lokale Proxychains-Konfiguration an. Damit können wir die meisten Programme unter Linux über den Proxy schleusen. Um die Angriffsoberfläche des internen Servers zu ermitteln, führen wir mit Nmap über Proxychains einen Port-Scan auf das System durch, und können im Anschluss falls wir einen verwundbaren Dienst finden diesen angreifen.

Wie wir sehen, sind auf diesem Server selber intern sehr viele verschiedene Dienste am Laufen, mehr als erwartet. Was uns hierbei besonders ins Auge sticht, ist Port 4646. In Kombination mit Port 5000 (Docker-Registry) könnte dieser Port auf eine Hashicorp Nomad Installation hinweisen. Durch Aufrufen des Ports mit Firefox über den Socks-Proxy können wir dies kontrollieren.

Wie gedacht handelt es sich um die Software Hashicorp Nomad. Diese Software wird zur Orchestrierung von Containern eingesetzt, und kann oftmals direkt Befehle auf dem System ausführen. In diesem Fall ist sie sogar ohne Authentifizierung umgesetzt, was wir für unsere Zwecke ausnutzen können.

Das Metasploit Framework verfügt dazu passend über ein entsprechendes Exploit-Modul namens „nomad_exec“, um direkt Code über Hashicorp Nomad auszuführen. Dieses erstellt einen neuen Job und führt darüber direkt Code aus.

Zum Ausnutzen starten wir Metasploit, wählen das Modul aus, und tragen in den Modul-Optionen die entsprechenden Werte ein. Nicht vergessen dürfen wir dabei den Socks-Proxy, um mit dem Dienst kommunizieren zu können.

Als Payload wählen wir eine Meterpreter Reverse-Shell, die zu unserem Kali-System zurückruft, und einen freien Port, auf dem wir auf die Daten warten. Alternativ könnten wir auch andere Exploits nutzen, um zum Beispiel neue User anzulegen, oder Daten zu löschen.

Nachdem alle unsere Werte gesetzt sind, und alles passend bereit ist, führen wir das Exploit aus, in der Hoffnung, dass alles klappt.

Es hat wie erwartet direkt funktioniert. Das Exploit hat erfolgreich einen Job erstellt, ausgeführt, und uns darüber eine Reverse-Meterpreter-Shell erstellt, die sich mit unserem System verbunden hat. Die Frage ist die sich nur noch abschließend stellt, ist, über welche Rechte verfügt die Shell?

Durch das Ausführen einer Shell und einfachen Linux-Kommandos stellen wir fest, dass die Shell als „root“, also absoluter Super-User, läuft. Mit diesem User können wir faktisch also alles auf dem System machen, neue User anlegen, die Konfiguration ändern, und vieles mehr. Wir konnten also das System übernehmen.

Fazit

TURN-Server stellen nicht nur theoretisch ein potenzielles Sicherheitsrisiko dar, sondern auch praktisch, wie wir im obenstehenden Beispiel demonstriert haben. Es konnte über die Verkettung von Schwachstellen der Server als Root-User übernommen werden. Natürlich gibt es einige Punkte, an denen die Angriffskette hätte unterbrochen werden können, z. B. den Hashicorp Nomad mit einer Authentifizierung versehen. Aber das würde dennoch nicht das Grundproblem lösen: Der TURN-Server ermöglicht Zugang zu internen Systemen und Services, auf die man eigentlich kein Zugriff hat, bzw. haben sollte. Selbst wenn dieses System sicher gewesen wäre, hätten wir wahrscheinlich auf andere, möglicherweise verwundbare Systeme zugreifen können.

Aus diesem Grund ist es unerlässlich, TURN-Server und die damit verbundene Infrastruktur sicher zu konfigurieren und idealerweise auf potenzielle Sicherheitslücken zu kontrollieren. Ansonsten kann es sein, dass man Angreifern Tür und Tor in das interne Netzwerk öffnet. Einen Ansatz, um den TURN-Server des Open-Source Tools coturn sicher zu konfigurieren, haben wir im ersten Teil unserer Reihe vorgestellt. Wenn Sie Fragen haben oder Unterstützung bei der Konfiguration und Überprüfung Ihrer TURN-Server und der Infrastruktur benötigen, zögern Sie nicht, uns zu kontaktieren.

Teil 1

Im ersten Teil der Serie, der als Auftakt-Artikel erschienen ist, wird genauer auf die Hintergründe der Schwachstelle eingegangen, und warum viele TURN-Server potenziell unsicher konfiguriert sind.

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