Tersine mühendisliğe karşı koruma yazılımları: statik kara listeler neden yetmez?

Tersine mühendisliğe karşı koruma yazılımlarının çoğu bir listeyle başlar: İyi bilinen bir debugger çalışıyorsa uygulamayı kapat. Sıradan meraka karşı bu işe yarar ve neredeyse hiçbir maliyeti yoktur. Ama bir dosyanın adını değiştirmeye ya da listede olmayan bir araç kullanmaya hazır biri karşısında pek bir şey yapamaz.

Bu rehberde process ve pencere kara listelerinin ne işe yaradığını, neden yalnızca bilinen araçları yakalayabildiklerini, davranışsal kontrollerin ve yapay zekâ destekli tespitin bunun üzerine neler kattığını anlatıyoruz. Son olarak, ürününüzü korurken o ürün için para ödeyen müşterileri cezalandırmayan bir tepki politikası öneriyoruz.

Statik kara listelerin iyi yaptığı işler

Statik bir kara liste, makinede çalışanları bilinen analiz araçlarının listesiyle karşılaştırır. Eşleştirmeyi birkaç şey üzerinden yapabilir: process adları, pencere başlıkları ve pencere sınıf adları. Bir eşleşme olduğunda uygulama tepki verir.

• –Ucuzdur. Listede arama yapmanın çalışma zamanında neredeyse hiçbir maliyeti yoktur.
• –Öngörülebilirdir. Aynı girdi her zaman aynı sonucu verir; bu da davranışını anlamayı kolaylaştırır.
• –Bariz vakaları yakalar. Pek çok deneme, herkese açık araçları varsayılan adlarıyla kullanır.
• –Uzaktan güncellenebilir. qPapel Auth'ta Uzaktan ayarlar sayesinde yeni bir derleme almadan pencere başlıklarını, sınıf adlarını, aktif process'leri ve debug araçlarını engelleyebilir; kuralları uygulama sürümüne, ülkeye veya kullanıcı grubuna göre hedefleyebilirsiniz.

Kara listenin her koruma kurulumunda yer almasının nedeni bu güçlü yanlardır. Hata, onu kurulumun tamamı sanmaktır.

Process ve pencere kara listeleri neden yalnızca bilinen araçları yakalar?

Bir kara liste isimleri bilir, yalnızca isimleri. Bu da ona, liste ne kadar özenle güncellenirse güncellensin kapatılamayacak üç kör nokta bırakır.

Ters yönde de bir hata riski var. Daha geniş bir alanı kapsamak için gevşek eşleştirme yapan bir liste, meşru yazılımları da yakalamaya başlar. Ödeme yapmış bir müşterinin uygulamasını, sırf açık bir geliştirici aracı var diye kapatırsanız bir destek talebi, belki de bir iade talebi yaratırsınız; kararlı bir saldırgan ise listeyi kolayca atlatır.

Tersine mühendislik korumasının kapsaması gerekenler

Bir masaüstü ürününü analiz etmek genellikle birkaç temel adım içerir: dosyalara bakmak, kodu incelemek, program çalışırken onu izlemek, ağ üzerinden ne gönderdiğini gözlemlemek ve son olarak onu değiştirmek. Her adım farklı bir savunma gerektirir; kara liste ise bunlardan yalnızca birine dokunur.

Tablo, savunmaların neden birbirini güçlendirdiğini de gösteriyor. Binary değerli hiçbir şey içermediğinde çalışma zamanı tespiti çok daha etkili olur; sunucu tarafındaki veriler de onları alan oturum izlendiğinde çok daha güvende olur.

Değerin büyük kısmı iki satırda yattığı için bunlar daha yakından bakmayı hak ediyor: değerli olanı istemciden uzak tutmak ve analizi, nasıl yapılırsa yapılsın fark etmek. İlki istemci tarafı koruma ile sunucu tarafı sırlar yazısında ayrıntılı olarak ele alınıyor. Bu yazının geri kalanı ikincisine odaklanıyor.

Davranışsal tespitin kattıkları

Davranışsal kontroller bir aracın adını sormaz. Process'inize ve çalıştığı makineye ne olduğunu sorar. Adı değiştirilmiş bir araç da işini yapmak zorundadır ve bu iş geride iz bırakır.

• –Debugger varlığı. qPapel Auth bağlı bir debugger'ı tespit edip ilgili lisansı yasaklayabilir. qPAnalyzer buna donanım breakpoint'leri, process debug bayrakları ve kernel debugger varlığı gibi kontroller ekler.
• –Sanal makineler. Anti-VM tespiti, yazılım analizinde yaygın olarak kullanılan sanal ortamları fark eder.
• –Değiştirilmiş kod. auth.CheckMemoryIntegrity(), programın belleğinin çalışma zamanında, örneğin komutlara yama yapılarak değiştirilip değiştirilmediğini kontrol eder. auth.CheckTextIntegrity() buna CRC, oturum tabanlı ve yama kontrolleri ekler.
• –Oturum davranışı. Session Token Enforcement ile Uzaktan ayarlar üzerinden azami aktif oturum sürelerini belirleyebilir ve oturumları IP adreslerine kilitleyebilirsiniz.

// Illustrative pseudocode
void OnPremiumFeatureOpened() {
    auth.CheckMemoryIntegrity();   // has running code been modified?
    auth.CheckTextIntegrity();     // CRC, session and patch checks
    LoadFeatureFromServer();       // server data only after checks pass
}

Kontrollerin nereye yerleştirildiği de önemlidir. Açılışta bir kez çalışan bir kontrol, yalnızca programın açılışta temiz olduğunu söyler. Bütünlük kontrollerini kritik anlarda, örneğin premium bir özellik açıldığında ya da sunucudan veri istenmeden önce yeniden çalıştırmak, oturumun tamamına dair çok daha faydalı bir tablo sunar.

Asıl önemli tasarım kararı, kontrolden sonra ne olacağıdır. Başarısız olduğunda yalnızca bir mesaj gösteren kontrol, birini o mesajı kaldırmaya davet eder. Başarısız olduğunda sunucunun veri göndermeyi kestiği ve anahtarın işaretlendiği bir kontrolün ise istemciden kaldırılamayacak sonuçları vardır.

Yapay zekâ destekli tespitin kattıkları

Davranışsal kontroller, analizin process'inize ne yaptığını yakalar. Ancak araçlar dikkatli davranıyorsa makinede hangilerinin açık olduğunu söylemez. Yapay zekâ destekli tespitin doldurduğu boşluk tam olarak budur.

qPAnalyzer arayüz yerleşim kalıplarını, pencere handle'larını ve bellek imzalarını inceler; böylece bir aracı, yeni bir ad gibi kozmetik değişikliklerden bağımsız olarak tanıyabilir. Bir pencere şüpheli göründüğünde ekran görüntüsünü alır, analiz motoru görsel arayüzü inceler ve ardından %0 ile %100 arasında kalibre edilmiş bir tehdit puanı atar. Çalıştırılabilir dosyanın adı ne olursa olsun analiz araçları analiz aracı gibi görünür.

Puanlama, tanıma kadar önemlidir. Evet/hayır şeklindeki bir karar sizi gerçek tehditleri kaçırmakla zayıf kanıtlara göre aksiyon almak arasında seçim yapmaya zorlar. %0 ile %100 arasındaki bir puan ise belli belirsiz bir benzerliğe net bir eşleşmeden farklı davranmanızı ve tespitin kendisine dokunmadan tepkinizi sıkılaştırıp gevşetmenizi sağlar.

qPAnalyzer'ın yanlış pozitiflerden kaçınmak için yaptıkları da en az bunlar kadar önemli. Her ürünün, qPAnalyzer için özel talimatlar içeren kendi beyaz listesi vardır; bulgular Threat Vault'ta ürün bazında filtrelenir ve tek tıkla “Tehdit değil” işlemi zararsız çıkan her şeyi kaldırır. Ayrıntılı anlatım için qPAnalyzer'ın adı değiştirilmiş ve özel araçları nasıl tespit ettiğini okuyabilirsiniz.

Orantılı bir tepki politikası

Net bir politikası olmayan tespit ya gürültü ya da öfkeli müşteriler üretir. Amaç, net sinyallere kararlı, belirsiz olanlara dikkatli tepki vermek ve her ikisi için de kanıt saklamaktır.

1. 01

   Bilinen zararlı araç

   İyi bilinen bir analiz aracıyla oluşan kara liste eşleşmesi otomatik bir aksiyonu tetikleyebilir: Oturumu kapatın ve kaydedin. Aynı anahtarda tekrarlanan eşleşmeler yasaklamayı haklı çıkarır.

2. 02

   Tanıdık olmayan araç, yüksek puan

   Aksiyonu qPAnalyzer'ın puanı belirlesin. PapelShip'in risk motoru sinyalleri tek bir puanda birleştirir; uyarı, kısıtlama, kapatma ve yasaklama eşiklerini siz belirlersiniz.

3. 03

   Tanıdık olmayan araç, düşük puan

   Kaydedin ve inceleyin. Kitlenizin kullandığı meşru bir yazılımsa ürün beyaz listesine ekleyin ya da “Tehdit değil” olarak işaretleyin.

4. 04

   Gecikmeleri kullanın

   Gecikmeli aksiyon modunda yaptırımlar rastgele bir gecikmeden sonra devreye girer; böylece tepki, onu tetikleyen kontrolü doğrudan ele vermez.

5. 05

   Merkezden müdahale edin

   Anahtarı ve gerektiğinde cihazı yasaklayın. Karar sunucuda verildiği için yeni bir sürüm yayınlamadan bir sonraki kontrolde geçerli olur.

Uygulamanın kapanmasının dürüst bir müşteri açısından nasıl göründüğünü de düşünün. EasyAuth kütüphanesinde uygulama, bir politika ihlali nedeniyle kapandığında “Security Policy Closing” mesajını gösterir ve nedeni belirlemeye yardımcı olacak ek bilgiler ekler. Gerçek bir müşteri desteğe ulaştığında bu bilgiler sayesinde yanlış pozitifi gerçek bir sorundan hızla ayırabilir, beyaz listeye eklenmesi gerekeni ekleyebilir ve müşterinin yeniden çalışmaya devam etmesini sağlayabilirsiniz.

Yeni derleme yayınlamadan tespiti güncel tutmak

Koda gömülü bir kara listenin diğer zayıflığı da eskimesidir. Binary'nize derlenmiş bir liste, yayın gününün ertesinde güncelliğini yitirir. Kuralları sunucuda tutmak bunu önler.

• –Uzaktan ayarlar; kara listeleri, anti-VM'i, bütünlük kontrollerini, debugger yasaklarını, oturum sistemini ve HWID kilidini, istemci güncellemesine gerek kalmadan panelden değiştirmenizi sağlar.
• –Otomatik kurallar ile aksiyonları kendi kurallarınıza göre otomatikleştirebilirsiniz. Bir kez tanımlayın, gerisi kendiliğinden çalışsın.
• –qPAnalyzer güncellemeleri tespiti PapelShip tarafında iyileştirir. Son sürümler kapsamı genişletti ve yanlış pozitifleri azalttı.

Sunucu tarafı kurallar deneme yapmayı da daha güvenli hâle getirir. Uzaktan ayarlar kuralları uygulama sürümüne, ülkeye veya kullanıcı grubuna göre hedefleyebildiği için yeni bir kara liste girdisini ya da daha sıkı bir eşiği önce küçük bir grupta deneyebilir, sonuçları Bilgisayarlar sayfasında izleyebilir ve dürüst müşterileri yakalamadığından emin olduğunuzda kapsamı genişletebilirsiniz.

Daha ileri gitmek isterseniz korumayı yeniden derlemeden uzaktan güncelleme yazısı bu iş akışını ayrıntılı olarak anlatıyor; qPAnalyzer ürün sayfası da panel görünümlerini gösteriyor.

Yeni bir adın aşamayacağı bir koruma kurun

Statik bir kara liste mantıklı bir ilk filtre, ama zayıf bir son savunma hattıdır. Davranışsal kontroller analizin process'inize ne yaptığını fark eder. Yapay zekâ destekli tespit araçları ne olduklarına göre tanır. Sunucu tarafı kararlar ise tespit edilen her şeyin aynı anda her yerde sonuç doğurmasını sağlar.

Listeyi koruyun, arkasına diğer katmanları ekleyin ve net sinyallere karşı kararlı, belirsiz olanlara karşı adil bir tepki politikası belirleyin. Bu katmanların lisanslama ve HWID bağlamanın yanında nasıl konumlandığını görmek için C++ ve C# için yazılım koruma katmanları yazısını okuyun.