विंडोज 10 पर कमजोर सिफर हटाने से निवर्तमान आरडीपी टूट जाता है

Question

Windows 10 मशीन RDP चलाने के कारण TrustWave की भेद्यता स्कैनर स्कैन विफल हो जाता है:

64 बिट्स (जैसे डीईएस और 3 डीईएस) के ब्लॉक साइज के साथ ब्लॉक सिफर एल्गोरिदम जन्मदिन का हमला जिसे स्वीट 32 (सीवीई -20161818) के नाम से जाना जाता है

नोट: RDP (रिमोट डेस्कटॉप प्रोटोकॉल) चलाने वाले विंडोज 7/10 सिस्टम पर, निष्क्रिय साइफर को निष्क्रिय किया जाना चाहिए जिसे 'TLS_RSA_WITH_3DES_EDE_CBC_SHA' लेबल किया जाता है।

IIS क्रिप्टो (नार्टैक द्वारा) का उपयोग करते हुए, मैंने "बेस्ट प्रैक्टिस" टेम्पलेट के साथ-साथ पीसीआईघड़ी 3.1 टेम्प्लेट को लागू करने की कोशिश की, हालांकि दोनों में असुरक्षित सिफर (TLS_RSA_WITH_3DES_ED_CBC_SHA) शामिल हैं:

यदि मैं यह सिफर, आरडीपी को निष्क्रिय से कार्य करना बंद कर कई विंडोज स्टेशनों के लिए इस कंप्यूटर (यह अभी भी कुछ 2008 R2 और 2012 R2 सर्वर के लिए काम करता है)। RDP क्लाइंट बस देता है, "एक आंतरिक त्रुटि हुई है" और ईवेंट लॉग:

TLS क्लाइंट क्रेडेंशियल बनाते समय एक घातक त्रुटि हुई। आंतरिक त्रुटि स्थिति 10013 है।

मैंने किसी एक सर्वर के सर्वर इवेंट लॉग की जाँच की और इन दो संदेशों को देखा

दूरस्थ क्लाइंट अनुप्रयोग से TLS 1.2 कनेक्शन अनुरोध प्राप्त हुआ था, लेकिन क्लाइंट अनुप्रयोग द्वारा समर्थित कोई भी सिफर सर्वर द्वारा समर्थित नहीं है। SSL कनेक्शन अनुरोध विफल हो गया है।

निम्नलिखित घातक चेतावनी उत्पन्न हुई थी: 40. आंतरिक त्रुटि स्थिति 1205 है।

मैं निवर्तमान आरडीपी को तोड़ने के बिना सुरक्षा भेद्यता को कैसे ठीक कर सकता हूं?

या, यदि उपरोक्त संभव नहीं है, तो क्या ऐसा कुछ है जो मैं प्रत्येक आरडीपी होस्ट पर कर सकता हूं जिसे मैं अब उस से कनेक्ट नहीं कर सकता जो इसे उस छोर पर संभालता है?

--- अपडेट # 1 ---

Windows 10 मशीन पर TLS_RSA_WITH_3DES_EDE_CBC_SHA को अक्षम करने के बाद, मैंने कई RDP होस्ट्स से कनेक्ट करने की कोशिश की (उनमें से आधे "एक आंतरिक त्रुटि ..." के साथ विफल रहे)। इसलिए मैंने इनमें से एक मेजबानों की तुलना की जिसे मैं उस एक के खिलाफ कनेक्ट कर सकता हूं जिसे मैं कनेक्ट नहीं कर सकता । दोनों 2008 R2 हैं। दोनों का एक ही आरडीपी संस्करण है (6.3.9600, आरडीपी प्रोटोकॉल 8.1 समर्थित)।

मैंने अपनी वर्तमान सेटिंग्स पर "टेम्पलेट सहेजें" करने के लिए IIS क्रिप्टो का उपयोग करके TLS प्रोटोकॉल और सिफर्स की तुलना की ताकि मैं टेम्पलेट फ़ाइलों की तुलना कर सकूं। वे समान थे! इसलिए जो भी मुद्दा है वह मेजबान पर एक लापता चिपर सूट की बात नहीं लगता है। यहाँ फाइलों से परे एक स्क्रीन शॉट है:

दो RDP होस्ट्स के बीच क्या अंतर हो सकता है जो इस मुद्दे का कारण बनता है और इसे कैसे ठीक किया जाए?

Comments

क्या आप क्लाइंट हेलो / सर्वर हैलो को कैप्चर करने के लिए नेटमन या विरेशर का उपयोग कर सकते हैं ताकि यह देखा जा सके कि कनेक्शन विफल होने पर वास्तव में क्या सिफर सूट हो रहा है, बनाम जब यह सफल होता है?

— रियान रिविस

@RyanRies: पहले से ही किया था, लेकिन यह कभी भी वास्तविक TLS हैंडशेक के लिए नहीं मिलता है। क्लाइंट एक "टीपीकेटी, कंटीन्यूएशन" पैकेज भेजता है और सर्वर "आरएसटी, एसीके" के साथ प्रतिक्रिया करता है।

— ज़ेक

Answer 1

IIS क्रिप्टो में सर्वर साइड (इनकमिंग) और क्लाइंट साइड (आउटगोइंग) दोनों विकल्प सेट करने का विकल्प है। वहाँ मुट्ठी भर सिफर्स हैं जिन्हें आपको अनुकूलता के लिए क्लाइंट साइड पर सक्षम छोड़ने की आवश्यकता है।

आप जो चाहते हैं वह करने के लिए मैं व्यक्तिगत रूप से निम्नलिखित के साथ जाऊंगा:

• 3.1 टेम्पलेट लागू करें
• सक्षम सभी सिफर स्वीट्स छोड़ दें
• क्लाइंट और सर्वर (चेकबॉक्स टिकटिक) दोनों पर लागू करें।
• परिवर्तनों को सहेजने के लिए 'लागू करें' पर क्लिक करें

यहां वांछित होने पर रिबूट करें (और आपके पास मशीन तक भौतिक पहुंच है)।

• 3.1 टेम्पलेट लागू करें
• सक्षम सभी सिफर स्वीट्स छोड़ दें
• सर्वर पर लागू करें (चेकबॉक्स अछूता)।
• 3DES विकल्प को अनचेक करें

यहां रिबूट का परिणाम सही अंत स्थिति में होना चाहिए।

प्रभावी रूप से आप केवल 3DES इनबाउंड को अक्षम करना चाहते हैं, लेकिन फिर भी उक्त सिफर सूट के आउटबाउंड उपयोग की अनुमति देते हैं।

Comments

यह आशाजनक लगता है! हालाँकि 3DES 168 को अक्षम करना एक गलती थी - मैं अब इससे नहीं जुड़ सकता। एक बार जब मैंने यह संभाला है, तो मैं केवल सर्वर-साइड पर सिफर को अक्षम करने का प्रयास करूंगा और वापस रिपोर्ट / उत्तर को स्वीकार करूंगा।

— ज़ेक

मैंने आपके सुझाव की कोशिश की: 1) "बेस्ट प्रैक्टिस" लागू करें और सर्वर और क्लाइंट दोनों पर लागू करें, फिर 2) TLS_RSA_WITH_3DES_EDE_CBC_SHA सिफर और "क्लाइंट साइड क्लाइंट सेट करें" को अनचेक करें और फिर से रिबूट करें। इस मशीन से RDPing समस्या अभी भी बनी हुई है। अतिरिक्त सुझावों का स्वागत है।

— ज़ेक

@ अजीब अजीब ... मैं एक ही तकनीक का इस्तेमाल किया है और यह काम किया है।

— टिम ब्रिघम

@ ज़ेक मुझे एहसास हुआ कि मैंने एक बड़ी गलती की है कि मैंने इसे कैसे लिखा। मैं उसी के अनुसार अपडेट करूंगा।

— टिम ब्रिघम

मैंने यह कोशिश की। 1) 3.1 टेम्प्लेट का चयन करें + सभी सिफर सुइट्स को छोड़ दें जैसे कि + "क्लाइंट साइड प्रोटोकॉल सेट करें" सक्षम + टीएलएस 1.0 की जांच करें (एसक्यूएल, आदि ब्रेक डब्ल्यू / ओ टीएलएस 1.0) + लागू करें और रिबूट करें। 2) 3.1 टेम्प्लेट का चयन करें + सभी सिफर सुइट्स को छोड़ दें जैसे कि + "क्लाइंट साइड प्रोटोकॉल सेट करें" अनियंत्रित + 3DES अनचेक करें और TLS 1.0 जांचें + लागू करें और रिबूट करें। मैं अब कनेक्ट नहीं कर सकता, "एक आंतरिक त्रुटि हुई है" (मुझे लगता है कि सर्वर को 3DES का समर्थन करना चाहिए)। मैं विंडोज 10 मशीन से कनेक्ट कर रहा हूं।

— ज़िक

Answer 2

मैं एक ही मुद्दा था, सर्वर पर KB3080079 पैच स्थापित करने से tls 1.1 और 1.2 के लिए समर्थन सक्षम हो जाता है।

ध्यान दें कि विंडोज़ 7 क्लाइंट के लिए आपको आरडीपी क्लाइंट अपडेट (KB2830477) इंस्टॉल करना होगा, अन्यथा केवल विंडोज़ 8+ कनेक्ट करने में सक्षम होंगे।

Comments

मैंने अभी-अभी डबल चेक किया और वे अपडेट पहले से इंस्टॉल हैं (मेरा मानना ​​है कि उन्हें कुछ समय के लिए पहले ही मानक विंडोज अपडेट में शामिल किया गया है), इसलिए यह मुद्दा नहीं है।

— ज़ेक

Answer 3

संपादित करें (2018-09-26): मैंने पाया है कि 2012R2 पर 3DES को अक्षम करना RDP को नहीं तोड़ता है लेकिन यह 2008 R2 को टूटता है। समर्थित विकल्प कर्नेल के बीच भिन्न होते हैं।

---

मैं अपना जवाब एक TechNet थ्रेड से साझा करूंगा लेकिन पहले BLUF:

सर्वरफॉल्ट निष्कर्ष: सबसे अधिक संभावना है कि आपके पास सिस्टम के बीच कुछ अन्य अंतर है। आप अलग-अलग OS संस्करणों के बीच कनेक्ट कर रहे हैं, एक सिस्टम में FIPS सक्षम है और दूसरा नहीं है, या आपके पास अलग-अलग सिफर प्रतिबंध हैं HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers। मैं निश्चित रूप से उस सिस्टम पर SCHANNEL लॉगिंग को सक्षम करूंगा जो यह निर्धारित करने के लिए काम करता है कि कौन सा सिफर उपयोग में है। अगर आप किसी तरह आरडीपी को वैकल्पिक सिफर के साथ काम करने के लिए वापस सुनना पसंद करेंगे।

पोस्ट की कॉपी:

हम इसे काम करने के लिए मिल गया!

स्पष्ट रूप से 2008 और 2012 में वाक्यविन्यास मुद्दे हैं और 2008/7 के लिए एक अनुगामी / 168 की आवश्यकता है। 2012 / 8.1 / 10 नहीं है।

2008 की कुंजी इस प्रकार है: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

और 2012 की कुंजी इस प्रकार है: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

मैं पुष्टि कर सकता हूं कि "ट्रिपल डेस 168/168" का उपयोग सिस्टम पर 3DES को अक्षम नहीं करता है। आप इसे प्रोटोकॉल स्कैनर (जैसे नेसस) या SCHANNEL लॉगिंग को सक्षम करके खुद को साबित कर सकते हैं:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007

फिर आपके पास उदाहरण के लिए सिस्टम लॉग में घटनाएँ होंगी;

एक SSL क्लाइंट हैंडशेक सफलतापूर्वक पूरा हुआ। बातचीत की गई क्रिप्टोग्राफ़िक पैरामीटर निम्नानुसार हैं।

प्रोटोकॉल: टीएलएस 1.0 सिफरसुइट: 0x2f एक्सचेंज ताकत: 1024

मेरे लिए परिणाम 0xa है जो Google TLS_RSA_WITH_3DES_EDE_CBC_SHA के रूप में प्रकट होता है।

जब मैं "ट्रिपल डेस 168" (/ 168 के बिना) का उपयोग करता हूं, तो सिस्टम इवेंट आईडी 36880 दिखाई नहीं देता है और आरडीपी सत्र अवरुद्ध है।

प्रति लेख: सिस्टम क्रिप्टोग्राफी: एन्क्रिप्शन, हैशिंग और साइनिंग के लिए FIPS अनुपालन एल्गोरिदम का उपयोग करें

दूरस्थ डेस्कटॉप सेवा (RDS) दूरस्थ डेस्कटॉप सेवा नेटवर्क संचार को एन्क्रिप्ट करने के लिए, यह नीति सेटिंग केवल ट्रिपल डेस एन्क्रिप्शन एल्गोरिथ्म का समर्थन करती है।

प्रति लेख: "सिस्टम क्रिप्टोग्राफ़ी: एन्क्रिप्शन, हैशिंग और साइनिंग के लिए FIPS अनुपालन एल्गोरिदम का उपयोग करें" सुरक्षा सेटिंग प्रभाव विंडोज़ एक्सपी और विंडोज के बाद के संस्करणों में।

यह सेटिंग Windows Server 2003 और Windows के बाद के संस्करणों में टर्मिनल सेवाओं को भी प्रभावित करती है। प्रभाव इस बात पर निर्भर करता है कि सर्वर प्रमाणीकरण के लिए टीएलएस का उपयोग किया जा रहा है या नहीं।

यदि सर्वर प्रमाणीकरण के लिए TLS का उपयोग किया जा रहा है, तो यह सेटिंग केवल TLS 1.0 का उपयोग करती है।

डिफ़ॉल्ट रूप से, यदि TLS का उपयोग नहीं किया जा रहा है, और यह सेटिंग क्लाइंट या सर्वर पर सक्षम नहीं है, तो सर्वर और क्लाइंट के बीच रिमोट डेस्कटॉप प्रोटोकॉल (RDP) चैनल RC4 एल्गोरिथ्म का 128-बिट के साथ उपयोग करके एन्क्रिप्ट किया गया है कुंजी लंबाई। जब आप इस सेटिंग को Windows Server 2003-आधारित कंप्यूटर पर सक्षम करते हैं, तो निम्न सत्य होता है: RDP चैनल को 168-बिट कुंजी लंबाई के साथ सिफर ब्लॉक चेनिंग (CBC) मोड में 3DES एल्गोरिथ्म का उपयोग करके एन्क्रिप्ट किया गया है। SHA-1 एल्गोरिथ्म का उपयोग संदेश डाइजेस्ट बनाने के लिए किया जाता है। ग्राहकों को कनेक्ट करने के लिए RDP 5.2 क्लाइंट प्रोग्राम या बाद के संस्करण का उपयोग करना चाहिए।

तो ये दोनों इस विचार का समर्थन करते हैं कि RDP केवल 3DES का उपयोग कर सकता है। हालाँकि, यह आलेख बताता है कि सिफर्स की एक बड़ी रेंज उपलब्ध है: FIPS 140 सत्यापन

क्रिप्टोग्राफ़िक एल्गोरिदम का सेट जो एक दूरस्थ डेस्कटॉप प्रोटोकॉल (RDP) सर्वर का उपयोग करेगा: - CALG_RSA_KEYX - RSA सार्वजनिक कुंजी विनिमय एल्गोरिथ्म - CALG_3DES - ट्रिपल डेस एन्क्रिप्शन एल्गोरिथ्म - CALG_AES_128 - 128 बिट एईएस - CALG_AES_256 - 256 बिट AES - CALG_R SHA हैशिंग एल्गोरिथ्म - CALG_SHA_256 - 256 बिट SHA हैशिंग एल्गोरिथ्म - CALG_SHA_384 - 384 बिट SHA हैशिंग एल्गोरिथ्म - CALG_SHA_512 - 512 बिट SHA हैशिंग एल्गोरिथ्म

अंततः यह स्पष्ट नहीं है कि RDP गैर-3DES प्रोटोकॉल का समर्थन कर सकता है जब FIPS मोड सक्षम किया गया है, लेकिन सबूत यह सुझाव देगा कि नहीं।

मुझे कोई सबूत नहीं है कि Server 2012 R2 सर्वर 2008 R2 से अलग तरीके से कार्य करेगा, लेकिन ऐसा लगता है कि Server 2008 R2 लगभग 140-1 अनुपालन के सर्वर पर आधारित था और Server 2012 R2, 140 140 FIPS का अनुसरण करता है, इसलिए यह पूरी तरह से संभव है कि सर्वर 2012 R2 समर्थन करता है अतिरिक्त प्रोटोकॉल। आप FIPS 140 सत्यापन लिंक में अतिरिक्त प्रोटोकॉल नोट करेंगे ।

निष्कर्ष में: मुझे नहीं लगता कि सर्वर 2008 R2 3DES अक्षम के साथ RDP को दान मोड में समर्थन कर सकता है। मेरी अनुशंसा यह पता लगाने के लिए है कि क्या आपका सिस्टम एक SWEET32 हमले (एक सत्र में 768GB से अधिक) और 3 डी को अक्षम करने के लिए आरडीपी क्षमता को हटाने के लायक है या नहीं। अन्य उपयोगिताओं RDP से परे सर्वरों को प्रबंधित करने के लिए विशेष रूप से एक ऐसी दुनिया में मौजूद हैं जहां वर्चुअलाइजेशन अत्यधिक सामान्य है।

Answer 4

स्पष्ट रूप से 2008 और 2012 में वाक्यविन्यास मुद्दे हैं और 2008/7 के लिए एक अनुगामी / 168 की आवश्यकता है। 2012 / 8.1 / 10 नहीं है।

2008 की कुंजी इस तरह दिखती है: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** बहुत अच्छा लगता है कि मैं कुछ विंडोज़ 2008 आर 2 डोमेन नियंत्रकों पर सटीक एक ही मुद्दा था, अजीब तरह से मेरे सदस्य 2008 आर 2 सर्वर ठीक लगते हैं ... और मेरे 2012 आर 2 सर्वर भी ठीक काम करते हैं। उन पुराने डीसी के डिकोमिंग पर दरार करने की आवश्यकता है :)

Comments

2008R2 सेटिंग के मेरे संस्करण 168में विंडोज 2012 रजिस्ट्री के समान सिंटैक्स को जोड़ने और स्वीकार करने की आवश्यकता नहीं है । सिर्फ FYI करें अगर 2008 में रजिस्ट्री सेटिंग आपके लिए काम नहीं करती थी

— ग्रेगरी सुवेलियन