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ść.