Dzień dobry. Dziś chciałbym poruszyć temat bezpieczeństwa sieci lokalnych i pokazać jeden z kilku tzw. low-hanging fruits, po które łatwo sięgnąć gdy znajdziemy się już w interesującym dla nas segmencie sieci:

• LLMNR
• NBNS (NetBIOS Name Service)
• ARP poisoining

Dwa pierwsze protokoły są prawie zawsze włączone w sieciach, które dane było mi testować, jeżeli chodzi o zabezpieczenie tablic ARP to również jest ono realizowane niezwykle rzadko (choć zdarzają się chlubne wyjątki). Generalnie złośliwe wykorzystanie metod identyfikacji hosta (LLMNR i NBNS) jest obszernie opisane w Internecie, więc nie będę tego robić po raz kolejny, chyba, że w komentarzach pojawią się takie prośby. Sam ARP poisoining również doczekał się wielu tutoriali i opisów, więc jego omówienie ograniczę do minimum. Artykuł ten jest również początkiem serii artykułów o Active Directory, ponieważ będziemy już pracować na testowej domenie how2hax.pl. Spróbujemy również połączyć dzisiaj atak ARP poisoining z crackowaniem wiadomości przesyłanych przez protokół Kerberos. Przyjmijmy (póki co skromną) sieć:

Z powyższego schematu widzimy, że atakującemu udało się uzyskać dostęp do sieci LAN w której znajduje stacja robocza WK01 oraz kontroler domeny DC01. Atakujący rozpoczął wysyłanie odpowiedzi ARP zarówno do stacji roboczej jak i do kontrolera domeny, informując obydwa urządzenia, że adresy protokołu warstwy wyższej (w tym przypadku IPv4) jednego i drugiego urządzenia znajdują się pod adresem MAC stacji Kali Linux. Innymi słowy – atakujący poinformował urządzenia w sieci, niejako „krzyżowo”, że powinny nawzajem szukać się pod adresem maszyny atakującego. Aby można było przekazywać pakiety do właściwego adresata, należało jeszcze na maszynie atakującego uruchomić ip forwarding poleceniem:

echo 1 > /proc/sys/net/ipv4/ip_forward

Zauważmy, że atakujący rozpoczął wysyłanie odpowiedzi ARP, mimo, że w sieci nie pojawiło się ani jedno zapytanie o dany adres IP. Efektem takiego działania było zatrucie tablicy ARP zarówno stacji roboczej WK01 oraz kontrolera domeny DC01 i możliwość podsłuchiwania ruchu przez atakującego.

Podsłuchanie ruchu pozwoliło na zaobserwowanie wymiany pakietów związanych z uwierzytelnieniem do domeny. Będąc w domenie, zarówno stacja robocza jak i użytkownik uwierzytelnia się za pomocą protokołu Kerberos. W Internecie znajduje się opis kilku najpopularniejszych metod ataku na protokół Kerberos, wśród nich można wyróżnić:

• AS-REPRoast – ciekawostka do pokazania na hacktheboxowych maszynach. W praktyce nigdy nie spotkałem się z zaznaczoną opcją „Do not require Kerberos preauthentication” przy jakichkolwiek kontach domenowych, a miałem okazje testować już na prawdę egzotyczne rozwiązania.
• Kerberoasting
• Pass-The-Ticket
• Silver Ticket
• Golden Ticket

Nie będę jednak ich omawiał w tym wpisie, nie będę też w szczegółach omawiać Kerberosa, ponieważ te zagadnienia są dość dobrze opisane w innych miejscach, a ponadto zasługują na oddzielny, duży artykuł. Dziś chciałbym pokazać jak można spróbować odzyskać hasło użytkownika na podstawie przechwyconego pakietu AS-REQ. Ważna uwaga – do domeny uwierzytelnia się również stacja robocza, więc weźmy pod uwagę zawartość pola „cname”, a dokładnie pola „CNameString” (niewidocznych na poniższym zrzucie ekranu), która powinna zawierać nazwę użytkownika, który próbuje się uwierzytelnić. W przypadku konta stacji roboczej pole zawierałoby wartość „$wk01”.

Czym jest pakiet AS-REQ? W dużym skrócie – użytkownik uwierzytelniający się w domenie musi uzyskać od KDC – Key Distribution Center ticket TGT – Ticket Granting Ticket. AS-REQ jest właśnie zapytaniem o TGT. Request ten zawiera znacznik czasu zaszyfrowany hashem hasła użytkownika, odpowiedź AS-REP natomiast zwraca bilet TGT zaszyfrowany hashem hasła użytkownika krbtgt oraz tzw. session key zaszyfrowany hashem hasła użytkownika. Poniżej przedstawiam mocno uproszczony schemat działania protokołu Kerberos.

Z przechwyconego pakietu AS-REQ możemy odczytać z jakiego algorytmu skorzystano podczas tworzenia zaszyfrowanego znacznika czasu. W przypadku pokazanym wyżej jest to eTYPE-AES256-CTS-HMAC-SHA1-96 (18). Hashcat posiada odpowiedni tryb w swojej bazie^[1].

Na podstawie formatu z manuala programu Hashcat stworzono hash zawierający w sobie dane z przechwyconego pakietu AS-REQ i uruchomiono program hashcat z uzupełnioną o hasło listą „rockyou.txt”. Na obrazku poniżej widzimy, że hashcat nie miał problemów ze złamaniem hasha.

Widzimy, że udało się odzyskać hasło użytkownika „u.testowy”. Prawdopodobnie nie udałoby się to, gdyby sieć lokalna była zabezpieczona przez arp-spoofingiem/arp-poisoningiem oraz gdyby użytkownik „u.testowy” stosował bardziej skomplikowane hasło. Dwie podstawowe metody na obronę przed arp-poisoningiem to

• Dynamic ARP inspection
• Statyczne tablice ARP

O ile to drugie rozwiązanie jest uciążliwe, wymaga od administratora dużego nakładu pracy i zdecydowanie utrudnia skalowanie, to pierwsze jest dobrą metodą na przeciwdziałanie zatruciom tablicy ARP. Izolacja podsieci nie jest najskuteczniejszym rozwiązaniem, ponieważ ARP poisoning jest tak samo skuteczny przeciwko końcowym stacjom roboczym jak również przeciwko routerom czy innym urządzeniom pełniącym rolę bramy.

Chciałbym, żeby ten krótki wpis pokazał nam jak ważne jest zabezpieczenie sieci lokalnych. W domenie rozgłoszeniowej domyślnie działa wiele serwisów umożliwiających atakującemu przechwycenie wielu wrażliwych informacji, które w konsekwencji mogą prowadzić do kompromitacji sieci i systemów. Hardening sieci lokalnej oraz procedura dostępu do niej (802.1X!) jest niezbędnym elementem zabezpieczenia każdej infrastruktury IT.

W kolejnym artykule na omówię i przetestuje narzędzia do audytu infrastruktury AD: BLoodHound oraz Ping Castle. Pokażę również jak korzystać z modułu PowerView z narzędzia PowerSploit.

[1] https://hashcat.net/wiki/doku.php?id=example_hashes