Joblib / Scikit-Learn Rastgele Kod Çalıştırma (ACE) Zafiyeti

Genel Bakış

Python geliştiricileri arasında joblib kütüphanesi sarsılmaz bir yere sahiptir. Özellikle "Scikit-Learn" (Rastgele Ormanlar, SVM vb.) tabanlı, içi devasa sayısal analizlerle (NumPy matrisleriyle) dolu makine öğrenimi modellerini hızlıca diske kaydetmek ve okutmak için joblib.dump() ve joblib.load() komutları kullanılır.

Fakat Eresus Sentinel sisteminizde beliren PAIT-JOBLIB-100 zafiyeti, yüklenmeye çalışılan bu "özel" modelin içerisine gizlenmiş yıkıcı bir siber komut pakedi olduğunu tespit etmiştir.

Zafiyetin temel sebebi joblib mimarisinin bizzat yapısıdır. Hızlı veri işleyebilmek için çekirdeğinde büyük oranda klasik Python pickle modülünü çevreleyen (wrapper) bir yapısı vardır. Dolayısıyla Pickle açıklarının tamamı Joblib yapılarında da ölümcül Remote Code Execution (Uzaktan Kod Çalıştırma - RCE) riskini taşır. Korsanın derlediği sahte bir .joblib dosyası yüklendiğinde içindeki tüm şifreli kodlar makinenizde tam yetkiyle çalışacaktır.

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

Saldırganlar .joblib paketinin içindeki şifreli veri bloklarına __reduce__ sınıfını atayarak zararlı sistem komutlarını modeller listesinde yayımlarlar. Veri Bilimcisi bu modeli kurduğunda komutlar sunucuya indirilir.

sequenceDiagram
    participant Attacker as Korsan
    participant ThirdParty as Açık Kaynak ML Sitesi
    participant MLOps_Env as Şirketin Scikit-Learn Ortamı
    participant Host_OS as Kurban Klasör Sistemi

    Attacker->>ThirdParty: İçinde Backdoor olan "Analiz.joblib" sunulur
    MLOps_Env->>ThirdParty: Otomatik CI/CD veya personel modeli bilgisayara çeker
    MLOps_Env->>MLOps_Env: Analiz için 'model = joblib.load(hedef)' çalıştırılır
    MLOps_Env->>Host_OS: Makine NumPy kodlarını deşifre ederken "Şifre Çalma" komutu aradan sıyrılır
    Host_OS-->>MLOps_Env: Sistem şifrelerini (Env) okur ve verileri tutar
    Host_OS->>Attacker: Cihaz korsanın IP adresine sessizce veritabanı loglarını yollar

Önemli Noktalar

Sayısal Verilere Aşırı Güven: Birçok BT personeli, .joblib veya .pkl uzantılarını tıpkı bir hesap makinesi yığını gibi tehlikesiz sayılardan ibaret zanneder. Aksine bunlar doğrudan çalışmaya hazır betiklerdir (Scripting architecture).
Tarihsel Zafiyet Geçmişi (CVE-2022-21797): Eski Joblib sürümlerinde, paralel işlemler (Multi-threading) yapılırken eval() komutunun denetimsiz çalışması sonucu ciddi açıklar raporlanmıştır. Zafiyet sadece ağırlık kodlarında değil kütüphanenin temelinde de köklenmiş olabilir.

Etkisi

Zehirlenmiş bir .joblib dosyasının ağınıza kabul edilmesi "İçeriden Fethi" mümkün kılar. Kurban model okuduğunu düşünürken zararlı kodlar saniyeler içerisinde sistemdeki Azure, S3 veya AWS ortam şifrelerine el koyup dışarı kaçırabilir. Ağ haritanızı çıkararak sunuculardaki kritik konteyner yapılarına yatay sızabilir (Lateral movement) ve nihai olarak tüm donanımdaki dosyaları şifreleyen bir Ransomware bombası ateşleyebilir.

En İyi Çözüm Pratikleri

Anonim Joblib Kaynaklarına Güvenmeyin: Kendi şirketinizin güvenilir CI/CD boru hattından (Pipeline) bizzat kendi eğittiğiniz kodlar halinde çıkmadığı sürece, rastgele indirilmiş dış .joblib verilerini kurum ağında load() komutuyla aslat okutmayın.
Güvenli Scikit-Learn Eklentileri Seçin: Model kayıt etme alışkanlıklarınızı skops platformu gibi güvenilir yapılara taşıyın. skops.io, temelinde zehirli (executable) pickle komutları kullanılmasını engelleyen şeffaf bir ML veri koruma standardı barındırır.
ONNX Dönüşümlerini Kullanın (ONNX Compilation): Modelinizi yalnızca üretim/servis bandına (Inference serving) sürecekseniz Scikit-Learn formüllerinizi "Open Neural Network Exchange (ONNX)" formatlarına aktararak çalıştırın. Python program belleği kullanmadan donanıma matematik hesabı yaptıran bu izole mimariler izinsiz siber komut çalışmasını fiziken ret eder.

İyileştirme (Remediation)

Eresus Sentinel algoritmaları bu tehdidi önlediyse şüphe altındaki çalışma ortamınızı hemen donanımsal izolasyona (Karantina) çekin. Cihazla son bir saatte etkileşime geçmiş bulut yönetim rollerini (IAM Roles) ve servis şifrelerini anında silip yenileyin. Sözde ML model paketinin ağdaki cihazlarınızda yayılıp yayılmadığını tüm repoları tarayarak teşhis edin, kaynağı saptayıp .joblib virüsünü fiziksel olarak sistemden yok edin.

İleri Okumalar ve Kaynaklar (Further Reading)

Yazılım optimizasyon kütüphanelerindeki özel siber güvenlik açıklıklarını daha geniş analizlerle öğrenin:

NIST - CVE-2022-21797 Vaka Raporu: Geçmişteki Joblib paralel işleme hatasının RCE açığına nasıl saptığı üzerine Amerikan Siber Raporu.
Scikit-Learn Güvenlik Dokümantasyonu: Platformun kendi yazarlarından güvenilmeyen kaynakların barındırdığı yıkıcı Pickel (Joblib) altyapı tehlikeleri.
SKOPS Güvenli ML Standardı: Zararlı kod çalıştırmasına mani olan güvenli formatlı yeni nesil yükleme protokelleri.

📥 Eresus Sentinel Scikit-Learn Ekosisteminizi Tam Koruma Altına Alır Gündelik bir yapay zeka analiz ortamının, şirketinizi batıracak bir siber rehinlenme olayına dönüşmesine izin vermeyin. Eresus Sentinel, sisteminizin indirdiği .joblib dizilerindeki opcode satırlarını anbean deşifre eder. Shell virüslerine, izinsiz sistem okumalarına ve port komutlarına taviz vermeyen siber altyapımızla tanışın.

Daha Fazla Bilgi | Demo Randevusu Alın

SSS

Bu risk sadece prompt injection ile mi sınırlı?

Hayır. AI güvenliğinde prompt injection önemli bir başlangıçtır ama tek başına resmi anlatmaz. Retrieval katmanı, tool izinleri, model artefact güveni, loglarda hassas veri, kullanıcı yetkisi ve entegrasyon sınırları birlikte değerlendirilmelidir.

İlk teknik kontrol ne olmalı?

Önce sistemin hangi veriye eriştiği, hangi aksiyonları alabildiği ve bu aksiyonların hangi kimlikle çalıştığı haritalanmalıdır. Bu harita olmadan yapılan test genellikle birkaç prompt denemesinden öteye geçemez.

Ne zaman profesyonel destek gerekir?

AI uygulaması müşteri verisine, iç dokümana, üretim API’lerine veya otomatik aksiyon alan agent akışlarına erişiyorsa profesyonel güvenlik incelemesi gerekir. Bu noktada risk artık model cevabı değil, kurum içi yetki ve veri sınırıdır.

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?