entwickler.com

Wie angekündigt geht es diese Woche um Denial-of-Service-Angriffe (DoS) auf TCP/IP. Dazu können Schwächen in den Protokollen oder Implementierungsfehler in den Systemen ausgenutzt werden. Die einfachste Möglichkeit eines DoS-Angriffs ist das Senden einer großen Anzahl von SYN-Paketen. Diese werden vom Opfer mit einem SYN/ACK-Paket beantwortet und eine TCP-Verbindung wird reserviert. Der Angreifer antwortet auf die SYN/ACK-Pakete nicht, sodass der 3-Wege-Handshake nicht vollendet wird. Die dadurch erzeugten halboffenen TCP-Verbindungen belegen beim Opfer Ressourcen, sodass nach einiger Zeit keine weiteren Verbindungen mehr angenommen werden können. Ein derartiger Angriff wird SYN-Flooding genannt.

Ein weiterer Flooding-Angriff arbeitet mit UDP-Paketen. Das verbindungslose Protokoll UDP besitzt keine Möglichkeit, den Empfang eines gesendeten Pakets zu kontrollieren. Während TCP in der Lage ist, auf eine verzögerte Empfangsbestätigung mit dem Senken der Sendehäufigkeit zu reagieren, sendet UDP unverändert weiter. Da UDP-Pakete Vorrang vor TCP-Paketen haben, belegt der UDP-Verkehr nach einiger Zeit die gesamte Bandbreite einer Verbindung und unterbindet damit den TCP-Verkehr.

Das einfachste Beispiel für einen solchen UDP-DoS-Angriff ist ein 'chargen-Angriff'. Dazu wird der Zeichen erzeugende Dienst chargen eines Rechners mit dem die empfangenen Daten reflektierenden Dienst echo eines anderen Rechners verbunden. Der Angreifer sendet UDP-Pakete zum chargen-Port (19) seines Opfers und gibt als Quelle den echo-Port (7) und eine ggf. gefälschte Quelladresse an. Der so erzeugte 'UDP Packet Storm' kann bei geeigneter Wahl der IP-Adressen ein ganzes Netzwerk lahmlegen.

Ein weiterer DoS-Angriff ist über das Protokoll ICMP möglich. Wird ein Paket an eine Broadcast-Adresse geschickt, wird es an jeden Rechner im betreffenden Netzwerk weitergeleitet. Ein Angreifer kann eine Folge von ICMP-Echo-Paketen (ping) mit der IP-Adresse des gewünschten Opfers als Quelle an die Broadcast-Adresse des Netzwerks des Opfers senden. Alle Rechner im betroffenen Netzwerk antworten darauf mit einem ICMP-ECHO-REPLY-Paket an das Opfer, das davon überflutet wird. Der Broadcast dient dabei als Multiplikator: Wenn der Angreifer z.B. 1.000 Pakete/Sekunde an die Broadcast-Adresse sendet, auf die 100 Rechner antworten, empfängt das Opfer 100.000 Pakete/Sekunde. Ein solcher Angriff wird nach dem zum Angriff verwendeten Programm Smurf-Angriff genannt.

Das Verfahren wurde unter dem Namen Fraggle-Angriff auf das Protokoll UDP übertragen. Fraggle verwendet statt ICMP-  UDP-Echo-Pakete, das Programm wurde lediglich für die Verwendung des Protokolls UDP umgeschrieben.

Smurf- und Fraggle-Angriffe können z.B. für DoS-Angriffe auf Intrusion-Detection- oder -Prevention-Systeme eingesetzt werden, da der Aufwand für den Angreifer relativ gering ist (s. About Security #46). Die Angriffe können verhindert werden, indem Broadcast-Pakete nicht in das lokale Netz weitergeleitet werden.

Ausnutzung von Implementierungsfehlern
Beim 'Ping of Death'-Angriff wurde eine Schwachstelle in der Implementierung vieler TCP/IP-Stacks ausgenutzt. IP-Pakete können einschließlich Header bis zu 65.535 Bytes lang sein. Pakete, die größer als die maximale Paketgröße des verwendeten Transportmediums sind, werden in Fragmente zerlegt, die vom Empfänger zusammengesetzt werden. Dabei bestimmt ein Offset-Wert die Position der einzelnen Fragmente. Wurde für das letzte Fragment ein Offset-Wert angegeben, der zusammen mit der Fragmentgröße einen größeren Wert als 65.535 Bytes ergab, kam es zu einem Pufferüberlauf. Der Name 'Ping of Death' entstand aus der Tatsache, dass die Schwachstelle meist über ICMP-Echo-Pakete (ping) ausgenutzt wurde.

Ähnlich arbeitet der Teardrop-Angriff: Die Fragmente wurden so erzeugt, dass sie sich überlappen, d.h. das zweite Fragment im ersten enthalten ist. Beim Zusammensetzen der Fragmente erkannten manche Systeme diesen Sonderfall nicht und er kam zu einem Absturz.

Auch der Land-Angriff nutzt einen Implementierungsfehler, ist aber deutlich komplexer. Der Angreifer schickt ein SYN-Paket, bei dem Quell- und Zieladresse sowie -port identisch sind, an einen offenen Port des Opfers. Dieses antwortet mit einem SYN/ACK-Paket an die Quelle (d.h. sich selbst). Durch den Implementierungsfehler wurde dieses SYN/ACK-Paket als SYN-Paket betrachtet und erneut mit einem SYN/ACK-Paket beantwortet. Die dadurch entstehende Endlosschleife legte das System lahm.

Sowohl 'Ping of Death'- als auch Teardrop-Angriffe funktionieren heutzutage nicht mehr, da die Implementierungen der TCP/IP-Stacks entsprechend angepasst wurden. Einige Versionen für Windows waren 2005 noch durch Land-Angriffe verwundbar, die Schwachstelle wurde von Microsoft mit dem Security Bulletin MS05-019 behoben.

In der nächsten Woche wird das Beispiel aus About Security #57 zum Abschluss gebracht und das Hijacking von TCP/IP-Verbindungen beschrieben.

Carsten Eilers

• About Security #1: IT-Sicherheit – Was ist das eigentlich?
• About Security #2: Angriffsszenarien
• About Security #3: Eindringlinge abwehren
• About Security #4: Gefährdung aus der Peripherie
• About Security #5: Der Pufferüberlauf
• About Security #6: Ausnutzung von Pufferüberlauf-Schwachstellen
• About Security #7: Gegenwehr – Pufferüberläufe verhindern
• About Security #8: Vorbeugung – Pufferüberläufe verhindern
• About Security #9: Sourcecode Audit – Pufferüberläufe finden
• About Security #10: Software-Audit – Schwachstellensuche in Binaries
• About Security #11: SQL-Injection
• About Security #12: SQL-Injection verhindern
• About Security #13: Mit Stored Procedures gegen SQL-Injection
• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #16: Skriptcode einschleusen
• About Security #17: HTTP Request Smuggling
• About Security #18: Spielarten des HTTP Request Smuggling, 1
• About Security #19: Spielarten des HTTP Request Smuggling, 2
• About Security #20: HTTP Request Smuggling erkennen und verhindern
• About Security #21: HTTP Response Splitting, 1
• About Security #22: HTTP Response Splitting, 2
• About Security #23: Caches vergiften
• About Security #24: Caches indirekt vergiften
• About Security #25: Entführen von Webseiten
• About Security #26: Gefahren für Webanwendungen
• About Security #27: Gefahren für Webserver
• About Security #28: Standorte für Webserver
• About Security #29: Die Firewall, 1
• About Security #30: Die Firewall, 2
• About Security #31: Die Firewall, 3
• About Security #32: Die Firewall, 4
• About Security #33: Die Firewall, 5
• About Security #34: Die Firewall, 6
• About Security #35: Die Firewall, 7
• About Security #36: Die Firewall, 8
• About Security #37: Logfiles – Welche Daten speichern?
• About Security #38: Logfiles – Wie auswerten?
• About Security #39: Paketfilter-Logfiles manuell auswerten
• About Security #40: HTTP-Proxy-Logfiles manuell auswerten,1
• About Security #41: HTTP-Proxy-Logfiles manuell auswerten, 2
• About Security #42: Intrusion-Detection-Systeme – Grundlagen
• About Security #43: Intrusion-Detection-Systeme – Positionierung
• About Security #44: IDS-Kommunikation
• About Security #45: IDS in hochverfügbaren Netzen
• About Security #46: Angriffe auf IDS
• About Security #47: Beispiele für IDS-Regeln
• About Security #48: Umsetzung der IDS-Beispiele mit Snort
• About Security #49: Intrusion Prevention
• About Security #50: Honeypots
• About Security #51: Ein Honeypot – Honeyd
• About Security #52: Firewall, IDS, IPS & Honeypot
• About Security #53: Security Policy
• About Security #54: Security Policy, 1
• About Security #55: Security Policy, 2
• About Security #56: Security Policy, 3
• About Security #57: Angriffe auf TCP/IP - Spoofing