Aşağıdaki yazı, http://www.ivizsecurity.com/blog/web-application-security/testing-flash-applications-pen-tester-guide/ adresindeki yazı üzerine bina edilmiştir. Orjinal adres yorumlarında faydalı başka linkler de mevcut.
OWASP'ın sitesinden flash uygulama güvenliği ile ilgili araştırma yapılmasında da fayda vardır.
...
Flash RIAs (Rich Internet Application) hakkında:
Flash, 1996 yılında Macromedia tarafından ortaya çıkarılan, sonrasında Adobe Systems tarafından geliştirilen bir multimedya platformudur. O yıldan bu yana Flash, web sayfalarına animasyon eklemek ve interaktif uygulamalar geliştirmek için çok popüler oldu. Yaygın kullanım alanları: Animasyon, reklam, çeşitli web sayfası bileşenleri oluşturma, web sayfalarına video entegre etme, ve son zamanlarda zengin internet uygulamaları geliştirme. (http://en.wikipedia.org/wiki/Adobe_Flash)
Yaygın kabule göre, Flash teknolojisi kullanılarak geliştirilen RIA, kullanıcının browser'ındaki Flash Plugin ya da kullanıcı sistemine kurulmuş AIR platformu tarafından çalıştırılmak üzere SWF/AIR objesi olarak derlenmiş bir front-end (kullanıcı ile iletişimden sorumlu parça) uygulamadan olıuşmaktadır. Bu interaktif uygulama son kullanıcı için bir arayüz sağlar ve iş mantığı işlemleri için bir arka-uç (back-end) sunucu ile HTTP/AMF, HTTP/SOAP, HTTP/REST gibi bir protokol üzerinden iletişim kurar.
Güvenlik Açısı:
Yaygın kullanılan web uygulamaları ve yazılımlarında olduğu gibi, bir RIA da en yaygın ve tehlikeli güvenlik zafiyetlerinin kurbanı olabilir. Mesela, çoğu Flash tabanlı RIA, iş mantığı işlemleri için bir uygulamanın önünde yerleşmiş olduğundan ve bir veritabanı kullandığından, kullanıcı girdileri düzgün bir şekilde işlenmediği takdirde SQL injection gibi yaygın olan uygulama zafiyetlerinden muzdariptir.
Bununla birlikte saldırganlar, mesela tamamen Flash/ActionScript ya da BOF ile yazılmış arka kapıları (backdoors) ya da kötücül yazılımları (malware), uygulamaları exploit etmek için kullanabilir.
Güvelik açıklarının çekirdek ortamda da (core environment) bulunabileceği (OS ya da web browser'lar gibi) ve bunların o ortamda çalışan uygulamalar hesaba katılmaksızın exploit edilebileceği, yaygın bilinen bir gerçek. Adobe, yayınladığı bir yazıyla Adobe'nin yaklaşımının, bir yandan diğer ortamlara hiç zarar vermezken, diğer yandan kendi ürünleri içinde güçlü bir güvenlik sağlamak / implemente etmek olduğunu öne sürmüştür. Bu, platformdan bağımsız bir şekilde, Flash uygulamalarının yapabileceği (Flash Player içinde yönetildiği gibi) tutarlı bir yüksek seviye güvenlik sağlar. Adobe ürünleri de mümkün olduğunca eski-versiyon-uyumlu (bacward-compatible) tasarlandığından, işletim sistemi ya da browser'lar içindeki bazı ortamlar açıklıklara karşı daha dayanıksız olabilirler; ya da daha zayıf kriptolama kabiliyetine sahip olabilirler. En sonunda, platform seçiminden ve ortamlarının bakımından kullanıcılar sorumlu.
Flash tabanlı RIA'lardali zafiyetler kabaca 2 kategoride sınıflandırılabilir: İstemci-tarafı zafiyetler ve sunucu-tarafı zafiyetler.
İstemci Tarafı Zafiyetleri:
Bir Flash uygulamayı istemci tarafında etkileyebilecek çeşitli zafiyetler arasında en yaygın olanları şunlardır:
Flash Parameter Injection: Bir saldırgan, bir ana HTML sayfasına bir video gömülü olduğu durumda global Flash parametreleri enjekte edebilir. Enjekte edilen bu parametreler, saldırgana, Flash film içindeki diğer objeleri kontrol edebilme yeteneği kazandırabileceği gibi, sayfanın DOM'u (Document Object Model) üzerinde full kontrol kazanmasını da sağlayabilir. Bu zafiyet üzerine IBM Rational elemanları hazırlanmış hoş bir yazı buradan indirilebilir.
Cross Domain Privilege Escalation: Etki alanları (domain) arası içerik ve veri paylaşımı (inter-mixing), SWF objesi hizmetini sunan domain'in crossdomain.xml dosyası içindeki erişim politikası baz alınarak gerçekleştirilir. Eğer erişim potikası çok açıksa, o zaman kesin koşullar altında, bir saldırgan için orjinal SWF objesi yerine kendi kötücül objesini koymak ya da servis sunan domain'in DOM'una erişmek mümkün hale gelebilir.
Cross Site Scripting: Erişim politikasına bağlı olarak, bir Flash SWF, çeşitli fonksiyonel nedenlerle host'unun DOM'una erişebilir. Bu durumda SWF objesi host'unun DOM'unu değiştirebilir ve eğer bu da temizliğe tabi tutulmamış (sanitize) kullanıcı girdilerine dayandırılarak yapılabiliyorsa, host DOM'u üzerinde XSS gerçekleştirmek olası hale gelebilir.
Cross Site Flashing (XSF): Bir SWF objesinin başka bir SWF objesi yüklediği (load) durumda oluşur. Bu saldırı, bir XSS ya da kullanıcıyı hassas veri (kullanıcı adı ve şifresi gibi) girmek için kandırabilecek bir arayüz değişikliği yapılabilmesi sonuçlarını doğurabilir. XSF, Flash HTML enjeksiyonu ya da loadMovie metotları kullanıldığında dış SWF dosyaları yanında kullanılabilir. OWASP'ın XSF test rehberi, çok geniş kapsamlı olmasa bile, XSF konusunda çok iyi bir başlangıç olacaktır.
Sunucu Tarafı Zafiyetleri:
Flash uygulamaları, bir arka uç sunucuya nadiren uzak çağrı yaparlar; bu çağrılar, hesapları aramak, ek veri ve grafik almak, ve karışık iş-mantıklarını yerine getirmek gibi çeşitli nedenlerle olabilir. Bununla birlikte, uzak metotları çağırabilme yeteneği, bu uygulamalar tarafından açığa çıkarılan atak yüzeylerini de genişletir. Flash uygulamaları, genelde HTTP protokolü üzerinden bir iletişim metoduna dönüştürülen AMF objelerini kullanan Adobe Flex SDK ile bina edilmiştir. AMF-Remoting çağrıları RPC-benzeri çağrılardır; Flash uygulama, sunucu üzerinde özel bir AMF Endpoint'te tanımlı istenen metodu çağırır. Bir saldırgan araya girebilir ve sunucu ile uzlaşmak için AMF verisi ile oynayabilir.
Çoğu durumda, bir Flash tabanlı RIA ön ucunun iş mantığını sağlamaktan sorumlu olan uygulama sunucusunun ön ucu, standart bir web uygulamasıdır ve diğer tüm web uygulamaları ile aynı zafiyetleri barındırıyor olabilir.
Flash Uygulamalarının Testi: Hedef ve Yaklaşımlar
- Uygulama girdi noktaları tanımla; ve SWF objesini olası açıklıklar için test et.
- İş mantığı ihtiyaçlarını karşılamak için uygulamanın iletişim kurduğu uzak sunucuyu -varsa- tanımla.
- SWF objesinin arka-uç sunucu ile kurduğu iletişim protokolünü tanımla. Çoğu zaman bu protokol SOAP/REST ya da AMF olacaktır.
- Arka-uç uygulama tarafından ortaya konan tüm fonksiyonları tanımla ve sırala.
- Arka-uç uygulama tarafından ortaya konan fonksiyonları tek tek standart uygulama zafiyetleri için sızma testine tabi tut.
İstemci Tarafı Testi:
İstemci tarafı, birincil olarak flash uygulamanın statik analizi ile ilintilidir. Bir Flash SWF objesinin statik analizi düşüncesi, SWF dosyasını decompile etmek ve white-box test yaklaşımıyla Flash SWF dosyasının kaynak kodu içine bakma yaklaşımıdır. İstemci tarafı zafiyet testi için temel yaklaşım:
- SWF dosyası, kaynak koduna decompile edilir (ActionScript) ve bilgi sızdırma gibi güvenlik denetimleri statik olarak analiz edilir (hard coded)
- Kaynak koda erişmeden üçüncü parti uygulamalar denetlenir.
- Kod içine gömülmüş (hard-coded) login credential'ları, IP adresleri vs analiz edilir.
- SWF dosyası analizi dışında, SWF objesinin gömüldüğü HTML dosyasının kaynak kodunun analiz edilmesi de önemlidir. Gerçek/kesin koşullar altında SWF girdilerini etkileyebilecek FlashVars değişkenlerini manipüle etmek mümkün olabilir (Bu cümle doğru oldu mu?)
Bu işleri gerçekleştirmek için otomatize araçlar da var: HP SWFScan gibi.
Sunucu Tarafı Testi:
Flash tabanlı bir RIA'nın sunucu tarafı testlerini gerçekleştirmenin yolları:
- Extract Gateway
- Flash'ı service capture / burp proxy / charles proxy çalışırken bir browser ile load et, örn. http://foo.com/bar.swf
- SWFdump kullanarak SWF dosyasını decompile et ve gateway örüntülerini (pattern) grep et (!). Ayrıca SWFdump içinden tüm URL'lerin bir listesini al.
- Servis / metotları sırala
- Pinta kullanarak tüm ağ geçitleri üzerinde amfphp.DiscoveryService dene.
- Servisler ve metotlar manuel olarak girilmişse bile AMF çağırmaları için Pinta kullan; bu durum, uzak (remote) metotların testinde de yardımcı olabilir.
- Eğer bu başarısız olursa şu regular expression kalıplarını kullanarak SWFDump regex ile bunları açmayı (extract) dene.
- AMF çağrıları yap
- Pinta kullanarak farklı test parametreleri ile uzak metot çağrıları yap.
- Tek tırnak (SQLi), komşu parametreler (Direct Object Reference).
–"\"([a-zA-Z0-9_]*)\"“ with filter as “service” (conventional)
.
–"destination id=\"([\\w\\d]*)\"“
Ortaya konmuş fonksiyonalite için tek sefer arka-uç uygulamayı test etmek, web uygulama güvenliğüi testleri için geleneksel sayılabilir.
Test Edilecek Zafiyetler Kontrol Listesi:
- XSS
- Kötücül veri enjeksiyonu
- Yetersiz kimlik denetim kısıtları
- Güvenli veri aktarımı / taşıması
- SWF bilgi sızdırma
- Anti-ClickJack için minimum stage (sahne)
- SWF kontrol izni
- Aynı domain'de güvenilmeyen SWF bulunması
- Clickjacking
- Hak ayırma (privilege seperation)
- Domain'ler arası politika denetlemesi
- Initialize edilmemiş değişken tarama (scanning)
- Uzak metot sıralama (enumeration)
- İş mantığı testi
Hiç yorum yok:
Yorum Gönder