OAuth ve OpenID Connect (OIDC) Yapılandırma Zaafiyetleri

Enistein

Kıdemli Üye
16 Eyl 2012
2,222
1,230
Amsterdam
f8l1281.png

İyi günler Türk Hack Team ailesi.
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.
Uzun zamandır konu paylaşımı yapmadığım için konu yazma stilimi unutmuş olabilirsiniz :D Önce teorik bilgi ardından pratik bilgi şeklinde ilerleyeceğiz.

Bundan dolayı sonuna kadar okumanızda fayda var.

PpUz4Fr.gif

F3beZqk.png

OAuth Nedir?
F3beZqk.png

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 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 sizin adınıza Facebook'a yönlendirilir. 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 veya kaynaklara erişim sağlamasına izin verir. 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. Yani kısacası aşağıdaki görsel anlamanıza daha yardımcı olabilir.
tzrJldC.png

Kısacası bu tarz yapılara OAuth deriz.


Arka tarafta yapı şu şekildedir:

İlk önce OAuth yaptığımız servis yani Gmail olduğunu varsayıyoruz. Client id ve ilgili oyunun URL'inin bulunduğu bir istek atılır.
GET https://accounts.google.com/o/oauth/v2/auth?client_id=enistein23&redirect_uri=https://hedefurl.com/callback&scope=profile&response_type=code&state=foobar
Herşey yolunda giderse ve kullanıcı izinleri verirse Gmail servisleri token oluşturmak için yeni bir istek oluşturur.
POST www.googleapis.com/oauth2/v4/token
Content-Type: application/x-www-form-urlencodedcode=oGd5GkJs5mKrtgH5&
client_id=enistein123
client_secret=enistein_secret_123&
grant_type=authorization_code
Bununda başarıyla tamamlandığını varsaydığımızda api, kullanıcıya bir token atayıp geri dönecektir.
{
"access_token": "FgrgGsd456GdSghDsgsa3fHg",
"expires_in: 4560,
"token_type": "Bearer"
}

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

OpenID Connect Nedir?

F3beZqk.png

OpenID Connect, anlatım olarak Oauth'a biraz benziyor. Bundan dolayı kafaları yakmamak için konunun hemen başında bir uyarı geçeyim.
OAuth sizi tanıyordu ve verilere erişmek için google gibi bir servisi kullanarak token oluşturmuştu.

Bu noktada OpenID Connect devreye giriyor ve kimlik doğrulama sürecini yönetiyor.

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.
NJupta7.png

OpenID Connect ile bir uygulamaya oturum açmak istediğinizde, uygulama sizi doğrulama sağlayıcısına (örneğin Google, Facebook gibi) yönlendirir.

Doğrulama sağlayıcısı, sizin 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 sizin kimliğinizi doğrular. Böylece uygulama, sizin kimlik bilgilerinizi doğrulama sağlayıcısına sormadan, güvenli bir şekilde oturum açmanızı sağlar.

Örneğin, "Google hesabınızla oturum aç" seçeneğini seçtiğinizde, OpenID Connect protokolü devreye girer. Sizi doğrulama sağlayıcısına yönlendirir, kimlik bilgilerinizi doğrular ve size bir ID token verir. Uygulama bu ID token'ı kullanarak sizin kimliğinizi doğrular ve oturum açma işlemini tamamlar.

dCIvbRz.png

Eğer bu teknolojiler ve standart bir web haberleşmesine aşinanız yoksa çok karışık gelmiş olabilir.
Bilgisayarınızı tekmelemeden önce farklı kaynaklardan da bu yapılar hakkında araştırma yapabilirsiniz.

OAuth ve OpenID Connect Zaafiyetleri
F3beZqk.png

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 realistik senaryoları görmeniz için Hackerone ve gibi platformlarda bildirilmiş olan ve gerçek hayat senaryoları üzerinden anlatımımı gerçekleştireceğim.



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

oMQDyYD.png

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 aslında.
Fakat doğru yapılandırılmadığı takdirde birçok zaafiyete yol açabilir. Bu zaafiyetler arasında, Account Takeover, Token Overflow, vb. gibi birçok farklı yaklaşım olabilir. Saldırı vektörleri biraz hedef websitenin mimarisine göre değişebilir.

Account Takeover
Örneğin JWT kullanılan bir yapıda, websiteye login olurken veya olduktan sonra her isteğimizde aşağıdaki gibi bir parametre yer alır.
DyBBzEd.png

JWT'ler her zaman cookie bilgisi içerisinde tutulmaz. Fakat, öğrendikten sonra header'de nerede olursa olsun gördüğünüzde anlayabilirsiniz.

Ayrıca Burp Suite'de JWT'leri otomatik tespit etmek için belirli araçlar mevcuttur.

Cookie'de yer alan jwt verisini herhangi bir jwt decodere attığımızda şu şekilde gözükür:
jMfC61k.png


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.


JWT'yi kopyalayıp, bir txt dosyasına atıyorum. Ardından John The Ripper ve Rockyou.txt'yi kullanarak kırmayı deniyorum.
Kod:
echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt
eooK5R2.png

Görselde gördüğünüz gibi Secret Key ilovepico olarak çıktı. Artık ben burada istediğim gibi JWT içerisindeki verileri değiştirip, doğrulayıp sunucuya gönderebilirim.
ikrHGd5.png

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.



lQAB20J.png


QTODVh0.png

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


Şimdi biraz da discord eğitimlerinde sürekli üzerinde durmuş olduğum konu
Exploit Chaining yani Zaafiyet Yükseltme veya farklı zaafiyetlerle birleştirmeye bakalım.
Gerçek hayatta yaşadığım bir senaryo.

Oldu da şifreyi kıramadık? Bu durumda açıkta kalan dizinleri tarayarak unutulmuş dosyaları arayabilirsiniz.

Örneğin benim senaryomda bir websitede .env dosyası açıkta kalmış ve içerisinde JWT_SECRET olarak secret key saklanmış.
I9EjKWL.png

Böylece herhangi bir decode işlemiyle uğraşmamıza gerek kalmadı.


Kontrol Edilmeyen Callback Yapıları

OAuth yapıları bir callback ile
evet, ben bu işlemi gerçekleştirdim x kişisine artık yetki verebilirsin şeklinde bir dönüş yaparlar.
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.


files-api.gif


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

Kullanıcı giriş yaparken arkada dönen ş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
Ardından redirect_uri parametresinde yer alan callback url'ini değiştirerek path traversal yapıyor ve başka bir kullanıcıya login olmasını sağlıyor.
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.
vX7ndyY.png


Yani aslında örneklere baktığımızda callback yapısı doğru bir şekilde kontrol edilmediğinde birçok zaafiyeti beraberinde getiriyor.

ycqJxGA.png



Kapanış
F3beZqk.png

Okuduğunuz için teşekkürler. Uzun zamandır konu yazmadığım için biraz paslanmış olabilirim.
Fakat, paslanmadan önce yazdığım o güzel konuları okumak isterseniz linklerini aşağıda bırakıyorum.

 

Suppressor

Request Uzmanı
16 Kas 2022
1,207
718
always, everywhere
f8l1281.png

İyi günler Türk Hack Team ailesi.
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.
Uzun zamandır konu paylaşımı yapmadığım için konu yazma stilimi unutmuş olabilirsiniz :D Önce teorik bilgi ardından pratik bilgi şeklinde ilerleyeceğiz.

Bundan dolayı sonuna kadar okumanızda fayda var.

PpUz4Fr.gif

F3beZqk.png

OAuth Nedir?
F3beZqk.png

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 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 sizin adınıza Facebook'a yönlendirilir. 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 veya kaynaklara erişim sağlamasına izin verir. 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. Yani kısacası aşağıdaki görsel anlamanıza daha yardımcı olabilir.
tzrJldC.png

Kısacası bu tarz yapılara OAuth deriz.


Arka tarafta yapı şu şekildedir:
İlk önce OAuth yaptığımız servis yani Gmail olduğunu varsayıyoruz. Client id ve ilgili oyunun URL'inin bulunduğu bir istek atılır.

Herşey yolunda giderse ve kullanıcı izinleri verirse Gmail servisleri token oluşturmak için yeni bir istek oluşturur.

Bununda başarıyla tamamlandığını varsaydığımızda api, kullanıcıya bir token atayıp geri dönecektir.


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


OpenID Connect Nedir?

F3beZqk.png

OpenID Connect, anlatım olarak Oauth'a biraz benziyor. Bundan dolayı kafaları yakmamak için konunun hemen başında bir uyarı geçeyim.
OAuth sizi tanıyordu ve verilere erişmek için google gibi bir servisi kullanarak token oluşturmuştu.

Bu noktada OpenID Connect devreye giriyor ve kimlik doğrulama sürecini yönetiyor.

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.
NJupta7.png

OpenID Connect ile bir uygulamaya oturum açmak istediğinizde, uygulama sizi doğrulama sağlayıcısına (örneğin Google, Facebook gibi) yönlendirir.

Doğrulama sağlayıcısı, sizin 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 sizin kimliğinizi doğrular. Böylece uygulama, sizin kimlik bilgilerinizi doğrulama sağlayıcısına sormadan, güvenli bir şekilde oturum açmanızı sağlar.

Örneğin, "Google hesabınızla oturum aç" seçeneğini seçtiğinizde, OpenID Connect protokolü devreye girer. Sizi doğrulama sağlayıcısına yönlendirir, kimlik bilgilerinizi doğrular ve size bir ID token verir. Uygulama bu ID token'ı kullanarak sizin kimliğinizi doğrular ve oturum açma işlemini tamamlar.

dCIvbRz.png

Eğer bu teknolojiler ve standart bir web haberleşmesine aşinanız yoksa çok karışık gelmiş olabilir.
Bilgisayarınızı tekmelemeden önce farklı kaynaklardan da bu yapılar hakkında araştırma yapabilirsiniz.

OAuth ve OpenID Connect Zaafiyetleri
F3beZqk.png

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 realistik senaryoları görmeniz için Hackerone ve gibi platformlarda bildirilmiş olan ve gerçek hayat senaryoları üzerinden anlatımımı gerçekleştireceğim.



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

oMQDyYD.png

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 aslında.
Fakat doğru yapılandırılmadığı takdirde birçok zaafiyete yol açabilir. Bu zaafiyetler arasında, Account Takeover, Token Overflow, vb. gibi birçok farklı yaklaşım olabilir. Saldırı vektörleri biraz hedef websitenin mimarisine göre değişebilir.

Account Takeover
Örneğin JWT kullanılan bir yapıda, websiteye login olurken veya olduktan sonra her isteğimizde aşağıdaki gibi bir parametre yer alır.
DyBBzEd.png

JWT'ler her zaman cookie bilgisi içerisinde tutulmaz. Fakat, öğrendikten sonra header'de nerede olursa olsun gördüğünüzde anlayabilirsiniz.

Ayrıca Burp Suite'de JWT'leri otomatik tespit etmek için belirli araçlar mevcuttur.

Cookie'de yer alan jwt verisini herhangi bir jwt decodere attığımızda şu şekilde gözükür:
jMfC61k.png


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.


JWT'yi kopyalayıp, bir txt dosyasına atıyorum. Ardından John The Ripper ve Rockyou.txt'yi kullanarak kırmayı deniyorum.
Kod:
echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt
eooK5R2.png

Görselde gördüğünüz gibi Secret Key ilovepico olarak çıktı. Artık ben burada istediğim gibi JWT içerisindeki verileri değiştirip, doğrulayıp sunucuya gönderebilirim.
ikrHGd5.png

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.



lQAB20J.png


QTODVh0.png

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


Şimdi biraz da discord eğitimlerinde sürekli üzerinde durmuş olduğum konu Exploit Chaining yani Zaafiyet Yükseltme veya farklı zaafiyetlerle birleştirmeye bakalım.
Gerçek hayatta yaşadığım bir senaryo.

Oldu da şifreyi kıramadık? Bu durumda açıkta kalan dizinleri tarayarak unutulmuş dosyaları arayabilirsiniz.

Örneğin benim senaryomda bir websitede .env dosyası açıkta kalmış ve içerisinde JWT_SECRET olarak secret key saklanmış.
I9EjKWL.png

Böylece herhangi bir decode işlemiyle uğraşmamıza gerek kalmadı.


Kontrol Edilmeyen Callback Yapıları

OAuth yapıları bir callback ile
evet, ben bu işlemi gerçekleştirdim x kişisine artık yetki verebilirsin şeklinde bir dönüş yaparlar.
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.


files-api.gif


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

Kullanıcı giriş yaparken arkada dönen şu OAuth yapısını takip ediyor.

Ardından redirect_uri parametresinde yer alan callback url'ini değiştirerek path traversal yapıyor ve başka bir kullanıcıya login olmasını sağlıyor.

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.

vX7ndyY.png


Yani aslında örneklere baktığımızda callback yapısı doğru bir şekilde kontrol edilmediğinde birçok zaafiyeti beraberinde getiriyor.

ycqJxGA.png



Kapanış
F3beZqk.png

Okuduğunuz için teşekkürler. Uzun zamandır konu yazmadığım için biraz paslanmış olabilirim.
Fakat, paslanmadan önce yazdığım o güzel konuları okumak isterseniz linklerini aşağıda bırakıyorum.

Elinize sağlık hocam.
 

kelvinxry

Katılımcı Üye
23 Ara 2022
366
104
f8l1281.png

İyi günler Türk Hack Team ailesi.
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.
Uzun zamandır konu paylaşımı yapmadığım için konu yazma stilimi unutmuş olabilirsiniz :D Önce teorik bilgi ardından pratik bilgi şeklinde ilerleyeceğiz.

Bundan dolayı sonuna kadar okumanızda fayda var.

PpUz4Fr.gif

F3beZqk.png

OAuth Nedir?
F3beZqk.png

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 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 sizin adınıza Facebook'a yönlendirilir. 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 veya kaynaklara erişim sağlamasına izin verir. 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. Yani kısacası aşağıdaki görsel anlamanıza daha yardımcı olabilir.
tzrJldC.png

Kısacası bu tarz yapılara OAuth deriz.


Arka tarafta yapı şu şekildedir:
İlk önce OAuth yaptığımız servis yani Gmail olduğunu varsayıyoruz. Client id ve ilgili oyunun URL'inin bulunduğu bir istek atılır.

Herşey yolunda giderse ve kullanıcı izinleri verirse Gmail servisleri token oluşturmak için yeni bir istek oluşturur.

Bununda başarıyla tamamlandığını varsaydığımızda api, kullanıcıya bir token atayıp geri dönecektir.


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


OpenID Connect Nedir?

F3beZqk.png

OpenID Connect, anlatım olarak Oauth'a biraz benziyor. Bundan dolayı kafaları yakmamak için konunun hemen başında bir uyarı geçeyim.
OAuth sizi tanıyordu ve verilere erişmek için google gibi bir servisi kullanarak token oluşturmuştu.

Bu noktada OpenID Connect devreye giriyor ve kimlik doğrulama sürecini yönetiyor.

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.
NJupta7.png

OpenID Connect ile bir uygulamaya oturum açmak istediğinizde, uygulama sizi doğrulama sağlayıcısına (örneğin Google, Facebook gibi) yönlendirir.

Doğrulama sağlayıcısı, sizin 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 sizin kimliğinizi doğrular. Böylece uygulama, sizin kimlik bilgilerinizi doğrulama sağlayıcısına sormadan, güvenli bir şekilde oturum açmanızı sağlar.

Örneğin, "Google hesabınızla oturum aç" seçeneğini seçtiğinizde, OpenID Connect protokolü devreye girer. Sizi doğrulama sağlayıcısına yönlendirir, kimlik bilgilerinizi doğrular ve size bir ID token verir. Uygulama bu ID token'ı kullanarak sizin kimliğinizi doğrular ve oturum açma işlemini tamamlar.

dCIvbRz.png

Eğer bu teknolojiler ve standart bir web haberleşmesine aşinanız yoksa çok karışık gelmiş olabilir.
Bilgisayarınızı tekmelemeden önce farklı kaynaklardan da bu yapılar hakkında araştırma yapabilirsiniz.

OAuth ve OpenID Connect Zaafiyetleri
F3beZqk.png

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 realistik senaryoları görmeniz için Hackerone ve gibi platformlarda bildirilmiş olan ve gerçek hayat senaryoları üzerinden anlatımımı gerçekleştireceğim.



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

oMQDyYD.png

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 aslında.
Fakat doğru yapılandırılmadığı takdirde birçok zaafiyete yol açabilir. Bu zaafiyetler arasında, Account Takeover, Token Overflow, vb. gibi birçok farklı yaklaşım olabilir. Saldırı vektörleri biraz hedef websitenin mimarisine göre değişebilir.

Account Takeover
Örneğin JWT kullanılan bir yapıda, websiteye login olurken veya olduktan sonra her isteğimizde aşağıdaki gibi bir parametre yer alır.
DyBBzEd.png

JWT'ler her zaman cookie bilgisi içerisinde tutulmaz. Fakat, öğrendikten sonra header'de nerede olursa olsun gördüğünüzde anlayabilirsiniz.

Ayrıca Burp Suite'de JWT'leri otomatik tespit etmek için belirli araçlar mevcuttur.

Cookie'de yer alan jwt verisini herhangi bir jwt decodere attığımızda şu şekilde gözükür:
jMfC61k.png


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.


JWT'yi kopyalayıp, bir txt dosyasına atıyorum. Ardından John The Ripper ve Rockyou.txt'yi kullanarak kırmayı deniyorum.
Kod:
echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt
eooK5R2.png

Görselde gördüğünüz gibi Secret Key ilovepico olarak çıktı. Artık ben burada istediğim gibi JWT içerisindeki verileri değiştirip, doğrulayıp sunucuya gönderebilirim.
ikrHGd5.png

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.



lQAB20J.png


QTODVh0.png

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


Şimdi biraz da discord eğitimlerinde sürekli üzerinde durmuş olduğum konu Exploit Chaining yani Zaafiyet Yükseltme veya farklı zaafiyetlerle birleştirmeye bakalım.
Gerçek hayatta yaşadığım bir senaryo.

Oldu da şifreyi kıramadık? Bu durumda açıkta kalan dizinleri tarayarak unutulmuş dosyaları arayabilirsiniz.

Örneğin benim senaryomda bir websitede .env dosyası açıkta kalmış ve içerisinde JWT_SECRET olarak secret key saklanmış.
I9EjKWL.png

Böylece herhangi bir decode işlemiyle uğraşmamıza gerek kalmadı.


Kontrol Edilmeyen Callback Yapıları

OAuth yapıları bir callback ile
evet, ben bu işlemi gerçekleştirdim x kişisine artık yetki verebilirsin şeklinde bir dönüş yaparlar.
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.


files-api.gif


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

Kullanıcı giriş yaparken arkada dönen şu OAuth yapısını takip ediyor.

Ardından redirect_uri parametresinde yer alan callback url'ini değiştirerek path traversal yapıyor ve başka bir kullanıcıya login olmasını sağlıyor.

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.

vX7ndyY.png


Yani aslında örneklere baktığımızda callback yapısı doğru bir şekilde kontrol edilmediğinde birçok zaafiyeti beraberinde getiriyor.

ycqJxGA.png



Kapanış
F3beZqk.png

Okuduğunuz için teşekkürler. Uzun zamandır konu yazmadığım için biraz paslanmış olabilirim.
Fakat, paslanmadan önce yazdığım o güzel konuları okumak isterseniz linklerini aşağıda bırakıyorum.

Elinize sağlık.
 

QuatrexDefacer

Katılımcı Üye
15 Eki 2022
632
416
Baku
f8l1281.png

İyi günler Türk Hack Team ailesi.
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.
Uzun zamandır konu paylaşımı yapmadığım için konu yazma stilimi unutmuş olabilirsiniz :D Önce teorik bilgi ardından pratik bilgi şeklinde ilerleyeceğiz.

Bundan dolayı sonuna kadar okumanızda fayda var.

PpUz4Fr.gif

F3beZqk.png

OAuth Nedir?
F3beZqk.png

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 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 sizin adınıza Facebook'a yönlendirilir. 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 veya kaynaklara erişim sağlamasına izin verir. 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. Yani kısacası aşağıdaki görsel anlamanıza daha yardımcı olabilir.
tzrJldC.png

Kısacası bu tarz yapılara OAuth deriz.


Arka tarafta yapı şu şekildedir:
İlk önce OAuth yaptığımız servis yani Gmail olduğunu varsayıyoruz. Client id ve ilgili oyunun URL'inin bulunduğu bir istek atılır.

Herşey yolunda giderse ve kullanıcı izinleri verirse Gmail servisleri token oluşturmak için yeni bir istek oluşturur.

Bununda başarıyla tamamlandığını varsaydığımızda api, kullanıcıya bir token atayıp geri dönecektir.


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


OpenID Connect Nedir?

F3beZqk.png

OpenID Connect, anlatım olarak Oauth'a biraz benziyor. Bundan dolayı kafaları yakmamak için konunun hemen başında bir uyarı geçeyim.
OAuth sizi tanıyordu ve verilere erişmek için google gibi bir servisi kullanarak token oluşturmuştu.

Bu noktada OpenID Connect devreye giriyor ve kimlik doğrulama sürecini yönetiyor.

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.
NJupta7.png

OpenID Connect ile bir uygulamaya oturum açmak istediğinizde, uygulama sizi doğrulama sağlayıcısına (örneğin Google, Facebook gibi) yönlendirir.

Doğrulama sağlayıcısı, sizin 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 sizin kimliğinizi doğrular. Böylece uygulama, sizin kimlik bilgilerinizi doğrulama sağlayıcısına sormadan, güvenli bir şekilde oturum açmanızı sağlar.

Örneğin, "Google hesabınızla oturum aç" seçeneğini seçtiğinizde, OpenID Connect protokolü devreye girer. Sizi doğrulama sağlayıcısına yönlendirir, kimlik bilgilerinizi doğrular ve size bir ID token verir. Uygulama bu ID token'ı kullanarak sizin kimliğinizi doğrular ve oturum açma işlemini tamamlar.

dCIvbRz.png

Eğer bu teknolojiler ve standart bir web haberleşmesine aşinanız yoksa çok karışık gelmiş olabilir.
Bilgisayarınızı tekmelemeden önce farklı kaynaklardan da bu yapılar hakkında araştırma yapabilirsiniz.

OAuth ve OpenID Connect Zaafiyetleri
F3beZqk.png

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 realistik senaryoları görmeniz için Hackerone ve gibi platformlarda bildirilmiş olan ve gerçek hayat senaryoları üzerinden anlatımımı gerçekleştireceğim.



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

oMQDyYD.png

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 aslında.
Fakat doğru yapılandırılmadığı takdirde birçok zaafiyete yol açabilir. Bu zaafiyetler arasında, Account Takeover, Token Overflow, vb. gibi birçok farklı yaklaşım olabilir. Saldırı vektörleri biraz hedef websitenin mimarisine göre değişebilir.

Account Takeover
Örneğin JWT kullanılan bir yapıda, websiteye login olurken veya olduktan sonra her isteğimizde aşağıdaki gibi bir parametre yer alır.
DyBBzEd.png

JWT'ler her zaman cookie bilgisi içerisinde tutulmaz. Fakat, öğrendikten sonra header'de nerede olursa olsun gördüğünüzde anlayabilirsiniz.

Ayrıca Burp Suite'de JWT'leri otomatik tespit etmek için belirli araçlar mevcuttur.

Cookie'de yer alan jwt verisini herhangi bir jwt decodere attığımızda şu şekilde gözükür:
jMfC61k.png


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.


JWT'yi kopyalayıp, bir txt dosyasına atıyorum. Ardından John The Ripper ve Rockyou.txt'yi kullanarak kırmayı deniyorum.
Kod:
echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt
eooK5R2.png

Görselde gördüğünüz gibi Secret Key ilovepico olarak çıktı. Artık ben burada istediğim gibi JWT içerisindeki verileri değiştirip, doğrulayıp sunucuya gönderebilirim.
ikrHGd5.png

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.



lQAB20J.png


QTODVh0.png

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


Şimdi biraz da discord eğitimlerinde sürekli üzerinde durmuş olduğum konu Exploit Chaining yani Zaafiyet Yükseltme veya farklı zaafiyetlerle birleştirmeye bakalım.
Gerçek hayatta yaşadığım bir senaryo.

Oldu da şifreyi kıramadık? Bu durumda açıkta kalan dizinleri tarayarak unutulmuş dosyaları arayabilirsiniz.

Örneğin benim senaryomda bir websitede .env dosyası açıkta kalmış ve içerisinde JWT_SECRET olarak secret key saklanmış.
I9EjKWL.png

Böylece herhangi bir decode işlemiyle uğraşmamıza gerek kalmadı.


Kontrol Edilmeyen Callback Yapıları

OAuth yapıları bir callback ile
evet, ben bu işlemi gerçekleştirdim x kişisine artık yetki verebilirsin şeklinde bir dönüş yaparlar.
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.


files-api.gif


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

Kullanıcı giriş yaparken arkada dönen şu OAuth yapısını takip ediyor.

Ardından redirect_uri parametresinde yer alan callback url'ini değiştirerek path traversal yapıyor ve başka bir kullanıcıya login olmasını sağlıyor.

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.

vX7ndyY.png


Yani aslında örneklere baktığımızda callback yapısı doğru bir şekilde kontrol edilmediğinde birçok zaafiyeti beraberinde getiriyor.

ycqJxGA.png



Kapanış
F3beZqk.png

Okuduğunuz için teşekkürler. Uzun zamandır konu yazmadığım için biraz paslanmış olabilirim.
Fakat, paslanmadan önce yazdığım o güzel konuları okumak isterseniz linklerini aşağıda bırakıyorum.

eline saglk hocam yara​
eline saglk hocam yararli konu​
 

hoaydar

Ar-Ge Ekibi
18 Ocak 2023
492
420
/system32
f8l1281.png

İyi günler Türk Hack Team ailesi.
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.
Uzun zamandır konu paylaşımı yapmadığım için konu yazma stilimi unutmuş olabilirsiniz :D Önce teorik bilgi ardından pratik bilgi şeklinde ilerleyeceğiz.

Bundan dolayı sonuna kadar okumanızda fayda var.

PpUz4Fr.gif

F3beZqk.png

OAuth Nedir?
F3beZqk.png

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 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 sizin adınıza Facebook'a yönlendirilir. 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 veya kaynaklara erişim sağlamasına izin verir. 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. Yani kısacası aşağıdaki görsel anlamanıza daha yardımcı olabilir.
tzrJldC.png

Kısacası bu tarz yapılara OAuth deriz.


Arka tarafta yapı şu şekildedir:
İlk önce OAuth yaptığımız servis yani Gmail olduğunu varsayıyoruz. Client id ve ilgili oyunun URL'inin bulunduğu bir istek atılır.

Herşey yolunda giderse ve kullanıcı izinleri verirse Gmail servisleri token oluşturmak için yeni bir istek oluşturur.

Bununda başarıyla tamamlandığını varsaydığımızda api, kullanıcıya bir token atayıp geri dönecektir.


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


OpenID Connect Nedir?

F3beZqk.png

OpenID Connect, anlatım olarak Oauth'a biraz benziyor. Bundan dolayı kafaları yakmamak için konunun hemen başında bir uyarı geçeyim.
OAuth sizi tanıyordu ve verilere erişmek için google gibi bir servisi kullanarak token oluşturmuştu.

Bu noktada OpenID Connect devreye giriyor ve kimlik doğrulama sürecini yönetiyor.

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.
NJupta7.png

OpenID Connect ile bir uygulamaya oturum açmak istediğinizde, uygulama sizi doğrulama sağlayıcısına (örneğin Google, Facebook gibi) yönlendirir.

Doğrulama sağlayıcısı, sizin 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 sizin kimliğinizi doğrular. Böylece uygulama, sizin kimlik bilgilerinizi doğrulama sağlayıcısına sormadan, güvenli bir şekilde oturum açmanızı sağlar.

Örneğin, "Google hesabınızla oturum aç" seçeneğini seçtiğinizde, OpenID Connect protokolü devreye girer. Sizi doğrulama sağlayıcısına yönlendirir, kimlik bilgilerinizi doğrular ve size bir ID token verir. Uygulama bu ID token'ı kullanarak sizin kimliğinizi doğrular ve oturum açma işlemini tamamlar.

dCIvbRz.png

Eğer bu teknolojiler ve standart bir web haberleşmesine aşinanız yoksa çok karışık gelmiş olabilir.
Bilgisayarınızı tekmelemeden önce farklı kaynaklardan da bu yapılar hakkında araştırma yapabilirsiniz.

OAuth ve OpenID Connect Zaafiyetleri
F3beZqk.png

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 realistik senaryoları görmeniz için Hackerone ve gibi platformlarda bildirilmiş olan ve gerçek hayat senaryoları üzerinden anlatımımı gerçekleştireceğim.



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

oMQDyYD.png

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 aslında.
Fakat doğru yapılandırılmadığı takdirde birçok zaafiyete yol açabilir. Bu zaafiyetler arasında, Account Takeover, Token Overflow, vb. gibi birçok farklı yaklaşım olabilir. Saldırı vektörleri biraz hedef websitenin mimarisine göre değişebilir.

Account Takeover
Örneğin JWT kullanılan bir yapıda, websiteye login olurken veya olduktan sonra her isteğimizde aşağıdaki gibi bir parametre yer alır.
DyBBzEd.png

JWT'ler her zaman cookie bilgisi içerisinde tutulmaz. Fakat, öğrendikten sonra header'de nerede olursa olsun gördüğünüzde anlayabilirsiniz.

Ayrıca Burp Suite'de JWT'leri otomatik tespit etmek için belirli araçlar mevcuttur.

Cookie'de yer alan jwt verisini herhangi bir jwt decodere attığımızda şu şekilde gözükür:
jMfC61k.png


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.


JWT'yi kopyalayıp, bir txt dosyasına atıyorum. Ardından John The Ripper ve Rockyou.txt'yi kullanarak kırmayı deniyorum.
Kod:
echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt
eooK5R2.png

Görselde gördüğünüz gibi Secret Key ilovepico olarak çıktı. Artık ben burada istediğim gibi JWT içerisindeki verileri değiştirip, doğrulayıp sunucuya gönderebilirim.
ikrHGd5.png

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.



lQAB20J.png


QTODVh0.png

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


Şimdi biraz da discord eğitimlerinde sürekli üzerinde durmuş olduğum konu Exploit Chaining yani Zaafiyet Yükseltme veya farklı zaafiyetlerle birleştirmeye bakalım.
Gerçek hayatta yaşadığım bir senaryo.

Oldu da şifreyi kıramadık? Bu durumda açıkta kalan dizinleri tarayarak unutulmuş dosyaları arayabilirsiniz.

Örneğin benim senaryomda bir websitede .env dosyası açıkta kalmış ve içerisinde JWT_SECRET olarak secret key saklanmış.
I9EjKWL.png

Böylece herhangi bir decode işlemiyle uğraşmamıza gerek kalmadı.


Kontrol Edilmeyen Callback Yapıları

OAuth yapıları bir callback ile
evet, ben bu işlemi gerçekleştirdim x kişisine artık yetki verebilirsin şeklinde bir dönüş yaparlar.
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.


files-api.gif


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

Kullanıcı giriş yaparken arkada dönen şu OAuth yapısını takip ediyor.

Ardından redirect_uri parametresinde yer alan callback url'ini değiştirerek path traversal yapıyor ve başka bir kullanıcıya login olmasını sağlıyor.

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.

vX7ndyY.png


Yani aslında örneklere baktığımızda callback yapısı doğru bir şekilde kontrol edilmediğinde birçok zaafiyeti beraberinde getiriyor.

ycqJxGA.png



Kapanış
F3beZqk.png

Okuduğunuz için teşekkürler. Uzun zamandır konu yazmadığım için biraz paslanmış olabilirim.
Fakat, paslanmadan önce yazdığım o güzel konuları okumak isterseniz linklerini aşağıda bırakıyorum.

Elinize sağlık mükemmel bir konu olmuş
 

gostking

Katılımcı Üye
29 Nis 2020
362
688
Vatan
f8l1281.png

İyi günler Türk Hack Team ailesi.
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.
Uzun zamandır konu paylaşımı yapmadığım için konu yazma stilimi unutmuş olabilirsiniz :D Önce teorik bilgi ardından pratik bilgi şeklinde ilerleyeceğiz.

Bundan dolayı sonuna kadar okumanızda fayda var.

PpUz4Fr.gif

F3beZqk.png

OAuth Nedir?
F3beZqk.png

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 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 sizin adınıza Facebook'a yönlendirilir. 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 veya kaynaklara erişim sağlamasına izin verir. 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. Yani kısacası aşağıdaki görsel anlamanıza daha yardımcı olabilir.
tzrJldC.png

Kısacası bu tarz yapılara OAuth deriz.


Arka tarafta yapı şu şekildedir:
İlk önce OAuth yaptığımız servis yani Gmail olduğunu varsayıyoruz. Client id ve ilgili oyunun URL'inin bulunduğu bir istek atılır.

Herşey yolunda giderse ve kullanıcı izinleri verirse Gmail servisleri token oluşturmak için yeni bir istek oluşturur.

Bununda başarıyla tamamlandığını varsaydığımızda api, kullanıcıya bir token atayıp geri dönecektir.


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


OpenID Connect Nedir?

F3beZqk.png

OpenID Connect, anlatım olarak Oauth'a biraz benziyor. Bundan dolayı kafaları yakmamak için konunun hemen başında bir uyarı geçeyim.
OAuth sizi tanıyordu ve verilere erişmek için google gibi bir servisi kullanarak token oluşturmuştu.

Bu noktada OpenID Connect devreye giriyor ve kimlik doğrulama sürecini yönetiyor.

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.
NJupta7.png

OpenID Connect ile bir uygulamaya oturum açmak istediğinizde, uygulama sizi doğrulama sağlayıcısına (örneğin Google, Facebook gibi) yönlendirir.

Doğrulama sağlayıcısı, sizin 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 sizin kimliğinizi doğrular. Böylece uygulama, sizin kimlik bilgilerinizi doğrulama sağlayıcısına sormadan, güvenli bir şekilde oturum açmanızı sağlar.

Örneğin, "Google hesabınızla oturum aç" seçeneğini seçtiğinizde, OpenID Connect protokolü devreye girer. Sizi doğrulama sağlayıcısına yönlendirir, kimlik bilgilerinizi doğrular ve size bir ID token verir. Uygulama bu ID token'ı kullanarak sizin kimliğinizi doğrular ve oturum açma işlemini tamamlar.

dCIvbRz.png

Eğer bu teknolojiler ve standart bir web haberleşmesine aşinanız yoksa çok karışık gelmiş olabilir.
Bilgisayarınızı tekmelemeden önce farklı kaynaklardan da bu yapılar hakkında araştırma yapabilirsiniz.

OAuth ve OpenID Connect Zaafiyetleri
F3beZqk.png

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 realistik senaryoları görmeniz için Hackerone ve gibi platformlarda bildirilmiş olan ve gerçek hayat senaryoları üzerinden anlatımımı gerçekleştireceğim.



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

oMQDyYD.png

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 aslında.
Fakat doğru yapılandırılmadığı takdirde birçok zaafiyete yol açabilir. Bu zaafiyetler arasında, Account Takeover, Token Overflow, vb. gibi birçok farklı yaklaşım olabilir. Saldırı vektörleri biraz hedef websitenin mimarisine göre değişebilir.

Account Takeover
Örneğin JWT kullanılan bir yapıda, websiteye login olurken veya olduktan sonra her isteğimizde aşağıdaki gibi bir parametre yer alır.
DyBBzEd.png

JWT'ler her zaman cookie bilgisi içerisinde tutulmaz. Fakat, öğrendikten sonra header'de nerede olursa olsun gördüğünüzde anlayabilirsiniz.

Ayrıca Burp Suite'de JWT'leri otomatik tespit etmek için belirli araçlar mevcuttur.

Cookie'de yer alan jwt verisini herhangi bir jwt decodere attığımızda şu şekilde gözükür:
jMfC61k.png


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.


JWT'yi kopyalayıp, bir txt dosyasına atıyorum. Ardından John The Ripper ve Rockyou.txt'yi kullanarak kırmayı deniyorum.
Kod:
echo "jwttokeniniz" > jwt.txt
./john jwt.txt --format=HMAC-SHA256 --wordlist=wordlist/dizini/rockyou.txt
eooK5R2.png

Görselde gördüğünüz gibi Secret Key ilovepico olarak çıktı. Artık ben burada istediğim gibi JWT içerisindeki verileri değiştirip, doğrulayıp sunucuya gönderebilirim.
ikrHGd5.png

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.



lQAB20J.png


QTODVh0.png

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


Şimdi biraz da discord eğitimlerinde sürekli üzerinde durmuş olduğum konu Exploit Chaining yani Zaafiyet Yükseltme veya farklı zaafiyetlerle birleştirmeye bakalım.
Gerçek hayatta yaşadığım bir senaryo.

Oldu da şifreyi kıramadık? Bu durumda açıkta kalan dizinleri tarayarak unutulmuş dosyaları arayabilirsiniz.

Örneğin benim senaryomda bir websitede .env dosyası açıkta kalmış ve içerisinde JWT_SECRET olarak secret key saklanmış.
I9EjKWL.png

Böylece herhangi bir decode işlemiyle uğraşmamıza gerek kalmadı.


Kontrol Edilmeyen Callback Yapıları

OAuth yapıları bir callback ile
evet, ben bu işlemi gerçekleştirdim x kişisine artık yetki verebilirsin şeklinde bir dönüş yaparlar.
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.


files-api.gif


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

Kullanıcı giriş yaparken arkada dönen şu OAuth yapısını takip ediyor.

Ardından redirect_uri parametresinde yer alan callback url'ini değiştirerek path traversal yapıyor ve başka bir kullanıcıya login olmasını sağlıyor.

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.

vX7ndyY.png


Yani aslında örneklere baktığımızda callback yapısı doğru bir şekilde kontrol edilmediğinde birçok zaafiyeti beraberinde getiriyor.

ycqJxGA.png



Kapanış
F3beZqk.png

Okuduğunuz için teşekkürler. Uzun zamandır konu yazmadığım için biraz paslanmış olabilirim.
Fakat, paslanmadan önce yazdığım o güzel konuları okumak isterseniz linklerini aşağıda bırakıyorum.

elinize emeğinize sağlık
 
Üst

Turkhackteam.org internet sitesi 5651 sayılı kanun’un 2. maddesinin 1. fıkrasının m) bendi ile aynı kanunun 5. maddesi kapsamında "Yer Sağlayıcı" konumundadır. İçerikler ön onay olmaksızın tamamen kullanıcılar tarafından oluşturulmaktadır. Turkhackteam.org; Yer sağlayıcı olarak, kullanıcılar tarafından oluşturulan içeriği ya da hukuka aykırı paylaşımı kontrol etmekle ya da araştırmakla yükümlü değildir. Türkhackteam saldırı timleri Türk sitelerine hiçbir zararlı faaliyette bulunmaz. Türkhackteam üyelerinin yaptığı bireysel hack faaliyetlerinden Türkhackteam sorumlu değildir. Sitelerinize Türkhackteam ismi kullanılarak hack faaliyetinde bulunulursa, site-sunucu erişim loglarından bu faaliyeti gerçekleştiren ip adresini tespit edip diğer kanıtlarla birlikte savcılığa suç duyurusunda bulununuz.