Kurumsal ortamlarda Windows işletim sistemleri üzerinde etkin olarak dosya ve klasör paylaşımları kullanılmaktadır. Bu özellik elbette Linux platformlarında da mevcuttur. Bu blog yazısında bir Linux dağıtımı (Ubuntu) üzerinden klasör paylaşıma açılıp Windows üzerinden klasöre ulaşma hakkında bilgi paylaşımı yapılacaktır.
Öncelikle Linux'a Samba yüklemesi yapacağız. Samba yükleme komutu:
# apt-get install samba
Masaüstünde paylasalim isminde yeni bir klasör oluşturup everyone (read-write) yetkisi verelim:
# cd Desktop
# mkdir -p paylasalim
# chmod 777 paylasalim
12 Ocak 2015 Pazartesi
18 Kasım 2014 Salı
Python Simple PhpBug Finder
Merhaba Arkadaşlar,
Farkındayım uzun zamandır bloga yazı yazmıyorum ancak mazeretim var, uzun süredir iş yoğunluğum mevcut. Bu yüzden maalesef pek fırsatım olmuyor..
Bugün yedek alırken eski arşivlere göz attım. Programlamaya yeni başladığım zamanlarda yazdığım birkaç programcığa rastladım :)
Vakti zamanında Python programlama dili ile Linux ortamında çalışıp Linux'un komut gücünü kullanarak PHP scriptler üzerinde basit bir bug bulucu yapmışım :)
Ekran görüntüsü:
Örneğin yukarıdaki çıktıya bakacak olursak;
cat.php dosyasının 5. satırındaki " pageID= $_GET['pid']; " ibaresi potansiyel bir XSS açığının olduğunu söylemektedir.
Programın kodlarını buradan indirebilirsiniz: http://pastebin.com/tUs0w2u7
Umarım yararlı olur, iyi günler.
Farkındayım uzun zamandır bloga yazı yazmıyorum ancak mazeretim var, uzun süredir iş yoğunluğum mevcut. Bu yüzden maalesef pek fırsatım olmuyor..
Bugün yedek alırken eski arşivlere göz attım. Programlamaya yeni başladığım zamanlarda yazdığım birkaç programcığa rastladım :)
Vakti zamanında Python programlama dili ile Linux ortamında çalışıp Linux'un komut gücünü kullanarak PHP scriptler üzerinde basit bir bug bulucu yapmışım :)
Ekran görüntüsü:
Örneğin yukarıdaki çıktıya bakacak olursak;
cat.php dosyasının 5. satırındaki " pageID= $_GET['pid']; " ibaresi potansiyel bir XSS açığının olduğunu söylemektedir.
Programın kodlarını buradan indirebilirsiniz: http://pastebin.com/tUs0w2u7
Umarım yararlı olur, iyi günler.
24 Haziran 2014 Salı
Xenotix XSS Exploit Framework ile XSS Tespiti
XSS (Cross-site Scripting) Zafiyeti Nedir?
Kaba yorum ile; web uygulamasında açığın meydana geldiği input/inject point (veri girişi) alanına gönderilen kötü niyetli javascript kodlarının, kullanıcının web tarayıcısında çalıştırıldığı bir saldırı türüdür. Yani Client-Side (kullanıcı taraflı) bir saldırıdır.URL adreslerindeki query stringler ve form alanlarında sıklıkla görülür.
Phishing saldırılarına zemin oluşturur.
Genellikle POST ve GET metotlarının kullanıldığı alanlarda olur.
Çeşitleri:
Reflected (Yansıyan), Stored (Depolanan) ve Dom-based olarak üç çeşittir.
Reflected XSS
Stored XSS
Etkileri:
Yazılım betiklerinin kullanıcı tarafında çalıştırılması sonucunda kullanıcının oturum bilgileri çalınabilir, web tarayıcısı (browser) ele geçirilebilir veya bilgisayarına zararlı kodlar enjekte edilerek ve bilgisayar yönetimi ele geçirilebilir...
XSS Zafiyeti Nasıl Oluşur?
Temel olarak web uygulamada kullanıcının veri girişi yaptığı alanlarda meta-karakterlerin filtrelenmemesinden kaynaklanmaktdır.XSS Zafiyetine Nasıl Önlem Alınabilir?
- Web uygulamalarında kullanıcının veri girişine izin verilen alanlarda filtreleme yaparak bu açıkları kapatabilirsiniz. Veri girişinin filtrelenmesi kadar veri çıkışının da incelenmesi web uygulamalarının güvenliğini arttıracaktır. Aşağıda belirtilen karakterlerin filtrelenmesi web uygulamaların güvenliğini sağlayacaktır:
['],[<],[>],[;],[/],[?],[=],[&],[#],[%],[{],[}],[|],[@],[\],["]Ayrıca bu tür karakterlerin gerektiği ortamlarda, girilen verinin encode edilmesi gerekebilir. NOT: Eğer uygulanabiliyorsa filtrelemelerde BlackList yerine WhiteList kullanılması daha güvenli olacaktır.
- Çerezlerin güvenli hale getirilmesi web uygulamalarının güvenliğini arttırmak adına yapılabilecek en önemli işlemlerdendir. Çerezler içinde kullanıcı adı, şifre ve oturum durumunun saklanmasından kaçınılmalıdır. Eğer tutulması gerekiyorsa şifreli olarak tutulması tercih edilmelidir.
- Çerezlere “httponly” set edilmelidir.
- Donanımsal/Yazılımsal Web Application Firewall (WAF) ile web uygulamasında varolan bir zafiyetin saldırgan tarafından keşfedilme aşamasını zorlaştırıp, loglayıp, bloklayabilirsiniz.
- Belirli periyotlarda içeriden ve dışarıdan web uygulama güvenlik testleri (penetrasyon testi) yaptırarak güvenlik açıklarının keşfi ve önlem alınması sisteminizi daha güvenli kılacaktır.
14 Mayıs 2014 Çarşamba
PHP Scriptlerde SQLi Tespiti ve Exploit Etme
- Manuel Araştırma
- Otomatik Kaynak Kod Tarayıcılarla
Biz bu blog yazısında iki yöntemi de kullanarak temel anlamda PHP scriptlerde zafiyetler (SQLi, XSS, RCE, LFI vb.) nasıl keşfedilir ve nasıl exploit (sömürme) edilebilir bunlara değineceğiz.
SQL Injection Nedir?
Web uygulamalarında birçok işlem için kullanıcıdan alınan veri ile dinamik SQL cümlecikleri oluşturulur. Örneğin; "SELECT * FROM Products" örnek SQL cümleciği basit şekilde veritabanından web uygulamasına tüm ürünleri döndürecektir. Bu SQL cümlecikleri oluşturulurken araya sıkıştırılan herhangi bir meta-karakter SQL Injection'a neden olabilir.
Etiketler:
bug bounty,
bug research,
havij,
rips,
sql injection,
sql injection açığı bulma,
sql injection korunma fix,
sql injection research,
sqlmap,
vulnerability research
3 Nisan 2014 Perşembe
Bir Pentest Hikayesi
Bu sefer teknik olmayan bir konuyla karşınızdayım. Başlıktan da anlaşıldığı gibi sizlere hikaye anlatacağım :)
Gerçekleştirmiş olduğum(uz) penetrasyon testlerinde karşılaştığımız problemleri, çözümleri, tecrübe edindiğimiz konuları, komik olayları vs.. anlatan ama detaylarında yeni başlayan arkadaşlar için faydalı olabilecek bir yazı dizisi planlamaktayım.
Sabahın 05:00 sularında uyandırıldım. Uyku sersemliğiyle telefonda anladığım kadarıyla sektöründe Türkiye'nin önemli firmalarından birinin terminal sunucusu ransomware saldırısına uğramış. Hemen hazırlandım ve yola çıktım. Diğer ekip arkadaşlarımda saldırıya maruz kalan firmaya doğru yol aldılar.
Firmaya vardığımızda tahmin ettiğimiz şekilde sunucuya bir text dosyası bırakılmış ve ilgili firmanın verilerini encrypt ettiğini ve encrypt edilen verilerin açılması için fidye istenmekteydi.
Birkaç saat boyunca çeşitli yöntemlerle (firewall logları ve ilgili/şüpheli makineler üzerinde windows logları, son çalıştırılan dosyalar, şüpheli dosyalar, sistem başlangıcı, regedit, çalışan servisler, portların taranması, dinlenen portların tespiti vs..) saldırıya dair izleri araştırdık.
Bu analiz süreci devam ederken IT sorumlusuna enfekte olmuş sunucunun Local Administrator parolasının ne olduğunu sordum. Ve tahmin ettiğim yanıt hiç gecikmeden geldi: 123456 :)
Bu tip hacking saldırıları genellikle; zayıf parola kullanımıyla beraber dışarıya açık olan uzak masaüstü servisi (RDP) ve MSSQL servisi, eski işletim sistemi zafiyetleri, mail yoluyla gönderilen fatura vb. gibi görünen zararlı dosyaların kullanıcının sisteme bulaştırılmasıyla böyle sonuçlara zemin oluşturmaktadır.
Firma çok şanslıydı.. Logları incelememiz sonucunda bu olayın başlangıç zamanından tam 1 dakika önce şirketimizin sistem çözümleri departmanında çalışan arkadaşımız tarafından farklı bağımsız bir lokasyona yedek alınmıştı. Bu yüzden verilerin kurtarılmasıyla uğraşmamıştık direkt olarak çözüm odaklı davrandık çünkü business continuity (iş sürekliliği) önemlidir. Aynı veya benzer pozisyondan gol yiyebilirsiniz. Bu yüzden olayın kaynağı tespit etmek, saldırı yüzeyini analiz etmek ve gedikleri tıkamak gerekir.
Pentest için anlaşılıp çalışma tarihi aldıktan sonra hazırlığımızı yapıp belirlenen tarihte firmaya gittik. Vakit kaybetmeden testlere başladık. Sırasıyla hibrit (otomatik ve manuel) bir şekilde önce sistemleri keşfetme-bilgi toplama, zafiyet taraması ve son olarak da tespit edilen bulgular özelinde exploiting işlemlerini yaptık. Ayrıca, sosyal mühendislik kapsamında phishing testi de yapılacaktı. Bunun için arama motorlarından elde ettiğimiz firma çalışanlarının mail adreslerine belirlediğimiz senaryo kapsamında zararlı yazılım (trojan) bulaştırılmaya çalışıldı. 21 kişiden 13 tanesi zararlı yazılımı açtı ve bilgisayarına bulaştırmıştı. Bu rakamlar çok tehlikeli..
Testin son demleriydi, elde ettiğimiz bulguları toparlıyorduk. Ben son kez sunucuların bulunduğu IP bloğunda farklı metotlarla tekrar bir port taraması gerçekleştirdim ve önceden keşfedemediğimiz bir sunucu keşfettim. 8090 portunda Apache Tomcat koşuyordu. Hemen web browserden kontrol ettim. Default Apache Tomcat parolalarını denedim ve bir tanesi tuttu. Yönetim bölümünün Deploy kısmından örnek ekran görüntüsünde görüldüğü gibi içeriye komut çalıştırabileceğim basit bir JSP shell (cmd) import ettim:
Yüklenen "cmd" isimli shell ile Windows üzerinde SYSTEM yetkileriyle komutlar yürütebilecektik. Bu shell ile Windows için Administrator yetkilerine sahip bir kullanıcı hesabı oluşturuldu ve bu kullanıcı Remote Desktop User grubuna dahil edilerek işletim sistemine uzaktan bağlantı sağladık. Daha sonra bu işletim sisteminde daha önceden oturum açmış olan kullanıcıların şifrelerini/parolalarını mimikatz aracıyla ele geçirdik.
Elde edilen bu şifreler/parolalar ile networkte bulunan diğer (SQL Server, SharePoint, Exchange vs..) sunuculara erişim sağlandı. Tüm sistem elimizin altındaydı. Son olarak Domain sunucusuna sızdığımızı IT müdürüne bildirdik. Müdür telaşla gelip "testi sonlandırın artık, tüm sistem deşifre oldu" demesiyle işte o zaman yüzümüzde tebessümler eksik olmuyordu.. :)
Gerçekleştirmiş olduğum(uz) penetrasyon testlerinde karşılaştığımız problemleri, çözümleri, tecrübe edindiğimiz konuları, komik olayları vs.. anlatan ama detaylarında yeni başlayan arkadaşlar için faydalı olabilecek bir yazı dizisi planlamaktayım.
Sabahın 05:00 sularında uyandırıldım. Uyku sersemliğiyle telefonda anladığım kadarıyla sektöründe Türkiye'nin önemli firmalarından birinin terminal sunucusu ransomware saldırısına uğramış. Hemen hazırlandım ve yola çıktım. Diğer ekip arkadaşlarımda saldırıya maruz kalan firmaya doğru yol aldılar.
Firmaya vardığımızda tahmin ettiğimiz şekilde sunucuya bir text dosyası bırakılmış ve ilgili firmanın verilerini encrypt ettiğini ve encrypt edilen verilerin açılması için fidye istenmekteydi.
Birkaç saat boyunca çeşitli yöntemlerle (firewall logları ve ilgili/şüpheli makineler üzerinde windows logları, son çalıştırılan dosyalar, şüpheli dosyalar, sistem başlangıcı, regedit, çalışan servisler, portların taranması, dinlenen portların tespiti vs..) saldırıya dair izleri araştırdık.
Bu analiz süreci devam ederken IT sorumlusuna enfekte olmuş sunucunun Local Administrator parolasının ne olduğunu sordum. Ve tahmin ettiğim yanıt hiç gecikmeden geldi: 123456 :)
Bu tip hacking saldırıları genellikle; zayıf parola kullanımıyla beraber dışarıya açık olan uzak masaüstü servisi (RDP) ve MSSQL servisi, eski işletim sistemi zafiyetleri, mail yoluyla gönderilen fatura vb. gibi görünen zararlı dosyaların kullanıcının sisteme bulaştırılmasıyla böyle sonuçlara zemin oluşturmaktadır.
Firma çok şanslıydı.. Logları incelememiz sonucunda bu olayın başlangıç zamanından tam 1 dakika önce şirketimizin sistem çözümleri departmanında çalışan arkadaşımız tarafından farklı bağımsız bir lokasyona yedek alınmıştı. Bu yüzden verilerin kurtarılmasıyla uğraşmamıştık direkt olarak çözüm odaklı davrandık çünkü business continuity (iş sürekliliği) önemlidir. Aynı veya benzer pozisyondan gol yiyebilirsiniz. Bu yüzden olayın kaynağı tespit etmek, saldırı yüzeyini analiz etmek ve gedikleri tıkamak gerekir.
Bu arada siber olay müdahale çerçevesinde yapılan analizler neticesinde bu ransomware vakasından tek bir sunucu etkilenmişti ve tehdit aktörünün yerel ağda başka sunuculara karşı yatay yayılım yapmadığı gözlemlendi.
Çalışmalar sabahın erken saatlerinden gece saat 02:00'a kadar sürdü ve bu konuyu başarılı bir şekilde sonlandırmış olduk. Tabi müşterimizin artık siber güvenlik hususunda farkındalığı vardı ve bu konuda yapılması gerekenleri bütçeleri dahilinde hızlıca gerçekleştirmeye karar verdiler. Müşteri siber güvenlik durum ve ihtiyaç analizi yapıldı, bir takım hizmet/ürün kalemi ortaya çıkmıştı, onlardan birisi de tabi ki pentest (penetrasyon testi/sızma testi) idi :)
Pentest için anlaşılıp çalışma tarihi aldıktan sonra hazırlığımızı yapıp belirlenen tarihte firmaya gittik. Vakit kaybetmeden testlere başladık. Sırasıyla hibrit (otomatik ve manuel) bir şekilde önce sistemleri keşfetme-bilgi toplama, zafiyet taraması ve son olarak da tespit edilen bulgular özelinde exploiting işlemlerini yaptık. Ayrıca, sosyal mühendislik kapsamında phishing testi de yapılacaktı. Bunun için arama motorlarından elde ettiğimiz firma çalışanlarının mail adreslerine belirlediğimiz senaryo kapsamında zararlı yazılım (trojan) bulaştırılmaya çalışıldı. 21 kişiden 13 tanesi zararlı yazılımı açtı ve bilgisayarına bulaştırmıştı. Bu rakamlar çok tehlikeli..
Testin son demleriydi, elde ettiğimiz bulguları toparlıyorduk. Ben son kez sunucuların bulunduğu IP bloğunda farklı metotlarla tekrar bir port taraması gerçekleştirdim ve önceden keşfedemediğimiz bir sunucu keşfettim. 8090 portunda Apache Tomcat koşuyordu. Hemen web browserden kontrol ettim. Default Apache Tomcat parolalarını denedim ve bir tanesi tuttu. Yönetim bölümünün Deploy kısmından örnek ekran görüntüsünde görüldüğü gibi içeriye komut çalıştırabileceğim basit bir JSP shell (cmd) import ettim:
Elde edilen bu şifreler/parolalar ile networkte bulunan diğer (SQL Server, SharePoint, Exchange vs..) sunuculara erişim sağlandı. Tüm sistem elimizin altındaydı. Son olarak Domain sunucusuna sızdığımızı IT müdürüne bildirdik. Müdür telaşla gelip "testi sonlandırın artık, tüm sistem deşifre oldu" demesiyle işte o zaman yüzümüzde tebessümler eksik olmuyordu.. :)
14 Mart 2014 Cuma
Python ile Banner Grabbing Mantığı
Genellikle Vulnerability Assessment tarayıcılarının genel olarak çalışma mantığı; hedef sistemi tararken öncelikle port taramasıyla hedef sistemin açık veya filtreli portlarını keşfeder. Açık portlarda yer alan servis bilgisini (hizmet, software vb.) keşfettikten sonra tarayıcının kendi veritabanında bulunan güvenlik zafiyeti barındıran servis ismiyle karşılaştırır eğer eşleşiyor ise bu sistemde XYZ zafiyeti vardır demektedir...
Tabi bu sadece possible yani olabilir demektir. Çünkü Vulnerability Assessment tarayıcıları keşfedilen zafiyeti sistemde gerçekten olup olmadığını doğrulamaz.
Evet belki hedef sistemin bir portunda çalışan XYZ servisinde daha önceden Security Reseacher'ler tarafından keşfedilmiş bir zafiyet olabilir fakat hedef sistemde belki bu zafiyet fixlenmiştir (kapatılmıştır)? Veya serviste sorun vardır tam çalışmıyordur bile.. İşte bu saydığım ve bunun gibi tarayıcılardan tarafından keşfedilen zafiyetlerin durumuna false-positive demekteyiz.
False-Positive kavramını basitçe anlatan bir diyagram çizdim:
Yukarıdaki belirttiğim konuya istinaden Vulnerability Assessment tarayıcıların temel çalışma mantığını Python'da socket modülünü kullanarak belirlenen hedef sisteme 21 FTP portundan bağlanıp önceden belirlediğimiz zafiyet barındıran FTP servislerinin karşı tarafta olup olmadığını eşleştiren küçük bir uygulama yapacağız.
Tabi bu sadece possible yani olabilir demektir. Çünkü Vulnerability Assessment tarayıcıları keşfedilen zafiyeti sistemde gerçekten olup olmadığını doğrulamaz.
Evet belki hedef sistemin bir portunda çalışan XYZ servisinde daha önceden Security Reseacher'ler tarafından keşfedilmiş bir zafiyet olabilir fakat hedef sistemde belki bu zafiyet fixlenmiştir (kapatılmıştır)? Veya serviste sorun vardır tam çalışmıyordur bile.. İşte bu saydığım ve bunun gibi tarayıcılardan tarafından keşfedilen zafiyetlerin durumuna false-positive demekteyiz.
False-Positive kavramını basitçe anlatan bir diyagram çizdim:
Yukarıdaki belirttiğim konuya istinaden Vulnerability Assessment tarayıcıların temel çalışma mantığını Python'da socket modülünü kullanarak belirlenen hedef sisteme 21 FTP portundan bağlanıp önceden belirlediğimiz zafiyet barındıran FTP servislerinin karşı tarafta olup olmadığını eşleştiren küçük bir uygulama yapacağız.
Kaydol:
Kayıtlar (Atom)