Mumble/Murmur und Teamspeak - Sicherheitsanalyse, Maßnahmen und Angriffsszenarien

Transkript

1 Hochschule für Technik, Wirtschaft und Kultur Leipzig Fakultät Informatik, Mathematik und Naturwissenschaften Projektarbeit Mumble/Murmur und Teamspeak - Sicherheitsanalyse, Maßnahmen und Angriffsszenarien Autoren: Studiengang: Marcel Graef Marco Franke Medieninformatik Master Lehrveranstaltung: IT-Sicherheit (Aufbaukurs) WS 2012/13 Verantwortlicher Professor: Prof. Dr. rer. nat. Uwe Petermann

2

3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung 1 2 Vergleich von Mumble/Mumur und TeamSpeak Anwendungsgebiete Funktionsweise und Protokolle Das Channel- und Rechtesystem Authentifizierung und Verwaltung der Clients Sprachcodecs CELP Speex CELT Opus Unterstützte Betriebssysteme Lizenzmodelle Weitere Besonderheiten Sicherheitsanalyse und Ermittlung von Schwachstellen Anforderungen und Schutzziele an Sprachkonferenzsysteme Verfügbarkeit Vertraulichkeit Verbindlichkeit Weitere Anforderungen Typische Angriffsarten Computervirus Wurm Trojaner Exploit Backdoor Rootkit Denial of Service Spoofing Sniffing Marcel Graef & Marco Franke i

4 Inhaltsverzeichnis Port Scanning Brute-Force-Angriff Man-in-the-middle-Angriff Phishing Hijacking Bedrohungen der Sprachkonferenzsysteme Mögliche Angriffsziele Verursacher Verletzung der Schutzziele Ermittlung der Schwachstellen Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Aufbau und Beschreibung der Untersuchungsumgebung Installation und Inbetriebnahme der Spachkonferenzsoftware TeamSpeak 3-Server TeamSpeak 3-Client Murmur-Server Clients Mumble Sicherheitsmaßnahmen Spachkonferenzsoftware Konfiguration der Server Sicherheitsrelevante Einstellungen des Betriebssystems Router und lokale Firewall Nutzerverwaltung Mensch als Schwachstelle Demonstration von Angriffsszenarien Betrachtung des TeamSpeak 3-Server Query Interface Aufbau des Testprogramm Untersuchung der Anti-Flood-Protection Brute-Force-Angriff auf das Query Interface TeamSpeak 3-Server Query Interface Exploit Funktionsweise von teamspeakrack Einrichten einer Hintertür Null Pointer Dereferenzierung Server mit Textnachrichten fluten Weitere Möglichkeiten von teamspeakrack Murmur Exploit für einen DoS-Angriff Resümee und Ausblick 54 ii Marcel Graef & Marco Franke

5 Inhaltsverzeichnis Literaturverzeichnis 56 Abbildungsverzeichnis 59 Tabellenverzeichnis 60 Abkürzungsverzeichnis 61 Eigenständigkeitserklärung 63 Marcel Graef & Marco Franke iii

6

7 1 Einleitung Die Nutzung von Sprachkommunikationsdiensten hat im letzten Jahrzehnt drastisch zugenommen. Es gibt bereits zahlreiche Programme, die Sprachkonferenzen ermöglichen - beispielsweise TeamSpeak, Mumble/Murmur, Skype oder Ventrilo. Ein Grund für diese Entwicklung ist der Ausbau von DSL-Verbindungen sowie der Leitungskapazität im Wide Area Network (WAN). Aber auch die Qualität der Sprachübertragung von Sprachkonferenzsystemen über IP-Netzwerke hat deutlich zugenommen. In dieser Arbeit werden zwei ausgewählte Sprachkonferenzsysteme untersucht. Dies ist zum Einen das proprietäre TeamSpeak 3 und das quelloffene Mumble/Murmur. Die Ähnlichkeiten und Unterschiede werden im Kapitel 2 aufgezeigt. Dabei wird neben den grundlegenden technischen Details, Funktionsweisen und verwendeten Codecs auf die Lizenzmodelle eingegangen. Letzteres spielt gerade für Unternehmen eine wichtige Rolle. Neben den technischen Eigenschaften der Sprachkonferenzsysteme ist vor allem die Sicherheit von großem Interesse. Um diese in Kapitel 3 zu analysieren, werden in Abschnitt 3.1 die Anforderungen und Schutzziele von Nutzern der Sprachkonferenzdienste aufgezeigt. Danach wird in Abschnitt 3.2 eine Übersicht typischer Angriffsarten gegeben. Mit Hilfe dieser Angriffsarten können Angreifer Angriffsziele erreichen und stellen somit eine Bedrohung für das Sprachkonferenzsystem dar. Diese werden in Abschnitt 3.3 analysiert und klassifiziert. Durch diese systematische Betrachtung ist es möglich, Schwachstellen von Sprachkonferenzsystemen zu identifizieren. Aufbauend auf diesen Erkenntnissen wird in Kapitel 4 eine Untersuchungsumgebung aufgebaut und Maßnahmen zur Erhöhung der Sicherheit betrachtet und umgesetzt. Mit Hilfe dieser Untersuchungsumgebung wird in Kapitel 5 aufgezeigt, dass die Sicherheit durch Sicherheitsmaßnahmen erhöht werden kann, aber durch kleine Fehler schnell beträchtliche Sicherheitsrisiken entstehen können. Marcel Graef & Marco Franke 1

8 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 Mumble/Murmur vorgestellt. Dabei wird auf den grundlegenden Aufbau, funktionale Eigenschaften und vor allem auf die technischen Details wie Authentisierung, verwendete Codecs, Protokolle und Formate der Sprachkonferenzsoftware eingegangen. Auch werden die Lizenzmodelle von TeamSpeak 3 und Mumble/Murmur gegenübergestellt, da diese eine wesentliche Rolle für Einrichtungen, Institutionen und Privatpersonen darstellen. 2.1 Anwendungsgebiete Das Hauptziel von TeamSpeak 3 als auch Mumble/Murmur ist es, einen Sprachkonferenzdienst bereit zu stellen, welcher eine möglichst niedrige Latenzzeit besitzt und dabei trotzdem eine störungsfreie und klare Audioqualität bietet. Aber auch die Datenrate soll möglichst gering (<25 kbit/s) gehalten werden. Gerade durch Erfüllung dieser Ziele wird die Software vor allem zur Kommunikation in Verbindung mit Online-Computerspielen verwendet. Aber auch in Netzwerken und Systemen mit beschränkten Ressourcen wird TeamSpeak 3 oder Mumble/Murmur eingesetzt. [TSo12g], [MuM12a] 2.2 Funktionsweise und Protokolle Der Aufbau einer Kommunikationsverbindung wird mit einem klassischen Client-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

9 2.2 Funktionsweise und Protokolle sich auf einen Server verbindet, belegt einen so genannten Slot. Die Anzahl der Clients, die sich mit einem Server verbinden können, ist damit auf die Anzahl der verfügbaren Slots beschränkt. Mit dem Server verbunden, können sich die Clients gegenseitig sehen und untereinander kommunizieren. Dabei gibt es die Möglichkeit zur Sprach- oder Textkommunikation. [TSo12g], [MuM12c] Abbildung 2.1: Schematische Darstellung des Client-Server-Modells von TeamSpeak 3 und Mumble/Murmur Für den Verbindungsaufbau und zur Steuerung zwischen Client und Server verwenden beide Anwendungen das verbindungsorientierte Transmission Control Protocol (TCP), dies wird als Kontrollkanal bezeichnet. Für die Sprachübertragung wird das User User Datagram Protocol (UDP) verwendet, da dies die Datenübertragung nicht sichert und zu geringeren Verzögerungen führt. Die Nutzung und Standard Ports dazu sind den Tabellen 2.1 und 2.2 zu zusammengefasst. TeamSpeak 3 Dienst Nutzung Standard-Port Sprachübertragung TeamSpeak 3 Client 9987 UDP TCP Query telnet ip port TCP Tabelle 2.1: Übersicht über die genutzten Standard-Ports von TeamSpeak 3 zu den jeweiligen Diensten. Als IP-Telefonie-Protokoll verwendet TeamSpeak 3 das Softwareeigene, nicht offen Marcel Graef & Marco Franke 3

10 2 Vergleich von Mumble/Mumur und TeamSpeak 3 spezifizierte, TeamSpeak-Protokoll. Aus diesem Grund kann keine Aussage über die Verschlüsselung der Daten gemacht werden. Das TeamSpeak-Protokoll ist zu keinem anderen freien Protokoll wie SIP, H.323 und IAX kompatibel. Es existiert aber eine quelloffene Protokoll Alternative namens soliloque-server, welches kompatibel zum TeamSpeak-Protokoll ist. Das Mumble-Protokoll ist ebenfalls mit keinem anderen Protokoll kompatibel, aber offen spezifiziert und damit für jeden einsehbar. [Cam10], [Nat12a] Mumble/Mumur Dienst Nutzung Standart-Port Sprachübertragung Mumble UDP Steuerkanal Mumble TCP Tabelle 2.2: Übersicht über die genutzten Standard-Ports von Mumble/Murmur zu den jeweiligen Diensten. Für die Verschlüsselung des Sprachkanals (UDP voice channel) wird der Advanced Encryption Standard (AES) mit einer Schlüssellänge von 128 Bits im Offset Codebook Mode (OCB) verwendet (OCB-AES128). Die Verschlüsselung des Steuerkanal (TCP control channel) ist durch den Einsatz des Verschlüsselungsprotokolls Transport Layer Security (TLS), AES mit einer Schlüssellänge von 256 Bits und dem Secure Hash Algorithm (SHA) gekennzeichnet (TLSv1-AES256-SHA). [SH10], [TSo12c], [Cam10] 2.3 Das Channel- und Rechtesystem In der Regel ist es nicht erwünscht, dass alle Clients, welche auf einen Server verbunden sind, mit einander kommunizieren. Um nicht für jede Konferenz einen eigenen Server verwenden zu müssen, gibt es die Möglichkeit, Bereiche zu erstellen, in denen sich die Konferenzteilnehmer zusammen schließen können. Diese Bereiche werden als Channel bezeichnet. Jeder Client kann sich beliebig einem dieser Channel anschließen und ausschließlich mit den darin befindlichen Clients kommunizieren. Auch ist der Wechsel zwischen verschiedenen Channels jederzeit möglich. Die Channels können auch in einander verschachtelt werden, woraus eine Hierarchie entsteht. Weiterhin kann man zwischen öffentlichen und passwortgeschützten Channels unterscheiden. Ein weiterer 4 Marcel Graef & Marco Franke

11 2.4 Authentifizierung und Verwaltung der Clients wichtiger Aspekt sind die komplexen Rechtesysteme, welche sich in TeamSpeak 3 und Mumble/Murmur stark ähneln. Die Rechtevergabe wird dabei über Rechtegruppen geregelt. Das heißt, die Rechte jedes Nutzers ergeben sich aus der Rechtegruppe, welcher er zugeordnet ist. Jede Gruppe besitzt dabei einen Namen und eine Identifikationsnummer sowie die Rechte, die der jeweiligen Gruppe eingeräumt werden. Standardmäßig sind die drei Gruppen Serveradmin, Normal und Gast vorhanden. Bei TeamSpeak 3 wird zusätzlich noch zwischen Server- und Channelgruppen unterschieden, wodurch es möglich ist Rechtegruppen zu erstellen, welche den Gültigkeitsbereich auf bestimmte Channel beschränken. Mit Hilfe dieser Zugriffssteuerung durch die Rechtesysteme können die Server auf verschiedene Szenarien angepasst werden. Denkbar ist beispielsweise die Konfiguration für ein virtuelles Tutorium. Dafür wird eine Gruppe für die Tutoren erstellt, welche das Recht haben zu Sprechen und eine Gruppe für die Teilnehmer, welche nur zuhören dürfen. Zusätzlich können die Tutoren einzelnen Teilnehmern das Recht zum sprechen geben oder wieder entziehen. Der Wunsch eines Teilnehmers zu Sprechen kann dabei über den Channelchat erfolgen. [TSo12e], [MuM12b] 2.4 Authentifizierung und Verwaltung der Clients Bei TeamSpeak 3 und Mumble/Murmur authentifiziert sich ein Client nicht über einen klassischen Login (bestehend aus Name und Passwort) auf einem Server. Bei einem TeamSpeak 3 Server geschieht dies durch eine so genannte Identität. Diese ist durch eine eindeutige ID beschrieben. Bei Mumble/Murmur erfolgt dies über Zertifikate. Dadurch ist es für den Client möglich, sich an einem Server zu verschiedenen Zeitpunkten mit unterschiedlichen Usernamen einzuloggen. Ein Client hat die Möglichkeit, mehrere dieser Identitäten bzw. Zertifikate anzulegen. Zusätzlich kann der Zugriff auf einen Server durch ein Serverpasswort geschützt werden, wenn beispielsweise keine Registrierung erwünscht ist. Die Informationen für registrierte Clients und deren Gruppenzugehörigkeiten werden auf dem TeamSpeak 3 Server bzw. Murmur in einer Datenbank gespeichert. Dabei ist es möglich, eine SQLite- oder MySQL-Datenbank zu verwenden. Die Verwaltung der Marcel Graef & Marco Franke 5

12 2 Vergleich von Mumble/Mumur und TeamSpeak 3 Datenbank kann serverseitig direkt vorgenommen werden. Mit den benötigten Rechten können bei TeamSpeak 3 und Murmur Einstellungen auch über die Client-Oberfläche vorgenommen werden. Zusätzlich bietet der TeamSpeak 3 Server einen Telnet-basierten Zugang zur Administration (bezeichnet als TCPQuery). [TSo12f], [Nat12a] 2.5 Sprachcodecs Ein weiterer wichtiger Aspekt in Bezug auf ressourcenschonende Datenübertragung sind die verwendeten Sprachcodecs. Auch in diesem Punkt findet man bei TeamSpeak 3 und Mumble/Murmur Parallelen. So verwenden beide Anwendungen die Sprachcodecs Speex und Constrained-Energy Lapped Transform (CELT). In älteren Versionen von TeamSpeak 3 wurden die Sprachcodecs Code-Excited Linear Prediction (CELP) und Global System for Mobile Communications (GSM) verwendet, welche aber in der aktuellen Version nicht mehr zu finden sind. Bei Mumble/Murmur findet man zusätzlich den Sprachcodec Opus. Eine nähere Betrachtung in diesem Abschnitt wird Aufschluss über Merkmale und Verwendung dieser speziellen Sprachcodecs geben CELP Die grundlegende Technik für die genannten Sprachcodecs lieferte das 1985 veröffentlichte CELP Verfahren. Dies ist ein Segment-orientiertes Codierungsverfahren, welches nach dem Analysis-by-Synthesis (AbS) Prinzip funktioniert. Mit Hilfe des Linear Predictive Coding (LPC) Verfahrens werden die Audiosignale auf ein spezielles, der menschlichen Sprache nachempfundenes Modell abgebildet. Dadurch ist es möglich, die Audiosignale im Vergleich zu Puls-Code-Modulation (PCM) Repräsentation, stark datenreduziert zu speichern bzw. zu übertragen. Daraus resultiert, dass das Verfahren zur Komprimierung von Musik ungeeignet ist. [Bad10, S ] 6 Marcel Graef & Marco Franke

13 2.5 Sprachcodecs Speex Mit dem Sprachcodec Speex wurde 2004 ein Codec veröffentlicht, welcher speziell in der IP-Telefonie eingesetzt wird. Der Datenratenbereich liegt bei 2 bis 44 kbit/s bei einer Abtastrate von bis zu 48 khz. Je nach Abtastrate wird dabei eine Latenzzeit zwischen 20 und 40 ms erreicht. Der Grund für die erreichten Werte ist die Verwendung verschiedener Verfahren und Methoden. Dabei werden die Kompressionsmethoden variable bit rate (VBR) und average bit rate (ABR) verwendet, welche abhängig von den Audiodaten unterschiedliche Bit-raten bei gleich bleibender Qualität erzeugen. Dieser Effekt wird durch die Sprechpausenerkennung Voice Activity Detection (VAD) und den Übertragungsmodus Discontinuous Transmission (DTX) weiter verstärkt. [PHS94] CELT Im Dezember 2007 wurde der CELT (Constrained-Energy Lapped Transform) Sprachcodec veröffentlicht. Dieser Sprachcodec erzielt im Vergleich zum Speex eine geringere Latenz von 5 bis 22,5 ms. Um dies zu erreichen, verwendet er eine höhere und konstante Datenrate von 32 bis 128 kbit/s. Zudem lässt sich durch die höhere Datenrate eine größere Frequenzbandbreite abbilden, wodurch sich dieser Sprachcodec auch zur Übertragung von Musik eignet. Durch ein integriertes Packet Loss Concealment (PLC) Verfahren lassen sich verloren gegangene Daten überbrücken und sind somit für den Empfänger kaum wahrnehmbar. Im Februar 2011 wurde die aktuelle Version veröffentlicht. [PHC08] Opus Im Gegensatz zu TeamSpeak 3 bietet Mumble/Murmur zusätzlich Unterstützung für den im September 2012 veröffentlichten Sprachcodec Opus. Dieser Codec vereint verschiedene Technologien, unter anderen vom CELT Sprachcodec. Er deckt einen großen Datenratenbereich von 6 bis 510 kbit/s mit einer maximalen Abtastrate von bis zu 48 khz, ab. Damit eignet er sich nicht nur für Sprache, sondern auch für Musik. Durch die Verwendung der Kompressionsmethoden constant bit-rat (CBR) und VBR unterstützt er konstante als auch variable Bit-raten. Auch wird das PLC Verfahren Marcel Graef & Marco Franke 7

14 2 Vergleich von Mumble/Mumur und TeamSpeak 3 zur Fehlerüberbrückung verloren gegangener Datenpakete verwendet. Neben Stereo unterstützt er bis zu 255 Kanäle. Anhand drei so genannter Modi kann der Codec je nach Verwendung eingestellt werden. [PHO11] 2.6 Unterstützte Betriebssysteme Neben technischen Details der Sprachkonferenzsoftware sind auch die unterstützten Plattformen von Interesse. TeamSpeak 3 unterstützt Windows, Mac OS X und Linux für den Einsatz von Server oder Client. Für das Betriebssystem FreeBSD steht ausschließlich ein TeamSpeak 3 Server zur Verfügung. Der TeamSpeak 3 Client unterstützt des Weiteren Smartphones mit den Betriebssystemen ios oder Android. [TSo12b] Mumble/Murmur steht ebenfalls für Windows, Mac OS X und Linux zur Verfügung. Der Client Mumble unterstützt ios und Android. Es steht auch eine Version für das von Nokia entwickelte Betriebsystem Maemo zur Verfügung. [MuM12d] 2.7 Lizenzmodelle Für den Betrieb eines Sprachserver sind die angebotenen Lizenzmodelle für Privatpersonen, Institute sowie besonders für Unternehmen von Interesse. Bei TeamSpeak 3 wird zwischen fünf Lizenzmodellen unterschieden. Die Non-Profit- Lizenz (NPL) steht zum Einen für nicht registrierte Nutzer zur Verfügung. Sie erlaubt die Verwendung eines Servers mit maximal 32 Slots für nicht kommerzielle Zwecke. Registrierte Nutzer können bis zu 10 Server mit maximal 512 Slots betreiben. Für gewerbliche Unternehmen, welche TeamSpeak 3 Server vermieten, wird die gewerbliche Lizenz für Autorisierte TeamSpeak Host Provider (ATHP) verwendet. Bei gewerblichen Unternehmen, welche TeamSpeak 3 innerhalb eines gewerblichen Umfelds nutzen, besteht zusätzlich die Möglichkeit, die jährliche Aktivierungslizenz (AAL) zu verwenden. Möchten gewerbliche Unternehmen mit dem TeamSpeak 3 Software Development Kit (SDK) Software entwickeln, kann die TeamSpeak 3 SDK Lizenz erworben werden. [TSo12d] 8 Marcel Graef & Marco Franke

15 2.8 Weitere Besonderheiten Mumble/Murmur steht zum Vergleich unter General Public License (GPL) Version 2 lizenziert und verfügt damit über keine lizenzrechtlichen Einschränkungen. [Nat12a] 2.8 Weitere Besonderheiten TeamSpeak 3 und Mumble/Murmur bieten gleichermaßen weitere Besonderheiten. So gibt es für das Sprechen die Möglichkeit, zwischen automatischer Sprachaktivierung oder Sprachaktivierung durch Tastendruck (Push-To-Talk) zu wählen. Auch können in beiden Anwendungen Einstellungen für Surround Sound vorgenommen werden. Damit ist es möglich, Konferenzteilnehmer virtuell räumlich anzuordnen, um eine reale Konferenz zu simulieren. Mit Hilfe so genannter Musikbots, welche virtuelle Konferenzteilnehmer darstellen, ist es möglich, Musik in einem Channel abzuspielen. Diese können aber auch verwendet werden, um Gespräche aufzuzeichnen. Die Möglichkeit des Aufzeichnens steht für den TeamSpeak 3 und Mumble-Client zur Verfügung. [Nat12b], [TSo12a] Marcel Graef & Marco Franke 9

16 3 Sicherheitsanalyse und Ermittlung von Schwachstellen 3 Sicherheitsanalyse und Ermittlung von Schwachstellen Um Sicherheitsmaßnahmen für die Sprachkonferenzsysteme TeamSpeak 3 und Mumble/Murmur zu entwickeln, müssen bestehende Schwachstellen erkannt werden. Um Schwachstellen zu erkennen, müssen zunächst in Abschnitt 3.1 Anforderungen an ein Sprachkonferenzsystem und den damit verbundenen Schutzzielen der Nutzer diskutiert werden. Danach wird in Abschnitt 3.2 eine Übersicht typischer Angriffe gegeben. Dies ist wichtig, um Bedrohungen (Abschnitt 3.3) der Sprachkonferenzsysteme zu erkennen und aufzuzeigen. Schließlich können daraus Schwachstellen (Abschnitt 3.4) ermittelt werden. Darauf aufbauend können bei der Konzeption und Realisierung in einer Untersuchungsumgebung in Kapitel 4 geeignete Gegenmaßnahmen abgeleitet und umgesetzt werden. 3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme Sowohl private Nutzer als auch Unternehmen verfolgen bestimmte Schutzziele und Anforderungen. Besonders für Unternehmen sollte der Analyse von Schutzzielen und Anforderungen eine große Beachtung beigemessen werden, da hier die Sicherheitsrisiken schwerwiegende wirtschaftliche Folgen haben können. Die primären Schutzziele sind Verfügbarkeit, Vertraulichkeit, Verbindlichkeit. [BSI04], [Bad10, S ] 10 Marcel Graef & Marco Franke

17 3.1 Anforderungen und Schutzziele an Sprachkonferenzsysteme Verfügbarkeit Mit dem Schutz der Verfügbarkeit wird gewährleistet, dass alle notwendigen Verbindungsund Sprachdaten für den Anwender stets verfügbar sind. In diesem Zusammenhang muss gesichert werden, dass die Funktionsweise der Sprachserver durch Angriffe, aber auch durch Ausfall technischer Geräte (z.b. Stromversorgung) nicht beeinträchtigt werden. [BSI04], [Bad10, S ] Vertraulichkeit Unter der Vertraulichkeit versteht man den Schutz vor der ungewollten Preisgabe von Informationen. Dies ist beispielsweise der Fall, wenn Gespräche von Unbefugten abgehört oder aufgezeichnet werden. Um die Vertraulichkeit durch externe Angriffe nicht zu verletzen, ist es notwendig, die Verbindungs- und Sprachdaten beim Austausch zwischen Server und Client geeignet zu verschlüsseln. Aber auch ungewollte interne Zugriffe auf diese Daten sind zu vermeiden. Das heißt, der Zugriff auf eine Konferenz darf nur von berechtigten Personen erfolgen. [BSI04], [Bad10, S ] Verbindlichkeit Unter Verbindlichkeit werden die Teilaspekte Authentizität, Integrität, Nicht-Abstreit barkeit und Rechtsverbindlichkeit zusammen gefasst. Dabei wird durch technische Maßnahmen versucht, die Echtheit empfangener Daten zu sichern. Als Authentizität wird der Beweis der Echtheit verstanden. Es muss immer für alle Daten die Herkunft eindeutig festgestellt werden können. Aber auch die Korrektheit der angegebenen Herkunft muss stets gesichert sein. So muss Beispielsweise auch sichergestellt werden, dass der Anrufende der ist, der er zu sein vorgibt. Mit dem Schutz der Integrität ist der Schutz vor unbefugter Manipulation von Ver bindungs- und Sprachdaten gemeint. Es muss gesichert sein, dass alle Verbindungsund Sprachdaten unverändert beim Empfänger eintreffen. Aber auch das Erkennen von Manipulationen muss gewährleistet werden. Wenn man zu einem späteren Zeitpunkt gegenüber einem Dritten (z.b. Gericht) be- Marcel Graef & Marco Franke 11

18 3 Sicherheitsanalyse und Ermittlung von Schwachstellen weisen muss, dass Daten gesendet oder empfangen wurden, reicht die Integrität und Authentizität meist nicht aus. Deshalb wird durch die Nicht-Abstreitbarkeit sichergestellt, dass der Versand und Empfang von Daten nicht abgestritten werden kann und somit ist das Ziel der Rechtsverbindlichkeit erfüllt. [BSI04], [Bad10, S ] Weitere Anforderungen Bei der Verwendung von Sprachkonferenzsystemen werden neben den allgemeinen Schutzzielen weitere Anforderungen der Leistungsfähigkeit des System gestellt. Die Anforderungen an ein System können als Quality of Service (QoS) zusammengefasst werden und beinhalten Anforderungen aus Anwender- bzw. technischer Sicht. Eine Anforderung aus Anwendersicht ist die Sprachqualität. Diese kann durch die Wahl eines geeigneten Codecs realisiert werden, aber auch durch technische Probleme (z.b. zu hohe Netzauslastung) oder Angriffe (z.b. Distributed Denial of Service) beeinträchtigt werden. Ebenso ist eine leichte Handhabung und Flexibilität im Einsatz der Sprachkonferenzsysteme von Interesse. Eine Anforderung aus technischer Sicht ist eine geringe Verzögerung (Delay) der Sprachsignale. Damit ist der Zeitverzug zwischen dem Aussprechen beim Sender und der Wiedergabe beim Empfänger gemeint. Des Weiteren ist das Auftreten von Jittern unerwünscht. Diese entstehen, wenn netzbedingt die Übertragungszeiten zwischen verschiedenen Paketen stark abweichen. Ab einer Differenz von etwa 50 ms ist dabei mit Problemen in der Kommunikation zu rechnen. Ein solches Problem kann beispielsweise die Verzerrung des hörbaren Sprachsignals sein. Aus verschiedenen Gründen (z.b. zu hohe Lautstärke der Lautsprecher beim Empfänger) können Rückkopplungen des eigenen Gesprochenen entstehen. In diesem Fall spricht man von unerwünschten Echos. Durch geeignete Verfahren zur Echokompensation muss dem entgegengewirkt werden. Durch Überlastung oder Fehler kann es dazu kommen, dass Pakete verworfen werden. Dieser Paketverlust ist ebenfalls unerwünscht und sollte daher möglichst gering gehalten werden. [Bad10, S ,191], [EE07, S.36-39] 12 Marcel Graef & Marco Franke

19 3.2 Typische Angriffsarten 3.2 Typische Angriffsarten Um Bedrohungen spezifisch von Sprachkonferenzsystemen ermitteln zu können, ist es notwendig, allgemeine Angriffsarten zu kennen. Grundlegend erben Sprachkonferenzsysteme alle Sicherheitsprobleme der IP-Welt und es kommen weitere hinzu Computervirus Ein Computervirus ist eine Befehlsfolge, die sich an ein bestehendes Programm anhängt (Infektion). Wird das infizierte Programm ausgeführt, werden auch die Befehlsfolgen des Computervirus ausgeführt. Zusätzlich sind Computerviren in der Lage, sich selbstständig zu verbreiten, d.h. sich selbst zu kopieren (Reproduktion). Computerviren können Schäden, Fehlfunktionen und Störungen bewirken. Sie werden meist durch Weitergabe infizierter Programme oder Dateien (z.b. als -Anhang) verbreitet. [Bad10, S ] Wurm Im Vergleich zum Computervirus ist ein Wurm ein eigenständiges Programm, welches sich über ein Netzwerk selbstständig verbreiten kann. Aber auch über Wechseldatenträger ist eine Verbreitung möglich. Zur Verbreitung kann ein Wurm beispielsweise ein -Programm verwenden, indem er sich automatisch an alle gespeicherten -Adressen als Anhang versendet. [Bad10, S ] Beispielsweise wurde mit Hilfe eines Instant-Messaging-Dienstes, welcher in der Sprachkonferenzsoftware Skype integriert ist, der Wurm Pykse verbreitet. Pykse führte dazu, dass die infizierte Sprachkonferenzsoftware Skype nicht mehr für eingehende Anrufe erreichbar war Trojaner Trojanische Pferde sind Schadprogramme, welche sich in vermeintlich nützlichen Programmen verbergen. Sie können sich nicht selbst verbreiten und sind somit auf die Marcel Graef & Marco Franke 13

20 3 Sicherheitsanalyse und Ermittlung von Schwachstellen Gutgläubigkeit der Nutzer angewiesen. In den meisten Fällen bauen Trojaner Verbindungen zum Angreifer auf und ermöglichen dadurch das Ausspähen sensibler Daten. Auch Fernsteuerung befallener Systeme kann dadurch ermöglicht werden. Aus dem Bereich von Sprachkonferenzsystemen ist beispielsweise der Trojaner FinSpy zu nennen. Dieser Trojaner ermöglicht unter anderem das Auslesen von Audiodaten, welche durch Lautsprecher wiedergegeben oder von einem Mikrophon erfasst werden. [Bad10, S ] Exploit Bei einem Exploit handelt es sich um das Ausnutzen von Schwachstellen in einer Software oder einem System. Diese Schwachstellen entstehen durch fehlerhafte Mechanismen, welche bei der Entwicklung nicht berücksichtigt wurden. Diese Schwachstellen können mit Hilfe eines speziell auf die fehlerhaften Mechanismen ausgerichteten Programms ausgenutzt werden. Solche Fehler werden in der Regel erst im Live-Betrieb einer Software oder einem System offengelegt und durch Nachbesserungen behoben. An dieser Stelle wird klar, dass zwischen der Offenlegung und Behebung der Schwachstelle eine erhöhte Gefahr für die Betreiber von Sprachkonferenzsystemen besteht. Ein Beispiel und dessen Auswirkungen wird in Kapitel 5 erläutert und demonstriert. [Bad10, S ] Backdoor Als Backdoor bezeichnet man Lücken, welche Angreifern unerwünschten Zugriff auf ein System oder Ressourcen ermöglichen. Im Vergleich zu einem Exploit handelt es sich dabei nicht um fehlerhafte Mechanismen in der Software oder einem System, sondern um eine fehlerhafte Konfiguration. Dies können beispielsweise offene Ports oder eine fehlende Zugriffssicherung sein. Solche können vor allem durch Unwissenheit oder Unachtsamkeit der Nutzer entstehen. Aber auch Würmer, Trojaner oder Exploits können solche Lücken auf einem System einrichten. [Bad10, S ] 14 Marcel Graef & Marco Franke

21 3.2 Typische Angriffsarten Rootkit Ein Rootkit ist eine Sammlung von Dateien und Programmen, welche dem Angreifer ermöglichen, Root-Rechte auf einem Rechner zu erlangen. Es setzt eine Schwachstelle im System voraus und wird in der Regel zusammen mit Exploits verwendet. Auch werden sie verwendet, um andere Schadprogramme vor Nutzern zu verbergen. [Bad10, S ] Denial of Service Bei Denial of Service (DoS) Attacken handelt es sich um Angriffe gegen die Verfügbarkeit von Systemen oder Diensten, welche angeboten werden. Es wird durch Überlastung des Systems oder der Software versucht, die Verfügbarkeit einzuschränken oder komplett außer Kraft zu setzen. Dieser Angriff kann auch von mehreren Systemen gleichzeitig durchgeführt werden. In diesem Fall spricht man von einem Distributed Denial of Service (DDoS) Angriff. Dabei wird durch ständiges Senden von Anfragen versucht, Systeme oder Dienste an ihre Belastungsgrenze zu bringen. Dies kann beispielsweise bei einer TCP-Verbindung durch das ständige Senden von SYN-Paketen erfolgen. Ein SYN-Paket ist ein Paket, in dem das SYN-Bit im Paketkopf (TCP-Header) gesetzt ist. Dieses Paket wird von einem Client an einen Server gesendet, um zu signalisieren, dass eine Verbindung über TCP aufgebaut werden möchte und somit einen Verbindungsaufbau initiiert. Ist eine zu hohe Anzahl von Verbindungsanfragen erreicht, kann der Dienst keine weiteren Verbindungen aufbauen und steht damit nicht mehr oder nur noch eingeschränkt zur Verfügung. [Bad10, S ] Spoofing Unter Spoofing versteht man das Benutzen einer falschen Identität. Dieser Angriff erfolgt durch Vortäuschung falscher Quelladressangaben. Dem kann durch eine gegenseitige Authentifizierung entgegengewirkt werden. Man unterscheidet zwischen IP-, DNS- und URL-Spoofing. Marcel Graef & Marco Franke 15

22 3 Sicherheitsanalyse und Ermittlung von Schwachstellen Bei IP-Spoofing wird in einem IP-Paket die Quell-IP-Adresse ausgetauscht, um somit einen anderen Kommunikationspartner vorzutäuschen. Bei DNS-Spoofing wird die Zuordnung zwischen IP-Adresse und Rechnername verändert. Auch bei einer aufgerufenen Webseite kann die Quell-URL verfälscht werden. In diesem Fall spricht man von URL-Spoofing. [Bad10, S ] Sniffing Als Sniffer bezeichnet man Programme, mit denen der Datenverkehr in Netzwerken empfangen und aufgezeichnet werden kann. Besonders bei unverschlüsselten Daten kann eine Auswertung dieser Daten sensible Informationen preisgeben. Beispielsweise stellt die Software Wireshark ein sehr umfangreiches Werkzeug für diesen Zweck und darüber hinaus dar Port Scanning Mit einem Portscan wird gezielt nach offenen Ports an einem Rechner gesucht, um Schwachstellen für Angriffe ausfindig zu machen. Dabei wird lediglich geschaut, ob bestimmte Dienste auf dem System laufen, bei denen bekannte Schwachstellen vorliegen. [Bad10, S ] Brute-Force-Angriff Der Brute-Force-Angriff richtet sich an Schnittstellen, an denen sich Nutzer mit ihren Logindaten (Benutzername und Passwort) bei einem Dienst oder System einloggen. Die Logindaten sind gültig, wenn sie einem Benutzerkonto zugeordnet werden können. Bei Angabe gültiger Logindaten wird der Zugriff auf den Dienst oder das System gewährt. Der Angreifer versucht, unter Verwendung eines speziellen Programms gültige Logindaten zu finden. Das Programm sucht mit Hilfe einer erschöpfenden Suche so lange nach Kombinationen von Logindaten, bis es eine gültige Kombination findet. Aufgrund der vielen Kombinationsmöglichkeiten ist es mit dieser Methode oft nicht möglich, den 16 Marcel Graef & Marco Franke

23 3.2 Typische Angriffsarten Angriff in einem realistischen Zeitfenster durchzuführen. Deshalb wird in den meisten Fällen der Suchraum verkleinert. Man beschränkt sich beispielsweise auf einen bestimmten Benutzernamen und versucht, dazu das passende Passwort zu finden. Zusätzlich kann der Suchraum durch so genannte Passwortlisten weiter verkleinert werden. In guten Passwortlisten sind in der Regel mehrere hunderttausend bekannter und beliebter Passwörter zusammengestellt. Ein bekannter Vertreter eines Programms zur Durchführung von Brute-Force-Angriffen ist THC-Hydra. Hauptmerkmal dieses Programms ist die hohe Anzahl unterstützter Protokolle, wie beispielsweise HTTP, SSH, POP3 oder telnet. Auch bietet das Programm Unterstützung für Brute-Force-Angriffe gegen die alte Version TeamSpeak Man-in-the-middle-Angriff Der Man-in-the-middle (MITM)-Angriff stellt einen Angriff dar, bei dem der Angreifer in einem Netzwerk zwischen den Kommunikationspartnern steht. Dabei liest der Angreifer gezielt Datenpakete der Kommunikation mit, manipuliert diese oder tauscht sie gänzlich aus Phishing Phishing bezeichnet alle Vorgänge, bei denen sensible Daten von Nutzern erschlichen werden. Zumeist handelt es sich dabei um das Ausnutzen der Gutgläubigkeit der Opfer, indem falsche Identitäten vorgetäuscht werden. Beispielsweise sind das gefälschte Login Bereiche, in denen die vom Nutzer eingegebenen Daten erschlichen werden. [Bad10, S ] Hijacking Als Hijacking bezeichnet man die Übernahme von Domänen oder Benutzerkonten. Nach einer erfolgreichen Übernahme der Identität muss diese nicht mehr vorgetäuscht werden. Ab diesem Zeitpunkt können alle Anfragen an diese Identität umgeleitet werden, um Angriffe an weitere Kommunikationspartner durchzuführen. Zur Übernahme werden in der Regel Phishing, Brute-Force- oder MITM-Angriffe verwendet. [Bad10, S ] Marcel Graef & Marco Franke 17

24 3 Sicherheitsanalyse und Ermittlung von Schwachstellen 3.3 Bedrohungen der Sprachkonferenzsysteme Um ermitteln zu können, welche Auswirkungen Bedrohungen für ein Sprachkonferenzsystem haben, muss analysiert werden, welche Ziele und Verursacher einer Bedrohung existieren. Danach kann zusammengefasst werden, welche Schutzziele als Folge einer Bedrohung, verletzt werden können. [Bad10, S ] Mögliche Angriffsziele Die Ziele der Angreifer können in vier Kategorien zusammen gefasst werden. Dazu gehört das Lauschen bzw. Abhören von Gesprächen, in denen sensible Informationen ausgetauscht werden und somit an unbefugte Dritte gelangen können. Weiterhin ist das Abfangen und Modifizieren von Daten ein Ziel. Dieses betrifft weniger die Sprachdaten einer Konferenz selbst; mehr wird dabei auf Daten, welche zur Steuerung oder Administration der Sprachkonferenzsysteme selbst benötigt werden, abgezielt. Da bei TeamSpeak 3 und Mumble/Murmur auch die Möglichkeit besteht, textbasiert zu kommunizieren, können auch diese Daten von Interesse sein, abgefangen oder modifiziert zu werden. Aber auch die bloße Beeinträchtigung der Funktionsweise des Dienstes ist ein beliebter Angriffspunkt. Gerade bei Unternehmen, welche auf die Kommunikation über das Sprachkonferenzsystem angewiesen sind, ist diese Art der Sabotage problematisch. Diese können beispielsweise die Kommunikation mit Kunden oder die Kommunikation bei internen Geschäftsprozessen sein. Auch der Missbrauch der Dienste ist ein denkbares Ziel. So können beispielsweise die Ressourcen der Sprachkonferenzsysteme für eigene Gespräche missbraucht werden. [Bad10, S ] Verursacher Die Verursacher einer Bedrohung können ebenfalls in vier Gruppen eingeteilt werden. Die naheliegendste Gruppe sind externe Angreifer. Sie haben im allgemeinen keine Verbindung zum Sprachkonferenzsystem selbst und müssen sich daher erst Zugriff zum System verschaffen. Die nächste Gruppe sind Schadprogramme (Viren, Würmer, Trojaner, Backdoors,...). Sie gehen zwar von einem externen Angreifer aus, aber stellen dennoch aufgrund ihres autonomen Handelns eine eigene Gruppe von Verursachern von Bedrohungen dar. Die beiden letzten Gruppen sind interne und externe Nutzer. Diese 18 Marcel Graef & Marco Franke

25 3.3 Bedrohungen der Sprachkonferenzsysteme beiden Gruppen besitzen von Vornherein Zugriff auf das Sprachkonferenzsystem und können beispielsweise durch zu viele Rechte böswillige Ziele verfolgen. Aber auch durch Fehlverhalten können unbeabsichtigte Schutzziele verletzt werden und stellen damit eine potentielle Bedrohung dar. [Bad10, S ] Verletzung der Schutzziele Mit den unter Abschnitt 3.2 erläuterten Angriffsarten können Versursacher ihre Angriffsziele erreichen. Jeder Verursacher (siehe Abschnitt 3.3.2) stellt dabei in Verbindung mit einem Angriffsziel (siehe Abschnitt 3.3.1) eine Bedrohung dar, welche Schutzziele verletzen kann. Diese sind in Tabelle 3.1 tabellarisch zusammengefasst. Verursacher Lauschangriff Abfangen und Dienstbe- Dienstmiss- Modifikation einträchtigung brauch Externe Integrität Integrität Integrität Angreifer Vertraulichkeit Authentizität Verfügbarkeit Authentizität Verfügbarkeit Verfügbarkeit Schad- Integrität Integrität Integrität Vertraulichkeit programme Verfügbarkeit Verfügbarkeit Verfügbarkeit Interne Integrität Integrität Integrität Benutzer Vertraulichkeit Authentizität Authentizität Authentizität Verfügbarkeit Verfügbarkeit Verfügbarkeit Externe Integrität Integrität Integrität Benutzer Vertraulichkeit Authentizität Authentizität Authentizität Verfügbarkeit Verfügbarkeit Verfügbarkeit Tabelle 3.1: Mögliche Verletzungen bzw. Folgen, die sich aus den Bedrohungen durch Verursacher und deren Ziele ergeben (Vgl. [Bad10, S.486]) Mit Hilfe dieser Zusammenstellung ist eine mehrseitige Betrachtung potenzieller Bedrohungen möglich und hilft dabei, Schwachstellen zu erkennen. Dabei wird deutlich, dass neben externen Angreifern auch interne Nutzer kritisch betrachtet werden müssen. Diese besitzen bereits Zugriff auf das interne Netzwerk oder das Sprachkonferenzsytem selbst und können Angriffsziele verfolgen. Beispielsweise ist es denkbar, dass interne Benutzer Daten abfangen und modifizieren. Dabei wird gleichzeitig die Integrität und Authentizität verletzt. Werden die Daten abgefangen und nicht mehr an das System gesendet, so ist die Verfügbarkeit verletzt. Auch ein Missbrauch des Sprachkonferenzdienstes ist denkbar. Beispielsweise durch das Ausnutzen zugesicherter Rechte, indem unbefugten Marcel Graef & Marco Franke 19

26 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 geschützt werden muss, sondern auch die interne Struktur (z.b. Netzwerk, Rechtevergabe) betrachtet werden muss. [Bad10, S ] 3.4 Ermittlung der Schwachstellen Anhand der bisherigen Vorüberlegungen von Kapitel 3 können jetzt verschiedene Szenarien abgeleitet und daraus resultierende Schwachstellen erarbeitet werden. Als erste Schwachstelle ist die Sprachkonferenzsoftware selbst zu nennen. Dabei obliegen sicherheitsrelevante Maßnahmen und die sichere Implementation dem Herausgeber der Software. Dazu gehört auch die Verwendung geeigneter Protokolle, welche daher ebenfalls als Schwachstelle anzusehen sind und vom Nutzer als solche betrachtet werden muss. Eine weitere Schwachstelle ist die Konfiguration der Software. Dabei ist der Herausgeber der Software zur Bereitstellung geeigneter Konfigurationsmöglichkeiten verpflichtet. Auf der anderen Seite muss der Nutzer eine für den Anwendungszweck geeignete Konfiguration vornehmen. Neben der Konferenzsoftware ist das verwendete Betriebssystem eine weitere Schwachstelle. Dies ist vom Nutzer geeignet zu wählen und zu konfigurieren. Damit ist besonders die durchdachte Vergabe von Rechten zu nennen. Um Zugriff auf das Netzwerk und damit auf die Sprachkonferenzsoftware zu ermöglichen, muss die Anbindung an das Netzwerk kritisch betrachtet werden. Daraus ergeben sich der Router und die Firewall als weitere Schwachstelle. Die wohl kritischste Schwachstelle stellen die Benutzer der Sprachkonferenzsysteme dar. Es ist daher unumgänglich, auch diese in Abschnitt 4.3 detailliert zu betrachten. In Tabelle 3.1 sind alle aufgezeigten Schwachstellen tabellarisch mit denkbaren Angriffsarten und den daraus resultierenden Folgen, im Sinne der Verletzung von Schutzzielen, dargestellt. 20 Marcel Graef & Marco Franke

27 3.4 Ermittlung der Schwachstellen Schwachstelle Angriffsart Folge Exploit Verletzung der Sprachkonferenzsoftware Brute-Force Vertraulichkeit, Verfügbarkeit, Authentizität Einräumen Verletzung der Konfiguration zu vieler Vertraulichkeit, Rechte Verfügbarkeit, Authentizität Computervirus Verletzung der Betriebssystem Wurm Vertraulichkeit, Trojaner Verfügbarkeit, Rootkit Authentizität Backdoor Verletzung der Router und Firewall (D)DoS Vertraulichkeit, Portscanning Verfügbarkeit, Authentizität Phishing Verletzung der Benutzer Vertraulichkeit, Verfügbarkeit, Authentizität Tabelle 3.2: Mögliche Folgen die sich durch Ausnutzung einer Schwachstelle ergeben können. Marcel Graef & Marco Franke 21

28 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 für Mumble/Murmur und für TeamSpeak 3 in Abschnitt 4.2 beschrieben, wie die Installation durchzuführen ist und welche Basiskonfiguration für den Betrieb notwendig sind. 4.1 Aufbau und Beschreibung der Untersuchungsumgebung Wie schon angedeutet, ist es für die Untersuchung von Netzwerkmanagementlösungen nötig, eine Untersuchungsumgebung bestehend aus verschiedenen Rechnern aufzubauen. In Abbildung 4.1 sind die involvierten Rechner dargestellt. Der PC 1 fungiert im Weiteren als TeamSpeak 3- und Murmur- Server. Der Router mit der Internet Protokoll (IP)-Adresse spielt eine besondere Rolle, da hier die Firewall und die Portweiterleitung entsprechend konfiguriert werden müssen. PC 2 spiegelt hier einen Rechner im internen Netzwerk wider. Das grün und blau hinterlegte Netzwerk der Abbildung 4.1 ist über eine Standard Digital Subscriber Line (DSL)-Verbindung an das Internet angebunden und verfügt daher über keine statische IP-Adresse. Damit PC 3 den Sprachdienst, der von PC 1 angeboten wird, 22 Marcel Graef & Marco Franke

29 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 über ein dynamisches Domain-Name-System (DynDNS) ein Fully Qualified Domain Name (FQDN) zugewiesen. Diese Einstellung wird am Router vorgenommen. 4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware TeamSpeak 3-Server Der TeamSpeak 3-Server kann für verschiedene Betriebssysteme auf der offiziellen Website unter der Rubrik Download heruntergeladen werden. Hier wird ein Linux Server amd installiert. Der Quellcode von TeamSpeak 3 ist nicht frei zugänglich, weshalb Sicherheitslücken wesentlich langsamer offiziell aufgedeckt werden. Daher darf der TeamSpeak 3-Server niemals als Root gestartet werden. Falls der Angreifer eine Sicherheitslücke in TeamSpeak 3 findet, hat er möglicherweise root-rechte. Das ist fatal. Es wird daher ein Benutzer teamspeak mit sudo adduser teamspeak angelegt. Der Benutzer wird im Terminal mit su teamspeak gewechselt. Das heruntergeladene Paket wird nun entpackt und mit./ts3server_startscript.sh Marcel Graef & Marco Franke 23

30 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 für den Sprachkanal im Router freigegeben werden TeamSpeak 3-Client Die Installation des TeamSpeak 3 Clients gestaltet sich ähnlich. Da der TeamSpeak 3 Client eine proprietäre Software ist, kann sie nicht über die Paketverwaltung installiert werden, sondern muss von der offiziellen Website unter der Rubrik Download heruntergeladen werden. 24 Marcel Graef & Marco Franke

31 4.2 Installation und Inbetriebnahme der Spachkonferenzsoftware (a) Festlegung Nicknamen (b) Mikrofoneinstellungen (c) Mikrofontest (d) Tastenkombination (e) Einstellungen Sprachausgabe (f) Channel hinzufügen Abbildung 4.3: Installation und Einrichtung des TeamSpeak 3 Clients Hier wird der Linux Client amd verwendet. Das Installationsscript TeamSpeak3- Client-linux_amd run wird gestartet und es muss den Installationsschritten, die teilweise in Abbildung 4.3 visualisiert sind, gefolgt werden. Beim Installionsprozess wird ein Ordner mit den Konfigurations- und ausführbaren Dateien erstellt. Marcel Graef & Marco Franke 25

32 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Der Client kann durch Ausführung des darin enthaltenen Shell-Script ts3client_runscript.sh gestartet werden. (a) Verbindung mit Server herstellen (b) Teamspeak Client Abbildung 4.4: Teamspeak 3 Client: Verbindung zu einem Server herstellen Mit dem TeamSpeak 3 Client kann über das Menü Verbindungen und den Eintrag Verbinden eine neue Verbindung erstellt werden. In dem Beispiel, welches in Abbildung 4.4 dargestellt ist, wird eine Verbindung als serveradmin zum Server mit der IP- Adresse hergestellt. Um Administrationsrechte zu erlangen, muss der beim ersten Start generierte Berechtigungsschlüssel (Token, siehe Abbildung 4.2) noch angegeben werden Murmur-Server Der Sprachkommunikationsserver Murmur wird auf dem PC 1 (siehe Abbildung 4.1) installiert. Auf dem PC 1 ist Ubuntu (precise) in der 64-Bit Version mit dem Kernel Linux generic installiert. Murmur ist in den Paketquellen der genannten Ubuntu-Version enthalten und kann mit apt-get install murmur oder apt-get install mumble-server und sudo dpkg-reconfigure mumble-server auf dem PC installiert werden. Auch viele andere Distributionen enthalten in den Standardquellen die benötigten Pakete. Falls dies nicht der Fall ist, können die Quelldateien auch unter heruntergeladen und kompiliert werden. Die grundsätzlichen Einstellungen des Murmur-Servers werden in der Konfigurationsda- 26 Marcel Graef & Marco Franke

33 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ält. 1 # Password to join server 2 serverpassword=password Listing 4.1: Änderung des Murmur-Serverpassworts in mumble-server.ini Der Server wird mit murmurd gestartet. Neu starten lässt sich der Server mit sudo /etc/init.d/mumble-server restart Des Weiteren müssen die Ports TCP für den Steuerkanal und UDP für den Sprachkanal im Router freigegeben werden. Damit ist nach wenigen Einstellungen der Server bereit für die Kommunikation. Für den Betrieb eines Murmur-Servers ist es empfehlenswert, die Nutzer- und Gruppenrechte zu überprüfen. Einige Hinweise werden hierzu in Abschnitt gegeben Clients Mumble Das Paket mumble ist in den Paketquellen der meisten Linux-Distributionen enthalten und kann mit sudo apt-get install mumble installiert werden. Beim ersten Start sind diverse Grundeinstellungen über die Audioein- und -ausgabe vorzunehmen. Ein Ablauf der vorzunehmenden Konfiguration ist in Abbildung 4.5 aufgezeigt. Die Spacheinstellungen müssen mit großer Sorgfalt durchgeführt werden, da hiervon der Benutzungskomfort abhängt. Des Weiteren ist es auch möglich, sich mit Mumble per Zertifikat bei dem Server zu authentifizieren. Der Vorteil ist dabei, dass nicht mit Passwörtern gearbeitet werden muss. Die Erstellung bzw. der Import eines solchen Zertifikates kann am Ende der Konfiguration vorgenommen werden. Marcel Graef & Marco Franke 27

34 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen (a) Audio-Einstellungen (b) Audio-Einstellungen (c) Spacheinstellungen (d) Spacheinstellungen (e) Qualitätseinstellungen (f) Positionsabhängiges Audio Abbildung 4.5: Schritte der Installation und Einrichtung von Mumble Nun sind alle Einstellungen bezüglich Mumble für einen reibungslosen Betrieb vorgenommen worden und es kann eine Verbindung zum Server ( ) 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

35 4.3 Sicherheitsmaßnahmen (a) Client mit dem Server verbinden (b) rechts im Bild: Der Channelviewer zeigt die Nutzeraccounts, die mit dem Server verbunden sind; links im Bild: Nachrichtenverlauf zwischen Server und Client 4.3 Sicherheitsmaßnahmen Abbildung 4.6: Benutzung von Mumble In diesem Abschnitt werden die aufgezeigten Schwachstellen diskutiert und Maßnahmen gegen bestehende Bedrohungen erarbeitet. Dabei werden auch grundsätzliche Betrachtungen und Handlungsempfehlungen des BSI einfließen Spachkonferenzsoftware Bei der Sprachkonferenzsoftware als Schwachstelle selbst ist für die sichere Konzeption und Implementation der Herausgeber verantwortlich. Darauf kann der Nutzer auf den ersten Blick nur begrenzt Einfluss nehmen. Bei einer näheren Betrachtung wird aber schnell klar, dass dieser einen wichtigen Beitrag zur Sicherheit leisten kann. Dabei wird der erste große Unterschied zwischen TeamSpeak 3 und Mumble/Murmur deutlich. Da der Quelltext von Mumble/Murmur für jeden frei einsehbar ist, kann jeder Nutzer mit Programmiererfahrung den Quelltext analysieren und gegebenenfalls Sicherheitslücken identifizieren. Diese sind dem Herausgeber der Sprachkonferenzsoftware mitzuteilen und von diesem zeitnah zu beheben. Zu den Aufgaben der Herausgeber gehört es ebenso, sicherheitsrelevante Mechanismen in die Sprachkonferenzsoftware zu integrieren. Dazu gehören Mechanismen wie das Protokollieren der Aktivitäten auf dem Sprachkonferenzsystem. So kann im Fall von Sicherheitsverletzungen (z.b. unautorisierte Zugriffe) der Vorfall stets zurück verfolgt werden. Auch der Einsatz geeigneter Protokolle und Verschlüsselungsverfahren ist vom Marcel Graef & Marco Franke 29

36 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Herausgeber zu berücksichtigen. Des Weiteren sind Möglichkeiten für sicherheitsrelevante Konfigurationen bereit zu stellen. Dies spiegelt sich bei TeamSpeak 3 und Mumble/Murmur in den umfangreichen Rechtesystemen für die Gruppenverwaltung wider. Auch der Einsatz von Maßnahmen zur Identifikation von Clients (siehe Abschnitt 2.4) spielt dabei eine große Rolle. Diese waren beispielsweise in der alten Version TeamSpeak 2 nicht integriert. Dies führte zur Entstehung so genannter TeamSpeak-Client-Flooder. Dies waren Programme, mit denen eine unbegrenzte Anzahl vermeintlicher Clients auf einen TeamSpeak 2-Server verbinden konnten und somit die Anzahl von Clients auf dem Server auf das Maximum brachten. Dadurch war der Zugriff weiterer Clients nicht mehr möglich. Ferner sind Mechanismen einzubauen, um das übermäßige Senden von Nachrichten (Spam) bei der textbasierten Kommunikation auf dem Server zu unterbinden. Dies lässt sich unterbinden, indem das Senden von Nachrichten auf eine maximale Anzahl für ein Zeitintervall vorgeschrieben wird. Diese Technik wird auch gegen Brute-Force-Attacken eingesetzt. Aber auch Nutzer ohne Programmiererfahrung können zur sicheren Implementation beitragen. Nutzer können beim Auffinden von Fehlern (Bugs) den Herausgeber der Software darüber informieren (anhand so genannter Bug Reports). Dazu stellen die meisten Herausgeber Bereiche zur Verfügung, indem Bug Reports eingereicht werden können. Bei TeamSpeak 3 und Mumble/Murmur sind speziell für diesen Zweck Bereiche in den offiziellen Foren eingerichtet. Im Aufgabenbereich des Nutzers liegt auch das Softwareaktualisierungen durchgeführt werden. Über neue Versionen kann sich auf den offiziellen Webseiten informiert werden. Bei TeamSpeak 3 und Mumble/Murmur wird jedoch auch beim Start der Software über neue verfügbare Versionen benachrichtigt Konfiguration der Server Die Möglichkeit zur Konfiguration der Sprachkonferenzsoftware allein ist nicht ausreichend, wenn diese nicht geeignet eingesetzt werden. Die Einstellungen und Rechtevergabe sind dabei gründlich zu planen und stark einsatzabhängig. Grundsätzlich ist es ratsam auf jedem Server nur genau einen Administrator mit allen Rechten einzurichten. Lediglich für Moderatoren muss noch eine weitere Rechtegruppe angelegt werden. Diese sind befugt, andere Clients vom Server zu bannen, neue Channel zu erstellen oder Clients in andere Channel zu verschieben. Handelt es sich um einen öffentlichen Sprachkonferenzserver, so ist der Zugang für jeden 30 Marcel Graef & Marco Franke

37 4.3 Sicherheitsmaßnahmen Client zu ermöglichen, die Rechte auf dem Server als Gast aber minimal zu halten. So dürfen Gäste lediglich das Recht erhalten, selbständig in dafür vorgesehene Channel beizutreten, sprechen zu dürfen oder Textnachrichten senden zu können. Es ist aber auch möglich, auf einem öffentlichen Server Channel einzurichten, dem ein Gast nicht beitreten kann, wenn dies nicht erwünscht ist. Der Zugriff kann dann beispielsweise nur durch einen Moderator, ein Passwort oder nur für auf dem Server registrierte Clients erfolgen. Es ist auch möglich, eine Rechtegruppe für Moderatoren zu erstellen, deren Wirkungsbereich sich nur auf spezielle Channel beschränkt. Möchte man einen privaten Sprachkonferenzserver betreiben, beispielsweise in einem Unternehmen zur internen Kommunikation, so ist der Zugriff auf den Server von vornherein zu unterbinden und nur für registrierte Clients oder mit Passwort zu ermöglichen. Aber auch der interne Bereich ist, wie bei einem öffentlichen Sprachkonferenzserver, geeignet einzurichten. Denn wie in Abschnitt hervorgegangen, können auch interne Nutzer können böswillige Ziele verfolgen oder eine Bedrohung darstellen. Auch hier gilt eine Einsatz abhängige, gründliche Planung der Struktur. Eine weitere wichtige Maßnahme ist die Verschlüsselung der Sprachdaten. Bei TeamSpeak 3 ist darauf zu achten, dass die Verschlüsselung standardmäßig deaktiviert ist. Dies findet beispielsweise Anwendung, wenn die durch die Verschlüsselung verursachte Latenz unerwünscht ist und es sich nicht um sensible Sprachdaten handelt. Grundlegend ist eine Verschlüsselung immer zu empfehlen. Bei Mumble/Murmur hingegen ist die Verschlüsselung immer aktiv und kann auch nicht deaktiviert werden. Neben der Rechtevergabe und dem Setzen von Passwörtern ist es auf einen TeamSpeak 3-Server möglich, eine so genannte Blacklist zu verwenden. Damit können Verbindungen an den TeamSpeak 3 TCP-Query Dienst einzelner IP-Adressen oder ganzer IP-Adressbereiche abgelehnt und damit von der Kommunikation mit dem Server ausgeschlossen werden Sicherheitsrelevante Einstellungen des Betriebssystems In diesem Abschnitt werden die wesentlichen Dinge erläutert, wie ein Linux Server (PC 1) sicherer gestaltet werden kann. Ein sehr wichtiger Teil des Sicherheitskonzepts von Linux und auch Windows ab Version Vista ist, dass mit unterschiedlichen Privilegien gearbeitet wird. Es ist extrem wichtig, dass kein Dienst als root bzw. Administrator Marcel Graef & Marco Franke 31

38 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen gestartet wird oder dass ein Nutzer a priori Administrationsrechte besitzt. Bei Ubuntu müssen die Administrationsrechte mit sudo angefordert werden und sind für 15 min gültig. Um die Sicherheit zu erhöhen, soll dies auf 0 min herunter gesetzt werden. Damit sind die Administrationsrechte nur für die eine Operation vorhanden. Zur Änderung wird die Datei /etc/sudoers mit root-rechten geöffnet und folgender Eintrag (siehe Listing 4.2) geändert: 1 # Setzt das Timeout fuer sudo auf Null, der Standardwert ist 15 Minuten. 2 Defaults timestamp timeout = 0 Listing 4.2: Timeout für sudo unter Ubuntu auf Null setzen Updates enthalten meist Verbesserungen von Software und Sicherheitsaktualisierungen. In den Software-Paketquellen empfiehlt es sich, wichtige Sicherheitsaktualisierungen automatisch stündlich zu aktualisieren. So können schnell Sicherheitslücken geschlossen werden. Abbildung 4.7: Dienste mit rcconf deaktivieren Des Weiteren müssen Dienste, die nicht benötigt werden, deaktiviert werden. Dazu wird das Programm rcconf installiert (sudo apt-get install rcconf dialog). Die Deaktivierung ist sehr davon abhängig, welche Aufgaben der Rechner (PC 1) übernehmen soll. Es ist empfehlenswert, beispielsweise grup-common und bluetooth zu deaktivieren, falls diese nicht benötigt werden (siehe Abbildung 4.7). 32 Marcel Graef & Marco Franke

39 4.3 Sicherheitsmaßnahmen Neben den Diensten stellt jede Software auf dem Rechner ein potentielles Sicherheitsrisiko dar. Aus diesem Grund sind überflüssige Pakete z.b. über Synaptic zu entfernen. Damit nicht die Möglichkeit besteht, dass sich Schadsoftware auf dem Rechner selbst übersetzt, ist es ratsam, alle Compiler (gcc) zu entfernen. Auch die Java Virtual Machine muss entfernt werden. Es besteht unter Ubuntu und vielen anderen Distributionen auch die Möglichkeit, die Sicherheit des Systems mit dem Programm Bastille Linux halb automatisch zu verbessern. Es beinhaltet die Änderung von Dateirechten, Bootreihenfolge, Logging, Remote-Login u.v.m. [Spe11, S ], [BSB04], [Ubu12a], [Ubu12b] Router und lokale Firewall Bei den Sicherheitseinstellungen bezüglich einer Firewall müssen zwei Netzwerkkomponenten betrachtet werden. Dies ist zum Einen die FritzBox 7240 und der PC 1. Da die Linux-Distribution der FritzBox nicht verändert wurde und keinerlei Software Erweiterungen durchgeführt wurden, läuft wie üblich lediglich ein Network Address Translation (NAT) Router mit Portfilter sowie Black- und Whitelists. NAT ist im Router aktiviert und es sind lediglich die Ports für Murmur (siehe Tabelle 2.2) und TeamSpeak 3 (siehe Tabelle 2.1) frei geschaltet. Die Pakete, die auf dem in den Tabellen 2.2 und 2.1 angegebenen Port an die FritzBox vom Internet ankommen, werden auf den PC 1 weiter geleitet. Alle anderen Pakete, die vom Internet ohne eine Anforderung vom internen Netz an die FritzBox ankommen, werden ignoriert. Zum Thema einer lokalen Firewall gehen die Meinungen in der Literatur und in der öffentlichen Diskussion sehr weit auseinander. In einem solchen Fall ist es wichtig, sich auf die Fakten zu konzentrieren. Wenn der Rechner keinen Dienst anbietet, dann kann auch über den Dienst nicht angegriffen werden. Die Gefahr, in den Kernel des Betriebssystems einzubrechen, besteht dabei fort. Ein wichtiger Vorteil einer lokalen Firewall ist, dass eine Entscheidung getroffen werden kann, welcher Prozess eine Kommunikation mit dem Netzwerk führen darf. Mit iptables kann über INPUT - und OUTPUT - Ketten entschieden werden, ob ein Paket von außen das System passieren und ob ein Paket vom System nach außen gelangen darf. Marcel Graef & Marco Franke 33

40 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Um einen Überblick über bestehende Regeln des Systems zu erhalten, können diese mit sudo iptables -L angezeigt werden. In Listing 4.3 ist das komplett kommentierte Firewallskript für den Rechner PC 1 dargestellt. Nun ein paar wesentliche Erläuterungen zu diesem Skript. Die Regel (0) im Listing 4.3 auf den Zeilen 6 und 7 ist gerade für 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 für den Fernzugriff über Secure Shell (SSH) notwendig. um den Server von der Ferne zu managen. Zur Erhöhung der Sicherheit kann auch statt der Regel (4) (Listing 4.3 Zeile 18) Regel (4a) aus Zeile 20 benutzt werden. Damit kann nur von einem bestimmten Rechner auf den PC 1 über SSH verbunden werden. Für einige Managementlösungen, ist ein Webserver notwendig. Um auf die generierten Webseiten zugreifen zu können, wurde Regel (5) (siehe Listing 4.3 Zeilen 22 und 23) erstellt. Die Regeln (6) und (8) in den Zeilen 25 und 29 werden zur Kommunikation über TeamSpeak 3 bzw. Murmur benötigt. 1 #!/bin/sh 2 # Diese Skript laed die Regel fuer die Firewall fuer einen Murmur bzw. TeamSpeak Server 3 IPTABLES= iptables 4 REMOTE ACCESS= #(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

41 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 m state state NEW j ACCEPT 28 #(8) Erlaube neue Murmur Sprachuebertragung UDP Steuerkanal TCP 29 $IPTABLES A INPUT p udp dport m state state NEW j ACCEPT 30 $IPTABLES A INPUT p tcp dport 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 für eine lokale Firewall (PC 1) über iptables für Murmur und TeamSpeak Mit den Regeln in Listing 4.3 ist das Firewallskript (firewallmurmurtsskript.sh) fertig und muss nur noch bei jedem Bootvorgang gestartet werden. Es ist sinnvoll, das Skript bei jedem Bootvorgang mit Netzwerkverbindung zu starten. Daher wird es ab Runlevel 3 gestartet. Das Firewallskript firewallmurmurtsskript.sh wird in das Verzeichnis /etc/init.d/ kopiert. Mit chmod 755 /etc/inti.d/firewallmurmurtsskript.sh wird das Skript ausführbar gemacht. Es ist dabei zu kontrollieren, dass der Besitzer der Datei firewallmurmurtsskript.sh der Benutzer root ist. Nun muss noch ein Startlink erzeugt werden. Dies kann mit den folgenden Befehlen in Listing 4.4 durchgeführt werden. Marcel Graef & Marco Franke 35

42 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 Ausführung des Firewallskript im Runlevel 3 Die zwei Zeilen in Listing 4.4 sind für die Runlevel 4 und 5 zu wiederholen. Die S- Nummer (in Listing 4.4) definiert die Reihenfolge der zu startenden Dienste. Diese Angabe ist für die Berücksichtigung der Abhängigkeiten von Diensten untereinander gedacht. Hier wird diese Angabe genutzt, um die Firewall vor dem Start des Netzwerks zu starten, damit keine Sicherheitslücke entsteht, die ein Angreifer ausnutzen könnte. 1 # sudo nmap st p Starting Nmap 5.21 ( ) at :02 CET 3 Nmap scan report for localhost ( ) 4 Host is up ( s latency). 5 Not shown: 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 /tcp open filtered netbios ssn /tcp open filtered microsoft ds /tcp open filtered ipp /tcp open filtered unknown /tcp open filtered netop rc /tcp open filtered privoxy /tcp open filtered unknown /tcp open filtered unknown /tcp open filtered unknown /tcp open filtered unknown /tcp open filtered unknown 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

43 4.3 Sicherheitsmaßnahmen werden. Dabei wurde sudo nmap -st -p aufgerufen. Der Parameter -st bewirkt, dass TCP geprüft wird. Soll das UDP getestet werden, muss -su angegeben werden. Mit Firewall ist die Ausgabe (siehe Listing 4.6) deutlich kürzer. 1 # sudo nmap st p Starting Nmap 5.00 ( ) at :06 CET 3 Interesting ports on adsd.fritz.box ( ): 4 Not shown: filtered ports 5 PORT STATE SERVICE 6 22/tcp open ssh 7 80/tcp open http /tcp open telnet /tcp open unknown 10 MAC Address: 50:E5:49:49:63:71 (Unknown) Nmap done: 1 IP address (1 host up) scanned in seconds Listing 4.6: Ergebnis des Portscans mit nmap mit lokaler Firewall auf PC 1 Ähnliche Ergebnisse konnten bei der Überprüfung von UDP beobachtet werden. [Spe11, S , S ] Nutzerverwaltung TeamSpeak 3-Server Der TeamSpeak 3-Server ist ohne weitere Konfigurationen betriebsbereit. Wie bei Murmur/Mumble können über den Client auch einige administrative Einstellungen vorgenommen werden. Dazu wird sich am Client als serveradmin angemeldet und es muss unter dem Menü Rechte Berechtigungsschlüssel der Berechtigungsschlüssel (Token siehe Abbildung 4.2), der beim Ersten Start des Servers über die Shell ausgegeben wurde, hinzugefügt werden. Nun müssen im Menü Rechte die jeweiligen Rechte der Server-Gruppen und Channel-Gruppen überprüft und gegebenenfalls geändert werden. Es ist auf jeden Fall zu empfehlen, dass ausschließlich der Server-Admin den Server administrieren darf. Normale Benutzer oder gar Gäste dürfen 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

44 4 Realisierung einer Untersuchungsumgebung unter Betrachtung von Sicherheitsmaßnahmen Admin zu überlassen. Empfehlenswert ist hier, eine separate Moderatoren-Gruppe anzulegen. Murmur Nachdem der Server Murmur betriebsbereit ist, müssen dennoch die Gruppenberechtigungen überprüft werden. Zunächst ist mit sudo -i murmurd -ini /etc/mumble-server.ini -supw PASSWORD ein SuperUser-Passwort zu genieren. Nun kann eine Verbindung über Mumble zum Server Murmur hergestellt werden. Dabei ist als Benutzername SuperUser und das dazugehörige Passwort zu verwenden. Mit einem Rechtsklick auf dem Hauptkanal und durch Betätigen von Bearbeiten wird das Gruppenund Berechtigungscenter geöffnet. Es ist wichtig, dass nur die Gruppe admin und evtl. eine neu angelegte Gruppe moderator die Berechtigungen bearbeiten können. Bei der Einstellung Selbst registrieren für die Gruppe all ist in diesem Zusammenhang zu prüfen, ob dies wirklich erwünscht ist. Im Zweifelsfall ist dies zu deaktivieren Mensch als Schwachstelle Neben den in diesem Kapitel erarbeiteten Maßnahmen technischer Natur müssen auch Maßnahmen gegen die Schwachstelle Mensch erarbeitet werden. Dies hat den Grund, dass der Mensch Informationen (z.b. Passwörter) besitzen muss, welche ihm Zugang zum System gewähren. Ferner ist der Mensch angreifbarer hinsichtlich Täuschungen und Manipulationen. So muss darauf geachtet werden, dass sensible Daten nicht an unberechtigte Dritte gelangen. Die erste Maßnahme ist die Wahl sicherer Passwörter. Es ist darauf zu achten, dass die Passwörter möglichst lang (ca. 8 Stellen) sind und aus Buchstaben, Zahlen und Sonderzeichen bestehen. Zusätzlich müssen stets unterschiedliche Passwörter gewählt werden. Auch dürfen Passwörter und Logindaten nie auf auf dem PC gespeichert werden. Es ist auch zu beachten, dass keine Logindaten an andere Personen weiter gegeben werden, auch nicht auf Anfrage vermeintlicher Administratoren. Ein weiterer Punkt ist das Herunterladen von Dateien oder Programmen. Es ist dabei notwendig, genau zu prüfen, ob es sich um eine vertrauenswürdige Quelle handelt. Über Instant Messenger oder erhaltene Hyperlinks sind vor dem Anklicken bzgl. ihrer Vertrauenswürdigkeit zu überprüfen. Beispielsweise kann die Dateiendung erste Hinweise auf die Art der Daten geben. Auch bei Anhängen ist Vorsicht geboten. 38 Marcel Graef & Marco Franke

45 4.3 Sicherheitsmaßnahmen s dürfen generell nur im Textformat geöffnet werden, damit keine integrierten Scripte ausgeführt werden. Es ist wichtig, dass alle Nutzer des Sprachkonferenzsystems sorgfältig darauf achten, alle erforderlichen Maßnahmen umzusetzen. Es bietet sich an dieser Stelle an, Verhaltensregeln zur Erhöhung der Sicherheit an die Nutzer zu tragen. In Unternehmen ist die Durchführung spezieller Schulungen zu diesem Sachverhalt zu empfehlen. Marcel Graef & Marco Franke 39

46 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ögliche Angriffsszenarien betrachtet und praktisch durchgeführt. 5.1 Betrachtung des TeamSpeak 3-Server Query Interface In diesem Abschnitt wird untersucht, welche Angriffsmöglichkeiten 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 und Angriffsszenarien betrachtet und durchgeführt Aufbau des Testprogramm Das Testprogramm wird die Aufgabe besitzen, automatisiert Daten zum TeamSpeak 3- Server Query Interface zu senden und zu empfangen. Für diese Aufgabe wurde ein Java-Programm geschrieben. Dieses ist in Listing 5.1 auszugsweise dargestellt. Als Erstes wird mit Hilfe der Klasse Socket eine Verbindung von PC 3 zum TeamSpeak 3-Server Query Interface des PC 1 hergestellt. Daten können während der Verbindung mit den 40 Marcel Graef & Marco Franke

47 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.1 können die zu sendenden Query-Befehle mit out.println() als String angegeben werden. Nach Abschluss der Befehlsfolge werden die vom Server (PC 1) empfangenen Daten ausgegeben. 1 [...] 2 try { 3 testsocket = new Socket( , ); 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 Ausführen des Testprogramms eine Verbindung vom PC 3 zum TeamSpeak 3-Server Query Interface von PC 3 hergestellt. 1 SERVER: TS3 2 SERVER: Welcome to the TeamSpeak 3 ServerQuery interface, type help for a list of commands and help <command> for information on a specific command. Listing 5.2: Ausgabe des Verbindungstests mit dem TeamSpeak 3-Server Query Interface Marcel Graef & Marco Franke 41

48 5 Demonstration von Angriffsszenarien Die von der TeamSpeak 3-Server Query Interface empfangenen Daten sind in Listing 5.2 dargestellt. Daraus lässt sich entnehmen, dass eine Verbindung hergestellt werden konnte 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 für ein Zeitfenster zu limitieren und somit einem Missbrauch wie beispielsweise dem Fluten mit Textnachrichten vorzubeugen. In diesem Szenario wird davon ausgegangen, dass der Angreifer bereits Zugang zum TeamSpeak 3-Server Query Interface besitzt. Ausgehend von dieser Situation möchte der Angreifer den TeamSpeak 3-Server mit Textnachrichten fluten. Für diesen Zweck wird im Testbereich des Testprogramms (Listing 5.1) die Befehlsfolge aus Listing 5.3 eingefügt. Um sich anzumelden, muss als Erstes der Befehl login verwendet werden. Danach wird mit dem Befehl use der virtuelle Server ausgewählt. 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 ausgeführt, erhält 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

49 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 für den Zugriff auf das Query Interface notwendig ist. Zum Anderen kann durch einen Tippfehler ein zu großer IP-Adressbereich angegeben worden sein, in dem sich auch der Angreifer befindet. Zusätzlich kann eine fehlerhafte Konfiguration der Anti-Flood-Protection dazu führen, 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 Für weitere Tests wird daher die IP-Adresse von PC 3 in die Whitelist eingetragen. Bei erneutem Durchführen der Befehlsfolge aus Listing 5.3 ist keine Verbindungsunterbrechung zu beobachten. Zur Veranschaulichung ist in Abbildung 5.1 die Wirkung als Ausschnitt im TeamSpeak 3-Client dargestellt. Abbildung 5.1: TeamSpeak 3 Server Query Interface Text Flut Wie erwartet, kann die Anti-Flood-Protection, durch einen Eintrag in die Whitelist gezielt deaktiviert werden. Aufgrund der daraus entstehenden Gefahren wird jedoch davon abgeraten. In manchen Fällen kann es jedoch erwünscht sein (für z.b. Fernwartungen), IP-Adressen oder ganze IP-Adressbereiche auf die Whitelist zu setzen. Diese Experimente zeigen, dass dabei sehr sorgfältig vorgegangen werden muss. Marcel Graef & Marco Franke 43

50 5 Demonstration von Angriffsszenarien Brute-Force-Angriff auf das Query Interface In Abschnitt wurde gezeigt, dass die Anti-Flood-Protection, wie erwartet, bei Adressen, welche in der Whitelist stehen, die Anzahl gesendeter Befehle nicht beschränkt. An dieser Stelle stellt sich die Frage, ob ein Angreifer ohne gültige Logindaten mit deaktivierter Anti-Flood-Protection einen Brute-Force-Angriff auf das TeamSpeak 3- Server Query Interface durchführen kann. Dies war beispielsweise bei TeamSpeak 2 mit dem Programm THC Hydra ([Hau12]) möglich. Der Testbereich im Testprogramm (Listing 5.1) wird dafür mit der unter Listing 5.5 dargestellten Befehlsfolge ersetzt. Die Befehlsfolge sendet mehrfach den login Befehl mit unterschiedlichen Passwörtern. 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 Ausführen der Befehlsfolge erhält man die unter Listing 5.6 dargestellte Antwort von dem TeamSpeak 3-Server Query Interface. Dem ist zu entnehmen, dass das TeamSpeak 3-Server Query Interface nach dem vierten fehlerhaften Loginversuch den Angreifer für 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ängiger Mechanismus existiert, welcher gegen Brute-Force-Angriffe vorbeugt. Durch die Dauer der Verbannung sind bei einem einzigen angreifenden Rechner maximal 576 Passwörter pro Tag testbar. Das heißt, Brute-Force-Angriffe sind durchführbar, werden jedoch stark beeinträchtigt. An dieser Stelle wird klar, wie wichtig die Wahl eines 44 Marcel Graef & Marco Franke

51 5.2 TeamSpeak 3-Server Query Interface Exploit sicheren Passwortes ist. Denn je länger das Passwort ist und um so mehr verschiedene Zeichen es beinhalten kann, um so mehr mögliche Passwörter sind bei einem Brute-Force- Angriff zu testen. Dadurch werden solche Angriffe in einem realistischen Zeitfenster nicht mehr durchführbar. 5.2 TeamSpeak 3-Server Query Interface Exploit Mit dem folgenden Szenario wird aufgezeigt, welche Auswirkungen das Ausnutzen einer Sicherheitslücke mit Hilfe eines Exploit haben kann. Ausgangspunkt dieser Szenarien ist die Missachtung oder Vernachlässigung der in Abschnitt 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 bereits angedeutet. Für das Szenario wird die in Kapitel 4 aufgebaute Untersuchungsumgebung dahingehend modifiziert, dass der verwendetet TeamSpeak 3-Server mit der Version auf PC 1 durch die Version beta23 ersetzt wird. Bis zu dieser Version ist durch die Verwendung eines von Luigi Auriemma geschriebenen C-Programms namens teamspeakrack möglich [Aur10c], eine Schwachstelle auszunutzen. Das C-Programm steht als Quelltext (teamspeakrack.c) zur Verfügung. Als Angreifer wird PC 3 (siehe Abbildung 4.1) verwendet. Mit Hilfe von teamspeakrack ist es möglich, TeamSpeak 3-Server Query-Befehle auf dem TeamSpeak-Server (PC 1) auszuführen, ohne einen authentifizierten Zugriff auf das Query Interface zu besitzen. Zusätzlich verfügt das C-Programm über vorgefertigte Angriffsszenarien in Form von Befehlssequenzen. Nach dem Start von teamspeakrack werden, wie in Abbildung 5.2 zu sehen, alle Szenarien, die das Programm bietet, aufgelistet Funktionsweise von teamspeakrack Mit Hilfe von teamspeakrack wird eine Schwachstelle ausgenutzt, welche bei der Umstellung des TeamSpeak-Protokolls entstanden ist. TeamSpeak 3 verwendet UDP-Pakete für acht verschiedene Aufgaben (8 Kanäle). Speziell der Kanal 2 wird für das Senden Marcel Graef & Marco Franke 45

52 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 über das UDP-Paket auf Kanal 2 gesendet werden, auf dem Server ausgeführt werden. Das heißt, um die Schwachstelle auszunutzen, muss ein modifiziertes UDP-Paket über den standardmäßig geöffneten Port 9987 an den Server gesendet werden. Dieses Paket wird so modifiziert, dass ein Query-Befehl an den Server gesendet wird. Dieses Einschleußen von Query-Befehlen wird auch als Bypass bezeichnet. Um dies zu testen, wird teamspeakrack zunächst mit der Option 1 (siehe Abbildung 5.2) in einen Zustand versetzt, welcher die selben Möglichkeiten bietet, als wäre der Angreifer mit dem TeamSpeak 3-Server Query Interface verbunden. Das heißt, der Angreifer kann mit teamspeakrack fortlaufend Query-Befehle senden. Die dabei für den Angreifer zu sehende Oberfläche ist in Abbildung 5.3 zu sehen. Da die Query-Befehle über ein UDP-Paket in den Server eingeschleust werden, können lediglich Fehlermeldungen empfangen werden. Das heißt, man kann mit teamspeakrack keine Informationen vom Server mit Hilfe von Query-Befehlen abfragen. Es ist nun nicht mehr notwendig, sich mit Hilfe gültiger Logindaten über TCP Port 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önnen jetzt gezielt Angriffe - basiert auf dem Senden von Query-Befehlen - gegen den Sprachdienst durchgeführt werden. Die dabei möglichen Befehle können dem TeamSpeak 3-Server Query Handbuch entnommen werden. Eine Reihe solcher Möglichkeiten sind als Befehlsfolgen in das Programm integriert und können ausgeführt werden. 46 Marcel Graef & Marco Franke

53 5.2 TeamSpeak 3-Server Query Interface Exploit Abbildung 5.3: TeamSpeak 3 Server Query Interface Exploit Einrichten einer Hintertür Als nächstes wird gezeigt, wie eine Hintertür (Backdoor) auf dem TeamSpeak 3-Server eingerichtet werden kann. Dafür wird ein administrativer Zugriff eingerichtet. Zunächst wird sich als Nutzer mit dem TeamSpeak 3-Client von PC 3 zum Server (PC 1) verbunden. Dabei ist der TeamSpeak 3-Client vorerst nur als Gast verbunden und besitzt keine administrativen Rechte. Dies ist in Abbildung 5.4 im rot markierten Bereich zu sehen. Abbildung 5.4: Als Gast auf dem TeamSpeak 3 Server verbunden Um jetzt Administrationsrechte zu erhalten, muss der Client der Gruppe der Serveradministratoren, welche durch eine Identifikationsnummer gekennzeichnet ist, zugeordnet werden. Dafür wird mit dem C-Programm teamspeakrack der Server Query-Befehl aus Listing 5.7 ausgeführten Syntax verwendet. 1 #servergroupaddclient sgid={groupid} cldbid={clientdbid} Listing 5.7: Query-Befehl servergroupaddclient Syntax Marcel Graef & Marco Franke 47

54 5 Demonstration von Angriffsszenarien Die benötigten Informationen groupid und clientdbid können zwar nicht mit teamspeakrack ermittelt werden, aber durch den verbundenen Client ist es möglich. Die groupid für die richtige Servergruppe erhält der Angreifer im Menü Rechte unter dem Punkt Channelgruppen im TeamSpeak 3-Client. In diesem Fall besitzt die Servergruppe der Administratoren die groupid = 6. Die clientdbid erhält der Angreifer ebenfalls im TeamSpeak 3-Client, indem er in der Channelübersicht auf den gewünschten Client klickt. Aus Abbildung 5.4 geht aus dem blau markierten Bereich hervor, dass die clientdbid = 2 ist. Der gesamte Befehl, der jetzt mit teamspeakrack abgesendet werden muss, ist in Listing 5.8 angegeben. 1 >servergroupaddclient sgid=6 cldbid=2 Listing 5.8: Query-Befehle zur Zuweisung zu einer Gruppe Ob der Vorgang erfolgreich war, kann dem TeamSpeak 3-Client entnommen werden. Das Ergebnis ist in Abbildung 5.5 durch die rot markierten Stellen gekennzeichnet. Abbildung 5.5: Gast mit vollen Administrationsrechten Auf diese Weise wurde demonstriert, wie einem Gast Administrationsrechte zugesichert werden können. Da bei einem Update der Sprachkonferenzsoftware, welche die Sicherheitslücke schließt, die Administrationsrechte für den vermeintlichen Gast bestehen bleiben, wurde erfolgreich eine Hintertür eingerichtet. Es wird empfohlen, nach dem Bekanntwerden und Schließen einer solchen Sicherheitslücke mit Hilfe von Backups oder Sicherungspunkten das System auf einen früheren Zustand zurück zu setzen. Ist dies nicht möglich, sollte die Rechtevergabe erneut durchgeführt werden. 48 Marcel Graef & Marco Franke

55 5.2 TeamSpeak 3-Server Query Interface Exploit 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 führen. Diese sind in Listing 5.9 aufgezählt. 1 >banlist 2 >complainlist 3 >servernotifyunregister 4 >serverrequestconnectioninfo 5 >setconnectioninfo 6 >servernotifyregister event=server Listing 5.9: Query-Befehle, die mit teamspeakrack zum Absturz führen Der Grund für den Absturz bei Verwendung dieser Befehle ist, dass bei der Verarbeitung der Befehle Informationen des Client, welcher den Befehl ausführen möchte, benötigt werden. Da bei Verwendung von teamspeakrack keine ordnungsgemäße Verbindung hergestellt wird, kann der TeamSpeak 3-Server den Befehl keinem gültigen Client zuordnen. Dadurch entsteht bei der Abfrage, welcher Client dem Befehl zuzuordnen ist, eine NullPointerException und der TeamSpeak 3-Server wird aufgrund dieses Fehlers stillschweigend beendet Server mit Textnachrichten fluten In diesem Szenario wird der TeamSpeak 3-Server mit Textnachrichten geflutet (Spam). Für diesen Zweck wird der im Listing 5.10 aufgeführte Befehl verwendet. 1 #sendtextmessage targetmode={1 3} msg={text} Listing 5.10: Query-Befehl sendtextmessage Syntax In teamspeakrack wird dieser Befehl (5.10) mit Hilfe einer Schleife und zufällig generierten Nachrichten an den Server gesendet. Mit der Option 4 (siehe 5.2) kann diese Befehlssequenz aufgerufen werden. In Abbildung 5.6 ist die Wirkung anhand des Nachrichtenfensters des TeamSpeak 3-Clients zu sehen. In der Abbildung ist ein Ausschnitt der gesendeten zufällig generierten Nachrichten dargestellt. Marcel Graef & Marco Franke 49

56 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änkung der gesendeten Befehle pro Zeitintervall, nicht greift. Dies ist mit dem Einschleusen der Befehle über die UDP-Pakete zu begründen. Dadurch werden die IP-basierten Filter (Anti-Flood-Protection) des TeamSpeak 3-Server Query Interface übergangen Weitere Möglichkeiten von teamspeakrack Neben den bisher vorgestellten Möglichkeiten, den TeamSpeak 3-Server zu manipulieren, bietet teamspeakrack weitere vorgefertigte Befehlssequenzen, welche durch die Optionen 1 bis 9 (siehe Abbildung 5.2) ausgewählt werden können. Dazu gehört die Möglichkeit, die maximale Anzahl von Clients auf dem TeamSpeak 3- Server mit Hilfe des unter Listing 5.11 aufgeführten Befehls auf Null zu setzen. Dadurch ist es nicht mehr möglich, mit dem TeamSpeak-Client eine Verbindung mit dem TeamSpeak 3-Server herzustellen. 1 >serveredit virtualserver maxclients=0 Listing 5.11: Query-Befehl zur Änderung der maximalen Anzahl von Clients auf dem Server Die bisher noch nicht betrachteten und vorgefertigten Optionen von teamspeakrack (siehe Abbildung 5.2) ermöglichen es, ohne Kenntnisse diverser Identifikationsnummern (z.b. clientid oder banid), alle Clients anzusprechen. Dabei werden Befehle, welche die Angabe einer Identifikationsnummer benötigen, innerhalb einer Schleife ausgeführt. Die dabei aufsteigende Schleifenvariable wird entsprechend als Parameter beim Aufruf eines Befehls verwendet. So wird iterativ jede mögliche ID zusammen mit einem Befehl verwendet. Die dafür zur Verfügung stehenden - in teamspeakrack implementierten - Möglichkeiten sind: alle Clients vom Server werfen 50 Marcel Graef & Marco Franke

57 5.3 Murmur Exploit für einen DoS-Angriff alle Clients vom Server verbannen alle Banns auf dem Server aufheben und alle Clients auf dem Server anstupsen. Die dabei verwendeten Befehle sind in Listing 5.12 aufgeführt. 1 #Client vom Server schmeissen 2 #Syntax: clientkick clid={clientid} reasonid={4 5} 3 #Client vom Server verbannen 4 #Syntax: banclient clid={clientid} 5 #Bann aufheben 6 #Syntax: bandel banid={banid} 7 #Client auf dem Server an stupsen 8 #Syntax: clientpoke clid={clientid} msg={text} Listing 5.12: Beispiel für Query-Befehle mit Parameter Damit wurde gezeigt, welche verheerenden Auswirkung ein Exploit haben kann. Aus dem Beispiel ist hervorgegangen, dass durch eine Aktualisierung der Software und somit die Schließung der bestehenden Sicherheitslücke nicht garantiert werden kann, dass der TeamSpeak 3-Server keine Folgeschäden davon getragen hat. In diesem Fall wäre der Folgeschaden die in Abschnitt eingerichtete Backdoor (siehe Abschnitt 3.2.5). Es ist also zwingend notwendig, nach Bekanntwerden einer solchen Sicherheitslücke das System genau zu prüfen. Falls möglich, sollte in diesem Fall das System auf einen früheren Zustand zurück gesetzt werden. Dies kann beispielsweise durch Wiederherstellungspunkte oder Backups erfolgen. 5.3 Murmur Exploit für einen DoS-Angriff Bei dem Murmur-Server der Version kleiner und Beta wurde ein Exploit durch Luigi Auriemma bekannt. Durch einen fehlerhaften Datentyp in der SQL-Abfrage ist es möglich, den Sprachkonferenzserver Murmur aufgrund eines Fehlers beim Umgang mit fehlerhaften SQL-Abfragen zum Beenden zu zwingen. Der Angreifer muss sich dabei mit dem Server verbinden, um den Fehler auszunutzen. Das Demo Programm von Luigi Auriemma generiert eine SQL-Abfrage. In der like Klausel sind fast alle Marcel Graef & Marco Franke 51

58 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- Adresse des Murmur-Servers als Parameter aufgerufen. (b) Der Mumble-Client ist mit dem Murmur- Server verbunden. Abbildung 5.7: Murmur Exploit für 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 installiert. Das Paket ist unter verfügbar und wird als deb-paket über die Paketverwaltung installiert. Auch das Programm zur Demonstration des Exploits mumbleed steht unter [Aur10a] als C-Programm zur Verwendung bereit. (a) Das Programm mumbleed wurde ausgeführt und hat den Murmur-Server beendet. (b) Der Mumble-Client ist nicht mehr mit dem Murmur-Server verbunden. Abbildung 5.8: Murmur Exploit für 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