Software vom Heartbleed Bug betroffen?

clouseau

treuer Stammgast
Im Heise-Forum schrieb jemand:

Re: Was heißt das jetzt für Windows-Nutzer? | Der GAU für Verschlüsselung im Web: Horr... | heise security news-Foren

Bei mir nutzen mehrere Programme die Datei libssl32.dll bzw. libeay32.dll, u.a. Starmoney, Spybot S&D, Kaspersky Internet Security u.a. Die gefährliche Version 1.0.1.x immerhin Kaspersky 2013 und LibreOffice. Ist es noch sicher die Programme zu nutzen? Kann ich irgendwo sichere Updates der dll's kriegen und diese dann "einfach" überall selbst ersetzen oder muss das der "Autor" bei einem Update erledigen?
 
Am besten gleich das Internet und alle Smartphones zerstören, damit die Sicherheit wieder hergestellt ist... wobei ich beides gar nicht mal sooo verkehrt finden würde :)

Aber der Fehler hat es echt schon in sich, die großen sagen natürlich nichts zur Lage, aber mein E-Mail-Anbieter als Beispiel hat jetzt die Zertifikate aktualisiert und darauf hingewiesen, man möge doch bitte sein Passwort erneuern.

Bin gespannt, ob da noch was folgt, im generellen, weil sicher einige es auch verschlafen werden.
 
Software vom Heartbleed Bug betroffen?
Um nochmal auf genau diese Frage einzugehen. Man sollte eigentlich meinen, dass nach gut einem Jahr alle oder zu mindestens die meisten und vor allem die wichtigsten Softwarehesteller, nämlich die von Antivirus-Software, dazugelernt haben sollten. Aber wie so oft sieht die Realität anders aus und das Prekäre daran ist sogar, dass die meisten Benutzer noch für diesen Schrott zahlen. Ich nenne sowas Betrug am Kunden. Denn folgendes hat sich nach diesem Jahr ergeben: neben Kaspersky sind noch Eset und Avast vom HeartBleed-Bug betroffen und das hat sehr wohl Folgen:

Updated: Kaspersky leaves users open to FREAK attack - SC Magazine UK

Golem beschreibt es sehr einfach auf deutsch:
http://www.golem.de/news/https-kaspersky-ermoeglicht-freak-angriff-1504-113747.html

Ebenso pc-mag
FREAK-Sicherheitslücke: Kaspersky weiterhin verwundbar - PC Magazin

Kaspersky kennt das Problem - und tut: nichts. Und kassiert fröhlich weiter.
"Kaspersky Internet Security weiterhin durch FREAK verwundbar" - Kaspersky Lab Forum

Um das mit eigenen Worten kurz zu schildern - die Software installiert ein eigenes Zertifikat in die genutzten Browser zwecks SSL-Prüfung. Bei der SSL-Prüfung müssen natürlich die verschlüsselten Daten entpackt, geprüft und anschliessend wieder neu verpackt und kodiert werden, damit wieder eine SSL-Struktur für den Browser gegeben ist. Fatal ist nun dabei, dass diese drei Produkte das veraltete und unsichere OpenSSL mit dem HeartBleed-Bug nutzen, Eset nciht mal den letzten Stand von TLS anbietet, und somit gegen Angriffe weder noch geschützt sind. Alles ist möglich, nichts ist mehr sicher, auch der Browser nicht.

Kaspersky hat als einzige Reaktion die SSL-Prüfung deaktiviert, jedoch ist diese für spezielle Seiten (wie zB Online-Banking) per se aktiviert und lässt sich auch nicht abschalten. Damit wird keine erhöhte Sicherheit geboten, sie wird massiv untergraben.

Das nächste Problem, welches sich dadurch ergibt, ist dass das in Chrome und Firefox integrierte "key pinning" mit den eingebrachten Zertifikaten ebenfalls ausser Kraft gesetzt wird. "key pinning" ist die eingebaute Zertifikats-Datenbank.
https://blog.mozilla.org/security/2014/09/02/public-key-pinning/
https://www.soeren-hentzschel.at/mo...-32-mehr-sicherheit-durch-public-key-pinning/

Jetzt kommen Eset und Avast daher und setzen einen drauf: interessiert uns nicht, wir prüfen eh alles anders.
Dabei ist "key pinning" ratifiziert worden und die nächste Stufe ist das sogenannte "OCSP Stapling"
https://blog.pki.dfn.de/2015/03/mehr-privacy-fuer-den-nutzer-ocsp-stapling/

Bislang wurde die Gültigkeit von Zertifikaten bei entsprechenden Zertifikats-Serven gegengeprüft. Damit wissen aber genau jene Server, wo der jeweilige Benutzer sich aufgehalten hat, was natürlich der Privatsphäre nicht förderlich ist, falls jemand unbefugtes dort sein Unwesen treiben würden.
Daher wurde das "OCSP Stapling" angeleiert, damit liefert der aufgerufene Server via SSL nicht nur sein Zertifikat, sondern auch eine Gültigkeitsbescheinigung. Die Technik und Software (zB Apache) wurde dem bereits angepasst und erweitert!

Da Avast und Eset dieses Prozedere bislang ablehnen, wissen die von jenen Herstellern genutzten Server bei beim Verfahren ohne Stapling wiederum, wo ihr wart. Ganz großes Kino für Software, die sich eigentlich auf die Fahne geschrieben hat, die Privatsphäre des Benutzers zu schützen.

Wer von euch kommt sich immer noch nicht verarscht vor?

Unabhängig davon ist die vom Produkt erzielte Leistung gegen die bekannten Bedrohungen.

Hatte ich eigentlich schon erwähnt, dass Antivirus-Software sich wie Rootkits verhalten mit ihren Kernel-Treibern? ;)
"Aber das ist eine andere Geschichte und soll ein andermal erzählt werden..."

Nachtrag:
Auch BitDefender gehört mit zu den Verlierern (Feb'15)
Bitdefender Products Break HTTPS Certificate Revocation | Effect Hacking

MfG
 
Zuletzt bearbeitet:
Der sichertse Tipp: Internet abstellen. Das funzt 100%. Aber das wär idiotisch. Wir alle wissen doch, dass es laufend "neue Fallen" gibt. Leben wir damit. Wenn man das nicht akzeptiert "kriegt man nen Vogel".
 
Abends.

Ein wenig "dünn", um darüber nachdenken zu wollen ;)
Es geht weniger um das neue, sondern um das, was man bisher als eigentlich sicher betrachtet hat, gar nicht so sicher ist in Wirklichkeit.

Das Thema SSL zieht weitere Kreise. Leider sind die folgenden Quelle alle nur auf englisch erhältlich, ich versuche, es soweit wie möglich einfach zu übersetzen.

7 mögliche Fehler bei der SSL-Prüfung
https://www.cert.org/blogs/certcc/post.cfm?EntryID=221
1. Unvollständige oder nicht ausreichende Prüfung des Zertifikats.
2. Ergebnisse einer Zertifikatsprüfung werden nicht an den Client weitergegeben, Webinhalte schon.
3. Überfüllung des "Canonical Name (CN-Feld)" kann eine Warnung aussetzen.
4. Unterdrückung oder Fälschung einer Ergebnisseite zur Zertifikatsprüfung
5. Entscheidung einer Prüfung anhand des HTTP-Headers.
6. Die prüfende Software schickt dennoch die Anfragen/Daten an den Server, bevor die Meldung an Client ergeht.
7. Die prüfende Software installiert das gleiche Zertifikat für alle Anwendungen.

Ergebnis: der Benutzer bekommt keine oder falsche Warnungen, oder seine Daten werden dennoch missbraucht, zudem lässt sich das System sogar zentral manipulieren.

Ganz unten auf dieser Seite werden einige Hersteller aufgelistet, die eine SSL-Prüfung mittels Hard-oder Software anbieten und möglicherweise von einem oder mehreren Punkten betroffen sein könnten. Eine Nichtnennung muss nicht automatisch nicht betroffen bedeuten, wie das obige Beispiel Avast zeigt.


CloudFlare bietet seit kurzem "strict ssl" an.
https://www.cloudflare.com/features-cdn

CloudFlare ist ein CDN (Content Distribution Network), ein Anbieter für dezentral gelagerter Webinhalte, um möglichst schnellen Zugriff darauf zu ermöglichen
Content Delivery Network ? Wikipedia

Nicht zu verwechseln mit CloudFront, welches zur Amazon-Gruppe gehört, ebenfalls ein CDN, AWS | Amazon CloudFront CDN ? Netzwerk für die Bereitstellung von Inhalten & Streaming
Akamai ebenso http://www.akamai.de/ und andere.


Englischer Text mit Bildern erklärt:
https://blog.cloudflare.com/introdu...a-man-in-the-middle-attack-on-origin-traffic/
Die Bilder zeigen, dass es diverse Möglichkeiten bei SSL-Verbindungen gibt und wo mögliche Schachstellen sein könnten.
CloudFlare arbeitet bei "strict ssl" mit nur ganz wenigen Stammzertifikaten, um sicherzustellen, dass auch so gut wie niemand die Verbindung zum Server manipulieren kann. Allerdings dürfte "strict ssl" wohl nur bei bezahlten Kunden verfügbar sein.

In einem Gespräch mit einem Amerikaner - USA, das Land der unbegrenzten Möglichkeiten - könnte jener sich auch vorstellen, dass es auch irgendwann ein Gerichtsurteil gegen jemanden mit einer SSL-Prüfung geben könnte. Hintergrund seiner Überlegung, die ich momentan eher für sehr abwegig halte, dass einer seiner Bekannten für eine Bank arbeitet und dort die die forensische Abteilung leitet. Tritt ein Schadensfall ein, gilt der Kunde solange als schuldig, solange er nicht das Gegenteil beweisen kann. Dazu gehört natürlich die aktive Mitarbeit, also auch die Bereitsstellung aller genutzten Hard- und Software, die mit für den Schadensfall ursächlich gewesen sein könnte. Wird dabei festgestellt, dass der Betrug über eine manipulierte SSL-Prüfung stattfand, ist das entsprechend negativ auszulegen - für den Kunden, nicht für die Prüfsoftware/-hardware. D.h. der Kunde muss letztendlich selbst einen Prozess gegen den Hersteller anstreben und freilich auch beweisen, dass deren Soft-/Hardware der Auslöser war. Für Hersteller in den Ostblockstaaten dürfte das wohl reichlich schwierig bis unmöglich werden, und die bekannten Marken in den Staaten dürften die besseren Anwälte und Argumente haben.

MfG
 
http://www.golem.de/news/https-kaspersky-ermoeglicht-freak-angriff-1504-113747.html schrieb:
...Bei Avast ist die HTTPS-Filterung in der Standardeinstellung aktiviert, ...

Also das Häckchen für "HTTPS-Scanning aktivieren" einfach herausnehmen? ^^Sry, da klaffen bei mir einige Wissenslücken auf - das ganze "Protokoll-Gedöns" ist ziemlich trocken um sich das hobby-mäßig mal schnell rein zu ziehen.
 
Oben