In der vernetzten Welt lauern aber noch weitere Gefahren. So empfiehlt beispielsweise Doodle die Abänderung der iCloud ID (=Apple ID), wenn man MyDoodle mit der iCloud verbunden hat. Wer macht das nicht, wenn man seinen Terminkalender aktuell halten will. Und was ist mit anderen betroffenen Diensten, die ebenfalls Zugriff auf iCal haben (Wunderlist z.B.)? Also: Für Entwarnung ist es noch zu früh!

Apple ist nicht betroffen, weil deren OpenSSL Version noch älter als zwei Jahre ist, oder warum?

Pinguin777:

Hier geht's um Apples Produkte OSX bzw. iOS (die beide kein OpenSSL verwenden sondern eine eigene SSL-Implementierung, und dasjenige OpenSSL, das OSX zusätzlich von Haus aus mitbringt, damit evtl. andere Software von Drittherstellern diese nutzen kann (wenn sie nicht selber eines oder eine andere Alternative mitbringt, wie z.B. Firefox das tut oder frühere Chrome-Versionen) ist veraltet und von dem aktuellen Heartbleet-Bug, der "nur" neuere OpenSSL-Versionen betrifft, nicht betroffen).

Und es geht um Apples Web- und Cloud-Dienste, die z.B. zu einem Teil Amazon-Cloud-basiert (AWS Cloud, welche wiederum Linux-basiert ist) und zum anderen Teil Windows Cloud-basiert sind. Bzw. Apples Web- und Download- und Software-Update-Server, die ihrerseits wiederum ein verwundbares OpenSSL nutzen könnten. Hier wäre dann noch Klärungsbedarf. Oder eben nicht mehr, weil Apple nach gründlicher Überprüfung das mit seiner jetzigen Klarstellung ebenfalls abgedeckt haben könnte, das wäre jetzt nochmal genau zu hinterfragen und sicherzustellen, ob dem so ist oder nicht.


Siehe:
Wunderlist (09.04.2014): How We Fixed the Heartbleed bug


+1

Muss man bei MyDoodle die AppleID Zugangsdaten angeben?
Selber schuld wer das macht. Die gebe ich nur bei Apple an, sonst nirgends.

Apples Dienste sind nicht betroffen, weil Apple auf OpenSSL verzichtet und eigene Kryptobibliotheken verwendet. iOS ist gar nicht betroffen, da dort kein OpenSSL eingesetzt wird.

Die ältere Version von OpenSSL ist zwar in OS X vorhanden, wird aber nur aus Kompatibilitätsgründen verwendet, ansonsten nicht.

Bitte, macht Euch doch wenigstens bei wichtigen Themen mal die Mühe, sachlich Richtiges abzuliefern, grad wenn Ihr fatalerweise "Entwarnung" gebt, wo die Konsequenzen dieses Mists aktuell noch nicht mal ansatzweise abzusehen sind.

Falsch. Es geht nicht darum, ob die fragliche Software OpenSSL benutzt sondern ob deren Aktualisierungsserver OpenSSL nutzt oder irgendwann mal in den letzten 2 Jahren in der anfälligen Variante nutzte. Sollte das der Fall gewesen sein und kam die Heartbeat-Extension zum Einsatz, konnten Dritte den Private Key des Servers klauen und in Folge (d.h. auch heute noch!) in Form von Man-in-the-Middle-Attacken Usern ein gefälschtes SSL-Zertifikat vorsetzen und damit alles Mögliche machen.

Bullshit. Der Fehler ist entdeckt worden (von potentiell "Bösen" vermutlich schon lange vorher), der Fehler ist nun auch veröffentlich worden und es existieren Patches für OpenSSL, die zum Teil eingespielt wurden, zum Teil nicht. Das Problem resultiert aus der Vergangenheit und der Tatsache, dass so lange nicht alle Zertifikate, deren Private Keys eventuell entwendet wurden, zurück- bzw aus dem Verkehr gezogen wurden, mit diesen Zertifikaten weiterhin Schindluder betrieben werden kann (und das kann weiterhin ein Angriff auf SSL in irgendeinem WLAN sein, das kann aber auch die hier angesprochene Auto-Update-Fähigkeit von Software bzw. generell "Software-Aktualisierung über das Internet" sein, weil sich Dritte mittels ggf. entwendeter private keys fälschlicherweise als der "richtige" Server ausgeben können.

Das Prozedere, um SSL-Zertifikate zurückzuziehen, mag bei Browsern noch halbwegs funktionieren. Aber bei irgendwelchen Software-Update-Mechanismen sieht's ganz anders aus bzw. hat man als Normalanwender noch nicht mal groß die Möglichkeit, das zu prüfen. Und damit für das Thema Entwarnung gegeben werden kann, müssen nicht nur sämtliche betroffenen Zertifikate erneuert werden sondern auch alle die vormals benutzten Zertifikate effektiv geblockt werden. Man google mal nach


Hier von Fehlerbehebung zu schreiben, ist der blanke Wahnsinn!

Wer mit dem Terminal auf seinen Server zugreifen kann, hat die Möglichkeit die Version von openssl zu überprüfen:
ssh root@xxx.xxx.xxx.xxx
Passwort eingeben und mit dem Befehl "openssl version" die aktuelle Version auf dem Server abfragen. Betroffen sind 1.0.1 bis 1.0.1f.

Thomas Kaiser:

+1

Wozu musst Du root sein, um lediglich die Version von OpenSSL abzufragen? Unnötig. Geht mit jedem anderen nicht-privilegierten Benutzer genauso und ist sicherer, weil nicht unnötig mehr Rechte habend als notwendig.

Und auch derjenige, der keinen Shell-Zugang hat, kann schnell hier seine Domain/seinen Webserver checken lassen:

Heartbleed test

@Thomas Kaiser

Der einzige hilfreiche Kommentar, danke.

Wichtig: Nach der Installation der Fixes alle betroffenen Dienste welche OpenSSL nutzen neu starten. Zertifikate erneuern und alle Nutzer informieren.

Github: CVE-2014-0160 mass scan on the Alexa top sites.

Python-Skript dazu (zur Transparenz und für diejenigen, die's selber machen wollen):
Nebst alle paar Stunden aktualisierter Top-10000-Ergebnisliste; die derzeit aktuellste ist diese hier top10000-10-Apr-14-2000UTC.txt

Es sind so einige .de-Domains auf der (natürlich beschränkten, aber 10000 gecheckte Sites ist doch schon mal was) Ergebnis-Liste (sowohl betroffene als auch nicht betroffene). Schon von daher ist diese Liste sicher ganz interessant und evtl. hilfreich.

Das Fatale ist: Das reicht alles nicht. Bzw. es reicht, um lediglich eine Variante der Heartbleed-Ausnutzung fortan zu verhindern: Das direkte Ausspähen von Logon Credentials.

Das weitaus Schlimmere an der Chose ist, dass SSL und damit Vertrauen/Vertraulichkeit im Internet Stand jetzt eigentlich komplett im Arsch ist. Warum?

SSL basiert auf asymetrischer Kryptographie, einer Public Key Infrastruktur und Zertifikaten. Ersteres und Letzteres setzt voraus, dass der private key geheim ist. Auf den paßt man besonders gut auf, den darf sonst keiner kennen, sonst ist alles, was da drauf basiert (also konkret Vertraulichkeit, Integrität und Authentizität -- halt eben alles) fürn Arsch.

Das Böse an Heartbleed ist, dass es einen serverseitig nicht entdeckten 64 Kbyte großen immer und immer wieder anzapfbaren Kanal direkt ins von OpenSSL genutze RAM darstellt(e). Und da drin auch der für das entsprechende Zertifikat verwendete private key auslesbar ist, wenn man Glück hat bzw. es oft genug probiert bzw. probiert hat.

Was bedeutet das? Dass jemand mit diesem private key nicht nur nachträglich eigentlich sicher verschlüsselten Traffic entschlüsseln kann (wo dann wiederum bspw. Usernamen/Paßwörter auslesbar sind. Und deshalb ist PFS so wichtig, hallo Apple, setzt das endlich mal in Eurer iCloud um!) sondern dass man mit diesem Key Zertifikate fälschen kann und sich damit gegenübern Opfer als falscher Server ausgeben kann, solange das Zertfikat nicht abgelaufen ist oder widerrufen wurde.

D.h. es reicht, dass ein Serverbetreiber irgendwann in den letzten 2 Jahren mal OpenSSL mit Heartbeat-Erweiterung in den verwundbaren Versionen eingesetzt hat (da reicht auch ein von außen erreichbares Testsystem, das man mit in einen Servercluster aufnimmt), um den für solche Man-in-the-Middle-Attacken attraktiven private key als potentiell "verloren" betrachten zu müssen. Und das ist die eigentliche Tragweite bzw. der Grund, warum Stand jetzt so wahnsinnig viel Zertifikaten (bzw. SSL/TLS an sich) nicht mehr zu vertrauen ist. Weil es um einen Zeitraum von 2 Jahren geht, innerhalb dessen die Basis für den ganzen SSL-Quatsch -- dass der private key eben verdammt nochmal private ist und nicht simpel abgegriffen werden kann -- für weite Teile des Internets nicht mehr gegolten hat. D.h. jeglicher Aktionismus und Gepatchte jetzt ändert nichts daran, dass eine unüberschaubare Anzahl an Zertifikaten als unsicher betrachtet werden muß.

Und was das für Konsequenzen hat, ahnen wir alle noch nicht mal ansatzweise (aber möglicherweise ahnen wir jetzt, wieso die Jungs und Mädels von NSA, GCHQ & Co. auf ihren Folien immer so überzeugt davon sind, in die meisten Systeme immer eindringen zu können: Vermutlich weil es neben dem Heartbleed-Kracher noch weitere gibt -- siehe Apples gotofail, das sich allerdings vergleichsweise harmlos neben Heartbleed anfühlt -- von denen die wissen und die sie aktiv nutzen)

danke. Ist die erste Liste, in der meine Bank erwähnt ist ("no SSL" bzw. "not vulnerable").

Vermutlich ?
sry, aber:
die haben von Quelltext bis Instalierten Routerbackdoor, praktisch unbegrenzte Mittel…und dann schreibst du was von "vermutlich"…das einzige was die nicht haben, unbegrenzt Zeit und Personal…

xkcd: Heartbleed Explanation (for Dummies)

Was mir an Heartbleed gefällt ist die Tatsache, daß man von außen nichts besonderes machen muß, außer Fragen zu stellen. Die Antworten kommen direkt, schnell, und hinterlassen keine Logs, keine Abstürze, keine Spuren, nichts. Es wird ja erwartet, daß man fragt, und bekommt 16k-weise (bisher war oft von 64k die Rede, aber egal) Interna serviert, immer wieder mal andere und so lange man möchte, und das exklusiv (dank OPENSSL_malloc) aus den relevanten Speicherbereichen. Großartig!

http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html

Nächster Kandidat: hat mit Heartbleed direkt nichts zu tun, ist für sich genommen aber auch shice und in Kombination mit Heartbleed erst recht: FreeBSD/Juniper (Stichwort: Netzwerk-Hardware) mit OpenSSH-Lücke:

Theo de Raadt: OpenSSH hole, April 9 ,

Heartbleed hin oder her, anscheinend wurde die Lücke bisher nicht genutz/mißbraucht?
Die Presse wäre doch sonst voll damit, Bank xy geknackt, Schaden geht in die Millionen.............
Sieht so aus das eben bisher nichts ernsthaft passiert ist?
Zum Glück.

Lexusdriver:

Von wegen.

Siehe: u.a.:

OpenSSL-Bug: Spuren von Heartbleed schon im November 2013
Ein Systemadministrator hat angeblich in einem Logfile vom November letzten Jahres Exploit-Code für den Heartbleed-Bug gefunden. Die EFF ruft andere Administratoren zu Nachforschungen auf.


EFF (10.04.2014): Wild at Heart: Were Intelligence Agencies Using Heartbleed in November 2013?

Außerdem besteht die Möglichkeit und eine gewisse nicht kleine Wahrscheinlichkeit, dass der SSL-Heartbleed-Bug und diese Meldungen hier in mittelbarem oder unmittelbarem Zusammenhang stehen könnten:

MTN (07.04.2014): Weitere 18 Millionen Mail-Accounts gehackt

MTN (21.01.2014): BSI meldet millionenfachen Identitätsdiebstahl von deutschen Internet-Nutzern

Zumal genau bekannt ist, wie diese Schwachstelle per Exploit ausgenutzt werden kann (so zum Beispiel ). Ohne groß Spuren zu hinterlassen. Wer Dir Böses will, der weiß das auch. Und der wird bestimmt nicht warten, bis alle gepatcht haben, der hat's evtl. schon gemacht oder macht's noch. Oder kommt jetzt erst durch auf die Idee, solange noch nicht alles abgedichtet ist.

Erstens IST die Presse voll mit Meldungen zum Thema, und zweitens ist man immer noch bei der Analyse und Zuordnung des Ganzen und der Tragweite. Es ist noch überhaupt nicht absehbar, welche Schäden das Ganze evtl. bereits nach sich gezogen hat oder noch ziehen wird. U.a. auch deshalb, weil vielleicht bisher entstandene Schäden einer ganz anderen Ursache zugeordnet worden sind, ihre wahre Ursache aber in diesem Vorfall haben und diesem zugeordnet werden müssen. Von der Zukunft und noch gar nicht absehbaren und nicht im Voraus eingrenzbaren weil einen aus der Vergangenheit evtl. einholbare Auswirkungen ganz zu schweigen.

Und Du beschließt Deine Worte mit "Sieht so aus das eben bisher nichts ernsthaft passiert ist? Zum Glück". Das sieht aber nur für Dich so aus.
Nichtwissen scheint manchmal ein tröstlicher Segen zu sein, habe ich grad' den Eindruck...

Prinzipiell gibt es ja CRLs und OCSP für solche Dinge. Aber der normale User macht sowas nicht, bzw. hat erstmal auch keine Ahnung davon.

Jeder Entwickler / Hoster müsste seine evtl. betroffenen Zertifikate invalidieren/revoken, neue verwenden. Ausserdem müssten die Apps und Frameworks (z.b. updateframeworks) einen CRL/OCSP check einbauen. Grundlegend gut wäre z.b. eine neue Sparkle-Version, die OCSP checkt (keine ahnung, ob das nicht evtl. schon passiert, hab Sparkle die letzten 4-5 jahre nicht mehr in den Code geschaut).

Notiz am Rande: iOS Apps testen die Zertifikate des Entwicklers beim start gegen ocsp.apple.com. Ist dort Pflicht. (nicht bei jedem start, aber ab und an). Und für den Mac App Store ist das seitens Apple empfohlen, aber noch nicht absolut Pflicht. Manchmal sind die "strengen" Vorgaben seitens Apple eben doch vernünftig.
Notiz am Rande des Randes: Dieser Check ist u.a. Notwendig für die Verteilung von Apps im Rahmen von Managed Distribution in VPP2. Wenn man mittels VPP2 / Managed Distribution einem User eine App wieder entzieht, kann er diese offiziell noch 30 Tage nutzen. Nach 30 Tagen geht die App dann nicht mehr, sofern es eine iOS App ist oder bei einer OS X App der entwickler den (noch optionalen) ocsp-check macht.

Absolut. Die Verwirrung und das Un-/Halbwissen ist gross.

Wie es der Zufall so will bin ich gerade mit einem Kollege in den USA, dort die Beta-Class für ein neu entwickeltes Advanced Mavericks 305 Training halten. Da hatten wir gestern auch ein Extra Kapitel zu Keys, Zertifikaten und Encryption - mit dem Abschnitt "Weaknesses of the X509 System".
Das Training richtet sich vor allem an fortgeschrittene Mac-Admins, der durchschnittliche User wird damit sicher erschlagen.
Wenn jemand daran interesse hat, kann mir gerne eine direkte Nachricht schreiben.

Das hat mehr mit nicht betroffen als nicht wissen zu tun!
Bin bisher nicht betroffen, und kenne auch niemand der betroffen ist!
Man muß auch nicht alles immer gleich so schwarz sehen!
Und wie man mit dem Bug 18 Millionen Internet Mail Konten hacken sollte,
müsste man mir mal erklären? Mit 16 KB Blöcken. Wieviel Jahre soll das dauern?
Aber am besten wir schalten das Internet ab, das ist dann sicher!

Du verstehst gar nicht was passiert ist, oder?

Preisfrage der Woche:
Finde heraus, an welcher Stelle Eves Passwort sicherer ist, weil sie einen Mac hat.

Und immer wenn du denkst es kann nicht mehr schlimmer werden... dann.

Wieso schlimmer?
Ist doch quasi nur eine Studie die zeigt wie und ob es funktioniert?

am besten gar keine Verschlüsselung