Nowa luka typu LPE (lokalna eskalacji uprawnień) umożliwia podniesienie uprawnień zwykłego użytkownika do administratora, poprzez uzyskanie dostępu do poufnych plików bazy danych rejestru systemowego. Podatne są systemy Windows 10 i 11. Sprawdź, czy też jest podatny Twój system.
O tym, że Microsoft zmaga się ostatnio z problemami związanymi z odkrywanymi podatnościami w systemie Windows mogliśmy się przekonać na podstawie ostatniej, opisywanej w zeszłym tygodniu podatności 0-day o nazwie PrintNightmare. Opisywana w tym artykule luka spędza sen z powiek działom bezpieczeństwa i administratorom w firmach, ponieważ jej wykorzystanie jest bardzo proste. Zobaczcie jak, poniżej.
Co to jest rejestr systemowy Windows?
Rejestr systemu Windows działa jako repozytorium konfiguracji systemu operacyjnego Windows i zawiera zaszyfrowane hasła, kastomizację profilu użytkownika, opcje konfiguracji aplikacji, klucze odszyfrowywania systemu i wiele innych danych, które powinny być należycie chronione. Może być on także zdalnie konfigurowany poprzez zasady grupy – GPO, jeśli w firmie wdrożona jest usługa katalogowa Active Directory.
Baza rejestru systemowego umiejscowiona jest lokalnie w Windows w specjalnych plikach przechowywanych w zabezpieczonym folderze „C:\Windows\system32\config” i podzielona na różne pliki, takie jak SYSTEM, SECURITY, SAM, DEFAULT i SOFTWARE.
Ponieważ pliki te zawierają poufne informacje o wszystkich kontach użytkowników na urządzeniu i tokenach zabezpieczających używanych przez funkcje systemu Windows, powinny być niedostępne dla zwykłych użytkowników bez podwyższonych uprawnień.
Powyższe stwierdzenie dotyczy zwłaszcza pliku Security Account Manager (SAM), ponieważ zawiera on zaszyfrowane hasła dla wszystkich użytkowników systemu, które cyberprzestępcy mogą wykorzystać do przejęcia tożsamości.
Na czym polega luka?
Dwa dni temu badacz bezpieczeństwa Jonas Lykkegaard odkrył, że pliki rejestru systemu Windows 10 i Windows 11 powiązane z Menedżerem Kont Zabezpieczeń (SAM) oraz wszystkie inne bazy danych rejestru są dostępne dla grupy „Użytkownicy” (Users), która ma niskie uprawnienia na urządzeniu. Każdy użytkownik Windows domyślnie przynależy do tej grupy.
Możecie się o tym przekonać wpisując poniższą komendę na Waszym systemie Windows. W naszym przypadku wykonaliśmy ją na w pełni zaktualizowanym systemie Windows 10 20H2.
icacls.exe c:\windows\system32\config\sam
Widzimy na liście grupę „Users” posiadająca uprawnienia Read and Execute, które wystarczą do tego, aby atakujący z ograniczonymi uprawnieniami na urządzeniu mógł wyodrębnić zaszyfrowane hasła NTLM dla wszystkich kont na urządzeniu i użyć tych skrótów w atakach typu pass-the-hash w celu uzyskania podwyższonych uprawnień.
Gdybyśmy normalnie chcieli otworzyć taki plik SAM zostaniemy zablokowani przez system Windows, ponieważ pliki są otwierane i blokowane przez inny program.
Lykkegaard znalazł na to obejście. Jak zauważył, pliki rejestru, w tym SAM, są zwykle archiwizowane przez kopie woluminów w tle systemu Windows (usługa VSS) i dzięki temu można uzyskać do nich dostęp w tle bez naruszenia dostępu (blokady systemu Windows).
Na przykład cyberprzestępcy mogą użyć następującej ścieżki przestrzeni nazw urządzenia Win32 dla poniższych kopii woluminów w tle, aby uzyskać dostęp do pliku SAM przez dowolnego użytkownika na komputerze.
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM
Jeśli dostępna jest kopia w tle dysku systemowego VSS, atakujący posiadający dostęp do zwykłego konta użytkownika bez uprawnień może wykorzystać dostęp do tych plików, aby uzyskać szereg możliwości, w tym między innymi:
- Wyodrębnić i wykorzystać skróty haseł NTLM do konta
- Odkryć oryginalne hasło instalacyjne systemu Windows
- Uzyskać klucze komputera DPAPI, których można użyć do odszyfrowania wszystkich kluczy prywatnych komputera.
- Uzyskać konto komputera, którego można użyć w ataku Silver Ticket.
Wykorzystanie luki w Windows
Oczywiście powyższe odkrycie nie pozostało bez echa w świecie Cybersecurity i natychmiast powstała implementacja POC luki. Korzystając z tak niskich i nieprawidłowych uprawnień do plików (wraz z kopiami plików woluminów w tle łącznie), badacz bezpieczeństwa i twórca Mimikatz, Benjamin Delpy błyskawicznie wdrożył możliwość wydobycia zaszyfrowanego hasła NTLM konta z wysokimi uprawnieniami w systemie. POC jest nagrany na poniższym filmie, w którym Delpy pokazuje jak za pomocą Mimikatz pobiera skrót hasła NTLM w celu uzyskania uprawnień debugowania.
Oprócz kradzieży skrótów NTLM i podnoszenia uprawnień niski, uprzywilejowany dostęp może pozwolić na dalsze ataki, takie jak ataki Silver Ticket.
Co na to Microsoft?
Nie jest jasne, dlaczego Microsoft zmienił uprawnienia w rejestrze systemowym, aby umożliwić zwykłym użytkownikom odczytywanie tych plików. Analityk podatności CERT/CC Will Dormann oraz autor SANS, Jeff McJunkin na Twitterze stwierdzili, że Microsoft wprowadził te zmiany uprawnień w systemie Windows 10 1809. Również podczas instalacji nowej wersji Windows 10 20H2 z czerwca nie było tych uprawnień. Czyżby to było jakieś niedopatrzenie Microsoft? Dlatego nie jest jasne, czy Microsoft naprawił problem z uprawnieniami podczas wykonywania czystej instalacji systemu Windows, ale nie naprawił go podczas aktualizacji do nowych wersji. Powyższa luka otrzymała numer CVE-2021-36934.
Środki zaradcze
UWAGA! Należy pamiętać, że kopie w tle usługi VSS mogą nie być dostępne w niektórych konfiguracjach Windows, jednak samo posiadanie dysku systemowego o rozmiarze większym niż 128 GB, a następnie wykonanie aktualizacji systemu Windows lub zainstalowanie pliku MSI zapewni automatyczne utworzenie kopii w tle usługi VSS.
Aby sprawdzić, czy system ma dostępne kopie w tle usługi VSS, uruchom następujące polecenie z wiersza polecenia uprzywilejowanego (na uprawnieniach administratora):
– vssadmin list shadows
Zalecane jest usunięcie uprawnień grupy „Users” (ograniczenie dostępu do plików bazy SAM, SYSTEM i SECURITY) oraz usunięcie kopii w tle wykonanych za pomocą VSS.
Poniższe polecenia pozwolą pozbyć się problemu na Windows:
– icacls %windir%\system32\config\sam /remove “Users”
– icacls %windir%\system32\config\security /remove “Users”
– icacls %windir%\system32\config\system /remove “Users”
oraz
– vssadmin delete shadows /for=c: /Quiet
Następnie należy sprawdzić, czy poprawnie zostały usunięte kopie w tle usługi VSS, uruchamiając polecenie „vssadmin list shadows”.
Należy pamiętać, że wszelkie funkcje oparte na istniejących kopiach w tle, takie jak Przywracanie Systemu, nie będą działać zgodnie z oczekiwaniami. Nowo utworzone kopie w tle, które będą zawierać odpowiednie listy ACL, będą działać zgodnie z oczekiwaniami.