bishopfox/cve-2026-58073-checkБезопасное обнаружение обхода аутентификации Veeam Service Provider Console CVE-2026-58073
Безопасный детектор без аутентификации для уязвимостей KB4893 в Veeam Service Provider Console (опубликовано 2026-08-04). Он отвечает на один вопрос по каждой цели, до любой аутентификации или TLS: присутствуют ли исправления KB4893 на этой консоли?
Основная пара — это цепочка. CVE-2026-58073 (CVSS 9.5) позволяет неаутентифицированному сетевому пиру имитировать подключённого агента управления и получить реальный сертификат этого агента, поскольку квитирование агента определяет авторизацию по GUID, который пир записал в свой собственный сертификат. CVE-2026-58072 (CVSS 9.0) — это произвольная запись файла, доступная после получения идентичности агента. В связке это неаутентифицированное удалённое выполнение кода на консоли, которая управляет резервными копиями каждого арендатора. То же уведомление также исправляет CVE-2026-58071 (CVSS 8.2, проксируемый API устройства как Portal Administrator) и CVE-2026-58067 (CVSS 8.7, неаутентифицированный DoS через истощение памяти). CVE-2026-58073 и CVE-2026-58072 были сообщены в Veeam через HackerOne; уведомление не называет автора сообщения.
Этот скрипт не пытается выполнить имитацию, запросить сертификат или записать файл. Он читает рекламируемое поколение протокола маршрутизатора и ничего больше.
Да. Детектор предназначен для использования в производстве и при оценке:
Connector, называющее приёмник, который не будет существовать. Никакой TLS-сеанс не
устанавливается, сертификат не предоставляется, и SaveFiles никогда не вызывается.ChannelHostProxy.m_multiplexers. Приёмник не регистрируется, канал или мультиплексор не создаётся,
запись агента не затрагивается. Квитирование типа Receiver зарегистрировало бы имя; этот инструмент
никогда его не отправляет.ConnectionHub.log, каждая с именем приёмника bf-probe-<uuid4>, чтобы защитник мог отличить сканирование
от атаки. Точные строки приведены ниже.VULNERABLE только после того, как она докажет,
что является VSPC ConnectionHub (см. ниже), поэтому тихий TCP-сервис не может быть ошибочно принят за
незапатченную консоль.На каждую цель инструмент открывает два TCP-соединения и отправляет одно квитирование ConnectionHub на
каждом, называя приёмник bf-probe-<uuid4>, который не будет существовать.
При транспорте по умолчанию --transport auto цель, чей транспорт не соответствует её порту, стоит одного
дополнительного соединения: зонд с неправильным транспортом отклоняется во время квитирования, до чтения
имени приёмника, и затем правильный транспорт используется для обоих реальных зондов. Зафиксируйте
--transport direct или --transport gateway, чтобы ограничиться ровно двумя соединениями — это стоит
сделать, если вы указали количество соединений в запросе на изменение.
Изменение состояния на сервере: нет. Путь кода Connector выполняет поиск по словарю в
ChannelHostProxy.m_multiplexers, не находит совпадения и возвращает ошибку. Приёмник не регистрируется,
мультиплексор или канал не создаётся, TLS-сеанс не устанавливается, запись агента не затрагивается. Этот
инструмент никогда не отправляет квитирование типа Receiver — именно оно зарегистрировало бы имя.
Записи журнала записываются в
%ProgramData%\Veeam\Veeam Availability Console\Log\Server\ConnectionHub.log. Дословно с живого
ConnectionHub 9.2.1.33875, с обрезанными временными метками и JSON области действия:
зонд 1 (версия 6), и запатченные, и незапатченные сборки:
[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",...}
зонд 2 (версия 7), только запатченные сборки:
те же три строки
зонд 2 (версия 7), незапатченные сборки:
[INFO] ChannelHostProxy: Accept connection begin
[WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
[INFO] ChannelHostProxy: Accept connection end
Два соединения, шесть строк, никаких других записей и никакого изменения состояния — подтверждено на живом хосте.
Литеральная строка bf-probe- в ConnectionHub.log идентифицирует трафик этого инструмента, поэтому
защитник может его атрибутировать, а команда сканирования — доказать, что она отправила. Измените
RECEIVER_PREFIX в исходном коде, если вам нужен другой маркер.
Маршрутизатор агентов управления ConnectionHub читает квитирование клиента до любой аутентификации или TLS,
и Request.Read проверяет рекламируемую клиентом версию протокола на соответствие жёстко заданному диапазону.
Исправление расширило этот диапазон в той же сборке, которая исправила CVE:
| Сборка | Проверка | Принимает |
|---|---|---|
<= 9.2.1.33875 (уязвимая) | (uint)(versionByte - 3) <= 3 | 3, 4, 5, 6 |
>= 9.3.0.35057 (запатченная) | (uint)(versionByte - 3) <= 4 | 3, 4, 5, 6, 7 |
Таким образом, квитирование с рекламой версии 7 — это чистый бинарный дискриминатор. Детектор отправляет два зонда на цель в этом порядке не случайно (обнаружение транспорта может добавить третий — см. ниже):
| Зонд | Рекламирует | Назначение |
|---|---|---|
| 1 | версия 6 | Должен вернуть Requested receiver not found, доказывая, что цель действительно является VSPC ConnectionHub |
| 2 | версия 7 | Ответ означает PATCHED; тишина означает VULNERABLE |
Без шлюза первого этапа тишина в зонде 2 также соответствует любому тихому TCP-сервису в интернете, и брандмауэры сообщались бы как уязвимые консоли Veeam.
Он работает по обоим путям, которые использует агент управления:
| Транспорт | Порт | Доступность |
|---|---|---|
| Напрямую к ConnectionHub | 9999 | обычно внутренний |
| Через шлюз Veeam Cloud Connect | 6180 | интернет-ориентированный по замыслу |
Путь через шлюз требует пролога ретрансляции, которого не должно быть на прямом пути, поэтому зонд 1
дополнительно выполняет обнаружение транспорта. При транспорте по умолчанию --transport auto он пробует
один транспорт, и если шлюз отпечатка не проходит, пробует другой. Тот, который проходит, фиксируется,
и зонд 2 использует его повторно — смешанный файл целей не требует аннотации для каждого хоста.
Фиксация критически важна. Если бы зонд 2 мог повторить попытку на другом транспорте, тишина больше не была
бы связана с проверкой версии, а только с «один из двух байтовых путей не ответил» — именно так создаётся
ложное VULNERABLE.
Какой транспорт пробуется первым, определяется портом, и это не косметика — два несоответствия завершаются с очень разной скоростью:
| Несоответствие | Как это читает удалённая сторона | Стоимость |
|---|---|---|
| Пролог ретрансляции → прямой хаб | int16 метаданных hostType 44 / versionByte 0, не проходит проверку диапазона Request.Read | закрывается за один цикл обмена |
| Прямое квитирование → шлюз | int32 длина кадра 1,012,729,346 | шлюз ждёт байты, которые никогда не приходят; сжигает полный таймаут |