TDE/EKM Tabanlı SQL Server Saldırısı ve Veritabanı Kurtarma

TDE/EKM tabanlı SQL Server saldırısı, SQL Server'ın veritabanlarını korumak için kullandığı şifreleme altyapısının yetkisiz kişiler tarafından bir kilitleme yöntemine dönüştürülmesidir. Saldırgan veritabanı dosyalarını silmek veya uzantılarını değiştirmek yerine, onları kendi denetimindeki harici bir şifreleme anahtarına bağlar. SQL Server bu anahtara ulaşamadığında MDF ve LDF dosyaları yerinde durduğu hâlde veritabanları açılamaz.

Geçtiğimiz günlerde, bizim de ilk kez karşılaştığımız bir vakada müşterimiz SQL veritabanlarının kurtarılması için başvurdu. İnceleme sırasında oldukça sıra dışı bulgulara ulaştık ve sorunun SQL veritabanı hasarından ya da disk arızasından kaynaklanmadığını fark ettik. Daha önce benzerine rastlamadığımız bu vakayla birlikte yeni bir SQL Server saldırı yöntemiyle karşılaştık.

Analiz Bulgularımız

Müşterimiz sunucusunun SSD'sini laboratuvarımıza gönderdiğinde ilk olarak diskin sağlık durumunu kontrol ettik. S.M.A.R.T. raporlarında ve yaptığımız okuma testlerinde herhangi bir arızaya rastlamadık. Özgün disk üzerinde işlem yapmadan sektör bazlı tam imajını aldık. İmaj alma işlemi sırasında da tek bir okuma hatasıyla karşılaşmadık. Bu sonuçlar, veri kaybının diskin fiziksel durumundan kaynaklanmadığını gösterdi.

İmaj üzerinden 12 SQL Server veritabanına ait MDF ve LDF dosyalarını, sistem veritabanlarını ve müşterinin haftalık olarak aldığı BAK yedeklerini çıkardık. MDF dosyalarının hiçbiri SQL Server'a bağlanamıyordu. Haftalık yedekler de geri yükleme işlemi sırasında hata veriyordu.

SQL Server veritabanı dosyaları, sürümlerine göre değişen ancak ikili düzeyde tanınabilen dosya başlıklarına, sayfa yapılarına ve kayıt düzenlerine sahiptir. Dosya türlerinin kendilerine özgü imzaları ve yapısal işaretleri bulunur. İncelediğimiz MDF dosyalarında beklediğimiz SQL Server sayfa yapıları görünmüyordu. Hex alanları karmaşık ve anlamsız veri bloklarıyla doluydu. Aynı görünüm haftalık BAK dosyalarında da vardı.

Disk sağlamdı; özgün veritabanları ve yedekleri ise aynı biçimde okunamıyordu. Bu aşamada sıradan bir dosya bozulmasından değil, veritabanlarına kasıtlı olarak uygulanmış bir şifreleme işleminden şüphelenmeye başladık.

Sistem Kayıtları Saldırıyı Ortaya Çıkardı

Dosyalar üzerinde onarım komutları denemek yerine Windows kayıtlarını, SQL Server günlüklerini, sistem veritabanlarını ve sunucuya sonradan eklenen bileşenleri inceledik. Kayıtlar, sisteme şirketin bilgisi dışında harici bir EKM sağlayıcısının kurulduğunu ve SQL Server veritabanlarının bu sağlayıcıdaki asimetrik anahtara bağlandığını gösterdi.

Şifreleme işlemi elektrik kesintisinden yaklaşık iki hafta önce başlamıştı. SQL Server günlüklerinde görülen 15466 numaralı şifre çözme hatası ve BAK dosyalarındaki asimetrik anahtar hatası aynı anahtar bağımlılığına işaret ediyordu. Veritabanı dosyaları bozulmamıştı; onları okunabilir hâle getiren şifreleme zinciri çalışmıyordu.

SQL Server'da TDE ve EKM Nedir?

Transparent Data Encryption (TDE), SQL Server veritabanlarının veri ve günlük dosyalarını depolama ortamında şifreler. Veritabanı şifreleme anahtarı, veritabanının önyükleme kaydında tutulur. Bu anahtarın kullanılabilmesi için SQL Server'ın onu koruyan sertifikaya veya asimetrik anahtara erişmesi gerekir.

Extensible Key Management (EKM), bu asimetrik anahtarların SQL Server dışında çalışan bir anahtar yönetim sisteminde veya donanımsal güvenlik modülünde saklanmasını sağlar. Kurumsal sistemlerde anahtarların veritabanı sunucusundan ayrı tutulması güvenliği artırır. SQL Server ile harici anahtar sistemi arasındaki bağ yetkisiz kişilerce kurulmuşsa aynı yapı veritabanlarını erişilemez hâle getirmek için de kullanılabilir.

Meşru Şifreleme Altyapısı Nasıl Saldırıya Dönüştürüldü?

Saldırgan, sunucuda elde ettiği yönetici yetkisini kullanarak harici EKM sağlayıcısını SQL Server'a tanıtmış ve veritabanlarının şifreleme anahtarlarını kendi denetimindeki sisteme bağlamıştı. Şifreleme işlemini SQL Server yürüttüğü için dosya adları ve uzantıları değişmemiş, sistemde klasik bir fidye yazılımı notu oluşmamıştı.

Harici anahtara erişim sürdüğü müddetçe uygulamalar çalışmaya devam etti. Bu sırada alınan haftalık yedekler de aynı anahtar zincirine bağımlı hâle geldi. Sunucu elektrik kesintisinden sonra yeniden başladığında harici anahtar bağlantısı kurulamadı ve 12 veritabanının tamamı SUSPECT durumuna düştü.

Elektrik Kesintisi Yalnızca Saldırıyı Görünür Hâle Getirdi

Elektrik kesintisi veritabanlarını bozmamış veya şifrelememişti. Yaklaşık iki hafta önce kurulmuş saldırı düzenini ortaya çıkarmıştı. Sunucu yeniden başlayana kadar SQL Server gerekli anahtara ulaşabildiği için uygulamalar çalışmış ve kullanıcılar şifreleme işlemini fark etmemişti.

Şifreleme öncesindeki temiz yedeklerin saklama döngüsünden çıkması saldırganın amacı olabilir. Mevcut kayıtlar bu ihtimali desteklese de fidye talebi bulunmadığı için saldırının mali amacı hakkında kesin bir sonuca ulaşmadık. Veri sızdırıldığına ilişkin bir bulgu da eldeki kayıtlarla doğrulanmadı.

Klasik Fidye Yazılımından Farkı

Klasik fidye yazılımlarında dosyalar çoğunlukla SQL Server'ın dışında çalışan bir program tarafından şifrelenir. Dosya uzantıları değişebilir, sisteme fidye notu bırakılabilir veya güvenlik yazılımları yabancı şifreleme sürecini tespit edebilir. Bu vakada şifrelemeyi SQL Server'ın kendisi gerçekleştirmişti. MDF, LDF ve BAK dosyaları özgün adlarını koruyor ancak saldırganın anahtarı olmadan okunamıyordu.

Bu nedenle MDF veya LDF dosyalarını onarmak, başka bir sunucuya kopyalamak ya da haftalık yedekleri geri yüklemek sorunu çözmedi. Kurtarma için eski işletim sistemi, SQL Server ve harici EKM sağlayıcısı arasında kurulmuş şifreleme ilişkisinin yeniden oluşturulması gerekiyordu.

Anahtar Zincirini Nasıl Yeniden Kurduk?

Özgün SSD'ye ve veritabanı dosyalarına müdahale etmeden bütün çalışmayı sektör bazlı imaj üzerinde yürüttük. İmajdan Windows Kayıt Defteri'ne ait SYSTEM, SECURITY ve SOFTWARE dosyalarını, LocalSystem hesabına ait DPAPI Protect kayıtlarını, SQL Server'ın özgün master.mdf dosyasını ve EKM sağlayıcısının kullandığı kütüphaneyi çıkardık. SQL Server hata günlükleri ile geri yüklenemeyen .bak dosyalarında görülen aynı anahtar parmak izi de veritabanlarının ortak bir şifreleme zincirine bağlı olduğunu doğruladı.

Windows Kayıt Defteri'nin SOFTWARE bölümündeki EKM kayıtları; sağlayıcının anahtar deposu, erişim bilgileri ve anahtar eşleştirmelerinin eski makinenin DPAPI korumasıyla saklandığını gösterdi. SYSTEM ve SECURITY dosyaları makineye bağlı koruma zincirinin izlerini, DPAPI Protect kayıtları ise bu zincirde kullanılan ana anahtarı sağladı. Özgün master.mdf içindeki sunucu düzeyindeki EKM kimliği ve asimetrik anahtar ilişkisi, hata günlükleri ile yedeklerdeki parmak iziyle eşleşti. Sağlayıcı kütüphanesini incelediğimizde de kayıtların açılması sırasında kullanılan uygulamaya özgü ek koruma verisini tespit ettik.

Bu parçaları aynı yazılım koşullarını taşıyan izole bir çalışma ortamında bir araya getirerek eski makine, EKM sağlayıcısı ve SQL Server arasındaki anahtar ilişkisini yeniden kurduk. Şifreleme altyapısı çalıştığında 12 veritabanını SQL Server'a bağladık. Veritabanları açıldıktan sonra TDE şifrelemesini kontrollü biçimde kapattık ve her veritabanını saldırıda kullanılan harici anahtar sisteminden bağımsız hâle getirdik.

On İki Veritabanı Yeniden Çalıştı

Kurtarma işlemini veritabanlarının ONLINE görünmesiyle tamamlanmış saymadık. Kullanılan tabloları, kayıt sayılarını ve son işlem tarihlerini kontrol ettik. Elektrik kesintisinden dakikalar önce girilen son fatura ve kasa hareketleri de veritabanlarında bulunuyordu.

On iki veritabanının tamamı yeniden çalıştırıldı ve talep edilen kayıtlarda veri kaybı tespit edilmedi.

Benzer Bir Olayda İlk Müdahale

SQL Server veritabanları yeniden başlatma veya siber olay sonrasında açılmıyorsa aynı dosyalar üzerinde art arda onarım denemeleri yapmak mevcut izleri değiştirebilir. Şifreleme şüphesi bulunan bir sistemde şu işlemlerden kaçınılmalıdır:

• Sunucuyu tekrar tekrar yeniden başlatmak veya işletim sistemini yeniden kurmak
• Özgün MDF ve LDF dosyaları üzerinde zorla attach ya da repair komutları çalıştırmak
• SQL Server sağlayıcılarını, sertifikaları veya Windows kayıtlarını silmek
• Mevcut yedeklerin üzerine yeni yedek almak
• Olay günlüklerini ve saldırının zamanını gösterebilecek sistem kayıtlarını temizlemek

Sunucu ağdan güvenli biçimde ayrılmalı, özgün diskler korunmalı ve inceleme çalışma kopyası üzerinde yapılmalıdır.

MDF, LDF veya BAK dosyalarınız açılmıyorsa SQL Server veri tabanı onarma hizmetimizi inceleyebilirsiniz. Farklı veritabanı sistemlerinde yaşanan dosya ve erişim sorunları için veri tabanı onarma sayfamızda destek verdiğimiz sistemleri bulabilirsiniz.