Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Vorweg: Dies soll keine Panik auslösen, sondern in einfachen Worten auf ein derzeit potentielles Sicherheitsproblem hinweisen. Nur wer mögliche Gefahren kennt, kann auch entsprechend handeln. Dabei soll dieser Beitrag helfen.

Vorgestern wurde eine Sicherheitslücke in den neuesten Versionen von OpenSSL bekanntgegeben -> https://www.openssl.org/news/secadv_20140407.txt
Wer die technischen Hintergründe, Möglichkeiten und Auswirkungen genauer nachlesen möchte -> http://heartbleed.com/
Etwas gekürzt auch auf Deutsch -> https://www.cert.at/warnings/all/20140408.html

Kurzfassung: Ausgerechnet jener Systemteil, der besonders sensible Datenübertragungen durch Verschlüsselung vor fremden Blicken schützen soll, hat einen Bug. Durch diesen ist es Angreifern möglich, von betroffenen Systemen Schlüsseldaten zu klauen, mit denen anschließend jede SSL/TLS-verschlüsselte Datenübertragung in Echtzeit entschlüsselt werden kann. Dazu muss der Angreifer natürlich auch die Übertragung belauschen können, im Regelfall würde er dabei allerdings nur Datenmüll sehen. Besitzt er jedoch die genannten Sicherheitsinformationen, kann er den Inhalt genauso entziffern wie der eigentlich angesprochene Rechner.
Ironischerweise tritt der Bug erst ab neueren Versionen der OpenSSL-Library auf. Ältere (oder absichtlich in ihren Funktionen eingeschränkte) Systeme sind davon nicht betroffen. (Zu alte allerdings vielleicht von älteren Schwachstellen...)

Wer ist betroffen?
Vor allem natürlich die Betreiber von SSL/TLS-geschützten Diensten. Dies sind vor allem Webseiten (https://www.xy.tld), aber auch z.B. die gerade und endlich auf SSL/TLS umstellenden mail-Provider. Ebenfalls alle, die selbst SSL-gesicherte Dienste verwenden oder anbieten (owncloud, ...)
In zweiter Linie natürlich die Nutzer dieser Dienste. Wer selbst einen Dienst nur zur eigenen Nutzung betreibt, muss selbst entscheiden, wie sensibel seine Daten sind und wie lohnend sein Server als Angriffsziel sein könnte. Demenstprechend sollte er sich um den inzwischen erhältlichen Bugfix kümmern. Wer seinen Dienst auch anderen zur Verfügung stellt, steht hierbei natürlich auf einer anderen Stufe der Verantwortung.

Was kann der einzelne tun?
Als Betreiber eines Web-Dienstes: Wie immer Security-Advisories beachten und seine OpenSSL-Version aktualisieren bzw. patchen. Außerdem in guter Manier davon ausgehen, daß der Schaden bereits eingetreten ist anstatt das Gegenteil zu hoffen. Das heißt: Alle vorhandenen Zertifikate für ungültig erklären und neue ausstellen (lassen).
Als Nutzer: Darauf achten, ob der verwendete Service betroffen sein könnte. Gegebenenfalls nachfragen und das Problem direkt ansprechen. Bis zur Klärung den Hausverstand gebrauchen. Wenn z.B. die Bank keine Ahnung hat, wovon man redet, auf jeden Fall die Nutzung von Telebanking überdenken, bis eine Lösung erkennbar ist.

Wie stellt man fest, ob ein Dienst betroffen ist?
Am schnellsten mit einem Terminalkommando:

Zitat

echo QUIT | openssl s_client -connect www.meinebank.com:443 -tlsextdebug 2>&1 | grep heartbeat

("www.meinebank.com" durch die abzufragende Adresse ersetzen)
Lautet die Ausgabe:

Zitat

TLS server extension "heartbeat" (id=15), len=1

...dann ist Vorsicht angezeigt, denn "Heartbeat" ist die Erweiterung, die den beschriebenen Angriff möglich macht.

Das gleiche Verfahren kann auch zum testen von mail-, jabber- und anderen Diensten angewendet werden. Hier ist allerdings der Hostname des Servers, sowie der entsprechende Port zu beachten. Beispiele:
ups...

Zitat von »DocHifi«

Was ist also zu tun

Große Anbieter sollten eigentlich selbst wissen was läuft und was sie tun können/sollten. So habe ich unter anderem von zwei Webdiensten gestern die Nachricht erhalten, daß sie bereits reagiert haben. Sie haben das Update eingespielt und sicherheitshalber alle verbundenen Clients ausgeloggt. Somit müssen diese die Verbindung neu aufbauen, was dann über die nunmehr wieder sichere Verbindung geschieht.

Aber es kann sicher nicht schaden, einmal freundlich nachzufragen.

Zusätzlich sollten alle Nutzer von verschlüsselten Diensten - egal welcher Art: Web, mail, VPN, etc. - umgehend ihre Zugangsdaten (Passwörter) ändern.
Warum? Siehe oben: Was für die Betreiber gilt, trifft natürlich auch für die Anwender zu: Im Zweifel davon ausgehen, daß die eigenen Zugangsdaten bereits entwendet worden sein können anstatt zu hoffen, daß es einen selbst schon nicht treffen wird.
(Wer sich jetzt noch hinter dem berühmten "Ich hab eh nix zu verbergen" versteckt, dem kann leider heutzutage nicht geholfen werden...)

Als bildhafte Info hier noch ein Screenshot von heute morgen (Quelle: teletext.orf.at):


Weitere Infos stehen bereits überall im Netz. Seid wachsam, aber nicht panisch: Es gibt auch andere SSL-Implementationen, somit ist keineswegs garantiert, daß alle Dienste davon betroffen sind. Allerdings ist OpenSSL die am meisten verwendete Library.

Hier noch eine Info, um das Problem deutlicher darzustellen. (Wollte es gestern so schnell wie möglich auch für Laien verständlich rüberbringen und habe deshalb nicht so ganz genau die Hintergründe durchleuchtet.) Also:

Zitat von »Fredl«

Dazu muss der Angreifer natürlich auch die Übertragung belauschen können, im Regelfall würde er dabei allerdings nur Datenmüll sehen.

Update: Es ist nicht nötig, eine Verbindung zu belauschen (was ja ohnehin bereits ein unbefugtes Eindringen in ein Datennetz wäre). Es geht leider viel einfacher über eine ganz normale Verbindung, während der die Lücke ausgenutzt werden kann. Das ganze spielt sich innerhalb des für den Anwender normalerweise unsichtbaren Datenaustauschs zwischen Client und Server ab. Vereinfachtes Szenario:
Hacker baut Verbindung zu SSL-gesicherter Webseite auf (also praktisch jede, sobald es um halbwegs sensible Daten geht). Während seiner Verbindung wendet er den Hack an und erlangt dadurch Zugriff auf interne Speicherbereiche des Webservers. Hier kann er nun in kleinen Häppchen Daten auslesen. Dabei kann er auf wirklich kritische Daten stoßen, wie zum Beispiel geheime Schlüsseldaten des Serverzertifikates. Damit wird es ihm möglich, dieses selbst zu verwenden, was in einer sicheren Umgebung ein absolutes no-go sein sollte. Zusätzlich können auch gerade übertragene Daten anderer Verbindungen im Speicher liegen, die er somit ebenfalls "finden" kann. Spätestens hier läuten Alarmglocken, denn das können ohne weiteres Zugangsdaten anderer User sein. Das besonders gemeine daran ist, daß diese Aktivitäten gar nicht aufgezeichnet werden, weil es sich im Rahmen der normalen Rechner-Kommunikation abspielt. Somit kann der Urheber gar nicht entdeckt bzw. ausgeforscht werden. (Derzeitiger Wissenstand)
Nicht umsonst ist bereits vom "Super-GAU" die Rede. Hier hilft eigentlich nur schnelles Handeln der User und vor allem der Betreiber, um das schlimmste zu vermeiden.
Zwar sind m.W. noch keine Datendiebstähle auf diese Art bekannt geworden, allerdings kursieren bereits erste "Anleitungen" für die Script-Kiddies. Man sollte also davon ausgehen, daß die echten Profis bereits ihre Tentakel geölt haben könnten.

Und nochwas zu den eigenen Passwörtern: Abgesehen davon, daß man diese ohnehin regelmäßig ändern sollte, sollte man auch keines für "unwichtig" halten. Wer meint, sein e-mail Konto sei sowieso uninteressant, sollte daran denken, daß viele andere Dienste über die Funktion "Passwort vergessen" entweder neue Zugangsdaten versenden oder eine Änderungsfunktion anbieten. Nicht selten spielt dabei die hinterlegte email-Adresse eine Rolle. Wer also demnächst mit seinen gewohnten Zugangsdaten irgendwo nicht mehr reinkommt, hat ein ernstes Problem.

Tipp: Wo immer es angeboten wird, sollte eine zweistufige Authentifikation (SMS-Code, One-Time-Passwort, Zeitbasierte Passwörter, etc.) genutzt werden. Ich selbst bekam gestern in kurzer Folge drei Auth-SMS von paypal, obwohl ich gar nicht auf mein Konto zugreifen wollte. Die SMS werden allerdings erst nach dem manuellen Login ausgelöst...

Zitat von »diesch«

Dazu muss der Angreifer die Übertragung nicht belauschen können

Das habe ich auch in meinem heutigen update richtiggestellt.

Zitat von »diesch«

so dass eine aktive Heartbeat-Erweiterung kein Hinweis auf ein Problem ist

Sagen wir es ist kein eindeutiger Nachweis, daß der Server die Lücke tatsächlich hat. Deshalb habe ich auch jeweils mit "könnte" formuliert. Es hat auch keinen Sinn, unnötig Panik zu verbreiten. Ein Hinweis zur Vorsicht ist es aber allemal. Denn:

Zitat von »diesch«

Inzwischen sollte jeder halbwegs brauchbare Admin die nötigen Aktualisierungen eingespielt haben

Dein Wort in Gottes Gehörgang
Man bedenke aber auch, daß das Besorgen und Installieren von neuen Zertifikaten u.U. auch etwas Zeit in Anspruch nehmen kann, speziell bei "hochwertigen" CAs/Servern. Weiters müssen die alten Zertifikate für ungültig erklärt werden, was zwar normalerweise beim Erneuern automatisch geschieht. Das nützt aber wenig, wenn die Anwender die Überprüfung auf abgelaufene Zertifikate nicht nutzen bzw. ausgeschaltet haben. Hier ist wieder der Anwender in der eigenen Verantwortung. Pop-ups in Warnfarben kommen nie ohne Grund! (Man sollte die Warnungen lesen vor dem Wegklicken...)
Nicht übersehen sollte man, daß auch bei schnellster Reaktionszeit mehrere Tage vergangen sind in denen die Lücke bekanntermaßen vorhanden war. Wie lange sie davor schon bestand und ob sie inzwischen ausgenutzt wurde, wird die Zukunft zeigen.

Zitat von ».not«

Mails hat wie von StartSSL

Achja, die werden in letzter Zeit auch immer zugänglicher für Extra-Einnahmen.*) Naja, langsam ist sogar am freien SSL-Markt etwas Kohle drin.

Zitat von ».not«

War eine durchpatchte Nacht

Mein Mitleid

*) Schon das neueste gehört? uberspace hat kürzlich die Zertifikate getauscht (hat jetzt nichts mit dem Thema zu tun). Dabei sind sie aber von Startcom weg zu einer anderen CA. Warum? Die waren plötzlich dagegen, daß sie ihr (bezahltes Class3) Wildcard-CRT ihren Usern zur eigenen Verwendung borgen. Außer gegen extra Kohle...

Zitat von »rbest«

jaaaa, Sie haben ja den vserver ... und da gibt es ja noch die Ubuntu-Foren.

Und das hat Strato so gesagt?

Zitat von »rbest«

ob ich jetzt in Panik geraten soll oder nicht.

Als Server-Admin sollte man immer einen erhöhten Adrenalin-Spiegel haben, auch als untauglicher.
Rest siehe maettu's Antwort. Wenn deine WP-User sich sowieso immer unverschlüsselt einloggen, ist jeder Bug unwichtig. Aber bestimmt haben sie für jede Webseite ein eigenes Passwort. Kann also kaum was passieren...

Übrigens:

Zitat von »floogy«

Also besser alle Zertifikate und betroffenen Passwörter mit gepatchtem OpenSSL erneuern.

Die Reihenfolge wäre wichtig:
1. Neues oder gepatchtes OpenSSL
2. Neue Zertifikate + alte revoken
3. neue Passworter
Solange am Server der Bug besteht, haben neue PWs nur mäßigen Sinn, denn sie können sofort wieder abhanden kommen. Ideale Strategie wäre natürlich häufiger PW-Wechsel, bis der Server nachweislich entbuggt ist. Danach nur noch wöchentlich

PS: Alles gllt, falls nicht ohnehin eine andere, nicht betroffene SSL-implementation installiert war/ist.

Zitat von »floogy«

web.de und andere getestet, die waren alle ok, aber waren sie das auch vor zwei Tagen?

Siehe Beitrag #2...

Zitat von »floogy«

Haben sie auch die Zertifikate erneuert und zurückgezogen?

Die Zertifikate haben ein Gültigkeitsdatum.

Zitat von »Fredl«

Die Zertifikate haben ein Gültigkeitsdatum.

... das ich mir bei web.de jetzt angesehen habe. Daraus ergibt sich, daß es vor zwei Tagen neu ausgestellt wurde. Der Test von Doc kam demnach einen Tag zu spät. Da aber heartbeat noch immer aktiviert ist, wird es das auch vorher gewesen sein. Nachdem sie das Zertifikat erneuert haben, kann man schließen, daß sie eine betroffene Version von OpenSSL am Start hatten. Sonst hätten sie wohl kaum ein neues Zertifikat gekauft. Wenn man davon ausgeht, daß sie auch die OpenSSL-Version erneuert haben, sollte jetzt alles ok sein, selbst wenn die "heartbeat"-Erweiterung noch immer aktiviert ist. Das Problem war ja hearbeat in den Versionen von 1.0.1 bis 1.0.1f. Daher auch immer meine vorsichtige Formulierung, wenn "hearbeat" aktiv ist, dann könnte der Server betroffen sein. Eine Verifikation bedarf weiterer Informationen, die letzten Endes nur Betreiber haben kann.
Aber um die Beruhigung nicht ausufern zu lassen: Version 1.0.1 war seit Dezember 2011 freigegeben...

Zitat von »rbest«

ob mein Verwaltungsserver (oder wie soll ich das Teil nennen, wo ich die Sites mit Plesk Panel verwalte?), das ist eine subdomain von stratoserver.net mit Zugang über Port :8443, in Gefahr ist.

Ruf die Seite auf und sieh dir das Zertifikat an + mach den Test aus Beitrag #1. Dann überlege weiter.

Zitat von »rbest«

Was könnte da schlimmstenfalls passieren?

Ich schreibe den ersten Beitrag jetzt nicht nochmal, und das Netz quillt mittlerweile über von Infos.