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) और CVE-2026-58067 (CVSS 8.7, बिना प्रमाणीकरण वाला मेमोरी-क्षय DoS) भी ठीक किए गए हैं। CVE-2026-58073 और CVE-2026-58072 को HackerOne के माध्यम से Veeam को रिपोर्ट किया गया था; सलाह में रिपोर्टर का नाम नहीं दिया गया है।
यह स्क्रिप्ट प्रतिरूपण का प्रयास नहीं करती, प्रमाणपत्र का अनुरोध नहीं करती, या फ़ाइल नहीं लिखती। यह राउटर के विज्ञापित प्रोटोकॉल जनरेशन को पढ़ती है और कुछ और नहीं।
हाँ। डिटेक्टर उत्पादन और मूल्यांकन उपयोग के लिए डिज़ाइन किया गया है:
Connector हैंडशेक भेजता है जो एक ऐसे रिसीवर का नाम देता है जो मौजूद नहीं होगा। कोई TLS सत्र बातचीत नहीं होती, कोई प्रमाणपत्र प्रस्तुत नहीं किया जाता, और कभी नहीं बुलाया जाता।SaveFilesChannelHostProxy.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 में लिखी जाती हैं। एक लाइव 9.2.1.33875 ConnectionHub से शब्दशः, टाइमस्टैम्प और स्कोप JSON के साथ छंटनी की गई:
probe 1 (version 6), both patched and unpatched 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",...}
probe 2 (version 7), patched builds only:
the same three lines
probe 2 (version 7), unpatched builds:
[INFO] ChannelHostProxy: Accept connection begin
[WARN] ChannelHostProxy: Handshake failed. Reason:Unsupported client version "7"
[INFO] ChannelHostProxy: Accept connection end
दो कनेक्शन, छह पंक्तियाँ, कोई अन्य प्रविष्टियाँ नहीं और कोई स्थिति परिवर्तन नहीं — एक लाइव होस्ट पर पुष्टि की गई।
ConnectionHub.log में शाब्दिक स्ट्रिंग bf-probe- इस उपकरण के ट्रैफ़िक की पहचान करती है, इसलिए एक रक्षक इसे आरोपित कर सकता है और एक स्कैनिंग टीम साबित कर सकती है कि उन्होंने क्या भेजा। यदि आपको एक अलग मार्कर की आवश्यकता है तो स्रोत में RECEIVER_PREFIX बदलें।
ConnectionHub प्रबंधन-एजेंट राउटर किसी भी प्रमाणीकरण या TLS से पहले एक क्लाइंट हैंडशेक पढ़ता है, और Request.Read क्लाइंट-विज्ञापित प्रोटोकॉल संस्करण को एक हार्डकोडेड सीमा के विरुद्ध मान्य करता है। फिक्स ने उस सीमा को उसी बिल्ड में चौड़ा किया जिसने CVEs को ठीक किया:
| Build | Check | Accepts |
|---|---|---|
<= 9.2.1.33875 (vulnerable) | (uint)(versionByte - 3) <= 3 | 3, 4, 5, 6 |
>= 9.3.0.35057 (patched) | (uint)(versionByte - 3) <= 4 | 3, 4, 5, 6, 7 |
इसलिए संस्करण 7 का विज्ञापन करने वाला एक हैंडशेक एक साफ बाइनरी विभेदक है। डिटेक्टर प्रति लक्ष्य दो प्रोब भेजता है, इस क्रम में एक कारण के लिए (ट्रांसपोर्ट पहचान एक तिहाई जोड़ सकती है — नीचे देखें):
| Probe | Advertises | Purpose |
|---|---|---|
| 1 | version 6 | Must return Requested receiver not found, proving the target really is a VSPC ConnectionHub |
| 2 | version 7 | A reply means PATCHED; silence means VULNERABLE |
स्टेज-वन गेट के बिना, प्रोब 2 में मौन इंटरनेट पर किसी भी शांत TCP सेवा से भी मेल खाता है, और फ़ायरवॉल को कमजोर Veeam कंसोल के रूप में रिपोर्ट किया जाएगा।
यह उन दोनों पथों पर काम करता है जो एक प्रबंधन एजेंट उपयोग करता है:
| Transport | Port | Exposure |
|---|---|---|
| Direct to the ConnectionHub | 9999 | usually internal |
| Through a Veeam Cloud Connect gateway | 6180 | internet-facing by design |
गेटवे पथ को एक रिले प्रस्तावना की आवश्यकता होती है जो प्रत्यक्ष पथ में नहीं होनी चाहिए, इसलिए प्रोब 1 ट्रांसपोर्ट पहचान के रूप में दोगुना हो जाता है। डिफ़ॉल्ट --transport auto के तहत यह एक ट्रांसपोर्ट आज़माता है, और यदि फिंगरप्रिंट गेट पास नहीं होता है, तो दूसरा आज़माता है। जो भी पास होता है उसे लैच किया जाता है, और प्रोब 2 इसे पुनः उपयोग करता है — एक मिश्रित लक्ष्य फ़ाइल को प्रति-होस्ट एनोटेशन की आवश्यकता नहीं होती।
लैच भार-वहन करने वाला है। यदि प्रोब 2 दूसरे ट्रांसपोर्ट पर पुनः प्रयास कर सकता है, तो मौन अब संस्करण जांच के लिए आरोपित नहीं होगा, केवल "दो बाइट पथों में से एक ने उत्तर नहीं दिया" के लिए, जो कि एक गलत VULNERABLE कैसे निर्मित होता है।
कौन सा ट्रांसपोर्ट पहले आज़माया जाता है यह पोर्ट द्वारा तय किया जाता है, और यह कॉस्मेटिक नहीं है — दो बेमेल बहुत अलग गति से विफल होते हैं:
| Mismatch | How the far end reads it | Cost |
|---|---|---|
| Relay prologue → direct hub | int16 meta of hostType 44 / versionByte 0, fails Request.Read's range check | disposed in one round trip |
| Direct handshake → gateway | int32 frame length of 1,012,729,346 | gateway waits for bytes that never arrive; burns the full timeout |
इसलिए auto उस सेवा के साथ आगे बढ़ता है जो पोर्ट की मालिक है: 6180 पर गेटवे पहले, बाकी सब जगह प्रत्यक्ष। यह सामान्य मामले को एकल प्रयास पर रखता है और महंगे बेमेल को तेज़ पथ से दूर रखता है। एक प्रोब जो TCP खोलने में बिल्कुल विफल रहता है, दूसरे ट्रांसपोर्ट की कोशिश किए बिना शॉर्ट-सर्किट हो जाता है, इसलिए एक विस्तृत स्वीप में मृत होस्ट एक टाइमआउट की लागत देते हैं, दो की नहीं।
VULNERABLE का अर्थ है "KB4893 फिक्स मौजूद नहीं हैं", "यह 9.2.1.33875 है" नहीं। 9.2.1 से पुराने बिल्ड समान संस्करण जांच साझा करते हैं, इसलिए उन्हें प्रोटोकॉल 6 रिपोर्ट करना चाहिए और कमजोर भी रिपोर्ट किया जाना चाहिए (कोड से अनुमानित, मापा नहीं — सीमाएँ देखें), लेकिन उपकरण 9.2.1 को 9.1 या 8.1 से अलग नहीं कर सकता। यदि आपको इसकी आवश्यकता है तो कंसोल UI में सटीक बिल्ड की पुष्टि करें।
# single host (default TCP/9999)
./cve_2026_58073_check.py vspc.example.com
# explicit port, several hosts
./cve_2026_58073_check.py vspc.example.com:9999 10.0.0.5
# scan a list, one target per line ('#' comments allowed), compact output
./cve_2026_58073_check.py -f targets.txt --brief
# machine-readable output for pipelines
./cve_2026_58073_check.py -f targets.txt --json > results.json
# a Veeam Cloud Connect gateway — the relay transport is detected automatically
./cve_2026_58073_check.py cc-gw.example.com:6180
# pin the transport to skip detection (port then defaults to 6180)
./cve_2026_58073_check.py --transport gateway cc-gw.example.com
# validate the wire codecs with no network access
./cve_2026_58073_check.py --self-test
| Flag | Description |
|---|---|
targets | One or more HOST[:PORT] (port defaults to 9999, or 6180 with --transport gateway) |
-f, --targets-file FILE | Read targets from a file (one per line; # comments) |
--transport {auto,direct,gateway} | How to reach the ConnectionHub. auto (default) detects it per target; gateway prepends the Cloud Connect relay prologue and defaults the port to 6180 |
-p, --port PORT | Override the default port |
--timeout SECS | Per-probe timeout (default: 8) |
--workers N | Concurrent targets (default: 16); output stays in input order |
-b, --brief | Single aligned line per target — ideal for scanning many hosts |
--json | Emit structured JSON, including every probe sent per target |
--no-color | Disable coloured output (also honours NO_COLOR and non-TTY) |
--self-test | Validate the .NET wire codecs and exit; no network access |
एक अनपैच्ड कंसोल (डिफ़ॉल्ट दो-पंक्ति आउटपुट)। [!] मार्कर और VULNERABLE TTY पर लाल रेंडर होते हैं:
$ ./cve_2026_58073_check.py vspc.example.com
[!] vspc.example.com:9999: VULNERABLE [protocol-7-rejected]
ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)
एक पैच्ड कंसोल:
$ ./cve_2026_58073_check.py patched.example.com
[+] patched.example.com:9999: PATCHED [protocol-7-accepted]
ConnectionHub accepts protocol 7, so the KB4893 fixes are present (>= 9.3.0.35057)
एक गेटवे लक्ष्य, रिले ट्रांसपोर्ट स्वतः पहचाना गया। (gateway) प्रत्यय उस ट्रांसपोर्ट का नाम देता है जिस पर निर्णय पहुंचा गया था:
$ ./cve_2026_58073_check.py cc-gw.example.com:6180
[!] cc-gw.example.com:6180 (gateway): VULNERABLE [protocol-7-rejected]
ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)
एक संपत्ति की स्वीपिंग, प्रति होस्ट एक संरेखित पंक्ति (--brief)। निकास स्थिति 1 है यदि कोई होस्ट VULNERABLE है, अन्यथा 0 — स्क्रिप्ट में उपयोगी:
$ ./cve_2026_58073_check.py -f targets.txt --brief; echo "exit: $?"
VULNERABLE vspc.example.com:9999 protocol-7-rejected
PATCHED patched.example.com:9999 protocol-7-accepted
UNAFFECTED fileserver.example.com:9999 not-vspc
ERROR unused.example.com:9999 unreachable
exit: 1
पाइपलाइनों के लिए मशीन-पठनीय आउटपुट (--json)। प्रत्येक प्रोब प्रति लक्ष्य शामिल है, इसलिए एक निष्कर्ष को साक्ष्य से पुनः प्राप्त किया जा सकता है बजाय भरोसा करने के। transport वह है जिस पर निर्णय पहुंचा गया था, और प्रत्येक प्रोब अपने उपयोग किए गए ट्रांसपोर्ट को ले जाता है — इसलिए एक स्वतः-पहचाना गया लक्ष्य अस्वीकृत प्रयास भी दिखाता है:
$ ./cve_2026_58073_check.py vspc.example.com --json
[
{
"target": "vspc.example.com:9999",
"host": "vspc.example.com",
"port": 9999,
"transport": "direct",
"verdict": "VULNERABLE",
"reason": "protocol-7-rejected",
"detail": "ConnectionHub rejects protocol 7 but accepts 6, so the KB4893 fixes are absent (<= 9.2.1.33875)",
"protocol_version": 6,
"affected_cves": [
"CVE-2026-58073",
"CVE-2026-58072",
"CVE-2026-58071",
"CVE-2026-58067"
],
"probes": [
{
"version_byte": 6,
"transport": "direct",
"connected": true,
"responded": true,
"status": "Error",
"message": "Cannot connect transmitter. Requested receiver not found (receiver name:bf-probe-b7c40be0-e2e8-41dc-9fc3-cbbd7345954a)",
"error": ""
},
{
"version_byte": 7,
"transport": "direct",
"connected": true,
"responded": false,
"status": "",
"message": "",
"error": ""
}
]
}
]
| Verdict | Reason tag | Meaning |
|---|---|---|
VULNERABLE | protocol-7-rejected | Confirmed VSPC ConnectionHub that accepts protocol 6 and rejects 7. The KB4893 fixes are absent (<= 9.2.1.33875). |
PATCHED | protocol-7-accepted | Confirmed VSPC ConnectionHub that accepts protocol 7. The KB4893 fixes are present (>= 9.3.0.35057). |
UNAFFECTED | not-vspc | Accepted TCP but did not answer a valid ConnectionHub handshake on any transport tried, so it is not a VSPC ConnectionHub. |
INCONCLUSIVE | unexpected-reply | Answered the fingerprint probe with something other than Requested receiver not found. |
INCONCLUSIVE | inconclusive-discriminator | Passed the fingerprint gate, then answered the version-7 probe in a way that is neither a pass nor a fail — or that second connection failed outright. Retry. |
ERROR | unreachable | Could not connect, or the Cloud Connect gateway refused the relay prologue on the first transport tried (which under auto means any target on port 6180). |
| Code | Meaning |
|---|---|
0 | No target was VULNERABLE |
1 | At least one target is VULNERABLE |
2 | Usage error (bad arguments / unreadable targets file) |
--transport auto के गेटवे चरण पर भी लागू होता है; अप्रयुक्त पथ को स्वीप से पूरी तरह दूर रखने के लिए --transport direct पिन करें।VULNERABLE निर्णय पैच स्थिति की बात करता है, न कि किसी ने कंसोल का शोषण किया या नहीं। शोषण पैच्ड और अनपैच्ड दोनों बिल्ड पर कंसोल के लॉग में अपने स्वयं के निशान छोड़ता है; उन्हें अलग से खोजें।Veeam Service Provider Console 9.3.0.35057 या बाद में अपग्रेड करें (KB4893)। सभी चार मुद्दे उस एक बिल्ड में ठीक किए गए हैं, और कोई 9.2.x बैकपोर्ट नहीं है, इसलिए उपचार एक हॉटफिक्स के बजाय एक संस्करण अपग्रेड है।
दो चीजें जो अपग्रेड नहीं करता। यह प्रतिबंधित नहीं करता कि TCP/9999 तक कौन पहुंच सकता है, जिसे केवल उन सबनेट्स का उत्तर देना चाहिए जिनमें आपके प्रबंधन एजेंट रहते हैं। और यह एक एजेंट प्रमाणपत्र को रद्द नहीं करता जो कंसोल ने पहले ही जारी किया है, जिसमें एक हमलावर को जारी किया गया प्रमाणपत्र भी शामिल है जबकि यह अनपैच्ड था। यदि आपको शोषण के साक्ष्य मिलते हैं, तो समझौता किए गए एजेंट प्रमाणपत्रों पर मार्गदर्शन के लिए एक Veeam सपोर्ट केस खोलें: उन्हें घुमाना एक प्रलेखित प्रक्रिया नहीं है, और पोर्टल में आप जिन प्रमाणपत्रों का प्रबंधन कर सकते हैं वे वह CA नहीं हैं जो एजेंट प्रमाणपत्रों पर हस्ताक्षर करता है।
यह कोड MIT लाइसेंस के तहत वितरित किया गया है।
पूर्व पारस्परिक सहमति के बिना लक्ष्यों पर हमला करने के लिए इस उपकरण का उपयोग अवैध है। सभी लागू स्थानीय, राज्य और संघीय कानूनों का पालन करना अंतिम उपयोगकर्ता की जिम्मेदारी है। डेवलपर्स कोई दायित्व नहीं मानते हैं और इस प्रोग्राम के किसी भी दुरुपयोग या क्षति के लिए जिम्मेदार नहीं हैं।