Mumble/Murmur und Teamspeak

Transcription

Hochschule für Technik, Wirtschaft und
Kultur Leipzig
Fakultä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.1 Anwendungsgebiete . . . . . . . . . . . . . . . .
2.2 Funktionsweise und Protokolle . . . . . . . . . .
2.3 Das Channel- und Rechtesystem . . . . . . . . .
2.4 Authentifizierung und Verwaltung der Clients .
2.5 Sprachcodecs . . . . . . . . . . . . . . . . . . .
2.5.1 CELP . . . . . . . . . . . . . . . . . . .
2.5.2 Speex . . . . . . . . . . . . . . . . . . .
2.5.3 CELT . . . . . . . . . . . . . . . . . . .
2.5.4 Opus . . . . . . . . . . . . . . . . . . . .
2.6 Unterstützte Betriebssysteme . . . . . . . . . .
2.7 Lizenzmodelle . . . . . . . . . . . . . . . . . . .
2.8 Weitere Besonderheiten . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
4
5
6
6
7
7
7
8
8
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
11
11
11
12
13
13
13
13
14
14
15
15
15
16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Sicherheitsanalyse und Ermittlung von Schwachstellen
3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme
3.1.1 Verfügbarkeit . . . . . . . . . . . . . . . . . . . . .
3.1.2 Vertraulichkeit . . . . . . . . . . . . . . . . . . . .
3.1.3 Verbindlichkeit . . . . . . . . . . . . . . . . . . . .
3.1.4 Weitere Anforderungen . . . . . . . . . . . . . . . .
3.2 Typische Angriffsarten . . . . . . . . . . . . . . . . . . . .
3.2.1 Computervirus . . . . . . . . . . . . . . . . . . . .
3.2.2 Wurm . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Trojaner . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 Exploit . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 Backdoor . . . . . . . . . . . . . . . . . . . . . . .
3.2.6 Rootkit . . . . . . . . . . . . . . . . . . . . . . . .
3.2.7 Denial of Service . . . . . . . . . . . . . . . . . . .
3.2.8 Spoofing . . . . . . . . . . . . . . . . . . . . . . . .
3.2.9 Sniffing . . . . . . . . . . . . . . . . . . . . . . . .
Marcel Graef & Marco Franke
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
i
Inhaltsverzeichnis
3.3
3.4
3.2.10 Port Scanning . . . . . . . . . . . .
3.2.11 Brute-Force-Angriff . . . . . . . . .
3.2.12 Man-in-the-middle-Angriff . . . . .
3.2.13 Phishing . . . . . . . . . . . . . . .
3.2.14 Hijacking . . . . . . . . . . . . . .
Bedrohungen der Sprachkonferenzsysteme
3.3.1 Mögliche Angriffsziele . . . . . . .
3.3.2 Verursacher . . . . . . . . . . . . .
3.3.3 Verletzung der Schutzziele . . . . .
Ermittlung der Schwachstellen . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
17
17
18
18
18
19
20
4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaß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
5.1 Betrachtung des TeamSpeak 3-Server Query Interface
5.1.1 Aufbau des Testprogramm . . . . . . . . . . .
5.1.2 Untersuchung der Anti-Flood-Protection . . .
5.1.3 Brute-Force-Angriff auf das Query Interface .
5.2 TeamSpeak 3-Server Query Interface Exploit . . . . .
5.2.1 Funktionsweise von teamspeakrack . . . . . .
5.2.2 Einrichten einer Hintertür . . . . . . . . . . .
5.2.3 Null Pointer Dereferenzierung . . . . . . . . .
5.2.4 Server mit Textnachrichten fluten . . . . . . .
5.2.5 Weitere Möglichkeiten von teamspeakrack . .
5.3 Murmur Exploit für einen DoS-Angriff . . . . . . . .
6 Resümee und Ausblick
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
40
40
42
44
45
45
47
49
49
50
51
54
Inhaltsverzeichnis
Literaturverzeichnis
56
Abbildungsverzeichnis
59
Tabellenverzeichnis
60
Abkürzungsverzeichnis
61
Eigenständigkeitserklärung
63
iii
1 Einleitung
Die Nutzung von Sprachkommunikationsdiensten hat im letzten Jahrzehnt drastisch
zugenommen. Es gibt bereits zahlreiche Programme, die Sprachkonferenzen ermöglichen
- beispielsweise TeamSpeak, Mumble/Murmur, Skype oder Ventrilo. Ein Grund für
diese Entwicklung ist der Ausbau von DSL-Verbindungen sowie der Leitungskapazität
im Wide Area Network (WAN). Aber auch die Qualität der Sprachübertragung
von Sprachkonferenzsystemen über IP-Netzwerke hat deutlich zugenommen.
In dieser Arbeit werden zwei ausgewählte Sprachkonferenzsysteme untersucht. Dies ist
zum Einen das proprietäre TeamSpeak 3 und das quelloffene Mumble/Murmur. Die
Ä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 fü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 Abschnitt 3.1 die Anforderungen und Schutzziele von Nutzern der Sprachkonferenzdienste
aufgezeigt. Danach wird in Abschnitt 3.2 eine Übersicht typischer Angriffsarten gegeben.
Mit Hilfe dieser Angriffsarten können Angreifer Angriffsziele erreichen und stellen
somit eine Bedrohung für das Sprachkonferenzsystem dar. Diese werden in Abschnitt
3.3 analysiert und klassifiziert. Durch diese systematische Betrachtung ist es möglich,
Schwachstellen von Sprachkonferenzsystemen zu identifizieren.
Aufbauend auf diesen Erkenntnissen wird in Kapitel 4 eine Untersuchungsumgebung
aufgebaut und Maßnahmen zur Erhöhung der Sicherheit betrachtet und umgesetzt. Mit
Hilfe dieser Untersuchungsumgebung wird in Kapitel 5 aufgezeigt, dass die Sicherheit
durch Sicherheitsmaßnahmen erhöht werden kann, aber durch kleine Fehler schnell
beträchtliche Sicherheitsrisiken entstehen können.
1
2 Vergleich von Mumble/Mumur und
TeamSpeak 3
In diesem Kapitel werden die wesentlichen Merkmale von TeamSpeak 3 und Mumble/Murmur vorgestellt. Dabei wird auf den grundlegenden Aufbau, funktionale Eigenschaften 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 gegenübergestellt, da diese
eine wesentliche Rolle für Einrichtungen, Institutionen und Privatpersonen darstellen.
2.1 Anwendungsgebiete
Das Hauptziel von TeamSpeak 3 als auch Mumble/Murmur ist es, einen Sprachkonferenzdienst bereit zu stellen, welcher eine möglichst niedrige Latenzzeit besitzt und dabei
trotzdem eine störungsfreie und klare Audioqualität bietet. Aber auch die Datenrate soll
möglichst gering (<25 kbit/s) gehalten werden. Gerade durch Erfüllung dieser Ziele wird
die Software vor allem zur Kommunikation in Verbindung mit Online-Computerspielen
verwendet. Aber auch in Netzwerken und Systemen mit beschränkten Ressourcen wird
TeamSpeak 3 oder Mumble/Murmur eingesetzt. [TSo12g], [MuM12a]
2.2 Funktionsweise und Protokolle
Der Aufbau einer Kommunikationsverbindung wird mit einem klassischen Client-ServerModell, wie in Abbildung 2.1 dargestellt, realisiert. Dabei wird bei TeamSpeak 3 zwischen
dem so genannten TeamSpeak 3 Server und dem TeamSpeak 3 Client unterschieden.
Analog dazu bezeichnet Mumble den Client und Murmur den Server. Jeder Client, der
2
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 können, ist damit auf die Anzahl der verfügbaren
Slots beschränkt. Mit dem Server verbunden, können sich die Clients gegenseitig sehen
und untereinander kommunizieren. Dabei gibt es die Möglichkeit zur Sprach- oder
Textkommunikation. [TSo12g], [MuM12c]
Abbildung 2.1: Schematische Darstellung des Client-Server-Modells von TeamSpeak 3
und Mumble/Murmur
Für den Verbindungsaufbau und zur Steuerung zwischen Client und Server verwenden
beide Anwendungen das verbindungsorientierte Transmission Control Protocol
(TCP), dies wird als Kontrollkanal bezeichnet. Für die Sprachübertragung wird das
User User Datagram Protocol (UDP) verwendet, da dies die Datenübertragung
nicht sichert und zu geringeren Verzögerungen führt. Die Nutzung und Standard Ports
dazu sind den Tabellen 2.1 und 2.2 zu zusammengefasst.
TeamSpeak 3
Dienst
Sprachübertragung
TCP Query
Nutzung
Standard-Port
TeamSpeak 3 Client
telnet ip port
9987 UDP
10011 TCP
Tabelle 2.1: Übersicht über die genutzten Standard-Ports von TeamSpeak 3 zu den
jeweiligen Diensten.
Als IP-Telefonie-Protokoll verwendet TeamSpeak 3 das Softwareeigene, nicht offen
3
spezifizierte, TeamSpeak-Protokoll. Aus diesem Grund kann keine Aussage über die
Verschlü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 für jeden einsehbar. [Cam10],
[Nat12a]
Mumble/Mumur
Dienst
Sprachübertragung
Steuerkanal
Nutzung
Standart-Port
Mumble
Mumble
64738 UDP
64738 TCP
Tabelle 2.2: Übersicht über die genutzten Standard-Ports von Mumble/Murmur zu den
jeweiligen Diensten.
Für die Verschlüsselung des Sprachkanals (UDP voice channel) wird der Advanced
Encryption Standard (AES) mit einer Schlüssellänge von 128 Bits im Offset
Codebook Mode (OCB) verwendet (OCB-AES128). Die Verschlüsselung des Steuerkanal (TCP control channel) ist durch den Einsatz des Verschlüsselungsprotokolls
Transport Layer Security (TLS), AES mit einer Schlüssellä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 erwünscht, dass alle Clients, welche auf einen Server verbunden sind, mit einander kommunizieren. Um nicht für jede Konferenz einen eigenen
Server verwenden zu müssen, gibt es die Möglichkeit, Bereiche zu erstellen, in denen
sich die Konferenzteilnehmer zusammen schließen kö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 möglich. Die Channels können auch
in einander verschachtelt werden, woraus eine Hierarchie entsteht. Weiterhin kann man
zwischen öffentlichen und passwortgeschützten Channels unterscheiden. Ein weiterer
4
2.4 Authentifizierung und Verwaltung der Clients
wichtiger Aspekt sind die komplexen Rechtesysteme, welche sich in TeamSpeak 3 und
Mumble/Murmur stark ähneln. Die Rechtevergabe wird dabei ü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 Identifikationsnummer sowie die Rechte, die der jeweiligen Gruppe eingeräumt werden. Standardmäßig
sind die drei Gruppen Serveradmin, Normal und Gast vorhanden. Bei TeamSpeak 3
wird zusätzlich noch zwischen Server- und Channelgruppen unterschieden, wodurch es
möglich ist Rechtegruppen zu erstellen, welche den Gültigkeitsbereich auf bestimmte
Channel beschränken.
Mit Hilfe dieser Zugriffssteuerung durch die Rechtesysteme können die Server auf
verschiedene Szenarien angepasst werden. Denkbar ist beispielsweise die Konfiguration
für ein virtuelles Tutorium. Dafür wird eine Gruppe für die Tutoren erstellt, welche
das Recht haben zu Sprechen und eine Gruppe für die Teilnehmer, welche nur zuhören
dürfen. Zusätzlich können die Tutoren einzelnen Teilnehmern das Recht zum sprechen
geben oder wieder entziehen. Der Wunsch eines Teilnehmers zu Sprechen kann dabei
über den Channelchat erfolgen.
[TSo12e], [MuM12b]
2.4 Authentifizierung und Verwaltung der Clients
Bei TeamSpeak 3 und Mumble/Murmur authentifiziert sich ein Client nicht über einen
klassischen Login (bestehend aus Name und Passwort) auf einem Server. Bei einem
TeamSpeak 3 Server geschieht dies durch eine so genannte Identität. Diese ist durch eine
eindeutige ID beschrieben. Bei Mumble/Murmur erfolgt dies über Zertifikate. Dadurch
ist es für den Client möglich, sich an einem Server zu verschiedenen Zeitpunkten mit
unterschiedlichen Usernamen einzuloggen. Ein Client hat die Möglichkeit, mehrere dieser
Identitäten bzw. Zertifikate anzulegen. Zusätzlich kann der Zugriff auf einen Server
durch ein Serverpasswort geschützt werden, wenn beispielsweise keine Registrierung
erwünscht ist.
Die Informationen für registrierte Clients und deren Gruppenzugehörigkeiten werden
auf dem TeamSpeak 3 Server bzw. Murmur in einer Datenbank gespeichert. Dabei ist
es möglich, eine SQLite- oder MySQL-Datenbank zu verwenden. Die Verwaltung der
5
Datenbank kann serverseitig direkt vorgenommen werden. Mit den benötigten Rechten
können bei TeamSpeak 3 und Murmur Einstellungen auch über die Client-Oberfläche
vorgenommen werden. Zusä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 Datenü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 ä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 zusätzlich den Sprachcodec Opus. Eine nähere Betrachtung in diesem Abschnitt
wird Aufschluss über Merkmale und Verwendung dieser speziellen Sprachcodecs geben.
2.5.1 CELP
Die grundlegende Technik für die genannten Sprachcodecs lieferte das 1985 veröffentlichte 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 möglich, die
Audiosignale im Vergleich zu Puls-Code-Modulation (PCM) Repräsentation, stark
datenreduziert zu speichern bzw. zu übertragen. Daraus resultiert, dass das Verfahren
zur Komprimierung von Musik ungeeignet ist. [Bad10, S.162-163]
6
2.5 Sprachcodecs
2.5.2 Speex
Mit dem Sprachcodec Speex wurde 2004 ein Codec verö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 fü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 abhängig von den
Audiodaten unterschiedliche Bit-raten bei gleich bleibender Qualität erzeugen. Dieser
Effekt wird durch die Sprechpausenerkennung Voice Activity Detection (VAD)
und den Übertragungsmodus Discontinuous Transmission (DTX) weiter verstärkt.
[PHS94]
2.5.3 CELT
Im Dezember 2007 wurde der CELT (Constrained-Energy Lapped Transform) Sprachcodec veröffentlicht. Dieser Sprachcodec erzielt im Vergleich zum Speex eine geringere
Latenz von 5 bis 22,5 ms. Um dies zu erreichen, verwendet er eine höhere und konstante Datenrate von 32 bis 128 kbit/s. Zudem lässt sich durch die höhere Datenrate
eine größere Frequenzbandbreite abbilden, wodurch sich dieser Sprachcodec auch zur
Übertragung von Musik eignet. Durch ein integriertes Packet Loss Concealment
(PLC) Verfahren lassen sich verloren gegangene Daten überbrücken und sind somit für
den Empfänger kaum wahrnehmbar. Im Februar 2011 wurde die aktuelle Version 0.11.1
veröffentlicht. [PHC08]
2.5.4 Opus
Im Gegensatz zu TeamSpeak 3 bietet Mumble/Murmur zusätzlich Unterstützung
für den im September 2012 verö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 für Sprache, sondern auch für Musik. Durch
die Verwendung der Kompressionsmethoden constant bit-rat (CBR) und VBR
unterstützt er konstante als auch variable Bit-raten. Auch wird das PLC Verfahren
7
zur Fehlerüberbrückung verloren gegangener Datenpakete verwendet. Neben Stereo
unterstützt er bis zu 255 Kanäle. Anhand drei so genannter Modi kann der Codec je
nach Verwendung eingestellt werden. [PHO11]
2.6 Unterstützte Betriebssysteme
Neben technischen Details der Sprachkonferenzsoftware sind auch die unterstützten
Plattformen von Interesse.
TeamSpeak 3 unterstützt Windows, Mac OS X und Linux für den Einsatz von Server
oder Client. Für das Betriebssystem FreeBSD steht ausschließlich ein TeamSpeak 3
Server zur Verfügung. Der TeamSpeak 3 Client unterstützt des Weiteren Smartphones
mit den Betriebssystemen iOS oder Android. [TSo12b]
Mumble/Murmur steht ebenfalls für Windows, Mac OS X und Linux zur Verfügung.
Der Client Mumble unterstützt iOS und Android. Es steht auch eine Version für das
von Nokia entwickelte Betriebsystem Maemo zur Verfügung. [MuM12d]
2.7 Lizenzmodelle
Für den Betrieb eines Sprachserver sind die angebotenen Lizenzmodelle für Privatpersonen, Institute sowie besonders für Unternehmen von Interesse.
Bei TeamSpeak 3 wird zwischen fünf Lizenzmodellen unterschieden. Die Non-ProfitLizenz (NPL) steht zum Einen für nicht registrierte Nutzer zur Verfügung. Sie erlaubt
die Verwendung eines Servers mit maximal 32 Slots für nicht kommerzielle Zwecke.
Registrierte Nutzer können bis zu 10 Server mit maximal 512 Slots betreiben. Für
gewerbliche Unternehmen, welche TeamSpeak 3 Server vermieten, wird die gewerbliche
Lizenz für Autorisierte TeamSpeak Host Provider (ATHP) verwendet. Bei
gewerblichen Unternehmen, welche TeamSpeak 3 innerhalb eines gewerblichen Umfelds
nutzen, besteht zusätzlich die Möglichkeit, die jährliche Aktivierungslizenz (AAL) zu
verwenden. Möchten gewerbliche Unternehmen mit dem TeamSpeak 3 Software
Development Kit (SDK) Software entwickeln, kann die TeamSpeak 3 SDK Lizenz
erworben werden. [TSo12d]
8
2.8 Weitere Besonderheiten
Mumble/Murmur steht zum Vergleich unter General Public License (GPL)
Version 2 lizenziert und verfügt damit über keine lizenzrechtlichen Einschränkungen.
[Nat12a]
2.8 Weitere Besonderheiten
TeamSpeak 3 und Mumble/Murmur bieten gleichermaßen weitere Besonderheiten. So
gibt es für das Sprechen die Möglichkeit, zwischen automatischer Sprachaktivierung oder
Sprachaktivierung durch Tastendruck (Push-To-Talk) zu wählen. Auch können in beiden
Anwendungen Einstellungen für Surround Sound vorgenommen werden. Damit ist es
möglich, Konferenzteilnehmer virtuell räumlich anzuordnen, um eine reale Konferenz
zu simulieren. Mit Hilfe so genannter Musikbots, welche virtuelle Konferenzteilnehmer
darstellen, ist es möglich, Musik in einem Channel abzuspielen. Diese können aber auch
verwendet werden, um Gespräche aufzuzeichnen. Die Möglichkeit des Aufzeichnens
steht für den TeamSpeak 3 und Mumble-Client zur Verfügung. [Nat12b], [TSo12a]
9
3 Sicherheitsanalyse und Ermittlung
von Schwachstellen
Um Sicherheitsmaßnahmen für die Sprachkonferenzsysteme TeamSpeak 3 und Mumble/Murmur zu entwickeln, müssen bestehende Schwachstellen erkannt werden. Um
Schwachstellen zu erkennen, müssen zunä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 Übersicht typischer Angriffe gegeben. Dies
ist wichtig, um Bedrohungen (Abschnitt 3.3) der Sprachkonferenzsysteme zu erkennen
und aufzuzeigen. Schließlich können daraus Schwachstellen (Abschnitt 3.4) ermittelt
werden. Darauf aufbauend können bei der Konzeption und Realisierung in einer Untersuchungsumgebung 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 für Unternehmen sollte der Analyse von Schutzzielen und
Anforderungen eine große Beachtung beigemessen werden, da hier die Sicherheitsrisiken
schwerwiegende wirtschaftliche Folgen haben können. Die primären Schutzziele sind
Verfügbarkeit, Vertraulichkeit, Verbindlichkeit. [BSI04], [Bad10, S.446-448]
10
3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme
3.1.1 Verfügbarkeit
Mit dem Schutz der Verfügbarkeit wird gewährleistet, dass alle notwendigen Verbindungsund Sprachdaten für den Anwender stets verfügbar sind. In diesem Zusammenhang
muss gesichert werden, dass die Funktionsweise der Sprachserver durch Angriffe, aber
auch durch Ausfall technischer Geräte (z.B. Stromversorgung) nicht beeinträ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 Gespräche von Unbefugten
abgehö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 verschlü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 Authentizität, Integrität, Nicht-Abstreit
barkeit und Rechtsverbindlichkeit zusammen gefasst. Dabei wird durch technische
Maßnahmen versucht, die Echtheit empfangener Daten zu sichern.
Als Authentizität wird der Beweis der Echtheit verstanden. Es muss immer für alle
Daten die Herkunft eindeutig festgestellt werden kö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 Integrität ist der Schutz vor unbefugter Manipulation von Ver
bindungs- und Sprachdaten gemeint. Es muss gesichert sein, dass alle Verbindungsund Sprachdaten unverändert beim Empfänger eintreffen. Aber auch das Erkennen von
Manipulationen muss gewährleistet werden.
Wenn man zu einem späteren Zeitpunkt gegenüber einem Dritten (z.B. Gericht) be-
11
weisen muss, dass Daten gesendet oder empfangen wurden, reicht die Integrität und
Authentizität meist nicht aus. Deshalb wird durch die Nicht-Abstreitbarkeit sichergestellt, dass der Versand und Empfang von Daten nicht abgestritten werden kann und
somit ist das Ziel der Rechtsverbindlichkeit erfüllt.
[BSI04], [Bad10, S.446-448]
3.1.4 Weitere Anforderungen
Bei der Verwendung von Sprachkonferenzsystemen werden neben den allgemeinen
Schutzzielen weitere Anforderungen der Leistungsfähigkeit des System gestellt. Die Anforderungen an ein System können als Quality of Service (QoS) zusammengefasst
werden und beinhalten Anforderungen aus Anwender- bzw. technischer Sicht.
Eine Anforderung aus Anwendersicht ist die Sprachqualitä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) beeinträchtigt werden. Ebenso ist eine leichte Handhabung und Flexibilität im Einsatz der
Sprachkonferenzsysteme von Interesse.
Eine Anforderung aus technischer Sicht ist eine geringe Verzögerung (Delay) der
Sprachsignale. Damit ist der Zeitverzug zwischen dem Aussprechen beim Sender und
der Wiedergabe beim Empfänger gemeint. Des Weiteren ist das Auftreten von Jittern
unerwünscht. Diese entstehen, wenn netzbedingt die Ü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 hörbaren Sprachsignals sein. Aus verschiedenen Gründen (z.B.
zu hohe Lautstärke der Lautsprecher beim Empfänger) können Rückkopplungen des
eigenen Gesprochenen entstehen. In diesem Fall spricht man von unerwünschten Echos.
Durch geeignete Verfahren zur Echokompensation muss dem entgegengewirkt werden.
Durch Überlastung oder Fehler kann es dazu kommen, dass Pakete verworfen werden.
Dieser Paketverlust ist ebenfalls unerwünscht und sollte daher möglichst gering gehalten
werden.
[Bad10, S.116-121,191], [EE07, S.36-39]
12
3.2 Typische Angriffsarten
Um Bedrohungen spezifisch von Sprachkonferenzsystemen ermitteln zu können, ist es
notwendig, allgemeine Angriffsarten zu kennen. Grundlegend erben Sprachkonferenzsysteme 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 anhängt
(Infektion). Wird das infizierte Programm ausgeführt, werden auch die Befehlsfolgen des
Computervirus ausgeführt. Zusätzlich sind Computerviren in der Lage, sich selbstständig
zu verbreiten, d.h. sich selbst zu kopieren (Reproduktion). Computerviren können
Schäden, Fehlfunktionen und Störungen bewirken. Sie werden meist durch Weitergabe
infizierter Programme oder Dateien (z.B. als E-Mail-Anhang) verbreitet. [Bad10, S.454456]
3.2.2 Wurm
Im Vergleich zum Computervirus ist ein Wurm ein eigenständiges Programm, welches
sich über ein Netzwerk selbstständig verbreiten kann. Aber auch über Wechseldatenträger ist eine Verbreitung mö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 Sprachkonferenzsoftware Skype integriert ist, der Wurm Pykse verbreitet. Pykse führte dazu,
dass die infizierte Sprachkonferenzsoftware Skype nicht mehr für eingehende Anrufe
erreichbar war.
3.2.3 Trojaner
Trojanische Pferde sind Schadprogramme, welche sich in vermeintlich nützlichen Programmen verbergen. Sie können sich nicht selbst verbreiten und sind somit auf die
13
Gutgläubigkeit der Nutzer angewiesen. In den meisten Fällen bauen Trojaner Verbindungen zum Angreifer auf und ermöglichen dadurch das Ausspähen sensibler Daten.
Auch Fernsteuerung befallener Systeme kann dadurch ermöglicht werden. Aus dem
Bereich von Sprachkonferenzsystemen ist beispielsweise der Trojaner FinSpy zu nennen. Dieser Trojaner ermö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 berücksichtigt wurden. Diese Schwachstellen kö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 erhöhte
Gefahr für die Betreiber von Sprachkonferenzsystemen besteht. Ein Beispiel und dessen
Auswirkungen wird in Kapitel 5 erläutert und demonstriert. [Bad10, S.454-456]
3.2.5 Backdoor
Als Backdoor bezeichnet man Lücken, welche Angreifern unerwünschten Zugriff auf
ein System oder Ressourcen ermö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 können beispielsweise offene Ports
oder eine fehlende Zugriffssicherung sein. Solche können vor allem durch Unwissenheit
oder Unachtsamkeit der Nutzer entstehen. Aber auch Würmer, Trojaner oder Exploits
können solche Lücken auf einem System einrichten. [Bad10, S.454-456]
14
3.2.6 Rootkit
Ein Rootkit ist eine Sammlung von Dateien und Programmen, welche dem Angreifer
ermö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
Verfügbarkeit von Systemen oder Diensten, welche angeboten werden. Es wird durch
Überlastung des Systems oder der Software versucht, die Verfügbarkeit einzuschränken
oder komplett außer Kraft zu setzen. Dieser Angriff kann auch von mehreren Systemen
gleichzeitig durchgeführt werden. In diesem Fall spricht man von einem Distributed
Denial of Service (DDoS) Angriff. Dabei wird durch ständiges Senden von Anfragen
versucht, Systeme oder Dienste an ihre Belastungsgrenze zu bringen.
Dies kann beispielsweise bei einer TCP-Verbindung durch das stä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 über TCP aufgebaut werden mö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 eingeschränkt zur Verfügung.
[Bad10, S.454-456]
3.2.8 Spoofing
Unter Spoofing versteht man das Benutzen einer falschen Identität. Dieser Angriff erfolgt
durch Vortäuschung falscher Quelladressangaben. Dem kann durch eine gegenseitige
Authentifizierung entgegengewirkt werden. Man unterscheidet zwischen IP-, DNS- und
URL-Spoofing.
15
Bei IP-Spoofing wird in einem IP-Paket die Quell-IP-Adresse ausgetauscht, um somit
einen anderen Kommunikationspartner vorzutäuschen. Bei DNS-Spoofing wird die
Zuordnung zwischen IP-Adresse und Rechnername verändert. Auch bei einer aufgerufenen Webseite kann die Quell-URL verfä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 unverschlüsselten Daten kann
eine Auswertung dieser Daten sensible Informationen preisgeben. Beispielsweise stellt
die Software Wireshark ein sehr umfangreiches Werkzeug für diesen Zweck und darüber
hinaus dar.
3.2.10 Port Scanning
Mit einem Portscan wird gezielt nach offenen Ports an einem Rechner gesucht, um
Schwachstellen fü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 gültig, wenn sie einem Benutzerkonto zugeordnet werden können. Bei
Angabe gültiger Logindaten wird der Zugriff auf den Dienst oder das System gewährt.
Der Angreifer versucht, unter Verwendung eines speziellen Programms gültige Logindaten zu finden. Das Programm sucht mit Hilfe einer erschöpfenden Suche so lange
nach Kombinationen von Logindaten, bis es eine gültige Kombination findet. Aufgrund
der vielen Kombinationsmöglichkeiten ist es mit dieser Methode oft nicht möglich, den
16
Angriff in einem realistischen Zeitfenster durchzuführen. Deshalb wird in den meisten
Fällen der Suchraum verkleinert. Man beschränkt sich beispielsweise auf einen bestimmten Benutzernamen und versucht, dazu das passende Passwort zu finden. Zusätzlich
kann der Suchraum durch so genannte Passwortlisten weiter verkleinert werden. In
guten Passwortlisten sind in der Regel mehrere hunderttausend bekannter und beliebter
Passwörter zusammengestellt.
Ein bekannter Vertreter eines Programms zur Durchführung von Brute-Force-Angriffen
ist THC-Hydra. Hauptmerkmal dieses Programms ist die hohe Anzahl unterstützter
Protokolle, wie beispielsweise HTTP, SSH, POP3 oder telnet. Auch bietet das Programm
Unterstützung fü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 gänzlich aus.
3.2.13 Phishing
Phishing bezeichnet alle Vorgänge, bei denen sensible Daten von Nutzern erschlichen
werden. Zumeist handelt es sich dabei um das Ausnutzen der Gutgläubigkeit der Opfer,
indem falsche Identitäten vorgetäuscht werden. Beispielsweise sind das gefä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 Übernahme von Domänen oder Benutzerkonten. Nach
einer erfolgreichen Übernahme der Identität muss diese nicht mehr vorgetäuscht werden.
Ab diesem Zeitpunkt können alle Anfragen an diese Identität umgeleitet werden, um
Angriffe an weitere Kommunikationspartner durchzuführen. Zur Übernahme werden in
der Regel Phishing, Brute-Force- oder MITM-Angriffe verwendet. [Bad10, S.454-456]
17
3.3 Bedrohungen der Sprachkonferenzsysteme
Um ermitteln zu können, welche Auswirkungen Bedrohungen für ein Sprachkonferenzsystem haben, muss analysiert werden, welche Ziele und Verursacher einer Bedrohung
existieren. Danach kann zusammengefasst werden, welche Schutzziele als Folge einer
Bedrohung, verletzt werden können. [Bad10, S.484-487]
3.3.1 Mögliche Angriffsziele
Die Ziele der Angreifer können in vier Kategorien zusammen gefasst werden. Dazu
gehört das Lauschen bzw. Abhören von Gesprächen, in denen sensible Informationen
ausgetauscht werden und somit an unbefugte Dritte gelangen können. Weiterhin ist
das Abfangen und Modifizieren von Daten ein Ziel. Dieses betrifft weniger die Sprachdaten einer Konferenz selbst; mehr wird dabei auf Daten, welche zur Steuerung oder
Administration der Sprachkonferenzsysteme selbst benötigt werden, abgezielt. Da bei
TeamSpeak 3 und Mumble/Murmur auch die Möglichkeit besteht, textbasiert zu kommunizieren, können auch diese Daten von Interesse sein, abgefangen oder modifiziert zu
werden. Aber auch die bloße Beeinträchtigung der Funktionsweise des Dienstes ist ein
beliebter Angriffspunkt. Gerade bei Unternehmen, welche auf die Kommunikation über
das Sprachkonferenzsystem angewiesen sind, ist diese Art der Sabotage problematisch.
Diese können beispielsweise die Kommunikation mit Kunden oder die Kommunikation
bei internen Geschäftsprozessen sein. Auch der Missbrauch der Dienste ist ein denkbares
Ziel. So können beispielsweise die Ressourcen der Sprachkonferenzsysteme für eigene
Gespräche missbraucht werden. [Bad10, S.484-487]
3.3.2 Verursacher
Die Verursacher einer Bedrohung können ebenfalls in vier Gruppen eingeteilt werden.
Die naheliegendste Gruppe sind externe Angreifer. Sie haben im allgemeinen keine
Verbindung zum Sprachkonferenzsystem selbst und müssen sich daher erst Zugriff
zum System verschaffen. Die nächste Gruppe sind Schadprogramme (Viren, Wü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
3.3 Bedrohungen der Sprachkonferenzsysteme
beiden Gruppen besitzen von Vornherein Zugriff auf das Sprachkonferenzsystem und
können beispielsweise durch zu viele Rechte böswillige Ziele verfolgen. Aber auch durch
Fehlverhalten kö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 erläuterten Angriffsarten können Versursacher ihre Angriffsziele 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.
Verursacher
Lauschangriff
Externe
Angreifer
Vertraulichkeit
Schadprogramme
Interne
Benutzer
Externe
Benutzer
Vertraulichkeit
Vertraulichkeit
Vertraulichkeit
Abfangen und
Modifikation
Integrität
Authentizität
Verfügbarkeit
Integrität
Verfügbarkeit
Integrität
Authentizität
Verfügbarkeit
Integrität
Authentizität
Verfügbarkeit
Dienstbeeinträchtigung
Integrität
Verfügbarkeit
Integrität
Verfügbarkeit
Integrität
Authentizität
Verfügbarkeit
Integrität
Authentizität
Verfügbarkeit
Dienstmissbrauch
Integrität
Authentizität
Verfügbarkeit
Integrität
Verfügbarkeit
Integrität
Authentizität
Verfügbarkeit
Integrität
Authentizität
Verfügbarkeit
Tabelle 3.1: Mö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 Bedrohungen möglich und hilft dabei, Schwachstellen zu erkennen. Dabei wird deutlich, dass
neben externen Angreifern auch interne Nutzer kritisch betrachtet werden müssen. Diese
besitzen bereits Zugriff auf das interne Netzwerk oder das Sprachkonferenzsytem selbst
und können Angriffsziele verfolgen. Beispielsweise ist es denkbar, dass interne Benutzer
Daten abfangen und modifizieren. Dabei wird gleichzeitig die Integrität und Authentizität verletzt. Werden die Daten abgefangen und nicht mehr an das System gesendet,
so ist die Verfügbarkeit verletzt. Auch ein Missbrauch des Sprachkonferenzdienstes ist
denkbar. Beispielsweise durch das Ausnutzen zugesicherter Rechte, indem unbefugten
19
Nutzern Zugang auf den Sprachkonferenzdienst gegeben werden. Damit wird klar, dass
das Sprachkonferenzsystem nicht nur gegen Angriffe von außen geschü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 Vorüberlegungen von Kapitel 3 kö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 gehö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 Konfigurationsmöglichkeiten
verpflichtet. Auf der anderen Seite muss der Nutzer eine für den Anwendungszweck
geeignete Konfiguration vornehmen.
Neben der Konferenzsoftware ist das verwendete Betriebssystem eine weitere Schwachstelle. Dies ist vom Nutzer geeignet zu wä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 ermö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 unumgänglich, auch diese in Abschnitt 4.3 detailliert zu betrachten.
In Tabelle 3.1 sind alle aufgezeigten Schwachstellen tabellarisch mit denkbaren Angriffsarten und den daraus resultierenden Folgen, im Sinne der Verletzung von Schutzzielen,
dargestellt.
20
3.4 Ermittlung der Schwachstellen
Schwachstelle
Sprachkonferenzsoftware
Konfiguration
Betriebssystem
Router und Firewall
Angriffsart
Exploit
Brute-Force
Einräumen
zu vieler
Rechte
Computervirus
Wurm
Trojaner
Rootkit
Backdoor
(D)DoS
Portscanning
Phishing
Benutzer
Folge
Verletzung der
Vertraulichkeit,
Verfügbarkeit,
Authentizität
Verletzung der
Vertraulichkeit,
Verfügbarkeit,
Authentizität
Verletzung der
Vertraulichkeit,
Verfügbarkeit,
Authentizität
Verletzung der
Vertraulichkeit,
Verfügbarkeit,
Authentizität
Verletzung der
Vertraulichkeit,
Verfügbarkeit,
Authentizität
Tabelle 3.2: Mögliche Folgen die sich durch Ausnutzung einer Schwachstelle ergeben
können.
21
4 Realisierung einer Untersuchungsumgebung unter Betrachtung von
Sicherheitsmaßnahmen
4 Realisierung einer
Untersuchungsumgebung unter
Betrachtung von
In diesem Kapitel wird beschrieben, wie eine Untersuchungsumgebung der beiden
Sprachdienste Mumble/Murmur und TeamSpeak 3 aufgebaut wird. Es wird für Mumble/Murmur und für TeamSpeak 3 in Abschnitt 4.2 beschrieben, wie die Installation
durchzuführen ist und welche Basiskonfiguration für den Betrieb notwendig sind.
4.1 Aufbau und Beschreibung der
Untersuchungsumgebung
Wie schon angedeutet, ist es für die Untersuchung von Netzwerkmanagementlösungen
nö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 müssen.
PC 2 spiegelt hier einen Rechner im internen Netzwerk wider. Das grün und blau
hinterlegte Netzwerk der Abbildung 4.1 ist über eine Standard Digital Subscriber
Line (DSL)-Verbindung an das Internet angebunden und verfügt daher über keine
statische IP-Adresse. Damit PC 3 den Sprachdienst, der von PC 1 angeboten wird,
22
4.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
ü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 für verschiedene Betriebssysteme auf der offiziellen Website 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 zugänglich, weshalb Sicherheitslücken wesentlich langsamer offiziell aufgedeckt werden. Daher darf der TeamSpeak 3-Server niemals als Root gestartet werden.
Falls der Angreifer eine Sicherheitslücke in TeamSpeak 3 findet, hat er mö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
23
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 für den Sprachkanal im Router freigegeben werden.
4.2.2 TeamSpeak 3-Client
Die Installation des TeamSpeak 3 Clients gestaltet sich ähnlich. Da der TeamSpeak 3
Client eine proprietäre Software ist, kann sie nicht über die Paketverwaltung installiert
werden, sondern muss von der offiziellen Website http://www.teamspeak.com/ unter
der Rubrik Download heruntergeladen werden.
24
(a) Festlegung Nicknamen
(b) Mikrofoneinstellungen
(c) Mikrofontest
(d) Tastenkombination
(e) Einstellungen Sprachausgabe
(f) Channel hinzufügen
Abbildung 4.3: Installation und Einrichtung des TeamSpeak 3 Clients
Hier wird der Linux Client amd64 3.0.9.2 verwendet. Das Installationsscript TeamSpeak3Client-linux_amd64-3.0.9.2.run wird gestartet und es muss den Installationsschritten, die teilweise in Abbildung 4.3 visualisiert sind, gefolgt werden. Beim Installionsprozess wird ein Ordner mit den Konfigurations- und ausführbaren Dateien erstellt.
25
Der Client kann durch Ausführung des darin enthaltenen Shell-Script ts3client_runscript.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 über das Menü 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 IPAdresse 192.168.1.100 hergestellt. Um Administrationsrechte zu erlangen, muss der
beim ersten Start generierte Berechtigungsschlü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 genannten 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 benötigten Pakete. Falls dies nicht der Fall ist, können die Quelldateien auch unter
http://mumble.info/snapshot/ heruntergeladen und kompiliert werden.
Die grundsätzlichen Einstellungen des Murmur-Servers werden in der Konfigurationsda-
26
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 enthält.
1
# Password to join server
2
serverpassword=PASSWORD
Listing 4.1: Änderung des Murmur-Serverpassworts in mumble-server.ini
Der Server wird mit murmurd gestartet. Neu starten lässt sich der Server mit sudo
/etc/init.d/mumble-server restart
Des Weiteren müssen die Ports 64738 TCP für den Steuerkanal und 64738 UDP für
den Sprachkanal im Router freigegeben werden. Damit ist nach wenigen Einstellungen
der Server bereit für die Kommunikation.
Für den Betrieb eines Murmur-Servers ist es empfehlenswert, die Nutzer- und Gruppenrechte zu überprü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 über die Audioein- und -ausgabe vorzunehmen. Ein
Ablauf der vorzunehmenden Konfiguration ist in Abbildung 4.5 aufgezeigt.
Die Spacheinstellungen müssen mit großer Sorgfalt durchgeführt werden, da hiervon
der Benutzungskomfort abhängt. Des Weiteren ist es auch möglich, sich mit Mumble
per Zertifikat bei dem Server zu authentifizieren. Der Vorteil ist dabei, dass nicht mit
Passwörtern gearbeitet werden muss. Die Erstellung bzw. der Import eines solchen
Zertifikates kann am Ende der Konfiguration vorgenommen werden.
27
(a) Audio-Einstellungen
(b) Audio-Einstellungen
(c) Spacheinstellungen
(d) Spacheinstellungen
(e) Qualitätseinstellungen
(f) Positionsabhängiges Audio
Abbildung 4.5: Schritte der Installation und Einrichtung von Mumble
Nun sind alle Einstellungen bezüglich Mumble für einen reibungslosen Betrieb vorgenommen 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
4.3 Sicherheitsmaßnahmen
(a) Client mit dem Server verbinden
(b) rechts im Bild: Der Channelviewer
zeigt die Nutzeraccounts, die mit dem Server verbunden sind; links im Bild: Nachrichtenverlauf zwischen Server und Client
Abbildung 4.6: Benutzung von Mumble
In diesem Abschnitt werden die aufgezeigten Schwachstellen diskutiert und Maßnahmen gegen bestehende Bedrohungen erarbeitet. Dabei werden auch grundsätzliche
Betrachtungen und Handlungsempfehlungen des BSI einfließen.
4.3.1 Spachkonferenzsoftware
Bei der Sprachkonferenzsoftware als Schwachstelle selbst ist für die sichere Konzeption
und Implementation der Herausgeber verantwortlich. Darauf kann der Nutzer auf den
ersten Blick nur begrenzt Einfluss nehmen. Bei einer nä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 für jeden frei einsehbar ist, kann jeder Nutzer mit
Programmiererfahrung den Quelltext analysieren und gegebenenfalls Sicherheitslücken
identifizieren. Diese sind dem Herausgeber der Sprachkonferenzsoftware mitzuteilen
und von diesem zeitnah zu beheben.
Zu den Aufgaben der Herausgeber gehört es ebenso, sicherheitsrelevante Mechanismen
in die Sprachkonferenzsoftware zu integrieren. Dazu gehören Mechanismen wie das
Protokollieren der Aktivitäten auf dem Sprachkonferenzsystem. So kann im Fall von
Sicherheitsverletzungen (z.B. unautorisierte Zugriffe) der Vorfall stets zurück verfolgt
werden. Auch der Einsatz geeigneter Protokolle und Verschlüsselungsverfahren ist vom
29
Herausgeber zu berücksichtigen. Des Weiteren sind Möglichkeiten für sicherheitsrelevante
Konfigurationen bereit zu stellen. Dies spiegelt sich bei TeamSpeak 3 und Mumble/Murmur in den umfangreichen Rechtesystemen fü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 fü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 möglich. Ferner sind Mechanismen einzubauen, um das übermäßige Senden
von Nachrichten (Spam) bei der textbasierten Kommunikation auf dem Server zu
unterbinden. Dies lässt sich unterbinden, indem das Senden von Nachrichten auf eine
maximale Anzahl für ein Zeitintervall vorgeschrieben wird. Diese Technik wird auch
gegen Brute-Force-Attacken eingesetzt.
Aber auch Nutzer ohne Programmiererfahrung können zur sicheren Implementation
beitragen. Nutzer können beim Auffinden von Fehlern (Bugs) den Herausgeber der
Software darüber informieren (anhand so genannter Bug Reports). Dazu stellen die
meisten Herausgeber Bereiche zur Verfügung, indem Bug Reports eingereicht werden
können. Bei TeamSpeak 3 und Mumble/Murmur sind speziell für diesen Zweck Bereiche
in den offiziellen Foren eingerichtet. Im Aufgabenbereich des Nutzers liegt auch das
Softwareaktualisierungen durchgeführt werden. Über neue Versionen kann sich auf den
offiziellen Webseiten informiert werden. Bei TeamSpeak 3 und Mumble/Murmur wird
jedoch auch beim Start der Software über neue verfügbare Versionen benachrichtigt.
4.3.2 Konfiguration der Server
Die Möglichkeit zur Konfiguration der Sprachkonferenzsoftware allein ist nicht ausreichend, wenn diese nicht geeignet eingesetzt werden. Die Einstellungen und Rechtevergabe sind dabei gründlich zu planen und stark einsatzabhängig. Grundsätzlich ist es
ratsam auf jedem Server nur genau einen Administrator mit allen Rechten einzurichten.
Lediglich fü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 öffentlichen Sprachkonferenzserver, so ist der Zugang für jeden
30
Client zu ermöglichen, die Rechte auf dem Server als Gast aber minimal zu halten. So
dürfen Gäste lediglich das Recht erhalten, selbständig in dafür vorgesehene Channel
beizutreten, sprechen zu dürfen oder Textnachrichten senden zu können. Es ist aber
auch möglich, auf einem öffentlichen Server Channel einzurichten, dem ein Gast nicht
beitreten kann, wenn dies nicht erwünscht ist. Der Zugriff kann dann beispielsweise nur
durch einen Moderator, ein Passwort oder nur für auf dem Server registrierte Clients
erfolgen. Es ist auch möglich, eine Rechtegruppe für Moderatoren zu erstellen, deren
Wirkungsbereich sich nur auf spezielle Channel beschränkt.
Möchte man einen privaten Sprachkonferenzserver betreiben, beispielsweise in einem
Unternehmen zur internen Kommunikation, so ist der Zugriff auf den Server von vornherein zu unterbinden und nur für registrierte Clients oder mit Passwort zu ermöglichen.
Aber auch der interne Bereich ist, wie bei einem öffentlichen Sprachkonferenzserver,
geeignet einzurichten. Denn wie in Abschnitt 3.3.2 hervorgegangen, können auch interne
Nutzer können böswillige Ziele verfolgen oder eine Bedrohung darstellen. Auch hier gilt
eine Einsatz abhängige, gründliche Planung der Struktur.
Eine weitere wichtige Maßnahme ist die Verschlüsselung der Sprachdaten. Bei TeamSpeak 3 ist darauf zu achten, dass die Verschlüsselung standardmäßig deaktiviert ist.
Dies findet beispielsweise Anwendung, wenn die durch die Verschlüsselung verursachte
Latenz unerwünscht ist und es sich nicht um sensible Sprachdaten handelt. Grundlegend
ist eine Verschlüsselung immer zu empfehlen. Bei Mumble/Murmur hingegen ist die
Verschlüsselung immer aktiv und kann auch nicht deaktiviert werden.
Neben der Rechtevergabe und dem Setzen von Passwörtern ist es auf einen TeamSpeak 3-Server möglich, eine so genannte Blacklist zu verwenden. Damit können Verbindungen an den TeamSpeak 3 TCP-Query Dienst einzelner IP-Adressen oder ganzer
IP-Adressbereiche abgelehnt und damit von der Kommunikation mit dem Server ausgeschlossen werden.
4.3.3 Sicherheitsrelevante Einstellungen des Betriebssystems
In diesem Abschnitt werden die wesentlichen Dinge erlä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
31
gestartet wird oder dass ein Nutzer a priori Administrationsrechte besitzt. Bei Ubuntu
müssen die Administrationsrechte mit sudo angefordert werden und sind für 15 min
gültig. Um die Sicherheit zu erhöhen, soll dies auf 0 min herunter gesetzt werden. Damit
sind die Administrationsrechte nur für die eine Operation vorhanden. Zur Änderung
wird die Datei /etc/sudoers mit root-Rechten geöffnet und folgender Eintrag (siehe
Listing 4.2) geändert:
1
# Setzt das Timeout fuer sudo auf Null, der Standardwert ist 15 Minuten.
2
Defaults timestamp timeout = 0
Listing 4.2: Timeout für sudo unter Ubuntu auf Null setzen
Updates enthalten meist Verbesserungen von Software und Sicherheitsaktualisierungen.
In den Software-Paketquellen empfiehlt es sich, wichtige Sicherheitsaktualisierungen
automatisch stündlich zu aktualisieren. So können schnell Sicherheitslücken geschlossen
werden.
Abbildung 4.7: Dienste mit rcconf deaktivieren
Des Weiteren müssen Dienste, die nicht benötigt werden, deaktiviert werden. Dazu wird
das Programm rcconf installiert (sudo apt-get install rcconf dialog). Die Deaktivierung ist sehr davon abhängig, welche Aufgaben der Rechner (PC 1) übernehmen
soll. Es ist empfehlenswert, beispielsweise grup-common und bluetooth zu deaktivieren,
falls diese nicht benötigt werden (siehe Abbildung 4.7).
32
Neben den Diensten stellt jede Software auf dem Rechner ein potentielles Sicherheitsrisiko dar. Aus diesem Grund sind überflüssige Pakete z.B. über Synaptic zu entfernen.
Damit nicht die Möglichkeit besteht, dass sich Schadsoftware auf dem Rechner selbst
übersetzt, ist es ratsam, alle Compiler (gcc) zu entfernen. Auch die Java Virtual Machine
muss entfernt werden.
Es besteht unter Ubuntu und vielen anderen Distributionen auch die Möglichkeit,
die Sicherheit des Systems mit dem Programm Bastille Linux halb automatisch zu
verbessern. Es beinhaltet die Änderung von Dateirechten, Bootreihenfolge, Logging,
Remote-Login u.v.m.
[Spe11, S. 143-167], [BSB04], [Ubu12a], [Ubu12b]
4.3.4 Router und lokale Firewall
Bei den Sicherheitseinstellungen bezüglich einer Firewall müssen zwei Netzwerkkomponenten betrachtet werden. Dies ist zum Einen die FritzBox 7240 und der PC 1.
Da die Linux-Distribution der FritzBox nicht verändert wurde und keinerlei Software
Erweiterungen durchgeführt wurden, läuft wie üblich lediglich ein Network Address
Translation (NAT) Router mit Portfilter sowie Black- und Whitelists. NAT ist im
Router aktiviert und es sind lediglich die Ports für Murmur (siehe Tabelle 2.2) und
TeamSpeak 3 (siehe Tabelle 2.1) frei geschaltet. Die Pakete, die auf dem in den Tabellen
2.2 und 2.1 angegebenen Port an die FritzBox vom Internet ankommen, werden auf
den PC 1 weiter geleitet. Alle anderen Pakete, die vom Internet ohne eine Anforderung
vom internen Netz an die FritzBox ankommen, werden ignoriert.
Zum Thema einer lokalen Firewall gehen die Meinungen in der Literatur und in der
öffentlichen Diskussion sehr weit auseinander. In einem solchen Fall ist es wichtig, sich auf
die Fakten zu konzentrieren. Wenn der Rechner keinen Dienst anbietet, dann kann auch
über den Dienst nicht angegriffen werden. Die Gefahr, in den Kernel des Betriebssystems
einzubrechen, besteht dabei fort. Ein wichtiger Vorteil einer lokalen Firewall ist, dass
eine Entscheidung getroffen werden kann, welcher Prozess eine Kommunikation mit
dem Netzwerk führen darf. Mit iptables kann über INPUT - und OUTPUT - Ketten
entschieden werden, ob ein Paket von außen das System passieren und ob ein Paket
vom System nach außen gelangen darf.
33
Um einen Überblick über bestehende Regeln des Systems zu erhalten, können diese
mit sudo iptables -L angezeigt werden. In Listing 4.3 ist das komplett kommentierte
Firewallskript für den Rechner PC 1 dargestellt. Nun ein paar wesentliche Erläuterungen
zu diesem Skript. Die Regel (0) im Listing 4.3 auf den Zeilen 6 und 7 ist gerade für
Ubuntu ganz wichtig, da viele Prozesse dieser Distribution zur Kommunikation InternetSockets verwenden. Aus diesem Grund muss der lokale Verkehr akzeptiert werden. Die
Regel (4) im Listing 4.3 auf Zeile 18 ist für den Fernzugriff über Secure Shell (SSH)
notwendig. um den Server von der Ferne zu managen. Zur Erhöhung der Sicherheit
kann auch statt der Regel (4) (Listing 4.3 Zeile 18) Regel (4a) aus Zeile 20 benutzt
werden. Damit kann nur von einem bestimmten Rechner auf den PC 1 über SSH
verbunden werden. Für einige Managementlösungen, ist ein Webserver notwendig. Um
auf die generierten Webseiten zugreifen zu können, wurde Regel (5) (siehe Listing 4.3
Zeilen 22 und 23) erstellt. Die Regeln (6) und (8) in den Zeilen 25 und 29 werden zur
Kommunikation über TeamSpeak 3 bzw. Murmur benötigt.
1
#!/bin/sh
2
# Diese Skript laed die Regel fuer die Firewall fuer einen Murmur− bzw.
TeamSpeak−Server
3
IPTABLES=”iptables”
4
REMOTE ACCESS=127.0.0.1
5
#(0) Akzeptiere lokalen Verkehr (Internet−Sockets)
6
$IPTABLES −A INPUT −i lo −j ACCEPT
7
$IPTABLES −A OUTPUT −o lo −j ACCEPT
8
#(1) Verwerfe alle nicht explizit akzeptierten Paket
9
$IPTABLES −P INPUT DROP
10
$IPTABLES −P OUTPUT DROP
11
#(2) Loesche alle Regeln in den INPUT− und OUTPUT−Ketten
12
$IPTABLES −F INPUT
13
$IPTABLES −F OUTPUT
14
#(3) Erlaube DNS Anfragen
15
$IPTABLES −A OUTPUT −p udp −−dport 53 −m state −−state NEW −j
ACCEPT
16
$IPTABLES −A OUTPUT −p tcp −−dport 53 −m state −−state NEW −j
ACCEPT
17
#(4) Erlaube neue SSH−Verbindungen (Administration)
18
$IPTABLES −A INPUT −p tcp −−dport 22 −m state −−state NEW −j
ACCEPT
19
34
#(4a) Empfehlung, wenn immer von einem bestimmten Host zugegriffen
wird
20
#$IPTABLES −A INPUT −p tcp −s $REMOTE ACCESS −−dport 22 −m
state −−state NEW −j ACCEPT
21
#(5) Erlaube neue HTTP−Verbindungen (Webinterfaces)
22
$IPTABLES −A INPUT −p tcp −−dport 80 −m state −−state NEW −j
ACCEPT
23
$IPTABLES −A OUTPUT −p tcp −−dport 80 −m state −−state NEW −j
ACCEPT
24
#(6) Erlaube neue TeamSpeak 3 Sprachuebertragung 9987 UDP
25
$IPTABLES −A INPUT −p udp −−dport 9987 −m state −−state NEW −j
ACCEPT
26
#(7) Erlaube neue telnet−Verbindung fuer TeamSpeak 3
27
$IPTABLES −A INPUT −p tcp −−dport 10011 −m state −−state NEW −
j ACCEPT
28
#(8) Erlaube neue Murmur Sprachuebertragung 64738 UDP Steuerkanal
64738 TCP
29
$IPTABLES −A INPUT −p udp −−dport 64738 −m state −−state NEW −
j ACCEPT
30
$IPTABLES −A INPUT −p tcp −−dport 64738 −m state −−state NEW −
j ACCEPT
31
#(9) Erlaube Antwortpakete und Fehlermeldungen fuer aufgebaute
Verbindungen
32
$IPTABLES −A INPUT −m state −−state ESTABLISHED,RELATED −j
ACCEPT
33
#(10) Erlaube aufgebaute Verbindungen nach aussen
34
$IPTABLES −A OUTPUT −m state −−state ESTABLISHED,RELATED −j
ACCEPT
Listing 4.3: Skript für eine lokale Firewall (PC 1) über iptables für Murmur und
TeamSpeak
Mit den Regeln in Listing 4.3 ist das Firewallskript (firewallMurmurTSSkript.sh) fertig
und muss nur noch bei jedem Bootvorgang gestartet werden. Es ist sinnvoll, das Skript
bei jedem Bootvorgang mit Netzwerkverbindung zu starten. Daher wird es ab Runlevel 3
gestartet. Das Firewallskript firewallMurmurTSSkript.sh wird in das Verzeichnis /etc/init.d/ kopiert. Mit chmod 755 /etc/inti.d/firewallMurmurTSSkript.sh wird
das Skript ausführbar gemacht. Es ist dabei zu kontrollieren, dass der Besitzer der Datei
firewallMurmurTSSkript.sh der Benutzer root ist. Nun muss noch ein Startlink erzeugt
werden. Dies kann mit den folgenden Befehlen in Listing 4.4 durchgeführt werden.
35
1
# cd /etc/rc3.d/
2
# ln −s /etc/init.d/firewallMurmurTSSkript.sh S05firewallMurmurTSSkript
Listing 4.4: Erzeugung eines Startlinks zur Ausführung des Firewallskript im Runlevel 3
Die zwei Zeilen in Listing 4.4 sind für die Runlevel 4 und 5 zu wiederholen. Die SNummer (in Listing 4.4) definiert die Reihenfolge der zu startenden Dienste. Diese
Angabe ist für die Berücksichtigung der Abhängigkeiten von Diensten untereinander
gedacht. Hier wird diese Angabe genutzt, um die Firewall vor dem Start des Netzwerks
zu starten, damit keine Sicherheitslücke entsteht, die ein Angreifer ausnutzen könnte.
1
# sudo nmap −sT −p− 192.168.1.100
2
Starting Nmap 5.21 ( http://nmap.org ) at 2012−12−12 22:02 CET
3
Nmap scan report for localhost (127.0.0.1)
4
Host is up (0.0000060s latency).
5
Not shown: 65520 closed ports
6
PORT STATE SERVICE
7
22/tcp open|filtered ssh
8
25/tcp open|filtered smtp
9
53/tcp open|filtered domain
10
80/tcp open|filtered http
11
139/tcp open|filtered netbios−ssn
12
445/tcp open|filtered microsoft−ds
13
631/tcp open|filtered ipp
14
4949/tcp open|filtered unknown
15
6502/tcp open|filtered netop−rc
16
8118/tcp open|filtered privoxy
17
18
19
20
21
22
23
Nmap done: 1 IP address (1 host up) scanned in 3.47 seconds
Listing 4.5: Ergebnis des Portscans mit nmap ohne lokale Firewall auf PC 1
Die Wirkungsweise der Firewall kann z.B. mit dem Network Mapper (nmap), einem
Programm zum Scannen von offenen Ports und darauf lauschenden Diensten, getestet
werden. Ohne den Einsatz einer Firewall konnte die Ausgabe in Listing 4.5 beobachtet
36
werden. Dabei wurde sudo nmap -sT -p- 192.168.1.100 aufgerufen. Der Parameter
-sT bewirkt, dass TCP geprüft wird. Soll das UDP getestet werden, muss -sU angegeben
werden.
Mit Firewall ist die Ausgabe (siehe Listing 4.6) deutlich kürzer.
1
# sudo nmap −sT −p− 192.168.1.100
2
Starting Nmap 5.00 ( http://nmap.org ) at 2012−12−12 22:06 CET
3
Interesting ports on adsd.fritz.box (192.168.1.100):
4
Not shown: 65531 filtered ports
5
PORT STATE SERVICE
6
22/tcp open ssh
7
80/tcp open http
8
10011/tcp open telnet
9
64738/tcp open unknown
10
MAC Address: 50:E5:49:49:63:71 (Unknown)
11
12
Nmap done: 1 IP address (1 host up) scanned in 135.58 seconds
Listing 4.6: Ergebnis des Portscans mit nmap mit lokaler Firewall auf PC 1
Ähnliche Ergebnisse konnten bei der Überprüfung von UDP beobachtet werden.
[Spe11, S. 82-141, S. 171-183]
4.3.5 Nutzerverwaltung
TeamSpeak 3-Server Der TeamSpeak 3-Server ist ohne weitere Konfigurationen
betriebsbereit. Wie bei Murmur/Mumble können über den Client auch einige administrative Einstellungen vorgenommen werden. Dazu wird sich am Client als serveradmin
angemeldet und es muss unter dem Menü Rechte I Berechtigungsschlüssel der Berechtigungsschlüssel (Token siehe Abbildung 4.2), der beim Ersten Start des Servers über
die Shell ausgegeben wurde, hinzugefügt werden. Nun müssen im Menü Rechte die
jeweiligen Rechte der Server-Gruppen und Channel-Gruppen überprüft und gegebenenfalls geändert werden. Es ist auf jeden Fall zu empfehlen, dass ausschließlich der
Server-Admin den Server administrieren darf. Normale Benutzer oder gar Gäste dürfen
dazu keine Rechte besitzen. Des Weiteren ist mit den Rechten zum Dateitransfer und zur
Mitgliederverwaltung sparsam umzugehen und die Erstellungsrechte hier dem Server-
37
Admin zu überlassen. Empfehlenswert ist hier, eine separate Moderatoren-Gruppe
anzulegen.
Murmur Nachdem der Server Murmur betriebsbereit ist, müssen dennoch die Gruppenberechtigungen überprüft werden. Zunächst ist mit sudo -i murmurd -ini /etc/mumble-server.ini -supw PASSWORD ein SuperUser -Passwort zu genieren. Nun kann
eine Verbindung über Mumble zum Server Murmur hergestellt werden. Dabei ist als
Benutzername SuperUser und das dazugehörige Passwort zu verwenden. Mit einem
Rechtsklick auf dem Hauptkanal und durch Betätigen von Bearbeiten wird das Gruppenund Berechtigungscenter geöffnet. Es ist wichtig, dass nur die Gruppe admin und evtl.
eine neu angelegte Gruppe moderator die Berechtigungen bearbeiten können. Bei der
Einstellung Selbst registrieren für die Gruppe all ist in diesem Zusammenhang zu
prüfen, ob dies wirklich erwünscht ist. Im Zweifelsfall ist dies zu deaktivieren.
4.3.6 Mensch als Schwachstelle
Neben den in diesem Kapitel erarbeiteten Maßnahmen technischer Natur müssen auch
Maßnahmen gegen die Schwachstelle Mensch erarbeitet werden. Dies hat den Grund,
dass der Mensch Informationen (z.B. Passwörter) besitzen muss, welche ihm Zugang
zum System gewähren. Ferner ist der Mensch angreifbarer hinsichtlich Täuschungen
und Manipulationen. So muss darauf geachtet werden, dass sensible Daten nicht an
unberechtigte Dritte gelangen.
Die erste Maßnahme ist die Wahl sicherer Passwörter. Es ist darauf zu achten, dass
die Passwörter möglichst lang (ca. 8 Stellen) sind und aus Buchstaben, Zahlen und
Sonderzeichen bestehen. Zusätzlich müssen stets unterschiedliche Passwörter gewählt
werden. Auch dürfen Passwörter und Logindaten nie auf auf dem PC gespeichert werden.
Es ist auch zu beachten, dass keine Logindaten an andere Personen weiter gegeben
werden, auch nicht auf Anfrage vermeintlicher Administratoren.
Ein weiterer Punkt ist das Herunterladen von Dateien oder Programmen. Es ist dabei
notwendig, genau zu prüfen, ob es sich um eine vertrauenswürdige Quelle handelt.
Über Instant Messenger oder E-Mail erhaltene Hyperlinks sind vor dem Anklicken bzgl.
ihrer Vertrauenswürdigkeit zu überprüfen. Beispielsweise kann die Dateiendung erste
Hinweise auf die Art der Daten geben. Auch bei E-Mail Anhängen ist Vorsicht geboten.
38
E-Mails dürfen generell nur im Textformat geöffnet werden, damit keine integrierten
Scripte ausgeführt werden.
Es ist wichtig, dass alle Nutzer des Sprachkonferenzsystems sorgfältig darauf achten,
alle erforderlichen Maßnahmen umzusetzen. Es bietet sich an dieser Stelle an, Verhaltensregeln zur Erhöhung der Sicherheit an die Nutzer zu tragen. In Unternehmen ist
die Durchführung spezieller Schulungen zu diesem Sachverhalt zu empfehlen.
39
5 Demonstration von
Angriffsszenarien
In diesem Kapitel werden eine Reihe von Angriffsszenarien betrachtet. Es werden
Sicherheitsmechanismen auf ihre Funktionen getestet, beispielsweise die Anti-FloodProtection von TeamSpeak. Dabei werden mögliche Angriffsszenarien betrachtet und
praktisch durchgeführt.
5.1 Betrachtung des TeamSpeak 3-Server Query
Interface
In diesem Abschnitt wird untersucht, welche Angriffsmöglichkeiten das TeamSpeak 3Server Query Interface bietet. Dabei werden verschiedene Schutzmechanismen betrachtet
und bewusst manipuliert. Als Angreifer wird dabei PC 3 aus Abbildung 4.1 verwendet.
Um mit dem TeamSpeak 3-Server Query Interface automatisiert zu kommunizieren,
wird in einem ersten Schritt ein Testprogramm (siehe Listing 5.1) erstellt. Mit diesem
Testprogramm werden dann in Abschnitt 5.1.2 und 5.1.3 Angriffsszenarien betrachtet
und durchgeführt.
5.1.1 Aufbau des Testprogramm
Das Testprogramm wird die Aufgabe besitzen, automatisiert Daten zum TeamSpeak 3Server Query Interface zu senden und zu empfangen. Für diese Aufgabe wurde ein
Java-Programm geschrieben. Dieses ist in Listing 5.1 auszugsweise dargestellt. Als Erstes
wird mit Hilfe der Klasse Socket eine Verbindung von PC 3 zum TeamSpeak 3-Server
Query Interface des PC 1 hergestellt. Daten können während der Verbindung mit den
40
Variablen out an den Server gesendet und mit in vom Server empfangen werden. Im
dargestellten Testbereich in Listing 5.1 können die zu sendenden Query-Befehle mit
out.println() als String angegeben werden. Nach Abschluss der Befehlsfolge werden die
vom Server (PC 1) empfangenen Daten ausgegeben.
1
[...]
2
try {
3
testSocket = new Socket(”77.179.185.146”, 10011 );
4
out = new PrintWriter(testSocket.getOutputStream(), true);
5
in = new BufferedReader(new InputStreamReader(testSocket.
getInputStream()));
//### Testbereich ###
6
7
out.println(”hier Query−Befehl als String”);
8
9
10
//############
11
String line = null;
12
while( (line=in.readLine()) != null){
13
if(!line.equals(””))
14
System.out.println(”SERVER: ”+line);
}
15
[...]
16
17
} catch (IOException e) {
System.err.println(”ERROR: Server refuse the connection.”);
18
19
}
20
[...]
Listing 5.1: Aufbau Testprogramm
Kann die Verbindung nicht aufgebaut werden oder wird sie unterbrochen, so wird eine
Fehlermeldung ausgegeben. In einem Versuch wird durch Ausführen des Testprogramms
eine Verbindung vom PC 3 zum TeamSpeak 3-Server Query Interface von PC 3
hergestellt.
1
SERVER: TS3
2
SERVER: Welcome to the TeamSpeak 3 ServerQuery interface, type ”help”
for a list of commands and ”help <command>” for information on a
specific command.
Listing 5.2: Ausgabe des Verbindungstests mit dem TeamSpeak 3-Server Query Interface
41
Die von der TeamSpeak 3-Server Query Interface empfangenen Daten sind in Listing
5.2 dargestellt. Daraus lässt sich entnehmen, dass eine Verbindung hergestellt werden
konnte.
5.1.2 Untersuchung der Anti-Flood-Protection
In diesem Szenario wird die Anti-Flood-Protection vom TeamSpeak 3-Server untersucht.
Diese dient dazu, die Anzahl der an das TeamSpeak 3-Server Query Interface gesendeten
Befehle für ein Zeitfenster zu limitieren und somit einem Missbrauch wie beispielsweise
dem Fluten mit Textnachrichten vorzubeugen.
In diesem Szenario wird davon ausgegangen, dass der Angreifer bereits Zugang zum
TeamSpeak 3-Server Query Interface besitzt. Ausgehend von dieser Situation möchte
der Angreifer den TeamSpeak 3-Server mit Textnachrichten fluten. Für diesen Zweck
wird im Testbereich des Testprogramms (Listing 5.1) die Befehlsfolge aus Listing 5.3
eingefügt. Um sich anzumelden, muss als Erstes der Befehl login verwendet werden.
Danach wird mit dem Befehl use der virtuelle Server ausgewählt. Jetzt kann mit Hilfe
einer Schleife eine beliebige Anzahl von Textnachrichten (hier numberOfMessages = 100)
an den Server geschickt werden.
1
2
out.println(”login serveradmin yI3K4DpO”);
3
out.println(”use 1”);
4
int numberOfMessages=100;
5
for( int i = 1; i <= numberOfMessages; i++ )
6
7
out.println(”sendtextmessage targetmode=3 msg=SPAMMSG Nr.”+i);
//############
Listing 5.3: TeamSpeak 3-Server Query Interface Login und Spam
Wird das Testprogramm ausgeführt, erhält man die im Listing 5.4 angegebene Ausgabe.
Daraus ist zu entnehmen, dass nach dem Senden der achten Nachricht die Anti-FloodProtection die Verbindung unterbricht.
Der TeamSpeak 3-Server Dokumentation ist zu entnehmen, dass die Anti-FloodProtection nur bei Verbindungen eingesetzt wird, deren IP-Adressen oder IP-Adress
bereiche nicht auf der Whitelist (query ip whitelist.txt) des TeamSpeak 3-Servers stehen.
Dabei sind Szenarien denkbar, in denen die IP-Adresse des Angreifers in die Whitelist
42
eingetragen wird. Zum Einen kann bei der Konfiguration des TeamSpeak 3-Servers
durch Unwissenheit wahllos von jedem Nutzer die IP-Adresse oder der IP-Adressbereich
eingetragen worden sein, da davon ausgegangen wurde, dass dies für den Zugriff auf
das Query Interface notwendig ist. Zum Anderen kann durch einen Tippfehler ein zu
großer IP-Adressbereich angegeben worden sein, in dem sich auch der Angreifer befindet.
Zusätzlich kann eine fehlerhafte Konfiguration der Anti-Flood-Protection dazu führen,
dass diese nicht wirkt.
1
SERVER: error id=0 msg=ok
2
3
4
5
6
7
8
9
10
ERROR: Server refuse the connection.
Listing 5.4: Verbindungsabbruch durch die Anti-Flood-Protection
Für weitere Tests wird daher die IP-Adresse von PC 3 in die Whitelist eingetragen.
Bei erneutem Durchführen der Befehlsfolge aus Listing 5.3 ist keine Verbindungsunterbrechung zu beobachten. Zur Veranschaulichung ist in Abbildung 5.1 die Wirkung als
Ausschnitt im TeamSpeak 3-Client dargestellt.
Abbildung 5.1: TeamSpeak 3 Server Query Interface Text Flut
Wie erwartet, kann die Anti-Flood-Protection, durch einen Eintrag in die Whitelist
gezielt deaktiviert werden. Aufgrund der daraus entstehenden Gefahren wird jedoch
davon abgeraten. In manchen Fällen kann es jedoch erwünscht sein (für z.B. Fernwartungen), IP-Adressen oder ganze IP-Adressbereiche auf die Whitelist zu setzen. Diese
Experimente zeigen, dass dabei sehr sorgfältig vorgegangen werden muss.
43
5.1.3 Brute-Force-Angriff auf das Query Interface
In Abschnitt 5.1.2 wurde gezeigt, dass die Anti-Flood-Protection, wie erwartet, bei
Adressen, welche in der Whitelist stehen, die Anzahl gesendeter Befehle nicht beschränkt.
An dieser Stelle stellt sich die Frage, ob ein Angreifer ohne gültige Logindaten mit
deaktivierter Anti-Flood-Protection einen Brute-Force-Angriff auf das TeamSpeak 3Server Query Interface durchführen kann. Dies war beispielsweise bei TeamSpeak 2 mit
dem Programm THC − Hydra ([Hau12]) möglich. Der Testbereich im Testprogramm
(Listing 5.1) wird dafür mit der unter Listing 5.5 dargestellten Befehlsfolge ersetzt. Die
Befehlsfolge sendet mehrfach den login Befehl mit unterschiedlichen Passwörtern.
1
2
String[] pws = {”a”,”b”,”c”,”aa”,”ab”,”ac”,”bb”,”ba”,”bc”,”cc”,”ca”,”cb”};
3
for( String pw : pws){
out.println(”login serveradmin ”+pw);
4
5
}
6
//############
Listing 5.5: Brute-Force-Befehlsfolge, um ein TeamSpeak 3-Query Interface Login zu
erhalten
Nach Ausführen der Befehlsfolge erhält man die unter Listing 5.6 dargestellte Antwort von dem TeamSpeak 3-Server Query Interface. Dem ist zu entnehmen, dass das
TeamSpeak 3-Server Query Interface nach dem vierten fehlerhaften Loginversuch den
Angreifer für 10 Minuten verbannt.
1
SERVER: error id=520 msg=invalid loginname or password
2
3
4
SERVER: error id=3329 msg=connection failed, you are banned extra msg=
you may retry in 600 seconds
Listing 5.6: TeamSpeak 3-Server Query Interface Reaktion auf Brute-Force-Befehlsfolge
Damit hat sich herausgestellt, dass neben der Anti-Flood-Protection ein weiterer
unabhängiger Mechanismus existiert, welcher gegen Brute-Force-Angriffe vorbeugt.
Durch die Dauer der Verbannung sind bei einem einzigen angreifenden Rechner maximal
576 Passwörter pro Tag testbar. Das heißt, Brute-Force-Angriffe sind durchführbar,
werden jedoch stark beeinträchtigt. An dieser Stelle wird klar, wie wichtig die Wahl eines
44
5.2 TeamSpeak 3-Server Query Interface Exploit
sicheren Passwortes ist. Denn je länger das Passwort ist und um so mehr verschiedene
Zeichen es beinhalten kann, um so mehr mögliche Passwörter sind bei einem Brute-ForceAngriff zu testen. Dadurch werden solche Angriffe in einem realistischen Zeitfenster
nicht mehr durchführbar.
Mit dem folgenden Szenario wird aufgezeigt, welche Auswirkungen das Ausnutzen einer
Sicherheitslücke mit Hilfe eines Exploit haben kann. Ausgangspunkt dieser Szenarien ist
die Missachtung oder Vernachlässigung der in Abschnitt 4.3.1 dargestellten Maßnahme,
die Sprachkonferenzsoftware stets auf der aktuellsten Version zu halten. Es sei an dieser
Stelle noch einmal gesagt, dass auch in einer aktuellen Version diese Art von Angriff
nicht ausgeschlossen werden kann, wie in Abschnitt 3.2.4 bereits angedeutet.
Für das Szenario wird die in Kapitel 4 aufgebaute Untersuchungsumgebung dahingehend
modifiziert, dass der verwendetet TeamSpeak 3-Server mit der Version 3.0.6.1 auf PC 1
durch die Version 3.0.0.0-beta23 ersetzt wird. Bis zu dieser Version ist durch die Verwendung eines von Luigi Auriemma geschriebenen C-Programms namens teamspeakrack
möglich [Aur10c], eine Schwachstelle auszunutzen. Das C-Programm steht als Quelltext (teamspeakrack.c) zur Verfügung. Als Angreifer wird PC 3 (siehe Abbildung 4.1)
verwendet.
Mit Hilfe von teamspeakrack ist es möglich, TeamSpeak 3-Server Query-Befehle auf
dem TeamSpeak-Server (PC 1) auszuführen, ohne einen authentifizierten Zugriff auf
das Query Interface zu besitzen. Zusätzlich verfügt das C-Programm über vorgefertigte
Angriffsszenarien in Form von Befehlssequenzen. Nach dem Start von teamspeakrack
werden, wie in Abbildung 5.2 zu sehen, alle Szenarien, die das Programm bietet,
aufgelistet.
5.2.1 Funktionsweise von teamspeakrack
Mit Hilfe von teamspeakrack wird eine Schwachstelle ausgenutzt, welche bei der Umstellung des TeamSpeak-Protokolls entstanden ist. TeamSpeak 3 verwendet UDP-Pakete
für acht verschiedene Aufgaben (8 Kanäle). Speziell der Kanal 2 wird für das Senden
45
Abbildung 5.2: Verwendung und Optionen des TeamSpeak 3 Server Exploit
von Befehlen, zwischen dem TeamSpeak 3-Client und -Server verwendet. Das Problem
besteht darin, dass auch Query-Befehle welche über das UDP-Paket auf Kanal 2
gesendet werden, auf dem Server ausgeführt werden. Das heißt, um die Schwachstelle
auszunutzen, muss ein modifiziertes UDP-Paket über den standardmäßig geöffneten
Port 9987 an den Server gesendet werden. Dieses Paket wird so modifiziert, dass ein
Query-Befehl an den Server gesendet wird. Dieses Einschleußen von Query-Befehlen
wird auch als Bypass bezeichnet. Um dies zu testen, wird teamspeakrack zunächst mit
der Option 1 (siehe Abbildung 5.2) in einen Zustand versetzt, welcher die selben Möglichkeiten bietet, als wäre der Angreifer mit dem TeamSpeak 3-Server Query Interface
verbunden. Das heißt, der Angreifer kann mit teamspeakrack fortlaufend Query-Befehle
senden. Die dabei für den Angreifer zu sehende Oberfläche ist in Abbildung 5.3 zu sehen.
Da die Query-Befehle über ein UDP-Paket in den Server eingeschleust werden, können
lediglich Fehlermeldungen empfangen werden. Das heißt, man kann mit teamspeakrack
keine Informationen vom Server mit Hilfe von Query-Befehlen abfragen.
Es ist nun nicht mehr notwendig, sich mit Hilfe gültiger Logindaten über TCP Port 10011
Zugriff auf das TeamSpeak 3-Server Query Interface zu verschaffen, um Konfigurationen
bzw. Manipulationen auf dem TeamSpeak 3-Server vorzunehmen. Aufbauend auf dieser
Situation können jetzt gezielt Angriffe - basiert auf dem Senden von Query-Befehlen
- gegen den Sprachdienst durchgeführt werden. Die dabei möglichen Befehle können
dem TeamSpeak 3-Server Query Handbuch entnommen werden. Eine Reihe solcher
Möglichkeiten sind als Befehlsfolgen in das Programm integriert und können ausgeführt
werden.
46
Abbildung 5.3: TeamSpeak 3 Server Query Interface Exploit
5.2.2 Einrichten einer Hintertür
Als nächstes wird gezeigt, wie eine Hintertür (Backdoor) auf dem TeamSpeak 3-Server
eingerichtet werden kann. Dafür wird ein administrativer Zugriff eingerichtet. Zunächst
wird sich als Nutzer mit dem TeamSpeak 3-Client von PC 3 zum Server (PC 1)
verbunden. Dabei ist der TeamSpeak 3-Client vorerst nur als Gast verbunden und
besitzt keine administrativen Rechte. Dies ist in Abbildung 5.4 im rot markierten
Bereich zu sehen.
Abbildung 5.4: Als Gast auf dem TeamSpeak 3 Server verbunden
Um jetzt Administrationsrechte zu erhalten, muss der Client der Gruppe der Serveradministratoren, welche durch eine Identifikationsnummer gekennzeichnet ist, zugeordnet
werden. Dafür wird mit dem C-Programm teamspeakrack der Server Query-Befehl aus
Listing 5.7 ausgeführten Syntax verwendet.
1
#servergroupaddclient sgid={groupID} cldbid={clientDBID}
Listing 5.7: Query-Befehl servergroupaddclient Syntax
47
Die benötigten Informationen groupID und clientDBID können zwar nicht mit teamspeakrack
ermittelt werden, aber durch den verbundenen Client ist es möglich. Die groupID für
die richtige Servergruppe erhält der Angreifer im Menü Rechte unter dem Punkt
Channelgruppen im TeamSpeak 3-Client. In diesem Fall besitzt die Servergruppe der
Administratoren die groupID = 6. Die clientDBID erhält der Angreifer ebenfalls im
TeamSpeak 3-Client, indem er in der Channelübersicht auf den gewünschten Client
klickt. Aus Abbildung 5.4 geht aus dem blau markierten Bereich hervor, dass die
clientDBID = 2 ist. Der gesamte Befehl, der jetzt mit teamspeakrack abgesendet werden
muss, ist in Listing 5.8 angegeben.
1
>servergroupaddclient sgid=6 cldbid=2
Listing 5.8: Query-Befehle zur Zuweisung zu einer Gruppe
Ob der Vorgang erfolgreich war, kann dem TeamSpeak 3-Client entnommen werden.
Das Ergebnis ist in Abbildung 5.5 durch die rot markierten Stellen gekennzeichnet.
Abbildung 5.5: Gast mit vollen Administrationsrechten
Auf diese Weise wurde demonstriert, wie einem Gast Administrationsrechte zugesichert
werden können. Da bei einem Update der Sprachkonferenzsoftware, welche die Sicherheitslücke schließt, die Administrationsrechte für den vermeintlichen Gast bestehen
bleiben, wurde erfolgreich eine Hintertür eingerichtet. Es wird empfohlen, nach dem
Bekanntwerden und Schließen einer solchen Sicherheitslücke mit Hilfe von Backups oder
Sicherungspunkten das System auf einen früheren Zustand zurück zu setzen. Ist dies
nicht möglich, sollte die Rechtevergabe erneut durchgeführt werden.
48
5.2.3 Null Pointer Dereferenzierung
Des Weiteren gibt es eine Reihe Query-Befehle, die aufgrund der Art und Weise, wie
teamspeakrack sie an den TeamSpeak 3-Server sendet, zum Absturz führen. Diese sind
in Listing 5.9 aufgezählt.
1
>banlist
2
>complainlist
3
>servernotifyunregister
4
>serverrequestconnectioninfo
5
>setconnectioninfo
6
>servernotifyregister event=server
Listing 5.9: Query-Befehle, die mit teamspeakrack zum Absturz führen
Der Grund für den Absturz bei Verwendung dieser Befehle ist, dass bei der Verarbeitung
der Befehle Informationen des Client, welcher den Befehl ausführen möchte, benötigt
werden. Da bei Verwendung von teamspeakrack keine ordnungsgemäße Verbindung
hergestellt wird, kann der TeamSpeak 3-Server den Befehl keinem gültigen Client
zuordnen. Dadurch entsteht bei der Abfrage, welcher Client dem Befehl zuzuordnen ist,
eine NullPointerException und der TeamSpeak 3-Server wird aufgrund dieses Fehlers
stillschweigend beendet.
5.2.4 Server mit Textnachrichten fluten
In diesem Szenario wird der TeamSpeak 3-Server mit Textnachrichten geflutet (Spam).
Für diesen Zweck wird der im Listing 5.10 aufgeführte Befehl verwendet.
1
#sendtextmessage targetmode={1−3} msg={text}
Listing 5.10: Query-Befehl sendtextmessage Syntax
In teamspeakrack wird dieser Befehl (5.10) mit Hilfe einer Schleife und zufällig generierten Nachrichten an den Server gesendet. Mit der Option 4 (siehe 5.2) kann diese
Befehlssequenz aufgerufen werden. In Abbildung 5.6 ist die Wirkung anhand des Nachrichtenfensters des TeamSpeak 3-Clients zu sehen. In der Abbildung ist ein Ausschnitt
der gesendeten zufällig generierten Nachrichten dargestellt.
49
Abbildung 5.6: Auswirkung von Spam mit teamspeakrack im TeamSpeak 3-Client
Das Interessante ist, dass die Anti-Flood-Protection des TeamSpeak 3-Servers, d.h. die
Einschränkung der gesendeten Befehle pro Zeitintervall, nicht greift. Dies ist mit dem
Einschleusen der Befehle über die UDP-Pakete zu begründen. Dadurch werden die
IP-basierten Filter (Anti-Flood-Protection) des TeamSpeak 3-Server Query Interface
übergangen.
5.2.5 Weitere Möglichkeiten von teamspeakrack
Neben den bisher vorgestellten Möglichkeiten, den TeamSpeak 3-Server zu manipulieren,
bietet teamspeakrack weitere vorgefertigte Befehlssequenzen, welche durch die Optionen
1 bis 9 (siehe Abbildung 5.2) ausgewählt werden können.
Dazu gehört die Möglichkeit, die maximale Anzahl von Clients auf dem TeamSpeak 3Server mit Hilfe des unter Listing 5.11 aufgeführten Befehls auf Null zu setzen. Dadurch
ist es nicht mehr möglich, mit dem TeamSpeak-Client eine Verbindung mit dem
TeamSpeak 3-Server herzustellen.
1
>serveredit virtualserver maxclients=0
Listing 5.11: Query-Befehl zur Änderung der maximalen Anzahl von Clients auf dem
Server
Die bisher noch nicht betrachteten und vorgefertigten Optionen von teamspeakrack
(siehe Abbildung 5.2) ermöglichen es, ohne Kenntnisse diverser Identifikationsnummern
(z.B. clientID oder banID), alle Clients anzusprechen. Dabei werden Befehle, welche
die Angabe einer Identifikationsnummer benötigen, innerhalb einer Schleife ausgeführt.
Die dabei aufsteigende Schleifenvariable wird entsprechend als Parameter beim Aufruf
eines Befehls verwendet. So wird iterativ jede mögliche ID zusammen mit einem Befehl
verwendet. Die dafür zur Verfügung stehenden - in teamspeakrack implementierten Möglichkeiten sind:
• alle Clients vom Server werfen
50
5.3 Murmur Exploit für einen DoS-Angriff
• alle Clients vom Server verbannen
• alle Banns auf dem Server aufheben und
• alle Clients auf dem Server anstupsen.
Die dabei verwendeten Befehle sind in Listing 5.12 aufgeführt.
1
#Client vom Server schmeissen
2
#Syntax: clientkick clid={clientID} reasonid={4|5}
3
#Client vom Server verbannen
4
#Syntax: banclient clid={clientID}
5
#Bann aufheben
6
#Syntax: bandel banid={banID}
7
#Client auf dem Server an stupsen
8
#Syntax: clientpoke clid={clientID} msg={Text}
Listing 5.12: Beispiel für Query-Befehle mit Parameter
Damit wurde gezeigt, welche verheerenden Auswirkung ein Exploit haben kann. Aus
dem Beispiel 5.2.2 ist hervorgegangen, dass durch eine Aktualisierung der Software
und somit die Schließung der bestehenden Sicherheitslücke nicht garantiert werden
kann, dass der TeamSpeak 3-Server keine Folgeschäden davon getragen hat. In diesem Fall wäre der Folgeschaden die in Abschnitt 5.2.2 eingerichtete Backdoor (siehe
Abschnitt 3.2.5). Es ist also zwingend notwendig, nach Bekanntwerden einer solchen
Sicherheitslücke das System genau zu prüfen. Falls möglich, sollte in diesem Fall das
System auf einen früheren Zustand zurück gesetzt werden. Dies kann beispielsweise
durch Wiederherstellungspunkte oder Backups erfolgen.
Bei dem Murmur-Server der Version kleiner 1.2.2 und Beta 1.2.3 wurde ein Exploit
durch Luigi Auriemma bekannt. Durch einen fehlerhaften Datentyp in der SQL-Abfrage
ist es möglich, den Sprachkonferenzserver Murmur aufgrund eines Fehlers beim Umgang
mit fehlerhaften SQL-Abfragen zum Beenden zu zwingen. Der Angreifer muss sich
dabei mit dem Server verbinden, um den Fehler auszunutzen. Das Demo Programm
von Luigi Auriemma generiert eine SQL-Abfrage. In der like Klausel sind fast alle
51
Zeichen Unicode Transformation Format (UTF)-8 Zeichen, außer ein paar
wenige UTF-32 Zeichen. Diese SQL-Abfrage bringt den Server zum Absturz.
(a) Das Programm mumbleed wird mit der IP- (b) Der Mumble-Client ist mit dem MurmurAdresse des Murmur-Servers als Parameter auf- Server verbunden.
gerufen.
Abbildung 5.7: Murmur Exploit für einen DoS-Angriff: Kommandozeile und MumbleClient vor dem Angriff.
Um die Wirkungsweise des Exploits zu zeigen, wird der Murmur Server auf PC 1 mit der
Version 1.2.2 installiert. Das Paket ist unter http://pkgs.org/ubuntu-10.04/ubuntuuniverse-i386/mumble-server_1.2.2-1ubuntu1_i386.deb.html verfügbar und wird
als deb-Paket über die Paketverwaltung installiert. Auch das Programm zur Demonstration des Exploits mumbleed steht unter [Aur10a] als C-Programm zur Verwendung
bereit.
(a) Das Programm mumbleed wurde ausgeführt
und hat den Murmur-Server beendet.
(b) Der Mumble-Client ist nicht mehr mit dem
Murmur-Server verbunden.
Abbildung 5.8: Murmur Exploit für einen DoS-Angriff: Kommandozeile und MumbleClient nach dem Angriff.
Das Programm mumbleed wird, wie in Abbildung 5.7 dargestellt, mit der IP-Adresse
52
(192.168.1.100) des Murmur-Servers (PC 1) als Parameter gestartet. Um die Auswirkungen des Programms mumbleed beobachten zu können, wird eine Verbindung zwischen
den Murmur-Server (PC 1) und des Mumble Clients (PC 2) hergestellt. Dem MumbleClient-Fenster (Abbildung 5.7) kann entnommen werden, dass eine Verbindung zum
Server hergestellt wurde.
Nachdem das Programm mumbleed ausgeführt wurde (siehe Abbildung 5.8), ist die
Verbindung zwischen Client und Server unterbrochen und kann nicht ohne ein erneutes
Starten des Murmur-Servers wiederhergestellt werden.
[Aur10b], [Aur10a]
53
In Kapitel 2 wurden die Sprachkonferenzsysteme TeamSpeak 3 und Mumble/Murmur
hinsichtlich ihrer Grundfunktionalitäten untersucht und verglichen. Dabei sind viele
Parallelen zwischen den Sprachkonferenzsystemen hervorgegangen. Deshalb ist Mumble/Murmur als gleichwertige Alternative zu TeamSpeak 3 anzusehen. Im Punkt der
verwendeten Codecs (siehe Abschnitt 2.5) hat sich Mumble/Murmur mit dem Einsatz
von Opus sogar als zukunftsorientierter erwiesen. Den größten Unterschied bilden die
unterschiedlichen Lizenzmodelle. Besonders für kommerzielle Unternehmen scheint die
Wahl für den Einsatz von Mumble/Murmur aus Kostengründen attraktiver.
Aus Kapitel 3 ist hervorgegangen, welche Schwachstellen in einem Sprachkonferenzsystem existieren können. Es hat sich gezeigt, dass mit einer detaillierten Analyse
viele Schwachstellen aufgedeckt werden können, welche man erst durch eine nähere
Betrachtung von Schutzzielen, Angriffsarten und Bedrohungen erkennt. Dies soll vor
allem ein Appell an Unternehmen sein, welche dem Sicherheitsmanagement und der
damit verbundenen Analyse des Systems nicht ausreichend Bedeutung zumessen.
In Kapitel 4 wurde beispielhaft eine Testumgebung auf Grundlage der in Kapitel 3
identifizierten Schwachstellen aufgebaut und getestet. Dabei wurden zahlreiche Maßnahmen und Empfehlungen vorgestellt, welche die Sicherheit des Sprachkonferenzsystems
enorm steigern. Besonders hervorzuheben sind dabei Maßnahmen der Konfiguration des
Sprachkonferenzsystems selbst, des Betriebssystems und der Firewall. An dieser Stelle
ist auch noch einmal auf die Schwachstelle Mensch“ hingewiesen, welcher nur durch
”
einen bewussten und sicherheitsorientierten Umgang mit einem Sprachkonferenzsystem
entgegen gewirkt werden kann.
Abschließend wurden in Kapitel 5 eine Reihe Szenarien aufgezeigt, welche die Angreifbarkeit von Sprachkonferenzsystemen demonstrieren. Daraus ist hervorgegangen,
welche Auswirkungen die Missachtung von Sicherheitsmaßnahmen, wie beispielsweise
die Verwendung aktueller Softwareversionen, haben kann. Es wurde gezeigt, dass die
54
Schwachstelle Mensch durch unachtsame Konfiguration oder die Verwendung unsicherer
Passwörter ein großes Sicherheitsrisiko darstellt.
Insgesamt wurde gezeigt, dass sowohl TeamSpeak 3 als auch Mumble/Murmur hohe
Sicherheitsstandards bieten, aber dennoch angreifbar sind. Da Mumble/Murmur im
Vergleich zu TeamSpeak 3 quelloffen ist und somit zur Identifikation von Sicherheitslücken einem größeren Personenkreis zur Verfügung steht, einen fortschrittlicheren
Codec verwendet und keinen lizenzrechtlichen Einschränkungen unterworfen ist, ist die
Verwendung von Mumble/Murmur zu empfehlen.
55
[Aur10a]
Auriemma, Luigi: Murmur: QueryUsers SQLite database bug. http:
//aluigi.org/poc/mumbleed.zip. Version: 2010. – aufgerufen: 02.01.2012
[Aur10b]
Auriemma, Luigi: Murmur: QueryUsers SQLite database bug. http:
//aluigi.altervista.org/adv/mumbleed-adv.txt. Version: 2010. – aufgerufen: 02.01.2012
[Aur10c]
Auriemma, Luigi: teamspeakrack. http://aluigi.altervista.org/adv/
teamspeakrack-adv.txt. Version: 2010. – aufgerufen: 02.01.2012
[Bad10]
Badach, Anatol: Voice over IP: Die Technik. HANSER, 2010
[BSB04]
Barrett, D.J. ; Silverman, R.E. ; Byrnes, R.G.: Linux-SicherheitsKochbuch. O’Reilly Germany, 2004
[BSI04]
Projektgruppe E-Government im Bundesamt für Sicherheit in der Informationstechnik(BSI):
Sichere Kommunikation im E-Government.
https://www.bsi.bund.de/cae/servlet/contentblob/476846/
publicationFile/28062/4_SiKomm_pdf.pdf.
Version: 2004. –
aufgerufen: 29.11.2012
[Cam10]
Camboulive, Hugo:
An open source alternative to the Teamspeak server with protocol compatibility. https://github.com/Youx/
soliloque-server/wiki/TeamSpeak-protocol. Version: 2010. – aufgerufen: 25.11.2012
[EE07]
Evren Eren, Detken Kai-Oliver: VoIP Security. HANSER, 2007
[Hau12]
Hauser van:
THC-Hydra.
http://www.thc.org/thc-hydra/.
Version: 2012. – aufgerufen: 30.11.2012
56
[MuM12a] Das Mumble-Team:
Mumble offizielle Webpränz.
http://mumble.
sourceforge.net/. Version: 2012. – aufgerufen: 25.11.2012
[MuM12b] Das Mumble-Team: Mumble offizielle Webpränz: ACL. http://mumble.
sourceforge.net/ACL_Tutorial/Deutsch. Version: 2012. – aufgerufen:
25.11.2012
[MuM12c] Das Mumble-Team: Mumble offizielle Webpränz: FAQ. http://mumble.
sourceforge.net/. Version: 2012. – aufgerufen: 25.11.2012
[MuM12d] Das Mumble-Team: Mumble offizielle Webpränz: Installing. http://
mumble.sourceforge.net/Installing_Mumble. Version: 2012. – aufgerufen: 25.11.2012
[Nat12a]
Natenom: Natenom: Mumble Benutzerhandbuch. http://wiki.natenom.
name/mumble/benutzerhandbuch. Version: 2012. – aufgerufen: 25.11.2012
[Nat12b]
Natenom: Natenom: wiki. http://wiki.natenom.name/. Version: 2012. –
[PHC08]
Xiph.Org Foundation: Celt Projekthomepage. http://celt-codec.org.
[PHO11]
Xiph.Org Foundation: Opus Projekthomepage. http://opus-codec.org.
[PHS94]
Xiph.Org Foundation: Speex Projekthomepage. http://www.speex.org.
[SH10]
Stefan Hacker, Mikko R.: Mumble protocol 1.2.X reference (WIP).
(2010)
[Spe11]
Spenneberg, R.: Linux-Firewalls mit iptables & Co.: Sicherheit mit Kernel
2.4 und 2.6 für Linux-Server und Netzwerke. Pearson Deutschland GmbH,
2011
[TSo12a]
TeamSpeak Systems GmbH: TeamSpeak offizielle Webpränz. http://www.
teamspeak.com. Version: 2012. – aufgerufen: 25.11.2012
[TSo12b]
TeamSpeak Systems GmbH: TeamSpeak offizielle Webpränz: Downloads.
57
http://www.teamspeak.com/?page=downloads. Version: 2012. – aufgerufen: 25.11.2012
[TSo12c]
TeamSpeak Systems GmbH: TeamSpeak offizielle Webpränz: FAQ. http:
//www.teamspeak.com/?page=faq. Version: 2012. – aufgerufen: 25.11.2012
[TSo12d]
TeamSpeak Systems GmbH: TeamSpeak offizielle Webpränz: Licensing Overview. http://sales.teamspeakusa.com/licensing.php. Version: 2012. –
[TSo12e]
TeamSpeak Systems GmbH: TeamSpeak offizielle Webpränz: Permissions
Guide. http://media.TeamSpeak.com/ts3_literature/TeamSpeak%203%
20Permissions%20Guide.txt. Version: 2012. – aufgerufen: 25.11.2012
[TSo12f]
TeamSpeak Systems GmbH: TeamSpeak offizielle Webpränz: Support. http:
//support.teamspeakusa.com/index.php. Version: 2012. – aufgerufen:
25.11.2012
[TSo12g]
TeamSpeak Systems GmbH: TeamSpeak offizielle Webpränz: What
is TeamSpeak. http://media.TeamSpeak.com/ts3_literature/What%
20Is%20TeamSpeak.pdf. Version: 2012. – aufgerufen: 25.11.2012
[Ubu12a]
ubuntu Deutschland e.V.: Sicherheitskonzepte. http://wiki.ubuntuusers.
de/Sicherheitskonzepte. Version: 2012. – aufgerufen: 11.12.2012
[Ubu12b]
ubuntu Deutschland e.V.: sudo Konfiguration. http://wiki.ubuntuusers.
de/sudo/Konfiguration. Version: 2012. – aufgerufen: 11.12.2012
58
2.1
4.1
4.2
4.3
4.4
4.5
4.6
4.7
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Schematische Darstellung des Client-Server-Modells von TeamSpeak 3
und Mumble/Murmur . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Schematische Darstellung der Untersuchungsumgebung . . . . . . . . .
Start des TeamSpeak 3-Servers mit Hilfe des Startskriptes. Beim ersten
Start werden das Administrator-Passwort und ein Token generiert. . . .
Installation und Einrichtung des TeamSpeak 3 Clients . . . . . . . . . .
Teamspeak 3 Client: Verbindung zu einem Server herstellen . . . . . . .
Schritte der Installation und Einrichtung von Mumble . . . . . . . . . .
Benutzung von Mumble . . . . . . . . . . . . . . . . . . . . . . . . . .
Dienste mit rcconf deaktivieren . . . . . . . . . . . . . . . . . . . . . .
23
TeamSpeak 3 Server Query Interface Text Flut . . . . . . . . . . . . . .
Verwendung und Optionen des TeamSpeak 3 Server Exploit . . . . . .
TeamSpeak 3 Server Query Interface Exploit . . . . . . . . . . . . . . .
Als Gast auf dem TeamSpeak 3 Server verbunden . . . . . . . . . . . .
Gast mit vollen Administrationsrechten . . . . . . . . . . . . . . . . . .
Auswirkung von Spam mit teamspeakrack im TeamSpeak 3-Client . . .
Murmur Exploit für einen DoS-Angriff: Kommandozeile und MumbleClient vor dem Angriff. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Murmur Exploit für einen DoS-Angriff: Kommandozeile und MumbleClient nach dem Angriff. . . . . . . . . . . . . . . . . . . . . . . . . . .
43
46
47
47
48
50
24
25
26
28
29
32
52
52
59
Tabellenverzeichnis
Tabellenverzeichnis
2.1
2.2
Übersicht über die genutzten Standard-Ports von TeamSpeak 3 zu den
jeweiligen Diensten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Übersicht über die genutzten Standard-Ports von Mumble/Murmur zu
den jeweiligen Diensten. . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
3.1
Mögliche Verletzungen bzw. Folgen, die sich aus den Bedrohungen durch
Verursacher und deren Ziele ergeben (Vgl. [Bad10, S.486]) . . . . . . .
3.2 Mögliche Folgen die sich durch Ausnutzung einer Schwachstelle ergeben
können. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
19
21
ABR average bit rate. 7
AbS Analysis-by-Synthesis. 6
AES Advanced Encryption Standard. 4
ATHP Autorisierte TeamSpeak Host Provider. 8
CBR constant bit-rat. 7
CELP Code-Excited Linear Prediction. 6
CELT Constrained-Energy Lapped Transform. 6, 7
DDoS Distributed Denial of Service. 15
DoS Denial of Service. 15
DSL Digital Subscriber Line. 22
DTX Discontinuous Transmission. 7
DynDNS dynamisches Domain-Name-System. 23
FQDN Fully Qualified Domain Name. 23
GPL General Public License. 9
GSM Global System for Mobile Communications. 6
IP Internet Protokoll. 22, 23, 26
LPC Linear Predictive Coding. 6
MITM Man-in-the-middle. 17
61
NAT Network Address Translation. 33
NPL Non-Profit-Lizenz. 8
OCB Offset Codebook Mode. 4
PCM Puls-Code-Modulation. 6
PLC Packet Loss Concealment. 7
QoS Quality of Service. 12
SDK Software Development Kit. 8
SHA Secure Hash Algorithm. 4
SSH Secure Shell. 34
TCP Transmission Control Protocol. 3, 27, 37
TLS Transport Layer Security. 4
UDP User Datagram Protocol. 3, 24, 27, 37, 45, 46, 50
UTF Unicode Transformation Format. 52
VAD Voice Activity Detection. 7
VBR variable bit rate. 7
WAN Wide Area Network. 1
62
Eigenständigkeitserklärung
Die vorliegende Arbeit wurde von uns mit größter Sorgfalt selbständig ohne Benutzung
anderer als den angegebenen Quellen erstellt. Textstellen, die wörtlich oder sinngemäß
übernommen wurden, sind als solche kenntlich gemacht.
Marco Franke
Marcel Graef
Leipzig, den 24. Februar 2012
63

Mumble/Murmur und Teamspeak

Transcription

Similar documents

UNIX-KURZANLEITUNG

Virtuelle (Lern-)Welten, Second Life in der Lehre - e

Broschüre HEINE BETA LED Ophthalmoskope

Alcatel OmniPCX Enterprise - Universität Koblenz · Landau