Sanallaştırılmış rootkit'ler konusu son günlerde bayağı gündemde. Joanna Rutkowska, görünmez rootkit kanıt kodu Blue-Pill'in yeni sürümü üzerine çalışıyor. Aynı anda tanınmış 3 güvenlik uzmanından oluşan bir ekip Joanna'ya "görünmez rootkit yoktur" diyerek meydan okuyorlar. Ekip BlackHat konferansında Blue-Pill'i tespit için çeşitli teknikler sundu. Bu konuda detaylı bilgi sahibi olmak için Federico Biancuzzi her iki tarafla da röportaj yapmış.

Bölüm 1: Joanna Rutkowska
Kendinizi tanıtırmısınız?
JR: İşletim sistemi güvenliğini araştırma konusuna odaklanmış bir güvenlik araştırmacısıyım. Rootkit'ler tarafından kullanılan gizleme teknolojileri, gizli kanallar (covert channels), İşletim sistemi ayrım mekanizmaları ve sanallaştırma teknolojileri ile ilgileniyorum. Bir kaç ay önce kendi danışmanlık firmam olan Invisible Things Lab i kurdum.

Blackhat konferansında Peter Ferrie, Nate Lawson ve Thomas Ptacek tarafından yapılan prezentasyonu gördünüzmü? Tepkiniz nedir?
JR: Tabiki gördüm! Prezentasyon sanallaştırma tabanlı kötü amaçlı kod problemini tamamen çözme vaatleri veriyor. Ve "sanallaştırılmış rootkit öldü" diyecek kadar ileri gittiler.

Fakat, maalesef iddialarını kanıtlayamadılar ve sunumda tüm yaptıkları sanallaştırmayı nasıl tespit ettikleri, sanallaştırma tabanlı kötü amaçlı kodları değil.

Donanımsal sanallaştırma teknolojisi gittikçe yaygınlaşıyor, daha fazla sayıda makine (blue-pill içerse de içermesede) sanallaştırma modu aktif olarak gelecek. Bu durumda blue-pill'in sanallaştırma aktif edilmiş gibi göstermesine gerek kalmayacak. Böyle olduğunda da "blue pill tespit edici" normalde sanallaştırma tespiti yaptığı için bir işe yaramayacak.

Yeni Blue Pill kodunun çoğunu yazan Alex Tereshkin ile birlikte yaptığımız prezentasyonda sanallaştırma tespit metodları bile güvenilir değil ve geliştirilmesi gerekiyor. Blue Pill'in öldüğünü duyuranların kullandığı ana metodlardan olan TLB profillemenin problemlerini anlattım. L1 cache'deki verilerin çakışmasını önlemek gibi nasıl ekstra önem göstermemiz gerektiğini açıkladım. Daha önce TLB profilleme metodlarını tartışan hiçbir araştırmacı bu konuya değinmemişti, bu da metodlarını hiç AMD işlemcilerde test etmediklerine işaret ediyor.

TLB profilleyicinin gelişmiş sürümünü çıkardık, bu daha güvenilir ve SVM modu tespit etmede kullanılabilir. Fakat, sadece sanallaştırma modunun aktif olup olmadığını söylediği için bu hala iyi bir blue-pill tespit yaklaşımı değil. Eğer donanım sanallaştırmasını kullanan normal bir uygulama kullanıyorsanız bu tespit edici de işe yaramaz.

Sizi %100 görünmez rootkit yapabileceğinize inandıran şey nedir?
JR: %100 tespit edilemezlik cümlesi pratik tespit içindir, daha geçen sene beklenmedik hypervisor denetimi için bazı metodlar biliyorduk. Bir yıl geçti ve hala sanallaştırma kötü amaçlı kodunu tespit etmek için iyi bir metodumuz yok ve donanım yardımı olmadıkça da böyle bir tespite sahip olamayacağız.

%100 görünmez sistem yapmanın mümkün olduğunu varsayalım. Bu herhangi birisinin legal (gizli denetim, honeypot, hids) şeyler yapabileceği gibi tespit edilmeden kanunsuz işlemler yapabilmesi anlamına da geliyor. Eğer tamamen tespit edilemeyeceğine eminsek, bunu internet'e sunmak etik olarak kabul edilebilirmi? Bir çeşit yenilmez silah sağlamak değilmi?
JR: Bu senaryoya bağlı. Bir hypervisor'un varlığını tespit etmek (çeşitli taktiklerle) mümkün olabilir, bir hypervisor'un var olmadığını umduğumuzda, bugün pek çok durumda böyle fakat gelecekte daha az durumda olacak, doğru olmayan birşeyi tespit edebileceğiz.

Örneğin bir honeypot'u düşünün. Bugün, eğer donanım sanallaştırma ile bir honeypot inşa edersek, çok az sayıda sunucunun VT-x veya SVM teknolojisi ile sanallaştırıldığını hesaba katarsak, bir saldırganın sunucunun şüpheli olduğunu bulması mümkün olabilir. Fakat, gelecekte çok daha fazla sunucunun VT-x/SVM ile sanallaştırılacağını umuyoruz, bu durumda da hem normal sunucular hem de honeypot'lar sanallaştırılmış olacak. Yani sunucuların çoğunluğunun sanallaştırılması beklendiğinden, bir saldırganın, sunucunun bir hypervisor kontrolü altında olduğunu bulması pek de yararlı olmayacak.

Sanallaştırma teknolojisindeki diğer bir trend'de uygulamaları birbirinden ayırarak (ör. kullanıcı webde "güvensiz" gezinme için bir VM dedike etmiş, hızlı mesajlaşma için başka bir makine dedike etmiş olabilir) masaüstü güvenliğini artırmak. Yine, bu tip bir senaryoda, sanallaştırma modunun aktif olması bekleniyor, ve blue-pill türü kötü amaçlı kodlar bu uygulamaların tepesine oturabilir (nested hypervisor desteği sayesinde), işletim sistemini kontrol edebilir. Bu durumda da sanallaştırmanın varlığını tespit etmek bir işe yaramayacak.

Sanallaştırmanın her zaman tespit edilebilir olduğunu sanırım söyleyebiliriz. Peki yapılması gereken normal hypervisor'u Blue-Pill'den nasıl ayıracağımızı bulmakmıdır?
JR: Sanallaştırma her zaman mümkün, fakat bunun için doğru düzgün dokümante edilmiş bir metod yok -- tek sahip olduğumuz bir kaç karmaşık işlem.

Örneğin, Ptacek, Ferrie ve Lawson un BlackHat konferansındaki konuşmalarında sunduklarını altetmenin kolay olduğunu ve henüz gelişmemiş ve güvenilir olmadığını gösterdim.

Mantıksal olarak, normal sanallaştırmayı kötü amaçlı sanallaştırmadan ayırmak bir sonraki adım olarak görünüyor, fakat bunu efektif olarak uygulayabilmek için kullanabaileceğimz iyi metodlar yok.

Bu problemi donanımın yardımı olmadan çözebileceğimize inanmıyorum. Fakat hala gerçekten nasıl yapacağımızı bilmiyorum.

Güvenlik açısından bakıldığında, AMD ve Intel işlemcilerde bulunan sanallaştırmalar arasında bir fark görüyormusunuz?
JR: AMD SVM tekenolojisi şu anki Intel VT-x implementasyonundan daha zengin, bu da kötü amaçlı kod yazarlarına biraz daha fazla özgürlük sağlıyor (ör SVM'de CPUID instruction'ı kesmeleri/durdurmaları gerekmiyor).

Diğer yandan AMD SVM daha iyi sistem koruması için çeşitli ilgi çekici özellikler sunuyor (ör. External Access Protection (EAP) ve SKINIT instruction).
Fakat benzer teknolojilerin yakında çıkacak Intel işlemcilerde de olacağını biliyorum.

Sonuç olarak, güvenlik açısından her iki teknoloji de benzer görünüyor (en azından dizayn seviyesinde) ve her ikisi de sanallaştırma tabanlı kötü amaçlı kodlar gibi benzer tehditlerden etkileniyorlar.

Vista ve x86 donanımdan bahsettiniz. MacOS X, Linux veya (Open)Solaris hakkında neler düşünüyorsunuz? Onlarda blue-pill'i kullanabilirmiyiz?
JR: Blue-Pill'in işletim sisteminden bağımsız olduğunu ve Vista'nın sadece bir örnek olduğunu hep söyledim. Donanımsal sanallaştırma destekleyen AMD işlemci kullanan herhangi bir işletim sistemi bu tip rootkit'lerden etkilenir.

Yazılım sanallaştırma çözümlerinin (VMware, Xen, VirtualPC,..) güvenliği hakkında neler düşünüyorsunuz?
JR: Açıkçası, burda en önemli soru VM'den kaçmak ve hypervisor/VMM'lere girebilmenin mümkün olup olmadığı. Bildiğim kadarıyla, şu ana kadar herhangi bir VMM motorunda exploit edilebilir bir bug bulunmadı. Bazı ek mekanizmalarda (ör. ağ NAT modülleri) bug bulundu.

Fakat, inanıyorum ki, önümüzdeki yıllarda sanallaştırmanın popülerliği arttıkça bu alanda da exploit ler göreceğiz.

Şu an için, bugünün yazılım tabanlı VMM'lerinin sunduğu ayırım (isolation) yetenekleri (Linux, Windows, BSD gibi) genel amaçlı işletim sistemlerinin sunduklarından çok daha güçlü.

Blue Chicken stratejisi nedir?
JR: Blue Pill'in, zaman-tabanlı sanallaştırma tespit edicileri altetmesini (bir VM içinde olduklarını anlayamıyorlar) sağlayan bir özellik. Sistemde sanal bir PC varsa, veya herhangi bir uygulama donanımsal sanallaştırmayı zaten kullanıyorsa Blue Chicken'a ihtiyacımız yok.

Bütün farklı zamanlama denemelerini yakalamak için Blue Chicken stratejisini sürekli güncellemeyi düşünüyormusunuz?
JR: Artık daha fazla "sanallaştırma kandırma" üzerine çalışacağımızı sanmıyorum. Daha çok, "sanallaştırma kandırma" ihtiyacı olmayan (tüm sanallaştırma tespit edicilerin tanım itibariyle işe yaramadığı) çeşitli içiçe geçmiş sanallaştırma senaryoları üzerine çalışacağız. Burdaki amacımız insanları genel sanallaştırma tespiti yaklaşımının sanallaştırma tabanlı kötü amaçlı kodları tespit etmede doğru yöntem olmadığına inandırmak.

Neden içiçe geçmiş sanallaştırmayı destekleme ihtiyacı duyuyorsunuz?
JR: İçiçe geçmiş sanallaştırma, eğer hedef sistemde sanallaştırmayı kullanmak isteyen başka uygulamalar da varsa (ör Virtual PC 2007) veya hypervisor içeren bir sisteme sahipsek gerekli. Her iki durumda da Blue Pill bu uygulamaları ve/veya işletim sisteminin kendi hypervisor'unu içiçe geçmiş olarak çalıştırmalı.

Burdaki sanallaştırma uygulamaları ve İşletim sisteminin kendi hypervisor'u ayrımına dikkat edin. İkincisinin (diğer hypervisor kurulumlarını bloklayarak) Blue Pill saldırılarını engelleyeceğine inanılsa da birincisi Blue Pill'in yüklenmesini engellemiyor. Gelecekte çok daha fazla sanallaştırma tabanlı uygulamaları masaüstlerimizde görmemiz bekleniyor fakat Microsoft'un masaüstü sistemler için kendi küresel hypervisor'unu çıkaracağını (en azından önümüzdeki bir kaç sene için) sanmıyorum.

Eğer Blue Pill (Blue Chicken kullanarak) kernel'de saklandığında daha görünemez durumda ise, neden sanallaştırma kullanma ihtiyacı duyuyorsunuz?
JR: Blue Chicken , Blue Pill'i uyku moduna sokmaya zorluyor, bu sayede milisaniyenin onda birinde de olsa Blue Pill kernel'de yaşıyor, orda herhangi birşeye hook olması gerekmeden uyku modunda duruyor. Sadece orda uyuyor (muhtemelen kriptolanmış olarak) uyanması ve ring -1'e geri dönmesi için bir DPC callback bekliyor.

VirtualPC içiçe geçmiş sanallaştırma desteklemiyor, yani Blue Pill hypervisor ise ve Virtual PC (veya herhangi bir misafir işletim sistemi) içiçe geçmeye izin olduğunu görürse, bu Blue Pill'in varlığına açık bir kanıt değilmidir?
JR: içiçe geçme açıp kapatabileceğiniz bir işlemci özelliği değil. içiçe geçme kendimizinkinin altında başka hypervisor'ları çalıştırma yolumuz. Bunu içiçe geçmiş hypervisor'ları destekleyen bir algoritma gibi düşünün.

VirtualPC'nin misafir işletim sistemleri içiçe geçmeye izin olduğunu bulmasına imkan yok, çünkü kendi hypervisor'ları (Virtual PC hypervisor) başka birşey görmezler.

Virtual PC hypervisor'unun içiçe geçme işleminin olduğunu bulması teorik olarak mümkün. Bir misafir olarak çalıştığını görmesi, ve sanallaştırma tespitinde kullanılan tekniklere inananlar buraya uygulanabilir olduğunu düşünebilirler. Fakat bu doğru değil, çünkü tüm bu teknikler birisinin sanallaştırmanın kullanıldığı halde, kullanılmadığı konusunda aldatmaca yaptığını tespit etmeye yönelik. İçiçe geçmiş Virtual PC hypervisor olayında, sanallaştırmanın kullanılmadığı konusunda aldatma yapmaya ihtiyacımız yok, çünkü zaten kullanılıyor olması zaten bekleniyor. Bu yüzden EFER erişimlerini yakalamamıza veya CPUID yakalamıza ihtiyacımız yok, ve bu yüzden tüm sanallaştırma tespit metodları çalışmaz.

Fakat burada işe yarayabilecek şey, eğer Virtual PC hypervisor'unda , hypervisor birisinin misafiri olarak çalıştığında farklı davranacak bazı instruction'lar inşa etmek. Prezantasyonumuzda belirttiğimiz GIF ayarlama/temizleme problemi buna güzel bir örnek.

Bazıları bu durumda, hiçbir zaman %100 içiçe geçmeli hypervisor desteğine sahip olmayacağımızı söyleyebilir. Bu doğru olabilir, fakat, maalesef hypervisor koduna bazı özel ekler yapmak gerektiğinden bu Blue Pill tehditine karşı savaşmada doğru bir yol değil. Hypervisor inşa etmenin ana kuralı .. basitlik (ör. güvenlik sebeplerinden).

Ayrıca bu eklerin zaman zaman yeni işlemci modellerini de desteklemesi için güncellenmesi gerekir. Sevgili A/V programlarımızın hypervisor'lere modül eklemesine izin verirmiyiz? Bu delilik olur - Çoğu A/V kernel bileşenlerinde bug olduğuna zaten şahit olduk, şimdi onların bunu hypervisor'lere yapmasına izin verirmiyiz?

Kaynak: http://www.securityfocus.com/columnists/451

__________________________