Uygulama Güvenliği

Mass Assignment Zafiyetinin Sömürülmesi

Bu bölümde Attack-Defense Labs üzerinde yer alan "Mass Assignment II" uygulamasını çözerek zafiyeti sömürme aşamasına geçeceğiz.

Anıl Baş |

12.02.2021

Öncelikle ortamı biraz tanıyalım. Bu laboratuvar ortamı bir bankacılık web uygulamasından oluşuyor. Web uygulaması, kullanıcıların başarılı bir giriş yaptıktan sonra şifrelerini ve e-posta kimliklerini güncellemelerine olanak tanıyor (Acaba sadece bunları mı? 😉). Görevimiz ise uygulama üzerinde "Golden Ticket" almak. Bu ticketı almak için hesabımızda 5000000 üzerinde bakiyemizin olması gerekiyor.  Hesabımızda login olduğumuz anda ise 500 bakiyemiz var.
 

Lab ortamında aldığımız ip adresini kontrol edelim.
 

blog 2- 1


192.107.253.2 IP adresi attacker (kali) makinesine atanmış, lab briefinginde söylendiğine göre hedef uygulamamız ise 192.X.Y.3 adresinin 5000 portunda çalışıyor. Hedef uygulamamıza http://192.107.253.3:5000 adresinden erişebiliyoruz.
 

blog-2-2


Uygulamamıza proxy tanımlayarak istekleri takip edecek ayarlamayı da yapalım.
 

blog-2-3


Uygulamaya giriş yapabileceğimiz bilgiler elliot:elliotalderson şeklinde belirtilmiş. Giriş yaptıktan sonra bir JWT token alıyoruz.
 

blog-2-4-4


Token içerisindeki verileri incelediğimizde ise bazı bilgilere ulaşıyoruz. 
 

blog2-5


Scope olarak "account-read" yetkimizin olduğunu görüyoruz. Bunu not aldık ve uygulamayı incelemeye devam edelim.  
 

Bakiyemizi görüntülemek için "check balance" butonuna tıkladığımızda aşağıdaki isteği görüyoruz. Bu servis bakiyemizi sorgulamak için kullanılan bir servis ve servisin yanıtı olarak 500 bakiyemiz olduğu görünüyor.

 

blog2-6


Golden ticketı almak istediğimizde ise bakiyemizin yetersiz olduğunu görüyoruz.
 

blog2-7


Uygulamada şifre ve eposta değiştirmek için update profile sayfasına gittiğimizde aşağıdaki gibi bir istek ile karşılaşıyoruz.
 

blog-28blog-2-9


Taşlar biraz yerine oturmaya başladı. Uygulamanın bir de 80 portu üzerinde bir dokümantasyonu olduğu lab girişinde belirtilmişti.
 

blog-2-10


Scope bölümünü incelediğimizde iki farklı yetki derecesi olduğunu görüyoruz.
 

blog-2-11


Dokümantasyonda şema bölümünü incelediğimizde uygulama yapısı ile ilgili bazı önemli bilgilere ulaşıyoruz.
 

blog-2-12


Uygulamanın modelinde is_admin_account alanının olduğunu görüyoruz, elimizde profil güncelleyebileceğimiz bir alan da var. Burada bir toplu atama tetikleyerek kendimizi admin yetkilerine yükseltebilecek miyiz? Hadi deneyelim.
 

blog-2-13blog-2-14


Uygulama tekrar giriş yapmamız için anasayfaya yönlendirdi. Tekrar oturum açtığımızda aldığımız JWT token içeriğini kontrol edelim. Eğer başarılı olduysak scope olarak "account-write" seviyesine çıkmış olmamız gerekiyor.
 

blog-2-15blog-2-16


Evet artık kullanıcımız yönetici yetkilerinde ve yazma haklarına sahip bir oturumu var. Fakat yönetici yetkimiz olsa da kullanıcımızın bakiyesi 500. Yine lab içerisinde belirtilen bir özelliği kullanarak bakiyemiz üzerinde işlem yapacağız. 
 

blog-2-17


Bakiye güncellemek için için bir API uç noktası olduğunu biliyoruz. Bu uç nokta yönetici yetkileri ve yazma hakkı gerektiriyor. Yönetici hesabımızın olmasını bu uç noktayı kullanarak kendi bakiyemizi güncellemek için kullanabiliriz.
 

blog-2-18


Kendi bakiyemizi golden ticket alacak şekilde güncelleyebildik gibi görünüyor. Bunu check balance ile tekrar kontrol edelim.
 

blog-2-19


Bakiyemiz güncellenmiş. Golden ticket alabilmek için önümüzde bir engel kalmamış gibi görünüyor.
 

blog-20

 

Görev tamam :)

Bir sonraki yazıda görüşmek üzere...

 

Kaynaklar

https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html

https://en.wikipedia.org/wiki/Mass_assignment_vulnerability

Anıl Baş |

12.02.2021

Yorumlar

Fatih Demirbaş
09.03.2021 - 10:21

Web uygulama güvenliği adına faydalı bir yazı, benzer yazıların da gelmesi dileğiyle :)