W artykule „RAM pamięta wszystko: niewidoczne zagrożenie w aplikacjach” opisałem zagrożenie wynikające z pozostawiania wrażliwych danych w pamięci operacyjnej aplikacji. Pokazałem, że wiele programów nie usuwa poprawnie sekretów po ich wykorzystaniu. Dziś pokażę, jak ten problem miał kluczowe znaczenie podczas rzeczywistego zadania red teamowego i wiązał się z podatnością CVE-2024-24915 w Check Point SmartConsole (R81.20), którą odkryłem w zeszłym roku.
Miłej lektury!
Proof of Concept dla CVE-2024-24915
Podatność polega na tym, że dane uwierzytelniające pozostają w pamięci aplikacji po ich użyciu. Aby to odtworzyć:
- Zaloguj się do aplikacji:
- Wykonaj zrzut pamięci:
- Wyszukaj ciągi znaków związane z logowaniem:
Proste, prawda? Ale czy to faktyczne zagrożenie? Przekonajmy się.
Kontekst red teamowy
Historia zaczęła się od skutecznej kampanii spear-phishingowej. Na współdzielonym udziale SMB umieściłem podatny instalator SmartConsole. Wejście do systemu było możliwe dzięki atakowi DLL hijacking, poprzez podmianę biblioteki profapi.dll (dokładniej opisane w moim wcześniejszym wpisie: „Przejmowanie bibliotek DLL w instalatorze Check Point SmartConsole aka CVE-2024-24916„). W momencie uruchomienia instalatora przez użytkownika, uruchamiana była powłoka zdalna (ang. reverse shell).
Po uzyskaniu trwałego dostępu, do akcji wkroczyła druga podatność – CVE-2024-24915.
Wykorzystanie poświadczeń zapisanych w pamięci procesu w postaci zwykłego tekstu
Na tym etapie brak bezpiecznego zarządzania pamięcią w SmartConsole okazał się kopalnią złota. Podczas każdej sesji powłoki wykonywałem zrzut pamięci procesu SmartConsole w celu pozyskania danych logowania. Dzięki CVE-2024-24915 dane te pozostawały w pamięci w postaci czystego tekstu.
To realny przykład na to, że problem z „RAM pamięta wszystko: niewidoczne zagrożenie w aplikacjach” to nie tylko teoria – w środowisku korporacyjnym może mieć bardzo poważne konsekwencje.
Ruch boczny
Dane logowania w postaci tekstowej mogą być natychmiast wykorzystane w kolejnych etapach ataku – np. z użyciem netexec do automatycznego sprawdzania ponownego użycia hasła na różnych usługach:
- Remote Desktop Protocol (RDP) – do interaktywnego dostępu do stacji roboczych lub serwerów,
- Server Message Block (SMB) – do współdzielenia plików i zdalnego uruchamiania poleceń,
- Windows Remote Management (WinRM) – do zarządzania systemem lub dyskretnego wykonania kodu,
- Windows Management Instrumentation (WMI) – dla dyskretnego zdalnego wykonania kodu,
- LDAP – do enumeracji użytkowników, komputerów i obiektów AD,
- Kerberos – do ataków typu Pass-the-Hash i Pass-the-Ticket.
Ale to nie wszystko. Te same dane logowania często zapewniają dostęp do:
- usług chmurowych, takich jak Office 365, Google Workspace, AWS, Azure,
- wewnętrznych i zewnętrznych aplikacji webowych, VPN-ów, systemów HR, Jira, Confluence, systemów ewidencji czasu i wielu innych krytycznych usług.
Połączenie ataku DLL hijacking z przechowywaniem poświadczeń w pamięci pozwala red teamowi – albo realnemu atakującemu – zbudować łańcuch ataku o ogromnej sile rażenia. To też idealny moment, by przypomnieć: NIGDY NIE UŻYWAJ DWA RAZY TEGO SAMEGO HASŁA.
Na zakończenie
Pozostawianie danych logowania w pamięci procesów użytkownika może sprawić, że jedno skuteczne phishowanie doprowadzi do przejęcia całej domeny. Współczesne scenariusze red teamowe jasno pokazują jedno: pamięć zbyt często odmawia zapomnienia.
