OWASP Top10 Açıklık ve İlgili Araçlar

OWASP'ın 2010 yılı için açıkladığı en önemli 10 güvenlik riski ve bunlar için en faydalı araçlardan birer örnek, bu yazının konusunu oluşturur. Yazı http://resources.infosecinstitute.com/owasp-top-10-tools-and-tactics/ adresinde bulunan makale baz alınarak hazırlanmıştır.
OWASP'ın 2010 yılı analizi ile ilgili detaylar için: http://www.owasp.org/index.php/Top_10_2010-Main

Risk - Araç matrisi:

RISK	TOOL
A1: Injection	SQL Inject Me
A2: Cross-Site Scripting (XSS)	ZAP
A3: Broken Authentication and Session Management	HackBar
A4: Insecure Direct Object References	Burp
A5: Cross-Site Request Forgery (CSRF)	Tamper Data
A6: Security Misconfiguration	Watobo
A7: Insecure Cryptographic Storage	N/A
A8: Failure to Restrict URL Access	Nikto/Wikto
A9: Insufficient Transport Layer Protection	Calomel
A10: Unvalidated Redirects and Forwards	Watcher

1. Injection: SQL Inject Me
SQL Inject Me, en yaygın bilinen Firefox plug-in'lerinden biridir. Aktif hale getirildiğinde aşağıdaki ekran görüntüsünde bir sidebar açılır. Bu arayüz değişkendir; browser'da açılan sayfadaki formlara ve girdi alanlarına göre dinamik olarak değişir.

Test tamamlandığında sonuçları ayrı bir Firefox tab'ı olarak açılır.

2. XSS: ZAP
ZAP: Zed Attack Proxy.
Bir OWASP projesidir. Web uygulamalarındaki zafiyetleri bulmak için kolay kullanımlı bir sızma testi aracıdır. Desteği devam eden ve gelecek planları yapılan bir araçtır. 1.2.0 versiyonu, bir kişisel vekil, kaba kuvvet saldırı, port tarama ve spidering gibi kabiliyetleri barındırmaktadır. Genel bir açıklık tarama aracı olmasına karşılık biz bu aracı XSS tarama için özel olarak değerlendiriyoruz.

Orijinal makalenin yazarı, ZED'in spidering kabiliyetini de takdir ettiğini söylüyor.

3. Broken Authentication and Session Management: HackBar
Sözü edilen açıklığın en önemli nedenlerinden biri, zayıf SessionID'dir. Sıkça SSL/TLS kullanmadan transfer edilirler; zayıf depolanmışlardır (kripto kullanmadan); URL rewriting ile ortaya çıkarılabilirler. SessionID'nin kullanıcı parolasının MD5 ya da Sha1 hash kodu olduğu durumlar bile görülmüştür. Saldırgan MITM (Man-In-The-Middle) gerçekleştirebilmişse ya da XSS gibi bir yöntemle kullanıcı SessionID'sini elde edebilmişse, ters çevirmeden replay edildiği konu edilmezse (!), Firefox plug-in'i olan HackBar kullanılabilir.
Yükledikten sonra F9 kısa yoluyla HackBar görüntülenebilir; burada Encryption pull-down menüsünden Sha1 ya da MD5 menüsü, o menü altından da Send To...

XSS ve SQLi testleri yanıs sıra, HackBar, Base64, URL ve Hex encoding-decoding konusunda da çok başarılı bir araç.

4. Insecure Direct Object References: Burp Suite
Doğrudan nesne referansının en kötü sonucunun dizin gezinimi olacağını düşünebiliriz.
Dizin gezinimi testi için Burp'ün ticari versiyonu yanında ücretsiz versiyonu da kullanılabilir.
Test için: WebGoat içindeki Access Control Flaws - ByPass a Path Based Access Control Scheme dersi kullanılabilir. Burp'ün sol penceresinde görünen linke (http://localhost/WebGoat/attack?Screen=17&menu=200) sağ tıklanarak adres Repeater'a gönderilir; Repeater tab'ına gidilir, File parametresindeki BackDoors.html değeri BackDoors.html..\..\..\..\..\..\..\..\windows\windows.ini olarak değiştirilir.


5. CSRF - TamperData
Firefox plug-in'i. Yüklendikten sonra Tools menüsü altından aktif hale getirilebilir. Tamper data ile yapılan, HTTP taleplerini yakalayıp değiştirerek göndermektir; bu özelliği ile CSRF testleri bilinen prosedürleri ile gerçekleştirilir. Webscarab vb kişisel vekiller ile HTTP talepleri yakalayarak CSRF testleri gerçekleştirmeden bir farkı yoktur Tamper Data ile bu testleri gerçekleştirmenin.


6. Security Misconfiguration: Watobo
Watobo, yarı otomatik web uygulama denetimleri yapmak için tasarlanmıştır ve ayrıca hatalı konfigüsaryonları bulma konusunda iyi bir araçtır.
Watobo bir kişisel vekil gibi çalışır. Ruby ile yazıldığından Ruby interpretter kurulmasını gerektirir. Öntanımlı olarak dinlediği port 8081'dir.


8. Failure to Restrict URL Access: Nikto/Wikto
Uygulama, korunmuş bölgelere erişen URL'leri her erişme girişiminde test etmeli; aksi halde saldırgan, Nikto (ya da bunun benzeri bir Windows GUI'si olan Wikto) benzeri araçlarla özellikle sayfa hiyerarşisi iyi bilinen wordpress benzeri uygulamalarda gizli/yetkisiz sayfalara erişebiliecektir.
Nikto, web sunucular üzerinde geniş kapsamlı testler gerçekleştirebilen bir web sunucu tarayıcısıdır. Potansiyel olarak tehlike taşıyan 6400 dosya/CGI, 1000'den fazla sunucu için versiyon güncelliği kontrolü ve 270'den fazla sunucu için var olan versiyona özel zafiyetler, Nikto'nun birçok test kaleminden birkaçıdır.
Nikto, Perl ile yazılmıştır ve çalıştırmak için Perl interpreter gerektirir. Linux bir sistemde şu şekilde çalıştırılabilir: ./nikto.pl -h <hedef host IP ya da URL>.

Nikto taramalarında false positive sonuçlar elde etmek olasıdır, ama çok değerli sonuçlar da elde edilecektir.
Yukarıdaki resmin sonunda erişimin kısıtlanması gerektiği düşünülen bir dizin raporlanmıştır.

9. Insufficient Transport Layer Protection: Calomel Add-on
Yetersiz taşıma katmanı korumasının tarifi kolaydır, SSL kullanılmaması. Calomel, sertifika durumu hakkında çok güzel bilgi veren bir Firefox plug-in'i.

Calomel, SSL bağlantısı güvenliğini derecelendirir; uygulamaya özel buton'un rengi, güvenlik seviyesine göre farklılaşacaktır. Butona basıldığında da şekildeki gibi detaylar dökülecektir.

10. Unvalidated Redirects and Forwards: Watcher
Watcher, Chris Weber'in Fiddler (ücretsiz web debugger) uygulaması için bir add-on (sadece IE için). Pasif bir analiz aracı olarak inanılmaz güzel çalışır. Ayrıca açık yeniden yönlendirmeleri (redirect & forward) yakalar. Fiddler ile birlikte kurulacak Watcherın çalışıp çalışmadığını anlamak, Fiddler üzerinden trafiğin geçtiğini anlamak kadar kolaydır; yani Fiddler üzerinden trafik akıyorsa (kişisel vekil) Watcher da çalışıyor demektir.

URL redirect zafiyetinin ne kadar yaygın olduğunu görmek için google'da şu aramayı yapabiliriz: inurl:”redirect.asp?url=”.

Unfiltered Header Injection Vulnerability

Forging HTTP Request Headers With Flash
http://www.securityfocus.com/archive/1/441014/30/0/threaded paper'ı (Amit Klein, Temmuz 2006) üzerine inşa edilmiştir. Acunetix tarafından raporlanan "Unfiltered Header Injection in Apache" zafiyetinin nasıl exploit edilebileceği ve neden bir zafiyet olarak kabul edilmesi gerektiği anlatılmaktadır.

Ön Bilgi -Flash:
Flash filmleri SWF (ShockWave File) dosyaları olarak yayımlanır. Adobe, Flash'a scripting kabiliyeti eklemek amacıyla Javascript benzeri bir zengin dil geliştirdi: ActionScript. ActionScript'in ilginç özelliklerinden biri de 3üncü pati sitelere, onları çağıran browser üzerinden HTTP talep (request) gönderebilmesidir. Bu nokta, Flash'ın güvenlik açısından ilginçleştiği noktadır. Flash ile 3üncü parti sitelere gönderilmek üzere, "standart" Javascript yolu ile oluşturulup gönderilmesi mümkün olmayan talepler bina etmek mümkün. Bu konuda özellikle ilgilendiğimiz yönü de giden talep ile birlikte rasgele / keyfi HTTP talep başlıkları (header) gönderebilme yeteneği.

Flash ile Keyfi HTTP Talep Başlıkları Gönderme:
Aşağıdaki kodlar, keyfi bir başlıkla birlikte bir GET talebi göndermek için ActionScript 2.0 kodu sözdizimidir (syntax).

Bu örnekte:
Talebin gönderileceği site: http://www.vuln.site/some/page.cgi?p1=v1&p2=v2
Gönderilecek keyfi başlık: Foo:Bar
Kodun çalışabileceği Flash versiyonları: Flash 7 ve Flash 8

var req:LoadVars=new LoadVars();
req.addRequestHeader("Foo","Bar");
req.send("http://www.vuln.site/some/page.cgi?p1=v1&p2=v2",
"_blank","GET");

Benzer bir kod da POST talebi gönderir (Yukarıdaki bilgilere ilaveten gövde olarak da a=b ve c=d gönderiliyor):

var req:LoadVars=new LoadVars();
req.addRequestHeader("Foo","Bar");
req.decode("a=b&c=d");
req.send("http://www.vuln.site/some/page.cgi?p1=v1&p2=v2",
"_blank","POST");

Flash nesnesinin çağırılması ile talep 3üncü parti siteye gönderilir. Browser'ın normalde gönderdiği cookie'ler, bu durumlarda da gönderilecektir. Neredeyse tüm browser'ların standart gönderdiği başlık olan User_Agent başlığı gönderilir. HTTP linkleri desteklenmektedir.

Bu örnek, Microsoft IE 6.0, Microsoft IE 6.0 SP 2, Firefox 1.5.0.4 ile, Flash v8.0.22.0 ve Flash v7.0.19.0 çalıştırılarak başarıyla gerçekleştirilmiştir.

IE içinde, basitçe addRequestHeader fonksiyonunu çağırarak var olan "normal" başlıkları yeniden yazmak da mümkün. Bu durum hem Referer, hem de User-Agent başlıkları için mümkün. Firefox içinde aynı yöntem uygulandığında başlıklar talebe append olur / talebe eklenir.

// One UA in IE 6.0 SP2, two UAs in FF 1.5.0.4
req.addRequestHeader("User-Agent","Hacker/1.0");

// One Referer in IE 6.0 SP2, two Referers in FF 1.5.0.4
req.addRequestHeader("Referer","http://somewhere/");

Ayrıca, IE içinde, başlık adına kolon ekleyerek bazı hassas başlıkları (Host ve Content-Length gibi) da yeniden yazmak mümkün. Bu teknik Firefox'ta uygulanamıyor.

req.addRequestHeader("Host:","foobar.site");

Not: Hedef URL, Flash filmi ile aynı domain'de durumda, LoadVars, HTTP yanıtlarını okumak için de kullanılabilir; bu da LoadVars'ı Flash tabanlı AJAX benzeri framework'ler için temel haline getirmekte.

Güvenlik Açısı:
Bir saldırganın, kurbanın web browser'ını kandi keyfi talep başlıklarını enjekte ettiği talepleri 3üncü parti sitelere göndermeye zorlama kabiliyeti, güvenlik açısından değerlendirmeye tabi tutulacak durumdur.

Burada açıklanan saldırıların, tek başlarına XSS saldırıdı olmadığını anlamak önemli; domainler arası (cross-domain) güven ilişkisini ya da Flash nesne ile gömüldüğü HTTP sayfa arasındaki güven ilişkisini kıran bir yapı söz konusu değil. Buradaki saldırılar sadece bir Flash nesnesinden bir URL'e içinde saldırganın işine yarayacak başlıkları barındıran HTTP talebi gönderebilmenin mümkün olduğu gerçeğinden faydalanmaktadır. Bu mümkünat, saldırgana kurbanın browser'ında açılacak bir Flash uygulamayı (Flash nesnenin gömülü olduğu bir HTTP sayfası ya da doğrudan uygulama) barındıran bir link göndermesiyle ortaya çıkan, kendi başına bir sorun. Bu Flash nesnesi, saldırganın ihtiyaç duyduğu başlıkları barındıran HTTP taleplerini hedef web sitesine gönderir ve bu durum kurbanın browser'ının güvenlik teamüllerinin kırılmasına sebep olur.

Diğer bir deyişle, yaygın olan HTTP başlıkları, keyfi değerler taşımaya zorlanamaz kanısı yerle bir...

Örnek: Expect Başlığı:
http://www.securityfocus.com/archive/1/433280 adresinde Apache 1.3.34/2.0.57/2.2.1 versiyonlarında var olan bir enjeksiyon problemi anlatılıyor: Bu versiyonlar, Expect başlığı yolu ile Javascript de dahil HTML verisi enjekte edilebilmesine olanak veriyor. Bir Flash nesnesi ile bu açıklığı exploit etmek oldukça basit. Kurbanın aşağıdaki linki tıkladığını düşünelim:

http://www.evil.site/attack.swf

Adres, aşağıdaki ActionScript kodunu taşıyan bir Flash nesnesini işaret ediyor:

var req:LoadVars=new LoadVars();
req.addRequestHeader("Expect","<script>alert('gotcha!')</script>");
req.send("http://www.target.site/","_blank","GET");

ActionScript, kurbanın browser'ından hedef URL'e Expect başlığı içinde kötücül HTML (Javascript) cümleleri barındıran bir request gönderir. Eğer hedef uygulama, zafiyeti barındıran bir Apache versiyonu üzerinde çalıştırılıyorsa, saldırı XSS ile sonuçlanır.

Flash 9:
Haziran 2006'da Flash 9 anons edildi (günümüzde 10 da mevcut). Flash 9'da yukarıda sözü edilen teknikler (LoadVars), ne herhangi browser-provided başlık için (Host, User-Agent ya da Referer gibi), ne de Content-Length gibi çoğu "korunan" başlıklar için işe yarıyor. Ancak yine de Expected gibi başlıklar gönderilerek bu açıklık exploit edilebilmekte.

Saldırı Tekniğinin Kısıtları:

• URL ve talebin gövde kısmı her zaman URL-encoded olmak zorunda. Bu yüzden SP, HT, CR ve LF (ve daha bir sürü) karakteri kaba halinde zorlamak mümkün değil.
• Sadece GET ve POST talepleri gönderilebilir.
• IE'de her başlığın sadece 1 olgusu gönderilebilir.

Flash Tabanlı RIA Testi (Türkçe)

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:

1. SWF dosyası, kaynak koduna decompile edilir (ActionScript) ve bilgi sızdırma gibi güvenlik denetimleri statik olarak analiz edilir (hard coded)
2. Kaynak koda erişmeden üçüncü parti uygulamalar denetlenir.
3. Kod içine gömülmüş (hard-coded) login credential'ları, IP adresleri vs analiz edilir.
4. 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ı:

1. 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.
2. 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.

–"\"([a-zA-Z0-9_]*)\"“ with filter as “service” (conventional)

.

–"destination id=\"([\\w\\d]*)\"“

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

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

ASP.NET Oracle Padding Vulnerability

Yazı, http://blogs.microsoft.co.il/blogs/linqed/archive/2010/09/19/padding-oracle-asp-net-vulnerability-explanation.aspx adresindeki açıklamalar üzerine bina edilmiştir.

"Padding Oracle" açıklığı, Eylül 2010 gibi bulundu.

Terimler:
Çok kabaca anlatılacak olursa, kriptolama (encryption) algoritmaları, data blokları (genelde her blokta 8 ya da 16 byte) üzerinde çalışırlar. Geri kalan bytelar ise "padded", yani doldurulmuş/şişirilmiştir. Mesela 5 harfli "ahmet" kelimesi, 8 byte'lık bir bloğa tamamlanmak üzere 3 byte ile doldurulur.

"Oracle", şifreleme (kriptolojide şifreleme, encription veya decryption işlemleri sırasında kullanılan algoritma olarak kullanılır) içinde bir mekanizmadır; verilen şifre metininin (cyphertext) geçerli olup olmadığı (valid or invalid) cevabını verme kabiliyetine sahiptir. Buradan şu tarife ulaşılabilir: "Padding Oracle" verilen şifre metininin dolduruluşunun geçerli olup olmadığı cevabını verme yeteneğine sahip bir mekanizmadır. Yani konunun Oracle veritabanı yönetim sistemi ile uzaktan yaqkından bir alakası yoktur.

Yine kabaca anatılacak olursa, basit geçerli/geçersiz cevabı, güvenlik araştırmacılarına, "CBC-Mode with PKSC#5 padding" (takılmayalım) ile encrypt edilmiş neredeyse tüm şifre metinlerini decrypt edebilecek bir algoritma oluşturma izni vermiştir; encryption kombinasyonlarını (passphrase) bilmedikleri halde. Bu durum, kaba kuvvet saldırılarına benzemektedir, ancak çok daha az deneme yaparak, dakikalar içinde çözüme ulaşılabilmektedir. Saldıran uygulama her seferinde şifre metininden 1 byte değiştirerek Oracle'a gönderir ve "geçerli mi" diye sorar, ta ki o byte decrypt edilene kadar.

Olayın boyutlarını görmek açısından şu video izlenmeli: http://www.youtube.com/watch?v=yghiC_U2RaM

Padding Oracle, ASP.NET ile nasıl ilişkili?
Şifreler (encrypt algoritmaları), .Net framework içinde gömülüdür; geçersiz bir doldurma (padding) işleminde "Padding is invalid and cannot be removed" mesajı ile birlikte "System.Security.Cryptography.CryptographicException" fırlatılır.

Kriptolanmış bir takım hassas veriyi cookie içinde saklayan bir uygulama düşünelim. Saldırgan, şifre metni içeren bu cookie'yi okuyabilir ve byte'ları ile oynayarak simüle ettiği talepleri, değiştirdiği cookie ile birlikte sunucuya gönderir. Sonra dönen yanıtları analiz eder ve hangi yanıtın "geçerli" hangisinin "geçersiz" anlamına geldiği kararını vermeye çalışır (Bu noktada saldırının ne olduğunun anlaşılmaya başlaması umulur).

Bu açıklık sadece ASP.NET'te mi var?
Tabi ki hayır. Bu açıklık ilk olarak JSF framework'ü üzerinde tespit edilmiştir. Ayrıca geçersiz şifrelerde exception fırlatan Java'da da bu açıklık vardır.

Saldırının Etkileri:
Bu açıklığı kullanarak saldırgan, ASP.NET tarafından istemciye gönderilen kriptolanmış tüm hassas veriyi çözebilir / decrypt edebilir: cookie'ler, ViewState, URL cümleleri, gizli alanlar vs. Daha sonra saldırgan, kriptolama (encryption) kombinasyonlarını (passphrase) bulabilir, kriptolanmış veriyi değiştirerek sunucuya gönderebilir. Mesela saldırgan, kendisini sisteme sistem yöneticisi gibi tanıtabilir.

Ayrıca, web.config dosyasının indirilebilme yeteneğini de düşünmek gerekir. TODO: Bunun nasıl olabileceği hakkında detaylı araştırma yapmakta fayda var. Acunetix de açıklığın bu yönü üzerinde durmuş.

Engelleme adına yapılabilecekler:
Herşeyden önce, hassas verileri istemci tarafında tutmamak (cookie, ViewState, gizli alan vs) şiddetle tavsiye edilir.

http://www.owasp.org/index.php/ASP.NET_POET_Vulnerability adresinde tavsiye edilen ve edilmeyen çözüm / engelleme yolları sıralanmış. Buna göre tavsiye edilen çözüm önerisi, Microsoft tarafından yayınlanan official yama: http://www.microsoft.com/technet/security/advisory/2416728.mspx

SSL/TLS Renegotiation Attack

Saldırının üst düzey etkisi, saldırgan kuralına uygun bir istemci-sunucu haberleşmesi içine bir network trafiği enjekte edebilmesi; TLS sunucunun da bu trafiği sanki istemciden geliyormuş gibi kabul etmesidir. Bu da saldırgana sunucu tarafında istemcinin credential bilgileriyle işlemler yürütmesine olanak tanır (Örn: istemci bilgileriyle pizza siparişi gibi). Ancak bu saldırıda saldırgan sunucudan dönecek yanıtı (response) göremeyecektir.

TLS Detayları:
Saldırı, TLS'in renegotiation (yeniden anlaşma) özelliğini kullanır. Bu özellik, aralarında zaten bir TLS bağlantı bulunan istemci ve sunucu arasında yeni parametreler, yeni anahtarlar vb ile yeniden anlaşma yapmasına olanak tanır. Yeniden anlaşma, var olan TLS bağlantısının içinde gerçekleşir.
Saldırının en basit şekli şu şekilde özetlenebilir:

Bir saldırıyı hayata geçirebilmek için saldırgan önce TLS sunucusuna bağlanır. Rasgele sayıda talep/yanıtlarla sunucuyla iletişim kurar. Tü bu trafik kriptoludur ve şekilde "==" ile ifade edilmektedir. Hazır olduğunda, saldırgan, kurbanın sunucu ile olan bağlantısını çalar (hijacking) ve sadece kriptolu kanalda seyreden kurban trafiğini proxy gibi üzerinden akıtır. Kurban, sunucu ile anlaşır ve bu noktadan sonra kurban ile sunucu doğrudan iletişim kurar. Dikkat edilecek nokta, kurban, saldırgan ile açık trafik üzerinden iletişim kurar ama ikinci el sıkışma kriptoludur ve saldırganın kanalı üzerinden yapılır. Bu durumda da kurban, sunucu ile "yeniden" anlaştığını bilmemektedir. Bununla birlikte, sunucu da ilk başta anlatılan saldırgan ile arasında iç trafiğin de kurbandan geldiğini düşünür.

Var olan uygulamalardaki etkisi:
TLS sadece bir güvenlik protokolüdür,bu saldırının etkisi TLS üzerinde koşulan uygulama protokolüne bağlıdır. Bu protokollerin en önemlisi tabi ki TLS üzerinden HTTP (HTTPS)'tir. Çoğu web uygulaması ilk kimlik doğrulamasını kullanıcı adı ve şifre çifti ile gerçekleştirir ve doğrulama durumunu HTTP cookie'ler ile devam ettirir. Bir saldırgan,  bu durumu, kendi özel isteğini anlatan bir HTTP request ön-parçası göndererek exploit edebilir. Sonra bu talep, istemcinin gerçek talebine ön ek olarak takılır.

Örnek:
Diyelim ki saldırgan, şu talep parçasını gönderiyor:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
X-Ignore-This:

ve son satırı, CR/LF (enter) koymadan boş bırakıyor. Sonra istemci kendi talebini gerçekleştiriyor:

GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
Cookie: victimscookie

ve bu iki talep birleşiyor:

GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
Cookie: victimscookie

Sonuç olarak saldırgan, siparişi için istemcinin hesabını kullanmış oluyor.

Benzer bir saldırı, sunucunun sertifika-tabanlı istemci kimlik doğrulaması kullandığı durumda da gerçekleştirilebilir: İstemci sertifikaları kullanan sunucular için istemcinin bağlanmasına ve bir kaynak talep etmesine izin vermesi ve eğer talep edilen kaynak korunuyorsa yeniden anlaşma (renegotiation) talep etmesi yaygın görülen bir durumdur. Saldırgan şu şekilde bu durumu exploit edebilir: önceden bir anlaşma (handshake) yapar; korunan kaynağı talep eder; yeniden anlaşma (renegotiation) işini de istemciye bırakır. Bu noktada sunucu, ilk talebin de istemciden geldiğini sanacaktır.

Önleme/Hafifletme:
Önlem, uygulamaların %99'undan fazlası için basittir: sunucu basitçe tüm yeniden anlaşmaları (renegotiation) disable eder; bu, saldırıları durduracaktır (OpenSSL, uygulama yeniden anlaşma için kurulmamışsa bile otomatik olarak yeniden anlaşır ve bu şekilde saldırının başarılı olmasında yardımcı olur). İstemci tarafında ise önlem almanın herhangi bir yolu yoktur. Tabi ki bu önlem, yeniden anlaşmanın zorunlu olduğu yaklaşımlar için uygulanabilir değildir.