Zdravim,
po delsi dobe zajimavejsi dotaz, takze prispeji i svoji troskou do mlyna. Nejake zkusenosti s fuzzingem mam, prvni dumb fuzzer jsem napsal uz pred hodne lety a zrovna tento tyden upravuji svuj IE fuzzer.
Tvuj dotaz je hodne obecny, neptas se v podstate na nic urciteho, jen jestli ma nekdo zkusenosti s tvorbou fuzzeru. Proto odpovim ze siroka a snad mezi tou hromadou textu najdes i neco uzitecneho.
Jako prvni je dulezite se rozhodnout, proc chces vlastne psat fuzzer? Jde ti o to se procvicit v programovani, nebo chces hledat bugy? Jestli ti jde o hledani bugu, nezatracoval bych jiz napsane fuzzery, jelikoz spousta z nich ma opravdu neco do sebe a jiz prinesly vysledky (CVE). Myslim si, ze seznameni se se zdrojovymi kody jinych fuzzeru neni nikdy na skodu, jelikoz okoukas, jak to delaji jini a muzes dostat potrebnou inspiraci.
Ja osobne patrim k tem, co neradi znovu vynalezaji kolo a proto se domnivam, ze psat vlastni fuzzer ma cenu jen v pripade, ze mas nejaky inovativni napad jak/co fuzzovat. Jestlize nejaky takovy napad mas, urcite fuzzer napis, jelikoz to prinese vysledky.
Kdyz uz se rozhodnes psat fuzzer, je pred tebou podstatna volba: mutation-based (MB) fuzzer, nebo generation-based (GB)? Musim priznat, ze oba maji sve vyhody i nevyhody. Predne je velice smutne, ze v roce 2016 jsou jeste MB fuzzery schopny nalezt exploitovatelne bugy, ale je to tak.
Hlavni vyhodou MB fuzzeru je hlavne jejich jednoduchost. Vystacis si relativne s par radky kodu (ale pozor, i MB fuzzer muze byt komplexnejsi, protoze neni MB fuzzer jako MB fuzzer ..). Druha vyhoda je, ze nepotrebujes zadne hlubsi znalosti o fuzzovanem protokolu/aplikaci.
Nevyhody jsou predevsim:
- slaba "code coverage" (to urcuje, jakou cast cilove aplikace jsi fuzzerem overil)
- skoro nemoznost odhalit sofistikovanejsi zranitelnosti (prave proto, ze code coverage je vetsinou dost nizky)
- jelikoz je to tak jednoduche, dela to skoro kazdy a to snizuje sance na nalezeni dalsich zranitelnosti
- plytvani zdroju (napr. WinRAR - v pripade MB fuzzeru vetsina mutaci neprojde ani uvodni validaci formatu, takze v podstate nic nefuzzujes. Po dni behu fuzzeru zjistis, ze proslo pouze 1000 vzorku ze 100 000)
Oproti tomu vyhody a nevyhody GB fuzzeru:
- podstatne lepsi code coverage
- vetsi sance na nalezeni bugu
- efektni pouzivani zdroju (vetsina vzorku je "validnich")
Nevyhody:
- slozitejsi na implemetaci
- jestlize chces vic bugu, musis se o fuzzer starat (napr. u browseru sledujes nove verze, nove features, nove API, atd a svuj fuzzer upravis tak, aby se na tyto nove oblasti zameril [btw tady postreh z praxe, opravdu to funguje velice dobre a pocet odhalenych bugu roste])
Dale je nutne si uvedomit, ze fuzzing samotny (at uz MB nebo GB) je jen pulka projektu. Druha pulka je, jak sledovat exceptions v aplikaci. To muze byt ve vysledku slozitejsi, nez se zda - hlavne, kdyz se i toto rozhodnes implementovat sam.
Jako dalsi a nemene dulezita vec je volba jazyka v kterem fuzzer napises. Kdyz se zameris na browsery, bezesporu ziskas vic testu za minutu, kdyz bude tvuj fuzzer v JavaScriptu, nez kdyz to budes psat v pythonu.
Zaverem, podelil bych se s tebou o nejake zdroje a par finalnich rad.
Ja jsem si pro svuj Ie fuzzer vybral kombinaci python+javascript. V pythonu mam implementovanou hlavni logiku + exception handling a reporting. Python vygeneruje prvni vychozi html soubor, ktery v sobe nese JavaScript, ktery se pak sam dal mutuje. BTW jestli sahnes po pythonu na windows, tak se urcite koukni na winappdbg, je to alternativa k pydbg, ale aktualnejsi, schopna pracovat s 32b i 64b procesy a za pydbg nijak nezaostava.
Urcite se koukni na [link] . Je to dalsi papir o fuzzingu, ale ma nekolik vyhod. Je relativne up-to-date a psal to clovek, ktery s tim fuzzerem nasel critical UAF v IE. Cela ta prezentace popisuje vse od tvorby fuzzeru az po finalni exploit.
Jeslize se rozhodnes fuzzovat browsery, doporucuji nastudovat jedny z poslednich mitigations v prohlizecich - IsolatedHeap a MemoryProtector. Protoze ty celkem komplikuje hledani UAF.
Jestlize jsi to docetl az sem, bravo :)
Playa (odpovědět) |