Fuzzing Mobile – 101

Posted on June 22nd, 2015

Yakın zamanda mobil platformlara yönelik bir fuzzing makalesi hazırlamaya karar verdik ve odak noktası olarak mobil web tarayıcısını ele aldık. Fuzzing testini Jailbreakli iOS 7 iPhone 4S cihazı üzerinde gerçekleştirdik.

Peki hedefimiz ne ?

Zafiyet arama işleminde hepimizin bildiği üzere ilk aşama input noktalarını tespit etmektir. Neticede yapılacak iş aslında bir input manipülasyonudur. Eğer bir browserı hedef alırsak , o zaman browserın olası input noktalarını belirlememiz gerekir. Aşağıdaki tablo bir browserın yorumladığı (rendering) , kullanıcı tarafından belirlenebilen dataları göstermektedir. Anlaşılacağı gibi bu tabloda belirtilen her element (PDF, Audio, Image, CSS, JS) browser için bir inputtur . İşte fuzzing’de biz bu inputlardan herhangi birini hedef alıp , input manipülasyonu yapabiliriz.

Genelde browserlarda , tabloda da görülebileceği üzere Javascript, Html ve CSS ‘ in payı daha büyüktür. Bu yüzden zafiyet avcıları genelde bu elementleri fuzz ederler. Biz ise bu makalede “auido” fuzzing gerçekleştireceğiz. Zaman zaman Safari ve çeşitli uygulamalarda TIFF , PDF, MP4 vb. medya elementlerinin yorumlanması esnasında oluşan zafiyetlerle karşılaşıyoruz. ¹ ²

Biz de AAC (Advanced Audio Coding) ses türlerinden .m4r ve .m4a dosyaları üzerinden mutation based – dumb fuzzing yapacağız.

Mutating Input Values

İlk amacımız bu iş için elimizdeki sample dosyanın içeriğini değiştirecek bir fuzzer kullanmamız lazım. Biz daha önceden geliştirilmiş Bug Hunter’s Diary kitabındaki fuzzer’dan yararlandık ancak aynı işlemi siz ufak bir script ile de yapabilirsiniz. Fuzzerın kodlarına projeye ait Github deposundan ulaşabilirsiniz: fuzzer.c

Alarm.m4r dosyasının orijinalini şimdilik bozmak istemediğimizden ilk olarak dosyayı case1.m4r adında klonladık. “du” komutuyla iki dosyanın da boyutlarının aynı olduğunu görebilirsiniz. Daha sonra fuzzer.c yi derledik ve case1.m4r dosyasının 4.offsetini “0xFF” (255) değeri ile değiştirdik;

Gördüğünüz gibi Alarm.m4r dosyasının 4.offseti 00 iken case1.m4r dosyasının 4.offseti FF değerini almış (saymaya 0’dan başlıyoruz). Bizim bu işlemi, fuzzing olabilmesi için sıfırıncı byte’dan başlayıp , son byte’a kadar bu şekilde belirlediğimiz bir fuzzing değeri ile (0xFF)değiştirerek (byte-flip ) otomatize etmemiz ve farklı testcaseler oluşturmamız gerekiyor. 0xFF değeri potansiyel integer overflow ve signedness error hatalarını tespit edebilmek için seçildi , farklı değerler da seçilebilir. Bu süreci otomatize etmek için autofuzz.sh scriptini kullanacağız. Scriptin kodları şu şekilde, baktığınızda da ne iş yaptığını kolayca anlaşılır;

Şimdi testcase dosyalarımızı otomatize bir şekilde oluşturalım yapalım:

“case1.m4r” dosyasının ilk 20 offsetine sırasıyla FF değerini yerleştirdik. Örnek olması açısından 20 tane dosya oluşturmayı tercih ettik.Fuzzing yaparken 1000 veya 10000 gibi sayılarla dosyaları oluşturacağız.

Buraya kadar her şeyi başarılı bir şekilde hallettik. Fuzzing’de ilk aşamamız yukarıda anlatıldığı gibi çeşitli sample dosyalardan bu şekilde binlerce testcaseler oluşturmak. İkinci aşamamız ise oluşturduğumuz bu testcaseleri , hedef uygulamada , örneği Safari browserda açmak. Amacımız oluşturduğumuz bu dosyaların Safari tarafından yorumlanmasını sağlamak ve bir crash / potansiyel zafiyet keşfetmek. Fakat oluşturduğumuz mutasyon ses dosyalarının 1000, 10000 gibi sayılar olduğunu düşünürsek, bu işlemi elle yapmak çok vakit alacaktır hatta imkansız bir hale dönüşecektir. Oluşturduğumuz ses dosyalarının browser üzerinde otomatik çalıştırmak istiyoruz.Bunun için 1.m4a dosyası açıldıktan belli bir süre sonra(1 saniye), 2.m4a 3.m4a ….,1000.m4a şeklinde açılmasını sağlamamız gerekiyor. Bu otomatize işlemi yapmak için de ayrı bir script geliştirmemiz gerekiyor. Windows ortamında bunu yapmak ve hatta crash olduğunda otomatik olarak log tutmak oldukça kolay ancak mobil platformlar biraz daha kapalı kutu.

Hedefimiz Safari olduğu için aklımıza oluşturduğumuz mutasyon dosyaları yorumlatmak için oldukça basit ve güzel bir yöntem geldi.Bunun için html meta taglarını kullanmaya karar verdik. Yani kullanacağımız yöntem html meta-refresh yöntemi. Kısaca meta-refreshi ne için ve nasıl kullanacağımızdan bahsedelim. Oluşturduğumuz ses dosyalarının sayısı kadar içinde html meta-refresh metodunu kullanarak yönlendirmeyi sağlayacağımız html dosyaları oluşturacağız. Örneğin 1.html dosyasının içinde 1.m4a çalıştırılacak, ardından 1 saniye gibi kısa bir zaman aralığından sonra 2.html dosyasına geçiş yapılacak ve 2.m4a çalıştırılacak. Bu döngü 1000.html 1000.m4a’ya veya sizin belirlediğiniz sınırlara kadar devam edecek.

Geliştirdiğimiz signalfuzzer.py scriptine projenin github sayfasından ulaşabilirsiniz. Fuzzing’i bu şekilde yapmak için web server kullanacağız. Hazırladığımız dosyaları web server’a atıp çalıştırınca fuzzing işlemi başlamış olacaktır.

Let the Fuzzing begin !

Scriptleri web server üzerinde çalıştırdık ve m4a dosyalarından testcaselerimizi oluşturduk. Daha sonra yapmamız gereken signalfuzzer.py scriptini gerekli inputları vererek çalıştırmak. Gördüğünüz gibi .m4a ve meta-refresh metotuyla çalışan html dosyaları oluşturuldu;

Bundan sonra yapmamız gereken, fuzzing yapacağımız mobil browser’da web server IP adresini kullanarak 1.html dosyasını çalıştırmak.

Örnek: http://ServerIP/1.html

1.html sayfası açılınca 1.m4a çalıştırılacak ve 1 saniye sonra 2.html sayfası açılıp 2.m4a çalıştırılacak.Bu döngü böyle 500’e kadar devam edecek. Oluşturduğumuz dosya sayısına ve türüne bağlı olarak eğer fuzzing işlemi işe yararsa browser crash olana kadar bu işlem devam edecektir.

Fuzzing’i başlattıktan sonra son olarak access_log dosyasını izlemeye alabilirsiniz. Crash olursa, Safari browser kapanacaktır, böylece en son hangi dosyaya erişildiğine loglardan bakara, crash eden dosyayı bulabiliriz. Sizde bu şekilde farklı dosya türlerini kullanarak mobile browser üzerinde fuzzing yapabilirsiniz.

Fatih Erdoğan