Jak rozwiązać problem błędów szyfrowania CredSSP

Wiosną 2018 r. Użytkownicy Windows zaczęli stawić czoła błędowi, który wcześniej nie spotkał.

Wkrótce stało się jasne, że wiadomość „Szyfrowanie Oracle Remediations” powstała podczas próby podłączenia komputera klienta z zdalnym komputerem, i stało się to w następujących okolicznościach:

• Podłączenie do zdalnego maszyny odbywa się z komputera, na którym niedawno zainstalowano stosunkowo stare system Windows (Server 2012, „Dziesięć” 1803 i poniżej, Server 2016), ponieważ nie ma żadnych aktualizacji bezpieczeństwa, które zostały wydane później;
• Połączenie występuje z serwerem, w którym brakuje powyższych aktualizacji;
• Podczas podłączania fundusze protokołu RDP są zablokowane zdalnym komputerem z powodu braku niezbędnej łatki na komputerze klienckim.

Rozważ przyczyny błędu i sposobu poprawienia sytuacji.

Dlaczego błąd CREDSSP jest

Tak więc wiemy już, że w wielu wersjach systemu Windows (opcje serwera 2016/2012/2008, z wyjątkiem 2013 r., A także klientów, zaczynając od 7) bez zainstalowanych kumulatywnych łatek, jeśli próbujesz połączyć się ze zdalnym komputerem komputerowym Przez RDS/RDP może pojawić się problem z połączeniem pulpitu zdalnego.

Innymi słowy, ze zdalnym połączeniem z komputerem podczas procedury uwierzytelniania szyfrowania wystąpił błąd CREDSSP, którego przyczyną może być brak konsultacji protokołów szyfrowania. Wynika to z faktu, że jeden z samochodów (klient lub pilot) nie zainstalował odpowiednich aktualizacji, które zostały wydane po marcu 2018 r.

Wtedy Microsoft zaczął dystrybuować aktualizację mającą na celu ochronę zidentyfikowanej podatności protokołu CredSSP, zagrażając prawdopodobieństwu zdalnego wykonania kodu przez atakujących. Szczegóły techniczne problemu podano wystarczającą szczegóły w biuletynie CVE2018-0886. Dwa miesiące później wydano kolejną aktualizację, która domyślnie wprowadziła zakaz możliwości komputera klienta Windows do skontaktowania się z serwerem zdalnym, jeśli ma wersję protokołu CredSSP, nie została propagowana przez marcową aktualizację.

Oznacza to, że jeśli masz okna klienta z aktualizacjami majowymi zainstalowanymi na czas, i próbujesz połączyć się ze zdalnymi serwerami, na których, od wiosny 2018 r., Nie było aktualizacji bezpieczeństwa, takie próby zakończą się w Niesprawiedlii. Jednocześnie maszyna kliencka otrzyma wiadomość o niemożności wykonania zdalnego połączenia typu CredSSP.

Tak więc przyczyną błędu może być korekta twórców protokołu szyfrowania CredSSP, który pojawił się w wyniku wydania następujących aktualizacji:

• dla wersji serwera z 2008 r. R2 i „Seven” - KB4103718;
• dla WS 2016 - KB4103723;
• dla WS 2012 R2 i Windows 8.1 - KB4103725;
• dla montażu „dziesiątki” 1803 - KB4103721;
• dla zespołu Windows 10 1609 - KB4103723;
• dla montażu „dziesiątki” 1703 - KB4103731;
• Dla W10 Build 1709 - KB4103727.

Wskazana lista wskazuje liczby aktualizacji opublikowanych w maju 2018 r. Ta operacja można wykonać na kilka sposobów. Na przykład odnosząc się do usługi Windows Update, w oparciu o serwery programistów lub za pomocą lokalnego serwera WSUS. Na koniec możesz ręcznie pobrać niezbędne wzorce bezpieczeństwa za pośrednictwem katalogu Microsoft Update (to jest katalog aktualizacji Vindodes).

W szczególności, aby wyszukać aktualizacje komputera, na którym zainstalowany jest zespół „tuzin” 1803, w maju 2020 r. Zapytanie o wyszukiwanie powinno mieć następujący widok: Windows 10 1803 5/*/2020.

Sposoby rozwiązania problemu

Istnieją dwa sposoby z tej sytuacji. Jak łatwo jest zgadnąć, jednym z nich jest usunięcie aktualizacji bezpieczeństwa na komputerze klienckim zainstalowanym po marcu 2018 r. Oczywiście taki krok jest uważany za bardzo ryzykowny i zdecydowanie nie jest zalecany, ponieważ istnieją inne rozwiązania problemu. Ale jest najłatwiejszy do wykonania i można go użyć do próby dostępu do zdalnego urządzenia.

Teraz rozważmy alternatywne „poprawne” opcje korygowania błędu, który występuje podczas sprawdzania autentyczności CredSSP.

Jednym z nich jest wyłączenie (jednorazowe) procedura sprawdzania wersji CredSSP na zdalnym komputerze podczas próby połączenia przez RDP. W takim przypadku pozostajesz chroniony, łatki pozostają ustalone, istnieje ryzyko tylko podczas sesji komunikacyjnej.

Algorytm działań:

• Wpływamy na konsolę „Perform” Gpedit.MSC (zbudowany -redaktor lokalnego GPO);
• Przechodzimy do karty konfiguracji komputera, wybieramy element szablonów administracji, a następnie przejdź do karty systemowej, a następnie - do delegacji poświadczeń. W Rossified Windows pełna ścieżka będzie wyglądać w następujący sposób: karta „Konfiguracja komputerowa”/karta „Szablony administracyjne”/menu Menu
• Na liście polityka szukamy linii szyfrowania Oracle Remediation, kliknij ją i włącz selektor polityka w pozycji włączonej/„integracyjnej”, wybierając linię podatną na wrażliwą (wrażliwość) na wyświetlonej liście);
• Rozpoczynamy konsolę, aby „wykonać” polecenie GPUpdate /Force (wymuszone aktualizację polityka), wypełniając procedurę odłączania powiadomień o edytowaniu lokalnej zasady grupy;
• Spróbuj połączyć się z zdalną maszyną.

Wyłączenie zasady SzyfrutionOraClemEmeNeMedion pozwoli komputerowi podłączyć się nawet do niestabilnych zdalnych komputerów i serwerów bez nowych aktualizacji bezpieczeństwa.

UWAGA. Przypomnij sobie, że ta metoda eliminowania błędów szyfrowania CredSSP w systemie Windows nie jest zalecana do ciągłego użytkowania. Lepiej jest poinformować administratora zdalnego komputera o problemie niespójności protokołów szyfrowania, aby zainstalować odpowiednie aktualizacje.

Zastanów się, jak działa polityka EOR. Ma trzy poziomy ochrony przed podatnościami protokołu CREDSSP przy braku łat:

1. Force zaktualizowane klony - podstawowy poziom ochrony, całkowity zakaz łączenia z zdalnego komputera do podłączania komputerów klientów bez zainstalowanych aktualizacji. Z reguły te zasady są aktywowane po pełnej aktualizacji w całej infrastrukturze sieciowej, to znaczy po zainstalowaniu świeży.
2. MITIGATED - Ten poziom ochrony blokuje wszelkie próby połączenia z serwerami, na których protokół CREDSSP nie jest właściwy. Jednocześnie nie wpływa to na wszystkie inne usługi CREDSSP.
3. Wrażliwy - minimalny poziom jest szyty, co usuwa zakaz zdalnego dostępu do komputera RDP, jeśli istnieje wrażliwa wersja CredSSSP.

Zauważ, że w niektórych samochodach klientów (na przykład w domowej wersji systemu Windows) nie jest uwzględniony redaktor lokalnego polityka w Zgromadzeniu. W takim przypadku wprowadzanie zmian, które pozwalają zaangażować się w zdalne maszyny bez przedłużonych aktualizacji po stronie serwera, jest wprowadzane ręcznie poprzez edycję rejestru.

Aby to zrobić, przedstaw linię do konsoli linii:

Reg Dodaj hkml \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ System \ Credssp \ Parameters /v AdtuerIncryptionOracle /t Reg_DWORD /D 2

Tę procedurę można zastosować do wszystkich stacji roboczych przy użyciu GPO domeny (uruchomienie konsoli - GPMC.MSC) lub możesz zastosować skrypt PowerShell (aby uzyskać listę stacji roboczych należących do tej domeny, możesz użyć polecenia get-dcomputer, które jest częścią rsat-op-powershell) po następującej treści:

Moduł importowy Actedirectory
$ Pss = (get -dcomputer -filter *).DnShostname
Foreach ($ komputer w $ pcs)
Invoke -Command -ComputerName $ computer -ScriptBlock
Reg Dodaj HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Policies \ System \ Credssp \ Parameters /V AldEncryptionoracle /t Reg_DWORD /D 2

Ale aby uniknąć niepotrzebnego ryzyka, konieczne jest natychmiastowe po połączeniu z zdalnym komputerem, jeśli istnieją odpowiednie prawa do ustawiania bieżących aktualizacji za pomocą usługi Windows Update (należy ją włączyć). Ta operacja można wykonać ręcznie, pobierając nowe aktualizacje skumulowane i wykonując ich instalację zgodnie z określonym wcześniej algorytmem.

Jeśli chcesz poprawić błąd szyfrowania CredSSP w systemie Windows XP/Server 2003, które obecnie nie są obsługiwane, ale z powodu określonych okoliczności, wszystkie te maszyny muszą przebić wbudowaną posadzkę 2009.

WAŻNY. Po pomyślnej próbie skontaktowania się z serwerem, instalacji skumulowanych łatek i ponownego uruchomienia serwera, pamiętaj o realizacji odwrotnych transformacji w zasadach klienta, ustawiając wartość w zasadzie ForceupDatedClents w domyślnej 2 do źródła 0. W ten sposób ponownie ochronisz komputer przed podatnościami związanymi z podłączeniem URDP, tworząc korekcję szyfrowania CredSSP.

Nie wspominaliśmy o innym scenariuszu błędnego wiadomości „Szyfrowanie Oracle Remedion” - gdy wszystko jest w kolejności ze zdalnym serwerem, a komputer klienta okazuje się niezgodny. Powstanie, jeśli zasady zostanie aktywowane na zdalnym komputerze, które blokuje próby nawiązania połączenia z zawartymi komputerami z klientem.

W takim przypadku nie jest konieczne usuwanie aktualizacji bezpieczeństwa na kliencie. Jeśli masz nieudaną próbę skontaktowania się z serwerem, powinieneś sprawdzić, kiedy ostatni raz nastąpiła instalacja skumulowanych aktualizacji bezpieczeństwa komputera klienta. Możesz wykonać kontrolę za pomocą modułu psWindowsUpdate, a także wykonując polecenie w konsoli:

GWMI Win32_QuickFixEngineering | Sortowane na -desk

Jeśli data jest dość stara (opcjonalna do marca 2018 r.), Zainstaluj najnowszą kumulatywną aktualizację dla wersji systemu Windows.