7 Ağustos 2018 Salı

Bloodhound Ile Domain Avı






Windows domain ortamlarında yetkili kullanıcıların tespiti ne yaptığını bilen bir saldırganın mutlaka gerçekleştireceği bir eylemdir. Tabii ki, bir saldırganın neler yapabileceğini ve ağın güvenlik seviyesini test eden sızma testi uzmanı için de aynı durum geçerli.


BloodHound

@_wald0@CptJesusve @harmj0y tarafından geliştirilen BloodHound, ele geçirilen Windows cihazlar üzerinden Active Directory ilişkilerini analiz etmek üzere geliştirilmiş bir araç. BloodHound ile yetkili kullanıcı, domain admin ve domain controller tespiti yapabilir, hangi domain kullanıcılarının nereye bağlanma yetkisi olduğunu ve ilgili istatistikleri grafikler üzerinden görüntüleyebilirsiniz.


Öncelikle BloodHound kuralım. Eğer Kali Linux kullanıyorsanız, apt ile BloodHound kurabilirsiniz.
Eğer başka bir işletim sistemi kullanıyorsanız aşağıdaki linki ziyaret ederek BloodHound indirebilirsiniz:

https://github.com/BloodHoundAD/BloodHound




BloodHound'u kurduktan sonra Neo4j veri tabanı ile bağlantısını sağlamak gerekli. Bunun için default olarak bolt://127.0.0.7687 'yi kullanabilirsiniz.




Aksiyon Zamanı!

İşe domain'e dahil bir cihazı ele geçirmekle başlayalım.


Bulunduğumuz dizine BloodHound'un önceden derlenmiş binary dosyalarından birini veya powershell betiğini kullanabiliriz.

bkz: (https://github.com/BloodHoundAD/BloodHound/tree/master/Ingestors)

Sıra, karşı tarafa dosyayı yüklemekte.



Karşıya attığımız ingestor'u çalıştırdığımızda, bulunduğumuz dizinde üç farklı dosya oluşturduğunu görüyoruz.



Şimdi bu dosyaları kendi sistemimize indirip karşı taraftan silelim.



BloodHound'u çalıştıralım ve veri tabanına bağlanalım.



İndirdiğimiz .csv uzantılı dosyaları BloodHound'a tanımlattıktan sonra, BloodHound bizim için Active Directory yetkilerine ve ilişkilerine dair grafikler üretecektir.



Grafiklerden ziyade var olan kaç domain admin oturumu olduğu, oturumların hangi cihazlar arasında gerçekleştiği gibi bilgileri görüntüleyebiliriz. Bunlara ek olarak, domain çerçevesinde kaç kullanıcı, bilgisayar, grup ve oturum olduğunu görüntüleyebiliriz.



Ve son olarak önceden oluşturulmuş analitik sorgular gerçekleştirebiliriz.



Daha da güzeli, her zaman kendi sorgularımızı, böylece kendi grafiklerimizi oluşturabiliriz.

BloodHound üzerine daha fazla bilgi için tavsiyem https://wald0.com/?p=68









on 07 Ağustos by Berk Cem Göksel |   Edit

18 Haziran 2018 Pazartesi

Tarayıcı İstismarı - Session Hijacking




Birçok platformda keşfedilen XSS açıklarından söz edildiği gözünüze çarpmıştır. Özellikle bug bounty için konuşacak olursak, bug bounty programı kapsamındaki sayfada bir pop-up penceresi açtığımız anda, ödül bizimdir.

Fakat gerçek bir saldırıda, saldırganların bu tür bir işleme asla girişmeyeceğini göreceksinizdir.

Aşağıdaki XSS payload'unu daha önce görmüşsünüzdür. Kendisi XSS bulmak için kullanılan basit bir javascript kodu.




Eğer saldırgan stored XSS açığı olan bir forma yukarıdaki satırı girecek olursa, bulguyu ifşa etmiş olacağından büyük ihtimalle daha açıktan yararlanamadan açık kapatılacaktır. Benzer şeyler, sızma testleri için de geçerli olabilir.

Ve yine gerçek bir saldırıda olduğu gibi, sızma testlerinde de sadece alarm üreterek XSS açığını doğruladığımızda pek de açığı istismar etmiş olmuyoruz. Bug bounty ile gerçek bir saldırının ve bir sızma testinin aynı şey olmadığını bilmemiz gerekiyor. Birçok kişi XSS tespit edebilirken, bunu sistematik bir şekilde istismar edebilen ve bunu geçerli bir saldırı vektörü olarak kullanabilen kişilerin sayısı daha az. Eğer amaç bug bounty ise bile --ki bug bounty'ye karşı hiçbir şeyim yok, XSS açıklarının istismarında ustalaşmak(tespitinden söz etmiyorum) sizi daha iyi bir bug avcısı yapacaktır.

Açıkçası, bu serinin amaçlarından biri de bunu göstermek.

Eğer XSS'e yeniyseniz, buraya.


Şimdi basmakalıp payload'umuza dönelim.



Not: Yukarıdaki kısa payload hakkında söylemeyi unuttuğum bir şey var.  Kendisi XSS tespitinde en sık kullanılan payload. Bu kadar sık kullanıldığından bir WAF  veya IPS/IDS tarafından tespit edilmesi ve engellenmesi çok muhtemel. Bu nedenle çoğu saldırgan(ve siber güvenlik uzmanı) çeşitli filtre atlatma teknikleri geliştirir/kullanır. Bunlardan bir kısmına aşağıdaki link'ten ulaşabilirsiniz.

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet


Bir pop-up penceresi çıkarmak hoş. Bakalım ekrana başka neler basabiliriz.


Şimdi bu payload'u biraz değiştirerek, çok çok çok ama çok teknik bir payload oluşturuyorum.

(bkz: https://eksisozluk.com/mubalaga)


Şimdi karşımıza çıkan pop-up penceresinde sayfayı ziyaret eden kişinin çerez bilgilerini görüntüleyebiliriz. Bu durumda bizim için ekstra önem taşıyan bilgiler ise, oturum çerezleri, (session cookie).

Örneği DVWA üzerinden vereceğim. Eğer duymadıysanız kendisi çeşitli web saldırılarını deneyip görebileceğiniz bir lab ortamı. Fakat eksikleri var. XVWA'yı tavsiye ederim.


Ana sayfayı ziyaret ettiğimizde bir kullanıcı giriş sayfasıyla karşılaşıyoruz.



Formu doldurduğumuzda gönderilen POST isteğine bakacak olursak, bize daha giriş yapmadan bir Session ID atandığını göreceğiz. (Acaba üst üste çok sayıda GET isteği göndersek atayabileceği  Session ID değerlerini tüketebilir miyiz? )



An itibariyle bize atanan Session ID'nin giriş yapma yetkisi yok. Fakat POST isteğini gönderdiğimde, eğer kullanıcı adım ve parolam doğruysa bu oturum çerezi yetkili olarak tanımlanacak.

Giriş yaptıktan sonra XSS açığı olan forma gidiyorum ve  bahsettiğimiz süper-fantastik XSS payload'unu giriyorum





İsteği karşıya yolladığımda, kendi tarayıcıma atanan cookie değerlerini görebilirim.



Başka bir tarayıcı ile aynı sayfayı ziyaret edersem,  tarayıcıya farklı bir Session ID atandığını görürüm. Eğer bu değeri yukarıdaki değer ile değiştirirsem, başka bir kullanıcının oturumunu ele geçirmiş, yani başarılı bir Session Hijacking saldırısı gerçekleştirmiş olurum.

7 Farkı Bul


Buradaki sorun ne? Kendi tarayıcımın oturum çerezlerini ele geçirmemin bana bir faydası yok. Artık yavaş yavaş pop-up pencerelerinden vazgeçebiliriz.

Aşağıdaki gibi bir javascript kodu başka bir kullanıcının sahip olduğu cookie bilgilerini kendi IP adresimiz üzerinde sunduğumuz bir netcat bağlantısına basmakta kullanılabilir.

DVWA üzerinde Reflected XSS penceresine gidip bu payload'u bir GET isteği içinde karşıya gönderebiliriz. Fakat bu payload'u DVWA'ya girdiğimizde + karakterinin sorun oluşturduğunu göreceğiz. Bunun nedeni karşıya gönderilen karakterler arasından + karakterinin URL encode edilmiyor olması. (+) karakterini %2B şeklinde encode ettiğimiz zaman bu problemin çözüldüğünü görüyoruz.

Elde ettiğimiz komutun son hali,




Sayfayı ziyaret eden kullanıcıların çerezlerini elde etmek için, stismar ettiğimiz açığın bir stored XSS açığı olmasına gerek yok. Basit bir şekilde, oturumu devam etmekte olan kullanıcılara link yollayabiliriz. Burası sosyal mühendislik becerilerinin döktürüldüğü yer :) Bizi teknik anlamda ilgilendirmediği için üzerinde durmuyorum.

Öncelikle bize gelen bağlantıyı yakalaması için bir netcat listener açalım ve port 80 üzerinden gelen bağlantıları dinlemeye başlayalım. Tabii ki, bu sırada IP adresimizi not etmekte de fayda var.



Şimdi ise kullanıcıya göndereceğimiz link'i hazırlayalım.

Kullanıcı bu linki ziyaret ettiğinde (eğer aynı tarayıcı üzerinde süregelen bir oturumu varsa) cookie bilgileri tarafımıza iletilecektir.






Elde edilen oturum çerezi bir proxy aracılığıyla web uygulamasına gönderildiğinde, kullanıcının oturumu ele geçirilecektir. Bu işlemi kolaylaştırmak için eski sürüm bir Firefox üzerinde CookiesManager+ kullanabiliriz. Eski sürüm Firefox kurmakla ile uğraşmayayım, hacklenirim derseniz  aynı işlemi yapacak birçok başka aracın mevcut olduğuna eminim.

BONUS - Thanks to: (@rodoassis) A.K.A.  Brute 

Tarayıcı üzerinde ele geçirecek cookie değerleri olmayabilir veya çerezler HttpOnly ile korunuyor olabilir.

Çıkmaz Sokak?  

Kesinlikle hayır. XSS, iyi istismar edildiğinde güçlü bir saldırı vektörüdür. Çerezler çalınamıyor olsa bile, XSS üzerinden kullanıcının tarayıcısını ele geçirmek mümkündür.


Bunu gerçekleştirmek için sunucuya enjekte edeceğimiz bir payload'a ihtiyacımız olacak.

svg onload XSS vektörünü kullanarak oluşturulan javascript payload'unu biraz daha yakından inceleyecek olursak,
Öncelikle kodumuzun belirli aralıklarda çalışmasını sağlayacak bir fonksiyona ihtiyacımız var. 

setInterval() fonksiyonunun çalışması için bunu başka bir javascript fonksiyonu içine grupluyoruz.


Bir script elementi oluşturuyoruz.

Şimdi ise sıra tarayıcının bağlanacağı IP adresi ve port'u tanımlama zamanı


Şimdi ise elementi var olan HTML dosyasının gövde(body) kısmına gömmekte.

Payload'umuzu biraz daha kısaltacak olursak (7 byte deyip geçmemek lazım)

Şimdi ise saldırganın terminalinde çalışacak bir listener'a ihtiyacımız var.

Artık sayfayı ziyaret eden tarayıcı düzenli olarak saldırgana bağlanacak ve saldırganın sağladığı javascript komutlarını çalıştıracak.

Aşağıdaki video'da bunun nasıl işlediğini görebilirsiniz.


Eğer XSS saldırı vektörleri ilginizi çekiyorsa brutelogic.com.br'yi ziyaret etmenizi tavsiye ederim.

Bonus bölümünün orjinalini daha detaylı halde https://brutelogic.com.br/blog/using-xss-to-control-a-browser/ adresinde bulabilirsiniz.

Thanks to @rodoassis for letting me use his material and writing it in the first place.
on 18 Haziran by Berk Cem Göksel |   Edit

1 Mayıs 2018 Salı

Ericcsson LG iPECS NMS - Cleartext Credential Disclosure



Zaman zaman sızma testlerinde 0-day açıkları ile karşılaşıyorum. Çoğu zaman böyle bir aksiyona girmek gereksiz olsa da, güvenlik yamaları tam olan, sıkı ağlarda Nessus gibi zafiyet tarama araçlarının doğal olarak atlayacağı basit 0-gün açıkları, iplik söküğünün başlangıcı olabiliyor. Ele geçirilen bir sunucu üzerinden gelecek olan bir domain parola hash'i domain controller'a giden yolun başlangıcı olabilir.

Binary dosyalarını fuzzlamak genellikle zaman kaybı olsa da, karşılaştığım IP kamera, IP telefon ve  Parmak izi okuyucusu [bunun hikayesi çok güzel :) ] gibi cihazların web uygulamalarını fuzzlamak pek eğlenceli olabiliyor.

Not: Burada dikkat edilmesi gereken önemli bir unsur var. Bu tür cihazları kolay bir şekilde hizmet dışı bırakabilirsiniz. Körü körüne değil, cihazlara arkada ne olup ne bittiğini anlayarak yaklaşmak elzem.

Bu sefer bir Network Management System yazılımı ile karşılaştım.

Bilgi Toplama

Bir NMS ürününden beklediğimiz birkaç şey var:

  • Ağdaki cihazların tespiti
  • Ağdaki cihazların izlenmesi
  • Ağ performansının analizi 
  • Ağdaki cihazların yönetimi
  • Özelleştirilebilir uyarı ve alarmlar

Küçük bir Google araması, yazılımın ne yaptığına dair bir bilgi verdi. Ürünün kendi sayfasını ziyaret ettiğimizde ürüne ait bir datasheet olduğunu görüyoruz. Bütün bunlar ürünün nasıl çalıştığını anlamamıza yardımcı olması için.



Ürünü exploit-db.com, securityfocus.com, cvedetails.com ve birkaç forumda arattığımda, herhangi bir istismar kodu veya CVE ID bulamadım. Büyük ihtimalle, daha önce birilerinin istismar etmediği bir uygulama.

Yazılımın web arayüzünü tarayıcı ile ziyaret edecek olursak. (Yazılımın güncel versiyonununun bu olduğu sonradan ortaya çıktı) aşağıdaki gibi bir ekranla karşılaşıyoruz.



Daha şimdiden iki problemimiz var gibi gözüküyor.

- 1) CAPTCHA veya benzeri bir doğrulama yok gibi (acaba bir lockout mekanizması var mı?)
- 2) Sayfa herhangi bir şifreleme kullanmıyor

Buraya yapılacak basit bir MiTM saldırısı kullanıcı giriş bilgilerini cleartext olarak saldırgana ifşa edecektir. Üstelik uygulama bruteforce parola tahmin saldırılarına izin verecekmiş gibi gözüküyor. (Sadece daha bilmiyoruz)

Adet yerini bulsun diye yanlış kullanıcı adı ve parola ile giriş denemesi gerçekleştiriyorum:



Dönen cevaba bakacak olursak:




Bruteforce gerçekleştirmek için kolaylıkla hydra veya benzeri bir araca failure string olarak "Wrong User Id or Password" tanımlayabiliriz. Ama (hiç sanmasam da) bu bir lockout durumu gerçekleştirebileceği için bu safhada böyle bir şey girişmiyorum. Hem, gerek de yok. Bu en son çare.


Bir kullanıcı giriş panelinin arkada bir veri tabanı kullanması çok muhtemel. Dahası, arka tarafta bir veri tabanı kullanmayan bir NMS yazılımı ender rastlanan bir şey olurdu. Akla ilk gelen şey olası bir SQL injection açığı.

Id ve Password kutucuklarına rastgele girdiler girdikten sonra gönderdiğim POST isteğini burp'de yakalıyorum ve aşağıdaki gibi değiştiriyorum:




Bu bana giriş yetkisi verdiğine göre,

- 3) bir SQL injection açığı ile karşı karşıyayız. (CVE-2018-9245)




Normalde işimiz daha kolay olurdu,  fakat SQLi üzerinden authentication bypass gerçekleştirdiğimizde yukarıdaki hata mesajını alıyoruz ve uygulama bizi tekrar giriş sayfasına yönlendiriyor.

Eminim bunun üstesinden gelmek için bir sürü başka yol düşünülebilir. Ben uygulamanın hatalı yapılandırılmasından kaynaklanan bir hassas bilgi ifşasını kullandım.

Tekrar Burp-Suite ile araya girdiğimizde, giriş yaptıktan sonra gönderdiğimiz ikinci POST isteğine bakıyoruz. 

İlk isteğimize bir session id çerezi dönmesini beklerdik. Bunun yerine aşağıdaki çerez ile karşılaşıyoruz:

mainTab_selectedChild=sysinfotab 

Burada başka bir açıktan söz edebiliriz,

- 4) Hatalı Doğrulama Mekanizması (CVE-2018-10285)

Uygulama doğrulama sonrası tarayıcıya bir oturum çerezi atamadığından buradan oturum kontrollerinin yapılmadığı ya da eksik yapıldığı çıkarımına varabiliriz. Bunu test etmek için, yukarıdaki isteği kaydedelim ve kullanıcı girişi yapmadan karşıya gönderiyorum.

Dönen cevaba bakacak olursak,




bunun işe yaramadığını göreceğiz. Uygulama oturum çerezleri kullanmasa da, bu sayfanın ziyaret edilmesi için son birkaç dakika içinde (kaynak kodu incelemek lazım) geçerli bir kullanıcı girişi yapılmış olması gerekiyor. Bu noktada SQL injection komutumuzu gönderdikten hemen sonra 2. POST isteğimizi gönderdiğimiz takdirde, az önce olduğu gibi giriş yapıyoruz, fakat uygulamadan hemen geri atılıyoruz.

işte işler burada ilginçleşiyor...

İkinci POST isteğimize dönen HTTP cevabına bakacak olursak,


Yeni bir bulgu ile karşılaşıyoruz

- 5) Hassas Bilgi İfşası (CVE-2018-10286)

Veri tabanı yönetici kullanıcısının ve parolasının cleartext olarak ifşa edildiğini görüyoruz. MiTM saldırısı gerçekleştiren bir saldırgan, bütün bu bilgileri cleartext olarak görebilirdi, ancak bu durumda, böyle bir şey yapmaya ihtiyacı yok.

Not: Veri tabanı parolasını cleartext elde etmiş olmamız güzel haber. Bunu tek başına SQL injection açığından yararlanarak yapamazdık. Ancak parolanın şifrelenmiş halini görüntüleyebilirdik. Eğer parola uzun ve karmaşık bir parola ise, şifreyi kırma şansımız oldukça düşük olurdu.


Uygulama otomatik olarak 2. POST isteğimize cevap dönen veri tabanı kullanıcı ve parola bilgilerini 3. POST requestimizin içinde gönderiyor.


Buradaki  "Adam zaten kendi kullanıcı parolası ile giriş yapmış, kendi bilgilerini görüntülese ne çıkar?" mantığı, görüdüğümüz üzere son derece tehlikeli ve güvensiz bir yaklaşım.

Şimdi bu 3. POST isteğine dönen cevaba bakalım,



Artık NMS web arayüzünün admin kullanıcı adı ve parolasını öğrendiğimize göre, bu kullanıcı adı ve parolayı kullanarak arayüze bağlanabiliriz.

İsteğin devamını görüntüleyecek olursak, başka bilgilerin de ifşa olduğunu görebiliriz.

Bunların dışında,

/nms/js/module/define.js
/nms/index.html

gibi dizinleri kullanıcı girişi yapmadan ziyaret ederek kaynak kod içerisinden başka hassas bilgilere ulaşabiliyoruz.




Bütün bunlar çok güzel ama biraz zaman alıyor. Bu işlemlerin hepsini basit bir script ile otomatik bir şekilde gerçekleştirebiliriz.

birşeyler.py 

Öncelikle yapmamız gereken şeyleri bir sıralayalım.

1) SQLi üzerinden giriş gerçekleştirmek (Hatırlarsak, yakın zamanda giriş yapmadıysak bir sonraki istekler kabul edilmiyordu.)

2) Karşıya nms_start komutunu barındıran bir POST isteği göndermek

3) İsteğe gelen cevap içinden veri tabanı kullanıcı ve parolasını elde etmek

4) Veri tabanı kullanıcı adı ve parolasını 3. bir POST isteği içinde karşıya göndermek

5) Son gönderdiğimiz isteğe gelen cevap içinden NMS arayüzünün yönetici kullanıcı adı ve parolasını öğrenmek


Yeni bir dosya oluşturup karşıya SQL injection komutumuzu gönderelim.


Şimdi nms_start komutunu barındıran POST isteğini gönderelim ve dönen cevabı db_cred_dump değişkenine atayalım.

POST isteğine dönen cevaptan kullanıcı adı ve parolayı ayrıştıralım. Bunu yapmak için basit bir regex kullanabiliriz. Veri tabanı kullanıcı adı ve parolasını sırasıyla postgre_db_user ve postgre_db_pwd değişkenlerine değer olarak atayalım.

Elde ettiğimiz veri tabanı kullanıcı adı ve parolasını son bir POST isteği içinde karşıya gönderelim. Dönen cevabı ise user_dump değişkenine değer olarak atayalım.

user_dump içerisinden, listedeki ilk kullanıcının kullanıcı adı ve parolasını çekelim. İlk oluşturulan kullanıcı her zaman yönetici kullanıcı olacağından, bu işimizi görecektir. Bunun için de basit bir regex yazabiliriz.

Bir şeyler yanlış gider de, elde ettiğimiz dump içinden NMS yönetici kullanıcı adı ve parolasını alamaz isek manuel olarak dump'ı okuyabilmemiz için her şeyi bir dosyaya yazalım.

İşte bu kadar.
Scriptin tamamını exploit-db üzerinden görüntüleyebilirsiniz.

https://www.exploit-db.com/exploits/44515/

Sonuç

Düzenli olarak ağınızda Nessus, OpenVAS gibi zafiyet tarama araçları çalıştırabilir, bütün yamaları eksiksiz bir şekilde geçebilirsiniz. Kendi geliştirdiğiniz uygulamalarınız düzenli olarak sızma testlerinden geçiyor olabilir. Bütün bu çabalar, işlerinizi kolaylaştırması için satın aldığınız test edilmemiş bir ürünün karşısında boşa gidebilir. Daha önce üzerinde hiçbir açık tespit edilmemiş olan ürünlere ekstra dikkat etmekte var.

TL;DR

Hedef yazılım internete açık olmadığından scriptin nasıl çalıştığını gösterebilmek adına aşağıdaki sıkıcı videoyu çektim.





on 01 Mayıs by Berk Cem Göksel |   Edit

14 Nisan 2018 Cumartesi

Tarayıcı Istısmari - Mass Mailing Saldırıları


Amaç

Bu bölümün amacı siber suçluların kullandığı yöntemlerden sadece bir tanesinin nasıl işlediğini görmek. Buna ek olarak sosyal mühendislik testlerinde kullanılabilecek bir takım teknikleri göreceğiz. 

Saldırı Vektörü: Mass Mailing

Bir kurumun bütün çalışanlarına gönderilecek zararlı bir link veya dosya barındıran bir e-posta çok güçlü bir sosyal mühendislik eylemi olabilir. Birçok saldırgan, kurum ve kuruluşlara sızarken ilk erişimi mail yoluyla teslim edilen macro dosyaları üzerinden gerçekleştiriyor. 

MuddyWater APT Grubu'nun benzer bir şekilde ilk erişimi zararlı macro dosyaları üzerinden sağladığını hatırlayalım. 

Başlayalım

Gerçekleştireceğimiz mass mailing işlemi için Setoolkit'i kullanabiliriz. Kendimiz küçük bir script de yazabiliriz fakat Setoolkit bizim için bunu hızlı bir şekilde yapıyor. 

Öncelikle karşı tarafa göndereceğimiz inandırıcı bir dosya bulmak için küçük bir Google araması yapalım.






Hoşumuza giden bir PDF dosyasını indirelim.


Şimdi ise sıra PDF dosyasının içine zararlı yazılımımızı gömmekte. Bunu Metasploit kullanarak aşağıdaki gibi yapabiliriz


Şaka... :)

Bu biraz eskide kaldı. Artık bu işi macro dosyaları üzerinden yapıyoruz. Bu işlem için çoğu saldırganın da siber güvenlik uzmanının da kullandığı Powershell Empire Framework'ü kullanacağız. 


Hedef işletim sistemimize göre bir macro stager seçtikten sonra bunu kullanacağımız listener'a bağlayıp modülü çalıştıralım.


Bu bize bir dizi macro komutunu çıktı veriyor. Çıktıyı olduğu gibi kopyalayalım ve bir macro dosyası oluşturalım.



Kopyaladığımız çıktıyı macro dosyası içine yapıştırıyoruz ve dosyayı bir yere kaydedelim.



Teslim

Şimdi sıra oluşturduğumuz macro'yu teslim etmekte.

Öncelikle "zararlı" bir gmail hesabı oluşturalım ve daha az güvenilir uygulama desteğini etkinleştirelim. Bu özelliği etkinleştirmezsek Setoolkit mail göndermek için Gmail'i kullanamayacaktır.


Setoolkit'i çalıştıralım, Mass Mailing saldırılarını seçelim ve devam edelim. Şimdilik 1. şıkkı seçerek tek bir e-posta adresini hedef alalım. 


Eğer istersek bir e-posta adresi listesi tanımlayarak 2. seçeneği seçebiliriz. Böylece birçok e-posta adresine e-posta gönderebiliriz.

Ben bu işlem için hayali dostumuz Ramiz'in e-posta adresini kullandım.

Şimdi sırada e-posta'nın içeriğini hazırlamak var. Bu işlemi kurbanımızın zeka seviyesini göz önünde bulundurarak itina ile gerçekleştirmeliyiz. Bol bol yazım hatası, anlatım bozuluğu ve mantık hatası kullanmayı unutmamalıyız. (bkz: istihza)


Fakat bu şekilde gelen kutumuza baktığımızda orada bir e-posta göremeyeceğiz. Bu, Gmail zararlı yazılımı tespit ettiği için. Bunun üstesinden gelmek için ise, dosyayı basitçe zip ile sıkıştırıp şifreleyebiliriz.

Bunun için aşağıdaki gibi bir komut kullanabiliriz:

zip --encrypt Macro.zip macro.docx

Tabii ki, buna göre phishing e-postamızı da yenilemek gerekecek.


Şimdi gelen kutumuza bakacak olursak, e-posta'nın başarılı bir şekilde karşı tarafa ulaştığını görebiliriz.





Anlaşılan Setoolkit'e '/root/Blog/' gibi absolute path vermek pek da akıllıca değilmiş. Göndermek istediğimiz dosyaya dizinine cd'ledikten sonra Setoolkit çalıştırarak bu sıkıntıyı atlatabiliriz.

Kurban zip parolasını girip Word dokümanını açtığı takdirde ürettiğimiz stager çalışacaktır. Buna rağmen birçok mail sunucusu (hatta bazı güvenlik ürünleri) birden fazla kişiye gönderilen şifreli zip dosyalarını bloklayacaktır.

Peki Ama Tarayıcı Bunun Neresinde?

Şimdi aynı mass mailing saldırısını zararlı bir dosya yerine, zararlı bir link göndererek gerçekleştirelim. Gönderdiğimiz link ise bir kullanıcı giriş formu olsun. 


Setoolkit'i çalıştırdıktan sonra,

> 1) Social-Engineering Attacks 
> 2) Website Attack Vectors 
> 3) Credential Harvester Attack Method
> 2) Site Cloner

seçimlerini yaptıktan sonra, POST isteğinin yönlendirileceği IP adresini girelim. Şimdi sıra kopyalayacağımız sayfanın URL'sini bulmakta. 

Tamamen örnek vermek amacıyla,  CERN'ün kullanıcı giriş sayfasını kullandım.


Not: CERN'de çalışan biri hayatta buraya kullanıcı adı parolasını girmez diyecekseniz, demeyin. Mesele insanlara gelince ne olacağı hiç bilinmez. Burada kinaye yok. Gerçekten, çok daha saçma phishing senaryolarına kurban olan iş yerleri ile karşılaştım.


Hayali dostumuz Ramiz'e gelince, kendisi phishing e-mailimizi aldığında içindeki linke tıklayarak yukarıdaki sayfayı ziyaret ediyor. CERN nedir bilmediğinden sayfayı iş yerinin OWA sayfası ile karıştırıyor ve kullanıcı bilgilerini giriyor :)

Terminal ekranımıza dönecek olursak, "zararlı" sayfamıza bir POST isteğinin gönderildiğini görüyoruz.


Ramiz zayıf parola kullanımından dersini almış olmasına rağmen, güvenli tarayıcı kullanmayı bilmemekten gol yiyor. Setoolkit Ramiz'i orjinal sayfaya yönlendiriyor ve böylece Ramiz bilgilerini çaldırdığını farketmiyor.

Not: Eğer bir sayfaya kullanıcı bilgisi girdikten sonra sayfa yenilenir ve/veya tekrar giriş sayfasına yönlendirilirse, ilk ziyaret ettiğiniz sayfanın sahte olup olmadığını anlamak için tarayıcı geçmişine bakabilirsiniz. Bu bazı durumlarda işe yaramayabilir fakat phishing sayfalarının büyük çoğunluğu tarayıcıyı ele geçirmekten veya istismar kodu çalıştırmaktansa sadece giriş bilgisi avlarlar.

Sosyal Mühendislik Testlerinde Kullanımı

Setoolkit kurum ve şirketlere gerçekleştirilen sosyal mühendislik testlerinde tercih edilebilir. Saldırı bittikten sonra CTRL + C ile Setoolkit'i kapattığımızda, Setoolkit bizim için bir rapor hazırlıyor ve raporun absolute pathini terminal ekranına basıyor.


Bu raporu yukarıdaki gibi HTML dosyasını açarak veya Setoolkit'in oluşturduğu XML dosyasını açarak görüntüleyebiliriz.


Yukarıda da görüldüğü üzere, Setoolkit bizim için kaç kişinin linke tıkladığının, kaç kişinin ise formu doldurduğunun kaydını tutuyor. Geriye, bize olanları raporlamak kalıyor.


on 14 Nisan by Berk Cem Göksel |   Edit

14 Ocak 2018 Pazar

Tarayıcı Istismarı - Sayfa Klonlama




Önceki yazımdaki saldırının saldırgan perspektifinden nasıl gerçekleşebileceğine bir bakalım.

Setoolkit ile Sayfa Klonlama

Bilmiyorsanız, Setoolkit, birçok sosyal mühendislik saldırısı gerçekleştirmekte ve sızma testlerinde kullanmak üzere gerekli adımları hızlı bir şekilde gerçekleştirmekte kullanılan bir araç. 

Kali Linux üzerinde kurulu gelmekle birlikte, github üzerinden de indirilebilir https://github.com/trustedsec/social-engineer-toolkit

Yeni bir terminal açıp, terminale setoolkit yazarak çalıştırabiliriz.


Gerçekleştireceğimiz saldırı bir sosyal mühendislik saldırısı olduğu için 1. şıkkı seçiyoruz.



Web sayfası saldırı vektörleri için 2 diyoruz.




Gördüğümüz üzere setoolkit bize 8 tane seçenek sunuyor. Biz aynı sayfa üzerinden birden fazla saldırı gerçekleştireceğiz. Gerçek dünyada da birçok saldırgan bu şekilde saldırılar kullanmakta. Bu 
durumda 6. opsiyonu seçerek birden fazla saldırıyı aynı anda gerçekleştirebiliriz.

6. opsiyonu seçtiğimizd aşağıdaki görüntü ile karşılaşacağız. Bu seçceğimiz saldırıları gerçekleştirmek için kullanacağımız web sayfasını belirlemek için.



İlk yöntem ile SET tarafından oluşturulmuş çeşitli phishing sayfalarını kullanabilir,
İkinci yöntem ile var olan bir sayfayı klonlayabilir,
Üçüncü yöntem ile kendi oluşturduğumuz bir web sayfasını kullanabiliriz.

Biz var olan bir sayfayı klonlayacağımızdan, 2'yi seçelim.

Bu noktada SET bize NAT arkasında olup olmadığımızı soruyor. Saldırıyı bizimle aynı ağdaki birilerini hedef alarak gerçekleştireceksek no demeliyiz. İşleri basitleştirmek için böyle yapacağız.

Not: Saldırıyı internete açık bir sunucu üzerinden yapıyorsak SET'e sunucunun alan adını veya IP adresini tanımlamamız yeterli. Eğer saldırıyı NAT arkasından yapıyorsak  gerekli port forwarding kurallarını tanımlamalıyız. 

SET bize metasploit listener'ımızın hangi porttan dinlemesi gerektiğini ve klonlayacağımız sayfanın adresini soracak.

 

Gerkekli bilgileri tanımladıktan sonra, kullanacağımız saldırı türlerini seçebiliriz. Tüm saldırıları gerçekleştirmek için 6 yı seçebiliriz.


Biz 2 ve 3 üzerinden gideceğiz.

Senaryo:
Kurban, Setoolkit Multi-Attack Web Method ile oluşturulan bir phishing sayfasına yönlendirilir. Kurbanın buraya kullanıcı adı, parola, ikamet adresi,  tc kimlik numarası, kredi kartı bilgileri vb. girmesi amaçlanmıştır. Ancak kurban bunu yapmadığı takdirde (veya yapmasına rağmen üstüne bir de) bir tarayıcı exploiti çalıştırılarak, işletim sistemi ele geçirilir.

Seçimlerimizi tamamladıktan sonra 7 yi seçerek sayfayı oluşturalım.



Şimdi ise sıra, kullanmak istediğimiz istismar kodunu seçmekte. Bu noktada spesifik bir hedefimiz varsa, kullandığı tarayıcı versiyonuna hitap eden bir exploit seçmeliyiz. Hedefin kullandığı tarayıcının versiyonunu öğrenmek için bize ait zararsız bir sayfayı ziyaret etmesini sağlayabilir veya bir XSS açığından yararlanabiliriz.

 Birden fazla kişiyi hedef alan bir saldırı gerçekleştirmek istiyorsak en güncel ve en sık kullanılan hizmetlerden birini seçmek mantıklı olacaktır.

Sırada istismar başarılı olduğu takdirde çalıştıracağı payload'u seçmek var. İstersek 9 opsiyonu seçerek kendi oluşturduğumuz bir dosyayı hedef sistem üzerinde çalıştırabiliriz. Eğer bulunduğumuz ağda Egress Firewall kuralları varsa, egress buster ile birden fazla porttan bağlantı kurmayı deneyebilir veya DNS üzerinden bağlantı kurmayı deneyebiliriz. Ağda Deep Packet İnspection aktifse, reverse HTTPS payload'unu kullanabiliriz.



İşleri basitleştirmek için 1'i seçelim. SET bize tersine bağlantı için hangi portu kullanmak istdiğimizi soracak.



İstediğimiz bir portu seçebiliriz. SET arkada çeşitli metasploit komutları çalıştırarak biz hızlı bir şekilde exploit kodunu çalıştıracak ve arka plana atacak.


(Görseldeki IP adresi değişikliğini kaile almayınız.)


Artık SET' geri dönebilir sayfamızı host edebiliriz. Kurban sayfamızı ziyaret ettiğinde hem istismar kodu çalışacak ve işletim sistemini ele geçirmeye çalışacak, hem de kurban bilgilerini sayfaya girdiği takdirde aşağıdaki gibi bilgilerini elde edeceğiz



Fakat burada iki problem var

1) İstismar kodu çalışmazsa (yanlış bir adres çağırırsa, vb.) tarayıcı çökeceği için credential harvester metodu da başarısız olacaktır.

NOT: Her istismar kodu farklı çalıştığından, istismar kodu başarılı bir şekilde çalışsa bile tarayıcı kullanım dışı kalabilir

2) Kullanmak istediğimiz istismar kodu SET içinde tanımlı olmayabilir. (Bkz: kendimiz geliştirmiş olabiliriz. Oraya da geleceğiz.)


Öncelikle, 1. problemimizi elimine etmek adına istismar kodumuzu en son çare olarak çalıştırmalıyız. Diyelim SET üzerinde bulamadığımız bir istismar kodunu bulduk. Credential Harvester metodunu seçtik ve phishing sayfamızı oluşturduk. Aşağıdaki gibi, bağlanıldığı zaman bir exploit çalıştıracak zararlı bir web sayfası sunmaya başladık.


İstismar kodumuzun bulunduğu sayfayı başka bir sayfada sunarak SET tarafından oluşturulan index.html dosyasında bir takım değişiklikler yapabiliriz. Aşağıda 4. satıra sayfa açıldıktan 30 saniye sonra 192.168.1.24:8080:/oriYQLjCdRF sayfasına yönlendirme yapacak bir satır ekledim.



Bu fazlasıyla basitleştirilmiş tek satır kod, kurbanın bilgilerini phishing sayfamıza girmesi için 30 saniye tanıdıktan sonra, bir yönlendirme yaptı ve ziyaret ettiği ikinci sayfada istismar kodunu çalıştırdı.



İstismar kodunun başarıyla çalıştığını görebiliriz. Artık hedef bilgisayarı ele geçirmiş durumdayız.



on 14 Ocak by Berk Cem Göksel |   Edit