Niezałatana luka w Windows Search URI umożliwia wyciek skrótów NTLMv2

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili podatność w mechanizmie obsługi schematu URI search: w systemie Windows, która może prowadzić do wycieku skrótów Net-NTLMv2. Problem polega na tym, że odpowiednio przygotowany link może skłonić system do nawiązania połączenia SMB z hostem kontrolowanym przez atakującego, co skutkuje ujawnieniem materiału uwierzytelniającego użytkownika.

Choć luka nie prowadzi bezpośrednio do zdalnego wykonania kodu, jej znaczenie operacyjne jest wysokie. Przechwycone skróty mogą zostać wykorzystane w dalszych etapach ataku, w tym do relay attack, prób łamania offline oraz ruchu bocznego w środowisku domenowym.

W skrócie

Podatność dotyczy obsługi search: URI w Windows.
Atak może wymusić połączenie SMB do ścieżki UNC wskazanej przez przeciwnika.
Skutkiem jest ujawnienie skrótu Net-NTLMv2 ofiary.
Luka wpisuje się w szerszą klasę problemów związanych z handlerami URI w Windows.
Wobec braku skutecznej poprawki kluczowe stają się działania kompensacyjne.

Kontekst / historia

Nowy przypadek nie jest odosobniony. W poprzednich latach opisywano już podobne problemy w innych komponentach Windows, gdzie nieprawidłowa walidacja parametrów przekazywanych do handlerów URI pozwalała inicjować połączenia do zdalnych zasobów UNC. Pokazuje to, że nie chodzi wyłącznie o pojedynczy błąd w jednym module, lecz o szerszą klasę ryzyk wynikających z łączenia lokalnych funkcji systemowych z danymi pochodzącymi z niezaufanych źródeł.

W tym przypadku istotną rolę odgrywa parametr crumb=location:, który może zostać użyty do wskazania zdalnej lokalizacji. Taki mechanizm był już wcześniej analizowany przez badaczy w kontekście wycieku poświadczeń, a obecne doniesienia potwierdzają, że znane techniki nadal znajdują nowe powierzchnie ataku w natywnych funkcjach systemu Windows.

Analiza techniczna

Sedno podatności sprowadza się do tego, że handler search: akceptuje parametry mogące wskazywać lokalizację zasobu w postaci ścieżki UNC, na przykład \\host\share. Jeśli użytkownik uruchomi odpowiednio spreparowany link, system może spróbować uzyskać dostęp do wskazanego udziału przez SMB. W środowiskach, w których nadal wykorzystywany jest NTLM, taka próba uwierzytelnienia powoduje przesłanie odpowiedzi Net-NTLMv2 do serwera kontrolowanego przez atakującego.

W praktyce oznacza to, że przeciwnik nie musi dostarczać ofierze pliku wykonywalnego ani bezpośrednio uruchamiać złośliwego kodu. W wielu scenariuszach wystarczy kliknięcie odnośnika osadzonego w wiadomości e-mail, dokumencie lub na stronie internetowej, o ile użytkownik zgodzi się na uruchomienie odwołania URI.

Przechwycony skrót Net-NTLMv2 może następnie zostać użyty do dalszych działań ofensywnych.

Prób łamania hasła offline, jeśli polityka haseł jest słaba.
Ataków NTLM relay przeciwko usługom wewnętrznym.
Eskalacji dostępu w środowiskach z nieprawidłowo skonfigurowanym SMB.
Wsparcia rozpoznania i ruchu bocznego w sieci organizacji.

Z punktu widzenia obrony szczególnie istotne jest to, że exploit nie wymaga skomplikowanej interakcji z systemem ofiary. Wystarczy doprowadzić do wygenerowania uwierzytelnionego połączenia SMB do infrastruktury przeciwnika, co czyni tę klasę podatności wyjątkowo użyteczną w kampaniach phishingowych oraz ukierunkowanych operacjach kradzieży poświadczeń.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest wyciek skrótów Net-NTLMv2, które w wielu organizacjach nadal stanowią cenny materiał operacyjny dla atakujących. W środowiskach utrzymujących NTLM ze względów kompatybilności już samo przechwycenie skrótu może wystarczyć do przeprowadzenia skutecznego relay attack bez poznania hasła w formie jawnej.

Ryzyko szczególnie rośnie tam, gdzie środowisko nie zostało odpowiednio utwardzone.

Dozwolony jest wychodzący ruch SMB do internetu lub niekontrolowanych segmentów.
Nie jest wymuszane SMB signing.
NTLM pozostaje szeroko wykorzystywany.
Użytkownicy mogą uruchamiać schematy URI z poziomu poczty i przeglądarki.
Brakuje monitoringu połączeń SMB do nietypowych adresów.

Dla zespołów SOC i administratorów oznacza to konieczność traktowania problemu jako zagrożenia dla bezpieczeństwa poświadczeń, a nie jedynie jako błędu funkcjonalnego. Nawet bez RCE luka może stać się punktem wejścia do przejęcia tożsamości użytkownika i rozwinięcia pełnoskalowego incydentu.

Rekomendacje

W sytuacji braku skutecznej poprawki organizacje powinny skupić się na działaniach kompensacyjnych ograniczających powierzchnię ataku. Kluczowe znaczenie mają zarówno kontrole sieciowe, jak i ograniczenia dotyczące sposobu inicjowania połączeń do zasobów UNC.

Blokować wychodzący ruch SMB, zwłaszcza na portach TCP 445 i 139.
Wymuszać SMB signing, aby ograniczyć skuteczność ataków relay.
Stopniowo wyłączać NTLM tam, gdzie pozwala na to zgodność aplikacyjna.
Monitorować uruchamianie nietypowych schematów URI i powiązane zdarzenia procesów.
Wykrywać połączenia SMB do zewnętrznych lub nieznanych hostów.
Wzmacniać ochronę poczty i przeglądarek przed phishingiem wykorzystującym odwołania URI.
Ograniczać możliwość inicjowania połączeń do zasobów UNC z kontekstu aplikacji użytkownika.
Prowadzić szkolenia uświadamiające dotyczące nieoczekiwanych linków uruchamiających funkcje systemowe.

Z perspektywy detekcji warto korelować zdarzenia otwierania handlerów URI z następującymi po nich próbami połączeń SMB. W środowiskach EDR przydatne może być także wyszukiwanie ciągów zawierających search: oraz crumb=location: w parametrach linii poleceń, logach aplikacyjnych i telemetrii procesów.

Podsumowanie

Niezałatana podatność w obsłudze search: URI pokazuje, że pozornie wygodne mechanizmy integrujące funkcje systemowe z linkami i dokumentami mogą stać się skutecznym wektorem wycieku poświadczeń. Choć problem nie umożliwia bezpośredniego wykonania kodu, pozwala pozyskać skróty Net-NTLMv2 i otwiera drogę do dalszej kompromitacji środowiska.

W praktyce jest to kolejny argument za odchodzeniem od NTLM, blokowaniem zbędnego ruchu SMB oraz wzmacnianiem monitoringu uwierzytelnionych połączeń. Do czasu wdrożenia pełnych zabezpieczeń najskuteczniejszą strategią pozostają środki kompensacyjne, segmentacja sieci i ograniczenie możliwości wynoszenia materiału uwierzytelniającego poza kontrolowane środowisko.