W końcu są wyniki egzaminów beta... Jak pewnie wiele osób, również mam je zaliczone. :)

No i teraz muszę podejść do następnego egzaminu (z Visty: 70-620), żeby Enterprise Administrator się uprawomocnił. :) Już chyba wiem na co wykorzystam voucher wygrany w quizie. ;)

Aktorzy: gsecdump, msvctl, psexec.

Czyli po prostu ekspresowa eskalacja uprawnień. Oczywiście jak zawsze, muszą zostać spełnione pewne warunki. :)
Najprostszy scenariusz zakłada, że:

1. Mamy dostęp na poziomie lokalnego admina do komputera w domenie. Niestety wciąż zbyt często nie stanowi to żadnego problemu, gdy np. szeroko stosowaną praktyką jest dodanie Domain Users do grupy lokalnych administratorów. "Bo wtedy wszystko działa!" ;)

2. Na tej stacji chociaż raz zalogowane było konto należące do grupy Domain Admins.

Jeżeli nawet żaden DA (Domain Admin) nie był zalogowowany na komputerze do którego mamy dostęp, to zawsze możemy zacząć od hasza wbudowanego konta lokalnego administratora. Jakie jest prawdopodobieństwo tego, że w sieci hasło lokalnego administratora jest inne na każdej stacji? Minimalne. Często będzie ono takie samo również na serwerach. W ten sposób szybko można wejść w posiadanie hasza DA.

A więc:

1. jako admin na stacji: gsecdump -a
2. msvctl haszNależącyDoDomainAdmins run cmd
3. w nowym oknie cmd: psexec -s \\domain_kontroller -c gsecdump.exe -s

W ten sposób weszliśmy w posiadanie wszystkich haszy w domenie i możemy "podszyć się" pod każde z nich. Proponuję sprawdzić pod tym kątem swoją sieć. Oczywiście tylko jeżeli mamy na to pozwolenie. :)

Jak można się przed tym bronić? Przede wszystkim NIE DAJEMY UŻYTKOWNIKOM PRAW LOKALNEGO ADMINISTRATORA! Ogromna poprawa bezpieczeństwa i równocześnie znacznie więcej na naszej głowie. ;) W innym przypadku... ciężko...

Można zwiększyć nieco odporność na tego typu atak...

Przede wszystkim nie logować się gdzie popadnie z kont należacych do Domain Admins i w ogóle ograniczyć do minimum korzystanie z takich kont. Jeżeli już zaistnieje potrzeba logowania DA, to można robić to na wyznaczonej do tego stacji.
Rozumiem, że inne hasło lokalnego admina na każdym komputerze jest często nierealne, ale co z serwerami? ;-)

Dodatkowo - moim zdaniem - całkiem niezłym pomysłem może być odizolowanie od siebie komputerów użytkowników sieci poprzez zastosowanie np. IPsec i włączenie lokalnego firewalla. Tutaj akurat możemy wygrać znacznie więcej niż tylko zmniejszenie efektywności programów z rodziny "Pass-The-Hash". Skutecznie zminimalizuje to również zagrożenia płynące ze strony różnych wirusów i robaków korzystających z sieci do rozprzestrzeniania się.

No i oczywiście SRP (Software Restriction Policies) ze standardowym poziomem zabezpieczeń ustawionym na Disallowed. Wtedy user nie będzie mógł zbyt łatwo skorzystać między innymi z wymienionych powyżej narzędzi. Dzięki implementacji SRP również zyskamy DUŻO więcej niż tylko ochronę przed gsecdump. :)

Nie wyeliminuje to całkiem zagrożenia, ale z pewnością je utrudni. W sumie sam jestem ciekaw, jak najskuteczniej bronić się przed takim atakiem. :-)

Jedną ze zmian związanych z GPO w systemach Windows Server 2008 i Windows Vista jest koncepcja katalogu centralnego (Central Store). Central Store jest po prostu katalogiem przechowywanym w udziale SYSVOL, w którym znajdują się wszystkie pliki szablonów administracyjnych (ADMX i ADML) w obrębie domeny.

Po uruchomieniu GPMC na Windows Server 2008 lub Windows Vista, pierwszym miejscem z którego nastąpi próba załadowania szablonów, będzie właśnie central store. W przypadku gdy system stwierdzi jego brak, kieruje się do lokalnych zasobów.

To rozwiązanie ma uporać się (między innymi) z kilkoma niedogodnościami charakterystycznymi dla procesu tworzenia i zarządzania politykami grup w systemach Windows 2000/XP/2003.

Jedną z tych niedogodności może być wzmożony ruch sieciowy związany z replikacją szablonów ADM. Inną, miejsce zarezerwowane na ich składowanie na kontrolerach domeny. Jeszcze inna niespodzianka czekała na nas, gdy dokonywaliśmy edycji GPO z systemów różniących się wersją językową. Poza tym, w sytuacjach gdy siecią zarządzała większa ilość Administratorów, mogły występować problemy z dokładnym określeniem, którą dokładnie wersję szablonu właśnie poddaliśmy edycji.

Do tej pory, w momencie utworzenia GPO, na SYSVOL zostawał zakładany katalog z GUID nowej GPO w nazwie. Nie zawierał on jednak jeszcze na tym etapie katalogu ADM w którym przechowywane  były szablony administracyjne. Kopiowanie następowało dopiero w momencie gdy dane GPO zostało otwarte w GPOE (Group Policy Object Editor).

Zestaw szablonów dla jednej GPO, to niecałe 4MB. Przy ok. pięćdziesięciu GPO, mówimy już o konieczności replikacji ok. 200 MB. W sytuacjach gdy lokacje w obrębie jednej domeny połączone są przy pomocy niezbyt wydajnych łącz, lub gdy łącza te są po prostu intesywnie wykorzystywane, rozmiar SYSVOL może mieć dość istotne znaczenie.

Jak już wspomniałem na początku, central store jest reprezentowany przez katalog o nazwie PolicyDefinitions w udziale sysvol na kontrolerach domeny. Cały proces tworzenia CS jest bardzo prosty...

1. Na kontrolerze domeny (preferowany jest tutaj DC pełniący rolę PDC Emulator, gdyż to właśnie do tego DC standardowo łączy się GPMC i GPOE), w poniższej ścieżce tworzymy główny katalog w którym składowane będą wszystkie szablony ADMX:

%systemroot%\sysvol\domain\policies\PolicyDefinitions

2. Tworzymy podfoldery dla wersji językowych plików ADML. Nazwy folderów nie są dowolne i możemy je znaleźć np. na liście Valid Locale Identifiers.

3. Kopiujemy pliki .admx z Visty (lub z Windows Server 2008) do folderu PolicyDefinitions na SYSVOL:

copy %systemroot%\PolicyDefinitions\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\

4. Kopiujemy pliki .adml do odpowiednich podfolderów utworzonych w katalogu PolicyDefinitions na SYSVOL:

copy %systemroot%\PolicyDefinitions\[MUIculture]\* %logonserver%\sysvol\%userdnsdomain%\policies\PolicyDefinitions\[MUIculture]\

Efekt końcowy powinien przedstawiać się następująco:

Powyższą procedurę musimy wykonać tylko raz, na jednym DC. Oczywiście konto użytkownika z którego będziemy wykonywać te kroki, musi być członkiem grupy Domain Administrators. Resztę zrobi za nas FRS (lub ewentualnie DFSR, jeżeli poziom funkcjonalny domeny został podniesiony do Windows Server 2008 i dokonaliśmy zmiany sposobu replikacji), który synchronizuje zawartość udziału sysvol na wszystkich kontrolerach w domenie.

Dodatkowa korzyść płynąca z posiadania magazynu centralnego w domenie, to łatwe udostępnianie i korzystanie z niestandardowych plików admx, które po skopiowaniu do CS, staną się automatycznie dostępne dla wszystkich osób administrujących GPO w naszej domenie.

Musimy pamiętać o tym, że od tej pory, edycji GPO powinniśmy dokonywać tylko z sytemów Windows Vista i Windows Server 2008. W innym przypadku, do katalogu edytowanej GPO znajdującym się na sysvol, skopiowany zostanie zestaw plików .adm.

W sytuacji gdy z jakichś powodów katalog PolicyDefinitions będzie niedostępny, wtedy Windows Vista i Windows Server 2008 automatycznie zaczną korzystać z plików .admx i .adml przechowywanych lokalnie.

Dobrze wiedzieć, że człowiek nie jest osamotniony w bólu... ;)
A ja mam tylko jakieś marne 1200+ nieprzeczytanych wpisów w Google Readerze. :) Pełnia szczęścia. ;)
http://blog.joeware.net/2008/03/13/1088/

Przyznaję, że wiadomość już może nie jest najświeższa, ale....

Kilka miesięcy temu pisałem o ciekawej prezentacji "Why I Can Hack Your Network in a Day!". Marcus Murray do zabawy z przekazywaniem haszy LM korzystał z MSVCTL. Jeżeli ktoś przegapił, to dobrze wiedzieć, że od października 2007, program ten jest dostępny publicznie.

http://truesecurity.se/blogs/murray/archive/2007/10/01/pass-the-hash-tool-msvctl-released-to-public.aspx

Poniżej dwa screeny. Pierwszy z laptopa (Host) na którym zainstalowany jest system Vista x64, a drugi został zrobiony na systemie wirtualnym w VMware Workstation (oczywiście na tym samym laptopie). Również Vista x64. Według Windows Experience Index dysk dostaje niezłego kopa na VM. ;)

Host:

Virtual Machine: