Loại bỏ mật mã dễ bị tổn thương trên Windows 10 phá vỡ RDP đi

Trình quét lỗ hổng của TrustWave không quét được do máy Windows 10 chạy RDP:

Khối thuật toán mã hóa với kích thước khối 64 bit (như DES và 3DES) tấn công sinh nhật được gọi là Sweet32 (CVE-2016-2183)

LƯU Ý: Trên các hệ thống Windows 7/10 chạy RDP (Giao thức máy tính từ xa), mật mã dễ bị vô hiệu hóa cần được gắn nhãn 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'.

Sử dụng IIS Crypto (bởi Nartac), tôi đã thử áp dụng mẫu "Thực tiễn tốt nhất" cũng như mẫu PCI 3.1, tuy nhiên cả hai đều bao gồm mật mã không an toàn (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Nếu tôi vô hiệu hóa mật mã này, RDP từ máy tính này đến nhiều trạm Windows sẽ ngừng hoạt động (nó vẫn hoạt động với một số máy chủ 2008 R2 và 2012 R2). Máy khách RDP chỉ đơn giản đưa ra, "Đã xảy ra lỗi nội bộ" và nhật ký sự kiện:

Đã xảy ra lỗi nghiêm trọng trong khi tạo thông tin xác thực ứng dụng khách TLS. Trạng thái lỗi nội bộ là 10013.

Tôi đã kiểm tra nhật ký sự kiện máy chủ của một trong các máy chủ và thấy hai thông báo này

Yêu cầu kết nối TLS 1.2 đã được nhận từ ứng dụng khách từ xa, nhưng không có bộ mật mã nào được ứng dụng khách hỗ trợ được máy chủ hỗ trợ. Yêu cầu kết nối SSL không thành công.

Cảnh báo gây tử vong sau đây đã được tạo: 40. Trạng thái lỗi bên trong là 1205.

Làm cách nào để khắc phục lỗ hổng bảo mật mà không phá vỡ RDP?

Hoặc, nếu điều trên là không thể, có điều gì tôi có thể làm trên mỗi máy chủ RDP mà tôi không còn có thể kết nối với xử lý nó ở đầu đó không?

--- Cập nhật # 1 ---

Sau khi vô hiệu hóa TLS_RSA_WITH_3DES_EDE_CBC_SHA trên máy Windows 10, tôi đã thử kết nối với một số máy chủ RDP (một nửa trong số đó không thành công với "Lỗi nội bộ ..."). Vì vậy, tôi đã so sánh một trong những máy chủ mà tôi có thể kết nối với một máy chủ mà tôi không thể kết nối. Cả hai đều là 2008 R2. Cả hai đều có cùng phiên bản RDP (6.3.9600, RDP Protocol 8.1 được hỗ trợ).

Tôi đã so sánh các giao thức và mật mã TLS bằng cách sử dụng IIS Crypto để thực hiện "Lưu mẫu" trên cài đặt hiện tại của chúng để tôi có thể so sánh các tệp mẫu. Chúng giống hệt nhau! Vì vậy, bất kể vấn đề là gì dường như không phải là vấn đề thiếu bộ chipher trên máy chủ. Đây là ảnh chụp màn hình từ Beyond So sánh trên các tệp:

Điều gì có thể khác nhau giữa hai máy chủ RDP gây ra sự cố này và cách khắc phục?

IIS Crypto có tùy chọn để đặt cả hai tùy chọn phía máy chủ (đến) và phía máy khách (đi). Có một số mật mã bạn cần để lại được kích hoạt ở phía máy khách để tương thích.

Để làm những gì bạn muốn, cá nhân tôi sẽ làm như sau:

• Áp dụng mẫu 3.1
• Để tất cả các bộ mật mã được kích hoạt
• Áp dụng cho cả máy khách và máy chủ (đánh dấu vào hộp kiểm).
• Nhấp vào 'áp dụng' để lưu các thay đổi

Khởi động lại ở đây nếu muốn (và bạn có quyền truy cập vật lý vào máy).

• Áp dụng mẫu 3.1
• Để tất cả các bộ mật mã được kích hoạt
• Áp dụng cho máy chủ (hộp kiểm chưa sử dụng).
• Bỏ chọn tùy chọn 3DES

Khởi động lại ở đây sẽ dẫn đến trạng thái kết thúc chính xác.

Thực tế, bạn chỉ muốn tắt 3DES trong nước, nhưng vẫn cho phép sử dụng bộ mật mã nói trên.

Tôi gặp vấn đề tương tự, cài đặt bản vá KB3080079 trên máy chủ cho phép hỗ trợ cho các bản 1.1 và 1.2.

Lưu ý rằng đối với máy khách windows 7, bạn sẽ phải cài đặt bản cập nhật máy khách thứ 7 (KB2830477), nếu không, chỉ có windows 8+ mới có thể kết nối.

Chỉnh sửa (2018-09-26): Tôi đã phát hiện ra rằng việc tắt 3DES trên 2012R2 KHÔNG phá vỡ RDP nhưng nó KHÔNG phá vỡ vào năm 2008 R2. Các tùy chọn được hỗ trợ dường như khác nhau giữa các hạt nhân.

Tôi sẽ chia sẻ câu trả lời của tôi từ một chủ đề TechNet nhưng BLEC đầu tiên:

Kết luận về Serverfault: Nhiều khả năng bạn có một số khác biệt khác giữa các hệ thống. Bạn đang kết nối giữa các phiên bản HĐH khác nhau, một hệ thống có kích hoạt Trin còn hệ thống kia thì không hoặc bạn có các hạn chế mật mã khác nhau HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Tôi chắc chắn sẽ cho phép khai thác gỗ SCHANNEL trên hệ thống mà không làm việc để xác định mật mã được sử dụng. Rất thích nghe lại nếu bạn bằng cách nào đó có RDP để làm việc với một mật mã thay thế.

Bản sao của bài viết:

Chúng tôi đã làm cho nó để làm việc!

Rõ ràng 2008 và 2012 có vấn đề về cú pháp và 2008/7 yêu cầu có dấu / 168. 2012 / 8.1 / 10 thì không.

chìa khóa năm 2008 trông như thế này: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

Và chìa khóa vào năm 2012 trông như thế này: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Tôi có thể xác nhận rằng việc sử dụng "Triple DES 168/168" KHÔNG tắt 3DES trên hệ thống. Bạn có thể tự chứng minh điều này bằng trình quét giao thức (như Nessus) hoặc bằng cách bật ghi nhật ký SCHANNEL:

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

Sau đó, bạn sẽ có các sự kiện trong nhật ký HỆ THỐNG;

Bắt tay khách SSL hoàn thành thành công. Các thông số mật mã được đàm phán như sau.

Giao thức: TLS 1.0 CodesSuite: 0x2f Cường độ trao đổi: 1024

Đối với tôi, kết quả là 0xa mà Google tiết lộ là TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Khi tôi sử dụng "Triple DES 168" (không có / 168), ID sự kiện hệ thống 36880 không xuất hiện và phiên RDP bị chặn.

Theo bài viết: Mật mã hệ thống: Sử dụng thuật toán tuân thủ mật khẩu để mã hóa, băm và ký

Dịch vụ máy tính từ xa (RDS) Để mã hóa giao tiếp mạng Dịch vụ máy tính từ xa, cài đặt chính sách này chỉ hỗ trợ thuật toán mã hóa Triple DES.

Theo bài viết: "Mật mã hệ thống: Sử dụng thuật toán tuân thủ mật khẩu để mã hóa, băm và ký" các hiệu ứng cài đặt bảo mật trong Windows XP và trong các phiên bản sau của Windows

Cài đặt này cũng ảnh hưởng đến Terminal Services trong Windows Server 2003 và các phiên bản Windows mới hơn. Hiệu quả phụ thuộc vào việc TLS có được sử dụng để xác thực máy chủ hay không.

Nếu TLS đang được sử dụng để xác thực máy chủ, cài đặt này chỉ khiến TLS 1.0 được sử dụng.

Theo mặc định, nếu TLS không được sử dụng và cài đặt này không được bật trên máy khách hoặc trên máy chủ, kênh Giao thức máy tính từ xa (RDP) giữa máy chủ và máy khách được mã hóa bằng thuật toán RC4 với 128 bit chiều dài khóa. Sau khi bạn bật cài đặt này trên máy tính chạy Windows Server 2003, điều sau đây là đúng: Kênh RDP được mã hóa bằng cách sử dụng thuật toán 3DES trong chế độ Chuỗi khối mã hóa (CBC) với độ dài khóa 168 bit. Thuật toán SHA-1 được sử dụng để tạo ra các thông báo. Khách hàng phải sử dụng chương trình máy khách RDP 5.2 hoặc phiên bản mới hơn để kết nối.

Vì vậy, cả hai đều hỗ trợ ý tưởng rằng RDP chỉ có thể sử dụng 3DES. Tuy nhiên, bài viết này cho thấy một phạm vi mật mã lớn hơn có sẵn: Xác thực Trin 140

Tập hợp các thuật toán mã hóa mà máy chủ Giao thức máy tính từ xa (RDP) sẽ sử dụng nằm trong phạm vi: - CALG_RSA_KEYX - Thuật toán trao đổi khóa công khai RSA - CALG_3DES - Thuật toán mã hóa ba DES - CALG_AES_128 - 128 bit AES - CALG_AES_256 Thuật toán băm SHA - CALG_SHA_256 - Thuật toán băm SHA 256 bit - Thuật toán băm SHA CALG_SHA_384 - 384 bit - Thuật toán băm SHA 512 bit

Cuối cùng, không rõ liệu RDP có thể hỗ trợ các giao thức không phải 3DES hay không khi chế độ Trin được bật nhưng bằng chứng sẽ cho thấy điều đó không xảy ra.

Tôi không thấy bằng chứng nào cho thấy Server 2012 R2 sẽ hoạt động khác với Server 2008 R2, tuy nhiên có vẻ như Server 2008 R2 dựa trên sự tuân thủ của Trin 140-1 và Server 2012 R2 tuân theo Trin 140-2 nên hoàn toàn có khả năng Server 2012 R2 hỗ trợ giao thức bổ sung. Bạn sẽ lưu ý các giao thức bổ sung trong liên kết Xác thực Trin 140 .

Tóm lại: Tôi không nghĩ Server 2008 R2 có thể hỗ trợ RDP ở chế độ Trin với 3DES bị tắt. Đề nghị của tôi là xác định xem hệ thống của bạn có đáp ứng các điều kiện cho một cuộc tấn công SWEET32 (hơn 768GB được gửi trong một phiên hay không) và việc tắt 3DES có đáng để loại bỏ khả năng RDP hay không. Các tiện ích khác tồn tại để quản lý các máy chủ ngoài RDP, đặc biệt là trong một thế giới nơi ảo hóa rất phổ biến.

Rõ ràng 2008 và 2012 có vấn đề về cú pháp và 2008/7 yêu cầu có dấu / 168. 2012 / 8.1 / 10 thì không.

khóa trên 2008 trông như thế này: HKEY_LOCAL_MACHINE \ HỆ THỐNG \ CurrentControlset \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** Tuyệt vời tôi đã gặp vấn đề tương tự chính xác trên một số bộ điều khiển miền Windows 2008 R2, kỳ lạ là các máy chủ thành viên 2008R2 của tôi có vẻ ổn ... và máy chủ 2012R2 của tôi cũng hoạt động tốt. Cần phải bẻ khóa khi ngừng hoạt động của những DC cũ hơn :)