Script di rilevamento dello stato di patch per l'impersonificazione dell'agente di Veeam Service Provider Console

Un rilevatore sicuro e non autenticato per le vulnerabilità KB4893 in Veeam Service Provider Console (pubblicato il 04-08-2026). Risponde a una domanda per ogni target, prima di qualsiasi autenticazione o TLS: le correzioni KB4893 sono presenti su questa console?

La coppia principale è una catena. CVE-2026-58073 (CVSS 9.5) consente a un peer di rete non autenticato di impersonare un agente di gestione connesso e di ricevere il certificato reale di quell'agente, perché l'handshake dell'agente decide l'autorizzazione in base al GUID che il peer ha scritto nel proprio certificato. CVE-2026-58072 (CVSS 9.0) è una scrittura arbitraria di file raggiungibile una volta che si possiede un'identità di agente. Collegate, costituiscono un'esecuzione remota di codice non autenticata sulla console che gestisce i backup di ogni tenant. Lo stesso advisory corregge anche CVE-2026-58071 (CVSS 8.2, API dell'appliance proxata come Portal Administrator) e CVE-2026-58067 (CVSS 8.7, DoS non autenticato per esaurimento della memoria). CVE-2026-58073 e CVE-2026-58072 sono state segnalate a Veeam tramite HackerOne; l'advisory non menziona il nome del segnalatore.

Questo script non tenta l'impersonificazione, non richiede un certificato e non scrive file. Legge solo la generazione del protocollo pubblicizzata dal router e nient'altro.

È sicuro eseguirlo?

Sì. Il rilevatore è progettato per uso in produzione e per valutazioni:

• Non viene tentata alcuna autenticazione e nessuna delle due vulnerabilità viene sfruttata. Invia solo un handshake Connector che nomina un receiver che non esisterà. Nessuna sessione TLS viene negoziata, nessun certificato viene presentato e SaveFiles non viene mai chiamato.
• Nessuno stato del target viene modificato. L'unica azione del server è una ricerca fallita nel dizionario in ChannelHostProxy.m_multiplexers. Nessun receiver viene registrato, nessun canale o multiplexer viene creato, nessun record di agente viene toccato. Un handshake di tipo Receiver registrerebbe un nome; questo strumento non ne invia mai uno.
• La sua impronta nei log è documentata e attribuibile. Due connessioni TCP e sei righe in ConnectionHub.log, ciascuna con il nome del receiver bf-probe-<uuid4> così che un difensore possa distinguere una scansione da un attacco. Le righe esatte sono riportate sotto.
• Protezione dai falsi positivi. Un target viene segnalato come VULNERABLE solo dopo aver dimostrato di essere un ConnectionHub VSPC (vedi sotto), quindi un servizio TCP silenzioso non può essere scambiato per una console non patchata.

Cosa lascia su un target

Per ogni target lo strumento apre due connessioni TCP e invia un handshake ConnectionHub su ciascuna, nominando un receiver bf-probe-<uuid4> che non esisterà.

Con il default --transport auto, un target il cui trasporto non è quello implicito dalla sua porta costa una connessione extra: la sonda con il trasporto sbagliato viene rifiutata durante l'handshake, prima che venga letto qualsiasi nome di receiver, e il trasporto corretto viene poi usato per entrambe le sonde reali. Fissa --transport direct o --transport gateway per mantenerlo esattamente su due connessioni — utile se hai preventivato un numero di connessioni in una richiesta di modifica.

Stato modificato sul server: nessuno. Il percorso di codice Connector esegue una ricerca nel dizionario in ChannelHostProxy.m_multiplexers, non trova nulla e restituisce un errore. Nessun receiver viene registrato, nessun multiplexer o canale viene creato, nessuna sessione TLS viene negoziata, nessun record di agente viene toccato. Questo strumento non invia mai un handshake di tipo Receiver, che è quello che registrerebbe un nome.

Le voci di log vengono scritte in %ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log. Verbatim da un ConnectionHub 9.2.1.33875 live, con timestamp e JSON di scope troncati:

sonda 1 (versione 6), sia build patchate che non patchate:
    [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 (versione 7), solo build patchate:
    le stesse tre righe

sonda 2 (versione 7), build non patchate:
    [INFO] ChannelHostProxy: Accept connection begin
    [WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
    [INFO] ChannelHostProxy: Accept connection end

Due connessioni, sei righe, nessun'altra voce e nessuna modifica di stato — confermato su un host live.

La stringa letterale bf-probe- in ConnectionHub.log identifica il traffico di questo strumento, quindi un difensore può attribuirlo e un team di scansione può dimostrare cosa ha inviato. Modifica RECEIVER_PREFIX nel sorgente se hai bisogno di un marcatore diverso.

Come funziona

Il router degli agenti di gestione ConnectionHub legge un handshake del client prima di qualsiasi autenticazione o TLS, e Request.Read valida la versione del protocollo pubblicizzata dal client contro un intervallo hardcoded. La correzione ha ampliato quell'intervallo nella stessa build che ha corretto le CVE:

Build	Controllo	Accetta
<= 9.2.1.33875 (vulnerabile)	(uint)(versionByte - 3) <= 3	3, 4, 5, 6
>= 9.3.0.35057 (patchata)	(uint)(versionByte - 3) <= 4	3, 4, 5, 6, 7

Quindi un handshake che pubblicizza la versione 7 è un discriminatore binario pulito. Il rilevatore invia due sonde per target, in questo ordine per un motivo (il rilevamento del trasporto può aggiungerne una terza — vedi sotto):

Sonda	Pubblicizza	Scopo
1	versione 6	Deve restituire Requested receiver not found, dimostrando che il target è davvero un ConnectionHub VSPC
2	versione 7	Una risposta significa PATCHED; il silenzio significa VULNERABLE

Senza il gate della prima fase, il silenzio nella sonda 2 corrisponderebbe anche a qualsiasi servizio TCP silenzioso su internet, e i firewall verrebbero segnalati come console Veeam vulnerabili.

Entrambi i trasporti, rilevati per target

Funziona su entrambi i percorsi che un agente di gestione usa:

Trasporto	Porta	Esposizione
Diretto al ConnectionHub	9999	di solito interno
Tramite un gateway Veeam Cloud Connect	6180	esposto a internet per progettazione

Il percorso del gateway richiede un prologo di relay che il percorso diretto non deve avere, quindi la sonda 1 funge anche da rilevamento del trasporto. Con il default --transport auto prova un trasporto e, se il gate dell'impronta non passa, prova l'altro. Qualunque passi viene agganciato (latched), e la sonda 2 lo riusa — un file di target misto non richiede annotazioni per host.

L'aggancio è portante. Se la sonda 2 potesse riprovare sull'altro trasporto, il silenzio non sarebbe più attribuibile al controllo della versione, ma solo a "uno dei due percorsi di byte non ha risposto", che è il modo in cui viene prodotto un falso VULNERABLE.

Quale trasporto viene provato per primo è deciso dalla porta, e non è una questione estetica — i due disallineamenti falliscono a velocità molto diverse: