• Kategori: Güvenlik
  • Eyüp ÇELİK
  • Gösterim: 4453

.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ı, özellikle Microsoft Domain mimarisi ile entegrasyonu ve kullanım kolaylığından dolayı, geliştiriciler 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” konusunu 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.

Directory Browsing

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.

.asax .vbproj .dsdgm .ldf
.ascx .webinfo .ssdgm .ad
.master .licx .lsad .dd
.skin .resx .ssmap .ldd
.browser .resources .cd .sd
.sitemap .mdb .dsprototype .adprototype
.config .vjsproj .lsaprototype .lddprototype
.cs .java .sdm .exclude
.csproj .jsl .sdmDocument .refresh
.vb .ldb .mdf .compiled
.msgx .vsdisco .rules  

Tablo-1 IIS’de ziyaretçi erişimine yasaklı olan uzantılar

web config

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 dizini

“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.

obj dizini

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.

dll indirme

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.

decompile

İ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.

sql conn

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.

cmdshell kapali

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 :)

cmdshell ac

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.

net user

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.

Comments

0 Anonim 22-09-2016 23:00 #1
Merhaba,
Bir siteyenin index sayfasını değiştirmek (hani meşur hacked yazısını yazmak) için sitede öncelikle hangi açıkları aramamız gerek ve/veya hangi açıklar bu işi yapmamızı kolaylaştırır/olanak sağlar?
Quote

Yorum ekle


Güvenlik kodu Yenile

Bookmaker betfair Bonus review by ArtBetting.co.uk

Bookmaker bet365 review by ArtBetting.co.uk

Germany bookmaker b.artbetting.de review by ArtBetting.de

Bookmaker Greece BET365 review by ArtBetting.gr

Back to top