Lab: Password Reset Poisoning via Middleware

Lab: Password Reset Poisoning via Middleware

URL ile Şifre Sıfırlama

Şifre sıfırlama mailindeki bağlantı dinamik olarak oluşturuluyorsa, bu süreç bazen “password reset poisoning” saldırılarına açık olabiliyor. Yani saldırgan, hedef kullanıcının şifre sıfırlama linkini manipüle ederek onun token’ını çalıp şifresini kendi belirlediği şekilde değiştirebiliyor. Aslında küçük bir yönlendirme hatası bile tüm süreci saldırganın lehine çevirebiliyor.

Lab: Password Reset Poisoning via Middleware

Bu yazıda PortSwigger’daki “Password reset poisoning via X-Forwarded-Host” labını, tamamen manuel test yaklaşımıyla nasıl çözdüğümü adım adım anlatıyorum. Lab’ın mantığında şu yatıyor:

“Uygulama, password reset linkini oluştururken X-Forwarded-Host header’ına güveniyor. Biz de bunu exploit server’a yönlendirerek kurbanın password reset token’ını çalıyoruz.”

Kurbanımız Carlos, klasik bir “linke tıklarım, sorun olmaz” yaklaşımına sahip. Biz de bunu kullanıyoruz.

İlk olarak kendi hesabımla giriş yaptım.Lab bana bir kullanıcı hesabı vermişti. Bu hesapla normal bir şekilde giriş yaptım ve uygulamanın temel akışını anlamak için etrafa biraz baktım.

Daha sonra kendi hesabım için Forgot Password işlemini başlattım. Uygulama bana bir e-posta gönderdi ve email client kısmına bir bağlantı düştü. Bu bağlantıyı kullanarak yeni bir şifre belirledim. Böylece normal akışın nasıl işlediğini görmüş oldum.

Şifre sıfırlama işlemi sırasında Burp Suite’e düşen isteklere baktım. Özellikle üç istek dikkatimi çekti:

POST /forgot-password

GET /forgot-password?temp-forgot-password-token=…

POST /forgot-password?temp-forgot-password-token=…

Bu üç istek de temp-forgot-password-token parametresini kullanıyordu. Yani şifre sıfırlama tamamen bu token üzerine kuruluydu.Bu noktada mantık netleşmeye başladı. Eğer bu token bir şekilde manipüle edilebilirse başka bir kullanıcının şifresi de değiştirilebilir.Kendi reset sürecimde aldığım token ile bu isteklerde kullanılan tokenı karşılaştırdığımda, sistemin bu değeri doğrulamadan sadece URL’den okuduğunu fark ettim. Bu da aklıma şu fikri getirdi:Tokenı kendi tokenımdan Carlos’un tokenına çevirirsem onun şifresini ben de sıfırlayabilirim.Ama bunun için önce Carlos’un tokenını ele geçirmem gerekiyordu.

X-Forwarded-Host neden tehlikeli?

X-Forwarded-Host genellikle reverse proxy’ler üzerinden gelen gerçek host bilgisini iletmek için kullanılır. Eğer uygulama bu değeri doğrulamadan reset linki oluşturmak için kullanıyorsa, saldırgan linki kendi kontrolündeki bir domaine yönlendirip token’ı ele geçirebilir.

Labın exploit server özelliğini hatırladım. Uygulamanın X-Forwarded-Host header’ını kabul ettiğini görünce şu header’ı ekledim:

X-Forwarded-Host: exploit-0a5000590454f43580f7751601ef00c8.exploit-server.net

Forgot Password isteğini Repeater’da açıp bu header’ı ekledim ve isteği gönderdim.Bu sayede sistem Carlos için bir reset linki oluşturduğunda linkin host kısmı exploit server adresi olacaktı.Gönderdiğim bu istekten sonra exploit server’ın log sayfasını açtım. Bir süre sonra Carlos’un tıkladığı GET isteği loglarda göründü:

Bu Carlos’un gerçek reset tokenıydı.Artık elimde ihtiyacım olan tüm bilgi var Şifre sıfırlama işleminde kullanılan tüm isteklerde kendi tokenımın yerine Carlos’tan aldığım tokenı koydum.

Böylece sistem benim değil Carlos’un hesabı için şifre yenileme ekranını açtı.Yeni parolayı şöyle belirledim:

pass
pass

İstek başarılıydı. Ardından Carlos’un kullanıcı adıyla giriş yaptığımda lab tamamlanmıştı.

Bu labda esas açık, uygulamanın X-Forwarded-Host header’ına güvenerek reset linkinin host kısmını manipüle edilebilecek şekilde oluşturması. Bu sayede reset tokenı saldırganın kontrol ettiği domaine yönlendirilebiliyor ve token loglardan alınarak hedef kullanıcının şifresi değiştirilebiliyor. Oldukça basit ama etkili bir zafiyetti. Uygun doğrulama yapılmadığında şifre sıfırlama süreçlerinin ne kadar kritik hale geldiğini bir kez daha görmüş oldum.