30 Haziran 2009 Salı

SSDT Hooking nedir?

Bilgisayarlarımızı amacı doğrultusunda güzel güzel kullanmak varken - birde kalkmış ne yaptığı belirsiz sayısız zararlı tehdit'i ile uğraşıyoruz. Sanki her biri belirli biz masum son kullanıcıların üzerine atılmış birer KANCA! gibi.

Çok fazla Steven Spielberg okuyorum herhalde jargonum değişti. Neyse; Hooking! Kimine göre gerekli bir mekanizma ama çoğunluk öyle düşünmüyor. İşletim sisteminde yer alan bu faideli ama tehlikeli oyuncak ile dilediğiniz emele ulaşmak içinizdeki şeytanın fısıltıları ile doğru orantılı. Gerek usermode taraflı gerekse kernel taraflı çeşitleri olan hooking işlemini kısa tanımı şöyle olsa gerek:

KernelMode Hooking = "İşletim sistemi bünyesinde bulunan orjinal hizmet fonksiyonlarının hafıza tabanlı adreslerinin ikinci bir dış odaklı amaca hizmet edecek başka bir fonksiyon adresi ile değiştirilmesine" denir. Bu alanların değiştirilmesi işletim sistemi tarafından belirli koruma mekanizmaları ile sağlanmaktadır (bkz:cr0 flags), ancak malumdur ki bu konuda başarı sağlanamamaktadır.

UserMode Hooking = İşletim Sisteminin GUI arayüzünü temsil eden ve usermode çağrılarının ilgili window'lara gönderilmeden önce birinci elden kendini legal hooking mekanizmasına kayıt ettiren kullanıcı processi tarafından işlenmesi ile yapılan hooking çeşitidir. Kullanımı ve dökümantasyonu Microsoft tarafından yapılır.

Api Hooking = Kernelmode hooking de anlatılan mantıkla çalışır ancak bunu koruyan bir mekanizma yoktur. Processlere ait hafıza alanlarında yer alan fonksyion adreslerinin değiştirilmesine dayanır.

Görüldüğü üzere var olan bir sistem akışını ikinci bir müdahale ile istenilen başka bir davranış biçimine sokmaya hooking deniyor. Bunu diler injection ile yapın dilerseniz legal olarak register ile yapın farketmez eğer amacınız sistemin veya kullanıcın hassasiyetlerini gözetmeden suistimal etmekse yaptığınız zararlı yazılım davranışı olacaktır. Burada etraflıca hooking'in bilinen tüm tekniklerini anlatmak ve örnekleri ile açıklamak gibi bir maceraya atılacağımı düşünmüyorsunuz herhalde :) Amacım sadece son yıllarda popülerliğini ve sahip olduğu low level hakimiyeti ile risk derecesini tavan yaptıran KernelMode Hooking kapsamına giren System Service Descriptor Table (SSDT)'nin nasıl modifiye edilebileceği, hangi amaçlar doğrultusunda kullanılabileceği ve nasıl bu yapının korunabileceğine dair kısa açıklamalar yapmaktır. Anlatacaklarımın kalan kısmını okuyan arkadaşların orta seviyede usermode ve kernelmode bilgisi sahibi olması tercih sebebidir.

Win32 Api ortamında kullandığımız fonksiyonların önemli bir kısmı yeteneklerini yardımcı kütüphaneler vasıtası ile gerekli güvenlik ve parametre kontrol işlemlerinden geçtikten sonra kernel mode taraflı bir fonksiyona dallanarak gerçekleştirirler. Bunlardan en çok bilinenleri kernel32.dll ve user32.dll kütüphanelerinde yer alan fonksiyonlardır. Bu kütüphanelerinden birinin export ettiği fonksiyonu kullanan bir process'i usermode çalışan bir debugger(bkz:ollydbg) ile debug ettiğinizde kodun akışını en fazla ntdll.dll kütüphanesi içerisinde yer alan "sysenter" komutuna kadar trace edebilirsiniz. Bu komuttan sonrasını izleyemez ve arka planda gerçekte ne gibi işlemler döndüğünden haberdar olamazsınız. Örnek olarak ExitProcess api'sini uygulamanızdan çağırdınızda izlediği yol şöyledir:

1- Processinizin iat'da yer alan JMP DWORD PTR DS:[&Kernel32.ExitProcess] gerçek fonskiyon adresine zıplar .
2- Oradan da bir kaç dizi parametre kontrol işlemi geçirdikten sonra ntdll.NtTerminateProcess apisini çağırır
3- Son olarakta ntdll.dll kütüphanesi içerisinde bu api ye (NtTerminateProcess) atanmış olan serviceID (bu xp sp3 için 0x101'dir) ile birlikte parametreleride stack'te hazırlayıp "sysenter" komutu ile kontrol asıl fonksiyonu yerine getirecek kernelmode taraflı fonksiyona geçer.

Bu aşamadan sonra süreç kernelmode katmanına geçer. Peki bu süreç nasıl işler? Şimdi de dilerseniz biraz derinlere dalalım ve sysenter sonrası işlemler silsilesine göz atalım.

Windows Xp ve 2003'ün çıkması ile birlikte Microsoft, Intel x86 komut seti kümesine kazandırılan "sysenter" adlı komut ile system service hizmetini sunmaya başladı. Bu komutun çalışması için 2 ön şart gereklidir:

1- Kullanılcak native api serviceID'si
2- Bu ServiceID'ye denk gelen kernel taraflı fonksyion adresini tutan bir tablo.

Windows işletim sistemi boot esnasında bu tabloyu işlemci ailesine göre kullandığı uygun çekirdek dosyası ile ki genelde bu ntoskrnl.exe'dir alarak doğru fonksiyon adresleri ve serviceID'lerini hazırlar ve sysenter komutunun çevrimsel başvurusu için kendini referans gösterip usermode çağrıları için hizmet verecek hale getirir.
Bu tablo kernel symbol referansı olarak KiServiceTable adını alır ve KeServiceDescriptorTable olarak bilinen struct içerisinde adresi tutulur. Tabloda yer alan her serviceID'ye fonksiyonu yerine getirecek uygun kernel taraflı fonksiyonun hafıza adresleri atanır ve özetle tablo artık usermode çağrılarına cevap verecek halini almış olur. Az önce de bahsettiğim gibi normal şartlar altında bu tablo readonly dir ve kernel tarafından yazma korumalıdır ancak minik bir trick le üstesinden gelinip bsod'a meydan vermenden değişiklik yapma şansınız olabiliyor.

Hikayenin TerminateProces ve usermode'dan bir sonraki adımına geldiğimize göre sürecin işleyişinide yukarıdaki anlatımlara göre nasıl şekillendiğinide anlamış olmalısınız. Artık posta kuşumuz elimizden uçtu ve tüm kontrol onda. Win32 api'lerinin tasarımı süphesiz kendi güvenlikliklerinide kapsıyordu ve bunun için System Service Table'larının bu amaçla kullanımı gayet uygundu. Tüm parametre ve çağrılar birinci elden usermode tarafındaki kütüphanelerde gerekli kontrollerden geçiyor ve son olarak artık kullanıcı kodunun erişim imkanı olmayan ve tamamı ile microsoft yazılımcılarının yazdığı güvenilir!!! kod akışına geçiyordu. Ta ki bu işi yüklenmiş olan bu güzide tabloya birinin müdahele etmeyi başardığı zamana kadar.

Aslında bu tabloyu antivirüs üreticileri bile modify ederken bunu başka bir zararlının yapamayacağını düşünmek mantıksız olurdu. Evet çoğu antivirüs ve yazılım tabamlı firewall üreticileri bu tabloyu hook ederek sistemin işleyişine müdahil olurlar. Bir önceki makalemde açığından bahsettiğim Zemana Antilogger gibi HIPS kategorisindeki yazılımlarında kalbide bu katmanda atar. Günümüzde halen usermode taraflı keylogger yazmayı düşünen arkadaşların ne yazık ki bu tip doğrudan api function'una yönelik kısıtlama getiren anti'lere karşı hiç bir şansları yok. Ta ki onlarda bu tabloya müdahele edip kendi amaöçları için değiştirinceye kadar. Peki bu tabloya programcı nasıl müdahale eder. Şunun farkındayım; bu blog çatısı altında kodlama ile uğraşanların çoğu high level dillere aşina ve burada anlattıklarımı koda dökmeleri çok zor ama yinede meraklısının bilmesi gerektiği kanaatindeyim.

Gerek zararlı rootkitler olsun, gerek sizi bu rootkitlerden koruyacağını idda eden savunma programları olsun SSDT denen bu tabloyu hook ederek bu işlevselliklerini sağlarlar. Yani iki tarafında yaptığı bu tabloyu uygun şekilde modifiye ederek kendi amaçları doğrultusunda kullanmaktan ibaret. Örneğin aslında tamamı ile Windows çekirdeğine ait fonksiyon adresleri ile dolu olması gereken bu tablonun Zemana Antilogger uğradıktan sonraki şekli aşağıdaki gibidir:

c:\program files\antilogger\antilog32.sys
0x0025 - NtCreateFile
0x0035 - NtCreateThread
0x003F - NtDeleteKey
0x0041 - NtDeleteValueKey
0x0061 - NtLoadDriver
0x006C - NtMapViewOfSection
0x0074 - NtOpenFile
0x0077 - NtOpenKey
0x007A - NtOpenProcess
0x007D - NtOpenSection
0x0080 - NtOpenThread
0x00B4 - NtQueueApcThread
0x00D2 - NtSecureConnectPort
0x00D5 - NtSetContextThread
0x00F0 - NtSetSystemInformation
0x00F7 - NtSetValueKey
0x0101 - NtTerminateProcess
0x0115 - NtWriteVirtualMemory

Gördüğünüz gibi 18 adet hook edilmiş fonksiyonun listesi ve yanlarında ait oldukları serviceID'leri. UserMode tarafında bir process erişimi, dosya işlemi, port erişimi, fiziksel hafızaya işlemleri ve code injection gibi bir çok işleme ait orjinal fonksiyon çağrıları birinci elden KernelMode katmanında AntiLogger sürücüsü tarafından işlenmekte. Böylelikle program sistem'de erişim kısıtlama ve erişim izni verme yetkilerinede sahip olmuş oluyor. Tabi amacı itibari ile de olması gereken bir işlem bu. Ancak bu işlemin aynını rootkitlerde yapıyor ki bu yüzden microsoft ve işlemci üreticileri buna dur diyerek KPP (Kernel Patch Protection) adı verilen bir sistemle bunun önüne geçmiş durumda(yada şimdilik öyle görünüyor) [1 yıl sonra gelen edit : evet öyle görünüyormuş artık ilk x64 rootkit örnekleri piyasaya çıktı]

Gelelim bu tabloyu nasıl değiştireceğinize. Hızlıca özetlersem \\device\\physicalmemory nesnesine erişim izni alarak işletim sisteminizin kullandığı orjinal kernel dosyasının içerisinden (benim core2 işlemcim için bu ntkrpamp.exe'dir) orjinal Service Dispatch Table fonksiyon adreslerini alıp hook edilmiş olanların üzerlerine yazarak çalışacak her türlü anti'den önce etkisiz kalmasını sağlayabilir veya doğrudan bir kernel rootkit yazarak bazı Antilerin tümü ile etkisiz kalmasını sağlayabilirsiniz.

Sizlerde dilediğiniz gibi üzerinde oynayabilir yada SSDT Hooking mantığını anlayıp kendi özel hook'unuzu yazıp korkusuzca sistemlerde cirit atabilirsiniz. Birdaha ki makaleye kadar sağlıcakla.

İbrahim Akgül

26 Haziran 2009 Cuma

Benmi geç kaldım! Yoksa birileri fazlamı uyanık?

Bilgisayar teknolojilerinin gelişimi ile birlikte iyi ve kötünün yararlı ve zararlının da savaşı siber alemde başlamış oldu. Donanımlar ve İşletim sistemleri gelişip yaygınlaştıkça, bunları suistimal edip kendi çıkarlarına kullanmaya çalışanların sayısında doğru orantılı bir artış oldu. Tabi tepkisel olarakda aynı düzlemde bu zararlılara karşı bir çok önlem alındı.

Özellikle 90'lı yıllardan sonra büyüme trendi maksimuma çıkan ve internet'in de yaygınlaşması ile artık önü bir türlü alınamayan bilgi hırsızlığı problemi altın çağını yaşamakta. Her zaman bir adım önde olan zararlı üreticileri, kendilerini egale etmeye çalışan onlarca orta ve büyük ölçekli sistem savunma firmalarına her defasında çalım atmaktalar. Tek bir coder'in yazdığı zararlının peşinden koşan bu büyük abiler günlerce uğraşmalarına rağmen çoğu zaman çaresiz kalmaktadırlar. Şu an hepinizin anımsayacağı bu büyük Güvenlik firmaları onlarca çalışanı ve ar-ge çalışmaları ile her yeni gün savaşta bir adım daha önde olabilmek için gayret göstermekteler. Ancak bugune değin hiç bir zaman kendilerinden zararlılara karşı kökten çözüm vaadi ve kendilerini kusursuz bir savunma sistemi imiş gibi beyan ettiklerini görmedim. Çünkü böyle bir söylem işletim sistemini üretenlere bile gerçekçi gelmiyorken bu sektörde yer alan orta halli bir kullanıcıya dahi komik gelecektir.

Ancak her ne hikmettirki uzun zamandır takip edemediğim ancak son 1 haftadır "dur bakalım neler yeni" edası ile göz atarken Türk Sistem!!! yazılımcılarının geliştirdiklerini iddaa ettikleri koruma yazılımlarından bir çoğu bu safsata ile kendilerini sektöre lanse eder olmuş. Bu beyanatlar çok dikkatimi çekmiş olacak ki bu ürünlerden en iddaalı olan üçünü sistemime kurdum ve tipik zararlı mantığı ile önce düşmanı yok et hedefini gözeterek yaptığım defeat&inject testleri ile kendilerini test ettim. Sonuçmu? Home 3:0 Away

Kendi Processlerinin açıklarını yamamayan bu yazılımlar bizi nasıl koruyacak! Açıkcası şayet bu aşamayı geçselerdi vaadettikleri koruma modüllerini deneme hevesim olacaktı.


Zaten x64 bit işlemciler sayesinde x64 Windows os'lerin desteklediği KPP sistemi ile artık kernel rootkitlerinden kurtuluyor gibi görünüyoruz. Bu vesile ile AV üreticilerinde neden tedirgin olup Microsoft ile savaşa tutuştuklarınıda anlamış oluyoruz sanırım. System Service Table'i hook edip bu yolla kernel mode'da cirit atma devri uzun bir müddet sekteye uğrayacak gibi ve bu yüzden teknolojilerinin belini bu mode'a bağlayanları epeyce üzeceğe benziyor.

Hepiniz sağlıcakla kalın.

24 Haziran 2009 Çarşamba

Sistemi kimler programlar

Yaklaşık 12 senelik programcılık hayatımın en verimli evrelerini bundan 3-4 sene önce yaşamıştım ve birikimlerimden doğan bir kaç yazı kaleme almıştım. Merak edenler olabilir diye linklerini paylaşmak istedim.

Bu linklerde yer alan Windows için Sistem Programcılığı serisi'ne ait bilgiler ile umuyorumki sizler için karanlık kalan bir çok nokta aydınlanacak ve o karanlık delhiz sanılan düşük seviyeli programlama fobinizden de kurtulmuş olacaksınız. Ne yazık ki ülkemiz os ve işlemciler için mimarisel anlamda programlama yapmaktan çok uzak. Tüm bilinen kaynakların yabancı dillerde olması ve konun profesyonel derecede programlama alt yapısı gerektirmesinden dolayı bu iş insanların gözünde dahada büyüyor. Sizleri aşağıda linkini verdiğim adresteki makaleleri okumaya davet ediyor ve en kısa zamanda örnek çalışmalarınızı yine aynı platformda paylaşmanızı istiyorum.

Sistem Programcılığı Serisi

23 Haziran 2009 Salı

Zemana AntiLogger ve Güvenlik!

Makale tadında bir şeyler yazmaktan ve karalamaktan nefret ederim ancak yazmaya başladığımda sanki hiç bitmeyecek bir romanı yazıyormuşum gibi olur ve kendimi durduramam.


Bir blog açma fikrini bile ancak boş bir vaktimde "dur bakalım bide bunu deneyelim atraksiyon olsun" tadına denk gelen anlarımdan birinde hayata geçirdim. O yüzden şimdiden size güzel bir haber: her gün yazıp sizlerin kafasını ütülemeyeceğim ve sadece gerçekten bilgilendirmeye değer gördüğüm durumları sizlerle paylaşmak için bana ayrılan bandwidth hakkımı kullanacağım.

Sizlere , 1-2 ay önce hiç birini hayata geçirmediğim yüzlerce projemden herhangi biri ile ilgilendiğim bir vakitte izlediğim bir video sayesinde varlığından haberdar olduğum Zemana firmasının geliştirmiş olduğu AntiLogger yazılımından bahsetmek istiyorum.


Her ne kadar kısa bir süreç içerisinde, yalnızca çalışma mantığı ve güvenlik zaafiyetleri üzerine göz atmış olsamda şahsi kanaatim uzun vadede geleceği parlak ve güzel bir uygulama olacağı yönünde. Programı burada tanıtıp advertorial kuşağına girmek istemediğimden sizlere sadece üreticisinin adresini vermekle yetiniyorum http://www.zemana.com/tr/default.aspx .

Evet siteye girip programın açıklamalarını okuduğunuzu ve download edip kullanarak ne işe yaradığını - neleri vaadettiğini - gelişim evrelerini ve işleyiş süreçlerini kavradığınızı düşünerek yazıma devam ediyorum.

Zemana AntiLogger'la ilk olarak sanırım 1.8.x.x versiyonu ile tanıştım ki zaten kullandığım süreç içerisinde sadece 5 adet patch yayınlandı. Bu makaleyi yazdığım sırada son versiyonu 1.9.2.104'dü ve yaklaşık 2 haftadır yeni bir patch yayınlanmadı. Sanırım üretici ya mevsim şartları gereği iş temposunu düşürerek istrahata çekildi ya da çok daha stabil versiyon için harıl harıl çalışıyor. Dileğim ikinci ihtimalin olması yönünde. Tanıyanlar bilirler yapım gereği elime geçen bir sistem veya programı kullanmak yerine çalışma mantığını ve bundan elde ettiğim verilerle güvenlik zaafiyetlerini bulmaktan hoşlanırım. Bu en büyük hobilerim arasında yer alıyor. Bu nedenlede AntiLogger'la tanışmam sonrası süreç aynı düzlemde ilerledi.

Programı sistemime ilk kurduğumda hali ile vaad edilen koruma yeteneklerinin gerçekliğini test ettim ve tatmin edici buldum. Daha önceden userland için kodladığım bir çok code injection, keylogger ve screen capture'ı başarı ile tespit edip engellemişti. Antilogger vaad ettiği koruma testlerinden başarı ile geçmişti ancak kendini koruyabiliyormuydu? İlk işlem olarak newbee seviyesindeki bir attacker mantığı üzerinden hareketle işlem sonlandırma girişiminde bulundum ve sonuç Access Denied'dı. Antilogger kendine yöneltilen tüm sonlandırma isteklerini ret ediyordu. Bu iyiye işaretti, böylece zararlıların ilk yaptığı iş olan "düşmanı egale etme" girişimi de zararlı için hüsranla sonuçlanıyordu. Testlerim devam ediyor ve tüm parametreler Zemana için iyiye işaret ediyordu.

İkinci test günümde yine AntiLogger'a kendi yazdığım ve çok bilinen 12 process terminate yöntemi ile saldırmayı denedim ve fonksiyonlarımın tümü "FALSE" değeri ile döndü. Ancak tam o esnada AntiLogger'in penceresini görünür yaptım ve mouse'umu üzerine doğru getiriyordum ki birden AntiLogger'in error trap mekanizması ekranda beliriverdi ve sunduğu seçeneklerden herhangi birini seçtikten sonra kendini sonlandırarak sistemi koruma görevinden vazgeçti. Sanırım bir zaafiyet bulmuştuk ve error reporting den aldığımız ip uçları ile de problemin program içerisinde nerede, hangi şartlar altında olduğu ve probleme neyin sebep olduğunu bulmak ve PoC yazmak artık çok kolay olacaktı.

Zayıflık programın tüm child pencerelerine WM_CLOSE veya SC_CLOSE mesajının gönderilmesi ve akabinde TfrmMain parent window'una bağlı controller'dan TfrmVistaButton sınıfının Borland Vcl kütüphanelerinde kullanılan ve başa bela olması ile de bi aralar bayağı meşhur olan TTimer nesnesinin UpdateTimer prosedürü içerisinde kullanılan FWindowHandle handle'ini zaten bir önceki mesajla kapatılmış olan window handle'ı ile işlemeye çalışmasından kaynaklanıyor. Aslında TTimer nesnesinin hafıza yönetimi baştan beri hep programcıların canını sıkmıştır ve buradada kendini gösteriyor.

Açık kısaca yukarıda tanımlandığı gibi işliyor ve AntiLogger'in işleyişini error trap mekanizmasına iletiyor. Bu esnada AntiLogger arka planda hizmet vermeye devam ediyor ancak aynı mesajı ikinci kez gönderdiğinizde artık tümü ile kendini sonlandırıp sizi terk ediyor. Bu kadar tanımdan sonra sanırım Zemana Yazılım ekibi çok kısa bir sürede bu açığıda kapatacaklar ve daha stabil bir sürümle bizleri sevindirecekler. Bu bahse son vermeden öncede örnek olması açısından http://rapidshare.de/files/48444246/KillWindows.rar.html adresindeki basit PoC'u Zemana AntiLogger yüklü os'niz de deneyebilirsiniz. Ben testlerimi Xp Sp2+Sp3 üzerinde yaptığımdan Vista ve Windows 7 üzerindeki User32.dll:SetTimer fonksiyonun bu hataya karşı gerçekleştireceği tepkiyi şu an için bilemiyorum. Test edip sonuçlarını bana yazarsanız onunda üstesinden gelen birşeyler yapabiliriz.

Makalenin bundan sonrası AntiLogger ve türevi yazılımların çalışma prensipleri ve işlevsellikerini nasıl sağladıkları üzerine olacaktır.Amacım sizlere İşlemci ve OS mimarisini anlatmak değil ama bazı kavramları anlamanız, makalenin ilerleyen kısımlarındaki terimelere yabancılık çekmemeniz için şart.

İşletim sistemleri sağladıkları yetenekleri tüm sistem,kullanıcı ve uyguluma geliştirme programcılarına - bütünleşik, hızlı, esnek ve güvenilir olarak sunmalıdırlar. Bilindiği üzere ve konu mankeni olarak kullanacağımız işletim sistemi ailesi Windows olduğundan bu işletim sistemi mimarisel olarak iki katmandan oluşur (UserMode-KernelMode). Bu katmanlar birbirlerinden soyutsal olarak ayrıdır ve bu ayırım işletim sisteminin bütünlüğünü kendi içinde koruması ve daha stabil olarak yönetmesi için gereklidir. UserMode katmanı donanımdan tümü ile soyutlanmıştır. Yani bu modda çalışan hiç bir process doğrudan diske yazamaz, okuyamaz, herhangi bir porta erişemez, hafıza alanlarına müdahelede bulunamaz ve bunun gibi daha bir çok yetenekten uzaktır. Yukarıda saydığımız tüm işlemleri yapabilecek olan yer KernelMode katmanıdır.

İşte bu aşamada gerek işlemci üreticilerinin sağladıkları yetenekler sayesinde olsun, gerekse OS içerisinde yer alan ve işlemcinin usermode ve kernelmode arabuluculuğunu yapan komutunu kullanarak güvenli ve hızlı bir iletişimi sağlayan yapısal yetenekleri olsun tümü ile bütünleşik bir yapı ile karşı karşıya kalırız. Intel ailesi komut setlerinden olan SysEnter Amd ailesi işlemcilerinde yer alan SysCall çağrıları az önce bahsettiğimiz çevrimleri bizler için çok hızlı ve güvenilir bir şekilde gerçekleştirir. Burada şöyle bir senaryo ile konun daha iyi ve net anlaşılmasını sağlayalım:

Herhangi bir dille Win32 api'lerini kullanarak dosya okuma işlemi gerçekleştirdiğinizi varsayalım. Bunu kernel32.dll altında ReadFile api'si ni kullanarak yaparsınız. Dilerseiniz programınızı yazıp gerekli parametreleri ile derledikten sonra çalıştırdığınızda neler olduğuna bakalım.

1-ReadFile çağrısı çalıştığında öncelikle programınız içerisindeki iat'den dosya okuma işlemi api'si için hangi işletim sistemi dosyasının çalışması gerektiği bilgisi alınır ve bu normal şartlarda (hooksuz) kernel32.dll:ReadFile api'sini gösterir. İşlemci eip yazmacı artık kernel32.dll içerisindeki ReadFile apisini fonksyion kodlarının bulunduğu alanı işaret eder.

2 - Kernel32.dll:ReadFile api'si bazı denetimleri yaptıktan sonra süreci ntdll.dll içerisinde yer alan ZwReadFile native api'sine devreder ve burada bir kaç denetim işleminden sonra ReadFile işleminin KernelMode tarafında asıl işlemerini gerçekleştirecek koduna dallanması için işletim sistemi tarafından kendine verilmiş olan ServiceID'sini ve parametreleride içeren stack registeri ile birlikte az önce yukarıda bahsettiğim ve işlemciye göre değişen mode çevrim komutunu çalıştırır.

3-Intel işlemcisi için konuşursak Sysenter çağrısı sonrası usermode da yer alan ntdll.dll içerisinden serviceID si ve parametreleri belirtilmiş değerler artık kernelmode tarafındadırlar. Kernelmode az öncede bahsettiğimiz üzere doğrudan hafıza ve donanıma erişim yetkisi bulunan bir yerdir ve bu yüzden de yukarıdaki ilk 2 adımda belirtilen denetim mekanizmalarından geçen veriler bu seviyeye ulaşabilmelidirler. Aksi takdirde sistemin güvenliği ve stabilitesi tehlikeye atılmış olunur.

Güncel microsoft ailesi işletim sistemleri UserMode dan gelen fonksiyonlar için KernelMode tarafında sysenter (amd'de syscall)komutundan gelen ServiceID numarasına göre çalışacak olan fonksiyonun gerçek adresini tutan ve adına Service Descriptor Table denen bir tablo bulunur.
Bu tablo yardımı ile usermode dan gelen serviceID'ye uygun gerçek fonksiyon adresi bulunur ve buraya dallanılır.

İşte dananın kuyruğunun koptuğu noktada burada devreye girer. Gerek zararlı rootkitler olsun, gerek sizi bu rootkitlerden koruyacağını idda eden savunma programları olsun bu tabloyu hook ederek bu işlevselliklerini sağlarlar. Yani iki tarafında yaptığı bu tabloyu uygun şekilde modifiye ederek kendi amaçları doğrultusunda kullanmaktan ibaret. Örneğin aslında tamamı ile Windows çekirdeğine ait fonksiyon adresleri ile dolu olması gereken bu tablonun Zemana Antilogger uğradıktan sonraki şekli aşağıdaki gibidir:

c:\program files\antilogger\antilog32.sys
0x0025 - NtCreateFile
0x0035 - NtCreateThread
0x003F - NtDeleteKey
0x0041 - NtDeleteValueKey
0x0061 - NtLoadDriver
0x006C - NtMapViewOfSection
0x0074 - NtOpenFile
0x0077 - NtOpenKey
0x007A - NtOpenProcess
0x007D - NtOpenSection
0x0080 - NtOpenThread
0x00B4 - NtQueueApcThread
0x00D2 - NtSecureConnectPort
0x00D5 - NtSetContextThread
0x00F0 - NtSetSystemInformation
0x00F7 - NtSetValueKey
0x0101 - NtTerminateProcess
0x0115 - NtWriteVirtualMemory

Gördüğünüz gibi 18 adet hook edilmiş fonksiyonun listesi ve yanlarında ait oldukları serviceID'leri. UserMode tarafında bir process erişimi,dosya işlemi,port erişimi,fiziksel hafızaya işlemleri ve code injection gibi bir çok işleme ait orjinal fonksiyon çağrıları birinci elden KernelMode katmanında AntiLogger sürücüsü tarafından işlenmekte. Böylelikle program sistem'de erişim kısıtlama ve erişim izni verme yetkilerinede sahip olmuş oluyor. Tabi amacı itibari ilede olması gereken bir işlem bu. Ancak bu işlemin aynını rootkitlerde yapıyor ki bu yüzden microsoft ve işlemci üreticileri buna dur diyerek KPP (Kernel Patch Protection) adı verilen bir sistemle bunun önüne geçmiş durumda(yada şimdilik öyle görünüyor) .

Daha fazla ayrıntı ve teknik detaya girerek kafaları karıştırmak istemiyorum. Son söz olarak yukarıda Zemana AntiLogger'in sonlanmasına neden olan işlemden sonra \\device\\physicalmemory nesnesine erişim izni alarak işletim sisteminizin kullandığı orjinal kernel dosyasının içerisinden (benim core2 işlemcim için bu ntkrpamp.exe'dir) orjinal Service Dispatch Table fonksiyon adreslerini alıp hook edilmiş olanların üzerlerine yazarak Zemanın bir dahaki reboota kadar yeniden başlasada etkisiz kalmasını sağlayabilir veya doğrudan bir kernel rootkit yazarak Zemana'nın tümü ile etkisiz kalmasını sağlayabilirsiniz.

Son söz olarak Zemana AntiLogger gerçekten geleceği parlak ve güzel bir yazılım ve umarım gelişimi KPP engeline takılmadan Microsftun New Api desteği adını verdiği yeni framework ile çalışıp şu anda hizmet veremedeği x64 ailesi işlemci ve os desteğinide vermesi ile daha da iyi bir şekilde sürer.

Hepiniz bir dahaki entry'me kadar sağlıcakla kalın.

İbrahim Akgül
bilgislem@hotmail.com