İmzasız token, admin yetkisi: 16 yaşındaki araştırmacı Microsoft'un iç servisine nasıl girdi?

Ne oldu?

Faav takma adlı 16 yaşındaki bir güvenlik araştırmacısı, Microsoft’un çalışanlara özel analiz servisi Titan’da bir giriş açığı buldu. Kendi yazdığı, Codex ve Claude üzerinde çalışan bir hata avı botu (Antares) servisi 25 Ağustos’ta işaretledi. Faav 5 Eylül’de SQL çalıştırmayı başardı ve aynı gün Microsoft’un güvenlik ekibine (MSRC) bildirdi. Açık 9 Eylül’de kapatıldı, 17 Eylül’de 5.000 dolar ödül geldi.

Kapılar nasıl tek tek açıldı?

Titan’ın web arayüzü sadece Microsoft VPN’iyle açılıyordu. Ama API’si internetten erişilebilir bir sunucudaydı. Herkese açık API belgesinde dört rota vardı, biri /v2/Query: doğrudan SQL kabul ediyordu. Sorgu için bir tablo adı gerekiyordu. Faav, Wayback Machine’deki 2023 tarihli kopyalardan eski bir yapılandırma dosyasını buldu. İçinde 56 tablo tanımı vardı, bunlardan 30’u hâlâ çalışıyordu.

Geriye giriş kaldı. Titan, token’ın hangi kuruma (tenant), hangi servise (audience) ve hangi uygulamaya ait olduğunu kontrol ediyordu. İmzayı ise hiç kontrol etmiyordu. Faav’ın yazısına göre algoritması none olan, imza kısmı boş bir token bütün kontrollerden geçti. E-posta biçimli kullanıcı adları “kullanıcı bulunamadı” hatası verdi. admin yazınca servis bunu 1 numaralı yerel kullanıcıyla eşleştirdi. O kullanıcı yöneticiydi ve SQL çalıştı.

Faav’ın hesabına göre 17 veritabanına erişim vardı, içlerinde Bing’in analiz verisi de bulunuyordu. Meta veriden çıkan toplam satır tahmini yaklaşık 17,3 trilyon. Bu bir depolama tahmini: Kopyalar, eski ve türetilmiş veriler de içinde. Faav müşteri verisine dokunmadığını, sadece kapsamı doğrulamak için iki adet tek satırlık örnek aldığını söylüyor.

JWT nedir, imza neden her şey?

JWT (JSON Web Token), noktalarla ayrılmış üç parçadan oluşur: başlık.içerik.imza. Başlık hangi algoritmanın kullanıldığını (alg) söyler. İçerikte “iddialar” (claims) vardır: kim olduğun, hangi servis için olduğu, ne zaman sona erdiği. İlk iki parça şifreli değil, sadece kodlanmış. Herkes okuyup değiştirebilir.

Token’ın sahte olmadığını kanıtlayan tek şey imza. GitHub App anahtarları yazısında gördüğün gibi, imzayı sadece özel anahtarı olan atabilir. İmzaya bakmayan bir sunucu için aud ya da tid kontrolü, bir kimlik kartının üzerindeki adı okuyup kartın sahte olup olmadığına hiç bakmamak gibi. Saldırgan o alanlara istediğini yazar.

alg: none ise standartta (RFC 7519) gerçekten var: “Bu token imzasız” demek. Bütünlüğün başka bir yolla sağlandığı nadir durumlar için düşünülmüş. Sorun, sunucunun token’a “hangi algoritmayla doğrulayayım?” diye sormasında. RFC 8725 bu yüzden algoritmanın token’dan değil, sunucunun ayarından gelmesini istiyor.

Tek hata değil, bir zincir

Bu açık tek bir hatadan değil, üst üste binen boşluklardan çıktı:

• Arayüz VPN arkasındaydı ama API değildi.
• Bir rota ham SQL kabul ediyordu.
• Eski yapılandırma internet arşivinde duruyordu.
• admin gibi tahmin edilebilir bir yerel kullanıcı tam yetkiliydi.

Bunlardan biri bile kapalı olsaydı, saldırı orada durabilirdi. Buna derinlemesine savunma (defense in depth) deniyor.

Kontrol listesi

• JWT kütüphanende kabul edilen algoritmaları açıkça yaz (örneğin sadece RS256). Token’ın alg alanına güvenme.
• none algoritmasını reddet, kütüphanenin bunu varsayılan olarak yaptığını test et.
• Önce imzayı doğrula, sonra aud, iss, exp gibi alanlara bak.
• Bir arayüzü ağla koruyorsan, arkasındaki API’yi de koru.
• Dışarıdan ham SQL alan rota açma. Gerekiyorsa sadece okuma yetkili, dar kapsamlı bir veritabanı kullanıcısı kullan.
• Kimlik doğrulamadan bağımsız, sabit isimli “admin” hesapları bırakma.
• Kendi servisine imzasız bir token göndererek test et. Reddetmiyorsa sorun var.

Düşün

• Senin API’n bir token’ı kabul etmeden önce tam olarak neleri kontrol ediyor? İmza bunların ilki mi?
• “Zaten VPN arkasında” dediğin bir sistemin dışarıdan erişilebilen bir parçası var mı?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.