AI/ML Araçlarında Bug Hunting Rehberi

AI/ML Bug Hunting Aslında Tanıdık Bir Saha

AI ve ML araçları yeni görünür; fakat bu araçlardaki birçok güvenlik açığı klasik web, API, code review ve exploit development becerileriyle bulunur. MLOps panelleri, inference server'ları, model registry'leri ve veri işleme arayüzleri çoğu zaman HTTP API, dosya sistemi erişimi, upload akışı ve background job mimarisinden oluşur.

Bu nedenle AI/ML bug hunting için ilk soru "model hallucination yapıyor mu?" değildir. Daha temel soru şudur: Bu araç dosyaları nereden okuyor, nereye yazıyor, hangi URL'leri fetch ediyor, hangi komutları çalıştırıyor ve kimlik kontrolünü nerede yapıyor?

Gerekli Beceri Alanları

Web ve API Güvenliği

ML araçlarının önemli bir kısmı web UI veya REST API sunar. MLflow, Airflow, H2O benzeri araçlarda klasik web güvenliği becerileri doğrudan işe yarar. Authentication eksikliği, authorization bypass, path traversal, SSRF, upload zafiyeti ve XSS hâlâ geçerlidir.

Code Review

AI/ML araçları hızlı geliştiği için kod içinde güvenli olmayan pattern'ler sık görülebilir. subprocess, os.system, eval, exec, pickle.load, yaml.load, shell=True, kontrolsüz path join ve URL fetch fonksiyonları özellikle incelenmelidir.

Exploit Development

Model formatları ve native parser'lar C/C++ sınırına yaklaştığında bellek güvenliği riskleri doğar. GGUF, ONNX runtime extension veya özel model parser'ları fuzzing için güçlü hedeflerdir. Bu alan daha fazla zaman ister ama etki seviyesi yüksektir.

En Kritik Üç Zafiyet Sınıfı

1. Aşırı Dosya Sistemi Erişimi

ML araçları model, dataset, artifact ve checkpoint dosyalarıyla çalışır. Kolaylık için kullanıcıya geniş path seçme imkânı verildiğinde local file include, arbitrary file read veya arbitrary file overwrite riski doğar.

Örnek riskli parametreler:

• path
• artifact_path
• model_dir
• filename
• output_dir
• checkpoint
• export_path

Saldırgan bu alanlarda .ssh/id_rsa, cloud credential dosyaları veya uygulama config dosyalarını hedefleyebilir. Yazma yetkisi varsa .bashrc, authorized keys, model dosyası veya pipeline config üzerine yazma RCE'ye kadar gidebilir.

2. SSRF

ML araçları remote dataset, S3 bucket, model URL veya webhook fetch etmeyi sever. URL alanı olan her API SSRF adayıdır. İç ağ servisleri, cloud metadata endpoint'leri, admin panelleri ve local-only servisler bu yolla hedeflenebilir.

SSRF testinde yalnızca http:// değil, file://, ftp://, s3://, redirect zinciri, DNS rebinding ve internal host allowlist bypass senaryoları da düşünülmelidir.

3. Remote Code Execution

RCE çoğu zaman iki yerden doğar: kullanıcı girdisinin komuta bağlanması veya model dosyasının güvenilmeyen şekilde yüklenmesi. Pickle tabanlı model yükleme, Keras custom layer, ONNX custom op veya shell çağrısı yapan preprocessing pipeline'ları özellikle risklidir.

Bir web UI, kullanıcıdan model upload alıp sunucuda yükleyebiliyorsa bu akış mutlaka sandbox içinde test edilmelidir.

Pratik Test Akışı

1. Aracı local ortamda ayağa kaldırın.
2. Web UI ve API trafiğini proxy ile yakalayın.
3. Tüm endpoint'leri tek tek haritalayın.
4. Dosya yolu, URL, komut, model ve artifact parametrelerini işaretleyin.
5. Low-privilege ve unauthenticated isteklerle authorization test edin.
6. Path traversal, SSRF ve upload payload'larını kontrollü deneyin.
7. Static code review ile riskli fonksiyonları arayın.
8. Bulguları gerçek etkiyle kanıtlayın.

Neden ML Araçları Daha Hassas?

Geleneksel web uygulamalarında upload edilen dosya genellikle görsel veya PDF olur. ML dünyasında upload edilen dosya modeldir ve model dosyası davranış taşıyabilir. Geleneksel uygulamada path seçimi nadirdir; ML aracında dataset ve artifact path'i temel özelliktir. Geleneksel uygulamada UI remote code execution çağırmaz; ML aracında deney çalıştırma veya pipeline tetikleme normal fonksiyondur.

Bu yüzden klasik güvenlik bilgisi ML bağlamında daha yüksek etki üretir.

Eresus Yaklaşımı

Eresus Security, AI/ML araçlarını yalnızca prompt güvenliğiyle değil, MLOps web yüzeyi, model dosyası güvenliği, artifact erişimi, SSRF, RCE ve supply chain zinciriyle birlikte test eder. Kurum içinde MLflow, Airflow, Kubeflow, model registry veya özel inference paneli çalışıyorsa bu sistemler üretim API'leri kadar ciddi güvenlik kapsamına alınmalıdır.

Sık Sorulan Sorular

Bu konuda ilk adım ne olmalı?

Önce varlık, veri, kimlik ve iş etkisi birlikte haritalanmalıdır. Böylece güvenlik testi araç odaklı değil risk odaklı ilerler.

Profesyonel destek ne zaman gerekir?

Sistem üretime yakınsa, hassas veriye erişiyorsa veya bulgular birden fazla ekibi etkiliyorsa bağımsız güvenlik değerlendirmesi gerekir.

Operasyonel İnceleme Checklisti

• Model veya agent kaynağı doğrulandı mı?
• Tool izinleri minimum yetkiyle mi tanımlandı?
• Retrieval sonucu kullanıcı yetkisine göre filtreleniyor mu?
• Memory kalıcı talimat riskine karşı incelendi mi?
• Model artefact hash veya imza ile takip ediliyor mu?
• Yükleme işlemi sandbox içinde test edildi mi?
• Prompt testi runtime aksiyon testiyle desteklendi mi?
• MCP veya plugin server listesi çıkarıldı mı?
• Agent production API çağırıyorsa onay var mı?
• Veri sızıntısı senaryosu kontrollü denendi mi?
• Kapsam net yazıldı mı?
• Etkilenen varlık sahibi belli mi?
• Test ortamı production etkisinden ayrıldı mı?
• Kullanıcı rolleri doğru temsil ediliyor mu?
• Hassas veri sınıfı tanımlandı mı?
• Yetki sınırı teknik olarak doğrulandı mı?
• Log kaynağı ve saklama süresi belli mi?
• Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
• İş etkisi teknik etkiden ayrı açıklandı mı?
• Düzeltme sahibi belirlendi mi?
• Retest kriteri yazıldı mı?
• Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
• Monitoring veya alert tarafında görünürlük var mı?
• Olay müdahale adımı gerekiyorsa planlandı mı?
• Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışı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?