21:07
25/6/2019

Po (zbyt) długiej przerwie (sorry!), publikujemy zawieruszony trzeci odcinek naszego videoporadnika pt. “Niebezpieczny Poradnik Pentestera”, którego celem jest prezentacja narzędzi wykorzystywanych podczas wykonywania testów penetracyjnych aplikacji webowych.

Niektóre z tych narzędzi omawiamy (w szerszym zakresie) na naszych szkoleniach z Atakowania i Ochrony Webaplikacji, które regularnie organizujemy w Warszawie, Krakowie, Wrocławiu, Poznaniu oraz Gdańsku i na które oczywiście serdecznie Was zapraszamy. Z pełną agendą szkolenia i najbliższymi terminami w Twoim mieście zapoznasz się na tej stronie.

Trzeci odcinek Niebezpiecznego (video)Poradnika Pentestera

W poprzednich odcinkach pokazaliśmy Wam jak przeprowadzić atak słownikowy z użyciem oprogramowania Hydra oraz pokazaliśmy jak szukać i wykorzystywać podatności typu SQL Injection, nawet bez znajomości języka SQL z użyciem narzędzia SQLmap.

Dziś chcielibyśmy zaprezentować wielozadaniowy program Burp Suite, niezbędny w pracy wielu pentesterów. Aplikacja ta pełni rolę serwera proxy HTTP/HTTPS i pozwala na podglądanie, przechwytywanie, analizę i modyfikację zapytań przeglądarki i odpowiedzi serwera. A dzięki dodatkowym modułom, możliwe jest usprawnienie pracy pentestera i automatyzacja działań na żądaniach HTTP(S).

Oto trzeci odcinek poradnika:

Instalacja Burp Suite i podatnej testowej aplikacji

Zanim przystąpimy do pracy z Burpem, należy go oczywiście pobrać i zainstalować. Burp napisany jest w Javie i da się go uruchomić na dowolnym, współczesnym systemie operacyjnym (Windows, Linux, MacOS itp).

Aplikacja dostępna jest nie tylko w wersji płatnej (350 Euro na rok), ale również w całkiem użytecznej wersji darmowej, tzw. “community”. Ma ona pewne ograniczenia, ale jeśli nie jesteś zawodowym pentesterem, to prawdopodobnie nie będą Ci zbytnio przeszkadzały w prostych testach aplikacji (zwłaszcza jeśli nie boisz się korzystania z innych, alternatywnych narzędzi lub pisania własnych skryptów). My na filmie korzystamy z wersji profesjonalnej — ale i Ty możesz z niej skorzystać przez miesiąc za darmo.

Po instalacji programu, należy go uruchomić i skonfigurować w nim pusty projekt. Od tego momentu, Burp nasłuchuje już na ruchu HTTP/HTTPS na porcie 8080 naszego lokalnego komputera i jest gotowy do pełnienia roli proxy. Musimy teraz uruchomić dowolną przeglądarkę internetową i skonfigurować ją tak, aby korzystała z Burpa jako z serwera proxy dla wszystkich protokołów komunikacyjnych.

Przykładowo, w Firefoksie wchodzimy kolejno:

ustawienia -> zaawansowane -> sieć -> połączenia -> ustawienia

Należy wpisać tam ustawienia jak na poniższym screenie.

W niektórych przeglądarkach nie da się bezpośrednio ustawić serwera proxy, ponieważ korzystają one z ustawień systemowych. W takim przypadku, należy odpowiednio skonfigurować swój system operacyjny, tak, aby ustawienia proxy wyglądały podobnie do tych z powyższego screena.

Podobnie jak w poprzednich odcinkach poradnika, tak i tym razem, nasze środowisko testowe postawimy na najtańszym VPSie z oferty firmy DigitalOcean. Do szybkiej konfiguracji środowiska do ataku, posłużymy się programem docker-compose. W tym celu najpierw musimy ściągnąć plik konfiguracyjny z opisem konfiguracji tego środowiska:

wget https://nbzp.cz/docker-hacklab

Teraz uruchamiamy docker-compose z następującymi parametrami:

docker-compose -f docker-hacklab up -d

Po wykonaniu powyższych poleceń i odczekaniu maksymalnie kilku minut, powinniśmy mieć na naszym serwerze uruchomione dwa kontenery. Jeden z Kali Linuksem (nie będziemy wykorzystywać go w tej części poradnika), a drugie z podatną aplikacją webową o nazwie DVWA. Gdy środowisko będzie już skonfigurowane, musimy załadować w przeglądarce stronę naszej instancji DVWA. Dostaniemy się do niej, wpisując http:// przed adresem IP serwera VPS, który skonfigurowaliśmy na DigitalOcean.

Podstawy obsługi Burpa

Jak pewnie zauważysz, strony internetowe w przeglądarce skonfigurowanej pod Burpa “przestały” się ładować. Dzieje się tak dlatego, że Burp przechwytuje żądania HTTP(S) i pyta użytkownika o to, co zrobić z każdym z nich. Do czasu podjęcia przez użytkownika decyzji, wstrzymuje dane zapytanie. Do wyboru mamy dwie podstawowe akcje (zakładka “proxy” w BURPie):

    FORWARD – zezwól na zapytanie i przekieruj je do docelowego serwera
    DROP – odrzuć zapytanie

Wyłączmy na chwilę analizę całego ruchu sieciowego, odklikując przycisk “Intercept is on“. Wchodzimy na stronę logowania DVWA i logujemy się do systemu za pomocą danych: admin/password

Przechodzimy na zakładkę “SQL Injection“. Formularz znajdujący się na tej stronie umożliwia odpytywanie bazy danych o użytkowników, posługując się ich numerami ID. Jeśli więc wpiszemy tam cyfrę “1“, otrzymamy użytkownika “admin“. Wykorzystamy ten mechanizm do zobrazowania pracy z burpowym modułem Intruder.

Ale najpierw włączmy z powrotem nasłuchiwanie (kliknij na “Interception is off“) i jeszcze raz wprowadźmy ID równe “1” w naszej aplikacji testowej. Gdy Burp zapyta, co zrobić z tym żądaniem, klikamy na “FORWARD”, a następnie podglądamy wysłane przez Burpa żądanie w historii zapytań:

proxy -> intercept -> HTTP history

Aby skorzystać z modułu Intrudera, klikamy na nim prawym przyciskiem myszy i z menu, które się pojawia wybieramy “Send to Intruder“.

Co chcemy zrobić?

Zaobserwowaliśmy, że wpisując dowolną liczbę w polu formularza, webaplikacja sprawdza, czy użytkownik o podanym numerze ID istnieje w systemie i pokazuje jego dane. Załóżmy, że naszym celem jest sprawdzenie, jak wielu użytkowników posiada dany system, aby przygotować się do ataku słownikowego na ich konta (por. pierwszy odcinek). Gdyby użytkowników było zaledwie kilku, moglibyśmy sprawdzić to ręcznie. Jest jednak szansa, że użytkowników będzie kilkuset czy nawet kilka tysięcy. Musimy więc sprawdzić (przesłać do webaplikacji) dość spory zakres ID. I właśnie w tym pomoże nam w tym “Intruder” z Burpa, który świetnie automatyzuje powtarzalne czynności.

Obsługa Intrudera

Moduł Intrudera służy do automatycznej modyfikacji requestów wysyłanych do serwera, wykorzystując w tym celu wcześniej przygotowane wzorce zapytań (tzw. payloady). Po ostatnio wykonanej akcji (“Send to Intruder”), powinniśmy mieć otwartą zakładkę “Intruder”. Przechodzimy na podzakładkę “Positions”. W polu tekstowym, które się pojawiło, widnieje kompletne zapytanie HTTP wysyłane do serwera. Niektóre części zapytania oznaczone będą kolorem żółtym. Są to potencjalne punkty wstrzyknięcia payloadu, które wybrał dla nas Burp samodzielnie. Nie chcemy ich wszystkich atakować, więc klikamy na “Clear”. My chcemy podmieniać przy każdym zapytaniu wysyłanym do serwera tylko wartość parametru “id”.

GET /vulnerabilities/sqli/?id=1&Submit=Submit HTTP/1.1

Zaznaczamy więc wartość parametru “id” (tu “1”), bo to ona ma być podmieniana i klikamy na “Add”. Burp powinien podświetlić nam tę część zapytania na żółto i oznaczyć dodatkowymi znakami po jego lewej i prawej stronie. Przechodzimy teraz na zakładkę “Payloads”, gdzie konfigurujemy parametry techniczne naszego ataku.

Chcemy przetestować np. pierwszych 100 użytkowników z bazy. Aby to zrobić, możemy skorzystać z wygodnego i wbudowanego w Burpa generatora liczb i powiedzieć mu, aby sprawdzał dla nas liczby z zakresu 1-100. Aby to zrobić, z rozwijanej listy pod “Payload type” wybieramy “Numbers”. Następnie wypełniamy odpowiednio kolejne pola:

Wracamy na zakładkę “Target” i klikamy na “Start attack”. Teraz BURP wyśle dla nas 100 zapytań (bo sprawdzamy 100 liczb) do serwera i zbierze odpowiedzi na nie.

Jeśli używasz darmowej wersji Burpa, to musisz wiedzieć, że limituje ona szybkość zautomatyzowanych zapytań w stosunku do wersji płatnej. Taki atak potrwa u Ciebie dłużej niż na naszym filmiku, gdzie korzystamy z wersji profesjonalnej Burpa.

Po chwili zobaczymy wyniki, ale ich interpretacja nie jest taka oczywista. Nie mamy jak szybko przeanalizować setek odpowiedzi jakie uzyskaliśmy. Wyniki przeprowadzonego ataku są dla nas mało użyteczne. Musimy skonfigurować dodatkowe opcje aby to poprawić.

Jak pewnie zauważyłeś, w niektórych odpowiedziach od serwera (tych z ID, które mapują się na prawdziwych użytkowników) pojawia się w treści: ID, First name i Surname. Jeśli jednak odpytamy o nieistniejący identyfikator użytkownika (np. 9999) otrzymamy pustą odpowiedź. Mamy więc “wyrocznię”, różne odpowiedzi serwera na to samo zapytanie w zależności od jego wyniku logicznego. Możemy więc założyć, że słowo “Surname” istnieje tylko na stronach z poprawnymi numerami ID. Wykorzystajmy tę wiedzę.

Wracamy do ustawień Intrudera na zakładkę “Options” i konfigurujemy tam opcję “Grep – Match” w taki sposób, aby na liście widniało jedynie słowo ‘Surname’.

Teraz wracamy na zakładkę “Target” i obecne wyniki będą wzbogacone o nową kolumnę o nazwie “Surname” (po której możemy posortować). Jeśli znacznik będzie w niej obecny, oznacza to, że pod podanym ID istnieje użytkownik. W ten sposób wyznaczyliśmy wszystkie ID użyte w systemie (do wartości 100).

Podsumowanie

W tym odcinku “Niebezpiecznego Poradnika Pentestera” poznałeś aplikację o nazwie Burp Suite w bardzo podstawowym zakresie. To narzędzie to kombajn. Ma setki dodatkowych funkcji i wiele więcej możliwości dzięki dodatkom pisanym przez “community”. Być może w kolejnych odcinkach Niebezpiecznego Poradnika Pentestera pokażemy inne jego funkcje.

Burp to jeden z tych programów, który może stać się Twoim podstawowym narzędziem pracy, jeśli zwiążesz swoją przyszłość z pentestingiem aplikacji webowych. U nas w zespole bezpieczeństwa, korzystają z niego wszyscy. Burp jest też pierwszym narzędziem jakie instalujemy w trakcie naszych 2 dniowych warsztatów z bezpieczeństwa aplikacji webowych, na których mamy nadzieję, że kiedyś się z Tobą spotkamy :)

PS. Jeśli macie pomysł na kolejny odcinek, niezależnie od tego czy miałby to być opis jakiejś techniki ataku, czy zaprezentowanie sposobu konfiguracji jakiegoś narzędzie, to dajcie nam znać na adres: npp@niebezpiecznik.pl. Postaramy się wziąć pod uwagę Wasze sugestie.

Przeczytaj także:

3 komentarzy

Dodaj komentarz
  1. Gdzie można znaleźć E1 i E2 ?

    Po kliknięciu na tagi nie pokazują się żadne inne artykuły. Znalazłem tylko jakiś taki luźno powiązny artykuł:

    https://niebezpiecznik.pl/post/jak-automatyzowac-ataki-na-webaplikacje-przy-pomocy-burp-suite-niebezpieczny-poradnik-pentestera-s01e02

    • @Exsillium

      W treści artykułu są do obydwu bezpośrednie linki, tam gdzie napisali: “W poprzednich odcinkach pokazaliśmy Wam >jak przeprowadzić atak słownikowy z użyciem oprogramowania Hydra oraz pokazaliśmy >jak szukać i wykorzystywać podatności typu SQL Injection, nawet bez znajomości języka SQL z użyciem narzędzia SQLmap”.

      Alternatywnie po prostu na YouTube można wybrać playlistę “Niebezpieczny poradnik pentestera”

  2. Faktycznie moglibyście się zdecydować na jakąś konsystencję w tagowaniu tej serii.
    Dwa pierwsze odcinki są otagowane jako “wideo”:
    https://niebezpiecznik.pl/tag/wideo/
    a niniejszy trzeci odcinek nie jest już otagowany “wideo” lecz “poradnik-pentestera”:
    https://niebezpiecznik.pl/tag/poradnik-pentestera/

Odpowiadasz na komentarz Exsilium

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: