Usunięcie podatnego szyfru w systemie Windows 10 przerywa wychodzący RDP

Skaner podatności na zagrożenia TrustWave kończy się niepowodzeniem ze względu na komputer z systemem Windows 10 z RDP:

Algorytmy blokowego szyfru o rozmiarze bloku 64 bitów (takie jak DES i 3DES) atak urodzinowy znany jako Sweet32 (CVE-2016-2183)

UWAGA: W systemach Windows 7/10 z protokołem RDP (Remote Desktop Protocol) wrażliwy szyfr, który należy wyłączyć, jest oznaczony jako „TLS_RSA_WITH_3DES_EDE_CBC_SHA”.

Korzystając z IIS Crypto (firmy Nartac), próbowałem zastosować szablon „Najlepsze praktyki”, a także szablon PCI 3.1, jednak oba zawierają niezabezpieczony szyfr (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Jeśli wyłączę ten szyfr, protokół RDP z tego komputera do wielu stacji Windows przestanie działać (nadal działa na niektórych serwerach 2008 R2 i 2012 R2). Klient RDP po prostu podaje: „Wystąpił błąd wewnętrzny” i dziennik zdarzeń:

Wystąpił błąd krytyczny podczas tworzenia referencji klienta TLS. Wewnętrzny stan błędu to 10013.

Sprawdziłem dziennik zdarzeń serwera na jednym z serwerów i zobaczyłem te dwa komunikaty

Żądanie połączenia TLS 1.2 zostało odebrane ze zdalnej aplikacji klienckiej, ale serwer nie obsługuje żadnego zestawu szyfrów obsługiwanego przez aplikację kliencką. Żądanie połączenia SSL nie powiodło się.

Wygenerowano następujący alert krytyczny: 40. Stan błędu wewnętrznego to 1205.

Jak mogę naprawić lukę w zabezpieczeniach bez przerywania wychodzącego RDP?

Lub, jeśli powyższe nie jest możliwe, czy jest coś, co mogę zrobić na każdym hoście RDP, z którym nie mogę się już połączyć, i który obsługuje to na tym końcu?

--- Aktualizacja nr 1 ---

Po wyłączeniu TLS_RSA_WITH_3DES_EDE_CBC_SHA na komputerze z systemem Windows 10 próbowałem połączyć się z kilkoma hostami RDP (połowa z nich zakończyła się błędem „Błąd wewnętrzny ...”). Porównałem więc jeden z tych hostów, z którymi mogę się połączyć, z jednym, z którym nie mogę się połączyć. Oba są 2008 R2. Oba mają tę samą wersję RDP (6.3.9600, obsługiwany protokół RDP 8.1).

Porównałem protokoły TLS i szyfry, używając Crypto IIS, aby zrobić „Zapisz szablon” przy ich bieżących ustawieniach, aby móc porównać pliki szablonów. Były identyczne! Tak więc bez względu na problem nie wydaje się to kwestią braku pakietu chipherów na hoście. Oto zrzut ekranu z Beyond Compare w plikach:

Co może różnić się między dwoma hostami RDP, które powodują ten problem, i jak go naprawić?

IIS Crypto ma opcję ustawienia zarówno po stronie serwera (przychodzące), jak i po stronie klienta (wychodzące). Istnieje kilka szyfrów, które należy pozostawić włączone po stronie klienta w celu zapewnienia zgodności.

Aby zrobić to, co chcesz, osobiście wykonałbym następujące czynności:

• Zastosuj szablon 3.1
• Pozostaw wszystkie zestawy szyfrów włączone
• Zastosuj zarówno do klienta, jak i serwera (zaznaczone pole wyboru).
• Kliknij „zastosuj”, aby zapisać zmiany

Uruchom ponownie tutaj, jeśli chcesz (i masz fizyczny dostęp do komputera).

• Zastosuj szablon 3.1
• Pozostaw wszystkie zestawy szyfrów włączone
• Zastosuj do serwera (pole wyboru niezaznaczone).
• Odznacz opcję 3DES

Uruchom ponownie tutaj, aby uzyskać prawidłowy stan końcowy.

W rzeczywistości chcesz tylko wyłączyć 3DES dla ruchu przychodzącego, ale nadal zezwalać na korzystanie z tego pakietu szyfrów.

Miałem ten sam problem, instalacja poprawki KB3080079 na serwerze umożliwia obsługę tls 1.1 i 1.2.

Pamiętaj, że w przypadku klientów Windows 7 będziesz musiał zainstalować aktualizację klienta rdp (KB2830477), w przeciwnym razie tylko Windows 8+ będzie mógł się połączyć.

Edycja (26.09.2018): Odkryłem, że wyłączenie 3DES na 2012R2 NIE psuje RDP, ale JEST psuje się na 2008 R2. Obsługiwane opcje wydają się różnić w zależności od jądra.

Podzielę się odpowiedzią z wątku TechNet, ale najpierw BLUF:

Wniosek dotyczący błędu serwera: najprawdopodobniej masz inną różnicę między systemami. Łączysz różne wersje systemu operacyjnego, jeden system ma włączoną obsługę FIPS, a drugi nie, lub obowiązują inne ograniczenia szyfrowania HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Z pewnością pozwoliłbym na logowanie SCHANNEL w systemie, który działa, aby ustalić, który szyfr jest w użyciu. Chciałbym usłyszeć odpowiedź, jeśli w jakiś sposób RDP będzie działać z alternatywnym szyfrem.

Kopia postu:

Mamy to do pracy!

Najwyraźniej w 2008 i 2012 roku występują problemy ze składnią, a 2008/7 wymaga końcowego / 168. 2012 / 8.1 / 10 nie.

klucz z 2008 roku wygląda następująco: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

A klucz w 2012 roku wygląda następująco: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Mogę potwierdzić, że użycie „Triple DES 168/168” NIE WYŁĄCZA 3DES w systemie. Możesz to sobie udowodnić za pomocą skanera protokołów (takiego jak Nessus) lub włączając rejestrowanie SCHANNEL:

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

Będziesz wtedy miał zdarzenia na przykład w dzienniku SYSTEM;

Uzgadnianie klienta SSL zakończyło się pomyślnie. Negocjowane parametry kryptograficzne są następujące.

Protokół: TLS 1.0 CipherSuite: 0x2f Siła wymiany: 1024

Dla mnie wynikiem jest 0xa, który Google ujawnia jako TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Gdy używam „Triple DES 168” (bez / 168), identyfikator zdarzenia systemowego 36880 nie pojawia się, a sesja RDP jest blokowana.

Zgodnie z artykułem: Kryptografia systemu: Użyj zgodnych algorytmów FIPS do szyfrowania, mieszania i podpisywania

Usługi pulpitu zdalnego (RDS) Do szyfrowania komunikacji sieciowej usług pulpitu zdalnego to ustawienie zasad obsługuje tylko algorytm szyfrowania Triple DES.

Zgodnie z artykułem: „Kryptografia systemu: używaj zgodnych algorytmów FIPS do szyfrowania, mieszania i podpisywania” efekty ustawień zabezpieczeń w systemie Windows XP i nowszych wersjach systemu Windows

To ustawienie wpływa również na usługi terminalowe w systemie Windows Server 2003 i nowszych wersjach systemu Windows. Efekt zależy od tego, czy TLS jest używany do uwierzytelniania serwera.

Jeśli TLS jest używany do uwierzytelniania serwera, to ustawienie powoduje, że używany jest tylko TLS 1.0.

Domyślnie, jeśli TLS nie jest używany, a to ustawienie nie jest włączone na kliencie lub serwerze, kanał protokołu RDP (Remote Desktop Protocol) między serwerem a klientem jest szyfrowany przy użyciu algorytmu RC4 z 128-bitowym długość klucza. Po włączeniu tego ustawienia na komputerze z systemem Windows Server 2003 spełnione są następujące warunki: Kanał RDP jest szyfrowany przy użyciu algorytmu 3DES w trybie Łańcuch bloków szyfrów (CBC) z kluczem o długości 168 bitów. Algorytm SHA-1 służy do tworzenia skrótów wiadomości. Klienci muszą korzystać z programu klienta RDP 5.2 lub nowszej wersji, aby się połączyć.

Oba te argumenty wspierają ideę, że RDP może wykorzystywać tylko 3DES. Jednak ten artykuł sugeruje, że dostępna jest większa liczba szyfrów: walidacja FIPS 140

Zestaw algorytmów kryptograficznych, których będzie używał serwer RDP, obejmuje: - CALG_RSA_KEYX - algorytm wymiany klucza publicznego RSA - CALG_3DES - algorytm szyfrowania potrójnego DES - CALG_AES_128 - 128-bitowy AES - CALG_AES_256 - 256-bitowy AES - CALG_SHA1 - Algorytm mieszania SHA - CALG_SHA_256 - 256-bitowy algorytm mieszania SHA - CALG_SHA_384 - 384-bitowy algorytm mieszania SHA - CALG_SHA_512 - 512-bitowy algorytm mieszania SHA

Ostatecznie nie jest jasne, czy RDP może obsługiwać protokoły inne niż 3DES, gdy włączony jest tryb FIPS, ale dowody sugerują, że tak nie jest.

Nie widzę dowodów na to, że Server 2012 R2 działałby inaczej niż Server 2008 R2, jednak wydaje się, że Server 2008 R2 był oparty na zgodności z FIPS 140-1, a Server 2012 R2 jest zgodny z FIPS 140-2, więc jest całkowicie możliwe, że Server 2012 R2 obsługuje dodatkowe protokoły. Zanotujesz dodatkowe protokoły w linku Walidacja FIPS 140 .

Podsumowując: nie sądzę, aby Server 2008 R2 mógł obsługiwać RDP w trybie FIPS z wyłączonym 3DES. Moim zaleceniem jest sprawdzenie, czy Twój system spełnia warunki ataku SWEET32 (ponad 768 GB wysłane w jednej sesji) i czy wyłączenie 3DES jest warte usunięcia możliwości RDP. Istnieją inne narzędzia do zarządzania serwerami poza protokołem RDP, szczególnie w świecie, w którym wirtualizacja jest bardzo powszechna.

Najwyraźniej w 2008 i 2012 roku występują problemy ze składnią, a 2008/7 wymaga końcowego / 168. 2012 / 8.1 / 10 nie.

klucz w 2008 roku wygląda następująco: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** Świetne odkrycie, że miałem dokładnie ten sam problem na niektórych kontrolerach domeny z systemem Windows 2008 R2, dziwnie moje serwery członkowskie 2008R2 wydają się być w porządku ... a moje serwery 2012R2 również działają dobrze. Trzeba złamać przy usuwaniu starszych DC :)