Acil: LiteLLM Geliştirici Bilgisayarlarını Saldırganlar İçin Hedef Haline Getirdi

Giriş

Son zamanlarda, yazılım geliştirme süreçlerindeki güvenlik açıkları, popüler kütüphanelerdeki tehlikeli saldırılarla yeniden gündeme geldi. LiteLLM kütüphanesi üzerinden gerçekleştirilen bir saldırı, geliştirici makinelerinin ne kadar hayati bir hedef olduğunu gözler önüne serdi.

LiteLLM Saldırısı: Geliştirici Uç Noktalarının Tehdit Altında Olması

Saldırı, uygulama açısından basit, ancak etkisi bakımından yıkıcıydı. TeamPCP,  1.82.7  ve  1.82.8  sürüm numaralarına sahip LiteLLM paketlerini  PyPI  üzerinde ele geçirerek, geliştiricilerin bu paketleri yüklediğinde devreye giren bir bilgi çalıcı zararlı yazılım enjekte etti. Bu zararlı yazılım, geliştirici makinelerinden SSH anahtarları, AWS, Azure ve GCP için bulut kimlik bilgileri, Docker yapılandırmaları ve diğer hassas verileri sistematik olarak topladı.

PyPI, kötü amaçlı paketleri algılandıktan birkaç saat içinde kaldırdı, ancak zarar görme süresi oldukça uzundu. GitGuardian tarafından yapılan analizler, 1,705 PyPI paketinin ele geçirilen LiteLLM sürümlerini bağımlılık olarak otomatik olarak çağıracak şekilde yapılandırıldığını ortaya koydu. dspy (ayda 5 milyon indirme), opik (ayda 3 milyon indirme) ve crawl4ai (ayda 1.4 milyon indirme) gibi popüler paketler, yükleme sırasında zararlı yazılımı tetiklemiş olabilirdi. Bu durum, doğrudan LiteLLM kullanmayan organizasyonların bile dolaylı olarak tehlikeye girmesine yol açtı.

Neden Geliştirici Makineleri Cazip Hedeflerdir?

Bu saldırı modeli yenilikçi değil; yalnızca daha görünür hale gelmiştir.  Shai-Hulud kampanyaları  benzer taktikleri ölçekli bir şekilde göstermiştir. GitGuardian, bu olaydan etkilenen  6,943  geliştirici makinesi üzerinde yaptığı analizde  33,185  benzersiz sırrın ortaya çıktığını, bunlardan en az  3,760 ‘ının hala geçerli olduğunu belirlemiştir. Daha çarpıcı olanı, her bir geçerli sırrın aynı makinede yaklaşık sekiz farklı konumda bulunmasıdır.

Saldırganlar, şimdi bağlı bağımlılıklar, kötü amaçlı eklentiler veya zehirlenmiş güncellemeler üzerinden araç zincirine sızmaktadır. Bu durumda, yerel ortam verilerini toplamak için sistematik bir yaklaşım kullanmaktadırlar; güvenlik ekipleri, güvenlik açıklarını tararken, onlar ise .env dosyalarında, kirli komut geçmişinde, IDE ayarlarında ve diğer yerlerde saklanan kimlik bilgilerini aramaktadır.

Gizli Bilgiler Her Yerde Düz Metin Olarak Bulunuyor

LiteLLM zararlı yazılımının başarısının arkasındaki neden, geliştirici makinelerinin düz metin kimlik bilgileri için yoğunlaşma noktaları olmasıdır. Gizli bilgiler, kaynak ağaçlarına, yerel yapılandırma dosyalarına, hata ayıklama çıktısına ve geçici scriptlere sızmaktadır. .env dosyaları içerisinde birikmekte ve bu, aynı zamanda kod tabanının kalıcı bir parçası haline gelmektedir.

Geliştiriciler, kimlik bilgilerine ihtiyaç duyan araçlar, yerel MCP sunucuları, CLI araçları, IDE uzantıları, inşa hatları ve geri alma iş akışları çalıştırmaktadır. Bu kimlik bilgilerinin bilinen yollar boyunca yayılması zararlı yazılımların arayabileceği yerlerdir: ~/.aws/credentials, ~/.config/gh/config.yml, proje .env dosyaları, shell geçmişi.

Geliştirici Uç Noktalarını Korumak

Her geliştirici uç noktasında kimlik bilgilerin toplandığı sürekli bir koruma oluşturmak önemlidir. GitGuardian, bu durumu kod depolarının ötesinde geliştirici makinelerine uzatarak ele almaktadır. LiteLLM saldırısı, geliştirici uç noktalarında düz metin olarak biriken kimlik bilgileriyle nelerin gerçekleşebileceğini göstermiştir. Bununla birlikte, maruz kalmayı azaltmak için yapılması gerekenler şu şekildedir:

Maruz Kalmanızı Anlayın

Görünürlük ile başlayın. Çalışma istasyonunu gizli bilgilerin taranması için birincil ortam olarak değerlendirin, bir düşünce sonrası değil.  ggshield  kullanarak yerel depoları kod veya Git tarihi içerisinde sızan kimlik bilgileri için tarayın. Kimlik bilgilerinin biriktiği dosya sistemi yollarını da tarayın: proje çalışma alanları, dot dosyaları, inşa çıktıları ve yerel AI araçlarının oluşturduğu günlükler, önbellekler, “bellek” depoları.

Kimlik Bilgilerini Hazinelere Taşıyın

Algılama olmadan tedavi sadece gürültü yapar. Bir kimlik bilgisi sızdığında, tedavi genellikle birden fazla ekip arasında koordinasyon gerektirir. Çözüm, kimlik bilgilerini yönetilen kimlikler olarak tanımlamak ve tedavi süreçlerini otomatikleştirmektir. Kimlik bilgilerini merkezi bir hazine altyapısına taşıyarak güvenlik ekiplerinin dönüşüm zamanlamalarını, erişim politikalarını ve kullanım izlemelerini uygulamasını sağlayın.

AI Araçlarını Kimlik Bilgisi Riski olarak Değerlendirin

Ajanik araçlar dosya okuyabilir, komut çalıştırabilir ve veri taşıyabilir. Açık Ajans tarzı araçlarla, “bellek” disk üzerindeki dosyalardır (SOUL.md, MEMORY.md) ve tahmin edilebilir yerlerde saklanmaktadır. Asla ajan sohbetlerine kimlik bilgisi girmeyin ve asla ajanlara “sonra” kullanılmak üzere gizli bilgiler öğretmeyin.

Kısa Süreli Kimlik Bilgilerini Kullanın

Kimlik bilgilerini henüz ortadan kaldıramıyorsanız, bunları kısa süreli ve otomatik olarak değiştirilen hale getirin.  SPIFFE  kullanarak kriptografik kimlik belgeleri (SVID’ler) çıkararak statik API anahtarları yerine otomatik olarak döngüsel hale gelin.

Sonuç

LiteLLM olayı, geliştirici uç noktalarının kurumsal ağlardaki kritik öneme sahip olduğunu bir kez daha gösterdi. Herhangi bir saldırıda, kimlik bilgileri üzerinden elde edilebilecek değerleri minimize etmek için, derhal güncellemeler yapmalı, gerekirse portları kapatmalı ve sürekli güvenlik taramaları gerçekleştirilmelidir. Geliştirici makinelerini, üretim sistemleriyle aynı yönetim disipliniyle ele alacak kuruluşlar, bir sonraki tedarik zinciri ihlalinde hayatta kalmanın yollarını bulacaktır.