WordPress es el CMS Open Source que conquistó Internet, de hecho gobierna nada más y nada menos que un cuarto de este. Esto hace que cualquier vulnerabilidad grave hallada en él termine siendo de gran relevancia, ya que muchos sitios web importantes confían en esta solución para desplegar sus contenidos.

Recientemente se ha descubierto una vulnerabilidad grave en WordPress que podría permitir a un atacante remoto reiniciar las contraseñas de los usuarios registrados en el backoffice del CMS en ciertas circunstancias. La vulnerabilidad, cuyo código es CVE-2017-8295, resulta incluso más peligrosa después de saberse que afecta a todas las versiones de WordPress, incluido la 4.7.4, que es la más reciente.

El fallo de seguridad fue descubierto por el investigador polaco de Legal Hackers Dawid Golunski, quien lo reportó a la misma comunidad de WordPress el pasado mes de julio sin recibir respuesta alguna, lo que ha dejado desde entonces expuestos a millones de sitios web de todo el mundo. Después de diez meses sin recibir una respuesta acorde a lo que buscaba, el investigador tomó la decisión de hacerlo público sin que todavía haya disponible un parche que lo neutralice.

La vulnerabilidad reside en la forma en que WordPress procesa la solicitud de restablecimiento de la contraseña. Por lo general, cuando un usuario solicita el reinicio de su contraseña a través de la opción de que se le ha olvidado, el CMS genera de forma inmediata un código secreto único que es enviado al email de identificación del usuario almacenado en la base de datos.

Mientras se está enviando el email con el código único para el restablecimiento de la contraseña, WordPress utiliza una variable llamada SERVER_NAME para obtener el nombre del host de un servidor y establecer los valores correspondientes a los campos From/Return-Path (Desde/Ruta de retorno).

From hace referencia a la dirección de email de un remitente y Return-Path se refiere a la dirección a la cual devolver los emails en caso de que haya un fallo en el proceso de envío. Según Golunski, un atacante podría enviar peticiones HTTP falsificadas con un valor que correspondería a un nombre de host personalizado y predefinido (por ejemplo, attacker-mxserver.com) mientras se inicia el proceso de restablecimiento de contraseña por parte de un administrador del sitio web WordPress.

A partir de que el nombre del host de la petición HTTP maliciosa es un dominio controlado por el atacante, los campos From y Return-Path en el restablecimiento de la contraseña serán modificados para incluir un identificador (ID) de email asociado con el dominio del atacante. Por ejemplo, si la dirección de email de identificación es [email protected], esta quedaría sustituida por [email protected].

Sin embargo, hay que tener en cuenta una cosa, y es que el email de recuperación sigue llegando solo a la víctima, pero con los campos From y Return-Path apuntando al identificador de email del atacante, este último podría recibir el código de restablecimiento en los siguientes escenarios:

1. En caso de que la víctima responda al email, lo enviado llegaría a la dirección identificadora del atacante (mencionado con el campo From), estando presente el enlace de restablecimiento en el historial del mensaje.
2. Si el servidor web de la víctima es tumbado, el email de restablecimiento de contraseña será devuelto automáticamente a la dirección de email mencionada en el campo Return-Path, que apunta al buzón del atacante.
3. Otro posible escenario sería forzar el correo de devolución. Si el atacante realiza un ataque DDoS contra el servidor de email de la víctima o envía una gran cantidad de emails (spam masivo), la cuenta de la víctima ya no podría servir recibiendo emails.

Como se puede comprobar, el ataque a realizar para obtener la cuenta de un usuario de WordPress mediante la manipulación del nombre del servidor no es nada sencillo. Sin embargo, esto no quiere decir que no esté al alcance de los hackers más habilidosos.

Otro punto a tener en cuenta es que no todos los servidores web permiten la modificación de un host a través de la cabecera SERVER_NAME, incluso si el WordPress alojado en él contiene la vulnerabilidad, lo que cierra la puerta al ataque.

Tras la publicación de este fallo de seguridad por parte de Golunski, la comunidad de WordPress ha recomendado cambiar la configuración de los servidores web, habilitando UseCanonicalName para forzar un valor SERVER_NAME estático y predefinido.

Fuente | The Hacker News