16. Security Considerations (Sicherheitsüberlegungen)
16.1. Attacks against the Protocol (Angriffe gegen das Protokoll)
16.1.1. Outside Attacks (Externe Angriffe)
Ein Angreifer kann versuchen, STUN-Nachrichten während der Übertragung zu modifizieren, um eine STUN-Operation zum Scheitern zu bringen. Diese Angriffe gegen Anfragen und Antworten können durch den Nachrichtenintegritätsmechanismus unter Verwendung entweder des Kurzzeit- oder Langzeit-Credentials erkannt werden. Natürlich werden die manipulierten Pakete nach der Erkennung verworfen, was dazu führt, dass die STUN-Transaktion effektiv fehlschlägt. Dieser Angriff kann nur von einem Angreifer im Pfad gestartet werden.
Ein Angreifer, der STUN-Nachrichten während der Übertragung beobachten, aber nicht modifizieren kann (z.B. ein Angreifer auf einem gemeinsam genutzten Zugriffsmedium wie Wi-Fi), kann eine STUN-Anfrage sehen und dann sofort eine STUN-Antwort, typischerweise eine Fehlerantwort, senden, um die STUN-Verarbeitung zu stören. Für Nachrichten mit MESSAGE-INTEGRITY wird auch dieser Angriff verhindert. Einige Fehlerantworten, insbesondere solche im Zusammenhang mit der Authentifizierung, können jedoch nicht durch MESSAGE-INTEGRITY geschützt werden. Wenn STUN selbst über ein sicheres Transportprotokoll wie TLS ausgeführt wird, werden diese Angriffe vollständig gemildert.
Abhängig von der STUN-Verwendung können diese Angriffe von minimaler Bedeutung sein, und daher ist möglicherweise keine Nachrichtenintegrität erforderlich, um sie zu verhindern. Wenn beispielsweise STUN mit einem grundlegenden STUN-Server verwendet wird, um einen serverreflektierten Kandidaten für die Verwendung mit ICE zu entdecken, sind Authentifizierung und Nachrichtenintegrität nicht erforderlich, da diese Angriffe während der Konnektivitätsprüfungsphase erkannt werden. Die Konnektivitätsprüfungen selbst müssen jedoch geschützt werden, damit ICE insgesamt ordnungsgemäß funktioniert. Wie in Abschnitt 14 erläutert, beschreibt eine STUN-Verwendung, wann Authentifizierung und Nachrichtenintegrität erforderlich sind.
Da STUN HMAC mit einem gemeinsamen Geheimnis für Authentifizierung und Integritätsschutz verwendet, ist es anfällig für Offline-Wörterbuchangriffe. Bei Verwendung der Authentifizierung sollten (SHOULD) Passwörter gewählt werden, die nicht solchen Offline-Wörterbuchangriffen unterliegen. Die Sicherung des Kanals selbst mit TLS kann diese Angriffe mildern. STUN wird jedoch am häufigsten über UDP ausgeführt, und in diesen Fällen sind starke Passwörter die einzige Verteidigung gegen diese Angriffe.
16.1.2. Inside Attacks (Interne Angriffe)
Ein böswilliger Client könnte versuchen, einen DoS-Angriff gegen einen Server zu starten, indem er ihm eine große Anzahl von STUN-Anfragen sendet. Glücklicherweise können STUN-Anfragen von einem Server zustandslos verarbeitet werden, was solche Angriffe schwer zu starten macht.
Ein böswilliger Client kann einen STUN-Server als Reflektor verwenden, indem er ihm Anfragen mit einer gefälschten Quell-IP-Adresse und einem gefälschten Port sendet. In diesem Fall würde die Antwort an diese Quell-IP und diesen Port zugestellt. Es gibt keine Verstärkung der Anzahl der Pakete bei diesem Angriff (der STUN-Server sendet ein Paket für jedes vom Client gesendete Paket), obwohl es eine kleine Verstärkung der Datenmenge gibt, da STUN-Antworten typischerweise größer als Anfragen sind. Ingress-Quelladressfilterung kann helfen, diesen Angriff zu mildern.
Die Offenlegung der spezifischen Softwareversion des Agents durch das SOFTWARE-Attribut könnte es einem Angreifer ermöglichen, Angriffe leichter gegen Software zu starten, von der bekannt ist, dass sie Sicherheitslücken enthält. Implementierer sollten (SHOULD) die Verwendung des SOFTWARE-Attributs zu einer konfigurierbaren Option machen.
16.2. Attacks Affecting the Usage (Angriffe, die die Verwendung betreffen)
Dieser Abschnitt listet Angriffe auf, die gegen eine STUN-Verwendung gestartet werden könnten. Jede STUN-Verwendung muss (must) berücksichtigen, ob diese Angriffe anwendbar sind, und wenn ja, Gegenmaßnahmen diskutieren.
Die meisten Angriffe in diesem Abschnitt drehen sich darum, dass ein Angreifer die reflexive Adresse modifiziert, die der STUN-Client durch eine Binding-Anfrage/Antwort-Transaktion lernt. Da die Verwendung der reflexiven Adresse eine Funktion der Verwendung ist, sind die Anwendbarkeit und Abhilfen für diese Angriffe verwendungsspezifisch. Im häufigsten Fall kann ein Angreifer im Pfad die reflexive Adresse leicht modifizieren. Betrachten Sie zum Beispiel den häufigen Fall, in dem STUN direkt über UDP ausgeführt wird. In diesem Fall kann ein Angreifer im Pfad die Quell-IP-Adresse der Binding-Anfrage modifizieren, bevor sie am STUN-Server ankommt. Der STUN-Server gibt diese IP-Adresse dann im XOR-MAPPED-ADDRESS-Attribut an den Client zurück und sendet die Antwort an diese (gefälschte) IP-Adresse und diesen Port zurück. Wenn der Angreifer diese Antwort auch abfangen kann, kann er sie zum Client umleiten. Der Schutz vor diesem Angriff mit einer Nachrichtenintegritätsprüfung ist unmöglich, da der Nachrichtenintegritätswert die Quell-IP-Adresse nicht abdecken kann, da sie von zwischengeschalteten NATs änderbar sein muss. Stattdessen besteht eine Lösung zur Verhinderung der unten aufgeführten Angriffe darin, dass der Client die gelernte reflexive Adresse verifiziert, wie es in ICE [MMUSIC-ICE] getan wird. Andere Verwendungen können andere Mittel zur Verhinderung dieser Angriffe verwenden.
16.2.1. Attack I: Distributed DoS (DDoS) against a Target (Verteilter DoS-Angriff gegen ein Ziel)
Bei diesem Angriff stellt der Angreifer einem oder mehreren Clients dieselbe gefälschte reflexive Adresse zur Verfügung, die auf ein beabsichtigtes Ziel zeigt. Dies täuscht die STUN-Clients dahingehend, dass ihre reflexiven Adressen denen des Ziels entsprechen. Wenn die Clients diese reflexive Adresse verteilen, um darauf Verkehr zu empfangen (z.B. in einer SIP-Nachricht), wird der Verkehr stattdessen an das Ziel gesendet. Dieser Angriff kann eine erhebliche Verstärkung bewirken, insbesondere bei Verwendung mit Clients, die STUN zur Aktivierung von Multimedia-Anwendungen verwenden. Er kann jedoch nur gegen ein Ziel gestartet werden, für das Pakete vom STUN-Server zum Ziel über den Angreifer laufen, was die Fälle einschränkt, in denen er möglich ist.
16.2.2. Attack II: Silencing a Client (Einen Client zum Schweigen bringen)
Bei diesem Angriff stellt der Angreifer einem STUN-Client eine gefälschte reflexive Adresse zur Verfügung. Die bereitgestellte reflexive Adresse ist eine Transportadresse, die nirgendwohin führt. Als Ergebnis erhält der Client keines der Pakete, die er zu erhalten erwartet, wenn er die reflexive Adresse verteilt. Dieser Exploit ist für den Angreifer nicht sehr interessant. Er betrifft einen einzelnen Client, der häufig nicht das gewünschte Ziel ist. Darüber hinaus kann jeder Angreifer, der den Angriff starten kann, effektivere DoS-Angriffe gegen den Client auf andere Weise starten, z.B. indem er verhindert, dass der Client überhaupt eine Antwort vom STUN-Server oder sogar einem DHCP-Server erhält. Wie beim Angriff in Abschnitt 16.2.1 ist dieser Angriff nur möglich, wenn sich der Angreifer im Pfad für Pakete befindet, die vom STUN-Server zu dieser ungenutzten IP-Adresse gesendet werden.
16.2.3. Attack III: Assuming the Identity of a Client (Annehmen der Identität eines Clients)
Dieser Angriff ähnelt Angriff II. Die gefälschte reflexive Adresse zeigt jedoch auf den Angreifer selbst. Dies ermöglicht es dem Angreifer, Verkehr zu empfangen, der für den Client bestimmt war.
16.2.4. Attack IV: Eavesdropping (Abhören)
Bei diesem Angriff zwingt der Angreifer den Client, eine reflexive Adresse zu verwenden, die zu ihm selbst führt. Er leitet dann alle Pakete, die er erhält, an den Client weiter. Dieser Angriff würde es einem Angreifer ermöglichen, alle an den Client gesendeten Pakete zu beobachten. Um den Angriff zu starten, muss der Angreifer jedoch bereits in der Lage gewesen sein, Pakete vom Client zum STUN-Server zu beobachten. In den meisten Fällen (wie wenn der Angriff von einem Zugangsnetzwerk aus gestartet wird) bedeutet dies, dass der Angreifer bereits Pakete beobachten konnte, die an den Client gesendet wurden. Dieser Angriff ist daher nur nützlich, um Verkehr für Angreifer zu beobachten, die sich im Pfad vom Client zum STUN-Server befinden, aber im Allgemeinen nicht im Pfad von Paketen, die zum Client geroutet werden.
16.3. Hash Agility Plan (Hash-Agilitätsplan)
Diese Spezifikation verwendet HMAC-SHA-1 zur Berechnung der Nachrichtenintegrität. Wenn zu einem späteren Zeitpunkt HMAC-SHA-1 als kompromittiert befunden wird, kann die folgende Abhilfe angewendet werden.
Wir werden eine STUN-Erweiterung definieren, die ein neues Nachrichtenintegritätsattribut einführt, das mit einem neuen Hash berechnet wird. Clients müssten sowohl das neue als auch das alte Nachrichtenintegritätsattribut in ihre Anfragen oder Anzeigen einschließen. Neue Server würden das neue Nachrichtenintegritätsattribut verwenden, und alte Server würden das alte verwenden. Nach einer Übergangsphase, in der gemischte Implementierungen bereitgestellt werden, wird das alte Nachrichtenintegritätsattribut durch eine andere Spezifikation veraltet, und Clients würden aufhören, es in Anfragen einzuschließen.
Es ist auch wichtig zu beachten, dass der von HMAC verwendete Schlüssel selbst mit einem Hash des Benutzernamens und Passworts berechnet wird. Die Wahl des MD5-Hash wurde für Legacy-Datenbankspeicherung von Passwörtern in dieser Form getroffen. Wenn zukünftige Arbeiten feststellen, dass die Verwendung von HMAC mit MD5-Eingaben unsicher ist und ein anderer Hash benötigt wird, kann dieser Plan auch für diese Änderung verwendet werden. Dies würde jedoch erfordern, dass Administratoren ihre Datenbanken neu befüllen.