Fiyakalı Bir CSP Bypass'ı, Phishing Sitelerini CT ile Tespit Edin, SSL ile WAF Bypass'ı

Fiyakalı Bir Content-Security-Policy (CSP) By-Pass'ı

Gün geçmiyor ki yeni bir Content Security Policy (CSP) by-pass yöntemi yayınlanmamış olsun. Ama bu defaki gerçekten etkileyici.

CSP; Cross-Site Scripting (XSS), Protocol Downgrading, Clickjacking vb. zafiyetlere karşı browserda ekstra bir güvenlik katmanı sağlar.

Yükte hafif olan CSP, pahada oldukça ağırdır. Kullandığınızda hayat kurtarır. Kullanılmadığı takdirde de XSS gibi zafiyetlerin varlığında son kale de düşürülmüş olur. Tüm modern tarayıcılar tarafından desteklenen CSP 'yi HTTP yanıt headerı olarak yahut belirli kısıtlar ile beraber meta tagları vasıtası ile set ederek devreye alabilirsiniz.

CSP kullanarak hangi kaynaktan script, stil dosyası, image vs. nesneler yükleneceğini bu güvenilir kaynakları whitelist ederek sınırlandırabiliriz. Yani hangi kaynaklardan yükleneceğini spesifik olarak belirtip, diğer tüm kaynaklardan yükleme işleminin iptal edilmesini sağlayabiliriz.

Peki hangi tür içerikler bu kaynakları yükleme kabiliyetine sahiptir? Elbette geçerli HTML sayfaları. Çünkü ancak bu sayfalar vasıtası ile yine bu sayfalarda bulunan HTML elemanları için istek yapılıp, kaynaklar yüklenebilir.

Hâl böyle olunca HTML tipinde sayfaların yanıt headerlarına CSP talimatlarını ekler; image gibi, Javascript dosyası gibi dosyalara CSP headerı eklemenin yersiz olduğunu düşünürdük. 

Fakat Wallarm Resarch'de yayınlanan bir araştırmaya göre işler sanılandan daha karmaşık.

Modern tarayıcılarda, bir imaj dosyasını doğrudan tarayıcı ile açmaya çalıştığınızda, sadece resmi görüntülemekle kalmaz. Bu resmi daha iyi göstermek için bir dizi yöntem uygulanır. Açılan resmi ortalayarak dekore etmek de bu yöntemlerden biridir.

Peki bunu nasıl yapıyor?

Tabii ki aslında resmi, kendisini çerçeveleyen bir HTML sayfası içerisinde <img> tagları ile yükleyerek:

Böylece pasif olarak addettiğimiz resim URL'i aslında resmi yükleyen bir HTML sayfasına sahip olur. Şimdi imajlara CSP set etmemek gerektiği konusundaki yargımızı bir kez daha gözden geçirebiliriz...

Bir örnek ile devam edelim. Saldırgan aşağıdaki gibi bir kod ile sayfaya bir iframe ekleyerek, iframe kaynağı olarak one.bmp isimli dosyayı gösterdiğini varsayalım:

frame=document.createElement("iframe");
frame.src="/one.bmp";
document.body.appendChild(frame);

Iframe içerisinde görüntülenen kaynak bir HTML kaynağına dönüştüğü için şimdi bu HTML kaynağına her türlü elemanı ekleyebiliriz.

Eklemek mi? Evet.

Same Origin Policy'nin (SOP) ilk kuralını hatırlayın. Her domain kendi originini URL'den alır. Dolayısıyla iframe ve parent aynı originde yer almakta ve birbirlerinin DOM'larına erişebilmektedirler.

one.bmp, aynı kaynaktan yüklendiği için, iframe'i yükleyen parent, iframe'e bir dizi başka elemanlar da ekleyebilir. Örneğin bir script blogu ekleyebilir:

script=document.createElement("script");
script.src="/one.js";
window.frames[0].document.head.appendChild(script);

Image tipindeki kaynakların HTTP yanıtlarına CSP eklemeyi gerekli görmediğimiz için saldırgan, bu kaynağa herhangi bir script dosyasını, CSS dosyasını enjekte edebilir.

Kıssadan hisse, imaj dosyaları, stil dosyaları ve hata sayfaları gibi pek çok kaynağa CSP headerları set edilmeli.

Sunucu konfigürasyon dosyaları marifetiyle dosya uzantısı ve tipi ile ilişkilendirilmiş HTTP yanıtları belirleyebiliriz. Apache Sunucular için örnek bir konfigürasyon:

<Files ~ "\.(png|jpe?g|gif)$">
Header set Content-Security-Policy script-src 'self'
</Files>

Araştırmanın ayrıntıları için lütfen tıklayınız.

Phishing Sitelerini Certificate Transparency ile Tespit Edin!

Haftanın Hackleri serisinde meşru amaçlarla tasarlanmış pek çok araç ve yöntemin nasıl kötüler tarafından kullanıldığına çokça yer verdik. Örneğin HPKP'nin yani HTTP Public Key Pinning teknolojisinin header injection marifetiyle nasıl saldırganlar tarafından kullanılıp, saldırgan kontrolündeki sertifikaların nasıl sitelere pinlendiğini ve sonrasında fidye karşılığı satılmak istendiği: RansomPKP!

Bu defa meşru amaçlarla tasarlanmış başka bir teknolojinin, yine meşru müdafaada elimizi kuvvetlendirecek bir yöntem için kullanılması söz konusu.

Certificate Transparency, Google'ın Nisan 2018'den itibaren imzalanacak tüm sertifikalar için şart koştuğu kamuya açık loga imzalanan sertifika kaydının yapılması zorunluluğunun ardındaki teknoloji.

Sertifika otoriteleri imzaladıkları sertifikalara ait tüm kayıtları buraya eklemek zorunda. Böylece teorik olarak domain sahipliği doğrulaması yapmak zorunda kalmayan ve ele geçirilme durumunda saldırganların kendi kontrolünde olmayan siteler için sertifika imzalatma tehlikesinin de önüne geçebilecek. Domain sahipleri bu public logu takip ederek kendi domainleri için imzalanan bir sertifika olduğunda bundan derhal haberdar olabilecekler

Konunun ayrıntıları daha önce yayınladığımız HTTP Güvenlik Headerları yazımızdan okuyabilirsiniz.

Facebook, Mayıs 2018'de devreye aldığı ve developerların kullanımına sunduğu Certificate Transparency Monitoring hizmeti ile domaininiz ve olası tüm varyasyonları ile ilgili bir sertifika imzalama işlemi yapıldığında sizi haberdar ediyor.

Buraya kadar şaşırtıcı bir şey yok. Crt.sh üzerinden zaten böyle bir hizmet veriliyor. Ve pek çok CT Alert sistemi var. Peki Facebook'un bu hizmetini kayda değer ve dikkate şayan kılan ne?

Facebook log'a eklenen her domain için en bilinen phishing yöntemlerine dair bir analiz yapılıyor oluşu.

Örneğin Homograph attack:

Faceb00k[.]com - O harflerinin 0(sıfır) ile değiştirildiğini görüyorsunuz.
facebook[.]com: O harfleri Latin alfabesindeki (0x6F) değil, Kiril alfabesindeki küçük "o" harfidir. (0x43E).

Bilinen marka adlarının, farklı anahtar kelimelerle kombine edilerek oluşturulan phishing domainleri:

	helpdesk-facebook[.]com
Facebook[.]com-legit.com

Mobil cihazlardaki ekran boyutları hesaba katılarak hazırlanan uzun phishing domainlerinin tespiti:

Facebook[.]com.long.subdomain.that.will.not.be.fully.shown.on.mobile.devices.com

Gözün algılayamayacağı harf yer değiştirmeleri ve hatalar yöntemi ile phishing domainleri oluşturmak:

	faecbook[.]com
Faceboook[.]com

Evet, Facebook'u diğer Transparency Log sistemlerinden ayırt eden nokta yukarıdaki bilindik phishing yöntemlerini tespit edebilmesi ve olası bir tespit durumunda seçmiş olduğunuz kanallar üzerinden sizi haberdar etmesi.

Peki markanıza ait bir phishing domaini tespit ettiğinizde ne yapmalısınız?

1. Domaini kayıt eden şirkete ulaşarak derhal askıya almalarını sağlayabilirsiniz.
2. Browser üreticilerine bu domain'i bildirerek kara listeye almalarını ve ziyaret durumunda uyarı görüntülemelerini temin edebilirsiniz.
3. Phishing domainine ait sertifikayı imzalayan sertifika otoritesi (CA) ile irtibata geçerek sertifikayı Revoke etmelerini sağlayabilirsiniz.

Ayrıntılı bilgi için lütfen tıklayınız.

SSL/TLS'i WAF Bypass'ında Kullanmak

SSL/TLS artan bir oranda uçtan uca şifrelemeyi sağlayarak webi güvenli kılan bir protokol. 90'ların ortalarında hayatımıza girdi. Esas kıymetini ve protokol olarak bağımsızlığını 2000'li yılların başında kazandı, Let's Encrypt gibi projeler sayesinde de ücretsiz sertifika sahipliği imkânı ile de-facto olma yolunda ilerliyor.

SSL/TLS iyi hoş da çevresi kötü. Bir sızma testi uzmanı, bir sızma testi hizmetinde SSL/TLS'i kullanarak WAF'ı nasıl atlatabildiğini bir blog posta dönüştürerek bizlerin de repertuarını zenginleştirdi.

İşte ayrıntıları…

Araştırmacının sızma testi yapmakla görevli olduğu firmanın topolojisi aşağıdaki şekilde:

Görüldüğü üzere web varlıklarını koruyan bir Web Application Firewall (WAF), sunucu ve kullanıcılar arasında konumlandırılmış.

Sızma testi esnasında WAF'dan aldığı şu yanıt araştırmacının dikkatini çekiyor: Unsupported SSL Ciphers

Tam burada bir es verip, SSL/TLS bağlantısının nasıl kurulduğuna dair küçük birkaç ayrıntıya yer verelim:

ClientHello/ServerHello

SSL/TLS trafiği seromonik bir el sıkışma ile başlar. Üç adımda gerçekleşen bu el sıkışmanın ilk aşaması ClientHello/ServerHello mesajlarının gidip gelmesidir. Bu safhada öncelikle istemci taraf ClientHello mesajını ve beraberinde desteklediği tüm TLS Chipher Suite listesini gönderir. Yani desteklediği tüm şifreleme teknolojilerini bildirir.

Mesajı aldıktan hemen sonra sunucu, ServerHello mesajı ile yanıt verir. Sunucu, istemcinin bildirdiği suitelerden, en güvenli olanını seçer.

Certificate Exchange - Sertifika Değişimi

Bağlantı kurulduktan sonra sunucu kendisini istemciye tanıtan bir sertifika göndermek zorundadır. İstemci kendi sertifika güven zincirinden hareketle sertifikanın güvenirliğini doğrular. Sertifika güvenilir ve zamanaşımına uğramamış ise el sıkışmanın sonraki aşamasına geçilir.

Key Exchange - Anahtar Değişimi

SSL/TLS aslında hibrit bir şifreleme yöntemidir. Asitmerik karakterinin yanında, simetrik bir karakteri de mevcuttur. İstemci gönderim ve alımda, encryption ve decryption'da kullanılacak bir anahtar belirler. Belirlediği bu anahtarı da sunucunun public key'i ile şifreleyip sunucuya gönderir.

Kader ağlarını örmeye yavaş yavaş devam ediyor. Araştırmacının kafasındaki fikir şu, şayet WAF'ın desteklemediği ancak sunucunun desteklediği bir cipher ile saldırı isteği yaparsam WAF kendisinin desteklemediği bu şifreleme türü ile şifrelenmiş paketi açıp, vazifesini bihakkın yerine getiremeyecek.

Ve kader anı!

Araştırmacımız, WAF ürün geliştiricisinin sitesinde bulduğu dökümantasyondan hareketle WAF ürününün hangi cipher'ları desteklediğinin listesine ulaşıyor ve WAF tarafından desteklenmeyen cipher'ı tespit ediyor:

Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA

Teorisini test etmek için WAF'da /ssl-cipher-test pathini engelleyecek bir kural belirliyor:

Şimdi sıra bypass'da. Curl'un --ciphers parametresi ile bağlantı esnasında hangi cipher'ın kullanılacağı belirtilebiliyor. Bu yöntemi kullanan araştırmacı WAF'ı aşarak doğrudan web sunucusuna erişmeyi başarıyor:

pwn@thinkpad:~$ curl --ciphers ECDHE-RSA-AES256-SHA https://waf-test.lab.local/ssl-cipher-test
<html lang=en>
  <title>HELLO </title>
  <p>Bypass worked</p>
pwn@thinkpad:~$

Araştırmanın ayrıntılarına ulaşmak için lütfen tıklayınız.