ONNX Modeli Dahili Dosya ve Truva Atı Tehditleri (Backdoor) İçeriyor

Genel Bakış

Backdoor (Arka kapı) tehditleri genellikle bilinen veri açma (deserialization) açıklarından yapı olarak biraz farklıdır. Oldukça karmaşık kurgu yetenekleri sayesinde siber saldırganlar, yapay zeka yapı taşlarının kapasitesini kullanarak zararlı makine kodlarını, harici yürütülebilir exe/bin dosyalarını görünüşte normal veri barındıran temel model dosyalarının içine gizleyebilirler.

PAIT-ONNX-200 uyarısı alan modellerin durumu:

Sunulan dosyaların serileştirme yapısı ve veri seti şeması standart ONNX (Open Neural Network Exchange) ile örtüşmektedir.
Eresus Sentinel tarayıcısı ONNX parametrelerinin gölgesine veya eklenen alt klasörlere (directories) gömülmüş tehlikeli ikili sistem harici dosyaları, arka kapıları saptamıştır.
ONNX hesaplama grafiklerini izole etmekte oldukça iyidir ancak paketleme kabiliyetleri harici zararlı kütüphanelerin matematik işlemlerine asalak formda gizlenmesine mahal verir.

Önemli Noktalar

Yapay zeka platformları ve kod yönetim sistemleri (HuggingFace vb.) zararlı kuluçkasına ev sahipliği etmek için Trojan (Truva Atı) dosyaları açısından mükemmel kamuflaj alanlarıdır.
ONNX içindeki bir casus yazılım geleneksel antivirüs güvenlik duvarlarını ekarte edip doğrudan ML platformlarını zehirleyebilir.

Etkisi

Zararlı arka kapılara sahip modeller kuruluşlarda ciddi altyapı siber sorunlarına yol açar. Gömülü çalışan bir trojan (Truva Atı); içerideki geliştirici verilerini şifreleyerek fidye faaliyetlerine (Ransomware), dışarıya ağ yapısı detaylarını veya SSH şifrelerini sızdırarak veri hırsızlığına, CI/CD platformlarında yatay sızmaya mahal verir.

En İyi Çözüm Pratikleri

Ağa dahil olan veya API sunucularına bağlanacak potansiyel her dosya dizinini Eresus Security statik tarayıcılarına emanet edin.
Halka açık AI platformlarında bulunan güvenilir görünüşlü, onaylı markanın logosunu kullanan yüksek puanlı ONNX varyantlarına körü körüne güvenmeyin.
Model MLOps hattında yürürlüğe konulmadan sadece sınır doğrulamalarıyla tüm mimari süzgeçleri atlamayın.

İyileştirme (Remediation)

İlgili ONNX mimarisini hemen sistem ve ağ sunucularından ayıklayın. Sızıntıya mahal veren dosyanın kurum ağına nereden sızdığını kayıt (SIEM) günlüklerinden belirleyin ve tüm takım iç iletişim ağında açıkça paylaşın. Parçalanmış zararlı paketini kendiniz el ile (manual) temizlemeye ve onarmaya uğraşmayın. Alternatif daha güvenli model sağlayıcılarına ya da direkt temiz PyTorch ağırlık dosyalarına başvurun.

Temel Değerlendirme

Model dosyaları yalnızca ağırlık veya matematik çıktısı değildir; bazı formatlar yükleme sırasında kod çalıştırabilir, beklenmeyen operatörleri tetikleyebilir veya çalışma zamanı davranışını değiştirebilir. Bu nedenle model güvenliği, dosya taramasından daha geniş bir artefact intake ve runtime izolasyonu problemidir.

Bu Konu Neden Önemli?

Model artefact production ortamına girdiğinde onu kullanan tüm servisleri etkiler.
Pickle, Keras Lambda, bazı export/import akışları ve runtime operatörleri beklenmeyen davranış üretebilir.
Topluluk model havuzlarından alınan dosyalar, klasik paket bağımlılığı gibi tedarik zinciri riski taşır.

Güvenlik ekipleri açısından değer, tekil bir bulgunun adından çok bulgunun hangi veriye, kullanıcıya, sisteme veya iş sürecine temas ettiğini gösterebilmekten gelir.

Bu nedenle değerlendirme yapılırken sadece teknik kontrol listesi değil, gerçek saldırı yolu, istismar kanıtı, operasyonel etki ve düzeltme önceliği birlikte ele alınmalıdır.

Pratik Örnek

Bir ekip açık kaynak model dosyasını indirip doğrudan inference servisine eklediğinde risk sadece model cevabı değildir. Yükleme sırasında çalışan unsafe deserialization yolu ortam değişkenlerini okuyabilir, dış bağlantı kurabilir veya job runner üzerinde kalıcı iz bırakabilir.

Yanlış Bilinenler

Modelin doğruluk oranı iyiyse güvenli olduğunu varsaymak.
Antivirüs taramasını model security review yerine koymak.
Model yükleme işlemini network izolasyonu olmadan production’a yakın ortamda yapmak.

Karar Tablosu

| Durum | Risk | Ne Yapılmalı? | | --- | --- | --- | | Sistem hassas veriye erişiyor | Veri sızıntısı veya yetki aşımı | Kapsamlı güvenlik testi planlanmalı | | Sadece demo ortamında çalışıyor | Düşük ama büyüyebilir risk | Mimari ve veri akışı şimdiden belgelenmeli | | Üretime yakın entegrasyon var | Zincirleme etki ve operasyon riski | Assessment, remediation ve retest takvimi çıkarılmalı |

Uygulanabilir Kontrol Listesi

Varlık, veri ve kullanıcı rolleri açıkça listelendi mi?
Kritik akışlar gerçek kullanıcı senaryolarıyla test edildi mi?
Yetki sınırları hem başarılı hem başarısız isteklerle doğrulandı mı?
Log, hata mesajı ve izleme sistemleri hassas veri sızdırıyor mu?
Bulgu çıktıları iş etkisi ve remediation sahibiyle birlikte yazıldı mı?
Düzeltme sonrası retest kriteri önceden belirlendi mi?

Profesyonel Destek Ne Zaman Gerekir?

Dış model dosyaları, müşteri verisiyle çalışan inference servisleri veya otomatik model intake pipeline’ları varsa profesyonel model security review gerekir.

Profesyonel destek gerektiren en net sinyal, riskin tek bir ekip tarafından tamamen görülememesidir. Ürün, güvenlik, DevOps, veri ve hukuk ekipleri aynı soruya farklı cevap veriyorsa bağımsız assessment işi hızlandırır.

Eresus Yaklaşımı

Eresus Security bu tip konularda yalnızca bulgu listesi üretmez; saldırı yolunu, iş etkisini, kanıtı, önerilen düzeltmeyi ve retest koşulunu birlikte verir.

Çalışma çıktısı teknik ekip için uygulanabilir, yönetim için anlaşılır ve satış/uyum görüşmeleri için kanıt niteliği taşıyacak şekilde hazırlanır.

Eresus uzmanları, model dosyalarını provenance, format riski, yükleme davranışı ve runtime izolasyonu açısından inceler. Üçüncü taraf model kabul sürecinizi güvenli bir intake mimarisine dönüştürebiliriz.

Saha Kontrol Soruları

Model kaynağı kim tarafından doğrulandı?
Dosya hash’i ve imza kontrol ediliyor mu?
Yükleme işlemi network izolasyonunda mı?
Unsafe deserialization yolu var mı?
Format parser güncel mi?
Runtime dış bağlantı kurabiliyor mu?
Ortam değişkenlerine erişim sınırlandırıldı mı?
Model provenance kaydı tutuluyor mu?
Karantina ve manuel onay adımı var mı?
Inference container yetkileri daraltıldı mı?
Dosya boyutu ve metadata anomalileri izleniyor mu?
Model import logları merkezi toplanıyor mu?
Aynı artefact hangi ortamlara dağıtıldı?
Rollback için temiz sürüm hazır mı?
Üçüncü taraf model politikası yazılı mı?

Sık Sorulan Sorular

ONNX Modeli Dahili Dosya ve Truva Atı Tehditleri (Backdoor) İçeriyor için ilk bakılması gereken şey nedir?

İlk bakılması gereken şey sistemin hangi veriye, hangi kimlikle ve hangi aksiyon yetkisiyle eriştiğidir. Teknik araç seçimi bundan sonra anlam kazanır.

Bu çalışma yalnızca otomatik araçlarla yapılabilir mi?

Otomatik araçlar iyi bir başlangıçtır ama iş mantığı, yetki sınırı, zincirleme etki ve gerçek istismar kanıtı için manuel güvenlik analizi gerekir.

Çıktı nasıl aksiyona dönüşür?

Her bulgu için etki, kanıt, önerilen düzeltme, sorumlu ekip ve retest kriteri yazılır. Böylece rapor sadece okunmaz, sprint veya güvenlik backlog’una girer.

Eresus bu konuda nasıl destek verir?

Eresus Security kapsam çıkarma, teknik test, risk önceliklendirme, remediation danışmanlığı ve retest aşamalarını tek bir çalışma akışıyla destekler.

Uygulama Planı

1. Kapsamı Netleştir

Model kaynağı, hash, imza, format, parser sürümü ve yükleme ortamı birlikte incelenir.
Import/load aşamasının ağ, dosya sistemi ve ortam değişkeni erişimi gözlemlenir.
Modelin production’a hangi pipeline üzerinden taşındığı ve kimlerin onay verdiği çıkarılır.

2. Kanıt Üret

Unsafe deserialization, şüpheli operatör veya runtime davranışı kontrollü sandbox içinde kaydedilir.
Aynı artefact’ın farklı ortamlara etkisi ve tekrar üretilebilirliği doğrulanır.
Model davranışıyla sistem davranışı birbirinden ayrılarak yanlış alarm riski azaltılır.

3. Düzeltmeyi Takip Edilebilir Hale Getir

Karantina ortamı, imza doğrulama ve provenance kaydı zorunlu hale getirilir.
Inference container yetkileri ve network çıkışı minimuma indirilir.
Dış model kabul süreci güvenlik onayı olmadan production’a geçmeyecek şekilde tasarlanır.

Raporlama Formatı

Bulgu adı kısa ve teknik olarak net yazılmalı.
Etkilenen varlık, kullanıcı rolü ve veri sınıfı belirtilmeli.
İstismar adımları tekrar üretilebilir ama gereksiz saldırı detayı içermeyecek şekilde verilmeli.
İş etkisi, teknik etkiden ayrı açıklanmalı.
Önerilen düzeltme, sorumlu ekip ve retest kriteri aynı blokta yer almalı.

İç Link ve Sonraki Okuma Stratejisi

Yazı ilgili hub sayfasına bağlanmalı.
Aynı pillar içindeki iki destekleyici bloga bağlantı verilmelidir.
Hizmet sayfasına giden CTA, okuyucunun bulunduğu karar aşamasına uygun olmalıdır.
Advisory veya araştırma içeriği varsa güven sinyali olarak ikincil bağlantı şeklinde kullanılmalıdır.

Sonraki Adım

Bu yazıdan sonra backdoored LLM tespiti, model file backdoor formatları ve pickle/RCE içerikleri aynı model intake sürecine bağlanmalıdır.