.NET Zincirleme Hatalar ve Hacking – Red Team Seyir Defteri 1
Birçok kurumda. NET uygulamaları kaçınılmaz olarak kullanılmakta ve geliştirilmektedir. .NET uygulamalarının özellikle Microsoft Domain mimarisi ile entegrasyonu ve kullanım kolaylığından dolayı, kurumlar tarafından sıklıkla tercih edilen bir platform olarak karşımıza çıktığını görmekteyiz.
Bu yazımda da bazı zincirleme hatalar ve bunun sonucu olarak hacking konusuna değineceğim. İlk başlarda biraz karışık gelebilir ancak konunun ilerleyen kısımlarında aslında pek karışık olmadığını göreceğiz. Şimdi nedir yahu bu hatalar diyenler için biraz daha detaylandıracağım. Ancak öncelikle .NET platformunda “Publish” ve “Build” konularına önemle değinmem ve biraz da “IIS” açmam gerekiyor ki konu daha iyi anlaşılsın.
.NET Uygulamalarında Publish
Geliştirilen bir web uygulamasının yayına (IIS vb.) hazır hale getirilmesi işlemidir. Publish işlemi ile kaynak kod ve derlenmiş kod birbirinden ayrılır. Sadece derlenmiş kod parçalarının ve dosyalarının yayın yapılacak sunucuya gönderilmesi için dosyaların ayrıştırılmasını sağlar.
.NET Uygulamalarında Build
Geliştirilen uygulamanın çalıştırılmadan önce derlenmesini sağlar. Build işlemi ile kaynak kod derlenir ve çalıştırılabilir hale getirilir. Bir sonraki adım olan Publish’ten önce derleyici çalışır, proje derlenir ve sonra publish edilmesini sağlar. Yani; bir proje publish edilmeden önce mutlaka IDE tarafından Build edilir ve sonra Publish edilmesini sağlar.
IIS Dizin ve Uzantı Güvenliği
Bir web uygulaması IIS sunucuya yüklenip, kullanıma hazır hale getirilirken IIS, varsayılanda bazı güvenlik korumalarını da beraberinde getirmektedir.
Directory Browsing: IIS 7 ve sonrasındaki tüm IIS sürümlerinde bu özellik kapalı gelir. Sayfayı ziyaret eden bir kullanıcı dizinleri görüntüleyemez.
Disallowed Extensions: Bu özellik IIS, varsayılanda bazı uzantılara erişimi engellemektedir. Aşağıdaki tabloda yer alan uzantılara sahip herhangi bir dosya IIS sunucusunda yayına açık dahi olsa, bir kullanıcı bu dosyalara erişip, indiremez.
Yukarıdaki tabloda IIS’de ziyaretçi erişimine yasaklı olan uzantıları görüyoruz.
Yukarıdaki resimde görüleceği üzere, IIS altında yer alan web.config dosyasına erişmeye çalıştığımızda 404 hatası alırız.
Aynı Şekilde Publish edilmiş yada derlenmiş .NET web uygulamalarına ait kaynak kodlar da “bin” dizini altındaki “projeadi.dll” dosyasında yer almaktadır. Bu dll dosyasına erişilmesi durumunda dosya “decompile” edilerek sitenin kaynak kodlarına ulaşılabilir. Ancak IIS 7 ve sonrasındaki IIS sürümlerinde “bin” dizinine erişim sağlanamadığı için bu dosyanın indirilme ihtimali de varsayılanda kalmıyor.
“bin” dizinine erişmeye çalıştığımızda da 404 hatası ile karşılaşmaktayız.
Bu kadar genel bilgiden sonra gelelim saldırı yöntemine. Eğer şansımız var ise yazılımcılar projeyi publish etmek yerine build edip, sunucuya yüklemişlerdir J Peki bir .NET yazılımının publish edilip mi yoksa build edilip mi sunucuya yüklendiğini nasıl anlayacağız ki? Bunu anlamanın çok basit bir yolu var aslında. Kaynak projenin yayın yaptığı dizinde “obj” klasörünü sorgulayarak bunu rahatlıkla anlayabiliriz. Erişmeye çalıştığımız sunucuda eğer “obj” dizini mevcut ise proje build edilerek sunucuya yüklenmiş, bu dizin yoksa proje publish edilerek sunucuya yüklenmiş demektir.
Yukarıdaki resimde görüleceği üzere, sayfanın (projenin) kök dosyasındaki “obj” dizinine erişmeye çalıştım. Ve bingo! Aldığım hata 403. Yani dizin var ancak hak ve yetkilerim dizini görüntülemeye yeterli değil. Bir daha yani dersek; sunucuda “Directory Browsing” aktif durumda ve dizinin altını görüntüleyemiyorum.
Şimdi biraz daha .NET’e bakacak olursak; .NET derlenen her proje için “/obj/Debug” klasörü altında, ilgili projenin proje adı ile bir dll dosyası ve derleme bilgisini tutar. Yani bizim “bin” dizininde yer alan ve tüm sayfanın kaynak kodlarını içinde barındıran projeadi.dll dosyasına “/obj/Debug” dizinini kullanarak erişebiliriz demektir.
Ancak buradaki en büyük sorun şu; varsayılanda kapalı olan Directory Browsing özelliğinden dolayı, projeadi.dll dosyasının adını tahmin etmeye çalışarak dosyaya ulaşmamız gerekiyor. Genelde eriştiğimiz web uygulamasının adı ile proje ya benzer ya da birbirine çok benzer olur. Örneğin; adeo web sayfası var ise proje adı da genelde “adeo, adeoWeb, adeoSite” gibi isimlere sahip olabilir.
Birkaç deneme yanılma yaptıktan sonra proje adının “vulnWeb” olduğunu tespit ediyorum. Veee dll dosyasını indirmeyi başardım. Şimdi geriye bu proje dosyasını “decompile” edip, kaynak kodlarına erişmek kalıyor.
İndirmiş olduğum dll dosyasını “ILSpy” ile decompile edip, kodlar arasında biraz gezindiğimde uygulamanın Connection String bilgilerini okudum. Şimdi geriye bu bilgileri değerlendirip, sisteme sızma işlemini güçlendirmek kalıyor.
Yukarıdaki resimde görüleceği üzere, Connection String’den elde ettiğim bilgileri kullanarak SQL sunucusuna bağlandım. Bundan sonra yapılması gereken basit! İşletim sistemine komut göndermek. Bunun için de MS-SQL içerisinde yerleşik gelen “xp_cmdshell” prosedürünü çalıştırabiliriz.
MS-SQL 2008 ve sonrasındaki tüm sürümlerde “xp_cmdshell” prosedürü varsayılanda kapalı gelmektedir. O halde öncelikle bunu açmalıyız J
Yukarıdaki ekranda görüleceği üzere, girdiğimiz parametreler ile “xp_cmdshell” prosedürünü aktif hale getirdik. Artık işletim sistemine komutlar gönderebiliriz beybili.
Görüleceği üzere artık MS-SQL üzerinden işletim sistemine komutlar gönderebiliriz. Bundan sonraki süreçte yapacaklarımız tamamen deneyimlerimize kalmış. Örneğin; “powershell” kullanarak sistemde Meterpreter çalıştırabilir ve diğer sistemler için post-exploitation gerçekleştirebiliriz.
Yazılım derleme (build) ya da yayınlama (publish) arasındaki fark umarım yeterince anlaşılır olmuştur. Bu tarz bir saldırı ile karşı karşıya kalmamak için publish edilmemiş kodların IIS sunucusuna yüklenmesini engellemeliyiz. Ayrıca network seviyesinde segmentasyon uygulanarak, saldırganın hareket kabiliyetlerini kısıtlamamız gerekmektedir. Bir başka konuda MS-SQL saldırılarını detaylıca işleyeceğim için, SQL sunucusuna Malware bulaştırma vb. konuları bu makalede işlemedim.