OSED i EXP-301: jak przygotować się do exploit development

OSED i EXP-301 koncentrują się na Windows user-mode exploit development. Kurs obejmuje buffer overflow, tworzenie własnych exploitów, DEP i ASLR, shellcode, format string bugs oraz reverse engineering w WinDbg i IDA Pro. Aktualny egzamin zawiera trzy niezależne zadania i trwa 47 godzin oraz 45 minut.

To nie jest kolejny network pentest. Kandydat musi rozumieć stan procesu i udowodnić kontrolę nad wykonaniem.

Fundamenty przed kursem

Potrzebna jest swoboda w x86: rejestry, stack, calling conventions, instrukcje skoku i reprezentacja little-endian. W Pythonie trzeba szybko parsować binaria, generować payloady i komunikować się z procesem lub siecią.

WinDbg używaj codziennie. Ustawiaj breakpointy, analizuj wyjątki, moduły, pamięć i łańcuch wywołań. Exploit development to iteracyjne testowanie hipotezy, nie jednorazowe uruchomienie skryptu.

Workflow pojedynczego exploita

Odtwórz crash na kontrolowanym wejściu.
Znajdź offset i zakres kontroli.
Zidentyfikuj bad characters i ograniczenia protokołu.
Sprawdź moduły oraz mitigations.
Zbuduj stabilną zmianę przepływu.
Dodaj ROP lub inny bypass, jeśli wymagany.
Wygeneruj shellcode zgodny z kontekstem.
Przetestuj wiele uruchomień i opisz założenia.

Stabilność jest częścią jakości. Payload działający raz na dziesięć prób wymaga analizy czasu, pamięci lub zależności środowiskowej.

DEP, ASLR i ROP

DEP wymusza rozdzielenie danych od kodu, a ASLR utrudnia przewidzenie adresów. Nie zapamiętuj jednego łańcucha ROP. Naucz się wyszukiwać gadżety, kontrolować rejestry, wyrównywać stos i wywoływać potrzebne API.

Dokumentuj każdy element łańcucha: adres, instrukcje, efekt i zależność od modułu. To przyspiesza debugowanie po zmianie binarki.

Przygotowanie do egzaminu

Ćwicz trzy rodzaje zadania równolegle, ale prowadź osobne runbooki. Zautomatyzuj tworzenie patternu, sprawdzanie offsetu, pakowanie adresów i eksport logów. Nie automatyzuj rozumowania o stanie procesu.

Raport twórz na bieżąco: screenshot crasha, rejestry, memory map, budowa payloadu i dowód końcowy. Po 48 godzinach nie da się wiarygodnie odtworzyć każdego kroku z pamięci.

OSED jest dobrym wyborem dla vulnerability research i reverse engineeringu. Jego miejsce względem OSEP i OSWE wyjaśnia roadmap OSCE3.

Analiza crasha krok po kroku

Zacznij od minimalnego wejścia, które niezawodnie wywołuje błąd. Potwierdź typ wyjątku, stan rejestrów i to, czy dane wejściowe kontrolują wskaźnik instrukcji lub inny element istotny dla przepływu wykonania. Następnie ustal dokładny offset za pomocą unikalnego wzorca i zweryfikuj go po ponownym uruchomieniu procesu. Jeden przypadkowy crash nie jest jeszcze stabilną prymitywą exploita.

Bad characters badaj dla konkretnego kanału wejścia. Bajt może zostać zmieniony przez parser, funkcję kopiującą albo kodowanie protokołu, dlatego wynik z jednego zadania nie powinien być bezrefleksyjnie przenoszony do następnego. Dopiero po poznaniu ograniczeń bufora wybieraj układ payloadu, rejestr pośredni i technikę przekazania sterowania.

DEP, ASLR i jakość łańcucha ROP

ROP nie polega na zebraniu jak największej liczby gadżetów. Łańcuch ma przygotować wymagane argumenty, zachować poprawny stos i zakończyć się przewidywalnym przekazaniem wykonania. Każdy gadżet opisz przez efekt na rejestrach, zmianę wskaźnika stosu i skutki uboczne. Po zbudowaniu fragmentu wykonaj go w debuggerze instrukcja po instrukcji, zanim dołączysz następny.

Przy ASLR sprawdź, skąd pochodzi każdy adres i czy jego moduł rzeczywiście ma oczekiwane właściwości w badanym środowisku. Przy DEP udokumentuj, w jaki sposób zmieniane są uprawnienia pamięci lub wykorzystywany jest istniejący kod. Taka analiza ogranicza „magiczne” stałe i ułatwia znalezienie miejsca, w którym exploit traci stabilność.

Warsztat i kontrola regresji

Utrzymuj osobny skrypt wysyłający dane, generator payloadu i notatnik debuggera. Po każdej zmianie uruchom mały zestaw regresji: czy aplikacja nadal dochodzi do tego samego crasha, czy offset się zgadza, czy długość bufora nie zmieniła protokołu i czy payload nie zawiera zakazanych bajtów. Automatyzacja ma usuwać pomyłki rachunkowe, ale nie może zasłaniać przepływu danych.

Raz w tygodniu odtwórz zadanie od czystej maszyny i napisz krótkie wyjaśnienie przyczyny błędu, prymitywy oraz zastosowanego obejścia ochrony. Jeśli nie potrafisz opisać exploita bez patrzenia w gotowy skrypt, przygotowanie jest jeszcze zbyt kruche.

Źródła: OffSec EXP-301 FAQ, OSED Exam Guide.