Bilinmeyen veya şüpheli dosyaların hızlıca sorgulanabilmesi için çok kullanışlı bir servis. Servis Whois, DNS ve HTTP/S protokolleri üzerinden dosya md5 veya sha1 hash değeri ile sorgulama yapmanıza olanak sağlıyor.

Cymru ekibi ayrıca Windows bilgisayarlar için, çalışan işlemleri ve disk üzerindeki dosyaları tarayabileceğiniz WinMHR adlı yazılımı kullanımınıza sunuyor.

Peki farklı platformlarda bu servisi kullanabileceğimiz basit bir malware scanner hazırlayabilir miyiz? Pek tabi. Bunun için DNS protokolü üzerinden çalışan bir script hazırladım.

Cymru malware scanner yazılımı Python ile hazırlanmış çok basit bir script. Yaptığı iş kendisine verdiğiniz dosyanın md5 özetini almak ve DNS protokolü üzerinden bunu MHR servisine sorgulamak.

Peki birden fazla dosya üzerinde bunu nasıl kullanabiliriz? Aşağıdaki gibi basit bir komut satırı döngüsü işinizi görecektir.

~/zararli$ for f in *; do ~/tools/scripts/cymru-malware-scanner.py $f; done
2RgU-server-bifrost.exe: Malware found!
643244763-dorkbot.gif: Malware found!
_com.allen.txthej_1_1.0_DroidKungFu.apk: Malware found!
eicar.com: Malware found!
FACEBOOK-DSC0000897643228312.jpg.exe: Malware found!
filegui-spyeye.exe: Malware found!
jSMSHider-org.expressme.love.ui.apk: Malware found!
net.maxicom.android.snake_7937c1ab615de0e71632fe9d59a259cf.apk: Malware found!
SoftonicDownloader_para_kaspersky-tdsskiller.exe: Clean – according to Cymru database
VALENTINE.exe: Clean – according to Cymru database
winzip.exe: Clean – according to Cymru database
Zitmo_tr_ECBBCE17053D6EAF9BF9CB7C71D0AF8D.apk: Malware found!
~/zararli$

Yukarıdaki örnek çıktıda da görülebileceği gibi, kötücül yazılımları (malware) çok hızlı bir şekilde algılama şansımız oldu. Ancak dikkat edilmesi gereken diğer bir konu, örneğin valentine.exe adlı yazılım çok yeni bir malware ve Cymru veritabanına göre bu dosyada bir problem bulunmuyor (Belki kısa bir süre sonra algılayabilir hale gelecektir). Bu nedenle hazırladığımız bu basit malware scanner’ı, bir sonraki adımda Virustotal ile entegre etme işine girişebiliriz.

Yazılımı buradan indirebilirsiniz.

Peki 2011′de neler oldu? Durumu Mert ve Ömer’le birlikte değerlendirdik. Bu aynı zamanda aylık olarak yapmayı planladığımız podcast serisinin de ilki oldu.

Buyrun, 2011′de neler oldu hatırlayalım.

Güvenlik Sohbetleri Bölüm 1
Tarih: 4 Ocak 2012 Çarşamba
Konu: 2011 yılında güvenlik dünyasında kısaca olup bitenler.
Katılımcılar: Mert SARICA, Sertan KOLAT, Ömer ALBAYRAK

Podcast dosyasını buradan indirebilirsiniz (Yaklaşık 23 dakika, 21MB)

Neler konuştuk?

O an hatırlayabildiğimiz kadarıyla; Stuxnet, Duqu, Sertifika otoritelerine yönelik saldırılar (Comodo, DigiNotar), APT ve ses getiren olaylar, RSA, Lockheed Martin, Sony, mobil platformlar… 2012′de bizi neler bekliyor?

Herkese sağlıklı, mutlu ve bol başarılı güzel bir yıl dilerim.

Web sunucusunun HTTP GET, HEAD, POST, OPTIONS isteklerine verdiği yanıtlar başta olmak üzere, TRACE, CONNECT, PUT, DELETE ve ek modüllerle aktif hale gelen birden fazla isteğe verdiği yanıtlardan çeşitli bilgiler elde edebiliriz [1]. Lab ortamında fuzzing yöntemleriyle bu isteklerin belirli bölümleri değiştirilerek, web sunucusu zaafiyet analizi de gerçekleştirilebilir.

Edinilebilecek bilgi hedef sistemin, yüklü bileşenlerin, yapılandırmaların durumuna göre değişebileceğinden, tam liste olmasa da şu bilgiler elde edilebilir:

• Bilinen dosya uzantılarına yapılan rastgele isteklerle teknoloji tespiti,
• Web sunucusu iç IP bilgileri,
• Yük dengeleme cihazları ve arkasındaki web sunucu sayısı,
• Yük dengeleme cihazları arkasında farklı içeriğe sahip sunucular,
• Web sunucu tipleri ve sürüm bilgisi,
• …

Örnek olması açısından rastgele seçilmiş bir hedef bulup çeşitli denemeler yapalım (domain uydurmadır).

$ nc -v penetrasyon.com 80
Connection to penetrasyon.com 80 port [tcp/www] succeeded!
GET / HTTP/1.1
Host: penetrasyon.com

$

$ nc -v penetrasyon.com 80
Connection to penetrasyon.com 80 port [tcp/www] succeeded!
GET / HTTP/1.1
Host: penetrasyon.com
User-Agent: Test

HTTP/1.1 200 OK
Date: Tue, 06 Dec 2011 09:32:51 GMT
Server: Apache
Last-Modified: Sat, 03 Dec 2011 07:26:18 GMT
ETag: "15ecb51-15f6e-4b32b005e7a80"
Accept-Ranges: bytes
Content-Length: 89966
Content-Type: text/html; charset=UTF-8
Set-Cookie: PCOOKIE1=677685440.20480.0000; path=/

... (devamı kesilmiştir)

Şu an isteğimize yanıt alabildik. Burada sunucu bilgisi, hedef sistem zamanı, istek yapılan dosyanın son değişiklik tarihi, içerik uzunluğu ve kullanıcıya atanan tanımlama bilgisi(Cookie) değerlerini görebiliyoruz.

Acaba isteklerimizi arttırarak, yanıt başlığı istatistiklerinden ek bilgiler elde edebilir miyiz? Bu isteği birden fazla hale getirip, verilen yanıtları karşılaştıralım.
Burada bize yardımcı olacak ufak bir script hazırlayabiliriz. Bu script, belirttiğimiz sayıda HTTP GET isteği göndererek, gelen HTTP yanıt başlıklarını daha kolay analiz edebilmemiz adına tekil hale getirip, sıralayarak sayıyor. (… |sort |uniq -c etkisi)

F5 tarafından atanan bu Cookie değeri, bilinen bir algoritmayla kodlandığından, aynı kodlama yöntemi tersine uygulanarak F5 arkasındaki web sunucusunun gerçek IP adresini ve web sunucu port numarasını öğrenmek mümkün olabilmektedir. 

F5 cihazı arkasındaki web sunucusu Internet üzerinden ulaşılabilir bir IP adresine sahipse, bu durum DoS saldırılarında F5′i egale edip direk arkadaki web sunucusuna saldırma amaçlı kullanılabilir. Veya yapılan denetimler sırasında F5′in aradan çıkartılmasına ve direk hedef sistemin denetlenmesine imkan sağlar.
F5 cihazı arkasındaki web sunucusu yerel IP adresine sahipse, bu bilgiler diğer saldırıları destekleme amaçlı kullanılabilir.
Bunların dışında F5 tarafından atanan Cookie değerleri web denetim yazılımlarına girilerek, bu yazılımların sadece belirtilen web sunucusunu taraması sağlanabilir.

Kodlanmış IP adreslerini farklı iç IP adresleriyle değiştirerek bunlarda bulunan servislere ulaşmak, veya kodlanmış TCP port bilgisini farklı portlarla değiştirerek port tarama veya diğer portlar üzerindeki servislere ulaşmak mümkün gözükmüyor. Veya benim test ettiğim hedeflerdeki konfigürasyonlarda şu ana kadar mümkün olmadı.

En sık karşılaşılan kalıcı Cookie değeri nasıl kodlanıyor inceleyelim (Tüm detaylar Overview of BIG-IP persistence cookie encoding makalesinde bulunabilir).

Örneğin 192.168.10.1 IP adresi ve 8080 port numarası üzerinden servis veren web sunucumuzu F5 Big-IP ile dışarıya açtığımızda oluşturulacak tanımlama bilgisi şu şekilde olacaktır:
17475776.36895.0000

Noktalarla ayrılmış bu değerde ilk bölüm IP adresini, ikinci bölüm ise port numarası bilgisini içermektedir. Üçüncü bölüm 4 tane 0′dan oluşmaktadır. Aşağıdaki gibi hesaplanır.

IP adresindeki her bir oktet, hex değerine çevrilir
192.168.10.1 = 0xC0 . 0xA8 . 0x0A . 0×01
Reverse byte order ile birlestirilir (0x010AA8C0)
0x010AA8C0 = 17475776

Veya şu şekilde hesaplanabilir:
192+168×256+10×(256^2)+1×(256^3) = 17475776

Port bilgisi ise
8080 = 0x1F90
Reverse byte order = 0x901F
0x901F = 36895

Özetle, Windows hesap makinesini bilimsel moda getiren herhangi birisi bile, bu değerlere bakarak içerideki sunucuların IP adreslerini öğrenebilir.

F5 kullanıyorsanız ve bu durum hoşunuza gitmiyorsa Overview of cookie encryption makalesine göz atın.

Aktardığım haliyle eski bir konu ve Nessus dahil bir çok yazılım bu problemi kontrol edebiliyor. F5 firması Haziran 2011′de cookie encoding makalesini güncellemiş. Bahaneyle uzun zamandır kullandığım script’i de, IPv4 Route Domain ve IPv6 kalıcı cookie değerlerini de deşifre edecek şekilde güncelledim ve paylaşmak istedim.

Örnek kullanım aşağıdaki gibidir, dilediğiniz kadar cookie değerini parametre olarak verip, içlerinde F5 BigIP cookie’si bulunuyorsa gerçek değerlerine çevrilmelerini sağlayabilirsiniz. Buradan indirebilirsiniz.

$ ./decode_bigip.py  "Set-Cookie: PCOOKIE1=2741283008.20480.0000; path=/ BIGipServer<pool_name>=rd5o00000000000000000000ffffc0000201o80 BIGipServer<pool_name>=vi20010db8000000000000ffff0a140574.20480"

Found IPv4 Cookie: 2741283008.20480.0000
Decoded IP/port: 192.168.100.163:80

Found IPv4 Cookie with root domain: rd5o00000000000000000000ffffc0000201o80
Root domain ID: 5
Decoded IP/port: 192.0.2.1:80

Found IPv6 Cookie: vi20010db8000000000000ffff0a140574.20480
Decoded IPv6/port: [2001:db8::ffff:a14:574]:80

$

Penetrasyon Testlerinde Düşülebilecek Hatalar, zaman içerisinde tecrübeyle edinilmiş bilgi birikiminden oluşan penetrasyon testi ipuçlarını içeriyor. Amacım profesyonel olarak penetasyon testi yapan veya bu işte henüz yeterince tecrübe kazanmamış kişilere ipuçları vererek belirli noktalarda kötü tecrübe yaşamalarını önlemek ve genel denetim kalitesini arttırmaktı.

Tabi ki sunum 45 dakikaya sığabilecek temel noktaları içeriyor. Bir kısmı bir çok kişi tarafından bilinse de, her seviyeden katılımcının kendisine bir şeyler kattığını duymak benim için sevindiriciydi.

Gelen herkese teşekkür ederim.

Sunumu buradan indirebilirsiniz.

Ayrıca cihazınızın show version çıktısını veya ağınızda bulunan cihazların IOS sürümlerini toplu olarak da bu yazılıma gönderebiliyorsunuz. Yapılan güvenlik denetimleri sırasında da kullanılabilir.

Cisco IOS Software Checker‘ı kullarak cihazlarınıza yönelik tehditleri görüntüleyin. Örnek çıktı ekran görüntüsünde görülebilir.

4 Haziran 11:40′ta Penetrasyon Testlerinde Düşülebilecek Hatalar başlıklı bir sunum yapacağım. Güvenlik denetimi ve sızma testlerinin planlama, denetim, raporlama gibi tüm aşamalarında düşülebilecek temel hatalardan bahsedip, penetrasyon testlerinden yüksek verim alma ve testlerin geliştirilmesi için önerilere değineceğim. Umarım herkesin bir bölümünden faydalanabileceği bir sunum olur.

Bunun dışındaki zamanlarda genelde orada olmaya çalışacağım. Görüşmek üzere.

2010 yılında denetlenen 100′ün üzerinde özel geliştirilmiş web uygulamasında en sık karşılaşılan güvenlik problemleri bu şekildeydi. Ayrıca kategori bazında, eskiden ne tip durumlarla karşılaştığımız ve günümüzde bunun nasıl değiştiği de konuşuldu.

İstatistik detaylarında o kategoriye ait güvenlik açıklarının alt detayları, en sık karşılaşılandan daha az karşılaşılana göre sıralandı. Sunuma biraz hareket katmak için denetimler sırasında karşılaşılan ilginç güvenlik problemlerinden de bazıları sözlü olarak anlatıldı, bazılarıysa özel oluşturulmuş gerçeğe benzer örnek ekran görüntüleriyle açıklandı.

Bu istatistikler uğraştıran bir çalışmanın sonunda oluşturuldu. İstatistikler güvenlik açığının hedef uygulamada var olup olmadığına göre değerlendirildi. Örneğin XPath Injection denetlenen uygulamada var veya yok olarak değerlendirildi. 3 noktada XPath Injection vardır diye istatistiklere alınmadı.

Buna göre düşündüğünüzde SQL’e Sızma(SQL Injection) ortalama 100 uygulamanın 29′unda karşımıza çıkmıştır diye düşünebilirsiniz. O 29 uygulamanın kaç noktasında SQL Injection vardır bilgisi bu istatistiklerde görülmüyor.

Yurt dışında otomatik denetim yapan bazı firmalar, veritabanından direk bu istatistikleri sağlayabiliyorlar. Ben de ileride daha detaylı istatistikler sağlamak üzere raporlama yazılımlarını değiştirmeyi düşünüyorum.

Katılan herkese teşekkür ederim.

Sunumu indirmek için tıklayınız.

root olarak ele geçirdiğiniz AIX sistemlerin parolalarını, John the Ripper yazılımını kullanarak kırabilirsiniz. Bu bize, deneme-yanılma saldırısıyla(brute-force) çok zaman kaybetmeden, komşu sistemlere gürültüsüz şekilde erişebilmemizi sağlayabilir.

AIX sistemlerdeki bazı ufak farklılıkları, /etc/passwd ve /etc/security/passwd dosyalarındaki detayları bu yazıda özetlemeye çalıştım.

Nedir bu /etc/security/passwd dosyası?

AIX sistemlere erişimi olan kullanıcılar /etc/passwd dosyasında bulunurlar. Ancak şifrelenmiş parolalar bu dosyada değil, sadece root kullanıcısının okuma hakkı olan /etc/security/passwd dosyasında tutulurlar.

Sisteme root Erişiminiz Yoksa

Hedef sistemde root olamadıysanız, /etc/passwd dosyası da yapacağınız diğer saldırılar için size bazı ipuçları verebilir. Örnek bir /etc/passwd dosyasını[1] inceleyelim:

root:!:0:0::/root:/usr/bin/bash
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
sys:!:3:3::/usr/sys:
adm:!:4:4::/var/adm:
uucp:!:5:5::/usr/lib/uucp:
guest:!:100:100::/home/guest:
nobody:!:4294967294:4294967294::/:
lpd:!:9:4294967294::/:
lp:*:11:11::/var/spool/lp:/bin/false
invscout:*:6:12::/var/adm/invscout:/usr/bin/ksh
sshd:*:202:201::/var/empty:/usr/bin/ksh
oracle:*:101:202::/home/oracle:/usr/bin/ksh
operasyon:!:203:204::/home/operasyon:/usr/bin/bash
dbadmin:!:777:205::/home/dbadmin:/usr/bin/ksh

AIX sistemlerdeki /etc/passwd dosyaları incelendiğinde, ikinci kolondaki ! (ünlem) ve * (yıldız) karakterleri göze çarpacaktır. Bu karakterler, /etc/security/passwd dosyasında şifresi olan ve olmayan kullanıcıları yansıtmaktadır.
Ünlem (!) karakteri olan kullanıcıların /etc/security/passwd dosyasında şifrelenmiş birer parolası vardır denilebilir. (Sistem özel olarak ayarlandıysa bu kullanıcıların boş şifreleri olabilir, veya hesapları devre dışı durumda olabilir)
Yıldız (*) karakteri olan kullanıcıların /etc/security/passwd dosyasında kaydı yoktur ve bu kullanıcılar sisteme giriş yapamazlar.

Yukarıdaki dosyayı incelediğimizde;

1. lp, invscout, sshd ve oracle kullanıcılarıyla sisteme giriş yapamayacağımızı görebiliriz.
2. Sistem kurulumuyla gelen daemon, bin, sys, adm gibi kullanıcıların da, /etc/security/passwd dosyasında muhtemelen geçerli bir şifresi bulunmamaktadır. Bu kullanıcıların ayrıca en son kolondaki login shell bölümü boş olması da yorumlamada kullanılabilir.
3. Bu durumda elimizde root, operasyon ve dbadmin kullanıcıları kaldı.
4. AIX sistemlerde default shell Korn Shell’dir (/usr/bin/ksh). Fakat genelde sistem yöneticilerinin, özellikle Linux geçmişi olanların, getirdikleri kolaylıklar nedeniyle Bash tercih ettiğini ve varsayılan shell’lerini bash yaptıklarını görebiliriz.

Yukarıdakileri göz önüne aldığımızda, root ve operasyon hesaplarının muhtemelen sıkça kullanıldığı (Bash shell), dbadmin hesabının ise tahminen çok kullanılmadığı ve belki de güncellenmeyen zayıf bir şifreye sahip olabileceğini ön görebiliriz. Operasyon, dbadmin gibi hesaplar diğer sunucularda da bulunma ihtimali olan hesaplardır. Ayrıca diğer bazı sunucularda, incelendiğimiz sistemde kullanılmayan oracle hesabına şifre verilmiş olabilir.

Duruma bağlı olarak bu hesaplara basit brute-force denemeleri yapabilirsiniz. Veya rsh aktifse ve kullanıcının home dizinine yazma izniniz bulunuyorsa, .rhosts dosyasına + + yazarak eski güzel günleri yadedebilirsiniz.

Sistemde root Erişimi Elde Ettiyseniz

Herhangi bir yöntemle hedef AIX sunuculardan birisine root erişimi elde ettiyseniz, yukarıda bahsettiğim /etc/security/passwd dosyasını okuyabilir ve bu dosyayı John the Ripper yazılımının okuyabileceği hale dönüştürüp parola kırma işlemini gerçekleştirebilirsiniz. Bu sayede, root şifresini tespit edebilir veya diğer hesapların şifrelerini bularak komşu sistemleri ele geçirebilirsiniz.

Örnek bir /etc/security/passwd dosyasını[1] inceleyelim:

root:
password = JYheSiLsil/OI
lastupdate = 1275641576

daemon:
password = *

bin:
password = *

sys:
password = *

adm:
password = *

uucp:
password = *

guest:
password = *

nobody:
password = *

lpd:
password = *

operasyon:
password = ho/Gl4LsilF4M
lastupdate = 1153248697
flags =

dbadmin:
password = hHvsilSILCmZM
lastupdate = 1154342459

Yukarıda görüldüğü gibi, root, operasyon ve dbadmin kullanıcıları için /etc/security/passwd dosyalarında şifrelenmiş birer parola mevcut. Diğer hesaplar ise devre dışı (* işareti bulunmaktadır).

John, bu haliyle /etc/secure/passwd dosyasını kıramıyor. Sadece “password =” bölümündeki şifrelenmiş parolaları bir dosyaya aktarıp john’a verebilirsiniz.

$ grep -E ‘password = [^*]‘ ornek-passwd |sed -r ‘s/.*=\s(.*)/\1/’
JYheSiLsil/OI
ho/Gl4LsilF4M
hHvsilSILCmZM

Ancak bu durumda dosyada username değeri bulunmayacağından, kullanıcı adlarına benzer/aynı şifrelerin tahmin edilmesi çok uzun sürebilir. Yukarıdaki işlem yerine /etc/secure/passwd dosyasını standart bir /etc/passwd dosyası formatına çevirebilirsiniz. Böylece john the ripper, kullanıcı adlarıyla aynı veya benzer olan basit şifreleri daha kolay bulabilir.

$ ./unaix.sh ornek-passwd
root:JYheSiLsil/OI:0:0:root::/usr/bin/ksh
daemon:*:0:0:daemon::/usr/bin/ksh
bin:*:0:0:bin::/usr/bin/ksh
sys:*:0:0:sys::/usr/bin/ksh
adm:*:0:0:adm::/usr/bin/ksh
uucp:*:0:0:uucp::/usr/bin/ksh
guest:*:0:0:guest::/usr/bin/ksh
nobody:*:0:0:nobody::/usr/bin/ksh
lpd:*:0:0:lpd::/usr/bin/ksh
operasyon:ho/Gl4LsilF4M:0:0:operasyon::/usr/bin/ksh
dbadmin:hHvsilSILCmZM:0:0:dbadmin::/usr/bin/ksh

Yukarıdaki unaix.sh dosyasını buradan indirebilirsiniz.

Aşağıdaki basit denemede iki yöntem arasındaki farkı görebilirsiniz. Yukarıdaki çıktıları deneme1 ve deneme2 adlı dosyalara yazdıralım, ve ardından…

$ ./john –single deneme1
Loaded 3 password hashes with 3 different salts (Traditional DES [128/128 BS SSE2])
guesses: 0  time: 0:00:00:00 100%  c/s: 0.00

Eh, tabi ki single modu kullanıcı adı bulunduğunda daha efektif bir yöntemdir. Wordlist’le deneyelim.

$ ./john –wordlist=dict.txt deneme1
Loaded 3 password hashes with 3 different salts (Traditional DES [128/128 BS SSE2])
root             (?)
guesses: 1  time: 0:00:00:00 100%  c/s: 9800  trying: 1234 – write

Yine 1 tane bulabildik. (wordlist’imiz çok geniş olmadığından)

Oysa ki kullanıcı adları da bulunan bir dosyada, şansınız yaver giderse işiniz daha kolay olabilir. unaix.sh script’i ile oluşturduğumuz deneme2 dosyasını deneyelim.

$ ./john –single deneme2
Loaded 3 password hashes with 3 different salts (Traditional DES [128/128 BS SSE2])
root             (root)
dbadmin          (dbadmin)
guesses: 2  time: 0:00:00:00 100%  c/s: 26920  trying: Operasyon42 – Operasyon59

Görüldüğü gibi daha kolay bir şekilde zayıf şifreleri tespit ettik. Ayrıca hangi şifre hangi kullanıcıya ait onu da daha rahat görebiliyoruz. Bu tarz ufak detaylar, yapılan denetimleri hızlandırabilir.

Notlar
[1] Bu yazıdaki örnek /etc/passwd ve /etc/security/passwd dosyaları, gerçek sistemlerle ilişkili değildir. Test sistemlerinden alınmış veya örnek olması açısından elle oluşturulmuş dosyalardır.
[2] unaix.sh dosyasını indirmek için tıklayın

Varolan yazıları ve yorumları kolayca import ettim, ama aktarılan yazıların formatı biraz kaymış olabilir. WordPress’i çok sevmiyorum, alışmam kolay olmayacak…