Resumo

  • O anúncio não autorizado de 162.55.80.0/24 manteve o AS24940 da Hetzner como origem aparente e passou como RPKI Valid sob uma ROA que permitia /24, apesar do caminho forjado.
  • A Virtualizor reconstruiu a propagação com 368 pares do RIPE RIS, mas diz que as respostas do invasor não chegaram aos seus logs e que não pode produzir uma lista definitiva das instalações afetadas.
  • Falta um recibo local de consumo da atualização, ligando versão solicitada, manifesto assinado, hash do pacote, chave aceita, decisão de verificação e resultado de instalação ou reversão.

Relatórios de incidentes têm a tendência de transformar o maior número disponível em sinônimo de impacto. Aqui, esse número é 368. A Virtualizor informa que todos os 368 pares do conjunto observado pelo RIPE Routing Information Service carregaram a rota sequestrada em algum momento. A constatação mede alcance na topologia de roteamento. Ela não mede clientes, downloads, instalações concluídas nem comprometimentos.

A distinção separa quatro sistemas de prova. Coletores de BGP registram caminhos anunciados. Uma autoridade certificadora registra validação de domínio e emissão. A máquina do invasor observa as solicitações desviadas. Cada servidor com Virtualizor toma, localmente, a decisão de buscar, aceitar e executar um pacote. O ataque atravessou as quatro superfícies, porém nenhum desses registros tem a mesma população ou responde às perguntas dos demais.

O LACNIC publicou em 10 de setembro de 2026 uma versão em espanhol da análise da Kentik. A publicação torna o episódio uma notícia relevante para a comunidade regional, mas não faz do LACNIC operador da infraestrutura afetada. A página declara que as opiniões são dos autores e não necessariamente representam o registro. A atribuição correta é simples: o LACNIC divulgou o caso, a Kentik analisou a rota e a Virtualizor relatou o impacto no produto.

O significado limitado de RPKI Valid

Por volta de 20h57 UTC de 28 de agosto, 162.55.80.0/24 apareceu na tabela global com o trecho final 6204 62390 24940. O /24 era mais específico que o 162.55.0.0/16 normalmente originado pela Hetzner. Em redes que aceitaram os dois anúncios, a regra de correspondência ao prefixo mais longo conduziu o tráfego do /24 para a nova rota.

O atacante preservou o AS24940 da Hetzner como origem aparente no fim do AS path. A ROA que cobria o espaço autorizava essa origem e permitia comprimento até /24. Assim, a validação de origem podia devolver RPKI Valid. A resposta dizia que prefixo, comprimento e último AS cabiam na autorização publicada. Não dizia que AS62390 era um upstream legítimo, que as adjacências eram verdadeiras ou que o destino pertencia ao fornecedor esperado.

A RFC 9319 descreve essa classe de sequestro de subprefixo com origem forjada. Quando uma ROA não mínima cobre prefixos mais específicos que o titular não anuncia de fato, um adversário pode manter a origem autorizada no fim do caminho e ocupar esse espaço vazio. A recomendação de usar ROAs mínimas, sempre que possível, reduz a oportunidade. Não oferece assinatura criptográfica de todo o AS path.

Por isso, a palavra “válida” precisa de complemento. Válida para a origem não é o mesmo que caminho autorizado, endpoint autêntico ou software confiável. Essa precisão não diminui o RPKI. Ao contrário, preserva sua utilidade ao impedir que uma verificação de escopo definido seja vendida como selo geral de segurança.

A Virtualizor situa o incidente aproximadamente entre 20h57 UTC de 28 de agosto e 06h10 UTC de 30 de agosto. Foram duas ondas ativas separadas por cerca de onze horas de calmaria. A reconstrução conta aproximadamente 10.600 retiradas de rota. Com tamanha oscilação, uma amostra a cada dez minutos não é um filme contínuo. A empresa ressalva que os pontos alinhados aos dumps de RIB de oito horas são mais confiáveis e que valores intermediários podem subcontar pares durante flapping intenso.

O resultado 368 de 368 também exige o advérbio “alguma vez”. Não significa que todos os pares carregaram o caminho ao mesmo tempo. No pico de uma onda ativa, o número informado equivaleu a cerca de 72% do conjunto completo de 368 pares. E ainda assim se trata de um proxy topológico, não de volume de tráfego. Um par ligado a uma grande rede e outro ligado a um participante menor recebem o mesmo peso. Converter essa taxa em vítimas seria fabricar uma estatística.

Um certificado correto para o destino errado

O desvio alcançou também o processo usado para comprovar controle dos domínios. Segundo a Virtualizor, o invasor conseguiu um certificado TLS tecnicamente válido para diversos nomes da família Softaculous, inclusive endpoints de distribuição. Um cliente enviado à máquina falsa podia estabelecer conexão criptografada sem alerta de certificado. O TLS protegia a sessão até o destino entregue pelo roteamento; não restaurava o destino pretendido pelo fornecedor.

A Corroboração de Emissão por Múltiplas Perspectivas, MPIC, foi criada para elevar o custo desse ataque. A autoridade certificadora consulta pontos remotos e exige concordância, de modo que uma falsidade localizada gere divergência. Desde 15 de junho de 2026, os requisitos aplicáveis do CA/Browser Forum pedem pelo menos quatro perspectivas remotas, com as confirmações distribuídas por ao menos duas regiões de serviço de RIRs. A Let’s Encrypt explica há anos que o sequestro ou redirecionamento do caminho de validação pode enganar uma observação única.

O certificado emitido não prova que MPIC seja inútil. O argumento da Kentik é mais estreito: uma rota mais específica, sem concorrente equivalente e amplamente propagada, apresentou a resposta do invasor a perspectivas suficientes para formar o quórum. Múltiplos pontos detectam uma mentira local pela discordância. Se a mentira vira a visão comum, o quórum pode concordar com o endpoint errado. ROAs estritas, alertas de rota, controles sensíveis ao caminho e perspectivas realmente diversas continuam sendo defesas complementares.

O log legítimo não vê a resposta ilegítima

A Virtualizor confirma que o pacote malicioso foi entregue a um pequeno número de instalações, descrito também como um punhado de servidores. Ao mesmo tempo, afirma não poder produzir a lista definitiva. As respostas foram servidas pelo sistema do atacante e jamais chegaram aos logs próprios.

Isso não é contradição. Um log de origem registra apenas solicitações que alcançam a origem. Durante um desvio bem-sucedido, a ausência de uma linha pode significar que o cliente não fez o pedido ou que outra máquina respondeu. Justamente quando o atacante captura o tráfego, o registro central legítimo fica fora da transação. Procurar novamente nesse log não revela uma resposta que ele nunca serviu.

O fluxo normal de atualização torna a lacuna cara. A documentação da Virtualizor diz que o produto, se a atualização automática não for desativada, verifica novidades a cada 24 horas. Um administrador também pode iniciar o processo no painel ou na linha de comando. Para delimitar o incidente seria preciso saber quais instalações consultaram durante as ondas, quais atravessaram um intervalo desviado, quais completaram o download, quais aceitaram o pacote e quais o executaram. A tabela de pares de roteamento não contém essas colunas.

O comunicado apresenta outra fragilidade essencial: os clientes ainda não verificavam criptograficamente os pacotes. A empresa promete implantar assinatura de código para todos eles. Essa é a primeira correção obrigatória. Um atualizador privilegiado deve validar metadados assinados, hash, versão, canal e chave autorizada, e deve parar quando a prova falha. A segurança do transporte não pode ser a única autenticação do código.

Assinatura e atribuição, porém, são controles diferentes. Uma assinatura permite ao cliente rejeitar no futuro um arquivo sem chave autorizada. Ela não registra automaticamente o que aconteceu em cada máquina no passado. Mesmo num sistema assinado, o operador precisa saber qual versão foi pedida, qual hash chegou, qual chave foi aceita, se a validação falhou e se houve instalação, quarentena ou rollback.

Um recibo produzido no ponto de decisão

Cada tentativa de atualização deveria deixar um registro pequeno e resistente a alteração na própria instalação. Ele inclui canal e versão solicitada, horário, hash do manifesto assinado, hash do pacote, chave ou quórum aceito, resultado da verificação e desfecho local: rejeição, quarentena, instalação, falha ou reversão. Revogações, alertas de incidente e correções posteriores devem poder referenciar o mesmo recibo.

Não é necessário publicar uma lista de clientes. O operador pode guardar o recibo, usar identificador pseudônimo para o equipamento ou frota e revelar apenas a prova indispensável. O fornecedor pode oferecer confirmação opcional: recebe evidência cega ou pseudônima e devolve um carimbo de tempo. Grandes empresas agregam internamente; operadores menores exportam um único comprovante ao suporte. Privacidade limita a coleta, mas não obriga a trabalhar sem prova.

O recibo cria uma junção entre duas afirmações. O registro de lançamento do fornecedor diz que certo manifesto, pacote e conjunto de chaves eram autorizados. O registro local diz que determinada máquina solicitou aquela versão, verificou aquele hash e tomou aquela decisão. Se o invasor controla rota e endpoint, mas não a chave, fica provada a rejeição. Se uma chave é revogada, localizam-se as instalações que a aceitaram. Se o verificador tiver uma falha, o hash delimita quem instalou o artefato.

Ele também organiza os substantivos do relatório. Um par RIS vendo a rota demonstra exposição de rede. Uma consulta numa janela desviada cria oportunidade de entrega. Um download concluído demonstra aquisição. A instalação demonstra execução. Um indicador de comprometimento demonstra impacto. São filtros sucessivos, não sinônimos. Cada contagem deve vir com seu denominador, método e incerteza.

A resposta atual foi substancial, mas não tinha recibos

A melhor defesa da atuação da empresa deve vir antes da crítica. A Virtualizor divulgou a entrega do pacote, publicou um indicador, pediu rotação e restrição de credenciais, recomendou auditoria e preservação de evidências, relatou o certificado para revogação, reconstituiu o roteamento e prometeu assinatura. Kentik e LACNIC explicaram ROAs estritas e monitoramento sem vender validação de origem como verdade sobre o caminho inteiro.

O problema não é a falta de uma certeza impossível nos logs do atacante. É a ausência anterior de uma obrigação para que o ponto de decisão produzisse um registro portátil. Quando o servidor malicioso respondeu, o log central saiu da transação. A evidência independente possível pertencia à instalação. Pedir que todos os operadores verifiquem seus sistemas é prudente sob incerteza; é também o custo operacional de não saber a quem enviar um alerta dirigido.

Um próximo relatório deveria conseguir alinhar três livros. O livro de rotas mostra qual perspectiva viu qual path e quando. O livro de lançamentos mostra manifesto, pacote, versão e chaves autorizadas. O livro das instalações mostra a decisão de cada cliente. Nenhum substitui outro. Juntos, eles transformam um alerta para todos em uma lista justificável de reparo.

Fontes