19 Ekim 2010 Salı

HE:WA-C5 Authorization Attack Case Studies-1



Authorization Attack Case Studies

Horizontal Privilege Escalation

Request içinden header'ları çıkararak gerekli olup olmadıkları anlaşılır.

Nümerik alanlara dikkat. Bunlar birer sıra numarası olabilir, manipüle edilerek başkalarının hesap bilgilerine ulaşılabilir. Misal, bir alışveriş sitesinde account bilgileri görüntüleme / değiştirme için yapılacak talepte cookie içindeki shopperID parametresini 1 azaltarak talebi gönderelim, işte bir başkasının account bilgileri, üzerinde değişiklik yapabilecek şekilde karşımızda.

Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;

ShopperID=193096346;

Tek yaptığımız shopperID'yi 1 azaltmak. Ve sonuçta başka bir kullanıcının hesap bilgileri!

Cookie: BIGipServerSecure2.TEAM.WebHosting=1852316332.20480.0000;

ShopperID=193096345;

Vertical Privilege Escalation

Dikey hak yükseltmeyle sonuçlanabilecek 4 senaryo var:

  1. User-modifiable Roles

Örnek1:

Cookie: Auth=

897ec5aef2914fd153091011a4f0f1ca8e64f98c33a303eddfbb7ea29d217b34; -

563131=Roles=End User; K=HomePageHits=True;ASP.NET_SessionId=

dbii2555qecqfimijxzfaf55

Buradaki "Roles=End User" parametresi iç gıcıklayıcı, manipüle edelim: "Roles=admin", "Roles=administrator"...

Örnek2:

Cookie: ASPSESSIONIDAACAACDA=AJBIGAJCKHPMDFLLMKNFLFME; rC=X=

C910805903&Y=1133214680303; role=ee11cbb19052e40b07aac0ca060c23ee

Açıkça görülüyor ki "role=ee..." parametresi üzerine eğileceğiz burada da. Ama anlamlı bir şey gibi gözükmüyor. Farklı bir kullanıcı ile talebi tekrar oluşturalım:

Cookie: ASPSESSIONIDAACAACDA=KPCIGAJCGBODNLNMBIPBOAHI; rC=C=0&T=

1133214613838&V=1133214702185; role=ee11cbb19052e40b07aac0ca060c23ee

Görünen o ki "role" parametresinin değeri değişken değil, statik!

İpucu: Stringin 32 karakter olması, rakamlar ve f'ye kadar harflerden oluşması, bizi bunun standart bir 128-bit MD5 hash kodunun hexadecimal gösterimi olduğu düşüncesine sevketti. Sonra "admin", "administrator", "root"... denemeye başlıyoruz.

İyisi mi bu işi otomatize edelim, payload oluşturup aracımıza yaptıralım bu denemeleri (Burp Suite'in intruder aracını hatırla!).

  1. Using Hijacked Accounts

Yatay hak yükseltme saldırısını hatırlayalım. Artarak giden bir ID belirleniyorsa en düşük ID numarasının sıradan kullanıcılardan daha çok yetkiye sahip bir admin yada developer hesabı olması olmayacak şey değil! "AuthID=3289" parametresi yerine "AuthID=1" gönderelim, bakalım ne sonuç verecek...

  1. Using Other Security Flaws

SQL injection yada buffer overflow gibi açıklıklar, istediğimiz yetkilere sahip olmak için yeterli olacaktır.

Hiç yorum yok:

Yorum Gönder

Web Uygulama Sızma Testleri İçin Kontrol Listeleri - V

Checklist for Web App Pentesting - V 6. Veri Denetimi (Data Validation) Testleri 6.1 Girdi Denetimi Bütün girdiler denetlenmelidir....