Wikimedia Blog/Borradores/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 88% 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 • ‎українська • ‎ייִדיש • ‎עברית • ‎العربية • ‎فارسی • ‎مصرى • ‎ଓଡ଼ିଆ • ‎தமிழ் • ‎മലയാളം • ‎ไทย • ‎中文 • ‎日本語 • ‎한국어

Respuesta de Wikimedia ante la vulnerabilidad de seguridad "Heartbleed"

Logotipo del error Heartbleed

El 7 de abril se reveló un problema generalizado en un componente central de la seguridad en Internet (OpenSSL). Ya hemos remediado esta vulnerabilidad en todos los wikis de Wikimedia. Si usted solo lee Wikipedia sin crear una cuenta, no necesita realizar ninguna acción. Si tiene una cuenta de usuario en cualquier wiki de Wikimedia, tendrá que iniciar una sesión nueva la próxima vez que use su cuenta.

El problema, conocido como Heartbleed, permitió a posibles atacantes el acceso a información privilegiada en cualquier sitio que utilizara una versión vulnerable de ese software. Las wikis hospedadas por la Fundación Wikimedia estuvieron expuestas durante varias horas después de darse a conocer este punto débil. Sin embargo, no tenemos ninguna evidencia de que nuestros sistemas o la información sobre nuestros usuarios hayan sido afectados, y, debido a la forma particular en nuestros servidores están configurados, hubiera sido muy difícil que un atacante se aprovechara de la vulnerabilidad con el fin de obtener las contraseñas de los usuarios.

Después de habernos enterado del problema, comenzamos a actualizar todos nuestros sistemas con versiones reparadas del software en cuestión. Después empezamos a sustituir certificados SSL críticos y a reestablecer todas las claves de sesión de usuario. El historial completo de nuestra respuesta se muestra a continuación.

Todos los usuarios registrados envían una señal de sesión secreta con cada solicitud al sitio. Si una persona malintencionada fuera capaz de interceptar esa señal, podría suplantar a otros usuarios. La reposición de las señales para todos los usuarios tiene la ventaja de hacer que todos los usuarios se vuelven a conectar a nuestros servidores utilizando la versión actualizada y fija del software OpenSSL, eliminando así este ataque potencial.

Le recomendamos cambiar su contraseña como medida de precaución estándar, pero no tenemos la intención actualmente de hacerlo obligatorio para todos los usuarios. Reiteramos que no hay evidencia de que los usuarios de la Fundación Wikimedia fueran el blanco de este ataque, pero queremos que todos nuestros usuarios estén lo más seguros posible.

Gracias por su comprensión y paciencia.

Greg Grossmeier, en nombre de los equipos de Operaciones y Plataforma de la Fundación Wikimedia (WMF).

Cronología de la respuesta de Wikimedia.

(Los horarios están en UTC)

7 de abril:

8 de abril:

09:08: Iniciamos el reemplazo de los certificados SSL.

13:09: Forzamos la actualización de libssl en WMF Tool Labs.

16:45: Todos los servidores wiki de Wikimedia accesibles a los usuarios que usan SSL tienen nuevos certificados.

9 de abril:

13:54: Se reemplaza el certificado ssl de ticket.wikimedia.org (el último)

10 de abril:

Preguntas frecuentes

(Esta sección se expandirá conforme sea necesario).

  • ¿Por qué no cambia la fecha "no válido antes de" en el certificado SSL si ya lo han reemplazado?
    Nuestro proveedor de certificado SSL conserva la fecha original del "no válido antes de" (al que algunas veces se refiere incorrectamente como fecha de "publicado en") en cualquier certificado reemplazado. No se trata de una práctica inusual. Además de observar los cambios en los archivos de tipo .pem enlazados en la cronología, se puede también verificar que el reemplazamiento se llevó a cabo comparando la huella digital (fingerprint) del nuevo certificado con el del anterior.