hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth ile Hesap Ele Geçirme

AWS hackleme konusunda sıfırdan kahramana kadar öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı)!

HackTricks'ı desteklemenin diğer yolları:

• Şirketinizi HackTricks'te reklamını görmek istiyorsanız veya HackTricks'i PDF olarak indirmek istiyorsanız ABONELİK PLANLARI'na göz atın!
• Resmi PEASS & HackTricks ürünlerini edinin
• PEASS Ailesi'ni keşfedin, özel NFT'lerimiz koleksiyonumuz
• 💬 Discord grubumuza katılın veya telegram grubumuza katılın veya bizi Twitter'da 🐦 @carlospolopm** takip edin.**
• Hacking püf noktalarınızı paylaşarak PR'lar göndererek HackTricks ve HackTricks Cloud github depolarına katkıda bulunun.

{% embed url="https://websec.nl/" %}

Temel Bilgiler

OAuth, OAuth 2.0 belgelerinde erişilebilen çeşitli sürümler sunar. Bu tartışma genellikle yaygın olarak kullanılan OAuth 2.0 yetkilendirme kodu tahsis türü üzerinde odaklanır, bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişmesine veya işlem yapmasına olanak tanıyan bir yetkilendirme çerçevesi sağlar (yetkilendirme sunucusu).

Hayali bir web sitesini düşünün https://ornek.com, 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://ornek.com, sosyal medya gönderilerinize erişim izni isteyecektir. Sonuç olarak, https://sosyalmedya.com üzerinde bir onay ekranı belirecek ve istenen izinler ile istekte bulunan geliştirici belirtilecektir. Onayınızın ardından, https://ornek.com, gönderilerinize sizin adınıza erişme yeteneği kazanır.

OAuth 2.0 çerçevesi içinde aşağıdaki bileşenleri anlamanız önemlidir:

• kaynak sahibi: Siz, kullanıcı/öğe olarak, sosyal medya hesabınızın gönderilerine erişim izni verirsiniz.
• kaynak sunucusu: Uygulama, erişim belirtecini kaynak sahibi adına aldıktan sonra kimlik doğrulama isteklerini yöneten sunucu, örneğin https://sosyalmedya.com.
• istemci uygulaması: kaynak sahibinden yetki isteyen uygulama, örneğin https://ornek.com.
• yetkilendirme sunucusu: kaynak sahibinin başarılı kimlik doğrulamasını ve yetkilendirmeyi sağladıktan sonra erişim belirteçlerini istemci uygulamasına veren sunucu, örneğin https://sosyalmedya.com.
• client_id: Uygulama için genel, benzersiz bir tanımlayıcı.
• client_secret: Yalnızca uygulama ve yetkilendirme sunucusu tarafından bilinen gizli bir anahtar, erişim belirteçleri oluşturmak için kullanılır.
• response_type: İstenen token türünü belirten bir değer, örneğin code.
• scope: istemci uygulamasının kaynak sahibinden istediği erişim seviyesi.
• redirect_uri: Yetkilendirme sonrası kullanıcının yönlendirileceği URL. Genellikle önceden kayıtlı yönlendirme URL'siyle uyumlu olmalıdır.
• state: Kullanıcının yetkilendirme sunucusuna yönlendirilirken ve oradan geri dönerken verileri korumak için bir parametre. Benzersizliği, CSRF koruma mekanizması olarak hizmet etmesi için önemlidir.
• grant_type: Tahsis türünü ve döndürülecek token türünü belirten bir parametre.
• code: yetkilendirme sunucusundan alınan yetkilendirme kodu, istemci uygulaması tarafından client_id ve client_secret ile birlikte kullanılarak erişim belirteci elde etmek için kullanılır.
• access_token: istemci uygulamasının API isteklerinde kullanacağı token kaynak sahibi adına.
• refresh_token: Uygulamanın kullanıcıya tekrar soru sormadan yeni bir erişim belirteci almasını sağlar.

Akış

Gerçek OAuth akışı şu şekilde devam eder:

1. https://ornek.com adresine giderek "Sosyal Medya ile Entegre Ol" düğmesini seçersiniz.
2. Site, ardından https://ornek.com'un uygulamasının gönderilerinize erişmesine izin vermeniz için https://sosyalmedya.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ı takiben, 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'ı birlikte kullanarak sizin adınıza bir sunucu tarafı isteği yapar ve sizin onayladığınız izinlere erişim sağlayan bir access_token alır:

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

6. Son olarak, işlem, https://example.com'un access_token'ını kullanarak bir API çağrısı yaparak Sosyal Medya'ya erişir.

Zafiyetler

Açık redirect_uri

redirect_uri, OAuth ve OpenID uygulamalarında güvenlik açısından önemlidir, çünkü hassas verileri, örneğin yetkilendirme kodlarını, yetkilendirme sonrası nereye gönderileceğini yönlendirir. Yanlış yapılandırılmışsa, saldırganların bu istekleri kötü amaçlı sunuculara yönlendirmesine izin vererek hesap ele geçirmesine olanak tanıyabilir.

Sömürü teknikleri, yetkilendirme sunucusunun doğrulama mantığına bağlı olarak değişir. Bunlar, katı yol eşleştirmesinden belirli etki alanı veya alt dizindeki herhangi bir URL'i kabul etmeye kadar uzanabilir. Yaygın sömürü yöntemleri arasında açık yönlendirmeler, yol geçişi, zayıf regexlerin sömürülmesi ve belirteç hırsızlığı için HTML enjeksiyonu bulunur.

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 duyarlıdır. Bu parametreler isteğe bağlıdır ve destekleri sunucular arasında değişir.

Bir OpenID sunucusunu hedefleyenler için keşif ucu 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ı listeleyebilir. Bu ayrıntılar, sunucunun kayıt ucu noktasını ve diğer yapılandırma özelliklerini tanımlamada 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 muhtemelen yönlendirme URL'sinin, kullanıcı kimlik doğrulamasından sonra sunucunun yanıtında yansıtıldığı ve XSS'ye duyarlı olduğu olabilir. Test etmek için olası yük:

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

CSRF - Durum parametresinin yanlış işlenmesi

OAuth uygulamalarında, state parametresinin yanlış kullanımı veya ihmal edilmesi, Cross-Site Request Forgery (CSRF) saldırılarının riskini önemli ölçüde artırabilir. Bu zafiyet, state parametresinin ya kullanılmaması, sabit bir değer olarak kullanılması veya doğru şekilde doğrulanmaması durumunda ortaya çıkar ve saldırganların CSRF korumalarını atlamasına izin verir.

Saldırganlar, yetkilendirme sürecini ele geçirerek kendi hesaplarını kurbanın hesabıyla bağlantılı hale getirerek potansiyel hesap ele geçirmelerine yol açabilir. Bu özellikle OAuth'nin kimlik doğrulama amaçlı kullanıldığı uygulamalarda son derece kritiktir.

Bu zafiyetin gerçek dünya örnekleri çeşitli CTF meydan okumalarında ve hacking platformlarında belgelenmiş ve pratik sonuçlarını vurgulamıştır. Sorun, Slack, Stripe ve PayPal gibi üçüncü taraf hizmetlerle entegrasyonlara da uzanır, burada saldırganlar bildirimleri veya ödemeleri kendi hesaplarına yönlendirebilirler.

state parametresinin doğru şekilde işlenmesi ve doğrulanması, CSRF'ye karşı korunma ve OAuth akışını güvence altına alma açısından hayati öneme sahiptir.

Hesap Ele Geçirme Öncesi

1. Hesap Oluştururken E-posta Doğrulaması Olmadan: Saldırganlar, kurbanın e-postasını kullanarak önceden bir hesap oluşturabilirler. Eğer kurban daha sonra giriş yapmak için üçüncü taraf bir hizmet kullanırsa, uygulama bu üçüncü taraf hesabını yanlışlıkla saldırganın önceden oluşturduğu hesapla ilişkilendirebilir ve yetkisiz erişime yol açabilir.

2. Geçerli Olmayan OAuth E-posta Doğrulamasını Sömürme: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini sömürebilir ve kendi servislerine kaydolup daha sonra hesap e-postasını kurbanın e-postasıyla değiştirebilirler. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimine yol açar, ancak farklı bir saldırı vektörü aracılığıyla gerçekleşir.

Sırların Açığa Çıkarılması

Gizli OAuth parametrelerini tanımlamak ve korumak hayati önem taşır. client_id güvenle açıklanabilirken, client_secret'in açıklanması önemli riskler oluşturur. Eğer client_secret tehlikeye atılırsa, saldırganlar uygulamanın kimliğini ve güvenini sömürerek kullanıcı access_token'larını ve özel bilgileri çalabilirler.

Uygulamaların yetkilendirme code'unun access_token ile değiş tokuşunu sunucu tarafında değil istemci tarafında yanlış şekilde işlemesi durumunda yaygın bir zafiyet ortaya çıkar. Bu hata, client_secret'in açığa çıkmasına yol açar ve saldırganların uygulama adına access_token'lar oluşturmasına olanak tanır. Dahası, sosyal mühendislik aracılığıyla saldırganlar, OAuth yetkilendirmesine ek kapsamlar ekleyerek uygulamanın güvenilir durumunu daha da kötüye kullanabilirler.

İstemci Sırrı Kaba Kuvvet Saldırısı

Kimlik sağlayıcı ile hizmet sağlayıcısının istemci_sırrını kaba kuvvet ile deneyebilir ve hesapları çalmaya çalışabilirsiniz.
BF'ye yönelik istek benzer olabilir:

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 Code + State

Müşteri code ve state'e sahip olduktan sonra, farklı bir sayfaya göz attığında Referer başlığında yansıtılıyorsa, zayıf bir durumdadır.

Erişim Belirteci Tarayıcı Geçmişinde Saklanıyor

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

Sonsuz Yetkilendirme Kodu

Yetkilendirme kodu, saldırganın çalıp kullanabileceği zaman penceresini sınırlamak için sadece belirli bir süre yaşamalıdır.

Yetkilendirme/Yenileme Belirteci müşteriye bağlı değil

Eğer yetkilendirme kodunu alabilir ve farklı bir müşteriyle kullanabilirseniz, diğer hesapları ele geçirebilirsiniz.

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

Bu yazıyı kontrol edin

AWS Cognito

Bu hata ödülü raporunda: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ görebilirsiniz ki AWS Cognito'nun kullanıcıya geri verdiği belirtecin, kullanıcı verilerini üzerine yazma iznine sahip olabileceği. Bu nedenle, farklı bir kullanıcı e-postası için kullanıcı e-postasını değiştirebilirseniz, başkalarının hesaplarını 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"
}
]
}

Diğer Uygulamaların Token'larının Kötüye Kullanımı

Bu yazıda belirtildiği gibi, token (ve bir kod değil) bekleyen OAuth akışları, token'ın uygulamaya ait olup olmadığını kontrol etmezse savunmasız olabilir.

Bu, çünkü bir saldırgan, kendi uygulamasında OAuth'yi destekleyen ve Facebook ile giriş yapan bir uygulama oluşturabilir. Ardından, bir kurbanın Facebook'ta saldırganın uygulamasında oturum açtığında, saldırgan, kurbanın OAuth uygulamasına verilen kullanıcı token'ını alabilir ve bu token'ı kullanarak kurbanın OAuth uygulamasına kurbanın kullanıcı token'ı ile oturum açabilir.

{% hint style="danger" %} Bu nedenle, saldırgan, kullanıcının kendi OAuth uygulamasına erişmesini sağlarsa, token'ın verildiği uygulama kimliğine bakılmaksızın token bekleyen ve token'ın uygulama kimliğine verilip verilmediğini kontrol etmeyen uygulamalarda kurbanın hesabını ele geçirebilecektir. {% endhint %}

İki bağlantı ve çerez

Bu yazıda belirtildiği gibi, bir kurbanın dönüş URL'sini saldırganın ana bilgisayarına işaret eden bir sayfayı açmasını sağlamak mümkündü. Bu bilgi bir çerezde (RU) saklanacak ve daha sonra prompt, kullanıcıya bu saldırganın ana bilgisayarına erişim vermek isteyip istemediğini soracaktır.

Bu prompt'u atlamak için, dönüş URL'sini kullanan bu RU çerezini ayarlayacak Oauth akışını başlatmak için bir sekme açmak, prompt gösterilmeden önce sekme kapatmak ve bu değeri olmadan yeni bir sekme açmak mümkündü. Ardından, prompt, saldırganın ana bilgisayarından bahsetmeyecek, ancak çerez ona ayarlanacak, böylece token yönlendirmede saldırganın ana bilgisayarına gönderilecektir.

SSRF parametreleri

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

OAuth'da Dinamik İstemci Kaydı, özellikle Sunucu Tarafı İstek Sahtekarlığı (SSRF) saldırıları için daha az açık ancak kritik bir vektör olarak hizmet verir. Bu uç nokta, OAuth sunucularının hassas URL'leri de içeren istemci uygulamaları hakkında ayrıntılar almasına olanak tanır.

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 Anahtar Kümesi (JWK'ler) için URL'ler gibi ayrıntıları kabul eder.
• Bu özellik, RFC7591 ve OpenID Connect Registration 1.0 tarafından belirlenen özelliklere uyar ve SSRF'ye açık olabilecek parametreleri içerir.
• Kayıt süreci, sunucuları yanlışlıkla 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ış işlenirse XSS'e yol açabilir.
• jwks_uri: İstemcinin JWK belgesine bir URL, kötü amaçlı olarak oluşturulursa, sunucunun saldırganın kontrol ettiği bir sunucuya çıkış istekleri yapmasına neden olabilir.
• sector_identifier_uri: Bir JSON dizisine redirect_uris referans verir, sunucu bunu alarak SSRF fırsatı yaratabilir.
• request_uris: İstemci için izin verilen istek URI'lerini listeler, sunucunun yetkilendirme sürecinin başında bu URI'leri alması durumunda sömürülebilir.

Sömürü Stratejisi:

• SSRF, logo_uri, jwks_uri veya sector_identifier_uri gibi parametrelerde kötü amaçlı URL'lerle yeni bir istemci kaydedilerek tetiklenebilir.
• Doğrudan request_uris üzerinden sömürü belki de beyaz liste kontrolleri ile hafifletilebilir, ancak önceden kaydedilmiş, saldırgan tarafından kontrol edilen bir request_uri sağlamak, yetkilendirme aşamasında SSRF'yi kolaylaştırabilir.