W

OJSKOWA

A

KADEMIA

T

ECHNICZNA

Podstawy bezpieczeństwa informacji

Sprawozdanie z ćwiczeń laboratoryjnych nr 2.

Prowadzący: mgr inż. Bartosz Kryński

Wykonali:

Jakub Łochocki
Grupa: I9M1S1
Nr albumu: 45303

Mateusz Fruba
Grupa: I9M1S1
Nr albumu: 45261

Treść zadania

Zadanie laboratoryjne nr 2 składało się z dwóch części a mianowicie:



Utworzyć mapę witryny programem Burp suite.



Utworzyć raport podatności witryny przy pomocy skryptu wapiti.

Wykonanie

Opis narzędzi

Jako pierwsze zostało wykonane zadanie utworzenia mapy witryny.

Burp suite jest zestawem wielu współpracujących narzędzi, wspierających wykonanie

testów penetracyjnych aplikacji webowych. Składa się on z następujących modułów:

 http proxy –

umożliwia przechwycenie komunikacji oprogramowania komunikującego

się przy pomocy protokołu HTTP

 repeater –

pozwala na modyfikację przechwyconych requestów lub utworzenie

nowych

 scanner –

skaner wykrywający podatności aplikacji webowych

 intruder –

fuzzer pozwalający wykonywać półautomatyczne testy penetracyjne

 sequencer –

analizuje losowość generatorów identyfikatorów sesji

 decoder –

umożliwia konwersję pomiędzy kodowaniami typu base64, hex.

 spider –

umożliwia stworzenie mapy witryny oraz zasobów z jakich korzysta (obrazy,

pliki styli)

 comparer –

umożliwia porównanie różnic pomiędzy zapytaniami lub odpowiedziami

http.

Podczas wykonywania tego zadania potrzebne były nam tylko dwa moduły tego programu:

http proxy oraz spider.

P

rzebieg ćwiczenia

Jako że podczas wykonywania zadania laboratoryjnego zgrywanie zrzutów ekranu nie

przebiegło pomyślnie i nie udało się ich odtworzyć, zadanie zostało wykonane ponownie na
własnej stronie internetowej.

Całość zadania schodziła się do kilku prostych czynności:

1. Uruchomienie programu Burp Suite

2. Ustawienie serwera proxy w pr

zeglądarce firefox (host: 127.0.0.1 port: 8080)

3.

Wpisanie i wywołanie adresu witryny w przeglądarce, zezwolenie w programie Burp
suite na wykonanie żądania.

4.

W zakładce Target -> Site map odnalezienie interesującej nas witryny i wybranie dla

niej opcji „spider this host”.

Wynik po wykonaniu powyższych kroków przedstawiony został na poniższym obrazku.

Kolejną częścią zadania laboratoryjnego było utworzenie raportu podatności witryny

przy pomocy skryptu wapiti.

Wapiti jest skryptem pythonowym p

ozwalającym nam na wykonywanie testu

podatności aplikacji internetowej. Bazuje on na modułach, co znaczy, że bez większego
problemu możemy dogrywać do niego moduły podatności. Po uruchomieniu skanowania,

pierwsza

czynność, jaka jest wykonywana jest to utworzenie mapy witryny w celu znalezienia

wszelkich miejsc do wstrzyknięcia ewentualnego złośliwego kodu. Czas skanowania jest
zależny od tego jak bardzo serwis jest rozbudowany i jak wiele posiada odnośników.

W celu uruchomienia skanowania

wystarczy uruchomić skrypt z następującymi parametrami:

> python wapiti.py [adres url lub ip] –r html

Np.: > python wapiti.py http://kurosup.cba.pl –r html

Przed skanowaniem możemy sobie określić, jakie moduły penetracyjne mają zostać

uruchomione jednak w naszym zadaniu laboratoryjnym

nie określaliśmy tego parametru,

przez co

wykonane zostały wszystkie dostępne w skrypcie testy.

Na powyższym zrzucie ekranu widzimy przykładowe uruchomienie skryptu.

Po dość długim skanowaniu otrzymamy raport podobny do tego poniżej

Po

pierwszym skanowaniu skrypt nie wykrył żadnych podatności, w ramach

ćwiczenia laboratoryjnego część zabezpieczeń witryny została wycięta na czas testu. Niestety
jak się okazało skrypt ten nie jest idealny w podstawowej formie nie wykrył wielu

potencjalnych

zagrożeń takich jak LFI, RFI. Niesprawdzone zostały także typowe błędy dla

danego języka w tym przypadku dla PHP nie zostało sprawdzone podanie jako argumentu
tablicy. Jak powszechnie wiadomo większość funkcji php po otrzymaniu takiego argumentu
przy włączonym raportowaniu błędów zwraca wiele cennych informacji dla potencjalnego
włamywacza, zaczynając od fizycznej ścieżki dostępu, pod jaką się znajduje dany moduł aż

po skrawki kodu.

Skrypt w raporcie nie uwzględnił także domyślnie wyrzucanych warningów

i błędów na stronie, które także zawierały ścieżki fizyczne. Twórca skryptu pomijając
wyszukiwanie tego typu rzeczy wyciął sprawdzanie błędów typu ByPass polegające na tym,
że kluczowe pliki nie są chronione niczym, są ogólnodostępne jedynie trzeba odgadnąć adres
dostępu do nich. Do wad skryptu można także zaliczyć to że jest bardzo ogólny, przy nie
bezpiecznym użyciu funkcji include() zgłosił błąd jako File Handling, gdzie należało by
sprawdzić rodzaj podatności: local file include, remote file include.

Ja możemy zauważyć ten skaner nadaje się tylko do powierzchownych testów i nigdy

nie zastąpi dobrze wykonanego audytu bezpieczeństwa. Pominął on wiele kluczowych

informacji, które

osobno może nie stanowią wielkiego zagrożenia, ale połączone razem dają

intruzowi pełny dostęp do aplikacji.