Mumble/Murmur und Teamspeak - Sicherheitsanalyse, Maßnahmen und Angriffsszenarien
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Hochschule für Technik, Wirtschaft und
Kultur Leipzig
Fakultät Informatik, Mathematik und Naturwissenschaften
Projektarbeit
Mumble/Murmur und Teamspeak -
Sicherheitsanalyse, Maßnahmen und
Angriffsszenarien
Autoren: Marcel Graef
Marco Franke
Studiengang: Medieninformatik Master
Lehrveranstaltung: IT-Sicherheit (Aufbaukurs) WS 2012/13
Verantwortlicher Professor: Prof. Dr. rer. nat. Uwe Petermann
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einleitung 1
2 Vergleich von Mumble/Mumur und TeamSpeak 3 2
2.1 Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Funktionsweise und Protokolle . . . . . . . . . . . . . . . . . . . . . . . 2
2.3 Das Channel- und Rechtesystem . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Authentifizierung und Verwaltung der Clients . . . . . . . . . . . . . . 5
2.5 Sprachcodecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.1 CELP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.2 Speex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5.3 CELT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5.4 Opus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Unterstützte Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 Lizenzmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.8 Weitere Besonderheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Sicherheitsanalyse und Ermittlung von Schwachstellen 10
3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme . . . . . . . 10
3.1.1 Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2 Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 Verbindlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.4 Weitere Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Typische Angriffsarten . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Computervirus . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Wurm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Trojaner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.4 Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.5 Backdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.6 Rootkit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.8 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.9 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Marcel Graef & Marco Franke i
Inhaltsverzeichnis
3.2.10 Port Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.11 Brute-Force-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.12 Man-in-the-middle-Angriff . . . . . . . . . . . . . . . . . . . . . 17
3.2.13 Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.14 Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Bedrohungen der Sprachkonferenzsysteme . . . . . . . . . . . . . . . . 18
3.3.1 Mögliche Angriffsziele . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 Verursacher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.3 Verletzung der Schutzziele . . . . . . . . . . . . . . . . . . . . . 19
3.4 Ermittlung der Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . 20
4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicher-
heitsmaßnahmen 22
4.1 Aufbau und Beschreibung der Untersuchungsumgebung . . . . . . . . . 22
4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware . . . . . . 23
4.2.1 TeamSpeak 3-Server . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2 TeamSpeak 3-Client . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Murmur-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.4 Clients Mumble . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Sicherheitsmaßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1 Spachkonferenzsoftware . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.2 Konfiguration der Server . . . . . . . . . . . . . . . . . . . . . . 30
4.3.3 Sicherheitsrelevante Einstellungen des Betriebssystems . . . . . 31
4.3.4 Router und lokale Firewall . . . . . . . . . . . . . . . . . . . . . 33
4.3.5 Nutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.6 Mensch als Schwachstelle . . . . . . . . . . . . . . . . . . . . . . 38
5 Demonstration von Angriffsszenarien 40
5.1 Betrachtung des TeamSpeak 3-Server Query Interface . . . . . . . . . . 40
5.1.1 Aufbau des Testprogramm . . . . . . . . . . . . . . . . . . . . . 40
5.1.2 Untersuchung der Anti-Flood-Protection . . . . . . . . . . . . . 42
5.1.3 Brute-Force-Angriff auf das Query Interface . . . . . . . . . . . 44
5.2 TeamSpeak 3-Server Query Interface Exploit . . . . . . . . . . . . . . . 45
5.2.1 Funktionsweise von teamspeakrack . . . . . . . . . . . . . . . . 45
5.2.2 Einrichten einer Hintertür . . . . . . . . . . . . . . . . . . . . . 47
5.2.3 Null Pointer Dereferenzierung . . . . . . . . . . . . . . . . . . . 49
5.2.4 Server mit Textnachrichten fluten . . . . . . . . . . . . . . . . . 49
5.2.5 Weitere Möglichkeiten von teamspeakrack . . . . . . . . . . . . 50
5.3 Murmur Exploit für einen DoS-Angriff . . . . . . . . . . . . . . . . . . 51
6 Resümee und Ausblick 54
ii Marcel Graef & Marco Franke
Inhaltsverzeichnis Literaturverzeichnis 56 Abbildungsverzeichnis 59 Tabellenverzeichnis 60 Abkürzungsverzeichnis 61 Eigenständigkeitserklärung 63 Marcel Graef & Marco Franke iii
1 Einleitung Die Nutzung von Sprachkommunikationsdiensten hat im letzten Jahrzehnt drastisch zugenommen. Es gibt bereits zahlreiche Programme, die Sprachkonferenzen ermöglichen - beispielsweise TeamSpeak, Mumble/Murmur, Skype oder Ventrilo. Ein Grund für diese Entwicklung ist der Ausbau von DSL-Verbindungen sowie der Leitungskapazität im Wide Area Network (WAN). Aber auch die Qualität der Sprachübertragung von Sprachkonferenzsystemen über IP-Netzwerke hat deutlich zugenommen. In dieser Arbeit werden zwei ausgewählte Sprachkonferenzsysteme untersucht. Dies ist zum Einen das proprietäre TeamSpeak 3 und das quelloffene Mumble/Murmur. Die Ähnlichkeiten und Unterschiede werden im Kapitel 2 aufgezeigt. Dabei wird neben den grundlegenden technischen Details, Funktionsweisen und verwendeten Codecs auf die Lizenzmodelle eingegangen. Letzteres spielt gerade für Unternehmen eine wichtige Rolle. Neben den technischen Eigenschaften der Sprachkonferenzsysteme ist vor allem die Sicherheit von großem Interesse. Um diese in Kapitel 3 zu analysieren, werden in Ab- schnitt 3.1 die Anforderungen und Schutzziele von Nutzern der Sprachkonferenzdienste aufgezeigt. Danach wird in Abschnitt 3.2 eine Übersicht typischer Angriffsarten gegeben. Mit Hilfe dieser Angriffsarten können Angreifer Angriffsziele erreichen und stellen somit eine Bedrohung für das Sprachkonferenzsystem dar. Diese werden in Abschnitt 3.3 analysiert und klassifiziert. Durch diese systematische Betrachtung ist es möglich, Schwachstellen von Sprachkonferenzsystemen zu identifizieren. Aufbauend auf diesen Erkenntnissen wird in Kapitel 4 eine Untersuchungsumgebung aufgebaut und Maßnahmen zur Erhöhung der Sicherheit betrachtet und umgesetzt. Mit Hilfe dieser Untersuchungsumgebung wird in Kapitel 5 aufgezeigt, dass die Sicherheit durch Sicherheitsmaßnahmen erhöht werden kann, aber durch kleine Fehler schnell beträchtliche Sicherheitsrisiken entstehen können. Marcel Graef & Marco Franke 1
2 Vergleich von Mumble/Mumur und TeamSpeak 3 2 Vergleich von Mumble/Mumur und TeamSpeak 3 In diesem Kapitel werden die wesentlichen Merkmale von TeamSpeak 3 und Mum- ble/Murmur vorgestellt. Dabei wird auf den grundlegenden Aufbau, funktionale Eigen- schaften und vor allem auf die technischen Details wie Authentisierung, verwendete Codecs, Protokolle und Formate der Sprachkonferenzsoftware eingegangen. Auch werden die Lizenzmodelle von TeamSpeak 3 und Mumble/Murmur gegenübergestellt, da diese eine wesentliche Rolle für Einrichtungen, Institutionen und Privatpersonen darstellen. 2.1 Anwendungsgebiete Das Hauptziel von TeamSpeak 3 als auch Mumble/Murmur ist es, einen Sprachkonfe- renzdienst bereit zu stellen, welcher eine möglichst niedrige Latenzzeit besitzt und dabei trotzdem eine störungsfreie und klare Audioqualität bietet. Aber auch die Datenrate soll möglichst gering (
2.2 Funktionsweise und Protokolle
sich auf einen Server verbindet, belegt einen so genannten Slot. Die Anzahl der Clients,
die sich mit einem Server verbinden können, ist damit auf die Anzahl der verfügbaren
Slots beschränkt. Mit dem Server verbunden, können sich die Clients gegenseitig sehen
und untereinander kommunizieren. Dabei gibt es die Möglichkeit zur Sprach- oder
Textkommunikation. [TSo12g], [MuM12c]
Abbildung 2.1: Schematische Darstellung des Client-Server-Modells von TeamSpeak 3
und Mumble/Murmur
Für den Verbindungsaufbau und zur Steuerung zwischen Client und Server verwenden
beide Anwendungen das verbindungsorientierte Transmission Control Protocol
(TCP), dies wird als Kontrollkanal bezeichnet. Für die Sprachübertragung wird das
User User Datagram Protocol (UDP) verwendet, da dies die Datenübertragung
nicht sichert und zu geringeren Verzögerungen führt. Die Nutzung und Standard Ports
dazu sind den Tabellen 2.1 und 2.2 zu zusammengefasst.
TeamSpeak 3
Dienst Nutzung Standard-Port
Sprachübertragung TeamSpeak 3 Client 9987 UDP
TCP Query telnet ip port 10011 TCP
Tabelle 2.1: Übersicht über die genutzten Standard-Ports von TeamSpeak 3 zu den
jeweiligen Diensten.
Als IP-Telefonie-Protokoll verwendet TeamSpeak 3 das Softwareeigene, nicht offen
Marcel Graef & Marco Franke 3
2 Vergleich von Mumble/Mumur und TeamSpeak 3
spezifizierte, TeamSpeak-Protokoll. Aus diesem Grund kann keine Aussage über die
Verschlüsselung der Daten gemacht werden. Das TeamSpeak-Protokoll ist zu keinem
anderen freien Protokoll wie SIP, H.323 und IAX kompatibel. Es existiert aber eine
quelloffene Protokoll Alternative namens soliloque-server, welches kompatibel zum
TeamSpeak-Protokoll ist. Das Mumble-Protokoll ist ebenfalls mit keinem anderen
Protokoll kompatibel, aber offen spezifiziert und damit für jeden einsehbar. [Cam10],
[Nat12a]
Mumble/Mumur
Dienst Nutzung Standart-Port
Sprachübertragung Mumble 64738 UDP
Steuerkanal Mumble 64738 TCP
Tabelle 2.2: Übersicht über die genutzten Standard-Ports von Mumble/Murmur zu den
jeweiligen Diensten.
Für die Verschlüsselung des Sprachkanals (UDP voice channel) wird der Advanced
Encryption Standard (AES) mit einer Schlüssellänge von 128 Bits im Offset
Codebook Mode (OCB) verwendet (OCB-AES128). Die Verschlüsselung des Steu-
erkanal (TCP control channel) ist durch den Einsatz des Verschlüsselungsprotokolls
Transport Layer Security (TLS), AES mit einer Schlüssellänge von 256 Bits
und dem Secure Hash Algorithm (SHA) gekennzeichnet (TLSv1-AES256-SHA).
[SH10], [TSo12c], [Cam10]
2.3 Das Channel- und Rechtesystem
In der Regel ist es nicht erwünscht, dass alle Clients, welche auf einen Server verbun-
den sind, mit einander kommunizieren. Um nicht für jede Konferenz einen eigenen
Server verwenden zu müssen, gibt es die Möglichkeit, Bereiche zu erstellen, in denen
sich die Konferenzteilnehmer zusammen schließen können. Diese Bereiche werden als
Channel bezeichnet. Jeder Client kann sich beliebig einem dieser Channel anschließen
und ausschließlich mit den darin befindlichen Clients kommunizieren. Auch ist der
Wechsel zwischen verschiedenen Channels jederzeit möglich. Die Channels können auch
in einander verschachtelt werden, woraus eine Hierarchie entsteht. Weiterhin kann man
zwischen öffentlichen und passwortgeschützten Channels unterscheiden. Ein weiterer
4 Marcel Graef & Marco Franke2.4 Authentifizierung und Verwaltung der Clients wichtiger Aspekt sind die komplexen Rechtesysteme, welche sich in TeamSpeak 3 und Mumble/Murmur stark ähneln. Die Rechtevergabe wird dabei über Rechtegruppen geregelt. Das heißt, die Rechte jedes Nutzers ergeben sich aus der Rechtegruppe, welcher er zugeordnet ist. Jede Gruppe besitzt dabei einen Namen und eine Identifikationsnum- mer sowie die Rechte, die der jeweiligen Gruppe eingeräumt werden. Standardmäßig sind die drei Gruppen Serveradmin, Normal und Gast vorhanden. Bei TeamSpeak 3 wird zusätzlich noch zwischen Server- und Channelgruppen unterschieden, wodurch es möglich ist Rechtegruppen zu erstellen, welche den Gültigkeitsbereich auf bestimmte Channel beschränken. Mit Hilfe dieser Zugriffssteuerung durch die Rechtesysteme können die Server auf verschiedene Szenarien angepasst werden. Denkbar ist beispielsweise die Konfiguration für ein virtuelles Tutorium. Dafür wird eine Gruppe für die Tutoren erstellt, welche das Recht haben zu Sprechen und eine Gruppe für die Teilnehmer, welche nur zuhören dürfen. Zusätzlich können die Tutoren einzelnen Teilnehmern das Recht zum sprechen geben oder wieder entziehen. Der Wunsch eines Teilnehmers zu Sprechen kann dabei über den Channelchat erfolgen. [TSo12e], [MuM12b] 2.4 Authentifizierung und Verwaltung der Clients Bei TeamSpeak 3 und Mumble/Murmur authentifiziert sich ein Client nicht über einen klassischen Login (bestehend aus Name und Passwort) auf einem Server. Bei einem TeamSpeak 3 Server geschieht dies durch eine so genannte Identität. Diese ist durch eine eindeutige ID beschrieben. Bei Mumble/Murmur erfolgt dies über Zertifikate. Dadurch ist es für den Client möglich, sich an einem Server zu verschiedenen Zeitpunkten mit unterschiedlichen Usernamen einzuloggen. Ein Client hat die Möglichkeit, mehrere dieser Identitäten bzw. Zertifikate anzulegen. Zusätzlich kann der Zugriff auf einen Server durch ein Serverpasswort geschützt werden, wenn beispielsweise keine Registrierung erwünscht ist. Die Informationen für registrierte Clients und deren Gruppenzugehörigkeiten werden auf dem TeamSpeak 3 Server bzw. Murmur in einer Datenbank gespeichert. Dabei ist es möglich, eine SQLite- oder MySQL-Datenbank zu verwenden. Die Verwaltung der Marcel Graef & Marco Franke 5
2 Vergleich von Mumble/Mumur und TeamSpeak 3 Datenbank kann serverseitig direkt vorgenommen werden. Mit den benötigten Rechten können bei TeamSpeak 3 und Murmur Einstellungen auch über die Client-Oberfläche vorgenommen werden. Zusätzlich bietet der TeamSpeak 3 Server einen Telnet-basierten Zugang zur Administration (bezeichnet als TCPQuery). [TSo12f], [Nat12a] 2.5 Sprachcodecs Ein weiterer wichtiger Aspekt in Bezug auf ressourcenschonende Datenübertragung sind die verwendeten Sprachcodecs. Auch in diesem Punkt findet man bei TeamSpeak 3 und Mumble/Murmur Parallelen. So verwenden beide Anwendungen die Sprachcodecs Speex und Constrained-Energy Lapped Transform (CELT). In älteren Versionen von TeamSpeak 3 wurden die Sprachcodecs Code-Excited Linear Prediction (CELP) und Global System for Mobile Communications (GSM) verwendet, welche aber in der aktuellen Version nicht mehr zu finden sind. Bei Mumble/Murmur findet man zusätzlich den Sprachcodec Opus. Eine nähere Betrachtung in diesem Abschnitt wird Aufschluss über Merkmale und Verwendung dieser speziellen Sprachcodecs geben. 2.5.1 CELP Die grundlegende Technik für die genannten Sprachcodecs lieferte das 1985 veröffent- lichte CELP Verfahren. Dies ist ein Segment-orientiertes Codierungsverfahren, welches nach dem Analysis-by-Synthesis (AbS) Prinzip funktioniert. Mit Hilfe des Linear Predictive Coding (LPC) Verfahrens werden die Audiosignale auf ein spezielles, der menschlichen Sprache nachempfundenes Modell abgebildet. Dadurch ist es möglich, die Audiosignale im Vergleich zu Puls-Code-Modulation (PCM) Repräsentation, stark datenreduziert zu speichern bzw. zu übertragen. Daraus resultiert, dass das Verfahren zur Komprimierung von Musik ungeeignet ist. [Bad10, S.162-163] 6 Marcel Graef & Marco Franke
2.5 Sprachcodecs 2.5.2 Speex Mit dem Sprachcodec Speex wurde 2004 ein Codec veröffentlicht, welcher speziell in der IP-Telefonie eingesetzt wird. Der Datenratenbereich liegt bei 2 bis 44 kbit/s bei einer Abtastrate von bis zu 48 kHz. Je nach Abtastrate wird dabei eine Latenzzeit zwischen 20 und 40 ms erreicht. Der Grund für die erreichten Werte ist die Verwendung verschiedener Verfahren und Methoden. Dabei werden die Kompressionsmethoden variable bit rate (VBR) und average bit rate (ABR) verwendet, welche abhängig von den Audiodaten unterschiedliche Bit-raten bei gleich bleibender Qualität erzeugen. Dieser Effekt wird durch die Sprechpausenerkennung Voice Activity Detection (VAD) und den Übertragungsmodus Discontinuous Transmission (DTX) weiter verstärkt. [PHS94] 2.5.3 CELT Im Dezember 2007 wurde der CELT (Constrained-Energy Lapped Transform) Sprach- codec veröffentlicht. Dieser Sprachcodec erzielt im Vergleich zum Speex eine geringere Latenz von 5 bis 22,5 ms. Um dies zu erreichen, verwendet er eine höhere und kon- stante Datenrate von 32 bis 128 kbit/s. Zudem lässt sich durch die höhere Datenrate eine größere Frequenzbandbreite abbilden, wodurch sich dieser Sprachcodec auch zur Übertragung von Musik eignet. Durch ein integriertes Packet Loss Concealment (PLC) Verfahren lassen sich verloren gegangene Daten überbrücken und sind somit für den Empfänger kaum wahrnehmbar. Im Februar 2011 wurde die aktuelle Version 0.11.1 veröffentlicht. [PHC08] 2.5.4 Opus Im Gegensatz zu TeamSpeak 3 bietet Mumble/Murmur zusätzlich Unterstützung für den im September 2012 veröffentlichten Sprachcodec Opus. Dieser Codec vereint verschiedene Technologien, unter anderen vom CELT Sprachcodec. Er deckt einen großen Datenratenbereich von 6 bis 510 kbit/s mit einer maximalen Abtastrate von bis zu 48 kHz, ab. Damit eignet er sich nicht nur für Sprache, sondern auch für Musik. Durch die Verwendung der Kompressionsmethoden constant bit-rat (CBR) und VBR unterstützt er konstante als auch variable Bit-raten. Auch wird das PLC Verfahren Marcel Graef & Marco Franke 7
2 Vergleich von Mumble/Mumur und TeamSpeak 3 zur Fehlerüberbrückung verloren gegangener Datenpakete verwendet. Neben Stereo unterstützt er bis zu 255 Kanäle. Anhand drei so genannter Modi kann der Codec je nach Verwendung eingestellt werden. [PHO11] 2.6 Unterstützte Betriebssysteme Neben technischen Details der Sprachkonferenzsoftware sind auch die unterstützten Plattformen von Interesse. TeamSpeak 3 unterstützt Windows, Mac OS X und Linux für den Einsatz von Server oder Client. Für das Betriebssystem FreeBSD steht ausschließlich ein TeamSpeak 3 Server zur Verfügung. Der TeamSpeak 3 Client unterstützt des Weiteren Smartphones mit den Betriebssystemen iOS oder Android. [TSo12b] Mumble/Murmur steht ebenfalls für Windows, Mac OS X und Linux zur Verfügung. Der Client Mumble unterstützt iOS und Android. Es steht auch eine Version für das von Nokia entwickelte Betriebsystem Maemo zur Verfügung. [MuM12d] 2.7 Lizenzmodelle Für den Betrieb eines Sprachserver sind die angebotenen Lizenzmodelle für Privatper- sonen, Institute sowie besonders für Unternehmen von Interesse. Bei TeamSpeak 3 wird zwischen fünf Lizenzmodellen unterschieden. Die Non-Profit- Lizenz (NPL) steht zum Einen für nicht registrierte Nutzer zur Verfügung. Sie erlaubt die Verwendung eines Servers mit maximal 32 Slots für nicht kommerzielle Zwecke. Registrierte Nutzer können bis zu 10 Server mit maximal 512 Slots betreiben. Für gewerbliche Unternehmen, welche TeamSpeak 3 Server vermieten, wird die gewerbliche Lizenz für Autorisierte TeamSpeak Host Provider (ATHP) verwendet. Bei gewerblichen Unternehmen, welche TeamSpeak 3 innerhalb eines gewerblichen Umfelds nutzen, besteht zusätzlich die Möglichkeit, die jährliche Aktivierungslizenz (AAL) zu verwenden. Möchten gewerbliche Unternehmen mit dem TeamSpeak 3 Software Development Kit (SDK) Software entwickeln, kann die TeamSpeak 3 SDK Lizenz erworben werden. [TSo12d] 8 Marcel Graef & Marco Franke
2.8 Weitere Besonderheiten Mumble/Murmur steht zum Vergleich unter General Public License (GPL) Version 2 lizenziert und verfügt damit über keine lizenzrechtlichen Einschränkungen. [Nat12a] 2.8 Weitere Besonderheiten TeamSpeak 3 und Mumble/Murmur bieten gleichermaßen weitere Besonderheiten. So gibt es für das Sprechen die Möglichkeit, zwischen automatischer Sprachaktivierung oder Sprachaktivierung durch Tastendruck (Push-To-Talk) zu wählen. Auch können in beiden Anwendungen Einstellungen für Surround Sound vorgenommen werden. Damit ist es möglich, Konferenzteilnehmer virtuell räumlich anzuordnen, um eine reale Konferenz zu simulieren. Mit Hilfe so genannter Musikbots, welche virtuelle Konferenzteilnehmer darstellen, ist es möglich, Musik in einem Channel abzuspielen. Diese können aber auch verwendet werden, um Gespräche aufzuzeichnen. Die Möglichkeit des Aufzeichnens steht für den TeamSpeak 3 und Mumble-Client zur Verfügung. [Nat12b], [TSo12a] Marcel Graef & Marco Franke 9
3 Sicherheitsanalyse und Ermittlung von Schwachstellen
3 Sicherheitsanalyse und Ermittlung
von Schwachstellen
Um Sicherheitsmaßnahmen für die Sprachkonferenzsysteme TeamSpeak 3 und Mum-
ble/Murmur zu entwickeln, müssen bestehende Schwachstellen erkannt werden. Um
Schwachstellen zu erkennen, müssen zunächst in Abschnitt 3.1 Anforderungen an ein
Sprachkonferenzsystem und den damit verbundenen Schutzzielen der Nutzer diskutiert
werden. Danach wird in Abschnitt 3.2 eine Übersicht typischer Angriffe gegeben. Dies
ist wichtig, um Bedrohungen (Abschnitt 3.3) der Sprachkonferenzsysteme zu erkennen
und aufzuzeigen. Schließlich können daraus Schwachstellen (Abschnitt 3.4) ermittelt
werden. Darauf aufbauend können bei der Konzeption und Realisierung in einer Unter-
suchungsumgebung in Kapitel 4 geeignete Gegenmaßnahmen abgeleitet und umgesetzt
werden.
3.1 Anforderungen und Schutzziele an
Sprachkonferenzsysteme
Sowohl private Nutzer als auch Unternehmen verfolgen bestimmte Schutzziele und
Anforderungen. Besonders für Unternehmen sollte der Analyse von Schutzzielen und
Anforderungen eine große Beachtung beigemessen werden, da hier die Sicherheitsrisiken
schwerwiegende wirtschaftliche Folgen haben können. Die primären Schutzziele sind
Verfügbarkeit, Vertraulichkeit, Verbindlichkeit. [BSI04], [Bad10, S.446-448]
10 Marcel Graef & Marco Franke3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme 3.1.1 Verfügbarkeit Mit dem Schutz der Verfügbarkeit wird gewährleistet, dass alle notwendigen Verbindungs- und Sprachdaten für den Anwender stets verfügbar sind. In diesem Zusammenhang muss gesichert werden, dass die Funktionsweise der Sprachserver durch Angriffe, aber auch durch Ausfall technischer Geräte (z.B. Stromversorgung) nicht beeinträchtigt werden. [BSI04], [Bad10, S.446-448] 3.1.2 Vertraulichkeit Unter der Vertraulichkeit versteht man den Schutz vor der ungewollten Preisgabe von Informationen. Dies ist beispielsweise der Fall, wenn Gespräche von Unbefugten abgehört oder aufgezeichnet werden. Um die Vertraulichkeit durch externe Angriffe nicht zu verletzen, ist es notwendig, die Verbindungs- und Sprachdaten beim Austausch zwischen Server und Client geeignet zu verschlüsseln. Aber auch ungewollte interne Zugriffe auf diese Daten sind zu vermeiden. Das heißt, der Zugriff auf eine Konferenz darf nur von berechtigten Personen erfolgen. [BSI04], [Bad10, S.446-448] 3.1.3 Verbindlichkeit Unter Verbindlichkeit werden die Teilaspekte Authentizität, Integrität, Nicht-Abstreit barkeit und Rechtsverbindlichkeit zusammen gefasst. Dabei wird durch technische Maßnahmen versucht, die Echtheit empfangener Daten zu sichern. Als Authentizität wird der Beweis der Echtheit verstanden. Es muss immer für alle Daten die Herkunft eindeutig festgestellt werden können. Aber auch die Korrektheit der angegebenen Herkunft muss stets gesichert sein. So muss Beispielsweise auch sichergestellt werden, dass der Anrufende der ist, der er zu sein vorgibt. Mit dem Schutz der Integrität ist der Schutz vor unbefugter Manipulation von Ver bindungs- und Sprachdaten gemeint. Es muss gesichert sein, dass alle Verbindungs- und Sprachdaten unverändert beim Empfänger eintreffen. Aber auch das Erkennen von Manipulationen muss gewährleistet werden. Wenn man zu einem späteren Zeitpunkt gegenüber einem Dritten (z.B. Gericht) be- Marcel Graef & Marco Franke 11
3 Sicherheitsanalyse und Ermittlung von Schwachstellen weisen muss, dass Daten gesendet oder empfangen wurden, reicht die Integrität und Authentizität meist nicht aus. Deshalb wird durch die Nicht-Abstreitbarkeit sicherge- stellt, dass der Versand und Empfang von Daten nicht abgestritten werden kann und somit ist das Ziel der Rechtsverbindlichkeit erfüllt. [BSI04], [Bad10, S.446-448] 3.1.4 Weitere Anforderungen Bei der Verwendung von Sprachkonferenzsystemen werden neben den allgemeinen Schutzzielen weitere Anforderungen der Leistungsfähigkeit des System gestellt. Die An- forderungen an ein System können als Quality of Service (QoS) zusammengefasst werden und beinhalten Anforderungen aus Anwender- bzw. technischer Sicht. Eine Anforderung aus Anwendersicht ist die Sprachqualität. Diese kann durch die Wahl eines geeigneten Codecs realisiert werden, aber auch durch technische Probleme (z.B. zu hohe Netzauslastung) oder Angriffe (z.B. Distributed Denial of Service) beein- trächtigt werden. Ebenso ist eine leichte Handhabung und Flexibilität im Einsatz der Sprachkonferenzsysteme von Interesse. Eine Anforderung aus technischer Sicht ist eine geringe Verzögerung (Delay) der Sprachsignale. Damit ist der Zeitverzug zwischen dem Aussprechen beim Sender und der Wiedergabe beim Empfänger gemeint. Des Weiteren ist das Auftreten von Jittern unerwünscht. Diese entstehen, wenn netzbedingt die Übertragungszeiten zwischen verschiedenen Paketen stark abweichen. Ab einer Differenz von etwa 50 ms ist dabei mit Problemen in der Kommunikation zu rechnen. Ein solches Problem kann beispielsweise die Verzerrung des hörbaren Sprachsignals sein. Aus verschiedenen Gründen (z.B. zu hohe Lautstärke der Lautsprecher beim Empfänger) können Rückkopplungen des eigenen Gesprochenen entstehen. In diesem Fall spricht man von unerwünschten Echos. Durch geeignete Verfahren zur Echokompensation muss dem entgegengewirkt werden. Durch Überlastung oder Fehler kann es dazu kommen, dass Pakete verworfen werden. Dieser Paketverlust ist ebenfalls unerwünscht und sollte daher möglichst gering gehalten werden. [Bad10, S.116-121,191], [EE07, S.36-39] 12 Marcel Graef & Marco Franke
3.2 Typische Angriffsarten 3.2 Typische Angriffsarten Um Bedrohungen spezifisch von Sprachkonferenzsystemen ermitteln zu können, ist es notwendig, allgemeine Angriffsarten zu kennen. Grundlegend erben Sprachkonferenz- systeme alle Sicherheitsprobleme der IP-Welt und es kommen weitere hinzu. 3.2.1 Computervirus Ein Computervirus ist eine Befehlsfolge, die sich an ein bestehendes Programm anhängt (Infektion). Wird das infizierte Programm ausgeführt, werden auch die Befehlsfolgen des Computervirus ausgeführt. Zusätzlich sind Computerviren in der Lage, sich selbstständig zu verbreiten, d.h. sich selbst zu kopieren (Reproduktion). Computerviren können Schäden, Fehlfunktionen und Störungen bewirken. Sie werden meist durch Weitergabe infizierter Programme oder Dateien (z.B. als E-Mail-Anhang) verbreitet. [Bad10, S.454- 456] 3.2.2 Wurm Im Vergleich zum Computervirus ist ein Wurm ein eigenständiges Programm, welches sich über ein Netzwerk selbstständig verbreiten kann. Aber auch über Wechseldaten- träger ist eine Verbreitung möglich. Zur Verbreitung kann ein Wurm beispielsweise ein E-Mail-Programm verwenden, indem er sich automatisch an alle gespeicherten E-Mail-Adressen als Anhang versendet. [Bad10, S.454-456] Beispielsweise wurde mit Hilfe eines Instant-Messaging-Dienstes, welcher in der Sprach- konferenzsoftware Skype integriert ist, der Wurm Pykse verbreitet. Pykse führte dazu, dass die infizierte Sprachkonferenzsoftware Skype nicht mehr für eingehende Anrufe erreichbar war. 3.2.3 Trojaner Trojanische Pferde sind Schadprogramme, welche sich in vermeintlich nützlichen Pro- grammen verbergen. Sie können sich nicht selbst verbreiten und sind somit auf die Marcel Graef & Marco Franke 13
3 Sicherheitsanalyse und Ermittlung von Schwachstellen Gutgläubigkeit der Nutzer angewiesen. In den meisten Fällen bauen Trojaner Verbin- dungen zum Angreifer auf und ermöglichen dadurch das Ausspähen sensibler Daten. Auch Fernsteuerung befallener Systeme kann dadurch ermöglicht werden. Aus dem Bereich von Sprachkonferenzsystemen ist beispielsweise der Trojaner FinSpy zu nen- nen. Dieser Trojaner ermöglicht unter anderem das Auslesen von Audiodaten, welche durch Lautsprecher wiedergegeben oder von einem Mikrophon erfasst werden. [Bad10, S.454-456] 3.2.4 Exploit Bei einem Exploit handelt es sich um das Ausnutzen von Schwachstellen in einer Software oder einem System. Diese Schwachstellen entstehen durch fehlerhafte Mechanismen, welche bei der Entwicklung nicht berücksichtigt wurden. Diese Schwachstellen können mit Hilfe eines speziell auf die fehlerhaften Mechanismen ausgerichteten Programms ausgenutzt werden. Solche Fehler werden in der Regel erst im Live-Betrieb einer Software oder einem System offengelegt und durch Nachbesserungen behoben. An dieser Stelle wird klar, dass zwischen der Offenlegung und Behebung der Schwachstelle eine erhöhte Gefahr für die Betreiber von Sprachkonferenzsystemen besteht. Ein Beispiel und dessen Auswirkungen wird in Kapitel 5 erläutert und demonstriert. [Bad10, S.454-456] 3.2.5 Backdoor Als Backdoor bezeichnet man Lücken, welche Angreifern unerwünschten Zugriff auf ein System oder Ressourcen ermöglichen. Im Vergleich zu einem Exploit handelt es sich dabei nicht um fehlerhafte Mechanismen in der Software oder einem System, sondern um eine fehlerhafte Konfiguration. Dies können beispielsweise offene Ports oder eine fehlende Zugriffssicherung sein. Solche können vor allem durch Unwissenheit oder Unachtsamkeit der Nutzer entstehen. Aber auch Würmer, Trojaner oder Exploits können solche Lücken auf einem System einrichten. [Bad10, S.454-456] 14 Marcel Graef & Marco Franke
3.2 Typische Angriffsarten 3.2.6 Rootkit Ein Rootkit ist eine Sammlung von Dateien und Programmen, welche dem Angreifer ermöglichen, Root-Rechte auf einem Rechner zu erlangen. Es setzt eine Schwachstelle im System voraus und wird in der Regel zusammen mit Exploits verwendet. Auch werden sie verwendet, um andere Schadprogramme vor Nutzern zu verbergen. [Bad10, S.454-456] 3.2.7 Denial of Service Bei Denial of Service (DoS) Attacken handelt es sich um Angriffe gegen die Verfügbarkeit von Systemen oder Diensten, welche angeboten werden. Es wird durch Überlastung des Systems oder der Software versucht, die Verfügbarkeit einzuschränken oder komplett außer Kraft zu setzen. Dieser Angriff kann auch von mehreren Systemen gleichzeitig durchgeführt werden. In diesem Fall spricht man von einem Distributed Denial of Service (DDoS) Angriff. Dabei wird durch ständiges Senden von Anfragen versucht, Systeme oder Dienste an ihre Belastungsgrenze zu bringen. Dies kann beispielsweise bei einer TCP-Verbindung durch das ständige Senden von SYN-Paketen erfolgen. Ein SYN-Paket ist ein Paket, in dem das SYN-Bit im Paketkopf (TCP-Header) gesetzt ist. Dieses Paket wird von einem Client an einen Server gesendet, um zu signalisieren, dass eine Verbindung über TCP aufgebaut werden möchte und somit einen Verbindungsaufbau initiiert. Ist eine zu hohe Anzahl von Verbindungsanfragen erreicht, kann der Dienst keine weiteren Verbindungen aufbauen und steht damit nicht mehr oder nur noch eingeschränkt zur Verfügung. [Bad10, S.454-456] 3.2.8 Spoofing Unter Spoofing versteht man das Benutzen einer falschen Identität. Dieser Angriff erfolgt durch Vortäuschung falscher Quelladressangaben. Dem kann durch eine gegenseitige Authentifizierung entgegengewirkt werden. Man unterscheidet zwischen IP-, DNS- und URL-Spoofing. Marcel Graef & Marco Franke 15
3 Sicherheitsanalyse und Ermittlung von Schwachstellen Bei IP-Spoofing wird in einem IP-Paket die Quell-IP-Adresse ausgetauscht, um somit einen anderen Kommunikationspartner vorzutäuschen. Bei DNS-Spoofing wird die Zuordnung zwischen IP-Adresse und Rechnername verändert. Auch bei einer aufgerufe- nen Webseite kann die Quell-URL verfälscht werden. In diesem Fall spricht man von URL-Spoofing. [Bad10, S.454-456] 3.2.9 Sniffing Als Sniffer bezeichnet man Programme, mit denen der Datenverkehr in Netzwerken empfangen und aufgezeichnet werden kann. Besonders bei unverschlüsselten Daten kann eine Auswertung dieser Daten sensible Informationen preisgeben. Beispielsweise stellt die Software Wireshark ein sehr umfangreiches Werkzeug für diesen Zweck und darüber hinaus dar. 3.2.10 Port Scanning Mit einem Portscan wird gezielt nach offenen Ports an einem Rechner gesucht, um Schwachstellen für Angriffe ausfindig zu machen. Dabei wird lediglich geschaut, ob bestimmte Dienste auf dem System laufen, bei denen bekannte Schwachstellen vorliegen. [Bad10, S.454-456] 3.2.11 Brute-Force-Angriff Der Brute-Force-Angriff richtet sich an Schnittstellen, an denen sich Nutzer mit ihren Logindaten (Benutzername und Passwort) bei einem Dienst oder System einloggen. Die Logindaten sind gültig, wenn sie einem Benutzerkonto zugeordnet werden können. Bei Angabe gültiger Logindaten wird der Zugriff auf den Dienst oder das System gewährt. Der Angreifer versucht, unter Verwendung eines speziellen Programms gültige Login- daten zu finden. Das Programm sucht mit Hilfe einer erschöpfenden Suche so lange nach Kombinationen von Logindaten, bis es eine gültige Kombination findet. Aufgrund der vielen Kombinationsmöglichkeiten ist es mit dieser Methode oft nicht möglich, den 16 Marcel Graef & Marco Franke
3.2 Typische Angriffsarten Angriff in einem realistischen Zeitfenster durchzuführen. Deshalb wird in den meisten Fällen der Suchraum verkleinert. Man beschränkt sich beispielsweise auf einen bestimm- ten Benutzernamen und versucht, dazu das passende Passwort zu finden. Zusätzlich kann der Suchraum durch so genannte Passwortlisten weiter verkleinert werden. In guten Passwortlisten sind in der Regel mehrere hunderttausend bekannter und beliebter Passwörter zusammengestellt. Ein bekannter Vertreter eines Programms zur Durchführung von Brute-Force-Angriffen ist THC-Hydra. Hauptmerkmal dieses Programms ist die hohe Anzahl unterstützter Protokolle, wie beispielsweise HTTP, SSH, POP3 oder telnet. Auch bietet das Programm Unterstützung für Brute-Force-Angriffe gegen die alte Version TeamSpeak 2. 3.2.12 Man-in-the-middle-Angriff Der Man-in-the-middle (MITM)-Angriff stellt einen Angriff dar, bei dem der Angreifer in einem Netzwerk zwischen den Kommunikationspartnern steht. Dabei liest der Angreifer gezielt Datenpakete der Kommunikation mit, manipuliert diese oder tauscht sie gänzlich aus. 3.2.13 Phishing Phishing bezeichnet alle Vorgänge, bei denen sensible Daten von Nutzern erschlichen werden. Zumeist handelt es sich dabei um das Ausnutzen der Gutgläubigkeit der Opfer, indem falsche Identitäten vorgetäuscht werden. Beispielsweise sind das gefälschte Login Bereiche, in denen die vom Nutzer eingegebenen Daten erschlichen werden. [Bad10, S.454-456] 3.2.14 Hijacking Als Hijacking bezeichnet man die Übernahme von Domänen oder Benutzerkonten. Nach einer erfolgreichen Übernahme der Identität muss diese nicht mehr vorgetäuscht werden. Ab diesem Zeitpunkt können alle Anfragen an diese Identität umgeleitet werden, um Angriffe an weitere Kommunikationspartner durchzuführen. Zur Übernahme werden in der Regel Phishing, Brute-Force- oder MITM-Angriffe verwendet. [Bad10, S.454-456] Marcel Graef & Marco Franke 17
3 Sicherheitsanalyse und Ermittlung von Schwachstellen 3.3 Bedrohungen der Sprachkonferenzsysteme Um ermitteln zu können, welche Auswirkungen Bedrohungen für ein Sprachkonferenz- system haben, muss analysiert werden, welche Ziele und Verursacher einer Bedrohung existieren. Danach kann zusammengefasst werden, welche Schutzziele als Folge einer Bedrohung, verletzt werden können. [Bad10, S.484-487] 3.3.1 Mögliche Angriffsziele Die Ziele der Angreifer können in vier Kategorien zusammen gefasst werden. Dazu gehört das Lauschen bzw. Abhören von Gesprächen, in denen sensible Informationen ausgetauscht werden und somit an unbefugte Dritte gelangen können. Weiterhin ist das Abfangen und Modifizieren von Daten ein Ziel. Dieses betrifft weniger die Sprach- daten einer Konferenz selbst; mehr wird dabei auf Daten, welche zur Steuerung oder Administration der Sprachkonferenzsysteme selbst benötigt werden, abgezielt. Da bei TeamSpeak 3 und Mumble/Murmur auch die Möglichkeit besteht, textbasiert zu kom- munizieren, können auch diese Daten von Interesse sein, abgefangen oder modifiziert zu werden. Aber auch die bloße Beeinträchtigung der Funktionsweise des Dienstes ist ein beliebter Angriffspunkt. Gerade bei Unternehmen, welche auf die Kommunikation über das Sprachkonferenzsystem angewiesen sind, ist diese Art der Sabotage problematisch. Diese können beispielsweise die Kommunikation mit Kunden oder die Kommunikation bei internen Geschäftsprozessen sein. Auch der Missbrauch der Dienste ist ein denkbares Ziel. So können beispielsweise die Ressourcen der Sprachkonferenzsysteme für eigene Gespräche missbraucht werden. [Bad10, S.484-487] 3.3.2 Verursacher Die Verursacher einer Bedrohung können ebenfalls in vier Gruppen eingeteilt werden. Die naheliegendste Gruppe sind externe Angreifer. Sie haben im allgemeinen keine Verbindung zum Sprachkonferenzsystem selbst und müssen sich daher erst Zugriff zum System verschaffen. Die nächste Gruppe sind Schadprogramme (Viren, Würmer, Trojaner, Backdoors, ...). Sie gehen zwar von einem externen Angreifer aus, aber stellen dennoch aufgrund ihres autonomen Handelns eine eigene Gruppe von Verursachern von Bedrohungen dar. Die beiden letzten Gruppen sind interne und externe Nutzer. Diese 18 Marcel Graef & Marco Franke
3.3 Bedrohungen der Sprachkonferenzsysteme
beiden Gruppen besitzen von Vornherein Zugriff auf das Sprachkonferenzsystem und
können beispielsweise durch zu viele Rechte böswillige Ziele verfolgen. Aber auch durch
Fehlverhalten können unbeabsichtigte Schutzziele verletzt werden und stellen damit
eine potentielle Bedrohung dar. [Bad10, S.484-487]
3.3.3 Verletzung der Schutzziele
Mit den unter Abschnitt 3.2 erläuterten Angriffsarten können Versursacher ihre An-
griffsziele erreichen. Jeder Verursacher (siehe Abschnitt 3.3.2) stellt dabei in Verbindung
mit einem Angriffsziel (siehe Abschnitt 3.3.1) eine Bedrohung dar, welche Schutzziele
verletzen kann. Diese sind in Tabelle 3.1 tabellarisch zusammengefasst.
Abfangen und Dienstbe- Dienstmiss-
Verursacher Lauschangriff
Modifikation einträchtigung brauch
Externe Integrität Integrität Integrität
Angreifer Vertraulichkeit Authentizität Verfügbarkeit Authentizität
Verfügbarkeit Verfügbarkeit
Schad- Integrität Integrität Integrität
Vertraulichkeit
programme Verfügbarkeit Verfügbarkeit Verfügbarkeit
Interne Integrität Integrität Integrität
Benutzer Vertraulichkeit Authentizität Authentizität Authentizität
Verfügbarkeit Verfügbarkeit Verfügbarkeit
Externe Integrität Integrität Integrität
Benutzer Vertraulichkeit Authentizität Authentizität Authentizität
Verfügbarkeit Verfügbarkeit Verfügbarkeit
Tabelle 3.1: Mögliche Verletzungen bzw. Folgen, die sich aus den Bedrohungen durch
Verursacher und deren Ziele ergeben (Vgl. [Bad10, S.486])
Mit Hilfe dieser Zusammenstellung ist eine mehrseitige Betrachtung potenzieller Bedro-
hungen möglich und hilft dabei, Schwachstellen zu erkennen. Dabei wird deutlich, dass
neben externen Angreifern auch interne Nutzer kritisch betrachtet werden müssen. Diese
besitzen bereits Zugriff auf das interne Netzwerk oder das Sprachkonferenzsytem selbst
und können Angriffsziele verfolgen. Beispielsweise ist es denkbar, dass interne Benutzer
Daten abfangen und modifizieren. Dabei wird gleichzeitig die Integrität und Authenti-
zität verletzt. Werden die Daten abgefangen und nicht mehr an das System gesendet,
so ist die Verfügbarkeit verletzt. Auch ein Missbrauch des Sprachkonferenzdienstes ist
denkbar. Beispielsweise durch das Ausnutzen zugesicherter Rechte, indem unbefugten
Marcel Graef & Marco Franke 193 Sicherheitsanalyse und Ermittlung von Schwachstellen Nutzern Zugang auf den Sprachkonferenzdienst gegeben werden. Damit wird klar, dass das Sprachkonferenzsystem nicht nur gegen Angriffe von außen geschützt werden muss, sondern auch die interne Struktur (z.B. Netzwerk, Rechtevergabe) betrachtet werden muss. [Bad10, S.484-487] 3.4 Ermittlung der Schwachstellen Anhand der bisherigen Vorüberlegungen von Kapitel 3 können jetzt verschiedene Szenarien abgeleitet und daraus resultierende Schwachstellen erarbeitet werden. Als erste Schwachstelle ist die Sprachkonferenzsoftware selbst zu nennen. Dabei obliegen sicherheitsrelevante Maßnahmen und die sichere Implementation dem Herausgeber der Software. Dazu gehört auch die Verwendung geeigneter Protokolle, welche daher ebenfalls als Schwachstelle anzusehen sind und vom Nutzer als solche betrachtet werden muss. Eine weitere Schwachstelle ist die Konfiguration der Software. Dabei ist der Herausgeber der Software zur Bereitstellung geeigneter Konfigurationsmöglichkeiten verpflichtet. Auf der anderen Seite muss der Nutzer eine für den Anwendungszweck geeignete Konfiguration vornehmen. Neben der Konferenzsoftware ist das verwendete Betriebssystem eine weitere Schwach- stelle. Dies ist vom Nutzer geeignet zu wählen und zu konfigurieren. Damit ist besonders die durchdachte Vergabe von Rechten zu nennen. Um Zugriff auf das Netzwerk und damit auf die Sprachkonferenzsoftware zu ermöglichen, muss die Anbindung an das Netzwerk kritisch betrachtet werden. Daraus ergeben sich der Router und die Firewall als weitere Schwachstelle. Die wohl kritischste Schwachstelle stellen die Benutzer der Sprachkonferenzsysteme dar. Es ist daher unumgänglich, auch diese in Abschnitt 4.3 detailliert zu betrachten. In Tabelle 3.1 sind alle aufgezeigten Schwachstellen tabellarisch mit denkbaren Angriffs- arten und den daraus resultierenden Folgen, im Sinne der Verletzung von Schutzzielen, dargestellt. 20 Marcel Graef & Marco Franke
3.4 Ermittlung der Schwachstellen
Schwachstelle Angriffsart Folge
Exploit Verletzung der
Brute-Force Vertraulichkeit,
Sprachkonferenzsoftware
Verfügbarkeit,
Authentizität
Einräumen Verletzung der
zu vieler Vertraulichkeit,
Konfiguration
Rechte Verfügbarkeit,
Authentizität
Computervirus Verletzung der
Wurm Vertraulichkeit,
Betriebssystem
Trojaner Verfügbarkeit,
Rootkit Authentizität
Backdoor Verletzung der
(D)DoS Vertraulichkeit,
Router und Firewall
Portscanning Verfügbarkeit,
Authentizität
Phishing Verletzung der
Vertraulichkeit,
Benutzer
Verfügbarkeit,
Authentizität
Tabelle 3.2: Mögliche Folgen die sich durch Ausnutzung einer Schwachstelle ergeben
können.
Marcel Graef & Marco Franke 214 Realisierung einer Untersuchungsumgebung unter Betrachtung von
Sicherheitsmaßnahmen
4 Realisierung einer
Untersuchungsumgebung unter
Betrachtung von
Sicherheitsmaßnahmen
In diesem Kapitel wird beschrieben, wie eine Untersuchungsumgebung der beiden
Sprachdienste Mumble/Murmur und TeamSpeak 3 aufgebaut wird. Es wird für Mum-
ble/Murmur und für TeamSpeak 3 in Abschnitt 4.2 beschrieben, wie die Installation
durchzuführen ist und welche Basiskonfiguration für den Betrieb notwendig sind.
4.1 Aufbau und Beschreibung der
Untersuchungsumgebung
Wie schon angedeutet, ist es für die Untersuchung von Netzwerkmanagementlösungen
nötig, eine Untersuchungsumgebung bestehend aus verschiedenen Rechnern aufzubauen.
In Abbildung 4.1 sind die involvierten Rechner dargestellt.
Der PC 1 fungiert im Weiteren als TeamSpeak 3- und Murmur- Server. Der Router mit
der Internet Protokoll (IP)-Adresse 192.168.1.1 spielt eine besondere Rolle, da
hier die Firewall und die Portweiterleitung entsprechend konfiguriert werden müssen.
PC 2 spiegelt hier einen Rechner im internen Netzwerk wider. Das grün und blau
hinterlegte Netzwerk der Abbildung 4.1 ist über eine Standard Digital Subscriber
Line (DSL)-Verbindung an das Internet angebunden und verfügt daher über keine
statische IP-Adresse. Damit PC 3 den Sprachdienst, der von PC 1 angeboten wird,
22 Marcel Graef & Marco Franke4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware
Abbildung 4.1: Schematische Darstellung der Untersuchungsumgebung
nutzen kann, wird der dynamischen externen IP-Adresse des Routers FritzBox 7240
über ein dynamisches Domain-Name-System (DynDNS) ein Fully Qualified
Domain Name (FQDN) zugewiesen. Diese Einstellung wird am Router vorgenommen.
4.2 Installation und Inbetriebnahme der
Spachkonferenzsoftware
4.2.1 TeamSpeak 3-Server
Der TeamSpeak 3-Server kann für verschiedene Betriebssysteme auf der offiziellen Web-
site http://www.teamspeak.com/ unter der Rubrik Download heruntergeladen werden.
Hier wird ein Linux Server amd64 3.0.6.1 installiert. Der Quellcode von TeamSpeak 3
ist nicht frei zugänglich, weshalb Sicherheitslücken wesentlich langsamer offiziell aufge-
deckt werden. Daher darf der TeamSpeak 3-Server niemals als Root gestartet werden.
Falls der Angreifer eine Sicherheitslücke in TeamSpeak 3 findet, hat er möglicherweise
root-Rechte. Das ist fatal. Es wird daher ein Benutzer teamspeak mit sudo adduser
teamspeak angelegt. Der Benutzer wird im Terminal mit su teamspeak gewechselt.
Das heruntergeladene Paket wird nun entpackt und mit ./ts3server_startscript.sh
Marcel Graef & Marco Franke 234 Realisierung einer Untersuchungsumgebung unter Betrachtung von
Sicherheitsmaßnahmen
start wird der Server als teamspeak Benutzer gestartet. Es erfolgt eine Ausgabe des
Servers, wie sie in Abbildung 4.2 dargestellt ist.
Abbildung 4.2: Start des TeamSpeak 3-Servers mit Hilfe des Startskriptes. Beim ersten
Start werden das Administrator-Passwort und ein Token generiert.
Zur Kommunikation mit entfernten Teilnehmern, wie z.B. PC 3 aus Abbildung 4.1 wird
der Dienst von no-ip.org als Dynamic DNS genutzt. Der automatische Abgleich der
dynamischen IP-Adresse wird im Router FritzBox 7240 eingestellt. Des Weiteren muss
das Port 9987 UDP für den Sprachkanal im Router freigegeben werden.
4.2.2 TeamSpeak 3-Client
Die Installation des TeamSpeak 3 Clients gestaltet sich ähnlich. Da der TeamSpeak 3
Client eine proprietäre Software ist, kann sie nicht über die Paketverwaltung installiert
werden, sondern muss von der offiziellen Website http://www.teamspeak.com/ unter
der Rubrik Download heruntergeladen werden.
24 Marcel Graef & Marco Franke4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware
(a) Festlegung Nicknamen (b) Mikrofoneinstellungen
(c) Mikrofontest (d) Tastenkombination
(e) Einstellungen Sprachausgabe (f) Channel hinzufügen
Abbildung 4.3: Installation und Einrichtung des TeamSpeak 3 Clients
Hier wird der Linux Client amd64 3.0.9.2 verwendet. Das Installationsscript TeamSpeak3-
Client-linux_amd64-3.0.9.2.run wird gestartet und es muss den Installationsschrit-
ten, die teilweise in Abbildung 4.3 visualisiert sind, gefolgt werden. Beim Installions-
prozess wird ein Ordner mit den Konfigurations- und ausführbaren Dateien erstellt.
Marcel Graef & Marco Franke 254 Realisierung einer Untersuchungsumgebung unter Betrachtung von
Sicherheitsmaßnahmen
Der Client kann durch Ausführung des darin enthaltenen Shell-Script ts3client_run-
script.sh gestartet werden.
(a) Verbindung mit Server herstellen (b) Teamspeak Client
Abbildung 4.4: Teamspeak 3 Client: Verbindung zu einem Server herstellen
Mit dem TeamSpeak 3 Client kann über das Menü Verbindungen und den Eintrag
Verbinden eine neue Verbindung erstellt werden. In dem Beispiel, welches in Abbildung
4.4 dargestellt ist, wird eine Verbindung als serveradmin zum Server mit der IP-
Adresse 192.168.1.100 hergestellt. Um Administrationsrechte zu erlangen, muss der
beim ersten Start generierte Berechtigungsschlüssel (Token, siehe Abbildung 4.2) noch
angegeben werden.
4.2.3 Murmur-Server
Der Sprachkommunikationsserver Murmur wird auf dem PC 1 (siehe Abbildung 4.1)
installiert. Auf dem PC 1 ist Ubuntu 12.04 (precise) in der 64-Bit Version mit dem
Kernel Linux 3.2.0-32-generic installiert. Murmur ist in den Paketquellen der genann-
ten Ubuntu-Version enthalten und kann mit apt-get install murmur oder apt-get
install mumble-server und sudo dpkg-reconfigure mumble-server auf dem PC
installiert werden. Auch viele andere Distributionen enthalten in den Standardquellen
die benötigten Pakete. Falls dies nicht der Fall ist, können die Quelldateien auch unter
http://mumble.info/snapshot/ heruntergeladen und kompiliert werden.
Die grundsätzlichen Einstellungen des Murmur-Servers werden in der Konfigurationsda-
26 Marcel Graef & Marco Franke4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware
tei /etc/mumble-server.ini vorgenommen. Wie in Listing 4.1 dargestellt ist, ist das
Passwort zu setzen. Dabei ist zu kontrollieren, dass nur der Benutzer root Lese- und
Schreibrechte auf diese Datei hat, da diese Datei das Passwort im Klartext enthält.
1 # Password to join server
2 serverpassword=PASSWORD
Listing 4.1: Änderung des Murmur-Serverpassworts in mumble-server.ini
Der Server wird mit murmurd gestartet. Neu starten lässt sich der Server mit sudo
/etc/init.d/mumble-server restart
Des Weiteren müssen die Ports 64738 TCP für den Steuerkanal und 64738 UDP für
den Sprachkanal im Router freigegeben werden. Damit ist nach wenigen Einstellungen
der Server bereit für die Kommunikation.
Für den Betrieb eines Murmur-Servers ist es empfehlenswert, die Nutzer- und Grup-
penrechte zu überprüfen. Einige Hinweise werden hierzu in Abschnitt 4.3.5 gegeben.
4.2.4 Clients Mumble
Das Paket mumble ist in den Paketquellen der meisten Linux-Distributionen enthalten
und kann mit sudo apt-get install mumble installiert werden. Beim ersten Start
sind diverse Grundeinstellungen über die Audioein- und -ausgabe vorzunehmen. Ein
Ablauf der vorzunehmenden Konfiguration ist in Abbildung 4.5 aufgezeigt.
Die Spacheinstellungen müssen mit großer Sorgfalt durchgeführt werden, da hiervon
der Benutzungskomfort abhängt. Des Weiteren ist es auch möglich, sich mit Mumble
per Zertifikat bei dem Server zu authentifizieren. Der Vorteil ist dabei, dass nicht mit
Passwörtern gearbeitet werden muss. Die Erstellung bzw. der Import eines solchen
Zertifikates kann am Ende der Konfiguration vorgenommen werden.
Marcel Graef & Marco Franke 274 Realisierung einer Untersuchungsumgebung unter Betrachtung von
Sicherheitsmaßnahmen
(a) Audio-Einstellungen (b) Audio-Einstellungen
(c) Spacheinstellungen (d) Spacheinstellungen
(e) Qualitätseinstellungen (f) Positionsabhängiges Audio
Abbildung 4.5: Schritte der Installation und Einrichtung von Mumble
Nun sind alle Einstellungen bezüglich Mumble für einen reibungslosen Betrieb vorge-
nommen worden und es kann eine Verbindung zum Server (192.168.0.100) hergestellt
werden. Dieser Schritt ist in Abbildung 4.6 visualisiert.
Ist die Verbindung korrekt aufgebaut, wird wie in 4.6 rechts dargestellt ist, eine
Willkommensnachricht vom Server an den Client gesendet.
28 Marcel Graef & Marco Franke4.3 Sicherheitsmaßnahmen
(a) Client mit dem Server verbinden (b) rechts im Bild: Der Channelviewer
zeigt die Nutzeraccounts, die mit dem Ser-
ver verbunden sind; links im Bild: Nach-
richtenverlauf zwischen Server und Client
Abbildung 4.6: Benutzung von Mumble
4.3 Sicherheitsmaßnahmen
In diesem Abschnitt werden die aufgezeigten Schwachstellen diskutiert und Maßnah-
men gegen bestehende Bedrohungen erarbeitet. Dabei werden auch grundsätzliche
Betrachtungen und Handlungsempfehlungen des BSI einfließen.
4.3.1 Spachkonferenzsoftware
Bei der Sprachkonferenzsoftware als Schwachstelle selbst ist für die sichere Konzeption
und Implementation der Herausgeber verantwortlich. Darauf kann der Nutzer auf den
ersten Blick nur begrenzt Einfluss nehmen. Bei einer näheren Betrachtung wird aber
schnell klar, dass dieser einen wichtigen Beitrag zur Sicherheit leisten kann. Dabei wird
der erste große Unterschied zwischen TeamSpeak 3 und Mumble/Murmur deutlich. Da
der Quelltext von Mumble/Murmur für jeden frei einsehbar ist, kann jeder Nutzer mit
Programmiererfahrung den Quelltext analysieren und gegebenenfalls Sicherheitslücken
identifizieren. Diese sind dem Herausgeber der Sprachkonferenzsoftware mitzuteilen
und von diesem zeitnah zu beheben.
Zu den Aufgaben der Herausgeber gehört es ebenso, sicherheitsrelevante Mechanismen
in die Sprachkonferenzsoftware zu integrieren. Dazu gehören Mechanismen wie das
Protokollieren der Aktivitäten auf dem Sprachkonferenzsystem. So kann im Fall von
Sicherheitsverletzungen (z.B. unautorisierte Zugriffe) der Vorfall stets zurück verfolgt
werden. Auch der Einsatz geeigneter Protokolle und Verschlüsselungsverfahren ist vom
Marcel Graef & Marco Franke 294 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Herausgeber zu berücksichtigen. Des Weiteren sind Möglichkeiten für sicherheitsrelevante Konfigurationen bereit zu stellen. Dies spiegelt sich bei TeamSpeak 3 und Mumble/Mur- mur in den umfangreichen Rechtesystemen für die Gruppenverwaltung wider. Auch der Einsatz von Maßnahmen zur Identifikation von Clients (siehe Abschnitt 2.4) spielt dabei eine große Rolle. Diese waren beispielsweise in der alten Version TeamSpeak 2 nicht integriert. Dies führte zur Entstehung so genannter TeamSpeak-Client-Flooder. Dies waren Programme, mit denen eine unbegrenzte Anzahl vermeintlicher Clients auf einen TeamSpeak 2-Server verbinden konnten und somit die Anzahl von Clients auf dem Server auf das Maximum brachten. Dadurch war der Zugriff weiterer Clients nicht mehr möglich. Ferner sind Mechanismen einzubauen, um das übermäßige Senden von Nachrichten (Spam) bei der textbasierten Kommunikation auf dem Server zu unterbinden. Dies lässt sich unterbinden, indem das Senden von Nachrichten auf eine maximale Anzahl für ein Zeitintervall vorgeschrieben wird. Diese Technik wird auch gegen Brute-Force-Attacken eingesetzt. Aber auch Nutzer ohne Programmiererfahrung können zur sicheren Implementation beitragen. Nutzer können beim Auffinden von Fehlern (Bugs) den Herausgeber der Software darüber informieren (anhand so genannter Bug Reports). Dazu stellen die meisten Herausgeber Bereiche zur Verfügung, indem Bug Reports eingereicht werden können. Bei TeamSpeak 3 und Mumble/Murmur sind speziell für diesen Zweck Bereiche in den offiziellen Foren eingerichtet. Im Aufgabenbereich des Nutzers liegt auch das Softwareaktualisierungen durchgeführt werden. Über neue Versionen kann sich auf den offiziellen Webseiten informiert werden. Bei TeamSpeak 3 und Mumble/Murmur wird jedoch auch beim Start der Software über neue verfügbare Versionen benachrichtigt. 4.3.2 Konfiguration der Server Die Möglichkeit zur Konfiguration der Sprachkonferenzsoftware allein ist nicht ausrei- chend, wenn diese nicht geeignet eingesetzt werden. Die Einstellungen und Rechtever- gabe sind dabei gründlich zu planen und stark einsatzabhängig. Grundsätzlich ist es ratsam auf jedem Server nur genau einen Administrator mit allen Rechten einzurichten. Lediglich für Moderatoren muss noch eine weitere Rechtegruppe angelegt werden. Diese sind befugt, andere Clients vom Server zu bannen, neue Channel zu erstellen oder Clients in andere Channel zu verschieben. Handelt es sich um einen öffentlichen Sprachkonferenzserver, so ist der Zugang für jeden 30 Marcel Graef & Marco Franke
4.3 Sicherheitsmaßnahmen Client zu ermöglichen, die Rechte auf dem Server als Gast aber minimal zu halten. So dürfen Gäste lediglich das Recht erhalten, selbständig in dafür vorgesehene Channel beizutreten, sprechen zu dürfen oder Textnachrichten senden zu können. Es ist aber auch möglich, auf einem öffentlichen Server Channel einzurichten, dem ein Gast nicht beitreten kann, wenn dies nicht erwünscht ist. Der Zugriff kann dann beispielsweise nur durch einen Moderator, ein Passwort oder nur für auf dem Server registrierte Clients erfolgen. Es ist auch möglich, eine Rechtegruppe für Moderatoren zu erstellen, deren Wirkungsbereich sich nur auf spezielle Channel beschränkt. Möchte man einen privaten Sprachkonferenzserver betreiben, beispielsweise in einem Unternehmen zur internen Kommunikation, so ist der Zugriff auf den Server von vorn- herein zu unterbinden und nur für registrierte Clients oder mit Passwort zu ermöglichen. Aber auch der interne Bereich ist, wie bei einem öffentlichen Sprachkonferenzserver, geeignet einzurichten. Denn wie in Abschnitt 3.3.2 hervorgegangen, können auch interne Nutzer können böswillige Ziele verfolgen oder eine Bedrohung darstellen. Auch hier gilt eine Einsatz abhängige, gründliche Planung der Struktur. Eine weitere wichtige Maßnahme ist die Verschlüsselung der Sprachdaten. Bei TeamS- peak 3 ist darauf zu achten, dass die Verschlüsselung standardmäßig deaktiviert ist. Dies findet beispielsweise Anwendung, wenn die durch die Verschlüsselung verursachte Latenz unerwünscht ist und es sich nicht um sensible Sprachdaten handelt. Grundlegend ist eine Verschlüsselung immer zu empfehlen. Bei Mumble/Murmur hingegen ist die Verschlüsselung immer aktiv und kann auch nicht deaktiviert werden. Neben der Rechtevergabe und dem Setzen von Passwörtern ist es auf einen TeamS- peak 3-Server möglich, eine so genannte Blacklist zu verwenden. Damit können Ver- bindungen an den TeamSpeak 3 TCP-Query Dienst einzelner IP-Adressen oder ganzer IP-Adressbereiche abgelehnt und damit von der Kommunikation mit dem Server ausge- schlossen werden. 4.3.3 Sicherheitsrelevante Einstellungen des Betriebssystems In diesem Abschnitt werden die wesentlichen Dinge erläutert, wie ein Linux Server (PC 1) sicherer gestaltet werden kann. Ein sehr wichtiger Teil des Sicherheitskonzepts von Linux und auch Windows ab Version Vista ist, dass mit unterschiedlichen Privilegien gearbeitet wird. Es ist extrem wichtig, dass kein Dienst als root bzw. Administrator Marcel Graef & Marco Franke 31
Sie können auch lesen
