Wystarczy wysłać mailem odpowiednio przygotowany plik (.theme) do innego użytkownika lub skopiować go na jego pulpit (czy inne dowolne miejsce na dysku), a możemy uzyskać poświadczenia NTLM tej osoby (NTLM hash).
Ten tydzień z pewnością nie jest przyjemny dla zwolenników systemu Windows. Rozpoczęliśmy od opisu krytycznej luki bezpieczeństwa w Windows 11, wczoraj informowaliśmy o kolejnym ataku, a dziś piszemy o ciekawym zero-dayu, którego wszyscy powinniśmy się obawiać.
Piszemy o tym nie po to, aby piętnować niedoskonałości systemu Windows (bo inne systemy też je mają), ale by uświadomić Was o istnieniu takiego zagrożenia i przygotować na nie.
Sprawcą dzisiejszego zamieszania jest plik motywu tła i pulpitu (themes).
O co chodzi w tym ataku?
W wielkim skrócie, w styczniu 2024 Microsoft stworzył poprawkę do błędu w przetwarzaniu plików motywów i pulpitu na Windows (plik *.theme), która wciąż zawiera błąd umożliwiający przejęcie hasha hasła NTLM użytkownika w momencie otrzymania takiego pliku w mailu lub na pulpicie. Warunek jest taki, iż plik musi się jedynie wyświetlić.
Format pliku Theme składa się z kilku bloków parametrów. Poniżej omówimy dwa parametry: parametr BrandImage wewnątrz bloku [theme] (Rysunek 1) i parametr Wallpaper (Rysunek 2) wewnątrz bloku [Control Panel\Desktop].
Rysunek 1. Parametr BrandImage w pliku theme (źródło: Akamai)
Rysunek 2. Parametr Wallpaper w pliku theme (źródło: Akamai)Każdy plik w systemie Windows jest opatrzony miniaturą, która ma odzwierciedlać jego funkcję. Może to być ikona, logo produktu lub wizualizacja jego zastosowania (na przykład kalkulator). Miniatury plików motywów składają się z trzech elementów: tapety (czarny prostokąt), pliku MSstyle (pomarańczowy kwadrat) i obrazu marki (przykładowo obraz Infection Monkey — zobacz Rysunek 3).
Rysunek. 3: Miniatura pliku motywu z trzema elementami (źródło: Akamai)Każdy z tych elementów zapisany jest w pliku motywu jako osobny parametr – BrandImage, Wallpaper oraz VisualStyle. Parametry te mogą zawierać ścieżki zdalne wskazujące na zasoby UNC, co potencjalnie umożliwia kierowanie ruchu do zdalnych punktów końcowych.
Jak doszło do odkrycia zero-daya?
W zeszłym roku Tomer Peled, badacz ds. bezpieczeństwa z Akamai, przeprowadził analizę plików motywów systemu Windows i odkrył krytyczną lukę w ich działaniu. Gdy plik motywu (.theme) zawierał ścieżkę do pliku sieciowego w polach takich jak BrandImage i Wallpaper, Windows automatycznie wysyłał uwierzytelnione żądania sieciowe do wskazanego zdalnego hosta. Te żądania obejmowały poświadczenia NTLM użytkownika, co stwarzało duże zagrożenie bezpieczeństwa.
Co istotne, luka umożliwiała automatyczne ujawnienie poświadczeń użytkownika bez jakiejkolwiek interakcji, jeżeli plik motywu znajdował się w folderze przeglądanym w Eksploratorze Windows lub na pulpicie. Mechanizm ten sprawiał, iż wystarczyło jedynie wyświetlenie złośliwego pliku, by dane uwierzytelniające użytkownika zostały przesłane na zdalny serwer.
Technicznie rzecz biorąc, lukę tę można było wykorzystać, tworząc spreparowany plik motywu, który określał zasób sieciowy kontrolowany przez atakującego jako źródło obrazu tła lub logo. W momencie, gdy Windows próbował załadować te zasoby, automatycznie wysyłał uwierzytelnienie NTLM, co umożliwiało atakującemu przechwycenie i potencjalne odszyfrowanie hashów NTLM, co w sprzyjających warunkach pozwalało uzyskać dostęp do konta użytkownika.
Nieskuteczne łatanie luki przez Microsoft
Microsoft załatał lukę CVE-2024-21320 trzy miesiące po otrzymaniu zgłoszenia, ale zrobił to nieskutecznie – co udowodnił inny badacz, Mitja Kolsek z Acros Security.
W przypadku CVE-2024-21320 poprawce Microsoftu zaufano zbyt szybko, jak twierdzi Kolsek. Odkrycie CVE-2024-38030 ujawniło, iż potrzebne jest inne podejście. Badacz przeanalizował poprawkę Microsoftu i zauważył, iż wykorzystuje ona funkcję PathIsUNC do sprawdzania, czy ścieżka w pliku motywu jest ścieżką sieciową; jeżeli tak, jest ona ignorowana. Teoretycznie miało to zapobiec wyciekom danych uwierzytelniających NTLM. Jednak James Forshaw już w 2016 roku opisał liczne metody omijania PathIsUNC. Badacz odkrył, iż techniki opisane przez Forshawa można wykorzystać do obejścia poprawki Microsoftu dla CVE-2024-21320, i zgłosił ten problem, aby Microsoft mógł podjąć kolejne kroki.
„Lokalizacja poprawki Microsoftu była, naszym zdaniem, dobrze dobrana dla dwóch pierwszych znanych podatnych parametrów. Jednak teraz, mając do czynienia z kolejnym zero-dayem, Microsoft może rozważyć przesunięcie poprawki do funkcji, którą w tej chwili zabezpieczamy. jeżeli jednak się na to zdecydują, powinni pozostawić pierwotne poprawki dla CVE-2024-38030, aby uniknąć konieczności kolejnych poprawek” – powiedział Kolsek.
„Należy zauważyć, iż poprawki zostały stworzone tylko dla systemu Windows Workstation, ale nie dla systemu Windows Server. Wynika to z faktu, iż aby motywy systemu Windows działały na serwerze, funkcja Desktop Experience musi być zainstalowana (nie jest ona zainstalowana domyślnie). Ponadto aby doszło do wycieku danych uwierzytelniających na serwerze, nie wystarczy samo wyświetlenie pliku motywu w Eksploratorze Windows lub na pulpicie; zamiast tego należy dwukrotnie kliknąć plik motywu i zastosować motyw” – wyjaśnili badacze Acros Security.
PoC luki zero-day
Przy publicznie dostępnych szczegółach CVE-2024-21320, CVE-2024-38030 oraz PoC dla pierwszej z tych luk, inni badacze bezpieczeństwa lub potencjalni atakujący mogą być w stanie zlokalizować nieznane wcześniej luki, które odkrył zespół Acros Security. „Byłbym bardzo zaskoczony, gdybyśmy byli jedynymi, którzy to znaleźli” – skomentował Kolsek.
Na poniższym wideo widać, jak wygląda atak:
Podobne ataki w historii Microsoftu i błędy w łataniu luk
Powyższy przykład przejęcia uprawnień metodą „bezklikalności” użytkownika to nie pierwszy w historii Microsoftu problem, z którego łataniem producent sobie nie radzi.
CVE-2023-23397 jest doskonałym przykładem luki wynikającej z mało znanej i nietypowej funkcjonalności w Outlooku. W tym przypadku atakujący mógł dołączyć do wiadomości e-mail odwołanie do pliku dźwiękowego, który automatycznie odtwarzał się po odebraniu wiadomości. Wtedy Microsoft podjął decyzję o całkowitym usunięciu tej funkcjonalności, zakładając, iż każda próba jej naprawy może okazać się niepełna.
Czy tak będzie i w tym przypadku? Zobaczymy.
Jak zapobiec problemom?
Poniżej prezentujemy sugestie dotyczące zabezpieczenia się i złagodzenia ryzyka związanego z uwierzytelnianiem NTLM w SMB w systemie Windows 11 w firmach i organizacjach:
- W systemie Windows 11 administratorzy mogą zablokować użycie protokołu uwierzytelniania NTLM dla protokołu SMB w przypadku zdalnych połączeń, korzystając z zasady grupy. Aby to skonfigurować, należy otworzyć Edytor zasad grupy i przejść do: Szablony administracyjne > Sieć > Stacja robocza Lanman > Blokuj NTLM. Ustawienie tej opcji zwiększa bezpieczeństwo, ograniczając wykorzystanie starszych metod uwierzytelniania NTLM, które mogą być podatne na ataki.
- Alternatywna zasada „Ogranicz NTLM” dla wyższej ochrony
Microsoft zaleca także zastosowanie zasady Ogranicz NTLM. Ta zasada, dostępna w zaawansowanych konfiguracjach zabezpieczeń systemu Windows, oferuje dodatkowe opcje blokowania ruchu NTLM, pozwalając administratorom na bardziej precyzyjne kontrolowanie jego przepływu w sieci. Szczegółowe instrukcje dotyczące implementacji tej zasady można znaleźć w dokumentacji Microsoftu, która prowadzi administratorów krok po kroku przez proces konfiguracji. - Mikrosegmentacja jako najważniejsze uzupełnienie zabezpieczeń SMB
Dzięki wdrożeniu mikrosegmentacji administratorzy sieci mogą blokować ruch SMB do zdalnych lokalizacji poza wewnętrzną siecią organizacji. Mikrosegmentacja pozwala ograniczyć dostępność SMB jedynie do kontrolerów domeny i serwerów plików, co minimalizuje ryzyko związane z nieoczekiwanymi połączeniami. Ruch SMB przeznaczony do zewnętrznych, nieautoryzowanych punktów zwykle nie jest potrzebny i może stanowić potencjalne zagrożenie, dlatego ograniczenie go zwiększa bezpieczeństwo.
Podsumowanie
Ataki wymuszające uwierzytelnianie są dobrze znanym narzędziem wykorzystywanym przez cyberprzestępców do poruszania się wewnątrz sieci i przechwytywania poświadczeń. Opisywaliśmy je kilkukrotnie na Kapitanie. Na przykład grupa Dragonfly stosowała zmodyfikowane pliki LNK, aby uzyskiwać dostęp do poświadczeń dzięki protokołu SMB. Później pisaliśmy również o LNK stomping.
Wykorzystanie plików motywów jako wektora tego rodzaju ataku jest nowym i zaskakującym sposobem działania.
Nie ulega wątpliwości, iż opisywana dzisiaj luka podkreśla potrzebę stosowania silnych zabezpieczeń antyphishingowych w organizacjach, gdyż atakujący mogą łatwo wysłać plik, który wygląda na nieszkodliwy, ale w rzeczywistości inicjuje ten typ ataku. Odkrycie to podkreśla potrzebę monitorowania takich funkcji przez Microsoft i wzmacnia argumenty za wyłączaniem nieużywanych komponentów systemowych.
Z zadowoleniem obserwujemy, iż Microsoft podjął kroki w celu ograniczenia tego wektora ataku poprzez dodanie odpowiednich zasad grupy. Zalecamy administratorom zabezpieczeń, aby zadbali o aktualizację punktów końcowych najnowszymi poprawkami.
