APT vs ATD - Bypass ve Ürün İnceleme

Uzun bir aradan sonra yeniden merhabalar.  Bir yıldır bir şeyler yazıp karalamıyorum . [Buraya bahaneler sıralanacak] :))

Giriş

Malumunuz değerli verilerimizin başı bir türlü bitten kurtulmuyor. Virüs,worm, trojan, sniffer, logger, hooker filan derken bir de gelişmiş akıllı hedef güdümlü APT zararlıları icat oldu. İyiden iyiye bir zenginlik aracı olmaya başlayan zararlı yazılım alanı zevk, hırs ve ego için zararlı geliştirmenin ötesinde bol kazançlı bir iş alanı haline geldi. Geçmişte sadece boy göstermek için yazılan bu kodlar günümüzde ulus devletlerin veya kurumsal ölçekli şirketlerin emellerine yataklık edecek şekilde geliştiriliyor. Bugünlerde artık tek kişilik çaba ve emeklerin eseri zararlılardan öte, dev geliştirici kadrosu olan ciddi ve planlı ekiplerin elinde çıkmış ve gerçekten kötü niyetli ürünler ile muhatap olmaya başladık. Bu tehditler artık geleneksel güvenlik çözümlerini bir çırpıda aşabiliyor ve sistemlerimizde amaçladıkları aksiyonları zorlanmadan gerçekleştirebiliyorlar. Zararlıların bazıları hedeflerini gerçekleştirdikten sonra, bazıları ise güzel güzel çalışırken yıllar sonra kafasına taş düşen bir güvenlik uzmanın merakı neticesinde tesadüf eseri tespit edilebilir hale gelmiş durumdalar.

Gelişme

IPS, Next-Gen Firewall, DLP, Web Proxy, Anti Virüs, Hips, katı güvenlik politikaları ve son açıklara karşı güncellediğimiz işletim sistemleri... Nasıl ama? Uçtan uca güzel bir güvenlik mimarisi gibi görünüyor değil mi? Bilinen bir tehdidin bu zincire takılmadan hedefine ulaşması pek olası görünmüyor. Açıkçası bilinen tehditlere karşı geleneksel imza tabanlı koruma sistemlerinin biraz daha evrilmiş hallerinden oluşan bu ürünler, bilinmeyen tehditlere karşı sezgisel olarak hiçbir zaman vaat edileni sunamadılar. Bu nedenledir ki artık bizler günümüzün gelişmiş ve akıllı zararlılarına karşı en az onlar kadar hızlı tepki verebilen, karşılaştığı riski uç noktada hareket ediyormuşcasına yorumlayıp doğru analiz sonuçlarını üretebilen sistemlerle çalışmak istiyoruz. Konuyu güncel bir örnekle açıklamamız gerekirse; popüler ebanking virüsleri ve fatura virüsünün onlarca varyantı ve sürekli güncellenen sample’ları yukarıda sayılan hiçbir sistem tarafından tanınamıyorken ATD sistemlerinin Payload Analysis fazında başarılı bir şekilde tespit edilebiliyorlar!!! Peki ya çözüm?

Bu sorunun cevabı da en az sorunun kendisi kadar bol çeşitli ve karmaşık. Verilen cevaplar ve sunulan çözümler ya yetersiz kalıyor ya da uygulanmak istenildiğinde farklı süreçleri etkilediğinden ölü doğuyor.

Çözüm ATD, mi?;

Advance Thread Defense (ATD). En az Advance Persistent Thread kadar havalı bir isim değil mi? Çözüm sağlayıcılar APT tehditlerine karşı katmanlı bir yaklaşım senaryosu sunmaktalar. Tehditlerin, ağ katmanında gösterdiği trafik hareketlerinden veya yine ağ katmanında yakalanan tehlike arz edebilecek dosyanın sandbox analiz sonuçlarına yada doğrudan endpoint üzerinde ki katılaştırma ve beyaz liste yolu ile engelleme yoluna gidilmekte. Bu yazımda sizlere, bu çözümlerden Payload analiz tekniklerini kullanan Sandbox çözümleri üzerinde edindiğim tecrübelerden bahsedeceğim.

Challange!

APT tehditlerinin popülaritesi hız kesmeden devam ediyor. Pazardaki bu açığı gören zeki girişimciler de aslında hep var olan davranışsal analiz ve sanallaştırma teknolojisinin güçlerini bir ürün haline getirerek bizlere sunmakta gecikmedi. Pazarlama aşamasında oldukça cüretkar vaatler sunan ürünlerin iş PoC’ler’e gelince topu taca atma girişimlerinin yorumlanması ise bu yazının bir başka konusu. Şu bir gerçek ki gelişmiş hedef odaklı zararlılara karşı koruma vaat eden ürünlerin kesinlikle olgunlaşması gerekiyor ve bir başka gerçekte şu ki bu ürünlere ait mekanizmaların bir şekilde etkisiz hale getirilebiliyor olması onları asla gereksiz kılmıyor. Tam aksine sundukları yetenekleri ile farkındalık seviyesinin artmasına  ve mevcut güvenlik ürünleri ile tespit edilmesi mümkün olmayan potansiyel veya bilinen tehditlerin tespitine yardımcı oldukları kabul edilmesi gereken bir gerçek.

2014 yılı içerisinde birkaç Payload Analizi yapan ATD ürünü ile test yapabilme fırsatım oldu. Çalıştığım kuruma ait güvenlik alt yapısının iyileştirilmesi kapsamında çözüm sağlayıcılar ile yapılan görüşmeler neticesinde ülkemizde bu alanda faaliyet gösteren üç üretici ile çalıştık. Bunlar; FireEye, Trend Micro ve McAfee oldu. PaloAlto ve SourceFire ise PoC takviminin darlığı sebebi ile testlere yetişemedi. Fidelis ve Damballa ise test etmek istediğim ancak ülkemiz pazarında muhatap bulamadığım için testini gerçekleştiremediğim Breach Detection ürünleri arasında yer aldı.

Hazırlık

Testler iki aşamadan oluşuyor;

1. İlk olarak ATD sisteminin vaat ettiği yeteneklerinin gerçek ortamda ne kadar etkin çalıştığının testlerini gerçekleştirdim. Bu testlerde;

• Yüksek traffic througput’larında ürün tarafından analiz edilmesi beklenen sample’ların yakalanma oranı,
• Sample analizlerinin süresi,
• Waiting Queue’ların uzunluğu,
• False-Positive oranı,
• Bilinen bir zararlının farklı formlarda tanınması(Bulk Zip, Encapsulate Binary vb..)
•  Diğer güvenlik çözümleri ile entegrasyon,
•  Raporların açıklayıcı ve detaylı olması

gibi kriterler ürün seçimi aşamasında ki ana noktaları oluşturuyordu.

    2.  İkinci aşama tamamı ile benim eğlence dünyama hitap ettiğinden, dileyen okuyucular bu kısmı atlayabilir;

El Yapımı APT

Geçmişten gelen low-level merakı ve kendi zararlılarımı yazabilmenin verdiği öz güven ile birlikte bende APT tehditleri konusunda iddialı olan bu ürünler üzerinde hazır fırsatını bulmuşken biraz oynamak istedim. Amacım gelişmiş zararlılar karşısında iddialı bir güvenlik çözümü olma vaadinde bulunan bu ürünlerin kendi güvenliklerinin durumunu test etmek ve sundukları Sandbox analiz yeteneklerinin etkisiz hale getirilip getirilemeyeceğini görmekti. Hali hazırda sahada keşfedilmiş bir çok sandbox bypass tekniği mevcut ancak üreticilerin de bunlardan haberdar olduğu denediğim her bilinen bypass yönteminin sandbox analiz raporunda gözüme sokulması ile kendini belli ediyordu. Lafı uzatmadan doğrudan sonuca gelecek olursam. Tüm ürünleri sample malware’im ile bypass edebildim. Hatta her hangi bilinen bir zararlıyı da dilenirse bu sample ile merge edip hedefe sorunsuzca ulaştırmak mümkün. Ben testlerimde kolay erişilebilirlik ve hız açısından EICAR ve Fatura sample’larını tercih ettim. 

Testler esnasında bir ürünün üzerinde ki tespit ettiğim web tabanlı açıkları yenilir yutulur cinsten değildi. Gerek bypass yöntemlerini gerekse de ürünlere ait kritik zafiyetleri ilgili firmalar ile paylaştım. Şu aşamada iki firma ile etik çerçevede yeni sürüm çıkana dek bu zafiyetleri public etmeme konusunda anlaştık. 

Yazdığım test zararlısını aslında bloğumu takip edenler hatırlayacaktır. “Malware Analizlerinde Anti-Analysis ve Anti-Debugging Teknikleri” adlı yazımda Malware analizine meraklı arkadaşlar için tüm detaylı açıklamaları da içinde yer alan kaynak kodu ile birlikte bir sample paylaşmıştım. İşte bu testler için de bu çalışmamı biraz daha geliştirip aşağıda ki özelliklere sahip bir test zararlısına dönüştürdüm.

Not: İlgili linkte yer alan streamer.exe sample'i bu yazıda incelenen ürünlere ait evasion tekniklerini ve diğer zararlı özelliklerini içermemektedir. 

Test zararlısının kullandığı bazı bilinen tekniklerin içeriği aşağıda ki gibi:

• Anti-Debugging
• Anti-Disassembly
• Anti-Analysis
• Anti-Emulation
• Anti-VM
• C&C Communication
• Shell Code Injection
• Web ve Local Malware Drop
• x86 Asm tricks 
• ve daha bir çok irili ufaklı zararlı yapıları..

Test zararlısını kodlarken en eğlendiğim kısım APT analiz süreçlerini atlatmaya çalıştığım kısımlardı. Bir çok bypass denememi başarı ile tespit edip, bu girişimleri Evasion Techniques veya Suspicious Activities olarak kategorilendiren ürünler, hiç ummadığım yerlerden gol yediklerinde beni oldukça şaşırttılar.

Bu özelliklerin kurban sistem üzerinde ki aktivitesini gösteren ekran alıntılarını da aşağıda yer alıyor:

Zararlımız çalışmadan önce...

Çalıştırıldıktan sonra.

Yukarıda ki resimlerden de anlaşılacağı üzere zararlımız herhangi bir sandbox veya analiz ortamında çalışmadığına emin olduğunda aşağıdaki görevlerini gerçekleştiriyor;

1. Başka bir zararlıyı (eicar veya ptt.exe) HTTPS kanalı ile download edip çalıştığı dizine yazma,
2. Zararlının kendi code bloğunda encrypt durumda olan EICAR test dosyasını doğrudan diske yazma,
3. Şayet ortamda PuTTY çalışıyorsa, ona shellcodunu inject ederek sistemde yönetici haklarına sahip kullanıcı oluşturma,

işlemlerini gerçekleştiriyor. Bu basit aktiviteleri streamer.exe'nin ilave kod yapısı gereği de tam olarak bir zararlı görünümüne sahip olması için yaptım. Download yöntemi olarak https kanalı kullanmamanın nedeni de ortamda ki IPS,Firewall ve Proxy Gateway'lerin görevlerini yapıp yapmadığını test etmek içindi. Testler sonucunda da anlaşıldı ki doğru ve etkili müdahaleler için SSL Inspection cihazları ile sadece Algılama ve Engelleme yapan cihazların bulunacağı bir Decrypt Zone oluşturmak mantıklı bir seçenek olarak karşımıza çıkıyor. Local bir admin accountu eklemek için ise zararlımızın hali ile SeDebugPrivilege tokeni ile çalışıyor olması gerektiğinden ya ilk açılışta UAC'den icazet almamız ya da onu bypass etmemiz gerekiyor. Bu arada belirtmeliyim ki tüm testlerimi son güncellemeleri yapılmış Windows 8.1 ve Windows 7 işletim sistemleri üzerinde yaptım. Ben test ortamımda Avecto Privilege Guard uygulamasının yeni keşfettiğim bir açığından yararlanarak local admin hesabını ekleyebildim. Normal şartlarda Avecto size tüm admin haklarını verse dahi Administrators grubuna ekleme/çıkarma yapmanıza izin vermiyor!  Avecto olmayan bir ortamda ise tüm özellikleri ile test etmek istediğimizde Yönetici olarak çalıştır seçeneğini seçmemiz gerekiyor. 

Aşağıda test edilen her ürün için streamer.exe zararlısına ait analiz sonuçlarını görebilirsiniz:

FireEye analizi esnasında, streamer.exe bilinen bir detection yöntemi ile analiz edildiğini algılıyor ve zararlı aktivitelerini gerçekleştirmeden kendini sonlandırıyor. Bilinmeyen diğer bypass yöntemlerini firma ile etik bir çerçevede paylaştığımdan burada yer veremiyorum.

McAfee ATD ürünü streamer.exe analiz sonucu için bir skorlama dahi yapma gereği duymuyor.

Trend Micro Deep Discovery Analyzer'in streamer.exe analizine ait bir ekran görüntüsü. Test sample'imiz kendisinin analiz edildiğini anlıyor ve sürecini sonlandırıp analiz aşamasını bypass ediyor.

Ürün Testleri

Testlere geçmeden önce konu hakkında ki bazı hayati bilgileri aktarmam gerektiğini düşünüyorum. Mevcut durumda APT tehditlerine karşı oluşturulmuş genel bir konsept bulunmuyor. Breach Detection, Advanced Thread Detection/Protection, ZeroDay Protection vs.. vs.. ATD ürünlerinden en büyük beklentimiz analizleri esnasında zararlı olarak tespit ettiği sample'ları blocklaması. Ancak bunu vaad eden ürünler ne yazık ki Sandbox Analysis aşamasında ilk kez karşılaştığı sample'ı zararlı olarak tespit etse dahi bunu engellemeyi başaramıyor. Bunun hız, kullanıcı isteklerinin bekletilme süreleri gibi bir çok nedeni var. Özetle, bloklama işlemini bu zararlı analiz sonrası tanınır hale geldikten sonra kullanabiliyorsunuz.

FireEye

Ticari Analiz

İlk testini gerçekleştirdiğim ürün FireEye oldu. FireEye, Web ve Email trafiği için iki ayrı kutu sunuyor ve Network Utilization’ınıza göre ölçekleyebildiğiniz geniş bir ürün yelpazesine sahip. Ben testlerimi Web trafiği üzerinde analiz yapan 7400 serisi cihaz ile gerçekleştirdim.  Her ne kadar protokol tipine göre ayrı çözümler sunuyor olsa da bu özelliği uçtan uca çözüm isteyen kurumlar için FireEye’ı rakiplerine göre biraz pahalı bir tercih haline getiriyor. Çözümler Inline olarak çalışabildiğinden bilinen zararlıları tespit edildiği anda bloklama imkanınız da bulunuyor.
Ticari boyutunda eleştirebileceğim en olumsuz bulduğum yanı ise manuel analiz yolu ile incelemek istediğiniz sample'lar için yine ayrı bir kutu alma zorunluluğun olması. Diğer incelediğim ürünlerde manuel sample analiz olanağı ücretsiz bir servis olarak sunulmakta.

Teknik Analiz

Bildiğim kadarı ile FireEye kendi patentli sandbox analiz teknolojisini kullanıyor. Satın aldığınız kutu üzerinde ki belirtilen ağ yükleri altında analiz süreleri kimi zaman uzun sürüyor olsa da bu sürenin kabul edilebilir bir aralıkta olduğunu belirtmek isterim. Sandbox analiz sonuçlarını raporlarken, kendi arayüzü üzerinde çok detaylı diyemeyeceğim bir şekilde trace sonucunu paylaşıyor. Zararlının yaptığı ağ trafiği ile alakalı forensic ihtiyacınızı ise export edebildiğiniz pcap dosyası ile sağlayabiliyor. PoC esnasında kurum bünyesinde kullanılan bir activex nesnesine ait ocx’in olması gerektiğinden çok daha über fonksiyonlara sahip olmasından rahatsız olan FireEye’ın bunu raporlaması hoş bir andı. FireEye'ı ayrıca bu yazıyı yazdığım sırada A10 firmasının SSL Inspection çözümü ile birlikte HTTPS trafiği içinde test edebilme fırsatı buldum. FireEye bilinen HTTPS zararlılarını da başarı ile algılayıp bloklayabildi. 

McAfee ATD (Advanced Thread Detection)

Ticari Analiz

Öncelikle ATD tek başına çalışan (standalone) bir ürün değil. Vazifesini yapabilmesi için onu besleyecek McAfee etiketli IPS, Web Gateway,Mail Gateway veya McAfee TIE Endpoint ürünlerinden birine sahip olmalısınız. Bu da hali ile ilk satın alma maliyetlerini arttıran bir etken. Tabi bu dezavantajı eğer bu McAfee ürünlerinden en az birini kullanıyorsanız avantaja çevirebilirsiniz.  MATD-3000 ve MATD-6000 adlı 2 farklı modele sahip. Bu modeller arasında ki fark eş zamanlı açılabilecek sandbox ve taranabilecek dosya sayısını belirliyor. Testleri gerçekleştirdiğim 6000 serisinde bu sayı 60 Vm Sandbox'tı. Sandbox image'ları için sizin oluşturduğunuz vm image'larına ihtiyaç duyuyor. Bu özelliğin artıları olsa da bazı handikapları olduğu ortada.    

Teknik Analiz

McAfee ATD'yi sample'lar ile besleme işlemini McAfee IPS ve Web Gateway ile yaptım. McAfee ATD henüz çok yeni bir ürün. Kağıt üstünde sunduğu özellikleri şayet ileride gerçekleştirilebilirse kendini rakiplerinden sıyırabilen bir ürün olması kuvvetle muhtemel. Ancak PoC’ler esnasında yeni bir çözüm olmasından kaynaklanan bir çok irili ufaklı sorun yüzünden bir türlü istenen verimi alamadım. Analiz sürelerinin uzunluğu,  kuyrukta bekleyen sample’ların çok kısa bir süre içinde analiz sürecini imkansız kılacak sayılara ulaşması, False Positive sonuçlar türemesi gibi problemlerle karşılaştım. Analiz aşamasında ki sıkıntılar muhtemelen IPS entegrasyonu ile ilgili bir sıkıntıydı ki aynı sorunları Web Gateway ile kurulan entegrasyonda yaşamadım. PoC sırasında çıkan yeni güncellemeyi de geçtiğimde False Positive sonuç oluşması problemi de ortadan kayboldu. Bunun gibi birçok ürün odaklı sorunu tedarikçi ve üretici firma ile paylaştım. Kendileri ATD’ye oldukça ciddi yatırımlar yaptıklarını, sürekli yaptıkları iyileştirme güncellemeleri ile ispat ediyorlar. Ancak tekrar etmek gerekirse mevcut durumu ile bir APT engelleyici çözüm olarak pazardaki rakiplerinin seviyesine erişmesi için çok daha olgunlaşması gerekliliği satın alma kararlarınızda göz önünde bulundurmanızda fayda var.

TREND MICRO Deep Discovery Inspection & Analyzer

Ticari Analiz

Trend Micro çözümünü 2 ayrı cihaz ile sunuyor. Deep Discovery Inspection (DDI) ve Deep Discovery Analyzer (DDA) olarak isimlendirilen kutular dan Inspection olanı  ağ üzerinden kendisine gönderilen trafik içerisinden web protokolü analizleri gerçekleştirirken, Analyzer adlı kutu Inspection’dan kendisine gönderilen executable’ların analizlerini gerçekleştirmekte. Email güvenliği için Trend Micro’da tıpkı FireEye gibi farklı bir kutu sunmakta. Manuel sample analizlerini ise DDA üzerinden gerçekleştirebiliyorsunuz. DDA üzerinde de ki sandbox'lar da sizin oluşturduğunuz Vm Image'lar ile çalışıyor.

Teknik Analiz

TM kutularını 1Gb throughput altında çalışabileceği bir trafik altında test ettim. Yapısı gereği sadece web protokollerine ait tanıdığı extensionlar üzerinde analizler gerçekleştirebilen DDI, ortamdan yakaladığı sample'ları DDA'ya göndererek gayet makul sürelerde analizler gerçekleştirdi. Mirror bir trafikle çalışan DDA, analiz sonucu zararlı olduğunu tespit ettiği sample için blocklama yeteneğinden mahrum. Ancak DDI inline konumlandırıldığı durumlarda bilinen C&C haberleşmelerini RST flag'i ile bloklayabiliyor. TM'nun analiz sonucu raporları ve Dashboard'u oldukça zengin ve doyurucu bir içeriğe sahip.

Sonuç

ATD çözümleri henüz uzun yıllardır pazarda olan seçenekler değil. Olgunlaşmaları ve geliştirmeleri gereken bir çok eksiklerinin olduğu ortada. Analiz ortamlarını ve yeteneklerini iyileştirdikce ve farklı katmanlarda ki Breach Detection sistemleri ile entegre oldukça çok daha iyi çözümler sunan ürünler olmaya devam edeceklerini umuyorum. Özellikle dinamik analizlerde başarılı grafikler çizen ATD teknolojisi bunu ne yazık ki static analizlerine yansıtamıyor görünüyor. Ticari veya serbest geliştirici olarak ATD ürünü geliştirenlere acizane önerim analiz aşamasının ilk fazını static analiz testlerine göre skorlamaları ve ardından dinamik analiz ve davranış analizi sonuçlarına göre ilgili sample için aksiyon almaları yönünde olacaktır. Böyle bir yaklaşımın otonom zararlı analizinin tüm katmanlarını çok daha iyi adresleyebileceğini düşünüyorum.

Özetle günümüz konjektüründe bu ürünlerden beklediğiniz "Maliyet/Güvende Hissetme" dengesi ne yazık ki tatmin edici seviyede değil. Bu nedenle güvenlik yatırımlarınızı, en az bu ürünlere ödediğiniz kadar tecrübeli insan kaynağına da yönlendirmenizi tavsiye ederim.

Not: Şayet Gartner müşterisi iseniz ATD pazarına ait güzel bir yazının linki şöyle: Five Styles of Advanced Threat Defense

Sağlıcakla kalın,

İbrahim AKGÜL - 2015

Malware Analizlerinde Anti-Analysis ve Anti-Debugging Teknikleri

Yeniden Merhabalar, Fırsat buldukça bir şeyler karalamaya çalışıyorum. Bu makalede, Malware Analysis ve Reverse Engineering konularında kaynak sıkıntısı çeken ve bu tip işlere meraklı yeni başlayan arkadaşlara Kod Analizleri esnasında karşılaşılan Anti-Debug ve Anti-Analysis yöntemlerini yardımcı bir program eşliğinde sunmaya gayret edeceğim. Programı incelemeye başlamadan önce analiz için VM makinenizi ve Olly, IDA gibi analiz araçlarınızı hazırlamanızı tavsiye ederim.

Analize başlamadan önce;

• Kullanacağımız uygulama Masm derleyicisi kullanılarak Assembly dili ile yazılmıştır. Tümü ile detaylı yorum satırları da dahil olmak üzere açık kaynak kodu ile birlikte gelmektedir. 
• Uygulama 17 faz olup, istediğiniz şekilde ilaveler yapabilirsiniz. Derleme işlemi için www.masm32.com üzerinden ilgili paketi indirmeniz yeterlidir.
• Kod içerisinde kullanılan tüm koruma methotdarı temel seviyede olup çözümleri de bir o kadar basittir. 
• Koruma methodlari sadece öğretici olmak için hazırlandığından atlatılmaları için ZF flag'ini NOT'lamanız yeterli olacaktır. Gerçek senaryolarda bu methodlar çok daha farklı ve obfuscate edilmiş olarak karşınıza çıkar. 
• Uygulama C dilinde de rahatlıkla yazılabileceği gibi Assembly kullanımında ki amaç analiz yeteneklerinin hızlı gelişimine katkıda bulunmaktır.
• Test programı ve bu makale 2 iş günü arasında fırsat bulunarak yazıldığından düzensiz görünmesini normal karşılamanızı rica ediyorum. 
• Analizler esnasında algılama tekniklerinin işleyişini daha iyi anlayabilmeniz için doğru kod bloklarında olmanız gerekebilir. Bu yüzden analiz süreciniz içerisinde kaynak kod ve debugger pencerenizi eş zamanlı şekilde kullanmanızı öneriyorum.
• Masm32 platformuna aşina olmayan arkadaşlar 7 yıl önce yazdığım ve giriş seviyesinde olan http://kernelturk.blogspot.com/2009/10/masm32-ve-win32api-voltran-voltran.html makalesini okuyabilirler.
• İlerleyen aşamalarda ucu açık kalan konular hakkında da (ör: polymorphic kod'lar ile packing, permutasyon çeşitleri ile Analizlerden kaçma yolları, kodunuzun bir VM veya Emulator üzerinde çalışıp çalışmadığının anlaşılması gibi) yazmayı planlıyorum. Bu yüzden ben o süreçleri hazırlayana kadar siz bu konuları kavramaya gayret edin lütfen.

Analiz Dosyasına ulaşmak için : İndir

Not: Doğrudan ve hızlı bir şekilde programın analizine başlayabilir veya sizlere fikir vereceğini düşündüğüm kısa bir yazıyı okuyabilirsiniz:

Kolay olan Tespit Etmek mi?

Zararlı Yazılımlar'ın öncelikli hedeflerinden biride tespit edildikleri anda tüm kirli çamaşırlarının bir bir ortaya çıkmasının önüne geçmektir. Zararlı Yazılım Analistleri ele geçirdikleri zararlı örnekleri üzerinde çalışmak için bir çok farklı araçtan yararlanırlar. Ancak analist zararlıyı incelemeden önce tamamı ile yalıtılmış bir ortam hazırlamak zorundadır. Çalışmalar ilk zamanlarda temiz bir işletim sistemi üzerinde tüm gerekli analiz araçları yüklenmiş ve network kablosu çekilmiş fiziksel pc'ler üzerinde yapılıyorken ilerleyen zamanlarda bu iş için uzaktan hata ayıklama (remote debugging) teknikleri yerini almıştı. Ancak yinede fiziksel pc bağımlılığı nedeni ile analiz süreleri zararlıların davranışlarına göre farklılıklar gösterdiğinden çok uzun zaman alıyordu.

İlerleyen zamanlarda Emulatorler ve Virtual Pc'lerin ortaya çıkması ile analiz süreçleri çok daha güvenli ve hızlı olarak yapılabilir hale geldi. Snapshot/Checkpoint teknikleri ile zararlının tüm davranış methodları tekrar ve detaylıca analiz edilebiliyor ve köşeye kıstırıldığı bu alanda eldeki tüm analyze silahları kullanılarak etkisiz kılınıyor ve zararlı tarihin karanlık kodlar çöplüğüne yollanıyordu. Tabi cephenin diğer tarafında bulunan zararlı geliştiricileri bu gelişmelere sessiz kalamazdı! Üstüne üstlük tüm bu savunma mekanizmalarının var oluş nedenleri yine zararlıların ta kendileri iken. Önceden olduğu gibi günümüzde de Zararlılar tespit edilmemenin dışında analiz edilmemek içinde oldukça efor harcıyorlar. Zararlı yazılım geliştiricileri, geliştirdikleri zararlının tespit edilmesi halinde analiz süreçlerini çok daha uzun ve içinden çıkılmaz bir hale getirmek için uğraş içerisindedirler. Aslında burada şunu da belirtmek gerekirse, kodlarının analiz edilmemesini isteyen kesim sadece zararlı geliştiricileri değil! Bir tarafta kötü amaçları için iyilerden kaçmaya çalışanlar olduğu gibi iyi amaçları için kötülerden kaçmaya çalışanlarda var! Ticari yazılım üreticileri programlarının lisans yükümlülükleri altında dağıtılmasını ve bu yol ile kazanç sağlamayı hedeflerler. Ancak bunun önünde Reverse Engineering yetenekleri oldukça gelişmiş Cracker camiasının elemanları bulunmaktadır. Değerli yazılımlarının lisans mekanizmalarının basitçe aşılmasına sessiz kalmak istemeyen yazılım üreticileri bir çok koruyucu tedbirlere yönelmiş ve onlarda yazılımlarını Anti-Analysis teknikleri ile koruma altına alma yoluna başvurmuşlardır. Hatta öyle ki Anti-Debug ve Anti-Analysis tamamen ticari bir kimliğe bürünüp kendine müşteriler bulmaya başladı. Armadillo, AsPack, Themida gibi Reverser'lara karşı koruma vaadeden yazılımların popülerliği hep gündemde yer bulmuştur.

Ne Kadar Bilgi O Kadar Analiz

x86 mimarisi üzerinde çalışan bir yazılım analiz edilmek istenildiğinde hangi dilde yazıldığına bağlı olmaksızın durumuna göre IA32 ve AMD64 komut ailesine ait assembly kodlarına dönüşürler. Analiz süreçlerinde assembly diline aşina olmak elbette önemlidir ancak tek başına yeterli olmayacaktır. Assembly bilginize ilave olarak çalıştığınız işletim sisteminin mimarisi üzerinde derinlemesine bilgi sahibi olmanız, kriptografi bilginiz, sanallaştırma ve emulasyon çözümlerinde ki derin teknik bilginiz analiz süreçlerinin çok daha kısa ve keskin sonuçlar vermesine katkı sağlayacaktır.

Test programımız üzerinde yapacağımız analizlerde de göreceğiz ki Anti-Analysis ve Anti-Debugging tekniklerinin bir çoğu Assembly dilinin getirdiği avantajları değil programın çalıştığı mimarinin yeteneklerini kullanır. Windows ortamında bir process'in ilk ortaya çıkması ile birlikte var olan TIB, PEB gibi yapılar gerek analiz gerekse anti-analiz süreçlerinde anahtar rol oynarlar. Bu ve bunun gibi internal yapıların iyi bir şekilde öğrenilmesi Reverser için analiz sürecini oldukça kısaltacaktır.

Bu test programı ile kazandığınız bilgiler giriş seviyesi olarak sizleri tatmin edecektir. Ancak ilerleyen fazlarda Assembly bilginizi neden ileri derecede geliştirmeniz gerektiğini fark edeceksiniz. Çok iyi bir assembly bilgisi ile ileri seviye koruma methodlarını yazılımlarınıza uygulayabilir veya Malware Analizleri esnasında karşılaştığınız engelleri rahatlıkla egale edebilir duruma gelirsiniz. Nanomites, Magic Opcodes, Stolen Bytes, Code Permutation, Garbage Code ve daha nice insan zekası ile opcode'ların birleşiminden oluşan bu zengin bilgi deryasına ancak iyi bir assembly bilgisi ile aşina olabilirsiniz.

Konu ve gelecek yazılar hakkında görüşlerinizi paylaşabilirsiniz.

Sağlıcakla.

Kasım 2013 - İbrahim Akgül

Uygulama İçi Static Key Zaafiyetlerine Öğretici Bir Yaklaşım

Şirketimiz'de staj yapan ve Security'ye ilgi duyan arkadaşlar için 1:1 eğitimlerin dışında örnek olarak hazırladığım bir dokumanı sizlerle de paylaşmak istedim.

Büyük ölçekli şirketlerin kurum içi Instant Message ihtiyaçlarını profesyonel ve free bir şekilde karşılayan Spark uygulamasın da denk geldiğim bir zaafiyet'den bahsedeceğim. Hemde bu vesile ile kriptografi öğrenimi sürecinde eğlenceli bir araç olan Cryptool uygulamasını tanıtmış olurum diye düşündüm.

Spark IM, kullanıcıları authentication işlemleri için Active Directory user hesaplarını kullandığından, sahip olduğu authentication mekanizmasınında bir o kadar güvenilir olması bekleniyor. Spark'ın sunucusu olan Openfire ile iletişimi ssl ile gerçekleşiyor ve Login prompt ekranında sunduğu parola hatırlatma seçeneğinin seçilerek sisteme giriş yapılması halinde girilen parolanın 3DES ile kriptolanarak bir dosyaya yazılması onu bulunduğu açık sistem üzerinde de güvenli kılıyor görünüyor. Ancak Spark açık kaynak kodlu bir ürün olduğundan bu parola bilgisini saklama esnasında kullandığı static key'e kolayca erişebiliyoruz:
http://svn.igniterealtime.org/svn/repos/spark/trunk/src/java/org/jivesoftware/spark/util/Encryptor.java

Aslında Opensource olmasa dahi herhangi bir uygulama encrypt/decrypt işlemleri için kullandığı key'i embed ettiğinde bir kaç Reverse adımı ile de sonuca ulaşabiliyorsunuz.

Statik key'i öğrendikten sonra, encode edilmiş parolanın bulunduğu dizini açıp (Windows 7'de C:\Users\username\AppData\Roaming\Spark\spark.properties) password keyword'ünün hashli içeriğini almamız gerekiyor. Bundan sonraki aşamalar ise süreci eğlenceli kılmamızı sağlayan kriptografik bir kaç dizi işlemi gerçekleştirmemizle devam ediyor.

İlk olarak size tavsiyem , şayet Kriptografi'yi seviyor ve merak ediyor ancak anlamakta güçlük çekiyorsanız mutlaka CrypTools uygulamasını sisteminize kurmalısınız. Cryptools gerçekten çok kullanışlı ve en sıkıcı hale bile gelebilen karmaşık kriptografik işlemleri sizin için eğlenceye dönüştürebilen bir uygulama.

CrypTool 2 karşılama ekranı

Yazının bundan sonraki kısmında Cryptool ile çalışacağız. Uygulamayı açtığımızda karşımıza gelen ekran üzerinden yeni bir boş proje seçerek decode işlemimiz için ilk adımı atıyoruz

Yeni proje açmak için workspace seçeneğini işaretliyoruz

Yeni projemiz için karşımıza gelen görüntü aşağıda ki gibi olacaktır. Ekranın sol kısmında yer alan araç çubuğu üzerinden projemizde kullanacağımız nesnelerinin seçimini yapacak ve sağ menüde bulunan bar ile de nesnelere ait özellikleri değiştirebileceğiz.

Workspace layout

Aşağıda ki resimden de görebileceğiniz gibi 2 adet TextInput, 1 Adet TextOutput ve asıl işlemleri gerçekleştirecek olan DES şifreleme nesnesini workspace'e ekliyoruz. Ardından eklemiş olduğumuz nesnelerin birbirleri ile iletişim kurabilmeleri için doğru renk kombinasyonuna sahip işaretleyiclerini mouse yardımı ile bağlıyoruz. Böylece gireceğmiz key ve encode edilmiş dataları DES cipher'ina gönderebilecek ve sonucu TextOutput penceresinden okuyabileceğiz.

Tasarım aşaması

Projemizin omurgası hazır olduğuna göre artık verileri doğru alanlara girmenin vakti gelmiş demektir. Yazının girişinde de belirttiğim Spark'a ait parola bilgilerinin encode edilmiş olarak durduğu dosya olan spark.properties'i bir editor yardımı ile açıp password keyword'ünün içermiş olduğu 32 karakterlik sabit uzunluğa sahip verimizi alıp bir sonraki adımımız için elde tutuyoruz.

spark.propterties dosyasından parola bilgisinin alınması

Yukarıdaki işlemin aynısını bu sefer secretKey için yine girişte url'ini verdiğim Sparkın kaynak koduna ait ilgili dosyadan temin ediyoruz. Artık elimizde biri kurbanımıza ait şifreli parola diğeri bu parolayı decode edecek keyimiz olmak üzere 2 verimiz var. Bu veriler base64 ile encode olduğundan Cryptools'da ki TextInput alanlarımıza girmeden önce decode etmeliyiz. Bunu net üzerinde online olarak gerçekleştiren bir çok siteden yapabilirsiniz.

http://www.opinionatedgeek.com/DotNet/Tools/Base64Decode/default.aspx 

Decode ettiğimiz keyin hexdecimal verisini 2 numaralı TextInput (bknz: alt resim sol alt köşe) nesnemize , parolaya ait olan decode verisinide 1 numaralı TextInput (bknz: alt resim sol üst köşe) yapıştırıyoruz. Bu aşamada text nesnelerinin sağ menü üzerinde bulunan özelliklerini hexdecimal olarak değiştirmeyi ihmal etmeyin. 

Artık PlainText parolamıza ulaşmamız için gereken tek şey DES nesnesinin özelliklerini ayarlamak. Ayrıca yazmak gerekirse DES nesnesine girdiğimiz attributes'lar aslında yine girişte linkini verdiğim Spark'ın source code'unda ki ilgili dosyadan elde ettiğim verilere dayanıyor. Özetle parolamız 3DES algoritmasının ECB mode'unu kullanarak şifreleniyor ve son aşamada PKCS7 yöntemi ile de son halini alıyor. Bizde bu veriler ışığında aynı seçenekleri seçip sadece bu defa encrypt yerine decrypt işlemi yapacağımızı belirtiyoruz. Bu işlem için DES nesnemizi seçtiğimizde sağ menüde görülecek olan özelliklerinden Actions alanını Decrypt, Chaining Mode'unu ECB, Padding Mode'u PKCS7 ve son olarak 3DES checkbox'ını işaretlememiz yeterli olacaktır. Tüm bu süreç sonunda Menü çubuğunda yer alan Play simgesine basarak decode edilmiş parolayı görebiliyor olacağız.

Sonuç

Ben programcıyım eğlenmek'te istemiyorum, bana decrypt edecek kodlar lazım diyenler için:

    private const string STATIC_KEY = "ugfpV1dMC5jyJtqwVAfTpHkxqJ0+E0ae";

    

    public static string Decrypt(string data)

    {

      var 3des = new TripleDESCryptoServiceProvider();

      3des.Mode = CipherMode.ECB; 

      3des.Padding = PaddingMode.PKCS7;

      3des.Key = Convert.FromBase64String(STATIC_KEY);

      var decrypt = 3des.CreateDecryptor();

      var b64 = Convert.FromBase64String(data);

      var result = decrypt.TransformFinalBlock(b64, 0, b64.Length);

      return Encoding.UTF8.GetString(result);

    }

Teşekkürler

Sahipsiz Blog

İş hayatı böyle gaddar işte! Verdiklerinden çok götürdükleri oluyor. Son girdimi 2 sene önce yazmışım. Demek ki blog yazarlığı bana göre değilmiş :( Hala varsa takipçilerden özür diliyorum. Aslında Google Analytics doğru söylüyorsa :p günlük 60'ın üzerine düşmemiş ve search edilen keyword'lere göre baya lowlevel  meraklısı varmış. Eğer başarabilirsem bu aralar bir şeyler karalamak istiyorum çünkü baya bi bilgi yüklü katır formundayım ve birileri ile paylaşmazsam bu bilgilerin değersizleştiğini düşünüyor insan. Mesala 6 ay önce Hyper-V 3.0'da keşfettiğim ve mission critical derecede değerlendirilip patch'i yayınlanan zevkli bir debugging serüvenini karalamaya başlıyorum. Hazır izindeyim bari bu sözümü tutayım. Daha böyle çok serüven var, umarım hepsini yazmayı başarırım ve birlikte eğleniriz.

Kernel Mode Driver Nedir? Nasıl Yazılır?

Tekrar merhabalar, seneler önce merakla Windows Nt tabanlı sistemler üzerinde Kernel Mode Driver  yazımı için kaynak aradığım zamanlardan rastladığım ve beğenerek takip ettiğim F-Four serisinden öğrenmiş olduğum bilgilerin ilk bölümünü arşivlerimden sizlerin huzuruna sunuyorum:

Bu makale de güncel olarak kullanılan Microsoft Windows 2003, XP, 2000, NT4.0 gibi Windows NT tabanlı işletim sistemleri üzerinde 32-Bit Assembly dili kullanılarak Kernel-Mode Aygıt sürücülerinin (device drivers) nasıl yazılacağı anlatılacaktır. Windows 95/98/ME versiyonları için VxD sürücüleri geliştirmek ise bu makalenin alanı dışındadır. Muhtemelen size aktardığım bilgilerde bazı konsept farklılıkları ve kişisel hatalar yapabilirim.

·       Mimariyi Tanıyalım

Ana Sistem Bileşenleri

Windows NT'nin mimarisi dahili olarak code denetimi (code permissions) ve adres boşluğu (address space) olarak iki kısma ayrılmıştır. Bu ayırım işlemi ile daha güvenli ve daha esnek bir işletim sistemi oluşturulması amaçlanmıştır. Ayrıca programcılar içinde yeni nesil işlemcilerin tüm yeteneklerinin kullanılması amaçlanmıştır. İşletim sistemi üzerinde çalışacak her programın çalışması için bir hafıza alanına ihtiyacı vardır. Bu alanlar işletim sistemi tarafından adres boşluklarının organize bir şekilde yönetilmesi ile uygulamalara paylaştırılır. Adres boşluğunun paylaşımı ise sanıldığının aksine basit bir mantığa dayanmaktadır. 32-Bit işlemci mimarisinde Adreslenebilir 4GB hafıza iki eşit parçaya ayrılır (tabi burada Fiziksel Adres açılımı olan PAE desteğini yok sayıyoruz)  ve bu iki parçadan kullanıcı modun'da (user-mode) olana bu boşluğun en düşük alanı olan 00000000 - 7FFFFFFFh adresleri arasındaki 2GB'lık alan verilir. Yani User-Mode dediğimiz user process'leri bu hafıza alanında çalışır ve bu onlar için bir sınır değerdir. Diğer kalan üst limit 80000000 - 0FFFFFFFFh 'lik doğrusal hafıza alan adresi oranı ise aygıt sürücüleri (device drivers) , sistem hafıza havuzu (system memory pools) ve sistem data yapıları (system data structures) gibi sistem bileşenlerine verilir. Bu adres oranlarına adreslenebilir hafıza alanları diyoruz. Bu hafıza alanları arasındaki ayrım ve yönetim işlemlerini ise hangi bileşenlerin kontrol ettiğini makalenin ilerleyen kısımlarında ayrıntılı bir şekilde işleyeceğiz.

User-mode'da çalışan temel işlemleri aşağıdaki şekilde tanımlayabiliriz:

• Sistem Destek İşlemleri (System Support Processes) - örneğin, Logon process'i (\%SystemRoot%\System32\Winlogon.exe dizininde yer alır);
• Hizmet İşlemleri (Service Processes) - örneğin, Yazıcılar için Spooler servisi (\%SystemRoot%\System32\spoolsv.exe'da yer alır);
• Kullanıcı uygulamaları (User Applications) - beş çeşittir: Win32, Windows 3.1, MS-DOS, POSIX ve OS/2;
• Ortam AltSistemleri (Environment Subsystems) - Windowsta üç çeşit ortama ait processleri çalıştırabilirsiniz: Win32 (\%SystemRoot%\System32\Csrss.exe yer alır); POSIX (\%SystemRoot%\System32\Psxss.exe'yer alır); OS/2 (\%SystemRoot%\System32\Os2ss.exe yer alır).

Windows XP ile birlikte artık OS/2 alt sistemi kaldırılmıştır.

Kernel-Mode bileşenleri ise aşağıdaki gibi tanımlanabilir:

• Yönetim (Executive) - hafıza yönetimi, process ve thread yönetimi, security, etc.;
• Kernel - thread'ların planlanması, kesme isteği(interrupt) ve istisna işleme (exception dispatching), etc. (Executive ve Kernel \%SystemRoot%\System32\Ntoskrnl.exe tarafından icra edilir);
• Aygıt Sürücler (Device Drivers) - Donanım aygıt sürücüleri (hardware device drivers), dosya sistemi sürücüleri (file system) ve ağ sürücüleri ( network drivers);
• Donanımdan soyutlandırma katmanı (Hardware Abstraction Layer), HAL - Kernel'den aygıt sürücülerden yönetim biriminden ve platforma özel donanım farklılıklarından yalıtılmış bir birimdir. ( \%SystemRoot%\System32\Hal.dll'de yer alır);
• Pencere ve Grafik sistemi (Windowing And Graphics System) - Pencerelerle çalışmak, kullanıcı arayüz kontrolleri ve çizim (drawing) işlemleri ile uğraşmak için grafiksel kullanıcı arayüzü (Graphical user interface [GUI]) fonksiyonları sağlar. ( \%SystemRoot%\System32\Win32k.sys'de yer alır).

1.1.2 Kernel Mode vs. User Mode

Aslında Intel x86 işlemcileri 4 adet imtiyaz seviyesi (privilege levels) sağlar (ring olarakta anılırlar) , ancak Windows bunlardan sadece 2 sini kullanır. Bunlar Kernel-Mode için privilege levels 0 (veya ring0) , user-mode için ise privilege levels 3 (veya ring3) seviyesidir.

Her user-mode processi kendine ait özel bir hafıza boşluğuna sahiptir. Processler en düşük imtiyaz seviyesinde (user-mode veya ring 3 diyebilirsiniz) çalıştıklarından, özel cpu komutlarını icra edemez, sistem data'ları ve sistem adres boşluğuna erişim sağlayamaz ve donanıma doğrudan erişim yapamazlar. Örneğin user-mode'da çalışan bir process adres boşluğunun kernel-mode tarafına ait bir orandaki hafıza adresine (8000000-0FFFFFFFFh) ulaşmaya çalışırsa, sistem o işlemi hemen sonlandıracaktır. User-Mode processleri sistem servislerini çağırarak kernel-mode'a geçiş yapabilirler ancak bu durum o hizmete yaptırılan işlemlerle sınırlıdır ve  process user-mode'a döner dönmez tüm kontrolü tekrar kaybedecektir.

User-Mode processleri sistem stabilizesini bozabileceklerinden potansiyel tehlike olarak görünürler. Bu yüzden sahip olduğu imtiyazlar sert çizgilerle belirlenmiştir ve yetkisizce yapmaya çalıştığı her işlem anında sonlandırılır.

Kernel-Mode bileşenleri ise kernel-mode hafıza alanını ortak bir şekilde paylaşırlar, en üst imtiyazlarla (ring0) çalışabilir ve istedikleri CPU komutunu çalıştırabilirler. Kısacası erişimleri sınırsızdır.

Sistemin adres boşluğunda çalışan kodlar tümüyle güvenilir olarak düşünülür. Bir sürücünün yüklenmesi esnasında sistem o sürücü kodlarını kendi bölümüymüş gibi varsayar. Driver'lar kernel'in kendi güvenilir bileşenleri listesinde yer aldığından istediği her erişimi sınırsızca yapabilir.

Tam olarak ifade edersek user-mode uygulamaları işletim sistemi tarafından bütünüyle soyutlanmıştır. Aslında bu işletim sisteminin bütünlüğü açısından iyidir, fakat , debugging araçları gibi bazı yardımcı araçların için tam bir baş ağrısıdır. User-Mode uygulamaları ile sistemle bütünleşik bir yazılım gerçekleştirmek çoğu zaman imkansızdır. İşletim sisteminin dahili fonksiyonları ve data yapıları'na user-mode'dan asla ulaşamazsınız bunun için yapmanız gereken sistem adres boşluğunun içerisine girmektir buda  kernel-mode düşerek olur.

Windows NT Device Drivers

1.2.1 Aygıt Sürücülerinin Tipleri

Windows NT geniş bir yelpazede aygıt sürücü tiplerini destekler, bunları aşağıdaki gibi listeleyebiliriz:

• User-Mode Drivers:
• Virtual Device Drivers (VDD) - 16-bit MS-DOS uygulamalarını emule edebilmek için kullanılan bir user-mode bileşenidir. Karıştırmayasınız diye yazıyorum Win 9x zamanı VxD'lerle benzer bir yanları yoktur.
• Printer Drivers - Aygıttan bağımsız baskı isteklerini yazıcıya özel komutlara çevirirler.
• Kernel-Mode Drivers:
• File System Drivers - Standart dosya sistem işlemlerini yerine getirirler.
• Legacy Drivers - Windows 2000/XP/2003 üzerinde değişmemiş ama önceki Windows NT versiyonları için yazılmış farklı sürücülerden yardım almaksızın bir donanım aygıtını kontrol etmeye yarayan sürücü çeşididir.
• Video Drivers - görsel data işleme;
• Streaming Drivers - ses ve tv kartı gibi multimedia aygıtları içindirler;
• WDM-Drivers - Windows Driver Model konseptine bağlıdırlar. WDM; Windows NT'nin güç yönetim desteğini ve tak çalıştır desteğini destekler. WDM'ler işletim sistemleri arasında binary uyumlulukları sayesinde kaynak-uyumu sağlarlar. Örneğin Windows 2000 için yazılmış bir WDM driver Windows Me ve 98 üzerinde çalışabilir.

Bunlardan farklı modellerde vardır ancak şimdilik bu konsepti tanımanız açısından yeterlidir.

Adlarında da gayet net anlaşılacağı gibi aygıt sürücüler bir aygıtı kontrol etmek için kullanılırlar. Ancak iyi bir tarafları vardır ki bu aygıt illa ki fiziksel bir aygıt olmak zorunda değildir. Dilerseniz sanal bir aygıt oluşturup onu programlayabilirsiniz.

Yapısal olarak aslında aygıt sürücüleri bir PE-format (Exe) dosyasından başka bir şey değildir. Aygıt sürücüler (Device Drivers) yüklenebilir kernel-mode modülleridirler. Genel olarak .sys uzantılarına sahiptirler. Aygıt sürücüler yükleme ve yönetim açısından bütünüyle farklı yollara sahiptirler. Gerçekte kernel-mode dll'leri user-mode tarafında çözülemeyecek görevleri yerine getirilmesi için tasarlanırlar. Bir de şu var ki biz user-mode processlerimiz ile aygıt sürücülerimizin ne kod ne de data alanlarına ulaşamayız. Bizim sürücülerimizle irtibat kuracağımız tek yol I/O Yöneticisi (I/O Manager)'dir.

Kernel-mode aygıt sürücüsü geliştirme aşamasında kendinizi bütünüyle çaylak hissedecek ve aslında önceden öğrendiğiniz onca programlama ve Win32API bilgisinin şimdi nasıl olup ta size yardımcı olamadığına şahit olacaksınız. Belki bundan önce hatırı sayılır user-mode uygulamaya imza atmış olabilirsiniz ancak kernel-mode mimarisinin komutları ve yapıları bütünüyle farklıdır.

·        Katmanlı ve Monolithic (Tek-Katmanlı) Aygıt Sürücüleri

Katmanlı sürücülerin çoğu fiziksel aygıtları kontrol etmek için yazılırlar. Adlarından gayet net anlaşıldığı gibi katmanlı sürücüler drivers stack olarak ta anılan bir konseptle en alt katmandaki sürücülere en üst katmandan aldıkları istekleri işleyerek veya bunun tam tersini yaparak çalışırlar. Bu mimaride I/O isteklerinin işlenmesi (handling request) görevi farklı sürücüler arasında dağıtılmıştır. Örneğin sabit disk üzerindeki bir dosyayı okumak isteyen uygulama’nın i/o istekleri önce dosya sistem sürücüsüne geçirilecek, oradan da disk sürücüsüne yönlenecek ve disk üzerinde veriyi okuyacaktır. Driver geldiği katmansal yolun tam tersini işleyerek veriyi uygulamaya ulaştıracaktır. Dilerseniz sizde bu katmansal mimarinin herhangi bir yerinde araya girerek filter-driver yazabilir , gelen ve giden veriyi encrypt/decrypt gibi şifreleme işlemlerine tabi tutabilirsiniz.

Monolithic driver ‘lar ise aygıt sürücülerin en basit tipleridirler. Yine adlarından anlaşılacağı gibi katmansız bir mimarileri vardır ve layered modeldeki gibi diğer driver’lar ile i/o işleme konusunda herhangi bir paylaşım yapmazlar. Sık olarak doğrudan user-mode uygulamalarına tek başlarına arayüz olarak destek vermeleri gerektiklerinde yazılırlar. Geliştirme ve debugging hizmetleri ise tanımlanabilir en basit görevleridir. Zaten makalenin ilerleyen kısımlarında böyle bir driver yazacağız ve ne anlatmak istediğimi daha iyi anlayacaksınız. Diğer aygıt sürücüsü kategorileri ise şimdilik yazımızın kapsamı dışındadır.

·       Thread context

Çoğu durumda yalnızca tek bir işlemciye sahip olduğumuz için, sistemin uygulamaları icra ediş şekli bizi hep bu işlemlerin aynı anda oluyormuşcasına izlenimine sokar. Çalışan tüm uygulamalar için işletim sistemi cpu zamanını herbir processin thread’ları için ayrı ayrı dilimlere ayırır. Cpu tek bir kaynaktır ve bu kaynağı işlemlerin sırası ile kullanabilmesi için Round-Robin denen algoritma kullanılır. Bu teknik sayesinde cpu ile olan işi kendine verilen quantum sürelik zamanı aşmasına rağmen bitmeyen bir thread’ın o anki tüm çalışma bilgileri bir yapıya geçirilip (CONTEXT) makine durum registerleri (msr)’lere saklanır ve sonraki thread’a geçilir.  Tabi bu teknik aslında çok daha kompleks işlerde yapar ama şimdilik bunlar bizim için yeterlidir. Birde fiziksel olarak işlemcilerin 1’den fazla olduğu durumlar vardır ki o zaman thread scheduling işlemi daha da karmaşık bir hal alır. Böyle bir yapıda thread’lar çekirdekler arası yük paylaşımına sokulur ve işletim sistemi çok daha gelişmiş kompleks algoritmalar kullanarak yönetim yapar. Thread’lar arası geçişte eğer bir sonraki çalışma sırası gelen thread aynı uygulamaya ait bir thread ise , işlemci tarafında sadece yukarıda tanımlamasını yaptığım basit bir thread context gerçekleşir. Lakin geçiş yapılan thread farklı bir process’e ait bir thread ise , işte o zaman hem bir “thread context switch” hemde işlemcinin CR3 register’inin içerisine o processe ait page table yüklenir.

Her kullanıcı işlemi (user process) kendine ait özel bir adres alanına sahiptir. Bu da şu demektir ki : her user process’i sayfa tablolarını (page tables) farklı sayfa dizinlerinde (page directory) tutar. Sayfa tabloları (page tables) sanal (virtual) adresleri fiziksel adreslere çevirmek için işlemcinin kullandığı tablolardır. Bu tabloları hazırlamak işlemcinin sorumluluğundadır ve her process’te mutlaka olmalıdır. İşlemci context’ine girdiği thread’in cr3 register’inada bakarak kullanacağı hafıza alanını tespit eder ve hafıza alanından faydalanmasını sağlar. Aslında kernel-mode’da driver yazarken bu işlemlerle bizim doğrudan bir etkileşimimiz yoktur. Fakat her context switch cpu israfına neden olduğundan driverlar genellikle kendileri thread olusturmazlar . Bu yüzden context switch’ler esnasında CPU zamanından tasarruf edebilmek için kernel-mode’da çalışan driver’lar üç çeşit context’ten birini kullanır:

·         Kullanıcı thread’inin context’in de bir I/O işlemi ile birlikte ;

·         Kernel-mode sistemi bağlamındaki threadlar olarak;

         Veya bir interrupt vasıtası ile  .

·       Kesme isteği seviyeleri

Kesmeler (interrupts) her işletim sisteminin de bulunan en önemli kısımlardandır. Her kesme oluştuğunda işlenmesi gerekir ve bu yüzden işlemci bir kesme oluştuğunda o anki normal akışını durdurur ve kesme'yi ilgilendiren koda dallanır. Yazılımsal ve Donanımsal olarak iki tip kesme vardır. Kesme'lere önceliklerine göre hizmet edilir. Düşük önceliğe sahip bir kesme akışına devam ederken, sonradan gelen yüksek öncelikli bir kesme bu akışı durdurup akışı ele geçirebilir.

Windows kesmelerin öncelik şemasını kesme isteği seviyeleri (interrupt request levels[IRQL]) olarak bilinen bir sistemle yönetir. Kernel IRQL'leri 0 dan 31'e kadar olan bir öncelik sırasına göre sıralar. Bu seviyelerden en yüksek duruma sahip olan en imtiyazlı interrupt olarak bilinir. Unutmadan belirtmeliyim ki IRQL imtiyaz seviyeleri ile işleç-programlama (thread-scheduling) arasında farklılıklar vardır. Bu yüzden birbirleri ile karıştırmayın.

Yukarıda ki tanımlamalarımıza göre IRQL=0 'a sahip bir kesme aslında bir kesme olayı başlatıp bir kodun akışını kesmez. Yani açıkçası aslında zaten o bir kesme değildir. User-Mode'da çalışan her thread passive level'de yürütülür. Bizim yazacağımız kodlarda bu IRQL seviyesinde olacaklardır. Böylelikle yazdığımız kodlar, başka akışların yarıda kesilmesine sebebiyet doğurmayacak. Tabi bu demek değildir ki her driver passive level de çalışacak. Bu sadece bizim örneklerimiz için geçerlidir.

Son olarak şunları belirtmekte fayda var:

Birincisi: Sürücü kodlarını icra ederken daha yüksek IRQL'le sahip bir işlem tarafından her zaman için akışı kesilebilir. Sürücü içersinde kod işleme aşamasında güncel IRQL seviyenizi öğrenebilir ve işleminizin yarıda kesilmemesi gereken kod bloklarında IRQL seviyenizi arttırabilir ve azaltabilirsiniz.

İkinci olarak: Passive IRQL seviyesindeyken bile her kernel fonksiyonunu çağırabilirsiniz. (Ayrıca DDK her fonksiyon için istenen IRQL seviyesini belirtmiştir). Ayrıca sayfalı(paged) ve sayfasız(nonpaged) adresleme yapabilirsiniz. Hafıza Yöneticisi sayfa hatası (page fault) hizmetleri açısından yetersiz kaldığından yüksek bir IRQL'de (DISPATCH_LEVEL veya daha yüksek (15-31 arası mesala)) paged bir hafıza alanına erişmeyi denerseniz sistemin çökmesine sebep olursunuz.

·       Sistem Çökmeleri

Daha önce hiç rastlamadım demeniz mümkün değil! Neden mi bahsediyorum? Tabi ki Meşhur Mavi Ekrandan (BSOD[Blue Screen of Death]). Muhtemelen hepte hiç beklemediğimiz bir anda ansızın karşımıza çıkmıştır. Ama onu uzun süredir göremiyorsanız üzülmeyin, çünkü kernel-mode'da driver yazarken kendisi ile bol bol haşır neşir olucaz :)

Windows kermel-mode 'da çalışan sürücüler tarafından kullanılan özel sistem hafızasını korumak için herhangi bir koruma işlemi yapmaz. Driver kernel-mode'a bir kere kancayı attımı artık tüm işletim sistemi dataları ve sistem hafıza alanı onun için serbest bölgedir. Bu yüzden driver'imizi kodlarken önceden planlı bir yapılanma izleyip sistem stabilitesini tehlikeye atmamamız şart.

Artık yukarıda anlatılanları iyice kavramanız şart. Şayet sizde kernel-mode'da bir driver'da benim olsun diyenlerdenseniz thread context, interrupt request levels, kernel-mode ve user-mode etc... gibi kavramlara mutlaka aşina olmak zorundasınız.

·       Driver Development Kit

Windows DDK ile aygıt sürücü geliştirme aşamasında ihtiyacımız olan tüm dahili sistem rutinleri ve data yapılarına erişebiliriz. Windows DDK, MSDN Profesyonel üyeliliğinin bir parçasıdır. Dilerseniz http://msdn.microsoft.com 'dan online olarak dokümantasyonlara erişebilir ve eğer Türkiye'de iseniz sembolik ( kızmayın :p ) bir ücret ödeyerek kargo ile microsoftun size gerekli kütüphane ve örneklerle komple kiti  göndermesini sağlayabilirsiniz.

·       MASM programcıları için Kernel-Mode Driver Kit

KmdKit sizin assembly dilinin gücünü ve Masm32 compiler'inin yeteneklerini birleştirerek aygıt sürücüleri yazabilmenizi sağlayacak alt yapıyı oluşturur. İndirmek için lütfen tıklayın :

http://www.freewebs.com/four-f/KmdKit/KmdKit.zip

·       Driver Debugging

Yazdığımız kernel-mode sürücülerini yine kernel-mode'da çalışacak debugger'lar vasıtası ile analiz edebiliriz. Bunun için en ideal araç ve tercihim Compuware firmasının Driver Studio ürünüdür. İçerisinde barındırdığı güçlü debugging yetenekleri ve sembol dosyası desteği ile daha boot aşamasından itibaren kernel'i ve yükleme aşamasından itibarende driver'larımı ayrıntılı olarak debug etme fırsatımız oluyor. Ayrıca birde microsoftun ücretsiz WinDbg ürünü var. Şayet iki pc'niz var ise diğer pc'nin kernelini adım adım yükleyebilir ve tüm sistemi tam anlamı ile kontrol edebilirsiniz. Birde ünlü SysInternals ekibinden Mark Russionovich'in yazdığı tool'u kullanarak windbg ile ikinci bir pc'ye ihtiyaç duymadan live debuging yapabilirsiniz.

Faydalı kaynaklar

• David Solomon, Mark Russinovich, "Inside Microsoft Windows 2000. Third Edition", Microsoft Press, 2000

Aygıt sürücü yazarları ve adayları için bir numaralı kaynak. Bu kitabı okuyarak benim iğrenc makalemi okumak zorunda kalmayabilirsiniz :}

• Sven B. Schreiber, "Undocumented Windows 2000 Secrets. A Programming Cookbook", Addison-Wesley

Bu da baş ucu eseri olma niteliğinde Win2000 neredeyse tüm gizliliklerini ifşa etmiş bir eser.

• Walter Oney, "Programming the Microsoft Driver Model", Microsoft Press, 1999

        Walter'in anlatımı çok ağır ve zaten karmaşık olan bir konuyu iyice zorlaştırmış ama yinede okunması gerekir

• Walter Oney, "Programming the Microsoft Windows Driver Model. 2nd edition", Microsoft Press, 2003

İşte bu diğerine 5 basar. hem anlatım sadeleşmiş hemde plug-in-play hiç bu kadar kolay anlatılmamıştı..

• Art Baker č Jerry Lozano, "The Windows 2000 Device Driver Book, A Guide for Programmers, Second Edition", Prentice Hall, 2000

Bunu okumadım ama referansı iyiye benziyor ve konumuzla tamamen alakalı olduğundan buraya yazdım

• Rajeev Nagar, "Windows NT File System Internals. A Developer's Guide", O'Reilly

Bu kitap varken bu makaleyi yazmamalıydım :)

• Prasad Dabak, Sandeep Phadke, and Milind Borate, "Undocumented Windows NT", M&T Books, 1999

• Gary Nebbett, " Windows NT-2000 Native API Reference", MacMillan Technical Publishing, 2000
• Jeffrey Richter, "Programming Applications for Microsoft Windows. Fourth Edition", Microsoft Press, 1999

Serinin ikincisinde görüşmek üzere...

Stuxnet hakkında herşey

Blogu bu aralar ziyaret edenlerin çoğu stuxnet cümlesini kullanmışlar. Bende ziyaretçilerin elini boş göndermemek için bir derleme yaptım. Aşağıda ki doküman ve videolar bu konudaki tüm soru işaretlerini silecektir diye umuyorum.

Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 1

Analyzing a Stuxnet Infection with the Sysinternals Tools, Part 2

Stuxnet is embarrassing, not amazing



Stuxnet hakkında yapılmış belgesel tadında bir video:

Stuxnet: Anatomy of a Computer Virus from Patrick Clair on Vimeo.

Stuxnet, kısacası; ileri reverse engineering ve çalıştığı mimariye ait derinlemesine assembly bilgisi olanlar için yapılabilirilitesi gayet mümkün olan bir iş.

Windows'un Evrimi (Video)

Windows işletim sisteminin Dos 5.0'dan Windows 7'ye kadar çıkmış tüm sürümlerinin hızlıca ve sade bir dille anlatıldığı çok hoş bir çalışmayı paylaşmak istedim.