OAuth to Account takeover
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Basic Information
OAuth, OAuth 2.0 belgeleri adresinde erişilebilen temel bilgilerle birlikte çeşitli sürümler sunar. Bu tartışma esas olarak yaygın olarak kullanılan OAuth 2.0 yetkilendirme kodu hibe türü etrafında döner ve bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişmesini veya eylemler gerçekleştirmesini sağlayan bir yetkilendirme çerçevesi sunar (yetkilendirme sunucusu).
Hayali bir web sitesi https://example.com düşünün; bu site tüm sosyal medya gönderilerinizi, özel olanlar da dahil olmak üzere, sergilemek için tasarlanmıştır. Bunu başarmak için OAuth 2.0 kullanılır. https://example.com, sosyal medya gönderilerinize erişim izni talep edecektir. Sonuç olarak, https://socialmedia.com üzerinde talep edilen izinleri ve talebi yapan geliştiriciyi belirten bir onay ekranı belirecektir. Onayınızla, https://example.com, adınıza gönderilerinize erişim sağlama yetkisi kazanır.
OAuth 2.0 çerçevesindeki aşağıdaki bileşenleri anlamak önemlidir:
resource owner: Siz, kullanıcı/varlık olarak, sosyal medya hesabı gönderileriniz gibi kaynağınıza erişim izni verirsiniz.
resource server: Erişim token'ı almış uygulamanın kimlik doğrulama isteklerini yöneten sunucu, örneğin, https://socialmedia.com.
client application:
resource owner
'dan yetkilendirme talep eden uygulama, örneğin, https://example.com.authorization server:
resource owner
'ın başarılı bir şekilde kimlik doğrulamasını yaptıktan sonraclient application
'aaccess tokens
veren sunucu, örneğin, https://socialmedia.com.client_id: Uygulama için kamuya açık, benzersiz bir tanımlayıcı.
client_secret: Sadece uygulama ve yetkilendirme sunucusu tarafından bilinen,
access_tokens
oluşturmak için kullanılan gizli bir anahtar.response_type: Talep edilen token türünü belirten bir değer, örneğin
code
.scope:
client application
'ınresource owner
'dan talep ettiği erişim seviyesi.redirect_uri: Kullanıcının yetkilendirmeden sonra yönlendirileceği URL. Bu genellikle önceden kaydedilmiş yönlendirme URL'si ile uyumlu olmalıdır.
state: Kullanıcının yetkilendirme sunucusuna yönlendirilmesi sırasında verileri korumak için bir parametre. Benzersizliği, CSRF koruma mekanizması olarak hizmet etmesi için kritik öneme sahiptir.
grant_type: Hibe türünü ve döndürülecek token türünü belirten bir parametre.
code:
authorization server
'dan alınan yetkilendirme kodu,client application
tarafındanaccess_token
almak içinclient_id
veclient_secret
ile birlikte kullanılır.access_token:
resource owner
adına API istekleri içinclient application
'ın kullandığı token.refresh_token: Uygulamanın kullanıcıyı yeniden istemeden yeni bir
access_token
almasını sağlar.
Flow
Gerçek OAuth akışı şu şekilde ilerler:
https://example.com adresine gidersiniz ve “Sosyal Medya ile Entegre Ol” butonuna tıklarsınız.
Site, https://example.com uygulamasının gönderilerinize erişim izni talep etmek için https://socialmedia.com adresine bir istek gönderir. İstek şu şekilde yapılandırılmıştır:
Ardından bir onay sayfası ile karşılaşırsınız.
Onayınızı takiben, Sosyal Medya
code
vestate
parametreleri ileredirect_uri
'ye bir yanıt gönderir:
https://example.com bu
code
'u,client_id
veclient_secret
ile birlikte, sizin adınıza biraccess_token
almak için sunucu tarafında bir istek yapmak üzere kullanır ve onayladığınız izinlere erişim sağlar:
Son olarak, süreç https://example.com
access_token
'ınızı kullanarak Sosyal Medya'ya erişmek için bir API çağrısı yapar.
Güvenlik Açıkları
Açık yönlendirme_uri
redirect_uri
, OAuth ve OpenID uygulamalarında güvenlik için kritik öneme sahiptir, çünkü yetkilendirme kodları gibi hassas verilerin yetkilendirme sonrası nereye gönderileceğini yönlendirir. Yanlış yapılandırıldığında, saldırganların bu istekleri kötü niyetli sunuculara yönlendirmesine izin verebilir ve hesap ele geçirme olasılığını artırır.
Sömürü teknikleri, yetkilendirme sunucusunun doğrulama mantığına bağlı olarak değişir. Katı yol eşleştirmeden, belirtilen alan veya alt dizin içindeki herhangi bir URL'yi kabul etmeye kadar değişebilir. Yaygın sömürü yöntemleri arasında açık yönlendirmeler, yol geçişi, zayıf regexlerin istismarı ve token hırsızlığı için HTML enjeksiyonu yer alır.
redirect_uri
dışında, client_uri
, policy_uri
, tos_uri
ve initiate_login_uri
gibi diğer OAuth ve OpenID parametreleri de yönlendirme saldırılarına karşı hassastır. Bu parametreler isteğe bağlıdır ve destekleri sunucular arasında değişiklik gösterir.
OpenID sunucusunu hedef alanlar için, keşif uç noktası (**.well-known/openid-configuration**
) genellikle registration_endpoint
, request_uri_parameter_supported
ve "require_request_uri_registration
" gibi değerli yapılandırma ayrıntılarını listeler. Bu ayrıntılar, kayıt uç noktasını ve sunucunun diğer yapılandırma özelliklerini belirlemede yardımcı olabilir.
Yönlendirme uygulamasında XSS
Bu hata ödülü raporunda belirtildiği gibi https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, yönlendirme URL'sinin sunucunun yanıtında yansıtılması mümkün olabilir, bu da XSS'ye karşı savunmasız hale getirir. Test etmek için olası yük:
CSRF - State parametresinin yanlış yönetimi
OAuth uygulamalarında, state
parametresinin kötüye kullanımı veya atlanması, Cross-Site Request Forgery (CSRF) saldırılarının riskini önemli ölçüde artırabilir. Bu zafiyet, state
parametresinin ya kullanılmaması, statik bir değer olarak kullanılması veya düzgün bir şekilde doğrulanmaması durumunda ortaya çıkar ve saldırganların CSRF korumalarını atlamasına olanak tanır.
Saldırganlar, yetkilendirme sürecini keserek kendi hesaplarını bir mağdurun hesabıyla ilişkilendirebilir, bu da potansiyel hesap ele geçirmelerine yol açar. Bu, OAuth'un kimlik doğrulama amaçları için kullanıldığı uygulamalarda özellikle kritik öneme sahiptir.
Bu zafiyetin gerçek dünya örnekleri, çeşitli CTF yarışmaları ve hacking platformları üzerinde belgelenmiştir ve pratik etkilerini vurgulamaktadır. Sorun, Slack, Stripe ve PayPal gibi üçüncü taraf hizmetlerle entegrasyonlara da uzanmakta, burada saldırganlar bildirimleri veya ödemeleri kendi hesaplarına yönlendirebilir.
state
parametresinin doğru yönetimi ve doğrulanması, CSRF'ye karşı korunmak ve OAuth akışını güvence altına almak için kritik öneme sahiptir.
Hesap Ele Geçirmeden Önce
Hesap Oluşturma sırasında E-posta Doğrulaması Olmadan: Saldırganlar, mağdurun e-posta adresini kullanarak önceden bir hesap oluşturabilir. Eğer mağdur daha sonra bir üçüncü taraf hizmeti ile giriş yaparsa, uygulama bu üçüncü taraf hesabını saldırganın önceden oluşturduğu hesapla yanlışlıkla ilişkilendirebilir ve yetkisiz erişime yol açabilir.
Gevşek OAuth E-posta Doğrulamasını Kötüye Kullanma: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini kötüye kullanarak kendi hizmetleriyle kaydolabilir ve ardından hesap e-posta adresini mağdurunki ile değiştirebilir. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimi riski taşır, ancak farklı bir saldırı vektörü aracılığıyla.
Gizli Bilgilerin Açığa Çıkması
Gizli OAuth parametrelerini tanımlamak ve korumak çok önemlidir. client_id
güvenle ifşa edilebilirken, client_secret
ifşa edilmesi önemli riskler taşır. Eğer client_secret
ele geçirilirse, saldırganlar uygulamanın kimliğini ve güvenini kötüye kullanarak kullanıcı access_tokens
ve özel bilgileri çalabilir.
Uygulamaların yetkilendirme code
'unu access_token
ile istemci tarafında değil, sunucu tarafında yanlışlıkla yönetmesi durumunda yaygın bir zafiyet ortaya çıkar. Bu hata, client_secret
'in açığa çıkmasına yol açar ve saldırganların uygulamanın kimliğini kullanarak access_tokens
oluşturmasına olanak tanır. Ayrıca, sosyal mühendislik yoluyla, saldırganlar OAuth yetkilendirmesine ek kapsamlar ekleyerek ayrıcalıkları artırabilir ve uygulamanın güvenilir durumunu daha da kötüye kullanabilir.
Client Secret Bruteforce
Bir hizmet sağlayıcının client_secret'ini çalmak için kimlik sağlayıcı ile bruteforce yapmayı deneyebilirsiniz. BF isteği şu şekilde görünebilir:
Referer Header leaking Code + State
Müşteri kod ve durum bilgilerine sahip olduğunda, eğer bu bilgiler Referer başlığında yansıtılıyorsa ve farklı bir sayfaya göz atıyorsa, o zaman bu açık durumdadır.
Access Token Stored in Browser History
Tarayıcı geçmişine gidin ve access token'ın orada kaydedilip kaydedilmediğini kontrol edin.
Everlasting Authorization Code
Yetkilendirme kodu, bir saldırganın onu çalabileceği ve kullanabileceği zaman penceresini sınırlamak için sadece bir süre boyunca geçerli olmalıdır.
Authorization/Refresh Token not bound to client
Eğer yetkilendirme kodunu alabilir ve bunu farklı bir istemci ile kullanabilirseniz, diğer hesapları ele geçirebilirsiniz.
Happy Paths, XSS, Iframes & Post Messages to leak code & state values
AWS Cognito
Bu hata ödül raporunda: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ AWS Cognito tarafından kullanıcıya geri verilen token'ın, kullanıcı verilerini üzerine yazmak için yeterli izinlere sahip olabileceğini görebilirsiniz. Bu nedenle, eğer bir kullanıcı e-posta adresini farklı bir kullanıcı e-posta adresi ile değiştirebilirseniz, diğer hesapları ele geçirebilirsiniz.
For more detailed info about how to abuse AWS cognito check:
Abusing other Apps tokens
As mentioned in this writeup, OAuth akışları token (ve kod değil) almayı bekliyorsa, token'ın uygulamaya ait olduğunu kontrol etmedikleri takdirde savunmasız olabilirler.
Bu, bir saldırganın kendi uygulamasında OAuth destekleyen ve Facebook ile giriş yapan bir uygulama oluşturabileceği anlamına gelir. Ardından, bir kurban saldırganın uygulamasında Facebook ile giriş yaptığında, saldırgan kullanıcının uygulamasına verilen OAuth token'ını alabilir ve bunu kurbanın OAuth uygulamasında kurbanın kullanıcı token'ı ile giriş yapmak için kullanabilir.
Bu nedenle, saldırgan kendi OAuth uygulamasına kullanıcı erişimini elde ederse, token bekleyen ve token'ın kendi uygulama kimliğine verilip verilmediğini kontrol etmeyen uygulamalarda kurbanın hesabını ele geçirebilir.
Two links & cookie
According to this writeup, bir kurbanın saldırganın ana bilgisayarına işaret eden bir returnUrl ile bir sayfa açması sağlanabiliyordu. Bu bilgi bir çerezde (RU) saklanacak ve sonraki adımda istem kullanıcıya o saldırganın ana bilgisayarına erişim vermek isteyip istemediğini soracaktır.
Bu istemi atlatmak için, returnUrl kullanarak bu RU çerezini ayarlayacak bir Oauth akışını başlatmak için bir sekme açmak, istem gösterilmeden önce sekmeyi kapatmak ve o değeri içermeyen yeni bir sekme açmak mümkündü. Böylece, istem saldırganın ana bilgisayarı hakkında bilgi vermeyecek, ancak çerez ona ayarlanacak, bu nedenle token saldırganın ana bilgisayarına yönlendirme sırasında gönderilecektir.
Prompt Interaction Bypass
As explained in this video, bazı OAuth uygulamaları, kullanıcıların platformda zaten oturum açmışlarsa webde verilen erişimi onaylamaları için prompt
GET parametresini None (&prompt=none
) olarak belirtmelerine izin verir.
response_mode
As explained in this video, kodun son URL'de nerede sağlanmasını istediğinizi belirtmek için response_mode
parametresini belirtmek mümkün olabilir:
response_mode=query
-> Kod bir GET parametresi içinde sağlanır:?code=2397rf3gu93f
response_mode=fragment
-> Kod URL parçası parametresi içinde sağlanır#code=2397rf3gu93f
response_mode=form_post
-> Kod,code
adında bir girdi ile bir POST formu içinde sağlanır ve değerresponse_mode=web_message
-> Kod bir post mesajında gönderilir:window.opener.postMessage({"code": "asdasdasd...
SSRFs parameters
Check this research For further details of this technique.
OAuth'taki Dinamik İstemci Kaydı, güvenlik açıkları için daha az belirgin ama kritik bir vektör olarak hizmet eder, özellikle Sunucu Tarafı İstek Sahteciliği (SSRF) saldırıları için. Bu uç nokta, OAuth sunucularının istemci uygulamaları hakkında, istismar edilebilecek hassas URL'ler de dahil olmak üzere, ayrıntılar almasına olanak tanır.
Ana Noktalar:
Dinamik İstemci Kaydı genellikle
/register
ile eşleştirilir veclient_name
,client_secret
,redirect_uris
ve logo veya JSON Web Key Sets (JWK'ler) için URL'ler gibi ayrıntıları POST istekleri aracılığıyla kabul eder.Bu özellik, RFC7591 ve OpenID Connect Registration 1.0'da belirtilen spesifikasyonlara uyar ve SSRF'ye karşı potansiyel olarak savunmasız olabilecek parametreleri içerir.
Kayıt süreci, istemcileri birkaç şekilde SSRF'ye maruz bırakabilir:
logo_uri
: Sunucu tarafından alınabilecek istemci uygulamasının logosu için bir URL, SSRF'yi tetikleyebilir veya URL yanlış yönetilirse XSS'ye yol açabilir.jwks_uri
: İstemcinin JWK belgesine giden bir URL, kötü niyetle oluşturulursa, sunucunun saldırgan kontrolündeki bir sunucuya dışa dönük istekler yapmasına neden olabilir.sector_identifier_uri
: Sunucunun alabileceğiredirect_uris
JSON dizisini referans alır, bu da SSRF fırsatı yaratır.request_uris
: İstemci için izin verilen istek URI'lerini listeler, bu URI'ler yetkilendirme sürecinin başlangıcında sunucu tarafından alınırsa istismar edilebilir.
İstismar Stratejisi:
SSRF,
logo_uri
,jwks_uri
veyasector_identifier_uri
gibi parametrelerde kötü niyetli URL'lerle yeni bir istemci kaydederek tetiklenebilir.request_uris
aracılığıyla doğrudan istismar, beyaz liste kontrolleri ile azaltılabilirken, önceden kaydedilmiş, saldırgan kontrolündeki birrequest_uri
sağlamak, yetkilendirme aşamasında SSRF'yi kolaylaştırabilir.
OAuth providers Race Conditions
If the platform you are testing is an OAuth provider read this to test for possible Race Conditions.
References
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Last updated