Wikimedia Blog/Drafts/Heartbleed

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
This page is a translated version of the page Wikimedia Blog/Drafts/Heartbleed and the translation is 75% complete.

Outdated translations are marked like this.

This post has been published at https://blog.wikimedia.org/2014/04/10/wikimedias-response-to-the-heartbleed-security-vulnerability/ . You are welcome to add translations here.

Other languages:
Bahasa Indonesia • ‎Bahasa Melayu • ‎British English • ‎Deutsch • ‎English • ‎Latina • ‎Nederlands • ‎Tiếng Việt • ‎Türkçe • ‎asturianu • ‎azərbaycanca • ‎dansk • ‎español • ‎français • ‎italiano • ‎magyar • ‎polski • ‎português • ‎português do Brasil • ‎suomi • ‎svenska • ‎Österreichisches Deutsch • ‎čeština • ‎русский • ‎татарча/tatarça • ‎українська • ‎ייִדיש • ‎עברית • ‎العربية • ‎فارسی • ‎مصرى • ‎ଓଡ଼ିଆ • ‎தமிழ் • ‎മലയാളം • ‎ไทย • ‎中文 • ‎日本語 • ‎한국어

Wikimedia's response to the "Heartbleed" security vulnerability

Logo for the Heartbleed bug

Am 7. April wurde ein schwerwiegender Fehler in einem zentralen Baustein der Internet-Sicherheit (OpenSSL) veröffentlicht. Der Fehler wurde nun auf allen Wikimedia-Wikis behoben. Wenn du lediglich Wikipedia ohne ein Benutzerkonto liest, musst du nichts weiter tun. Wenn du ein Benutzerkonto bei irgendeinem Wikimedia-Wiki hast, musst du dich erneut anmelden, bevor du es wieder benutzen kannst.

The issue, called Heartbleed, would allow attackers to gain access to privileged information on any site running a vulnerable version of that software. Wikis hosted by the Wikimedia Foundation were potentially affected by this vulnerability for several hours after it was disclosed. However, we have no evidence of any actual compromise to our systems or our users' information, and because of the particular way our servers are configured, it would have been very difficult for an attacker to exploit the vulnerability in order to harvest users' wiki passwords.

Nachdem wir auf die Sicherheitslücke aufmerksam gemacht wurden, begannen wir damit, all unsere Systeme mit korrigierten Versionen der fraglichen Software auszustatten. Danach fingen wir an, kritische, für den Benutzer sichtbare SSL-Zertifikate auszutauschen und alle Benutzersitzungen zu beenden. (Der vollständige Verlauf ist weiter unten dokumentiert.)

Alle angemeldeten Benutzer senden mit jeder Anfrage an die Seite ein geheimes Session Token. Wenn böswillige Angreifer dieses Token abfangen würden, so könnten sie sich damit als andere Benutzer ausgeben. Dadurch, dass wir alle Session Tokens zurückgesetzt haben, ergibt sich der Vorteil, dass alle Benutzer eine neue Verbindung mit den Servern aufbauen, die die korrigierte Version von OpenSSL verwenden, was diesen potenziellen Angriff unmöglich macht.

Zur Sicherheit empfehlen wir allen Benutzern, ihr Passwort zu ändern, aber zur Zeit haben wir nicht vor, dies zu erzwingen. Nochmal: es gibt keine Hinweise darauf, dass Benutzer der Wikimedia Foundation durch diesen Angriff betroffen sind, aber wir wünschen uns größtmögliche Sicherheit für alle Benutzer.

Vielen Dank für dein Verständnis und deine Geduld.

Greg Grossmeier, im Namen der WMF Operations und Platform Teams

Verlauf der Reaktion durch Wikimedia

(Alle Zeiten in UTC)

7. April:

8. April:

09:08: Wir fangen an, SSL-Zertifikate zu ersetzen.

13:09: Wir erzwingen eine libssl-Aktualisierung auf WMF Tool Labs.

16:45: Alle Wikimedia-Wiki-SSL-Server verwenden neue Zertifikate.

9. April:

13:54: Das SSL-Zertifikat von ticket.wikimedia.org wird ersetzt (das letzte)

  • 16:44: An alle Benutzer von ticket.wikimedia.org (OTRS) und otrs-wiki.wikimedia.org werden E-Mails mit der Empfehlung, ihre Passwörter zu ändern, verschickt .
  • 22:33: Logged out all Bugzilla users

10. April:

Häufig gestellte Fragen

(Dieser Abschnitt wird bei Bedarf erweitert.)

  • Warum wurde das „nicht gültig vor“-Datum des SSL-Zertifikats nicht geändert, als es ersetzt wurde?
    Der Aussteller unserer SSL-Zertifikate behält das „nicht gültig vor“-Datum (das manchmal auch fälschlicherweise als „ausgestellt am“-Datum verstanden wird) in allen ersetzten Zertifikaten bei. Dies ist nicht ungewöhnlich. Um zu überprüfen, dass der Wechsel stattgefunden hat, kannst du die Änderung an den .pem-Dateien oben im Verlauf nachvollziehen oder den Fingerabdruck des neuen Zertifikats mit dem des alten vergleichen.