TAGS
Actualización (28/05/14): Lamentablemente, la mayoría de las historias que cubren esta entrada del blog han sido todos "OMG Todo esta roto" en lugar de "Así es cómo hacer mejor las cosas hasta WordPress lanza una solución" (lo que humildemente cree que va a tomar un tiempo para * * totalmente corrección, dado que su soporte SSL es tan irregular). Por lo tanto, dado que la mayoría de la gente que lee esto probablemente provengan de uno de esos artículos, creo que es importante comenzar con los puntos de acción que la gente puede hacer para mitigar los ataques de galletas-secuestro en WordPress:
post original a continuación.
Mientras que la caza de un informe de error para, me di cuenta de la cookie "wordpress_logged_in" que se envía a través de HTTP claro a un punto final de la autenticación de WordPress (en el blog de alguien.
Suena como una mala noticia! Como siempre, dijo mamá, usted debe establecer el indicador de "seguro" en las cookies sensibles, de modo que nunca son enviados en texto plano.
Para comprobar si esta cookie hizo nada interesante, sesión de mi cuenta de wordpress, copié la cookie wordpress_logged_in en un perfil del navegador fresco, y visitado en el nuevo perfil del navegador. Sí, yo estaba conectado!
Esto no sería tan malo si la cookie wordpress_logged_in se invalida cuando el usuario cierra la sesión original, o se puede anotar de nuevo, pero sin duda aún funcionaba. Expira? En 3 años. (No estoy seguro cuando se invalida en el lado del servidor, no han esperado el tiempo suficiente como para saber.)
Es esto tan malo como el envío de nombre de usuario / contraseña en texto plano? Traté de ver si podía restablecer la contraseña del usuario original.
Eso no funcionó, así que estoy asumiendo WordPress utiliza la cookie no segura (wordpress_sec) para operaciones muy importantes como el cambio de contraseña. Buen trabajo, pero. . .
Resulta que podía publicar en el blog del usuario original (y crear nuevos sitios de blogs en su nombre):
Podía ver los mensajes privados:
Podría publicar comentarios en otros blogs como ellos:
Podía ver sus estadísticas en el blog:
Etcétera. No podía hacer algunas tareas del administrador del blog que requieren acceder de nuevo con el nombre de usuario / contraseña, pero aún así, no está mal para una sola cookie.
Moraleja de la historia: no visitan un sitio de WordPress mientras está conectado a su cuenta en una red local no es de confianza.
Actualización: Gracias a Andrew Nacin de WordPress para informar a mí que las cookies de autenticación será invalidado después de una sesión termina en la próxima versión de WordPress y que el soporte SSL en WordPress será mejorar!
Actualización (26/05/14): I posteriormente se determine que la cookie insegura podría ser usado para fijar el dispositivo de autenticación 2fac de alguien si no lo había puesto, bloqueando de este modo a salir de su cuenta. Si alguien ha establecido ya 2fac, el atacante puede todavía derivación de inicio de sesión de autenticación mediante el robo de galletas - la cookie de autenticación 2fac también se envía a través de texto plano.
Actualización (26/05/14): Un par de personas han preguntado acerca de si la línea de tiempo debajo de la divulgación es razonable, y mi respuesta es.
Divulgación línea de tiempo:
Miér 21 May 2014 16:12:17 PST: Correspondiente al tema security@automattic.com~~V, según las instrucciones en este punto, el informe era sobre todo por cortesía, ya que pensé que tenía que ser obvio para ellos y muchos WP los usuarios ya que la cookie de inicio de sesión no estaba asegurada (es sólo un ajuste de configuración simple en WordPress para encender el indicador galleta segura, como yo lo entiendo). Recibido ninguna indicación de que se ha recibido el correo electrónico.
22 de de mayo de 2014 16:43: mencionaron la falta de galletas asegurar públicamente.
22 de de mayo de 2014 17:39: respuesta recibida de Andrew Nacin (no en relación con la falta de galleta de fijación, sino más bien que la vida útil de autenticación de cookies pronto será la de una cookie de sesión regular).
23 de de mayo de 2014 ~ 13: 00: Descubierto tema de autenticación de dos factores en accidentes, informó que tanto security@automattic.com y security@wordpress.org en respuesta al mensaje original. También lo mencioné a Dan Goodin desde que encontré el error al intentar responder a una pregunta que tenía sobre las cookies, pero no revelar públicamente.
25 de de mayo de 2014 15:20: La respuesta de correo electrónico que provienen security@automattic.com diciendo que estaban buscando en ella internamente (sin mención de la línea de tiempo). Escribió de nuevo a decir gracias.
26 de mayo de 2014, ~ 10: 00: artículo de Ars Technica sobre esto se publica, que menciona el tema de autenticación 2-fac. He actualizado esta entrada del blog para reflejar eso.
26-27 de de mayo de 2014: Algunos comentaristas sobre el artículo Ars Technica descubrir un error posiblemente peor que el que el artículo original estaba por: WordPress envía el formulario de acceso a través de HTTP. (A pesar de que la forma POST es a través de HTTPS, el atacante red local puede modificar los objetos en la página HTTP sin embargo, él / ella quiere y luego se acabó el juego.) Esto no sería tan malo si todo el mundo utiliza un gestor de contraseñas y cambió las contraseñas semi-regularmente, ya que la mayoría de la gente tiende a iniciar sesión en WordPress a través del portal de administración de sus blogs (que es siempre https por lo que yo puedo decir), excepto que reutilización de contraseñas es rampante. Robert Graham publicó posteriormente.
29 de mayo de 2014, 05:52: respuesta recibida de WordPress diciendo que me iban a correo electrónico de nuevo cuando se fija.
30 de mayo de 2014, 14:51: Andrew Nacin dice que todos los temas están supuestamente fijos.
.
