Kontynuując temat słabych haseł, dziś przedstawię Ci darmowy sposób na weryfikację, czy hasło Twojego pracownika nie wyciekło. Jest to coś, czego opisywane przeze mnie wcześniej Azure AD Microsoft Entra Password Protection nie potrafi.
Brzmi świetnie? Jasne, ale zanim zaczniemy mały disclaimer.
Przeczytaj mnie, zanim Cię zwolnią!
Zamierzasz zrobić coś, co może być potraktowane jako incydent bezpieczeństwa. Dlatego przed grzebaniem na produkcji, konieczne uzyskaj zgodę na takie działania. Jeśli zdarzy się, że ktoś nieoczekiwanie zaakceptuje Twoją prośbę, to podjedź do tematu z głową i działaj w odizolowanym środowisku, pozbawionym połączenia z Internetem. To bardzo ważne, ponieważ naprawdę nie chcesz, aby kopie Twoich skrótów haseł, czy baza Active Directory wylądowały w darkweb.
Jaki jest plan?
Naszym celem jest porównanie skrótów haseł z lokalnej domeny Active Directory z tymi, które zostały już ujawnione w wyciekach. Jeśli odnajdziemy konta, dla których skróty się pokryją, to konieczne będzie natychmiastowe wymuszenie zmiany hasła takiego konta oraz przeprowadzenie obowiązkowego szkolenia z zakresu bezpieczeństwa dla jego właściciela.
Co potrzebujemy?
Do naszego małego audytu będziemy potrzebować:
- Pozwolenia Twojego przełożonego na wykonanie opisywanych tu działań
- Bazy danych Have I Been Pwned
- Bazy danych Active Directory
- Modułu PowerShell DSInternals
- Odizolowanego środowiska (VM), na którym będziemy działać
Przygotowania
Pobieranie bazy danych Have I Been Pwned
Bazę danych skrótów NTLM haseł z wycieków pobierzemy od Have I Been Pwned, za pomocą ich narzędzia PwnedPasswordsDownloader.
Instrukcja
Pobieramy i instalujemy .NET 6.0 na maszynie, która ma połączenie z Internetem.
Następnie za pomocą CMD instalujemy narzędzie PwnedPasswordsDownloader.
|
|
Uruchamiamy nasz “pobieracz” i zapisujemy bazę haseł do pliku txt.
|
|
Baza waży około 29GB i będzie pobierać się kilka minut/godzin/dni w zależności od prędkości Twojego łącza internetowego.
Po pobraniu skopiuj plik pwnedpasswords_ntlm.txt na maszynę, na której będziesz wykonywał porównanie.
Zapis modułu DSInternals do pliku
Do analizy haseł naszych pracowników wykorzystamy narzędzie DSInternals. Nasza maszyna wirtualna, na której będziemy wykonywać porównanie, nie będzie miała dostępu do Internetu, dlatego musimy pobrać moduł na inne urządzenie i skopiować go na docelową VM.
Instrukcja
Uruchamiamy PowerShell i zapisujemy moduł poleceniem Save-Module
|
|
Kopiujemy katalog DSInternals z folderu tymczasowego C:\Temp na docelową maszynę.
Eksport bazy danych Active Directory
Ostatnią rzeczą na naszej liście jest kopia bazy danych Active Directory, czyli plik ntds.dit oraz klucz służący do jej odszyfrowania tzw. BootKey/SysKey.
Instrukcja
Domyślnie plik ntds.dit jest ciągle wykorzystywany przez nasz kontroler domeny, dlatego nie możemy go tak po prostu skopiować.
W Internecie dostępnych jest kilka sposobów skopiowane tego pliku. Ja wybrałem wariant wykorzystujący Volume Shadow Copy (VSSAdmin), ponieważ nie wymaga on instalowania ani pobierania żadnych zewnętrznych aplikacji czy narzędzi.
Uruchamiamy CMD i tworzymy nowe shadow copy:
|
|
Następnie kopiujemy plik ntds.dit z utworzonego shadow copy:
|
|
Plik został skopiowany do folderu C:\Temp. Teraz możemy po sobie posprzątać. Usuwamy utworzoną kopię poleceniem:
|
|
Do odszyfrowania naszego pliku ntds.dit potrzebować będziemy jeszcze BootKey/SysKey. Pozyskamy go z eksportu rejestru z naszego kontrolera domeny.
Aby wykonać eksport uruchamiamy CMD i wykonujemy polecenie reg.exe SAVE
|
|
Gotowe, skopiuj pliki ntds.dit i SYSTEM.hiv na maszynę, na której będziesz wykonywał porównanie.
Czas na audyt
Checklista
Na naszej maszynie wirtualnej powinnyśmy mieć cztery eksporty:
- Bazę Have I Been Pwned - plik pwnedpasswords_ntlm.txt
- Moduł PowerShell - folder DSInternals
- Bazę Active Directory - plik ntds.dit
- Kopię rejestru z kontrolera domeny - plik SYSTEM.hiv
Jeśli odhaczyłeś wszystkie rzeczy z listy, to możemy zaczynać porównywanie.
Import DSInternals
Aby “zainstalować” pobrany wcześniej moduł PowerShell, wystarczy skopiować folder DSInternals do katalogu C:\Program Files\WindowsPowerShell\Modules
.
Następnie za pomocą polecenia Get-Module
sprawdzamy, czy nasz moduł został odnaleziony.
|
|
Pierwsza próba wykonania audytu
Gdy już mamy wszystkie elementy na miejscu możemy zacząć audyt naszych haseł. Wykonujemy go za pomocą poleceń Get-ADDBAccount
oraz Test-PasswordQuality
, które są częścią modułu DSInternals.
|
|
Cóż nie spodziewałem się takiego rezultatu…
Wychodzi na to, że musimy naprawić naszą bazę danych AD przed ponowną próbą wykonania porównania. No cóż, takie życie, nie wszystko wychodzi za pierwszym razem 🙃
Naprawa pliku ntds.dit
Wracamy do kopii zapasowej naszego kontrolera domeny i uruchamiany wiersz poleceń. Na początku chcemy sprawdzić, czy faktycznie nasza baza danych jest uszkodzona. Do tego celu wykorzystamy wbudowane narzędzie ESENTUTL.
|
|
Wygląda na to, że z uszkodzoną bazą Active Directory da się żyć 🙂
Niestety do naszego małego audytu potrzebujemy sprawnej bazy dlatego spróbujemy ją naprawić.
|
|
Potwierdziliśmy wcześniej, że nasz plik ntds.dit jest uszkodzony, dlatego świadomie akceptujemy ostrzeżenie i kontynuujemy działania naprawę.
Sukces! Udało się nam. Baza została naprawiona. Dla pewności sprawdźmy raz jeszcze jej integralność.
|
|
ESENTUTL tym razem nie zwrócił już żadnych błędów. Możemy raz jeszcze spróbować wykonać nasz audyt haseł.
Druga próba wykonania audytu
Podmieniamy nasz uszkodzony plik ntds.dit na naprawioną kopię i ponownie wykonujemy polecenia.
|
|
Tym razem otrzymaliśmy wynik polecenia bez zbędnych błędów. Pora na analizę wyników.
Wyniki
Przed przystąpieniem do wykonywania poleceń specjalnie przygotowałem konta, które DSInternals “powinien” oflagować. Konta te miały ustawione hasła oznaczone przez Have I Been Pwned jako pwned!.
Całość wygenerowanego raportu znajduje się poniżej:
|
|
Jakie z tego możemy wyciągnąć wnioski?
W naszej domenie 5 użytkowników posiada hasła, które były już częścią wycieków i znajdowały się w bazie Have I Been Pwned. Hasło dla takich kont powinno zostać jak najszybciej zresetowane.
Użytkownik
good.boy1
to oszust. Próbował zgrywać tego dobrego, aby nas zmylić. Jak widać, nie udało mu się nas przechytrzyć!Mamy jedną grupę użytkowników, którzy z jakiegoś powodu posiadają identyczne hasła. Czyżby to ten sam użytkownik posiadał dwa konta w AD a może to cudowny zbieg okoliczności?
Trzech użytkowników w ogóle nie musi zmieniać haseł, ignorując naszą politykę haseł. Dla ciekawskich konto MSOL_XYZ to konto serwisowe usługi AD Connect.
Oczywiście, jak widać, cały raport zawiera więcej detekcji niż te które opisałem. Szczegółowy opis polecenia Test-PasswordQuality
dostępny jest w seriwsie GitHub DSInternals.
Podsumowanie
Czy było warto?
Moim zdaniem zdecydowanie tak! Pomimo drobnych problemów z plikiem ntds.dit, udało nam się wykryć potencjalną możliwość przejęcia kont użytkowników Active Directory, co mogło mieć poważne konsekwencje. Oczywiście cała operacja również mogła doprowadzić do wycieku danych, gdyby nie została przeprowadzona w kontrolowanym środowisku…
Czy da się to jakoś zautomatyzować?
Tak, polecenia Get-ADDBAccount
i Test-PasswordQuality
mogą działać na produkcyjnej bazie danych Active Directory, w oparciu o specjalnie przygotowane konto serwisowe. Z kolei bazę Have I Been Pwned możemy okresowo aktualizować. Jednak zabezpieczenie tego procesu może być bardzo trudne i wymagać wielu audytów.
A może jest jakaś usługa, która będzie robić to za nas skutecznie i bezpiecznie?
No cóż, Microsoft ma taką usługę, która jest w planie Azure AD Premium P2 Microsoft Entra ID P2, ale to temat na kolejny wpis 🤫
Miłej zabawy z Waszymi testami.