[Netzwelt] Massive Sicherheitslücke in OpenSSL

Ein Sicherheitsdefekt erlaubt es Unbefugten, Informationen zwischen dem Nutzer und der Gegenstelle auszulesen. Alle OpenSSL-Versionen, die seit dem Dezember 2011 veröffentlicht wurden, sind betroffen. Datenübermittlungen via SSL oder TLS gilt bis zum einspielen eines entsprechenden Patches nicht mehr als sicher. Da auf diesem Weg auch Schlüssel und Passwörter ausgelesen werden können, ist es möglich, komplett die Accounts der jeweiligen Dienste zu übernehmen.

Entdeckt wurde das Problem von Sicherheitsforschern der Firma Codenomicon und Neel Mehta aus dem Security-Team von Google.


Quelle:
Sonderseite:
 
Zuletzt bearbeitet:
Ja, das ist der aktuelle Zustand. Die Schwachstelle betraf auch ngb.to, der Patch wurde am Morgen des 8. April 2014 eingespielt. Da StartSSL bisher nicht erlaubt, Zertifikate kostenlos zu widerrufen und auszutauschen (und daher möglicherweise aus den Trust-Stores entfernt wird - vgl. , und ), haben wir das nicht getan, zumal im ngb durch SSL keine hochsensiblen Daten geschützt werden und das Widerrufen per CRL ohnehin nicht zuverlässig funktioniert, da diverse Browser in der Standardkonfiguration gar keine CRLs laden. Sollte StartSSL zukünftig einen kostenlosen Austausch anbieten, wie es auch andere CAs tun, werden wir das Angebot natürlich wahrnehmen.
 
Das war damals ein deutscher Student, der jetzt bei T-Systems arbeitet

Dass es ein Deutscher war, habe ich auch gelesen. Allerdings wenn du jetzt sagst, dass er bei T-Systems arbeitet, wird mir einiges klar. Unfähigkeit und T-* zieht sich irgendwie an. Damit wäre auch geklärt, ob es Absicht oder Versehen war, es war ganz eindeutig Unfähigkeit. :D

@Larius: Die Tests sind immer nur so gut, wie ihre Ersteller. In der Regel weiß man ja, was man erwartet und wenn man nicht auf die "Idee" kommt mal auf eine ganz bestimmte Weise falschen Input zu erzeugen, dann schreibt man eben auch keinen Test dafür. Zumal leider auch nicht immer auf Herz und Nieren getestet wird, sondern oft genug nach dem Motto "ist kurz, sieht richtig aus, scheint trivial, ist okay". :(
Zumal ich mir gut vorstellen kann, dass ein derartiger Fehler beim Testen der einzelnen Routine gar nicht auffällt:

Nehmen wir an, du willst nur testen => string + bytelänge => output
Dann schreibt dein Server (im schlimmsten Fall) im Test eben auch nur den String in seinen Speicher und wenn die Bytelänge "größer" ist, dann steht eben sonst nichts drin, er liefert dann unabhängig von der Bytelänge eben nur den String. Dass beim kompletten System aber noch mehr als der String da steht und mehr geliefert werden kann (und wird), ist eben durch's Raster des Tests gefallen. Zumindest könnte ich es mir so erklären und so ganz unbeleckt bin ich auch nicht, was Programmieren angeht.


Aber ich frage mich gerade von welcher Tragweite die Schwachstelle tatsächlich ist.
Welche Verbreitung hatten denn die betroffenen OpenSSL Versionen?
Bei der Bank wäre zumindest eher von einer mittelschweren Bedrohung auszugehen, denn da sollte das TAN Verfahren ja noch mal eine gewisse Sicherheit mitbringen oder?

Edit @ Kugelfisch:
Wieso arbeitet ihr nicht mit einem self-signed Zertifikat?
 
Zuletzt bearbeitet:
Damit wäre auch geklärt, ob es Absicht oder Versehen war, es war ganz eindeutig Unfähigkeit. :D
Ich möchte gar nicht wissen, welche Fehler Du bisher in Deinem Leben gemacht hast, wo jeder andere gesagt hätte: Mensch, mit ein wenig Hirn wäre das nicht passiert. Das möchte ich nicht mal bei mir selber wissen.

Fehler sind menschlich und passieren. In diesem Fall hatte der Fehler nur blöderweise eine sehr große Tragweite. Wäre der Fehler nun von einem Microsoft-Entwickler gekommen, würdest Du wahrscheinlich gegen Microsoft und deren Unfähigkeit hetzen. Wäre der Fehler von einem Apple-Entwickler gekommen, dann gegen die. Wäre es einem hauptberuflichem Linux-Entwickler passiert, würdest Du vielleicht sogar den Fehler runterspielen, wer weiß...


Grüße
Thomas
 
Aber ich frage mich gerade von welcher Tragweite die Schwachstelle tatsächlich ist.
Welche Verbreitung hatten denn die betroffenen OpenSSL Versionen?
Die betroffenen Versionen des 1.0.1-Zweigs waren (unter den Diensten, welche OpenSSL einsetzen) sehr weit verbreitet, da sie in allen aktuellen GNU/Linux-Distributionen enthalten waren. Lediglich in einigen oldstable-Zweigen wurden ältere OpenSSL-Versionen noch gepflegt.

Wieso arbeitet ihr nicht mit einem self-signed Zertifikat?
Weil nicht allgemein als `vertrauenswürdig` erkannte Zertifikate sowohl für unerfahrene Benutzer als auch für Suchmaschinen abschreckend wirken. Wenn wir selbstsignierte Zertifikate nutzen würden, könnten wir daher SSL nicht zwangsweise und auch nicht standardmässig anbieten, was den Nutzen erheblich einschränken würde (z.B. durch Umleitungen auf die nicht-HTTPS-Version des ngb durch einen Angreifer).
 
@Kugelfisch:

War das Board angreifbar und kann man das im Nachhinein feststellen? Ist es angeraten, hier auch das Passwort zu ändern?


p n
 
Fehler sind menschlich und passieren. In diesem Fall hatte der Fehler nur blöderweise eine sehr große Tragweite. Wäre der Fehler nun von einem Microsoft-Entwickler gekommen, würdest Du wahrscheinlich gegen Microsoft und deren Unfähigkeit hetzen. Wäre der Fehler von einem Apple-Entwickler gekommen, dann gegen die. Wäre es einem hauptberuflichem Linux-Entwickler passiert, würdest Du vielleicht sogar den Fehler runterspielen, wer weiß...
Das war bezugnehmend auf die Unterstellung(en) weiter oben, der Fehler sei vom NSA implementiert worden.
Nach deiner mir unterstellten Handlungslogik sollte ich den Fehler jedoch herunterspielen, da kein böses mafiöses Kommerz-Unternehmen sondern eine gute OpenSource Welt dahinter steht, oder?
 
Es ging mir eigentlich nur um die Aussage "T-Systems = Da kann nix gescheites bei rauskommen". Dabei spielt es eigentlich gar keine Rolle ob er nun dort oder bei Microsoft oder sonstnochwo gearbeitet hat. Fehler passieren jedem mal.


Grüße
Thomas
 
War das Board angreifbar und kann man das im Nachhinein feststellen? Ist es angeraten, hier auch das Passwort zu ändern?
Ja, der Webserver war angreifbar, ob das geschehen ist, lässt sich nicht zuverlässig feststellen, da ein entsprechender Request gültig ist und daher nicht in Error-Logs o.ä. auftaucht. Wir können bloss ausschliessen, dass jemand die Schwachstelle massiv durch viele Requests ausgenutzt hat, da die dann erhöhte Serverlast aufgefallen wäre. Benutzerpasswörter werden bei aktivierter JavaScript-Unterstützung für ngb.to ohnehin niemals im Klartext übertragen - es wird clientseitig ein MD5-Hash erzeugt, welcher dann an den Server übermittelt wird. Der MD5-Hash lässt sich zwar benutzen, um sich gegenüber dem ngb zu authentifizieren, das ursprüngliche Passwort lässt jedoch nur durch einen (bei einem starken Passwort sehr aufwändigen) Preimage-Angriff ermitteln. Allerdings sind die clientseitig zur Authentifizierung verwendeten Hash-Werte anders als die Hashes in der Datenbank nicht mit einem Salt versehen, so dass dazu Rainbow Tables genutzt werden können.

Insofern ist das Ändern der Passwörter normalen Benutzern zwar grundsätzlich anzuraten, aber meines Erachtens nicht dringend erforderlich, zumal mit einem kompromittierten Benutzerkonto eines normalen Benutzers kaum Schaden angerichtet werden könnte.
 
Zuletzt bearbeitet:
Naja, wäre es nicht sogar sehr problematisch? Ihr habt ja keine IP-Logs, daher wären unregelmäßigkeiten bei gehackten Accounts gar nicht feststellbar, zumindest nicht anhand der IP-Logs. Bestenfalls wäre Hacking von Accounts dann feststellbar über plötzliches Trolling von Nutzern.. Wobei Hacker da ja höhere Ansprüche hätten als auf NGB zu trollen.. oder?
 
Ich denke mal nicht das ein Hacker - wenn er schon so eine Sicherheitslücke hat - seine Zeit mit Trolling zu verschwenden sondern eher versucht sich ins AdminCP reinzuschummeln. Siehe damals das Problem mit VBKing der ja eine Sicherheitslücke in der Forensoftware ausgenutzt hat um das Board zu schreddern.

@Pleitgengeier: Siehe die Definition von Hacker - . Das kommt schon etwas hin auch wenn die Massenmedien für alles und jedes "Hacker" sagen.
 

Ich finde die Unterscheidung zwischen Grey- und Blackhats unnötig, da beide ungefragt in fremde Systeme eindringen. Und es ist vollkommen wumpe, was die Motivation ist. Wenn einer bei dir einbricht, um aufzuräumen und einen Kaffee zu kochen, ist er trotzdem eingebrochen und ist somit Einbrecher.
 
Es fordert ja auch niemand die ständige Unterscheidung zwischen den Hutfarben.
Aber Hacker!=Cracker könnte man in einem IT-Board doch erwarten, sonst sind wir am Niveau der Bild"zeitung"
 

Der Unterschied zwischen Hacker und Cracker ist der selbe, bzw hat die selbe Grundlage.
Alles, was kein Hacker (Grey- und Blackhats) ist, ist "IT-Sicherheitsexperte" (Whitehat) und gut.
 
Ich finde die Unterscheidung zwischen Grey- und Blackhats unnötig, da beide ungefragt in fremde Systeme eindringen. Und es ist vollkommen wumpe, was die Motivation ist.
Da bin ich klar anderer Meinung - wenn jemand (auch ungefragt) durch einen Angriff eine Schwachstelle aufzeigt und sich zumindest bemüht, dabei nicht mehr Schaden als nötig anzurichten, ist das meines Erachtens eine sehr willkommene Unterstützung für die Administration. Selbst wenn sich jemand dadurch profilieren möchte und temporär Schaden anrichtet, der später wieder rückgängig gemacht werden kann (z.B. ein Defacement), dann ist das zwar unschön, aber sicherlich unproblematischer als eine offene Schwachstelle. Die Gefahr sehe ich primär dann, wenn jemand unbemerkt einbricht, sensible Daten kopiert und diese veröffentlicht oder gar verkauft - oder wenn Systeme kompromittiert werden, um sie für kriminelle Aktivitäten zu missbrauchen.
 

Bei "willkommener Unterstützung" fragt man nach, bzw. lässt sich engagieren, wie es die Whitehats tun.
Jeder Verstoß gegen das Gesetz ist ja vorerst das - ein Verstoß gegen das Gesetz. Und Menschen, die gegen das Gesetz verstoßen, brauchen eine gemeinsame Bezeichnung.
 
Leidige Debatte. Hacker sind das alles. Der Begriff ist sehr weiträumig und nicht einmal unbedingt auf "IT" begrenzt. Da könnte man hier schon wieder rumjammern, daß das manch einer nicht versteht.

Motivation und Ziel sind wieder was anderes. Nur weil ein paar Handwerker einen abzocken, erfindet man auch keine neuen Wörter und nennt die dann Handzocker oder Werkscracker oder Malerzocker, Straßenbrecher, oder was weiß ich. Handwerker sind Handwerker, aber unterteilt in Schlosser, Maler, Bauarbeiter, etc. Da kommt doch auch keiner auf die Idee, die dann nochmal anders zu benennen.
Andersrum ist ein bösartiger Mensch ein bösartiger Mensch und fertig. In welcher Branche oder Situation er bösartig handelt, ist doch letztlich egal.

Aus meiner Sicht ist diese Cracker/Hacker-Unterscheidung nichts als das typische elitäre Gerede in dieser sich ewig selbstfeiernden Ai-Tiii-Branche, die für ihren Kram, den sie selber produziert hat und selber nicht mehr versteht, ständige neue Wörter erfindet. Ebenso meiner Ansicht nach, ist das einfach falsch, weil der Begriff eigentlich sowieso alles und noch viel mehr umfasst.

Ein anderer Ansatz, um sich wenigstens für die verschiedenen Motivationsarten aussprechen zu können, wären diese Symbole, wenn man es denn unbedingt braucht oder gut findet (so wie ich im Profil, ja ;-)):
Aber wozu man wie im hier konkreten Fall überhaupt darüber diskutieren müsste, ob das nun gut oder schlecht war, erschließt sich mir nicht. Sprich, in Folge dessen brauchts auch keine Diskussion darüber, wie man den Typ nun nennt. Nennt ihn einfach Arschloch, weil das ist allgemeingültig für sowas. Wenn das einer in den Medien nicht kapiert, ist er dumm. Auch da braucht man nicht weiter drüber zu reden.
 
Eigentlich müsste man die Greyhats auch wieder in verschiedene Bereiche aufsplittern. Es gibt bsp. Greyhats, die eher in Richtung Whitehats gehen, weil sie einfach einen Fehler den entsprechenden Stellen melden weil sie durch exploratives Testen darauf gekommen sind. Das kann bsp. sein das sich jemand Heartbleed im Detail anschauen will, drauf kommt "oh der Server ist verwundbar" und das einfach an die Support-Emailadresse weiterschickt ohne die Lücke effektiv auszunutzen. Erst wenn der Serverbetreiber nicht reagiert kann das Ganze öffentlich gemacht werden damit etwas "Druck" von Außerhalb da ist. Wäre somit ein klassischer Greyhat der aber eher in Richtung Whitehat tendiert. Eigentlich wären somit alle Personen, die eine Sicherheitslücke in einem öffentlichen Forum diskutieren, per Definition Greyhats da man diese Lücke ja ausnutzen könnte - siehe die Lücken in diversen Forensoftwares die ja dort öffentlich besprochen werden.

Genauso gibt es Greyhats die eher in Richtung Blackhats tendieren indem sie einfach die Lücke ausnutzen bzw. Publik machen bevor man die Chance zum Reagieren hat.
 

Greyhats sind für mich diejenigen, die gegen das Gesetz verstoßen (ungefragt ins System eindringen), um etwas Positives oder wenigstens Neutrales zu erreichen. Aber Verstoß ist Verstoß. Wenn man die Greyhats "reinwäscht", dann kann man auch gleich Selbstjustiz auf der Straße dulden.
Diejenigen, die sich nur etwas anschauen und nicht ins System eindringen, sind für mich Whitehats. Um das Straßenbeispiel aufzugreifen: für mich sind das diejenigen, die die Polizei anrufen, statt den Verbrecher selber zu erschießen.
 
Zurück
Oben