Veeam Service Provider Console Agent-Impersonation — Skript zur Erkennung des Patch-Zustands

Ein sicherer, nicht authentifizierter Detektor für die KB4893-Schwachstellen in Veeam Service Provider Console (veröffentlicht am 04.08.2026). Er beantwortet eine Frage pro Ziel, vor jeder Authentifizierung oder TLS: Sind die KB4893-Fixes auf dieser Konsole vorhanden?

Das Hauptpaar ist eine Kette. CVE-2026-58073 (CVSS 9.5) erlaubt es einem nicht authentifizierten Netzwerk-Peer, einen verbundenen Management-Agenten zu impersonieren und das echte Zertifikat dieses Agenten ausgestellt zu bekommen, weil der Agenten-Handshake die Autorisierung aus der GUID ableitet, die der Peer in sein eigenes Zertifikat geschrieben hat. CVE-2026-58072 (CVSS 9.0) ist ein beliebiges Dateischreiben, das erreichbar ist, sobald man eine Agenten-Identität besitzt. Verkettet ergeben sie eine nicht authentifizierte Remote-Codeausführung auf der Konsole, die die Backups jedes Mandanten verwaltet. Das gleiche Advisory behebt auch CVE-2026-58071 (CVSS 8.2, proxierte Appliance-API als Portal-Administrator) und CVE-2026-58067 (CVSS 8.7, nicht authentifizierter Speicher-Erschöpfungs-DoS). CVE-2026-58073 und CVE-2026-58072 wurden Veeam über HackerOne gemeldet; das Advisory nennt den Melder nicht.

Dieses Skript versucht nicht, eine Impersonation durchzuführen, ein Zertifikat anzufordern oder eine Datei zu schreiben. Es liest die beworbene Protokollgeneration des Routers und sonst nichts.

Ist die Ausführung sicher?

Ja. Der Detektor ist für den Produktions- und Bewertungseinsatz konzipiert:

• Es wird keine Authentifizierung versucht und keine der beiden Schwachstellen wird ausgenutzt. Es sendet nur einen Connector-Handshake, der einen Empfänger benennt, der nicht existieren wird. Es wird keine TLS-Sitzung ausgehandelt, kein Zertifikat vorgelegt und SaveFiles wird nie aufgerufen.
• Es wird kein Zielzustand geändert. Die einzige Aktion des Servers ist eine fehlgeschlagene Wörterbuchsuche in ChannelHostProxy.m_multiplexers. Es wird kein Empfänger registriert, kein Kanal oder Multiplexer aufgebaut, kein Agenten-Datensatz berührt. Ein Receiver-Typ-Handshake würde einen Namen registrieren; dieses Tool sendet nie einen.
• Sein Log-Fußabdruck ist dokumentiert und zurechenbar. Zwei TCP-Verbindungen und sechs Zeilen in ConnectionHub.log, jede mit dem Empfängernamen bf-probe-<uuid4>, damit ein Verteidiger einen Scan von einem Angriff unterscheiden kann. Die genauen Zeilen finden Sie unten.
• Schutz vor Fehlalarmen. Ein Ziel wird nur dann als VULNERABLE gemeldet, nachdem es nachweist, dass es ein VSPC ConnectionHub ist (siehe unten), sodass ein stiller TCP-Dienst nicht mit einer ungepatchten Konsole verwechselt werden kann.

Was es auf einem Ziel hinterlässt

Pro Ziel öffnet das Tool zwei TCP-Verbindungen und sendet auf jeder einen ConnectionHub-Handshake, der einen Empfänger bf-probe-<uuid4> benennt, der nicht existieren wird.

Unter dem Standard---transport auto kostet ein Ziel, dessen Transport nicht der durch seinen Port implizierte ist, eine zusätzliche Verbindung: Die Sonde mit dem falschen Transport wird während des Handshakes abgelehnt, bevor ein Empfängername gelesen wird, und der richtige Transport wird dann für beide echten Sonden verwendet. Fixieren Sie --transport direct oder --transport gateway, um es bei genau zwei Verbindungen zu halten — sinnvoll, wenn Sie eine Verbindungsanzahl in einem Änderungsantrag angegeben haben.

Auf dem Server geänderter Zustand: keiner. Der Connector-Codepfad führt eine Wörterbuchsuche in ChannelHostProxy.m_multiplexers durch, findet nichts und gibt einen Fehler zurück. Es wird kein Empfänger registriert, kein Multiplexer oder Kanal erstellt, keine TLS-Sitzung ausgehandelt, kein Agenten-Datensatz berührt. Dieses Tool sendet nie einen Receiver-Typ-Handshake, derjenige wäre es, der einen Namen registrieren würde.

Logeinträge werden in %ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log geschrieben. Wörtlich von einem Live-9.2.1.33875-ConnectionHub, mit Zeitstempeln und Scope-JSON gekürzt:

Sonde 1 (Version 6), sowohl gepatchte als auch ungepatchte Builds:
    [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",...}

Sonde 2 (Version 7), nur gepatchte Builds:
    die gleichen drei Zeilen

Sonde 2 (Version 7), ungepatchte Builds:
    [INFO] ChannelHostProxy: Accept connection begin
    [WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
    [INFO] ChannelHostProxy: Accept connection end

Zwei Verbindungen, sechs Zeilen, keine weiteren Einträge und keine Zustandsänderung — bestätigt auf einem Live-Host.

Der wörtliche String bf-probe- in ConnectionHub.log identifiziert den Datenverkehr dieses Tools, sodass ein Verteidiger ihn zuordnen und ein Scan-Team nachweisen kann, was es gesendet hat. Ändern Sie RECEIVER_PREFIX im Quellcode, wenn Sie eine andere Markierung benötigen.

So funktioniert es

Der ConnectionHub-Management-Agenten-Router liest einen Client-Handshake vor jeder Authentifizierung oder TLS, und Request.Read validiert die vom Client beworbene Protokollversion gegen einen fest codierten Bereich. Der Fix erweiterte diesen Bereich im selben Build, der die CVEs behob:

Build	Prüfung	Akzeptiert
<= 9.2.1.33875 (verwundbar)	(uint)(versionByte - 3) <= 3	3, 4, 5, 6
>= 9.3.0.35057 (gepatcht)	(uint)(versionByte - 3) <= 4	3, 4, 5, 6, 7

Ein Handshake, der Version 7 bewirbt, ist also ein sauberer binärer Diskriminator. Der Detektor sendet zwei Sonden pro Ziel, in dieser Reihenfolge aus gutem Grund (die Transporterkennung kann eine dritte hinzufügen — siehe unten):

Sonde	Bewirbt	Zweck
1	Version 6	Muss Requested receiver not found zurückgeben, was beweist, dass das Ziel wirklich ein VSPC ConnectionHub ist
2	Version 7	Eine Antwort bedeutet PATCHED; Stille bedeutet VULNERABLE

Ohne das Stufe-1-Gate würde Stille in Sonde 2 auch zu jedem stillen TCP-Dienst im Internet passen, und Firewalls würden als verwundbare Veeam-Konsolen gemeldet.

Beide Transporte, pro Ziel erkannt

Es funktioniert über beide Pfade, die ein Management-Agent verwendet:

Transport	Port	Exposition
Direkt zum ConnectionHub	9999	normalerweise intern
Über ein Veeam Cloud Connect Gateway	6180	konstruktionsbedingt internetzugewandt

Der Gateway-Pfad benötigt einen Relay-Prolog, den der direkte Pfad nicht haben darf, daher dient Sonde 1 gleichzeitig als Transporterkennung. Unter dem Standard---transport auto versucht es einen Transport, und wenn das Fingerprint-Gate nicht besteht, den anderen. Welcher auch immer besteht, wird verriegelt, und Sonde 2 verwendet ihn erneut — eine gemischte Zieldatei benötigt keine Pro-Host-Annotation.

Die Verriegelung ist tragend. Wenn Sonde 2 auf dem anderen Transport erneut versuchen könnte, wäre Stille nicht mehr der Versionsprüfung zuzuschreiben, sondern nur noch „einer von zwei Byte-Pfaden hat nicht geantwortet", und genau so wird ein falsches VULNERABLE erzeugt.

Welcher Transport zuerst versucht wird, entscheidet der Port, und das ist nicht kosmetisch — die beiden Fehlanpassungen scheitern mit sehr unterschiedlicher Geschwindigkeit: