Ders 7 - Cross Site Request Forgery (Low Level)
Bu yazıda DVWA adlı web uygulamasının içerisinde bulunan bir sayfanın güvenlik zafiyetinden faydalanarak Cross Site Request Forgery saldırısında bulunulacaktır.

Dersin Hedefi

DVWA'da oturum açmış kurbanın şifresini kurban fark etmeden değiştirin.

Cross Site Reqeust Forgery Nedir?

Cross-Site Request Forgery, yani sitelerarası talep sahtekarlığı saldırısı uzaktan bir form tag’ını kurbana submit’leştirmeye denir. Mesela saldırganın online bir bankacılık işlemi için kullanılan parametrelere sahip linki kurbana eposta yoluyla gönderdiğini varsayalım. Bu durumda kurban mail’i görüntülediği sıralarda ilgili bankaya ait siteye bağlı vaziyette ise istemeden bankanın bir form'unu submit’lemiş olur ve mesela saldırgana para transfer etmiş olur. Tüm bu süreci anlamlandırabileceğiniz örnek bir sonraki başlıkta bahsedilmiştir.

Cross Site Reqeust Forgery Nasıl Yapılır?

lk olarak bu dersin linkine dikkat edin:

http://localhost/dvwa/vulnerabilities/csrf/

Ardından ekrandaki metin kutularını doldurun:





Change butonu ile form'u submit'leştirdiğinizde linkin dönüştüğü son hale bakın:

http://localhost/dvwa/vulnerabilities/csrf/?password_new=deneme&password_conf=deneme&Change=Change#

Görüldüğü üzere DVWA'nın bu sayfası şifre değişikliğini "GET" methodu ile yapmaktadır. Bunu bilen saldırgan yukarıdaki linke bakarak şifre kısımlarına kendi belirlediği şifreleri koyabilir, ardından bu linki <img’nin içine gömüp bir eposta hazırlayabilir ve kurbana yollayabilir. Bunun üzerine kurban, saldırgandan gelen postayı görüntülediğinde eğer DVWA'da oturumu o sıralar açık vaziyette ise şifresini istemeden değiştirmiş olur. Hem de fark etmeden... Böylesi bir senaryoda saldırgan aşağıdaki gibi bir eposta içeriğini kurbana yollayabilir:



TEBRİKLER, 10$ KAZANDINIZ

Bravo size ^^



Yukarıdaki <img> tag'ına dikkat edin. <img> tag'ı resim linki almalıyken bunun yerine saldırganın emelleri doğrultusunda hazırlanmış bir link almıştır. Bu link kurbanın şifresini "deneme" olarak değiştirecektir. Aklınıza şöyle bir soru gelmiş olabilir: Neden <img> tag'ı kullanıldı? Bunun nedeni <img> tag'ının aldığı linke kullanıcıdan hiçbir müdahale istemeden otomatikmen talep gönderiyor oluşundandır. Yani düşünün: Bir web sitesinde siz resim görüntülerken genellikle "resmi görüntüle" gibi butonlara basmazsınız. Resim kendiliğinden görüntülenir. İşte bunun nedeni <img> tag'ının otomatik bir şekilde resmi sunucudan istiyor oluşundandır. Saldırgan <img> tag'ının bu otomatik talep gönderme özelliğinden faydalanarak resim linki yerine kendi saldırı linkini koymuştur. Böylelikle kurban epostayı görüntülendiğinde <img> tag'ı otomatikmen kendinde olan linke resim alabilmek için talepte bulunacaktır. Sonuçta bu bir resim linki olmadığı için cevap olarak resim gelmeyecektir. Fakat sonuçta talep yapılmış olacaktır. Yani sanki kurban, saldırganın gönderdiği linki tarayıcısının adres çubuğuna girip ENTER'lamış gibi olacaktır. Diğer bir ifadeyle sanki kurban DVWA'nın şifre değiştirme sayfasında yer alan formu eliyle submit'lemiş gibi olacaktır. Saldırgan kurbanın epostadan kuşkulanmaması için <img tag'ına genişlik ve yükseklik olarak 1 değerini koymuştur (width="1" height="1") Böylece <img> tag'ı resim alamadığında resim görüntülenemiyoru ifade etmek için göstereceği çarpı işaretinin görüntülenmesi engellenmiş olacaktır ve kurban hiçbir şeyden haberdar olamayacaktır.

DVWA'da oturumunuz açık vaziyette dursun ve yukarıdaki eposta içeriğini bir html dosyasına yapıştırın. Ardından html dosyasını tarayıcınızın yan sekmesinde görüntüleyin. Artık şifreniz değişmiş bulunmaktadır. Bunu görmek için DVWA'nın sol alt köşesindeki Logout butonuna tıklayın ve eski şifreniz ile giriş yapmayı deneyin. Giremeyeceksiniz. Epostada kullandığınız linkin parametresinde yer alan yeni şifre ile giriş yapabilirsiniz.

NOT: Saldırı esnasında bir eposta hizmeti fark ettiyseniz kullanılmadı. Bunun yerine eposta içeriğini biz kendi tarayıcımızda görüntüleyerek saldırıyı simule ettik. Bunun nedeni popüler eposta hizmeti veren servislerin bu tip saldırıları bertaraf ediyor oluşundandır.

Sonuç

Yukarıda bahsedilen yöntemle şifre değiştirmenin dışında daha etkili saldırılar da yapılabilir. Mesela bu yöntem para transferi için GET methodunu kullanan online bankacılık sitelerinde de kullanılabilir. img tag’ının içine yerleştirilen url’nin para ve transfer yap parametrelerine belli bir miktar para ve saldırganın kendi hesap bilgisi konularak kurbanın ruhu duymadan para transferi gerçekleştirilebilir. Fakat bankalar böyle açıklıklara artık sahip değiller. Üstelik email hizmeti sunan hotmail, gmail gibi servisler de <img> tagının böyle usülsüzce kullanımı konusunda önlemler almışlardır. Mesela gmail aldığı img tag’ını kendi sunucusunda değerlendiriyor ve img tag’ının resim üretmediğini tespit etiğinde img’nin src attribute’una kendi url’sini yerleştirerek eposta alıcısına postayı o şekilde sunuyor. Böylelikle kurban saldırıyı atlatmış oluyor. Bu sakıncalı URL’yi ziyaret eden Google sunucusu ise normal bir kullanıcı gibi sitelerde gezip oturum açmayacağı için gelen saldırıdan etkilenmiyor. Dolayısıyla img tag’ının bu kaydadeğer kullanımı popüler eposta servis sağlayıcıları için geçerli değildir. Ancak yeni yetme email servislerinde eğer önlem alınmamışsa kullanılabilir. CSRF saldırısı ile yapılabileceklere ilave örnek olarak kurbanın zafiyete sahip web uygulamasındaki hesabında yer alan eposta adresini değiştirme (böylece hesabı ele geçirmeye dönük şifre reset'lemeyi umma), kurban adına zafiyete sahip web uygulamasında absürt bir ileti gönderme (böylece kurbanı belki kötü bir duruma düşürme) gibi.

Bu gösterilen csrf saldırısı temel bir uygulamadır. Bu uygulamayı saldırganın çeşitli sayıda saldırı kodunu epostaya gömdüğü şekilde hayal edebilirsiniz. Yani bu eposta içerisinde csrf açığı olan birden fazla web uygulamasına (popüler teknoloji forumlarına, popüler oyun forumlarına, popüler portallere) dönük aksiyon aldırtma veya birden fazla aksiyon aldırtma kodları yer aldığı şeklinde. Bu şekilde birden fazla (örn; onlarca) <img etiketi ile saldırgan kurbanların bu siteleri kullanıyor olduğu varsayımından hareketle şansını arttırmayı deneyebilir.

Cross Site Request Forgery'den Korunma

Hassas bilgilerin iletileceği form'larda GET kullanımından kaçınılmalıdır. GET yerine POST kullanılmalıdır. Çünkü eğer kritik form'larda GET methodu kullanılırsa formu Submit'leme işlevi linklere de verilmiş olur ve böylelikle yukarıda anlatılanlardan gördüğünüz üzere Cross Site Request Forgery'nin önü açılmış olur. Kritik olmayan noktalarda (formlarda) GET methodu kullanılabilir. GET ile POST'un arasındaki farkı öğrenmek için şu yazımı okuyabilirsiniz.

Eğer GET kullanımı mecburiyse ve GET'in kullanılacağı form gerçekten de kritik bir işlem yürütüyorsa bu durumda CSRF saldırılarıyla kurbanların bu form'u fark etmeden submit'lemesinin (veya submit'lettirilmesinin) önüne geçmek için Cross Site Request Forgery Token (Siteler Arası Talep Sahtekarlığı Jetonu) kullanılmalıdır. Yani kısaca CSRF Token önlemi. CSRF Token, form alanlarına koyulan rastgele oluşturulmuş bir değerdir. GET metodunu kullanan form'larda form'un uzaktan (örneğin yan sekmelerden) submit'lettirilmesinin önüne geçmek için kullanılır.

Örneğin DVWA için konuşacak olursak dvwa'da csrf açığı olan nokta şu şekildeydi;


DVWA'da CSRF Saldırısı Yapılabilen Nokta:

New password:

Confirm new password:




Çıktı:



Form alındaki yeni şifre, yeni şifre onay kısımlarına ilave olarak ekstradan CSRF token değeri tutan bir alan eklenirse bu saldırının önüne geçilebilir. Yani uygulamadaki bu kod bloğu;


Uygulamadaki Talep Noktası (Güvensiz Hal):

New password:

Confirm new password:




aşağıdaki gibi düzenlenirse,


Uygulamadaki Talep Noktası (Güvenli Hal):

New password:

Confirm new password:




eposta yoluyla gönderilen zararlı postadaki <img etiketindeki link rastgele değerde oluşturulan csrf token parametresine sahip olmayacağından veya bu parametreye sahip olsa bile doğru değeri (sunucunun kabul ettiği değeri) tutturması oldukça güç olacağından kurban, postayı görüntülediğinde farkına varmadan talebi yapacaktır yine, ama, talebi alan sunucu talepteki csrf token değerinin yanlışlığını görerek talebi geçersiz sayacaktır ve işlemeyecektir. Böylece kurban isteği dışında ve fark etmeden bir form'u submit'lememiş olacaktır.

Ekstra

Piyasada Zimbra adıyla öne çıkan bir eposta servisi üzerinden csrf saldırısını uygulayalım ve bu eposta içeriğinin gerçekten işe yarayıp yaramadığını test edelim. Öncelikle (filtreleme mekanizmaları iyi çalışmayan) bu eposta servisiyle / uygulamasıyla zararlı kod içeren (Tebrikler 10$ kazandınız.... diyen içerekteki) epostayı oluşturalım. Not: Muhtemel odur ki eposta içeriğini saldırgan daha akıllıca süslemeyi deneyebilir. Böylece kurbanların epostaya tıklama ve görüntüleme dürtüleri üzerinden sonuca ulaşmayı deneyebilir.

Aşağıda örnek bir eposta servisi üzerinden eposta oluşturma ekranı gösterilmiştir.





Eposta servisinin eposta içeriği doldurma bölgesine metin nitelikte veri doldurma yerine html veri koyabilmek için eposta servisinin seçenek olarak sunduğu "Kaynak Kod" olanağından faydalanılır.





Daha sonra kaynak kod bölümüne zararlı kod gömülür.





Pencereye Tamam dendiğinde kaynak kod, eposta metin bölümüne gömülecektir ve görünüm olarak sadece html verinin oluşturduğu çıktı ekrana gelecektir. Gönder butonu ile eposta kurbana gönderilir.





Örneğin yine aynı filtreleme mekanizması iyi çalışmayan eposta servisiyle / uygulamasıyla kurban, epostayı almış olsun.





Kurban epostayı açmadan önce, burada saldırının işe yaraması noktasında bir başka gereksinime ihtiyaç vardır. O da kurbanın tarayıcıda eposta servisini görüntülerken yan sekmesinde Cross Site Request Forgery zafiyetine sahip web uygulamasını da barındırıyor olmasıdır. Burada örnek olarak DVWA uygulaması kullanılmaktadır.





Kurban epostayı açmadan önce yan sekmedeki Cross Site Request Forgery açığına sahip web uygulamasında surf'ünü dilediğince yaparken







veya başka yan sekmelerde takılırken bir süre sonra eposta servisinin olduğu sekmeye geldiğinde ve gelen zararlı postayı açtığında o sırada Cross Site Request Forgery zafiyetine sahip web uygulaması halen yanda açık olduğundan




1



2


saldırı gerçekleşir. Böylelikle kurban farkına dahi varmadan yan sekmedeki sitede bir işlem yapmış olacaktır. Burada csrf açığı olan web uygulaması ve bu açıklığı barındıran noktası gereği kurbana sadece şifre değiştirttik. O bilmese de... Eğer csrf açığı olan web uygulamasında başka csrf açıklığı barındıran noktalar da varsa o zaman yapılabileceklerin niceliği ve niteliği o kadar saldırgan nezdinde artacaktır.

Not:
Örnek olarak kullanılan eposta istemcisi resim içerikli postadaki resimlerin görüntülenmesini onaylıyor musun onaylamıyor musun tarzı bir vurguda bulunmaktadır. Bu bir önlemdir. Fakat yeterli değildir. Çünkü burada kullanıcıya bir anlamda CSRF saldırısını yiyip yememe seçimi sunulmaktadır. Bu riski, kullanıcıya sunmadan esasında eposta hizmetinin bazı filtrelemelerle minimize etmesi gerekirdi. Fakat filtreleme mekanizması iyi çalışmadığından risk olduğu gibi kullanıcılarına gitmektedir.


kurban, ekranında hiçbir hareket görmese de saldırıyı yemiş olur ve yanda açık olan Cross Site Request Forgery zafiyetine sahip web uygulamasındaki hesabı zararlı postada ne yap deniyorsa onu farkına varmadan yapmış olur. Bu DVWA uygulamasında biz kurbanın şifresini değiştirme form'unu uzaktan sessizce kendi belirlediğimiz şifre ile submit'ledik (yani submit'lettirdik). Fakat bu yolla yapılabilecekler Cross Site Request Forgery zafiyetine sahip web uygulamasının yetenekleri ölçüsünde arta da bilir azala da bilir. Bir uygulama ne kadar çok Cross Site Request Forgery zafiyetine sahip talep alma ve sunucuya gönderme noktası barındırıyorsa saldırgan o kadar çok şey yapabilir.

Saldırı sonrası kurban tekrar yan sekmedeki Cross Site Request Forgery zafiyetine sahip web uygulamasına (örn; bir forum olabilir bu) geçip halen sorunsuzca surf'ünü yapabilir.









Fakat Logout (çıkış) yaptığında, daha önce görüntülediği zararlı posta kurbanın zafiyete sahip web uygulamasındaki şifresini değiştirdiği için tekrar giriş yapamayacaktır.




Kurban CSRF açığına sahip web sitesindeki
hesabından çıkış yapar



Çıkış yapılmıştır.



Kurban belli bir süre sonra uygulamaya
tekrar giriş yapmak ister.




Görüldüğü üzere giriş başarısızdır. Çünkü daha önce görüntülediği zararlı eposta onun kullanmakta olduğu uygulamadaki hesabının şifresini değiştirmiştir.





Eposta içeriğine gömülen kodda şifre "deneme" olarak değiştirilsin denmişti. Bu nedenle şifre olarak "password" yerine saldırganın belirlediği "deneme" girildiğinde





oturum açılabilecektir. Böylece CSRF zafiyeti yoluyla kurbanlara sessiz sedasız aksiyon aldırtılabilir.

Yararlanılan Kaynak:

http://blog.10degres.net/dvwa-csrf/
Bu yazı 16.01.2016 tarihinde, saat 14:58:54'de yazılmıştır. 03.05.2019 tarihi ve 16:33:45 saatinde ise güncellenmiştir.
Yazar : Hasan Fatih ŞİMŞEK Görüntülenme Sayısı : 1605
Yorumlar
Yorum
Yani mail sunucularından göndersek manipule etmiş oluruz değil mi ? IMG tagı çalışır değil mi ?
Bu yorum 17.10.2016 tarihinde, saat 13:16:45'de gönderilmiştir.
Mehmet
Abi bu ders çok temel kalmış. :( Medium ve High level' da anlatır mısın?
Bu yorum 04.08.2018 tarihinde, saat 11:56:47'de gönderilmiştir.
Hasan Fatih ŞİMŞEK
Merhaba Mehmet, hevesini anlıyorum. Ancak haftaiçleri çalışmaktayım ve haftasonları da kafa tatili yapıyorum. Durum gerçi artık biraz değişti. Uzun bir aradan sonra artık haftaiçleri bir günümün belli bir vaktini bloga harcayacağım . O nedenle talep ettiğin makaleleri belki de öncelik sırasına alıp yayınlayabilirim. İyi çalışmalar.
Bu yorum 13.08.2018 tarihinde, saat 11:21:22'de gönderilmiştir.
Hasan Fatih ŞİMŞEK
Diğer arkadaş, mail sunucudan gönderdiğinde de başarılı olursun. Ancak popüler mail servisleri (hotmail,gmail,yahoo gibi) bu saldırıları berbataraf ettiğinden onlarda bu teknikle başarılı olamazsın. Burada anlatılan teknik bu saldırı türünün bir örneği ve yeni yetme mail servislerinde işe yaraması muhtemel.
Bu yorum 27.08.2018 tarihinde, saat 08:41:01'de gönderilmiştir.
Yorum Ekle
*
* (E-posta adresiniz yayınlanmayacaktır.)
*
*

#Arşiv


#Giriş

ID :
Şifre :