Po pierwszej fazie rekonesansu, czyli enumeracji subdomen, powinieneś mieć sporo informacji o atakowanej organizacji. Następnym krokiem jest wybranie jednej subdomeny i wykonanie na niej szczegółowego rekonesansu. W tym artykule poznasz narzędzia służące do enumeracji ścieżek i zapytań. Dowiesz się również, jak z nich korzystać i zautomatyzować cały proces rekonesansu pojedynczej domeny. Opisywane badania oparte są na metodologii OWASP oraz metodologii zawartej w książce „Hack Tricks” autorstwa Carlosa Polopa.
Generalnie, gdy testem objęta będzie tylko jedna domena to celem rekonesansu będą następujące zasoby:
Przed rozpoczęciem pracy uruchom nowy projekt w Burp Suite i wyłącz przechwytywanie, jak pokazano na poniższym zrzucie ekranu:
Następnie przygotuj odpowiednie katalogi, do których będą zapisywane wyniki rekonesansu (większość wyników z wykorzystywanych narzędzi zostanie zapisana w pliku „recon.txt”). Rozwiąż adresy IP domeny docelowej i ustaw odpowiednie zmienne, na których będziemy działać. Ustaw domenę docelową w pierwszym wierszu zamiast zmiennej „$ domain”, jak pokazano poniżej. Użyte narzędzie to dig:
Pierwszym zadaniem jest sprawdzenie otwartych portów w rozwiązanych adresach IP docelowej subdomeny. Następnie przeprowadzamy wykrywanie systemu operacyjnego, wykrywanie wersji usług, skanowanie skryptami NSE i śledzenie trasy ruchu sieciowego. Ograniczamy skanowanie tylko do otwartych portów. Zapisujemy wyniki w formacie txt oraz w formacie grep – będzie to przydatne w przypadku, gdy pojawi się potrzeba użycia innych narzędzi, takich jak BruteSpray. Użyte narzędzie to nmap. Poniższy zrzut ekranu pokazuje, jak zautomatyzować ten proces za pomocą bash’a:
Następnie sprawdzamy, czy na serwerze istnieją pliki „robots.txt” i „sitemap.xml” i wydobywamy zawarte w nich adresy URL. Aby wyodrębnić zawartość pliku „robots.txt”, wystarczy użyć polecania „curl”, podczas gdy zawartość pliku „sitemap.xml” musi zostać sparsowana. W tym celu polecam skrypt, stworzony przez „yuriyyakym”, który jest dostępny pod tym linkiem. Użyte narzędzie to sitemap-urls. Poniższy zrzut ekranu pokazuje, jak zautomatyzować ten proces za pomocą bash’a:
Następnym krokiem jest zidentyfikowanie technologii używanych na stronach internetowych i sprawdzenie, czy jest używana jakaś zapora aplikacji sieci Web (z ang. WAF – Web Application Firewall). Użyte narzędzia to:
- wafw00f
- webtech
Poniższy zrzut ekranu pokazuje, jak zautomatyzować ten proces za pomocą bash’a:
Następnie wykonujemy atak siłowy (brute-force), aby odkryć znane i potencjalnie niebezpieczne skrypty na serwerze. W tym celu korzystamy z narzędzia nikto. Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Następnie używamy programu „Wapiti”, aby przeskanować punkty końcowe testowanej aplikacji internetowej, szukając błędnej konfiguracji we flagach plików cookie, CSP (Content Security Policy), zabezpieczeniach nagłówków i pliku „htaccess”. Dodatkowo sprawdzana jest podatności „shellshock” oraz możliwość wstrzyknięcia znaków nowej linii <CR><LF>. Poniższy zrzut ekranu pokazuje, jak zautomatyzować ten proces za pomocą bash;a:
Następnym krokiem jest przeszukanie sieci w celu odnalezienia nazw parametrów zawartych w plikach testowanej domeny. Użyte narzędzia to:
- gospider
- paramspider
- gau
- waybackurls
- hakrawler
- galer
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Po przeszukaniu sieci, scalamy wyniki z poprzedniej fazy rozpoznania (opisanej w poprzednim artykule) zebrane w „../urls.txt” (ale tylko te związane z testowaną subdomeną) z bieżącymi wynikami „crawlerów” w „urls.txt”. Użyte narzędzia to:
- anew
- qsreplace
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Teraz sprawdzamy wszystkie statusy adresów URL zawierających ciąg zapytania i przekieruj je do programu „Burp Suite”. Użyte narzędzia to:
- wfuzz
- Burp Suite
Poniższy zrzut ekranu pokazuje, jak zautomatyzować ten proces za pomocą bash’a:
Następnie wydobywamy wszystkie ścieżki z pliku „urls.txt” i dodajemy je do listy słów, która będzie używana do ataku siłowego na katalogi testowanej domeny. W tym celu korzystamy z narzędzia unfurl. Poniższy zrzut ekranu pokazuje, jak zautomatyzować ten proces za pomocą bash’a:
Nadszedł czas na wykonanie ataku siłowego (brute-force) w celu odgadnięcia nazw plików i katalogów używanych na serwerze aplikacji webowej w oparciu o wcześniej stworzoną listę endpointów. Do tego celu posłużymy się narzędziem ffuf. Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Następnym krokiem jest przefiltrowanie wyników w celu usunięcia potencjalnie nieistotnych odpowiedzi zwracanych przez serwer. W tym celu stworzyłem własny skrypt o nazwie „clever_ffuf” (można go pobrać z tego linku). Jednak nie powinieneś polegać tylko na nim i ręcznie sprawdzić plik „status_ffuf.txt”. Użyte narzędzia to:
- clever_ffuf
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Teraz pobieramy kod źródłowy wszystkich znalezionych, prawidłowych adresów URL i zapisujemy go w katalogu „all_source_code/”. Nazywamy każdy plik jako nazwę adresu URL. W ten sposób możesz łatwo znaleźć stronę internetową, na której np. wyciekł klucz API, jeśli znajdziesz go w późniejszych etapach tego rozpoznania. Użyte narzędzie to curl. Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Następnie używamy narzędzia „getJS„, aby zebrać więcej adresów URL zawierających pliki JavaScript. Do puli skryptów dodajemy także również linki do plików JavaScript zdobytych w trakcie scrapowania sieci („urls.txt”) i ataku siłowego („ffuf.txt”). Następnie sprawdzamy, czy są one prawidłowe. Użyte narzędzia to:
- getJS
- anew
- httpx
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Następnie ponownie zbieramy cały kod źródłowy, ale tym razem tylko z aktywnych linków JavaScript. Użyte narzędzie to curl. Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Następnym krokiem jest wyodrębnienie ścieżek i kluczy API z zebranego kodu źródłowego. Użyte narzędzia to:
- zile
- unfurl
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Następnie sprawdzamy, czy nie ma duplikatów w nowych endpointach wyodrębnionych z plików JavaScript oraz jaki kod odpowiedzi zwraca serwer. Aby to zrobić, korzystamy z narzędzia wfuzz. Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Kolejnym krokiem jest usunięcie wszystkich odpowiedzi serwera z kodami statusu 400 i 404. Następnie łączymy listy z ataków siłowych w jedną o nazwie „ffuf.txt” i przesyłamy wyniki do programu „Burp Suite” w celu dalszego przetwarzania. Użyte narzędzia to:
- wfuzz
- anew
- Burp Suite
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Sprawdzamy, czy znalezione do tej pory pliki nie mają na serwerze swoich kopii zapasowych w publicznie dostępnych katalogach. W tym celu wykorzystałem mój program o nazwie „crimson_backuper”, który można pobrać tutaj.
Użyte narzędzia to:
- crimson_backuper
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
W następnym kroku wyodrębniamy unikalne zapytania z pliku „status_params.txt” i zapisujemy je w „exp/params.txt”. Dodatkowo przygotowujemy listę katalogów i plików zdobytych w trakcie ataku siłowego, do dalszej analizy dodając „/” na koniec każdej linii w pliku „ffuf.txt„. Użyte narzędzia to:
- qsreplace
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Sprawdzamy błędy konfiguracji CORS (Cross Origin Resource Sharing) i wyszukujemy klucze API w katalogu „all_source_code/”. Użyte narzędzie to:
- CorsMe
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Na samym końcu wykonujemy atak siłowy na nazwach parametrów. Jest to bardzo czasochłonne, ale może przyczynić się do znalezienia parametrów, które nie pojawiają się przy „normalnym” użytkowaniu strony, ale mimo to są przetwarzane przez samą webaplikację – jest to możliwe, kiedy są one zadeklarowane w kodzie źródłowym, ale twórcy aplikacji nie zdecydowali się na ich „oficjalne” wykorzystanie, przez co mogą też być nieprzetestowane pod kątem bezpieczeństwa. Użyte narzędzia to:
- Arjun
Poniższy zrzut ekranu pokazuje jak można zautomatyzować ten proces za pomocą bash’a:
Po wykonaniu wszystkich tych czynności sprawdzamy następujące pliki tekstowe i katalogi:
- recon.txt — wyniki większości narzędzi używanych w całym procesie
- urls.txt — wyryte adresy URL
- status_params.txt —kody stanu zebranych parapometrów
- zile.txt —klucze api i punkty końcowe z kodów źródłowych
- status_ffuf.txt — kody statusu z pierwszego ataku siłowego na pliki i katalogi
- status_new_endpoints.txt — kody statusu z drugiego ataku siłowego na pliki i katalogi
- ffuf.txt —zebrane katalogi i pliki podczas ataków siłowych
- status_dir.txt — kody stanu wszystkich adresów URL zebranych w pliku ffuf.txt
- exp/params.txt — lista zawierająca zapytania do serwera przygotowana dla następnego modułu
- exp/dirs.txt — lista zawierająca nazwy katalogów przyogowana do następnego modułu
- exp/arjun.txt — parametry znalezione podczas ataku siłowego
- backups.txt — potencjalnie pliki kopii zapasowych
Powyższy proces został zautomatyzowany w jednym skrypcie o nazwie „crimson_target”. To jeden z trzech modułów, które są częścią narzędzia „crimson”, które nieustannie tworzę i udostępniam na Github.
Teraz powinieneś mieć dużo informacji na temat docelowej subdomeny. Następnym krokiem powinno być stricte szuganie błędów we wszystkich znalezionych plikach i parametrach. Ten proces jest zautomatyzowany w moim trzecim module o nazwie „crimson_exploit”, który zostanie opisany w następnym artykule.
References:
