Blogue Wikimédia/Brouillons/Heartbleed
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.
Réponse de Wikimédia à la vulnérabilité de sécurité « Heartbleed »
Le 7 avril a été révélé un problème très répandu dans un composant central (OpenSSL) pour la sécurité sur Internet. La vulnérabilité a maintenant été corrigée sur tous les wikis de Wikimédia. Si vous ne faites que lire Wikimédia sans créer de compte, vous n'avez rien à faire. Si vous avez un compte utilisateur sur un wiki de Wikimédia, vous devrez vous reconnecter la prochaine fois que vous utiliserez votre compte.
Le problème, appelé « Heartbleed », pourrait permettre à des attaquants d’avoir accès à des informations privilégiées sur tout site exécutant une version vulnérable de ce logiciel. Les wikis hébergés par la Fondation Wikimédia ont été potentiellement affectés par cette vulnérabilité durant quelques heures après sa découverte. Cependant, nous n’avons aucune preuve de compromission effective de nos systèmes ou des informations de nos utilisateurs et, du fait de la façon particulière dont nos serveurs sont configurés, il aurait été très difficile à un attaquant d’exploiter cette vulnérabilité afin de récolter les mots de passe des utilisateurs sur nos wikis.
Dès que nous avons été avisés du problème, nous avons commencé à mettre à jour nos systèmes avec des versions corrigées du logiciel en question. Nous avons commencé à remplacer les certificats SSL critiques exposés à l’utilisateur et à réinitialiser tous les jetons de sessions d’utilisateurs. Consultez le calendrier complet de notre réponse ci-dessous.
Tous les utilisateurs connectés envoient un jeton secret de session avec chacune de leurs requêtes au site. Si une personne malveillante était en mesure d’intercepter ce jeton, elle pourrait se faire passer pour d’autres utilisateurs. La réinitialisation des jetons de tous les utilisateurs a l’avantage de faire se reconnecter tous les utilisateurs à nos serveurs en utilisant la version mise à jour et corrigée du logiciel OpenSSL, ce qui ôte cette attaque potentielle.
Nous recommandons de modifier votre mot de passe en tant que mesure standard de précaution, mais nous ne comptons pas actuellement forcer ce changement pour tous les utilisateurs. À nouveau, il n‘y a pas eu de preuve que les utilisateurs des serveurs de la Fondation Wikimédia ont été la cible de cette attaque, mais nous voulons que nos utilisateurs soient dans une situation aussi sûre que possible.
Merci pour votre compréhension et votre patience.
Greg Grossmeier, au nom des équipes des opérations et plateforme de la Fondation Wikimédia.
Chronologie de la réponse de Wikimédia
(Les heures sont mentionnées dans le fuseau UTC.)
7 avril :
- 17h30 : L’anomalie Heartbleed est rendue publique.
- 21h48 : Ubuntu publie des versions corrigées du logiciel.
8 avril :
- 04h03 : Nous commençons à mettre à jour libssl sur tous nos serveurs, en commençant par les machines les plus prioritaires.
- 09h08 : Nous commençons à remplacer les certificats SSL.
- 13h09 : Nous forçons la mise à jour de libssl sur les serveurs des Tool Labs de la Fondation Wikimédia.
- 13h46 : La mise à jour de libssl est achevée sur tous les serveurs publics.
- 16h45 : Tous les serveurs SSL de wikis exposés aux utilisateurs ont de nouveaux certificats en place.
- 23h08 : Nous commençons à réinitialiser les jetons de connexion des utilisateurs (ce qui force les utilisateurs à se reconnecter en utilisant les nouvelles versions de libssl et des certificats).
9 avril :
- 13h54 : Le certificat SSL de ticket.wikimedia.org est remplacé (le dernier)
- 16h44 : Envoi d’un courriel à tous les utilisateurs de ticket.wikimedia.org (Special:MyLanguage/OTRS) et de otrs-wiki.wikimedia.org pour leur demander de changer leurs mots de passe.
- 22h33 : Déconnexion de tous les utilisateurs de Bugzilla
10 avril :
Foire aux questions
(Cette section sera étendue si nécessaire.)
- Pourquoi la date « non valide avant » de notre certificat SSL n’a-t-elle pas été changée si vous l’avez déjà remplacée ?
- Notre fournisseur de certificat SSL conserve la date originale « non valide avant » (parfois incorrectement décrite comme la date « publiée le ») dans tout certificat remplacé. Ceci n’est pas une pratique rare. En dehors de la consultation des fichiers .pem liés dans la chronologie ci-dessus, l’autre façon de vérifier que le remplacement a eu lieu est de comparer l’empreinte numérique de notre nouveau certificat avec la précédente.