Soru:
SSDT'nin bir bellek dökümünden yamalı olup olmadığını tespit etmenin kolay bir yolu var mı?
Polynomial
2013-04-02 02:56:28 UTC
view on stackexchange narkive permalink

SSDT, Windows NT çekirdeği içindeki bir gönderim tablosudur ve çeşitli dahili çekirdek API'lerine yapılan çağrıları işlemek için kullanılır. Genellikle kötü amaçlı yazılımlar, belirli çekirdek işlevlerini bağlamak için SSDT'deki adresleri değiştirir. Bu tür şeyleri bir bellek dökümünde tespit etmek harika olurdu, çünkü potansiyel rootkit'leri belirlememe izin verirdi. Onları güvenilir şekilde tespit etmenin bir yolu var mı? Ne tür bir bellek dökümü gerekiyor?

Iki yanıtlar:
#1
+8
0xC0000022L
2013-04-02 05:39:33 UTC
view on stackexchange narkive permalink

Kesinlikle güvenilir bir yol yok, hayır.

Her iki durumda da tam bir döküme ihtiyacınız olacak, ancak sorun şu ki, kötü amaçlı yazılımlar, çekirdek içindeki sorumlu işlevleri bağlayabilir ve neyin atılacağını değiştirin. Burada dikkate alınması gereken birkaç şey var.

Kötü amaçlı yazılım ilk etapta bağlantı kurmak için önemsiz bir yöntem kullanıyorsa bunu tespit edebilirsiniz . Adresin bir tramboline veya başka bir yüklenmiş görüntünün içine (veya hatta sayfasız havuzdaki birinin dışına) değiştirildiğini varsayalım, o zaman kolayca algılayabilirsiniz . Basitçe tüm modülleri numaralandırabilir ve içinde adresin SSDT'nin içinde bulunduğu modülü bulmaya çalışabilirsiniz. Bir trambolin durumunda, nereye atladığını / çağırdığını görmek için oradaki talimatları sökmeniz gerekecektir. udis86 gibi amaca uygun birçok kitaplık var.

Ancak, kötü amaçlı bir yazılım sinsi ise, doğal boşlukları kullanabilir belleğe yüklendiğinde bir yürütülebilir dosyanın (çekirdek gibi) içinde. Muhtemelen bildiğiniz gibi, bir PE dosyasının ( ntoskrnl.exe ve arkadaşlar gibi) diskte ve bellekte farklı şekilde temsil edilme şekli. Disk üzerindeki dosya biçimi daha kısadır. Belleğe yüklenen bölümler, PE başlığında açıklanan belirli bir şekilde hizalanır. Bu şekilde, bir bölümün gerçek boyutu (son) ile doğru şekilde hizalanmış bölüm boyutu ("dolgu") arasında büyük olasılıkla boşluklar olacaktır. Bu, bir trambolin gibi bir şeyi gizlemek veya basit bir trambolinden daha fazla kabuk kodu bırakır. Bu nedenle, yukarıdaki gibi saf bir kontrol - yani modülleri numaralandırma ve SSDT işlevlerinin çekirdek görüntüsünün içine işaret edip etmediğini kontrol etme - çalışmayacaktır. Az önce anlattıklarımı yapacak kadar sofistike kötü amaçlı yazılımlar tarafından atlanırdı.

Tahmin edebileceğiniz gibi bu, kötü amaçlı yazılım / kötü amaçlı yazılımdan korunma her şeyde olduğu gibi, her şeyin hızla silahlanma yarışına dönüştüğü anlamına gelir. Şiddetle önereceğim şey, bir çekirdek hata ayıklayıcı eklemeniz (akla Firewire üzerinden WinDbg geliyor) ve araştırırken virüs bulaşmış (veya virüs bulaştığı iddia edilen) makineyi belirsizlikte tutmanızdır. Siz bağlıyken ve hata ayıklayıcıya girdiğinizde, hata ayıklayıcı hiçbir şey yapamaz. Bu, bir sistemde canlı hata ayıklamak için kullanılabilir ve - kötü amaçlı yazılımın kdcom 'u da manipüle edecek kadar gizli olmadığını varsayarsak - değerli ölçümler elde etmek için - doğrudan bir çökme dökümü oluşturmak için de kullanılabilir (WinDbg yardımına bakın ). Bir makinenin, sergilediği belirtiler nedeniyle enfekte olduğuna dair kesin kanıtınız varsa, büyük olasılıkla kötü amaçlı yazılımın çok karmaşık olmaması ve özetlediğim özel durumu önemsemeniz gerekmez. Ancak, bu özel durumun, gizlemek için kullanılan pek çok olası durumdan yalnızca biri olarak kabul edilebileceğini unutmayın. Çok uzun lafın kısası: İstediğinizi yapmanın kesinlikle güvenilir bir yolu yoktur.

Bazen söylendi - ve doğrudur - saldırganın sadece birini bulması gerekir Savunan, bilinen saldırı vektörlerini yalnızca sınırlı sayıda savunabilir. Bundan çıkarılacak ders, kötü amaçlı yazılımdan koruma endüstrisi olarak (benim çalıştığım) her zaman sistemde hiçbir şey bulamadığımızı iddia edebiliriz, ancak bunu iddia etmenin yanlış olduğunu sistem temiz.


Kasıtlı olarak bir BSOD'ye nasıl neden olunur

Klavye sürücü (ler) inin bir BSOD'ye neden olduğu söylenebilir:

  HKLM \ CurrentControlSet \ Services \ kbdhid \ Parameters  

veya (eski PS / 2 klavyeler için)

  HKLM \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters  

Ve orada CrashOnCtrlScroll adlı bir REG_DWORD öğesini 1 olarak ayarlayın.

Bir sonraki yeniden başlatmanın ardından mavi ekranı Ctrl + ScrollLk + ScrollLk ile zorlayabilirsiniz. Bu durumda hata kontrol kodu 0xE2 ( MANUALLY_INITIATED_CRASH ) olacaktır.


Yan not: Ben de okudum ama hiç görmedim bir çekirdek hata ayıklama oturumunda kendimde veya herhangi bir FLOSS uygulamasında, bazı yöntemlerin çekirdeği diskteki görüntüden yeniden yüklemeye ve onu ilk başlatma adımlarından geçmeye çalışarak bir "gölge" SSDT oluşturması. Bu daha sonra bozulmamış olacak ve orijinal SSDT'den tek bir hamlede her şeyi "çözmek" için kullanılabilir. Yine, bunun uygulandığını görmedim, ancak dahili bilgilerime göre bir olasılık görünüyor. Elbette bu, bir kök setinin işlevlerini tespit etme / çözme fikrinde, virüs bulaşmış bir sistemin bellek dökümünü alma amacınızdan çok daha fazla işe yarar.

#2
+6
Brendan Dolan-Gavitt
2013-04-02 05:37:25 UTC
view on stackexchange narkive permalink

Oynaklık, desteklenen biçimlerden herhangi birindeki bir bellek görüntüsüne bağlı olarak bu tür kancaları algılayabilir.

Özellikle, diziler eklentisi, SSDT kancalı herhangi bir diziyi HookedSSDT olarak etiketler ve ssdt eklentisi, SSDT'deki tüm işlevleri atar ve aşağıdakileri içeren çekirdek modülünün adını verir

Daha incelikli bozulma türlerini tespit edebilecek başka bir yöntem de WinDbg'yi (canlı bir sistemde veya kilitlenme dökümünde) kullanmak ve chkimg her bir çekirdek modülünü denetlemek için komut, örneğin:

  chkimg -d nt  

Bu, çekirdeğin bozulmamış bir kopyasını MS Symbol sunucusundan indirir ve raporlar bellek içi sürümden herhangi bir farklılık. Bunun muhtemelen iş parçacığı başına SSDT'ye yerleştirilen herhangi bir kancayı algılamayacağını unutmayın.

Maalesef @0xC0000022L'yi yakaladığınız için teşekkürler. Sabit.


Bu Soru-Cevap, otomatik olarak İngilizce dilinden çevrilmiştir.Orijinal içerik, dağıtıldığı cc by-sa 3.0 lisansı için teşekkür ettiğimiz stackexchange'ta mevcuttur.
Loading...