Railway ihlali: uygulamanın secret'larını kesinti olmadan nasıl yenilersin

21 Ekim'de Railway, yetkisiz bir tarafın müşteri ortam değişkenlerini saklayan sistemlere eriştiğini ve bunların bir kısmının şifresi çözülmüş içeriğini ele geçirmiş olabileceğini açıkladı. Railway tüm deploy'ları durdurdu, key'lerin iptal edilmesi için upstream sağlayıcıları bilgilendirdi ve tüm kullanıcılarından, özel registry kimlik bilgileri dahil, ortam değişkenlerini yenilemelerini istedi.

Ön raporu daha fazla ayrıntı veriyor:

TechCrunch'ın haberine göre Railway, bunun yapay zekâ inference sağlayıcılarını ele geçirmeyi amaçlayan ve platformlara yönelik daha geniş bir kampanyanın parçası olduğunu düşünüyor. Aynı hafta yapay zekâ kodlama aracı OpenCode da hackerların müşterilerinin %1'inden fazlasına ait API key'lerini ve diğer secret'ları ele geçirdiğini açıkladı.

Çalınan yapay zekâ key'leri gerçek para ediyor. Saldırganlar erişimi yeniden satıyor ya da senin kotanı kendi iş yükleri için tüketiyor; araştırmacılar bu örüntüye LLMjacking diyor. Bir hosting platformu bu key'leri toplamak için verimli bir yer, çünkü binlerce uygulama OpenAI, Anthropic, Stripe ve veritabanı key'lerini tek bir yerde tutuyor.

Railway'in raporunda rahatsız edici bir ayrıntı var. Değişkenler şifreliydi, ama platformun onları build'lerine ve çalışan servislerine enjekte edebilmesi için şifrelerini çözebilmesi gerekiyor. Saldırgan doğru iç erişimi elde ettiğinde, bekleyen veri şifrelemesi onu durdurmadı. Bu Railway'e özgü değil. Kodunu çalıştıran her host secret'larını okuyabilir.

Yani asıl soru "host'um güvenli mi?" değil. Asıl soru şu: "Host'umun secret'ları yarın sızsa durum ne kadar kötü olur ve ne kadar hızlı toparlanabilirim?"

Birkaç şey için "yenile"ye zaten tıkladıysan bile buna 20 dakika ayır.

1. Her secret'ın envanterini çıkar. Staging ve preview ortamları dahil, her proje ve ortamdaki değişken adlarını listele. Bir .env.example dosyan varsa iyi bir başlangıç noktası:

Her biri için neyin kilidini açtığını not et: bir veritabanı, bir ödeme sağlayıcı, bir yapay zekâ sağlayıcı, e-posta, bir storage bucket, bir GitHub token'ı.

2. Yapay zekâ sağlayıcı kullanımını ve faturalarını kontrol et. 20 Ekim'den bu yana kullanım sıçramalarına, tanımadığın modellere veya garip saatlerdeki isteklere bak. Kötüye kullanımın ilk ortaya çıkacağı yer büyük ihtimalle burası.

3. Elindeki audit log'larını kontrol et. Railway özellikle GitHub audit log'larını ve yüklü uygulama erişimlerini, ayrıca Docker Hub gibi registry log'larını incelemeyi öneriyor. Ödeme sağlayıcının API log'larına ve veritabanının bağlantı log'larına da bak.

4. Veritabanına internetten erişilip erişilemediğini kontrol et. Railway'in raporu veritabanlarına genel ağ erişiminin kaldırılmasını öneriyor. Sızan bir bağlantı dizesi herkesin bağlanabildiği bir veritabanını gösteriyorsa, sızıntı anında kullanılabilir:

5. Frontend'inin zaten neleri ele verdiğini kontrol et. Bu tür ihlaller, gerçek secret'ları tasarım gereği herkese açık olan değerlerden ayırmanın önemini hatırlatıyor. JavaScript bundle'ında gönderilen bir key zaten hiçbir zaman gizli değildi.

İnsanların baskı altında yaptığı hata, önce eski key'i iptal etmek, sonra uygulama hata döndürürken yenisini deploy etmeye çabalamak. Bunun yerine şu sırayla ilerle:

Listende etki alanı en büyük olandan başlayarak ilerle: ödeme key'leri, veritabanı kimlik bilgileri, bulut ve storage key'leri, yapay zekâ sağlayıcı key'leri, GitHub ve registry token'ları, sonra geri kalan her şey. Railway'in kendi rehberi 21 Ekim'den önce ayarlanmış değişkenlere odaklanıyor; sonraki tavsiyeleri ise GitHub bağlantısını yeniden kurmayı ve CLI ile CI kimlik bilgilerini yeniden oluşturmayı da ekliyor.

Bazı secret'lar ekstra özen istiyor:

Host'unun ihlal edilmesini engelleyemezsin. Ama sızan bir secret'ın değerini düşürebilirsin.

Key'lerin kapsamını dar tut. Sağlayıcılar sunuyorsa kısıtlı key'ler kullan. Yalnızca checkout oturumu oluşturabilen bir Stripe restricted key, tam yetkili bir secret key'e göre saldırgan için çok daha az işe yarar.

Harcamaya sınır koy. Her yapay zekâ sağlayıcısında aylık bütçe ve kullanım uyarıları ayarla. Böylece beş haneli sürpriz bir fatura, bir e-postaya dönüşür.

Ortamları ayır. Production key'lerini staging veya preview deploy'larında yeniden kullanma. Her ortamın kendi kimlik bilgileri olmalı ki birindeki sızıntı diğerini de teslim etmesin.

Veritabanlarını gizli tut. Platformunun özel ağını kullan; Supabase kullanıyorsan Row Level Security'nin açık olduğundan emin ol ki sızan bir anon key tablolarını açığa çıkarmasın.

Secret'ları asla erişilebilir dosyalarda tutma. Web kök dizinine deploy edilmiş bir .env dosyası, hiçbir ihlale gerek kalmadan sızar.

Yenileme runbook'unu şimdi yaz: 1. adımdaki liste, yukarıdaki sıra ve her key'in nerede yönetildiği. Bir dahaki sefere yenileme bir hafta sonu yerine bir saat sürer.

Deploy ettiğin her uygulama için bunun üzerinden geç:

Railway hızlıca açıklama yapıp yenilemeyi zorlayarak doğru olanı yaptı. Ama bu, hosting ve geliştirici platformlarının başına gelmeye devam ediyor, çünkü key'ler orada. Bunu sakin atlatan geliştiriciler, hangi secret'lara sahip olduğunu bilen ve hepsini bir öğleden sonrada değiştirebilenler.

Temizlik yaparken uygulamanın dışarıdan neleri açığa çıkardığını kontrol etmeye de değer. AppSafe canlı siteni JavaScript bundle'larındaki API key'leri, açıkta kalan .env ve .git dosyaları ve eksik güvenlik header'ları gibi yaygın sorunlar için tarar ve anlaşılır düzeltmeler sunar. Yapay zekâ ile geliştirilen uygulamalar için hazırladığımız yayın kontrol listesi diğer temel konuları kapsıyor.

Her şeyi yeniledikten sonra, başka hiçbir şeyin sızmadığından emin olmak için ücretsiz bir AppSafe taraması çalıştır.