16 Eylül 2020 Çarşamba

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

Tehdit istihbaratında çalışıyorsanız sık sık haberleri, hacker forumlarını, yeni zafiyetleri ve dünya çapında gerçekleşen önemli siber saldırıları takip etmeniz gerekiyor. Bunlar bir yana, her yiğidin yoğurt yiyişi başka. Ben teknik olarak kendini geliştirmenin yanı sıra dünyaya ve geleceğe dair bir vizyona sahip olmanın tehdit istihbaratında çalışan biri için büyük bir fark oluşturduğuna inanıyorum. Bu doğrultuda vizyonumu genişletmek için de küçük bir rutinim var. Her sabah, istisnasız bir saatlik bir süreyi düzenli takip ettiğim haber sayfalarını ve blogların yazılarını okuyarak geçiriyorum. Bu bana siber güvenlik sektörünün nereye doğru evrildiğine ve dünya siyasetinin nereye doğru evrildiğine dair küçük ipuçları veriyor. Bunun dünya çapında gerçekleşen siber saldırıların ve algı yönetimi çalışmalarının arkasındaki nedenlere dair başka fikirler verdiği de oluyor. Bu tür bir disiplin oturtmak meyvelerini on, belki yirmi yıl sonra verecektir.

Dünyaya dair konular bir yana, önemli zararlı yazılımların zaman zaman çok başarılı analizleri paylaşılıyor. Bu analizleri mutlaka okumaya ve kendi tespit ettiğim zararlıları analiz etmeye özen gösteriyorum. Bu teknik olarak güncel kalmamda yardımcı oluyor. Ancak her şey bir yana, düzenli okuma yapmak belki de en önemlisi. Rapor değil, kitap okumaktan söz ediyorum. Peki ne tür şeyler okumalı? Bu tamamen kişinin kendine kalmış. Ben daha tamamlamamış olsam da, dostum Sylvain'in okuma listesinden çok keyif alıyorum.

Sylvain'in OSINT ve Physical Intrusion üzerine okuma listesini burada bulabilirsiniz.

Okumak demişken, dil bilmek tabii ki çok önemli. Bugünlerde tehdit istihbaratı analistlerinde aranan en büyük özelliklerden biri Rusça, Çince, Arapça gibi dilleri biliyor olmaları. İngilizce tabii ki olmazsa olmaz. Bu kimsenin şevkini kırmamalı. Google Translate bugüne kadar birçok dilde blog yazısını anlamamda ve yorumlamamda gayet yeterli oldu. Ancak dil öğrenmek gibi bir fırsatınız (zaman, maddiyat, yetenek) varsa, mutlaka kullanın derim.

Hacker forumlarının ve tehdit aktörlerinin düzenli takibi tabii ki işin önemli bir parçası. Bu süreçlerin bir kısmı otomasyon ile takip edilse de (örneğin: crawler'lar) ilişkilendirme tamamen analistler tarafından yapılması gereken bir iş. Son iki yıldır takip ettiğim "T.C. Cimer" veya "Cimer Duyuru" ibarelerini sık kullanan grubun oltalama kampanyalarına göz atarken, bir süredir devam eden, benzer ama farklı bir oltalama kampanyası ile karşılaştım.
Aşağıdaki sayfaya hızlıca bir göz atalım:

Kredi kartı numarası, TC kimlik numarası, son kullanma tarihi ve CVV kodunun istendiği, E-devleti andıran bir sayfa. Burada TC kimlik numarasının istenmesi biraz ilginç. İsim ve soy isim bilgileri istenmiyor. Aklıma ilk gelen senaryo, saldırganların 2013 yılında sızdırılan Mernis veri tabanını kullanarak, 90 öncesi doğumlu T.C. vatandaşlarının isim ve soy isim bilgilerini TC kimlik numarası üzerinden sorgulatacak olmaları.

Sayfayı biraz inceleyince Let's Encrypt üzerinden bir SSL sertifikası tanımlandığını görebiliyoruz.

Kaynak koda bakarsak, sms ile gönderilen doğrulama kodunu çalma vb. işlemlere yönelik çeşitli fonksiyonlar görüyoruz.



Buradaki PHP uzantılı dosyaları teker teker ziyaret ettiğimde, aşağıdakine benzer bir görüntü mevcut.


Hatta SMS hatalı gönderilirse (bunun kontrolünün back-end tarafında nasıl yapıldığına dair bir bilgimiz yok) bunun için de bir sayfa var.


Ancak daha dikkat çekici öğeler mevcut.


Buradan hızlı çıkarımlarda bulunmak çok doğru olmayacaktır. FATAL lakabı, oltalama panelini geliştiren kişiye de ait olabilir, oltalama kampanyasını yürüten tehdit aktörü de olabilir. Bu bulgu şimdilik dursun. Öncelikle kampanyanın ne kadar büyük olduğuna dair bir fikir elde edinmek adına aynı IP üzerinde kaç alan adı kayıtlı buna bir bakmanın doğru olacağını düşündüm. Bing IP search ile farklı bir alan adı bulmak mümkün oldu.


Bir plesk giriş sayfasına yönlendirildik. Bu alan adı artık tarayıcılar ve güvenlik ürünleri tarafından yakalanmaya başladığı için kaldırılmış olabilir.


Aynı IP adresine çözümlenen diğer alan adlarına baktığımız zaman bunların bir kısmının aktif olmadığını ancak hala aynı IP adresine çözümlendiğini görebiliyoruz.


Örneğin, daha önceden kullanılan ancak şimdi aktif olmayan bir alan adı ziyaret edildiğinde aşağıdaki görüntü ile karşılaşıyoruz. 


Bunu DNS kayıtlarının güncellenmesinin zaman almasına bağlayabiliriz ancak çoğu hosting provider TTL değerini değiştirmeye izin veriyor. Tehdit aktörü bu durumu tamamen atlamış da olabilir.

Oltalama kampanyasının daha önceden de tespit edildiğine dair bulgular mevcut.

Kaynak: MalwareHunterTeam (@malwrhunterteam) / Twitter

Bir Twitter paylaşımı da, benzer bir kampanyanın Azarbaycan vatandaşlarını hedef aldığına işaret ediyor.


Hızlıca bir iki alan adına whois kaydı atınca whois protection kullanıldığını görüyoruz. Tehdit aktörü aracı bir firmayı kullanarak kendi adres ve e-posta gibi bilgilerini gizliyor. Ancak bu tür durumlarda siber suçluların sık sık hata yaptığını görüyoruz. Bütün kayıtlara tek tek bakmakta fayda var.


Buradan elle tutulabilir bir bulgu elde edemedik. Aktör dikkatlı davranmış gibi gözüküyor.

Bu noktada merakımdan ötürü sayfaya gelen giden isteklere kısaca bir baktım.


IP adresimin karşıya gönderilmesi çok normal. Aslen HTTP loglarından da bakılabilir ancak uygulama büyük ihtimalle bizden aldığı verileri formatlı bir şekilde kaydediyor. Büyük çapta bir kampanya için bu mantıklı. Bu noktada aktörün lakabını panelin birden fazla yerine yazdığını görebiliriz.

Elimizde bir ICQ adresi ve lakap var.



Tehdit aktörü hakkında bir takım araştırmalar sonucunda Stack Overflow üzerinde sorulmuş (ve silinmiş), bir soru görüyoruz.

Kaynak: https://quabr.com/62186391/mysql-sql-injection-delete-get-text

Stack Overflow üzerinde okuduğum kadarıyla, Stack Overflow silinen soruları 60 gün kadar daha aktif tutuyor ancak arama sonuçlarında göstermiyor. Ancak linke sahipseniz veya sorunun sahibi sizseniz, içeriği görebiliyorsunuz. İçeriği göremediğimize göre soru silineli 60 günden fazla olmuş olmalı. Ancak sorunun bir zamanlar var olduğunu kanıtlamanın basit bir yolu var. Stack Overflow üzerinde aşağıdaki URL adresini ziyaret ediyoruz.

https://stackoverflow.com/questions/62186391/

Sayfa bizi otomatik olarak aşağıdaki URL adresine yönlendiriyor.


Artık bunun silinen bir sonuç olduğuna eminiz. Soruyu soran hesap "emre bey" ismini kullanmış. 


Profiline aşağıdan ulaşılabilir:

https://stackoverflow.com/users/13676974/emre-bey?tab=profile


"emre bey" profili bize daha fazla bulgu vermiyor. Ancak Hacker forumları arasında yapılan küçük bir arama, oltalama panelinin fatal lakaplı aktör tarafından geliştirildiğini ve ICQ üzerinden pazarlandığını gösteriyor. 


IoC Listesi

Oltalama kampanyası ile ilişkili IoC'ler aşağıdadır.

Alan adları:

  • egov-cumhurbasvuruyapmak.com

  • mtr-facebook-me.com

  • egov-cumhuribasvuruyaptr.com

  • egov-cumhuribasvuruyap.com

  • egov-basvurumerkezi.com

  • www.egov-cumhuribasvuruyaptr.com

  • egov-cumhuribasvuruyap.com

  • www.egov-cumhuribasvuruyap.com

  • www.egov-basvurumerkezi.com

  • instagramhelp-me.com

  • mfacebook-me.com

  • egov-emekcilerburdaa.com

  • mfacebook-m.com

  • www.egov-ortakbanka.com

  • www.egov-emekcilerburdaa.com

  • www.egov-cumhuriyetcilik.com

  • www.egov-basvurularyapilir.com

  • www.egov-ihabasvur.com

  • www.egov-ecumhuriyet.com

  • www.egov-e-cimer.com

  • instagramhelp-me.com

  • www.egov-e-cumhuriyett.com

  • instagramhelp-me.com

  • www.egov-e-cumhuriyet.com

  • www.egov-1000tl.com

  • tr-f-facebook.com

  • egov-ciimerr.com

  • www.egov-ccimer.com

  • egov-trbasvuruyapiniz.com

  • egov-trbasvuruyapiniz.com

  • egovbasvuru-turkiyecumhuri.com

  • www.instagramhelp-me.com

  • egov-trbasvuruyapiniz.com

  • www.egov-cimmeerr.com

  • www.egov-cimeraidat.com

  • www.egov-cimerrturk.com

  • www.egov-cimerturk.com

  • egov-cimerturk.com

  • tr-devletkapisi.com

  • tr-devlettenmujde.com

  • e-gov-az.com


IP Adresi

  • 65.52.121.212

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