Alexa Top 1 Milyon Domain'de .DS_Store Avı! HTTPS'in Limitlerini Anlamak
Alexa top 1 milyon websitesi üzerinde .ds_store avına çıkan araştırmacılar bizlerle bulgularını paylaşıyorlar. Web site bağlantısını güvenli bağlantıya geçirmek için kullandığımız HTTPS'in limitlerini yeterince anlayabiliyor muyuz?
Alexa Top 1 Milyon Domain'de .DS_Store Avı!
.DS_Store dosyası, Mac OS işletim sistemlerinde Finder uygulaması tarafından dizinler içerisinde oluşturulan, dizin dosyaları ve dizin görüntüleme tercihlerini içeren bir dosya. DS_Store ismi ise Desktop Service'in bir kısaltması.
.DS_Store dosya isminin başındaki nokta (.) işareti ise, Unix türevi işletim sistemlerine aşina olan okurların hatırlayacağı gibi, dosya ve dizinleri gizli tutmanın bir yolu.
Web güvenliği söz konusu olduğunda .DS_Store'u bizler için önemli kılan ne?
.DS_Store dosyası kaynak bulma aşamasında, farklı dizin ve dosyaları tespit etmemize olanak sağlayan bir vektör olarak kullanılabilir.
Dolayısıyla bu dosyanın production ortamlarında, web kök dizinlerinde yer almaması, kazara buralara yüklenmiş olsalar bile, web sunucu konfigürasyonunun bu dosyalara erişimi men edecek şekilde yapılandırılmış olması gerekiyor.
Bu haftaki yazımıza konu olan ilk haberde, Leipzig'de gerçekleşen Kaos İletişim Kongresinin 34.sünde hızlı internet bağlantısını fırsat bilen iki kafadarın, Alexa Top 1 Milyon listesinde yer alan siteler üzerinde gerçekleştirdikleri .DS_Store yoklamasının sonuçlarını konu edeceğiz.
Araştırmanın sonuçlarına göre Top 1 Milyon listesindeki sitelerden, 10 bininde .DS_Store dosyası mevcut ve erişilebilir durumda. Araştırmacılar daha yüksek bir rakamı umuyor olacaklar ki, 10 bini az bulduklarını ve hayal kırıklığına uğradıklarını belirtmeden edememişler. Fakat araştırmayı derinleştirdiklerinde çarpıcı sonuçlara ulaşmaları da kaçınılmaz olmuş.
Araştırmacılar, Recursive Mode ile bu sayıyı yaklaşık 1 milyon 185 bin 671 'e vardırıyorlar. Bunun anlamı şu, şayet ana domainde buldukları bir .DS_Store dosyası başka bir dizin adını içeriyorsa, bu dizinin de ayrıca bir .DS_Store dosyası içerip içermediği kontrol ediliyor. Şayet içeriyorsa buradaki dosya ve dizinler de aynı muameleye tabi tutuluyorlar. Recursive Mode böylece sürüp gidiyor.
Eklemekte fayda var. .DS_Store dosyası plain text bir dosya değil. Dolayısıyla binary tipindeki bu dosyayı parse etmek için araştırmacılar özel olarak geliştirdikleri bir parser kullanıyorlar. Ayrıntılar için lütfen tıklayınız.
Elde ettikleri URL'lerin 21 bin tanesin 403, 404 ve 500 yanıt kodları ile erişilemez olduklarının raporlandığı sonuç kısmında, .DS_Store'u en yüksek oranda ihtiva eden TLD'nin 5 bin rakamı ile .com TLD'sine sahip domainler olduğu belirtiliyor.
Araştırmadaki ilginç noktalardan biri şu, .DS_Store'da tespit edilen dosya ve dizin adlarının varlığı kontrol edilirken, HEAD metodu ile istek yapılıyor oluşu. Hatırlanacağı üzere HEAD metodu ile bir kaynağa yapılan isteklerde, dönen yanıtın body kısmı herhangi bir data içermez, sadece yanıtın Header kısmında talep edilen kaynağa yönelik, örneğin bu kaynak mevcut mu değil mi, hangi dil tercihlerini kullanıyor, sunucunun tarih ve saat bilgileri vb. bilgiler dönmektedir.
Fakat bilindiği gibi bazı sunucularda HEAD metodu kapalı olduğu için aslında var olan dosyalara 200 dışında bir kod ile yanıt verilmiş olabilir. Örneğin 401 Method Not Allowed gibi.
Araştırmada .DS_Store vasıtası ile ulaşılan, sıralamada ilk 10'da yer alan dosya uzantıları ve adetleri şu şekilde:
| 256715 | .jpg |
| 75177 | .png |
| 64835 | .php |
| 42422 | .html |
| 39691 | .gif |
| 23683 | .htm |
| 16397 | |
| 9736 | .js |
| 9346 | .txt |
| 6886 | .css |
Listenin devamında güvenlik açısından risk arz eden, dikkat çekici uzantılar da var:
| 661 | .bak |
| 569 | .gz |
| 549 | .doc |
| 464 | .db |
| 343 | .csv |
| 266 | .eml |
| 248 | .log |
| 240 | .old |
| 202 | .docx |
| 186 | .inc |
| 162 | .config |
| 129 | .cfg |
| 123 | .sql |
| 123 | .sh |
| 105 | .htaccess |
| 55 | .git |
| 35 | .LOG |
| 23 | .orig |
| 22 | .tgz |
| 21 | .pem |
| 18 | .out |
| 16 | .conf |
| 16 | .cfs |
| 10 | .php_old |
| 10 | .php_ |
| 10 | .key |
| 8 | .back |
| 6 | .backup |
| 5 | .bkp |
| 4 | .php_bak |
| 3 | .htpasswd |
| 2 | .core |
| 2 | .bash_history |
.bak uzantısı, dosya yedekleri için kullanılan bir uzantı.
| 9 index.php | .bak |
| 2 wp-config.php | .bak |
| 2 php.ini | .bak |
| 2 db | .bak |
Çözüm
11 yıl önce zafiyet ilk kez Apple'e aşağıdaki ticket ile raporlandı:
https://www.securityfocus.com/bid/3324/discuss
Aşağıdaki yöntem ile network paylaşımlı dizinlerde kapatılması öneriliyor:
https://support.apple.com/de-de/HT1629
Adobe ise, bir cronjob yardımı ile periyodik aralıklarla bu dosyayı silmeyi öneriyor:
https://helpx.adobe.com/dreamweaver/kb/remove-ds-store-files-mac.html
Bu ya da başka bir yolla .DS_Store dosyasını kaldırmış / silmiş olsak dahi, VCS sistemine daha önce push edilmiş olabilir. Bu noktaların da mutlaka kontrol edilmesi gerekiyor.
Sunucu tarafında ise, .DS_Store dosyasına yapılacak istekleri aşağıdaki ayarları kullanarak engellemek mümkün:
Apache için .htaccess ya da httpd.conf dosyasında:
<Files ~ "\.DS_Store$">
Order allow,deny
Deny from all
</Files>Nginx için konfigürasyon dosyasında server bloğuna:
location ~ \.DS_Store$ {
deny all;
}Araştırmanın ayrıntıları için lütfen tıklayınız.
HTTPS'in Limitlerini Anlamak
Geçtiğimiz günlerde Eric Lawrence HTTPS'in Limitlerini Anlamak başlıklı bir yazıyı kendi blogunda yayınladı.Türkiyeli okurun kafasında HTTPS implementasyonuna dair hâlâ muğlak ya da anlaşılmaz olan noktaları berraklaştırmak için, Haftanın Hackleri'nde Lawrence'ın altını çizdiği noktaları özetlemek istedik.
Bugün modern tarayıcıların sunduğu imkanlar açısından SSL'in limitlerini ve doğru bir SSL implementasyonu için gerekli noktaları Lawrence'ın yazısı dolayısıyla bir kez daha hatırlatalım:
SSL Şayet Siz Kullanırsanız İşe Yarar
SSL/TLS teknolojileri siz onları kullanırsanız işe yarar. Tıpkı pek çok güvenlik özelliği gibi! Bugün hâlâ tarayıcıların varsayılan olarak kullandığı protokol HTTP. Yani siz özel olarak tüm bağlantılarınızın güvenli bağlantıya dönüştürülmesini talep etmezseniz, SSL kullanmanıza rağmen, downgrade, SSL Strip saldırılarına hedef olabilirsiniz.
Mixed Content
Web uygulamanızda SSL olsa dahi, aktif ya da pasif kaynakların (script dosyaları, stil dosyaları, resimler) güvensiz bir bağlantı üzerinden yükleniyor olması SSL gardınızı düşürebilir. Bu zafiyete terminolojide Mixed Content adını veriyoruz.
Güvenli bağlantı sunan sitenize erişildiğinde, bir aktif content, yani sizin sitenizin kontekstinde çalışarak DOM'unuza erişebilecek bir kaynağın yüklenmesinde (Örneğin Script dosyaları) güvensiz bir bağlantı kullanılıyorsa, saldırganlar bu dosyanın içeriğini değiştirerek, güvenli bağlantı ile servis ettiğiniz sitenizi değiştirecek, manipüle edebilecek kodları enjekte edebilirler.
Çözüm olarak, kendi siteniz üzerinden yüklenen tüm kaynakların güvenli bağlantıya dönüştürülmesini HSTS ile sağlayabilirsiniz. Diğer sitelerden yükleyeceğiniz kaynakların güvenli bağlantı üzerinden servis ediliyor olduğunu doğrulamak ve aksi durumları kabul etmediğinizi belirtmek zorundasınız. Bunun için Content-Security-Policy headerlarını kullanabilirsiniz.
Gözden Kaçan HTTP Linkler
Active / Passive Mixed Content kadar doğrudan bir risk arz etmese de, sayfada unutulan ve HTTP protokolünü kullanan bağlantılar son kullanıcı için bir dizi endirekt risk oluşturulabilir.
Bu sorun ile daha çok e-posta gönderimlerinde karşılaşıldığını biliyoruz.
Şöyle bir senaryo düşünün:
<a href="http:///www.example.com/download.php">Click for download!</a>
Siteniz güvenli bağlantı üzerinden servis edilmesine rağmen yukarıda harici bir kaynağa link verirken HTTP protokolünü kullanıyorsunuz. Ağdaki bir saldırgan bu bağlantıyı kolaylıkla dinleyebilir, yanıtı değiştirebilir. Sizin sitenize olan güven sayesinde tıklanan bu link ziyaretçilerinize zarar verebilir, tarayıcıdaki bir zafiyeti istismar ederek sizin DOM'unuza da erişebilir. Nitekim Site İsolation mekanizmasının bir çözüm olarak önerildiği haha önceki Haftanın Hackleri yayınında belirttiğimiz uXSS vb. zafiyetler bu noktada ilk akla gelenlerden.
SNI / IP Address
SNI, yani Server Name Indication, değişkeni birden fazla site barındıran sunucularda güvenli bağlantı kurulmak istenirken hangi sitenin sertifikasının talep edildiğini belirtir. Yine ağı dinleyen biri, SSL sayesinde paket içeriklerini göremese de güvenli bağlantı talebinin hangi IP adresine gönderildiğini ve SNI ile de hangi web sayfasının görüntülenmek istediğini anlayabilir.
TLS 1.3 SNI'nın şifreli gönderilmesini sağlayacak bir yöntem öneriyor.
Data Length
SSL trafiğinde paket içerikleri görüntülenemese de data boyutları görüntülenebiliyor. Örneğin birinin Wikipedia.org'a erişmek istediğini-güvenli bir bağlantı kullansa dahi- IP ve SNI değeri ile anlayabiliriz. Ama paket içerikleri şifrelendiği için hangi maddeyi okuduğunu göremeyiz. Ancak data length değerlerinden bir eşleştirme yapıp, hangi maddenin okunduğun tahmini pasif bir saldırı ile mümkün olabilir. Ayrıntılar için şu ve şu linklere bakabilirsiniz.
Ticket Linking
TLS ticketları istemciyi tanımlamak için kullanılabilir. TLS 1.3 ile bu sorun giderildi.
Referrer Header
Bir site, kendisi üzerinden başka bir siteye erişim yapıldığında, Referer headerı ile kendi adresini belirtir. Hedef site de yine Referer headerı ile bu gezinime kaynak teşkil eden siteyi görebilir. Referer headerı sadece site üzerindeki bir link tıklandığında değil, aynı zamanda stil, imaj ve script yüklemelerinde, form gönderimlerinde de yapılan isteğe eklenecektir. Gerçek, gizlilik ve güvenliği tesis eden bir bağlantıda Referrer headerı da doğru biçimde kullanılmalıdır. Ayrıntılar için lütfen tıklayınız.
One Hop
Hop, bir mesaj paketinin hedef noktaya varmak için kat ettiği noktaların her birine verilen isimdir.
Örneğin komut yorumlayıcınızda tracert netsparker.com yazdığınızda paketin Netsparker sunucusuna erişene kadar üzerinden geçtiği tüm noktaları (hop'ları) görebilirsiniz.
SSL'i "one hop security" olarak tarif edebiliriz. Yani sadece istemciden gönderilen paket ilk hop'da deşifre edilmekte ve paket içeriği okunmaktadır. TOR vb. networkleri bununla ilgili istisna sayabiliriz. Zira iç içe konulmuş ve şifrelenmiş her paket (soğan benzetmesi de bu işleyişe istinaden yapılmaktadır.) yalnız ilgili relay'de deşifre edilmekte ve elde edilen şifreli paketin içeriği görülemeden bir sonraki relay'e gönderilmektedir.
Lawrence'ın örneği ile devam edelim. Fiddlerbook.com 'a girdiğinizde güvenli bir bağlantı ile hedefe erişirsiniz. Ancak güvenli bağlantı Fiddlerbook.com 'un önünde duran Cloudflare'de sonlandırılmıştır bile. Fiddlerbook.com (Lawrence'ın deyimiyle) bir sertifikaya sahip olmadığı için Cloudflare ve Fiddlerbook.com arasındaki bağlantı HTTP üzerinden devam etmektedir. Doğru bir hop'da konumlanan saldırgan, bu paket içeriği okuyabilir, değiştirebilir. Not: Cloudflare'da Full HTTPs Mode 'u kullanırsanız, Cloudflare ile sizin sunucunuz arasında kurulacak bağlantı da TLS üzerinden gerçekleştirilecektir.
Netsparker Türkiye Blogu'ndan aşağıdaki yazıları da güvenli bir SSL/TLS implementasyonu için okumanızı tavsiye ediyoruz.
- https://www.netsparker.com.tr/blog/web-guvenligi/preload-hayat-kurtarir-vbulletin-zafiyetleri-xss-teknikleri/
- https://www.netsparker.com.tr/blog/web-guvenligi/http-guvenlik-headerlari/
Eric Lawrence'ın Understanding the Limitations of HTTPS yazısına ulaşmak için lütfen tıklayınız.
