Un atacante utilizó credenciales comprometidas para acceder al sistema de actualización de cPGuard a las 02:06 UTC del 2 de noviembre, según un aviso de OPSSHIELD, fabricante de la herramienta de seguridad. El canal comprometido distribuyó un script malicioso junto con las versiones 5.88.12 a 5.88.19 de cPGuard, lo que pudo afectar a los servidores Linux que instalaron esas versiones.

El script instaló una puerta trasera y recopiló archivos, entre ellos hashes de contraseñas de /etc/shadow, datos de cuentas de /etc/passwd, la configuración de MariaDB o MySQL de root, el historial del shell y archivos de autorización SSH y de hosts conocidos. Envió los datos recopilados a un servidor de licencias de OPSSHIELD utilizando una cuenta comprometida. La empresa afirma que, posteriormente, el atacante sustrajo 32 archivos de ese servidor, cada uno asociado a un servidor de un cliente. Esa cifra refleja los archivos cuya sustracción se conoce y no determina el número total de servidores que pudieron verse afectados.

OPSSHIELD detectó el ataque en las 12 horas posteriores a la publicación de las versiones afectadas, protegió las credenciales de su infraestructura e impidió que se siguiera distribuyendo el script. La empresa no ha dicho cuántos servidores instalaron una versión afectada y sigue investigando cómo obtuvo el atacante las credenciales y qué datos se sustrajeron de cada servidor. Afirmó que hasta el momento no ha encontrado ninguna otra actividad maliciosa, aunque señaló que la investigación sigue en curso.

Los administradores deben actualizar todos los servidores cPGuard ejecutando `cpgcli update --start` y, después, confirmar con `cpgcli --version` que se está utilizando la versión 5.88.25 o posterior. OPSSHIELD afirma que esas versiones eliminan la puerta trasera y los archivos que dejó el script. Sin embargo, una actualización no demuestra que un servidor nunca haya sido comprometido, y las credenciales copiadas podrían seguir siendo válidas.

Para revisar los registros de actualización, los administradores pueden buscar con `grep 'Successfully updated' /opt/cpguard/logs/install_log`. Una entrada correspondiente a una versión entre la 5.88.12 y la 5.88.19 significa que el servidor instaló una actualización afectada, pero no demuestra que el script se ejecutara ni que se sustrajeran datos. Un registro ausente, incompleto o sin indicios de afectación quizá no permita descartar la exposición; OPSSHIELD recomienda ponerse en contacto con el equipo de soporte si no se conoce con certeza el estado del servidor.

En los servidores donde el script se ejecutó o pudo haberse ejecutado, la empresa recomienda restablecer las credenciales de las cuentas locales protegidas con contraseña, incluida la de root, desde un entorno de recuperación confiable. También deben cambiarse desde un dispositivo confiable las contraseñas reutilizadas en otros sistemas. Los administradores deben renovar las contraseñas de bases de datos, las claves de acceso de S3, los tokens de DigitalOcean y los secretos registrados en el historial del shell de root; además, deben reemplazar las claves privadas SSH almacenadas en /root/.ssh y eliminar las claves públicas antiguas correspondientes de los sistemas que confían en ellas.

OPSSHIELD no recomienda actualmente un restablecimiento completo rutinario ni reinstalar el sistema operativo, aunque afirma que esa recomendación podría cambiar a medida que avance la investigación. Recomienda evaluar cada caso por separado en los sistemas que presenten otros indicios de compromiso o cuyo estado no pueda confirmarse. La empresa también está preparando una actualización preventiva aparte para eliminar de los servidores las claves SSH de acceso de soporte en aquellos casos en que los clientes habilitaron previamente esa función. No ha dicho si la clave privada correspondiente quedó expuesta.

Fuentes: The Hacker News.