18. Security Considerations (Sicherheitsüberlegungen)

In einem ICE-System sind verschiedene Arten von Angriffen möglich. In diesem Abschnitt werden diese Angriffe und ihre Gegenmaßnahmen betrachtet. Diese Gegenmaßnahmen umfassen:

• Verwendung von ICE in Verbindung mit sicheren Signalisierungstechniken wie SIPS.

• Begrenzung der Gesamtzahl der Konnektivitätsprüfungen auf 100 und optional Begrenzung der Anzahl der Kandidaten, die sie in einem Angebot oder einer Antwort akzeptieren.

18.1. Attacks on Connectivity Checks (Angriffe auf Konnektivitätsprüfungen)

Ein Angreifer könnte versuchen, die STUN-Konnektivitätsprüfungen zu stören. Letztendlich täuschen alle diese Angriffe einen Agenten vor, etwas Falsches über die Ergebnisse der Konnektivitätsprüfungen zu denken. Die möglichen falschen Schlussfolgerungen, die ein Angreifer versuchen und verursachen kann, sind:

False Invalid (Falsch ungültig): : Ein Angreifer kann ein Paar von Agenten täuschen, zu denken, dass ein Kandidatenpaar ungültig ist, obwohl dies nicht der Fall ist. Dies kann verwendet werden, um einen Agenten dazu zu bringen, einen anderen Kandidaten zu bevorzugen (z. B. einen vom Angreifer eingeschleusten) oder einen Anruf zu stören, indem alle Kandidaten zum Scheitern gezwungen werden.

False Valid (Falsch gültig): : Ein Angreifer kann ein Paar von Agenten täuschen, zu denken, dass ein Kandidatenpaar gültig ist, obwohl dies nicht der Fall ist. Dies kann dazu führen, dass ein Agent mit einer Sitzung fortfährt, aber dann keine Medien empfangen kann.

False Peer Reflexive Candidate (Falscher Peer-Reflexive-Kandidat): : Ein Angreifer kann einen Agenten dazu bringen, einen neuen Peer-Reflexive-Kandidaten zu entdecken, obwohl er dies nicht hätte tun sollen. Dies kann verwendet werden, um Medienströme zu einem Denial-of-Service (DoS)-Ziel oder zum Angreifer umzuleiten, um sie abzuhören oder zu anderen Zwecken.

False Valid on False Candidate (Falsch gültig auf falschem Kandidaten): : Ein Angreifer hat einen Agenten bereits davon überzeugt, dass es einen Kandidaten mit einer Adresse gibt, die nicht tatsächlich zu diesem Agenten routet (z. B. durch Einschleusen eines falschen Peer-Reflexive-Kandidaten oder falschen Server-Reflexive-Kandidaten). Er muss dann einen Angriff starten, der die Agenten zwingt zu glauben, dass dieser Kandidat gültig ist.

Wenn ein Angreifer einen falschen Peer-Reflexive-Kandidaten oder falsch gültig auf einem falschen Kandidaten verursachen kann, kann er jeden der in [RFC5389] beschriebenen Angriffe starten.

Um das falsch ungültige Ergebnis zu erzwingen, muss der Angreifer warten, bis die Konnektivitätsprüfung von einem der Agenten gesendet wird. Wenn dies der Fall ist, muss der Angreifer eine gefälschte Antwort mit einer nicht behebbaren Fehlerantwort, wie z. B. 400, einschleusen. Da der Kandidat jedoch tatsächlich gültig ist, kann die ursprüngliche Anfrage den Peer-Agenten erreichen und zu einer Erfolgsantwort führen. Der Angreifer muss dieses Paket oder seine Antwort durch einen DoS-Angriff, eine Layer-2-Netzwerkstörung oder eine andere Technik zum Verwerfen zwingen. Wenn er dies nicht tut, erreicht die Erfolgsantwort auch den Urheber und alarmiert ihn über einen möglichen Angriff. Glücklicherweise wird dieser Angriff durch den STUN-Kurzzeit-Anmeldeinformationsmechanismus vollständig gemildert. Der Angreifer muss eine gefälschte Antwort einschleusen, und damit diese Antwort verarbeitet werden kann, benötigt der Angreifer das Passwort. Wenn die Angebots-/Antwort-Signalisierung gesichert ist, hat der Angreifer das Passwort nicht und seine Antwort wird verworfen.

Das Erzwingen des gefälschten gültigen Ergebnisses funktioniert auf ähnliche Weise. Der Agent muss auf die Binding-Anfrage von jedem Agenten warten und eine gefälschte Erfolgsantwort einschleusen. Der Angreifer muss sich keine Sorgen machen, die tatsächliche Antwort zu stören, da sie, wenn der Kandidat ungültig ist, vermutlich ohnehin nicht empfangen würde. Wie der gefälschte ungültige Angriff wird dieser Angriff jedoch durch den STUN-Kurzzeit-Anmeldeinformationsmechanismus in Verbindung mit einem sicheren Angebots-/Antwortaustausch gemildert.

Das Erzwingen des Ergebnisses des falschen Peer-Reflexive-Kandidaten kann entweder mit gefälschten Anfragen oder Antworten oder mit Wiederholungen erfolgen. Wir betrachten zuerst den Fall der gefälschten Anfragen und Antworten. Es erfordert, dass der Angreifer eine Binding-Anfrage an einen Agenten mit einer Quell-IP-Adresse und einem Port für den falschen Kandidaten sendet. Darüber hinaus muss der Angreifer auf eine Binding-Anfrage vom anderen Agenten warten und eine gefälschte Antwort mit einem XOR-MAPPED-ADDRESS-Attribut generieren, das den falschen Kandidaten enthält. Wie die anderen hier beschriebenen Angriffe wird dieser Angriff durch die STUN-Nachrichtenintegritätsmechanismen und sichere Angebots-/Antwortaustausche gemildert.

Das Erzwingen des Ergebnisses des falschen Peer-Reflexive-Kandidaten mit Paketwiederholungen ist anders. Der Angreifer wartet, bis einer der Agenten eine Prüfung sendet. Er fängt diese Anfrage ab und wiederholt sie gegenüber dem anderen Agenten mit einer gefälschten Quell-IP-Adresse. Er muss auch verhindern, dass die ursprüngliche Anfrage den Remote-Agenten erreicht, entweder indem er einen DoS-Angriff startet, um das Verwerfen des Pakets zu verursachen, oder indem er es mithilfe von Layer-2-Mechanismen zum Verwerfen zwingt. Das wiederholte Paket wird beim anderen Agenten empfangen und akzeptiert, da die Integritätsprüfung bestanden wird (die Integritätsprüfung kann und deckt die Quell-IP-Adresse und den Port nicht ab). Es wird dann darauf geantwortet. Diese Antwort enthält eine XOR-MAPPED-ADDRESS mit dem falschen Kandidaten und wird an diesen falschen Kandidaten gesendet. Der Angreifer muss sie dann empfangen und an den Urheber weiterleiten.

Der andere Agent initiiert dann eine Konnektivitätsprüfung gegenüber diesem falschen Kandidaten. Diese Validierung muss erfolgreich sein. Dies erfordert, dass der Angreifer ein falsch gültig auf einem falschen Kandidaten erzwingt. Das Einschleusen von gefälschten Anfragen oder Antworten, um dieses Ziel zu erreichen, wird mithilfe der Integritätsmechanismen von STUN und dem Angebots-/Antwortaustausch verhindert. Somit kann dieser Angriff nur durch Wiederholungen gestartet werden. Dazu muss der Angreifer die Prüfung gegenüber diesem falschen Kandidaten abfangen und gegenüber dem anderen Agenten wiederholen. Dann muss er die Antwort abfangen und diese ebenfalls zurückspielen.

Dieser Angriff ist sehr schwer zu starten, es sei denn, der Angreifer wird durch den gefälschten Kandidaten identifiziert. Dies liegt daran, dass der Angreifer Pakete abfangen und wiederholen muss, die von zwei verschiedenen Hosts gesendet wurden. Wenn sich beide Agenten in verschiedenen Netzwerken befinden (z. B. über das öffentliche Internet), kann dieser Angriff schwer zu koordinieren sein, da er gleichzeitig gegen zwei verschiedene Endpunkte in verschiedenen Teilen des Netzwerks erfolgen muss.

Wenn der Angreifer selbst durch den gefälschten Kandidaten identifiziert wird, ist der Angriff einfacher zu koordinieren. Wenn jedoch SRTP verwendet wird [RFC3711], kann der Angreifer die Medienpakete nicht abspielen, sondern nur verwerfen, wodurch der Medienstrom für den Anruf effektiv deaktiviert wird. Dieser Angriff erfordert jedoch, dass der Agent Pakete stört, um zu verhindern, dass die Konnektivitätsprüfung das Ziel erreicht. In diesem Fall ist es, wenn das Ziel darin besteht, den Medienstrom zu stören, viel einfacher, ihn einfach mit demselben Mechanismus zu stören, anstatt ICE anzugreifen.

18.2. Attacks on Server Reflexive Address Gathering (Angriffe auf die Erfassung von Server-Reflexive-Adressen)

ICE-Endpunkte verwenden STUN-Binding-Anfragen zum Erfassen von Server-Reflexive-Kandidaten von einem STUN-Server. Diese Anfragen werden in keiner Weise authentifiziert. Infolgedessen gibt es zahlreiche Techniken, die ein Angreifer anwenden kann, um dem Client einen falschen Server-Reflexive-Kandidaten bereitzustellen:

• Ein Angreifer kann das DNS kompromittieren, was dazu führt, dass DNS-Abfragen eine betrügerische STUN-Serveradresse zurückgeben. Dieser Server kann dem Client gefälschte Server-Reflexive-Kandidaten bereitstellen. Dieser Angriff wird durch DNS-Sicherheit gemildert, obwohl DNS-SEC nicht erforderlich ist, um ihn zu beheben.

• Ein Angreifer, der STUN-Nachrichten beobachten kann (wie ein Angreifer in einem gemeinsam genutzten Netzwerksegment wie WLAN), kann eine gefälschte Antwort einschleusen, die gültig ist und vom Client akzeptiert wird.

• Ein Angreifer kann einen STUN-Server mithilfe eines Virus kompromittieren und ihn dazu bringen, Antworten mit falschen abgebildeten Adressen zu senden.

Eine falsche abgebildete Adresse, die durch diese Angriffe gelernt wurde, wird im ICE-Austausch als Server-Reflexive-Kandidat verwendet. Damit dieser Kandidat tatsächlich für Medien verwendet wird, muss der Angreifer auch die Konnektivitätsprüfungen angreifen und insbesondere ein falsch gültig auf einem falschen Kandidaten erzwingen. Dieser Angriff ist sehr schwer zu starten, wenn die falsche Adresse eine vierte Partei identifiziert (weder den Anbieter, den Antwortenden noch den Angreifer), da er das Angreifen der von jedem Agenten in der Sitzung generierten Prüfungen erfordert und durch SRTP verhindert wird, wenn er den Angreifer selbst identifiziert.

Wenn der Angreifer beschließt, die Konnektivitätsprüfungen nicht anzugreifen, kann er im schlimmsten Fall verhindern, dass der Server-Reflexive-Kandidat verwendet wird. Wenn der Peer-Agent jedoch mindestens einen Kandidaten hat, der für den angegriffenen Agenten erreichbar ist, stellen die STUN-Konnektivitätsprüfungen selbst einen Peer-Reflexive-Kandidaten bereit, der für den Austausch von Medien verwendet werden kann. Peer-Reflexive-Kandidaten werden im Allgemeinen gegenüber Server-Reflexive-Kandidaten bevorzugt. Daher hat ein Angriff allein auf die STUN-Adresserfassung normalerweise überhaupt keine Auswirkungen auf eine Sitzung.

18.3. Attacks on Relayed Candidate Gathering (Angriffe auf die Erfassung von Relayed-Kandidaten)

Ein Angreifer könnte versuchen, die Erfassung von Relayed-Kandidaten zu stören, indem er den Client zwingt zu glauben, dass er einen falschen Relayed-Kandidaten hat. Austausche mit dem TURN-Server werden unter Verwendung einer langfristigen Anmeldeinformation authentifiziert. Folglich funktioniert das Einschleusen von gefälschten Antworten oder Anfragen nicht. Darüber hinaus sind Allocate-Anfragen im Gegensatz zu Binding-Anfragen nicht anfällig für Replay-Angriffe mit modifizierten Quell-IP-Adressen und Ports, da die Quell-IP-Adresse und der Port nicht verwendet werden, um dem Client seinen Relayed-Kandidaten bereitzustellen.

TURN-Server sind jedoch anfällig für DNS-Angriffe oder Viren, die auf den TURN-Server abzielen, um ihn in einen Zombie- oder Schurkenserver zu verwandeln. Diese Angriffe können durch DNS-SEC und durch gute Box- und Softwaresicherheit auf TURN-Servern gemildert werden.

Selbst wenn ein Angreifer den Client dazu gebracht hat, an einen falschen Relayed-Kandidaten zu glauben, führen die Konnektivitätsprüfungen dazu, dass ein solcher Kandidat nur verwendet wird, wenn sie erfolgreich sind. Somit muss ein Angreifer wie oben ein falsch gültig auf einem falschen Kandidaten starten, was ein sehr schwer zu koordinierender Angriff ist.

18.4. Attacks on the Offer/Answer Exchanges (Angriffe auf die Angebots-/Antwortaustausche)

Ein Angreifer, der die Angebots-/Antwortaustausche selbst modifizieren oder stören kann, kann mit ICE leicht eine Vielzahl von Angriffen starten. Er könnte Medien auf ein Ziel eines DoS-Angriffs lenken, er könnte sich selbst in den Medienstrom einfügen usw. Diese ähneln den allgemeinen Sicherheitsüberlegungen für Angebots-/Antwortaustausche, und die Sicherheitsüberlegungen in RFC 3264 [RFC3264] gelten. Diese erfordern Techniken für Nachrichtenintegrität und Verschlüsselung für Angebote und Antworten, die durch den SIPS-Mechanismus [RFC3261] erfüllt werden, wenn SIP verwendet wird. Daher wird die Verwendung von SIPS mit ICE EMPFOHLEN (RECOMMENDED).

18.5. Insider Attacks (Insider-Angriffe)

Zusätzlich zu Angriffen, bei denen der Angreifer eine dritte Partei ist, die versucht, gefälschte Angebote, Antworten oder STUN-Nachrichten einzufügen, sind mit ICE mehrere Angriffe möglich, wenn der Angreifer ein authentifizierter und gültiger Teilnehmer am ICE-Austausch ist.

18.5.1. The Voice Hammer Attack (Der Voice-Hammer-Angriff)

Der Voice-Hammer-Angriff ist ein Verstärkungsangriff. Bei diesem Angriff initiiert der Angreifer Sitzungen zu anderen Agenten und fügt böswillig die IP-Adresse und den Port eines DoS-Ziels als Ziel für den im SDP signalisierten Medienverkehr ein. Dies verursacht eine erhebliche Verstärkung; ein einzelner Angebots-/Antwortaustausch kann eine anhaltende Flut von Medienpaketen erzeugen, möglicherweise mit hohen Raten (berücksichtigen Sie Videoquellen). Dieser Angriff ist nicht spezifisch für ICE, aber ICE kann helfen, Abhilfe zu schaffen.

Insbesondere wenn ICE verwendet wird, führt der Agent, der das bösartige SDP empfängt, zuerst Konnektivitätsprüfungen zum Ziel der Medien durch, bevor er Medien dorthin sendet. Wenn dieses Ziel ein Drittanbieter-Host ist, werden die Prüfungen nicht erfolgreich sein und Medien werden niemals gesendet.

Leider hilft ICE nicht, wenn es nicht verwendet wird. In diesem Fall könnte ein Angreifer das Angebot einfach ohne die ICE-Parameter senden. In Umgebungen, in denen die Menge der Clients bekannt ist und auf diejenigen beschränkt ist, die ICE unterstützen, kann der Server jedoch alle Angebote oder Antworten ablehnen, die keine ICE-Unterstützung anzeigen.

18.5.2. STUN Amplification Attack (STUN-Verstärkungsangriff)

Der STUN-Verstärkungsangriff ähnelt dem Voice Hammer. Anstatt dass Sprachpakete auf das Ziel gerichtet werden, werden STUN-Konnektivitätsprüfungen auf das Ziel gerichtet. Der Angreifer sendet ein Angebot mit einer großen Anzahl von Kandidaten, sagen wir 50. Der Antwortende empfängt das Angebot und beginnt seine Prüfungen, die auf das Ziel gerichtet sind und folglich niemals eine Antwort generieren. Der Antwortende startet alle Ta ms eine neue Konnektivitätsprüfung (sagen wir, Ta=20ms). Die Neuübertragungs-Timer sind jedoch aufgrund der großen Anzahl von Kandidaten auf eine große Zahl eingestellt. Infolgedessen werden Pakete in einem Intervall von einem alle Ta Millisekunden und dann mit zunehmenden Intervallen danach gesendet. Somit sendet STUN Pakete nicht mit einer Rate, die schneller ist als Medien gesendet würden, und die STUN-Pakete bleiben nur kurz bestehen, bis ICE für die Sitzung fehlschlägt. Dennoch ist dies ein Verstärkungsmechanismus.

Es ist unmöglich, die Verstärkung zu beseitigen, aber das Volumen kann durch eine Vielzahl von Heuristiken reduziert werden. Agenten SHOULD die Gesamtzahl der Konnektivitätsprüfungen, die sie durchführen, auf 100 begrenzen. Darüber hinaus MAY Agenten die Anzahl der Kandidaten begrenzen, die sie in einem Angebot oder einer Antwort akzeptieren.

Häufig zwingen Protokolle, die diese Art von Angriffen vermeiden möchten, den Initiator, auf eine Antwort zu warten, bevor er die nächste Nachricht sendet. Im Fall von ICE ist dies jedoch nicht möglich. Es ist nicht möglich, die folgenden zwei Fälle zu unterscheiden:

• Es gab keine Antwort, weil der Initiator verwendet wird, um einen DoS-Angriff gegen ein ahnungsloses Ziel zu starten, das nicht antworten wird.

• Es gab keine Antwort, weil die IP-Adresse und der Port für den Initiator nicht erreichbar sind.

Im zweiten Fall sollte bei der nächsten Gelegenheit eine weitere Prüfung gesendet werden, während im ersteren Fall keine weiteren Prüfungen gesendet werden sollten.

18.6. Interactions with Application Layer Gateways and SIP (Interaktionen mit Application Layer Gateways und SIP)

Application Layer Gateways (ALGs) sind Funktionen, die in einem NAT-Gerät vorhanden sind, die den Inhalt von Paketen inspizieren und modifizieren, um die NAT-Überquerung für Anwendungsprotokolle zu erleichtern. Session Border Controllers (SBCs) sind enge Cousins von ALGs, sind aber weniger transparent, da sie tatsächlich als SIP-Vermittler auf Anwendungsebene existieren. ICE hat Interaktionen mit SBCs und ALGs.

Wenn ein ALG SIP-fähig, aber nicht ICE-fähig ist, funktioniert ICE durch es hindurch, solange das ALG das SDP korrekt modifiziert. Eine korrekte ALG-Implementierung verhält sich wie folgt:

• Das ALG ändert die m- und c-Zeilen oder das rtcp-Attribut nicht, wenn sie externe Adressen enthalten.

• Wenn die m- und c-Zeilen interne Adressen enthalten, hängt die Änderung vom Status des ALG ab:

  Wenn das ALG bereits eine Bindung hergestellt hat, die einen externen Port einer internen IP-Adresse und einem Port zuordnet, die den Werten in den m- und c-Zeilen oder dem rtcp-Attribut entsprechen, verwendet das ALG diese Bindung, anstatt eine neue zu erstellen.

  Wenn das ALG noch keine Bindung hat, erstellt es eine neue und modifiziert das SDP, indem es die m- und c-Zeilen und das rtcp-Attribut neu schreibt.

Leider ist bekannt, dass viele ALGs in diesen Randfällen schlecht funktionieren. ICE versucht nicht, defekte ALGs zu umgehen, da dies außerhalb des Umfangs seiner Funktionalität liegt. ICE kann helfen, diese Bedingungen zu diagnostizieren, die sich oft als Nichtübereinstimmung zwischen dem Satz von Kandidaten und den m- und c-Zeilen und rtcp-Attributen zeigen. Das ice-mismatch-Attribut wird zu diesem Zweck verwendet.

ICE funktioniert am besten durch ALGs, wenn die Signalisierung über TLS ausgeführt wird. Dies verhindert, dass das ALG die SDP-Nachrichten manipuliert und den ICE-Betrieb stört. Implementierungen, von denen erwartet wird, dass sie hinter ALGs bereitgestellt werden, SHOULD einen TLS-Transport des SDP vorsehen.

Wenn ein SBC SIP-fähig, aber nicht ICE-fähig ist, hängt das Ergebnis vom Verhalten des SBC ab. Wenn er als richtiger Back-to-Back User Agent (B2BUA) fungiert, entfernt der SBC alle SDP-Attribute, die er nicht versteht, einschließlich der ICE-Attribute. Folglich erscheint der Anruf beiden Endpunkten so, als ob die andere Seite ICE nicht unterstützt. Dies führt dazu, dass ICE deaktiviert wird und Medien durch den SBC fließen, wenn der SBC dies angefordert hat. Wenn der SBC jedoch die ICE-Attribute ohne Änderung weitergibt, aber das Standardziel für Medien (enthalten in den m- und c-Zeilen und dem rtcp-Attribut) ändert, wird dies als ICE-Nichtübereinstimmung erkannt und die ICE-Verarbeitung wird für den Anruf abgebrochen. Es liegt außerhalb des Umfangs von ICE, als Werkzeug zum „Umgehen“ von SBCs zu fungieren. Wenn einer vorhanden ist, wird ICE nicht verwendet und die SBC-Techniken haben Vorrang.