Make (anteriormente Integromat Connector) <= 1.5.10 — Carga de archivos arbitrarios autenticada para administradores (CVE-2025-6085)

Fecha: 2025-09-03

Autor: Experto en seguridad de Hong Kong

Resumen

CVE-2025-6085 afecta a las versiones del plugin Make (anteriormente Integromat Connector) hasta e incluyendo 1.5.10. Un administrador autenticado puede cargar archivos arbitrarios en el sitio a través de los puntos finales de carga del plugin. Aunque la explotación requiere credenciales de administrador, las consecuencias pueden ser severas: webshells, ejecución remota de código, persistencia y compromiso total del sitio.

Este aviso proporciona un desglose técnico, escenarios de ataque realistas, indicadores de detección, un manual de respuesta a incidentes y mitigaciones prácticas que puedes aplicar de inmediato, con un enfoque en el endurecimiento operativo del servidor y parches virtuales donde sea apropiado.

Por qué los propietarios de sitios deberían preocuparse incluso cuando se requieren privilegios de administrador

• Las credenciales de administrador se reutilizan, filtran o se obtienen mediante phishing; una sola cuenta de administrador comprometida permite la explotación directa.
• Muchos sitios tienen múltiples administradores (desarrolladores, contratistas) lo que aumenta la exposición.
• Los atacantes pueden encadenar otros errores (XSS, CSRF, fijación de sesión) para obtener sesiones de administrador y luego explotar esta falla de carga.
• Una vez que un atacante puede colocar archivos ejecutables bajo el directorio raíz web, puede ejecutar código, persistir y pivotar a través del entorno.

Trata esta vulnerabilidad como de alta prioridad incluso si requiere autenticación de administrador.

Desglose técnico (lo que significa “carga de archivos arbitrarios” aquí)

Las vulnerabilidades de carga de archivos arbitrarios ocurren cuando las cargas de archivos se almacenan sin una validación suficiente del lado del servidor de:

• Tipo de archivo y tipo MIME
• Extensión de archivo
• Directorio de destino
• Contenido del archivo (para prevenir código ejecutable)
• Nombre del archivo (para prevenir la traversía de ruta)
• Comprobaciones de autorización en el punto de carga

En Make <= 1.5.10, el punto de carga permitía a un administrador autenticado colocar archivos arbitrarios en el disco. Si el destino es accesible por la web (cargas, directorio de plugins), un atacante puede subir un webshell PHP e invocarlo a través de HTTP. Alternativamente, los archivos subidos podrían ser incluidos más tarde por otra lógica de la aplicación, lo que lleva a la ejecución remota de código.

Componentes típicos de tal explotación:

• Un punto de carga que acepta datos de archivos a través de POST
• Falta de comprobaciones estrictas de tipo/extensión/contenido del lado del servidor
• Destino de carga accesible para el servidor web
• Permisos de archivo permisivos o configuración del servidor web que permite la ejecución

Escenarios de ataque realistas

1. Administrador malicioso o cuenta de administrador comprometida:

   Se utiliza una cuenta de administrador de proveedor o contratista comprometida para subir un webshell PHP a través del plugin, luego el atacante ejecuta comandos para persistir y escalar.

2. Cadena CSRF / XSS almacenado:

   Un atacante induce a un administrador a realizar acciones o explota XSS almacenado para obtener una sesión privilegiada, luego sube una carga útil.

3. Puertas traseras persistentes / abuso de la cadena de suministro:

   Las puertas traseras subidas sobreviven a las actualizaciones o se utilizan para manipular otros plugins/temas/archivos del núcleo.

CVSS y contexto de riesgo

La puntuación CVSS publicada es 7.2. La puntuación refleja un alto impacto (posible ejecución remota de código / compromiso del sitio) mientras que la complejidad del ataque se modera por el requisito de privilegios de administrador. En la práctica, los sitios pequeños a menudo están en mayor riesgo debido a una higiene de credenciales débil y monitoreo limitado.

Detección: señales de que puedes haber sido explotado

• Archivos PHP nuevos o modificados en:
  • /wp-content/uploads/
  • /wp-content/plugins/make-connector/ (o el nombre de la carpeta del plugin)
  • Otros directorios de plugins o temas
• Archivos con nombres extraños o extensiones dobles (por ejemplo, .php.jpg, .phtml)
• Archivos con marcas de tiempo que coinciden con inicios de sesión de administrador sospechosos
• Usuarios de administrador no reconocidos o cambios recientes de roles
• Tareas cron sospechosas o tareas programadas
• Conexiones salientes desde el servidor web a IPs o dominios inusuales
• Registros HTTP que muestran acceso a archivos recién subidos o POSTs inusuales a puntos finales de plugins
• .htaccess modificado o configuraciones del servidor que permiten la ejecución

Herramientas de detección útiles: monitoreo de integridad de archivos, registros de acceso/error del servidor, escáneres de malware y auditorías de bases de datos para usuarios sospechosos o cambios de opciones.

Pasos inmediatos si ejecutas el plugin afectado (triage de incidentes)

1. Aislar y contener
   • Coloca el sitio en modo de mantenimiento o desconéctalo para limitar las operaciones del atacante.
   • Si es posible, bloquea el acceso HTTP público en el firewall o servidor mientras investigas.
2. Preservar evidencia
   • Copia los registros (acceso/error web, FTP/SFTP, SSH), volcado de base de datos y listados del sistema de archivos a un lugar seguro para forenses.
   • No sobrescribas registros ni reinicies sistemas críticos a menos que sea necesario para contener la situación.
3. Identifica y elimina archivos sospechosos

   Busca archivos PHP añadidos recientemente e inspecciona su contenido. Preserva copias forenses antes de la eliminación.

   find /var/www/html/wp-content/uploads -type f -mtime -7 -print

   Busca indicadores de webshell como base64_decode, eval, preg_replace con /e, llamadas a system/exec.

4. Cambie las credenciales
   • Restablece todas las contraseñas de administrador y cuentas de servicio (FTP, SSH, DB).
   • Fuerza el cierre de sesión de todos los usuarios y expira sesiones.
   • Rota las claves API y tokens utilizados por el sitio.
5. Verifica la persistencia
   • Inspecciona wp-config.php, mu-plugins, .htaccess y archivos PHP de temas/plugins en busca de código inyectado.
6. Restaurar desde una copia de seguridad conocida y buena

   Si está disponible, restaure desde una copia de seguridad limpia tomada antes de la violación. Verifique que el sitio restaurado esté parcheado y limpio antes de reconectar a producción.

7. Actualizar o eliminar el complemento

   Si existe un parche, aplíquelo de inmediato. Si no hay una solución disponible y el complemento no es esencial, desinstálelo y elimine sus archivos; la desactivación sola puede dejar archivos en el disco.

8. Asegurar y monitorear
   • Aplique endurecimiento del lado del servidor y configure monitoreo continuo durante al menos varias semanas después de la remediación.

Si no tiene confianza para realizar los pasos de manera segura, involucre a su proveedor de alojamiento o a un equipo profesional de respuesta a incidentes; una limpieza incompleta puede dejar puertas traseras persistentes.

Mitigaciones prácticas que puede aplicar de inmediato (no se requiere parche a nivel de código)

Estas mitigaciones reducen la superficie de ataque y limitan el impacto incluso cuando el complemento vulnerable permanece instalado.

A. Bloquear el(los) punto(s) de carga en el nivel de WAF / servidor web

Cree reglas para bloquear solicitudes POST a los puntos de carga del complemento, excepto desde IPs de confianza. Si su firewall admite parches virtuales, bloquee solicitudes que coincidan con patrones de explotación (por ejemplo, POST a admin-ajax.php con un parámetro de acción específico).

Ejemplo de regla nginx para denegar una URI de carga de complemento específica:

location ~* /wp-admin/admin-ajax.php {

Confirme los nombres de acción y las URIs inspeccionando el código fuente del complemento y pruebe las reglas en un entorno de pruebas primero.

B. Deshabilitar la ejecución de PHP en directorios de carga

Evite que se ejecute PHP desde archivos subidos configurando el servidor web:

Apache (.htaccess) para /wp-content/uploads/:

<IfModule mod_php7.c>
    php_flag engine off
</IfModule>
<FilesMatch "\.(php|php5|phtml|phar)$">
    Require all denied
</FilesMatch>

Nginx (bloque de servidor):

location ~* ^/wp-content/uploads/.*\.(php|php5|phtml|phar)$ {

Esto bloquea la ejecución directa incluso si se carga un archivo PHP.

C. Hacer cumplir estrictas verificaciones de tipo de archivo en los controladores de carga

Donde sea posible, restringir los tipos MIME y extensiones aceptados a tipos conocidos como seguros (imágenes, PDFs). Para plugins no confiables, confiar en controles a nivel de servidor hasta que el plugin sea parcheado.

D. Fortalecer el acceso de administrador

• Requerir autenticación de dos factores para todas las cuentas de administrador.
• Eliminar cuentas de administrador no utilizadas y limitar el número de administradores al mínimo.
• Usar contraseñas fuertes y únicas y un gestor de contraseñas.
• Restringir el acceso a wp-admin por IP o utilizando HTTP Basic Auth si es operativamente posible.

E. Menor privilegio para procesos PHP y permisos de archivo

• Asegurarse de que el servidor web se ejecute con una cuenta de usuario sin privilegios.
• Establecer permisos del sistema de archivos para que wp-content sea escribible solo donde sea necesario y los archivos del plugin no sean escribibles por el mundo o el servidor web a menos que se esté actualizando.

F. Copias de seguridad regulares y copias inmutables

• Mantener copias de seguridad diarias fuera del sitio y al menos una instantánea inmutable que el servidor web no pueda alterar.
• Probar restauraciones periódicamente.

G. Monitoreo y alertas

• Utilizar monitoreo de integridad de archivos para alertar sobre archivos PHP nuevos o modificados.
• Monitorear conexiones salientes y patrones de tráfico anormales.

WAF y parcheo virtual: lo que hacen y por qué son importantes aquí

El parcheo virtual aplica reglas en la capa del firewall para interceptar y bloquear intentos de explotación sin modificar el código de la aplicación. Cuando un parche oficial aún no se aplica (o no se puede aplicar de inmediato), los parches virtuales ofrecen protección inmediata.

Tácticas comunes de parcheo virtual para esta vulnerabilidad:

• Bloquear las publicaciones POST a la acción de carga del plugin específica excepto desde IPs de administrador de confianza.
• Bloquear cargas multipart que incluyan etiquetas de apertura PHP o nombres de archivos que terminen en .php.
• Bloquear solicitudes con cargas multipart sospechosas o parámetros inesperados.

El parcheo virtual es valioso para la protección a corto plazo mientras parches, elimines el plugin o realices una remediación controlada.

Firmas de WAF de muestra (patrones conceptuales)

Estos son patrones ilustrativos; prueba cuidadosamente en staging para evitar falsos positivos.

• Detectar nombres de archivos que terminen en .php en la carga multipart:

  Condición: multipart/form-data && filename =~ /\.php(\d+)?$/i

• Bloquear cargas que contengan etiquetas PHP:

  Condición: request_body contiene “<?php”

• Bloquear POST a la acción de carga del plugin:

  Condición: POST && request_uri contiene “/wp-admin/admin-ajax.php” && args contiene “action=make_upload”

Seguridad a largo plazo: lista de verificación para desarrolladores y propietarios de sitios

• Mantener actualizado el núcleo de WordPress, temas y plugins; suscribirse a fuentes de vulnerabilidades para una rápida conciencia.
• Limitar cuentas de administrador y auditar roles regularmente.
• Hacer cumplir 2FA para usuarios privilegiados.
• Usar contraseñas fuertes y únicas y rotar credenciales ante sospechas.
• Desactivar la edición de archivos en WP admin:

  define('DISALLOW_FILE_EDIT', true);

• Escanear regularmente en busca de malware y realizar verificaciones de integridad de archivos.
• Endurecer PHP: desactivar funciones peligrosas (exec, shell_exec, system) si no son necesarias.
• Deshabilitar la lista de directorios en la configuración del servidor web.
• Utilizar protecciones del lado del servidor como mod_security o conjuntos de reglas equivalentes y un WAF correctamente configurado.
• Mantener copias de seguridad probadas y planes de restauración.
• Limitar el acceso SSH/FTP a IPs conocidas y usar SSH basado en claves.

Manual de respuesta a incidentes (flujo de trabajo detallado)

1. Triage (primeras 24 horas)
   • Confirmar si el sitio ejecuta el plugin/version afectado.
   • Crear instantáneas forenses del servidor y la base de datos.
   • Limitar el acceso cambiando las contraseñas de administrador y colocando el sitio en modo de mantenimiento.
2. Contener (24–72 horas)
   • Aplicar reglas de firewall/WAF para bloquear patrones de explotación de inmediato.
   • Deshabilitar o desinstalar el plugin si no existe un parche confiable.
   • Preservar y eliminar archivos sospechosos después de que se tomen copias forenses.
   • Rotar credenciales de administrador y del sistema.
3. Erradicar y Recuperar (72 horas – semanas)
   • Limpiar o restaurar archivos comprometidos; si no está seguro, restaurar desde una copia de seguridad limpia.
   • Parchear y actualizar todos los componentes de software.
   • Reconstruir sistemas si es necesario y volver a emitir claves y secretos de API.
4. Post-incidente
   • Realizar un análisis de causa raíz para entender cómo se expusieron las credenciales de administrador.
   • Mejorar el registro, la monitorización y la capacitación de administradores.
   • Considere evaluaciones de seguridad regulares y pruebas de penetración.

Indicadores de Compromiso (IoCs) — lista de verificación rápida

• Nuevos archivos con nombres sospechosos en directorios de cargas o plugins
• Firmas de webshell: base64_decode, eval(base64_decode(…)), preg_replace con /e, system/exec/passthru
• Registros HTTP que muestran acceso a archivos sospechosos o POSTs a puntos finales de plugins
• Conexiones salientes inesperadas desde procesos PHP
• Usuarios administradores no reconocidos o cambios de rol

Ejemplos de fragmentos de endurecimiento (usar con cuidado)

Deshabilitar XML-RPC si no es necesario:

add_filter('xmlrpc_enabled', '__return_false');

Deshabilitar la edición de archivos de plugins/temas en wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Si no puede aplicar un parche de inmediato — opciones defensivas temporales

• Desinstale y elimine el plugin por completo si no es esencial.
• Elimine los archivos del plugin después de la desactivación para evitar código sobrante.
• Bloquee los puntos finales de administración del plugin a nivel de servidor web o WAF.
• Restringa wp-admin a IPs conocidas o coloque HTTP Basic Auth frente a wp-admin.
• Monitoree continuamente los indicadores de explotación.

Consejo de cierre de un experto en seguridad de Hong Kong

Las rutas de código que aceptan archivos y escriben bajo el webroot deben ser tratadas con la máxima precaución. Las vulnerabilidades a nivel de administrador a menudo conducen rápidamente a un compromiso completo porque permiten a los atacantes colocar código ejecutable persistente. Si ejecuta el plugin afectado y no puede actualizar de inmediato, tome medidas conservadoras: desactive o elimine el plugin, aplique restricciones a nivel de servidor, imponga 2FA y otro endurecimiento de administrador, y asuma compromiso hasta que se demuestre lo contrario.

Cuando tenga dudas, involucre a su proveedor de alojamiento o a un equipo de respuesta a incidentes de confianza para garantizar una limpieza exhaustiva y profesional.

Lista de verificación final — acciones rápidas para realizar ahora

1. Verifique la versión del plugin: si <= 1.5.10, actúe de inmediato.
2. Si hay una versión parcheada disponible, actualiza sin demora.
3. Si no existe un parche, desinstala y elimina los archivos del plugin.
4. Aplica 2FA y contraseñas fuertes para todas las cuentas de administrador.
5. Desactiva la ejecución de PHP en las subidas y bloquea los puntos de carga de plugins a nivel de servidor/WAF.
6. Escanea en busca de archivos sospechosos y preserva evidencia para forenses.
7. Rota todas las credenciales y claves API después de la limpieza.
8. Habilita la monitorización: integridad de archivos, tráfico saliente y registros de acceso.

Referencias y lecturas adicionales

• CVE-2025-6085 (aviso público)
• Directrices de endurecimiento de seguridad de WordPress (documentación oficial)
• Mejores prácticas de endurecimiento de PHP y servidor web