cPGuard repartió una puerta trasera a servidores Linux por su propio canal de actualizaciones, y el aviso llegó cuando parte del daño ya estaba hecho. OPSSHIELD, la empresa detrás de la herramienta, publicó este martes 3 de noviembre un aviso de seguridad: reconoce que un atacante entró el 2 de noviembre a las 02:06 UTC a su infraestructura de distribución, la red de entrega de contenido que reparte las actualizaciones, con credenciales robadas. Desde ahí empujó un script malicioso a servidores que usan cPGuard como cortafuegos. No explotó un fallo del programa: entró por la vía que reparte las actualizaciones.
Las versiones afectadas son la 5.88.12 a la 5.88.19. OPSSHIELD contó que detectó el ataque dentro de las 12 horas siguientes al lanzamiento de esas actualizaciones, aseguró la cuenta comprometida, limpió las credenciales de su infraestructura y detuvo el reparto del script. Esa rapidez tiene un límite: como los servidores revisan actualizaciones en intervalos distintos, algunos podrían no haber ejecutado el script.
El script buscaba lo más sensible de un servidor Linux. Copió /etc/shadow y /etc/passwd, la configuración de la base de datos de la cuenta raíz (my.cnf de MariaDB o MySQL), el historial de comandos de la cuenta raíz y los archivos de autorización y de equipos conocidos de SSH. Todo quedó en una carpeta oculta bajo /var/tmp, con el nombre .cpg91511, dentro de un archivo llamado loot.tgz, y subió al propio servidor de licencias de OPSSHIELD, bajo una cuenta comprometida, para que el atacante lo recogiera después. El programa que debía defender al servidor se convirtió en el mensajero de sus secretos.
32 archivos confirmados en manos del atacante
En la actualización del 3 de noviembre, OPSSHIELD estimó que el atacante recuperó 32 archivos recogidos, cada uno de un servidor cliente distinto. La empresa subraya que esa cifra mide la recuperación confirmada, no el total de servidores que pudieron recibir el script, y que es preliminar. Tampoco halló, hasta ahora, otra actividad maliciosa aparte de la recolección de datos y de la puerta trasera instalada por el script.
El detalle que más duele a un administrador está en /etc/shadow. Las contraseñas de Linux se guardan ahí como resúmenes irreversibles, no como texto legible, así que nadie puede entrar con el resumen directamente. Pero puede probar listas de contraseñas conocidas contra esos resúmenes, sin tocar el servidor, hasta dar con las débiles o repetidas. Las largas, únicas y generadas al azar resisten mucho mejor esa prueba, aunque ni la contraseña fuerte garantiza que la cuenta esté a salvo, advierte OPSSHIELD. Los secretos que aparecen en la configuración de la base de datos o en el historial de comandos no tienen ni esa protección: ahí sí puede haber claves en claro.
Cómo saber si un servidor recibió la actualización mala
La revisión empieza en el registro de actualizaciones con un comando: grep ‘Successfully updated’ /opt/cpguard/logs/install_log. Cualquier entrada entre la 5.88.12 y la 5.88.19 confirma que el servidor instaló una actualización afectada, y OPSSHIELD ordena tratarlo como potencialmente comprometido, aunque ya corra la versión corregida. Falta un matiz que la empresa repite dos veces: esa entrada no prueba que el script se ejecutara ni que salieran datos, y un registro ausente o incompleto tampoco prueba que el servidor escapó.
Los indicios concretos que deja el script tienen nombre propio: el archivo cpguard-v58812-i91511.sh, la puerta trasera en /var/tmp/.cpg91511_sh y la carpeta /var/tmp/.cpg91511. La actualización correctiva borra la puerta y los archivos guardados. Su ausencia después de la limpieza no demuestra que el script nunca corriera, porque la limpieza borra justo la evidencia que se busca. El patrón no es nuevo: una actualización de Rank Math PRO trajo malware con la misma lógica de confianza, y en este caso el canal era el de una herramienta de seguridad.
El arreglo tiene dos pasos y OPSSHIELD los pone en orden. Primero, actualizar todos los servidores con cpgcli update –start. Después, comprobar la versión con cpgcli –version: debe mostrar 5.88.25 o superior. Si la actualización falla, el camino es el soporte de OPSSHIELD.
Actualizar no basta, y ahí está la parte que más trabajo deja. OPSSHIELD pide restablecer las contraseñas de la cuenta raíz y de todas las cuentas locales con contraseña, desde un entorno de recuperación confiable, y cambiar en otros sistemas cualquier contraseña reutilizada. A eso se suma rotar las contraseñas de las bases de datos, las llaves de S3, los tokens de DigitalOcean y los secretos que aparezcan en el historial de comandos, además de reemplazar las llaves privadas de SSH bajo /root/.ssh y retirar las llaves públicas viejas de cada sistema que las confíe. La empresa no recomienda, por ahora, reconstruir el servidor completo como respuesta de rutina, con una salvedad: si aparecen más señales de compromiso, la reconstrucción entra en la conversación.
Para un dueño de hosting pequeño, la lección es incómoda: la herramienta contratada para vigilar su servidor fue la que abrió la puerta, y la defensa real fue revisar a tiempo un registro que muchos miran cada semana, no cada hora. La cifra de 32 archivos puede moverse en cualquier dirección. Los servidores que instalaron la 5.88.12 a la 5.88.19 ya saben qué buscar; los que no revisaron su registro todavía están a ciegas.
Fuente: Cybersecurity News
