Bulut sunucuları, kendilerine atanmış geçici kimlik bilgilerini ve yapılandırma verilerini 169.254.169.254 adresindeki meta veri servisinden okur. IMDSv2, bu servise erişmek için önce bir PUT isteğiyle kısa ömürlü oturum jetonu almayı ve sonraki her sorguda bu jetonu başlığa eklemeyi zorunlu kılan ikinci nesil erişim modelidir. Amaç basittir: bir uygulamanın yanıltılarak meta veri adresine istek atmasıyla sunucunun IAM rolü anahtarlarının dışarı sızmasını engellemek.

IMDSv2, meta veri erişimini tek yönlü bir PUT-jeton el sıkışmasına bağlayarak, uygulamanın kandırılıp yaptığı sıradan bir GET isteğinin kimlik bilgisi çalamamasını sağlar.

Sorun Nereden Çıkıyor?

İlk nesil serviste (IMDSv1) tek bir GET isteği anahtarları döndürüyordu. Bir web uygulamasında sunucu taraflı istek sahteciliği açığı bulan saldırgan, uygulamayı meta veri adresine istek atmaya zorlayabiliyor ve dönen yanıttaki rol anahtarlarını kendi makinesine taşıyabiliyordu. 2019’daki büyük bir bulut ihlali tam olarak bu zincirle, yanlış yapılandırılmış bir güvenlik duvarı üzerinden meta veri servisine ulaşılarak gerçekleşti. Bu tür meta veri servisi saldırıları, bulut ortamlarında en çok gözlenen ilk erişim yöntemlerinden biri haline geldi.

Oturum Jetonu Neyi Değiştirir?

IMDSv2 iki tasarım kararıyla saldırı zincirini kırar. Birincisi, jeton yalnızca PUT metoduyla alınır; çoğu SSRF açığı ise saldırgana sadece GET tetikleme imkânı verdiğinden zincir daha ilk adımda tıkanır. İkincisi, jeton alma isteğinde IP-TTL değeri 1’e ayarlanabilir; böylece bir yönlendiriciden geçmesi gereken vekil veya konteyner ağı üzerinden yapılan istekler paket düşürülerek reddedilir. Bu iki kısıt, klasik cloud metadata SSRF istismarı denemelerinin ezici çoğunluğunu işlevsiz bırakır.

Geçiş ve Zorunlu Kılma

Koruma yalnızca IMDSv2 mevcut olduğunda değil, IMDSv1 kapatıldığında tam anlam kazanır. Sunucular her iki sürümü de kabul ettiği sürece saldırgan basitçe eski uç noktayı kullanmayı seçer. Bu yüzden geçiş, uygulamaların jeton tabanlı çağrıya uyum sağlaması ve ardından örnek meta veri seçeneklerinde eski sürümün tümüyle devre dışı bırakılmasıyla tamamlanır.

• Örnek başlatma yapılandırmasında meta veri jeton zorunluluğunu ‘required’ olarak ayarlayın.
• Uygulama SDK’larını jeton alan güncel sürümlere yükseltin ve eski sabit çağrıları temizleyin.
• Hop limitini iş yükü mimarisine göre ayarlayın; konteyner çalıştıran düğümlerde ek sıçrama gerekebilir.
• IMDSv1 kullanımını izleyin ve sıfırlandığından emin olduktan sonra eski sürümü kapatın.

Jeton zorunluluğu tek başına her riski kapatmaz. Konteyner ortamlarında pod’ların düğüm meta verisine hiç erişememesi için ağ katmanında 169.254.169.254 adresine giden trafiğin engellenmesi, IMDSv2 ile birlikte uygulanması gereken tamamlayıcı bir önlemdir.

Kurumsal Yaklaşım

Meta veri korumasının doğru kurulması, tek bir sunucu ayarından çok bulut hesabının genel mimarisiyle ilgilidir: hangi iş yüklerinin hangi rolleri taşıdığı, ağ yollarının nereye açık olduğu ve eski sürümün tüm filoda gerçekten kapandığı topluca doğrulanmalıdır. Privia Security ekibi, bu doğrulamayı bir altyapı ve mimari gözden geçirme çalışmasıyla ele alır ve meta veri erişiminin uçtan uca güvenli olduğunu kanıtlar.