Radiografía del ataque a un WordPress.

Casi al finalizar el 2023 me solicitaron ayuda para «salvar», un CMS infectado, los síntomas eran:

• Apariciones de páginas con caracteres en japones.
• Activación de ventanas emergentes de forma aleatoria.
• Publicidad no deseada.
• Redirección a otros sitios.
• Tráfico desconocido desde el cliente a internet, mientras se navegaba por el sitio.

Triage

El gestor de contenidos utilizado era WordPress, alojado en un hosting administrado desde un cPanel.

El WordPress y algunos de sus plugin se encontraban desactualizados, varios con algún CVE a cuesta, por lo tanto, la primera tarea fue dejar el sitio en modo mantenimiento, respaldar todo e instalar la última versión del CMS y de cada plugin, desde el administrador.

Estas acciones sólo contuvieron la hemorragia y activaron la ventilación mecánica para mantener al CMS estable, dentro de su gravedad, pero el paciente seguía en shock.

INVESTICACION & ANALISIS

Cuentas maliciosas

El siguiente paso fue cambiar las contraseñas, pero al revisar la lista de usuarios me encuentro con más de 100 cuentas con perfil suscriptor, las cuales tienen privilegios sólo para navegar por los posts y editar su propio perfil, pero lo curioso es, que no debería existir ninguno…

Me conecte a la base de datos MySQL y revise la tabla wp_users, la cual contiene por defecto, los datos de los usuarios en WordPress, al revisar estos en detalle, pude inferir y averiguar algunas curiosidades:

• Múltiples cuentas fueron creadas utilizando servicios de correos temporales o desechables como: 1secmail.com, mailmenot.io, mail.ru, entre otros y algunos de ellos sólo disponible en ruso.
• Otros correos, distintos a los temporales, estaban catalogados como de «Alto Riesgo», ya que identifique una gran cantidad de registros y denuncias de actividades abusiva desde esos dominios, esto lo verifique en sitios como, abuseipdb.com.
• Había cuentas creadas, incluso, meses antes que alguien detectara señales anómalas o de infección.
• Múltiples coincidencias de correos registrados como suscriptor en otros WordPress, pero con datos distintos, es decir, el mismo mail, pero diferente información personal, la mayoría en Europa.
• Existían cuentas de correos falsas que utilizaban dominios ficticios o quizás fueron dominios validos en su momento, pero que ya había dejado de operar.
• Muchas cuentas contenían números al final del nombre de usuario, desde 3 dígitos en adelante, comportamiento típico en la creación de cuentas automatizadas o utilizadas por bots.

Pero más alarmante que lo anterior, fue, encontrar 2 cuentas, desconocidas, con perfil administrador, los nombres de usuarios utilizados coinciden con el nombre de usuario del correo, con el formato: tempuser_[números], donde el valor numérico, aparentemente era un número aleatorio o un correlativo, de todas formas, la utilización de este formato me lleva a pensar que existe algún proceso automatizado en la creación, infección y utilización de estas cuentas.

Codigo malicioso

Lo siguiente fue buscar las actividades realizadas por los administradores, y una de ellas fue instalar un plugin llamado WPCode (anteriormente conocido como Insertar encabezados y pies de página por WPBeginner) es un complemento popular para WordPress utilizado por más de 2 millones de sitios web y permite agregar fragmentos de código en el CMS, sin tener que editar el archivo funciones.php, incrusta scripts en el encabezado o pie de página de todo el sitio, estos fragmentos de códigos pueden ser PHP personalizados, JavaScript, código CSS o HTML.

En este caso puntual, existía una publicación llamada «Fragmento de código sin título», en el pie de página, esto significaba que ese fragmento de código se ejecutaba cada vez que se visitaba alguna página del sitio. Al revisar en detalle me encuentro con las siguientes líneas.

En javascript la función fromCharCode() es un método estático de la clase String que devuelve una cadena creada a partir de una secuencia de valores Unicode especificada o si has participado en un CTF, quizas que te resulte familiar el formato de algún reto criptográficos, ya que el texto anterior podemos convertirlo en ASCII desde Decimal, utilizando CyberChef con esta acción descubrí lo que sería, en este caso, la primera capa de ofuscación del malware o código malicioso.

Luego utilizo Js-Beautify para obtener un formato indentado del script, el cual me permite visualizar con mayor claridad los ciclos y condicionales utilizados, pero aún mantiene una ofuscación evidente y tipica de este tipo de malware, que busca tratar de ocultar su funcionalidad.

Subí el código a VirusTotal, para que sea evaluado por múltiples sistemas de seguridad pero no obtuve el resultado critico que esperaba, ya que sólo un par de aplicaciones lo identifican como malicioso y ambos lo clasificaron como troyano.

Al menos fue posible obtener algunos indicadores de compromiso (IOC).

Continue con mi cruzada de entender el código y antes de llegar al irremediable trabajo artesanal, recurrí a «JavaScript Deobfuscator and Unpacker«, y obtuve un código un poco más amable con el investigador.

Lo siguiente fue remplazar en el programa, cada variable del arreglo «_$_a798» por su valor, es decir reemplace donde decía: _$_a798[0], por su contenido en este caso un punto (.) y el código quedo de la siguiente forma.

Ahora, el porcentaje de «Spagetti Code«, bajo al mínimo y en resumen logre entender lo siguiente:

1. Primero, hace una solicitud a la API de ipify para obtener la dirección IP del cliente.
2. Luego, reemplaza todos los puntos (.) y dos puntos (:) en la dirección IP con guiones (-).
3. Obtiene el nombre de host del sitio web actual (comprometido). Si el nombre de host está vacío, lo reemplaza con «unk.com».
4. Luego, hace una solicitud a la API de resolución de DNS de Google. En la solicitud, concatena el nombre de host, la dirección IP modificada y un número aleatorio, seguido de «.ads-promo.com&type=txt».
5. Si la respuesta de la API de Google contiene una respuesta de tipo 16 (que corresponde a un registro TXT), decodifica la respuesta usando, «atob».
6. Finalmente, si la respuesta decodificada no está vacía, redirige al usuario a la URL especificada en la respuesta.

El dominio ads-promo.com, había sido registrado de forma privada, esto significa que, al consultar el registro DNS, en lugar de mostrar los datos de la empresa o persona que realiza la inscripción, en la base de datos pública WHOIS, sólo se proporcionan datos genéricos de la compañía registradora.

La fecha del registro del domino fue sólo un par de meses antes y su última actualización se realiza 10 días previos al momento de la creación del fragmento de código JavaScript.

Comentarios maliciosos

Lo siguiente fue revisar los comentarios registrados en la base de datos, para identificar algún tipo de inyección, pero se descartó rápidamente, porque si bien hubo un intento desde Corea y Canadá, esto sucedió hace varios años en unos comentarios no aprobados, con unos inocente tags de HTML, que seguramente buscaban aumentar su ranking en los motores de búsqueda, una de las muchas técnica utilizada en Black SEO.

Archivos maliciosos

La probabilidad que algunos de los archivos del WordPress, temas o plugin siguieran infectados, era muy alta, entonces previo a revisar en detalle, tome la motosierra y realice lo siguiente:

• Elimine todos los temas no utilizados.
• Elimine todos los plugin no utilizados.
• Elimine todos los archivos y directorios no necesarios como respaldos, backup o duplicados.

El CMS seguía en modo mantenimiento, pero como administrador podía navegar en él, utilizando las herramientas de desarrollo web del navegador Firefox, monitorie los scripts que se cargaban en el sitio, para identificar alguno que hiciera referencia o se conectara con un dominio externo… y Bingo!

Al buscar las librerías de JavaScript, retina.min.js y modernizr.min.js, ambas tenían la misma fecha de modificación que además era distinta a todas las demás de su directorio. Luego contraste con la librería original y modernizr.min.js, tenía al menos 10 kb de diferencia, eso equivale a muchas líneas de código y retina.min.js ni siquiera existía, ya que el archivo original es retina.js.

Revise ambos en Virus Total y el resultado fue similar, 3 sistemas de seguridad los catalogaron como malicioso, yo por mi parte, no tenía ninguna duda.

siguiendo el patrón de archivos con fechas de modificación distinta a sus pares, realice un script para buscar otros candidatos, pero no identifique más archivos coincidentes.

Conecciones maliciosas

Antes de la marcha blanca instale un plugin llamado, «IP location Block» el cual realiza un bloqueo geográfico según el país del visitante mediante la IP y el ASN. Ya que los visitantes de este CMS se limitan a un país, no era necesario recibir o permitir conexiones desde todo el mundo.

Otro plus de este plugin es que registra un log con los bloqueos y al activar el sitio comenzó a llenarse rápidamente, almacenando múltiples peticiones desde países como: Rusia, Países Bajos, Indonesia, Vietnam, Tailandia, Argelia y Brasil, entre otros.

Varios de los bloqueos eran evidentemente bots o scripts automatizados buscando archivos específicos seguramente WebShell conocidas o previamente instaladas.

Registros maliciosos

Si lo recuerdan, uno de los síntomas de infección fue las apariciones de páginas con caracteres en japones, con esto en mente revise la base de datos con las publicaciones previas para buscar algún indicio de Cloaking, esta es una técnica de Black SEO, donde una web muestre un contenido al usuario y otro distinto a los bots de buscadores, existen de varios tipos como:

Cloaking por User Agent: Este es el más conocido, utiliza técnicas como HTTP rewrite que hacen que sólo se muestren los resultados si el USER-AGENT, es de un motor de búsqueda, por lo regular uno previamente seleccionado como el de Google.

Cloaking por IP Delivery: Aquí también se entrega una página distinta a la original, pero en función de la IP de origen de la petición, es decir si viene con el USER-AGENT de Google y sólo si viene de una de las direcciones IP utilizadas por el Bot de Google.

Cloaking por HTTP-Referer: Esta técnica consiste en realizar el filtrado mediante el HTTP-Referer, si el campo identifica una cadena de búsqueda originaria de Google muestra el contenido adaptado.

Luego de revisar la tabla wp_post, descarte la existencia de otras publicaciones, ya sean paginas o entradas, no existía nada fuera de lugar, tampoco identifique el uso de alguna técnica o método para permanecer ocultas a los administradores, ni existían categorías distintas a las originalmente creadas.

Cache malicioso

Una duda me seguía rondando en la cabeza, respecto a la aparición de páginas o publicaciones con caracteres en japones, nada de lo previamente encontrado explicaba este resultado. Así que recurrí a Google, pero utilizando dorks, para buscar en el cache e intentar de reconstruir lo que había hace unos meses. La primera alerta o indicios de infección, vista por los administradores, fue la aparición de páginas en japones, pero cuando comencé con la investigación había pasado más de un mes del último kanji visto en el sitio.

Para comenzar con la búsqueda en Google, filtre por el domino para acotar la búsqueda, con: «site:cmsinfectado.com«, de esta forma Google filtrara el resultado al dominio indicado, además incluí el patrón intext:, para especificar al motor que realice un búsqueda del texto indicado en el contenido, como palabra utilice el kanji más común en la escritura japonesa: «日» (esto me lo dijo una IA ;).

 site: cmsinfectado.com intext:"日"

La búsqueda me entrego un par de páginas de registros en el resultado, alguno de ellos incluso tenía 5 estrellas de calificación con varios comentarios, pero como se imaginarán… todos eran falsos.

"Un regalo de cumpleaños encantador: juego de 5 teteras de madera.
 Condición del producto Gastos de envío: Sin rayones ni manchas notables. Envío incluido (pago por el vendedor). 
Región de envío: Prefectura de Hyogo. 
Método de envío: Entrega fácil de Mercari. Tiempo de entrega: 2-3 días. Un juego de 5 tazones de té de madera."

El texto anterior es la traducción de la imagen con 5 estrellas, ya nos podemos imaginar que era lo que buscaban, básicamente levantaron un catálogo completo en el sitio que probablemente fue parte de una agresiva campaña de publicaciones fraudulentas de redes sociales o aplicaciones móviles, es un modelo de estafa típico de venta de productos, que jamás llegaran a su destino y posterior a realizar una gran cantidad de ventas desaparecen.

Recuerden que todas las imágenes anteriores vienen del cache de Google, ninguna de las páginas referenciada en este se encontraba en el actual CMS, estas url buscaban directorios, archivos PHP y HTML que ya no existían físicamente en el servidor, todos ellos fueron borrados antes que yo comenzara con el análisis y las imágenes era obtenidas desde otro dominio.

Ningún administrador del CMS borro los archivos asociados a este catálogo, sólo queda suponer que fueron eliminados por los mismo que realizaron esta campaña fraudulenta o por otro grupo cibercriminal, que tomo control del WordPress, durante ese periodo y quiso eliminar la competencia.

Antivirus

Previo a mi llegada los administradores habían probado con varios tipos de «plugin antivirus», sobre el CMS, y como pueden imaginar todos tenían el mismo veredicto, su CMS está SEGURO.

0 Archivos en Cuarentena
0 Inyecciones de base de datos
0 Amenazas de htaccess
0 Exploits de TimThumb
0 Amenazas Conocidas
0 Cambios en el archivo núcleo
0 Amenazas Potenciales

Probablemente la verificación que realizan se basa en infecciones genéricas, firmas conocidas o en técnicas antiguas o en retirada, quizás no es capaz de identificar al atacante que se comporta como un usuario real, porque sus acciones son realizadas a partir de cuentas «validas» en el sistema, pero después del análisis anterior era muy claro que el CMS estaba completamente comprometido.

Hardening WordPress

Como recomendaciones generales voy a enumerar algunas medidas que pueden tomar, para minimizar el riesgo de ser vulnerados y mantener un WordPress un poco más seguro.

1. Actualiza: Validar que siempre su CMS esté ejecutando la última versión de WordPress, también debe asegurarse que todos los plugin instalados se mantengan en su última actualización. Un software obsoleto puede ser vulnerable y una amenaza de seguridad. Además de parches de seguridad y correcciones de errores, las actualizaciones también pueden incluir nuevas características y funcionalidades.
   
2. Credenciales seguras: Usa contraseñas fuertes para tus cuentas, pero sobre todo para el administrador de WordPress. Esto puede dificultar que los atacantes adivinen tus credenciales.
   
3. Control de acceso: Limitar el acceso a tu página de administración de WordPress a ciertas direcciones IP.
   
4. Usa temas de confianza: Los temas de fuentes desconocidas pueden contener código malicioso. Es mejor obtenerlos de fuentes oficiales o confiables.
   
5. Usa plugin de confianza: Los plugin desconocidos pueden contener código malicioso. Es mejor obtenerlos de fuentes oficiales o confiables, prefiere aquellos con mayor cantidad de descargas y con buena puntuación, tampoco utilices plugin abandonado por sus creadores o que su última actualización fue hace mucho tiempo, ya que puede contener vulnerabilidades no conocidas.
   
6. Usa certificado SSL: Un certificado SSL cifra la comunicación entre el servidor y los usuarios, lo que puede proteger contra ataques de «hombre en el medio».
   
7. Eliminar los plugin y temas de WordPress no utilizados: Los plugin y temas no utilizados pueden ser una fuente de vulnerabilidades. Es mejor eliminarlos si no los estás utilizando.
   
8. Habilitar la autenticación de dos factores para WP-Admin: La autenticación de dos factores agrega una capa adicional de seguridad al requerir una segunda forma de autenticación.
   
9. Realizar copias de seguridad con regularidad: Implementa un sistema de respaldo en tiempo real o realice copias de seguridad de forma regular, ya que esto permitirá restaurar tu sitio, en el caso de ser necesario.
   
10. Limitar los intentos de inicio de sesión: Limitar los intentos de inicio de sesión por usuario e IP, puede prevenir ataques de fuerza bruta, en la misma línea, otra medida que se recomienda es la implementación de un sistema de CAPTCHA, para robustecer el control de acceso.
    
11. Cambiar la URL de inicio de sesión: Modificar la URL de inicio de sesión dificulta a los ataques automatizados el acceso a tu administrador.
    
12. Borra lo que no utilices: Elimina todos los plugin que no utilices o aquellos desactivados, sólo mantén el tema vigente, los demás bórralos, nunca subas información confidencial, archivos privados o información que no piensas publicar en el servidor, estos pueden ser indexados por un buscador o ser encontrados por un atacante.
    
13. Si no utiliza trackbacks y pingbacks desactívalos: Ya que estos pueden permitir generar comentarios no deseados y pueden usarse en un ataque DDoS y de fuerza bruta.
    
14. Ocultar errores: PHP tiene capacidades de depuración integradas y puede mostrar los mensajes de error generados por PHP en el front-end. Esta es un recurso útil para la etapa de desarrollo, sin embargo, nunca debes utilizarse en un sitio público.
    
15. Prevenir la ejecución de PHP: Algunos temas y complementos incluyen funciones que permiten a los usuarios cargar archivos a su servidor web. Sin embargo, esta característica se puede aprovechar para cargar archivos que contengan una carga útil o código malicioso, ya que este podría permitir a un atacante comprometer tu CMS. Para minimizar este riesgo modifique los permisos y evite la ejecución de código PHP en todos los directorios que no requieran ese permiso.
    
16. Elimine permisos innecesarios: Se recomienda modifica todos los directorios y archivos del CMS en el servidor y asignar los privilegios mínimos necesarios para su funcionamiento.
    
17. No listar de directorios: Al permitir la exploración de directorios estas ayudando a un atacante que recopile una gran cantidad de información sobre su sitio web.
    
18. Nombre de usuarios: No utilices usuarios administradores por defecto como «admin» o «administrador», además utiliza alias para todos los usuarios, en el caso que un atacante logre enumerar usuario el alias obtenido no coincidirá con el usuario del login para acceder al CMS.
    
19. Cerrar sesión automáticamente en usuarios inactivos: Evite accesos no autorizados para esto, se recomienda cerrar la sesión de los usuarios automáticamente después de un período de tiempo determinado de inactividad.
    
20. Busca vulnerabilidades: Escanea regularmente tu CMS con un buscador de vulnerabilidades , existen varios aplicativos gratuitos, sitios públicos y de pagos que te permiten buscar vulnerabilidades, sin tener que acceder a tu WordPress ni compartir credenciales.
    
21. Supervisión: A veces la prevención no es suficiente y aun así es posible que comprometan tu WordPress. Por eso la detección/monitoreo de intrusiones es muy importante. Le permitirá reaccionar más rápido, descubrir qué sucedió y recuperar su sitio. Mantener un log y registro de varias actividades como: accesos al sitio, llamados, creación de usuarios, modificación o creación de archivos o registros.
    

Conclusión

Con las acciones de mitigación descritas, finalmente el WordPress quedó «liberado», y hasta la fecha, no se han identificaron signos de reinfección ni tampoco fue comprometido nuevamente.

Como conclusión, creo que el CMS sufrió varios ataques automatizados originados desde distintos grupos de cibercriminales, utilizando diversos métodos, luego en la etapa de explotación y persistencia del compromiso, fue cuando uno de ellos se quedó con el control, aparentemente, expulsando al, o los demás.

He visto muchas veces organizaciones que implementas algún tipo de CMS, y con en el tiempo se desentienden de su mantención y seguridad, debemos recordar que este es un software «vivo», que debe ser mantenido y supervisado ya que es susceptible a vulnerabilidades, por lo mismo, es muy apetecido por cibercriminales, porque puede ser el medio para realizar ataques de fuerza bruta a terceros, propagar códigos maliciosos, generar spam, explotar técnicas de Black SEO, provocar ataques de denegación de servicio, realizar alguna de la inmensa variedad de estafas en línea o ser utilizado como vector de entrada para comprometer una organización, entre otras cibercrimen-cosas.

#HappyHacking