Wybrany post: Atak na użytkowników w sieci lokalnej poprzez sfałszowanie komunikacji LLMNR i NBT-NS. Przykład i porady.

W tym artykule przedstawimy ciekawy atak Man-in-the-middle (atak pośredniczący) służący do przejmowania poświadczeń użytkowników. Wciąż popularny i wykonywany w niezabezpieczonej sieci korporacyjnej wykorzystując nieodpowiednio skonfigurowane usługi LLMNR oraz NBT-NS na Windows. Pokażemy, jak go przeprowadzić i na końcu zamieścimy porady jak się przed nim chronić.

Wstęp

Nadal w wielu sieciach korporacyjnych, powszechnym (i łatwym) sposobem na zebranie danych uwierzytelniających użytkowników i zdobycie wstępnego przyczółku atakującego w sieci klienta jest przeprowadzenie ataku Man-in-the-Middle polegającego na sfałszowaniu żądań usługi LLMNR i NBT-NS. Atak ten jest też często wykorzystywany przez pentesterów podczas przeprowadzania testów penetracyjnych sieci. W zależności od tego, jak aktywni są użytkownicy w sieci, może niemal natychmiast dostarczyć cenne informacje cyberprzestępcy. Na szczęście, przy niewielkiej wiedzy, można łatwo się przed nim zabezpieczyć, ale o tym później. Jako ciekawostkę dodamy, że atak ten jest blisko związany ze słabościami mechanizmu/protokołu uwierzytelniania NTLM, o którym pisaliśmy w naszym wcześniejszym artykule tutaj.

Co to jest LLMNR i NBT-NS?

Link-Local Multicast Name Resolution (LLMNR) i NetBIOS Name Service (NBT-NS) to komponenty systemu Microsoft Windows, które są alternatywnymi metodami identyfikacji hosta w przypadku awarii lub braku jego rozpoznania w DNS. LLMNR opiera się na protokole DNS i umożliwia komputerom w tej samej sieci lokalnej rozpoznawać nazwy innych hostów. Zaś NBT-NS rozróżnia hosty w sieci według ich nazwy NetBIOS. LLMNR został wprowadzony w systemie Microsoft Windows Vista i jest następcą NBT-NS.

Oba komponenty są na pozór nieszkodliwe, ponieważ ich zadaniem jest pomaganie innym komputerom w tej samej podsieci w identyfikacji hostów w przypadku awarii DNS. Jeśli więc jeden komputer spróbuje rozpoznać konkretnego hosta, ale rozpoznawanie DNS nie powiedzie się, urządzenie spróbuje następnie zapytać wszystkie inne komputery w sieci lokalnej o prawidłowy adres przez LLMNR lub NBT-NS. Teoretycznie wydaje się to nieszkodliwe, ale otwiera poważną lukę, którą atakujący mogą wykorzystać do uzyskania pełnych danych uwierzytelniających w systemie.

Na czym polega problem?

Atakujący będąc wpięty do tej samej sieci co inne hosty Windows, może sfałszować zapytania LLMNR i NBT-NS poprzez nasłuchiwanie transmisji LLMNR (UDP 5455) lub NBT-NS (UDP 137) przesyłanej przez sieć i odpowiadać na nie. Udaje, że zna lokalizację odpytywanego hosta w zapytaniu i skutecznie podszywa się pod jego fikcyjną usługę, tak aby jego ofiary mogły komunikować się z systemem kontrolowanym przez atakującego. W większości przypadków osoba atakująca może następnie oszukać ofiarę w celu wymuszenia na nim wysłania nazwy użytkownika i hasła w postaci skrótu hasła (hash) w protokole uwierzytelniającym NTLMv2 lub v1 (patrz przykład ze złośliwym plikiem PDF). Przechwytując skrót hasła użytkownika cyberprzestępca uzyskuje dostęp do zasobów sieciowych i może go wykorzystać np. do ataku Pass-the-Hash atakując inne komputery w sieci. Jeśli ofiara zdecyduje się przekazać dane uwierzytelniające, a konto, na którym jest zalogowana do komputera posiada podwyższone uprawnienia, osoba atakująca może przejąć pełną kontrolę nad jego komputerem nawet bez znajomości hasła.

Ten typ scenariusza ataku służącego do uzyskania poświadczeń użytkowników nazywany jest Man-in-the-Middle (MITM) attack i zwykle wykorzystuje protokół SMB (445). Może również używać błędnie skonfigurowaną lub domyślnie skonfigurowaną w Windows usługę proxy WPAD służącą do automatycznego wykrywanie konfiguracji serwera proxy, którą może sfałszować atakujący.

Przykład ataku

Spójrzmy na przykład ataku na poniższym schemacie:

1. Użytkownik (ofiara ataku) klika na link w dokumencie (zobacz scenariusz ataku z użyciem złośliwego PDF) odwołujący się do lokalizacji zasobu komputera w sieci lokalnej np. \\Serwer. Użytkownik nie zauważył błędu w nazwie odnośnika i jego komputer zamiast odwołać się do \\Server przechodzi do błędnie zlokalizowanego komputera w sieci o innej nazwie (Serwer). W tym kroku sprawdzana jest nazwa komputera „Serwer” względem pliku hosts w systemie Windows. Jeśli tej informacji nie ma w pliku hosta, tworzone jest zapytanie do lokalnej pamięci podręcznej DNS. Jeśli pamięć podręczna DNS nie zawiera żądanych informacji, przenosi się na serwer DNS w sieci lokalnej.
2. Serwer DNS odpowiada ofierze, mówiąc, że nie zna tego hosta.
3. Komputer ofiary następnie pyta, czy w sieci lokalnej jest ktoś, kto zna lokalizację serwera \\Serwer. Jeśli serwer DNS nie ma odpowiedniego rekordu, nazwa systemu jest wysyłana jako LLMNR, zapytaniem multicast NetBIOS-NS.
4. Ponieważ zapytanie jest typu multicast, atakujący nasłuchuje ruch sieciowy i przechwytuje zapytania rozpoznawania nazw. Atakujący następnie informuje ofiarę, że system atakującego jest hostem, którego szuka ofiara czyli \\Serwer.
5. Ofiara ufa atakującemu i wysyła do niego własną nazwę użytkownika i skrót hasła (hash) NTLMv2. Atakujący następnie odpowiada na wszystkie zapytania LLMNR i NBT-NS, umożliwiając manipulowanie ruchem w celu uzyskania nazwy użytkownika i skrótu hasła.
6. Atakujący może teraz złamać skrót hasła (hash), wydobywając z niego hasło w postaci tekstu (np. korzystając z narzędzia ) lub wykorzystać ten skrót do zaatakowania innych komputerów w sieci (atak Pass-the-Hash ).

Popularne narzędzia używane do ataku LLMNR i NBT-NS

Popularne używane narzędzia na Linux:

1. Responder – opracowany przez SpiderLabs. Przykład ataku z wykorzystaniem Responder zobaczysz w naszym innym artykule tutaj.
2. Man-in-the-Middle Framework (MiTMf) – Opracowany przez Byt3bl33d3r.
3. LLMNR_Response – Moduł w Metasploit Framework.
4. Nbnspoof – Opracowane przez Roberta McGrew.

Popularne używane narzędzia na Windows:

1. Inveigh – Opracowany przez Kevina Robertsona.

Jak sobie radzić z problemem?

Poniżej zamieściliśmy kroki do wykonania w celu ograniczenia ataku:

1. Wyłącz LLMNR i NBT-NS. Musisz wyłączyć oba, ponieważ jeśli LLMNR jest wyłączony, automatycznie spróbuje użyć NBT-NS. Zobacz instrukcje poniżej.
2. Wyłącz automatyczne wykrywanie serwera proxy w ustawieniach przeglądarki internetowej. Zabezpieczenie przez złośliwym WPAD. Zobacz instrukcje poniżej.
3. Zapobiegaj komunikacji między sieciami VLAN. Ograniczając komunikację między hostami w tej samej sieci, znacznie zmniejszasz skuteczność większości ataków w sieci lokalnej. Stosowanie wydzielonych sieci będzie na pewno dobrym posunięciem.
4. Używaj kont użytkowników z ograniczonymi uprawnieniami– może to nie zapobiegnie to atakowi, ale ograniczy szkody, które może wyrządzić udany atak, a przynajmniej sprawi, że atakujący będzie miał więcej pracy. Na przykład, jeśli ofiara korzysta na komputerze z poświadczeń „administratora domeny” lub „administratora lokalnego”, udany atak umożliwiłby dostęp do wszystkich komputerów w sieci. Z drugiej strony, jeśli ofiara korzysta z ograniczonego konta, atakujący będzie musiał wykonać więcej pracy, aby uzyskać dalszy dostęp do środowiska.
5. Wdróż oprogramowanie wykrywające fałszowanie LLMNR / NBT-NS.
6. Monitoruj ruch sieciowy dla UDP 5355 i UDP 137, jeśli korzystasz z LLMNR / NetBIOS.
7. Monitoruj wpis w rejestrze „HKLM\Software\Policies\Microsoft\Windows NT\ DNSClient” pod kątem zmian wartości DWORD „EnableMulticast”. Wartość „0” oznacza, że LLMNR jest wyłączony.
8. Wdróż system do zaawansowanego monitorowania logowań użytkowników w sieci i zagrożeń z tym związanych, w szczególności pod kątem ruchu bocznego i ataków na konta użytkowników.

Uwaga! Zastosowanie wymienionych poniżej konfiguracji nie powinno mieć negatywnego wpływu w większości środowisk, jednak zastosuj te ustawienia w środowisku testowym przed wdrożeniem do sieci produkcyjnej. Windows 2000 i nowsze wersje mogą wymagać, aby ustawienia te pozostawały niezmienione w zależności od środowiska.

Porady i kroki do wykonania

1. Wyłączenie LLMNR i NBT-NS na komputerach w sieci

W celu ograniczenia ataku LLMNR i NBT-NS należy wykonać zmianę w ustawieniach GPO lokalnego lub domenowego w AD:

1. Kliknij “Start”.
2. Wpisz “gpedit.msc” w polu tekstowym.
3. Przejdź do lokalnych zasad komputera -> Konfiguracja komputera -> Szablony administracyjne -> Sieć -> Klient DNS.
4. W folderze klienta DNS kliknij dwukrotnie „Wyłącz rozpoznawanie nazw multicast” i ustaw na „Włączone”.

Ustawienie wprowadza modyfikację następującego klucza w rejestrze systemowym na komputerach (wyłączy LLMNR) “HKLM\Software\Policies\Microsoft\Windows NT\DNSClient” „EnableMulticast” DWORD wartość „0”

2. Wyłączenie usługi nazw NetBIOS na komputerze.

W celu wyłączenia obsługi nazw NetBIOS na jednym komputerze:

1. Otwórz Panel sterowania.
2. W sekcji „Sieć i Internet” kliknij „Wyświetl stan sieci i zadania”.
3. Kliknij „Zmień ustawienia adaptera”.
4. Kliknij prawym przyciskiem myszy „Połączenie lokalne”, a następnie kliknij „Właściwości”.
5. Kliknij dwukrotnie „Protokół internetowy w wersji 4 (TCP/IPv4)”, kliknij „Zaawansowane”, a następnie kliknij kartę „WINS” (Windows Internet Name Service).
6. Kliknij „Wyłącz NetBIOS przez TCP/IP”.

3. Wyłączenie obsługi nazw NetBIOS w domenie z klientami DHCP

W celu wyłączenia obsługi nazw NetBIOS w domenie z klientami DHCP:

1. Przejdź na serwerze DHCP do przystawki mmc DHCP.
2. Przejdź do „opcji zakresu” dla zmienianej sieci.
3. Kliknij prawym przyciskiem myszy na „Configure options”.
4. Wybierz kartę Zaawansowane i zmień opcję „Vendor class” na „Microsoft Windows 2000 Options”.
5. W polu „Available Options” wybierz i zaznacz pole „001 Microsoft Disable Netbios Option”.
6. W ramce „Data Entry” zmień wpis danych na „0x2”.
7. Kliknij „OK”. Nowe ustawienia będą obowiązywać, gdy klienci odnowią swoje adresy.

Więcej szczegółów pod linkiem Microsoft.

4. Zabezpieczenie przed atakiem na WPAD

Utwórz wpis DNS dla WPAD, który wskazuje na wewnętrzny serwer proxy, aby osoba atakująca nie mogła manipulować ruchem. Wyłącz „Autodetect Proxy Settings” w Internet Explorerze za pomocą zasad grupy.

Zachęcamy do dyskusji, udostępniania i dzielenia się z nami opinią na portalu LinkedIn oraz Facebook.

Artykuł sponsorowany przez Veracomp – Exclusive Networks Poland SA i Tenable – właściciela oprogramowania Tenable.ad.