En este blog tratamos mucho los temas que afectan a la seguridad de WordPress. Aquí se ha hablado varias veces de los grandes problemas de seguridad a los que se enfrenta la plataforma, el CMS más utilizado para la publicación de páginas web hoy en día. Hemos llegado hasta el punto de crear un WordPress en Modo Paranoico, incluso implementado en Docker para ponerlo aún más fácil y 0xWord ha publicado un libro dedicado íntegramente a la seguridad de WordPress que se ha convertido en una auténtica referencia, llamado “Máxima Seguridad en WordPress”.
Nos preocupamos porque localizar y solucionar vulnerabilidades de seguridad en esta plataforma no es una tarea sencilla, que requiere una actualización constante. No sólo hay que analizar el código fuente de la aplicación principal, también se suman (y posiblemente este sea el principal problema hoy día) las vulnerabilidades que puedan aparecer en los miles de plugins que existen para WordPress.
Exactamente de eso habla este artículo de Chema Alonso donde también se da a conocer un paper llamado “Detección y estimación de vulnerabilidades en plugins de WordPress”, dedicado exactamente a esta función, donde además se muestran varios CVE generados a partir de vulnerabilidades que se descubrieron a raíz del mismo.
Incluso desde el punto de vista profesional, ElevenPaths ofrece una solución orientada a empresas para proteger la infraestructura WordPress. Esta aplicación se llama FAAST para WordPress y permite de una manera sencilla, realizar todas estas tareas de detección de posibles problemas relacionados con la seguridad de la plataforma. Como queda claro en este artículo, nos preocupamos mucho por WordPress. Y no es de extrañar, ya que seguimos viendo noticias que afectan a su seguridad, como esta reciente vamos a comentar en profundidad.
Stored XSS en WordPress
Hace unos días, se solucionó un problema de seguridad en WordPress el cual permitía ejecución remota de código (RCE). En concreto, la vulnerabilidad era del tipo XSS o Cross-Site Scripting. Para ser más exactos del tipo “stored XSS” o también llamada “persistente”, que luego veremos en detalle. Este tipo de ataques a tecnologías web se basa en sacar el máximo de los Client-Side Attacks, que tanto daño hacen a las plataformas de Internet.
Este fallo de seguridad, con CVE-2019-16219 afectaba a la versión 5.0 o posterior. En concreto, el código que provocaba dicha vulnerabilidad se encontraba localizado en el editor incorporado en WordPress llamado Gutenberg. Al parecer, existía un problema relacionado con los “Shortcodes”, que veremos a continuación. Ejemplo de Shortcode para incrustar un documento de SlideShare:
El problema aparece cuando se añaden ciertos caracteres como por ejemplo “<” (sin las comillas) cuando se está subiendo un bloque. Esto provoca un error (y muestra una pre-visualización) ya que Wordpress traduce “<” como “<” y aunque Gutenberg tiene un detector de ataques XSS, este puede se puede engañar fácilmente añadiendo el siguiente código:
El término “stored XSS” significa, simplificando mucho el término, que el código inyectado se almacena en el mismo código fuente de la aplicación principal, aunque el objetivo final son los usuarios que visitan la página y no la aplicación (aunque se podría atacar el servidor web como veremos a continuación).
OWASP trata este tipo de ataques como uno de los más peligrosos del tipo XSS. Pero este puede ser aún incluso más devastador. Si el atacante consigue una cuenta tipo "administrador", es posible incluso poner en riesgo el servidor web donde se aloja la aplicación. Este sería más o menos el procedimiento (en este enlace de Fortinet se describe en profundidad):
Wordpress es el CMS más popular, llegando al 60% de utilización (Joomla! es el segundo con sólo un 5,2%). Por lo tanto, su securización y control de vulnerabilidades es algo no debemos dejar de lado. Tener una solución para analizar tanto el código principal como los plugins es una tarea que se convierte en crítica para mantener seguro tu servicio WordPress. En esta charla, Chema Alonso cuenta algunos procedimientos que implementamos nosotros para Fortificar WordPress like a Hacker!
Figura 8: Faast For WordPress de ElevenPaths
Mantener la seguridad de nuestro sitio WordPress es una prioridad absoluta, pero como hemos podido observar, no podemos centrarnos sólo en la seguridad del CMS exclusivamente. Los plugins se están convirtiendo en el mayor problema relacionado con la seguridad de WordPress. De nada sirve tener nuestra web al día si no realizamos un seguimiento e incluso auditorías, de los plugins instalados.
Figura 9: Faast For WordPress de ElevenPaths
Si necesitas una solución profesional para auditar y mantener segura tu página WordPress, recuerda que ElevenPaths ofrece la solución Faast For WordPress, un servicio de pentesting persistente para sitios con dominio WordPress.
Happy Hacking Hackers!
Más Referencias:
[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[Paper] Detección y estimación de vulnerabilidades en WordPress
[Vídeo] Proteger WordPress con Latch
[Vídeo] Proteger WordPress con Latch Cloud TOTP
[Vídeo] MyWordPress in Paranoid Mode (conferencia Chema Alonso)
[Vídeo] MyWordPress in Paranoid Mode (ElevenPaths Talks de Pablo González)
[Vídeo] Ejemplo de uso de Latch en WordPress
[Vídeo] Hardening WordPress like a hacker
[Vídeo] WordPress Demo XSS en WP-UserAgent
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] Máxima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicación entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress aún más seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al corazón) de tu WordPress
[BlogPost] Cómo robarle las contraseñas a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] Cómo debería ser un WordPress un poco más seguro
[BlogPost] WPHardening: Automatizar fortificación de WordPress
[BlogPost] Protege los borradores de los artículos de tu WordPress
[BlogPost] Registro de cuentas en WordPress públicos
[BlogPost] Riesgos en la ejecución de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] MySQLDumper: Un script de backup que no debes publicar en tu WP
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
[BlogPost] Docker WordPress in Paranoid Mode
[BlogPost] Faast for WordPress
[BlogPost] Cómo buscar {y encontrar} 0days en plugins de WordPress
[BlogPost] WordPress Stored XSS: Nueva vulnerabilidad para tu CMS. Actualiza.
 |
| Figura 1: WordPress Stored XSS: Nueva vulnerabilidad para tu CMS. Actualiza. |
Nos preocupamos porque localizar y solucionar vulnerabilidades de seguridad en esta plataforma no es una tarea sencilla, que requiere una actualización constante. No sólo hay que analizar el código fuente de la aplicación principal, también se suman (y posiblemente este sea el principal problema hoy día) las vulnerabilidades que puedan aparecer en los miles de plugins que existen para WordPress.
 |
| Figura 2: Libro de "Máxima Seguridad en WordpPress" |
Exactamente de eso habla este artículo de Chema Alonso donde también se da a conocer un paper llamado “Detección y estimación de vulnerabilidades en plugins de WordPress”, dedicado exactamente a esta función, donde además se muestran varios CVE generados a partir de vulnerabilidades que se descubrieron a raíz del mismo.
Incluso desde el punto de vista profesional, ElevenPaths ofrece una solución orientada a empresas para proteger la infraestructura WordPress. Esta aplicación se llama FAAST para WordPress y permite de una manera sencilla, realizar todas estas tareas de detección de posibles problemas relacionados con la seguridad de la plataforma. Como queda claro en este artículo, nos preocupamos mucho por WordPress. Y no es de extrañar, ya que seguimos viendo noticias que afectan a su seguridad, como esta reciente vamos a comentar en profundidad.
Stored XSS en WordPress
Hace unos días, se solucionó un problema de seguridad en WordPress el cual permitía ejecución remota de código (RCE). En concreto, la vulnerabilidad era del tipo XSS o Cross-Site Scripting. Para ser más exactos del tipo “stored XSS” o también llamada “persistente”, que luego veremos en detalle. Este tipo de ataques a tecnologías web se basa en sacar el máximo de los Client-Side Attacks, que tanto daño hacen a las plataformas de Internet.
 |
| Figura 4: Libro de Hacking Web Technologies: Client-Side Attacks (XSS, CSSP, SSRF, XSPA, SSJS) |
Este fallo de seguridad, con CVE-2019-16219 afectaba a la versión 5.0 o posterior. En concreto, el código que provocaba dicha vulnerabilidad se encontraba localizado en el editor incorporado en WordPress llamado Gutenberg. Al parecer, existía un problema relacionado con los “Shortcodes”, que veremos a continuación. Ejemplo de Shortcode para incrustar un documento de SlideShare:
[slideshare id=8874930&doc=sotw2011-as-delivered-110816213106-phpapp01&w=650&h=500]Los “Shortcodes” son básicamente una serie de comandos (atajos) que pueden utilizar los usuarios para incrustar ficheros o crear objetos en una sola línea (vídeo, audio, imágenes, documentos, etc). Estos códigos se pueden incorporar a una página Wordpress simplemente utilizando el botón de “Añadir bloque” que está presente en el editor Gutenberg.
 |
| Figura 5: Información de Shortcodes en WordPress |
El problema aparece cuando se añaden ciertos caracteres como por ejemplo “<” (sin las comillas) cuando se está subiendo un bloque. Esto provoca un error (y muestra una pre-visualización) ya que Wordpress traduce “<” como “<” y aunque Gutenberg tiene un detector de ataques XSS, este puede se puede engañar fácilmente añadiendo el siguiente código:
"><img src=1 onerror=prompt(1)>A partir de este momento, cuando cualquier usuario visite la página web con esta publicación, el código XSS se ejecutará en su navegador. Es decir, cualquier usuario con simplemente con accesos de nivel “Contributor” o superior, permitiría ejecutar este ataque e inyectar código JavaScript/HTML en el navegador de la víctima. El rol de “Contributor” es importante, ya que es el nivel mínimo para que este ataque se pudiera materializar.
El término “stored XSS” significa, simplificando mucho el término, que el código inyectado se almacena en el mismo código fuente de la aplicación principal, aunque el objetivo final son los usuarios que visitan la página y no la aplicación (aunque se podría atacar el servidor web como veremos a continuación).
 |
| Figura 6: Código insertado en el bloque de los Shortcodes. |
OWASP trata este tipo de ataques como uno de los más peligrosos del tipo XSS. Pero este puede ser aún incluso más devastador. Si el atacante consigue una cuenta tipo "administrador", es posible incluso poner en riesgo el servidor web donde se aloja la aplicación. Este sería más o menos el procedimiento (en este enlace de Fortinet se describe en profundidad):
1. El atacante envía una petición GET a la siguiente URL:
/wordpress/wp-admin/user-new.php
2. Se obtiene el valor actual “nonce” (un token de seguridad en forma de hash de una duración limitada).
3. Utilizando este valor nonce, se podría programar una query POST para crear un usuario y una contraseña (ambas aleatorias) del tipo administrador.
4. De esta forma, el atacante podría modificar el fichero existente php a una webshell, lo que permitiría ejecutar acciones sobre el servidor y de esa forma tomar control sobre el mismo.Este no ha sido el único problema solucionado relacionado con XSS y WordPress. También aparecieron otros de un funcionamiento similar asociados a la sección de comentarios, subida multimedia o incluso el dashboard.
 |
| Figura 7: Código XSS para añadir una cuenta administrador. |
Wordpress es el CMS más popular, llegando al 60% de utilización (Joomla! es el segundo con sólo un 5,2%). Por lo tanto, su securización y control de vulnerabilidades es algo no debemos dejar de lado. Tener una solución para analizar tanto el código principal como los plugins es una tarea que se convierte en crítica para mantener seguro tu servicio WordPress. En esta charla, Chema Alonso cuenta algunos procedimientos que implementamos nosotros para Fortificar WordPress like a Hacker!
Figura 8: Faast For WordPress de ElevenPaths
Mantener la seguridad de nuestro sitio WordPress es una prioridad absoluta, pero como hemos podido observar, no podemos centrarnos sólo en la seguridad del CMS exclusivamente. Los plugins se están convirtiendo en el mayor problema relacionado con la seguridad de WordPress. De nada sirve tener nuestra web al día si no realizamos un seguimiento e incluso auditorías, de los plugins instalados.
Figura 9: Faast For WordPress de ElevenPaths
Si necesitas una solución profesional para auditar y mantener segura tu página WordPress, recuerda que ElevenPaths ofrece la solución Faast For WordPress, un servicio de pentesting persistente para sitios con dominio WordPress.
Happy Hacking Hackers!
Más Referencias:
[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[Paper] Detección y estimación de vulnerabilidades en WordPress
[Vídeo] Proteger WordPress con Latch
[Vídeo] Proteger WordPress con Latch Cloud TOTP
[Vídeo] MyWordPress in Paranoid Mode (conferencia Chema Alonso)
[Vídeo] MyWordPress in Paranoid Mode (ElevenPaths Talks de Pablo González)
[Vídeo] Ejemplo de uso de Latch en WordPress
[Vídeo] Hardening WordPress like a hacker
[Vídeo] WordPress Demo XSS en WP-UserAgent
[BlogPost] My WordPress in Paranoid Mode
[BlogPost] Máxima Seguridad en WordPress
[BlogPost] Hackear un WordPress con Network Packet Manipulation
[BlogPost] Fortificar comunicación entre WordPress y MySQL
[BlogPost] WordPress Latch Enforcement
[BlogPost] WordPress aún más seguro con Latch Lock After Request
[BlogPost] Fortificar WordPress frente a ataques de fuerza bruta
[BlogPost] Ataques (al corazón) de tu WordPress
[BlogPost] Cómo robarle las contraseñas a los administradores de WordPress
[BlogPost] Agrupar el control de varios WordPress con un solo Latch
[BlogPost] WordPress: Time-Based XSPA (Cross-Site Port Attack)
[BlogPost] Cómo debería ser un WordPress un poco más seguro
[BlogPost] WPHardening: Automatizar fortificación de WordPress
[BlogPost] Protege los borradores de los artículos de tu WordPress
[BlogPost] Registro de cuentas en WordPress públicos
[BlogPost] Riesgos en la ejecución de tareas de Cron
[BlogPost] WordPres: XSS en plugin WP-UserAgent
[BlogPost] MySQLDumper: Un script de backup que no debes publicar en tu WP
[BlogPost] Listar los plugins de WordPress en un pentest
[BlogPost] WordPress: SQL Injection en Scarcity Builder Plugin
[BlogPost] Docker WordPress in Paranoid Mode
[BlogPost] Faast for WordPress
[BlogPost] Cómo buscar {y encontrar} 0days en plugins de WordPress
[BlogPost] WordPress Stored XSS: Nueva vulnerabilidad para tu CMS. Actualiza.
Autor: Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades.
No hay comentarios:
Publicar un comentario