Hacking for all!

https://chacker.pl/

Jesteśmy wreszcie gotowi, aby złożyć części razem i zbudować exploit:

UWAGA: Czasami wymagane jest użycie NOP lub padding przed shellcode. Shellcode Metasploit potrzebuje trochę miejsca na stosie, aby zdekodować się podczas wywoływania procedury GETPC, jak opisano przez „sk” w jego artykule Phrack 62:

UWAGA: Czasami wymagane jest użycie NOP lub padding przed shellcode. Shellcode Metasploit potrzebuje trochę miejsca na stosie, aby zdekodować się podczas wywoływania procedury GETPC, jak opisano przez „sk” w jego artykule Phrack 62:

https://chacker.pl/

W systemach Windows stos znajduje się w dolnym zakresie adresów pamięci. Stanowi to problem z techniką ataku Aleph 1, której użyliśmy w exploitach Linuksa. W przeciwieństwie do scenariusza programu meet.exe w przypadku exploitów w świecie rzeczywistym nie możemy po prostu kontrolować EIP za pomocą adresu powrotu na stosie. Adres prawdopodobnie będzie zawierał 0x00 na początku i spowoduje problemy, gdy przekażemy ten bajt NULL do podatnego programu. W systemach Windows trzeba będzie znaleźć inny wektor ataku. Często znajdziesz część (jeśli nie całość) swojego bufora w jednym z rejestrów, gdy program Windows ulegnie awarii. Jak pokazano w poprzedniej sekcji, kontrolujemy obszar stosu, w którym program ulega awarii. Wszystko, co musimy zrobić, to umieścić nasz kod powłoki zaczynający się od bajtu 496 i nadpisać wskaźnik powrotu adresem kodu operacji, aby jmp lub wywołać esp. Wybraliśmy ten wektor ataku, ponieważ każdy z tych kodów operacji umieści wartość ESP w EIP i wykona kod pod tym adresem. Inną opcją jest znalezienie sekwencji instrukcji, która wykonuje push esp, a następnie ret. Aby znaleźć adres żądanego kodu operacji, musimy przeszukać załadowane moduły (biblioteki DLL), które są dynamicznie powiązane z programem ProSSHD. Pamiętaj, że w Immunity Debugger możesz wyświetlić listę połączonych modułów, naciskając ALT-E. Użyjemy narzędzia Mona, aby przeszukać załadowane moduły. Najpierw użyjemy Mona, aby ustalić, które moduły nie uczestniczą w kontrolach ograniczających eksploatację, takich jak /REBASE i randomizacja układu przestrzeni adresowej (ASLR). Często zdarza się, że moduły dołączone do aplikacji innej firmy nie uczestniczą w niektórych lub wszystkich tych kontrolach. Aby dowiedzieć się, które moduły chcemy wykorzystać jako część naszego eksploitu, uruchomimy polecenie !mona modules z wnętrza Immunity Debugger. Możesz również użyć !mona modules -o, aby wykluczyć moduły systemu operacyjnego. Wystąpienie wsshd.exe, do którego wcześniej dołączyliśmy za pomocą Immunity Debugger, powinno być nadal aktywne, pokazując poprzedni wzorzec w EIP. Jeśli nadal nie jest aktywne, kontynuuj i ponownie uruchom poprzednie kroki, dołączając do procesu wsshd.exe. Po dołączeniu debugera do procesu uruchom następujące polecenie, aby uzyskać takie same wyniki:

Jak widać z próbki danych wyjściowych Mona, moduł MSVCR71.dll nie jest chroniony przez większość dostępnych kontroli exploitmitigation. Co najważniejsze, nie jest on ponownie bazowany i nie uczestniczy w ASLR. Oznacza to, że jeśli znajdziemy nasz pożądany kod operacji, jego adres powinien być niezawodny w naszym exploicie, omijając ASLR! Będziemy teraz nadal używać wtyczki Mona od Petera Van Eeckhoutte’a (znanego również jako corelanc0d3r) i zespołu Corelan. Tym razem użyjemy jej, aby znaleźć nasz pożądany kod operacji z MSVCR71.DLL. Uruchom następujące polecenie:

Jak widać z próbki danych wyjściowych Mona, moduł MSVCR71.dll nie jest chroniony przez większość dostępnych kontroli exploitmitigation. Co najważniejsze, nie jest on ponownie bazowany i nie uczestniczy w ASLR. Oznacza to, że jeśli znajdziemy nasz pożądany kod operacji, jego adres powinien być niezawodny w naszym exploicie, omijając ASLR! Będziemy teraz nadal używać wtyczki Mona od Petera Van Eeckhoutte’a (znanego również jako corelanc0d3r) i zespołu Corelan. Tym razem użyjemy jej, aby znaleźć nasz pożądany kod operacji z MSVCR71.DLL. Uruchom następujące polecenie:

Jak widać z próbki danych wyjściowych Mona, moduł MSVCR71.dll nie jest chroniony przez większość dostępnych kontroli exploitmitigation. Co najważniejsze, nie jest on ponownie bazowany i nie uczestniczy w ASLR. Oznacza to, że jeśli znajdziemy nasz pożądany kod operacji, jego adres powinien być niezawodny w naszym exploicie, omijając ASLR! Będziemy teraz nadal używać wtyczki Mona od Petera Van Eeckhoutte’a (znanego również jako corelanc0d3r) i zespołu Corelan. Tym razem użyjemy jej, aby znaleźć nasz pożądany kod operacji z MSVCR71.DLL. Uruchom następujące polecenie:

Weź wynik poprzedniego polecenia i dodaj go do skryptu ataku (zauważ, że zmienimy nazwę zmiennej z buf na sc). Wykluczamy bajt „\x00”, ponieważ bajty null są zazwyczaj problematyczne. W module scp.py znajduje się parametr o nazwie sanitize. Domyślnie jego wartość jest ustawiana przez wywołanie funkcji o nazwie _sh_quote, która zwraca nasz ciąg znaków ujętych w pojedyncze cudzysłowy. Jest to prawdopodobnie ochrona w kodzie, aby zapobiec lukom w zabezpieczeniach związanym z wstrzykiwaniem poleceń. Zauważysz w nadchodzącym kodzie, że ustawiliśmy sanitize na wartość równą funkcji lambda, która po prostu zwraca tę samą wartość.

https://chacker.pl/

Następnie będziesz musiał użyć wtyczki mona.py PyCommand od Corelan Team, aby wygenerować wzorzec, który określi liczbę bajtów, w których uzyskamy kontrolę. Aby uzyskać mona.py, przejdź do https://github.com/corelan/mona i pobierz najnowszą kopię narzędzia. Zapisz ją w folderze PyCommands w folderze Immunity Debugger. Będziemy używać skryptów wzorca przeniesionych z Metasploit. Najpierw chcemy skonfigurować nasz katalog roboczy, w którym będą zapisywane dane wyjściowe generowane przez Mona. Dlatego uruchom instancję Immunity Debugger. Nie martw się ładowaniem programu w tym momencie. Kliknij w powłoce poleceń Pythona u dołu okna debugera, a następnie wprowadź polecenie pokazane tutaj:

Jeśli Immunity Debugger przejdzie do okna dziennika, możesz po prostu kliknąć przycisk „c” na pasku wstążki, aby powrócić do głównego okna CPU. Teraz musimy wygenerować 500-bajtowy wzór do wykorzystania w naszym

który wygeneruje 500-bajtowy wzór, przechowując go w nowym folderze i pliku, w którym kazałeś Monie zapisać jego dane wyjściowe. Sprawdź swój katalog C: \grayhat\mona_logs\ pod kątem nowego folderu, prawdopodobnie zatytułowanego wsshd. W tym katalogu powinien znajdować się nowy plik o nazwie pattern.txt. To jest plik, z którego chcesz skopiować wygenerowany wzór. Jak mówi Mona, nie kopiuj wzoru z okna dziennika Immunity Debugger, ponieważ może zostać obcięty. Zapisz nową kopię skryptu ataku prosshd1.py na swojej maszynie wirtualnej Kali Linux (w tym przykładzie użyto nazwy prosshd2.py). Skopiuj wzór ASCII z pliku pattern.txt i zmień wiersz req, aby go uwzględnić, w następujący sposób:

UWAGA: Wzór po skopiowaniu będzie bardzo długą linią. Sformatowaliśmy linię pokazaną tutaj tak, aby zmieściła się na wydrukowanej stronie. Uruchom nowy skrypt z okna terminala Kali Linux za pomocą python3 prosshd2.py. Wynik jest pokazany poniżej.

UWAGA: Wzór po skopiowaniu będzie bardzo długą linią. Sformatowaliśmy linię pokazaną tutaj tak, aby zmieściła się na wydrukowanej stronie. Uruchom nowy skrypt z okna terminala Kali Linux za pomocą python3 prosshd2.py. Wynik jest pokazany poniżej.

Można zobaczyć, że po 492 bajtach bufora nadpisujemy wskaźnik powrotu z bajtów 493 do 496 wartością 41347141. Jest to widoczne po przejrzeniu sekcji Stack programu Immunity Debugger. Następnie, 4 bajty dalej, po bajcie 496, reszta bufora znajduje się na górze stosu po awarii programu. Narzędzie Metasploit pattern offset, którego właśnie użyliśmy z Mona, pokazuje przesunięcie przed rozpoczęciem wzorca.

https://chacker.pl/

Otwórz swój ulubiony edytor na swojej maszynie wirtualnej Kali Linux i utwórz następujący skrypt, zapisując go jako prosshd1.py, aby zweryfikować podatność serwera:

UWAGA: Moduły paramiko i scp są wymagane do tego skryptu. Moduł paramiko powinien być już zainstalowany, ale musisz zweryfikować, czy Twoja wersja Kali zawiera scp. Jeśli spróbujesz uruchomić poniższy skrypt i otrzymasz błąd dotyczący scp, musisz pobrać i zainstalować moduł scp, uruchamiając pip3 install scp. Będziesz również musiał połączyć się raz z domyślnym klientem SSH z powłoki poleceń w Kali Linux, aby podatny serwer docelowy znalazł się na liście znanych hostów SSH. Musisz utworzyć konto użytkownika na docelowej maszynie wirtualnej Windows z uruchomionym ProSSHD, którego użyjesz w swoim exploicie. Używamy nazwy użytkownika test1 z hasłem asdf. Utwórz to konto lub podobne i użyj go w tym laboratorium.

Ten skrypt zostanie uruchomiony z hosta atakującego i skierowany na cel (uruchomiony w środowisku VMware).

UWAGA: Pamiętaj, aby zmienić adres IP tak, aby odpowiadał Twojemu podatnemu serwerowi i sprawdź, czy utworzyłeś konto użytkownika test1 na swojej maszynie wirtualnej z systemem Windows.

Okazuje się, że w tym przypadku luka istnieje w procesie potomnym, wsshd.exe, który istnieje tylko wtedy, gdy istnieje aktywne połączenie z serwerem. Dlatego będziemy musieli uruchomić exploit, a następnie szybko podłączyć debuger, aby kontynuować analizę. Dlatego funkcja sleep() jest używana z argumentem 15 sekund, co daje nam czas na podłączenie. Wewnątrz maszyny VMware możesz podłączyć debuger do podatnego programu, wybierając Plik | Dołącz. Wybierz proces wsshd.exe, a następnie kliknij przycisk Dołącz, aby uruchomić debuger.

UWAGA: Może być pomocne posortowanie ekranu Attach według kolumny Name, aby szybko znaleźć proces. Jeśli potrzebujesz więcej czasu na dołączenie, możesz zwiększyć liczbę sekund przekazanych jako argument do funkcji sleep(). Oto, co trzeba zrobić! Uruchom skrypt ataku z Kali za pomocą następującego polecenia, a następnie szybko przełącz się na cel VMware i dołącz Immunity Debugger do wsshd.exe:

Gdy debuger się uruchomi i załaduje proces, naciśnij klawisz F9, aby „kontynuować” program. W tym momencie exploit powinien zostać dostarczony, a prawy dolny róg debugera powinien zmienić kolor na żółty i wyświetlić napis „Wstrzymano”. W zależności od wersji systemu Windows, której używasz jako celu, debuger może wymagać ponownego naciśnięcia klawisza F9 po pierwszej pauzie. Dlatego jeśli nie widzisz 0x41414141 w rejestrze EIP, jak pokazano poniżej, naciśnij klawisz F9 jeszcze raz. Często przydatne jest umieszczenie okna ataku w pozycji, która umożliwia wyświetlenie prawego dolnego rogu debugera, aby zobaczyć, kiedy debuger się zatrzymuje.

Jak widać, mamy kontrolę nad EIP, które teraz zawiera 0x41414141.

https://chacker.pl/

Serwer ProSSHD to serwer sieciowy SSH, który umożliwia użytkownikom „bezpieczne” łączenie się i zapewnia dostęp do powłoki przez zaszyfrowany kanał. Serwer działa na porcie 22. Kilka lat temu wydano ostrzeżenie ostrzegające przed przepełnieniem bufora w przypadku akcji po uwierzytelnieniu. Oznacza to, że użytkownik musi już mieć konto na serwerze, aby wykorzystać lukę. Luka może zostać wykorzystana poprzez wysłanie ponad 500 bajtów do ciągu ścieżki polecenia GET protokołu SCP (Secure Copy Protocol).

W tym momencie skonfigurujemy podatny serwer ProSSHD v1.2 na gościnnej maszynie wirtualnej (VM) VMware z systemem Windows 10 x64 20H2  Enterprise. Możesz również wybrać inną wersję systemu Windows. Każda wersja systemu Windows z uruchomionym Immunity Debugger może dawać nieco inne wyniki; jednak ostateczny exploit użyty w tym rozdziale został przetestowany w wielu wersjach systemu Windows. Użyjemy VMware, ponieważ pozwala nam uruchamiać, zatrzymywać i ponownie uruchamiać naszą maszynę wirtualną znacznie szybciej niż ponowne uruchamianie.

UWAGA: Ponieważ uruchamiamy podatny program, najbezpieczniejszym sposobem przeprowadzenia testów jest ustawienie wirtualnej karty sieciowej (VNIC) VMware w trybie sieciowym tylko dla hosta. Zapewni to, że żadne zewnętrzne maszyny nie będą mogły połączyć się z naszą podatną maszyną wirtualną.

Wewnątrz maszyny wirtualnej pobierz i zainstaluj aplikację ProSSHD, korzystając z opcji pobierania pod następującym linkiem: https://www.exploitdb.com/exploits/11618. Po pomyślnej instalacji przy użyciu „typowej” opcji instalacji uruchom program xwpsetts.exe z katalogu instalacyjnego (na przykład instalacja może znajdować się w C:\Users\Public\Program Files (x86)\Lab-NC\ProSSHD\xwpsetts.exe). Po uruchomieniu programu kliknij Uruchom, a następnie Uruchom jako exe (jak pokazano poniżej). Może być również konieczne kliknięcie Zezwalaj na połączenie, jeśli pojawi się zapora sieciowa. Jeśli wersja próbna jest wyświetlana jako wygasła, może być konieczne ponowne uruchomienie maszyny wirtualnej lub wyłączenie opcji automatycznego ustawiania czasu, ponieważ ta wersja ProSSHD nie jest już obsługiwana, jak to ma miejsce w przypadku wielu programów zawierających luki w zabezpieczeniach.

UWAGA: Jeśli funkcja Data Execution Prevention (DEP) jest uruchomiona dla wszystkich programów i usług na docelowej maszynie wirtualnej, musisz tymczasowo skonfigurować wyjątek dla ProSSHD. Najszybszym sposobem sprawdzenia jest przytrzymanie klawisza Windows i naciśnięcie klawisza BREAK na klawiaturze, aby wyświetlić Panel sterowania systemem. Po lewej stronie panelu sterowania kliknij Zaawansowane ustawienia systemu. W menu podręcznym kliknij Ustawienia w obszarze Wydajność. Kliknij prawy panel zatytułowany Zapobieganie wykonywaniu danych. Jeśli opcja „Włącz funkcję DEP dla wszystkich programów i usług z wyjątkiem tych, które wybiorę” jest już wybrana, musisz dodać wyjątek dla programów wsshd.exe i xwpsshd.exe. Po prostu kliknij Dodaj, wybierz te dwa pliki EXE z folderu ProSSHD i gotowe!

Teraz, gdy serwer SSH jest uruchomiony, musisz określić adres IP systemu i użyć klienta SSH, aby połączyć się z nim z komputera Kali Linux. W naszym przypadku maszyna wirtualna z uruchomionym ProSSHD znajduje się pod adresem 192.168.209.198. Musisz albo wyłączyć zaporę systemu Windows z poziomu powłoki poleceń administracyjnych za pomocą polecenia NetSh Advfirewall set allprofiles state off, albo po prostu dodać regułę zezwalającą na ruch przychodzący na port TCP 22 dla SSH. W tym momencie podatna aplikacja i debuger działają na podatnym serwerze, ale nie są jeszcze podłączone, dlatego zaleca się zapisanie stanu maszyny wirtualnej VMware poprzez utworzenie migawki. Po zakończeniu migawki możesz powrócić do tego punktu, po prostu powracając do migawki. Ta sztuczka pozwoli Ci zaoszczędzić cenny czas testowania, ponieważ możesz pominąć wszystkie poprzednie konfiguracje i ponowne uruchomienia w kolejnych iteracjach testowania.

https://chacker.pl/

Proces tworzenia exploitów często składa się z następujących kroków:

1. Kontroluj wskaźnik instrukcji.
2. Określ przesunięcie(a).
3. Określ wektor ataku.
4. Zbuduj exploit.
5. Przetestuj exploit.

6. Debuguj exploit, jeśli to konieczne.

https://chacker.pl/

Następnie użyjesz domyślnej instalacji Pythona w systemie Kali Linux. Jeśli biblioteki paramiko i scp nie są jeszcze zainstalowane, musisz je zainstalować za pomocą pip. Docelowym systemem operacyjnym, na którym działa podatna aplikacja używana w przykładach, jest Windows 10 x64 20H2 Enterprise. W tej sekcji kontynuujemy korzystanie z Immunity Debugger, a także używamy wtyczki Mona od Petera Van Eeckhoutte i zespołu Corelan (https://www.corelan.be). Celem jest kontynuacja procesu opracowywania exploitów omówionego do tej pory. Następnie dowiesz się, jak przejść od porady dotyczącej podatności do podstawowego exploita proof-of-concept.

https://chacker.pl/

Do tego laboratorium musisz pobrać i zainstalować Immunity Debugger w systemie Windows z powyższego łącza. Immunity Debugger nadal jest zależny od Pythona 2.7, który zostanie zainstalowany automatycznie, jeśli nie jest już zainstalowany w systemie. Będziesz debugować program meet.exe, który wcześniej skompilowałeś. Używając Python IDLE w systemie Windows, wpisz następujące polecenie:

W poprzednim kodzie przekazaliśmy drugi argument 408 A. Program powinien automatycznie uruchomić się pod kontrolą debugera. Być może będziesz musiał przekazać wszelkie wyjątki czasu wykonania, naciskając SHIFT-F9. 408 A przepełni bufor. Teraz jesteśmy gotowi, aby rozpocząć analizę programu. Interesuje nas wywołanie strcpy() z wnętrza funkcji Greeting(), ponieważ wiadomo, że jest podatne na ataki z powodu braku sprawdzania granic. Znajdźmy je, uruchamiając okno Executable Modules, które można otworzyć za pomocą ALT-E. Kliknij dwukrotnie moduł „meet”, a zostaniesz przeniesiony do wskaźników funkcji programu meet.exe. Zobaczysz wszystkie funkcje programu (w tym przypadku Greeting i Main). Przejdź strzałką w dół do wiersza JMP meet.greeting (możesz musieć go poszukać), a następnie naciśnij ENTER, aby przejść do tej instrukcji JMP w funkcji Greeting, jak pokazano tutaj:

UWAGA: Jeśli nie widzisz nazw symboli, takich jak Greeting, strcpy i printf, być może nie skompilowałeś pliku binarnego z symbolami debugowania. Możesz również zobaczyć mniejszą lub większą tabelę skoków, w zależności od używanej wersji systemu Windows. Nawet kompilacja w innej wersji systemu Windows może dać różne wyniki. Jeśli nadal nie widzisz symboli po prawej stronie, patrząc na ekran, po prostu postępuj zgodnie z instrukcjami w następnym akapicie, aby wyszukać ciąg ASCII „Hello %s %s” i przerwać na instrukcji CALL kilka wierszy nad nim. Jest to wywołanie strcpy, które można zweryfikować, klikając je i naciskając ENTER. Teraz, gdy patrzymy na funkcję Greeting() w oknie Deasemblera, ustawmy punkt przerwania przy wywołaniu podatnej funkcji (strcpy). Przesuwaj strzałkę w dół, aż dojdziesz do wiersza 0x011C6EF4. Ponownie, adresowanie i symbole w Twojej wersji systemu Windows mogą być inne. Jeśli tak, po prostu poszukaj instrukcji call kilka linijek nad disasemblacją pokazującą ASCII „Hello %s %s” po prawej stronie, aby zobaczyć, gdzie ustawić punkt przerwania. Możesz sprawdzić, czy jest to prawidłowe wywołanie, klikając instrukcję i naciskając ENTER. Powinno to pokazać, że wywołanie jest wykonywane do funkcji strcpy(). W tym wierszu naciśnij F2, aby ustawić punkt przerwania; adres powinien zmienić kolor na czerwony. Ten punkt przerwania pozwala na szybki powrót do tego punktu. Na przykład w tym momencie uruchom ponownie program za pomocą CTRL-F2, a następnie naciśnij F9, aby przejść do punktu przerwania. Powinieneś teraz zobaczyć, że Immunity Debugger zatrzymał się na wywołaniu funkcji, która nas interesuje (strcpy).

UWAGA: Adresy przedstawione tu prawdopodobnie będą się różnić w Twoim systemie ze względu na rebasing i ASLR. Dlatego powinieneś postępować zgodnie z technikami, a nie konkretnymi adresami. Ponadto, w zależności od wersji systemu operacyjnego, może być konieczne ręczne ustawienie punktu przerwania przy każdym uruchomieniu programu, ponieważ Immunity Debugger wydaje się mieć problemy z trwałością punktu przerwania w niektórych wersjach systemu Windows. WinDbg jest świetną alternatywą, ale nie jest tak intuicyjny. Teraz, gdy mamy ustawiony punkt przerwania w wywołaniu podatnej funkcji (strcpy), możemy kontynuować, przechodząc przez funkcję strcpy (naciskając klawisz F8). Gdy rejestry się zmienią, zobaczysz, że staną się czerwone. Ponieważ właśnie wykonaliśmy wywołanie funkcji strcpy, powinieneś zobaczyć, że wiele rejestrów zmieni kolor na czerwony. Kontynuuj przechodzenie przez program, aż dojdziesz do instrukcji RETN, która jest ostatnim wierszem kodu w funkcji powitalnej. Na przykład, ponieważ „wskaźnik powrotu” został nadpisany czterema A, debugger wskazuje, że funkcja zamierza powrócić do 0x41414141. Zwróć również uwagę, jak funkcja epilog skopiowała adres EBP (Extended Base Pointer) do ESP (Extended Stack Pointer), a następnie zdjęła wartość ze stosu (0x41414141) do EBP, jak pokazano poniżej.

UWAGA: Jeśli nie widzisz nazw symboli, takich jak Greeting, strcpy i printf, być może nie skompilowałeś pliku binarnego z symbolami debugowania. Możesz również zobaczyć mniejszą lub większą tabelę skoków, w zależności od używanej wersji systemu Windows. Nawet kompilacja w innej wersji systemu Windows może dać różne wyniki. Jeśli nadal nie widzisz symboli po prawej stronie, patrząc na ekran, po prostu postępuj zgodnie z instrukcjami w następnym akapicie, aby wyszukać ciąg ASCII „Hello %s %s” i przerwać na instrukcji CALL kilka wierszy nad nim. Jest to wywołanie strcpy, które można zweryfikować, klikając je i naciskając ENTER. Teraz, gdy patrzymy na funkcję Greeting() w oknie Deasemblera, ustawmy punkt przerwania przy wywołaniu podatnej funkcji (strcpy). Przesuwaj strzałkę w dół, aż dojdziesz do wiersza 0x011C6EF4. Ponownie, adresowanie i symbole w Twojej wersji systemu Windows mogą być inne. Jeśli tak, po prostu poszukaj instrukcji call kilka linijek nad disasemblacją pokazującą ASCII „Hello %s %s” po prawej stronie, aby zobaczyć, gdzie ustawić punkt przerwania. Możesz sprawdzić, czy jest to prawidłowe wywołanie, klikając instrukcję i naciskając ENTER. Powinno to pokazać, że wywołanie jest wykonywane do funkcji strcpy(). W tym wierszu naciśnij F2, aby ustawić punkt przerwania; adres powinien zmienić kolor na czerwony. Ten punkt przerwania pozwala na szybki powrót do tego punktu. Na przykład w tym momencie uruchom ponownie program za pomocą CTRL-F2, a następnie naciśnij F9, aby przejść do punktu przerwania. Powinieneś teraz zobaczyć, że Immunity Debugger zatrzymał się na wywołaniu funkcji, która nas interesuje (strcpy).

UWAGA: Adresy przedstawione w tym rozdziale prawdopodobnie będą się różnić w Twoim systemie ze względu na rebasing i ASLR. Dlatego powinieneś postępować zgodnie z technikami, a nie konkretnymi adresami. Ponadto, w zależności od wersji systemu operacyjnego, może być konieczne ręczne ustawienie punktu przerwania przy każdym uruchomieniu programu, ponieważ Immunity Debugger wydaje się mieć problemy z trwałością punktu przerwania w niektórych wersjach systemu Windows. WinDbg jest świetną alternatywą, ale nie jest tak intuicyjny. Teraz, gdy mamy ustawiony punkt przerwania w wywołaniu podatnej funkcji (strcpy), możemy kontynuować, przechodząc przez funkcję strcpy (naciskając klawisz F8). Gdy rejestry się zmienią, zobaczysz, że staną się czerwone. Ponieważ właśnie wykonaliśmy wywołanie funkcji strcpy, powinieneś zobaczyć, że wiele rejestrów zmieni kolor na czerwony. Kontynuuj przechodzenie przez program, aż dojdziesz do instrukcji RETN, która jest ostatnim wierszem kodu w funkcji powitalnej. Na przykład, ponieważ „wskaźnik powrotu” został nadpisany czterema A, debugger wskazuje, że funkcja zamierza powrócić do 0x41414141. Zwróć również uwagę, jak funkcja epilog skopiowała adres EBP (Extended Base Pointer) do ESP (Extended Stack Pointer), a następnie zdjęła wartość ze stosu (0x41414141) do EBP, jak pokazano poniżej.

Aby kontynuować sprawdzanie stanu uszkodzonej maszyny, w oknie stosu przewiń w dół do bieżącej ramki stosu (bieżąca ramka stosu zostanie podświetlona). Możesz również powrócić do bieżącej ramki stosu, wybierając wartość rejestru ESP, a następnie klikając prawym przyciskiem myszy tę wybraną wartość i wybierając Follow in Stack. Zauważysz, że kopię bufora można również znaleźć w lokalizacji ESP+4, jak pokazano poniżej. Informacje takie stają się cenne później, gdy wybieramy wektor ataku

Jak widać, Immunity Debugger jest łatwy w użyciu.

UWAGA : Immunity Debugger działa tylko w przestrzeni użytkownika i tylko dla aplikacji 32-bitowych w momencie pisania tego tekstu. Jeśli musisz zanurzyć się w przestrzeni jądra, będziesz musiał użyć debugera Ring0, takiego jak WinDbg firmy Microsoft.

W tym laboratorium pracowaliśmy z Immunity Debugger, aby śledzić przepływ wykonywania z naszymi złośliwymi danymi jako danymi wejściowymi. Zidentyfikowaliśmy podatne wywołanie strcpy() i ustawiliśmy punkt przerwania oprogramowania, aby przejść przez funkcję. Następnie pozwoliliśmy na kontynuowanie wykonywania i potwierdziliśmy, że możemy uzyskać kontrolę nad wskaźnikiem instrukcji. Stało się tak, ponieważ funkcja strcpy() pozwala nam nadpisać wskaźnik powrotu używany przez funkcję Greeting(), aby zwrócić kontrolę z powrotem do main().

https://chacker.pl/

Popularnym debugerem w trybie użytkownika jest Immunity Debugger, który możesz pobrać ze strony https://www.immunityinc.com/products/debugger/. W momencie pisania tego tekstu stabilną wersją jest wersja 1.85, używana w tym rozdziale. Główny ekran Immunity Debugger jest podzielony na pięć sekcji. Sekcja „Code” lub „Disassembler” (w lewym górnym rogu) służy do przeglądania zdemontowanych modułów. Sekcja „Registers” (w prawym górnym rogu) służy do monitorowania stanu rejestrów w czasie rzeczywistym. Sekcja „Hex Dump” lub „Data” (w lewym dolnym rogu) służy do przeglądania surowego heksadecymalnego pliku binarnego. Sekcja „Stack” (w prawym dolnym rogu) służy do przeglądania stosu w czasie rzeczywistym. Możesz zobaczyć te sekcje na nadchodzącym obrazku. Sekcja „Information” (w lewym środkowym rogu) służy do wyświetlania informacji o instrukcji wyróżnionej w sekcji Code. Każda sekcja ma menu kontekstowe dostępne po kliknięciu prawym przyciskiem myszy w tej sekcji. Immunity Debugger ma również oparty na Pythonie interfejs powłoki na dole okna debugera, aby umożliwić automatyzację różnych zadań, a także wykonywanie skryptów, aby pomóc w rozwijaniu exploitów. Mimo że dostępne są inne aktywnie utrzymywane debugery, społeczność użytkowników stworzyła bogate w funkcje rozszerzenia, takie jak Mona.py od Corelanc0d3r. Przed kontynuowaniem pobierz i zainstaluj Immunity Debugger z podanego wyżej łącza. Możesz rozpocząć debugowanie programu za pomocą Immunity Debugger na kilka sposobów:

• Otwórz Immunity Debugger i wybierz Plik | Otwórz.
• Otwórz Immunity Debugger i wybierz Plik | Dołącz.

• Wywołaj Immunity Debugger z wiersza poleceń — na przykład z wiersza poleceń Windows IDLE Python, w następujący sposób:

• Otwórz Immunity Debugger i wybierz Plik | Otwórz.
• Otwórz Immunity Debugger i wybierz Plik | Dołącz.

• Wywołaj Immunity Debugger z wiersza poleceń — na przykład z wiersza poleceń Windows IDLE Python, w następujący sposób:

Poprzednia linia poleceń uruchomi meet.exe wewnątrz Immunity Debugger, jak pokazano tutaj:

Debuger może wychwycić wyjątek, a jeśli tak się stanie, musisz przekazać wyjątek, naciskając SHIFT-F9, aby przejść do domyślnego punktu przerwania w punkcie wejścia programu. Podczas nauki Immunity Debugger będziesz chciał znać typowe polecenia wymienione w Tabeli  (jeśli używasz hosta macOS do przekazywania tych poleceń do maszyny wirtualnej Windows, może być konieczne zamapowanie powiązań klawiszy).

Debuger może wychwycić wyjątek, a jeśli tak się stanie, musisz przekazać wyjątek, naciskając SHIFT-F9, aby przejść do domyślnego punktu przerwania w punkcie wejścia programu. Podczas nauki Immunity Debugger będziesz chciał znać typowe polecenia wymienione w Tabeli  (jeśli używasz hosta macOS do przekazywania tych poleceń do maszyny wirtualnej Windows, może być konieczne zamapowanie powiązań klawiszy).

W tym przypadku możemy zobaczyć główny moduł wykonywalny dla meet.exe wymieniony jako pierwszy, a następnie różne biblioteki DLL. Ta informacja jest przydatna, ponieważ, jak zobaczysz później, te moduły zawierają kody operacji, które są dostępne podczas eksploatacji. Należy pamiętać, że adresowanie będzie się różnić w każdym systemie ze względu na randomizację układu przestrzeni adresowej (ASLR) i inne czynniki.

https://chacker.pl/

Jeśli wpiszesz cl.exe /?, otrzymasz ogromną listę opcji kompilatora. Jednak większość z nich nie jest dla nas interesująca w tym momencie. Tabela  zawiera listę i opis flag, których będziesz używać.

Ponieważ będziemy teraz używać debugera, skompilujmy meet.exe z pełnymi informacjami debugowania i wyłączmy funkcjonalność stack canary.

UWAGA: Przełącznik /GS włącza implementację ochrony stack canary firmy Microsoft, która jest dość skuteczna w zatrzymywaniu ataków przepełnienia bufora. Aby dowiedzieć się więcej o istniejących lukach w oprogramowaniu (zanim ta funkcja stała się dostępna), wyłączymy ją za pomocą flagi /GS–.

Wykonaj następujący krok, aby skompilować wersję programu meet.c, której będziesz używać w laboratorium

Świetnie, teraz, gdy masz plik wykonywalny zbudowany z informacjami debugowania, czas zainstalować debuger i sprawdzić, jak debugowanie w systemie Windows wypada w porównaniu z debugowaniem w systemie Unix. W tym laboratorium użyłeś programu Visual Studio 2019 Community Edition do skompilowania programów hello.c i meet.c. Skompilowaliśmy program meet.c z pełnymi informacjami debugowania, które pomogą nam w następnym laboratorium. Przyjrzeliśmy się również różnym flagom kompilatora, których można użyć do wykonywania działań, takich jak wyłączenie kontroli łagodzenia eksploitów /GS.