Jak zapobiec włamaniu sethc.exe?

Istnieje exploit, który pozwala użytkownikom zresetować hasło administratora w systemie Windows. Odbywa się to poprzez uruchomienie z dysku naprawczego, uruchomienie wiersza polecenia i zamianę C: \ Windows \ System32 \ sethc.exe na C: \ Windows \ System32 \ cmd.exe.

Po naciśnięciu kombinacji klawiszy lepkich na ekranie logowania użytkownicy uzyskują dostęp do wiersza polecenia z uprawnieniami administratora.

Jest to ogromna dziura w zabezpieczeniach, która sprawia, że ​​system operacyjny jest podatny na zagrożenia dla każdego, kto ma choćby niewielką wiedzę informatyczną. To prawie sprawia, że ​​chcesz przejść na Maca lub Linuksa. Jak można temu zapobiec?

Aby uniemożliwić atakującemu uruchomienie z dysku naprawczego i wykorzystanie go do uzyskania dostępu do systemu, należy podjąć kilka kroków. W kolejności ważności:

• Użyj ustawień BIOS / UEFI, aby zapobiec uruchamianiu z nośnika wymiennego lub wymagaj hasła do uruchomienia z nośnika zewnętrznego. Procedura różni się w zależności od płyty głównej.
• Zamknij swoją wieżę. Zwykle istnieje sposób na zresetowanie ustawień BIOS / UEFI (w tym haseł), jeśli osoba atakująca uzyska fizyczny dostęp do płyty głównej, więc warto temu zapobiec. To, jak daleko posuniesz się, zależy od takich czynników, jak ważność chronionych danych, stopień oddania atakujących, rodzaj fizycznego bezpieczeństwa prowadzącego do stacji roboczej (np. Czy w biurze, do którego dostęp mają tylko współpracownicy lub czy jest to izolowany obszar otwarty dla publiczności) i ile czasu typowy napastnik będzie musiał złamać twoje fizyczne bezpieczeństwo, nie będąc zauważonym.
• Użyj pewnego rodzaju szyfrowania dysku, takiego jak BitLocker lub TrueCrypt. Chociaż nie powstrzyma to dedykowanego atakującego przed ponownym sformatowaniem systemu, jeśli będzie on mógł uzyskać fizyczny dostęp i zresetować hasło systemu BIOS, powstrzyma prawie każdego od uzyskania dostępu do twojego systemu (zakładając, że dobrze strzeżesz swoich kluczy, a atakujący nie ma dostęp do dowolnych tylnych drzwi).

Problemem jest tutaj fizyczny dostęp do maszyny. Wyłącz możliwość rozruchu z CD / USB i zablokuj BIOS hasłem. Jednak nie zapobiegnie to włamaniu się do niego na wiele różnych sposobów.

Plik SETHC.exe można również zastąpić kopią programu explorer.exe (lub dowolnego innego pliku .exe), który zapewnia również pełny dostęp do systemu z poziomu ekranu logowania. Nie powtarzając innych, ale jeśli mówisz o bezpieczeństwie serwera, sądzę, że pewna ilość bezpieczeństwa fizycznego już istnieje. Ile zależy od akceptowalnego ryzyka przedstawionego przez twoją organizację.

Zamieszczam to, aby być może pójść inną drogą. Jeśli obawiasz się, że społeczność użytkowników w Twojej organizacji może lub zrobi to na stacjach roboczych Windows 7 (jak opisano w pytaniu), jedynym sposobem na obejście tego rodzaju ataków jest „przeniesienie” obliczeń do centrum danych. Można to osiągnąć za pomocą dowolnej liczby technologii. Wybieram produkty Citrix, aby krótko zapoznać się z procesem, chociaż wielu innych dostawców oferuje podobne oferty. Za pomocą XenApp, XenDesktop, Machine Creation Services lub Provisioning Services możesz „przenieść” stację roboczą do centrum danych. W tym momencie (o ile twoje centrum danych jest bezpieczne) masz fizyczne bezpieczeństwo nad stacją roboczą. Możesz użyć cienkich klientów lub w pełni zdolnych stacji roboczych, aby uzyskać dostęp do pulpitu hostowanego z centrum danych. W każdym z tych scenariuszy potrzebujesz hiperwizora jako konia roboczego. Chodzi o to, że stan bezpieczeństwa fizycznej maszyny, na której znajduje się użytkownik, jest bardzo mały, niezależnie od tego, czy jest zagrożony czy nie. Zasadniczo fizyczne stacje robocze mają dostęp tylko do bardzo ograniczonej liczby zasobów (AD, DHCP, DNS itp.). W tym scenariuszu wszystkie dane i cały dostęp są przyznawane tylko do zasobów wirtualnych w kontrolerze domeny, a nawet jeśli zagrożona jest stacja robocza lub cienki klient, nie można uzyskać żadnego zysku z tego punktu końcowego. Ten typ konfiguracji jest bardziej odpowiedni dla dużych przedsiębiorstw lub środowisk o wysokim poziomie bezpieczeństwa. Pomyślałem, że wyrzucę to jako możliwą odpowiedź. Chodzi o to, że stan bezpieczeństwa fizycznej maszyny, na której znajduje się użytkownik, jest bardzo mały, niezależnie od tego, czy jest zagrożony czy nie. Zasadniczo fizyczne stacje robocze mają dostęp tylko do bardzo ograniczonej liczby zasobów (AD, DHCP, DNS itp.). W tym scenariuszu wszystkie dane i cały dostęp są przyznawane tylko do zasobów wirtualnych w kontrolerze domeny, a nawet jeśli zagrożona jest stacja robocza lub cienki klient, nie można uzyskać żadnego zysku z tego punktu końcowego. Ten typ konfiguracji jest bardziej odpowiedni dla dużych przedsiębiorstw lub środowisk o wysokim poziomie bezpieczeństwa. Pomyślałem, że wyrzucę to jako możliwą odpowiedź. Chodzi o to, że stan bezpieczeństwa fizycznej maszyny, na której znajduje się użytkownik, jest bardzo mały, niezależnie od tego, czy jest zagrożony czy nie. Zasadniczo fizyczne stacje robocze mają dostęp tylko do bardzo ograniczonej liczby zasobów (AD, DHCP, DNS itp.). W tym scenariuszu wszystkie dane i cały dostęp są przyznawane tylko do zasobów wirtualnych w kontrolerze domeny, a nawet jeśli zagrożona jest stacja robocza lub cienki klient, nie można uzyskać żadnego zysku z tego punktu końcowego. Ten typ konfiguracji jest bardziej odpowiedni dla dużych przedsiębiorstw lub środowisk o wysokim poziomie bezpieczeństwa. Pomyślałem, że wyrzucę to jako możliwą odpowiedź. a nawet jeśli zagrożona jest stacja robocza lub cienki klient, z tego punktu końcowego nie można uzyskać żadnego zysku. Ten typ konfiguracji jest bardziej odpowiedni dla dużych przedsiębiorstw lub środowisk o wysokim poziomie bezpieczeństwa. Pomyślałem, że wyrzucę to jako możliwą odpowiedź. a nawet jeśli zagrożona jest stacja robocza lub cienki klient, z tego punktu końcowego nie można uzyskać żadnego zysku. Ten typ konfiguracji jest bardziej odpowiedni dla dużych przedsiębiorstw lub środowisk o wysokim poziomie bezpieczeństwa. Pomyślałem, że wyrzucę to jako możliwą odpowiedź.

Po prostu wyłącz monit o wyświetlanie klawiszy lepkich po naciśnięciu klawisza Shift 5 razy. Gdy nazwa CMD zostanie zmieniona na SETHC, nie pojawi się. Rozwiązany.

Win7:

1. Start> wpisz „zmień sposób działania klawiatury”
2. Kliknij pierwszą opcję
3. Kliknij skonfiguruj lepkie klucze
4. Odznacz włącz lepkie klawisze, gdy Shift jest wciśnięty 5 razy.

Naprawdę nie musisz mieć dysku Windows ani obrazu na dysku USB, aby exploit działał. Próbuję powiedzieć, że wyłączenie uruchamiania komputera z innego napędu niż wewnętrzny dysk systemowy nie uniemożliwi wykonania exploita. To obejście polega na zresetowaniu komputera podczas uruchamiania i użyciu naprawy przy uruchamianiu w celu uzyskania dostępu do systemu plików w celu zmiany nazwy CMD na SETHC. Jasne, to jest trudne na dysku, ale jeśli włamujesz się do czyjejś maszyny, to naprawdę cię to nie obchodzi.