Merhabalar,
Bugünkü konuda Portswigger firmasının kendini geliştirmek isteyenler için oluşturmuş olduğu Web Security Academy içerisinde bulunan CSRF where token is tied to non-session cookie adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token is tied to non-session cookie | Web Security Academy
Her zaman olduğu gibi bu lab diğer önceki çözdüğümüz yöntemler ile çözülememekte. Gerçek bir seneryo örneği bakımından hepsini deneyerek bulguları göstermek isterdim fakat konunun asıl amacı dışına çıkmamak ve konuyu çokta uzun tutmamak için denemeyeceğim. Bir önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 4
Bir önceki lab olduğu gibi CSRF açığının web uygulamasındaki kullanıcıların email değiştirme fonksiyonunda ortaya çıktığını biliyoruz. Bu yüzden doğrudan web uygulamasına eriştikten sonra login olarak devam edebiliriz.
Her zaman olduğu gibi güvenlik testlerimizi gerçekleştirmek adına örnek bir mail giriyoruz ve giden requesti yakalayıp incelemeye başlıyoruz.
Altını kırmızı ile çektiğim kısımlara bakarsanız diğer lablarda karşılaşmadığımız bir durum mevcut. Body ksımında giden csrf token haricinde ayrıca cookie olarak csrfKey tanımlanmış. Bir diğer dikkat edilmesi gereken nokta iki değerin birbirinden farklı olması. Yani double submit gibi bir durum söz konusu değil.
Konunun başında da belirttiğim gibi bir önceki çözümlerimizin hepsini konuyu uzun tutmamak açısından denemeyeceğim fakat uygulamanın mekanizmasını anlamamız açısından kısa bir noktaya değineceğim. Öncelikle lab testlerimizi gerçekleştirmemiz için bize wiener ve carlos adında 2 hesap sağlıyor. Böylece saldırıyı 2 hesap üzerinden tekrar edip sonuçlarını inceleyebiliriz.
Bir önceki lab çözümünde ortak bir token havuzu olduğunu ve bu token'in ilgili kullanıcıya bağlı olup olmadığını kontrol etmediği için csrf saldırısı gerçekleştirebilmiştik. Burada body içerisindeki csrf parametresini ve değerini alıp diğer hesap üzerinde kullanmayı denediğimizde hata alıyoruz. Aynı şekilde csrfKey içinde öyle.
Bu anlattıklarımın sonucunda çıkarım yapmaya çalışırsak body içerisinde giden csrf token ile cookie de giden csrfKey değerleri birbirine bağlı olabilir. Yani requesti gönderdiğimizde back-end sistemi iki değerin eşleşip eşleşmediğini kontrol ediyor olabilir. Bunu öğrenmek için 1. hesabımız olan wiener ile yukarıdaki görseldeki requesti oluşturuyor ve csrf ile csrfKey değerlerini alıyoruz, daha sonrasında carlos hesabımıza geçip aynı requesti oluşturduktan sonra wiener hesabından elde ettiğimiz csrf ile csrfKey değerlerini değiştiriyoruz ve sonucu incelediğimizde başarılı olduğunu görüyoruz.
Artık web uygulmasının email fonksiyonunda CSRF zafiyeti olduğunu biliyoruz fakat bizim bu saldırıyı gerçekleştirebilmemiz için hedefimizdeki kişinin csrfKey parametresinede müdahale etmeliyiz. Bunun içinde Http Header Injection yapmaya ihtiyacımız var. Sırada web uygulamasında header injection zafiyeti aramak var.
Uygulamanın ana sayfasında bulunan arama fonksiyonunu test ettiğimizde yukarıdaki görseldeki gibi arattığımız kelimenin response header içerisinde bize geri yansıdığını görüyoruz. Bizim istediğimiz hedef kişiye istediğimiz csrfKey cookie tanımlamak olduğu için response header içerisinde bir alt satıra inip kendi parametremizi tanımlamayı deneyeceğiz.
Bir satır aşağıya inmek URL encoding için %0a anlamına gelmektedir. Yukarıdaki görselde altığını çizdiğim gibi test%0aFahrettin-Altay yazdığımda %0a sonrası bir alt satırdan devam etmekte. Buradan sonrasında istediğimiz cookie enjekte edebiliriz.
Bizim enjekte etmek istediğimiz saldırı kodunun son hali yukarıdaki görseldeki şekilde. Gereken her şeyi bulduğumuza göre artık son aşama olan CSRF PoC oluşturma aşamasına geçebiliriz.
Burada CSRF PoC kodunu incelecek olursak seneryodaki hedef kişi bu kodu yüklediğimiz siteye tıkladığında öncelikle tarayıcı <img> tagını gördüp resmi yüklemek için src değerinde belirtilen kaynağa ulaşmaya çalışacak ve bunu yaptığında bizim istediğimiz csrfKey parametresi cookie olarak set edilecek fakat kaynak resim içermediği için onerror kısmında yazan javascript kodunu çalıştıracak. Bu kod diğer lab çözümlerindeki PoC kodları gibi email değiştirme fonksiyonuna istediğimiz parametrelerle birlikte request gönderecek ve sonuç olarak hedef kişinin maili bizim belirttiğimiz mail ile değişecek.
İşlemleri benim gibi uyguladığınız taktirde sorunsuz bir şekilde labı başarı ile çözdüğümüzü görüyoruz.
Anlatımlarımda doğrudan lab çözümünü göstermek yerine saldırganın düşünme metodolojisini ve uygulama analizini göstermeye çalıştım ki bu labların çözülme amacında yalnızca çözmüş olmak için çözmek değil bu lablar vesilesi ile kendi düşünme metodolojilerinizi geliştirip bakış açısını kazanabilmek ve zafiyeti doğada nasıl arayacağınızı ve exploit edeceğinizi anlamak.
Okuduğunuz için teşekkür ederim, işinize yaradıysa ne mutlu bana. Anlamadığınız veya takıldığınız bir yer olursa sormaktan çekinmeyin, elimden geldiğince yardımcı olmaya çalışırım.
Bugünkü konuda Portswigger firmasının kendini geliştirmek isteyenler için oluşturmuş olduğu Web Security Academy içerisinde bulunan CSRF where token is tied to non-session cookie adlı labın çözümünü anlatacağım.
İlgili lab linki: Lab: CSRF where token is tied to non-session cookie | Web Security Academy
Her zaman olduğu gibi bu lab diğer önceki çözdüğümüz yöntemler ile çözülememekte. Gerçek bir seneryo örneği bakımından hepsini deneyerek bulguları göstermek isterdim fakat konunun asıl amacı dışına çıkmamak ve konuyu çokta uzun tutmamak için denemeyeceğim. Bir önceki konuyu okumayanlar buradan ulaşabilirler -> Web Security Academy | CSRF - Lab 4
Bir önceki lab olduğu gibi CSRF açığının web uygulamasındaki kullanıcıların email değiştirme fonksiyonunda ortaya çıktığını biliyoruz. Bu yüzden doğrudan web uygulamasına eriştikten sonra login olarak devam edebiliriz.
Her zaman olduğu gibi güvenlik testlerimizi gerçekleştirmek adına örnek bir mail giriyoruz ve giden requesti yakalayıp incelemeye başlıyoruz.
Altını kırmızı ile çektiğim kısımlara bakarsanız diğer lablarda karşılaşmadığımız bir durum mevcut. Body ksımında giden csrf token haricinde ayrıca cookie olarak csrfKey tanımlanmış. Bir diğer dikkat edilmesi gereken nokta iki değerin birbirinden farklı olması. Yani double submit gibi bir durum söz konusu değil.
Konunun başında da belirttiğim gibi bir önceki çözümlerimizin hepsini konuyu uzun tutmamak açısından denemeyeceğim fakat uygulamanın mekanizmasını anlamamız açısından kısa bir noktaya değineceğim. Öncelikle lab testlerimizi gerçekleştirmemiz için bize wiener ve carlos adında 2 hesap sağlıyor. Böylece saldırıyı 2 hesap üzerinden tekrar edip sonuçlarını inceleyebiliriz.
Bir önceki lab çözümünde ortak bir token havuzu olduğunu ve bu token'in ilgili kullanıcıya bağlı olup olmadığını kontrol etmediği için csrf saldırısı gerçekleştirebilmiştik. Burada body içerisindeki csrf parametresini ve değerini alıp diğer hesap üzerinde kullanmayı denediğimizde hata alıyoruz. Aynı şekilde csrfKey içinde öyle.
Bu anlattıklarımın sonucunda çıkarım yapmaya çalışırsak body içerisinde giden csrf token ile cookie de giden csrfKey değerleri birbirine bağlı olabilir. Yani requesti gönderdiğimizde back-end sistemi iki değerin eşleşip eşleşmediğini kontrol ediyor olabilir. Bunu öğrenmek için 1. hesabımız olan wiener ile yukarıdaki görseldeki requesti oluşturuyor ve csrf ile csrfKey değerlerini alıyoruz, daha sonrasında carlos hesabımıza geçip aynı requesti oluşturduktan sonra wiener hesabından elde ettiğimiz csrf ile csrfKey değerlerini değiştiriyoruz ve sonucu incelediğimizde başarılı olduğunu görüyoruz.
Artık web uygulmasının email fonksiyonunda CSRF zafiyeti olduğunu biliyoruz fakat bizim bu saldırıyı gerçekleştirebilmemiz için hedefimizdeki kişinin csrfKey parametresinede müdahale etmeliyiz. Bunun içinde Http Header Injection yapmaya ihtiyacımız var. Sırada web uygulamasında header injection zafiyeti aramak var.
Uygulamanın ana sayfasında bulunan arama fonksiyonunu test ettiğimizde yukarıdaki görseldeki gibi arattığımız kelimenin response header içerisinde bize geri yansıdığını görüyoruz. Bizim istediğimiz hedef kişiye istediğimiz csrfKey cookie tanımlamak olduğu için response header içerisinde bir alt satıra inip kendi parametremizi tanımlamayı deneyeceğiz.
Bir satır aşağıya inmek URL encoding için %0a anlamına gelmektedir. Yukarıdaki görselde altığını çizdiğim gibi test%0aFahrettin-Altay yazdığımda %0a sonrası bir alt satırdan devam etmekte. Buradan sonrasında istediğimiz cookie enjekte edebiliriz.
Bizim enjekte etmek istediğimiz saldırı kodunun son hali yukarıdaki görseldeki şekilde. Gereken her şeyi bulduğumuza göre artık son aşama olan CSRF PoC oluşturma aşamasına geçebiliriz.
HTML:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0aeb00d104d42ec6c0a4096700a400b6.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="fahrettin@altay.tht" />
<input type="hidden" name="csrf" value="UxVmMFpyqYFIPNq05NUaE3Arr8qGxWmV" />
<input type="submit" value="Submit request" />
</form>
<img src="https://SIZIN-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=Cf3YsJAbYDK4IOzV4S6aar2YSbBO48uh" onerror="document.forms[0].submit()"
</body>
</html>Burada CSRF PoC kodunu incelecek olursak seneryodaki hedef kişi bu kodu yüklediğimiz siteye tıkladığında öncelikle tarayıcı <img> tagını gördüp resmi yüklemek için src değerinde belirtilen kaynağa ulaşmaya çalışacak ve bunu yaptığında bizim istediğimiz csrfKey parametresi cookie olarak set edilecek fakat kaynak resim içermediği için onerror kısmında yazan javascript kodunu çalıştıracak. Bu kod diğer lab çözümlerindeki PoC kodları gibi email değiştirme fonksiyonuna istediğimiz parametrelerle birlikte request gönderecek ve sonuç olarak hedef kişinin maili bizim belirttiğimiz mail ile değişecek.
İşlemleri benim gibi uyguladığınız taktirde sorunsuz bir şekilde labı başarı ile çözdüğümüzü görüyoruz.
Anlatımlarımda doğrudan lab çözümünü göstermek yerine saldırganın düşünme metodolojisini ve uygulama analizini göstermeye çalıştım ki bu labların çözülme amacında yalnızca çözmüş olmak için çözmek değil bu lablar vesilesi ile kendi düşünme metodolojilerinizi geliştirip bakış açısını kazanabilmek ve zafiyeti doğada nasıl arayacağınızı ve exploit edeceğinizi anlamak.
Okuduğunuz için teşekkür ederim, işinize yaradıysa ne mutlu bana. Anlamadığınız veya takıldığınız bir yer olursa sormaktan çekinmeyin, elimden geldiğince yardımcı olmaya çalışırım.
