Fehler im HTTP-Protokoll ermöglicht DoS-Attacken

Sicherheitslücken Das IT-Unternehmen Resolvo Systems wurde auf eine kritische Schwachstelle im grundlegenden Web-Protokoll HTTP aufmerksam. Diesbezüglich sollen sich DDoS-Attacken (Distributed Denial of Service) starten lassen, heißt es. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Jetzt haben die USA ja ihren Internet Notausschalter... das sie da nicht selber drauf gekommen sind^^
 
"dass folglich alle Web-Dienste, welche auf HTTP setzen, einem gewissen Risiko ausgesetzt sind. " - ist wie "Wenn ich auf die Straße gehe bin ich einem gewissen Risiko ausgesetzt vom Auto erfasst zu werden"....
 
das ist das ende... wir stehen wieder am anfang
 
Na so was. Man kann via HTTP Daten übertragen. ... Ganz offensichtlich ist das Protokoll unbrauchbar.
 
@RalphS: Es geht nicht um die bloße Möglichkeit, sondern um die fehlende Abwehr gegen sinnlose Datenübertragungen.
 
@twinky: Mag ja sein, aber wo soll das hinführen? Wo ist das Ende? Keines der geläufigen Protokolle verhindert ungültige Daten. Wie sollte das auch funktionieren? Ok, wenn man noch jede Menge Overhead-Prüfdaten mitschickt, dann vielleicht... aber, ganz im Ernst, es ist wirklich dasselbe wie "Autofahren bedroht Ihre Gesundheit" oder "Studien haben gezeigt, daß man am Ende des Lebens tot sein kann".
 
@RalphS: Und weil kein Protokoll einen derartigen Schutz bietet, soll es nicht als Sicherheitslücke zählen? Nur unvermeidbare Ereignisse wie der Tod? Also bitte... ______@unbound.gene: ein Botnetz ist mit einem deutlich höheren Aufwand verbunden. Es macht schon einen Unterschied, ob man einen oder tausende PCs benötigt.
 
@twinky: Das ist eine Eigenschaft des Protokolls selber und darüber hinaus systembedingt - genauso wie es eine Eigenschaft von Straßen ist, gefährlich zu sein und vom Leben, irgendwann zu enden. -- Es ist keine Sicherheitslücke einfach aus dem Grund, daß es nichts gibt was man reparieren könnte; um dieses Problem loszuwerden müßte man den gesamten Kommunikationsprozess neu aufrollen, ein neues Protokoll implementieren, neue Server -UND- Browser bauen... und natürlich müßte man ne Idee haben, *wie* um alles in der Welt man solche Checks in ein *Protokoll* implementieren sollte.
 
@RalphS: Eine Strasse hat nicht die Eigenschaft gefährlich zu sein. Diese Eigenschaft besitzen einige ihrer Benutzer. Es ist ein großer Unterschied, ob man Risiken wahrnehmen und sich effektiv dagegen schützen kann, deshalb hinkt dein Vergleich. Das heranfahrende Auto kann ein aufmerksamer Mensch sehen und hören, den http Traffic nicht. Die meisten User stehen diesem Phänomen völlig hilflos gegenüber, sie merken nichteinmal wenn ihre PCs infiziert sind und wähnen sich in Sicherheit, weil der Virenscanner nix meldet.
 
@twinky: Die Möglichkeit fehlt dir meistens so oder so, ein Botnetz aus ein paar tausend Rechnern greifen auf Webseite xyz zu, da gehen bei vielen ohnehin die Lichter schnell aus. Denn dann bekommst du eh nicht mehr Gut von Böse getrennt, wie auch. Das einzige was effektiv vor einem DDoS und dem damit beabsichtigen Ausfall des Dienstes "schützt" ist immer mehr Power als "der Gegner" zu haben.
 
@RalphS: Das tolle ist, diese tolle Sicherheitslücke ist schon ewig bekannt. Da HTTP kein Timeout kennt, braucht man dazu nicht einmal eine POST versenden siehe Slowloris Angriffe. ;)
 
Im Endeffekt ist alles nur eine Frage der Zeit, bis dies bis jenes geknackt wird oder Sicherheitslücken herausgefunden werden. Dann wird eben HTTP v2 entwickelt :)
 
Hä? Irgendwie erschließt sich mir nicht was deswegen am protokoll kaputt sein soll?

Wenn ich Daten schicken kann kann ich daten schicken und ich kann auch erst im Nachhinein wissen ob sie Sinnvoll sind oder nicht. Sind DoS Attacken nicht auch schon immer Application Layer? Ich meine das heißt ja auch Denial of Service und nicht Denial of Transport :D
 
@XiRoT: "Denial of Service" heißt, daß das Ziel des Angriffs der Ausfall des ...äh... Zielsystems ist, bzw anders formuliert daß der (die) bereitgestellten Dienste ausfallen. Man verwehrt also anderen den Zugriff (denial of access) auf bereitgestellte Dienste (services) - umgangsprachlich meint man damit die Webserver-Software, aber das kann jeder beliebige Dienst sein, bis hin zum Ausfall des Betriebssystems selbst (was dann offensichtlich den Ausfall sämtlicher bereitgestellter Dienste nach sich zieht). --- WIE man das erreicht, steckt in der Bezeichnung "Denial of Service" aber nicht mit drin - genaugenommen ist schon "Stecker rausziehen" ne DoS Attacke ;)
 
Dass man das erst jetzt bemerkt? Der Server verwirft unsinnige POST-Anfragen ja auch nicht gleich, oder? Also hilft auch eine "Sinnigkeitsprüfung" (Ja, da gibts auch ein Fachwort für) ob er jetzt gerade ein upload-Feld besucht oder nicht, nicht, weil der Server ja die Daten dennoch akzeptiert und verarbeitet
 
@BajK511: Muß er doch! Wie willst Du denn sonst die Daten auf "Sinnigkeit" prüfen? Du müßtest Die Gültigkeit von Daten prüfen, aber Du hast keine Vorlage, was denn "gültige Daten" sein sollen. Man könnt jetzt kommen und sagen, die ersten vier Datenpakete müssen genau SO aussehen... dann werden halt die (4+x)ten Datenpakete entsprechend manipuliert. Ergebnis: noch ein weiteres Katz-und-Maus-Spiel, das Zeit und Resourcen verschlingt. Und grad auf großen Websites ist Resourcenzuordnung alles andere als trivial, da kommt's auf jedes Byte Arbeitsspeicher an. Niemand wird eine bestenfalls trügerische "Sicherheit" gegen x-tausend Hits pro Sekunde eintauschen.
 
@RalphS: Du verstehst mich falsch. Der Server weiß ja nicht bzw. ihm ist es egal, wohin du die POST-Daten lieferst, an die Index-Seite, Impressums-Seite, oder doch eine valide Upload-Seite. Und deshalb verarbeitet er die Daten dennoch unter Rechenlast, nur um sie nachher wieder zu verwerfen. Und das kannst Du nicht unterbinden, weil Du dem Server ja nicht sagen kannst, "nimm nur POST-Uploads oder POST-Anfragen auf den Seiten a, b und c an"
 
@BajK511: ... ja, ich glaub wir sagen beide in etwa dasselbe. Betrachten wir's also einfach als Info für alle anderen Leser ;)
Jedenfalls, um Deinem Gedankengang zu folgen: das (potentielle) Problem, so wie Du's beschreibst, besteht tatsächlich, aber das läßt sich mit relativ wenig Aufwand... in der jeweiligen Scriptsprache zumindest abmildern. Es geht auch nicht darum, was Du Deinem Server sagen kannst und was nicht - bzw sollte es nicht. Die tatsächliche Problem ist dies: es besteht via HTTP keine Möglichkeit, Daten zu verifizieren. Etwas bildlicher, um den Irrsinn zu verdeutlichen: die Straße (HTTP, der Übertragungsweg) ist nicht in der Lage festzustellen, ob das Auto (die Daten) was da grad fährt, ein gültiges TÜV-Siegel hat (gültig ist) oder nicht.
 
Erinnert mich doch irgendwie an die Aussagen, POP3/SMTP ist Mist, weil dadurch auch Spam übertragen werden kann.
 
@Lastwebpage: Ja, das ist ganz genau dasselbe.
 
@Lastwebpage: Gäbe es keine Maßnahmen, den Spam einzudämmen und bestünden Deine Emails zu 99% aus Spam, würdest Du dem sicher zustimmen.
 
@twinky: Du vergleichst hier grad Äpfel mit Schwarzenegger. Spam-Mails sind nämlich gültige Daten im Sinne des Übertragungsprotokolls, auch wenn Du sie nicht haben willst. Ebenso wäre eine defekte Datei noch "gültige Daten" im Sinne des Übertragungsprotokolls (zumindest bei HTTP). Ungültige Daten sind nur die, die eben nicht als Mail, oder Datei, oder was auch erwartet wurde, interpretiert werden können - einfachstes Beispiel, wenn Du ein Akzeptiert (ACK) - Paket kriegst, ohne daß Du eines angefordert hast, dann ist das im Sinne des Protokolls (hier: tcp/ip) ungültig, weil der auswertende Rechner nicht weiß, was er mit diesen Daten machen soll.
 
@RalphS: Ich kam nicht mit dem POP3-Vergleich an ,-) Und nochmal für Dich: Gäbe es über POP3 beinahe ausschließlich Spam, wäre das gesamte System unbrauchbar und wäre nunmal Mist, ganz unabhängig davon, ob Spammails "gültig" im Sinne des Protokolls sind. Nur dank der Gegenmaßnahmen kann man es noch sinnvoll nutzen. Oder würdest Du POP3 sinnvoll finden, wenn Du darüber zum größten Teil nur Unsinn bekommst und die relevanten Emails wie die Nadel im Heuhaufen suchen mußt?
 
@twinky: *lach* Ich kenn genügend solcher Fälle. Ich denke immer noch, das eine hat mit dem anderen nix zu tun - schaff ja auch keine Straßen (Protokolle) oder Autobahnen (spezifisches Protokoll, sagen wir HTTP) ab, nur weil da bloß noch LKWs mit 80 fahren und 30km Platz auf der Überholspur brauchen. Trotzdem hast Du natürlich Recht; ich würd nach Alternativen suchen. (Und bei beiden Beispielen wäre eigentlich der richtige Ansatz, was an den Verkehrsbestimmungen zu ändern und nicht am Transportweg selber - mit anderen Worten, auf einer anderen Ebene.)
 
Zitat "Aus diesem Grund sei das Protokoll als kaputt einzustufen, berichtete Resolvo Systems."

Was ist denn das für Kindersprache? "kaputt"???? Könnte man da nicht auch schreiben "Aus diesem Grund sei das Protokoll als unsicher einzustufen....." ???? Ich glaube kaum das ein Vertreter der Sicherheitsfirma solche Begriffe benutzt hat.
Kommentar abgeben Netiquette beachten!