Większość systemów informatycznych posiada różne rodzaje kont użytkowników.
Mamy więc administratorów, redaktorów czy też subskrybentów.
Każdy z niech posiada dostęp do różnych miejsc i funkcjonalności.
Naszym zadaniem jako pentesterów - jest sprawdzenie, czy wszystko działa jak należy.
Nie chcemy bowiem dopuścić do sytuacji, kiedy to zwykły użytkownik może zmienić hasło dowolnej osoby.
Oczywiście można testować to manualnie - czyli logować się na każde konto z osobna i sprawdzać, jakie funkcję działają a jakie nie.
Dziś pokaże, jak można to zrobić prościej i szybciej wykorzystując AutoReapeater z pakietu BurpSuite.
Najpierw, musimy zainstalować narzędzie.
Standardowo, można to zrobić bezpośrednio z poziomu Burpa - wykorzystując zakładkę Extender -> Store.
Tylko, że wersje, które się tutaj znajdują zazwyczaj nie są najnowszymi, które możemy dostać.
Dlatego też wykorzystamy alternatywną opcję instalacji.
Ściągamy odpowiednik plik jar z repozytorium - link znajdziesz w opisie pod tym filmem.
Teraz w zakładce Extender wybieramy przycisk Add.
Wskazujemy na miejsce w którym znajduje się nasz nowo ściągnięty plik.
Jeżeli wszystko zadziałało - powinniśmy zobaczyć nową zakładkę AutoRepeater.
Ja, zademonstruje możliwości tego rozszerzenia na przykładzie WordPressa.
W tym celu loguje się do bloga jako administrator i tworze dwa nowe konta użytkownika - jedno z uprawnieniami subskrybenta, drugie natomiast z rolą redaktora.
Teraz, musimy zastanowić się jak WordPress sprawdza, jaki obecnie użytkownik jest zalogowany.
Jak większość witryn, wykorzystuje do tego celu ciasteczko - a właściwe dwa ciasteczka.
Jedno wordpress podkreślenie i losowy ciąg znaków oraz drugie - wordpress_logged_in.
Tak naprawdę to nie losowy ciąg znaków a hash MD5 nazwy domeny, na której zainstalowany jest system.
To właśnie na podstawie wartości tego ciasteczka, system wie kto go obecnie używa.
Najlepiej rozpatrzyć to na przykładzie.
Burp posiada wbudowany moduł Comparer.
Pozwala on na porównanie dwóch żądań i wskazania różnic między nimi.
Dzięki temu jak na dłoni widać - czym różnią się dwa żądania między sobą.
Wybieramy więc z historii żądań, w którym to jesteśmy zalogowaniu jako administrator.
Następnie klikamy prawym przyciskiem myszy i wybieramy opcję Send to comparer -> request.
Teraz tworze nowe okno incognito w przeglądarce - tak aby wyczyścić wszystkie ciasteczka.
Brak ciasteczek sprawia, że WordPress myśli, że nie jesteśmy zalogowani.
Loguje się więc jako redaktor wykorzystując wcześniej stworzone konto użytkownika.
Ponownie w zakładce history znajduje moje żądanie - tym razem to, gdzie jestem zalogowany jako redaktor i ponownie przesyłam je do modułu comparer.
Teraz możemy je ze sobą porównać.
W ciasteczkach najpierw znajduje się nazwa użytkownika potem znak procent i dalsza zaszyfrowana cześć.
Żeby więc wykonać jakieś żądanie jako redaktor, a nie administrator - musielibyśmy w każdym z żądań zmieniać wartość ciasteczka.
Oczywiście można robić to ręcznie przy pomocy modułu repeater - ale na dłuższą metę nie ma to sensu.
Tu do gry wchodzi AutoRepeater.
Działa on na zasadzie mechanizmu Znajdź -> Zamień, który znajduje się w edytorach tekstu.
Jeżeli ustalony przez nas ciąg znaków znajduje się w jakimkolwiek żądaniu przesłanym do Burpa - narzędzie automatycznie podmieni jego zawartość i wykona żądanie do serwera ponownie - tylko, że tym razem ze zmienionymi wartościami.
W taki oto sposób możemy w locie podmieniać wartości naszych ciasteczek.
Rzeczy, które będziemy podmieniać można grupować w zakładkach.
W naszym przykładzie będziemy więc mieli dwie zakładki - jedną dla konta redaktora i drugą dla konta subskrybenta.
Dostępne są dwie opcję - base replacements oraz replacements.
Czym się one różnią między sobą?
Replacements - dla każdego znalezionego i zamienionego ciągu znaków - wykonuje osobne żądanie do serwera.
Jeżeli więc mamy dwie rzeczy do zamiany - wykonane zostaną 2 żądania.
Base replacements natomiast łączy wszystkie zamiany ze sobą i wykonuje je jako jedno żądanie - nie zależnie od ilości zmian, jakie zostały wykonane.
I to właśnie tą opcje wykorzystamy w naszym przykładzie.
Musimy bowiem zamienić dwa ciasteczka - wordpress_logged_in oraz wordpress.
Gdybyśmy używali trybu replacements - Burp wysłał by dwa żądania - pierwsze z podmienionym jedynie pierwszym ciasteczkiem i drugie z podmienionym jedynie drugim ciasteczkiem.
Jako typ wybieramy Match cookie Name, replace value.
Poszukuje ono ciasteczka o podanej nazwie i zamienia jedynie jego wartość.
W polu match - wklejamy pierwszą nazwę ciasteczka, które będziemy podmieniać
W polu replace wklejamy wartość ciasteczka dla użytkownika redaktor.
Analogicznie postępujemy z drugim ciasteczkiem zmieniając tylko jego nazwę.
I zasadniczo to już wszystko.
W celu przyspieszenia działania całego mechanizmu, można jeszcze określić dodatkowe warunki - kiedy podmiana ma mieć miejsce.
W naszym testowym przypadku nie musimy tego robić.
Ryzyko, że w jakiejkolwiek innej stronie wystąpi ciasteczko o takiej samej nazwie jest praktycznie zerowe.
Teraz analogicznie powtarzamy całą nasza pracę, tym razem z kontem subskrybenta.
Pamiętajmy, aby po skopiowaniu wartości ciasteczka z okna incognito nie wylogowywać się.
Wtedy bowiem ciasteczko przestanie być ważne i całość nie zadziała.
Można już przeglądać stronę będąc zalogowanym jako administrator.
Każde żądanie, zostanie wysłane ponownie - tym razem ze zmienionymi ciasteczkami.
Nowo wysłane żądania widoczne są w stosownej tabeli okna AutoRepeater.
Różnice pomiędzy oryginalnym i zmienionym żądaniem można porównać przy użyciu zakładki Diff.
Dzięki temu od razu wiadomo, czy narzędzie jest skonfigurowane prawidłowo.
No dobrze - ale jak stwierdzić, że gdzieś na stronie znajduje się błąd?
Musimy przejrzeć każde z automatycznie przesłanych żądań.
WordPress - gdy użytkownik nie posiada uprawnień do wykonywania danej czynności wyświetla odpowiedni komunikat.
Jeżeli to on znajduje się w odpowiedzi - wiemy, że wszystko działa prawidłowo.
A jeżeli zamiast niego znajduje się odpowiedź - wtedy warto się zastanowić, czy dany użytkownik powinien mieć możliwość wykonania konkretnej akcji.
Ale jak stwierdzić, które żądania są interesujące a które nie?
Jednym ze sposobów jest wartość kolumny Response Length.
Jeżeli jest ona względnie mała - to najprawdopodobniej będzie to treść błędu.
W najnowszej wersji narzędzia możemy użyć dodatkowej opcji, która pokoloruje odpowiedzi według podanego przez nas schematu.
My - użyjemy czerwonego koloru wszędzie tam, gdzie w odpowiedzi znajduje się ciąg: "Przepraszamy, nie posiadasz uprawnień do tej strony".
Wtedy od razu jak na dłoni widać - że dane żądania, nie są dla nas interesujące.
Całość działa podobnie jak tworzenie reguł.
Wybieramy kolor a następnie, że interesuje nas odpowiedź zmodyfikowanego żądania.
I to tyle - teraz nasza tabelka będzie odpowiednio pokolorowana.
Oczywiście to nie jedyny sposób użycia tego narzędzia.
Podobnie można go wykorzystać do testowania dostępu dla niezalogowanych użytkowników.
Zamiast zamieniać ciasteczka - wystarczy wybrać opcję, która je usunie.
