El pasado 2 de noviembre, un atacante no identificado irrumpió en el sistema de actualizaciones de la herramienta de seguridad cPGuard y lo aprovechó para distribuir un script malicioso a los servidores Linux de sus clientes. El script instalaba una puerta trasera y extraía hashes de contraseñas y otros archivos sensibles de los equipos que lo ejecutaban, según detalló OPSSHIELD, la empresa responsable de cPGuard, en un aviso de seguridad. Parte de esa información ya ha sido sustraída por el atacante.
Las versiones 5.88.25 y posteriores de cPGuard eliminan la puerta trasera y los archivos que dejó el script. No obstante, las credenciales que el script copió podrían seguir siendo válidas después de la actualización, por lo que cualquier servidor que haya podido ejecutarlo necesita nuevas contraseñas y claves.
Cronología y alcance del incidente
A las 02:06 UTC, el atacante utilizó credenciales comprometidas para acceder al sistema de actualizaciones de cPGuard. El script se distribuyó a través de las versiones 5.88.12 a 5.88.19 de cPGuard. Según OPSSHIELD, el ataque se detectó en un plazo de 12 horas desde la publicación de esas versiones. La compañía ha restablecido las credenciales de su infraestructura y ha impedido que el script llegue a más servidores. Continúa investigando cómo obtuvo el atacante las credenciales.
OPSSHIELD no ha precisado cuántos servidores instalaron alguna de las versiones afectadas. Dado que los servidores comprueban si hay actualizaciones a intervalos regulares, es posible que algunos no llegaran a ejecutar el script.
Cómo comprobar si un servidor está afectado
Los administradores pueden verificar si un servidor instaló una versión afectada consultando el registro de actualizaciones: grep 'Successfully updated' /opt/cpguard/logs/install_log. Si aparece una entrada de cualquier versión entre la 5.88.12 y la 5.88.19, significa que el servidor instaló una actualización afectada. La mera presencia de esa entrada no demuestra que el script se ejecutara ni que se filtraran datos. Aun así, el servidor debe considerarse potencialmente comprometido, incluso si ahora ejecuta la versión 5.88.25 o posterior.
Un servidor sin entradas coincidentes, o con un registro ausente o incompleto, también podría haber ejecutado el script. Los administradores que tengan dudas pueden contactar con el soporte de OPSSHIELD.
Datos recopilados por el script
Según OPSSHIELD, el script recopiló los siguientes tipos de datos: los archivos /etc/shadow y /etc/passwd, la configuración de MariaDB o MySQL del usuario root (my.cnf), el historial de shell de root y los archivos de autorización SSH y known-hosts de root. Es posible que no recopilara todos los archivos de todos los servidores, y la empresa sigue determinando qué información salió de cada uno.
El archivo /etc/shadow almacena hashes de contraseñas de un solo sentido. Las contraseñas débiles, comunes o filtradas previamente pueden recuperarse probando conjeturas fuera de línea, e incluso las contraseñas robustas deben restablecerse. Los secretos que pueden encontrarse en la configuración de la base de datos o en el historial de shell no cuentan con esa protección de hash.
El script subió lo que recopiló a un servidor de licencias gestionado por la propia OPSSHIELD, utilizando una cuenta comprometida, para que el atacante pudiera recogerlo más tarde. OPSSHIELD ya ha asegurado esa cuenta.
A última hora del 2 de noviembre (UTC), OPSSHIELD estimó que el atacante sustrajo 32 archivos de ese servidor, cada uno vinculado a un servidor de cliente. La cifra solo incluye los archivos que se sabe que fueron sustraídos y podría variar. No indica cuántos servidores podrían estar implicados en total.
Más allá de la recopilación de datos y la puerta trasera, OPSSHIELD no ha encontrado hasta ahora otra actividad maliciosa, una conclusión que la empresa califica de no definitiva.
Qué deben hacer ahora los administradores de cPGuard
OPSSHIELD pide a los administradores que actualicen todos los servidores con cPGuard de inmediato y confirmen la versión:
- Ejecutar cpgcli update –start en cada servidor.
- Ejecutar cpgcli –version y comprobar que informa la versión 5.88.25 o posterior. Si la actualización falla o la versión es inferior, contactar con el soporte de OPSSHIELD.
Los administradores también deben tomar estas medidas en cualquier servidor donde el script se haya ejecutado o pueda haberse ejecutado:
- Desde un entorno de recuperación de confianza, restablecer las contraseñas de root y de todas las demás cuentas locales de Linux que utilicen contraseña.
- Desde un dispositivo de confianza, cambiar cualquiera de esas contraseñas que también se usen en otros sistemas.
- Rotar las contraseñas de la base de datos del servidor, las claves de acceso a S3, los tokens de DigitalOcean y cualquier secreto registrado en el historial de shell de root.
- Sustituir las claves privadas SSH almacenadas en /root/.ssh y eliminar las claves públicas antiguas correspondientes de todos los sistemas que confíen en ellas.
OPSSHIELD no recomienda como paso rutinario un restablecimiento completo ni una reinstalación del sistema operativo, y señala que esa postura podría cambiar a medida que avance la investigación. Los administradores que detecten otros indicios de compromiso o no puedan confirmar que un servidor está limpio deben solicitar al soporte de OPSSHIELD una revisión caso por caso, que podría derivar en una reinstalación.
Por otra parte, OPSSHIELD está publicando otra actualización, a modo de precaución, que elimina sus claves de acceso de soporte de los servidores cPGuard donde se habían añadido anteriormente.
El acceso de soporte es una función de cPGuard que los clientes utilizan para permitir que el personal de OPSSHIELD acceda a un servidor para tareas de diagnóstico. Según la documentación de la empresa, concederlo añade una clave pública SSH propiedad de OPSSHIELD al archivo authorized_keys de root. OPSSHIELD no ha indicado si la clave privada correspondiente a su clave de acceso de soporte quedó expuesta en el ataque.
Archivos que dejó el script
OPSSHIELD ha publicado los siguientes nombres de archivo. La actualización elimina el shell de la puerta trasera y el directorio de recopilación, por lo que su ausencia tras actualizar no demuestra nada sobre si el script se ejecutó.
- Archivo: cpguard-v58812-i91511.sh (el script malicioso)
- Archivo: /var/tmp/.cpg91511_sh (shell de la puerta trasera)
- Directorio: /var/tmp/.cpg91511 (donde el script reunía los archivos)
- Archivo: /var/tmp/.cpg91511/loot.tgz (archivo comprimido que preparaba el script)
Deja una respuesta