News Heartbleed möglicherweise bereits Ende 2013 ausgenutzt

Mal eine ganz andere Frage:

Welche Passwörter muss man denn jetzt wechseln?
Ich habe nur eine kurze Liste auf Mashable gefunden. Die u.a. Dropbox etc. listet.
Bzw. wie kann man denn herausfinden ob eine Seite den Bug hatte?

Vllt. besser einfach alle zu wechseln?
 
@Ed40
Auf Serverseite ist es sehr kritisch, bei den Clients muss man nicht in Panik verfallen, da die meisten Anwendungen wie Thunderbird / Firefox seine eigenen SSL Bibliotheken mitbringt. Das bedeutet aber trotzdem das man die OpenSSL Version aktualisieren sollte.

@NuminousDestiny
Hier kannst du nachprüfen ob eine Webseite noch ungepatcht ist.
 
SoilentGruen schrieb:
Die beim NSA müssen wirklich ne Menge Hirn und Man-Power habe um die ganzen OpenSource Sachen vollständig und regelmäßig zu durchleuchten... Unglaublich was die Gutes damit machen könnten.

Das läuft so nicht, sondern wahrscheinlich so:

Person X guckt sich den Code an. Findet eine Lücke, testet sie aus, und sie funktioniert. X weiß über die Konsequenzen einer solchen Lücke Bescheid. X hat jetzt drei Möglichkeiten:

-X meldet die Lücke und fixt sie
-X verkauft die Lücke auf dem Schwarzmarkt
-X verkauft die Lücke an einen Geheimdienst

Konsequenzen der jeweiligen drei Optionen:

-Die Lücke wird weltweit entdeckt, Xs Name taucht kurzzeitig überall auf, das wars
-Er macht einen Haufen Geld, die Lücke wird massig und öffentlich ausgenutzt und bekannt gemacht, wird sofort gefixt, das wars
-Der Geheimdienst möchte die Lücke solange wie möglich nutzen, damit X dicht hält, bekommt er nach dem ersten Verkauf noch zusätzlich Kohle

Was macht also das durchschnittliche Arschloch (hier "X") am ehesten?
 
Marius schrieb:
Ich hab die Knackdauer der üblichen Passwörter oben erläutert.
Die meisten Firmen setzten auf 96 Zeichen zu 8 Zeichen Mindestlänge.

Das ist ja nichts neues, daß es Schwachsinn ist, auf kurze komplexe Paßwörter zu setzen.
Es ist halt für Menschen schwieriger, kompexe Paßwörter zu erfassen als lange, und so fehlt (mangels technisch-mathematischer Kenntnis) die Einsicht, das zu ändern.
 
Cool Master schrieb:

Naja, wozu deinen Container knacken, wenn se schon längst dein masterPW haben? Verstehst du das Problem ?
 
Einmal ordentlich erklärt das Ganze, ist übrigens seit 2006 öffentlich bekannt:

http://fm4.orf.at/stories/1736830/



Verblüffende Knackeffekte
Der Zwischenbericht des Kryptografenteams brachte Anfang April zwei grundlegende Erkenntnisse. In einem Feldversuch mit einem speziell zum Brechen von Algorithmen optimierten Rechnercluster im Gegenwert von 40.000 Dollar gelang es den Kryptografen, einen Verschlüsselungsvorgang, der seine Zufallselemente aus dem Dual EC DRBG bezog, innerhalb von 90 Minuten zu knacken. Das entsprach etwa den Prognosen; die eigentliche Überraschung passierte aber erst, als die Protokollerweiterung "Extended Random" zusätzlich implementiert wurde.

Die Prozedur, um den verwendeten Schlüssel herauszurechnen, wurde durch "Extended Random" um den Faktor 65.000 beschleunigt, was große Verblüffung unter den Forschern zur Folge hatte. Die auf weniger als drei Sekunden reduzierte "Knackzeit" dieser Kombination hätte nämlich dafür gesorgt, dass die NSA Serverschlüsselungen quasi am Fließband knacken kann. Der Protokollerweiterung "Extended Random" für TLS/SSL selbst war diese verblüffende Wirkung ebenso wenig anzusehen, wie man vornherein gemutmaßt hätte, dass eine fehlerhafte Implementation der "Heartbeat"-Erweiterung dazu führen kann, dass ein entsprechend angegriffener Server mit dem Auswerfen von 64 Kilobyte seines RAM-Zwischenspeichers reagiert.

Der Ursprung des "Bullrun"-Programms
"Der Angriff besteht hier aus zwei Elementen", sagte Kafka, "ein insgesamt schwacher Krypto-Algorithmus wird durch eine Schwächung auf Ebene des TLS/SSL-Protokolls durch Extended Random kompromittiert. Etwa 40 Prozent der "Zutaten" für die Zufallszahlen sind einem Angreifer nämlich von vornherein bekannt, weil sie noch vor dem Verschlüsselungsvorgang im Klartext übertragen werden."
 
Zuletzt bearbeitet:
@Marius

Deswegen sollte man auch nicht die Random Generator ab Vista nutzen. Diese wurden von der NSA mit entwickelt. Ich sage nur /dev/urandom. Wenn man ernsthaft verschlüsseln will nutzt man nur Open Source Software und vor allem ein Open Source OS dafür langt sogar eine VM oder eine Live CD. Ganz zur not setzt man auf rng-tools und packt sein Smartphone oder ein anderes Gerät an den Rechner. Wie gesagt Serpent-Twofish-AES oder AES-Twofish-Serpent ist sicher und nicht knackbar mit aktuellen mitteln.

@dMopp

Erstmal muss man an das PW kommen... Wenn man nicht gerade ein Keyloger aufm Rechner hat oder 24/7 überwacht wird spielt das eher keine Rolle und wenn man tatsächlich 24/7 Überwacht wird hat man andere Probleme...
 
@Cool Master
Generell stimme ich dir zwar zu, aber in diesem speziellen Fall hat das absolut nichts mit open oder closed source zu tun. Der Standard für den Dual EC DRBG ist ja öffentlich einsehbar und die Schwachstelle hatte nichts mit einer geheimen Backdoor in der Implementierung zu tun. D.h. jede standardkonforme Implementierung hat diese Schwachstelle.
Das ändert natürlich nichts daran, dass es wesentlich schwerer ist Backdoors in einem CS-System zu entdecken als in einem OS. Darüber, wo man ein (nicht triviale) Backdoor leichter hineinbekommt will ich jetzt aber lieber nicht spekulieren.

Wenn ich richtig informiert bin kommt dieser Random Number Generator aber glücklicher weise nur selten zum Einsatz - gerade weil man schon länger vermutet hat, dass die NSA die Konstanten im Algorithmus nicht zufällig gewählt hat und er auch deutlich langsamer ist als andere DRNGs.

@Marius:
Erstmal Danke für den Hinweis.
Was aber die Sicherheit von Passwörtern angeht: Dass unsichere (z.B. zu kurze oder leicht zu erratende) PW wenig Sicherheit bringen hat hier keiner bestritten. Wenn ich aber von einem "guten" Passwort ausgehe ist es z.B. viel leichter dieses um 3-4 Stellen zu erweitern, als für einen Angreifer die 1000 Fache Rechenleistung aufzubringen. Außerdem sollte man nicht vergessen, dass nur die wenigsten Informationen, die man als Privatmensch verschlüsselt soo wichtig sind, dass tatsächlich jemand die Mittel in die Hand nimmt um ein "gutes" 10-15 Zeichen PW zu knacken - Bzw. man muss halt die Passwortstärke dem Wert der zu schützenden Information anpassen.
Wie du und andere hier aber schon geschrieben haben dürfte dir größere Gefahr wohl von Schwachstellen in den Algorithmen, Fehlern in der Implementierung oder Keyloggern auf dem PC ausgehen.

Bei den Firmen mit denen ich bisher zu tun hatte wurde "ernsthafte" Verschlüsselung übrigens meistens nicht via Passwort realisiert, sondern mit einem Keys auf externen Geräten (z.B. Chipkarte) und die sind üblicherweise so lang, dass sie auch einem massiven Bruteforce Angriff standhalten (auch hier dürften andere Angriffsvektoren wahrscheinlicher sein). Falls du allerdings du auf Zugangspasswörter angespielt hast ist ein kürzeres Passwort da viel weniger kritisch, weil man gegen diese eher selten einen offline Angriff führen kann.

@highks:
Von On-Time-Pad mal abgesehen, gibt es keine Verschlüsselung deren Sicherheit mathematisch beweisbar ist. Bei allen anderen Algorithmen vermutet man es nur, weil sie auf mathematischen Problemen beruhen, für die man bisher noch keine effiziente Lösung gefunden hat. Man konnte aber auch noch nicht beweisen, dass diese Probleme nicht effizient lösbar sind.
 
Zuletzt bearbeitet:
Cool Master schrieb:
Wenn man ernsthaft verschlüsseln will nutzt man nur Open Source Software und vor allem ein Open Source OS dafür langt sogar eine VM oder eine Live CD.
... und auf Open Source Hardware. Ups, das war nichts. In jedem Teil der Hardware kann eine Backdoor oder Implementationsschwäche stecken und da bringt dir das allertollste und sicherste OS nichts, wenn du weißt, was wann zurück kommt, wenn du nur die Hardware kennst, die eine zusätzliche Entropie einbringt (selbst ein Mikrofon, was Umgebungsgeräusche aufnimmt und in die Entropie mit einbezieht wäre da nicht mehr sicher).

War doch letztens erst der Fall, dass die Intel-Implementation für Zufallszahlen bei irgend eine Lib verworfen wurde... Ich glaub das wars: http://www.golem.de/news/freebsd-misstrauen-bei-rngs-von-intel-und-via-1312-103305.html

Aber auch OSS bringt dir nichts, denn wie du siehst, existiert hierbei genauso eine klaffende Lücke. Einzig sinnvolle Schlussfolgerung: Du verkriechst dich wieder in die Höhle und distanzierst dich von allem. Falls das keine Option ist: Überall existieren Lücken, die nur ausgenutzt werden wollen und da kann die verwendete Software OSS oder CSS sein. In beides steckst du dein Vertrauen, bei OSS nur blauäugiger, da du ja davon ausgehst, dass es sicher sein kann/muss/soll, weil ja jemand drüber guckt, besonders bei populären Libs wie OpenSSL.

Wenn das von Marius noch zutrifft (werd mir den Artikel im Laufe des Tages mal durchlesen), ist die Situation noch viel schlimmer, als bis jetzt angenommen...

"Sicher" ist aber nur, was du im Kopf hast. Sobald es irgendwo steht oder weitergesagt wurde, kannst du die "sichere" Info gleich abschreiben.
 
Marius schrieb:
.. hihi, wer braucht bei den App-Berechtigungen und voller Spiegelung am Google-Server denn noch Angst vor geknackten Passwörtern haben?!:)

Alle...

ps. schon ein dicker Hund, was da hinten herum so alles passiert....
( gibt es da irgendwo schon eine doku ...oder herrscht eher journalistisches Schweigen? )
 
"Ob Kriminelle ebenfalls Zugriff hatten ist noch unklar"
Öhm, die NSA ist nicht kriminell?
Schon klar ;)
 
Sollte die Aussage der NSA, dass sie die Sicherheitslücke schon ewig kennen korrekt sein, dann beweist das wieder mal nur genau das was ich seit Jahren über Open Source Software predige.
Ja es ist ganz toll, dass jeder den Code einsehen und selber kompilieren kann, weil so auch jeder nach Sicherheitslücken suchen und sie fixen kann.
Der Nachteil daran ist halt nur, dass jeder nach Sicherheitslücken suchen kann ;), also auch jeder der sie nicht fixen sondern nach allen Regeln der Kunst ausnutzen will.
Und jetzt die Preisfrage, bei wem ist die Motivation nach Lücken zu suchen wohl größer und wer wird deshalb den größeren Aufwand treiben.
Das sind natürlich die Kriminellen, Geheimdienste(sofern man zwischen den beiden überhaupt unterscheiden möchte) und alle möglichen anderen finsteren Gestalten.
Und seien wir mal ehrlich. Wer von denen die OpenSSL nutzen hat jemals aktiv im Source Code nach Sicherheitslücken gesucht? Praktisch niemand. Die Arbeit bleibt auch bei OSS in der Regel an den normalen Stammentwicklern hängen.
Und dadurch wird OSS letztendlich unsicherer als CSS weil durch Faulheit/Desinteresse auch nicht aktiver Sicherheitslücken gefixt werden als bei CSS aber dafür das finden von Lücken für Hacker/Geheimdienste um ein vielfaches erleichtert wird.

Zusammengefasst is OSS eine gute Idee, die aber schlicht daran scheitert dass die ganze Idee auf der Annahme beruht, dass die ganze Welt aus netten hilfsbereiten und selbstlosen Menschen besteht.

Gleiches lässt sich auch über FOSS sagen. Alles kostenlos herzugeben ist eine noble Idee, kann aber nur deshalb funktionieren weil die Entwickler die dran mitwirken ihr täglich Brot in CSS Projekten verdienen und deshalb nicht hungern müssen (oder, bevor wieder einer Mozilla als leuchtendes Gegenbeispiel auspackt, weil einer der größten CSS-Konzerne permanent Geld reinschießt, damit seine Websuche Standard bleibt).
 
Hypothese:

Und das zeigt auch das nicht alles Super und problemlos ist nur weil es Open Source ist. Denn die Frage ist , wer von der breiten Masse hat einerseits das nötige Wissen und andererseits die Zeit alle möglichen OS Scripte auf Fehler zu überprüfen.

Vielleicht ist es manchmal sogar gefährlicher, da die NSA dank Opensource eigene Software Abwandlungen einbauen könnte die niemanden auffallen- weil es nicht geprüft und/oder nur durch Zufall erkannt wird.
 
OSS hat meiner Meinung nach einen Vorteil: Wenn in CSS eine Hintertür eingebaut ist dann vermutlich mit Wissen der beteiligten Entwickler und Verantwortlichen und damit ist es extrem unwahrscheinlich, dass diese jemals gefunden bzw geschlossen wird.
Auf der anderen Seite dürfte die Anzahl an Institutionen, die eine BD in CSS einbauen und ausnutzen können relativ überschaubar sein.
Edit: Nebenbei bemerkt ist es ja nicht so, dass in CSS keine Sicherheitslücken gefunden würden. Ich denke der Verbreitungsgrad ist tendenziell wichtiger als die frage ob der Sourecode vorhanden ist oder nicht. Openssl ist da natürlich gleich doppelt schlecht drann.
 
Zuletzt bearbeitet:
Jaja und die Firmen wollen immer mehr online machen wenns ums Geld geht. Ist ja angeblich alles so mega sicher und verschlüsselt.
 
dgschrei schrieb:
Zusammengefasst is OSS eine gute Idee, die aber schlicht daran scheitert dass die ganze Idee auf der Annahme beruht, dass die ganze Welt aus netten hilfsbereiten und selbstlosen Menschen besteht.

Gleiches lässt sich auch über FOSS sagen. Alles kostenlos herzugeben ist eine noble Idee, kann aber nur deshalb funktionieren weil die Entwickler die dran mitwirken ihr täglich Brot in CSS Projekten verdienen und deshalb nicht hungern müssen (oder, bevor wieder einer Mozilla als leuchtendes Gegenbeispiel auspackt, weil einer der größten CSS-Konzerne permanent Geld reinschießt, damit seine Websuche Standard bleibt).
Was Kompletter Schwachsinn ist. Mit der (falschen) Aussage wiederlegst du auch selber deinen eigenen Post. Bei sovielen Post's und Mitgliedsjahren darf man ja wohl etwas mehr Wissen erwarten.

Willst du uns jetzt auch noch erzählen das Redhat seine Einnahmen rein durch Spenden macht, und in Wirklichkeit da alle für Umsonst Arbeiten?
Wer ernsthaft hier im Forum noch mit dem Mythos OSS=Alles Kostenlos kommt, sollte sich bitte von jeglicher Diskussion zu dem Thema Fernhalten.

Um mal Stallman zu Zitieren: " Free as in free speech, not free beer."

Um es weiter zu Verdeutlichen:
Since 2005, nearly 10,000 individual developers from over 1000 different companies have contributed to the kernel.
http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2013


FINANCIAL RESULTS FOR FISCAL YEAR 2013
$1.33 billion in total revenue, an increase of 17% over fiscal 2012
$150 million in net income, or $0.77 per diluted share
$1.09 billion in deferred revenue at the end of fiscal 2013, an increase of 15% over fiscal 2012
$465 million in operating cash flow, an increase of 19% over fiscal 2012
$1.32 billion in cash and investments at the end of fiscal 2013
Red Hat Inc. - Annual Report 2013
 
Zuletzt bearbeitet:
anonymous_user schrieb:
Wer ernsthaft hier im Forum noch mit dem Mythos OSS=Alles Kostenlos kommt, sollte sich bitte von jeglicher Diskussion zu dem Thema Fernhalten.
Das ist doch aber dem Endnutzer pupsegal. Für ihn heißt OSS = kostenlos, ohne wenn und aber. Support brauch er nicht, den holt er sich in Foren auf Erbarmen der Helfer. Hauptsache Lizenzkosten oder allgemein Geld für etwas gespart. Als ob Oma Gertrude sich nen Kopf drum macht, ob geistiges Eigentum in Form von Source Code ein Gut der Allgemeinheit bleiben soll oder nicht...

Dass Enterprise Support auch bei OSS ne richtige Stange Geld kostet, steht doch dann auf nem anderen Blatt. (weswegen ich die Kalkulation von Limux auch niedlich finde, aber anderes Thema...)

Aber ganz Unrecht hat er ja auch nicht, schließlich kommt das Argument "da kann doch jeder drüber gucken", "jeder selbst fixen", "jeder selbst nach einer Backdoor suchen" etc. doch immer und immer wieder. Nur haben die paar Hanseln hier im Forum (mir inklusive) keine Ahnung von solch tiefgreifender Materie wie einer effektiven Verschlüsselung, Umgang mit der Programmiersprache selbst, Bereichsprüfungen, Speicherlecks, Pufferüberlaufe etc., sowie kann sich selbst der erfahrenste Entwickler wohl erstmal Monate durch fremden Quellcode hangeln, um überhaupt die Art und Weise der Programmierung zu verstehen. Selbst wenn jemand Verschlüsselung bis ins kleinste Detail durchnehmen kann, mangelt es evtl. an C-Kenntnissen, wodurch die Durchsicht am Code sinnlos ist. Umgekehrt natürlich genauso.
 
Yuuri schrieb:
Das ist doch aber dem Endnutzer pupsegal. Für ihn heißt OSS = kostenlos, ohne wenn und aber. Support brauch er nicht, den holt er sich in Foren auf Erbarmen der Helfer. Hauptsache Lizenzkosten oder allgemein Geld für etwas gespart.
Würde ich nichtmal verneinen, nur sehe ich da nicht den Bezug zu meinem Kommentar? Es geht ja nicht darum was der "0815" Enduser denkt, ich rede ja nur vom dem IST Zustand von OSS.


Yuuri schrieb:
Aber ganz Unrecht hat er ja auch nicht, schließlich kommt das Argument "da kann doch jeder drüber gucken", "jeder selbst fixen", "jeder selbst nach einer Backdoor suchen" etc. doch immer und immer wieder.
Ist ja auch im Grunde so, auch wenn es natürlich bei so dingen wie einer OpenSSL Bibliothek den meisten wohl an Wissen fehlen dürfte wie du schon sagtest, um überhaupt was zu verstehen geschweige denn zu Fixen.
Aber trotzdem hat er nunmal nicht recht, weil es quasi Schwarz/Weiß dargestellt wurde ala: "Entweder du Arbeitest unter OSS Projekten für Umsonst, oder wirst Kriminell Aktiv und suchst Sicherheitslücken und verkaufst jene."
Nur wird da ein Fundamentaler Grund außer Acht gelassen: Bspw. die Meisten Entwickler am Linux Kernel, werden von Firmen wie Intel, Red Hat, IBM, Oracle und co. dafür Bezahlt am Linux Kernel zu Entwickeln. Die machen das nicht für Umsonst. Und deshalb ist nunmal der ganze Post von Ihm Unsinnig, da alles auf der Annahme beruht das es nur die beiden Extremen "Umsonst/Freiwillig" Arbeiten oder "Kriminell" werden gibt.

Und man kann auch durchaus davon ausgehen, das die ganzen Großen Firmen nur Leute an die jeweiligen Projekte Abstellen, die auch von dem Bereich Ahnung/Erfahrung haben. Die haben also einen Festen Job, vermutlich auch keine Schlechte Bezahlung, also auch garkeine Motivation Kriminell Aktiv zu werden.
 
anonymous_user schrieb:
Nur wird da ein Fundamentaler Grund außer Acht gelassen: Bspw. die Meisten Entwickler am Linux Kernel, werden von Firmen wie Intel, Red Hat, IBM, Oracle und co. dafür Bezahlt am Linux Kernel zu Entwickeln.
Ich kenne mich in dem Bereich nicht wirklich aus, aber machen die auch was außer Treiber zu entwickeln? Mein Eindruck war bisher immer, dass sich das Engagement von Firmen im OSS Bereich hauptsächlich darauf beschränkt, entweder ein eigenes Produkt um das OS-System herum zu bauen oder eben dafür zu sorgen, dass die eigenen Produkte zu Linux kompatibel sind.
Eclipse wäre ein aktuelles Beispiel, das von hunderten anderen Projekten (CS und OS) benutzt wird, bei dem sich aber kaum jemand um das Hauptsystem kümmert - und das obwohl es ursprünglich sogar von IBM entwickelt wurde (dieser Schritt war damals wiederum eines der wenigen positiven Beispiele die ich kenne)
 
Zuletzt bearbeitet:
Zurück
Oben