DDoS über TCP ist doch möglich - und das hat dramatische Folgen

[o1] DRMfan^^ am 18.08. 23:39
+2 -
Und woher kommt der Fehler? Sind das unvollständige Implementierungen von Webstandards und durch Updates zu beseitigen, oder ist die Schwäche inhärent in den Protokollen?

Nebenbei ist der Titel irreführend - natürlich war DDoS immer über TCP möglich - das merkt man zum Beispiel, wenn Konzertkarten zu einem angekündigten Zeitpunkt zum Verkauf freigeschaltet werden. Das eigentlich neue ist der TCP-Amplify für Angriffe.
[o2] Tomy Tom am 19.08. 09:27
+2 -
Sorry wenn ich da mal "blöd" nachfrage, aber wenn ich das jetzt richtig deute, müssten die Angreifer aber zunächst einmal die Firewall/NAT usw. übernehmen um dann entsprechende Angriffe zu starten.
Wäre dann nicht die Lösung das diese Geräte durch verbesserten Passwortschutz und entsprechende Updates sicherer gemacht werden?
[re:1] 0711 am 19.08. 09:37
+3 -
@Tomy Tom: die "zwischengeräte" werden nicht übernommen sondern die Pakete sind so gestaltet dass diese annehmen hier eine gültige TCP Verbindung zu haben auch wenn sie eigentlich nicht gültig ist was dann nicht mehr einfach nur abgelehnt wird sondern versucht wird passabel zu beantworten.
Wobei man sagen muss, so relevant wie im Artikel sind Spiegel Angriffe nicht, sie erleichtern einen Angriff mit relativ wenigen clients aber da botnetze immer größer werden ist das auch egal
[re:1] Tomy Tom am 19.08. 09:57
+1 -
@0711: Danke für die erklärung, damit wird's jetzt klarer. :-)
[re:2] dpazra am 19.08. 10:02
+7 -
@Tomy Tom: Disclaimer, ich habe das Paper bisher nur quergelesen und bin kein Experte für Netzwerkprotokolle. Falls du selber nachlesen möchtest, es heißt "Weaponizing Middleboxes for TCP Reflected Amplification".

Ich verstehe die Idee folgendermaßen: Sagen wir, Alice will Bob angreifen, aber will, dass bei Bob mehr Traffic ankommt als sie selbst verschicken kann. Bei UDP würde es sich folgendermaßen abspielen:
Alice zu Carol: Hallo, ich bin Bob, bitte schicke mir [großen Inhalt].
Carol zu Bob: [großer Inhalt]

Und bei TCP geht das bisher nicht, weil bei TCP immer erst eine gegenseitige Bestätigung vorausgeht, also würde es so laufen:
Alice zu Carol: Hallo, ich bin Bob.
Carol zu Bob: Hallo Bob, Prüfsumme X. (kurze Nachricht)
Bob: ? (ignoriert)
Alice zu Carol: Hallo Carol, hier ist Bob, bestätige Prüfsumme X, bitte schicke mir [großen Inhalt].
...

Das Problem ist hier natürlich, dass Alice die Prüfsumme raten müsste und das ist eine 32-Bit Zahl, also ist die Chance ca. 1 zu 4 Milliarden.

Die neue Idee ist folgende. Alice weiß, dass es eine Middlebox "Mike" gibt, die Pornografie filtern soll, z.B. eine nationale Firewall, und zwischen Verbindungen sitzt. Jetzt tut Alice folgendes.

Alice über Mike: Hallo Pornhub, hier ist Bob, bestätige Prüfsumme X, bitte schicke mir [irgendwas].
Mike zu Bob: [lange Fehlerseite darüber, dass Pornografie verboten ist] (viel größere Nachricht als Alice an Mike geschickt hat)

Das Problem ist, dass Mike nicht wirklich nach einer korrekten Implementierung von TCP agiert, sich nicht wirklich um die Prüfsumme X schert, die zwischen Bob und Pornhub hätte ausgetauscht werden müssen damit die empfangene Nachricht Sinn macht, sondern einfach sturr seine Blockantworten verschickt, unter der Annahme, dass (oder in Gleichgültigkeit darüber, ob) Bob und Pornhub schon eine gültige TCP-Verbindung haben.
[re:1] somedevdude am 19.08. 13:31
+3 -
@dpazra: Leider bin ich ein Pedant, das mit der Prüfsumme ist nicht ganz richtig.

Jeder Endpunkt in der Verbindung (Server und Client) generieren bei Verbindungsaufbau eine zufällige, 32-bit lange Zahl den Sie als Zähler benutzen, keine Prüfsumme. Dieser Zähler erhöht sich beim Senden bzw. beim Empfangen damit jeder Endpunkt weiß, dass noch keine Daten verloren gegangen sind, welche dann vom gegenüber erneut angefordert werden können.

Ansonst recht gut erklärt, dein ersten Beispiel ist praktisch SYN-Flooding ähnlich (Alice kontaktiert Carol als "Bob", Carol schickt Bob dann eine Antwort; wenn genug Server Carol als Bob kontaktieren, hat man ein recht einfaches, aber gut DDoS)
[re:1] dpazra am 19.08. 14:07
+3 -
@somedevdude: Wenn es einen guten Platz für Pedanterie gibt, dann bei IT-Sicherheitsfragen deshalb danke für die Korrektur!

Ja, das Beispiel 1 ist ähnlich wie SYN-Flooding bei TCP, im Detail meinte ich in diesem Beispiel eine UDP Amplification attack.
[re:1] Odyssee am 19.08. 16:52
+1 -
@dpazra: Ich danke Euch Beiden für diese geilen Erklärungen.
Edit:Typo
[o3] somedevdude am 19.08. 13:26
+2 -
Nur als Info, SYN-Flooding gibts schon länger, aber das hier ist auch sehr interessant.

@dpazra hat das schon ganz gut erklärt woran es hier scheitert. Kurz gesagt: Fehlerhafte Implementierung des TCP-Stacks. Und wenn ich mir anschaue welche Netzwerkausrüster kontaktiert wurden, dann stimmt das schon ein wenig ängstlich was da in Zukunft noch kommen könnte.
oder

Zugangsdaten vergessen?

Jetzt kostenlos Registrieren!
Desktop-Version anzeigen
Hoch © 2023 WinFuture Impressum Datenschutz Cookies