23 Ekim 2014 Perşembe

WEB ÇÖZÜMLERİ : Web Servislerindeki Zaafiyetler - Detaylı Anlatım

 

Web Servislerine yönelik uygulama düzeyindeki tehditler hakkında özetleyici bir konu.

Önsöz

 

Güvenlik, web servislerinin yaygın kullanımında, sınırılı bir etkiye sahip. Sonuç olarak, üzerinde durulan konu, çeşitli yüksek seviye güvenlik standartları ve protokolleri üzerine; ancak birçok durumda en basit uygulama düzeyli saldırılar ihmal ediliyor.

Bu konuda, saldırganların gözünden, web servislerinin doğasındaki düşük seviyeli zaafiyeleri keşfedeceğiz.

Web servislerinin XML e olan bağımlılığı bu dökümanın kapağını oluşturuyor. ayrıştırıcı (parsers) vedoğrulayıcı (validators) exploit lerini içeren XML tabanlı saldırılar ve son olarak bunlara karşı alınacak önlemler, tavsiyeler… Bu döküman özellikle geliştiricilere ve web uygulama mimarisine yöneliktir.


Giriş.
Service-oriented architecture (SOA) (servis tabanlı mimariler) kavramı, içeriden ya da halka açık bir şekilde olabilecek web servislerinin tanıtımıyla beraber, uygulamaların dağıtımında bir devrim geçirdi.

Web servisleri birçok sebepten popülerliğini artırmış durumda:


Birlikte çalışabilirlik: Servisler, herhangi bir framework e, herhangi bir dil kullanılarak, bağımsız bir programlama modeli kavramıyla yerleştirilebilir.

İyileştirme/Bakım: SOA, iyileştirme başlığı altında birçok fonksiyonel modüle sahip.

Tekrar Kullanım (Reuse): SOA, tamamıyla kullanılabilecek bir servis sağlayarak, farklı uygulamlar arasında kodun tekrar kullanımını teşvik eder.

Akıllı Boru (Smart pipe): Muhtemelen SOA nın en çok arzulanan özelliği, bir "akıllı boru" ya giriştir; Tek bir aramaya değer ekleyen bir aracı servisler dizisi.

Web servisleri sık sık arka uçlarla (backend) sarılmışlardır, ki bunlar çoklu katmanlarla geleneksel olarak korunmaya devam ediyorlar. Güvenlik sık sık bu katmanlarla sağlanır, ki çıkarılıp modülden web e ayrılmıştır ve uygulama mantığındaki çeşitli saldırılara açıktır.

Üstelik, XML in bir iletişim protokolü olarak tanıtılması web servislerini XML tabanlı saldırıların dünyasına açar.

FalseSecure

İspata yönelik amaçlar doğrultusunda, FalseSecure kullanıyor olacağız. Alttaki resimde sunulan mimari tasarıma sahip bir model uygulama...Bu uygulama iki mantıksal katmandan meydana geliyor: FalseSecure Client ve FalseSecure Server. Önceden bu iki katman, üç katmanlı bir web tabanlı mimarinin parçasıydı. Fakat (onların) servislerini iş ortaklarına ve diğer satıcılara sağlamaya yönelik ihtiyaçla birlikte, FalseSecure onların işletme mantığını bir web servisine aldı. Şuan FalseSecure Client ın tek amacı, Java Server sayfalarından (JSP) oluşan bir kullanıcı arayüzü sağlamak. Ki aynı zamanda kullanıcı girişini, FalseSecure web servisine yapılan çağrılara dönüştürmekte kullanılıyor.

FalseSecure, bir e-ticaret uygulamasıdır. Kullanıcı isterse bir ürüne ait alıntı isteyebilir. Ürüne ait herhangi bir işlem vs bunları XML formu üzeriden yapar. FalseSecure web servisi aşağıdaki hizmetleri sunar:

Kimlik doğrulama
Ürüne ait stok kontrolü
Ürün listeleri talebi
Ürüne ait fiyatlandırmalar
Siparişi verme
XML yığını isteme
Kredi kartı işlemleri
Oturum kapatma


Saldırılar

Birçok saldırı türü, HTTP üzerinden gerçekleşir. Temelde hepsi web uygulamasıdır. Aynı hizmeti sunan diğer meslektaşları gibi, benzer zaafiyetlere katlanmak zorundadılar. Web uygulama açıklarının tepesinde OWASP top 10 listesindeki gibi web servislerindeki uygulamalar vardır.


Web servislerinin framework lerinde bir SOAP isteğinin formu olarak XML dökümanlar client tan server a geçilir. Ardından XML web serviste işlenir ve XML tabanlı saldırılar dizisine açılmış olur.


WSDL Enumeration

Diger web uygulama saldirilarinda oldugu gibi bir web servisine yapilacak saldirinin ilk basamagi servis dagitiminin kesfi ve tanimlamasidir. Bu basamakta elde edilen bilgiler web servisine yapilacak saldirilarda buyuk rol oynar.

WSDL dosyasi, sadece web servisi tarafindan saglanan islevselligi degil, ayni zamanda da beklenen syntax'i, giris ve cikis noktalarini ve servise erisim yerini belirten web servislerinin bir dagitim tanimlayicisidir. Bir baska deyisle, web servisi kendi lokasyonunu, sagladigi yontemleri ve girdilere gore yaptigi varsayimlari dunyaya duyurur. Bu da kotu niyetli biri icin bir altin madeni gibidir.

Bu konuda bilgi sahibi bir kisi FalseSecure'nin taslagina bakinca asagidaki maddeleri cikartabilir:


1. Login metodu girdi olarak bir kullanici adi ve sifre gerektirir. Bu yuzden de bunun web servisi icin yetkilendirmede kullanildigindan emin olabiliriz. Yetkilendirmeyi asmak istersek bunu brute force, SQL Injection ya da daha sonra tartisacagimiz baska bir yontemle deneyebiliriz.
2. SessionId bu uygulamada butun metodlar icin bir parametredir. Boylece belki yetkilendirmeyi session hijacking ya da brute force ile bypass edebiliriz.
3. Servis etiketi web servisinin yerini bize soyler. Biz de bunu web servisine direk olarak erismek icin kullanacagiz.


Bircok web servis uygulamasinda WSDL dosyalari halka acik halde bulunur. Bir saldirgan asagidaki metodlari kullanarak bu dosyalara erisebilir:

- Servis URL'sinin sonuna ?WSDL ya da .WSDL eklemek bu dosyalari ortaya cikarabilir. Bizim ornegimizde asagidaki gibi bir URL dosyayi ortaya cikartti:

http://localhost:8080/FalseSecure/Fa...ureIFPort?WSDL

- Arama motorlari genellikle domain uzerindeki WSDL dosyalarini da indexler. Zekice hazirlanmis bir sorgu ile saldirgan bu dosyalara ulasabilir. Ornek olarak asagidaki dorklar kullanilabilir:


filetype:wsdl
index of "/wsdl"
inurl:wsdl
inurl:asmx


- "Universal Description, Discovery and Integration (UDDI) serverlari web servislerinin ve bunlarin WSDL dosyalarinin bir kaynagini tutar. Servis saglayicilari bazen kullanicilarin onlara erisebilmeleri icin kendi detaylarini UDDI'lere verir. Boylece hacklerlar da web servislerini tanimlayabilir ve bulabilir.


Koruma

1. UDDI 3.0.2 ya da uzeri surumlerde bulunan erisim kontrolu kullanarak WSDL'yi UDDI uzerinde erisime kapatin.


2. robots.txt kullanarak arama motorlarinin dosyalari indexlemesini engelleyin.


XML Ayristirisini Exploitlemek

XML yayinlari uygulama mantigi dahilinde bir noktada ayristirilirlar, ve saldirganin bu ayristirma mantigini kullanarak web servise girmeye calisacagindan emin olabilirsiniz. Bunun en acik ornegi, cok buyuk XML dosyalarini girdi olarak kullanip sunucu kaynaklarini ayristirma sirasinda tuketerek bir DOS saldirisi yapmaktir. FalseSecure web servisimiz girdi olarak bir XML yayini aliyor ve bu sekilde iletisimi sagliyor. Saldirgan buyuk bir dosya girdisi yaparak DoS saldirisinda bulunuyor:

Saldirgan daha sonra XML bilesenlerini kullanarak daha fazla islem yaptirip daha fazla yuklenebilir.

SAX tabanli ayristiricilar yukaridaki belirttigimiz DoS saldirisina duyarli degildir. Aradaki fark ise SAX tabanli ayristiricilar XML yayinlarini gerektigi zaman ayristirirlar. Boylece belirli bir zaman araliginda hafizada en fazla iki tane elementi tutarlar. Ancak bu tiplerde XML-Injection adi verilen baska bir yontem kullanilabilir.

Bir XML-Injection saldirisinda saldirgan yayinin uzerine yeniden yazarak XML yayinini manipule eder. FalseSecure ornegimizde bir kullanici kredi karti bilgilerini giriyor, ancak arkaplanda processCreditCardTransaction metodundan gecen XML yayini manipule edilmis.

Asagidaki ornekte kullanici alacagi televizyonun fiyatini 6.66 dolar olarak gorurken aslinda <total> elementi ile bu fiyat 4000 dolar olarak isleniyor.


Bircok kisinin dusundugunun aksine DOM tabanli ayristiricilar da XML-Injection'a karsi duyarlidir. Asagidaki XML yayinina bir goz atin. Ayristirma mantigina gore goreceksiniz ki ayni XML yayininin DOM tabanli versiyonu da benzer sekilde manipule edilebiliyor:

Savunma

1. Bazi saldiri tiplerini unutabileceginiz icin ozellestirilmis ayristiricilari uygulamayin. Test edilmis ve guvenli olan ayristiricilari kullanin.

2. DoS saldirilarina karsi korunmak icin mumkun oldugunca SAX tabanli ayristirma yontemini kullanin.

3. Eger DOM tabanli bir ayristirici kullanacaksaniz XML yayinini ayristirmadan once dogrulayin.

4. XML-Injection eksik girdi dogrulamasindan olusur. Bu yuzden her zaman herseyi dogrulayin.


XML Doğrulayıcıları Kötüye Kullanmak


XML akışları, uygulama tarafından kullanılmadan önce, kesin kurallara karşı doğrulanır. Verinin tamamnlanmış olduğundan emin olmak da bu doğrulamanın sebeplerindendir.
Böylece düşman, doğrulamayı aşmaya veya kırmaya çalıştığı zaman, uygulama mantığında umulmadık bir girişle karşılaşır.

Döküman Tip Tanımlaması (DTD), en çok kullanılan doğrulama metodlarından biridir. DTD şu şekilde oluşturulur:

1- Dahili : XML Dökümanı ile <!DOCTYPE TRANSACTION[...]>
2- Harici : Harici bir dosyayı referans göstererek <!DOCTYPE TRANSACTION SYSTEM "file">
3- İki Türlü : <!DOCTYPE TRANSACTION SYSTEM "file" [...]>


Her durumda da <!DOCTYPE> tagı XML dökümanda mevcut olandır.

DTD Entity Reference Attack olarak gösterilen benzer bir atakta da web servisteki sunucu hostinginde bulunan hassas dataların açığa çıkarılmasıyla işlem
gerçekleştirilir. XML emrini bir giriş olarak algılayan FalseSecure placeXMLOrder'ı dikkate alırsak eğer; aşağıdaki resimde bulunan XML emri şu çıktıyı verecektir.


"Thank you Bob Smith. Your order has been placed successfully."

Kötü niyetli kullanıcı isim ekosunun DTD'yi manipüle ederek, daha farklı bir şeyin ekosu olarak gösterilebileceğini farkeder.

"Thank you [contents of c:\\boot.ini on the remote server]. Your order has been placed successfully."

- Savunma -

1- XML Schema Definiton (XSD)yi kullanarak XML akışları doğrulayın. XSDler XML döküman ile birlikte tanımlanmazlar, bu yüzden kullanıcı tarafından değiştirilemezler.

2- Eğer DTD'yi kullanmak zorundaysanız, kullanıcının XML dökümanın prolog bölümüne tedarik yapmasına izin vermeyin. Ayrıca XML ayrıştırma ve doğrulamadan önce,
tüm kötü niyetli karakterler için tüm girişleri doğruladığınızdan emin olun.


Hata İşleme

Hata mesajları bir saldırgan için altın madeni niteliğindedir. Çünkü, uygulama içersindeki hassas verileri sıklıkla açığa vururlar. Açığa çıkan bu bilgiler saldırgana özel uygulama mantığına yönelik bir saldırı gerçekleştirmesi için yeterince bilgi sağlamış olur. Başarılı bir saldırı için hata mesajlarının toplanması en başta gelir.

Web hizmetleriyle, uygulama mantığında bulunan özel durumlar SOAP motorunda tespit edilir ve istemciye cevaben SOAP hata unsuru olarak gösterilir. Örneğin; aşağıdaki mesaj FalseSecure şifre olarak giriş metoduna tek bir tırnakla yanıttır (genel bir SQL inj)

Web hizmetleri genellikle web uygulamalarından çok daha hassas bilgileri ortaya çıkarmaya yöneliktir. Bir çok web hizmeti, kamuyuna açılan arka plandaki sistemlerce sarılmıştır. Bunlar çevresindeki katmanlarda uygulanan önemli bir nokta olan hata işlemeden yoksundurlar. Ortak bir kod inceleme uygulaması, uygulamanın girdiği noktadan başlamaktadır yani sunucu sayfasından ve istisna oluşturabilecek herhangi bir yöntem sağlamak için hata işleme mantığı ile çevrilirler böylelikle sadece genel mesajlar son kullanıcıya gösterilir. Bu durumlarda; sunucu sayfasını kaldırdığınızda bununla birlikte hata işlemeyi de kaldırmış olursunuz.

Savunma

1. Tüm istisnaların gözden kaçmamasını ve genel hata mesajlarının SOAP ile döndürülmesini sağlayın.

2. Bazı SOAP motorları hata unsurlarını da dahil olmak üzere istisnai detayları saklamak için yeterince yapılandırılabilir durumdadırlar. Axis içersindeki örneğin server-config.wsdd dosyasındaki axis.development.system parametresi, sunucuya gönderilmeden önce hata dizinine çıkarılıp çıkarılmadığını göstermektedir. Bu değer üretim sistemi için false olarak ayarlanmalıdır.

XPath Enjeksiyonu

XML belgeleri genellikle veri depoları olarak kabul edilir ve onları işleyen ve kullanan web hizmetleri tarafından sorgulanırlar.SQL geleneksel ilişkisel veritabanı olarak kullanıldığı gibi, XPath ise XML belgelerini sorgulamak için kullanılır. XPath, SQL gibi sunucudaki isteğe bağlı sorguların çalıştırılmasına yol açabilen enjeksiyonlara karşı duyarlıdır.


Dinamik olarak kullanıcı girişi ile birleştirilen XPath sorguları geliştiricisinin niyetinde olmayan bir şekilde kullanıcı tarafından değiştirilebilir. FalseSecure web hizmetleri giriş yönteminde kullanılabilen aşağıdaki XPath sorgusu inceleyebilirsiniz, kalın yazılmış değerler kullanıcı girişinin nerede olduğunu gösterir:


//users/custid/[123]

Bir kullanıcı tüm kullanıcılara dönmek için XPath tablosunda değişiklik yaparak kimlik doğrulamayı atlama girişiminde bulunabilir.

//user/custid[./age > 1]

Savunma

XPath enjeksiyonu kullanıcı girişi doğrulama eksikliğinden kaynaklanmaktadır. Doğrulayın! Doğrulayın! Doğrulayın!

SONUÇ

Bu WS-Security gibi güvenlik standartları, güvenli web hizmetleri uygulanması için çok önemlidir. Ancak bir sistem en zayıf halkası kadar güvenlidir ve çoğu web hizmeti uygulamalarında, bu en zayıf halka uygulama mantığıdır.


OWASP kılavuzda yayınlanan dünyanın en büyük uygulama düzeyinde güvenlik açıklarından başka web hizmetleri de bu yazıda ele alınan çeşitli XML tabanlı saldırılara karşı hassastır. Ayrıca, WSDL dosyasının kamunun aydınlatılması ile çok daha kolay bir plan sağlayarak sistem saldırganın işi kolaylaştırır.

SAVAŞ KIRÇOVALI

ÖZEL BÜRO HACK TİMİ

[publicize twitter]

[publicize facebook]

[category teknoloji]

[tags WEB ÇÖZÜMLERİ, Web Servisleri, Zaafiyetler, Detaylı Anlatım]

Hiç yorum yok:

Yorum Gönder

Hakkımızda

Fotoğrafım
BU BLOG ÖZEL BÜRO GRUBU'NA AİTTİR. RESMİ WEB SİTEMİZ : http://www.ozelburoistihbarat.com

ÖZEL BÜRO İSTİHBARAT GRUBU