Khunt Saldırısının Perde Arkası: Bilgisayar Korsanları Oracle Veritabanını Nasıl Bir Saldırı Platformuna Dönüştürdü?

Saldırı Nasıl İşledi: Otomatik Tamamlama Aramasıyla SQL Enjeksiyonu

Saldırganların sisteme ilk giriş noktası, Apache Tomcat üzerinde çalışan ve herkese açık bir Java uygulamasındaki SQL enjeksiyon açığıydı . Uygulamanın otomatik tamamlama (autocomplete) arama özelliği, kullanıcı girdilerini gerektiği gibi doğrulamadığı için saldırganlar, Oracle veritabanına olan JDBC bağlantısı üzerinden SQL komutları enjekte edebildi . Huntress araştırmacılarının da belirttiği gibi, bu yeni bir açık türü değildi; SQL enjeksiyonu saldırıları onlarca yıldır var ve genellikle SQL sunucusuna giden kullanıcı girdilerinin yanlış işlenmesinden kaynaklanır . Uygulamanın basit bir arama alanını temizlememesi, tüm bu saldırı zincirini başlatmaya yetti.

Khunt Araç Seti: Veritabanının İçinde Java Nesneleri Olarak Yaşamak

Saldırganlar, ele geçirilen sunucuya geleneksel kötü amaçlı dosyalar yerleştirmek yerine, Oracle'ın yerleşik JVM'sini ve CREATE JAVA SOURCE ifadesini kullanarak tüm sömürü sonrası araç setini, Oracle veritabanı içinde Java şema nesneleri olarak derleyip depoladı . Bu yaklaşım, standart işletim sistemi düzeyindeki savunmalar tarafından görülmelerini engelledi çünkü EDR ve antivirüs yazılımları, işletim sistemindeki süreçlere, ikili dosyalara (binary) ve dosyalara odaklanır; Oracle içinde depolanan Java sınıflarını ve PL/SQL sarmalayıcılarını genellikle denetlemez .

Khunt araç seti şu bileşenleri içeriyordu ve her biri bir veritabanı nesnesi olarak saklanıyordu:

Tam Sistem Kontrolüne Ulaşmak: Veritabanından Windows İşletim Sistemine Geçiş

Saldırganlar, yalnızca veritabanı seviyesinde kalmadı. Khunt araç setini kullanarak çok adımlı bir süreçle veritabanı katmanından alttaki Windows işletim sistemine geçtiler:

1. KhuntCmd ile İşletim Sistemi Komut Çalıştırma: KhuntCmd modülünü kullanarak cmd.exe /c whoami komutunu çalıştırdılar ve Windows sunucusunda SYSTEM seviyesinde yetkileri olduğunu doğruladılar. Bu, veritabanından işletim sistemine uzaktan kod çalıştırma (RCE) anlamına geliyordu .
2. Kimlik Bilgisi Hırsızlığı: PowerShell kullanarak reg.exe komutunu çağırdılar ve SECURITY ile SYSTEM kayıt defteri kovanlarını kopyalayarak F:\Oracle\ dizinine khuntSECURITY.hiv ve khuntSYSTEM.hiv olarak kaydettiler .
3. Hizmet Numaralandırması: tasklist /svc komutunu çalıştırarak çıktıyı khunttasks.txt dosyasına kaydettiler .
4. Ek Kovan Çıkarma: esentutl.exe aracını kullanarak SAM ve ikinci bir SECURITY kovanı kopyasını alıp khuntSAM.hiv ve khunt_SECURITY.hiv olarak kaydettiler .

Sızdırılan bu kayıt defteri kovanları, çevrimdışı olarak kullanılıp sistemdeki tüm yerel hesapların parola hash'lerini çıkarmak ve kırmak için kullanılabilirdi .

Savunmadaki Kör Noktalar: Huntress'in Temel Bulguları

Huntress'in soruşturması, bu saldırının başarılı olmasına ve tespit edilmekten kaçınmasına izin veren birkaç kritik kör noktayı ortaya çıkardı:

• Veritabanının Köprübaşına Dönüşmesi: Veritabanı, pasif bir veri deposundan aktif bir saldırı platformuna dönüştürüldü. Kötü amaçlı araç seti, diskte veya bellekte değil, veritabanının içinde yaşıyordu .
• EDR/AV'den Kaçış: Geleneksel EDR ve antivirüs araçları, Oracle içinde depolanan Java sınıflarını ve PL/SQL sarmalayıcılarını genellikle denetlemez. Bu durum, araç setini standart işletim sistemi düzeyindeki savunmalara karşı görünmez kıldı .
• Klasik Açık, Yeni Teslimat Yöntemi: İlk SQL enjeksiyonu, iyi bilinen bir hata sınıfıydı. Sıfırıncı gün açığı (zero-day) gerektirmiyordu. Otomatik tamamlama arama özelliği, PL/SQL'e ve ardından işletim sistemine ulaşmak için yeterliydi. Bu, veritabanı motorunun işletim sistemi seviyesinde yetenekleri olduğunda, temel girdi doğrulama hatalarının ne kadar derin bir güvenlik ihlaline yol açabileceğini gösteriyor .
• Aşırı Yetkilendirilmiş Veritabanı Hesapları: SQL enjeksiyonu başarılı olsa bile, veritabanı kullanıcı hesabının Java kaynakları oluşturma veya saklı prosedürleri çalıştırma yetkisi yoksa hasar sınırlı kalır. Kuruluşlar genellikle veritabanı hesaplarına gereğinden fazla yetki verir, bu da saldırganlara khunt'ı dağıtmak için ihtiyaç duydukları ek izinleri sağlar .

Huntress Tarafından Önerilen Önlemler

Bu saldırıya dayanarak Huntress şu önlemleri önerdi :

• Tüm web girdileri için uygun girdi temizliği (input sanitization) ve sorgu parametrelendirmesi (query parameterization) yapılması
• Veritabanı kullanıcı yetkilerinin kısıtlanması; böylece enjekte edilen sorguların bile Java kaynakları oluşturamaması veya rastgele saklı prosedürler çalıştıramaması sağlanmalı
• İzleme kapsamının yalnızca işletim sistemi düzeyindeki öğelerle sınırlı kalmayıp veritabanı nesnelerini (Java sınıfları, PL/SQL sarmalayıcıları) da içerecek şekilde genişletilmesi

Bu saldırı, yerleşik programlama ortamlarına (Oracle'ın JVM'si gibi) sahip veritabanı motorlarının, tek bir doğrulanmamış girdi alanıyla birleştiğinde nasıl gizli saldırı platformlarına dönüşebileceğinin çarpıcı bir hatırlatıcısıdır. Güvenlik ekipleri, izleme faaliyetlerini işletim sisteminin ötesine taşıyarak veritabanı nesne katmanını da kapsamalıdır.