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).