Um invasor entrou no sistema de atualização da ferramenta de segurança cPGuard em 2 de novembro e o usou para enviar um script malicioso aos servidores Linux dos clientes.
O script instalou uma porta dos fundos (backdoor) e coletou hashes de senhas e outros arquivos sensíveis dos servidores que o executaram, informou a OPSSHIELD, fabricante do cPGuard, em um comunicado. O invasor já obteve parte desses dados.
A versão 5.88.25 do cPGuard e as posteriores removem o backdoor e os arquivos deixados pelo script. Credenciais copiadas pelo script podem continuar funcionando após a atualização, por isso qualquer servidor que possa ter executado o script também precisa de novas senhas e chaves.
Às 02:06 UTC (Tempo Universal Coordenado), o invasor, que não foi identificado, usou credenciais comprometidas para acessar o sistema de atualização do cPGuard. O script foi distribuído nas versões 5.88.12 a 5.88.19.
O ataque foi detectado em até 12 horas após o lançamento dessas versões, segundo a OPSSHIELD. A empresa redefiniu as credenciais de infraestrutura e impediu que o script chegasse a mais servidores. A investigação continua para apurar como o invasor obteve as credenciais.
A OPSSHIELD não informou quantos servidores instalaram uma dessas versões. Os servidores verificam atualizações em intervalos, então alguns podem não ter executado o script.
Administradores podem verificar se um servidor instalou uma versão afetada pesquisando seu registro de atualização:
grep 'Successfully updated' /opt/cpguard/logs/install_log
Uma entrada de qualquer versão de 5.88.12 a 5.88.19 indica que o servidor instalou uma atualização afetada. A entrada, por si só, não mostra que o script foi executado nem que dados saíram do servidor. O servidor ainda deve ser tratado como potencialmente comprometido, mesmo que agora use a versão 5.88.25 ou posterior.
Um servidor sem entradas correspondentes, ou com um registro ausente ou incompleto, ainda pode ter executado o script. Administradores em dúvida podem entrar em contato com o suporte da OPSSHIELD.
A OPSSHIELD identificou que o script coletou os seguintes tipos de dados: /etc/shadow e /etc/passwd, a configuração do MariaDB ou MySQL do root (my.cnf), o histórico de shell do root e os arquivos de autorização SSH (Secure Shell) e de hosts conhecidos do root. Pode não ter coletado todos os arquivos de todos os servidores, e a empresa ainda está apurando quais arquivos saíram de cada um.
O arquivo /etc/shadow armazena hashes de senha de mão única. Senhas fracas, comuns ou já vazadas podem ser recuperadas desses hashes por meio de testes de tentativas offline, e mesmo as senhas fortes precisam ser redefinidas. Segredos que podem estar na configuração do banco de dados ou no histórico de shell não têm nenhum hash que os proteja.
O script enviou os dados coletados para um servidor de licenciamento operado pela própria OPSSHIELD, usando uma conta comprometida, para que o invasor pudesse recuperá-los depois. A OPSSHIELD já protegeu essa conta.
Segundo estimativa da OPSSHIELD feita no fim de 2 de novembro (UTC), o invasor retirou 32 arquivos desse servidor, cada um associado a um servidor de cliente. A contagem inclui apenas os arquivos sabidamente retirados e pode mudar. Ela não mostra quantos servidores podem estar envolvidos no total.
Além da coleta de dados e do backdoor, a OPSSHIELD não encontrou, até agora, outra atividade maliciosa, uma conclusão que, segundo a empresa, ainda não é definitiva.
O que os administradores do cPGuard devem fazer agora
A OPSSHIELD pede que os administradores atualizem agora todos os servidores com cPGuard e confirmem a versão:
- Execute cpgcli update --start em cada servidor.
- Execute cpgcli --version e verifique se a versão é 5.88.25 ou posterior. Se a atualização falhar ou a versão for inferior, entre em contato com o suporte da OPSSHIELD.
Os administradores também devem adotar as seguintes medidas em qualquer servidor onde o script foi executado ou possa ter sido executado:
- A partir de um ambiente de recuperação confiável, redefina as senhas do root e de todas as outras contas locais do Linux que usem senha.
- A partir de um dispositivo confiável, altere as senhas que também são usadas em outros sistemas.
- Renove as senhas do banco de dados do servidor, as chaves de acesso do S3 (Amazon Simple Storage Service), os tokens da DigitalOcean e quaisquer segredos registrados no histórico de shell do root.
- Substitua as chaves privadas SSH armazenadas em /root/.ssh e remova as chaves públicas antigas correspondentes de todos os sistemas que confiam nelas.
A OPSSHIELD não recomenda uma redefinição completa nem a reinstalação do sistema operacional como etapa de rotina, e afirma que essa posição pode mudar conforme a investigação avança. Administradores que encontrarem outros sinais de comprometimento ou não puderem confirmar que um servidor está limpo devem solicitar ao suporte da OPSSHIELD uma análise caso a caso, que pode levar à reinstalação.
Paralelamente, a OPSSHIELD está lançando outra atualização, como medida preventiva, que remove suas chaves de acesso de suporte dos servidores cPGuard onde foram adicionadas anteriormente.
O acesso de suporte é um recurso do cPGuard que os clientes usam para permitir que a equipe da OPSSHIELD acesse um servidor para solução de problemas. Ao concedê-lo, é adicionada ao arquivo authorized_keys do root uma chave pública SSH pertencente à OPSSHIELD, segundo a documentação da empresa.
A OPSSHIELD não informou se a chave privada correspondente à sua chave de acesso de suporte foi exposta no ataque.
Arquivos deixados pelo script
A OPSSHIELD divulgou os nomes destes arquivos. A atualização remove o shell de backdoor e o diretório de coleta, de modo que a ausência deles após a atualização não comprova se o script foi executado.
- Arquivo: cpguard-v58812-i91511.sh (o script malicioso)
- Arquivo: /var/tmp/.cpg91511_sh (shell de backdoor)
- Diretório: /var/tmp/.cpg91511 (onde o script reunia os arquivos)
- Arquivo: /var/tmp/.cpg91511/loot.tgz (arquivo compactado preparado pelo script)
