Protokollfragen VoIP-Security bei SIP & Co.

Ordnungsmerkmale

erschienen in: <kes> 2005^#2, Seite 55

Rubrik: Management und Wissen

Schlagwort: Voice over IP

Zusammenfassung: Voice over IP (VoIP) ist "in". Und für die Telefonie via Datennetz setzt sich zunehmend das Session Initiation Protocol (SIP) durch. Doch wie steht es dabei um die Sicherheit?

Autor: Von Andrew Graydon, Mississauga (CA)

Damit Sprachtelefonie übers Datennetz auch außerhalb einer geschlossenen Benutzergruppe funktioniert, benötigt sie naturgemäß standardisierte Protokolle. Hierbei scheint das Session Initiation Protocol (SIP) das Rennen zu machen: schon fast eine ganze Protokoll-Familie, die sich bei der Internet Engineering Task Force (IETF) – großenteils als "Proposed Standards" – im Normungsprozess befindet. SIP (RFC 3261) ist ein Kontrollverfahren der Anwendungsschicht zum Aufbau, zur Ablaufsteuerung und zum Beenden von Multimedia-Sessions mit zwei oder mehr Teilnehmern; neben Internet-Telefonie können das unter anderem auch Instant-Messaging-(IM-)Anwendungen, Videokonferenzen oder Multimedia-Streamings sein.

Um mit einem anderen Anwender Daten austauschen zu können, muss man diesen zunächst "finden" (IP-Adresse), seinen Verbindungswunsch signalisieren und sich mit ihm über die Parameter des Austauschs verständigen – hierzu dient SIP in Verbindung mit dem Session Description Protocol (SDP, RFC 2327). Der eigentliche Datenaustausch findet dann anschließend über andere Verfahren statt, beispielsweise via Real-time Transport Protocol (RTP, RFC 1889) oder Real-Time Streaming Protocol (RTSP, RFC 2326).

Bestehende VoIP-Implementierungen nutzen heute typischerweise das verbindungslose User Datagram Protocol (UDP); SIP kann jedoch auf verschiedenen Transportmechanismen aufsetzen. Und Beschränkungen der Paket- und Nachrichtengröße haben bereits zum Ruf nach einem bevorzugten Einsatz des Transmission Control Protocol (TCP) geführt; beispielsweise hat Microsofts SIP-System, der Live Communications Server (LCS), bereits eine vollständige TCP-Implementierung.

SIP-Nachrichten bestehen aus (UTF-8-kodierten) Textzeichen, ganz ähnlich wie beispielsweise die Web- und E-Mail-Protokolle HTTP und SMTP (vgl. Abb. 1). Während der eigentliche SIP-Header die Adressierung und Signalisierung übernimmt, beschreibt SDP die Multimedia-Komponenten, die zur Session-Steuerung erforderlich sind.

Abbildung 1: Das Session Initiation Protocol (SIP) arbeitet, ähnlich wie das Mail-Protokoll SMTP, in schlichter Textform.

Verbindungsaufbau

SIP kennt mehrere Verbindungsarten. Typischerweise erfolgt ein Ruf-Aufbau per SIP aber über ein Proxy, das Anfragen von Clients annimmt und an das Rufziel weiterleitet. Das Proxy agiert als Vermittlungsstelle und übernimmt zudem Authentifikation, Autorisierung, Netzzugangskontrolle (Network Access Control) und Routing.

Zum Aufbau einer SIP-Verbindung sendet ein Teilnehmer eine so genannte Invite-Nachricht an das SIP-Proxy, welches die Anforderung an die (vom Client) in einem Location-Server hinterlegte IP-Adresse des Rufziels weiterleitet. Unmittelbar nach der Aushandlung der Session- und Media-Parameter kann dann der Datenaustausch von User-Agent zu User-Agent beginnen (vgl. Abb. 2 und 3).

Abbildung 2: Typischer Nachrichtenfluss beim Verbindungsaufbau mit SIP-Proxy

Da die eigentliche Kommunikation letztlich Peer-to-Peer über zufällige Ports erfolgt, die via SIP ausgehandelt wurden, stellen diese Verbindungen ein Problem für gesicherte Netzwerkgrenzen dar: Einerseits "weiß" der User Agent nichts von eventuellen Network Adress Translations (NAT) an der Perimetergrenze und überdies muss eine Firewall dort SIP- und RTP-Verbindungen zulassen, für die keine festen IP-Nummer-/Port-Kombinationen bekannt sind. Um eine weite Öffnung des Netzes zu vermeiden, muss also die Firewall "SIP-aware" sein und möglichst dynamisch auf entsprechende Session-Verabredungen reagieren können. Damit ein Ende-zu-Ende-Routing überhaupt möglich wird, muss zudem die NAT-Problematik gelöst werden, indem entweder der Client von der "äußeren IP" weiß (z. B. via STUN: Simple Traversal of UDP through NATs, RFC 3489) oder die SIP-Messages an der Netzwerkgrenze "umgeschrieben" werden (z. B. per Application Level Gateway).

Abbildung 3: Der Verbindungsaufbau bei VoIP-Telefonaten erfolgt typischerweise über ein SIP-Proxy. Nach dem Aushandeln der Verbindungsparamerter erfolgt das eigentliche Telefonat jedoch direkt zwischen den Anwendersystemen (Peer-to-Peer).

Angriffe

Abgesehen von den "vererbten" Bedrohungen der IP-Ebene (Denial-of-Service, Mitlesen von Paketen, IP-Spoofing usw.) bestehen bei SIP/VoIP auch spezifische Angriffsmöglichkeiten in der Anwendungsschicht.

SIP-Spam

Gleich drei verschiedene Arten von SIP-Spam sind mittlerweile in der Diskussion: zwei Spam-Varianten, die auf Instant-Messaging-(IM-)Funktionen von SIP zielen und entweder Nachrichten zustellen oder eine Aufnahme in die IM-Kontaktliste erfragen, sowie Telemarketer-Spam, der aus massenhaften Invite-Anfragen besteht. Schätzungen zufolge könnte diese Art der telefonischen Kontaktaufnahme bei den Kosten um bis zu drei Größenordnungen billiger sein als traditioneller Telemarketing-"Spam".

Neben den Belästigungen bei direkter Erreichbarkeit könnte SIP-Spam auch zu Problemen mit Anrufbeantworterfunktionen führen: Häufig übermitteln Unternehmenslösungen aufgezeichnete Nachrichten als WAV-Datei per E-Mail an den Anwender. Da eine 30-sekündige Sprachnachricht durchaus ein halbes Megabyte groß werden kann, wäre eine Vielzahl solcher (Spam-)Voicemails eine deutliche Belastung für das Mail-System (Voicemail Bombing). Zudem könnte eine große Zahl von Spam-Voicemails, vor allem bei Abfrage per Mobiltelefon, faktisch den Anrufbeantworter lahm legen, da man zwischen den Spams die erwünschten Nachrichten kaum noch finden würde.

Spoofing

Das Vortäuschen falscher Absenderidentitäten könnte bei SIP ähnliche Auswirkungen zeigen wie Phishing-Attacken bei E-Mail: Eine vorgebliche "Autorität" oder ein vermeintlich vertrauenswürdiger Anrufer könnten zur Preisgabe von Informationen führen oder sonstige Social-Engineering-Angriffe unterstützen.

Malformed Messages

Ende 2003 hatte in einem Test mit der PROTOS-SIP-Suite der finnischen Universität Oulu von neun SIP-basierten Telefonanlagen nur ein einziges System keine Schwachstellen bei der Nachrichtenbehandlung gezeigt ( [externer Link] www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/). Intoleranzen bezüglich "missgebildeter" Messages können dabei durchaus sicherheitsrelevante Folgen nach sich ziehen und beispielsweise zu Denial-of-Service-Attacken (DoS), Speicherfehlern oder Stack- oder Buffer-Overflows führen.

Registration Hijacking

Ohne starke Authentifizierung können Angreifer einige oder alle SIP-Anwender bei einem Anbietersystem de-registrieren; diese User würden dann keine weiteren Anrufe mehr empfangen können. Umgekehrt wäre es auch denkbar, für eine große Zahl vorgeblicher Teilnehmer denselben Host zu registrieren, um VoIP-Daten auf dieses System zu lenken – der Registrar und seine Proxy-Server könnten dabei als "Verstärker" für einen Denial-of-Service-Angriff dienen. Je nach Implementierung ist es zudem denkbar, Rufnummern unbefugt umzuleiten oder sogar bestehende Gespräche umzulenken.

Cancel

Die Cancel-Nachricht sorgt im SIP für den Abbruch einer Suchanfrage oder eines Rufaufbaus. Falls ein Angreifer zur "richtigen" Zeit eine Cancel-Message schickt, während das Opfer eine Invite-Nachricht erhält, kann dies ebenfalls zu Unerreichbarkeit führen. Eine Cancel-Nachricht kann entweder von einem User Agent oder einem Proxy ausgehen und durch einen User-Agent-Client nicht auf einfache Weise authentifiziert werden (ggf. per S/MIME möglich).

SIP-Sicherheit

Eine grundlegende Authentifizierung und Autorisierung der Teilnehmer ist im SIP per Digest Authentification vorgesehen, die analog zu HTTP-Digests arbeitet; hiermit ist sowohl eine Authentifizierung der (Proxy-)Server als auch einzelner User möglich. Darüber hinaus sieht der Standard Signatur- und Verschlüsselungsmöglichkeiten der Nachrichten (SIP-Bodies, z. B. SDP Messages) per S/MIME vor, was aber eine Public-Key-Infrastruktur (PKI) erfordert. Zur Sicherung der SIP-Header ist zudem ein Tunneling-Modus definiert, der ebenfalls auf S/MIME zurückgreift.

Auch für die nachfolgende Kommunikation zwischen den Anwendern liegt bei der IETF ein Proposed Standard mit erweiterten Sicherheitsfunktionen vor: Das Secure Real-time Transport Protocol (SRTP, RFC 3711) erweitert RTP um Vertraulichkeit, Message Authentication und Wiedereinspielsicherheit (Replay Protection). SRTP wäre an sich ideal für VoIP-Daten geeignet, da es mit Header-Komprimierung zusammenarbeiten kann und keine Effekte auf die IP-Bandbreitensteuerung (Quality of Service, QoS) hat. Bislang unterstützen allerdings nur sehr wenige Anbieter SRTP, da derzeit eine Implementierung ohne Beeinträchtigungen der Latenzzeiten schwierig ist, somit also zu merklichen Verzögerungen führen kann.

Aktuelle VoIP-Systeme verlagern jedoch insgesamt den Sicherheits-Fokus eher auf die Transportschicht, vorrangig auf Virtual Private Networks (VPNs) mit IPSec. Ein solcher VPN-Tunnel schützt zwar eine VoIP-Verbindung gegen "äußere" Angriffe. Dieses Vorgehen hat aber auch den deutlichen Nachteil, dass es den Teilnehmerkreis auf (im Vorhinein bekannte) VPN-Teilnehmer beschränkt.

Zur Verdeutlichung möge ein Vergleich mit der klassischen Telefonie dienen: Wenn wir ein Festnetz- oder Mobiltelefon benutzen, erwarten wir jedes andere Telefon auf dieser Welt erreichen zu können, dessen Nummer uns bekannt ist, egal welchen Anbieter der andere Teilnehmer nutzt. Obwohl es keine garantierte Sicherheit gegen Abhören gibt, vermuten doch die meisten Nutzer, dass die physische "Eigenständigkeit" der Telekommunikationsnetze und klare gesetzliche Regelungen für ein akzeptables Sicherheitsniveau sorgen.

Dasselbe Szenario weltweit erreichbarer Teilnehmer liefert bei VoIP im Hinblick auf die Sicherheit jedoch ein anderes Bild: VoIP-Anrufe erscheinen aufgrund der software-gestützten Abhörbarkeit mittels leicht erhältlicher Packet Sniffer (vgl. S. 58), dem einfacheren "Identitätsdiebstahl" im Netz sowie unklarer Gesetze erheblich anfälliger für Attacken. Setzt nun ein Anbieter sicherheitstechnisch auf die Transportschicht, indem er ein IPSec-VPN schafft, so ist der Anwender zwar gesichert an das VoIP-Netz des Providers angeschlossen. Dieses "sichere Netz" teilt er aber auch mit jedem anderen angeschlossenen Teilnehmer – und innerhalb dieses Netzes hilft keine Transportschicht-Sicherung gegen Angriffe anderer Teilnehmer! Im Falle einer weltweiten Erreichbarkeit dürfte hier nicht viel Sicherheit übrig bleiben, was ein Überdenken der aktuell genutzten Strategien nahelegt.

Andrew Graydon ist Vice President Technology bei BorderWare Technologies Inc. und Chairman des VoIP Security Requirements Committee der VoIP Security Alliance.