Toparlanın Git'miyoruz

Ziyahan Albeniz - 11 Eylül 2018 -

Git - versiyon kontrol sistemini (VCS) websiteniz de kullanıyor musunuz? Peki, konfigurasyonların doğru yapılandırılmadığında tüm websitesinin kaynak kodunun saldırganın eline verebileceğizi biliyor muydunuz? Git'e hızlı bir bakış ile güvenlik konfigurasyonlarını inceliyoruz. Tor servislerinde SSL ekleyeyim derken Public IP'nizin ifşa olması!

Toparlanın Git'miyoruz

Finlandiyalı bilgisayar uzmanı Linus Torvalds, dünyayı iki kez değiştirdi. İlki takriben 25 yıl önce Linux çekirdeğini yazarak, ikincisinde ise versiyon kontrol sistemlerine yeni bir soluk getiren, dağıtık bir mimaride tüm eşlerin kaynak koda sahip olabildiği Git versiyon kontrol sistemini geliştirerek.

Şayet versiyon kontrol sistemi dosyalarını public erişime açık bir halde web sitenizle birlikte deploy ettiyseniz, üzgünüm ancak  sizin dünyayı değiştirmek için ikinci bir şansınız olmayabilir. Çünkü böylesi bir durumda sitenizin kaynak kodları, API tokenları, database erişim parolaları çoktan kötü niyetli kişilerin eline geçmiş olacak.

Vladimír Smitka isimli Çek güvenlik araştırmacısı önce Çekya'ya ait siteler üzerinde ardından da Slovakya ve global web siteleri üzerinde, Git versiyon sistemi dosyaları üzerine yaptığı araştırmanın sonuçlarını yayınladı.

Haftanın Hackleri'nin bu yazısında bu araştırma sonuçlarından hareketle versiyon kontrol sistemi dosyalarının güvenlik konusunda yaratacağı risklere ve çözüm önerilerine değineceğiz.

Smitka'nın araştırması ile başlayalım. Çek siteleri ile ilgili araştırmasını 1.5 milyon Çek sitesi üzerinde gerçekleştiren Smitka, 2 gün süren scan sonucunda 1.950 web sitesinde Git klasörünün genel erişime açık olduğunu tespit etti.

Çekya'ya ait sitelerden sonra, araştırmasına Slovakya'ya ait siteleri inceleyerek devam eden Smitka, bu kez 930 sitenin Git klasörünü genel erişime açık halde bıraktığını belirtiyor.

Bu iki araştırmadan sonra hedefi büyüten Smitka bu kez global çapta bir analiz için kolları sıvıyor. Global scani 230 milyon domain üzerinde gerçekleştiriyor.

Yaklaşık 4 hafta ve 250 dolara mal olan scan sonucunda Smitka, 390 bin domainin genel erişime açık bir Git dizini barındırdığını tespit ediyor.

Listede 189 bin 472 adet ile .com uzantılı domainleri, ikinci sırada 85 bin 202 adet ile .top domainleri takip ediyor.

Araştırmayı bu sitelerin kullandığı teknolojilere göre kategorilendirmek için derinleştiren Smitka, zafiyet barındıran sitelerin ağırlıklı olarak PHP ve Apache kullandıklarını belirtiyor.

Git'e İçeriden Bir Bakış

git

https://xkcd.com/1597/

git init komutu ile bir Git reposu oluşturduğunuzda ilgili klasörde .git adında gizli bir dizin oluşturulacaktır. Aynı şekilde bir repo'yu klonladığınızda da bilgisayarınıza kopyalanan repoda .git uzantılı bir dizin olduğunu göreceksiniz. Bu dizin Git 'in çalışması için gerekli tüm bilgi ve dosyaları içermektedir:

├── HEAD
├── branches
├── config
├── description
├── hooks
│ ├── pre-commit.sample
│ ├── pre-push.sample
│ └── ...
├── info
│ └── exclude
├── objects
│ ├── info
│ └── pack
└── refs
├── heads
└── tags

Bu .git klasörü deploy edilmemeli yahut public erişime açık olmamalıdır.

Bunu anlamanın birkaç yolu var.

www.example.com/.git/

Şayet Git klasörü sunucuda unutuldu ve dizin gösterimi için sunucuda dizin gösterimi ile ilgili gerekli ayarlar mevcutsa, klasör içeriğini gösteren bir dizin listesi ile karşılaşacaksınız.

Şayet dizin listeleme kapalı ise sunucunun varsayılan olarak görüntülemek için konfigüre edildiği index.php, index.html gibi dosyalar bu dizinde mevcut olmadığı için 403 hatası alabilirsiniz. Bu her şeyin yolunda olduğu sanısına kapılmanıza yol açmasın.

Çünkü esas olarak klasörün erişime açık olup olmadığını www.example.com/.git/HEAD ya da www.example.com/.git/config 'e erişerek anlayabiliriz.

Git'in dosya yapısı ile ilgili pek çok bilgi olduğu için saldırganın bir kez bu dizine ulaştıktan sonra kodu elde etmesi hiç zor olmayacaktır. Kaldı ki bu işlemleri otomatize eden pek çok araç bulunmakta.

Git klasörünün varlığından emin olduktan sonra, bu klasörü wget kullanarak recursive modda indirebiliriz: 

wget -r http://www.example.com/.git/

Ne Yapmalı?

Production ortamında .git klasörünü bırakmamanızı öneriyoruz. Eğer bu bir zorunluluksa web kök dizini dışında bir yere taşımanızı öneririz. Zira sistemde aksi bir duruma  sebep olacak bir zafiyet yoksa, web sunucuları sadece web kök dizinini servis etmek üzere programlanmıştır.

Diğer bir yöntem ise sunucuyu "." ile başlayan dizinlere erişimi doğrudan engelleyecek şekilde konfigüre etmek. Burada karşımıza küçük bir istisna çıkıyor: .well-known dizini. RFC 5785 ile tanımlanan bu dizinin görevi site kapsamında meta bilgisini ihtiva etmek. DNT bilgileri, Let's Encrypt validasyonu, security.txt dosyaları bu dizine konulabilir.

Dolayısıyla, "." ile başlayan klasör ve dosyalara erişimi engellemek için kural yazarken bu hususu da dikkatlerden kaçırmamak gerekiyor:

Nginx:

location ~ /\.(?!well-known\/) {
        deny all;
}

Apache:

<Directory ~ "/\.(?!well-known\/)">
        Order deny,allow
        Deny from all
</Directory>

Caddy Server:

status 403 /blockdot
rewrite {
        r /\.(?!well-known\/)
        to /blockdot
}

Araştırma hakkında daha ayrıntılı bilgi için lütfen tıklayınız.

Tor Servislerinin Public IP'lerine SSL Sertifikası ile Erişmek

Tor yani The Onion Router, Internet trafiğini rastgele seçilmiş relayler üzerinden hedefe ulaştırarak anonimlik vaadeden bir servis.

Anonimliklerini korumak isteyen kullanıcılar için Tor networkünde sunulan diğer bir seçenek de Tor servisleri. İnternetin bir alt kümesi olarak düşünebileceğimiz Tor networkünde, Tor Servisi olarak adlandırabileceğimiz "onion" uzantısını kullanan web sayfaları bulunmaktadır. Bu web sayfalarına ancak Tor networkü üzerinden erişebilirsiniz.

Üstelik bu siteler sandığınız gibi sadece karanlık işler için değil, gayet meşru amaçlarla da kullanılabiliyorlar. Hatta gündelik yaşantımızın ayrılmaz bir parçası olan pek çok site ve servis anonimliğe önem veren kullanıcılar tarafından erişebilir olmak için, sitelerinin Tor networkünde bir kopyalarını barındırıyor.

Örneğin New York Times'ın Tor Network'ündeki yansısı https://www.nytimes3xbfgragh.onion ya da Facebook'a erişim için https://facebookcorewwwi.onion adreslerini kullanabilirsiniz.

Bir Tor Servisi işletmek için Tor'a mahsus bir dizi ayar dışında, servisin hizmet vereceği makine üzerinde Apache ya da Nginx gibi bir web sunucu kurulu olmalı.

İşte yazımızın bu kısmına konu olan zafiyet de tam bu noktada yapılan bir yanlış konfigürasyondan kaynaklanıyor.

Tor kullanarak anonimliği önemsediğiniz anlaşılıyor. Bir de Tor servisini güvenli kılmak için TLS'i yani SSL'i implemente ettiğimizi düşünelim. Bunun için bir sertfika otoritesine, sitemizi servis edeceğimiz "onion" uzantılı domain için sertifika imzalatmalıyız. Tor servis adresimiz examplewwwi.onion olsun. Varsayılan ayarlarla servisimize 443 numaralı porttan erişim talep edildiğinde ClientHello mesajına cevaben sunucu ServerHello mesajında seçtiğimiz şifreleme bilgileri ile birlikte, sertifikamızı da gönderecek. Sertifikada bulunan CN alanı da domainimizi belirtecek, yani examplewwwi.onion'ı.

Certificate Viewer - 02

Apache, Nginx ya da hangi sunucu programını kullanıyorsanız, konfigürasyonda bir anlık bir dikkatsizlik yaptığınızı ve erişim için loopback (127.0.0.1) adresini dinlemek yerine 0.0.0.0 adresini yani tüm ağ arayüzlerine gelecek erişimi dinlediğinizi düşünelim.

Bilgisayarınızın public IP'sinden aynı şekilde 443 'e erişmeye çalışan biri, ClientHello mesajına cevaben ServerHello yanıtında servis edilen sertifikayı ve burada CN alanındaki onion uzantılı domaini görecek.

Certificate Viewer - 03

Ya hu zaten Tor kullanıyoruz, bizim public IP'mizi nereden bilecekler, diye sorabilirsiniz.

Haklı bir soru.

Peki saldırganların ya da bilgilerimize erişmek isteyen kişilerin şöyle bir yol izlediğini düşünsek:

Bir IP aralığına (örneğin 75.30.203.1 - 75.30.203.254)  443 numaralı porttan bağlantı isteği ve ClientHello mesajı gönderip, gelen yanıttaki yani ServerHello mesajındaki CN alanını extract edip, IP'ler ile bu "onion" uzantılı domainleri eşleştirseler?

Belki de Tor networkünde hizmet veren pek çok sitenin bilgilerine bu şekilde ulaşmış olacaklar.

Rosselyn Barroyeta adlı araştırmacı yayınladığı blog postta canlı bir örnek üzerinden yanlış konfigürasyonun yol açacağı tehlikeyi, IP ifşasını, gözler önüne seriyor.

Maalesef araştırmanın dili İspanyolca ve yazı yazıldığı esnada İngilizce versiyonu olmadığı için Google Translate üzerinden ulaşabildiğimiz çeviri üzerinden ayrıntıları elde edebildik.

Araştırmaya ulaşmak için lütfen tıklayınız.