EresusSecurity
Araştırmalara Dön
Deserialization Threats

Model Üzerinden Çevre Ortamı Değişkeni Sızdırması (Data Exfiltration)

Yiğit İbrahim SağlamOfansif Güvenlik Uzmanı
10 Nisan 2026
Güncellendi: 27 Nisan 2026
6 dk okuma

Genel Bakış

Makine öğrenimini rehin alan bazı Rastgele Kod Çalıştırma (ACE) zafiyetleri gürültülü ters bağlantı (Reverse shell - PAIT-PKL-102) açıp altyapıyı hemen çökertirken, PAIT-PKL-103 tehdidi tamamen sessiz ancak yüksek bütçeli hasarlara sebep olan finansal bir sızıntıdır: Sessiz Veri Sızdırma (Data Exfiltration). Bu tehlike; Eresus Sentinel sisteminizde serileştirilmiş bir model dosyasının belleğe yerleşirken sessizce ortam değişkenlerini, işletim sistemi şifrelerini veya yerel API bağlantı kodlarını tespit edip, korsana iletmesi engellendiğinde karşınıza çıkar.

Python'un esnek pickle serileştirme yeteneği, ağ haritalarını taşımanın çok ötesine geçerek .pkl veya .pt dosyalarının yasal program satırları (kod parçacıkları) kopyalamasına olanak sunar. Cihazlarınızda model geliştiren bulut bazlı MLOps süreçleri genelde AWS/GCP, S3 depolama, dış hizmetler (ör. OpenAI, Anthropic) veya şirket API platformlarıyla olan bağlantısını "Çevre Değişkenlerinde (.env)" aradığından, bu kimlik doğrulamaları saldırganların bir numaralı hazine listesindedir.

Sistem Güvenliğiniz Bir PAIT-PKL-103 Güvenlik Uyarısı Algılırsa: Takımın indirip denemek istediği, dış kaynaktan geldiği varsayılan bir yapay zeka kodunun içerisinde ufak ve zehirli bir blok bulunmaktadır. Dosya çalışırken sistemden API bilgilerini, klasör veritabanlarını veya SSH şifrelerini gizlice emer ve standart bir web HTTP/HTTPs GET ya da POST isteği gibi karşı tarafa sızdırır.

Şifre Hırsızlığının Hayalet Doğası

Hacker cephesi, Python'un tehlikeli __reduce__ kurgusuna sızıp siber bir C4 patlayıcı yerleştirmek yerine içerideki kodlara, işletim sistemindeki bilgileri (os.environ) çağırabilen ve standart urllib.request.urlopen kütüphanesini aktive edecek bir algoritma katar. Bu ufak metruk sızıntı zararlı bir program hissi uyandırmadan milisaniyeler içerisinde bilgisayardaki gizli AWS veya Token bilgilerini alır, URL sorgusuna kopyalar (http://hacker-sistemi.com/log?veri=[SIFRELENMIS_VERILER]) ve sunucuya yollar. Aynı sürede kurban mühendis o sahte "Yapay Zeka Modeli" yavaş da olsa ekrana düştüğü için çalıştığı projede hiçbir aksaklık şüphesi gütmez.

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

Virüs siber uzaydan bilgisayara giriş yaptığı an tek hamleyle verileri kopyalayıp çıkar; asıl sistem yöneticilerin bu sızıntıyı hissetmemesi amaçlanmıştır.

sequenceDiagram
    participant Attacker_C2 as Korsan IP Adresi
    participant File_System as Açık ML Havuzu (Kaggle/HF)
    participant Cloud_VM as Veri Bilimci Cihazı / Bulut Ortamı
    participant OS as Kurbanın İşletim Sistemi

    Attacker_C2->>File_System: İçerisine '.env' çağıran '__reduce__' yapısı konmuş pkl dosyasını yükler
    Cloud_VM->>File_System: Modelin şüphe göstermeyen sürümünü indirir
    Cloud_VM->>OS: Şifre çözerken sistemden "os.environ" klasöründeki şifreleri talep eder
    OS-->>Cloud_VM: AWS/Sunucu vb. API şifrelerini (Saf halleriyle) okuyucuya geri verir
    Cloud_VM->>Cloud_VM: Şifre metinlerini karmaşık Hash formatlarına veya Base64'e çevirir 
    Cloud_VM->>Attacker_C2: Cihaz gizlice masum görünen dış bir Web Bağlantısına bilgi gönderir
    Attacker_C2-->>Attacker_C2: Bütün gün sızdırılan kurumsal şifreler Korsan C2 merkezinde depolanır

Önemli Noktalar

  • Asenkron Şekilde Veri Transferi: Sızıntı mantığı, yazılım süreçlerinden bağımsız siber iplikçikler (Threads vs) üzerinden kopuk çalıştığından hızla görevini bitirir.
  • Devasa Maddi Yıkımlar: Bulut ortam anahtarları (Azure/AWS keys), tokenları ve proje kök şifreleri saldırganın eline geçerse şirketinizin hesaplarına bağlı fahiş ödeme faturası oluşturacak Kripto Madenciliği (Crypto-mining) donanımları dakikalar içerisinde yetkiniz bilgisi dışında kiralanabilir.
  • Zayıf DAST İncelemelerini Yenmesi: Betik içerisindeki dışarı transfer isteği urllib benzeri sömürülmeyen ana sistem eklentileri içerdiğinden sahte telemetri ile masum işlemler arasında kalınır, çoğu eski nesil tarama yazılımı durumu anlamaz.

Etkisi

Zafiyet sonucunda ortam değişkenlerinin hırsızlığa maruz kalması kurumsal regülasyonlar (SOC2, KVKK, ISO27001) açısından büyük darbedir. Yüksek potansiyelli mimari kimlikleri (IAM), veritabanına giriş izni bulunduran yönetici şifreleri yasa dışı olarak kopyalandıktan sonra tehdit gruplarının yasal izlek kontrollerinden rahatlıkla sızması muhtemeldir ve saldırının yıkıcı potansiyeli maksimize olur.

En İyi Çözüm Pratikleri

Modelleri incelediğiniz sanal bilgisayarları (ML workspaces) şifre sömürücü zafiyetlerden ayırmak ve kriz çıkmasına engel olmak için:

  • Çalışma Ortamlarında Anahtar Depolamayın: Olabildiğince tüm işletim sisteminin okuyabileceği kök formatlardaki .env klasörlerinden, AWS statik donanım anahtarlarını barındıran yerel dosyalardan (~/.aws/credentials) feragat edin. Bunların yerine HashiCorp Vault ya da bulut hizmeti geçiş tokeni sağlayan (AWS Secrets Manager vb.) geçici kimliklendirme kullanan sağlam yazılımlara geçiniz.
  • Katı No-Pickle Anlayışı Mimarisi Prensibi: pickle tabanlı formlardan radikal biçimde vazgeçin. Formatlarınız Safetensors olsun zira os ile en ufak bağ dahi kurulamayan sistemlerde sızıntı yapacak bir kanal kalmayacaktır.
  • Geçirgen Olmayan Katı DNS Sistem Ayarı (Zero-Trust Rules): Makine öğrenimi çalıştırılan donanımlardaki izinsiz link veya domain yönlendirmelerine karşı sert ağ sınırları oluşturun; Python'un iletişim kurabileceği veri adresleri sınırlı olsun.

İyileştirme (Remediation)

Ağa takılan PAIT-PKL-103 şüphe dosyası, hızlı reaksiyonlar geliştirmeniz için direktif taşımaktadır.

  1. Problemli MLOps makinesindeki (Inference Container vs.) operasyonları aniden durdurun, Eresus Sentinel arayüzünde modelin girmeye yeltendiği domain yapısına göz atın.
  2. Derhal ağa dahil bu ünitede kayıtlı hangi yetki/token veya şifre kombinasyonu varsa o ortamların hesap ayar sayfalarından panik butonlarıyla tüm izinlerini (AWS, Database, AI hesap anahtarları vb.) KAPATIN ve hepsinin yenilerini yaratıp kodlayın.
  3. Sunucu ve veritabanı (CloudTrail türü) geçmiş loglarınızı geriye sararak şüpheli, sizinkinden ayrı, o kod yetkileri üzerinden girilmiş olağandışı hareket verilerine dikkatlice bakın.
  4. Kaynak zehirli veriyi bir daha ortamınıza koymamak üzere tüm kaynaklarıyla güvenilir ve sertifikalı Safetensors eşlenikleriyle güncelleyin.

İleri Okumalar ve Kaynaklar (Further Reading)

Modern endüstri kriz senaryolarından derlenen şifre zehirlemeleri vakalarını inceleyin:


📥 Eresus Sentinel MLOps İşlemlerini Çevre Hırsızlıklarından Sessizce Kurtarır! Operasyonel güvenliğinizi tehlikeye atacak bir siber krizi baştan söküp alın! Eresus Sentinel, yükleme süreçlerinden hemen önce pickle modellerindeki derleşik sömürü bloklarını algılar. Modüle sokulmaya çalışılan ortam verilerinize os.environ türü eklentilerle bulaşan ağ şebekelerini devre dışı bırakır. Sızıntılara izin vermeyin, şirketin bütün AI donanımını güvende tutun.

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.

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?

İlgili Araştırmalar