Un atacante no identificado tomó el control del sistema de actualizaciones de cPGuard, una herramienta de seguridad para servidores Linux de hosting. Lo usó para enviar a los clientes un script malicioso que instaló una puerta trasera (backdoor) y robó credenciales. El caso afecta a cualquier organización o proveedor de hosting que use cPGuard, y muestra cómo una herramienta de protección puede convertirse en la vía de entrada.
Según el aviso de OPSSHIELD, fabricante de cPGuard, el intruso ingresó el 2 de noviembre a las 02:06 UTC con credenciales comprometidas. El script viajó dentro de las versiones 5.88.12 a 5.88.19. La empresa detectó el ataque en menos de 12 horas, revocó las credenciales de su infraestructura y detuvo la distribución. Aún investiga cómo obtuvo el atacante esas credenciales y no ha revelado cuántos servidores instalaron las versiones afectadas.
El script recopiló archivos sensibles: /etc/shadow y /etc/passwd, la configuración de MariaDB o MySQL de root (my.cnf), el historial de comandos de root y los archivos de autorización y hosts conocidos de SSH. El archivo /etc/shadow guarda los hashes de las contraseñas, es decir, versiones cifradas en un solo sentido. Las contraseñas débiles o ya filtradas pueden recuperarse probando combinaciones fuera de línea. Los secretos del historial de comandos o de la configuración de la base de datos quedan expuestos sin ninguna protección.
La información robada se subió a un servidor de licencias del propio fabricante mediante una cuenta comprometida, desde donde el atacante la descargó. OPSSHIELD estima que se llevó 32 archivos, cada uno asociado a un servidor de cliente, aunque la cifra puede cambiar. Además, el fabricante retirará como precaución sus llaves de acceso de soporte, que se agregan al archivo authorized_keys de root. No ha aclarado si la llave privada correspondiente quedó expuesta.
Los administradores deben ejecutar cpgcli update --start en cada servidor y confirmar con cpgcli --version que la versión sea 5.88.25 o posterior, que elimina el backdoor y los archivos del script. Para saber si un servidor instaló una versión afectada, pueden revisar el registro con grep 'Successfully updated' /opt/cpguard/logs/install_log. Un registro ausente o incompleto no descarta el compromiso. La actualización no invalida lo robado, así que en todo servidor posiblemente afectado conviene:
- Restablecer, desde un entorno de recuperación confiable, la contraseña de root y de cada cuenta local con contraseña.
- Cambiar esas contraseñas en otros sistemas donde se reutilicen.
- Rotar contraseñas de bases de datos, llaves de acceso de S3, tokens de DigitalOcean y cualquier secreto presente en el historial de root.
- Reemplazar las llaves privadas SSH de
/root/.sshy retirar las llaves públicas antiguas de todos los sistemas que confían en ellas.
Los artefactos publicados son cpguard-v58812-i91511.sh, /var/tmp/.cpg91511_sh, el directorio /var/tmp/.cpg91511 y el archivo loot.tgz. Como la actualización los elimina, su ausencia no prueba que el servidor esté limpio.
Qué significa para tu empresa: Si tus servidores de hosting usan cPGuard, trátalos como comprometidos y rota esta semana todas sus credenciales y llaves SSH, aunque ya estén actualizados. Este caso demuestra que no basta con confiar en el software de seguridad instalado. Un servicio de monitoreo 24/7 desde un SOC detecta conexiones salientes inusuales, accesos con llaves no autorizadas o la creación de archivos ocultos en /var/tmp, y permite contener el incidente en horas. Revisa también qué proveedores tienen acceso de soporte a tus servidores y retira el que no sea indispensable.
Fuente original: The Hacker News — ver artículo →