Hedef yazılım üzerinde, girişlere tanımı yapılan belirli karakterler ile birlikte yazılımsal sorunların tespitine biz fuzzing diyoruz lakin son zamanlarda fuzzing project adı altında piyasada bulunan güvenlik araçlarının daha çok mantıksal açıklarla tanışmasıyla birlikte eski method 'stack overflow' benzeri açıkların yerini 'out-of-bounds access, use after free, type confusion, race condition' gibi yüksek derecede öneme sahip açıklar almıştır. 'Smart' ve 'Dumb' dediğimiz iki method türemiştir. Bu yüzden yukarıda belirttiğimiz sınıflara göz atmakta fayda var.
Bu açıklar white,black ve gray box testing olmak üzere 3 sınıf içinde inceleniyor.
White Box; Kaynak kodları elinde olmakla birlikte 'blind' method olmaksızın yapılan tespitlere verilen ad.
Black Box; Kullanıcı kontrollü kaynak kod olmaksızın ve sadece input üstünde 'blind' method dediğimiz sistemle yapılan tespitlere verilen ad. Buna örnek olarak 'sql injection' denemelerini gösterebiliriz kaynak kod olmaksızın belirlenen karakterle sadece dış odaklı aramalar bu sınıfın tam tanımıdır.
Gray Box; Yukarıda tanımı yapılan her iki test aşamalarının uygulanmasına ise gray box fuzz türü diyebiliriz.
Fuzzing Project adı altında piyasaya sunulan 'Binary' bazlı uygulamalar ile birlikte bir devrim olmuş ve zaman aralığı olarak 2 yılda keşfedilen zafiyet sayısına 1 ay gibi kısa bir sürede ulaşılmıştır. Bu yüzden fuzzing project iyi tanımak, iyi anlamak ve uygulamalar üstünde süreklilik göstermek gerekir.
Linux tabanlı sistemlerde zafiyetlerin nasıl tetikleneceği ve bu zafiyetlerin alt yapısını inceleyeceğiz. Bildiğiniz üzere işletim sistemlerinde eğer bir zafiyet arayacaksanız ve dahi o zafiyeti bulduysanız tetiklemek ve o açıktan faydalanmak için o sistemlerin yapısını iyi bilmeniz gerekmektedir. Son zamanlarda çıkan yardımcı araçlarla beraber sistemlerde zafiyet tespiti, zafiyetin detaylı olarak konsept hali ve zafiyetlerin türleri kolay şekilde belirlenebilmektedir. Bunlara örnek vermek gerekirse eğer; hepimizin bildiği AFL Fuzzing, Honggfuzz, OSS-Fuzz ve piyasanın kernel bazında en iyi projesi olan Syzkaller geliyor bunlar ve bunlara benzer daha bir çok fuzzing projesi mevcut olmakla birlikte bunların yanı sıra; kasan, ktsan, kmsan ve kubsan gibi açık türünün tespitine dair ek yazılımlar geliştirilmiştir. Belirtilen yazılımlarla yüzlerce açık tespit edilmiş ve bunlardan bazıları 'exploit' edilirken bazıları için ise hızlı bir yama prosedürü uygulanmıştır.
Peki bunlar ne gibi açık türleri ve tespitleri nasıl yapılmaktadır ?
Syzkaller aslında fuzzing ve sanitizer dediğimiz iki methodun birleşimi ile performans göstermektedir. Sadece kaynak kodlar üzerinde değil, harici bellekler ile özgün çalışmalarda da başarılı bir performans sergileyin syzkaller bu alanda şimdiye kadar geliştirilmiş en başarılı araç olarak görünüyor. USB-Exploitation denildiğinde aklıma gelen ilk makale sanırım bu olacak, çünkü etkili bir fuzzing tekniği ve fiziksel araçların kullanımıyla başarılı bir sonuç elde edilmesi bu alan ile ilgilenen kişiler için yeni fikirler ve keşifler demek olacak. Yazılımları fuzz edebilmek kadar, fuzz edilen yazılımın exploit edilebilmeside aynı ölçüde önem taşımaktadır. Kod blogları arasında bulunan her zafiyetin exploit edilemediğini anlamamız ve idrak etmemiz gerekiyor. Syzkaller ile bulunan zafiyetlerin en iyi şekilde incelenerek pratik olarak anlaşılması gerekmektedir. Size hazır POC sağlamış olması sizin o açığı sömürebileceğiniz anlamına gelmez. Linux Kernel Exploitation için bir çok adım atmanız gerekmektedir, bu adımların başında günbegün eklenen güvenlik önlemlerini aşmanızın yanı sıra o mimariyi iyi ve etkili şekilde kullanmanızda gerekir.
Neden ? Çünkü bir mimarinin nasıl bir algoritmayla çalıştığını anlayamazsanız o mimari ile ilgili fikir yürütemezsiniz. Mesela BSD mimarisinde meydana gelen bir use-after-free açığını UMA mimarisi bilmeden exploit edebilmeniz fazla imkanlı görünmüyor, aynı durum Linux ve Windows mimarilerde geçerli. Bu yüzden öncelikle exploit edeceğiniz açığın türevini, bu açığın etkileşimde olduğu kod bloğunu ve o açık türevini sömürmek için gerekli olan argümanları toplamamız gerekir. Örneğin use-after-free yahut double-free yahut null-pointer açıklarından faydalanabilmek için öncelikle bu açıkların ne işe yaradığını ve zafiyetin nasıl oluştuğunu ve nasıl tetikleneceğini bilmemiz gerekiyor. Mesela; bir use-after-free açığından faydalanmak için yukarıda belirttiğimiz üzere SL(AUO)B memory management mantığını bilmemiz gerekecek. Bunun yanı sıra Heap Spray(Sendmsg Heap Spraying) yöntemini ve SMEP & SMAP gibi güvenlik önlemlerini aşmamız gerekecek tabi bunların ROP yahut JIT gibi yöntemlerle iltisaklı olduğunu unutmamak gerekiyor. Bu yüzden sizin yerinize POC yazacak bir yazılım değil pratik olarak sizin anlayıp uyguladığınız bir yazılıma dönüşmesi gerekmektedir. Sonuçta kodları siz okumuyorsunuz ya da kod bloglarını siz incelemiyorsunuz tek yaptığınız farklı config ayarları ile birlikte belirtilen yazılımı fuzz etmek. Bu konulardan mütevellit bir kaç örnek ile konuyu genişletmekte fayda var, bunlardan birisi Heartbleed zafiyeti. Bu açık son zamanlarda görülmüş en büyük zafiyetlerden birisi olması hasebiyle ve büyük bir etki göstermesiyle adını duyurdu, OpenSSL kütüphanesinde meydana gelen bu açık ile beraber yahoo, flickr ve tumblr gibi birbirine bağlı ünlü siteleri etkilemekle beraber hassas bilgilerinde açığa çıkmasını sağladı. Peki bu açık nasıl keşfedildi ve açık keşfedilirken nelerden faydalanıldı muhakkak merak etmişsinizdir o zaman beraber gözatmakta fayda var. Devami vol. II(Heartbleed açığını detaylı incelemek ve etkilenen siteleri görmek için referans kısmını kontrol edebilirsiniz.)
Yukarıda ki resimde gördüğünüz üzere "selftls" olan bir dosya üstünde fuzzing işlemi gerçekleştiriyoruz. Bu aslında; üretilen sertifikanın handshake dediğimiz yöntemle fuzz edilmesi demektir. Bu bahsettiğimiz üzere bir memory allocator hatasından kaynaklanmaktadır. Bu hatayı detaylı olarak anlamak istiyorsanız My heart is ok, but my eyes are bleeding yazısıyla tam manasıyla vakıf olabilirsiniz. Fuzzing başlattık.
Fuzing başladıktan 21 saat sonrası AFL bir hata ile karşılaştığını belirtti. İşte tam olarak otomasyon mantığıyla çalışan fuzzing yazılımlarının görevi bu oluyor, kodları satır satır okuyan arkadaşlar için bir doğrulama yöntemi olmasının yanında "blind fuzzing" içinde ideal bir araç olmuş oluyor. Bulduğumuz bu 3 açık aslında tam olarak openssl'in "memory allocator" yapısıyla alakalı yani ortaya çıkan açık "stack-based buffer overflow" açığı. Yani siz "ssl" kullanan bir yapıya istek yaptığınızda gönderdiğiniz istek eğer "memory" aşacak bir istekse haliyle hafızada hata üretiyor. Bu gibi hatalar "alloc" edilmiş bir hafızanın taşması sonrası meydana geliyor lakin yukarıda verdiğimiz linkte göreceğiniz üzere "openssl" firması kendi "allocator" yapısını oluşturmuş ve bu yapı baştan sona sağma bir biçimde yazılımla adapte edilmiş gibi duruyor(yeni versiyonlarda rastlayamazsınız).
Zaman ilerledikçe yapı üstünde ki hatalar artmaya devam ediyor. Bu "openssl allocator" yapısının yazılıma olan etkisi. (Biz burada 512-bit bir fuzz işlemi yapmıştık eğer bunu büyütmek isterseniz özgürsünüz bununla eşdeğer şekilde hızınızın düşeceğinide unutmayınız.) Handshake sırasında meydana gelen hataların çeşitliliği gitgide artıyor, bu "allocator" için sabit bir yapıyla gelen isteklerin 512-bit RSA olması gerektiğini düşünerek bu kadar alana sahip sabit bir alan ayırmasından ve bu alanın fazlasını karşılayamayacak esnek olmayan bir yapıya sahip olmasından kaynaklanıyor.
İlk bölüm burada bitsin, önümüzde ki bölümde açığın detaylı incelenmesi ve exploit edilmesiyle ilgili bir yazı yazacağız.
Referanslar;
https://www.scoop.it/t/flawless/p/4061440037/2016/03/20/coverage-guided-kernel-fuzzing-with-syzkaller-lwn-net
https://www.amazon.com/Fuzzing-Brute-Force-Vulnerability-Discovery-ebook/dp/B0031AI0V2
https://www.amazon.com/Fuzzing-Brute-Force-Vulnerability-Discovery-ebook/dp/B0031AI0V2
güzel makale sefa
YanıtlaSil