Menghapus cipher rentan pada Windows 10 istirahat keluar RDP

Pemindai kerentanan TrustWave gagal memindai karena mesin Windows 10 yang menjalankan RDP:

Algoritma cipher blok dengan ukuran blok serangan ulang tahun 64 bit (seperti DES dan 3DES) dikenal sebagai Sweet32 (CVE-2016-2183)

CATATAN: Pada sistem Windows 7/10 yang menjalankan RDP (Remote Desktop Protocol), sandi rentan yang harus dinonaktifkan diberi label 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'.

Menggunakan IIS Crypto (oleh Nartac), saya mencoba menerapkan templat "Praktik Terbaik" serta templat PCI 3.1, namun keduanya termasuk cipher yang tidak aman (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Jika saya menonaktifkan cipher ini, RDP dari komputer ini ke banyak stasiun Windows berhenti bekerja (masih berfungsi untuk beberapa server 2008 R2 dan 2012 R2). Klien RDP hanya memberikan, "Terjadi kesalahan internal" dan log peristiwa:

Kesalahan fatal terjadi saat membuat kredensial klien TLS. Status kesalahan internal adalah 10013.

Saya memeriksa log peristiwa server dari salah satu server dan melihat dua pesan ini

Permintaan koneksi TLS 1.2 diterima dari aplikasi klien jarak jauh, tetapi tidak ada suite sandi yang didukung oleh aplikasi klien yang didukung oleh server. Permintaan koneksi SSL telah gagal.

Peringatan fatal berikut ini dihasilkan: 40. Status kesalahan internal adalah 1205.

Bagaimana saya bisa memperbaiki kerentanan keamanan tanpa melanggar RDP keluar?

Atau, jika hal di atas tidak mungkin, apakah ada sesuatu yang dapat saya lakukan pada setiap host RDP yang tidak dapat saya sambungkan lagi ke yang menanganinya?

--- Perbarui # 1 ---

Setelah menonaktifkan TLS_RSA_WITH_3DES_EDE_CBC_SHA pada mesin Windows 10, saya mencoba menghubungkan ke beberapa host RDP (setengah dari mereka gagal dengan "An internal error ..."). Jadi saya membandingkan salah satu dari host yang dapat saya hubungkan dengan yang tidak dapat saya hubungkan. Keduanya 2008 R2. Keduanya memiliki versi RDP yang sama (6.3.9600, RDP Protocol 8.1 didukung).

Saya membandingkan protokol dan sandi TLS dengan menggunakan IIS Crypto untuk melakukan "Simpan Templat" pada pengaturan mereka saat ini sehingga saya dapat membandingkan file templat. Mereka identik! Jadi, apa pun masalahnya, tampaknya bukan masalah chipher suite yang hilang pada host. Berikut ini cuplikan layar dari Beyond Compare pada file:

Apa yang bisa berbeda antara dua host RDP yang menyebabkan masalah ini dan bagaimana cara memperbaikinya?

IIS Crypto memiliki opsi untuk mengatur opsi sisi server (masuk) dan sisi klien (keluar). Ada beberapa cipher yang perlu Anda aktifkan di sisi klien untuk kompatibilitas.

Untuk melakukan apa yang Anda inginkan, saya pribadi akan mengikuti yang berikut:

• Terapkan 3,1 template
• Biarkan semua cipher suite diaktifkan
• Berlaku untuk klien dan server (kotak centang dicentang).
• Klik 'terapkan' untuk menyimpan perubahan

Reboot di sini jika diinginkan (dan Anda memiliki akses fisik ke mesin).

• Terapkan 3,1 template
• Biarkan semua cipher suite diaktifkan
• Berlaku ke server (kotak centang tidak dicentang).
• Hapus centang opsi 3DES

Reboot di sini akan menghasilkan kondisi akhir yang benar.

Secara efektif Anda hanya ingin menonaktifkan 3DES inbound, tetapi masih mengizinkan penggunaan outbound suite sandi tersebut.

Saya memiliki masalah yang sama, menginstal KB3080079 patch pada server memungkinkan dukungan untuk tls 1.1 dan 1.2.

Perhatikan bahwa untuk klien windows 7 Anda harus menginstal pembaruan klien rdp (KB2830477), jika tidak hanya windows 8+ yang dapat terhubung.

Sunting (2018-09-26): Saya telah menemukan bahwa menonaktifkan 3DES pada 2012R2 TIDAK merusak RDP tetapi TIDAK rusak pada 2008 R2. Opsi yang didukung tampaknya berbeda di antara kernel.

Saya akan membagikan jawaban saya dari utas TechNet tetapi pertama-tama BLUF:

Kesimpulan Serverfault: Kemungkinan besar Anda memiliki beberapa perbedaan lain di antara sistem. Anda menghubungkan antara versi OS yang berbeda, satu sistem memiliki FIPS diaktifkan dan yang lainnya tidak, atau Anda memiliki batasan cipher yang berbeda di tempatnya HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Saya pasti akan memungkinkan SCHANNEL logging pada sistem yang tidak bekerja untuk menentukan cipher digunakan. Senang mendengar kembali jika Anda entah bagaimana membuat RDP bekerja dengan cipher alternatif.

Salinan pos:

Kami berhasil!

Rupanya 2008 dan 2012 memiliki masalah sintaksis dan 2008/7 membutuhkan trailing / 168. 2012 / 8.1 / 10 tidak.

kunci pada 2008 terlihat seperti ini: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

Dan kuncinya pada 2012 terlihat seperti ini: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Saya dapat mengkonfirmasi bahwa penggunaan "Triple DES 168/168" JANGAN menonaktifkan 3DES pada sistem. Anda dapat membuktikan ini sendiri dengan pemindai protokol (seperti Nessus) atau dengan mengaktifkan pendataan SCHANNEL:

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

Anda kemudian akan memiliki acara di log SISTEM misalnya;

Jabat tangan klien SSL berhasil diselesaikan. Parameter kriptografi yang dinegosiasikan adalah sebagai berikut.

Protokol: TLS 1.0 CipherSuite: 0x2f Kekuatan pertukaran: 1024

Bagi saya hasilnya adalah 0xa yang diungkapkan oleh Google sebagai TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Ketika saya menggunakan "Triple DES 168" (tanpa / 168), System event ID 36880 tidak muncul dan sesi RDP diblokir.

Per artikel: Sistem kriptografi: Gunakan algoritma yang sesuai FIPS untuk enkripsi, hashing, dan penandatanganan

Remote Desktop Services (RDS) Untuk mengenkripsi komunikasi jaringan Remote Desktop Services, pengaturan kebijakan ini hanya mendukung algoritma enkripsi Triple DES.

Per artikel: "Kriptografi sistem: Gunakan algoritma yang sesuai FIPS untuk enkripsi, hashing, dan penandatanganan" efek pengaturan keamanan di Windows XP dan di versi Windows yang lebih baru

Pengaturan ini juga memengaruhi Layanan Terminal di Windows Server 2003 dan di versi Windows yang lebih baru. Efeknya tergantung pada apakah TLS digunakan untuk otentikasi server.

Jika TLS digunakan untuk otentikasi server, pengaturan ini hanya menyebabkan TLS 1.0 digunakan.

Secara default, jika TLS tidak sedang digunakan, dan pengaturan ini tidak diaktifkan pada klien atau di server, saluran Remote Desktop Protocol (RDP) antara server dan klien dienkripsi dengan menggunakan algoritma RC4 dengan 128-bit panjang kunci. Setelah Anda mengaktifkan pengaturan ini pada komputer berbasis Windows Server 2003, berikut ini benar: Saluran RDP dienkripsi dengan menggunakan algoritma 3DES dalam mode Cipher Block Chaining (CBC) dengan panjang kunci 168-bit. Algoritma SHA-1 digunakan untuk membuat intisari pesan. Klien harus menggunakan program klien RDP 5.2 atau versi yang lebih baru untuk terhubung.

Jadi keduanya mendukung gagasan bahwa RDP hanya dapat memanfaatkan 3DES. Namun, artikel ini menyarankan berbagai jenis cipher tersedia: Validasi FIPS 140

Himpunan algoritma kriptografi yang akan digunakan server Remote Desktop Protocol (RDP) untuk: - CALG_RSA_KEYX - Algoritma pertukaran kunci publik RSA - CALG_3DES - Algoritme enkripsi Triple DES - CALG_AES_128 - 128 bit AES - CALG_AES_256 - 256 bit AES - CALG_SHA Algoritma hashing SHA - CALG_SHA_256 - 256 bit Algoritma hashing SHA - CALG_SHA_384 - 384 bit Algoritma hashing SHA - CALG_SHA_512 - 512 bit Algoritma hashing SHA

Pada akhirnya tidak jelas apakah RDP dapat mendukung protokol non-3DES ketika mode FIPS diaktifkan tetapi bukti menunjukkan itu tidak.

Saya tidak melihat bukti bahwa Server 2012 R2 akan berfungsi secara berbeda dari Server 2008 R2, namun tampaknya Server 2008 R2 didasarkan pada kepatuhan FIPS 140-1 dan Server 2012 R2 mengikuti FIPS 140-2 sehingga sangat mungkin bahwa Server 2012 R2 mendukung protokol tambahan. Anda akan mencatat protokol tambahan di tautan Validasi FIPS 140 .

Sebagai kesimpulan: Saya tidak berpikir Server 2008 R2 dapat mendukung RDP dalam mode FIPS dengan 3DES dinonaktifkan. Rekomendasi saya adalah memastikan apakah sistem Anda memenuhi persyaratan untuk serangan SWEET32 (lebih dari 768GB yang dikirim dalam satu sesi) dan apakah menonaktifkan 3DES layak untuk menghapus kemampuan RDP. Utilitas lain ada untuk mengelola server di luar RDP terutama di dunia di mana virtualisasi sangat umum.

Rupanya 2008 dan 2012 memiliki masalah sintaksis dan 2008/7 membutuhkan trailing / 168. 2012 / 8.1 / 10 tidak.

kunci pada 2008 terlihat seperti ini: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** Hebat menemukan saya memiliki masalah yang sama persis pada beberapa pengontrol domain windows 2008 R2, anehnya server 2008R2 anggota saya tampak ok ... dan server 2012R2 saya berfungsi dengan baik juga. Perlu untuk memecahkan decomming DC tua :)