deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Ekim ayındaki dört API anahtarı sızıntısı: ele geçirilen bir LiteLLM sürümünden Railway ihlaline

Geliştiricilerin API anahtarları tek bir ayda dört farklı yoldan sızdı; bunlardan biri ele geçirilmiş bir LiteLLM gateway sürümüydü. Bir dev.to analizi ise yerel bir gizli bilgi maskeleme aracının neleri engelleyip neleri engelleyemeyeceğini test etti.

Ekim ayındaki dört API anahtarı sızıntısı: ele geçirilen bir LiteLLM sürümünden Railway ihlaline

Bir ayda anahtarların sızdığı dört yol

Bir API anahtarı aynı zamanda harcama yetkisi de veren bir kimlik bilgisidir: Anahtarın bir kopyasına sahip olan kişi, sahip iptal edene kadar hesabı kullanabilir ve masrafları oluşturabilir. 28 Ekim'de dev.to'da yayımlanan bir analize göre geliştiricilerin anahtarları tek bir ayda dört ayrı kanaldan sızdı.

En elaborate olanı, yaygın kullanılan açık kaynak bir AI gateway'i olan LiteLLM'nin 1.107.0 sürümünü içeriyordu. Yazıya göre saldırgan, herkese açık bir depoya commit edilmiş ve hiç iptal edilmemiş bir agent config dosyasındaki master key ile başladı. Bu anahtar, bir GitHub token'ı döndüren LiteLLM agent API'sine karşı kullanıldı; token depo gizli bilgilerini çekti ve CI üzerinden bir webhook'a gönderdi, ardından bir release workflow'u benzer görünümlü bir fork'a yönlendirildi. Yayımlanan wheel'lerin, yazıya göre, her Python başlangıcında uzaktan kod çalıştırdığı ve bir stealer bileşeninin diskleri, tarayıcıları ve cloud metadata'yı okuyup şifreli bir arşivi dışarı sızdırdığı belirtiliyor.

Ayrı olarak, bir Tensorlake npm paketinin 0.5.144 sürümü, geliştiricilerin anahtarlarını kopyalayan, bunları diğer paketlerine yaymak için kullanan ve depolara agent yapılandırma dosyaları yerleştiren kod taşıyordu. Yazar, payload'ın büyük ölçüde encode edilmiş olduğunu, bu yüzden hakkında bilinenlerin düz metin dizelerinden geldiğini belirtiyor.

Üçüncü olarak, bir cloud hosting sağlayıcısı olan Railway, build altyapısında bir privilege escalation yaşadı; şifrelenmiş değişkenler çekildi ve bir kısmı çözüldü; AI sağlayıcı anahtar adları arandı — gönderinin ön rapor olarak nitelediği bir bulgu. Dördüncü olarak, OpenCode'un barındırılan Console'ı arkasındaki eski bir sisteme erişildi ve kullanıcıların oraya kaydettiği sağlayıcı anahtarları açığa çıktı; ancak yazar, OpenCode'tan birinci elden bir açıklama bulamadı, yalnızca kullanıcıların issue bildirimlerini gördü.

Yerel bir savunma yardımcı olur muydu?

Yazının diğer yarısı, gizli bilgileri maskeleyen yerel bir agent hook'u olan Cloakroom'un bunlardan herhangi birini değiştirip değiştiremeyeceğini soruyor. Karar kesin: Hayır. Yazar, her olayın her adımını araçla karşılaştırdı ve gerçekleşen her hırsızlık adımının diski, bir sunucuyu veya CI'ı doğrudan okuduğunu; bunların tümünün yerel bir hook'un gözlemleyebileceğinin ötesinde olduğunu gördü.

Aracın etkileyebileceği şey ise yukarı akıştaki kopyalardır: bir agent üzerinden commit edilen bir anahtar veya araç çıktısı yoluyla model bağlamına ve gateway loglarına geçen bir token. Hatta LiteLLM commit adımı bile o commit'in nasıl yapıldığına bağlı — yazıya göre LiteLLM bunu hiç netleştirmemişti. İki stealer da agent oturum transkriptlerini okumadı, yani gizli bilgileri transkriptlerden uzak tutmak bu hırsızlıkları da değiştirmezdi — ikisi de agent kimlik bilgilerini doğrudan diskten aldı.

Kontrollü bir benchmark

Neleri engellediğini nicel olarak göstermek için yazar, stealers'ın tipik olarak baktığı yerlere on bir sahte gizli bilgi yerleştirilmiş bir depo kurdu: .env dosyaları, bir gateway yapılandırması, bir MCP config'i, npm, AWS ve SSH dosyaları ile bir GitHub CLI token'ı yazdıran bir betik. Ardından Claude Code aynı görevi iki kez çalıştırdı: bir kez sade haldeyle, bir kez Cloakroom 0.8.0 ile; sonrasında modelin girdisi, oturum transkripti ve git geçmişi tam değerler için tarandı.

Cloakroom olmadan on bir gizli bilginin tamamı modelin girdisine ve transkripte ulaştı; biri — gateway anahtarı — git geçmişine girdi. Araçla birlikte üçündeki sayı sıfırdı. Cloakroom, betiğin tam çıktısını tuttu böylece token modele hiç ulaşmadı ve gateway anahtarının bir kurulum dosyasına yazılma girişimini reddetti; bunun üzerine agent yerine bir placeholder koydu. Yazar sınırlar hakkında açık sözlü: placeholder'lar bir agent'ın yazdığı dosyalarda gerçek değerlere geri dönüştürülüyor, transkriptler yazılanları kaydediyor ve sonuç tek bir makine, tek bir model ve tek bir prompt'tan geliyor; yine de çalıştırma betiği başkalarının tekrarlamabilmesi için yayımlandı.

Yanında ne yayımlandı

Yazıya göre Cloakroom 0.8.0 ile iki özellik 27 Ekim'de PyPI'de yayımlandı. Biri, bir agent'ın hangi gizli bilgileri gördüğünü raporluyor; diğeri bir deponun agent ve editör yapılandırmalarını — .claude/settings.json hook'ları, .mcp.json ve .vscode/tasks.json dahil — eklenen veya değiştirilen komutlar için tarıyor ve checkout ile merge sonrası çalışan bir git hook'una bağlı. İkisi de raporluyor; hiçbiri engellemiyor.

Neden önemli

Ekim ayındaki olaylar, saldırganların doğrudan AI geliştirme araç zincirini hedeflediğini gösteriyor: kurduğunuz gateway, bağımlı olduğunuz npm paketi, deponuzdaki agent yapılandırması ve barındırılan konsollara emanet edilen sağlayıcı anahtarları. Kimlik bilgileri artık tek bir .env dosyasından çok daha fazla yerde yaşıyor ve her kopya bir hedef.

Cloakroom deneyi ayrıca istemci tarafı maskelemenin dürüst sınırını çiziyor: model bağlamındaki, transkriptlerdeki ve loglardaki kopyaları küçültüyor ama diskleri, sunucuları veya CI'ı göremiyor. Bu da tek bir kontrole güvenmek yerine katmanlı savunmaları — rotation ve iptal, kısa ömürlü kimlik bilgileri, depolarda ve CI'da gizli bilgi taraması — destekliyor. Ve kendi aracının incelediği olayları durduramayacağı sonucuna varan kamuya açık bir yazı, başlı başına nadir ve faydalı bir veri noktası.

  • #security
  • #api-keys
  • #supply-chain
  • #ai-agents
  • #secrets-management

İlgili yazılar