As primeiras horas depois de um CVE crítico: uma lista de verificação que funciona

É publicada uma vulnerabilidade de severidade máxima num componente central. A partir desse momento o relógio corre para toda a gente, atacantes incluídos. A diferença entre um dia calmo e uma semana má raramente é o patch em si. É o que se faz nas horas antes e depois dele. Esta é a sequência que seguimos, escrita para que a possa adaptar à sua própria frota.

Hora zero: leia o aviso duas vezes

Leia o aviso uma vez para perceber a falha e outra para perceber as condições. A maioria dos avisos sérios vem com qualificadores: só quando um determinado módulo está carregado, só num determinado modo do servidor, só quando uma funcionalidade é alcançável a partir da rede. Esses qualificadores decidem quais dos seus hosts são urgentes, quais são apenas afetados, e que mitigação se aplica.

Escreva três coisas antes de tocar em alguma coisa: os nomes dos pacotes afetados, a versão upstream corrigida, e as condições de exploração. Tudo o que se segue é verificado contra essa nota.

Encontre todos os hosts que o correm

Pergunte à base de dados de pacotes de cada host em vez de confiar no que julga estar instalado:

for h in $(cat hosts.txt); do
  printf '%s: ' "$h"
  ssh -o BatchMode=yes "$h" 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}\n" <package> 2>/dev/null || echo not-installed'
done | tee exposure-$(date +%F).txt

Depois verifique as condições. Se a falha vive num módulo, liste o que está realmente carregado. Se precisa de uma funcionalidade alcançável, verifique se o é. Ordene o resultado em três grupos: expostos e alcançáveis, instalado mas não explorável tal como está configurado, e não presente. O primeiro grupo é mitigado agora.

Mitigue antes de a correção existir

Há quase sempre algo que se pode fazer antes de um pacote corrigido estar disponível: desativar a funcionalidade vulnerável, alterar um valor de configuração, colocar uma regra no edge que bloqueie a forma de request de que o exploit precisa. Escolha a mitigação menos disruptiva que feche o caminho, e aplique-a com disciplina:

• Mantenha uma lista de todas as mitigações que colocou, para poder levantar as que custam desempenho assim que a correção real chegar. As mitigações que não custam nada podem ficar.

Construa a correção se for preciso

Às vezes o projeto upstream já publicou código-fonte corrigido e a distribuição ainda não o empacotou. Esperar é uma opção, mas não é a única. Quando decidimos não esperar, construímos o pacote nós próprios: a partir da especificação do próprio maintainer da distribuição, num container limpo e descartável, a partir de código-fonte cujo checksum é verificado contra a página oficial de download do projeto, com uma release tag escolhida para que o build do próprio fabricante substitua o nosso automaticamente quando chegar. Os pacotes vão para o nosso próprio mirror com os checksums registados. O método completo, com comandos, está em O seu próprio mirror RPM, e construir a correção antes de a distribuição a publicar.

A decisão de construir é um juízo, não um reflexo. Construa quando a falha está a ser explorada ou é trivialmente explorável, os hosts afetados são alcançáveis, e nenhuma mitigação fecha o caminho suficientemente bem. Caso contrário, uma mitigação sólida mais uma curta espera pelo pacote do fabricante é normalmente a escolha mais calma.

Mantenha um registo, e informe as pessoas

Mantenha uma cronologia à medida que avança

Abra um ficheiro de texto simples na hora zero e escreva uma linha por ação, com a hora: aviso lido, inventário feito, mitigação colocada em que hosts, pacote construído, cada host corrigido, revisão de logs terminada. Custa segundos por linha. Dá-lhe a janela de exposição exata de cada host, de que a revisão de logs precisa, e transforma o relatório que deve depois numa edição em vez de um exercício de memória.

Informe as pessoas antes de perguntarem

As pessoas que dependem dos sistemas afetados vão saber de uma vulnerabilidade famosa pelas notícias, muitas vezes em horas. Diga-lhes primeiro. Uma mensagem curta a indicar se os seus sistemas são afetados, o que já foi feito e quando a correção chega vale mais do que um relatório perfeito uma semana depois. Se algum passo precisar de downtime, acorde o momento com elas antes de o tomar.

Rollout um host de cada vez, com prova

Cada host recebe uma verificação prévia e uma verificação posterior, e as duas são comparadas, não olhadas por alto:

php -m | sort > pre-modules.txt      # or the equivalent for your component
curl -s -o /dev/null -w '%{http_code}\n' https://<site>/health
# install, then reload gracefully
systemctl reload php-fpm
php -m | sort > post-modules.txt && diff pre-modules.txt post-modules.txt

Numa frota maior, automatize a parte cuidadosa em vez de a saltar. Um rollout que atualiza um servidor por execução, amostra websites reais antes e depois, e pára todo o varrimento e chama um engenheiro no momento em que um único website não volta, é ao mesmo tempo mais rápido e mais seguro do que uma pessoa a percorrer uma lista de noite.

Depois pergunte se a janela foi usada

O patching fecha a porta. Não lhe diz se alguém passou por ela enquanto esteve aberta. Assim que o rollout terminar, pesquise os logs web e de autenticação para o período entre a divulgação e o patch em cada host exposto. Procure as formas de request de que o exploit precisa, processos ou ficheiros inesperados criados nessa janela, e logins que não encaixam no padrão habitual. Escreva o que encontrou, incluindo «nada», porque as pessoas que dependem desses sistemas vão perguntar.

A versão curta

• Leia as condições, não só a severidade.
• Inventário a partir da base de dados de pacotes, não de memória.
• Mitigue em horas.
• Construa a correção apenas quando se justifica, e faça-o da forma limpa.
• Mantenha uma cronologia e informe cedo as pessoas afetadas.
• Rollout um host de cada vez com verificações comparáveis antes e depois, e paragem automática.
• Reveja a janela de exposição nos logs, e reporte-a.

Se for divulgada uma vulnerabilidade e quiser ajuda para a gerir na sua própria plataforma, estamos por perto. Fale com um engenheiro

Relacionados: Resposta de emergência a vulnerabilidades no mesmo dia · O hardening baseline em cada host · Plataformas atuais e disciplina de atualizações