W poprzednim artykule rozmawialiśmy o tym, w jaki sposób jedną z technik ochrony przed wyodrębnianiem haseł z pamięci systemu Windows za pomocą narzędzi podobnych do mimikatz jest uniemożliwienie administratorom systemu korzystania z zasad grupy programu do debugowania. Jednak niedawno odkryto, że bez uprawnień do debugowania (w systemie Windows jest to przywilej SeDebugPrivilege), administrator lokalnego serwera nie może zainstalować ani zaktualizować Microsoft SQL Server. Faktem jest, że instalator programu SQL Server podczas uruchamiania sprawdza uprawnienia SeSecurity. SeBackup i SeDebug, których potrzebuje do uruchomienia procesu SQL Server i uzyskania informacji o pomyślnym uruchomieniu SQL Server. Tak to wygląda.
Podczas instalacji programu SQL Server podczas wykonywania wstępnych kontroli instalator potknie się o czek Skonfiguruj uprawnienia do konta.
Klikając link „Niepowodzenie”, możesz zobaczyć następujący komunikat:
Konto, na którym działa Instalator programu SQL Server, nie ma jednego lub wszystkich następujących uprawnień: prawo do tworzenia kopii zapasowych plików i katalogów, prawo do zarządzania audytem i dziennikiem bezpieczeństwa oraz prawo do debugowania programów. Aby kontynuować, użyj konta z obydwoma tymi prawami. Aby uzyskać więcej informacji, zobacz https://msdn.microsoft.com/en-us/library/ms813696.aspx, https://msdn.microsoft.com/en-us/library/ms813959.aspx i https: // msdn .microsoft.com / en-us / library / ms813847.aspx.
Teraz otwórz raport instalacji SystemConfigurationCheck_Report.htm.
Jak widać, podczas sprawdzania reguły HasSecurityBackupAndDebugPrivilegesCheck instalator stwierdził, że bieżący proces nie ma jednego z następujących uprawnień:
- SeSecurity - zarządzanie dziennikiem audytu i bezpieczeństwa
- SeBackup - prawa do tworzenia kopii zapasowych plików i katalogów
- SeDebug - prawo do debugowania programów
W dzienniku znajdują się bardziej szczegółowe informacje wskazujące, że proces instalacji nie ma flagi SeDebug:
(09) 2017-09-12 14:25:13 Slp: Reguła inicjująca: Ustaw uprawnienia konta
(09) 2017-09-12 14:25:13 Slp: Reguła zostanie wykonana: Prawda
(09) 2017-09-12 14:25:13 Slp: Obiekt docelowy reguły początkowej: Microsoft.SqlServer.Configuration.SetupExtension.FacetPrivilegeCheck
(09) 2017-09-12 14:25:13 Slp: Reguła „HasSecurityBackupAndDebugPrivilegesCheck” Wynik: Uruchomiony proces ma uprawnienie SeSecurity, ma uprawnienie SeBackup i nie ma uprawnienia SeDebug.
(09) 2017-09-12 14:25:13 Slp: Ocena reguły: HasSecurityBackupAndDebugPrivilegesCheck
(09) 2017-09-12 14:25:13 Slp: Reguła uruchomiona na komputerze: msk-sql10
(09) 2017-09-12 14:25:13 Slp: Ocena reguły wykonana: Nie powiodło się
Postanowiłem poszukać obejścia dla uzyskania praw SeDebugPrivilege bez zmiany lub wyłączenia zasad programów debugowania. Jak się okazało, istnieje dość prosty sposób na obejście tej zasady, jeśli masz uprawnienia lokalnego administratora na serwerze. Narzędzie secedit pomoże nam w tym, umożliwiając zarządzanie politykami bezpieczeństwa lokalnego serwera.
Sprawdź aktualne uprawnienia:
whoami / priv
Jak widać, teraz w tokenie bieżącego użytkownika nie ma uprawnień SeDebugPrivilege .
Eksportujemy bieżące prawa użytkownika skonfigurowane przez zasady grupy do pliku tekstowego:
secedit / export / cfg secpolicy.inf / area USER_RIGHTS
Teraz, za pomocą dowolnego edytora testów, musisz otworzyć plik secpolicy.inf do edycji i dodać wiersz w sekcji [Prawa przywileju], który przyznaje prawa programów debugowania grupie lokalnych administratorów.
SeDebugPrivilege = * S-1-5-32-544
Zapisz plik. Teraz musisz zastosować nowe prawa użytkownika:
secedit / configure / db secedit.sdb / cfg secpolicy.inf / overwrite / area USER_RIGHTS
Teraz musisz uruchomić wylogowywanie / logowanie i używając secpol.msc upewnij się, że prawa do programu debugowania są przypisane do grupy lokalnych administratorów. To samo polecenie whoami / priv potwierdza to:
SeDebugPrivilege Programy debugowania włączone
Możesz teraz rozpocząć instalację / aktualizacje programu SQL Server. Warto jednak pamiętać, że przywilej SeDebugPrivilege w tym przypadku jest przypisywany tylko tymczasowo i zostaną one zresetowane przy kolejnej aktualizacji zasad grupy (ale po wylogowaniu użytkownika).
Jak rozumiesz, włączenie polityki zakazu programów do debugowania nie jest panaceum na uzyskanie uprawnień SeDebugPrivilege przez złośliwe programy, które już weszły na serwer z prawami lokalnego administratora, co może zagrozić wszystkim kontom użytkowników / administratorów pracującym na serwerze.
