Keras HDF5 'Lambda Layer' İzinsiz Kod Çalıştırma (RCE) Zafiyeti

Genel Bakış

Keras platformu, TensorFlow motorunun en güçlü ön yüz (API) geliştirme aracıdır. Ancak yeni nesil güvenilir formata (.keras v3) geçiş yapılana dek, dünyadaki milyonlarca ML geliştiricisi yıllar boyunca modellerini eski HDF5 (.h5) formatında derleyip kaydetti.

Eresus Sentinel ekranında PAIT-KERAS-100 zafiyeti görüyorsanız, sistem eski jenerasyon (legacy) bir .h5 Keras dosyasının içindeki özelleştirilmiş kod bölümlerini (Custom Objects / Lambda Layers) okumaya çalışırken, bu katmanlara zehirli siber komutların eklendiğini fark etmiş ve süreci felaketten önce kesmiştir.

Açığın temel varlık sebebi HDF5 sisteminin, yazılımcılara kolaylık olması açısından, modelin içerisine doğrudan "okunabilir Python kodları" eklenmesine müsaade etmesidir. (Keras motoru, standart bir matematik fonksiyonu uyduramadığında kullanıcının yazdığı manuel "Lambda" Python kodlarını alıp pickle mimarisiyle modelin içine gömer). Doğal olarak siber bir korsan, oradaki matematiksel döngüyü silip yerine sunucuya arka kapı açacak zararlı işletim sistemi kodları (os.system("nc -e /bin/bash...")) tanımlayabilir. Dosya kurbanda keras.models.load_model() çağrısıyla açıldığı an, Keras bu kodu iyi niyetli bir hesap formülü sanarak okur ve sunucuyu hackletir.

safe_mode Argümanı Neden İşe Yaramaz?

Güncel Keras kullanıcıları load_model(safe_mode=True) yazarak güvende olduklarını düşünürler. Fakat bu parametre yalnızca modern .keras dökümanlarını korumak için tasarlanmıştır. Yazılım, eski bir .h5 dosyası çağırdığında bu güvenlik bayrağını çoğunlukla göz ardı eder (Ignore) ve gizli virüs sorunsuzca derlenerek RCE patlaması yaşatır.

Saldırı Nasıl Gerçekleşiyor (How The Attack Works)

Korsanlar Hugging Face gibi platformlara oldukça inandırıcı gözüken (.h5 formunda) açık kaynaklı Keras projeleri atarlar. Geliştirici onu sistemine load ettiği saniyede virüs sisteme yapışır.

sequenceDiagram
    participant Attacker as Saldırgan
    participant File_Registry as Dış Model Kaynağı
    participant Keras_Backend as Cihazdaki Keras Motoru
    participant OS as Kurban İşletim Sistemi

    Attacker->>Attacker: H5 dosyasının Activation(Lambda) katmanına root komutu gömer
    Attacker->>File_Registry: Eğitimli olarak "YuzTanima_v1.h5" modelini yükler
    Keras_Backend->>File_Registry: Geliştirici modeli test etmek için bilgisayarına indirir
    Keras_Backend->>Keras_Backend: `keras.models.load_model()` kodu okumaya başlar
    Keras_Backend->>Keras_Backend: Lambda nesnesine gelir ve 'Pickle' yetkileriyle kodu çalıştırır
    Keras_Backend->>OS: Gizlenen işletim sistemi tırnakları (OS hooks) asıl sunucuya emir verir
    OS-->>Attacker: Sunucu dış dünyaya port açarak korsana sessizce komuta yetkisi verir

Önemli Noktalar

• Kendi Yazılımınızla Vurulursunuz: Virüs programları bu durumu saptayamaz çünkü dosyayı açan, zararlı kodu tetikleyen mimari bizzat bilgisayarınıza güvenle kurduğunuz Keras Python modülünün ta kendisidir. Cihaz için her şey olağan görünür.
• Eski Kodların Acımasızlığı: "Format deprecated (eskidi)" denilse de internetteki ML eğitim arşivlerinin %70'inden fazlası hala HDF5 kalıntılarıyla doludur. Kurban havuzu milyarlarcadır.
• Sistematik MLOps Vurukları: (CVE-2024-3660, CVE-2025-9905) gibi ciddi kayıtlı olaylar, Keras sistemlerinin doğrulanmamış modülleri taramadan geçirmedeki yapısal zayıflığını acı tecrübelerle kanıtlar.

Etkisi

Zehirlenmiş tek bir Keras .h5 modelini bilgisayarınızda okutmanız makinenizi kalıcı olarak tehdit aktörüne bağlar. İster şirketinizin Amazon IAM hizmetini, ister kişisel donanım ağınızı (Ethernet/VPN) kullanıyor olun hedef tamamen ele geçirilir. Korsan GPU ve Ram'lerinizi kripto kazıcılara boğdurturken veritabanlarınızı fidye bataklığına kilitler. Olay Keras'un load_model aşamasında tamamen otonom patladığı için verilerin ne sunduğunun ya da matematiksel ağın tutarlı olup olmamasının artık hiçbir önemi kalmaz.

En İyi Çözüm Pratikleri

• Korsan H5 Arşivlerine Son Verin: Kurum içinde onaylanmamış dış repo geliştiricilerinden çekilen eski .hdf5 veya .h5 model veri havuzlarını test etmeyi yasaklayın. Modellerin mutlaka modernize edilmiş ve güvenli .keras uzantısında yayımlanmış olanlarını indirin.
• Kişisel Fonksiyonları İptal Edin (Disable Custom Objects): Çok acil bir durumda arkaik (eski) bir model okutmak mecburiyetiyse, yükleme modülünü Keras için özel olan custom_objects=None limitleriyle bağlayarak içerdeki saklı kodların hafızaya yansımasını kesin.
• Özel Alan Simülasyonu (Air-Gapped Sandboxing): Modelin içi bilinemiyorsa, ana sisteme internet erişimi olmayan (offline), kısa ömürlü ağ yalıtımlı Docker kısıtlarında açarak ilk kod patlamasının kurban sunucularınıza ulaşmasını önleyin.

İyileştirme (Remediation)

Eresus Sentinel üzerindeki PAIT-KERAS-100 alarm bayrağı yanıyorsa sistem; HDF5 içine saklanarak Keras maskesiyle RCE açmaya yeltenen bir Lambda kodunu sızmadan durdurmuştur. Dosyanın otonom parçalarının hafızaya sızabildiği ihtimallerinden kurtulmak amacıyla ilgili Keras sunucusunu ve betiğini anında askıya alın. Şirketinizin veri ambarlarından o sonu ".h5" biten zehirli modeli bularak çekirdek dosyasıyla beraber fiziken parçalayın ve modeli açık formdaki yepyeni safetensors algoritmalarına geçirin.

İleri Okumalar ve Kaynaklar (Further Reading)

Güvenilmez seri okuma dosyalarındaki zayıf mimarileri tanımlama yetinizi güçlendirin:

• Resmi Keras Güvenlik Dokümantasyonu: Geliştiricilerin bizzat legacy sistemlerin neden payload manipülasyonlarına ev sahipliği yaptığını izah ettiği güvenlik yönergesi.
• CVE-2024-3660 RCE Kusurları: NIST tarafından duyurulan HDF5 Lambda Layer tahrifatının ML yapılarına olan doğrudan yıkımı üstüne teknik özetler.
• TensorFlow Ortam Güvenliği (Serialization): Dış kaynak grafiklerin otonom ortamlarda nasıl izole yollanacağına dair güncel çözüm standartları.

---

📥 Eresus Sentinel Eski Nesil Yükleme Tuzaklarını Anında Filtreler Ömrünü tamamlamış (deprecated) eski teknoloji bir dosyanın şirket bulut deponuzu çökertmesine izin verilemez. Eresus Sentinel, sisteminizin indirdiği yaşlı .h5 sürümlü modüllerin Lambda bloklarındaki gizli ve kodlu argüman dizgelerini salisede tarar. Python hattınızın içine zehirli Unix satırları enjekte etmeye kalkan sömürü virüslerini motor aşamasından önce sonsuza dek kırar. Kurumsal yapay zeka entegrasyonlarınızı bugün otonom zırhla kaplayın.

Daha Fazla Bilgi | Demo Randevusu Alın

Uygulama Notları

AI güvenliği incelenirken ilk soru modelin ne cevap verdiği değil, sistemin hangi yetkiyle ne yapabildiğidir. Aynı prompt güvenli görünebilir; fakat arka tarafta CRM, dosya deposu, ticket sistemi veya SQL aracı bağlıysa risk seviyesi tamamen değişir.

Pratik değerlendirme için ekip şu dört katmanı ayrı ayrı yazmalıdır:

• Kullanıcıdan gelen giriş ve sistem prompt sınırları.
• Retrieval kaynağı, index yetkisi ve hassas veri filtresi.
• Tool çağrıları, API token kapsamı ve onay mekanizması.
• Log, izleme, alert ve olay müdahale akışı.

Karar Çerçevesi

AI uygulaması yalnızca metin önerisi veriyorsa risk daha çok veri sızıntısı ve yanlış yönlendirme üzerinden okunur. Uygulama tool çağırıyor, dosya yazıyor, ticket açıyor, ödeme başlatıyor veya müşteri kaydı güncelliyorsa değerlendirme agent runtime güvenliğine döner.

Bu ayrım önemlidir çünkü prompt filtreleri runtime yetki hatasını çözmez. Filtre modeli ikna etmeye çalışır; güvenli runtime ise agent yanlış ikna edilse bile neye erişemeyeceğini belirler.

Profesyonel Destek Eşiği

Aşağıdaki durumlardan biri varsa konu artık yalnızca iç kontrol maddesi değildir:

• Production verisi veya müşteri hesabı etkilenebilir.
• Yetki sınırı birden fazla rol ya da tenant üzerinden çalışır.
• Bulgu zincirlenince veri sızıntısı, kalıcı erişim veya operasyon kesintisi doğurabilir.
• Ekipte test kanıtını yeniden üretecek ve remediation önceliği çıkaracak zaman yoktur.

Eresus Security bu noktada bulguyu sadece raporlamakla kalmaz; istismar kanıtı, etki analizi, remediation sırası ve retest kriteriyle birlikte ele alır. Böylece ekip “ne açık?” sorusundan “neyi, hangi sırayla kapatmalıyız?” kararına geçer.

Ek Kontrol Soruları

• Bu risk hangi varlıkları etkiliyor?
• Hangi kullanıcı rolleri bu akışa erişebiliyor?
• Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
• Bulgunun müşteri verisine etkisi var mı?
• Loglardan olayın izi sürülebiliyor mu?
• Düzeltme sonrası retest nasıl yapılacak?
• Geçici önlem ile kalıcı çözüm ayrıldı mı?
• İş etkisi teknik ekibin dışında da anlaşılır mı?
• Benzer hata için önleyici kontrol eklenebilir mi?
• Ekip bu kontrolü release sürecine bağlayabilir mi?
• Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
• Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?