Reddit'den Öğrendiğim Bir şey Var! Standartları Kullanarak Sitenizi Daha Güvenli Hale Getirin! Edge'de Kritik Bir Zafiyet
2FA bypass edilmesi, JS zararlısının Türkçe karakterler karşısında zayıflığı ve Edge browserlarda keşfedilen uzaktan erişim zafiyeti.
Web Güvenliği Açısından Reddit'in Öğrettikleri
Geçtiğimiz günlerde Reddit, Haziran ayı içerisinde hacklendiğini duyurdu. Bu vaka sonucunda 2007 ve öncesine ait verilerin olduğu sunucu yedeklerine erişildiği belirtiliyor. Yedeklerde bulunan kullanıcı bilgileri, kullanıcı parolalarının hashlenmiş ve salt'lanmış halleri ve 2018 Ağustos ayına ait e-posta bültenleri ele geçirildi.
Vakanın, birkaç Reddit çalışanına ait SMS'lerin ele geçirilmesi ile vuku bulduğu belirtiliyor.
Tabii bu vakada bildiklerimiz Reddit'in açıklamasında paylaştıklarından ibaret. Bu kadarı dahi web güvenliği perspektifinden olayın artı ve eksilerini yorumlamamız için bize bir miktar veri sunuyor.
Parolaların hashlenerek ve tuzlanarak (salt) saklanması.
Bir best practice olarak kullanıcı parolaların hashlenerek ve tuzlanarak (salt) saklanması, bu vakadan elde edilen bilgilerin, kullanıcı parolalarının clear text hallerine ulaşılmasını engelliyor. Bu da şayet kullanıcılar başka platformlarda aynı parolayı kullanıyorlarsa, saldırının farklı yönlere sıçramasını engellemiş oluyor. Tabii farklı platformlarda aynı parolayı kullanmak kesinlikle önerdiğimiz bir pratik değil.
Reddit, kullanıcıların sızan datada bulunan parola hashleri ile mevcut parola hashleri aynı ise, yani çalınan dataların ait olduğu zaman dilimi 2007'den bu yana bir parola değişikliği yapılmadı ise parola değişikliği gereksinimi konusunda kullanıcıya bilgi verilecek.
2FA veya MFA (Multifactor Authentication) Kullanımı
Reddit çalışanları 2FA yani iki aşamalı doğrulama kullanarak yine doğru bir pratiği işletiyorlar.
Önce 2FA'yı tekrar hatırlayalım.
2FA, kullanıcıların kendilerinin iddia ettikleri kişi olduklarını doğrulamak için aşağıdaki kombinasyonları kullanmalarını zorunlu kılar. Bu kombinasyonda aşağıdaki unsurlar kullanılabilir:
- Kullanıcının bildiği (Şifre ya da PIN)
- Kullanıcının sahip oldukları (Telefon, OTP, Token Generator)
- Bizzat kendisi olan (Biometrik tanımlama, parmak izi vb.)
Bir süredir gerek SIM-swapping tekniği gerekse de SS7 protokol saldırıları ile, SMS’lerin ele geçirildiği biliniyor
Sütten ağzı yanan Reddit, SMS temelli 2FA yerine, token temelli doğrulamayı kullanacaklarını belirtiyor.
Bunun anlamı şu, kimlik doğrulamanın ilk aşaması tamamlandıktan sonra, ikinci aşamada kullanıcı kendisine SMS yolu ile iletilen veri ile değil, bir "generator" tarafından üretilen token ile ikinci aşamayı tamamlıyor olacak.
Loglar, loglar...
Aynı madde OWASP Proactive Controls listesinde de 8. Sırada yer alan Implement Logging and Intrusion Detection maddesi ile de benzerlik gösteriyor. Tabii Proactive Controls listesinde logging mekanizmasının implemente edilmesi bir proaktif hareket olarak önerilirken, Top 10 listesinde de bu mekanizmanın hatalı yapılandırılması bir zafiyet olarak değerlendiriliyor.
14-18 Haziran tarihlerinde gerçekleşen bu girişimden -kendi beyanlarından hareketle- 19 Haziran günü, yani bir gün sonra haberdar olan Reddit yetkilileri, 2016 yılında ortalama 191 gün olarak hesaplanan data sızıntısı tespit süresi göz önünde bulundurulursa oldukça iyi bir iş çıkarmış görünüyor.
Reddit tarafından yapılan duyuruya ulaşmak için lütfen tıklayınız.
İşinizi Şansa Bırakmayın, Standartları Kullanarak Sitenizi Daha Güvenli Hale Getirin!
Yazımıza veri sızıntısı vakaları ile başladık, aynı şekilde devam edelim. Biletix 27 Haziran 2018 tarihinde sosyal medya hesapları ve web sitesi üzerinden bir duyuru yayınlayarak, 23 Haziran tarihinde Ticketmaster İngiltere'nin, Biletix'in de kullandığı Inbenta firmasına ait müşteri destek uygulamasında bir zararlı yazılım tespit ettiğini ve Inbenta'nın hızlı bir reaksiyon ile bu zararlı kodları derhal uygulamadan kaldırdığını duyurmuştu. Inbenta müşterilerinin Kuzey Amerika başta olmak üzere yüzde 5'lik bir kısmının bu saldırıdan etkilendiği belirtiliyordu.
JS zararlısı kendisini bilinen kütüphanelerin içerisine enjekte ederek gizliyor. Ödeme sayfasına geldiğinde tüm inputlara yerleştirdiği event handler sayesinde ise dataları toplayıp, saldırgan kontrolündeki sunuculara gönderiyordu.
Gönderilen datalarda input isimleri ve değerleri string birleştirme işleminden geçiliyor, aktarımdan önce de base64 ile encode ediliyordu.
Saldırganın hesap edemediği nokta tam da burada ortaya çıkıyordu: Satın Al butonuna basıldığında bu metindeki Türkçe karakterleri encode edemeyen btoa Javascript fonksiyonu hata veriyor ve işleme devam edilemiyordu. Böylece veri elde edilmiş olsa bile saldırgan kontrolündeki sunucuya gönderilemiyordu.
Evet tarih tekerrürden ibarettir. Fakat her zaman insanlara karşı bu kadar cömert olmaz. Üstelik tekerrür etse dahi birincisinde trajedi, ikincisinde komedi olur.
Dolayısıyla gelin işimizi şansa bırakmayalım ve üçüncü parti ürün ve hizmet kullanımlarında standartları kullanarak sitelerimizi daha güvenli hale nasıl getirebileceğimize bir göz atalım.
Subresource Integrity (SRI)
Script ve Style kaynaklarını aldığımız sunucular bir saldırıya uğramış ve yığınla web sitesine servis edilen script ve style dosyaları değiştirilmiş ise ne yapabiliriz?
Bu durumda yardımımıza SRI koşuyor.
Script ve Link taglarına eklenen integrity özelliği ile, harici bir kaynaktan yükleyeceğimiz dosyanın SHA-256, SHA-384, SHA-512 hash değerlerinden birini ya da birkaçını base64 encode olarak belirtebiliyoruz. Yüklenmek istenen dosyanın hash değeri, bu hashler ile aynı ise dosyalar sitemizin bir parçası olarak yükleniyor, aksi takdirde, yani hash değerleri uyuşmazsa tarayıcı hata vererek bu kaynağın yüklenmesini engelliyor.
<script src="http://my2cdn.com/myscript.js" integrity="sha256-0URT8NZXh/hI7oaypQXNjC07bwnLB52GAjvNiCaN7Gc=" crossorigin="anonymous"></script>Hash'ler Uyuşmazsa ne olur?
SRI'yi destekleyen bir browser kullandığınızda hashler uyuşmadığı takdirde, script ya da style dosyası yüklenmeyecek ve kullanıcıya uyarı verilecektir. (Eğer SRI desteklemeyen bir browser ya da eski bir sürüm browser kullanıyorsanız, script yüklenecektir.)
Kıssadan Hisse
Mert Sarıca ile aynı günlerde bizim de blogumuzda SSL ve statik siteler bağlamında ele aldığımız JS zararlısı türevinin kendini gizlemek için, bilinen Javascript kütüphanelerinin içerisine eklediğini belirtmiştik.
Dolayısıyla Biletix özelinde bu zararlıdan etkilenmiş olduğu düşünülen firmalar harici script ve style yüklemelerinde SRI kullansalardı, hedef dosya değiştiğinde browser yüklemeyi durduracak ve zararlı kod işlevini yerine getiremeyecekti.
SRI'nın ayrıntıları için lütfen tıklayınız.
Content-Security-Policy (CSP)
2012 Kasım ayında ilk versiyonu hayatımıza giren CSP, başta XSS olmak üzere, Clickjacking, Protocol Downgrading, Frame Injection vb bir dizi zafiyete karşı istemci tarafında ekstra güvenlik katmanı sunmaktadır. Content Security Policy (CSP) ayrıntıları için lütfen tıklayınız.
CSP set edildiğinde, event handlerindeki JS kodlarının, inline script kodlarının ve whitelist edilmemiş kaynaklardan context'e dahil edilmek istenen kodların çalışmasını engelleyecektir.
Content-Security-Policy: script-src 'self' https://apis.google.comYine SRI de olduğu gibi script bloklarına bir hash atayıp, script ve stil kaynağında herhangi bir değişiklik vuku bulduğunda yüklenmesini engelleyebilirsiniz:
Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='Biletix olayının biraz daha sofistike olduğu düşünebilir. Yani zaten müşteri destek yazılımı için bir firmaya güvenilmiş; dahili ve bu firmaya ait harici URL'ler de whitelist edilmiş olabilir. Dolayısıyla bu ahval ve şerait içinde vazifemiz ne olacaktır? Bu açmazdan nasıl kurtulacağız?
Oysa CSP'nin sunduğu imkânlar burada da yardımımıza koşuyor. Örneğin Biletix ve benzer JS zararlılarının bulaştığı sistemlerde CSP'nin connect-src talimatı hayat kurtarabilir, üstelik bu veri hırsızlığından da anında haberdar olunabilirdi.
connect-src
connect-src; XHR, WebSockets, EventSource ile bağlanılabilecek kaynakları kısıtlar. Sadece güvenilir kaynaklar whitelist edilebilir.
Content-Security-Policy: connect-src 'self' https://thirdparty.com/end-point;Site kendi end-point URL'lerini, varsa üçüncü parti servis end-pointlerini whitelist ettikten sonra JS zararlısının eli kolu bağlanmış olacak.
Çünkü tabiatı gereği bu JS zararlısı elde ettiği dataları saldırgan kontrolündeki CC'ye göndermek isteyecek, fakat bu istek CSP connect-src talimatı dolayısıyla bloke edilecek.
Daha da önemlisi, şayet connect-src talimatını report-uri opsiyonu ile birlikte kullandıysanız, tarayıcı isteği bloke etmek ile kalmayacak, aynı zamanda report-uri de belirttiğiniz end-point'e JSON tipinde bir veri post ederek, hangi sayfada connect-src talimatının ihlal edildiğini, hangi kaynağa veri gönderilmek istenirken blokaj işlemi yapıldığını, hangi dataların gönderilmek üzere olduğunu size bildirecektir.
Content-Security-Policy: connect-src 'self' https://thirdparty.com/end-point; report-uri https://www.example.com/report-uri"csp-report": {
"document-uri": "http://example.org/page.html",
"referrer": "http://evil.example.com/",
"blocked-uri": "http://evil.example.com/evil.cc",
"violated-directive": "connect-src 'self' https://apis.google.com",
"original-policy": "connect-src 'self' https://apis.google.com; report-uri
http://example.org/my_amazing_csp_report_parser"
}
}Tüm Dosyalara Uzaktan Erişim İmkanı Veren Edge Zafiyeti
Ekibimizden Ziyahan Albeniz Microsoft Edge browserında bir zafiyet tespit etti. Mail and Calendar'da bulunan başka bir zafiyet ile kombine edildiği takdirde kullanıcın yerel dosyalarına uzaktan erişim imkanı veren zafiyet Microsoft Windows'un Haziran güncellemesi ile birlikte fixlendi.
IE de dahil tüm modern browserlar XHR nesnesi ile yerel sistem dosyalarına erişim yapılmasını engelliyorlar. Fakat Edge bu noktada farklılık gösteriyor, XHR vasıtası ile sistem üzerindeki herhangi bir dosyaya istek yapılabiliyordu.
Bu zafiyeti kullanan bir saldırgan teorik olarak zararlı JS kodunu içeren bir HTML sayfasını hazırlayıp hedef kişiye gönderebilir ve makinesindeki herhangi bir dosyayı okuyabilirdi:
<html>
<head>
<script>
let resultDiv = document.getElementById("result");
let xhr= new XMLHttpRequest();
let user = document.location.href.match(/file:\/\/\/C:\/Users\/([a-z0-9\-]*)\//i)[1];
xhr.open("GET",'file://C:/Users/${user}/Desktop/secret.txt");
xhr.onreadystatechange = ()=> {
if(xhr.readyState==4) {
resultDiv.innerText = xhr.responseText;
}
}
xhr.send();
</script>
</head>
<body>
</body>
<div id="result"></div>
</html>Tabii zafiyetin exploit edilmesinde saldırgan bir takım kısıtlarla karşı karşıya kalacaktı:
Saldırgan zararlı kodu bir web sayfası olarak hazırlayıp gönderdiği takdirde Same Origin Policy (SOP) engeline takılacaktı. Çünkü web sayfası HTTP ya da HTTPS şema üzerinden yüklendiği halde, XHR nesnesi ile istek yapılan kaynağa erişimde file:// şeması kullanılacaktı. Daha ilk elden şema - host - port uyumunu zaruri kılan SOP engeli karşısına dikilecek ve browser tarafından işlemin iptal edildiğine dair bir mesajla karşılaşacaktı.
Saldırgan bu defa başka bir yol deneyecek ve kullanıcı siteye girer girmez, bu JS kodunu içeren HTML sayfasının download edilmesini ve hedefteki kullanıcının da bunu açmasını sağlayacaktı.
Saldırgan burada da başka bir engel ile karşılaşacak: Windows işletim sistemi download edilen dosyaları blocked olarak işaretlemekte. Dolayısıyla bu dosyalarda bulunan JS kodları, dosyalar açılsa dahi browser tarafından çalıştırılmayacaktı.
Zafiyetin exploiti üzerine kafa yoran Ziyahan Albeniz yukarıdaki engelleri aşmak için bu defa zararlı dosyayı e-posta ile gönderilebileceğini düşünüyor. Şansı yaver gidiyor. Birkaç denemeden sonra Mail and Calendar programının 17.8600.40445.0 versiyonunun, e-posta eklerini açmak üzere indirdiğinde, bunun Temp klasöründe oluşturulan kopyasının Blocked olarak işaretlenmediğini farkediyor.
Bu HTML e-posta ekinin açılması işleminde Microsoft Edge kullanılıyor ise, zararlı JS dosyası işletim sistemi tarafından bloklanmayacak ve XHR isteğinin olduğu JS kodu Edge browserında çalıştırılacak. Böylece de uzaktan dosya erişimine imkân veren zafiyet exploit edilmiş olacak.
Zafiyet PoC videosu:
