Railway çalışanının AI agent’ı rakip platformun secret’larını istedi

Railway olayı, ekimde yaklaşık 100.000 hesabı etkilemiş olabilecek bir ihlal açıklayan Railway’in bu kez bir çalışanının rakip platforma izinsiz erişim denemesiyle gündeme geldi. Primcloud kurucusu Josh Manders’a göre çalışan, uygulamasının container’ından aldığı credential’larla platformdaki bütün secret’ları istedi, metadata endpoint’ine gitti, iç veritabanı adlarını tahmin etti ve 65.536 iç adresi taradı. Erişilen veri olmadı; Railway, aracın bir AI agent olduğunu ve 15 dakika içinde durdurulduğunu söylüyor.

Railway nedir?

Railway, uygulama, veritabanı ve arka plan servislerini sunucu yönetmeden deploy etmeye yarayan bir bulut platformudur. Geliştiriciler kodu bir repo’dan bağlayıp ortam değişkenleri ve servisleri tek bir panelden yönetir. Küçük ekipler ve yan projeler arasında yaygındır. Benzer platformlar arasında Heroku, Render ve Fly.io sayılabilir.

Railway olayı neden sizi ilgilendiriyor

Bir PaaS veya iç geliştirici platformu işletiyorsanız bu saldırı zinciri tanıdık gelecek. Müşteri container’ından credential alındı. Bu credential’la platformun secret API’sine gidildi, sonra metadata endpoint’i ve iç ağ yoklandı.

Manders’a göre hiçbir şeye erişilmedi, yani istekler bir yerde durdu. Fakat tek bir müşteri hesabının bütün platformun secret’larını isteyebilmesi, tasarımda kapatılacak bir kapı.

15 dakikada yapılan keşif

Railway kurucusu Jake Cooper, aracın bir kez çalıştırıldığını ve 15 dakika içinde kapatıldığını söylüyor. Bu süre, Manders’ın saydığı adımların hepsine yetti: secret isteği, metadata endpoint’i, veritabanı adı tahmini ve 65.536 adreslik tarama.

Tespit kuralınız saatlik özetle çalışıyorsa, böyle bir oturum bittiğinde alarm henüz üretilmemiş olur. Agent’ın gürültülü çalışması işinize yarar. Tek bir tenant’tan gelen çok sayıda farklı secret adı isteği veya kısa sürede binlerce iç bağlantı denemesi, log’larda kolay ayrılan bir desen.

Tenant container’ındaki credential’ları daraltın

İlk soru şu: müşteri container’ına koyduğunuz token neye erişebiliyor? Cevap yalnızca o tenant’ın kaynakları olmalı. Kubernetes üzerinde çalışıyorsanız pod’a bağlanan service account’un yetkisini ve ağ kurallarını kontrol edin:

kubectl auth can-i --list --as=system:serviceaccount:<namespace>:<serviceaccount>
kubectl get networkpolicy -A

İlk çıktı başka bir namespace’e veya secret’a yetki gösteriyorsa önce onu kapatın. İkinci çıktı boşsa pod’larınız cluster içinde istediği adrese gidebiliyor.

Öncelik sırasıyla yapılacaklar:

• Secret API’sinde her isteği çağıranın tenant’ına göre yetkilendirin; isim tahminiyle başka tenant’ın secret’ına ulaşılamasın.
• Workload’ların metadata endpoint’ine erişimini egress kuralıyla engelleyin. Çoğu bulut sağlayıcısında bu adres 169.254.169.254.
• Tenant’tan platformun iç servislerine ve başka tenant’lara giden trafiği varsayılan olarak kapatın.
• Secret API’sine rate limiting (hız sınırlama) koyun, reddedilen istek sayısına alarm bağlayın.

Agent, Cooper’ın anlatımına göre hosted bir Deepseek servisinde çalıştı. Agent döngüsünde araç çıktıları modele geri gider. Container’dan çekilen credential da bu yoldan üçüncü bir tarafa geçmiş olabilir. Bu tür bir olayın hedefi olduysanız, sızan credential’ı rotate edin.

Kendi agent’larınızın kapsamı

Railway olayı, agent çalıştıran taraf için de ders içeriyor. Kıdemli ürün mühendisi Jake Runzer, rakip platformlarda kayıt ve “agentic testing” yapan agent’lar çalıştırdığını söylüyor. Agent görevin dışına çıktı ve hedef platformun iç ağına uzandı.

Cooper bunu mesai dışında yazılmış kişisel bir bug bounty aracı olarak tanımlıyor. Railway yine de “appropriate action” aldığını açıkladı. İzinsiz erişim Atlantik’in iki yakasında da suç; agent’ın gönderdiği her istek onu çalıştıranın hesabından çıkıyor.

Agent’a ağ erişimi veriyorsanız sınırları ağ katmanında çizin:

• Gidebileceği host’ları allowlist ile belirleyin.
• Sandbox’ında iç IP aralıklarını ve metadata adresini engelleyin.
• Kendi hesabınızın dışındaki bir kaynağa dokunan ilk çağrıda oturumu durduran bir kill switch kurun.

Cooper, şirket içi red team çalışmasının “strict guidelines” ile yürüdüğünü söylüyor. Bu olayda araç o kuralların dışında, rakip bir platformda koştu. Red team kapsamınızı yazılı kuralla tanımlıyorsanız, aynı kapsamı agent’ın çalıştığı ortamın egress kurallarına da işleyin.