Prvně: Hledání chyb typu BOF, HOF nebo Format String je založené na jiných přístupech než hledání chyb typu sandbox escape. První je možné hledat mechanicky a automatizovaně. Druhé většinou předpokládá znalost implementace daného sandboxu a jeho fungování.
Co se hledání těch prvních chyb týká: Těch přístupů je celá řada. Když bych to měl vzít zjednodušeně, jmenoval bych asi tyhle tři:
1. Nalezení chyby na základě reportovaného pádu aplikace. V tomhle případě se nejedná o cílené hledání chyby ze strany výzkumníka, ale o získání logu z aplkkace po jejím pádu.
2. Nalezení chyby manuální analýzou kódu. Tento přístup můžeme rozdělit ještě na přístup tzv. blackboxu - hledání chyb bez znalosti zdrojového kódu (ve většině případů je nutná znalost assembleru, v omezeném případě je možné kód zpětně dekompilovat do (téměř) původní podoby) - a whiteboxu - hledání chyb na základě znalosti zdrojového kódu (nutnost znalosti syntaxe programovacího jazyka, ve které je aplikace napsána).
3. Nalezení chyb pomocí fuzzingu (fuzzing se dělí na několik skupin v závislosti na způsobu generování testovaných dat). Tento přístup je založený na znalosti testované aplikace (například formát vstupních dat, formát souboru, struktura komunikačního protokolu). Na základě těchto znalostí se vytvoří šablona, do které se podle zadaných kritérií pomocí aplikace zvané fuzzer generují testovací paterny. Fuzzer následně kontroluje, jestli testovaná aplikace na použitý vstup padne nebo ne. V případě, že nepadne, pokračuje generováním dalšího vstupu. V případě, že padne, zaznamená potřebné informace nutné k replikaci chyby (v některých případech se může jednat o chyby, které se replikovat nepodaří, protože k pádu aplikace došlo souhrou náhod).
Ať tak či tak, nalezení chyby je teprve první krok. Následuje snaha o replikaci, implementaci exploitu (dnešní operační systémy poskytují celou řadu bezpečnostních 'překážek' - Windows například ASLR, SafeSEH, SEHOP, DEP a další). Následuje ověření různých verzí aplikace, aby bylo zřejmé, jak dlouho se chyba v aplikaci nachází a jak velké je potenciální riziko zneužití. Dále se otestují možnosti replikace chyby na různé verze operačního systému (některé části exploitu budou pro různé verze operačního systému různé). Na základě těchto zjištění je teprve (někdy) možné vytvořit (téměř) spolehlivý univerzální exploit.
Každopádně hledání chyb v softwaru je z pohledu IT security pomyslný vrcholný stupeň, protože předpokládá hluboké znalosti z několika oborů (reverzní inženýrství, operační systémy, programování, počítačové sítě a další) a tím pádem není pro každého. S nástupem programů jako je například HackerOne nebo společností jako je například Zerodium nebo akcemi typu Pwn2Own se počet snadno nalezitelných chyb v softwaru výrazně snížil. Navíc dnes už nejsou exploity v kritickém softwaru o jedné jediné chybě, ale jedná se o zřetězení nejméně dvou, většinou však spíše ještě více chyb. To je také důvod, proč se dnes za chyby v kritickém softwaru platí takové ceny.
----------
Sec-Cave.cz - [link]
(odpovědět) |
