Hochschule fur¨ Technik, Wirtschaft und Kultur Leipzig Fakult¨at 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 Einleitung1

2 Vergleich von Mumble/Mumur und TeamSpeak 32 2.1 Anwendungsgebiete...... 2 2.2 Funktionsweise und Protokolle...... 2 2.3 Das Channel- und Rechtesystem...... 4 2.4 Authentifizierung und Verwaltung der Clients...... 5 2.5 Sprachcodecs...... 6 2.5.1 CELP...... 6 2.5.2 Speex...... 7 2.5.3 CELT...... 7 2.5.4 Opus...... 7 2.6 Unterstutzte¨ Betriebssysteme...... 8 2.7 Lizenzmodelle...... 8 2.8 Weitere Besonderheiten...... 9

3 Sicherheitsanalyse und Ermittlung von Schwachstellen 10 3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme...... 10 3.1.1 Verfugbarkeit¨ ...... 11 3.1.2 Vertraulichkeit...... 11 3.1.3 Verbindlichkeit...... 11 3.1.4 Weitere Anforderungen...... 12 3.2 Typische Angriffsarten...... 13 3.2.1 Computervirus...... 13 3.2.2 Wurm...... 13 3.2.3 Trojaner...... 13 3.2.4 Exploit...... 14 3.2.5 Backdoor...... 14 3.2.6 Rootkit...... 15 3.2.7 Denial of Service...... 15 3.2.8 Spoofing...... 15 3.2.9 Sniffing...... 16

Marcel Graef & Marco Franke i Inhaltsverzeichnis

3.2.10 Port Scanning...... 16 3.2.11 Brute-Force-Angriff...... 16 3.2.12 Man-in-the-middle-Angriff...... 17 3.2.13 Phishing...... 17 3.2.14 Hijacking...... 17 3.3 Bedrohungen der Sprachkonferenzsysteme...... 18 3.3.1 M¨ogliche Angriffsziele...... 18 3.3.2 Verursacher...... 18 3.3.3 Verletzung der Schutzziele...... 19 3.4 Ermittlung der Schwachstellen...... 20

4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicher- heitsmaßnahmen 22 4.1 Aufbau und Beschreibung der Untersuchungsumgebung...... 22 4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware...... 23 4.2.1 TeamSpeak 3-Server...... 23 4.2.2 TeamSpeak 3-Client...... 24 4.2.3 Murmur-Server...... 26 4.2.4 Clients Mumble...... 27 4.3 Sicherheitsmaßnahmen...... 29 4.3.1 Spachkonferenzsoftware...... 29 4.3.2 Konfiguration der Server...... 30 4.3.3 Sicherheitsrelevante Einstellungen des Betriebssystems..... 31 4.3.4 Router und lokale Firewall...... 33 4.3.5 Nutzerverwaltung...... 37 4.3.6 Mensch als Schwachstelle...... 38

5 Demonstration von Angriffsszenarien 40 5.1 Betrachtung des TeamSpeak 3-Server Query Interface...... 40 5.1.1 Aufbau des Testprogramm...... 40 5.1.2 Untersuchung der Anti-Flood-Protection...... 42 5.1.3 Brute-Force-Angriff auf das Query Interface...... 44 5.2 TeamSpeak 3-Server Query Interface Exploit...... 45 5.2.1 Funktionsweise von teamspeakrack...... 45 5.2.2 Einrichten einer Hintertur¨ ...... 47 5.2.3 Null Pointer Dereferenzierung...... 49 5.2.4 Server mit Textnachrichten fluten...... 49 5.2.5 Weitere M¨oglichkeiten von teamspeakrack...... 50 5.3 Murmur Exploit fur¨ einen DoS-Angriff...... 51

6 Resumee¨ und Ausblick 54

ii Marcel Graef & Marco Franke Inhaltsverzeichnis

Literaturverzeichnis 56

Abbildungsverzeichnis 59

Tabellenverzeichnis 60

Abkurzungsverzeichnis¨ 61

Eigenst¨andigkeitserkl¨arung 63

Marcel Graef & Marco Franke iii

1 Einleitung

Die Nutzung von Sprachkommunikationsdiensten hat im letzten Jahrzehnt drastisch zugenommen. Es gibt bereits zahlreiche Programme, die Sprachkonferenzen erm¨oglichen - beispielsweise TeamSpeak, Mumble/Murmur, Skype oder Ventrilo. Ein Grund fur¨ diese Entwicklung ist der Ausbau von DSL-Verbindungen sowie der Leitungskapazit¨at im Wide Area Network (WAN). Aber auch die Qualit¨at der Sprachubertragung¨ von Sprachkonferenzsystemen uber¨ IP-Netzwerke hat deutlich zugenommen.

In dieser Arbeit werden zwei ausgew¨ahlte Sprachkonferenzsysteme untersucht. Dies ist zum Einen das propriet¨are TeamSpeak 3 und das quelloffene Mumble/Murmur. Die Ahnlichkeiten¨ und Unterschiede werden im Kapitel2 aufgezeigt. Dabei wird neben den grundlegenden technischen Details, Funktionsweisen und verwendeten Codecs auf die Lizenzmodelle eingegangen. Letzteres spielt gerade fur¨ Unternehmen eine wichtige Rolle.

Neben den technischen Eigenschaften der Sprachkonferenzsysteme ist vor allem die Sicherheit von großem Interesse. Um diese in Kapitel3 zu analysieren, werden in Ab- schnitt 3.1 die Anforderungen und Schutzziele von Nutzern der Sprachkonferenzdienste aufgezeigt. Danach wird in Abschnitt 3.2 eine Ubersicht¨ typischer Angriffsarten gegeben. Mit Hilfe dieser Angriffsarten k¨onnen Angreifer Angriffsziele erreichen und stellen somit eine Bedrohung fur¨ das Sprachkonferenzsystem dar. Diese werden in Abschnitt 3.3 analysiert und klassifiziert. Durch diese systematische Betrachtung ist es m¨oglich, Schwachstellen von Sprachkonferenzsystemen zu identifizieren.

Aufbauend auf diesen Erkenntnissen wird in Kapitel4 eine Untersuchungsumgebung aufgebaut und Maßnahmen zur Erh¨ohung der Sicherheit betrachtet und umgesetzt. Mit Hilfe dieser Untersuchungsumgebung wird in Kapitel5 aufgezeigt, dass die Sicherheit durch Sicherheitsmaßnahmen erh¨oht werden kann, aber durch kleine Fehler schnell betr¨achtliche Sicherheitsrisiken entstehen k¨onnen.

Marcel Graef & Marco Franke 1 2 Vergleich von Mumble/Mumur und TeamSpeak 3

2 Vergleich von Mumble/Mumur und TeamSpeak 3

In diesem Kapitel werden die wesentlichen Merkmale von TeamSpeak 3 und Mum- ble/Murmur vorgestellt. Dabei wird auf den grundlegenden Aufbau, funktionale Eigen- schaften und vor allem auf die technischen Details wie Authentisierung, verwendete Codecs, Protokolle und Formate der Sprachkonferenzsoftware eingegangen. Auch werden die Lizenzmodelle von TeamSpeak 3 und Mumble/Murmur gegenubergestellt,¨ da diese eine wesentliche Rolle fur¨ Einrichtungen, Institutionen und Privatpersonen darstellen.

2.1 Anwendungsgebiete

Das Hauptziel von TeamSpeak 3 als auch Mumble/Murmur ist es, einen Sprachkonfe- renzdienst bereit zu stellen, welcher eine m¨oglichst niedrige Latenzzeit besitzt und dabei trotzdem eine st¨orungsfreie und klare Audioqualit¨at bietet. Aber auch die Datenrate soll m¨oglichst gering (<25 kbit/s) gehalten werden. Gerade durch Erfullung¨ dieser Ziele wird die Software vor allem zur Kommunikation in Verbindung mit Online-Computerspielen verwendet. Aber auch in Netzwerken und Systemen mit beschr¨ankten Ressourcen wird TeamSpeak 3 oder Mumble/Murmur eingesetzt. [TSo12g], [MuM12a]

2.2 Funktionsweise und Protokolle

Der Aufbau einer Kommunikationsverbindung wird mit einem klassischen Client-Server- Modell, 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 Marcel Graef & Marco Franke 2.2 Funktionsweise und Protokolle

sich auf einen Server verbindet, belegt einen so genannten Slot. Die Anzahl der Clients, die sich mit einem Server verbinden k¨onnen, ist damit auf die Anzahl der verfugbaren¨ Slots beschr¨ankt. Mit dem Server verbunden, k¨onnen sich die Clients gegenseitig sehen und untereinander kommunizieren. Dabei gibt es die M¨oglichkeit zur Sprach- oder Textkommunikation. [TSo12g], [MuM12c]

Abbildung 2.1: Schematische Darstellung des Client-Server-Modells von TeamSpeak 3 und Mumble/Murmur

Fur¨ den Verbindungsaufbau und zur Steuerung zwischen Client und Server verwenden beide Anwendungen das verbindungsorientierte Transmission Control Protocol (TCP), dies wird als Kontrollkanal bezeichnet. Fur¨ die Sprachubertragung¨ wird das User User Datagram Protocol (UDP) verwendet, da dies die Datenubertragung¨ nicht sichert und zu geringeren Verz¨ogerungen fuhrt.¨ Die Nutzung und Standard Ports dazu sind den Tabellen 2.1 und 2.2 zu zusammengefasst.

TeamSpeak 3 Dienst Nutzung Standard-Port Sprachubertragung¨ TeamSpeak 3 Client 9987 UDP TCP Query telnet ip port 10011 TCP

Tabelle 2.1: Ubersicht¨ uber¨ die genutzten Standard-Ports von TeamSpeak 3 zu den jeweiligen Diensten.

Als IP-Telefonie-Protokoll verwendet TeamSpeak 3 das Softwareeigene, nicht offen

Marcel Graef & Marco Franke 3 2 Vergleich von Mumble/Mumur und TeamSpeak 3 spezifizierte, TeamSpeak-Protokoll. Aus diesem Grund kann keine Aussage uber¨ die Verschlusselung¨ 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 fur¨ jeden einsehbar. [Cam10], [Nat12a]

Mumble/Mumur Dienst Nutzung Standart-Port Sprachubertragung¨ Mumble 64738 UDP Steuerkanal Mumble 64738 TCP

Tabelle 2.2: Ubersicht¨ uber¨ die genutzten Standard-Ports von Mumble/Murmur zu den jeweiligen Diensten.

Fur¨ die Verschlusselung¨ des Sprachkanals (UDP voice channel) wird der Advanced Encryption Standard (AES) mit einer Schlussell¨ ¨ange von 128 Bits im Offset Codebook Mode (OCB) verwendet (OCB-AES128). Die Verschlusselung¨ des Steu- erkanal (TCP control channel) ist durch den Einsatz des Verschlusselungsprotokolls¨ Transport Layer Security (TLS), AES mit einer Schlussell¨ ¨ange 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 erwunscht,¨ dass alle Clients, welche auf einen Server verbun- den sind, mit einander kommunizieren. Um nicht fur¨ jede Konferenz einen eigenen Server verwenden zu mussen,¨ gibt es die M¨oglichkeit, Bereiche zu erstellen, in denen sich die Konferenzteilnehmer zusammen schließen k¨onnen. Diese Bereiche werden als Channel bezeichnet. Jeder Client kann sich beliebig einem dieser Channel anschließen und ausschließlich mit den darin befindlichen Clients kommunizieren. Auch ist der Wechsel zwischen verschiedenen Channels jederzeit m¨oglich. Die Channels k¨onnen auch in einander verschachtelt werden, woraus eine Hierarchie entsteht. Weiterhin kann man zwischen ¨offentlichen und passwortgeschutzten¨ Channels unterscheiden. Ein weiterer

4 Marcel Graef & Marco Franke 2.4 Authentifizierung und Verwaltung der Clients wichtiger Aspekt sind die komplexen Rechtesysteme, welche sich in TeamSpeak 3 und Mumble/Murmur stark ¨ahneln. Die Rechtevergabe wird dabei uber¨ Rechtegruppen geregelt. Das heißt, die Rechte jedes Nutzers ergeben sich aus der Rechtegruppe, welcher er zugeordnet ist. Jede Gruppe besitzt dabei einen Namen und eine Identifikationsnum- mer sowie die Rechte, die der jeweiligen Gruppe einger¨aumt werden. Standardm¨aßig sind die drei Gruppen Serveradmin, Normal und Gast vorhanden. Bei TeamSpeak 3 wird zus¨atzlich noch zwischen Server- und Channelgruppen unterschieden, wodurch es m¨oglich ist Rechtegruppen zu erstellen, welche den Gultigkeitsbereich¨ auf bestimmte Channel beschr¨anken.

Mit Hilfe dieser Zugriffssteuerung durch die Rechtesysteme k¨onnen die Server auf verschiedene Szenarien angepasst werden. Denkbar ist beispielsweise die Konfiguration fur¨ ein virtuelles Tutorium. Dafur¨ wird eine Gruppe fur¨ die Tutoren erstellt, welche das Recht haben zu Sprechen und eine Gruppe fur¨ die Teilnehmer, welche nur zuh¨oren durfen.¨ Zus¨atzlich k¨onnen die Tutoren einzelnen Teilnehmern das Recht zum sprechen geben oder wieder entziehen. Der Wunsch eines Teilnehmers zu Sprechen kann dabei uber¨ den Channelchat erfolgen.

[TSo12e], [MuM12b]

2.4 Authentifizierung und Verwaltung der Clients

Bei TeamSpeak 3 und Mumble/Murmur authentifiziert sich ein Client nicht uber¨ einen klassischen Login (bestehend aus Name und Passwort) auf einem Server. Bei einem TeamSpeak 3 Server geschieht dies durch eine so genannte Identit¨at. Diese ist durch eine eindeutige ID beschrieben. Bei Mumble/Murmur erfolgt dies uber¨ Zertifikate. Dadurch ist es fur¨ den Client m¨oglich, sich an einem Server zu verschiedenen Zeitpunkten mit unterschiedlichen Usernamen einzuloggen. Ein Client hat die M¨oglichkeit, mehrere dieser Identit¨aten bzw. Zertifikate anzulegen. Zus¨atzlich kann der Zugriff auf einen Server durch ein Serverpasswort geschutzt¨ werden, wenn beispielsweise keine Registrierung erwunscht¨ ist.

Die Informationen fur¨ registrierte Clients und deren Gruppenzugeh¨origkeiten werden auf dem TeamSpeak 3 Server bzw. Murmur in einer Datenbank gespeichert. Dabei ist es m¨oglich, eine SQLite- oder MySQL-Datenbank zu verwenden. Die Verwaltung der

Marcel Graef & Marco Franke 5 2 Vergleich von Mumble/Mumur und TeamSpeak 3

Datenbank kann serverseitig direkt vorgenommen werden. Mit den ben¨otigten Rechten k¨onnen bei TeamSpeak 3 und Murmur Einstellungen auch uber¨ die Client-Oberfl¨ache vorgenommen werden. Zus¨atzlich 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 Datenubertragung¨ 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 ¨alteren Versionen von TeamSpeak 3 wurden die Sprachcodecs Code-Excited Linear Prediction (CELP) und Global System for Mobile Communications (GSM) verwendet, welche aber in der aktuellen Version nicht mehr zu finden sind. Bei Mumble/Murmur findet man zus¨atzlich den Sprachcodec Opus. Eine n¨ahere Betrachtung in diesem Abschnitt wird Aufschluss uber¨ Merkmale und Verwendung dieser speziellen Sprachcodecs geben.

2.5.1 CELP

Die grundlegende Technik fur¨ die genannten Sprachcodecs lieferte das 1985 ver¨offent- lichte CELP Verfahren. Dies ist ein Segment-orientiertes Codierungsverfahren, welches nach dem Analysis-by-Synthesis (AbS) Prinzip funktioniert. Mit Hilfe des Linear Predictive Coding (LPC) Verfahrens werden die Audiosignale auf ein spezielles, der menschlichen Sprache nachempfundenes Modell abgebildet. Dadurch ist es m¨oglich, die Audiosignale im Vergleich zu Puls-Code-Modulation (PCM) Repr¨asentation, stark datenreduziert zu speichern bzw. zu ubertragen.¨ Daraus resultiert, dass das Verfahren zur Komprimierung von Musik ungeeignet ist. [Bad10, S.162-163]

6 Marcel Graef & Marco Franke 2.5 Sprachcodecs

2.5.2 Speex

Mit dem Sprachcodec Speex wurde 2004 ein Codec ver¨offentlicht, 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 fur¨ die erreichten Werte ist die Verwendung verschiedener Verfahren und Methoden. Dabei werden die Kompressionsmethoden variable bit rate (VBR) und average bit rate (ABR) verwendet, welche abh¨angig von den Audiodaten unterschiedliche Bit-raten bei gleich bleibender Qualit¨at erzeugen. Dieser Effekt wird durch die Sprechpausenerkennung Voice Activity Detection (VAD) und den Ubertragungsmodus¨ Discontinuous Transmission (DTX) weiter verst¨arkt. [PHS94]

2.5.3 CELT

Im Dezember 2007 wurde der CELT (Constrained-Energy Lapped Transform) Sprach- codec ver¨offentlicht. Dieser Sprachcodec erzielt im Vergleich zum Speex eine geringere Latenz von 5 bis 22,5 ms. Um dies zu erreichen, verwendet er eine h¨ohere und kon- stante Datenrate von 32 bis 128 kbit/s. Zudem l¨asst sich durch die h¨ohere Datenrate eine gr¨oßere Frequenzbandbreite abbilden, wodurch sich dieser Sprachcodec auch zur Ubertragung¨ von Musik eignet. Durch ein integriertes Packet Loss Concealment (PLC) Verfahren lassen sich verloren gegangene Daten uberbr¨ ucken¨ und sind somit fur¨ den Empf¨anger kaum wahrnehmbar. Im Februar 2011 wurde die aktuelle Version 0.11.1 ver¨offentlicht. [PHC08]

2.5.4 Opus

Im Gegensatz zu TeamSpeak 3 bietet Mumble/Murmur zus¨atzlich Unterstutzung¨ fur¨ den im September 2012 ver¨offentlichten 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 fur¨ Sprache, sondern auch fur¨ Musik. Durch die Verwendung der Kompressionsmethoden constant bit-rat (CBR) und VBR unterstutzt¨ er konstante als auch variable Bit-raten. Auch wird das PLC Verfahren

Marcel Graef & Marco Franke 7 2 Vergleich von Mumble/Mumur und TeamSpeak 3 zur Fehleruberbr¨ uckung¨ verloren gegangener Datenpakete verwendet. Neben Stereo unterstutzt¨ er bis zu 255 Kan¨ale. Anhand drei so genannter Modi kann der Codec je nach Verwendung eingestellt werden. [PHO11]

2.6 Unterstutzte¨ Betriebssysteme

Neben technischen Details der Sprachkonferenzsoftware sind auch die unterstutzten¨ Plattformen von Interesse.

TeamSpeak 3 unterstutzt¨ Windows, Mac OS X und Linux fur¨ den Einsatz von Server oder Client. Fur¨ das Betriebssystem FreeBSD steht ausschließlich ein TeamSpeak 3 Server zur Verfugung.¨ Der TeamSpeak 3 Client unterstutzt¨ des Weiteren Smartphones mit den Betriebssystemen iOS oder Android. [TSo12b]

Mumble/Murmur steht ebenfalls fur¨ Windows, Mac OS X und Linux zur Verfugung.¨ Der Client Mumble unterstutzt¨ iOS und Android. Es steht auch eine Version fur¨ das von Nokia entwickelte Betriebsystem Maemo zur Verfugung.¨ [MuM12d]

2.7 Lizenzmodelle

Fur¨ den Betrieb eines Sprachserver sind die angebotenen Lizenzmodelle fur¨ Privatper- sonen, Institute sowie besonders fur¨ Unternehmen von Interesse.

Bei TeamSpeak 3 wird zwischen funf¨ Lizenzmodellen unterschieden. Die Non-Profit- Lizenz (NPL) steht zum Einen fur¨ nicht registrierte Nutzer zur Verfugung.¨ Sie erlaubt die Verwendung eines Servers mit maximal 32 Slots fur¨ nicht kommerzielle Zwecke. Registrierte Nutzer k¨onnen bis zu 10 Server mit maximal 512 Slots betreiben. Fur¨ gewerbliche Unternehmen, welche TeamSpeak 3 Server vermieten, wird die gewerbliche Lizenz fur¨ Autorisierte TeamSpeak Host Provider (ATHP) verwendet. Bei gewerblichen Unternehmen, welche TeamSpeak 3 innerhalb eines gewerblichen Umfelds nutzen, besteht zus¨atzlich die M¨oglichkeit, die j¨ahrliche Aktivierungslizenz (AAL) zu verwenden. M¨ochten gewerbliche Unternehmen mit dem TeamSpeak 3 Software Development Kit (SDK) Software entwickeln, kann die TeamSpeak 3 SDK Lizenz erworben werden. [TSo12d]

8 Marcel Graef & Marco Franke 2.8 Weitere Besonderheiten

Mumble/Murmur steht zum Vergleich unter General Public License (GPL) Version 2 lizenziert und verfugt¨ damit uber¨ keine lizenzrechtlichen Einschr¨ankungen. [Nat12a]

2.8 Weitere Besonderheiten

TeamSpeak 3 und Mumble/Murmur bieten gleichermaßen weitere Besonderheiten. So gibt es fur¨ das Sprechen die M¨oglichkeit, zwischen automatischer Sprachaktivierung oder Sprachaktivierung durch Tastendruck (Push-To-Talk) zu w¨ahlen. Auch k¨onnen in beiden Anwendungen Einstellungen fur¨ Surround Sound vorgenommen werden. Damit ist es m¨oglich, Konferenzteilnehmer virtuell r¨aumlich anzuordnen, um eine reale Konferenz zu simulieren. Mit Hilfe so genannter Musikbots, welche virtuelle Konferenzteilnehmer darstellen, ist es m¨oglich, Musik in einem Channel abzuspielen. Diese k¨onnen aber auch verwendet werden, um Gespr¨ache aufzuzeichnen. Die M¨oglichkeit des Aufzeichnens steht fur¨ den TeamSpeak 3 und Mumble-Client zur Verfugung.¨ [Nat12b], [TSo12a]

Marcel Graef & Marco Franke 9 3 Sicherheitsanalyse und Ermittlung von Schwachstellen

3 Sicherheitsanalyse und Ermittlung von Schwachstellen

Um Sicherheitsmaßnahmen fur¨ die Sprachkonferenzsysteme TeamSpeak 3 und Mum- ble/Murmur zu entwickeln, mussen¨ bestehende Schwachstellen erkannt werden. Um Schwachstellen zu erkennen, mussen¨ zun¨achst in Abschnitt 3.1 Anforderungen an ein Sprachkonferenzsystem und den damit verbundenen Schutzzielen der Nutzer diskutiert werden. Danach wird in Abschnitt 3.2 eine Ubersicht¨ typischer Angriffe gegeben. Dies ist wichtig, um Bedrohungen (Abschnitt 3.3) der Sprachkonferenzsysteme zu erkennen und aufzuzeigen. Schließlich k¨onnen daraus Schwachstellen (Abschnitt 3.4) ermittelt werden. Darauf aufbauend k¨onnen bei der Konzeption und Realisierung in einer Unter- suchungsumgebung in Kapitel4 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 fur¨ Unternehmen sollte der Analyse von Schutzzielen und Anforderungen eine große Beachtung beigemessen werden, da hier die Sicherheitsrisiken schwerwiegende wirtschaftliche Folgen haben k¨onnen. Die prim¨aren Schutzziele sind Verfugbarkeit,¨ Vertraulichkeit, Verbindlichkeit. [BSI04], [Bad10, S.446-448]

10 Marcel Graef & Marco Franke 3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme

3.1.1 Verfugbarkeit¨

Mit dem Schutz der Verfugbarkeit¨ wird gew¨ahrleistet, dass alle notwendigen Verbindungs- und Sprachdaten fur¨ den Anwender stets verfugbar¨ sind. In diesem Zusammenhang muss gesichert werden, dass die Funktionsweise der Sprachserver durch Angriffe, aber auch durch Ausfall technischer Ger¨ate (z.B. Stromversorgung) nicht beeintr¨achtigt werden. [BSI04], [Bad10, S.446-448]

3.1.2 Vertraulichkeit

Unter der Vertraulichkeit versteht man den Schutz vor der ungewollten Preisgabe von Informationen. Dies ist beispielsweise der Fall, wenn Gespr¨ache von Unbefugten abgeh¨ort 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 verschlusseln.¨ Aber auch ungewollte interne Zugriffe auf diese Daten sind zu vermeiden. Das heißt, der Zugriff auf eine Konferenz darf nur von berechtigten Personen erfolgen. [BSI04], [Bad10, S.446-448]

3.1.3 Verbindlichkeit

Unter Verbindlichkeit werden die Teilaspekte Authentizit¨at, Integrit¨at, Nicht-Abstreit barkeit und Rechtsverbindlichkeit zusammen gefasst. Dabei wird durch technische Maßnahmen versucht, die Echtheit empfangener Daten zu sichern.

Als Authentizit¨at wird der Beweis der Echtheit verstanden. Es muss immer fur¨ alle Daten die Herkunft eindeutig festgestellt werden k¨onnen. Aber auch die Korrektheit der angegebenen Herkunft muss stets gesichert sein. So muss Beispielsweise auch sichergestellt werden, dass der Anrufende der ist, der er zu sein vorgibt.

Mit dem Schutz der Integrit¨at ist der Schutz vor unbefugter Manipulation von Ver bindungs- und Sprachdaten gemeint. Es muss gesichert sein, dass alle Verbindungs- und Sprachdaten unver¨andert beim Empf¨anger eintreffen. Aber auch das Erkennen von Manipulationen muss gew¨ahrleistet werden.

Wenn man zu einem sp¨ateren Zeitpunkt gegenuber¨ einem Dritten (z.B. Gericht) be-

Marcel Graef & Marco Franke 11 3 Sicherheitsanalyse und Ermittlung von Schwachstellen

weisen muss, dass Daten gesendet oder empfangen wurden, reicht die Integrit¨at und Authentizit¨at meist nicht aus. Deshalb wird durch die Nicht-Abstreitbarkeit sicherge- stellt, dass der Versand und Empfang von Daten nicht abgestritten werden kann und somit ist das Ziel der Rechtsverbindlichkeit erfullt.¨

[BSI04], [Bad10, S.446-448]

3.1.4 Weitere Anforderungen

Bei der Verwendung von Sprachkonferenzsystemen werden neben den allgemeinen Schutzzielen weitere Anforderungen der Leistungsf¨ahigkeit des System gestellt. Die An- forderungen an ein System k¨onnen als Quality of Service (QoS) zusammengefasst werden und beinhalten Anforderungen aus Anwender- bzw. technischer Sicht.

Eine Anforderung aus Anwendersicht ist die Sprachqualit¨at. Diese kann durch die Wahl eines geeigneten Codecs realisiert werden, aber auch durch technische Probleme (z.B. zu hohe Netzauslastung) oder Angriffe (z.B. Distributed Denial of Service) beein- tr¨achtigt werden. Ebenso ist eine leichte Handhabung und Flexibilit¨at im Einsatz der Sprachkonferenzsysteme von Interesse.

Eine Anforderung aus technischer Sicht ist eine geringe Verz¨ogerung (Delay) der Sprachsignale. Damit ist der Zeitverzug zwischen dem Aussprechen beim Sender und der Wiedergabe beim Empf¨anger gemeint. Des Weiteren ist das Auftreten von Jittern unerwunscht.¨ Diese entstehen, wenn netzbedingt die Ubertragungszeiten¨ zwischen verschiedenen Paketen stark abweichen. Ab einer Differenz von etwa 50 ms ist dabei mit Problemen in der Kommunikation zu rechnen. Ein solches Problem kann beispielsweise die Verzerrung des h¨orbaren Sprachsignals sein. Aus verschiedenen Grunden¨ (z.B. zu hohe Lautst¨arke der Lautsprecher beim Empf¨anger) k¨onnen Ruckkopplungen¨ des eigenen Gesprochenen entstehen. In diesem Fall spricht man von unerwunschten¨ Echos. Durch geeignete Verfahren zur Echokompensation muss dem entgegengewirkt werden. Durch Uberlastung¨ oder Fehler kann es dazu kommen, dass Pakete verworfen werden. Dieser Paketverlust ist ebenfalls unerwunscht¨ und sollte daher m¨oglichst gering gehalten werden.

[Bad10, S.116-121,191], [EE07, S.36-39]

12 Marcel Graef & Marco Franke 3.2 Typische Angriffsarten

3.2 Typische Angriffsarten

Um Bedrohungen spezifisch von Sprachkonferenzsystemen ermitteln zu k¨onnen, ist es notwendig, allgemeine Angriffsarten zu kennen. Grundlegend erben Sprachkonferenz- systeme alle Sicherheitsprobleme der IP-Welt und es kommen weitere hinzu.

3.2.1 Computervirus

Ein Computervirus ist eine Befehlsfolge, die sich an ein bestehendes Programm anh¨angt (Infektion). Wird das infizierte Programm ausgefuhrt,¨ werden auch die Befehlsfolgen des Computervirus ausgefuhrt.¨ Zus¨atzlich sind Computerviren in der Lage, sich selbstst¨andig zu verbreiten, d.h. sich selbst zu kopieren (Reproduktion). Computerviren k¨onnen Sch¨aden, Fehlfunktionen und St¨orungen bewirken. Sie werden meist durch Weitergabe infizierter Programme oder Dateien (z.B. als E-Mail-Anhang) verbreitet. [Bad10, S.454- 456]

3.2.2 Wurm

Im Vergleich zum Computervirus ist ein Wurm ein eigenst¨andiges Programm, welches sich uber¨ ein Netzwerk selbstst¨andig verbreiten kann. Aber auch uber¨ Wechseldaten- tr¨ager ist eine Verbreitung m¨oglich. Zur Verbreitung kann ein Wurm beispielsweise ein E-Mail-Programm verwenden, indem er sich automatisch an alle gespeicherten E-Mail-Adressen als Anhang versendet. [Bad10, S.454-456]

Beispielsweise wurde mit Hilfe eines Instant-Messaging-Dienstes, welcher in der Sprach- konferenzsoftware Skype integriert ist, der Wurm Pykse verbreitet. Pykse fuhrte¨ dazu, dass die infizierte Sprachkonferenzsoftware Skype nicht mehr fur¨ eingehende Anrufe erreichbar war.

3.2.3 Trojaner

Trojanische Pferde sind Schadprogramme, welche sich in vermeintlich nutzlichen¨ Pro- grammen verbergen. Sie k¨onnen sich nicht selbst verbreiten und sind somit auf die

Marcel Graef & Marco Franke 13 3 Sicherheitsanalyse und Ermittlung von Schwachstellen

Gutgl¨aubigkeit der Nutzer angewiesen. In den meisten F¨allen bauen Trojaner Verbin- dungen zum Angreifer auf und erm¨oglichen dadurch das Aussp¨ahen sensibler Daten. Auch Fernsteuerung befallener Systeme kann dadurch erm¨oglicht werden. Aus dem Bereich von Sprachkonferenzsystemen ist beispielsweise der Trojaner FinSpy zu nen- nen. Dieser Trojaner erm¨oglicht 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 berucksichtigt¨ wurden. Diese Schwachstellen k¨onnen mit Hilfe eines speziell auf die fehlerhaften Mechanismen ausgerichteten Programms ausgenutzt werden. Solche Fehler werden in der Regel erst im Live-Betrieb einer Software oder einem System offengelegt und durch Nachbesserungen behoben. An dieser Stelle wird klar, dass zwischen der Offenlegung und Behebung der Schwachstelle eine erh¨ohte Gefahr fur¨ die Betreiber von Sprachkonferenzsystemen besteht. Ein Beispiel und dessen Auswirkungen wird in Kapitel5 erl ¨autert und demonstriert. [Bad10, S.454-456]

3.2.5 Backdoor

Als Backdoor bezeichnet man Lucken,¨ welche Angreifern unerwunschten¨ Zugriff auf ein System oder Ressourcen erm¨oglichen. Im Vergleich zu einem Exploit handelt es sich dabei nicht um fehlerhafte Mechanismen in der Software oder einem System, sondern um eine fehlerhafte Konfiguration. Dies k¨onnen beispielsweise offene Ports oder eine fehlende Zugriffssicherung sein. Solche k¨onnen vor allem durch Unwissenheit oder Unachtsamkeit der Nutzer entstehen. Aber auch Wurmer,¨ Trojaner oder Exploits k¨onnen solche Lucken¨ auf einem System einrichten. [Bad10, S.454-456]

14 Marcel Graef & Marco Franke 3.2 Typische Angriffsarten

3.2.6 Rootkit

Ein Rootkit ist eine Sammlung von Dateien und Programmen, welche dem Angreifer erm¨oglichen, 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 Verfugbarkeit¨ von Systemen oder Diensten, welche angeboten werden. Es wird durch Uberlastung¨ des Systems oder der Software versucht, die Verfugbarkeit¨ einzuschr¨anken oder komplett außer Kraft zu setzen. Dieser Angriff kann auch von mehreren Systemen gleichzeitig durchgefuhrt¨ werden. In diesem Fall spricht man von einem Distributed Denial of Service (DDoS) Angriff. Dabei wird durch st¨andiges Senden von Anfragen versucht, Systeme oder Dienste an ihre Belastungsgrenze zu bringen.

Dies kann beispielsweise bei einer TCP-Verbindung durch das st¨andige 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 uber¨ TCP aufgebaut werden m¨ochte und somit einen Verbindungsaufbau initiiert. Ist eine zu hohe Anzahl von Verbindungsanfragen erreicht, kann der Dienst keine weiteren Verbindungen aufbauen und steht damit nicht mehr oder nur noch eingeschr¨ankt zur Verfugung.¨

[Bad10, S.454-456]

3.2.8 Spoofing

Unter Spoofing versteht man das Benutzen einer falschen Identit¨at. Dieser Angriff erfolgt durch Vort¨auschung falscher Quelladressangaben. Dem kann durch eine gegenseitige Authentifizierung entgegengewirkt werden. Man unterscheidet zwischen IP-, DNS- und URL-Spoofing.

Marcel Graef & Marco Franke 15 3 Sicherheitsanalyse und Ermittlung von Schwachstellen

Bei IP-Spoofing wird in einem IP-Paket die Quell-IP-Adresse ausgetauscht, um somit einen anderen Kommunikationspartner vorzut¨auschen. Bei DNS-Spoofing wird die Zuordnung zwischen IP-Adresse und Rechnername ver¨andert. Auch bei einer aufgerufe- nen Webseite kann die Quell-URL verf¨alscht 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 unverschlusselten¨ Daten kann eine Auswertung dieser Daten sensible Informationen preisgeben. Beispielsweise stellt die Software Wireshark ein sehr umfangreiches Werkzeug fur¨ diesen Zweck und daruber¨ hinaus dar.

3.2.10 Port Scanning

Mit einem Portscan wird gezielt nach offenen Ports an einem Rechner gesucht, um Schwachstellen fur¨ 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 gultig,¨ wenn sie einem Benutzerkonto zugeordnet werden k¨onnen. Bei Angabe gultiger¨ Logindaten wird der Zugriff auf den Dienst oder das System gew¨ahrt.

Der Angreifer versucht, unter Verwendung eines speziellen Programms gultige¨ Login- daten zu finden. Das Programm sucht mit Hilfe einer ersch¨opfenden Suche so lange nach Kombinationen von Logindaten, bis es eine gultige¨ Kombination findet. Aufgrund der vielen Kombinationsm¨oglichkeiten ist es mit dieser Methode oft nicht m¨oglich, den

16 Marcel Graef & Marco Franke 3.2 Typische Angriffsarten

Angriff in einem realistischen Zeitfenster durchzufuhren.¨ Deshalb wird in den meisten F¨allen der Suchraum verkleinert. Man beschr¨ankt sich beispielsweise auf einen bestimm- ten Benutzernamen und versucht, dazu das passende Passwort zu finden. Zus¨atzlich kann der Suchraum durch so genannte Passwortlisten weiter verkleinert werden. In guten Passwortlisten sind in der Regel mehrere hunderttausend bekannter und beliebter Passw¨orter zusammengestellt.

Ein bekannter Vertreter eines Programms zur Durchfuhrung¨ von Brute-Force-Angriffen ist THC-Hydra. Hauptmerkmal dieses Programms ist die hohe Anzahl unterstutzter¨ Protokolle, wie beispielsweise HTTP, SSH, POP3 oder telnet. Auch bietet das Programm Unterstutzung¨ fur¨ Brute-Force-Angriffe gegen die alte Version TeamSpeak 2.

3.2.12 Man-in-the-middle-Angriff

Der Man-in-the-middle (MITM)-Angriff stellt einen Angriff dar, bei dem der Angreifer in einem Netzwerk zwischen den Kommunikationspartnern steht. Dabei liest der Angreifer gezielt Datenpakete der Kommunikation mit, manipuliert diese oder tauscht sie g¨anzlich aus.

3.2.13 Phishing

Phishing bezeichnet alle Vorg¨ange, bei denen sensible Daten von Nutzern erschlichen werden. Zumeist handelt es sich dabei um das Ausnutzen der Gutgl¨aubigkeit der Opfer, indem falsche Identit¨aten vorget¨auscht werden. Beispielsweise sind das gef¨alschte Login Bereiche, in denen die vom Nutzer eingegebenen Daten erschlichen werden. [Bad10, S.454-456]

3.2.14 Hijacking

Als Hijacking bezeichnet man die Ubernahme¨ von Dom¨anen oder Benutzerkonten. Nach einer erfolgreichen Ubernahme¨ der Identit¨at muss diese nicht mehr vorget¨auscht werden. Ab diesem Zeitpunkt k¨onnen alle Anfragen an diese Identit¨at umgeleitet werden, um Angriffe an weitere Kommunikationspartner durchzufuhren.¨ Zur Ubernahme¨ werden in der Regel Phishing, Brute-Force- oder MITM-Angriffe verwendet. [Bad10, S.454-456]

Marcel Graef & Marco Franke 17 3 Sicherheitsanalyse und Ermittlung von Schwachstellen

3.3 Bedrohungen der Sprachkonferenzsysteme

Um ermitteln zu k¨onnen, welche Auswirkungen Bedrohungen fur¨ ein Sprachkonferenz- system haben, muss analysiert werden, welche Ziele und Verursacher einer Bedrohung existieren. Danach kann zusammengefasst werden, welche Schutzziele als Folge einer Bedrohung, verletzt werden k¨onnen. [Bad10, S.484-487]

3.3.1 M¨ogliche Angriffsziele

Die Ziele der Angreifer k¨onnen in vier Kategorien zusammen gefasst werden. Dazu geh¨ort das Lauschen bzw. Abh¨oren von Gespr¨achen, in denen sensible Informationen ausgetauscht werden und somit an unbefugte Dritte gelangen k¨onnen. Weiterhin ist das Abfangen und Modifizieren von Daten ein Ziel. Dieses betrifft weniger die Sprach- daten einer Konferenz selbst; mehr wird dabei auf Daten, welche zur Steuerung oder Administration der Sprachkonferenzsysteme selbst ben¨otigt werden, abgezielt. Da bei TeamSpeak 3 und Mumble/Murmur auch die M¨oglichkeit besteht, textbasiert zu kom- munizieren, k¨onnen auch diese Daten von Interesse sein, abgefangen oder modifiziert zu werden. Aber auch die bloße Beeintr¨achtigung der Funktionsweise des Dienstes ist ein beliebter Angriffspunkt. Gerade bei Unternehmen, welche auf die Kommunikation uber¨ das Sprachkonferenzsystem angewiesen sind, ist diese Art der Sabotage problematisch. Diese k¨onnen beispielsweise die Kommunikation mit Kunden oder die Kommunikation bei internen Gesch¨aftsprozessen sein. Auch der Missbrauch der Dienste ist ein denkbares Ziel. So k¨onnen beispielsweise die Ressourcen der Sprachkonferenzsysteme fur¨ eigene Gespr¨ache missbraucht werden. [Bad10, S.484-487]

3.3.2 Verursacher

Die Verursacher einer Bedrohung k¨onnen ebenfalls in vier Gruppen eingeteilt werden. Die naheliegendste Gruppe sind externe Angreifer. Sie haben im allgemeinen keine Verbindung zum Sprachkonferenzsystem selbst und mussen¨ sich daher erst Zugriff zum System verschaffen. Die n¨achste Gruppe sind Schadprogramme (Viren, Wurmer,¨ Trojaner, Backdoors, ...). Sie gehen zwar von einem externen Angreifer aus, aber stellen dennoch aufgrund ihres autonomen Handelns eine eigene Gruppe von Verursachern von Bedrohungen dar. Die beiden letzten Gruppen sind interne und externe Nutzer. Diese

18 Marcel Graef & Marco Franke 3.3 Bedrohungen der Sprachkonferenzsysteme beiden Gruppen besitzen von Vornherein Zugriff auf das Sprachkonferenzsystem und k¨onnen beispielsweise durch zu viele Rechte b¨oswillige Ziele verfolgen. Aber auch durch Fehlverhalten k¨onnen unbeabsichtigte Schutzziele verletzt werden und stellen damit eine potentielle Bedrohung dar. [Bad10, S.484-487]

3.3.3 Verletzung der Schutzziele

Mit den unter Abschnitt 3.2 erl¨auterten Angriffsarten k¨onnen Versursacher ihre An- griffsziele erreichen. Jeder Verursacher (siehe Abschnitt 3.3.2) stellt dabei in Verbindung mit einem Angriffsziel (siehe Abschnitt 3.3.1) eine Bedrohung dar, welche Schutzziele verletzen kann. Diese sind in Tabelle 3.1 tabellarisch zusammengefasst.

Abfangen und Dienstbe- Dienstmiss- Verursacher Lauschangriff Modifikation eintr¨achtigung brauch Externe Integrit¨at Integrit¨at Integrit¨at Angreifer Vertraulichkeit Authentizit¨at Verfugbarkeit¨ Authentizit¨at Verfugbarkeit¨ Verfugbarkeit¨ Schad- Integrit¨at Integrit¨at Integrit¨at Vertraulichkeit programme Verfugbarkeit¨ Verfugbarkeit¨ Verfugbarkeit¨ Interne Integrit¨at Integrit¨at Integrit¨at Benutzer Vertraulichkeit Authentizit¨at Authentizit¨at Authentizit¨at Verfugbarkeit¨ Verfugbarkeit¨ Verfugbarkeit¨ Externe Integrit¨at Integrit¨at Integrit¨at Benutzer Vertraulichkeit Authentizit¨at Authentizit¨at Authentizit¨at Verfugbarkeit¨ Verfugbarkeit¨ Verfugbarkeit¨

Tabelle 3.1: M¨ogliche Verletzungen bzw. Folgen, die sich aus den Bedrohungen durch Verursacher und deren Ziele ergeben (Vgl. [Bad10, S.486])

Mit Hilfe dieser Zusammenstellung ist eine mehrseitige Betrachtung potenzieller Bedro- hungen m¨oglich und hilft dabei, Schwachstellen zu erkennen. Dabei wird deutlich, dass neben externen Angreifern auch interne Nutzer kritisch betrachtet werden mussen.¨ Diese besitzen bereits Zugriff auf das interne Netzwerk oder das Sprachkonferenzsytem selbst und k¨onnen Angriffsziele verfolgen. Beispielsweise ist es denkbar, dass interne Benutzer Daten abfangen und modifizieren. Dabei wird gleichzeitig die Integrit¨at und Authenti- zit¨at verletzt. Werden die Daten abgefangen und nicht mehr an das System gesendet, so ist die Verfugbarkeit¨ verletzt. Auch ein Missbrauch des Sprachkonferenzdienstes ist denkbar. Beispielsweise durch das Ausnutzen zugesicherter Rechte, indem unbefugten

Marcel Graef & Marco Franke 19 3 Sicherheitsanalyse und Ermittlung von Schwachstellen

Nutzern Zugang auf den Sprachkonferenzdienst gegeben werden. Damit wird klar, dass das Sprachkonferenzsystem nicht nur gegen Angriffe von außen geschutzt¨ 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 Voruberlegungen¨ von Kapitel3k ¨onnen jetzt verschiedene Szenarien abgeleitet und daraus resultierende Schwachstellen erarbeitet werden.

Als erste Schwachstelle ist die Sprachkonferenzsoftware selbst zu nennen. Dabei obliegen sicherheitsrelevante Maßnahmen und die sichere Implementation dem Herausgeber der Software. Dazu geh¨ort auch die Verwendung geeigneter Protokolle, welche daher ebenfalls als Schwachstelle anzusehen sind und vom Nutzer als solche betrachtet werden muss. Eine weitere Schwachstelle ist die Konfiguration der Software. Dabei ist der Herausgeber der Software zur Bereitstellung geeigneter Konfigurationsm¨oglichkeiten verpflichtet. Auf der anderen Seite muss der Nutzer eine fur¨ den Anwendungszweck geeignete Konfiguration vornehmen.

Neben der Konferenzsoftware ist das verwendete Betriebssystem eine weitere Schwach- stelle. Dies ist vom Nutzer geeignet zu w¨ahlen und zu konfigurieren. Damit ist besonders die durchdachte Vergabe von Rechten zu nennen.

Um Zugriff auf das Netzwerk und damit auf die Sprachkonferenzsoftware zu erm¨oglichen, muss die Anbindung an das Netzwerk kritisch betrachtet werden. Daraus ergeben sich der Router und die Firewall als weitere Schwachstelle.

Die wohl kritischste Schwachstelle stellen die Benutzer der Sprachkonferenzsysteme dar. Es ist daher unumg¨anglich, auch diese in Abschnitt 4.3 detailliert zu betrachten.

In Tabelle 3.1 sind alle aufgezeigten Schwachstellen tabellarisch mit denkbaren Angriffs- arten und den daraus resultierenden Folgen, im Sinne der Verletzung von Schutzzielen, dargestellt.

20 Marcel Graef & Marco Franke 3.4 Ermittlung der Schwachstellen

Schwachstelle Angriffsart Folge Exploit Verletzung der Brute-Force Vertraulichkeit, Sprachkonferenzsoftware Verfugbarkeit,¨ Authentizit¨at Einr¨aumen Verletzung der zu vieler Vertraulichkeit, Konfiguration Rechte Verfugbarkeit,¨ Authentizit¨at Computervirus Verletzung der Wurm Vertraulichkeit, Betriebssystem Trojaner Verfugbarkeit,¨ Rootkit Authentizit¨at Backdoor Verletzung der (D)DoS Vertraulichkeit, Router und Firewall Portscanning Verfugbarkeit,¨ Authentizit¨at Phishing Verletzung der Vertraulichkeit, Benutzer Verfugbarkeit,¨ Authentizit¨at

Tabelle 3.2: M¨ogliche Folgen die sich durch Ausnutzung einer Schwachstelle ergeben k¨onnen.

Marcel Graef & Marco Franke 21 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen

4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen

In diesem Kapitel wird beschrieben, wie eine Untersuchungsumgebung der beiden Sprachdienste Mumble/Murmur und TeamSpeak 3 aufgebaut wird. Es wird fur¨ Mum- ble/Murmur und fur¨ TeamSpeak 3 in Abschnitt 4.2 beschrieben, wie die Installation durchzufuhren¨ ist und welche Basiskonfiguration fur¨ den Betrieb notwendig sind.

4.1 Aufbau und Beschreibung der Untersuchungsumgebung

Wie schon angedeutet, ist es fur¨ die Untersuchung von Netzwerkmanagementl¨osungen n¨otig, 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 mussen.¨

PC 2 spiegelt hier einen Rechner im internen Netzwerk wider. Das grun¨ und blau hinterlegte Netzwerk der Abbildung 4.1 ist uber¨ eine Standard Digital Subscriber Line (DSL)-Verbindung an das Internet angebunden und verfugt¨ daher uber¨ keine statische IP-Adresse. Damit PC 3 den Sprachdienst, der von PC 1 angeboten wird,

22 Marcel Graef & Marco Franke 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 uber¨ 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 fur¨ verschiedene Betriebssysteme auf der offiziellen Web- site http://www.teamspeak.com/ unter der Rubrik Download heruntergeladen werden. Hier wird ein Linux Server amd64 3.0.6.1 installiert. Der Quellcode von TeamSpeak 3 ist nicht frei zug¨anglich, weshalb Sicherheitslucken¨ wesentlich langsamer offiziell aufge- deckt werden. Daher darf der TeamSpeak 3-Server niemals als Root gestartet werden. Falls der Angreifer eine Sicherheitslucke¨ in TeamSpeak 3 findet, hat er m¨oglicherweise root-Rechte. Das ist fatal. Es wird daher ein Benutzer teamspeak mit sudo adduser teamspeak angelegt. Der Benutzer wird im Terminal mit su teamspeak gewechselt. Das heruntergeladene Paket wird nun entpackt und mit ./ts3server_startscript.sh

Marcel Graef & Marco Franke 23 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen start wird der Server als teamspeak Benutzer gestartet. Es erfolgt eine Ausgabe des Servers, wie sie in Abbildung 4.2 dargestellt ist.

Abbildung 4.2: Start des TeamSpeak 3-Servers mit Hilfe des Startskriptes. Beim ersten Start werden das Administrator-Passwort und ein Token generiert.

Zur Kommunikation mit entfernten Teilnehmern, wie z.B. PC 3 aus Abbildung 4.1 wird der Dienst von no-ip.org als Dynamic DNS genutzt. Der automatische Abgleich der dynamischen IP-Adresse wird im Router FritzBox 7240 eingestellt. Des Weiteren muss das Port 9987 UDP fur¨ den Sprachkanal im Router freigegeben werden.

4.2.2 TeamSpeak 3-Client

Die Installation des TeamSpeak 3 Clients gestaltet sich ¨ahnlich. Da der TeamSpeak 3 Client eine propriet¨are Software ist, kann sie nicht uber¨ die Paketverwaltung installiert werden, sondern muss von der offiziellen Website http://www.teamspeak.com/ unter der Rubrik Download heruntergeladen werden.

24 Marcel Graef & Marco Franke 4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware

(a) Festlegung Nicknamen (b) Mikrofoneinstellungen

(c) Mikrofontest (d) Tastenkombination

(e) Einstellungen Sprachausgabe (f) Channel hinzufugen¨

Abbildung 4.3: Installation und Einrichtung des TeamSpeak 3 Clients

Hier wird der Linux Client amd64 3.0.9.2 verwendet. Das Installationsscript TeamSpeak3- Client-linux_amd64-3.0.9.2.run wird gestartet und es muss den Installationsschrit- ten, die teilweise in Abbildung 4.3 visualisiert sind, gefolgt werden. Beim Installions- prozess wird ein Ordner mit den Konfigurations- und ausfuhrbaren¨ Dateien erstellt.

Marcel Graef & Marco Franke 25 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Der Client kann durch Ausfuhrung¨ des darin enthaltenen Shell-Script ts3client_run- script.sh gestartet werden.

(a) Verbindung mit Server herstellen (b) Teamspeak Client

Abbildung 4.4: Teamspeak 3 Client: Verbindung zu einem Server herstellen

Mit dem TeamSpeak 3 Client kann uber¨ 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 IP- Adresse 192.168.1.100 hergestellt. Um Administrationsrechte zu erlangen, muss der beim ersten Start generierte Berechtigungsschlussel¨ (Token, siehe Abbildung 4.2) noch angegeben werden.

4.2.3 Murmur-Server

Der Sprachkommunikationsserver Murmur wird auf dem PC 1 (siehe Abbildung 4.1) installiert. Auf dem PC 1 ist Ubuntu 12.04 (precise) in der 64-Bit Version mit dem Kernel Linux 3.2.0-32-generic installiert. Murmur ist in den Paketquellen der genann- ten Ubuntu-Version enthalten und kann mit apt-get install murmur oder apt-get install mumble-server und sudo dpkg-reconfigure mumble-server auf dem PC installiert werden. Auch viele andere Distributionen enthalten in den Standardquellen die ben¨otigten Pakete. Falls dies nicht der Fall ist, k¨onnen die Quelldateien auch unter http://mumble.info/snapshot/ heruntergeladen und kompiliert werden.

Die grunds¨atzlichen Einstellungen des Murmur-Servers werden in der Konfigurationsda-

26 Marcel Graef & Marco Franke 4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware tei /etc/mumble-server.ini vorgenommen. Wie in Listing 4.1 dargestellt ist, ist das Passwort zu setzen. Dabei ist zu kontrollieren, dass nur der Benutzer root Lese- und Schreibrechte auf diese Datei hat, da diese Datei das Passwort im Klartext enth¨alt.

1 # Password to join server

2 serverpassword=PASSWORD

Listing 4.1: Anderung¨ des Murmur-Serverpassworts in mumble-server.ini

Der Server wird mit murmurd gestartet. Neu starten l¨asst sich der Server mit sudo /etc/init.d/mumble-server restart

Des Weiteren mussen¨ die Ports 64738 TCP fur¨ den Steuerkanal und 64738 UDP fur¨ den Sprachkanal im Router freigegeben werden. Damit ist nach wenigen Einstellungen der Server bereit fur¨ die Kommunikation.

Fur¨ den Betrieb eines Murmur-Servers ist es empfehlenswert, die Nutzer- und Grup- penrechte zu uberpr¨ ufen.¨ 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 uber¨ die Audioein- und -ausgabe vorzunehmen. Ein Ablauf der vorzunehmenden Konfiguration ist in Abbildung 4.5 aufgezeigt.

Die Spacheinstellungen mussen¨ mit großer Sorgfalt durchgefuhrt¨ werden, da hiervon der Benutzungskomfort abh¨angt. Des Weiteren ist es auch m¨oglich, sich mit Mumble per Zertifikat bei dem Server zu authentifizieren. Der Vorteil ist dabei, dass nicht mit Passw¨ortern gearbeitet werden muss. Die Erstellung bzw. der Import eines solchen Zertifikates kann am Ende der Konfiguration vorgenommen werden.

Marcel Graef & Marco Franke 27 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen

(a) Audio-Einstellungen (b) Audio-Einstellungen

(c) Spacheinstellungen (d) Spacheinstellungen

(e) Qualit¨atseinstellungen (f) Positionsabh¨angiges Audio

Abbildung 4.5: Schritte der Installation und Einrichtung von Mumble

Nun sind alle Einstellungen bezuglich¨ Mumble fur¨ einen reibungslosen Betrieb vorge- nommen worden und es kann eine Verbindung zum Server (192.168.0.100) hergestellt werden. Dieser Schritt ist in Abbildung 4.6 visualisiert.

Ist die Verbindung korrekt aufgebaut, wird wie in 4.6 rechts dargestellt ist, eine Willkommensnachricht vom Server an den Client gesendet.

28 Marcel Graef & Marco Franke 4.3 Sicherheitsmaßnahmen

(a) Client mit dem Server verbinden (b) rechts im Bild: Der Channelviewer zeigt die Nutzeraccounts, die mit dem Ser- ver verbunden sind; links im Bild: Nach- richtenverlauf zwischen Server und Client

Abbildung 4.6: Benutzung von Mumble

4.3 Sicherheitsmaßnahmen

In diesem Abschnitt werden die aufgezeigten Schwachstellen diskutiert und Maßnah- men gegen bestehende Bedrohungen erarbeitet. Dabei werden auch grunds¨atzliche Betrachtungen und Handlungsempfehlungen des BSI einfließen.

4.3.1 Spachkonferenzsoftware

Bei der Sprachkonferenzsoftware als Schwachstelle selbst ist fur¨ die sichere Konzeption und Implementation der Herausgeber verantwortlich. Darauf kann der Nutzer auf den ersten Blick nur begrenzt Einfluss nehmen. Bei einer n¨aheren 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 fur¨ jeden frei einsehbar ist, kann jeder Nutzer mit Programmiererfahrung den Quelltext analysieren und gegebenenfalls Sicherheitslucken¨ identifizieren. Diese sind dem Herausgeber der Sprachkonferenzsoftware mitzuteilen und von diesem zeitnah zu beheben.

Zu den Aufgaben der Herausgeber geh¨ort es ebenso, sicherheitsrelevante Mechanismen in die Sprachkonferenzsoftware zu integrieren. Dazu geh¨oren Mechanismen wie das Protokollieren der Aktivit¨aten auf dem Sprachkonferenzsystem. So kann im Fall von Sicherheitsverletzungen (z.B. unautorisierte Zugriffe) der Vorfall stets zuruck¨ verfolgt werden. Auch der Einsatz geeigneter Protokolle und Verschlusselungsverfahren¨ ist vom

Marcel Graef & Marco Franke 29 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Herausgeber zu berucksichtigen.¨ Des Weiteren sind M¨oglichkeiten fur¨ sicherheitsrelevante Konfigurationen bereit zu stellen. Dies spiegelt sich bei TeamSpeak 3 und Mumble/Mur- mur in den umfangreichen Rechtesystemen fur¨ 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 fuhrte¨ zur Entstehung so genannter TeamSpeak-Client-Flooder. Dies waren Programme, mit denen eine unbegrenzte Anzahl vermeintlicher Clients auf einen TeamSpeak 2-Server verbinden konnten und somit die Anzahl von Clients auf dem Server auf das Maximum brachten. Dadurch war der Zugriff weiterer Clients nicht mehr m¨oglich. Ferner sind Mechanismen einzubauen, um das uberm¨ ¨aßige Senden von Nachrichten (Spam) bei der textbasierten Kommunikation auf dem Server zu unterbinden. Dies l¨asst sich unterbinden, indem das Senden von Nachrichten auf eine maximale Anzahl fur¨ ein Zeitintervall vorgeschrieben wird. Diese Technik wird auch gegen Brute-Force-Attacken eingesetzt.

Aber auch Nutzer ohne Programmiererfahrung k¨onnen zur sicheren Implementation beitragen. Nutzer k¨onnen beim Auffinden von Fehlern (Bugs) den Herausgeber der Software daruber¨ informieren (anhand so genannter Bug Reports). Dazu stellen die meisten Herausgeber Bereiche zur Verfugung,¨ indem Bug Reports eingereicht werden k¨onnen. Bei TeamSpeak 3 und Mumble/Murmur sind speziell fur¨ diesen Zweck Bereiche in den offiziellen Foren eingerichtet. Im Aufgabenbereich des Nutzers liegt auch das Softwareaktualisierungen durchgefuhrt¨ werden. Uber¨ neue Versionen kann sich auf den offiziellen Webseiten informiert werden. Bei TeamSpeak 3 und Mumble/Murmur wird jedoch auch beim Start der Software uber¨ neue verfugbare¨ Versionen benachrichtigt.

4.3.2 Konfiguration der Server

Die M¨oglichkeit zur Konfiguration der Sprachkonferenzsoftware allein ist nicht ausrei- chend, wenn diese nicht geeignet eingesetzt werden. Die Einstellungen und Rechtever- gabe sind dabei grundlich¨ zu planen und stark einsatzabh¨angig. Grunds¨atzlich ist es ratsam auf jedem Server nur genau einen Administrator mit allen Rechten einzurichten. Lediglich fur¨ 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 ¨offentlichen Sprachkonferenzserver, so ist der Zugang fur¨ jeden

30 Marcel Graef & Marco Franke 4.3 Sicherheitsmaßnahmen

Client zu erm¨oglichen, die Rechte auf dem Server als Gast aber minimal zu halten. So durfen¨ G¨aste lediglich das Recht erhalten, selbst¨andig in dafur¨ vorgesehene Channel beizutreten, sprechen zu durfen¨ oder Textnachrichten senden zu k¨onnen. Es ist aber auch m¨oglich, auf einem ¨offentlichen Server Channel einzurichten, dem ein Gast nicht beitreten kann, wenn dies nicht erwunscht¨ ist. Der Zugriff kann dann beispielsweise nur durch einen Moderator, ein Passwort oder nur fur¨ auf dem Server registrierte Clients erfolgen. Es ist auch m¨oglich, eine Rechtegruppe fur¨ Moderatoren zu erstellen, deren Wirkungsbereich sich nur auf spezielle Channel beschr¨ankt.

M¨ochte man einen privaten Sprachkonferenzserver betreiben, beispielsweise in einem Unternehmen zur internen Kommunikation, so ist der Zugriff auf den Server von vorn- herein zu unterbinden und nur fur¨ registrierte Clients oder mit Passwort zu erm¨oglichen. Aber auch der interne Bereich ist, wie bei einem ¨offentlichen Sprachkonferenzserver, geeignet einzurichten. Denn wie in Abschnitt 3.3.2 hervorgegangen, k¨onnen auch interne Nutzer k¨onnen b¨oswillige Ziele verfolgen oder eine Bedrohung darstellen. Auch hier gilt eine Einsatz abh¨angige, grundliche¨ Planung der Struktur.

Eine weitere wichtige Maßnahme ist die Verschlusselung¨ der Sprachdaten. Bei TeamS- peak 3 ist darauf zu achten, dass die Verschlusselung¨ standardm¨aßig deaktiviert ist. Dies findet beispielsweise Anwendung, wenn die durch die Verschlusselung¨ verursachte Latenz unerwunscht¨ ist und es sich nicht um sensible Sprachdaten handelt. Grundlegend ist eine Verschlusselung¨ immer zu empfehlen. Bei Mumble/Murmur hingegen ist die Verschlusselung¨ immer aktiv und kann auch nicht deaktiviert werden.

Neben der Rechtevergabe und dem Setzen von Passw¨ortern ist es auf einen TeamS- peak 3-Server m¨oglich, eine so genannte Blacklist zu verwenden. Damit k¨onnen Ver- bindungen an den TeamSpeak 3 TCP-Query Dienst einzelner IP-Adressen oder ganzer IP-Adressbereiche abgelehnt und damit von der Kommunikation mit dem Server ausge- schlossen werden.

4.3.3 Sicherheitsrelevante Einstellungen des Betriebssystems

In diesem Abschnitt werden die wesentlichen Dinge erl¨autert, wie ein Linux Server (PC 1) sicherer gestaltet werden kann. Ein sehr wichtiger Teil des Sicherheitskonzepts von Linux und auch Windows ab Version Vista ist, dass mit unterschiedlichen Privilegien gearbeitet wird. Es ist extrem wichtig, dass kein Dienst als root bzw. Administrator

Marcel Graef & Marco Franke 31 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen gestartet wird oder dass ein Nutzer a priori Administrationsrechte besitzt. Bei Ubuntu mussen¨ die Administrationsrechte mit sudo angefordert werden und sind fur¨ 15 min gultig.¨ Um die Sicherheit zu erh¨ohen, soll dies auf 0 min herunter gesetzt werden. Damit sind die Administrationsrechte nur fur¨ die eine Operation vorhanden. Zur Anderung¨ wird die Datei /etc/sudoers mit root-Rechten ge¨offnet und folgender Eintrag (siehe Listing 4.2) ge¨andert:

1 # Setzt das Timeout fuer sudo auf Null, der Standardwert ist 15 Minuten.

2 Defaults timestamp timeout = 0

Listing 4.2: Timeout fur¨ sudo unter Ubuntu auf Null setzen

Updates enthalten meist Verbesserungen von Software und Sicherheitsaktualisierungen. In den Software-Paketquellen empfiehlt es sich, wichtige Sicherheitsaktualisierungen automatisch stundlich¨ zu aktualisieren. So k¨onnen schnell Sicherheitslucken¨ geschlossen werden.

Abbildung 4.7: Dienste mit rcconf deaktivieren

Des Weiteren mussen¨ Dienste, die nicht ben¨otigt werden, deaktiviert werden. Dazu wird das Programm rcconf installiert (sudo apt-get install rcconf dialog). Die De- aktivierung ist sehr davon abh¨angig, welche Aufgaben der Rechner (PC 1) ubernehmen¨ soll. Es ist empfehlenswert, beispielsweise grup-common und bluetooth zu deaktivieren, falls diese nicht ben¨otigt werden (siehe Abbildung 4.7).

32 Marcel Graef & Marco Franke 4.3 Sicherheitsmaßnahmen

Neben den Diensten stellt jede Software auf dem Rechner ein potentielles Sicherheitsri- siko dar. Aus diesem Grund sind uberfl¨ ussige¨ Pakete z.B. uber¨ Synaptic zu entfernen. Damit nicht die M¨oglichkeit besteht, dass sich Schadsoftware auf dem Rechner selbst ubersetzt,¨ 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 M¨oglichkeit, die Sicherheit des Systems mit dem Programm Bastille Linux halb automatisch zu verbessern. Es beinhaltet die Anderung¨ 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 bezuglich¨ einer Firewall mussen¨ zwei Netzwerkkom- ponenten betrachtet werden. Dies ist zum Einen die FritzBox 7240 und der PC 1. Da die Linux-Distribution der FritzBox nicht ver¨andert wurde und keinerlei Software Erweiterungen durchgefuhrt¨ wurden, l¨auft wie ublich¨ lediglich ein Network Address Translation (NAT) Router mit Portfilter sowie Black- und Whitelists. NAT ist im Router aktiviert und es sind lediglich die Ports fur¨ 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 ¨offentlichen 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 uber¨ 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 fuhren¨ darf. Mit iptables kann uber¨ 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.

Marcel Graef & Marco Franke 33 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Um einen Uberblick¨ uber¨ bestehende Regeln des Systems zu erhalten, k¨onnen diese mit sudo iptables -L angezeigt werden. In Listing 4.3 ist das komplett kommentierte Firewallskript fur¨ den Rechner PC 1 dargestellt. Nun ein paar wesentliche Erl¨auterungen zu diesem Skript. Die Regel (0) im Listing 4.3 auf den Zeilen 6 und 7 ist gerade fur¨ Ubuntu ganz wichtig, da viele Prozesse dieser Distribution zur Kommunikation Internet- Sockets verwenden. Aus diesem Grund muss der lokale Verkehr akzeptiert werden. Die Regel (4) im Listing 4.3 auf Zeile 18 ist fur¨ den Fernzugriff uber¨ Secure Shell (SSH) notwendig. um den Server von der Ferne zu managen. Zur Erh¨ohung 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 uber¨ SSH verbunden werden. Fur¨ einige Managementl¨osungen, ist ein Webserver notwendig. Um auf die generierten Webseiten zugreifen zu k¨onnen, 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 uber¨ TeamSpeak 3 bzw. Murmur ben¨otigt.

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 #(4a) Empfehlung, wenn immer von einem bestimmten Host zugegriffen

34 Marcel Graef & Marco Franke 4.3 Sicherheitsmaßnahmen

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 fur¨ eine lokale Firewall (PC 1) uber¨ iptables fur¨ 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 /et- c/init.d/ kopiert. Mit chmod 755 /etc/inti.d/firewallMurmurTSSkript.sh wird das Skript ausfuhrbar¨ 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 durchgefuhrt¨ werden.

Marcel Graef & Marco Franke 35 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen

1 # cd /etc/rc3.d/

2 # ln −s /etc/init.d/firewallMurmurTSSkript.sh S05firewallMurmurTSSkript

Listing 4.4: Erzeugung eines Startlinks zur Ausfuhrung¨ des Firewallskript im Runlevel 3

Die zwei Zeilen in Listing 4.4 sind fur¨ die Runlevel 4 und 5 zu wiederholen. Die S- Nummer (in Listing 4.4) definiert die Reihenfolge der zu startenden Dienste. Diese Angabe ist fur¨ die Berucksichtigung¨ der Abh¨angigkeiten von Diensten untereinander gedacht. Hier wird diese Angabe genutzt, um die Firewall vor dem Start des Netzwerks zu starten, damit keine Sicherheitslucke¨ entsteht, die ein Angreifer ausnutzen k¨onnte.

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 10011/tcp open|filtered unknown

18 17500/tcp open|filtered unknown

19 30033/tcp open|filtered unknown

20 38912/tcp open|filtered unknown

21 64738/tcp open|filtered unknown

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 Marcel Graef & Marco Franke 4.3 Sicherheitsmaßnahmen

werden. Dabei wurde sudo nmap -sT -p- 192.168.1.100 aufgerufen. Der Parameter -sT bewirkt, dass TCP gepruft¨ wird. Soll das UDP getestet werden, muss -sU angegeben werden.

Mit Firewall ist die Ausgabe (siehe Listing 4.6) deutlich kurzer.¨

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

Ahnliche¨ Ergebnisse konnten bei der Uberpr¨ ufung¨ 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 k¨onnen uber¨ den Client auch einige adminis- trative Einstellungen vorgenommen werden. Dazu wird sich am Client als serveradmin angemeldet und es muss unter dem Menu¨ Rechte I Berechtigungsschlussel¨ der Berech- tigungsschlussel¨ (Token siehe Abbildung 4.2), der beim Ersten Start des Servers uber¨ die Shell ausgegeben wurde, hinzugefugt¨ werden. Nun mussen¨ im Menu¨ Rechte die jeweiligen Rechte der Server-Gruppen und Channel-Gruppen uberpr¨ uft¨ und gegebe- nenfalls ge¨andert werden. Es ist auf jeden Fall zu empfehlen, dass ausschließlich der Server-Admin den Server administrieren darf. Normale Benutzer oder gar G¨aste durfen¨ dazu keine Rechte besitzen. Des Weiteren ist mit den Rechten zum Dateitransfer und zur Mitgliederverwaltung sparsam umzugehen und die Erstellungsrechte hier dem Server-

Marcel Graef & Marco Franke 37 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Admin zu uberlassen.¨ Empfehlenswert ist hier, eine separate Moderatoren-Gruppe anzulegen.

Murmur Nachdem der Server Murmur betriebsbereit ist, mussen¨ dennoch die Gruppen- berechtigungen uberpr¨ uft¨ werden. Zun¨achst ist mit sudo -i murmurd -ini /etc/mum- ble-server.ini -supw PASSWORD ein SuperUser-Passwort zu genieren. Nun kann eine Verbindung uber¨ Mumble zum Server Murmur hergestellt werden. Dabei ist als Benutzername SuperUser und das dazugeh¨orige Passwort zu verwenden. Mit einem Rechtsklick auf dem Hauptkanal und durch Bet¨atigen von Bearbeiten wird das Gruppen- und Berechtigungscenter ge¨offnet. Es ist wichtig, dass nur die Gruppe admin und evtl. eine neu angelegte Gruppe moderator die Berechtigungen bearbeiten k¨onnen. Bei der Einstellung Selbst registrieren fur¨ die Gruppe all ist in diesem Zusammenhang zu prufen,¨ ob dies wirklich erwunscht¨ ist. Im Zweifelsfall ist dies zu deaktivieren.

4.3.6 Mensch als Schwachstelle

Neben den in diesem Kapitel erarbeiteten Maßnahmen technischer Natur mussen¨ auch Maßnahmen gegen die Schwachstelle Mensch erarbeitet werden. Dies hat den Grund, dass der Mensch Informationen (z.B. Passw¨orter) besitzen muss, welche ihm Zugang zum System gew¨ahren. Ferner ist der Mensch angreifbarer hinsichtlich T¨auschungen und Manipulationen. So muss darauf geachtet werden, dass sensible Daten nicht an unberechtigte Dritte gelangen.

Die erste Maßnahme ist die Wahl sicherer Passw¨orter. Es ist darauf zu achten, dass die Passw¨orter m¨oglichst lang (ca. 8 Stellen) sind und aus Buchstaben, Zahlen und Sonderzeichen bestehen. Zus¨atzlich mussen¨ stets unterschiedliche Passw¨orter gew¨ahlt werden. Auch durfen¨ Passw¨orter 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 prufen,¨ ob es sich um eine vertrauenswurdige¨ Quelle handelt. Uber¨ Instant Messenger oder E-Mail erhaltene Hyperlinks sind vor dem Anklicken bzgl. ihrer Vertrauenswurdigkeit¨ zu uberpr¨ ufen.¨ Beispielsweise kann die Dateiendung erste Hinweise auf die Art der Daten geben. Auch bei E-Mail Anh¨angen ist Vorsicht geboten.

38 Marcel Graef & Marco Franke 4.3 Sicherheitsmaßnahmen

E-Mails durfen¨ generell nur im Textformat ge¨offnet werden, damit keine integrierten Scripte ausgefuhrt¨ werden.

Es ist wichtig, dass alle Nutzer des Sprachkonferenzsystems sorgf¨altig darauf achten, alle erforderlichen Maßnahmen umzusetzen. Es bietet sich an dieser Stelle an, Verhal- tensregeln zur Erh¨ohung der Sicherheit an die Nutzer zu tragen. In Unternehmen ist die Durchfuhrung¨ spezieller Schulungen zu diesem Sachverhalt zu empfehlen.

Marcel Graef & Marco Franke 39 5 Demonstration von Angriffsszenarien

5 Demonstration von Angriffsszenarien

In diesem Kapitel werden eine Reihe von Angriffsszenarien betrachtet. Es werden Sicherheitsmechanismen auf ihre Funktionen getestet, beispielsweise die Anti-Flood- Protection von TeamSpeak. Dabei werden m¨ogliche Angriffsszenarien betrachtet und praktisch durchgefuhrt.¨

5.1 Betrachtung des TeamSpeak 3-Server Query Interface

In diesem Abschnitt wird untersucht, welche Angriffsm¨oglichkeiten das TeamSpeak 3- Server 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 durchgefuhrt.¨

5.1.1 Aufbau des Testprogramm

Das Testprogramm wird die Aufgabe besitzen, automatisiert Daten zum TeamSpeak 3- Server Query Interface zu senden und zu empfangen. Fur¨ 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 k¨onnen w¨ahrend der Verbindung mit den

40 Marcel Graef & Marco Franke 5.1 Betrachtung des TeamSpeak 3-Server Query Interface

Variablen out an den Server gesendet und mit in vom Server empfangen werden. Im dargestellten Testbereich in Listing 5.1k ¨onnen 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()));

6 //### Testbereich ###

7

8 out.println(”hier Query−Befehl als String”);

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) {

18 System.err.println(”ERROR: Server refuse the connection.”);

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 Ausfuhren¨ 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 ” for information on a specific command.

Listing 5.2: Ausgabe des Verbindungstests mit dem TeamSpeak 3-Server Query Interface

Marcel Graef & Marco Franke 41 5 Demonstration von Angriffsszenarien

Die von der TeamSpeak 3-Server Query Interface empfangenen Daten sind in Listing 5.2 dargestellt. Daraus l¨asst 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 fur¨ 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 m¨ochte der Angreifer den TeamSpeak 3-Server mit Textnachrichten fluten. Fur¨ diesen Zweck wird im Testbereich des Testprogramms (Listing 5.1) die Befehlsfolge aus Listing 5.3 eingefugt.¨ Um sich anzumelden, muss als Erstes der Befehl login verwendet werden. Danach wird mit dem Befehl use der virtuelle Server ausgew¨ahlt. Jetzt kann mit Hilfe einer Schleife eine beliebige Anzahl von Textnachrichten (hier numberOfMessages = 100) an den Server geschickt werden.

1 //### Testbereich ###

2 out.println(”login serveradmin yI3K4DpO”);

3 out.println(”use 1”);

4 int numberOfMessages=100;

5 for( int i = 1; i <= numberOfMessages; i++ )

6 out.println(”sendtextmessage targetmode=3 msg=SPAMMSG Nr.”+i);

7 //############

Listing 5.3: TeamSpeak 3-Server Query Interface Login und Spam

Wird das Testprogramm ausgefuhrt,¨ erh¨alt man die im Listing 5.4 angegebene Ausgabe. Daraus ist zu entnehmen, dass nach dem Senden der achten Nachricht die Anti-Flood- Protection die Verbindung unterbricht.

Der TeamSpeak 3-Server Dokumentation ist zu entnehmen, dass die Anti-Flood- Protection 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 Marcel Graef & Marco Franke 5.1 Betrachtung des TeamSpeak 3-Server Query Interface 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 fur¨ 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. Zus¨atzlich kann eine fehlerhafte Konfiguration der Anti-Flood-Protection dazu fuhren,¨ dass diese nicht wirkt.

1 SERVER: error id=0 msg=ok

2 SERVER: error id=0 msg=ok

3 SERVER: error id=0 msg=ok

4 SERVER: error id=0 msg=ok

5 SERVER: error id=0 msg=ok

6 SERVER: error id=0 msg=ok

7 SERVER: error id=0 msg=ok

8 SERVER: error id=0 msg=ok

9 SERVER: error id=0 msg=ok

10 ERROR: Server refuse the connection.

Listing 5.4: Verbindungsabbruch durch die Anti-Flood-Protection

Fur¨ weitere Tests wird daher die IP-Adresse von PC 3 in die Whitelist eingetragen. Bei erneutem Durchfuhren¨ der Befehlsfolge aus Listing 5.3 ist keine Verbindungsunter- brechung 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 F¨allen kann es jedoch erwunscht¨ sein (fur¨ z.B. Fernwar- tungen), IP-Adressen oder ganze IP-Adressbereiche auf die Whitelist zu setzen. Diese Experimente zeigen, dass dabei sehr sorgf¨altig vorgegangen werden muss.

Marcel Graef & Marco Franke 43 5 Demonstration von Angriffsszenarien

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 beschr¨ankt. An dieser Stelle stellt sich die Frage, ob ein Angreifer ohne gultige¨ Logindaten mit deaktivierter Anti-Flood-Protection einen Brute-Force-Angriff auf das TeamSpeak 3- Server Query Interface durchfuhren¨ kann. Dies war beispielsweise bei TeamSpeak 2 mit dem Programm THC − Hydra ([Hau12]) m¨oglich. Der Testbereich im Testprogramm (Listing 5.1) wird dafur¨ mit der unter Listing 5.5 dargestellten Befehlsfolge ersetzt. Die Befehlsfolge sendet mehrfach den login Befehl mit unterschiedlichen Passw¨ortern.

1 //### Testbereich ###

2 String[] pws = {”a”,”b”,”c”,”aa”,”ab”,”ac”,”bb”,”ba”,”bc”,”cc”,”ca”,”cb”};

3 for( String pw : pws){

4 out.println(”login serveradmin ”+pw);

5 }

6 //############

Listing 5.5: Brute-Force-Befehlsfolge, um ein TeamSpeak 3-Query Interface Login zu erhalten

Nach Ausfuhren¨ der Befehlsfolge erh¨alt man die unter Listing 5.6 dargestellte Ant- wort 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 fur¨ 10 Minuten verbannt.

1 SERVER: error id=520 msg=invalid loginname or password

2 SERVER: error id=520 msg=invalid loginname or password

3 SERVER: error id=520 msg=invalid loginname or password

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 unabh¨angiger Mechanismus existiert, welcher gegen Brute-Force-Angriffe vorbeugt. Durch die Dauer der Verbannung sind bei einem einzigen angreifenden Rechner maximal 576 Passw¨orter pro Tag testbar. Das heißt, Brute-Force-Angriffe sind durchfuhrbar,¨ werden jedoch stark beeintr¨achtigt. An dieser Stelle wird klar, wie wichtig die Wahl eines

44 Marcel Graef & Marco Franke 5.2 TeamSpeak 3-Server Query Interface Exploit sicheren Passwortes ist. Denn je l¨anger das Passwort ist und um so mehr verschiedene Zeichen es beinhalten kann, um so mehr m¨ogliche Passw¨orter sind bei einem Brute-Force- Angriff zu testen. Dadurch werden solche Angriffe in einem realistischen Zeitfenster nicht mehr durchfuhrbar.¨

5.2 TeamSpeak 3-Server Query Interface Exploit

Mit dem folgenden Szenario wird aufgezeigt, welche Auswirkungen das Ausnutzen einer Sicherheitslucke¨ mit Hilfe eines Exploit haben kann. Ausgangspunkt dieser Szenarien ist die Missachtung oder Vernachl¨assigung 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.

Fur¨ das Szenario wird die in Kapitel4 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 Verwen- dung eines von Luigi Auriemma geschriebenen C-Programms namens teamspeakrack m¨oglich [Aur10c], eine Schwachstelle auszunutzen. Das C-Programm steht als Quell- text (teamspeakrack.c) zur Verfugung.¨ Als Angreifer wird PC 3 (siehe Abbildung 4.1) verwendet.

Mit Hilfe von teamspeakrack ist es m¨oglich, TeamSpeak 3-Server Query-Befehle auf dem TeamSpeak-Server (PC 1) auszufuhren,¨ ohne einen authentifizierten Zugriff auf das Query Interface zu besitzen. Zus¨atzlich verfugt¨ das C-Programm uber¨ 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 Umstel- lung des TeamSpeak-Protokolls entstanden ist. TeamSpeak 3 verwendet UDP-Pakete fur¨ acht verschiedene Aufgaben (8 Kan¨ale). Speziell der Kanal 2 wird fur¨ das Senden

Marcel Graef & Marco Franke 45 5 Demonstration von Angriffsszenarien

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 uber¨ das UDP-Paket auf Kanal 2 gesendet werden, auf dem Server ausgefuhrt¨ werden. Das heißt, um die Schwachstelle auszunutzen, muss ein modifiziertes UDP-Paket uber¨ den standardm¨aßig ge¨offneten 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 zun¨achst mit der Option 1 (siehe Abbildung 5.2) in einen Zustand versetzt, welcher die selben M¨og- lichkeiten bietet, als w¨are der Angreifer mit dem TeamSpeak 3-Server Query Interface verbunden. Das heißt, der Angreifer kann mit teamspeakrack fortlaufend Query-Befehle senden. Die dabei fur¨ den Angreifer zu sehende Oberfl¨ache ist in Abbildung 5.3 zu sehen. Da die Query-Befehle uber¨ ein UDP-Paket in den Server eingeschleust werden, k¨onnen 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 gultiger¨ Logindaten uber¨ 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 k¨onnen jetzt gezielt Angriffe - basiert auf dem Senden von Query-Befehlen - gegen den Sprachdienst durchgefuhrt¨ werden. Die dabei m¨oglichen Befehle k¨onnen dem TeamSpeak 3-Server Query Handbuch entnommen werden. Eine Reihe solcher M¨oglichkeiten sind als Befehlsfolgen in das Programm integriert und k¨onnen ausgefuhrt¨ werden.

46 Marcel Graef & Marco Franke 5.2 TeamSpeak 3-Server Query Interface Exploit

Abbildung 5.3: TeamSpeak 3 Server Query Interface Exploit

5.2.2 Einrichten einer Hintertur¨

Als n¨achstes wird gezeigt, wie eine Hintertur¨ (Backdoor) auf dem TeamSpeak 3-Server eingerichtet werden kann. Dafur¨ wird ein administrativer Zugriff eingerichtet. Zun¨achst 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 Serverad- ministratoren, welche durch eine Identifikationsnummer gekennzeichnet ist, zugeordnet werden. Dafur¨ wird mit dem C-Programm teamspeakrack der Server Query-Befehl aus Listing 5.7 ausgefuhrten¨ Syntax verwendet.

1 #servergroupaddclient sgid={groupID} cldbid={clientDBID}

Listing 5.7: Query-Befehl servergroupaddclient Syntax

Marcel Graef & Marco Franke 47 5 Demonstration von Angriffsszenarien

Die ben¨otigten Informationen groupID und clientDBID k¨onnen zwar nicht mit teamspeakrack ermittelt werden, aber durch den verbundenen Client ist es m¨oglich. Die groupID fur¨ die richtige Servergruppe erh¨alt 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 erh¨alt der Angreifer ebenfalls im TeamSpeak 3-Client, indem er in der Channelubersicht¨ auf den gewunschten¨ 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 k¨onnen. Da bei einem Update der Sprachkonferenzsoftware, welche die Sicher- heitslucke¨ schließt, die Administrationsrechte fur¨ den vermeintlichen Gast bestehen bleiben, wurde erfolgreich eine Hintertur¨ eingerichtet. Es wird empfohlen, nach dem Bekanntwerden und Schließen einer solchen Sicherheitslucke¨ mit Hilfe von Backups oder Sicherungspunkten das System auf einen fruheren¨ Zustand zuruck¨ zu setzen. Ist dies nicht m¨oglich, sollte die Rechtevergabe erneut durchgefuhrt¨ werden.

48 Marcel Graef & Marco Franke 5.2 TeamSpeak 3-Server Query Interface Exploit

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 fuhren.¨ Diese sind in Listing 5.9 aufgez¨ahlt.

1 >banlist

2 >complainlist

3 >servernotifyunregister

4 >serverrequestconnectioninfo

5 >setconnectioninfo

6 >servernotifyregister event=server

Listing 5.9: Query-Befehle, die mit teamspeakrack zum Absturz fuhren¨

Der Grund fur¨ den Absturz bei Verwendung dieser Befehle ist, dass bei der Verarbeitung der Befehle Informationen des Client, welcher den Befehl ausfuhren¨ m¨ochte, ben¨otigt werden. Da bei Verwendung von teamspeakrack keine ordnungsgem¨aße Verbindung hergestellt wird, kann der TeamSpeak 3-Server den Befehl keinem gultigen¨ 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). Fur¨ diesen Zweck wird der im Listing 5.10 aufgefuhrte¨ 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 zuf¨allig gene- rierten 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 Nach- richtenfensters des TeamSpeak 3-Clients zu sehen. In der Abbildung ist ein Ausschnitt der gesendeten zuf¨allig generierten Nachrichten dargestellt.

Marcel Graef & Marco Franke 49 5 Demonstration von Angriffsszenarien

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 Einschr¨ankung der gesendeten Befehle pro Zeitintervall, nicht greift. Dies ist mit dem Einschleusen der Befehle uber¨ die UDP-Pakete zu begrunden.¨ Dadurch werden die IP-basierten Filter (Anti-Flood-Protection) des TeamSpeak 3-Server Query Interface ubergangen.¨

5.2.5 Weitere M¨oglichkeiten von teamspeakrack

Neben den bisher vorgestellten M¨oglichkeiten, den TeamSpeak 3-Server zu manipulieren, bietet teamspeakrack weitere vorgefertigte Befehlssequenzen, welche durch die Optionen 1 bis 9 (siehe Abbildung 5.2) ausgew¨ahlt werden k¨onnen.

Dazu geh¨ort die M¨oglichkeit, die maximale Anzahl von Clients auf dem TeamSpeak 3- Server mit Hilfe des unter Listing 5.11 aufgefuhrten¨ Befehls auf Null zu setzen. Dadurch ist es nicht mehr m¨oglich, mit dem TeamSpeak-Client eine Verbindung mit dem TeamSpeak 3-Server herzustellen.

1 >serveredit virtualserver maxclients=0

Listing 5.11: Query-Befehl zur Anderung¨ der maximalen Anzahl von Clients auf dem Server

Die bisher noch nicht betrachteten und vorgefertigten Optionen von teamspeakrack (siehe Abbildung 5.2) erm¨oglichen es, ohne Kenntnisse diverser Identifikationsnummern (z.B. clientID oder banID), alle Clients anzusprechen. Dabei werden Befehle, welche die Angabe einer Identifikationsnummer ben¨otigen, innerhalb einer Schleife ausgefuhrt.¨ Die dabei aufsteigende Schleifenvariable wird entsprechend als Parameter beim Aufruf eines Befehls verwendet. So wird iterativ jede m¨ogliche ID zusammen mit einem Befehl verwendet. Die dafur¨ zur Verfugung¨ stehenden - in teamspeakrack implementierten - M¨oglichkeiten sind:

• alle Clients vom Server werfen

50 Marcel Graef & Marco Franke 5.3 Murmur Exploit fur¨ 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 aufgefuhrt.¨

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 fur¨ 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 Sicherheitslucke¨ nicht garantiert werden kann, dass der TeamSpeak 3-Server keine Folgesch¨aden davon getragen hat. In die- sem Fall w¨are der Folgeschaden die in Abschnitt 5.2.2 eingerichtete Backdoor (siehe Abschnitt 3.2.5). Es ist also zwingend notwendig, nach Bekanntwerden einer solchen Sicherheitslucke¨ das System genau zu prufen.¨ Falls m¨oglich, sollte in diesem Fall das System auf einen fruheren¨ Zustand zuruck¨ gesetzt werden. Dies kann beispielsweise durch Wiederherstellungspunkte oder Backups erfolgen.

5.3 Murmur Exploit fur¨ einen DoS-Angriff

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 m¨oglich, 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

Marcel Graef & Marco Franke 51 5 Demonstration von Angriffsszenarien

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 Murmur- Adresse des Murmur-Servers als Parameter auf- Server verbunden. gerufen.

Abbildung 5.7: Murmur Exploit fur¨ einen DoS-Angriff: Kommandozeile und Mumble- Client 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/ubuntu- universe-i386/mumble-server_1.2.2-1ubuntu1_i386.deb.html verfugbar¨ und wird als deb-Paket uber¨ die Paketverwaltung installiert. Auch das Programm zur Demons- tration des Exploits mumbleed steht unter [Aur10a] als C-Programm zur Verwendung bereit.

(a) Das Programm mumbleed wurde ausgefuhrt¨ (b) Der Mumble-Client ist nicht mehr mit dem und hat den Murmur-Server beendet. Murmur-Server verbunden.

Abbildung 5.8: Murmur Exploit fur¨ einen DoS-Angriff: Kommandozeile und Mumble- Client nach dem Angriff.

Das Programm mumbleed wird, wie in Abbildung 5.7 dargestellt, mit der IP-Adresse

52 Marcel Graef & Marco Franke 5.3 Murmur Exploit fur¨ einen DoS-Angriff

(192.168.1.100) des Murmur-Servers (PC 1) als Parameter gestartet. Um die Auswirkun- gen des Programms mumbleed beobachten zu k¨onnen, wird eine Verbindung zwischen den Murmur-Server (PC 1) und des Mumble Clients (PC 2) hergestellt. Dem Mumble- Client-Fenster (Abbildung 5.7) kann entnommen werden, dass eine Verbindung zum Server hergestellt wurde.

Nachdem das Programm mumbleed ausgefuhrt¨ 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]

Marcel Graef & Marco Franke 53 6 Resumee¨ und Ausblick

6 Resumee¨ und Ausblick

In Kapitel2 wurden die Sprachkonferenzsysteme TeamSpeak 3 und Mumble/Murmur hinsichtlich ihrer Grundfunktionalit¨aten untersucht und verglichen. Dabei sind viele Parallelen zwischen den Sprachkonferenzsystemen hervorgegangen. Deshalb ist Mum- ble/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 gr¨oßten Unterschied bilden die unterschiedlichen Lizenzmodelle. Besonders fur¨ kommerzielle Unternehmen scheint die Wahl fur¨ den Einsatz von Mumble/Murmur aus Kostengrunden¨ attraktiver.

Aus Kapitel3 ist hervorgegangen, welche Schwachstellen in einem Sprachkonferenz- system existieren k¨onnen. Es hat sich gezeigt, dass mit einer detaillierten Analyse viele Schwachstellen aufgedeckt werden k¨onnen, welche man erst durch eine n¨ahere 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 Kapitel4 wurde beispielhaft eine Testumgebung auf Grundlage der in Kapitel3 identifizierten Schwachstellen aufgebaut und getestet. Dabei wurden zahlreiche Maßnah- men 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 Kapitel5 eine Reihe Szenarien aufgezeigt, welche die An- greifbarkeit 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 Marcel Graef & Marco Franke Schwachstelle Mensch durch unachtsame Konfiguration oder die Verwendung unsicherer Passw¨orter 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 Sicherheits- lucken¨ einem gr¨oßeren Personenkreis zur Verfugung¨ steht, einen fortschrittlicheren Codec verwendet und keinen lizenzrechtlichen Einschr¨ankungen unterworfen ist, ist die Verwendung von Mumble/Murmur zu empfehlen.

Marcel Graef & Marco Franke 55 Literaturverzeichnis

Literaturverzeichnis

[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. – auf- gerufen: 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-Sicherheits- Kochbuch. O’Reilly Germany, 2004

[BSI04] Projektgruppe E-Government im Bundesamt fur¨ Sicherheit in der In- formationstechnik(BSI): Sichere Kommunikation im E-Government. https://www.bsi.bund.de/cae/servlet/contentblob/476846/ publicationFile/28062/4_SiKomm_pdf.pdf. Version: 2004. – auf- gerufen: 29.11.2012

[Cam10] Camboulive, Hugo: An open source alternative to the Teams- peak server with protocol compatibility. https://github.com/Youx/ soliloque-server/wiki/TeamSpeak-protocol. Version: 2010. – aufgeru- fen: 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 Marcel Graef & Marco Franke Literaturverzeichnis

[MuM12a] Das Mumble-Team: Mumble offizielle Webpr¨anz. http://mumble. sourceforge.net/. Version: 2012. – aufgerufen: 25.11.2012

[MuM12b] Das Mumble-Team: Mumble offizielle Webpr¨anz: ACL. http://mumble. sourceforge.net/ACL_Tutorial/Deutsch. Version: 2012. – aufgerufen: 25.11.2012

[MuM12c] Das Mumble-Team: Mumble offizielle Webpr¨anz: FAQ. http://mumble. sourceforge.net/. Version: 2012. – aufgerufen: 25.11.2012

[MuM12d] Das Mumble-Team: Mumble offizielle Webpr¨anz: Installing. http:// mumble.sourceforge.net/Installing_Mumble. Version: 2012. – aufge- rufen: 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. – aufgerufen: 25.11.2012

[PHC08] Xiph.Org Foundation: Celt Projekthomepage. http://celt-codec.org. Version: 2008. – aufgerufen: 25.11.2012

[PHO11] Xiph.Org Foundation: Opus Projekthomepage. http://opus-codec.org. Version: 2011. – aufgerufen: 25.11.2012

[PHS94] Xiph.Org Foundation: Speex Projekthomepage. http://www.speex.org. Version: 1994. – aufgerufen: 25.11.2012

[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 fur¨ Linux-Server und Netzwerke. Pearson Deutschland GmbH, 2011

[TSo12a] TeamSpeak Systems GmbH: TeamSpeak offizielle Webpr¨anz. http://www. teamspeak.com. Version: 2012. – aufgerufen: 25.11.2012

[TSo12b] TeamSpeak Systems GmbH: TeamSpeak offizielle Webpr¨anz: Downloads.

Marcel Graef & Marco Franke 57 Literaturverzeichnis

http://www.teamspeak.com/?page=downloads. Version: 2012. – aufgeru- fen: 25.11.2012

[TSo12c] TeamSpeak Systems GmbH: TeamSpeak offizielle Webpr¨anz: FAQ. http: //www.teamspeak.com/?page=faq. Version: 2012. – aufgerufen: 25.11.2012

[TSo12d] TeamSpeak Systems GmbH: TeamSpeak offizielle Webpr¨anz: Licensing Over- view. http://sales.teamspeakusa.com/licensing.php. Version: 2012. – aufgerufen: 25.11.2012

[TSo12e] TeamSpeak Systems GmbH: TeamSpeak offizielle Webpr¨anz: 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 Webpr¨anz: Support. http: //support.teamspeakusa.com/index.php. Version: 2012. – aufgerufen: 25.11.2012

[TSo12g] TeamSpeak Systems GmbH: TeamSpeak offizielle Webpr¨anz: 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 Marcel Graef & Marco Franke Abbildungsverzeichnis

Abbildungsverzeichnis

2.1 Schematische Darstellung des Client-Server-Modells von TeamSpeak 3 und Mumble/Murmur...... 3

4.1 Schematische Darstellung der Untersuchungsumgebung...... 23 4.2 Start des TeamSpeak 3-Servers mit Hilfe des Startskriptes. Beim ersten Start werden das Administrator-Passwort und ein Token generiert.... 24 4.3 Installation und Einrichtung des TeamSpeak 3 Clients...... 25 4.4 Teamspeak 3 Client: Verbindung zu einem Server herstellen...... 26 4.5 Schritte der Installation und Einrichtung von Mumble...... 28 4.6 Benutzung von Mumble...... 29 4.7 Dienste mit rcconf deaktivieren...... 32

5.1 TeamSpeak 3 Server Query Interface Text Flut...... 43 5.2 Verwendung und Optionen des TeamSpeak 3 Server Exploit...... 46 5.3 TeamSpeak 3 Server Query Interface Exploit...... 47 5.4 Als Gast auf dem TeamSpeak 3 Server verbunden...... 47 5.5 Gast mit vollen Administrationsrechten...... 48 5.6 Auswirkung von Spam mit teamspeakrack im TeamSpeak 3-Client... 50 5.7 Murmur Exploit fur¨ einen DoS-Angriff: Kommandozeile und Mumble- Client vor dem Angriff...... 52 5.8 Murmur Exploit fur¨ einen DoS-Angriff: Kommandozeile und Mumble- Client nach dem Angriff...... 52

Marcel Graef & Marco Franke 59 Tabellenverzeichnis

Tabellenverzeichnis

2.1 Ubersicht¨ uber¨ die genutzten Standard-Ports von TeamSpeak 3 zu den jeweiligen Diensten...... 3 2.2 Ubersicht¨ uber¨ die genutzten Standard-Ports von Mumble/Murmur zu den jeweiligen Diensten...... 4

3.1 M¨ogliche Verletzungen bzw. Folgen, die sich aus den Bedrohungen durch Verursacher und deren Ziele ergeben (Vgl. [Bad10, S.486])...... 19 3.2 M¨ogliche Folgen die sich durch Ausnutzung einer Schwachstelle ergeben k¨onnen...... 21

60 Marcel Graef & Marco Franke Abkurzungsverzeichnis¨

Abkurzungsverzeichnis¨

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

Marcel Graef & Marco Franke 61 Abkurzungsverzeichnis¨

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 Marcel Graef & Marco Franke Eigenst¨andigkeitserkl¨arung

Die vorliegende Arbeit wurde von uns mit gr¨oßter Sorgfalt selbst¨andig ohne Benutzung anderer als den angegebenen Quellen erstellt. Textstellen, die w¨ortlich oder sinngem¨aß ubernommen¨ wurden, sind als solche kenntlich gemacht.

Marco Franke Marcel Graef Leipzig, den 24. Februar 2012

Marcel Graef & Marco Franke 63