PORTSWIGGER WEB SECURITY - BUSINESS LOGIC VULNERABILITIES LAB ÇÖZÜMLERİ
Business Logic (İş Mantığı) zafiyeti, bir web uygulamasının tasarımında ve uygulamasında, saldırganın istenmeyen davranışlar sergilemesine olanak tanıyan bir web zafiyetidir. Uygulama mantığının hatalı yapılandırılmasından kaynaklanan bu zafiyet, developerlar tarafından web uygulamasında tanımlanan kuralların ve kısıtlamaların bypass edilerek, uygulamanın çalışma mantığının ihlaline neden olabilir.
Bu çalışmada bahsedilen Business Logic zafiyeti için tüm laboratuvar çözümleri ele alınmıştır. Keyifli okumalar..
Lab 1: Excessive trust in client-side controls
Bir saldırgan, tarayıcı tarafından gönderilen isteği sunucuya ulaşmadan Burp Proxy gibi araçları kullanarak verileri inceleyebilir. Web sayfasında yapamayacağı değişiklikleri, istek üzerinde yapabilir ve gerekli kontroller sağlanmıyorsa saldırılar düzenleyebilir. Gönderilen veriler sunucu tarafından denetlenmeden kabul edildiğinde, web sayfası için ciddi hasarlar oluşturabilmektedir.
Bu e-ticaret sitesinde kullanıcı girişi yeterince doğrulanmadığından, istenilmeyen bir fiyata ürün sipariş edilebilmektedir.
Laboratuvarda login olabileceğimiz bir hesap (wiener:peter) tanımlanmıştır. Bu hesap bilgisiyle login olduğumuzda 100$ kredimiz olduğunu görüyoruz.
Sayfa üzerinde Lightweight l33t leather jacket başlıklı ürünü görüntüleyelim. Ürün hakkında detaylı bir açıklama yapılmaktadır. Add to cart seçeneği ile ürünü sepete ekleyebiliriz fakat ilk olarak gönderilen isteği burp suite aracıyla inceleyeceğiz.
Gönderilen istekte, 133700 değerini içeren price (fiyat) parametresi yer almaktadır. Bu parametre sepete eklenecek ürünün fiyatını (1337$) göstermektedir. İsteği repeatera gönderelim ve ardından isteği forward edelim.
Sepeti görüntülediğimizde eklediğimiz ürünün fiyatı ve adedi mevcuttur. Yeterli kredimiz olmadığı için bu ürünü sipariş veremiyoruz.
price parametresi yeterince doğrulanmamaktadır. Bu nedenle mevcut kredimizden daha düşük bir tutar (13$) tanımlayıp, isteği send ettiğimizde herhangi bir hata almayacağız.
Sepeti tekrar görüntülediğimizde ürün fiyatının 13$ olarak değiştiğini gözlemleyelim. Kredimizden daha düşük bir tutar tanımlamıştık artık sipariş verebiliriz.
Sipariş verdikten sonra 1337$ değerinde olan ürünü 13$’a satın almış olduk. Laboratuvarın çözümü bu şekildedir.
Lab 2: High-level logic vulnerability
Bir e-ticaret sitesinde ürün sipariş ederken, kullanıcılar genellikle sipariş etmek istedikleri miktarı belirtebilir. Web sayfasında ürün miktarı için değerler pozitiftir fakat burp suite gibi proxy araçları ile ürün miktarı negatif bir sayı olarak verilebilir. Bu nedenle web uygulamasında giriş kontrollerinin doğru bir şekilde yapılması elzemdir. Developerların, tüm olası senaryoları tahmin etmesi ve bunları uygulama mantığına işlemeleri gerekmektedir.
Web sayfasında kullanıcı girişi yeterince doğrulanmadığından istenilmeyen bir fiyata ürün satın alınabilmektedir. Bir önceki laboratuvarda price parametresi üzerinden hareket etmiştik. Bu bölümde quantity parametresi üzerinden hareket edeceğiz.
Sayfa üzerinde, kredimiz (100$) kapsamında bir ürün seçelim. Add to cart seçeneği ile ürünü sepete ekleyelim ve gönderilen isteği burp suite aracıyla inceleyelim. Ürün miktarının 1 olduğunu quantity parametresinde görebiliriz. İsteği forward ettiğimizde sepete ilgili üründen bir adet eklenecektir.
Sepetimizde The Trapster adlı bir ürün mevcut ve bunun maliyeti 21.41$’dır. İstek üzerinde quantity değerini -10 olarak değişip send edelim.
Sepetteki ürün sayısının 1 iken -9 olduğunu göreceğiz. Totalde ise ürünlerin fiyatı -192.69$ olarak değişmiştir. Zafiyetin varlığını tespit ettiğimize göre bunu nasıl istismar edebileceğimizi görelim.
Şimdi sayfadaki en pahalı ürünü sepete ekleyelim. Total değeri kredi değerimiz kapsamında olmadığı için burp aracıyla sayfaya yeni bir istek gönderelim.
quantity değerini -52 olarak verdiğimiz zaman bu sepetteki The Trapster ürününün miktarı -61 olacaktır. The Trapster ürünün toplam maliyeti -1306.01$ etmekte ve sepetteki ürünlerin toplam total değeri 30.99$ olmaktadır.
Görüldüğü üzere bu şekilde yanlış yapılandırılmış bir uygulama hatasından dolayı 1337$ değerinde olan Lightweight l33t leather jacket adlı ürünü 30.99$’a diğer ürünle beraber sipariş verebiliyoruz.
Congratulations, you solved the lab!
Lab 3: Low-level logic flaw
Bu web sayfasında quantity parametresine bir öncekinde olduğu gibi istediğimiz her değeri tanımlayamıyoruz. 3 basamaklı yada daha büyük ve negatif bir değer tanımladığımızda hata almaktayız. Fakat buna rağmen kullanıcı girişi yeterince doğrulanmamaktadır. Bundan dolayı kredinin yetersiz kaldığı bir ürün alınabilmektedir.
Sayfadaki en pahalı ürünü seçelim. Add to cart seçeneği ile ürünü sepete ekleyelim ve gönderilen isteği burp suite aracıyla inceleyelim.
Ürün miktarını 100 olarak belirleyip isteği send ettiğimizde “Invalid parameter:quantity” hatası almaktayız.
Fakat ürün miktarını 99 olarak tanımladığımızda hata almıyoruz. Daha sonra atak başlatacağımız için isteği intrudera gönderelim ve ardından forward edelim.
Sepeti görüntülediğimizde 99 adet ürünün eklendiğini göreceğiz. Şimdi sayfaya boş yükler göndererek sayfanın nasıl tepki vereceğini gözlemleyeceğiz. Intrudera gönderdiğimiz istek üzerindeki hiçbir parametreyi $ tagları arasına almayacağız.
Payload tipini Null payloads seçeceğimiz için Intrudera gönderdiğimiz istek üzerindeki hiçbir parametreyi $ tagları arasına almıyoruz. Ayrıca Payload Options bölümünden Continue indefinitely (süresiz devam et) seçeneğini işaretleyip atağı başlatıyoruz.
Atak biz durdurmayana dek sürekli devam edecektir. Bu sırada sayfayı sürekli yenilersek total değerinin her defasında artmaya devam ettiğini göreceksiniz. Fakat bir yerden sonra fiyatın aniden büyük bir negatif tamsayıya geçtiğine ve 0'a doğru saymaya başladığını gözlemlemiş olacağız. Fiyat, programlama dilindeki bir tamsayı için izin verilen en yüksek değeri (2.147.483.647) aştığı için en düşük değerden (-2.147.483.648) itibaren geri saymaya başladı.
Az önce başlattığımız atak zafiyetin tespiti içindi ve artık sonlandırabiliriz. Yeni bir atak başlatacağız ama öncesinde sepeti boşaltalım. Bu adımda süresiz olarak değilde 323 payload gönderecek şekilde atağı başlatıyoruz.
Sayfayı sürekli yenilersek total değerinin her defasında artmaya devam ettiğini ve 2.147.483.647 değerinden sonra geri saymaya başladığını göreceğiz. Atak sonlandığında -63974.20$ değeriyle son bulacaktır. Sipariş verebilmek için bu değeri kredi aralığımıza denk getirmeliyiz.
Repeaterda quantity değerini 47 olarak tanımlayıp isteği send ettiğimizde istediğimiz 0–100$ aralığına yine denk gelmiyoruz.
Bundan sonrası için manuel olarak ikinci ürünün miktarını artıracağız. Ürün miktarını 15 yaptığımızda total değeri kredi aralığımıza denk gelmekte ve sipariş verebilmekteyiz.
Congratulations, you solved the lab!
Lab 4: Inconsistent handling of exceptional input
Bu web sayfasında bir Admin paneli mevcut ve bu paneli görüntüleyebilmek için @dontwannacry.com ile biten bir mail adresine sahip olmamız gerekmektedir. Email formuna girilecek değerin 255. karakterden sonrası kesilmektedir. Bu durumdan yararlanarak admin panelini görüntüleyip carlos adında ki kullanıcıyı sileceğiz.
Burp aracı aktifken sayfayı yenileyelim. Trafiği incelemek ve içerik keşfi yapabilmek için sırasıyla “Target > Site map > Engagement tools > Discover content” adımlarını izleyelim. “Session is not running”a tıklayarak içerik keşfini başlatalım. Kısa bir süre sonra “Site map” sekmesinde bir /admin dizininin keşfedildiğini göreceğiz.
Url üzerinden admin dizinine gittiğimizde, Admin paneline yalnızca DontWannaCry kullanıcılarının erişim sağlayabileceğini bildiren bir mesaj almaktayız.
Register bölümünden, içerisinde email sunucumuzdaki id değerini barındıran, toplamda en az 200 karakter olacak şekilde bir email adresiyle hesap oluşturalım. Ardından Email istemcisini açalım ve doğrulama bağlantısına tıklayarak hesabı aktif edelim.
Oluşturduğumuz arif:123456 hesabıyla login olduğumuzda mail adresinin 255. karakterden sonrasının kesildiğini gözlemleyeceğiz. Uzun bir mail adresi tanımlamamızın sebebi bunu görebilmek içindir. Şimdi içerisinde, email client id değerini içeren ve 255. karakteri dontwannacry.com uzantısındaki son harf m’ye denk gelen bir mail adresiyle hesap oluşturacağız.
Admin paneline gidebilmek için oluşturacağımız hesap dontwannacry.com uzantılı bir mail adresi olmalıdır. Tanımladığımız mail adresindeki 255. karakter dontwannacry.com uzantısındaki son harf olan m olacaktır ve m harfinden sonrası kesilecektir. Fakat yinede mail adresinin sonunda Email client sayfasının id değerini belirtiyoruz. Bunun sebebi hesabı oluşturduktan sonra email istemcisine bir doğrulama bağlantısının düşmesini sağlamaktır.
Email istemcisine düşen bağlantıya tıklayalım ve ardından yeni hesap bilgilerimizle arif1:1234567 login olalım. Artık bir DontWannaCry kullanıcısıyız ve sayfa üzerindeki admin paneline erişim sağlayabiliyoruz.
Admin panelinde aktif kullanıcıları görebiliriz. Laboratuvarın çözümü için carlos kullanıcısını delete etmemiz yeterli olacaktır.
Lab 5: Inconsistent security controls
Web uygulaması üzerindeki kurallar ve güvenlik önlemleri yeterli seviyede denetlenmezse, bir saldırgan tarafından istismar edilebilir tehlikeli sonuçlara neden olabilir. Bir önceki laboratuvarda olduğu gibi bu web sayfasında da bir Admin paneli mevcut ve bu paneli görüntüleyebilmek için @dontwannacry.com ile biten bir mail adresine sahip olmamız gerekmektedir. Hesap oluştururken, doğrulama bağlantısının düşmesi için email client sayfasının domain adresini tanımlıyoruz. Dolayısıyla direkt olarak @dontwannacry.com ile biten bir email ile hesap açamıyoruz. Bunun için başka bir hesap açacağız ve email güncelleme panelinden @dontwannacry.com ile biten bir email tanımlayacağız.
Şimdi ilk olarak admin dizinin varlığını tespit edeceğiz.
Burp aracı aktifken sayfayı yenileyelim. Trafiği incelemek ve içerik keşfi yapabilmek için sırasıyla “Target > Site map > Engagement tools > Discover content” adımlarını izleyelim. “Session is not running”a tıklayarak içerik keşfini başlatalım. Kısa bir süre sonra “Site map” sekmesinde bir /admin dizininin keşfedildiğini göreceğiz.
Url üzerinden admin dizinine gittiğimizde, Admin paneline yalnızca DontWannaCry kullanıcılarının erişim sağlayabileceğini bildiren bir mesaj almaktayız.
Random bir kullanıcı adı ve password tanımlayıp, içerisinde email sunucumuzdaki id değerini barındıran bir email adresiyle hesap oluşturalım.
Ardından Email istemcisini açalım ve doğrulama bağlantısına tıklayarak hesabı aktif delim.
Yeni hesap bilgilerimizle pentest:1234567 login olduktan sonra karşımıza bir mail güncelleme paneli çıkmaktadır. Email’e, @dontwannacry.com ile biten yeni bir mail adresiyle güncelledikten sonra Admin paneline erişim sağlıyor olacağız.
Admin panelinde aktif kullanıcıları görebiliriz. Laboratuvarın çözümü için carlos kullanıcısını delete etmemiz yeterli olacaktır.
Lab 6: Weak isolation on dual-use endpoint
Bir web uygulaması, kullanıcı tarafından gönderilen isteği ve yer alan parametreleri kontrol etmelidir. Aksi takdirde bir saldırgan bu parametrelerden herhangi birini silerek yada değişerek istenilmeyen sonuçlara (başkalarının hesabına erişim sağlaması gibi) neden olabilir.
Laba erişim öncesi tanımlanan hesap bilgisiyle wiener:peter login olduğumuzda mail adresimizi ve parolamızı değişebileceğimiz bir panel karşımıza çıkmaktadır. Parolamızı değişmek için, wiener kullanıcısının şimdiki parolasını ve yeni oluşturacağımız parola değerini tanımlayıp submit edelim.
Submit ettiğimiz bu isteği burp suite ile incelediğimizde bu değerlerin tanımlandığı parametreler açık bir şekilde görülmektedir.
İsteği repeatera gönderelim. current-password (mevcut şifre) parametresini silip send ettiğimiz zaman parolanın başarılı bir şekilde değiştirildiğini aldığımız response ile görmekteyiz. Bu parametre, web uygulaması tarafından kontrol edilmemektedir. Dolayısıyla username’e başka bir kullanıcı adı tanımladığımızda, tanımladığımız kullanıcı adının mevcut parolasını girmeden yeni parolasını tanımlamış ve değişmiş olacağız.
username değerini administrator olarak değişip isteği send ettiğimizde administrator kullanıcısının parolasını 12345 olarak başarılı bir şeikilde değiştirmiş oluyoruz.
Web sayfasındaki yanlış yapılandırılmış bu mantık hatasından dolayı, şifresini bilmediğimiz bir kullanıcı adı (administrator) için yeni bir şifre tanımladık ve hesaba erişim sağladık.
Admin panelini görüntüleyip carlos kullanıcısını delete ettiğimizde laboratuvarı çözmüş olacağız.
Lab 7: Insufficient workflow validation
Bu web sayfasında, ikinci adımda gönderilen veriler sunucu tarafından denetlenmeden kabul edilmektedir. Bu nedenle ikinci adım bypass edilebilir ve kredi miktarını aşan bir ürün sipariş verilebilir.
My account sayfasında wiener:peter hesap bilgisiyle login olalım ve kredimiz aralığında bir ürün sepete ekleyelim. Bu ürünü sipariş vereceğiz fakat öncesinde gönderilen isteğe bakalım.
Gönderilen POST /cart/checkout isteği ile bir sipariş onay sayfasına yönlendirilmekteyiz. İsteği forward edelim.
Karşımıza gelen bu istekte sipariş onayını (true) belirten bir order-confirmed parametresi yer almaktadır. Bu isteği repeatera gönderelim ve ardından forward edelim. Ürünü satın almış olduk fakat bu onay isteği gönderildikten sonra, sayfa herhangi bir parametre kontrolü yapmadığı için kredi aralığımızın dışında olan farklı bir ürünü de sipariş edebiliriz. Bunun için sayfa üzerinde pahalı bir ürün seçip sepete ekleyelim. Daha sonra repeatera gönderdiğimiz bu onay isteğini send ettiğimizde, sepete eklediğimiz yeni ürün için, kredi miktarımızda bir eksilme olmadan sipariş verilecektir.
Kısacası, burada ilk ürün için gönderilen onay isteğini ikinci ürün içinde gönderdik. Bu adım doğrulanmadığı için istediğimizi ürünü bu şekilde sipariş verebiliriz.
Congratulations, you solved the lab!
Lab 8: Authentication bypass via flawed state machine
Bu web sayfasında da bir Admin paneli mevcut ve bu paneli yalnızca administrator kullanıcısı görüntüleyebilmektedir. Fakat yanlış yapılandırılmış bir mantık hatasından dolayı wiener kullanıcısıyla görüntüleyebilmekteyiz.
wiener:peter hesap bilgisiyle login olduktan sonra ilerleyebilmek için rolümüzü belirtmemiz gerekmektedir. Ana sayfaya geçmeden önce rolümüzü (User) seçelim.
Burp aracı aktifken ana sayfayı yenileyelim. Trafiği incelemek ve içerik keşfi yapabilmek için sırasıyla “Target > Site map > Engagement tools > Discover content” adımlarını izleyelim. “Session is not running”a tıklayarak içerik keşfini başlatalım. Kısa bir süre sonra “Site map” sekmesinde bir /admin dizininin keşfedildiğini göreceğiz.
Url üzerinden admin dizinine gittiğimizde, Admin paneline yalnızca administrator kullanıcısının erişim sağlayabileceğini bildiren bir mesaj almaktayız.
Hesaptan çıkış yapalım. Intercept aktifken tekrar login olalım ve burp aracıyla yakaladığımız isteği forward edelim. Bir sonraki istek ekranda görüldüğü gibi GET /role-selector şeklindedir.
GET /role-selector isteğini drop edip, url üzerindeki role-selector dizgisini silerek ana sayfayı dönelim.
Ana sayfayı görüntülediğimizde artık yönetici rolünde olduğumuzu, yönetici paneline erişebildiğimizi göreceğiz. Admin panelini görüntüleyip carlos kullanıcısını delete ettiğimizde laboratuvarı çözmüş olacağız.
Congratulations, you solved the lab!
Lab 9: Flawed enforcement of business rules
Alışveriş sayfalarının sıkça kullanılan indirim uygulamaları, yeterli şekilde denetlenmediği zaman saldırılara neden olabilmektedir. Örneğin, 1000$ üzerindeki siparişlerde %10 indirim kupon uygulaması sunan bir alışveriş sayfası düşünelim. Web uygulaması indirim uygulandıktan sonra siparişin değiştirilip değiştirilmediğini kontrol etmezse, bu durum kötüye kullanılabilir.
Web sayfasında bize verilen hesap bilgisiyle login olduğumuzda bir kupon kodunun tanımlandığını göreceğiz.
Anasayfanın en alt tarafında bir haber bülteni var ve bu haber bültenine random bir mail adresi ile kaydolduğumuzda yeni bir kupon kodu tanımlanmaktadır.
Use coupon SIGNUP30 at checkout!
Sayfa üzerinde 1337$’lık ürünü sepete ekleyelim ve ilk kupon kodumuzu fazladan (ikişer defa) apply edelim. İki kez ard arda aynı kuponu uyguladığımızda, kupon zaten uygulandığından hata mesajı alıyoruz.
Fakat aldığımız iki kuponu sırasıyla geçiş yaparak apply ettiğimizde kuponların başarıyla uygulandığını gözlemliyor olacağız. Total değeri 0$’ a ulaştığında sipariş verelim.
Hiç ödeme yapmadan, kredi aralığımızda olmayan bir ürünü bu şekilde sipariş vermiş olduk.
Lab 10: Infinite money logic flaw
Bu web sayfasında, indirim kuponu yanı sıra sipariş verildikten sonra bir hediye kuponu verilmektedir. Hediye kuponu kullanıldığı zaman krediye belli bir miktarda tutar eklenmektedir. Bahsettiğimiz bu işler otomatize bir şekilde gerçekleştiğinde bir zafiyet söz konusu olmaktadır.
Bu otomatize işlemi gerçekleştirmek için öncesinde Burp suite aracında ki Makro özelliğini kullanacağız.
İlk olarak Burp suite aracı aktifken, tanımlanmış (wiener:peter) hesap bilgisiyle login olalım ve ardından anasayfanın aşağı tarafında yer alan haber bültenine random bir mail adresiyle kaydolalım. Bunun karşılığında bize bir kupon kodu SIGNUP30 vermektedir.
Gift Card adlı 10$ tutarındaki bir ürünü sepete ekleyelim ve aldığımız kupon kodunu bu ürün için uygulayalım.
Ürünü sipariş verdiğimizde bize bir hediye kartı kuponu tanımlanmaktadır.
Login olduktan sonraki sayfaya gelip bu kopun kodunu Gift cars bölümünde onaylatalım. Bu durumda kredimize 10$ eklenecek ve kredimiz 103$ olacaktır. Toplamda 3$ kar etmiş olmaktayız. Henüz bir zafiyet tespiti söz konusu değildir fakat bu işlemi otomatik bir şekilde gerçekleştirdiğimizde bir zafiyet meydana gelmektedir.
Bunun için belli URL’leri test macro özelliği ile test edeceğiz. “Project options” > “Sessions”>”Add” adımlarını izleyerek Session handling rule editor penceresini açıyoruz ve Scope sekmesinde Include all URLs seçiyoruz.
Daha sonra “Details” sekmesindeki “Rule Actions” bölümünden “Run a macro” seçeneğini ekliyoruz. Ardından “Select Macro” sekmesi altında “Add” e tıklayarak “Macro Recorder” penceresini açıyoruz. Ekranda belirtilen 5 isteği seçip onaylayacağız.
Seçtiğimiz 5 istekten ilk önce, GET /cart/order-confirmation?order-confirmed=true isteği için yapılandırma yapacağız. “Configure item” ı ve ardından açılan iletişim kutusunda, özel bir parametre oluşturmak için “Add”i tıklayalım. Sonrasında gift-card parametresini ve buna eşlenecek hediye kartı kuponunu belirtelim.
İkinci olarak, POST /gift-card isteği için yapılandırma yapacağız. “Configure item” a tıkladıktan sonra, gift-card parametresinin önceki yanıttan türetilmesi gerektiğini “Parameter handling” bölümünde belirtmek için, Derive from prior response seçeneğini seçelim.
Şimdi Test macro seçeneği ile makroları test edelim. Sonrasında GET /cart/order-confirmation?order-confirmed=true isteği yanıtında bir hediye kartı oluşturulacaktır. POST /gift-card isteğinde ise 302 yanıtının döndüğünü ve gift-card parametresinin eşleştiğini görmekteyiz. Bundan sonrası için my-account isteğini intrudera gönderip sayfaya boş payloadlar gönderilmesini sağlayacağız. Kullandığımız Makro özelliği sayesinde, Burp Intruder ile göndereceğimiz her istek sayfada kredi değerinin artmasını sağlayacaktır.
Payload tipini Null payloads seçeceğimiz için Intrudera gönderdiğimiz istek üzerindeki hiçbir parametreyi $ tagları arasına almıyoruz.
Ayrıca Payload Options bölümünden Generate seçeneği ile 323 payload gönderecek şekilde atağı başlatıyoruz.
Atak devam ediyorken kredimiz sürekli artacaktır. Atak tamamlandığında ise anasayfada ki en pahalı ürünü bile alabilecek bir kredi tutarına (1345$) sahip olmaktayız.
En pahalı ürünü sepete ekleyip siparişi verdiğimizde laboratuvarı çözmüş olacağız.
Lab 11: Authentication bypass via encryption oracle
Bir web uygulamasında kullanıcı tarafından kontrol edilebilen giriş parametre değerleri, şifrelenmiş olsa dahi kullanıcı tarafından görülebiliyorsa tehlikeli senaryolar ortaya çıkabilir. Saldırgan, bir algoritma veya asimetrik anahtar kullanarak bu parametre değerini şifreleyebilir ve başka bir kullanıcının verilerini ele geçirebilir.
Bu laboratuvarda şifrelenmiş doğrulama değerleri kullanıcılar tarafından görülmekte ve denetlenmemektedir. Bu zafiyet, administrator kullanıcısı olarak sisteme erişim sağlamamıza olanak tanımaktadır.
Login panelinde geçerli wiener:peter kullanıcı bilgileriyle stay logged in (oturumu açık tut) seçeneğini işaretleyerek giriş yapalım. Giriş yaptıktan sonra burp aracıyla inceleme yapılırsa, wiener kullanıcısına ait stay logged in değerinin şifrelendiği görülecektir.
Herhangi bir blog gönderisinde rastgele bir mail adresi tanımlayarak yorum mesajı gönderelim. Mail adresi gmail.com uzantılı olduğu için herhangi bir hata mesajı almıyoruz.
Bloğa geri dönüp portswigger.com şeklinde geçersiz bir mail adresi tanımlayarak mesajı gönderelim.
Ardından email adresinin geçersiz olduğunu bildiren bir hata mesajı almaktayız. Hata mesajını email değerinden aldığımız için ilerleyen bölümde email parametresi üzerinden tanımlamalar yapacağız.
Bu işlemleri burp aracı aktifken gerçekleştirdik. Http history bölümünden adım adım istekleri inceleyebiliriz. POST /post/comment başlıklı isteğin üzerinde bir stay-logged-in bilgisi yer almaktadır. İsteğin yanıtı üzerinde ise, blog gönderisine yönlendirilmeden önce şifreli bir notification tanımlama bilgisinin kullanıldığı görülmektedir. Burada, POST /post/comment ve GET /post?postId=3 başlıklı iki istek üzerinden hareket edip işlemler gerçekleştireceğiz.
Repeaterda, verileri şifrelemek ve Set-Cookie başlığına karşılık gelen şifreli metni çözebilmek için POST isteğinin e-posta parametresini kullanabiliriz. Aynı şekilde, şifrelenmiş metnin şifresini çözmek ve istek yanıtında alınacak hata mesajını görebilmek için GET isteğindeki notification değerini kullanabiliriz. Kolaylık sağlamak adına POST isteğini ENCRPTED, GET isteğini DECRYPTED olarak adlandıralım.
DECRYPTED isteği üzerinde, tıpkı ENCRPTED isteğinin yanıtında ki gibi bir notification parametresi yer almaktadır. Şifreyi çözebilmek adına ENCRPTED isteğinde yer alan stay-logged-in değerini DECRYPTED isteği üzerindeki notification değerine tanımlayıp isteği send ettiğimizde, bir hata mesajı yerine şifresi çözülmüş stay-logged-in değerini bildiren bir response dönmektedir. Bu wiener:1643823170838 bilgisi, cookie değerinin username:timestamp formatında olduğunu göstermektedir. Burada ki timestamp değerini administrator için kullanacağız.
ENCRYPTED isteğinde email değerini administrator:1643823170838 olarak değişelim ve isteği send edelim. Dönen response üzerindeki notification değerini çözmek için tekrar DECRYPTED isteğini kullanacağız. notification değerini kopyalayalım.
Kopyaladığımız değeri DECRYPTED isteği üzerindeki notification değerine tanımlayıp isteği send ettiğimizde 23 karakterlik Invalid email address cümlesinin administrator:164302310838 bilgisine bir ön ek olarak geldiğini görmekteyiz. Sadece username:timestamp şeklinde bir sonuç döndürülmesi gerekmektedir. Bunun için kopyaladığımız notification değerini decodera gönderelim.
Değeri ilk önce URL sonrada Base64 formatında decode ederek 23 byte silme işlemi gerçekleştirelim. Bu notification değerini tekrardan encode etmemiz gerekmtektedir. Sırasıyla Base64 ve URL formatında encode edelim ve yeni notification değerini kopyalayalım.
Kopyaladığımız değeri tanımlayıp isteği send ettiğimizde bir hata mesajı alacağız. Bu hata mesajında blok tabanlı bir şifreleme algoritmasının kullanıldığı ve giriş uzunluğunun 16'nın katı olması gerektiği belirtilmektedir.
Daha önce administrator:1643823170838 bilgisi öncesinde yer alan Invalid email address cümlesini kaldırmak için 23 byte silmiştik. 16'nın katı olması için 32 byte silmemiz gerekmektedir. Dolayısıyla ENCRYPTED isteği üzerindeki email adresine 9 adet x ekliyoruz. İsteği send edelim ve dönen respnse üzerindeki notification değerini decodera gönderelim. Daha önce yaptığımız önce decode ve ardından encode etme işlemlerini tekrar yapalım. Tek fark bir öncekinde 23 byte silmişken burada 32 byte siliyoruz. İşlem sonrasında yeni notification değerini kopyalayalım.
Kopyaladığımız yeni notification değerini tanımlayıp isteği send ettiğimizde hata mesajı almadığımızı ve response’un sadece username:timestamp formatında olduğu göreceğiz.
Sayfa üzerinde yeni bir istek gönderelim ve administrator kullanıcısına ait encode edilmiş yeni notification değerini tanımlayalım. İsteği forward ettiğimizde administrator olarak oturum açmış olacağız.
Buraya kadar yaptığımız tüm bu işlemler administrator kullanıcısına ait notification değerini bulabilmek ve encode edebilmek içindi.
Ana sayfayı görüntülediğimizde artık yönetici rolünde olduğumuzu, yönetici paneline erişebildiğimizi göreceğiz.
Admin panelini görüntüleyip carlos kullanıcısını delete ettiğimizde son laboratuvarıda bu şekilde çözmüş olacağız.
Congratulations, you solved the lab!
NOT: Bu laboratuvarda yaptığımız işlemi kısaca şu şekilde özetleyebiliriz: İstekler üzerinde ki cookie bilgileri şifrelenmiş bir biçimde karşımıza çıkmaktadır. wiener kullanıcısına ait cookie bilgisini decode ederek şifrelenmiş değerin username:timestamp formatında olduğunu tespit ettik. Daha sonra email parametresi üzerinden administrator kullanıcısı için cookie bilgisini şifre çözümlemek istediğimizde hata aldık ve bu hatayı çözmek içinde decoder sekmesinden byte silme işlemi gerçekleştirdik. administrator kullanıcısı için, giriş değerinin uygun formatta olmasını sağlayarak yeni encode edilmiş bir cookie değeri oluşturduk ve bu cookie değeriyle admin panelinde erişim sağladık.
