Script de Detecção de Estado de Patch — Impersonação de Agente no Veeam Service Provider Console

Um detector seguro e não autenticado para as vulnerabilidades KB4893 no Veeam Service Provider Console (publicado em 2026-08-04). Ele responde a uma pergunta por alvo, antes de qualquer autenticação ou TLS: as correções da KB4893 estão presentes neste console?

O par principal é uma cadeia. CVE-2026-58073 (CVSS 9.5) permite que um peer de rede não autenticado se faça passar por um agente de gerenciamento conectado e receba o certificado real desse agente, porque o handshake do agente decide a autorização a partir do GUID que o peer escreveu no próprio certificado. CVE-2026-58072 (CVSS 9.0) é uma escrita arbitrária de arquivo alcançável quando você possui uma identidade de agente. Encadeadas, elas resultam em execução remota de código não autenticada no console que gerencia os backups de todos os tenants. O mesmo aviso também corrige CVE-2026-58071 (CVSS 8.2, API de appliance proxied como Portal Administrator) e CVE-2026-58067 (CVSS 8.7, DoS não autenticado por exaustão de memória). CVE-2026-58073 e CVE-2026-58072 foram reportadas à Veeam por meio do HackerOne; o aviso não nomeia o reporter.

Este script não tenta impersonação, não solicita um certificado e não escreve um arquivo. Ele lê a geração de protocolo anunciada pelo roteador e nada mais.

É Seguro Executar?

Sim. O detector foi projetado para uso em produção e avaliação:

• Nenhuma autenticação é tentada, e nenhuma das vulnerabilidades é exercitada. Ele envia apenas um handshake Connector nomeando um receiver que não existirá. Nenhuma sessão TLS é negociada, nenhum certificado é apresentado, e SaveFiles nunca é chamado.
• Nenhum estado do alvo é alterado. A única ação do servidor é uma busca de dicionário com falha em ChannelHostProxy.m_multiplexers. Nenhum receiver é registrado, nenhum canal ou multiplexer é construído, nenhum registro de agente é tocado. Um handshake do tipo Receiver registraria um nome; esta ferramenta nunca envia um.
• Sua pegada de log é documentada e atribuível. Duas conexões TCP e seis linhas em ConnectionHub.log, cada uma carregando o nome do receiver bf-probe-<uuid4> para que um defensor possa distinguir um scan de um ataque. As linhas exatas estão abaixo.
• Proteção contra falsos positivos. Um alvo só é reportado como VULNERABLE depois de provar que é um VSPC ConnectionHub (veja abaixo), então um serviço TCP silencioso não pode ser confundido com um console sem patch.

O que ele deixa em um alvo

Por alvo, a ferramenta abre duas conexões TCP e envia um handshake ConnectionHub em cada uma, nomeando um receiver bf-probe-<uuid4> que não existirá.

Sob o padrão --transport auto, um alvo cujo transporte não é o implicado pela sua porta custa uma conexão extra: a sonda de transporte errado é rejeitada durante o handshake, antes que qualquer nome de receiver seja lido, e o transporte correto é então usado para ambas as sondas reais. Fixe --transport direct ou --transport gateway para manter exatamente duas conexões — vale a pena se você citou uma contagem de conexões em uma solicitação de mudança.

Estado alterado no servidor: nenhum. O caminho de código Connector realiza uma busca de dicionário em ChannelHostProxy.m_multiplexers, falha e retorna um erro. Nenhum receiver é registrado, nenhum multiplexer ou canal é criado, nenhuma sessão TLS é negociada, nenhum registro de agente é tocado. Esta ferramenta nunca envia um handshake do tipo Receiver, que é o que registraria um nome.

As entradas de log são gravadas em %ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log. Verbatim de um ConnectionHub 9.2.1.33875 ao vivo, com timestamps e JSON de escopo removidos:

sonda 1 (versão 6), builds com e sem patch:
    [INFO] ChannelHostProxy: Accept connection begin {"RemoteEndPoint":"<ip>:<port>","Line":"1"}
    [INFO] ChannelHostProxy: Accept connection end   {"RemoteEndPoint":"<ip>:<port>","Line":"2",...}
    [WARN] ChannelHostProxy: Cannot connect transmitter. Requested receiver not found
           (receiver name:bf-probe-<uuid>) {"RemoteEndPoint":"<ip>:<port>","Line":"3",...}

sonda 2 (versão 7), apenas builds com patch:
    as mesmas três linhas

sonda 2 (versão 7), builds sem patch:
    [INFO] ChannelHostProxy: Accept connection begin
    [WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
    [INFO] ChannelHostProxy: Accept connection end

Duas conexões, seis linhas, nenhuma outra entrada e nenhuma mudança de estado — confirmado em um host ao vivo.

A string literal bf-probe- em ConnectionHub.log identifica o tráfego desta ferramenta, então um defensor pode atribuí-lo e uma equipe de scan pode provar o que enviou. Altere RECEIVER_PREFIX no código-fonte se precisar de um marcador diferente.

Como Funciona

O roteador de agentes de gerenciamento ConnectionHub lê um handshake do cliente antes de qualquer autenticação ou TLS, e Request.Read valida a versão de protocolo anunciada pelo cliente contra um intervalo fixo. A correção ampliou esse intervalo no mesmo build que corrigiu as CVEs:

Build	Verificação	Aceita
<= 9.2.1.33875 (vulnerável)	(uint)(versionByte - 3) <= 3	3, 4, 5, 6
>= 9.3.0.35057 (com patch)	(uint)(versionByte - 3) <= 4	3, 4, 5, 6, 7

Portanto, um handshake anunciando a versão 7 é um discriminador binário limpo. O detector envia duas sondas por alvo, nesta ordem por um motivo (a detecção de transporte pode adicionar uma terceira — veja abaixo):

Sonda	Anuncia	Propósito
1	versão 6	Deve retornar Requested receiver not found, provando que o alvo realmente é um VSPC ConnectionHub
2	versão 7	Uma resposta significa PATCHED; silêncio significa VULNERABLE

Sem a barreira do estágio um, o silêncio na sonda 2 também corresponderia a qualquer serviço TCP silencioso na internet, e firewalls seriam reportados como consoles Veeam vulneráveis.

Ambos os transportes, detectados por alvo

Funciona sobre ambos os caminhos que um agente de gerenciamento usa:

Transporte	Porta	Exposição
Direto ao ConnectionHub	9999	geralmente interno
Através de um gateway Veeam Cloud Connect	6180	voltado à internet por design

O caminho do gateway precisa de um prólogo de relay que o caminho direto não deve ter, então a sonda 1 também serve como detecção de transporte. Sob o padrão --transport auto, ele tenta um transporte e, se a barreira de fingerprint não passar, tenta o outro. Qualquer um que passe é fixado, e a sonda 2 o reutiliza — um arquivo de alvos misto não precisa de anotação por host.

A fixação é essencial. Se a sonda 2 pudesse tentar novamente no outro transporte, o silêncio não seria mais atribuível à verificação de versão, apenas a "um dos dois caminhos de bytes não respondeu", que é como um VULNERABLE falso é fabricado.

Qual transporte é tentado primeiro é decidido pela porta, e isso não é cosmético — as duas incompatibilidades falham em velocidades muito diferentes:

Incompatibilidade	Como o lado remoto lê	Custo
Prólogo de relay → hub direto	meta int16 de hostType 44 / versionByte 0, falha na verificação de intervalo de Request.Read	descartado em uma ida e volta
Handshake direto → gateway	comprimento de frame int32 de 1,012,729,346	o gateway espera por bytes que nunca chegam; queima o timeout completo