¿Es Cross-Site Scripting una amenaza real para WordPress? Las vulnerabilidades son un hecho de la vida para cualquiera que administre un sitio web, incluso cuando se utiliza un sistema de administración de contenido bien establecido como WordPress.
No todas las vulnerabilidades son iguales, ya que algunas permiten el acceso a datos confidenciales que normalmente estarían ocultos a la vista del público, mientras que otras podrían permitir que un ciberdelicuente tome el control total de un sitio web afectado.
Hay muchos tipos de vulnerabilidades, incluido el control de acceso, la configuración incorrecta, los fallos de integridad de los datos y la inyección, entre otros. Un tipo de vulnerabilidad de inyección que a menudo se subestima, pero que puede proporcionar una amplia gama de amenazas a un sitio web, es Cross-Site Scripting, también conocido como «XSS«.
En un solo período de 30 días, Wordfence bloqueó un total de 31.153.743 intentos de exploit xSS, lo que lo convierte en uno de los tipos de ataque más comunes que vemos.
Titulares
¿Qué es Cross-Site Scripting?
Cross-Site Scripting es un tipo de vulnerabilidad que permite a un ciberdelincuente inyectar código, generalmente JavaScript, en sitios web legítimos.
El navegador web utilizado por el usuario del sitio web no tiene forma de determinar que el código no es una parte legítima del sitio web, por lo que muestra contenido o realiza acciones dirigidas por el código malicioso.
XSS es un tipo de vulnerabilidad relativamente conocida, en parte porque algunos de sus usos son visibles en un sitio web afectado, pero también hay usos «invisibles» que pueden ser mucho más perjudiciales para los propietarios de sitios web y sus visitantes.
Sin dividir XSS en sus diversos usos, hay tres categorías principales de XSS que tienen diferentes aspectos que podrían ser valiosos para un actor malicioso. Los tipos de XSS se dividen en XSS almacenado, reflejado y basado en DOM. XSS almacenado también incluye un subtipo conocido como XSS ciego.
El scripting entre sitios almacenado podría considerarse el tipo más nefasto de XSS. Estas vulnerabilidades permiten almacenar exploits en el servidor afectado. Esto podría ser en un comentario, revisión, foro u otro elemento que mantenga el contenido almacenado en una base de datos o archivo, ya sea a largo plazo o de forma permanente.
Cada vez que una víctima visita una ubicación, se representa el script, el exploit almacenado se ejecutará en su navegador.
Un ejemplo de una vulnerabilidad XSS almacenada autenticada se puede encontrar en la versión 4.16.5 o anterior del complemento Leaky Paywall. Esta vulnerabilidad permitió introducir código en los campos separador de mil y separador decimal y guardarlo en la base de datos.
Cada vez que se cargaba esta pestaña, el código guardado se cargaba. Para este ejemplo, usamos la función JavaScript para ejecutar el código inyectado cada vez que el mouse pasaba por encima del cuadro de texto, pero esto podría modificarse fácilmente para ejecutar el código tan pronto como se cargue la página, o incluso así se ejecutaría cuando un usuario hace clic en un elemento de página especificado.
La vulnerabilidad existía debido a la falta de validación y desinfección de entrada adecuada en el archivo del complemento. Si bien hemos elegido un ejemplo menos grave que requiere permisos de administrador para explotar, muchas otras vulnerabilidades de este tipo pueden ser explotadas por atacantes no autenticados.
Blind Cross-Site Scripting es un subtipo de XSS almacenado que no se representa en una ubicación pública. Como todavía se almacena en el servidor, esta categoría no se considera un tipo separado de XSS en sí.
En un ataque que utiliza XSS ciego, el actor malintencionado deberá enviar su exploit a una ubicación a la que accedería un usuario back-end, como un administrador del sitio.
Un ejemplo sería un formulario de comentarios que envía comentarios al administrador con respecto a las características del sitio. Cuando el administrador inicia sesión en el panel de administración del sitio web y accede a los comentarios, el exploit se ejecutará en el navegador del administrador.
Este tipo de exploit es relativamente común en WordPress, con ciberdelincuentes que aprovechan aspectos del sitio que proporcionan datos en el panel de administrador.
Una de estas vulnerabilidades fue explotable en la versión 13.1.5 o anterior del complemento WP Statistics, que está diseñado para proporcionar información sobre los visitantes del sitio web.
Si la opción Compatibilidad de caché estaba habilitada, un usuario no autenticado podría visitar cualquier página del sitio y obtener el código fuente, y usar ese nonce en una URL especialmente diseñada para inyectar JavaScript u otro código que se ejecutaría cuando un administrador acceda a las páginas de estadísticas.
El scripting entre sitios reflejado es una forma más interactiva de XSS. Este tipo de XSS se ejecuta de inmediato y requiere engañar a la víctima para que envíe la carga útil maliciosa por sí misma, a menudo haciendo clic en un enlace diseñado o visitando un formulario controlado por el atacante.
Los exploits para las vulnerabilidades XSS reflejadas a menudo usan argumentos agregados a una URL, resultados de búsqueda y mensajes de error para devolver datos en el navegador o enviar datos a un actor malintencionado.
Esencialmente, el actor de amenazas crea una URL o una entrada de campo de formulario para inyectar su código malicioso, y el sitio web incorporará ese código en el proceso de envío para la función vulnerable. Los ataques que utilizan XSS reflejado pueden requerir que un administrador u otro usuario del sitio abra un correo electrónico o mensaje que contenga un enlace especialmente diseñado para obtener el resultado deseado del exploit.
Este tipo de XSS generalmente implica cierto grado de ingeniería social para tener éxito y vale la pena señalar que la carga útil nunca se almacena en el servidor, por lo que la posibilidad de éxito depende de la interacción inicial con el usuario.
En enero de 2022, el equipo de Wordfence descubrió una vulnerabilidad XSS reflejada en el complemento Profile Builder – User Profile & User Registration Forms.
La vulnerabilidad permitió una simple modificación de la página, simplemente creando específicamente una URL para el sitio.
Aquí generamos una alerta utilizando el parámetro y actualizamos el texto de la página para que diga «404 Página no encontrada», ya que este es un mensaje de error común que probablemente no causará alarma, pero podría atraer a una víctima a hacer clic en el enlace de redirección que activará la ventana emergente.
DOM-Based Cross-Site Scripting es similar a XSS reflejado, con la diferencia definitoria de que las modificaciones se realizan completamente en el entorno DOM.
Esencialmente, un ataque que utiliza XSS basado en DOM no requiere que se realice ninguna acción en el servidor, solo en el navegador de la víctima.
Si bien la respuesta HTTP del servidor permanece sin cambios, una vulnerabilidad XSS basada en DOM aún puede permitir que un actor malicioso redirija a un visitante a un sitio bajo su control, o incluso recopile datos confidenciales.
Un ejemplo de una vulnerabilidad basada en DOM se puede encontrar en versiones anteriores a 3.4.4 del complemento Elementor page builder. Esta vulnerabilidad permitió a los usuarios no autenticados poder inyectar código JavaScript en páginas que habían sido editadas utilizando las versiones gratuita o Pro de Elementor.
La vulnerabilidad estaba en la configuración de lightbox, con la carga útil formateada como JSON y codificada en base64.
¿Cómo afecta el cross-site Scripting a los sitios de WordPress?
Los sitios web de WordPress pueden tener una serie de repercusiones de las vulnerabilidades de Cross-Site Scripting (XSS).
Debido a que los sitios web de WordPress se generan dinámicamente en la carga de la página, el contenido se actualiza y almacena dentro de una base de datos.
Esto puede facilitar que un actor malicioso explote una vulnerabilidad XSS almacenada o ciega en el sitio web, lo que significa que un atacante a menudo no necesita confiar en la ingeniería social de una víctima para que su carga útil XSS se ejecute.
Uso de secuencias de comandos entre sitios para manipular sitios web
Una de las formas más conocidas en que XSS afecta a los sitios web de WordPress es manipulando el contenido de la página. Esto se puede utilizar para generar ventanas emergentes, inyectar spam o incluso redirigir a un visitante a otro sitio web por completo.
Este uso de XSS proporciona a los actores maliciosos la capacidad de hacer que los visitantes pierdan la fe en un sitio web, ver anuncios u otro contenido que de otro modo no se vería en el sitio web, o incluso convencer a un visitante de que está interactuando con el sitio web previsto a pesar de ser redirigido a un dominio similar o sitio web similar que está bajo el control del actor malicioso.
Al probar las vulnerabilidades XSS, los investigadores de seguridad a menudo utilizan un método simple, como o para probar si el navegador ejecutará el método y mostrará la información contenida en la carga útil. Por lo general, esto se parece a lo siguiente y, por lo general, causa poco o ningún daño al sitio web afectado.
Este método también se puede utilizar para incitar a un visitante a proporcionar información confidencial, o interactuar con la página de maneras que normalmente no serían intencionadas y podrían provocar daños al sitio web o información robada.
Un tipo común de carga útil XSS que vemos cuando nuestro equipo realiza limpiezas del sitio es una redirección. Como se mencionó anteriormente, las vulnerabilidades XSS pueden utilizar JavaScript para que el navegador realice acciones.
En este caso, un atacante puede utilizar el método u otro método similar para redirigir a la víctima a otro sitio. Esto puede ser utilizado por un atacante para redirigir a un visitante del sitio a un dominio malicioso separado que podría usarse para infectar aún más a la víctima o robar información confidencial.
En este ejemplo, solíamos redirigir el sitio a wordfence.com. El uso de significa que el script se ejecuta tan pronto como se carga el elemento de la página a la que se adjunta el script.
Generar una URL especialmente diseñada de esta manera es un método común utilizado por los actores de amenazas para que los usuarios y administradores aterricen en las páginas bajo el control del actor. Para ocultar aún más el ataque a una víctima potencial, el uso de la codificación de URL puede modificar la apariencia de la URL para que sea más difícil detectar el código malicioso.
Esto incluso se puede llevar un paso más allá en algunos casos modificando ligeramente el JavaScript y utilizando la codificación de caracteres antes de la codificación de URL. La codificación de caracteres ayuda a eludir ciertas restricciones de caracteres que pueden impedir que un ataque tenga éxito sin codificar primero la carga útil.
Cuando se habla de la manipulación de sitios web, es difícil ignorar las desfiguraciones del sitio. Esta es la forma más obvia de ataque en un sitio web, ya que a menudo se usa para reemplazar el contenido previsto del sitio web con un mensaje del mal actor.
Esto a menudo se logra mediante el uso de JavaScript para forzar que el contenido previsto del mal actor se cargue en lugar del contenido original del sitio. Utilizando funciones de JavaScript como o es posible reemplazar elementos de la página, o incluso toda la página, con contenido nuevo.
Las desfiguraciones requieren una vulnerabilidad XSS almacenada, ya que el actor malintencionado querría asegurarse de que todos los visitantes del sitio vean la desfiguración.
Esta no es, por supuesto, la única forma de desfigurar un sitio web. Una desfiguración podría ser tan simple como modificar elementos de la página, como cambiar el color de fondo o agregar texto a la página. Estos se logran de la misma manera, mediante el uso de JavaScript para reemplazar los elementos de la página.
Robo de datos con secuencias de comandos entre sitios
XSS es una de las vulnerabilidades más fáciles que un actor malicioso puede explotar para robar datos de un sitio web.
Las URL especialmente diseñadas se pueden enviar a los administradores u otros usuarios del sitio para agregar elementos a la página que envían datos de formulario al actor malicioso, así como, o en lugar de, la ubicación prevista de los datos que se envían en el sitio web en condiciones normales.
Las cookies generadas por un sitio web pueden contener datos confidenciales o incluso permitir que un atacante acceda directamente a la cuenta de un usuario autenticado. Uno de los métodos más simples para ver las cookies activas en un sitio web es utilizar la función JavaScript para enumerar todas las cookies.
En este ejemplo, enviamos las cookies a un cuadro de alerta, pero pueden enviarse fácilmente a un servidor bajo el control del atacante, sin siquiera ser perceptibles para el visitante del sitio.
Si bien el robo de datos de formularios es menos común, puede tener un impacto significativo en los propietarios y visitantes del sitio. La forma más común en que esto sería utilizado por un actor malicioso es robar información de tarjetas de crédito.
Es posible simplemente enviar la entrada de un formulario directamente a un servidor bajo el control del mal actor, sin embargo, es mucho más común usar un keylogger.
Muchas soluciones de procesamiento de pagos incrustan formularios de sus propios sitios, a los que normalmente No se puede acceder directamente mediante JavaScript que se ejecuta en el contexto de un sitio infectado.
El uso de un keylogger ayuda a garantizar que se reciban datos utilizables, lo que no siempre puede ser el caso cuando simplemente se recopilan datos del formulario a medida que se envían a la ubicación prevista.
Aquí utilizamos la codificación de caracteres para ofuscar el recopilador de pulsaciones de teclas de JavaScript, así como para facilitar la ejecución directamente desde un enlace creado maliciosamente.
Esto luego envía las pulsaciones de teclas recopiladas a un servidor bajo el control del actor de amenazas, donde se utiliza un script PHP para escribir las pulsaciones de teclas recopiladas en un archivo de registro.
Esta técnica podría usarse como lo hicimos aquí para apuntar a víctimas específicas, o se podría aprovechar una vulnerabilidad XSS almacenada para recopilar pulsaciones de teclas de cualquier visitante del sitio que visite una página que cargue el código JavaScript malicioso. En cualquier caso de uso, debe existir una vulnerabilidad XSS en el sitio web de destino.
Si esta forma de robo de datos se utiliza en una página de inicio de sesión vulnerable, un actor de amenazas podría obtener fácilmente acceso a nombres de usuario y contraseñas que podrían usarse en ataques posteriores. Estos ataques podrían ser contra el mismo sitio web, o utilizados en ataques de relleno de credenciales contra una variedad de sitios web, como servicios de correo electrónico e instituciones financieras.
Aprovechar los scripts entre sitios para hacerse cargo de las cuentas
Quizás uno de los tipos de ataques más peligrosos que son posibles a través de las vulnerabilidades XSS es una toma de control de la cuenta. Esto se puede lograr a través de una variedad de métodos, incluido el uso de cookies robadas, similar al ejemplo anterior.
Además de simplemente usar cookies para acceder a una cuenta de administrador, los actores maliciosos a menudo crean cuentas de administrador falsas bajo su control, e incluso pueden inyectar puertas traseras en el sitio web. Las puertas traseras le dan al actor malicioso la capacidad de realizar más acciones en un momento posterior.
Si existe una vulnerabilidad XSS en un sitio, inyectar un usuario administrador malintencionado puede ser un trabajo ligero para un actor de amenazas si puede hacer que un administrador de un sitio web vulnerable haga clic en un enlace que incluye una carga útil codificada, o si se puede explotar otra vulnerabilidad XSS almacenada.
En este ejemplo, inyectamos al usuario administrador extrayendo el código malicioso de una ubicación accesible en la web, utilizando un acortador de URL común para ocultar aún más la verdadera ubicación de la ubicación maliciosa.
Ese enlace se puede utilizar en una URL especialmente diseñada o inyectarse en una forma vulnerable con algo como cargar el script que inyecta a un usuario administrador malicioso cuando se carga la página.
Las puertas traseras son una forma para que un actor malicioso retenga el acceso a un sitio web o sistema más allá del ataque inicial.
Esto hace que las puertas traseras sean muy útiles para cualquier actor de amenazas que tenga la intención de continuar modificando su ataque, recopilar datos a lo largo del tiempo o recuperar el acceso si un administrador del sitio elimina un usuario administrador malicioso inyectado.
Si bien JavaScript que se ejecuta en la sesión de un administrador se puede usar para agregar puertas traseras PHP a un sitio web editando archivos de complementos o temas, también es posible «puerta trasera» del navegador de un visitante, lo que permite a un atacante ejecutar comandos arbitrarios como víctima en tiempo real.
En este ejemplo, utilizamos una puerta trasera de JavaScript a la que se podía conectar desde un shell de Python que se ejecutaba en un sistema bajo el control del actor de amenazas.
Esto permite que el actor de la amenaza ejecute comandos directamente en el navegador de la víctima, lo que permite al atacante tomar el control directamente de él y, potencialmente, abrir más ataques a la computadora de la víctima dependiendo de si el navegador en sí tiene alguna vulnerabilidad sin parchear.
A menudo, se utiliza una puerta trasera para retener el acceso a un sitio web o servidor, pero lo que es único en este ejemplo es el uso de una vulnerabilidad XSS en un sitio web para obtener acceso a la computadora que se utiliza para acceder al sitio web afectado.
Si un actor de amenazas puede hacer que la carga útil de JavaScript se cargue cada vez que un visitante accede a una página, como a través de una vulnerabilidad XSS almacenada, entonces cualquier visitante de esa página en el sitio web se convierte en una víctima potencial.
Las herramientas hacen un trabajo ligero de exploits
Hay herramientas disponibles que facilitan la explotación de vulnerabilidades como Cross-Site Scripting (XSS). Algunas herramientas son creadas por actores maliciosos para actores maliciosos, mientras que otras son creadas por profesionales de ciberseguridad con el propósito de probar vulnerabilidades para prevenir la posibilidad de un ataque.
No importa cuál sea el propósito de la herramienta, si funciona, los actores maliciosos la usarán. Una de estas herramientas es una herramienta de prueba de penetración disponible gratuitamente llamada BeEF.
Esta herramienta está diseñada para trabajar con un explorador para encontrar vulnerabilidades del lado del cliente en una aplicación web. Esta herramienta es ideal para los administradores, ya que les permite probar fácilmente sus propias aplicaciones web para XSS y otras vulnerabilidades del lado del cliente que puedan estar presentes.
La otra cara de esto es que también puede ser utilizado por actores de amenazas que buscan posibles objetivos de ataque.
Una cosa que es consistente en todos estos exploits es el uso de solicitudes para manipular el sitio web. Estas solicitudes se pueden registrar y utilizar para bloquear acciones maliciosas en función de los parámetros de solicitud y las cadenas contenidas en la solicitud.
La única excepción es que los XSS basados en DOM no se pueden registrar en el servidor web, ya que estos se procesan completamente dentro del navegador de la víctima.
Los parámetros de solicitud que los actores maliciosos suelen usar en sus solicitudes son a menudo campos comunes, como el parámetro de búsqueda de WordPress y, a menudo, son solo conjeturas con la esperanza de encontrar un parámetro común con una vulnerabilidad explotable.
El parámetro de solicitud más común que hemos visto actores de amenazas que intentan atacar recientemente es el que generalmente se usa para identificar el nombre de dominio del servidor desde el que se carga el sitio web.
Conclusión
Cross-Site Scripting (XSS) es un tipo de vulnerabilidad potente, pero a menudo subestimada, al menos cuando se trata de instancias de WordPress.
Si bien XSS ha sido una vulnerabilidad de larga data en el Top 10 de OWASP, muchas personas piensan en ella solo como la capacidad de inyectar contenido como una ventana emergente, y pocas se dan cuenta de que un actor malicioso podría usar este tipo de vulnerabilidad para inyectar spam en una página web o redirigir a un visitante al sitio web de su elección.
Convencer a un visitante del sitio para que proporcione su nombre de usuario y contraseña, o incluso hacerse cargo del sitio web con relativa facilidad, todo gracias a las capacidades de JavaScript y el conocimiento práctico de la plataforma backend.
Una de las mejores maneras de proteger su sitio web contra las vulnerabilidades de XSS es mantener WordPress y todos sus complementos actualizados.
A veces, los atacantes se dirigen a una vulnerabilidad de día cero y un parche no está disponible de inmediato, por lo que el firewall de Wordfence viene con protección XSS incorporada para proteger a todos los usuarios de Wordfence, incluidos Free, Premium, Care y Response, contra los exploits XSS.