Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Battle Royale: WordPress infectados atacando otros WordPress #Wordpress #hardening
Una de las noticias de la semana pasada fue el descubrimiento de una botnet de sistemas Wordpress que intentaban atacar a otros Wordpress no infectados. El número de instalaciones infectadas superaba los 20.000, aunque no se descarta un aumento en los días que han transcurrido. El ataque que los Wordpress infectados realizaban contra los otros sistemas Wordpress NO infectados no era un ataque complejo, pero al fin y al cabo, sí efectivo por lo que parece.
La empresa del Wordfence, propietaria de un plugin de Wordpress que implementa un sistema de firewall para la aplicación, fue la que descubrió el ataque y ha publicado un reporte muy profundo sobre el ataque, incluyendo desde dónde se enviaban las instrucciones mediante los C2 o Command and Control.
¿Cómo detectaron los ataques?
Según explican en su reporte detectaron, en el último mes, más de cinco millones de intentos de acceso. Estos intentos de acceso iban desde instalaciones de Wordpress infectadas, o supuestamente infectadas, contra otras instalaciones de Wordpress que no lo estarían.
¿Cómo se realiza el ataque?
El ataque es básico, es lo que se llama un ataque de diccionario. Es decir, los sitios infectados van probando ciertas credenciales. Si el ataque tiene acceso se consigue acceso al sistema, por lo que se podrá infectar y ser parte de la botnet. El investigador Mikey Veenstra comentó que la empresa de Wordfence identificó cuatro servidores C2 o Command and Control que son los encargados de enviar las instrucciones al resto de instalaciones infectadas.
Figura 3: Cómo proteger WordPress con Latch
Este es un ataque muy común, y por supuesto ya hablamos de cómo prevenir este tipo de ataques a través del uso de Latch.
¿Cómo envían las instrucciones de ataque a las instalaciones infectadas?
Los C&C envían las instrucciones a través de un conjunto de máquinas o red de más de 14.000 proxies. Estos proxies están alquilados al servicio Best Proxies, los cuales transmiten la información a scripts maliciosos ubicados en las instalaciones de Wordpress infectadas.
¿Cómo funcionan los scripts maliciosos?
Sencillo. Leen una lista de destinos que reciben desde los servidores C2, crean una lista de credenciales basándose en patrones de contraseñas y luego intentan utilizar dichas contraseñas para iniciar sesión como administrador. Como se puede ver el funcionamiento es sencillo, pero potente.
En otras palabras, si el script malicioso tiene que intentar iniciar sesión en peligro.com con el usuario admin, se genera una contraseña como peligro, admin, admin1, admin2018, etcétera. Por lo que el patrón identificado es una contraseña para la cuenta similar al nombre de usuario o que derive de él. Es un ataque de diccionario que genera credenciales dinámicas en función del contexto del dominio y del usuario. Nada nuevo.
Según parece en la investigación de Defiant, la empresa de Wordfence, comenta que la gente que está detrás de esta botnet cometió algunos errores en la implementación de los scripts maliciosos. De esta forma se ha podido conocer el detalle y exponer toda la infraestructura de backend de la botnet.
Incluso, parece que los investigadores pudieron evitar el sistema de acceso al panel del C2 y echar un vistazo a la operación. Parece que los errores no solo estaban en la implementación de los scripts, si no que también se implementó de forma incorrecta los sistemas de autenticación del panel de administración. Al menos con algunos bugs.
Aunque se ha compartido toda esta información en este reporte, los C2 han seguido activos debido a que el proveedor donde están alojados no satisface solicitudes de retirada. Hay que tener en cuenta que los intentos de inicio de sesión automatizados no van dirigidos al panel de inicio de sesión de Wordpress, y sí al mecanismo de autenticación XML-RPC de Wordpress. No intentemos cambiar la URL del panel de inicio de sesión, ya que eso no servirá. Es importante utilizar un plugin que bloquee los ataques de fuerza bruta o de diccionario que se pueden realizar contra el servicio XML-RPC.
¿Qué más podemos hacer?
Aparte de instalar un plugin que permita bloquear ataques de fuerza bruta, es importante disponer de un 2FA de autenticación. Se puede instalar el plugin oficial de Latch para Wordpress para no permitir autenticar, mientras no abramos el cerrojo Por otro lado, otra opción muy recomendado es proteger Wordpress con Latch Cloud TOTP para generar un token una vez se valide el usuario, y se introduzca como un 2FA.
Figura 7: Proteger WordPress con Latch Cloud TOTP
A modo de evitar la modificación o alteración de la base de datos se puede instalar nuestra herramienta Wordpress in Paranoid Mode. Esta herramienta permite ‘congelar’ la base de datos en caso de incidente de seguridad o darnos el poder de decidir qué tablas se pueden modificar y cuando. Con tres modos de funcionamiento: Administración, Edición y Read-Only permite al usuario utilizar una granularidad suficiente para controlar inserciones, actualizaciones y borrado de datos.
En la conferencia de la Figura 8 hay un montón más de trucos de hardening de WordPress que puedes aprender en los diferentes posts y artículos enlazados en la referencia, pero el libro de nuestro colega Daniel Maldonado en 0xWord dedicado a "Máxima Seguridad Wordpress" ayuda a entender las necesidades que tienen este tipo de aplicaciones para garantizar la seguridad de tus sitios.
Por supuesto, si quieres tener siempre auditado y controlado tu servicio WordPress, en ElevenPaths desarrollamos un servicio que puedes contratar cuando desees que se llama Faast For WordPress y que hace Pentesting Persistente a tu servidor desde Internet para que tengas un reporte continuo de las vulnerabilidades que te afectan en el momento en que se descubren.
Figura 10: Faast for WordPress demo
Os dejo un listado de las referencias que os pueden ayudar a mejorar la seguridad de vuestras instancias de Wordpress:
[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[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] MyWordPress in Paranoid Mode for Developers
[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] 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
 |
| Figura 1: Battle Royale: WordPress infectados atacando otros WordPress |
La empresa del Wordfence, propietaria de un plugin de Wordpress que implementa un sistema de firewall para la aplicación, fue la que descubrió el ataque y ha publicado un reporte muy profundo sobre el ataque, incluyendo desde dónde se enviaban las instrucciones mediante los C2 o Command and Control.
¿Cómo detectaron los ataques?
Según explican en su reporte detectaron, en el último mes, más de cinco millones de intentos de acceso. Estos intentos de acceso iban desde instalaciones de Wordpress infectadas, o supuestamente infectadas, contra otras instalaciones de Wordpress que no lo estarían.
 |
| Figura 2: Informe de Wordfence |
¿Cómo se realiza el ataque?
El ataque es básico, es lo que se llama un ataque de diccionario. Es decir, los sitios infectados van probando ciertas credenciales. Si el ataque tiene acceso se consigue acceso al sistema, por lo que se podrá infectar y ser parte de la botnet. El investigador Mikey Veenstra comentó que la empresa de Wordfence identificó cuatro servidores C2 o Command and Control que son los encargados de enviar las instrucciones al resto de instalaciones infectadas.
Figura 3: Cómo proteger WordPress con Latch
Este es un ataque muy común, y por supuesto ya hablamos de cómo prevenir este tipo de ataques a través del uso de Latch.
¿Cómo envían las instrucciones de ataque a las instalaciones infectadas?
Los C&C envían las instrucciones a través de un conjunto de máquinas o red de más de 14.000 proxies. Estos proxies están alquilados al servicio Best Proxies, los cuales transmiten la información a scripts maliciosos ubicados en las instalaciones de Wordpress infectadas.
 |
| Figura 4: Estructura del ataque con proxies |
Sencillo. Leen una lista de destinos que reciben desde los servidores C2, crean una lista de credenciales basándose en patrones de contraseñas y luego intentan utilizar dichas contraseñas para iniciar sesión como administrador. Como se puede ver el funcionamiento es sencillo, pero potente.
En otras palabras, si el script malicioso tiene que intentar iniciar sesión en peligro.com con el usuario admin, se genera una contraseña como peligro, admin, admin1, admin2018, etcétera. Por lo que el patrón identificado es una contraseña para la cuenta similar al nombre de usuario o que derive de él. Es un ataque de diccionario que genera credenciales dinámicas en función del contexto del dominio y del usuario. Nada nuevo.
 |
| Figura 5: Peticiones de autenticación en el ataque |
Según parece en la investigación de Defiant, la empresa de Wordfence, comenta que la gente que está detrás de esta botnet cometió algunos errores en la implementación de los scripts maliciosos. De esta forma se ha podido conocer el detalle y exponer toda la infraestructura de backend de la botnet.
Incluso, parece que los investigadores pudieron evitar el sistema de acceso al panel del C2 y echar un vistazo a la operación. Parece que los errores no solo estaban en la implementación de los scripts, si no que también se implementó de forma incorrecta los sistemas de autenticación del panel de administración. Al menos con algunos bugs.
 |
| Figura 6: Logs de los ataques |
Aunque se ha compartido toda esta información en este reporte, los C2 han seguido activos debido a que el proveedor donde están alojados no satisface solicitudes de retirada. Hay que tener en cuenta que los intentos de inicio de sesión automatizados no van dirigidos al panel de inicio de sesión de Wordpress, y sí al mecanismo de autenticación XML-RPC de Wordpress. No intentemos cambiar la URL del panel de inicio de sesión, ya que eso no servirá. Es importante utilizar un plugin que bloquee los ataques de fuerza bruta o de diccionario que se pueden realizar contra el servicio XML-RPC.
¿Qué más podemos hacer?
Aparte de instalar un plugin que permita bloquear ataques de fuerza bruta, es importante disponer de un 2FA de autenticación. Se puede instalar el plugin oficial de Latch para Wordpress para no permitir autenticar, mientras no abramos el cerrojo Por otro lado, otra opción muy recomendado es proteger Wordpress con Latch Cloud TOTP para generar un token una vez se valide el usuario, y se introduzca como un 2FA.
Figura 7: Proteger WordPress con Latch Cloud TOTP
A modo de evitar la modificación o alteración de la base de datos se puede instalar nuestra herramienta Wordpress in Paranoid Mode. Esta herramienta permite ‘congelar’ la base de datos en caso de incidente de seguridad o darnos el poder de decidir qué tablas se pueden modificar y cuando. Con tres modos de funcionamiento: Administración, Edición y Read-Only permite al usuario utilizar una granularidad suficiente para controlar inserciones, actualizaciones y borrado de datos.
Figura 8: Hardening WordPress like a Hacker
En la conferencia de la Figura 8 hay un montón más de trucos de hardening de WordPress que puedes aprender en los diferentes posts y artículos enlazados en la referencia, pero el libro de nuestro colega Daniel Maldonado en 0xWord dedicado a "Máxima Seguridad Wordpress" ayuda a entender las necesidades que tienen este tipo de aplicaciones para garantizar la seguridad de tus sitios.
 |
| Figura 9: Libro de "Máxima Seguridad en WordPress" |
Por supuesto, si quieres tener siempre auditado y controlado tu servicio WordPress, en ElevenPaths desarrollamos un servicio que puedes contratar cuando desees que se llama Faast For WordPress y que hace Pentesting Persistente a tu servidor desde Internet para que tengas un reporte continuo de las vulnerabilidades que te afectan en el momento en que se descubren.
Figura 10: Faast for WordPress demo
Os dejo un listado de las referencias que os pueden ayudar a mejorar la seguridad de vuestras instancias de Wordpress:
[Libro] Máxima Seguridad en WordPress
[Libro] Hardening GNU/Linux
[Paper] WordPress in Paranoid Mode (Parte 1)
[Paper] WordPress in Paranoid Mode (Parte 2)
[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] MyWordPress in Paranoid Mode for Developers
[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] 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
Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.
No hay comentarios:
Publicar un comentario