Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

19 KiB
Raw Blame History

OAuth ile Hesap Ele Geçirme

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

HackTricks'ı desteklemenin diğer yolları:

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

Temel Bilgiler

OAuth, OAuth 2.0 belgelerinde erişilebilir temel bilgilerle birlikte ç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 ve 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, kaynak sahibi adına bir erişim belirteci aldıktan sonra kimlik doğrulaması yapılan istekleri 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 istemci uygulamasına erişim belirteçleri 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 düzeyi.
  • 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önlendirilmesi ve oradan geri dönmesi sırasında verileri saklamak 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 bir erişim belirteci almak 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 daha sonra, 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

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

  2. 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
  1. https://example.com, sizin adınıza bir access_token almak için bu code'u, birlikte client_id ve client_secret'ını kullanır, böylece sizin 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"}
  1. Son olarak, işlem https://example.com'un access_token'ını kullanarak bir API çağrısı yaparak Sosyal Medya'ya erişir.

Zayıflıklar

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çirmelerine 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'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 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, kayıt ucu noktasını ve sunucunun diğer yapılandırma ayrıntılarını tanımlamada yardımcı olabilir.

Yönlendirme uygulamasındaki 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 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ı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ı bir kurbanın hesabıyla bağlayarak potansiyel hesap ele geçirmelerine yol açabilir. Bu özellikle OAuth'nin kimlik doğrulama amaçlı kullanıldığı uygulamalarda 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. 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şturulan hesabına bağlayabilir 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 ardından hesap e-postasını kurbanın e-postasıyla değiştirebilirler. Bu yöntem, ilk senaryoya benzer şekilde yetkisiz hesap erişimine ve farklı bir saldırı vektörü aracılığıyla risk oluşturur.

Sırların Açıklanması

Gizli OAuth parametrelerini tanımlamak ve korumak hayati önem taşır. client_id güvenle açıklanabilirken, client_secret'in ifşa edilmesi ö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.

Yaygın bir zafiyet, uygulamaların yetkilendirme code'unun access_token karşılığını sunucu tarafında değil istemci tarafında yanlış şekilde işlemesinden kaynaklanır. 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 ayrıcalıkları artırabilir ve 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 client_secret'ini kaba kuvvet saldırısı ile deneyebilirsiniz, böylece 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 koda 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 Kodu ve 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ğini. 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"
}
]
}

AWS Cognito'yu kötüye kullanma hakkında daha detaylı bilgi için şu linke bakabilirsiniz:

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

Diğer Uygulamaların Token'ları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 zayıf olabilir.

Bu, çünkü bir saldırgan, kendi uygulamasında OAuth'yi destekleyen ve Facebook ile giriş yapabilen 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ında verilen kullanıcı token'ını alabilir ve kurbanın kullanıcı token'ını kullanarak 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 verildiği uygulama kimliğine bakılmadan bir 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 bir returnUrl ile saldırganın ana bilgisayarını işaret eden bir sayfayı açmasının mümkün olduğu belirtildi. Bu bilgi bir çerezde (RU) saklanacak ve daha sonra prompt, kullanıcıya o saldırganın ana bilgisayarına erişim vermek isteyip istemediğini soracaktır.

Bu prompt'u atlamak için, returnUrl'yi kullanan Oauth akışını başlatan 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 yönlendirmede token 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 Sahtekarlığı (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 içeren istemci uygulamaları hakkında ayrıntılar almasını sağlar 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 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 duyarlı 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: Sunucunun alabileceği redirect_uris JSON dizisine referans verir, bu da sunucunun SSRF fırsatı yaratabilir.
  • request_uris: İstemci için izin verilen istek URI'lerini listeler, bu URI'lerin yetkilendirme sürecinin başında sunucu tarafından alınması durumunda kötüye kullanılabilir.

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 azaltılabilir, ancak ö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ısı ise, olası Yarış Koşullarını test etmek için bunu okuyun.

Referanslar

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

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

HackTricks'i desteklemenin diğer yolları: