13 Eylül 2020 Pazar

TEHDİT İSTİHBARATI GÜNLÜKLERİ - 1

world map cyber ddos globe


Bu yazıda siber tehdit istihbaratının temellerinden bahsedeceğim. İlerleyen zamanlarda da uzmanlaştığım tehdit istihbaratı alanına dair daha detaylı yazılar yazmayı planlıyorum. Şimdilik, kısa bir giriş yapalım.


Siber Tehdit İstihbaratı Nedir?

Siber tehdit istihbaratı, siber tehdit verisinin kaynak ve güvenilirlik açısından değerlendirilmesini ve verinin rafine edildikten sonra sunuma hazır şekile getirilmesini ele alan bir döngüdür ve nihai amacı düzenli yönetilebilir istihbarat (actionable intelligence) elde etmektir. Siber tehdit istihbaratı, klasik istihbarat kaynaklarından birçok yönden farklıdır.

Klasik İstihbarat Kaynakları


HUMINT: Direkt veya dolaylı olarak insan etkileşimi ile toplanan bilgiyi kapsar. Forumlar üzerinden yapılan yazışmalar, telefon görüşmeleri, e-posta ve mesaj üzerinden gerçekleşen iletişimi de kapsar. Tehdit aktörleri tarafından kısmi olarak sıklıkla kullanılır.

GEOINT: Uydu üzerinden elde edilen verinin analiz edilerek hareketlilik tespiti ve konum belirleme gibi konuları ele alır.

MASINT: Sabit veya dinamik hedef kaynaklarının metrik, açısal, uzamsal ve modüler özelliklerini tespit etmeye ve tanımlamaya yönelik bilgi toplamaktır.

SIGINT: Elektronik cihazların sinyallerinin toplanması, analizi ve iletişimi ile elde edilen bilgilerdir.

OSINT: Erişime açık kaynaklar (blog, forum, sosyal medya vb.) üzerinden hedef hakkında bilgi toplanmasıdır.

Bazı Siber Tehdit İstihbaratı Terimleri


  • Veri, Enformasyon, Bilgi, İstihbarat

  • Tehdit

  • İndikatör

  • IoC

  • IoA

  • Hasım


Veri, Enformasyon, İstihbarat




Tehdit

Tehdit aktörlerinin olgunluk seviyelerinin belirlenmesinde üç faktör rol oynar:

  1. Niyet

  2. Kabiliyet

  3. Fırsat


Bir tehdit aktörünün başarılı bir sızma gerçekleştirmesi için gerekli zamanı ve kaynakları saldırıya ayırması gerekmektedir. Ek olarak, aktörün yararlanabileceği bir fırsatın mevcut olması ve aktörün bu fırsatı değerlendirecek kabiliyete sahip olması gerekmektedir. Tehdit, bu üç elementin de mevcut olduğu durumlarda mevcuttur.


Indikatör


Örneğin; www.abc.com adresinden elde edilen veriler, komuta kontrol sunucusu ile anlamlandırılarak bir ölçü elde edilebilir.

IoC

IoC'ler sistemler üzerinden elde edilen, tehdide dair kalıntılardır. Ağ trafiği, disk içeriği ve bellek içeriği üzerinden elde edilebilirler. 

IoC Örnekleri

Genel olarak bir olaya ilişkin IoC'ler aşağıdaki bilgiler ile başlar:

  • Dosya İmzaları 

Saldırıda kullanılan zararlı yazılımların imzaları

  • IP Adresleri

Komuta kontrol sunucusunun IP adresi 

  • Alan Adları

Phishing için hasım tarafından kullanılan alan adı.

Ancak herhangi bir bulgu, doğru şartlar altında IoC olarak değerlendirilebilir. Örneğin:

  • Şifreleme Anahtarları

Komuta kontrol altyapısı tarafından şifreli bağlantılar için kullanılan sertifika veya açık/gizli anahtar içeriği.

  • SSL/TLS Sertifikaları

Zararlı yazılımın bağlandığı komuta kontrol sunucusunun SSL sertifikası. (Birden fazla sunucu için kullanılıyor olabilir)

  • Obfuscation Tespiti

Yazılımın zararlı yazılım tarafından kullanılan bir obfuscation yöntemini kullanıyor olması.


IoC ve IoA Farkı

Terminoloji olarak IoC (Indicator of Compromise), başarılı bir saldırıya işaret ederken, IoA (Indicator of Attack) bir saldırının gerçekleştiğine işaret eder. Başarısız bir buffer overflow istismarı IoC değil, IoA olarak nitelendirilir. 


Hasımlar

Devletler arasında siber casusluk faaliyetleri süreklidir. Her kurum kendi içinde hasımlarının (adversary) kullandığı yöntem ve metodolojileri irdeleyerek gerçekleşen saldırıların hangi gruplar tarafından yapıldığını tespit etmekte (attribution) başarısını artırabilir. Hasımlar düzenli olarak takip edilmeli ve kullandıkları teknik taktik ve prosedürlerde yer alan değişimler gözlemlenmelidir. Böylelikle aynı hasım tarafından gelecekte gerçekleştirilecek saldırılara karşı gerçekçi önlemler almak mümkün olacaktır. Bu durumun en büyük sebeplerinden biri, hasımların aynı hedefe dair birden fazla saldırı gerçekleştiriyor olmasıdır. APT gruplarının yıllar boyunca aynı hedefleri farklı zamanlarda çeşitli saldırılar ile hedef aldığı bilinen bir durumdur.


Siber Tehdit İstihbaratı Veri Tipleri

  1. Stratejik

  2. Operasyonel

  3. Taktiksel


Basit Bir Senaryo


Siber Tehdit İstihbaratının Aşamaları

1.Yönlendirme ve Planlama (Direction)

Bu aşamada öncelikler ve istihbarat hedefleri belirlenerek bir planlama yapılır. İstihbarat hedeflerinizi, kuruluşunuzun temel değerlerine ne kadar yakından bağlı oldukları, sonuçta ortaya çıkan kararın ne kadar büyük bir etkiye sahip olacağı ve kararın ne kadar zamana duyarlı olduğu gibi soruların cevaplarına göre belirleyin ve önceliklendirin. 

2.Toplama (Collection)

Bu aşamada, ilk aşamada (yönlendirme ve planlama aşaması) belirlenen gereksinimleri karşılayan ham verileri toplamaktır. Ağ olay günlükleri ve geçmiş olay yanıtlarının kayıtları gibi dahili kaynaklar ve open web, dark web ve teknik kaynaklardan harici olanlar gibi çok çeşitli kaynaklardan veri toplamak en iyisidir.

3.İşleme ve Değerlendirme (Processing)

Bu aşamada; tüm ham veriler toplandıktan sonra, bunları sıralamanız, meta veri etiketleriyle düzenlemeniz ve gereksiz bilgileri veya false negativeleri ve negativeleri filtrelenir.

4.Analiz (Analysis)

İşlenmiş verinin anlamlandırıldığı aşamadır. Bu aşamadaki amaç, olası güvenlik sorunlarını araştırmak ve planlama ve yönlendirme aşamasında belirtilen istihbarat gereksinimlerini karşılayan bir formatta ilgili ekipleri bilgilendirmektir.

5.Dağıtım (Dissemination)

Bu aşamada, bitmiş ürün (istihbarat) gönderilmesi gereken takım arkadaşlarına dağıtılır. Tehdit istihbaratının eyleme geçirilebilir olması için doğru zamanda doğru kişilere ulaşması gerekir.

6.Geri Bildirim (Feedback)

Son adım, istihbarat döngüsünün tam bir çember haline geldiği ve onu ilk planlama ve yönlendirme aşamasıyla yakından ilişkili hale getirdiği zamandır. Bitmiş istihbarat ürününü aldıktan sonra, ilk isteği yapan kişi onu gözden geçirir ve sorularının yanıtlanıp yanıtlanmadığını belirler. Bu, bir sonraki istihbarat döngüsünün amaçlarını ve prosedürlerini yönlendirerek yine dokümantasyonu ve sürekliliği gerekli kılar.


on 13 Eylül by Berk Cem Göksel |   Edit

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