Alışılmış phishing yöntemlerinde phishingi yapan kişi; bir bankanın, sosyal ağın, ihale sitesinin ya da ödeme işlemleri için kullanılan sitelerin taklidini yaparak kurbanlarını avlar. Kullanıcılara karşı yapılan bu girişimde hacker, e-posta ya da anlık mesajlaşma servisleri aracılığıyla zararlı web sitesine ait bir link gönderir. Ama Mozilla Firefox ve Google Chrome gibi gelişmiş tarayıcılar, bu tür phishing saldırılarını tespit etmede oldukça iyiler. Açılan sitenin phishing amaçlı oluşturulduğunu kullanıcılarına anında bildirirler.

Hackerlar ise web tarayıcılarda yer alan bu anti-phishing korumalarına karşılık yeni bir yöntem geliştirdiler. E-postaya HTML ataçlama yaparak bu yöntem işliyor. Bu yöntemle phishing sitesine ait HTTP GET istekleri önlenmiş oluyor. Böylece tarayıcının siteyi bloklaması engelinden kurtulmuş olunuyor.

Bilgisayara indirilen ve orada tutulan HTML ataçı, tarayıcıda uyarı verilmeden rahatlıkla açılabiliyor.

Kurban, bilgilerini yazıp “Agree and Submit” butonuna tıkladığında, açılmış olan HTML form, çalınan bilgileri POST isteğiyle; hacklenmiş ancak önceden yasal veya resmi yani güvenli olarak bilinen web serverlarındaki PHP scripte gönderiyor. (Bu konudaki güvenli olarak düşündüğümüz site Fritolay.com)

Genellikle çalınan bilgiler, hacklenmiş web serverındaki PHP dosyasına gönderilir. (Not: Yukarıdaki resimde adresi blurlanan php dosyası sonradan incelenerek zararlı olduğundan dolayı silinmiş.)

Hackerın php scripti, kurban tarafından bilgilerin girilip onaylanmasının ardından kurbanımızı Paypal’ın ana sayfasına yönlendiriyor. Çalınan bilgiler, hackerın ilgili serverına POST isteği şeklinde gönderilirken Google Chrome ve Mozilla Firefox herhangi bir zararlı aktivite tespit edememiş. Bazı anti phishing programları da aynı şekilde hiçbir uyarı veremedi. Yani bu yöntem oldukça etkili. Mantıken tarayıcıların POST isteği gönderilen bağlantıyı tespit etmesi gereklidir. Peki neden bu phishing tekniğinin tespit edilmesi zordur. İşte nedenleri:

1. Zararlı olarak raporlanan PHP bağlantıların sayısı azdır. Çünkü sıradan kullanıcılar herhangi bir bağlantıyı rapor edemezler. Çünkü ilgili phishing bağlantısı, HTML kaynak kodu görüntüleyebilecek kadar teknik bilgiye sahip olan kullanıcılar hariç, diğer kullanıcılar için görülebilir değildir.

2. Bağlantıları phishing bağlantısı olarak kesin şekilde damgalamak zordur. Eğer bu bağlantıya eşlik eden HTML form yoksa, phishing sitesinin tespit edilmesi imkansız hale geliyor. Çünkü PHP scriptler server üzerinde çalışır ve onay butonuna tıklandıktan sonra herhangi bir HTML dosyası görüntülenmez.

Son aylarda bu tür phishing olaylarının arttığı görülmüştür. Bu yüzden e-postanızdaki HTML ataçlara karşı dikkatli olmalısınız. Eğer e-posta adresi şüpheli olarak görülüyorsa HTML dosyasını açmayın. Eğer açarsanız HTML formuna önemli bilgilerinizi yazarken uyanık olun.

Kaynak: http://labs.m86security.com/2011/03/phishing-scam-in-an-html-attachment/

Çeviri: Serdar BARAKLI

Giriş

Cross Site Reference Forgery (XSRF), bir eylemi gerçekleştirmek için web tabanlı uygulamaları tahmin edilebilir yapı içinde etkileyebilecek bir saldırı türüdür. Bu saldırının ismi farklı şekillerde kısaltılabilmektedir ama en genel kullanımı XSRF şeklinde olup CSRF ile aynı anlama gelmektedir. XSRF saldırıları, aynı zamanda “Saldırgan Linkleme” saldırıları olarak da bilinmektedir. CSRF ismi, Peter Watkins (peterw@usa.net) tarafından 2001 Haziran ayında verilmiştir. XSRF saldırılarına karşı hassas olan uygulamaların, XSRF kusuruna sahip olabileceği veya XSRF’ye karşı kusurlu duruma gelebileceği söylenilmektedir.

XSRF kusurları; kullanıcıları denetlemek için çerezleri, tarayıcı denetlemelerini ve istemci tarafı sertifikalarını kullanan ve önceden tahmin edilebilir eylem yapısına sahip olan web uygulamalarında oluşmaktadır. XSRF’deki ana fikir çok basittir; saldırgan, bir linkle veya başka bir içerikle hedef uygulama üzerinde, saldırganın seçimiyle, kurbanın eylemlerini yöneten bir başka eylemi gerçekleştirerek kullanıcıyı aldatır. Bu, HTTP GET örneği üzerinde anlamak için en kolay tanımdır.

Örneğin;

http://www.google.com/search?q=iSEC+Partners

Bu linke tıklanılması halinde Google’da “iSEC Partners” olarak arama yapılmaktadır. Bu zararsızdır.

http://www.isecpartners.com/EditProfile?action=set&key=emailAddress&value=evil@isecpartners.com

Fakat link yukarıdakine benzer bir şekilde olursa; sadece çerez, tarayıcı denetlenmesi veya sertifikasıyla ispatlanmış kullanıcılara, herhangi bir uygulama üzerinden başka kullanıcının profilini düzenlemeye veya e-posta adresini değiştirmeye izin verecektir.

Linkler, kolay bir şekilde gizlenebilir; bu yüzden başka bir yere yönlenebileceği görülmektedir ve kelimeleri gizlemek, onların gerçek fonksiyonlarını açığa çıkarabilmektedir. XSRF saldırıları; eylemlerini gerçekleştirebilmek için HTTP GET ya da HTTP POST kullanan uygulamaları etkiler.

XSRF Uygulamasına Örnek — Goat Chat

Goat Chat, kullanıcılar arasında mesajlaşmayı sağlayan kuramsal web uygulamasıdır. Goat Chat; kullanıcıların isim ve şifrelerini içermeyen ve daha uzak istekleri denetlemek için kullanıcılar tarafından kullanılan, geniş ve tahmin edilemeyen oturum ID çerezi oluşturur. Goat Chat’in özeliklerinden birisi; diğer bütün linkleri içeren text mesajları gönderebilmesidir. Goat Chat kuramsal olarak https://goatchat.isecpartners.com/ adresinde görülmektedir ve mesajları, delilleri ve oturum tanıtıcılarının sırrını ağ dinleyicilerinden korumak için HTTPS yi kullanır. Bu uygulama, etkin cross site scripting filtreleri içermektedir ve HTML içerik engellemesine sahiptir.

Goat Chat aşağıdaki kullanıcı eylemlerini destekler:

- Oturum Açma(Login)

- Mesaj Gönderme

- Yeni Mesajları Denetleme

- Oturumu Kapatma(Logout)

“Gelen Mesajlar” çerçevesi, oturumu açmış olan kullanıcılara görünür. Bu çerçeve Javascript kullanır ya da “Check for new messages” eylemini gerçekleştirmek için her 10 saniyede kullanıcıların yan tarafında etiket yenilenir. Yeni mesajlar bu çerçevede görüntülenir ve gönderenin ismi ile mesajın metnini içerir. Metin, HTTP veya HTTPS urlsi içeriyorsa otomatik olarak linke dönüştürülmektedir. “Send a message” eylemi 2 parametre içermektedir; Mesajın varış yeri(Kullanıcı ismi) ve kısa karakter dizisi içeren metnin kendisi. “Logout” eylemi ise hiçbir parametreyi gerektirmemektedir.

Uygulamanın XSRF’ye hassas olup olmadığını belirlemek için, “Send a message” eylemine bakmamız gerekmektedir. Bunu yapacağımız zaman; gönderilen mesajlara sunulan aşağıdaki basit HTML formunu buluruz:

<form action=”GoatChatMessageSender” method=”GET”>
Send To:<br>
<INPUT type=”radio” name=”Destination” value=”Bob”>Bob<BR>
<INPUT type=”radio” name=”Destination” value=”Alice”>Alice<BR>
<INPUT type=”radio” name=”Destination” value=”Malory”>Malory<BR>
<INPUT type=”radio” name=”Destination” value=”All”>All<BR>
Message: <input type=”text” name=”message” value=”" \>
<br><input type=”submit” name=”Send” value=”Send Message” \>
</form>

Şekil 1: Mesaj Gönderme Formu(Yukarıda)

Burada da çerçevenin neye benzediği:

Şekil 2: Şekil 1’in Sunumu(Yukarıda)

Bu forma bakarak, kullanıcıların Hi Alice metnini içeren bir mesajı Alice’e göndermek istediklerinde, Send Messaga’a tıkladıklarında aşağıdaki URL’nin çekileceğini anlayabiliyoruz.

https://goatchat.isecpartners.com/GoatChatMessageSender?Destination=Alice&message=Hi+Alice&Send=Send+Message

URL 1: Alice’e “Hi Alice” metnini içeren mesajı gönderen URL

Kullanıcı, URL 1 için bir HTTP GET gerçekleştireceği zaman; tarayıcı goatchat.isecpartners.com sitesi için uygun çerezleri içerir. Oturum açmış kullanıcıya çerezin gönderilebilmesi için gereken tek şey; sadece bir istek yapmak. Saldırganlar bunu uygulayabilirler.

Eğer oturumu açmış olan kullanıcı; hackerlar tarafından üçüncü parti başka bir siteye ziyaret ettirilmişse, kullanıcının yönlendirildiği bu site aşağıdaki görüntü etiketini içermiştir. URL 1, kurbanın tarayıcısı tarafından çekilmişse ve uygulama serverı tarafından çalıştırılmışsa; sanki kullanıcı Alice’e “Hi Alice” metnini içeren bir mesaj göndermiş gibi olacaktır.

<img src = “https://goatchat.isecpartners.com/GoatChatMessageSender?Destination=Alice&message=Hi+Alice&Send=Send+Message” \>

Şekil 3: Kullanıcının URL 1’i ziyaret etmesine neden olan HTML

Saldırgan, bir linki alternatif olarak bir e-postayla ya da anlık mesajlaşma servisleri yardımıyla kullanıcıya gönderebilirdi. Saldırgan, bu linki http://tinurl.com/ benzeri bir site ile gizleyebilir ve ardından kurbanı hedef siteye yönlendirebilir. Birçok site; kurbanları herhangi bir web sayfasına yönlendirmek için kullanılan sayfalara sahiptir. Bu parametreler, sıkça URL şifreleme veya diğer hile yollarıyla oluşturulmaktadır.

Eğer GET yerine POST metodu kullanılsaydı, link tarafından yapılan uygulama değişiklik gösterecekti. Saldırgan, kendi kontrolünde olan bir siteye kurbanı yönlendirecek bir linki kurbana gönderebilir ki bu site; hedef siteyi gösteren bazı içeriklere sahip olabilir. Bu form, ya otomatik olarak ECMAScript ile ya da kullanıcı ona tıkladığında onaylanır. Daha çok varyasyonlar; çok aşamalı formlarla mümkün olabilir.

Şekil 4 örneği ise, kullanıcının eski şifresini girmeden onun parolasını değiştirmeye izin veren bir formdur. Bu örnekte hedef servlet(*) HTTP Post talep etmektedir ve saldırgan; tüm gereksinimlerin yerine getirilebilmesi için kendiliğinden onaylanabilir bir form oluşturabilir. Şunu bilmemiz gerekir ki; bu exploit Şekil 3teki gibi image tabanlı istekler kadar garanti bir yöntem olmayabilir. Kullanıcının tarayıcısı(veya bu exploiti içeren frameler) hedeflenen siteye yönlendirilir. Tarayıcı scripting’i pasif hale getirilmiş kullanıcılar, bu tür saldırılardan etkilenmeyeceklerdir. Ve tabiî ki de bu kullanıcının tarayıcısına ve konfigürasyonuna bağlıdır.

(*)Dinamik içerik üreten bir Java Web bileşenidir.

<HTML><BODY>
<form method=”POST” id=”evil” name=”evil” action=”https://www.isecpartners.com/VictimApp/PasswordChange”>
<input type=hidden name=”newpass” value=”badguy”>
</form>
<script>document.evil.submit()</script>
</BODY></HTML>

Şekil 4: Gizli form tabanlı exploit

Hatta eğer scripting’i pasif hale getirilmiş olsa bile, “Close This Window” linkleri bile aslında saldırganın isteği doğrultusunda kullanıcıyı kandırmaya yönelik bir buton olabilir.

Görünür ve Gizli XSRF

Benzer bir şekilde XSS ve XSRF zayıflıkları iki büyük kategoriye ayrılırlar. Gizli ve Görünür.

Gizli XSRF zayıflıkları, saldırganın kurbana exploit linkleri gönderdiği uygulamaları kullanabildiği yerlerde veya kurbanın tarayıcısını uygulamaya yönlendiren; böylece kurban yaparmış gibi çalıştırılan ama saldırganın kontrolüne teslim olan içeriklerde görülebilir.

Görünür XSRF zayıflıklarında ise saldırgan; kurbanı exploit linki veya başka bir içerikle karşı karşıya getirmek için sistem dışında bir uygulama kullanır. Bu, bir blogu kullanarak, e-posta mesajlarında, anlık mesajlaşmada, mesaj panosuna post atma gibi şeylerde olabilir. Görünür XSRF açıkları genelde başarısızlıkla sonuçlanır. Exploit denenmeye çalışıldığında, saldırga-nın o sistemin kullanıcısı olarak oraya girme ihtimali düşüktür. Yapılan görünür XSRF ataklarından geriye kalan belirtiler, saldırganın kontrolü altındadır. Exploit tamamlandıktan sonra bu tür belirtiler saldırgan tarafından silinebilir.

Basit Exploitleme Senaryoları

Bazı uygulamalar, XSRF ataklarına karşı diğerlerinden daha zayıf olabilir. Kuşkusuz ki gizli XSRF zayıflıklarına sahip bir uygulama, kesin bir şekilde exploit edilebilir.

Bir çok uygulama HTTP GET çağrılarını, HTTP POST için de yetkili olan aynı kişiye yönlendirir. Servlette(Dinamik içerik üreten bir Java Web bileşeni) örneğin doGet metodu basit bir şekilde doPost metodunu çağırır ve parametreleri böyle yönlendirir. Bu, image veya link tabanlı exploitleri daha kolay kılar ve XSRF açıklarının exploitlenmesini kolaylaştırır.

Bazı uygulamalar; özellikle intranet(*) siteleri, bağlantı ve erişim noktalarındaki yönetim konsolları ve diğer ağ araçları, entegre tarayıcı onaylamasını kullanırlar. Bu tip izinler geçerliliğini yitirmez ve bu yeterlilik belgeleri tarayıcı kapatılana kadar devamlılığını sürdürür. Tüm gün tarayıcısını kullanmak zorunda olanlar için bu süre çok uzundur. Bu tür bir kullanımda, görünür XSRF ataklarının etkinliği daha da artacaktır.

(*) http://tr.wikipedia.org/wiki/İntranet

Birçok uygulama, kullanıcıların o siteye yeniden döndüklerinde bir daha onay belgesini almayı gerektirmeyecek şekilde bir cookie uygulamasına sahiptir. Uzun sessionlar, kullanıcıların XSRF ataklarıyla karşı karşıya bırakabilir.

Bazı uygulamalar ise kullanıcılarına, eski şifreyi yazmadan şifrelerini değiştirme imkanı tanırlar. Eğer bu şifre değiştirme mekanizmaları XSRF’ye karşı zayıfsa, yeniden saldırganlara karşı bir hedef haline gelecektir.

XSRF ve XSS Arasındaki Fark

XSRF ve XSS ki özellikle de görünür XSS, güvenlik risklerinin olduğunu gösterir ve ikisi arasındaki benzerlik bazen kafa karıştırabilir. Bir çok kişi, XSS veya XSRF açıklarını deneyerek bulabilir. Tespit ettiğimiz güvenlik açığının kapanmasındaki yöntemler, aradaki ayrımı daha kolay yapmamızı sağlayacaktır. XSS açıklarına bakarsak saldırgan, girdi veya çıktı filtreleme eksikliğini exploit eder.  Eğer uygulamadaki <, >, “, ‘, &, ;, veya # gibi zararlı karakterler filtrelenirse açık kapanabilir. Tabii ki sadece XSS açığı. XSRF ise biraz da uygulamanın yapısının tahmin edilebilirliğine bağlıdır. XSS ise, uygulamanın gerçekleştirdiği yetersiz veri onaylaması ile alakalıdır.

XSS açıkları, XSRF’ye karşı alınan güvenlik açıklarına karşı bypass yapmaya izin verebilir. Bundan dolayı XSS açıklarının çözümlenmesinde XSRF açıklarına da göz atılmalıdır.

XSRF Hakkında Yanlış Bilinenler

Yanlış: XSRF, XSS’nin özelleşmiş halidir.

Doğru: XSRF, çözüm yollarının farklılığı ile XSS’den ayrılan bir güvenlik açığıdır. XSS açığını çözmek daha önemli ve öncelikli olmasına rağmen, XSS’ye karşı alınan güvenlik önlemleri XSRF ataklarını durduramayacaktır.

Yanlış: İşlem gerçekleştirmek için çok sayfalı formlar kullanılırsa, o uygulama XSRF açıklarına karşı zayıf olmaz.

Doğru: Çok sayfalı formaların kullanılması exploitlemeyi daha zorlu kılsa bile, saldırganlar genellikle onları exploitleyebilirler.

Yanlış: HTTP POST kullanan uygulamalar XSRF’ ye karşı sağlamdır.

Doğru: POSTlar exploit edilmesi zor olmasına rağmen, kesinlikle exploit edilebilirler.

Yanlış: XSRF atakları kullanıcı hatalarıdır.

Doğru: Kullanıcılar, XSRF exploitleri için genellikle kusurlu değillerdir. Uygulamalar, web sitenin sorumluluğunu alan kişi tarafından daha güvenli tasarlanmalıdır.

Yanlış: XSRF açıkları düşük risklidir.

Doğru: XSRF açıkları sayesinde saldırgan, izin verilmiş bir kullanıcının gerçekleştirdiği eylemleri kolaylıkla gerçekleştirebilir! Bu şifre değiştirme, ticari bir mal satın alma veya para transferi olabilir.

Yanlış: Benim güvenlik duvarım/ SSL server/ .NET beni XSRF‘den korur.

Doğru: Eğer uygulamanızı özel olarak XSRF’ye karşı koruma konusunda çaba sarf etmiyorsanız, hemen hemen XSRF’ye karşı savunmasızsınız.

Cross Site Reference Forgery

Kaynak: http://www.isecpartners.com/documents/XSRF_Paper.pdf

Çeviri: Serdar BARAKLI

Uygulamalarınızı Cross-Site Request Forgery(CSRF) karşı sağlamlaştırmak, hiçbir zaman kolay olmamıştır. Bir program sizi bu işten kurtarırken, niye web sitenizde her formu yeniden yazıyorsunuz?

Basit bir şekilde aşağıdaki satırı, her PHP dosyasının en üstüne yazın;

require_once ’/path/to/csrf-magic.php’;

ve rahatınıza bakın.

Download: http://csrf.htmlpurifier.org/releases/csrf-magic-1.0.0.tar.gz

Deneme: http://csrf.htmlpurifier.org/dev/test.php

CSRF Nedir?

Cross-Site Request Forgery (CSRF), web sitelerinde şu günlerde görülen, nispeten yeni bir saldırı türüdür. Bir web sitesi üzerinde tarayıcı sayesinde bir eylemi gerçekleştirme üzerine kurulu bir saldırıdır. Şimdi şu senaryoyu düşünün: Bob, büyük ve önemli bir şirkette, sadece bir butona tıklamasıyla işe alma ve işten çıkarma yetkisine sahip olan bir insan kaynakları müdürü. Mallory pratik bir şaka olarak Bob’a CSRF saldırısı yapmaya karar verir. Mallory, hire and fire(işten alıp çıkarma) web sitesine otomatik olarak form gönderen bir web sitesi kullanarak Bob’u kandırır. Ertesi sabah, tüm çalışanlar gelen kutusunda pembe slip bulurlar.

Neden CSRF-Magic?

CSRF önleme için bulunan güncel standartlar, bir “şimdiki zaman” oluşturmaktadır. Bu oldukça etkili olabilir; ama çok can sıkıcı bir iştir. Eğer uygulamalarınıza girebilmek için formlarınızı el ile yazıyorsanız, CSRF koruması etkisini tam gösteremeyebilecektir.

İşte burada csrf-magic devreye girmektedir. Csrf-magic, mekanik olarak dökümanınızda, formları ve scriptleri yeniden yazmak için PHP’nin output buffering yeteneğini kullanır. Aynı zamanda POST isteklerini de engelleyecektir. Bu; formlarla beraber normal bir web sitesi için, csrf-magic’i kurup gerisini düşünmemeniz anlamına gelir.

Kaynak: http://csrf.htmlpurifier.org/

Çeviri: Serdar BARAKLI