6 typów fuzzerów – który jest dla Ciebie najlepszy?

Kiedyś (okolice 2014 roku) było całkiem prosto. Na “rynku” były fuzzery “mądre” i fuzzery, delikatnie mówiąc, nie grzeszące rozumem. Wybór był oczywisty – chciałeś przetestować swój projekt, wybierałeś AFL i nie czekałeś długo a kolejka błędów rosła i rosła… Teraz za to jest fajniej: rozwiązania specjalizowane pod konkretne zastosowania, tuningowane fuzzery i sprytne sposoby poszukiwania nowych ścieżek. A oto dwanaście punktów, które zwiększą Twoją skuteczność bughuntingu:

1. Dumb fuzzery mają się całkiem dobrze!

Zbyt szybko researcherzy postawili kreskę na klasycznych rozwiązaniach. Po pierwsze, generują ciekawe mutacje i szybko jesrzyteśmy w stanie wygenerować korpus testowy (i to całkiem skomplikowany!). Po drugie, nawet dzisiaj, znajdują błędy, pomijam już fakt “trywialności” wdrożenia.

2. …jednak specjalizacja = wysoka skuteczność (structured fuzzing)

Testując gramatyki (JS, Yara, C/C++) bezsensowne jest “karmienie” parsera, czymś wykraczającym poza zakres danego języka. Czasami jednak ma to szanse zadziałać i znaleźć jakiś błąd, lecz jest to zdecydowanie wyjątek niż reguła. Warto wtedy skorzystać z domato, który pozwala stworzyć własny generator gramatyki, lub zaprząc do roboty gotowca takiego jak csmith, fuzzilli  lub libprotobuf-mutator.

3. Nadajmy kolorytu fuzzingowi, czyli testowanie greybox

Nie tylko badanie pokrycia kodu i feedback z niego, czynią fuzzer “mądrym”. Można zaprogramować, go wcześniej, aby całkowicie pominąć etap nauki i na starcie korzystać ze skuteczniejszego generowania przypadków testowych. Generycznie robi to aflsmart, a bardzo fajny przykład wykorzystania tego mechanizmu pokazał CheckPoint w swoim researchu Windows Deployment Services (CVE-2018-8476).

4. Pokazanie palcem jest też sposobem na buga!

Guided fuzzing może pomóc kiedy wiemy czego chcemy i gdzie to jest. Łącząc Symbolic Execution i “moc” feedbacku z pokrycia kodu, jesteśmy w stanie i dobrym stylu doprowadzić do awarii kodu. Pomocą służą driller oraz aflgo, warto spróbować bo jest to obiecujące podejście.

5. Przerzucanie “roboty” na sprzęt jest (prawie) zawsze właściwym kierunkiem

Honggfuzz, WinAFL (tak!) i szereg innych projektów, korzystają ze sprzętowego wsparcia w zakresie pomiaru pokrycia kodu. Praktycznie wszystkie nowe procesory Intela wspierają te mechanizmy, korzystajmy przerzucając cykle CPU na fuzzing, a nie programowe metody badania code coverage.

6. Deweloperzy <3 UT, prawdopodobnie pokochają też fuzzery!

Słyszałem wiele wymówek od programistów, dlaczego nie korzystają z technik automatycznych testów bezpieczeństwa. Testy jednostkowe zdecydowanie szybciej zdobyły serca deweloperów (chociaż po sieci dalej krąży legendarny mem). DeepState pozwala na wykorzystanie mocy fuzzerów, w ten, nieco niecodzienny dla specjalistów bezpieczeństwa, sposób 😉

Daj znać w komentarzu, jaki jest najskuteczniejszy według Ciebie sposób “automatycznego” atakowania kodu – może pominąłem jakiś ciekawy?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.