OAuth ve Mesaj Mesajı | surajdisoja.me

Tl;dr: Bir OAuth yanlış yapılandırması keşfedildi redirect_uri https://app.target.com/oauth/authorize adresindeki hedefin OAuth IDP’sinde bulunan parametre, saldırganların ../ karakterler. Bu sorun, farklı bir alt alanda postMessage’in yanlış yapılandırılmasıyla zincirlendi. https://xyz.target.com/something/somepage.htmlKullanıcıların kimliğini doğrulamak için aynı IDP’yi kullanan. Bu güvenlik açıkları zinciri, erişim belirteci sızıntısına ve hesabın ele geçirilmesine yol açtı.

Özet

Bir bulgu hakkında en son yazdığımdan bu yana epey zaman geçti. Bu blog yazısında, OAuth yanlış yapılandırmasını (evet, hala varlar!) postMessage yanlış yapılandırmasıyla zincirleyebildiğim bir güvenlik açığını paylaşmak istiyorum. Bu, sonuçta, kurbanın kötü amaçlı bir bağlantıya tıklaması durumunda oturum açma jetonlarını çalmamı sağladı. Gizlilik adına, savunmasız orijinal URL’lerde değişiklikler yaptım.

Hataları test ederken genellikle tek bir uygulamanın derinliklerine inerim. Bu yaklaşım, bunun gibi bulgulara yol açabilecek hedefin işlevlerini anlamamı sağlıyor. Bu yazının okuyucularının OAuth’a aşina olduğunu varsayıyorum. Değilse, önce bu makaleyi incelemenizi şiddetle tavsiye ederim.

OAuth yanlış yapılandırması

OAuth yanlış yapılandırmaları genellikle bir OAuth istemcisinin özellikleri güvenli olmayan şekilde yapılandırıldığında meydana gelir ve bu da erişim belirteci sızıntısı gibi sonuçlara yol açabilir. Test ettiğim hedefin şu tarihte bir OAuth IDP’sine sahip olduğunu varsayalım: https://app.target.com/oauth/authorize

İle uğraşmak redirect_uri parametresi OAuth zayıflıklarından yararlanmanın en yaygın yollarından biridir. Saldırgan, yönlendirme_uri parametresinde kötü amaçlı bir URL sağlayarak kullanıcının erişim belirteci veya OAuth koduyla bu URL’ye yönlendirilmesine neden olabilir.

Ancak bu tür bir güvenlik açığı günümüzde oldukça nadir hale geldi. URL’mi sağlamanız yeterli redirect_uri parametresi burada çalışmadı ve sunucu beklendiği gibi bir hata verdi. Biraz araştırma yaptıktan sonra, yönlendirme_uri parametresindeki geri çağırma bitiş noktasının yolunu kullanarak değiştirmenin mümkün olduğunu keşfettim. ../. Örneğin, şunu tıklarsak:

https://app.target.com/oauth/authorize?client_id=APP&redirect_uri=https://app.target.com/callback/../anything&response_type=token

şuraya yönlendirileceğiz:

https://app.target.com/anything#access_token=[ACCESS_TOKEN_FOR_APP]

Amaçlanan yerine /callback son nokta!

Ancak, açık bir yeniden yönlendirme sorunu bulup kurbanın erişim belirtecini dışarı çıkarmak için bu dizin geçişini zincirlemediğimiz sürece bu keşif işe yaramazdı. Açık bir yönlendirme aramak için biraz zaman harcadım ama bulamadım. Daha fazla zaman geçirdikten sonra yaklaşımımı değiştirmeye karar verdim.

Farklı Bir Yaklaşım

Test ettiğim hedef, kaynaklar, öğrenme merkezleri, bloglar vb. gibi birden fazla alt alana ve özelliğe sahip orta ölçekli bir kurumsal yazılım şirketiydi. Bu alanları, kapsam dışında oldukları için herhangi bir hatayı aktif olarak test etmeden keşfetmeye başladım.

Belirli bir alt alan adı olan xyz.target.com, yetkilendirme sunucusunu kullanan bir oturum açma işlemine sahipti. https://app.target.com/oauth/authorizeKullanıcı kimlik doğrulaması için ana uygulamaya benzer. OAuth isteği şuna benziyordu:

https://app.target.com/oauth/authorize?client_id=XYZ&redirect_uri=https://xyz.target.com/callback&response_type=code&state=%2F

Kullanıcı şu adreste oturum açtıysa: https://app.target.comsunucu onları şuraya yönlendirecektir:

https://xyz.target.com/callback?code=[oauth_code_for_xyz]&state=%2F

Bu daha sonra Konum başlığı değerinin durum parametresiyle eşleştiği bir 302 yönlendirmesini tetikler; %2F (/’ye eşdeğer). Bu da OAuth akışı sonrasında yolu kontrol edebildiğimizi gösteriyor.

Xyz.target.com’daki alt alan adı, kullanıcıların kurslarını tamamlayabilecekleri ve sertifika için sınavlara girebilecekleri bir öğrenme merkeziydi. Gezinirken arka planda bir HTML dosyasının istendiğini fark ettim: https://xyz.target.com/something/somepage.html aşağıdaki içerikle:

Bunu görür görmez, hesap devralma güvenlik açığımın olduğunu anladım. Fark etmediyseniz, yukarıdaki kod parçacığı postMessage’ın yanlış yapılandırılmasına karşı savunmasızdır. PostMessage yanlış yapılandırması, tarayıcı hassas verileri farklı kaynaklara gönderdiğinde meydana gelir. window.postmessage() javascript işlevi. Bu yanlış yapılandırmalar hakkında daha fazla bilgiyi burada bulabilirsiniz.

Bu özel kod, window.location.hash özelliğini, herhangi bir kökene bakılmaksızın, 10. satırdaki ana penceresine aktarın . Ayrıca sayfada şu da eksikti: X-çerçeve-Seçenekler

herhangi bir Origin’in onu iframe’lere yüklemesine izin veren başlık.Artık bir dizin geçişi, sınırlı bir yeniden yönlendirme ve mesaj sonrası yanlış yapılandırmaya sahip olduğumuza göre, kurbanın https://app.target.com erişim belirtecini çalmak için bu sorunları zincirleyebiliriz.

! Devam etmeden önce öncelikle bu üç sorundan nasıl yararlanabileceğimizi ve erişim jetonunu nasıl sızdırabileceğimizi düşünmenizi istiyorum.

İşte sorunlardan yararlanmak için PoC’m:

https://app.target.com/oauth/authorize?client_id=APP&response_type=token&redirect_uri=https://app.target.com/callback/../oauth/authorize?response_type=code%26client_id=XYZ%26redirect_uri=https%3A%2F%2Fxyz.target.com%2Fcallback%26scope=full%26state=%2fsomething%2fsomepage.html&scope=full&response_type=token

Yukarıdaki POC kodu şunu işaret eden bir Iframe oluşturur:

Kullanıcı app.target.com’da oturum açarsa aşağıdakiler gerçekleşir: –

https://app.target.com/callback/../oauth/authorize?response_type=code&client_id=XYZ&redirect_uri=https://xyz.target.com/callback&state=/something/somepage.html#access_token=[ACCESS_TOKEN_FOR_APP]`

Kötü amaçlı olarak barındırılan sayfamızı ziyaret ettikten sonra sunucu, erişim belirteci karmada olacak şekilde aşağıdaki URL’ye bir 302 atacaktır. Yeniden yönlendirme sayısına bakılmaksızın karma her zaman istemci tarafında korunur. /callback/../oauth/authorize/Yeniden yönlendirmenin yoluna dikkat edin:

https://app.target.com/oauth/authorize?client_id=XYZ&redirect_uri=https://xyz.target.com/callback&response_type=code&state=/something/somepage.html#access_token=[ACCESS_TOKEN_FOR_APP]

. Bu dizin geçişi, xyz.target.com alanı için OAuth akışını, aşağıdaki 302 yönlendirmeleriyle birlikte karmadaki uygulamaya yönelik erişim belirteciyle başlatır:

https://xyz.target.com/callback?code=[oauth_code_for_xyz]&state=/something/somepage.html#access_token=[ACCESS_TOKEN_FOR_APP]

Jetonumuz hala karmadayken kullanıcı şuraya yönlendirilir:

Durum parametresinin değerine dikkat edin.

https://xyz.target.com/something/somepage.html#access_token=[ACCESS_TOKEN_FOR_APP]

Bu geri çağırma uç noktası, kullanıcının xyz.target.com adresinde kimliğini doğrulayacak ve ardından onları mesaj sonrası yanlış yapılandırmaya açık sayfaya yönlendirecektir. window.postmessage()

işlev daha sonra kendi karması içindeki erişim_tokenini ana pencereye (iframe’i barındıran kötü amaçlı sayfamız) gönderir. Tamamından beri app.target.com

Bir kullanıcının kimliğini doğrulamak için çalınan bu erişim belirtecine güvenen bir saldırgan, bu sorunlardan yararlanarak kurbanın hesabını ele geçirebilir. Bu sorun, hassas postMessage yanlış yapılandırmasına sahip HTML sayfasının kaldırılması ve aynı zamanda engellenmesi yoluyla bildirildi ve çözüldü. ../ içindeki karakterler yönlendirme_uri

parametre.

• Zaman çizelgesi:

• 5-Ağu-2021: Sorun keşfedildi ve bildirildi 13-Ağu-2021: Önem düzeyi düşürüldü yüksek ile orta

• çünkü mesaj sonrası yanlış yapılandırma bir OOS alt etki alanındaydı.

• geri bildirim

8 Ekim 2021: Sorun çözüldü ve kapatıldı. Okuduğunuz için teşekkürler! Bize ulaşmaktan çekinmeyin heyecan