Um invasor usou credenciais comprometidas para acessar o sistema de atualização do cPGuard às 02:06 UTC de 2 de novembro, de acordo com um comunicado da OPSSHIELD, fabricante da ferramenta de segurança. O canal comprometido distribuiu um script malicioso com as versões 5.88.12 a 5.88.19 do cPGuard, podendo afetar servidores Linux que instalaram essas versões.
O script instalou um backdoor e coletou arquivos, incluindo hashes de senhas de /etc/shadow, detalhes de contas de /etc/passwd, a configuração do MariaDB ou MySQL do root, histórico do shell e arquivos de autorização SSH e de hosts conhecidos. Ele enviou os dados coletados para um servidor de licenciamento da OPSSHIELD usando uma conta comprometida. A empresa afirma que, posteriormente, o invasor retirou 32 arquivos desse servidor, cada um associado a um servidor de cliente. Esse número corresponde aos arquivos cuja retirada foi confirmada e não estabelece o número total de servidores potencialmente afetados.
A OPSSHIELD detectou o ataque em até 12 horas após o lançamento das versões afetadas, protegeu as credenciais de sua infraestrutura e bloqueou a distribuição do script. A empresa não informou quantos servidores instalaram uma versão afetada e ainda investiga como o invasor obteve as credenciais e quais dados foram retirados de cada servidor. Ela afirmou não ter encontrado nenhuma outra atividade maliciosa até o momento, observando que a investigação continua.
Os administradores devem atualizar todos os servidores cPGuard executando `cpgcli update --start` e, em seguida, confirmar com `cpgcli --version` que estão usando a versão 5.88.25 ou posterior. A OPSSHIELD afirma que essas versões removem o backdoor e os arquivos deixados pelo script. No entanto, uma atualização não comprova que um servidor nunca foi comprometido, e as credenciais copiadas podem continuar válidas.
Para verificar os registros de atualização, os administradores podem pesquisar com `grep 'Successfully updated' /opt/cpguard/logs/install_log`. Uma entrada referente a uma versão entre 5.88.12 e 5.88.19 significa que o servidor instalou uma atualização afetada, mas não comprova que o script foi executado nem que dados foram retirados. Um registro ausente, incompleto ou sem ocorrências não necessariamente descarta a exposição; a OPSSHIELD recomenda entrar em contato com o suporte se houver dúvida sobre o estado do servidor.
Para servidores nos quais o script foi executado ou pode ter sido executado, a empresa recomenda redefinir as credenciais de root e de outras contas locais que usam senha, a partir de um ambiente de recuperação confiável. Senhas reutilizadas em outros sistemas também devem ser alteradas a partir de um dispositivo confiável. Os administradores devem trocar as senhas de bancos de dados, as chaves de acesso do S3, os tokens da DigitalOcean e os segredos registrados no histórico do shell de root, além de substituir as chaves privadas SSH armazenadas em /root/.ssh e remover as respectivas chaves públicas antigas dos sistemas que confiam nelas.
No momento, a OPSSHIELD não recomenda uma redefinição completa de rotina nem a reinstalação do sistema operacional, embora afirme que essa orientação possa mudar à medida que a investigação avançar. A empresa recomenda uma análise caso a caso para sistemas com outros indícios de comprometimento ou cujo estado não possa ser confirmado. Ela também está preparando uma atualização preventiva separada para remover as chaves SSH de acesso ao suporte dos servidores em que os clientes ativaram anteriormente esse recurso. A empresa não informou se a chave privada correspondente foi exposta.
Fontes: The Hacker News.