CVE-2004-0230 — Vermutung von TCP-Sequenznummern und Injektion von RST-Paketen

CVE-2004-0230 — Vermutung von TCP-Sequenznummern und Injektion von RST-Paketen

30212
Created On 09/26/18 13:44 PM - Last Modified 06/01/23 07:13 AM


Resolution


TCP, wenn es eine große Fenstergröße verwendet, erleichtert es entfernten Angreifern, Sequenznummern zu erraten und einen Denial of Service (Verbindungsverlust) zu persistenten TCP-Verbindungen zu verursachen, indem Sie immer wieder ein TCP-RST-Paket einspritzt, insbesondere in Protokollen, die langlebige Verbindungen, wie BGP.

 

Quellen:

http://CVE.mitre.org/cgi-bin/cvename.cgi?Name=CVE-2004-0230

http://www.RFC-Base.org/txt/RFC-5961.txt

 

Damit der Angriff erfolgreich ist, muss der RST im gültigen Empfangs Fenster sein. Der Angreifer würde versuchen, viele RST-Segmente zu schmieden, um zu versuchen, den Raum möglicher Fenster zu bedecken, indem er in jedem potentiellen Fenster ein Paket auslegt. Um dies zu tun, muss der Angreifer mehrere Informationen haben oder erraten:

 

  • 4-Tuple (IP-Adresse und TCP-Port für beide Seiten der Verbindung).
  • Sequenznummer, die im RST verwendet wird.
  • Fenstergröße, die die beiden Endpunkte verwenden. Dieser Wertmuss nicht die exakte Fenstergröße sein, da ein kleinerer Wert, der anstelle des korrekten verwendet wird, nur dazu führt, dass der Angreifer mehr Segmente generiert, bevor er in diesem Unheil erfolgreich ist.   Häufig kann der Angreifer, mit einer angemessenen Gewissheit (in Kenntnis der Anwendung, die unter Beschuss steht), eine sehr enge Annäherung an die tatsächliche Fenstergröße, die auf der Verbindung verwendet wird, finden.
  • Das Empfangs Fenster ist die Anzahl der Bytes, die ein Absender übertragen kann, ohne eine Bestätigung zu erhalten.

 

Nach der Zusammenstellung der obigen Informationen beginnt der Angreifer, gefälschte TCP-Segmente mit dem RST-Bit-Satz und einer erraten TCP- Sequenznummer zu senden.  Jedes Mal, wenn ein neues RST-Segment gesendet wird, wird die Sequenznummer-Vermutung durch die Fenstergröße erhöht.

 

Jede Anwendung hat die Kontrolle über eine Reihe von Faktoren, die die Wahrscheinlichkeit eines erfolgreichen Spuck Angriffs drastisch beeinflussen.  Zu diesen Faktoren gehören:

 

  • Fenstergröße
  • Server Port Number
  • Kunden Portnummer

 

Mit anderen Worten: die durchschnittliche Anzahl der Versuche, ein RST-Segment einzuschleusen, ist (2 ^ 31/Fenster) und nicht die 2 ^ 31 (2 ^ 31 = 2147483648/32.768 = 65536). Desto größer das Fenster, desto weniger Vermutungen wird es annehmen.

 

Wenn wir Zahlen in diese Formel ersetzen, sehen wir, dass für eine Fenstergröße von 32.768 durchschnittlich 65.536 Pakete übertragen werden müssen, um ein TCP-Segment zu "Spoof", das für einen TCP-Empfänger akzeptabel ist.  Eine Fenstergröße von 65.535 reduziert diese noch weiter auf 32.768 Pakete.  Bei den heutigen Zugriffs Bandbreiten ist ein Angriff dieser Größe machbar.

 

Mit einem Anstieg der Bandbreite zu Hause und im Büro ist nur zu erwarten, dass die Werte für Standard-Fenstergrößen weiter steigen, um die neu verfügbare Bandbreite besser zu nutzen.

 

Eine TCP-Verbindung, die nur wenige kurze Pakete dauert, wie es oft für den Web-Traffic der Fall ist, wäre nicht Gegenstand eines solchen Angriffs, da die Verbindung nicht lange genug hergestellt werden kann, damit ein Angreifer genügend Verkehr erzeugt. Allerdings werden einige Anwendungen, wie BGP, als potenziell am stärksten von dieser Verwundbarkeit betroffen beurteilt. BGP setzt auf eine persistente TCP-Session zwischen BGP-Kollegen. Das Zurücksetzen der Verbindung kann aufgrund der Notwendigkeit, Routing-Tabellen und Routen Klappen neu zu erstellen, zu einer Unverfügbarkeit führen. Für Anwendungen, die die TCP-MD5-Option, wie BGP, verwenden können, macht diese Option die in dieser Spezifikation beschriebenen Angriffe effektiv unmöglich.

 

RFC 5961 Bedrohungsminderung wurde in Pan-OS implementiert 6.0.0



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CllyCAC&lang=de&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language