Rote Telefone

Telefonieren über das Inter-/Intranet scheint verlockend: Kosten sinken, die Administration vereinfacht sich. Allerdings hat Voice over IP auch mindestens einen Haken: Ohne Vorsichtsmaßnahmen sind die Gespräche leicht zu belauschen.

12

11.04.2002, 02:00 Uhr

Lesezeit: 8 Min.

iX Magazin

Von

Luigi Lo Iacono

Als eine Internet-Applikation der Zukunft wird Voice over IP (VoIP) - das Telefonieren über IP-basierte Netze und somit auch das Internet - hoch gehandelt. Zunächst waren die im Vergleich zum PSTN (Public Switched Telephone Network) geringeren Verbindungsgebühren die maßgebliche Triebfeder für VoIP. Der liberalisierte Telekommunikationsmarkt und die damit einhergehend stark gesunkenen Preise, gerade für Ferngespräche, lassen diesen Vorteil an Gewicht verlieren. An die Stelle der attraktiveren Verbindungsgebühren treten vielmehr Aspekte wie die Konvergenz der Netze (Everything over IP) und die Integration der wichtigsten Kommunikationsform in computergestützte Anwendungen. Außerdem lassen sich neben der Sprache weitere multimediale Daten per Telefonie austauschen, sodass ein Mehrwert entsteht (Videokonferenzen, verteiltes kooperatives Arbeiten).

Zwei Kommunikationswege sind bei der Übertragung multimedialer Daten nötig: Einer für die Steuerung der Sitzung, der andere für die Nutzdaten (Abb. 1).

Um den im Folgenden erläuterten passiven Angriff auf IP-Telefonate besser verstehen zu können, sind zunächst Grundlagen multimedialer Anwendungen, die das Internet als Transportmedium nutzen, zu klären. Zum Steuern einer Sitzung wird ein Signalisierungsprotokoll benötigt (s. Abb. 1). Mit ihm steuern Kommunikationspartner die Sitzung (Anrufen, Auflegen, Makeln et cetera) und handeln hierfür benötigte Parameter wie Codecs, Transportadressen und so weiter aus. Ist die Signalisierung abgeschlossen, können die Endpunkte einen oder mehrere Medienkanäle öffnen (Datenpfad) und im Falle von VoIP Sprachdaten übermitteln. Zurzeit haben sich für VoIP-Anwendungen die Signalisierungsprotokolle H.323 und SIP etabliert. Der Transport der Mediendaten erfolgt über RTP/UDP. Beispielsweise nutzt Microsofts NetMeeting zur Signalisierung H.323 und zum Transport RTP. Weitere Einzelheiten über dieses Themengebiet finden sich in der Februar-Ausgabe der iX [1].

Immer der Fährte nach

Ressourcen

Das Abhören eines IP-basierten Telefonats ist mit einigen Bordmitteln einfach möglich. Es reichen beispielsweise ein Sniffer wie Aldebaran (siehe Kasten ‘Ressourcen’) zum Belauschen des Medienstroms und das Java Media Studio (JMS) zur Wiedergabe. Aldebaran erlaubt es, gefilterte Pakete in Form von UDP-Datagrammen an einen beliebigen Host weiterzuleiten und nicht nur die abgefangenen Pakete in einer textuellen Form darzustellen oder zu speichern, wie das seine bekannteren Kollegen tcpdump und Ethereal tun. Da echtzeitorientierte Applikationen als Transportprotokoll UDP verwenden, kann Aldebaran eine Kopie des Paketstroms anfertigen. Wartet auf der angesteuerten Abhörstelle ein Media-Player, der RTP-Sitzungen öffnen und abspielen kann, ist dieser nur korrekt zu konfigurieren. Aus dem Header eintreffender RTP-Pakete entnimmt er, mit welchen Codec die Mediendaten kodiert wurden, und kann - falls der Dekodierer enthalten ist - den Strom rücktransformiert wiedergeben. Das JMS kann RTP-Sitzungen öffnen und beinhaltet eine Vielzahl weit verbreiteter Codecs. Dazu gehören die im VoIP-Umfeld gebräuchlichen G.711 (ISDN-Qualität) und G.723 ebenso wie die Video-Codecs H.261 und H.263, die üblicherweise für die Bilder in Videokonferenzen sorgen. JMS ist im optionalen Paket Java Media Framework (JMF) enthalten. Für Linux bietet Blackdown eine Version des JMF an.

Eve will Gespräche zwischen Bob und Alice belauschen (Abb. 2).

Geht man von dem in Abbildung 2 gezeigten Szenario aus, hat man zwei Kommunikationspartner - Alice und Bob - die ein Telefonat über IP führen möchten. Eve will nun unbedingt diese Kommunikation abhören. Im Prinzip geht sie dabei genauso vor, wie sie das bereits von anderen Internet-Applikationen kennt: Sie bemächtigt sich eines Kommunikationsknotens, über den die Sprachpakete zwischen Alice und Bob fließen, fängt diese dort ab und sendet eine Kopie der Pakete an sich selbst.

aldebaran -i eth0 -h 1.1.3.1:5000  -r ip src host 1.1.1.1 and port 5000 aldebaran -i eth0 -h 1.1.3.1:5002  -r ip src host 1.1.2.1 and port 5000

Mit Hilfe des Java Media Studio lassen sich VoIP-Gespräche leicht mithören (Abb. 3).

Das Beispiel verdeutlicht, dass beide Richtungen getrennt abgefangen und weitergeleitet werden müssen. Das Wiedergabeprogramm muss deshalb auf den beiden angegebenen Ports (5000 und 5002) auf eintreffende Pakete horchen. Nach dem Start des JMS kann man dies einfach durch das Auswählen der Menüoption ‘Open RTP Session ...’ initiieren. Der im Anschluss erscheinende Dialog (s. Abb. 3) ist nun nur noch gemäß der Situation auszufüllen.

Abhören aller multimedialen Inhalte

Auf diese Weise lassen sich nicht nur über IP-basierte Netze übertragene Gespräche mithören, sondern jegliche Art multimedialer Kommunikation. Ungeschützte Videofilmübertragungen gehören ebenso dazu wie kooperatives, verteiltes Arbeiten.

Aldebaran ist in der aktuellen Version 3.0.2 nur auf Linux-Systemen einsetzbar. Da der größte Teil aller Paket-Sniffer schließlich und endlich auf der Bibliothek libpcap basiert, für die ein Pendant namens WinPcap auf Windows-Plattformen existiert, ist eine Portierung für geübte C/C++-Programmierer eine leichte Übung. Diejenigen, die sich eher auf das Programmieren in Java verstehen, können mit der Jpcap ebenfalls relativ simpel Netzschnüffler implementieren. Mit der Jpcap steht Entwicklern ein Java Native Interface (JNI) zur libpcap beziehungsweise WinPcap zur Verfügung. Somit kann man das dargestellte Szenario auf jeder Plattform, für die eine JVM verfügbar ist, nachvollziehen.

Um Mitarbeiter zu bespitzeln, muss man nicht unbedingt zuvor einen Netzknoten erobern. Hängen die Kommunikationsendpunkte an einem gemeinsamen Kabel, ist der beschriebene passive Angriff ebenfalls möglich. Durch Switches strukturierte Netze bilden hierbei keine Ausnahme. MAC-Spoofing mit Werkzeugen wie arp0c und dsniff oder Random MAC-Flooding mit angst können Switches gezielt verwirren, sodass sie Pakete an alle Ports senden und ihr Verhalten zu dem von Hubs degeneriert. Durch Switches strukturierte Firmennetzwerke sind folglich nicht immun gegen das Mithören Dritter.

Unbefugtes Einschalten in Multimedia-Kommunikationen, die über ein IP-Netz laufen, ist ohne große Mühen möglich. Folglich ist der Einsatz dieser Kommunikationsformen ohne wirksame Schutzmaßnahmen nicht empfehlenswert. Bleibt die Frage, wie die aussehen müssen.

Sicherheit durch IPSEC und SRTP

Neben einer Reihe herstellerspezifischer Verfahren (etwa die Sicherheitsmechanismen in Microsofts NetMeeting und Speak Freely), die aber wenig interoperabel sind, können Standards wie IPSEC die Ende-zu-Ende-Verschlüsselung der IP-Pakete übernehmen. Dieser Ansatz ist unabhängig von der gewählten VoIP-Applikation, birgt allerdings einen nicht zu unterschätzenden administrativen Aufwand in sich - ganz abgesehen davon, dass auf der Plattform, auf der die VoIP-Anwendung betrieben wird, eine IPSEC-Implementierung verfügbar sein muss.

In der H.323-Protokollfamilie befasst sich der H.235-Standard mit Sicherheitsdiensten für Signalisierungs- und Mediendaten. Allerdings stehen dort Authentizität und Integrität der Signalisierungsnachrichten im Vordergrund. Eine Verschlüsselung des RTP-Payloads ist zwar außerdem definiert, einen Schutz für RTCP-Pakete sieht H.235 allerdings nicht vor. Einen relativ neuen Ansatz zum Schutz der zu übertragenden Mediendaten untersucht und diskutiert zurzeit die IETF (Internet Engineering Task Force) in der Arbeitsgruppe AVT-WG. Es handelt sich um den Internet Draft ‘Secure Real-Time Transport Protocol’ (SRTP), das für die RTP- und RTCP-Pakete Sicherheitsdienste wie Vertraulichkeit und Authentifikation/Integrität bietet. Außerdem sind Mechanismen gegen Replay-Attacken enthalten.

Neue Kommunikationsformen auf Basis des Internets sehen sich den gleichen Risiken ausgesetzt wie ihre Vorfahren E-Mail und WWW. Schutzmaßnahmen existieren und werden für die Anforderungen der neuen meist echtzeitorientierten Applikationen weiterentwickelt. Bleibt den Herstellern noch, diese in geeigneter Form umzusetzen und den Anwendern, sie schließlich zu benutzen.

Luigi Lo Iacono
ist wissenschaftlicher Mitarbeiter am Institut für Nachrichtenübermittlung der Universität Siegen. Er erforscht die Sicherheit echtzeitorientierter Internet-Applikationen.