Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md
Translator workflow 6cb783ece2 Translated to Turkish
2024-02-10 18:14:16 +00:00

19 KiB
Raw Blame History

OAuth Hesabı Ele Geçirmek İçin

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'i desteklemenin diğer yolları:

Temel Bilgiler

OAuth, OAuth 2.0 belgelerinde erişilebilir olan çeşitli sürümler sunar. Bu tartışma, temel olarak bir uygulamanın başka bir uygulamadaki bir kullanıcının hesabına erişim veya işlem yapmasını sağlayan bir yetkilendirme çerçevesi olan OAuth 2.0 yetkilendirme kodu grant türüne odaklanır.

Bir örnek web sitesi olan https://example.com, özel olanlar dahil olmak üzere tüm sosyal medya gönderilerinizi sergilemek için OAuth 2.0 kullanır. Bunun için https://example.com, sosyal medya gönderilerinize erişim izni isteyecektir. Sonuç olarak, https://socialmedia.com üzerinde bir onay ekranı görünecek ve istenen izinler ve istekte bulunan geliştirici belirtilecektir. Sizin onayınızla, https://example.com, sizin adınıza gönderilerinize erişme yeteneği kazanır.

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

  • kaynak sahibi: Siz, kullanıcı/öğe olarak, sosyal medya hesabınız gibi kaynağınıza erişime izin verirsiniz.
  • kaynak sunucusu: Uygulama, erişim belirtecini kaynak sahibi adına güvence altına aldıktan sonra yetkilendirilmiş istekleri yöneten kimlik doğrulaması yapılan sunucu, örneğin https://socialmedia.com.
  • istemci uygulaması: kaynak sahibinden yetkilendirme isteyen uygulama, örneğin https://example.com.
  • yetkilendirme sunucusu: kaynak sahibinin başarılı kimlik doğrulamasını ve yetkilendirmeyi takiben erişim belirtecini istemci uygulamasına veren sunucu, örneğin https://socialmedia.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 belirteci oluşturmak için kullanılır.
  • response_type: İstenen belirteç türünü belirten bir değer, örneğin code.
  • scope: istemci uygulamasının kaynak sahibinden istediği erişim düzeyi.
  • redirect_uri: Yetkilendirme sonrasında kullanıcının yönlendirildiği URL. Bu genellikle önceden kaydedilmiş yönlendirme URL'siyle uyumlu olmalıdır.
  • state: Verilerin kullanıcının yetkilendirme sunucusuna yönlendirilmesi ve sunucudan geri yönlendirilmesi sırasında verilerin korunması için bir parametre. Benzersizliği, CSRF koruma mekanizması olarak önemlidir.
  • grant_type: İzin türünü ve döndürülecek belirteç 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 bir erişim belirteci elde etmek için kullanılır.
  • access_token: istemci uygulamasının API isteklerinde kullanacağı belirteç, kaynak sahibi adına.
  • refresh_token: Uygulamanın kullanıcıyı tekrar sormadan yeni bir erişim belirteci elde etmesini sağlar.

Akış

Gerçek OAuth akışı aşağıdaki gibi ilerler:

  1. https://example.com adresine gidip "Sosyal Medya ile Entegre Ol" düğmesini seçersiniz.
  2. Site, https://example.com'un uygulamasının gönderilerinize erişim sağlaması için sizin izniniz istenmesi için https://socialmedia.com adresine bir istek gönderir. İstek aşağıdaki gibi 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

  1. Ardından bir onay sayfasıyla karşılaşırsınız.

  2. Onayınızı takiben, Sosyal Medya redirect_uri'ye code ve state parametreleriyle bir yanıt gönderir:

https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com, bu code'u, client_id ve client_secret ile birlikte kullanarak sizin adınıza bir sunucu tarafı isteği yapar ve sizin onayladığınız izinlere erişim sağlamak için bir access_token elde eder:
POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}
  1. Son olarak, süreç https://example.com'un access_token'ı kullanarak Sosyal Medya'ya erişmek için bir API çağrısı yapmasıyla sonuçlanır.

Zayıflıklar

Açık redirect_uri

redirect_uri, OAuth ve OpenID uygulamalarında güvenlik açısından önemlidir çünkü yetkilendirme sonrasında yetkilendirme kodları gibi hassas verilerin gönderildiği yeri yönlendirir. Yanlış yapılandırıldığında, 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 belirtilen etki alanı veya alt dizindeki herhangi bir URL'yi 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 karşı savunmasız olabilir. Bu parametreler isteğe bağlıdır ve destekleri sunucular arasında değişir.

OpenID sunucusunu hedefleyenler için keşif ucu noktası (**.well-known/openid-configuration**), registration_endpoint, request_uri_parameter_supported ve "require_request_uri_registration gibi değerli yapılandırma ayrıntılarını genellikle listeler. Bu ayrıntılar, sunucunun kayıt ucu noktasını ve diğer yapılandırma ayrıntılarını belirlemeye yardımcı olabilir.

Yönlendirme uygulamasında XSS

Bu hata avı raporunda https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html belirtildiği gibi, kullanıcının kimlik doğrulamasından sonra sunucunun yanıtında URL'nin yansıtıldığı ve XSS'ye karşı savunmasız olabileceği mümkündür. 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ılması veya atlanması, Cross-Site Request Forgery (CSRF) saldırılarının riskini önemli ölçüde artırabilir. Bu güvenlik açığı, 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 araya girerek kendi hesaplarını kurbanın hesabıyla bağlayarak potansiyel hesap ele geçirmelerine yol açabilirler. Bu durum özellikle OAuth'nin kimlik doğrulama amaçlı kullanıldığı uygulamalarda kritik öneme sahiptir.

Bu güvenlik açığına ilişkin gerçek dünya örnekleri, çeşitli CTF zorlukları ve hacking platformları tarafından belgelenmiş ve pratik sonuçlarını ortaya koymuştur. Sorun, Slack, Stripe ve PayPal gibi üçüncü taraf hizmetlerle olan entegrasyonlara da uzanır ve saldırganlar bildirimleri veya ödemeleri kendi hesaplarına yönlendirebilirler.

CSRF'ye karşı korunmak ve OAuth akışını güvence altına almak için state parametresinin doğru şekilde işlenmesi ve doğrulanması önemlidir.

Hesap Ele Geçirme Öncesi

  1. Hesap Oluşturmada E-posta Doğrulaması Olmaksızın: Saldırganlar, kurbanın e-postasını kullanarak önceden bir hesap oluşturabilirler. Kurban daha sonra giriş için üçüncü taraf bir hizmet kullanırsa, uygulama yanlışlıkla bu üçüncü taraf hesabını 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ın Sömürülmesi: Saldırganlar, e-postaları doğrulamayan OAuth hizmetlerini sömürebilirler. Bunun için kendi servislerine kaydolup hesap e-postasını kurbanın e-postasıyla değiştirirler. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimine yol açar, ancak farklı bir saldırı vektörü kullanır.

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

Gizli OAuth parametrelerinin belirlenmesi ve korunması önemlidir. client_id güvenli bir şekilde açıklanabilirken, client_secret'in açığa çıkarılması önemli riskler oluşturur. Eğer client_secret tehlikeye düşerse, saldırganlar uygulamanın kimliğini ve güvenini sömürerek kullanıcı access_token'larını ve özel bilgileri çalabilirler.

Yaygın bir güvenlik açığı, uygulamaların yetkilendirme code'unun access_token ile değişimini sunucu tarafı yerine istemci tarafında yanlış şekilde işlemesidir. Bu hata, client_secret'in açığa çıkmasına neden olur ve saldırganların uygulama adına access_token üretmesine olanak tanır. Dahası, sosyal mühendislik yoluyla saldırganlar, OAuth yetkilendirmesine ek kapsamlar ekleyerek ayrıcalıkları artırabilir ve uygulamanın güvenilir durumunu daha da sömürebilirler.

İstemci Gizli Kuvvet Saldırısı

Hesapları çalmak için hizmet sağlayıcının istemci gizli kuvvetini kaba kuvvetle deneyebilirsiniz.
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 Başlığı Sızdıran Kod + Durum

İstemci, kod ve durumu aldıktan sonra, farklı bir sayfaya göz attığında Referer başlığı içinde yansıtılıyorsa, bu zayıf bir noktadı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, istemciye bağlı değil

Yetkilendirme kodunu alabilir ve farklı bir istemciyle kullanabilirseniz, başka hesapları ele geçirebilirsiniz.

Mutlu Yollar, XSS, İframe'ler ve Kod & Durum Değerlerini sızdırmak için Gönderi Mesajları

Bu gönderiyi kontrol edin

AWS Cognito

Bu hata avı raporunda: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ AWS Cognito'nun kullanıcıya geri verdiği belirtecin, kullanıcı verilerini üzerine yazmak için yeterli izinlere sahip olabileceğini görebilirsiniz. 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"
}
]
}

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

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

Diğer Uygulama Tokenlarının Kötüye Kullanılması

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, bir saldırganın kendi uygulamasında OAuth'yi destekleyen ve Facebook ile giriş yapabilen bir uygulama oluşturabileceği anlamına gelir. Ardından, bir kurbanın Facebook ile saldırganın uygulamasında oturum açması durumunda, saldırgan, kurbanın OAuth uygulamasına verilen kullanıcı tokenını alabilir ve kurbanın kullanıcı tokenı kullanılarak kurbanın OAuth uygulamasına giriş yapabilir.

{% hint style="danger" %} Bu nedenle, saldırgan kullanıcının kendi OAuth uygulamasına erişmesini sağlarsa, tokenın uygulama kimliklerine verilip verilmediğini kontrol etmeyen uygulamalarda kurbanın hesabını ele geçirebilir. {% endhint %}

İki bağlantı ve çerez

Bu yazıda belirtildiği gibi, bir kurbanın saldırganın ana bilgisayarına yönlendiren bir returnUrl'ye sahip bir sayfayı açması mümkündü. Bu bilgi bir çerezde (RU) saklanacak ve bir sonraki adımda 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, Oauth akışını başlatan ve bu RU çerezini returnUrl kullanarak ayarlayan 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ını bilgilendirmeyecek, ancak çerez ona ayarlanacak, bu nedenle token yönlendirmede saldırganın ana bilgisayarına gönderilecektir.

SSRF parametreleri

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

OAuth'da Dinamik İstemci Kaydı, özellikle Sunucu Tarafı İstek Sahteciliği (SSRF) saldırıları için daha az açık ama kritik bir vektör olarak hizmet verir. Bu uç nokta, OAuth sunucularının hassas URL'leri de dahil olmak üzere istemci uygulamaları hakkında ayrıntıları almasına olanak tanır ve bu URL'lerin kötüye kullanılmasına neden olabilir.

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 Setleri (JWK'ler) için URL'ler gibi ayrıntıları kabul eder.
  • Bu özellik, SSRF'ye açık olabilen parametrelere sahip RFC7591 ve OpenID Connect Registration 1.0 tarafından belirlenen özelliklere uyar.
  • Kayıt süreci, sunucuları yanlışlıkla SSRF'ye açabilir:
  • logo_uri: Sunucu tarafından alınabilecek istemci uygulamasının logosu için bir URL, bu da SSRF'yi tetikleyebilir veya URL yanlış işlenirse XSS'ye yol açabilir.
  • jwks_uri: İstemcinin JWK belgesine bir URL, kötü niyetli olarak oluşturulursa sunucunun saldırgan tarafından kontrol edilen bir sunucuya çıkış istekleri yapmasına neden olabilir.
  • sector_identifier_uri: Sunucu tarafından alınabilecek bir redirect_uris JSON dizisine referans verir, bu da SSRF fırsatı yaratabilir.
  • request_uris: İstemci için izin verilen istek URI'lerini listeler, sunucunun yetkilendirme sürecinin başında bu URI'leri alırsa kötüye kullanılabilir.

Sömürü Stratejisi:

  • SSRF, logo_uri, jwks_uri veya sector_identifier_uri gibi parametrelerde kötü niyetli URL'lerle yeni bir istemci kaydederek tetiklenebilir.
  • request_uris aracılığıyla doğrudan sömürü, beyaz liste kontrolleri tarafından hafifletilebilirken, önceden kaydedilmiş, saldırgan tarafından kontrol edilen 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ı ise, mümkün olan Yarış Koşullarını test etmek için bunu okuyun.

Referanslar

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'ı desteklemenin diğer yolları: