Zafiyet Araştırmalarında Fuzzing - I
Veysel Hataş, Fatih Sevimli, TÜBİTAK BİLGEM   
01.10.2014

Her geçen gün popüler uygulamalarda ve protokollerde tespit edilen güvenlik açıklıkları yayınlanmaktadır. Güvenlik sitelerinden veya deep web üzerinden duyurusu yapılmış/yapılmamış tespit edilen bu güvenlik açıklıkları buz dağının görünen kısmıdır. Bu yazıda bahsedeceğimiz Fuzzing yöntemleri bu zafiyetlerin keşfedilmesinde en çok başvurulan ve dinamik olarak gerçekleştirilen test tekniğidir.

Yazılım hatalarının (bugs) bazıları faklı risk derecelerinde zafiyet içerebilmektedirler. Bu zafiyetlerin farklı amaçlar doğrultusunda (hak yükseltme, veri sızdırma, arka kapı oluşturma gibi) kötüye kullanılması o yazılımı kullanan kişilerin mağdur olmasına neden olmaktadır. Bu nedenle yazılımcıların ürün öncesinde ve sonrasında yazılım üzerinde statik ve dinamik olarak zafiyet araştırmaları yapması ve zafiyet barındıran bug’ları tespit edip sonrasında yamamaları gerekmektedirler.

Uygulama güvenlik testleri için geliştirilen yöntemler temelde açık kutu (white box) testi, kapalı kutu (black box) testi ve ISO27001 Standartları kapsamında uygulama güvenliği aşamalarından biri olarak görülen gri kutu (gray box) testi başlıkları altında toplanmaktadırlar. Açık kutu testleri, kaynak kod üzerinden gerçekleştirilen ve RATs, Flawfinder, CodeSpy gibi kaynak kod denetim araçlarının kullanıldığı testlerdir. Bellek taşması zafiyetlerine neden olan güvensiz C/C++ fonksiyonlarının giderilmesinin yanı sıra format string, double-free, use-after-free, memory-leak gibi zafiyetlere neden olan kodlamadan kaynaklı (poor design) bug’ların tespitinde de kullanılan yöntemlerdir [1]. Kapalı kutu güvenlik testlerinde ise bazı aşamalarında tersine mühendislik (reverse engineering) yöntemlerinin de kullanıldığı ikili (binary) dosya üzerinden zafiyet araştırmaları gerçekleştirilmektedir. 

Gelişmiş uygulamalarda ve protokollerde kaynak kodun çok uzun olması ve kod akışı üzerinden tek tek zafiyet araştırmalarının neredeyse imkânsız olması otomatize etme ihtiyacını doğurmaktadır (Not: IDA disassemble, statik analizde en çok kullanılan araçtır). Zafiyet tespitlerinde otomatize stres testleri olarak fuzz yöntemleri tercih edilir. Günümüzde de Google, Mozilla, Microsoft, Apple gibi büyük firmalar, yazılım testi (SDL) aşamasında efektif olmasından dolayı fuzzing kullanmaktadırlar. Fuzz testleri genelde kapalı kutu olarak yapılsa da Gramer tabanlı testler, açık kutu şeklinde de gerçekleştirilebilmektedirler [2].

 FUZZ TESTİ 

Fuzzing, tanım olarak otomatik ya da yarı-otomatik olarak gerçekleştirilen uygulamanın buna karşı tepkisinin ölçüldüğü bir yazılım test tekniğidir.Uygulamanın girdi noktalarına yarı-geçerli (semi-valid) beklenmedik rasgele (random) veriler, sistematik olarak gönderilir. Sınır değer analizi (Boundary Value Analysis – BVA) ile doğrudan ilgilidir. Fuzz testini gerçekleştiren araçlara da fuzzer denilmektedir. Fuzzer’lar,  kendi algoritmalarını kullanarak geniş bir test kümesi (test cases) ile uygulama üzerinde deneme yapmaktadırlar. Uygulamaya göre fuzz testleri günlerce, haftalarca belki de aylarca çalışabilmektedirler.

fuzzing_tarihi.png 

Şekil 1 - Fuzzing Tarihi

Fuzz testi ilk olarak 1988/89 yıllarında Wisconsin Üniversitesi üyesi Prof. Barton Miller ve öğrencileri tarafından UNIX uygulamalarına rasgele string gönderen oldukça basit bir fuzzer ile gerçekleştirilmiştir. Günümüz itibariyle de fuzz testleri, farklı fuzzing yaklaşımlarıyla gelişimine devam etmektedirler.

 FUZZ EVRELERİ ve FUZZING PLATFORMU

Otomatize ve yarı-otomatize gerçekleştirilebilen fuzzer’ların neredeyse tamamı aşağıdaki resimde görülen fuzzing aşamalarını içermektedirler. Öncelikle hedef yazılım üzerindeki testini gerçekleştireceğimiz girdi noktalarının tespiti yapılır. Hedefimiz bir dosya formatı (swf, pdf, jpeg, m3u ...), bir protokol (ftp, http, arp, ssl ...), çevresel değişken (environment variable), web uygulaması ya da kayıt anahtarı girdisi (register key) şeklinde olabilir. Sonrasında girdi noktalarına gönderilecek formatına uygun fuzz verilerinin, tercih edilen fuzzing yöntemi ile oluşturması gerekmektedir. Fuzzing’in her aşamasında bu veriler çalıştırılarak o girdinin herhangi bir hataya neden olup olmadığı framework altında gözlemlenir ve bu bir program çakılması (crash) ise sonuçları kayıt altına alınır (sysinfo, memory map, backtrace log’ları gibi). Bu fuzzing sonuçları güvenlik problemlerinin tespiti açısından büyük önem taşımaktadır. Son aşamada sonuçlar üzerinden bug’ın sömürülebilir (exploitable) olup olmadığına bakılarak güvenlik risk düzeyi tespit edilir (Windows sistemlerde windbg eklentisi !exploitable, Linux sistemlerde Amerika CERT ekibinin geliştirdiği CERT Triage Tools kullanılabilir).

Döngüsel olarak fuzzer uygulamaya yeni input’lar göndererek çalışmasına kaldığı yerden fuzzing işlemi sonlanıncaya kadar otomatik veya yarı-otomatik devam eder. Fuzzing sonrası exploitable log’lar üzerinden biraz assembly kod yorumlaması yaparak zafiyetin türünün tespiti (örneğin, “REP MOVS ...” komutunda crash olduysa strcpy/memcpy fonksiyon kullanımından kaynaklı overflow zafiyeti, “MOV %ECX, (%EAX)” komutunda crash olduysa format string zafiyeti şeklinde yorumlayabilme gibi) yapılabilir.

fuzz_evreleri.png 

Şekil 2 - Fuzz Evreleri

Örnek bir ftp uygulaması için yukarıdaki adımlara göre basit bir fuzzer tasarımı görelim. Sunucu – istemci arasındaki protokol fuzz edilecekse giriş vektörleri de ftp komutları (STOR, MKD, LIST, ...) olacaktır. Zafiyete uygun (format string, buffer overflow, integer overflow ...) fuzz verisi üretmemiz gerekmektedir. Burada bellek taşması zafiyetinin [3] tetiklenmesi istenildiğinden fuzzing boyunca farklı uzunluklarda “A” string’ini üretilecektir ve sunucuya ftp komutlarıyla gönderilecektir. Zafiyet içeren ftp sunucusu ve yazılan fuzzer kaynak kodlarını buradan indirebilirsiniz.

ftp_fuzzer_fuzz_evreleri.png 

Şekil 3 - FTP Fuzzer (Fuzz Evreleri)

Monitor edilen fuzzing işlemi esnasında fuzzer tarafından basit bir şekilde crash log’u tutulmuştur.

crash_log.png 

Şekil 4 - Crash Log

Yazının bu bölümünde "Fuzzing Nedir" konusuna değinildi. Yazının II. bölümünde ise "Fuzzing Metotları" konusundan bahsedilecektir.

REFERANSLAR 

[1] http://www.hpenterprisesecurity.com/vulncat/en/vulncat/index.html

[2] http://people.csail.mit.edu/akiezun/pldi-kiezun.pdf 

[3] https://www.bilgiguvenligi.gov.tr/yazilim-guvenligi/bellek-tasmasi-stack-overflow-ve-korunma-yontemleri.html

[4] M. Sutton, A. Greene, and P. Amini, Fuzzing: Brute Force Vulnerability Discovery, Addison–Wesley Professional, United States, 2007. 


Favori olarak ekle (0) | Görüntüleme sayısı: 8533

Bu yazıya ilk yorumu yazın

Sadece kayıtlı kullanıcılar yorum yazabilir.
Lütfen sisteme giriş yapın veya kayıt olun.