การเอารหัสลับที่มีช่องโหว่ใน Windows 10 ทำให้ RDP ขาออกไม่ทำงาน

โปรแกรมสแกนช่องโหว่ของ TrustWave ไม่สามารถสแกนได้เนื่องจากเครื่อง Windows 10 ที่รัน RDP:

บล็อกอัลกอริธึมเข้ารหัสที่มีขนาดบล็อก 64 บิต (เช่น DES และ 3DES) การโจมตีวันเกิดที่รู้จักกันในชื่อ Sweet32 (CVE-2016-2183)

หมายเหตุ: ในระบบ Windows 7/10 ที่รัน RDP (Remote Desktop Protocol) รหัสตัวเลขที่มีช่องโหว่ที่ควรปิดการใช้งานจะมีป้ายกำกับว่า 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'

การใช้ IIS Crypto (โดย Nartac) ฉันลองใช้เทมเพลต "Best Practices" รวมถึงเท็มเพลต PCI 3.1 อย่างไรก็ตามทั้งคู่มีการเข้ารหัสที่ไม่ปลอดภัย (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

หากฉันปิดการใช้งานรหัสนี้ RDP จากคอมพิวเตอร์เครื่องนี้ไปยังสถานี Windows หลายแห่งหยุดทำงาน (ยังคงใช้ได้กับเซิร์ฟเวอร์ 2008 R2 และ 2012 R2 บางเครื่อง) ไคลเอนต์ RDP เพียงให้ "เกิดข้อผิดพลาดภายใน" และบันทึกเหตุการณ์:

เกิดข้อผิดพลาดร้ายแรงขณะสร้างข้อมูลรับรองไคลเอ็นต์ TLS สถานะข้อผิดพลาดภายในคือ 10013

ฉันตรวจสอบบันทึกเหตุการณ์เซิร์ฟเวอร์ของหนึ่งในเซิร์ฟเวอร์และดูข้อความทั้งสองนี้

ได้รับการร้องขอการเชื่อมต่อ TLS 1.2 จากแอปพลิเคชันไคลเอนต์ระยะไกล แต่ไม่มีการสนับสนุนชุดเข้ารหัสที่รองรับโดยแอปพลิเคชันไคลเอนต์ไคลเอนต์ คำขอเชื่อมต่อ SSL ล้มเหลว

สร้างการแจ้งเตือนที่ร้ายแรงต่อไปนี้: 40. สถานะข้อผิดพลาดภายในคือ 1205

ฉันจะแก้ไขช่องโหว่ความปลอดภัยโดยไม่ทำลาย RDP ขาออกได้อย่างไร

หรือถ้าเป็นไปไม่ได้มีบางอย่างที่ฉันสามารถทำได้ในแต่ละโฮสต์ RDP ที่ฉันไม่สามารถเชื่อมต่อกับที่จัดการมันในปลายนั้นได้หรือไม่?

--- อัปเดต # 1 ---

หลังจากปิดใช้งาน TLS_RSA_WITH_3DES_EDE_CBC_SHA บนเครื่อง Windows 10 ฉันพยายามเชื่อมต่อกับโฮสต์ RDP หลายแห่ง (ครึ่งหนึ่งของพวกเขาล้มเหลวด้วย "ข้อผิดพลาดภายใน ... ") ดังนั้นฉันจึงเปรียบเทียบหนึ่งในโฮสต์เหล่านี้ที่ฉันสามารถเชื่อมต่อกับโฮสต์ที่ฉันไม่สามารถเชื่อมต่อได้ ทั้งคู่เป็น 2008 R2 ทั้งคู่มีรุ่น RDP เดียวกัน (6.3.9600, รองรับโปรโตคอล RDP 8.1)

ฉันเปรียบเทียบโปรโตคอล TLS และ ciphers โดยใช้ IIS Crypto เพื่อทำ "บันทึกเทมเพลต" ในการตั้งค่าปัจจุบันของพวกเขาเพื่อให้ฉันสามารถเปรียบเทียบไฟล์เทมเพลต พวกเขาเหมือนกัน! ดังนั้นสิ่งที่เป็นปัญหาดูเหมือนจะไม่เป็นเรื่องของชุด chipher ที่ขาดหายไปในโฮสต์ นี่คือภาพหน้าจอจาก Beyond เปรียบเทียบกับไฟล์:

สิ่งที่อาจแตกต่างกันระหว่างโฮสต์ RDP สองแห่งที่ทำให้เกิดปัญหานี้และวิธีการแก้ไข

IIS Crypto มีตัวเลือกในการตั้งค่าทั้งฝั่งเซิร์ฟเวอร์ (ขาเข้า) และตัวเลือกฝั่งไคลเอ็นต์ (ขาออก) มี ciphers จำนวนหนึ่งที่คุณต้องเปิดใช้งานไว้ในฝั่งไคลเอ็นต์เพื่อความเข้ากันได้

หากต้องการทำสิ่งที่คุณต้องการฉันจะไปกับ:

• ใช้แม่แบบ 3.1
• เปิดใช้งานชุดรหัสตัวเลขทั้งหมด
• ใช้กับทั้งไคลเอ็นต์และเซิร์ฟเวอร์ (ทำเครื่องหมายถูกที่กล่องกาเครื่องหมาย)
• คลิก 'ใช้' เพื่อบันทึกการเปลี่ยนแปลง

รีบูทที่นี่หากต้องการ (และคุณสามารถเข้าถึงเครื่องได้)

• ใช้แม่แบบ 3.1
• เปิดใช้งานชุดรหัสตัวเลขทั้งหมด
• นำไปใช้กับเซิร์ฟเวอร์ (ช่องทำเครื่องหมายไม่ถูกต้อง)
• ยกเลิกการเลือกตัวเลือก 3DES

การรีบูตที่นี่ควรส่งผลให้สถานะสิ้นสุดที่ถูกต้อง

อย่างมีประสิทธิภาพคุณต้องการปิดการใช้งาน 3DES inbound เท่านั้น แต่ยังคงอนุญาตให้ใช้ขาออกของชุดรหัสดังกล่าวได้

ฉันมีปัญหาเดียวกันการติดตั้ง KB3080079 patch บนเซิร์ฟเวอร์ช่วยรองรับ tls 1.1 และ 1.2

โปรดทราบว่าสำหรับไคลเอนต์ windows 7 คุณจะต้องติดตั้งการอัปเดตไคลเอ็นต์ rdp (KB2830477) มิฉะนั้นเฉพาะ Windows 8+ เท่านั้นที่จะสามารถเชื่อมต่อได้

แก้ไข (2018-09-26): ฉันค้นพบแล้วว่าการปิดใช้งาน 3DES ใน 2012R2 ไม่ได้ทำลาย RDP แต่มันหยุดในวันที่ 2008 R2 ตัวเลือกต่าง ๆ ที่รองรับนั้นแตกต่างกันระหว่างเมล็ด

ฉันจะแบ่งปันคำตอบของฉันจากเธรด TechNet แต่ BLUF แรก:

ข้อสรุป Serverfault:ส่วนใหญ่แล้วคุณจะมีความแตกต่างระหว่างระบบ คุณกำลังเชื่อมต่อระหว่างระบบปฏิบัติการรุ่นที่แตกต่างกันระบบใดระบบหนึ่งได้เปิดใช้งาน FIPS และอื่น ๆ ไม่ได้หรือคุณมีข้อ จำกัด HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphersที่แตกต่างกันในการเข้ารหัสขึ้นภายใต้ แน่นอนฉันจะเปิดใช้งานการบันทึก SCHANNEL บนระบบที่ใช้งานได้เพื่อกำหนดรหัสลับที่ใช้งานอยู่ ชอบที่จะได้ยินกลับถ้าคุณมี RDP ให้ทำงานร่วมกับรหัสอื่น

สำเนาโพสต์:

เราได้มันไปทำงาน!

Apparently 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

ฉันสามารถยืนยันได้ว่าการใช้ "Triple DES 168/168" ไม่ปิดการใช้งาน 3DES ในระบบ คุณสามารถพิสูจน์ได้ด้วยตัวคุณเองด้วยเครื่องสแกนโปรโตคอล (เช่น Nessus) หรือโดยการเปิดใช้งานการบันทึก SCHANNEL:

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

จากนั้นคุณจะมีเหตุการณ์ในบันทึกของระบบตัวอย่างเช่น

จับมือไคลเอ็นต์ SSL เสร็จสมบูรณ์ พารามิเตอร์การเข้ารหัสลับที่เจรจาต่อรองมีดังนี้

โปรโตคอล: TLS 1.0 CipherSuite: ความแข็งแรงในการแลกเปลี่ยน 0x2f: 1024

สำหรับฉันแล้วผลลัพธ์คือ 0xa ซึ่ง Google เปิดเผยว่าเป็น TLS_RSA_WITH_3DES_EDE_CBC_SHA

เมื่อฉันใช้ "Triple DES 168" (ไม่มี / 168), รหัสเหตุการณ์ของระบบ 36880 ไม่ปรากฏขึ้นและเซสชัน RDP ถูกบล็อก

สำหรับบทความ: การเข้ารหัสระบบ: ใช้อัลกอริธึมที่เข้ากันได้กับ FIPS สำหรับการเข้ารหัสการแฮชและการลงชื่อ

Remote Desktop Services (RDS) สำหรับการเข้ารหัสการสื่อสารเครือข่าย Remote Desktop Services การตั้งค่านโยบายนี้รองรับเฉพาะอัลกอริทึมการเข้ารหัส Triple DES

ตามบทความ: "การเข้ารหัสของระบบ: ใช้อัลกอริทึมที่เข้ากันได้กับ FIPS สำหรับการเข้ารหัสการแฮชและการเซ็นชื่อ" ผลการตั้งค่าความปลอดภัยใน Windows XP และ Windows รุ่นที่ใหม่กว่า

การตั้งค่านี้มีผลกับบริการเทอร์มินัลใน Windows Server 2003 และ Windows รุ่นที่ใหม่กว่า ผลกระทบขึ้นอยู่กับว่า TLS ใช้สำหรับการตรวจสอบความถูกต้องของเซิร์ฟเวอร์หรือไม่

หากใช้ TLS สำหรับการตรวจสอบความถูกต้องของเซิร์ฟเวอร์การตั้งค่านี้จะทำให้ใช้ TLS 1.0 เท่านั้น

ตามค่าเริ่มต้นหากไม่ได้ใช้ TLS และการตั้งค่านี้ไม่ได้เปิดใช้งานบนไคลเอนต์หรือเซิร์ฟเวอร์ช่องทาง Remote Desktop Protocol (RDP) ระหว่างเซิร์ฟเวอร์และไคลเอนต์จะถูกเข้ารหัสโดยใช้อัลกอริทึม RC4 ที่มี 128 บิต ความยาวของคีย์ หลังจากที่คุณเปิดใช้งานการตั้งค่านี้บนคอมพิวเตอร์ที่ใช้ Windows Server 2003 ต่อไปนี้เป็นจริง: แชนเนล RDP ถูกเข้ารหัสโดยใช้อัลกอริทึม 3DES ในโหมด Cipher Block Chaining (CBC) ที่มีความยาวคีย์ 168 บิต อัลกอริทึม SHA-1 ใช้เพื่อสร้างการแยกย่อยข้อความ ลูกค้าจะต้องใช้โปรแกรมไคลเอนต์ RDP 5.2 หรือรุ่นที่ใหม่กว่าเพื่อเชื่อมต่อ

ดังนั้นทั้งคู่จึงสนับสนุนแนวคิดที่ว่า RDP สามารถใช้ 3DES ได้เท่านั้น อย่างไรก็ตามบทความนี้แนะนำช่วงของ ciphers ที่ใหญ่กว่านั้น: การตรวจสอบความถูกต้องของ 140

ชุดของอัลกอริทึมการเข้ารหัสลับที่เซิร์ฟเวอร์เดสก์ท็อประยะไกลโพรโทคอล (RDP) จะใช้ขอบเขตเพื่อ: - CALG_RSA_KEYX - อัลกอริทึมการแลกเปลี่ยนคีย์สาธารณะ RSA - CALG_3DES - อัลกอริทึมการเข้ารหัส DES สามมิติ - CALG_AES_256 - 128 บิต AES - CALG_AES_256 อัลกอริทึมการแฮช SHA - CALG_SHA_256 - อัลกอริทึมการแฮช SHA 256 บิต - CALG_SHA_384 - 384 บิตอัลกอริทึม SHA แฮช - CALG_SHA_512 - อัลกอริทึม SHA แฮช 512 บิต

ท้ายที่สุดมันยังไม่ชัดเจนว่า RDP สามารถรองรับโปรโตคอลที่ไม่ใช่ 3DES เมื่อเปิดใช้งานโหมด FIPS แต่หลักฐานจะแนะนำว่าไม่

ฉันไม่เห็นหลักฐานว่า Server 2012 R2 จะทำงานแตกต่างจาก Server 2008 R2 แต่ดูเหมือนว่า Server 2008 R2 นั้นเป็นไปตามการปฏิบัติตาม FIPS 140-1 และเซิร์ฟเวอร์ 2012 R2 ตามด้วย FIPS 140-2 ดังนั้นจึงเป็นไปได้ทั้งหมดที่เซิร์ฟเวอร์ 2012 R2 รองรับ โปรโตคอลเพิ่มเติม คุณจะต้องสังเกตโปรโตคอลเพิ่มเติมในลิงค์การตรวจสอบความถูกต้องของ 140

สรุป:ฉันไม่คิดว่า Server 2008 R2 สามารถรองรับ RDP ในโหมด FIPS เมื่อปิดใช้งาน 3DES คำแนะนำของฉันคือการตรวจสอบว่าระบบของคุณเป็นไปตามเงื่อนไขสำหรับการโจมตี SWEET32 (มากกว่า 768GB ส่งในเซสชันเดียว) และการปิดใช้งาน 3DES นั้นคุ้มค่าหรือไม่ที่จะลบความสามารถ RDP มียูทิลิตีอื่น ๆ เพื่อจัดการเซิร์ฟเวอร์ที่เกิน RDP โดยเฉพาะในโลกที่การจำลองเสมือนเป็นเรื่องธรรมดา

Apparently 2008 และ 2012 มีปัญหาเกี่ยวกับไวยากรณ์และ 2008/7 ต้องใช้การต่อท้าย / 168 2012 / 8.1 / 10 ไม่ได้

คีย์บน 2008 มีลักษณะดังนี้: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** เยี่ยมมากฉันพบปัญหาเดียวกันกับตัวควบคุมโดเมน windows 2008 R2 บางตัวเซิร์ฟเวอร์ของฉันที่เป็นสมาชิก 2008R2 ดูเหมือนจะโอเค ... และเซิร์ฟเวอร์ 2012R2 ของฉันก็ทำงานได้ดีเช่นกัน ต้องการที่จะถอดรหัสการทำลาย DC เก่าเหล่านั้น :)