XSS2Shell: una cadena previa a la autenticación puede convertir WordPress en una puerta de entrada al servidor

De la página de inicio de sesión al DOM clobbering

Los investigadores de Pwn han descrito recientemente XSS2Shell, una cadena de ataque crítica que comienza en la página de acceso de WordPress y no requiere autenticación inicial.

El ataque utiliza un nombre de usuario inexistente, que se refleja en el mensaje de error. El primer filtro aplicado por PHP mediante strip_tags() no reconoce como etiquetas válidas los elementos escritos con un espacio entre el carácter < y el nombre:

< area id=ajaxurl>

Posteriormente, wp_kses_post() interpreta la cadena como un elemento HTML válido y la convierte en contenido activo dentro del DOM.

El atributo id="ajaxurl" permite entonces un DOM clobbering: el navegador expone el elemento como la propiedad window.ajaxurl, alterando el comportamiento previsto de los scripts de la página.

Abuso de user-profile.js y de la REST API

La página de inicio de sesión también carga user-profile.js, utilizado para gestionar los restablecimientos de contraseña. El script puede detectar y activar automáticamente un botón de restablecimiento manipulado, sin que el administrador tenga que hacer clic explícitamente.

A continuación, la cadena aprovecha una respuesta JSONP de la REST API. El parámetro callback acepta puntos, lo que permite recorrer cadenas de propiedades entre ventanas del navegador. Los investigadores reutilizaron una técnica publicada por primera vez en 2022 para lograr un clic entre ventanas dentro de la sesión activa de un administrador autenticado.

El navegador es redirigido a una pantalla de WordPress para aprobar las Application Passwords. Las cookies y el nonce de la sesión administrativa permiten activar automáticamente el botón de aprobación.

El resultado es una Application Password válida para la cuenta de administrador.

De la credencial a la posible ejecución de código

WordPress acepta la Application Password mediante autenticación HTTP Basic en la REST API. La configuración CORS refleja el origen de la solicitud y permite las cabeceras Authorization y Content-Type, haciendo posibles las llamadas autenticadas a la API desde otros orígenes.

En instalaciones de un solo sitio, los administradores suelen disponer de la capability unfiltered_html. Por tanto, es posible conservar JavaScript arbitrario en el contenido publicado.

El atacante puede publicar una página con código JavaScript, utilizarla para cargar un plugin y lograr la ejecución de código PHP arbitrario. En la prueba de concepto, una respuesta JSON confirmó la ejecución con la identidad del usuario del servidor web.

El impacto potencial incluye:

• compromiso de la sesión administrativa;
• emisión fraudulenta de Application Passwords;
• publicación de contenido JavaScript;
• instalación de plugins maliciosos;
• Remote Code Execution;
• posible toma de control total del servidor.

La prueba de concepto no dejó persistencia: los investigadores revocaron la credencial, eliminaron la página y borraron el directorio del plugin.

Qué deben comprobar los administradores

No se han indicado identificadores CVE ni números de versión vulnerables o corregidos para WordPress, PHP, los navegadores o los componentes implicados.

Los administradores deberían:

1. actualizar WordPress a las versiones corregidas publicadas por el proveedor;
2. aplicar las actualizaciones de seguridad de WordPress, PHP y los componentes instalados;
3. revocar las Application Passwords sospechosas o innecesarias;
4. revisar las páginas publicadas, los plugins, los directorios de plugins y los registros de la REST API;
5. buscar solicitudes anómalas a los endpoints de aprobación de Application Passwords;
6. supervisar el tráfico JSONP y las llamadas cross-origin con la cabecera Authorization;
7. reducir los privilegios administrativos y limitar, cuando sea posible, el uso de unfiltered_html.

No se conocen las versiones afectadas. Por tanto, la ausencia de actividad anómala observable no basta para descartar una posible intrusión.