fuzz

Tarihçe
Fuzz testi, 1989 yılında Profesör Barton Miller ve öğrencileri tarafından Wisconsin Madison
Üniversitesi'nde geliştirildi. Onların (devam) çalışmaları http://www.cs.wisc.edu/~bart/fuzz/
adresinde bulunabilir ; temelde komut satırı ve UI bulanıklaştırmasına yöneliktir ve modern
işletim sistemlerinin basit bulanıklaştırmalara karşı savunmasız olduğunu gösterir.
Fuzzer uygulamaları
Bulanıklaştırıcı, otomatik olarak yarı rasgele veriyi bir program / yığına enjekte eden ve hataları
tespit eden bir programdır.
Veri oluşturma bölümü üreticilerden oluşur ve güvenlik açığı tanımlaması hata ayıklama
araçlarına dayanır. Jeneratörler genellikle statik tüylenme vektörlerinin (tehlikeli olduğu bilinen
değerler) veya tamamen rasgele veri kombinasyonlarını kullanır. Yeni nesil fuzzers, enjekte
edilen verileri ve gözlemlenen etkiyi bağlamak için genetik algoritmalar kullanır. Bu tür araçlar
henüz halka açık değil.
Kriptanaliz ile karşılaştırma
Mümkün olan güvenilir çözümlerin sayısı , keşfedilebilir çözümler alanıdır . Kriptanalizin amacı,
bu alanı azaltmaktır; bu, bir şeylerin şifresini çözmek için saf bruteforce denemek için daha az
anahtara sahip olmanın bir yolunu bulmak anlamına gelir.
Serserilerin çoğu:

protokol / dosya formatına bağlı

veri türüne bağlı
Niye ya?

İlk olarak, fuzzer hedefe bağlı giriş kanalına bağlanmak zorunda olduğundan.

İkincisi, çünkü bir program sadece yeterince yapılandırılmış veriyi anlar. Bir web sunucusuna
ham bir şekilde bağlanırsanız, yalnızca GET (veya en sonunda kilitlenme) gibi listelenen
komutlara yanıt verir. Dize "GET" ile başlamak ve geri kalanı şaşırtmak daha az zaman alır,
ancak dezavantajı, ilk fiildeki tüm testleri atlamanızdır.
Bu bağlamda, Fuzzers, işe yaramaz testlerin sayısını azaltmaya çalışır, yani çalışacakları için çok
az şansları olduğunu zaten bildiğimiz değerler: öngörülemezliği, hız lehine azaltırsınız.
Saldırı türleri
Bir fuzzer şunlara yapılan saldırı kombinasyonlarını dener:

sayılar (işaretli / işaretsiz tamsayılar / kayan nokta ...)

karakter (url, komut satırı girişleri)

meta veri: kullanıcı girişi metni (id3 etiketi)

saf ikili diziler
Fuzzing'e ortak bir yaklaşım, her tür için "tehlikeli olduğu bilinen değerler" ( fuzz
vektörleri ) listelerini tanımlamak ve bunları enjekte etmek veya rekombinasyon yapmaktır.

tamsayılar için: sıfır, muhtemelen negatif veya çok büyük sayılar

karakter için: kaçan, yorumlanabilen karakterler / talimatlar (örneğin: SQL İstekleri için,
alıntılar / komutlar ...)

ikili için: rastgele olanlar
Lütfen gerçek hayattaki akıcı vektörler örnekleri ve metodolojisi için OWASP'ın Fuzz Vector
kaynağına bakın.
Protokoller ve dosya formatları, bazen bulanık, çok karmaşık veya çok kötü uygulanan normları
belirtir: geliştiricilerin bazen uygulama sürecinde (zaman / maliyet kısıtlamaları nedeniyle)
karışıklığa uğramasının nedeni budur. Bu yüzden zıt yaklaşımı benimsemek ilginç olabilir: bir
norm alın, tüm zorunlu özelliklere ve kısıtlamalara bakın ve hepsini deneyin; yasak / rezerve
değerler, bağlantılı parametreler, alan ölçüleri. Bu uygunluk testi odaklı tüysüzlük olur.
Uygulama fuzzing
Bulanık sistem ne olursa olsun, saldırı vektörleri G / Ç içindedir. Masaüstü uygulaması için:

Kullanıcı Arabirimi (tüm düğme dizilerini / metin girişlerini test etme)

komut satırı seçenekleri

içe / dışa aktarma yetenekleri (bkz. aşağıda dosya formatı
Bir web uygulaması için: URL'ler, formlar, kullanıcı tarafından oluşturulan içerik, RPC istekleri, ...
Protokol fuzzing
Bir protokol fuzzer, sahte paketleri test edilen uygulamaya gönderir veya sonunda bir vekil olarak
hareket eder, anında istekleri değiştirir ve tekrar eder.
Fuzzing dosya formatı
Bir dosya formatı karıştırıcısı birden fazla hatalı biçimlendirilmiş örnek üretir ve bunları sırayla
açar. Program çöktüğünde, hata ayıklama bilgileri daha fazla araştırma için saklanır.
Biri saldırabilir:

ayrıştırıcı katman (container katman): dosya formatı kısıtlamaları, yapı, kurallar, alan
boyutları, bayraklar, ...

Codec / uygulama katmanı: alt seviyedeki saldırılar, programın daha derinlerini hedefliyor
Dosya formatıyla ilgili güvenlik açıklarına bir örnek: MS04-028 (KB833987) Microsoft'un JPEG
GDI + güvenlik açığı, içeriği olmayan, sıfır boyutlu bir yorum alanıydı.
Şaşırtıcı bir şekilde, dosya formatı belirsizleri bu kadar yaygın değil, ancak bugünlerde ortaya
çıkma eğilimindedir; bazı örnekler:

Genel bir dosya formatı fuzzer: Ilja van Sprundel'in mangle.c ; "kullanımı çok basit, bir dosya
adı alıyor ve girdi olarak başlıyor. Daha sonra rastgele baytlarla başlığın% 0 ila% 10'u
arasında değişecek." (yazardan)

Zzuf, fuzzed bir dosya üreticisi olarak hareket edebilir , http://sam.zoy.org/zzuf/

Biri, Hachoir gibi araçları dosya formatı fuzzer geliştirmesi için genel bir çözümleyici
olarak kullanabilir .
Fuzzers'ın avantajları
Fuzz testinin en büyük avantajı, test tasarımının son derece basit ve sistem davranışına ilişkin
önyargılardan arınmış olmasıdır (Wikipedia'dan http://en.wikipedia.org/wiki/Fuzz_testing
adresinden ).
Sistematik / rastgele yaklaşım, bu yöntemin insan gözüyle sıklıkla gözden kaçan böcekleri
bulmasını sağlar. Ayrıca, test edilen sistem tamamen kapatıldığında (örneğin bir SIP telefonu),
tüyleme işlemi kalitesini incelemenin tek yoludur.
Fuzzers sınırlamaları
Fuzzers genellikle basit hata bulma eğilimindedir; Ayrıca, bir fuzzer protokolü ne kadar fazla
olursa, o kadar az garip hata bulur. Bu yüzden ayrıntılı / rastgele yaklaşım, durgun topluluk içinde
hala popülerdir.
Başka bir sorun, bazı kara kutu testleri yaptığınızda, genellikle kapalı bir sisteme saldırmanızdır;
bu da bulunan güvenlik açığının tehlikesini / etkisini değerlendirmede zorluk çeker (hata ayıklama
olanakları yoktur).