Jak efektivně používat AFL a AFL++ k fuzzu binárních souborů

Pokud máte zájem Binárně orientovaná kybernetická bezpečnost a zneužíváníDříve nebo později narazíte na fuzzing, a zejména na AFL a AFL++. Nemluvíme o teoretickém laboratorním nástroji, ale o něčem, co se denně používá k nalezení skutečných chyb ve známých programech, stejně jako se to stalo se zranitelnostmi v... populární aplikace jako 7-Zip.

V následujících řádcích se podrobně a přátelským tónem podíváme na to, Jak používat AFL a AFL++ k fuzzu binárních souborůVysvětlíme si přesně, co je fuzz testování, proč je tak účinné z hlediska bezpečnosti a jak ho integrovat do moderního vývojového postupu. Také se podíváme na reálný případ zranitelnosti (podtečení celého čísla, které umožňuje vzdálené spuštění kódu) a probereme doplňkové nástroje, jako například GDB s rozšířeními, AFLTriage a operačními moduly.

Co jsou AFL/AFL++ a proč jsou považovány za chytré fuzzery?

AFL (Americký Fuzzy Lop) a jeho vývoj AFL++ Jedná se o open-source fuzzing nástroje určené k automatickému testování binárních souborů a hledání chyb, jako jsou přetečení, chyby paměti nebo neočekávané chování, které vede k pádům nebo dokonce zneužitelným zranitelnostem.

Krása AFL nespočívá jen v odesílání náhodných dat, ale spíše v inteligentní fuzzer nebo fuzzer s řízeným pokrytímVycházeje z jednoho nebo více platných vzorových záznamů (tzv. testovacích případů), AFL neustále generuje variace a díky instrumentaci programu detekuje, kdy nová mutace způsobí, že binární soubor zvolí jinou cestu spuštění.

Pro dosažení této instrumentace má AFL vlastní kompilátory, jako například afl-gcc a afl-g++Tyto funkce vkládají do kódu během kompilace malé „háčky“. Tyto háčky informují AFL o nalezení určitého vstupu. nové trasy v toku programuTo vám umožňuje zaměřit se na mutace, které skutečně poskytují dodatečné pokrytí, a neztrácet čas daty, která nic nemění.

Díky tomuto přístupu je AFL něčím jako „dirb binárních souborů“: známým nástrojem, snadno použitelným, jakmile pochopíte základní postup, a dostatečně výkonným na to, abyste objevili... závažné nedostatky ve výrobních programechi když existují pokročilejší nebo specializovanější fuzzery.

Úvod do fuzz testování a jeho role v kybernetické bezpečnosti

Fuzz testování, nebo jednoduše fuzzing, je technika automatizované testování bezpečnosti a robustnostiMyšlenkou je poslat aplikaci záplavu chybně formátovaných, náhodných nebo neobvyklých dat s cílem zjistit, zda se program nepodaří zhroutit, spadnout nebo se chovat neočekávaně.

Když je software vystaven fuzzingu, cílem je lokalizovat chyby, jako například přetečení vyrovnávací paměti, selhání validace vstupu, problémy se správou paměti nebo soubojové podmínkyMnoho z těchto chyb může vést k libovolnému spuštění kódu, únikům informací nebo odmítnutí služby.

V typickém pracovním postupu se fuzz testování řídí třemi jasnými fázemi: nejprve se vygeneruje testovací datová sada (ať už zcela náhodná, generovaná podle specifického formátu nebo mutací platných vstupů); poté... Spustit testovaný binární soubor během monitorování Jeho chování je monitorováno; a nakonec jsou zaznamenávány a analyzovány pády nebo neobvyklé chování, aby vývojáři mohli prozkoumat zdroj problému.

Existují různé strategie fuzzingu. Některé nástroje se zaměřují na generační chmýřívytváření položek, které respektují dobře definovaný formát (například strukturu souborů nebo síťový protokol); jiné jsou založeny na mutace platných vstupůPrávě v tomto přístupu vynikají AFL a AFL++. Existují také náhodnější přístupy a další, které se spoléhají na specifické znalosti testovaného systému, aby se zaměřily na jeho nejslabší místa.

V moderní kybernetické bezpečnosti je fuzz testování základním spojencem: pomáhá najít zranitelnosti v proaktivně, ještě předtím, než software půjde do produkčního prostředía přispívá k dodržování předpisů a norem, jako je ISO 27001, nebo požadavků na ochranu osobních údajů. Dále snižuje riziko poškození reputace, které by mohlo vzniknout v důsledku toho, že by se útočníci dostali do kritické zneužitelné zranitelnosti.

Případová studie: Zranitelnost typu Integer Underflow a RCE v dekompresoru

Abychom pochopili skutečnou hodnotu AFL a fuzzingu, je velmi užitečné podívat se na konkrétní zranitelnost na základě Celočíselné podtečení ve velmi populárním dekompresoru souborůJedná se o chybu vzdáleného spuštění kódu (RCE), která se spustí při zpracování komprimovaných souborů algoritmem Zstandard s vysokým, i když ne maximálním, skóre CVSS, a to právě proto, že vyžaduje poněkud specifičtější kontext (například, že se zpracovávají konkrétní soubory).

K celočíselnému podtečení dochází, když celočíselná proměnná s dobře definovanými dolními hranicemi Používá se v odčítacích operacích, dokud není dosaženo jeho minimální hodnoty.Protože mnoho celočíselných typů neumožňuje záporné hodnoty, při „klesnutí pod nulu“ dochází místo získání čísla pod nulou k skoku na maximální možnou hodnotu rozsahu, a to kvůli tomu, jak jsou tato čísla interně reprezentována.

Představte si celočíselnou proměnnou, která by teoreticky nikdy neměla být záporná. Pokud budete odčítat konstantu, dokud nedosáhnete 0, a budete v odčítání pokračovat, Nedostanete -1, -2 atd.Místo toho se hodnota invertuje a stane se gigantickým číslem na horní hranici povoleného rozsahu. Toto absurdní číslo, pokud je použito jako index nebo velikost v paměťových operacích, může způsobit čtení nebo zápis mimo zamýšlené limity.

Problém se stává kritickým, když se celočíselná proměnná, která může mít nedostatečný objem, použije pro pro správu vyrovnávací paměti nebo pro výpočet posunůTypickým pseudo-příkladem by bylo použití uživatelem ovládané proměnné nepřímo jako offsetu ve funkci typu memcpy, ve smyčce, která v každé iteraci snižuje konstantu, dokud údajně nedosáhne nuly nebo nekladného čísla.

V takovém scénáři, pokud počáteční hodnota nikdy nedokáže „čistě“ splnit výstupní podmínku, podtečení nakonec způsobí, že číslo bude enormní, smyčka bude pokračovat v běhu a masivní poškození pamětiTo se promítá do pádů systému a při dostatečném využití i do možnosti spuštění libovolného kódu.

Jak AFL pomáhá lokalizovat tyto typy zranitelností

Jakmile pochopíme koncept celočíselného podtečení (Integer Underflow), bude jasné, proč jsou AFL a AFL++ tak užitečné: počínaje jeden nebo několik dokonale platných vstupních souborůFuzzer dokáže generovat desítky tisíc variací, dokud nenarazí na tu, která spouští konkrétní chybu v postižené dekompresní cestě.

Během fuzzingu AFL monitoruje instrumentovaný binární soubor, aby určil, kdy vstup způsobí provedení jiné cesty řízení toku. Pokaždé, když detekuje novou cestu, Označit tento příspěvek jako zajímavý a zachovává jej jako základ pro budoucí mutace. Tímto způsobem se prozkoumávají nejen obvyklé cesty provádění, ale také ty kombinace dat, které aktivují neobvyklé cesty kódu, jako je například proces dekomprese s podivnými parametry.

V případě podtečení celého čísla dokáže AFL najít vzorek, který způsobí, že daná proměnná ve smyčce nikdy nedosáhne očekávané výstupní hodnoty. Výsledkem je detekovatelný pád, který bude uložen v odpovídající složce s výsledky AFL a připraven k další analýze.

Po několika minutách nebo hodinách provádění je běžné, že AFL indikuje první relevantní havárieNe všechny chyby, které najdete, budou zneužitelné, ale jsou jasným ukazatelem toho, že něco ve správě paměti, validaci vstupu nebo vnitřní logice binárního souboru nefunguje tak, jak by mělo.

Tehdy přicházejí na řadu podpůrné nástroje jako AFLTriage nebo debugger jako GDB, které vám umožní hlouběji se ponořit do havárie, sledovat stav registrů a paměti a posoudit, zda lze selhání spolehlivě zneužít, nebo zda se jedná pouze o zádrhel, který je z pohledu útočníka bezvýznamný.

Základní instalace AFL / AFL++ a analytického prostředí

Nastavení minimálního prostředí pro fuzzing s AFL na standardním linuxovém systému je poměrně jednoduché. V mnoha distribucích stačí nainstalovat balíček odpovídající instrumentovaným kompilátorům, například pomocí příkazu jako nainstalujte afl-g++ nebo ekvivalentní balíček AFL++ přiveďte celou sadu.

Tímto způsobem se nainstalují oba nástroje pro fuzzing (jako například afl-fuzz), jako jsou specializované kompilátory (afl-gcc, afl-g++ a jejich moderní varianty v AFL++). Tyto kompilátory použijete, když chcete cíl znovu zkompilovat s instrumentací, což je nezbytné pro maximální využití fuzzingu řízeného pokrytím.

Kromě samotného fuzzeru je prakticky nezbytné dobré ladicí prostředí. Rozšířená GDB s pluginy jako PEDA nebo GEF Díky dalším příkazům, pohodlnému formátování paměti, vizualizacím zásobníku a zkratkám pro kontrolu registrů a map paměti to výrazně usnadňuje život.

Pokud ještě nemáte GDB, můžete si jej nainstalovat pomocí správce balíčků vaší distribuce. Poté jednoduše integrujte vybraný plugin (například stažením GEF nebo PEDA z jejich repozitářů a jejich přidáním do konfiguračního souboru GDB nebo použitím příkazu `source` v samotném debuggeru).

Díky této „GDB na steroidech“ budete moci analyzovat instrumentované binární soubory, které se hroutí při fuzzingu, stáhnout si vstupy, které způsobují havárii a krok za krokem sledujte, co se děje při provádění přesně v okamžiku selhání.

Zkompilujte cílový binární soubor s AFL pro fuzzing

Jakmile máte připravený AFL nebo AFL++, dalším krokem pro seriózní fuzzing je zkompilujte cíl pomocí kompilátorů AFLa učinit tak s vhodnými možnostmi pro usnadnění analýzy i potenciálního zneužití, v případě, že cílem dané činnosti je útočný výzkum.

Ve velkých projektech, jako je dekompresor nebo sada archivních nástrojů, je vhodné povolit ladicí symboly (volba DEBUG nebo příznaky jako -ga minimalizovat optimalizace (například použitím -O0 místo -O2). To výrazně pomáhá pochopit, co se děje ve zdrojovém kódu v souvislosti s pozorovaným pádem.

Obvykle budete muset najít příslušný makefile nebo build soubor a upravte řádky, kde jsou definovány příznaky kompilaceTo může zahrnovat aktivaci proměnné DEBUG, vynucení určité úrovně optimalizace a, co je nejdůležitější, nahrazení CC a CXX nástroji afl-gcc a afl-g++ (nebo ekvivalentními nástroji AFL++).

Například byste mohli spustit sestavení s parametry jako CC=afl-gcc a CXX=afl-g++ spolu s příslušným makefile. Výsledkem bude instrumentovaný binární soubor, který obsahuje potřebné hooky, aby AFL mohl měřit pokrytí během provádění.

Po dokončení kompilace je vhodné zkontrolovat, zda výsledný binární soubor skutečně obsahuje ladicí symboly a správnou architekturu, a to pomocí příkazu jako soubor o spustitelném souboruDíky tomu se nepoužívají metody fuzzing naslepo a lze snadno ladit jakékoli objevené pády.

Příprava testovacích případů a provedení AFL

Před spuštěním AFL proti vašemu binárnímu souboru si musíte připravit sadu minimální počet platných záznamůPokud testujete dekompresor, který selže se soubory komprimovanými pomocí specifického algoritmu, budete muset vytvořit alespoň jeden správně formátovaný soubor, který používá danou metodu komprese.

Obvyklou praxí je vytvořit adresář, například nazvaný testcases, a uložit do něj jeden nebo více pracovních vzorků. Ty budou sloužit jako výchozí bod pro AFL. generuje stále agresivnější mutacesnaží se objevit nové cesty spuštění a nakonec dochází k pádu.

Typický příkaz pro spuštění AFL vypadá přibližně takto: zadejte název relace nebo synchronizace, vstupní složku s testovacími případy, výstupní cestu, kam budou výsledky uloženy, a některé další parametry, jako je časový limit, abyste se vyhnuli nekonečným smyčkám.

Příkazový řádek také určuje, jak se cílový program spustí pomocí výsledková tabule @@který AFL automaticky nahradí cestou každého testovacího případu, který vygeneruje. Můžete tedy zadat něco jako ./binární argumenty @@ a AFL bude zodpovědný za tisíce spuštění spustitelného souboru s různými soubory.

Je důležité vědět, že AFL si může zpočátku stěžovat na konfiguraci systému (kvůli omezením zdrojů, výpisům jádra atd.). V takovém případě obvykle existuje pomocný skript nebo nástroj, který upravuje parametry jádra a relace pro optimalizaci fuzzingového prostředí. Ten by měl být spuštěn s příslušnými oprávněními před opakováním testu.

Analýza havárie pomocí AFLTriage a GDB

Po určité době optimalizace AFL postupně zaplní výstupní složku zajímavými novými záznamy a především soubory, které způsobily pádyTy jsou obvykle uloženy v určitém podadresáři (například havárie ve složce relace).

Abyste se vyhnuli zběsilému prohlížení každého vstupu jeden po druhém, existují nástroje jako AFLTriage, které vám umožňují Automaticky spustit binární soubor pro každý soubor s pádem a generovat strukturované zprávy s podrobnostmi o tom, kde a jak k selhání došlo.

Při spuštění AFLTriage zadáte vstupní adresář (složku s chybami), výstupní adresář pro ukládání zpráv a příkaz pro spuštění binárního souboru pomocí @@. Nástroj analyzuje každý případ a Vygeneruje textové soubory s informacemi, které vás zajímají. pro analytika.

Typický obsah těchto hlášení zahrnuje typ signálu, který způsobil pád, směr, ve kterém došlo k selhání, základní trasování zásobníku a v mnoha případech funkci nebo makro, kde došlo k přerušení kódu (například specifická operace kopírování, kompresní smyčka nebo makro COPY_CHUNKS, které v každé iteraci odečítá velikosti).

Jakmile je nalezen zajímavý pád, dalším krokem je jeho reprodukce v GDB. Za tímto účelem se spustí ladicí program s binárním souborem a vstupním souborem viníka jako argumenty a program se spustí z GDB. Po reprodukci pádu se stav Klíčové záznamy jako RAX, RDX atd., zkontrolujte přesnou instrukci, která se právě provádí, a podívejte se do map paměti (vmmap), abyste zjistili, která oblast se čte nebo do které se zapisuje.

Od havárie k potenciálnímu zneužití: analytické moduly v GDB

Selhání binárního souboru neznamená vždy, že je zranitelnost zneužitelná. A právě zde přicházejí na řadu rozšíření GDB, jako je modul . zneužitelný, navržený k analýze kontextu havárie a nabídnutí hrubé klasifikace toho, zda by selhání mohlo být zneužito či nikoli.

Tyto typy rozšíření studují aspekty, jako je platnost ukazatele instrukce, stav ukazatele zásobníku, oprávnění paměti adresy, kde se provádí pokus o čtení nebo zápis, a povaha signálu, který způsobil selhání. Se všemi těmito informacemi poskytují orientační verdikt o potenciálu využití (například kategorizací chyby jako pravděpodobně zneužitelné, potenciálně zneužitelné nebo málo zajímavé).

V případě celočíselného podtečení, které nakonec zapisuje do paměti jen pro čtení, může plugin naznačit, že se jedná o potenciálně zneužitelný případ, protože operace zápisu je prováděna mimo očekávané limity v oblasti, kde by se nemělo nic dotýkat.

Ne všechny scénáře budou tak přímočaré, ale tato kombinace AFL pro odhalení havárie, AFLTriage pro seskupení a popis případů a GDB s rozšířeními pro posouzení zneužitelné schopnosti tvoří Velmi robustní binární auditní kanálZbývající práce se dále zaměřuje pouze na výzkum a vývoj exploitu, jehož složitost se může enormně lišit v závislosti na binární a aktivní ochraně.

Další klíčovou součástí analýzy, zejména pokud je publikována CVE a související záplata, je kontrola toho, jak byla zranitelnost opravena ve zdrojovém kódu. To obvykle zahrnuje změny v typu používaných dat (například přechod ze znaménkového bajtu na nepodepsaný bajt, rozšíření rozsahu) a zahrnutí dalších kontrol (operátorů if, které vracejí chybové kódy, pokud jsou překročeny určité limity), aby se zabránilo podtečení nebo poškození paměti.

Další relevantní fuzzery a nástroje v ekosystému

Ačkoli AFL a AFL++ patří mezi nejznámější možnosti pro fuzzing nativních binárních souborů, ekosystém fuzz testování je mnohem širší a pokud s ním pravidelně pracujete, stojí za to ho sledovat. zabezpečení softwaru.

Mezi nejpoužívanější možnosti patří LibFuzzer, knihovna původně vyvinutá společností Google, která se přímo integruje s kódem C/C++ a provádí fuzzing na úrovni specifických funkcí, ideální pro testování jednotlivých komponent s vysoce kontrolovanými vstupy.

K dispozici je také Peach Fuzzer, obecnější a konfigurovatelnější platforma, která umožňuje definovat přesné modely protokolů, formátů souborů a složitých strukturJe velmi oblíbený v odvětvích, kde je spolehlivost kritická, jako jsou průmyslové systémy nebo prostředí IoT.

Ve webové doméně zahrnují nástroje jako OWASP ZAP fuzzing moduly zaměřené na webové aplikace, které jsou schopné odesílat manipulované požadavky, chybně načtené zátěže a injekční testy Koncové body HTTP pro detekci zranitelností, jako jsou SQL injekce, problémy s ověřováním vstupu nebo chyby při zpracování formulářů.

Toto vše doplňuje binární fuzzing AFL/AFL++, protože umožňuje pokrytí od nízkoúrovňového nativního kódu až po vrstvy aplikace, které jsou nejvíce vystaveny koncovému uživateli. Společný cíl je ve všech případech stejný: automatizovat vyhledávání zranitelností dříve, než to udělají útočníci.

Jak integrovat fuzz testování do vývojového cyklu

Aby fuzzing konzistentně přinášel skutečnou hodnotu, nestačí jen občas spustit AFL nebo AFL++ a zapomenout na to. Je to mnohem efektivnější. integrace fuzz testování do životního cyklu vývoje softwaru, podobným způsobem, jako se to dělá u jednotkových nebo integračních testů.

Prvním krokem je definovat které části systému jsou nejdůležitějšíAnalyzátory souborů, síťové moduly, komponenty zpracovávající uživatelská data nebo externě exponované služby. Pro tyto cíle lze s využitím pečlivě vybraných testovacích případů navrhnout specifické fuzzing kampaně.

Dále je třeba pro každý případ zvolit správný nástroj. Pro složité nativní binární soubory jsou obvykle přirozenými kandidáty AFL++ nebo LibFuzzer, zatímco pro webová API nebo HTTP aplikace bude dávat větší smysl webově orientovaný nástroj. Důležité je, aby se fuzzing prováděl správně. opakovatelné a automatizované.

Integrace se systémy CI/CD je velmi užitečná: pipeline lze nakonfigurovat tak, aby se v určitých větvích nebo před určitými nasazeními spouštěla ​​fuzzing baterie s omezenou dobou, čímž se ukládají případné nově nalezené pády a sestavení selhává, pokud se objeví potenciálně závažné zranitelnosti.

Nakonec je důležité si uvědomit, že fuzzing je iterativní proces. Pokaždé, když je chyba opravena, měla by být postižená komponenta znovu fuzzována, aby se ověřilo, že oprava funguje a že nebyly zavedeny žádné nové chyby. žádné nové regrese ani zranitelnostiTímto způsobem se fuzz testování stává další vrstvou nepřetržité ochrany a nikoli izolovaným auditem.

Všechny výše uvedené skutečnosti dohromady ukazují, jak nám AFL, AFL++ a fuzz testování obecně umožňují přejít od bezpečnostního přístupu založeného výhradně na manuálních kontrolách ke komplexnějšímu přístupu. mnohem automatizovanější a důkladnějšíJe schopen odhalit chyby, které by jinak zůstaly skryté. Práce s reálnými případy, jako jsou zranitelnosti způsobující podtečení v široce používaných dekompresorech, také pomáhá pochopit, že se nejedná jen o teorii, ale o problémy, které jsou již zneužívány. Proto může být udržování softwaru aktualizovaného a pravidelně podrobovaného fuzzingu rozdíl mezi kompromitovaným a odolným systémem.