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 सत्र बातचीत नहीं होती, कोई प्रमाणपत्र प्रस्तुत नहीं किया जाता, और 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 में लिखी जाती हैं। एक लाइव 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 खोलने में बिल्कुल विफल रहता है, दूसरे ट्रांसपोर्ट की कोशिश किए बिना शॉर्ट-सर्किट हो जाता है, इसलिए एक विस्तृत स्वीप में मृत होस्ट एक टाइमआउट की लागत देते हैं, दो की नहीं।