¿Se deben suspender los complementos mantenidos del repositorio de WordPress cuando hay un problema de seguridad?

Publicado: 2020-03-12

El 27 de febrero de 2020, a las 9:34 p. m. (CET), recibimos un correo electrónico notificándonos que nuestro complemento WP Activity Log fue "retirado temporalmente del directorio de complementos de WordPress.org debido a un exploit" .

Enviamos una solución el viernes 28 de febrero de 2020 a las 4:08 p. m. Solo tardamos 16,5 horas en publicar la corrección. Habríamos solucionado el problema mucho antes si esto sucediera durante nuestro horario laboral normal (estamos ubicados en Europa), porque tenemos un tiempo de respuesta de soporte muy bueno (referencia).

Nuestro complemento se restableció el lunes 2 de marzo de 2020 a la 1:00 p.m. Eso es 69 horas después de que enviamos la corrección. Es importante tener en cuenta que el equipo tardó tanto en restablecer el complemento debido al fin de semana.

Registro de actividad de WP retirado del repositorio

¿Por qué estoy escribiendo esto?

Me gustaría señalar que creo que los complementos no mantenidos que tienen problemas de seguridad deben suspenderse del repositorio de WordPress. Además, tengo un gran respeto por el trabajo que realizan los voluntarios del equipo de revisión de complementos, y también asumo toda la responsabilidad por el problema de seguridad informado.

Sin embargo, creo que los problemas de seguridad informados en los complementos mantenidos podrían manejarse mejor. Debido a la forma en que se manejan en este momento, la reputación del complemento recibe un gran impacto negativo y sus usuarios y sus sitios web están en riesgo. Por lo tanto, al final de esta publicación, destaco algunas posibles mejoras que pueden ayudar y que creo que deberían tenerse en cuenta. La idea es siempre poner en riesgo a menos usuarios y disminuir el impacto en el complemento y los desarrolladores.

En esta publicación, también documento todos los detalles de lo que sucedió y explico la vulnerabilidad de caso de borde de baja gravedad informada en nuestro complemento.

¿Cuál es el procedimiento para informar un problema de seguridad del complemento de WordPress?

De las pautas oficiales en el Manual de complementos:

Todos los intentos de contactar al desarrollador directamente deben hacerse antes de informarnos sobre el complemento (aunque entendemos que esto puede ser difícil: verifique primero el código fuente del complemento, muchos desarrolladores enumeran sus correos electrónicos). Si no puede comunicarse con ellos en privado, contáctenos directamente y lo ayudaremos.

¿Qué pasó en nuestro caso?

Dejamos muy claro en el complemento quién desarrolla el complemento. ¡Solo mire la página del complemento en el repositorio y tendrá una idea! También hacemos que sea muy fácil ponerse en contacto con nosotros.

Sin embargo, nadie nos informó del problema de seguridad antes de que el complemento se retirara temporalmente del repositorio de complementos. Entonces, alguien informó el problema al equipo de revisión de complementos de WordPress y retiraron temporalmente nuestro complemento del repositorio sin notificación previa.

Antes de sumergirnos en los porqués y qué, y qué es bueno, malo y qué se puede mejorar, echemos un vistazo a la vulnerabilidad del complemento y una breve explicación de quiénes somos.

¿Cuál era la vulnerabilidad del complemento?

Tenemos un asistente de instalación en el registro de actividad de WP para ayudar a los usuarios a configurar el complemento. Una de las configuraciones en el asistente le permite a los usuarios que no son administradores leer los registros de actividad.

Asistente de instalación del registro de actividad de WP

Sin embargo, cometimos un error; no verificamos si el usuario que ejecuta el asistente estaba autenticado. Por lo tanto, los usuarios no autenticados podrían ejecutar el asistente y permitir que otro usuario o función acceda a la configuración del complemento. Sin embargo, este es un problema de baja gravedad del caso extremo.

¿Por qué se trata de un problema de seguridad de casos perimetrales de baja gravedad?

Los atacantes solo podrían explotar esto si:

  • el asistente de instalación nunca fue completado por el instalador,
  • los atacantes ya tenían un usuario / tenían acceso a un usuario en el sitio web,
  • Los atacantes solo pueden obtener acceso a la configuración y el registro de actividad del complemento.

Al explotar estos problemas de seguridad, los atacantes no obtienen acceso a otros privilegios en el sitio web de WordPress. Por lo tanto, este exploit no tiene ningún efecto negativo en el comportamiento y la funcionalidad del sitio web en sí.

Prueba de concepto

El POC es muy simple. Visite esta página como usuario no autenticado:

http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access

Este es el paso del asistente que le permite especificar quién puede ver los registros. Busque el nonce '_wpnonce' en el código fuente de la página HTML, cópielo e insértelo en el siguiente comando curl:

$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access' -d '_wpnonce=INSERT-NONCE-AQUÍ&wsal-access=yes&editors%5B%5D= suscriptor&save_step=Siguiente'

Una vez que inicie sesión como suscriptor, tendrá acceso completo a la configuración del complemento.

¿Por qué creemos que este caso fue mal manejado?

En el correo electrónico que nos enviaron, había lo siguiente:

No cerramos complementos a la ligera y, cuando se trata de problemas de seguridad, intentamos equilibrar el volumen de usuarios y el historial de los desarrolladores con la gravedad y el potencial de daño del informe.

Sin embargo, creo que nuestro complemento se retiró demasiado pronto. Hasta aquí;

  1. Cuando tuvimos problemas en el pasado, siempre los abordamos en unas pocas horas. Hicimos lo mismo esta vez.
  2. Siempre respondimos a tiempo cuando el equipo de revisión de complementos se puso en contacto.
  3. El problema de seguridad solo afectó a nuestro complemento (gravedad baja) y fue un caso extremo.
  4. El problema de seguridad no podía explotarse automáticamente.
  5. El único daño que podía hacer el atacante era cambiar la configuración del complemento, leer los registros de actividad o purgarlos.

¿Qué piensan otros desarrolladores de tales situaciones?

La mayoría de nosotros ya hemos leído un artículo, tweet o mensaje en las redes sociales sobre temas similares. Sin embargo, quería descubrir por mí mismo lo que otras personas, especialmente los desarrolladores, piensan sobre esto. Creo que esto es importante porque puede haber algunas cosas que no estoy viendo.

Para empezar, envié un correo electrónico a la persona que identificó el problema, agradeciéndole la divulgación responsable. Su respuesta fue:

“Me alegra ver que solucionó rápidamente el problema en el complemento. Por cierto, me di cuenta de que la gente de wordpress.org lo cerró durante unos días, eso fue un poco duro y no era realmente necesario.”- Jerome Bruandet.

También hice una pequeña encuesta en el grupo de Facebook Selling WordPress Products. Aunque este grupo es pequeño, la mayoría de sus miembros son desarrolladores de complementos y temas. De la encuesta podemos ver que los desarrolladores acuerdan unánimemente que en caso de problemas de gravedad baja a media, se debe contactar a los desarrolladores y darles la oportunidad de proporcionar una solución y no retirar el complemento:

Encuesta de desarrolladores de complementos de WordPress en grupo de Facebook

¿Cómo se pueden mejorar estos procedimientos?

Que yo sepa, no existen procedimientos documentados para cuando alguien informa un problema de seguridad en un complemento. Si este es el caso, los procedimientos como el siguiente podrían ayudar a los desarrolladores y también poner en riesgo a menos personas.

Póngase en contacto con los desarrolladores y acuerde un plan de acción antes de cerrar el complemento

El equipo de revisión de complementos puede intentar ponerse en contacto con los desarrolladores y confirmar la vulnerabilidad antes de cerrar el complemento. Los desarrolladores deben responder con un plan de acción, incluida una fecha razonable para la corrección.

Si es necesario, el equipo de revisión de complementos puede establecer una fecha límite. Por ejemplo, los desarrolladores deberían tener entre 12 y 24 horas para solucionar el problema. Sin embargo, en algunos casos pueden necesitar más tiempo, dependiendo de la zona horaria en la que se encuentren, etc. Si los desarrolladores no responden, el complemento debe retirarse del repositorio.

Determinar la gravedad y el tipo del problema de seguridad.

Esto podría estar abierto a debate. Sin embargo, alguien con un poco de experiencia en seguridad puede saber fácilmente si un problema de seguridad informado se puede explotar automáticamente, si es un caso extremo o no, y cuál es su impacto a partir de la prueba de concepto (POC) informada.

Verifique que los desarrolladores se ciñan al plan de acción

Debería haber una especie de verificación para confirmar que los desarrolladores envíen la corrección a tiempo y se apeguen a cualquier otra tarea incluida en el plan de acción.

Retirar complementos mantenidos del repositorio no ayuda

En el caso de complementos mantenidos, retirarlos del repositorio hace más daño que bien. Por ejemplo;

  1. Hace público que el complemento tiene un problema, muy probablemente un problema de seguridad. Esto genera muchas alarmas y pone de relieve el complemento. Esto también es como invitar a los atacantes, diciéndoles que algo en el complemento es posiblemente explotable.
  2. Expone la base actual de usuarios de complementos porque, de repente, sus sitios web se convirtieron en un objetivo. La mayoría de los usuarios no tienen idea de lo que deben hacer, especialmente si la funcionalidad del complemento es fundamental para su sitio web y su negocio.
  3. Aumenta las posibilidades de retrasar la solución. Esto suele deberse a la falta de comunicación o a las vacaciones y los fines de semana.

Se podría argumentar que al retirar un complemento del repositorio, se detiene la propagación de la infección . Sin embargo, si el problema de seguridad es de baja gravedad, la explotación no se puede automatizar y la divulgación es responsable, no hay riesgos involucrados o los riesgos son extremadamente bajos.

Descargo de responsabilidad: esto no es un ataque

Me gustaría señalar que esto no es un ataque contra el equipo de revisión de complementos de WordPress ni contra nadie involucrado en estos procesos. Sinceramente, respeto su trabajo y sé que lo que hacen es de buena fe. Sin embargo, ciertamente hay un lugar para mejorar, como en cualquier otro sistema y proceso.

Muchos probablemente me dirán que si quiero un cambio debería ser voluntario en lugar de escribir esta publicación.

He estado tratando de unirme durante bastante tiempo; He hablado con varias personas en diferentes WordCamps para que se involucren, y también he estado monitoreando la página de complementos de Make WordPress en busca de voluntarios. Sin embargo, en los últimos años no han tenido vacantes. Cuando necesitaban ayuda, agregaban nuevos miembros solo por invitación.