Fuzzing w poszukiwaniu awarii

Fuzzing polega na wysyłaniu do programu niepoprawnych lub zbyt dużych danych wejściowych w celu wywołania nieoczekiwanego zachowania, zwłaszcza awarii. Awaria często wskazuje na błąd związany z uszkodzeniem pamięci.

W przypadku przepełnień bufora pierwszym celem jest doprowadzenie do awarii celu, aby potwierdzić istnienie przepełnienia.

Klasyczny przebieg wykorzystywania podatności wygląda następująco:

• Przeprowadzić fuzzing, aby doprowadzić program do awarii.
• Znajdź dokładne przesunięcie względem adresu powrotu.
• Przejąć kontrolę nad EIP.
• Przekierować wykonanie do shellcode.

Ta lekcja obejmuje dwa pierwsze kroki.

Aby obserwować awarie, należy podłączyć debugger (na przykład Immunity Debugger lub x64dbg w systemie Windows albo GDB w systemie Linux) do celu.

Gdy program ulegnie awarii, debugger pokaże stan rejestrów, zwłaszcza EIP, co pozwoli ustalić, czy adres powrotu został nadpisany.

Prosty fuzzer wysyła coraz dłuższe ciągi znaków, aż program ulegnie awarii. Często zaczyna się od wysłania wielu znaków „A” (0x41).

Jeśli po awarii EIP zawiera 41414141, oznacza to potwierdzenie przejęcia kontroli nad adresem powrotu.

Gdy aplikacja ulega awarii, a EIP jest równy 41414141, oznacza to, że przepełnienie dotarło do zapisanego adresu powrotu.

Nadal jednak nie wiadomo dokładnie, ile bajtów poprzedza EIP. Wysłanie samych identycznych bajtów informuje, że można kontrolować EIP, ale nie wskazuje jego położenia.

Aby znaleźć dokładne przesunięcie, należy zamiast samych znaków „A” wysłać unikalny, niepowtarzający się wzorzec. Każde 4 bajty tworzą inną sekwencję, więc wartość, która trafi do EIP, wskazuje przesunięcie.

Metasploit zawiera narzędzie pattern_create.rb.

Po awarii wywołanej wzorcem należy odczytać wartość EIP. Po przekazaniu jej do pattern_offset.rb narzędzie zwróci dokładną liczbę bajtów poprzedzających EIP.

To przesunięcie określa rozmiar dopełnienia przed bajtami adresu powrotu.

Zawsze należy przeprowadzić weryfikację. Proszę zbudować dane wejściowe zawierające offset bajtów „A”, a następnie cztery bajty „B” (0x42). Jeśli EIP zmieni się na 42424242, przesunięcie jest dokładne.

Takie potwierdzenie pozwala uniknąć wielogodzinnego debugowania błędu wynikającego z przesunięcia różniącego się o kilka bajtów.

Po przejęciu kontroli nad EIP należy również sprawdzić, gdzie wskazuje ESP w chwili awarii. ESP zwykle wskazuje miejsce tuż za nadpisanym adresem powrotu, wewnątrz pozostałej części bufora.

To właśnie tam można później umieścić shellcode.

Przydatne narzędzia do fuzzingu i pracy ze wzorcami to między innymi:

• Spike i boofuzz: fuzzery protokołów sieciowych.
• pattern_create / pattern_offset: znajdowanie przesunięcia EIP.
• mona.py w Immunity: automatyzacja zadań związanych ze wzorcami, przesunięciem i niedozwolonymi znakami.

Przydatna awaria musi być powtarzalna. Należy zapisać dokładne dane wejściowe, które ją wywołują, i uruchomić program ponownie w czystym stanie, aby potwierdzić stabilność przesunięcia.

Niespójne awarie często oznaczają, że błąd nie jest typowym przepełnieniem stosu albo że pewien warunek (czas, długość lub zawartość) zmienia się między uruchomieniami.

Proszę przypomnieć sobie, dlaczego wzorzec cykliczny jest lepszy od ciągu identycznych bajtów.

Wiedzą już Państwo, jak znaleźć przesunięcie powodujące awarię:

• Przeprowadzić fuzzing z coraz większymi danymi wejściowymi, aby wywołać awarię; potwierdzić ją wartością 41414141 w EIP.
• Użyć wzorca cyklicznego wraz z pattern_create / pattern_offset, aby znaleźć dokładne przesunięcie.
• Zweryfikować wynik za pomocą dopełnienia i czterech bajtów „B” (42424242).
• Sprawdzić, gdzie wskazuje ESP, aby później umieścić shellcode.

W następnym kroku przejmą Państwo pełną kontrolę nad EIP i przekierują wykonanie.