OAuth to Account takeover

Reading time: 15 minutes

Basic Information

OAuth, çeşitli versiyonlar sunar ve temel bilgiler OAuth 2.0 belgeleri adresinde mevcuttur. Bu tartışma, yaygın olarak kullanılan OAuth 2.0 yetkilendirme kodu hibe türü etrafında dönmektedir 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 paylaşımlarınızı, özel olanlar da dahil, sergilemek için tasarlanmıştır. Bunu başarmak için OAuth 2.0 kullanılmaktadır. https://example.com, sosyal medya paylaşımlarınıza erişim izni talep edecektir. Sonuç olarak, https://socialmedia.com üzerinde, talep edilen izinler ve talebi yapan geliştirici hakkında bilgi veren bir onay ekranı belirecektir. Onayınızla, https://example.com, paylaşımlarınıza sizin adınıza erişim sağlama yetkisi kazanır.

OAuth 2.0 çerçevesi içindeki aşağıdaki bileşenleri anlamak önemlidir:

• resource owner: Siz, kullanıcı/varlık olarak, sosyal medya hesabı paylaşımlarınız gibi kaynaklarınıza erişim izni verirsiniz.
• resource server: Uygulama, access token alarak resource owner adına kimlik doğrulama taleplerini 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 sonra client application'a access 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'ın resource 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 ve sonrasında verileri korumak için bir parametre. Benzersizliği, CSRF koruma mekanizması olarak hizmet vermesi açısından 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ından access_token almak için client_id ve client_secret ile birlikte kullanılır.
• access_token: resource owner adına API talepleri için client application tarafından kullanılan 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:

1. https://example.com adresine gidersiniz ve “Sosyal Medya ile Entegre Ol” butonunu seçersiniz.
2. Site, https://example.com uygulamasının paylaşımlarınıza erişim izni talep etmek için https://socialmedia.com adresine bir istek gönderir. İstek şu şekilde yapılandırılmıştır:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Ardından bir onay sayfası ile karşılaşırsınız.
4. Onayınızın ardından, Sosyal Medya redirect_uri'ye code ve state parametreleri ile bir yanıt gönderir:

https://example.com?code=uniqueCode123&state=randomString123

5. https://example.com bu code'u, client_id ve client_secret ile birlikte kullanarak, sizin adınıza bir access_token almak için sunucu tarafında bir istek yapar ve onayladığınız izinlere erişim sağlar:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. Son olarak, süreç https://example.com access_token'ınızı kullanarak Sosyal Medya'ya API çağrısı yaparak sona erer.

Güvenlik Açıkları

Açık redirect_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 olanağı tanır.

Sömürü teknikleri, yetkilendirme sunucusunun doğrulama mantığına bağlı olarak değişir. Katı yol eşleşmesinden, 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 çalmak 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, kullanıcı kimlik doğruladıktan sonra sunucunun yanıtında yansıtılması mümkün olabilir ve bu durum XSS'ye karşı savunmasızdır. Test etmek için olası yük:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

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 kullanılmaması, statik bir değer olarak kullanılması veya kullanıcı oturumu ile doğru bir şekilde doğrulanmaması veya ilişkilendirilmemesi durumunda ortaya çıkar ve saldırganların CSRF korumalarını aşmasına olanak tanır.

Saldırganlar, yetkilendirme sürecini keserek kendi hesaplarını bir mağdurun hesabıyla ilişkilendirmek için bunu istismar edebilir, bu da bir kullanıcının saldırgana ait neredeyse tamamlanmış bir oauth akışıyla giriş yapmasını sağlayarak 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 hackleme platformlarında belgelenmiştir ve pratik etkilerini vurgulamaktadır. Sorun, saldırganların bildirimleri veya ödemeleri kendi hesaplarına yönlendirebileceği Slack, Stripe ve PayPal gibi üçüncü taraf hizmetlerle entegrasyonlara da uzanmaktadır.

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

1. 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.
2. Gevşek OAuth E-posta Doğrulamasını İstismar Etme: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini istismar edebilir; kendi hizmetleriyle kaydolup ardından hesap e-posta adresini mağdurunki ile değiştirebilirler. 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 istismar ederek kullanıcı access_tokens ve özel bilgileri çalabilirler.

Uygulamaların yetkilendirme code'unu access_token ile istemci tarafında değil, sunucu tarafında yanlışlıkla ele alması 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 istismar edebilirler.

Client Secret Bruteforce

Bir hizmet sağlayıcının client_secret'ını çalmak için kimlik sağlayıcı ile bruteforce yapmayı deneyebilirsiniz.
BF isteği şu şekilde görünebilir:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

Referer Header sızdıran Kod + State

Müşteri kod ve state'e sahip olduğunda, eğer bu Referer header içinde yansıyorsa ve farklı bir sayfaya gittiğinde, o zaman bu açık bir durumdadır.

Tarayıcı Geçmişinde Saklanan Erişim Token'ı

Tarayıcı geçmişine gidin ve erişim token'ının orada kaydedilip kaydedilmediğini kontrol edin.

Sürekli Yetkilendirme Kodu

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.

Yetkilendirme/Yenileme Token'ı istemciye bağlı değil

Eğer yetkilendirme kodunu alabilir ve bunu farklı bir istemci ile kullanabilirseniz, diğer hesapları ele geçirebilirsiniz.

Mutlu Yollar, XSS, Iframe'ler ve Kod & State değerlerini sızdırmak için Post Mesajları

Bu gönderiyi kontrol edin

AWS Cognito

Bu hata ödül raporunda: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ AWS Cognito'nun kullanıcıya geri verdiği 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.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

Daha ayrıntılı bilgi için AWS cognito'yu nasıl kötüye kullanacağınızı kontrol edin:

AWS - Cognito Unauthenticated Enum - HackTricks Cloud

Diğer Uygulama token'larını Kötüye Kullanma

bu yazıda bahsedildiği gibi, token (ve kod değil) almayı bekleyen OAuth akışları, token'ın uygulamaya ait olduğunu kontrol etmedikleri takdirde savunmasız olabilir.

Bu, bir saldırganın kendi uygulamasında OAuth destekleyen ve Facebook ile giriş yapan bir uygulama oluşturabileceği anlamına gelir. Daha sonra, 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.

İki Bağlantı & Çerez

bu yazıya göre, bir kurbanın saldırganın ana bilgisayarına işaret eden bir returnUrl ile bir sayfa açmasını sağlamak mümkündü. Bu bilgi bir çerezde (RU) saklanacak ve sonraki adımda istem kullanıcının 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 ayarlamak için Oauth akışını başlatmak üzere bir sekme açmak, istem gösterilmeden önce sekmeyi kapatmak ve bu değeri içermeyen yeni bir sekme açmak mümkündü. Böylece, istem saldırganın ana bilgisayarından bahsetmeyecek, ancak çerez ona ayarlanacak, bu nedenle token saldırganın ana bilgisayarına yönlendirme sırasında gönderilecektir.

İstem Etkileşimi Atlatma

bu videoda açıklandığı gibi, bazı OAuth uygulamaları, kullanıcıların platformda zaten oturum açmışlarsa webde verilen erişimi onaylamak için bir istemde sorulmasını önlemek amacıyla prompt GET parametresini None (&prompt=none) olarak belirtmeye izin verir.

response_mode

bu videoda açıklandığı gibi, kodun son URL'de nerede sağlanacağını 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ça 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ğer
• response_mode=web_message -> Kod bir post mesajında gönderilir: window.opener.postMessage({"code": "asdasdasd...

OAuth ROPC akışı - 2 FA atlatma

bu blog yazısına göre, bu, OAuth üzerinden kullanıcı adı ve şifre ile giriş yapmayı sağlayan bir OAuth akışıdır. Bu basit akış sırasında, kullanıcının gerçekleştirebileceği tüm eylemlere erişim sağlayan bir token dönerse, bu token kullanılarak 2FA atlatılabilir.

Açık yönlendirme temelinde yönlendirme ile ATO

Bu blog yazısı, bir açık yönlendirmeyi referans değerinden yararlanarak OAuth'u ATO için nasıl kötüye kullanabileceğini yorumlamaktadır. Saldırı şu şekildedir:

1. Kurban saldırganın web sayfasına erişir.
2. Kurban kötü niyetli bağlantıyı açar ve bir açıcı, saldırganın web sitesi referansını kullanarak response_type=id_token,code&prompt=none ek parametreleri ile Google OAuth akışını başlatır.
3. Açıcı, sağlayıcı kurbanı yetkilendirdikten sonra, onları redirect_uri parametresinin değerine (kurban webi) 30X kodu ile geri gönderir ve bu hala saldırganın web sitesini referans olarak tutar.
4. Kurban web sitesi, referansa dayalı açık yönlendirmeyi tetikler ve kurban kullanıcıyı saldırganın web sitesine yönlendirir, çünkü respose_type id_token,code olduğundan, kod saldırgana URL'nin parçasında geri gönderilecektir ve bu da onun kurbanın hesabını Google üzerinden ele geçirmesine olanak tanır.

SSRF'lerin parametreleri

Bu araştırmayı kontrol edin Bu tekniğin daha fazla ayrıntısı için.

OAuth'taki Dinamik İstemci Kaydı, güvenlik açıkları için daha az belirgin ama kritik bir vektör olarak Sunucu Tarafı İstek Sahteciliği (SSRF) saldırılarına hizmet eder. Bu uç nokta, OAuth sunucularının istemci uygulamaları hakkında ayrıntılar almasına olanak tanır; bu, kötüye kullanılabilecek hassas URL'leri içerir.

Ana Noktalar:

• Dinamik İstemci Kaydı, genellikle /register ile eşleştirilir ve client_name, client_secret, redirect_uris ve POST istekleri aracılığıyla logolar veya JSON Web Key Sets (JWK'ler) için URL'ler gibi ayrıntıları kabul eder.
• Bu özellik, RFC7591 ve OpenID Connect Registration 1.0'da belirtilen spesifikasyonlara uyar; bu, SSRF'ye karşı potansiyel olarak savunmasız parametreleri içerir.
• Kayıt süreci, birkaç şekilde sunucuları SSRF'ye maruz bırakabilir:
• logo_uri: Sunucu tarafından alınabilecek istemci uygulamasının logosu için bir URL; bu, 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ği redirect_uris JSON dizisini referans alır ve bu, SSRF fırsatı yaratır.
• request_uris: İstemci için izin verilen istek URI'lerini listeler; bu, sunucu bu URI'leri yetkilendirme sürecinin başında alırsa kötüye kullanılabilir.

Kötüye Kullanım Stratejisi:

• SSRF, logo_uri, jwks_uri veya sector_identifier_uri gibi parametrelerde kötü niyetli URL'ler ile yeni bir istemci kaydederek tetiklenebilir.
• request_uris aracılığıyla doğrudan kötüye kullanım, beyaz liste kontrolleri ile azaltılabilirken, önceden kaydedilmiş, saldırgan kontrolündeki bir request_uri sağlamak, yetkilendirme aşamasında SSRF'yi kolaylaştırabilir.

OAuth sağlayıcıları Yarış Koşulları

Test ettiğiniz platform bir OAuth sağlayıcısıysa Olası Yarış Koşullarını test etmek için bunu okuyun.

Değiştirilebilir İddialar Saldırısı

OAuth'ta, sub alanı bir kullanıcıyı benzersiz olarak tanımlar, ancak formatı Yetkilendirme Sunucusuna göre değişir. Kullanıcı tanımlamasını standart hale getirmek için bazı istemciler e-posta veya kullanıcı tanıtıcıları kullanır. Ancak bu risklidir çünkü:

• Bazı Yetkilendirme Sunucuları, bu özelliklerin (örneğin e-posta) değişmez kalmasını sağlamaz.
• Bazı uygulamalarda—"Microsoft ile Giriş" gibi—istemci, e-posta alanına dayanır; bu alan Entra ID'de kullanıcı tarafından kontrol edilir ve doğrulanmaz.
• Bir saldırgan, kendi Azure AD organizasyonunu (örneğin, doyensectestorg) oluşturarak bunu Microsoft girişi yapmak için kullanabilir.
• Sub'da saklanan Nesne Kimliği (Object ID) değişmez ve güvenli olsa da, değiştirilebilir bir e-posta alanına bağımlılık, bir hesap ele geçirmeyi mümkün kılabilir (örneğin, victim@gmail.com gibi bir hesabı ele geçirmek).

İstemci Karışıklığı Saldırısı

Bir İstemci Karışıklığı Saldırısı'nda, OAuth İkili Akışını kullanan bir uygulama, nihai erişim token'ının özel olarak kendi İstemci Kimliği için oluşturulduğunu doğrulamakta başarısız olur. Bir saldırgan, Google’ın OAuth İkili Akışını kullanan bir kamu web sitesi kurar, binlerce kullanıcıyı oturum açmaya kandırarak saldırganın sitesine yönelik erişim token'larını toplar. Bu kullanıcıların, token'ın İstemci Kimliği'ni doğrulamayan başka bir savunmasız web sitesinde de hesapları varsa, saldırgan toplanan token'ları kullanarak kurbanları taklit edebilir ve hesaplarını ele geçirebilir.

Kapsam Yükseltme Saldırısı

Yetkilendirme Kodu Verme türü, kullanıcı verilerini iletmek için güvenli sunucu-sunucu iletişimini içerir. Ancak, eğer Yetkilendirme Sunucusu, Erişim Token'ı İsteği'ndeki bir kapsam parametresine dolaylı olarak güveniyorsa (RFC'de tanımlanmayan bir parametre), kötü niyetli bir uygulama, daha yüksek bir kapsam talep ederek bir yetkilendirme kodunun ayrıcalıklarını yükseltebilir. Erişim Token'ı oluşturulduktan sonra, Kaynak Sunucusu bunu doğrulamalıdır: JWT token'ları için, bu JWT imzasını kontrol etmeyi ve client_id ve scope gibi verileri çıkarmayı içerir; rastgele dize token'ları için, sunucu, token'ın ayrıntılarını almak için Yetkilendirme Sunucusu'na sorgu yapmalıdır.

Yönlendirme Şeması Kaçırma

Mobil OAuth uygulamalarında, uygulamalar özel URI şemaları kullanarak Yetkilendirme Kodları ile yönlendirmeleri alır. Ancak, bir cihazda birden fazla uygulama aynı şemayı kaydedebileceğinden, yalnızca meşru istemcinin yönlendirme URI'sini kontrol ettiği varsayımı ihlal edilir. Örneğin Android'de, com.example.app:// gibi bir Intent URI, şemaya ve bir uygulamanın intent-filter'ında tanımlanan isteğe bağlı filtrelere göre yakalanır. Android'in intent çözümlemesi geniş olabileceğinden—özellikle yalnızca şema belirtilmişse—bir saldırgan, yetkilendirme kodunu kaçırmak için dikkatlice hazırlanmış bir intent filtresi ile kötü niyetli bir uygulama kaydedebilir. Bu, kullanıcı etkileşimi yoluyla (birden fazla uygulama intent'i işlemek için uygun olduğunda) veya aşırı belirgin filtreleri kötüye kullanan atlatma teknikleri aracılığıyla bir hesap ele geçirmeyi mümkün kılabilir.

Referanslar

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors
• https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html