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

1 yorum:

  1. Serkan GÖKTÜRK31 Temmuz 2009 06:31

    tartışabilecek birilerinin olduğunu görmek ve aynı sınırlar içerisinde yaşadığını bilmek çok mutlu edici.

    Teşekkürler
    Serkan GÖKTÜRK

    YanıtlaSil