MFA ve gelişmiş güvenliği kapalı AWS Cognito user pool'ları kimlik sınırlarını açık bırakıyor

Sınırı çizen varsayılanlar

dev.to'da yayımlanan teknik bir analiz, AWS Cognito hakkında odaklı bir argüman ortaya koyuyor: bir uygulamanın kimlik sınırının gerçekten bulunduğu yer user pool'dur. Müşterileri doğrular, uygulamanın güvendiği JWT'leri üretir ve sosyal kimlik sağlayıcıları üzerinden oturum açmayı aracılık eder. Bir ekibin güvenlik için yaptığı diğer her şey — bekleyen durumda şifreleme, ağ izolasyonu, denetim günlükleri — ancak pool, bir oturuma API'yi çağırma izni verdikten sonra anlam taşır.

Analize göre sorun şu: konsoldan veya aws cognito-idp create-user-pool komutuyla oluşturulan bir user pool, iki güvenlik özelliği kapalı olarak hayata başlar: MfaConfiguration ve UserPoolAddOns.AdvancedSecurityMode varsayılan olarak OFF durumundadır. Yazar, bu ayarların sonra değiştirilebilecek küçük onay kutuları gibi göründüğünü ve bu hâlde sıklıkla üretime ulaştıklarını belirtiyor.

Yalnızca parolalı oturum açma ne davet eder

MFA kapalıyken parolanın tamamı tek doğrulama faktörüdür. Analiz, bunun sonucunda kolaylaşan üç saldırı kalıbını sıralıyor. Credential stuffing, veri ihlali dökümlerinden elde edilen e-posta ve parola çiftlerini oturum açma uç noktasında tekrar oynatır; başarılı tahminler meşru oturumlardan ayırt edilemeyen oturumlar üretir. Password spraying yaklaşımı tersine çevirir: bilinen çok sayıda kullanıcı adı üzerinde tek bir zayıf parola denenir ve Cognito'nun kullanıcı başına kilitlemesi yalnızca tek bir hesaba karşı tekrarlanan başarısız denemelerden sonra devreye girdiği için, her hesabı yalnızca bir kez hedefleyen bir spray hiçbir zaman eşiği tetiklemez. Phishing ile ele geçirilen bir parola ise saldırganın doğrudan oturum açması için gereken her şeydir.

dev.to yazısına göre bu girişimleri yakalayacak katman gelişmiş güvenliktir. Etkinleştirildiğinde her oturum açma üzerinde bir risk modeli çalıştırır — alışılmadık konum, imkânsız seyahat, dış kaynaklardan ele geçirildiği bilinen kimlik bilgileri — ve kullanıcıya ek doğrulama isteyerek, girişimi engelleyerek veya bir bildirim göndererek yanıt verebilir. Bu ayrıca ücretli bir özelliktir ve yazar, sık sık kapalı kalmasının tam da bu yoldan olduğunu savunur: AWS'in servise gömdüğü risk motoru, birçok operatörün göze almadığı ek bir maliyet yüzünden kullanılmaz kalır.

HackerOne'daki hesap ele geçirme zinciri

Analiz, somut bir örnek olarak bomma raporu diye bahsettiği bir HackerOne bildirimine işaret ediyor. O zincir iki pool ayarına dayanıyordu: e-posta kullanıcı adı takma adı olarak kullanılıyordu ve e-posta değişiklikleri doğrulanmıyordu. Ayrı bir açık aracılığıyla — örneğin profil güncelleme uç noktasındaki parametre kirliliği — kurbanın e-posta adresini değiştirebilen bir saldırgan, standart parolamı-unuttum akışını tetikleyip kimlik bilgisini sıfırlayabilir ve hesabı ele geçirebilir.

Yazara göre MFA bu zinciri kırardı. O etkin olsaydı saldırganın kurbanın ikinci faktörüne de ihtiyacı olurdu. Gelişmiş güvenlik açık olsaydı, parola sıfırlamasının ardından gelen alışılmadık konumdaki oturum açma ek bir doğrulama tetiklerdi. İkisi de kapalıyken sıfırlamayı tamamlamak, hesap ele geçirmeyi tamamlar.

Tespit ve düzeltme

Yazar gereksinimi bir değişmez olarak çerçeveliyor: müşteriye dönük Cognito user pool'ları MFA'yı zorunlu kılmalıdır; ikinci faktörleri zaten üstteki kimlik sağlayıcısının yönettiği dahili pool'lar için bir istisna tanınır. Bunu denetlenebilir kılmak için yazı, bir policy control örneği gösteriyor — Stave adlı araçta CTL.COGNITO.MFA.001, yüksek önem derecesi — MFA'nın zorunlu kılınmadığı her user pool'u işaretler; ayrıca her iki anahtar da açıldığında bildirilen ihlalin nasıl temizlendiğini gösteren bir öncesi-sonrası örneği yer alır.

Düzeltmenin kendisi kısadır. İşi iki CLI çağrısı yapar: --mfa-configuration ON ve software-token MFA etkin biçimde set-user-pool-mfa-config, ile --user-pool-add-ons AdvancedSecurityMode=ENFORCED parametresiyle update-user-pool. Analiz, aynı ayarların Terraform'a kodlanmasını öneriyor — mfa_configuration ON yapılacak, bir software-token bloğu eklenecek ve advanced_security_mode ENFORCED yapılacak — böylece yapılandırma, pool'un yeniden oluşturulmasından sonra da korunur.

Mod seçimi konusunda yazar, yalnızca risk modelinin ne yapacağını kaydeden AUDIT ile gerçekten ek doğrulama isteyen veya engelleyen ENFORCED'ı ayırır. Bir ekip motorunun neleri yakalayacağını gözlemlerken AUDIT yeni bir dağıtım için makul olabilir; kararlı durum ENFORCED olmalıdır.

Neden önemli

Kimlik ön kapıdır: çalışan bir parola sunan herkese geçerli token'lar veren bir pool'u telafi edecek miktarda aşağı akış sertleştirme yoktur. Anlatılan saldırılar egzotik hiçbir şey gerektirmiyor — ihlal verisi, zayıf parola spray'i veya bir profil güncelleme hatası — ve varsayılanlar onları kutudan çıktığı gibi uygulanabilir kılıyor. Buna karşılık düzeltme iki API çağrısı artı bir altyapı-kodu düzenlemesinden ibaret; analiz de MFA'yı bu yanlış yapılandırma kümesinde en az çabayla en fazla etkiyi yaratan değişiklik olarak öne çıkarıyor.