LinuxParty

Durante los últimos días se ha confirmado una campaña de ataques contra sitios Joomla 3 que utilizan Helix Ultimate, Helix 3 y SP Page Builder. Los atacantes están aprovechando varias vulnerabilidades ya corregidas para modificar la configuración del sitio, inyectar código JavaScript y, en algunos casos, crear nuevos usuarios con privilegios de Super Administrador. (JoomShaper)

En ExtreHost hemos podido analizar un caso real en producción donde el código malicioso había sido almacenado dentro del campo

params

de un elemento del menú principal.

A continuación explicamos cómo comprobar si tu instalación ha sido afectada y qué pasos recomendamos seguir para eliminar la infección.

¿Qué vulnerabilidades corrigen las actualizaciones?

JoomShaper ha publicado actualizaciones de seguridad para Joomla 3 que corrigen, entre otros problemas:

• Vulnerabilidades XSS (Cross Site Scripting) en Mega Menu, galerías y Media Manager.
• Falta de validación CSRF en llamadas AJAX.
• Comprobaciones insuficientes de permisos.
• Validación incorrecta de rutas.
• Subidas inseguras de archivos.
• Redirecciones abiertas (Open Redirect).

Estas vulnerabilidades permiten que un atacante modifique configuraciones del sitio o inserte código JavaScript que posteriormente se ejecutará cuando un administrador acceda al panel de Joomla. (JoomShaper)

Lo primero: actualizar inmediatamente

Antes de limpiar el sitio es imprescindible instalar las versiones corregidas.

Descargas oficiales:

• Helix Ultimate Security Update
• Artículo oficial de JoomShaper sobre las vulnerabilidades

Si utilizas:

• Helix Ultimate
• Helix3
• SP Page Builder

deben actualizarse todos.

Actualizar únicamente SP Page Builder no elimina una posible explotación realizada mediante Helix Ultimate.

¿Cómo funciona el ataque?

En uno de los sitios analizados el atacante había introducido un enorme bloque JavaScript dentro del campo:

params

Del elemento de menú Inicio. (En la Base de datos de Joomla)

Ese código permanecía almacenado en la base de datos hasta que un administrador abría el menú desde Joomla.

En ese momento el navegador ejecutaba el JavaScript utilizando la sesión del propio administrador.

Entre otras acciones, el script:

• obtenía el token CSRF;
• abría el formulario de creación de usuarios;
• intentaba crear un nuevo Super Usuario;
• enviaba las credenciales a un servidor remoto.

Es decir, el atacante no necesitaba conocer la contraseña del administrador: utilizaba su propia sesión cuando éste accedía al panel.

Vaciar el campo params

En la mayoría de los casos puede eliminarse completamente el contenido del campo

params

Generalmente no afecta al funcionamiento del menú.

Únicamente podrían perderse opciones estéticas como:

• iconos;
• badges;
• HTML personalizado;
• clases CSS;
• opciones específicas del Mega Menu.

El enlace del menú seguirá funcionando porque esa información se almacena en otros campos de la tabla.

Cómo eliminar el contenido desde phpMyAdmin

Entrar en:

phpMyAdmin

Seleccionar la base de datos de Joomla.

Abrir la tabla:

jos_menu

(o el prefijo correspondiente de tu Base de Datos).

Buscar el elemento afectado.

Editar el registro.

En el campo:

params

reemplazar el contenido por:

{}

o dejarlo completamente vacío.

Guardar los cambios.

Buscar otros menús afectados

Es recomendable revisar toda la tabla de menús.

SELECT id,title
FROM jos_menu
WHERE params LIKE '%<script%'
   OR params LIKE '%warnightkardesim%'
   OR params LIKE '%admin_mori%'
   OR params LIKE '%custom_html%'
   OR params LIKE '%badge%';

Revisar los módulos

También pueden existir inyecciones en módulos Joomla.

SELECT id,title,module
FROM jos_modules
WHERE params LIKE '%<script%'
   OR content LIKE '%<script%';

Revisar los estilos de plantilla

Los parámetros de la plantilla también pueden ser utilizados para almacenar código.

SELECT id,title,template
FROM jos_template_styles
WHERE params LIKE '%<script%'
   OR params LIKE '%warnightkardesim%'
   OR params LIKE '%admin_mori%'
   OR params LIKE '%custom_html%';

Revisar los artículos

Aunque menos frecuente, también es recomendable comprobar los artículos.

SELECT id,title
FROM jos_content
WHERE introtext LIKE '%<script%'
   OR fulltext LIKE '%<script%';

Buscar usuarios creados por el atacante

Uno de los primeros pasos consiste en revisar todos los Super Usuarios.

SELECT
    u.id,
    u.name,
    u.username,
    u.email,
    u.registerDate,
    u.lastvisitDate,
    u.block,
    m.group_id
FROM jos_users AS u
INNER JOIN jos_user_usergroup_map AS m
ON m.user_id=u.id
WHERE m.group_id=8
ORDER BY u.id DESC;

También es recomendable comprobar los usuarios creados recientemente.

SELECT
id,
name,
username,
email,
registerDate,
lastvisitDate
FROM jos_users
ORDER BY registerDate DESC;

Si aparece cualquier usuario desconocido, debe eliminarse inmediatamente.

Cerrar todas las sesiones

Una vez eliminados los usuarios sospechosos y cambiadas las contraseñas, conviene cerrar todas las sesiones activas.

TRUNCATE TABLE jos_session;

Todos los usuarios tendrán que volver a iniciar sesión.

Buscar código malicioso en toda la base de datos

( Esto, en el caso de tener acceso SSH, pero te la puedes descargar )

Una búsqueda rápida mediante

mysqldump

puede ahorrar muchas horas de revisión.

mysqldump -u usuario -p basedatos --no-create-info \
| grep -niE "warnightkardesim|admin_mori|joomlacreater|<script>"

( Esto, en el caso de tener acceso SSH, pero te la puedes descargar )
( En tal caso, basta hacer, con Linux, Mac o FreeBSD )

cat ficherobbdd.txt | grep -niE "warnightkardesim|admin_mori|joomlacreater|<script>"

En Windows con PowerShell:

Get-Content ficherobbdd.txt | Select-String -Pattern "warnightkardesim", "admin_mori", "joomlacreater", "<script>"

Revisar los logs del servidor

Los registros de Apache o Nginx pueden ayudar a localizar el momento de la intrusión.

Algunas búsquedas útiles:

grep -RiE \
'helix|helixultimate|com_ajax|com_menus|task=.*save' \
/var/www/vhosts/system/TUDOMINIO/logs/

Y para SP Page Builder:

grep -RiE \
'com_sppagebuilder|uploadCustomIcon|asset.uploadCustomIcon' \
/var/www/vhosts/system/TUDOMINIO/logs/

También es recomendable buscar accesos relacionados con la creación de usuarios.

grep -RiE \
'option=com_users|task=user.apply|task=user.save' \
/var/www/vhosts/system/TUDOMINIO/logs/

No basta con actualizar

Actualizar Helix Ultimate o SP Page Builder cierra la vulnerabilidad, pero no elimina:

• usuarios creados por el atacante;
• JavaScript almacenado en la base de datos;
• modificaciones realizadas en los menús;
• posibles puertas traseras instaladas en el servidor.

Por ello, si el sitio ya ha sido comprometido, es imprescindible realizar una revisión completa antes de considerarlo limpio. (JoomShaper)

Recomendaciones finales

Después de limpiar el sitio recomendamos:

• Actualizar Joomla y todas las extensiones.
• Cambiar todas las contraseñas (Joomla, FTP, SSH, panel de hosting y base de datos).
• Revisar los Super Usuarios.
• Vaciar todas las sesiones.
• Comprobar los registros del servidor.
• Revisar periódicamente las tablas

  jos_menu

  ,

  jos_modules

  y

  jos_template_styles

• Mantener copias de seguridad diarias.

Conclusión

Los ataques recientes contra Joomla 3 demuestran que una vulnerabilidad en una extensión puede ser suficiente para comprometer completamente un sitio web. En muchos casos la actualización llega cuando el atacante ya ha introducido código persistente en la base de datos.

La buena noticia es que, actuando rápidamente, es posible detectar la mayoría de las modificaciones, eliminar los usuarios maliciosos y devolver el sitio a un estado seguro.

Si administras sitios Joomla para clientes o utilizas Helix Ultimate, Helix3 o SP Page Builder, ahora es el momento de revisar todos tus servidores antes de que la próxima sesión de administración active una carga JavaScript oculta.