Que validadores um certificado raiz extra afeta?

Encontra um certificado raiz que não deveria estar ali, e a primeira pergunta é que identidade ele pode imitar. A resposta honesta depende de que software consulta esse repositório e de como a sua VPN verifica o gateway. Um navegador, um gestor de pacotes e um cliente VPN com uma impressão digital fixada não partilham necessariamente a mesma decisão de confiança. Mapeie os validadores antes de decidir o âmbito.

Uma raiz no repositório do sistema não é uma chave universal

Instalar uma raiz torna os certificados assinados com essa chave aceitáveis para programas que usam o repositório afetado. Não os torna automaticamente aceitáveis em todo o lado, porque algumas aplicações trazem o seu próprio pacote ou verificam um valor fixado. Também não prova que alguém executou código na máquina; uma mudança de confiança é uma capacidade entre várias. Trate o certificado como um achado a delimitar, não como todo o incidente.

O repositório importa tanto como o certificado: um pacote ao nível do utilizador e uma âncora ao nível do sistema chegam a consumidores diferentes.

Mapeie cada validador e a sua fonte de confiança

Anote cada componente que valida certificados para os fluxos de trabalho afetados: navegador, gestor de pacotes, cliente de correio, VPN. Depois encontre a fonte de confiança que cada um lê.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

A listagem do diretório mostra âncoras adicionadas localmente em sistemas ao estilo Debian, e a lista de confiança mostra o que o repositório do sistema expõe neste momento. Um navegador com repositório próprio não aparecerá ali, e uma aplicação Java ou Python pode usar outro pacote. Registe que entradas são esperadas e quais não são, usando a impressão digital em vez de apenas o nome apresentado. Essa lista é o que um responsável de resposta a incidentes precisa antes de apagar seja o que for.

Verifique a validação de par da própria VPN

Uma VPN com uma CA privada ou uma impressão digital explícita avalia o gateway segundo a sua própria configuração. Compare o que o cliente espera com o que o gateway apresenta.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

A saída dá a impressão digital SHA-256 e o assunto do certificado que o ponto final apresenta, que pode comparar com o valor configurado. OpenVPN tem uma opção de impressão digital de par que faz essa comparação para o túnel sem exigir que o repositório do sistema aceite o signatário. Essa independência é útil para o túnel e não diz nada sobre o navegador. Também não ajuda se a impressão digital esperada foi copiada desde o início da ligação suspeita.

Delimite o incidente para além do certificado

Use o procedimento do proprietário do dispositivo para remover âncoras não autorizadas e procurar as alterações que normalmente as acompanham: novos serviços, clientes modificados, definições de proxy alteradas. Numa máquina gerida, confirme a configuração legítima antes de apagar material de que outro software depende. Para cada validador, registe de onde vem a sua confiança, que identidade espera e como confirmou que a configuração atual está correta. Um túnel funcional após a limpeza é uma observação, não uma prova de que o ponto final está limpo.

Depois volte a testar os fluxos de trabalho que usavam o repositório, porque remover uma âncora pode quebrar um serviço interno que dependia dela legitimamente. A recuperação termina quando as relações de confiança esperadas funcionam e as inesperadas não.