OAuth ve OpenID Connect (OIDC) Yapılandırma Zafiyetleri: Gerçek Hayattan Saldırı Senaryoları

Bugün sizlerle günümüzde çok yaygın kullanılan protokollerin yanlış ve zayıf yapılandırmasından kaynaklı ortaya çıkan zaafiyetleri konuşacağız. OAuth ve OpenID Connect gibi teknolojiler, web uygulamalarımızı daha güvenli ve kullanıcı dostu hale getiriyor, ama bir hata yaparsanız, hacker'lar kapıda bekliyor!

OAuth Nedir?

OAuth, modern web uygulamalarında sıkça karşılaştığımız bir durumu ele alır: "Bir uygulama, Facebook veya Google hesabınızı kullanarak oturum açmanızı ister." İşte bu noktada OAuth devreye girer ve sizin izninizle erişim sağlamak için güvenli bir yöntem sunar.

Diyelim ki, bir uygulamaya oturum açarken "Facebook ile oturum aç" seçeneğini gördünüz. Bu seçeneği seçtiğinizde, uygulama sizi Facebook'a yönlendirir. Ancak, uygulama sizin kullanıcı adınızı ve parolanızı asla görmez veya kaydetmez. Bunun yerine, OAuth protokolünü kullanarak size erişim talebi yapar ve sizin izninizle belirli verilere (profil, e-posta gibi) erişim sağlar. Bu şekilde, uygulama sizi doğrudan doğrulama sağlayıcısıyla ilişkilendirerek güvenli bir oturum açma süreci sunar.

Bu tam olarak bir OAuth modelidir. Kısacası, OAuth üçüncü taraf uygulamalara sınırlı erişim hakkı verir, ama kimliğinizi tam olarak doğrulamak için değil – o kısım OIDC'ye kalıyor. Aşağıdaki görsel anlamanıza daha yardımcı olabilir.

Kısacası bu tarz yapılara OAuth deriz. Arka tarafta yapı şu şekildedir: İlk önce OAuth yaptığımız servis (örneğin Gmail) için client_id ve ilgili uygulamanın URL'inin bulunduğu bir istek atılır.

Örnek İstek:

GET https://accounts.google.com/o/oauth2/v2/auth?client_id=your_client_id&redirect_uri=https://yourapp.com/callback&scope=profile email&response_type=code&state=random_state_value

Her şey yolunda giderse ve kullanıcı izin verirse, Gmail servisi token oluşturmak için yeni bir istek atar.

Token İsteği:

POST https://www.googleapis.com/oauth2/v4/token
Content-Type: application/x-www-form-urlencoded

code=received_auth_code&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=https://yourapp.com/callback&
grant_type=authorization_code

Başarıyla tamamlandığında, API kullanıcıya bir token döner:

{
 "access_token": "ya29.a0AfH6SMC...example_token",
 "expires_in": 3600,
 "token_type": "Bearer"
}

Böylece bir OAuth döngüsü tamamlanmış olur.

OpenID Connect Nedir?

OpenID Connect, anlatım olarak OAuth'a biraz benziyor. Bundan dolayı kafaları yakmamak için konunun hemen başında bir uyarı geçeyim: OAuth erişim token'ı verir (verilere ulaşmak için), OIDC ise kimlik token'ı (ID Token) ekleyerek kimliğinizi doğrular.

Yani OpenID Connect, OAuth protokolünü temel alarak kimlik doğrulama ve kullanıcı kimliği hakkında bilgi sağlama sürecini gerçekleştiriyor.

OpenID Connect ile bir uygulamaya oturum açmak istediğinizde, uygulama sizi doğrulama sağlayıcısına (örneğin Google, Facebook) yönlendirir. Doğrulama sağlayıcısı, kimlik bilgilerinizi doğrular ve size bir kimlik belgesi olan ID Token verir. Bu ID Token, uygulamaya geri gönderilir ve uygulama bu token'ı kullanarak kimliğinizi doğrular.

Örneğin, "Google hesabınızla oturum aç" seçeneğini seçtiğinizde, OpenID Connect devreye girer. Sizi doğrulama sağlayıcısına yönlendirir, kimlik bilgilerinizi doğrular ve ID Token verir. Uygulama bu token'ı kullanarak oturum açar.

OAuth vs. OIDC Karşılaştırması

OAuth ve OpenID Connect Zaafiyetleri

Eğer bu teknolojiler ve standart bir web haberleşmesine aşina değilseniz, çok karışık gelebilir. Bilgisayarınızı tekmelemeden önce farklı kaynaklardan (örneğin OWASP kılavuzları) araştırma yapabilirsiniz.

Artık OAuth ve OpenID Connect kafamızda biraz yer edindiğine göre, bu zat-ı muhteremlerden dolayı ortaya çıkan zaafiyetleri inceleyebiliriz. Konunun bu tarafında biraz daha realist senaryoları görmeniz için HackerOne gibi platformlarda bildirilmiş gerçek hayat senaryoları üzerinden anlatacağım.

JWT(Json Web Token) Saldırıları

JSON Web Token (JWT), OpenID Connect protokolünde kullanılan bir kimlik doğrulama mekanizmasıdır. Buna ben de dahil birçok geliştiricinin hayatını kolaylaştıran bir mimaridir. Fakat doğru yapılandırılmadığı takdirde birçok zaafiyete yol açabilir: Account Takeover, Token Overflow, none algoritma zaafiyeti gibi. Saldırı vektörleri hedef sitenin mimarisine göre değişir.

Account Takeover Örneği

Örneğin JWT kullanılan bir yapıda, website'ye login olurken her isteğimizde bir JWT parametresi yer alır (genellikle Cookie veya Header'da).

JWT'ler her zaman cookie'de tutulmaz, ama Burp Suite gibi araçlarla otomatik tespit edebilirsiniz.

Cookie'deki JWT'yi decode ettiğimizde şöyle gözükür:

Gördüğünüz gibi user bilgisi içerisinde sadece benim nickim yer alıyor. Başka bir anahtar ile koruma yapılmamış. Fakat, her halükarda JWT için Secret Key'e ihtiyacım var.

Bunu elde etmek için John The Ripper veya Hashcat gibi araçları kullanabilirsiniz.

echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt

Görselde gördüğünüz gibi Secret Key "ilovepico" çıktı. Artık JWT içindeki verileri değiştirip yeniden imzalayabiliriz (örneğin user'ı "admin" yap).

Yukarıdaki görselde görmüş olduğunuz gibi user'i admin olarak değiştirdim, VERIFY SIGNATURE adresine kırmış olduğumuz secret keyi yazdık. Sol alt tarafta da Signatura Verified şeklinde JWT'imizin onaylandığını belirtti. Şimdi Manipüle edilmiş JWT kodumuzu kopyalayıp, sunucumuzda değiştirelim ve olacakları görelim.

Burp Suite'de JWT'mi değiştiriyorum.

Yukarıdaki görselde görmüş olduğunuz gibi admin olarak giriş yapmış olduk.

None Algoritma Zafiyeti

Bu zaafiyet, JWT'nin imza doğrulamasını tamamen devre dışı bırakma potansiyeli taşıyan kritik bir yapılandırma hatasıdır. JWT standardı, imzasız token'ları belirtmek için alg (algoritma) başlığında "none" değerine izin verir. Eğer sunucu tarafındaki kütüphane veya kod, bu değeri bir imza algoritması olarak kabul edecek şekilde hatalı yapılandırılmışsa, saldırganlar imza kısmını kaldırarak token'ı istedikleri gibi manipüle edebilirler.

Örnek Saldırı Adımları:

1.Orijinal Token'ı Yakala: Saldırgan, uygulamadan aldığı geçerli bir JWT'yi yakalar.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoidXNlcjEyMyJ9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

2.Token'ı Decode Et: Token'ın header ve payload kısımlarını Base64 formatından decode eder.

Header: {"alg": "HS256", "typ": "JWT"}

Payload: {"user": "user123"}

3.Token'ı Manipüle Et: Header'daki alg değerini "none" olarak, payload'daki kullanıcıyı ise "admin" olarak değiştirir.

Yeni Header: {"alg": "none", "typ": "JWT"}

Yeni Payload: {"user": "admin"}

4.Yeni Token'ı Oluştur: Değiştirilmiş header ve payload'ı tekrar Base64 ile encode eder ve imza kısmını boş bırakır. Token'ın sonundaki nokta karakteri kalmalıdır.

Saldırı Token'ı: eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.

5.İsteği Gönder: Saldırgan, bu manipüle edilmiş token ile sunucuya istek gönderdiğinde, hatalı yapılandırılmış sunucu hiçbir imza doğrulaması yapmadan payload'daki bilgileri geçerli kabul eder ve saldırgana admin yetkileriyle erişim verir.

 Bu zaafiyet özellikle eski kütüphanelerde (örneğin bazı Node.js JWT library'lerinde) yaygındır ve OWASP tarafından yüksek riskli olarak sınıflandırılır.

Bir Diğer konu Exploit Chaining yani Zaafiyet Yükseltme veya farklı zaafiyetlerle birleştirmeye bakalım. Exploit Chaining, yani zaafiyetleri birleştirme. Bu, tek bir zaafiyeti kullanarak başka zaafiyetlere sıçramak anlamına gelir ve gerçek saldırılarda etkiyi katlar.

Bir bug bounty programında yaşadığım bir senaryo: Şifreyi kıramadık mı? Açıkta kalan dizinleri tarayın (örneğin .env dosyası). Örneğimde bir sitede .env açık kalmış ve içinde JWT_SECRET yer alıyor.

Böylece decode uğraşmadan secret'ı alıyoruz. Ek ipucu: .git, backup dosyalarını da kontrol edin. Bu chaining, bir zaafiyeti (dizin enumeration) başka bir zaafiyetle (JWT cracking) birleştirerek etkiyi büyütür.

Exploit chaining için başka bir örnek şu olabilir

Diyelim ki bir sitede önce bir Open Redirect zaafiyeti bulundu (redirect URI manipülasyonu). Bunu kullanarak kullanıcıyı phishing sayfasına yönlendirerek, orada JWT tokeni çalınabilir (örneğin XSS ile). Sonra çalınan token'ı decode edip, none algoritmasıyla manipüle edilebilir ve admin hesabı ele geçirilebilir. Veya .env'den secret aldıktan sonra, IDOR (Insecure Direct Object Reference) ile birleştirilebilir: Manipüle edilmiş JWT ile başka kullanıcıların verilerine erişilebilir. Bu zincir, düşük seviye zaafiyetleri kritik hale getirir.

State Parametresi Eksikliği (CSRF Atakları): OAuth akışında "state" parametresi, CSRF'yi önler. Eksikse, saldırgan kullanıcıyı sahte bir login sayfasına yönlendirip token çalabilir. örneğin: Kullanıcıya e-posta ile sahte link gönderilebilir, state doğrulanmazsa erişim sağlanır. 

Kontrol Edilmeyen Callback Yapıları

OAuth yapıları bir callback ile "Evet, işlem tamam, yetki ver" der. 

Fakat burada yapılan Callback kontrol edilmiyorsa hinliği, şeytanlığı başında olan saldırganlar gelir ve servise şunu diyebilir;

ben bu işlemi gerçekleştirdim artık x kişisinin admin olarak login olmasını sağlayabilirsin.

Bu anlatımı Hackerone 'da bulduğum bir rapor üzerinden yapacağım. Okumak isterseniz bu adresten okuyabilirsiniz.

Kullanıcı girişte şu OAuth yapısını takip ediyor:

redirect_uri=https%3A%2F%2Fbooth.pm%2Fusers%2Fauth%2Fpixiv%2Fcallback&response_type=code&scope=read-works+read-favorite-users+read-friends+read-profile+read-email+write-profile&state=%3A1a38b53563599621ce25094661b1c4458ddb52d79d771149

Saldırgan redirect_uri'yi değiştirerek path traversal yapar:

redirect_uri=https%3A%2F%2Fbooth.pm%2Fusers%2Fauth%2Fpixiv%2Fcallback/../../../../ja/items/4503924​

Böylece serviste callback yanıtını kontrol eden herhangi bir mekanizma olmadığı için 4503924 idli kullanıcının hesabına giriş yapmış oluyor.

Yine farklı bir Hackerone raporunda kullanıcı oauth'ta yer alan callback'ın redirect ettiği urlyi modifiye ederek open redirect zaafiyetinden faydalanıyor. Bu durum da firmanın kullanıcılarına yönelik güçlü phishing senaryoları doğuruyor.

Yani aslında örneklere baktığımızda redirect_uri parametresinin sunucu tarafından doğru bir şekilde kontrol edilmemesi; Open Redirect, Path Traversal, CSRF ve Hesap Ele Geçirme (Account Takeover) gibi birçok kritik zaafiyete kapı aralıyor.