Hesap Devralma için IDOR

May 06 2023

Özet Merhaba millet! OSCP sertifikamı tamamladıktan sonra ve hata ödüllerine tekrar dalmak istediğimde, belki de birisinin yararlı bulması veya ondan bir şeyler öğrenmesi umuduyla önceki bulgularıma dayanarak bazı bloglar yazmam gerektiğine karar verdim. Bu yazı, iki IDOR güvenlik açığının bulunmasını ve bunların PII sızdırmak için kullanılmasını ve böylece bir hesabın ele geçirilmesini gerektirir.

Özet

Merhaba insanlar! OSCP sertifikamı tamamladıktan sonra ve hata ödüllerine tekrar dalmak istediğimde, belki de birisinin yararlı bulması veya ondan bir şeyler öğrenmesi umuduyla önceki bulgularıma dayanarak bazı bloglar yazmam gerektiğine karar verdim.

Bu yazma, iki IDOR güvenlik açığının bulunmasını ve bunların, bir hesabın ele geçirilmesiyle sonuçlanan PII sızıntısı için kullanılmasını gerektirir . Hesabın devralınması, şirketin hesap kurtarma sürecini yönetme biçimi nedeniyle mümkün oldu ve aslında hata ödüllerine ilk başladığımda ilk bulgularımdan biriydi. Bunu bulmanın verdiği heyecan beni sürekli olarak fazla mesai yapmaya yöneltti.

Bahsettiğim bu IDOR nedir?

Insecure Direct Object Referencegenellikle "IDOR" olarak kısaltılır ve altında kategorize edilebilen bir güvenlik açığı türüdür access control. IDORsUygulama, kullanıcının doğru yetkilendirme izinlerine sahip olup olmadığını görmek için herhangi bir kontrol gerçekleştirmeden doğrudan nesneye erişmek için kullanıcı tarafından sağlanan girdiyi kullandığında uygulama içinde meydana gelir. Çoğunlukla yatay ayrıcalık artışıyla ilişkilendirilen IDORsuygulama ve kullanıcı tabanı üzerinde zararlı etkiler oluşturabilir.

Genellikle IDOR'lara karşı savunmasız olan tipik parametrelerin en iyi örneği şunları içerir: id= | userID= | messageId=. Uygulamanın akışını anlamak, bu tür sorunları tanımlamayı kolaylaştırabilir.

Yukarıdaki görüntü iki senaryoyu göstermektedir. Scenario Asolda, users 2 and 3kendilerine ait olmayan hassas kayıtlara erişmeye çalışılan ancak olması access denied errorgerektiği gibi sonuçlanan daha güvenli bir uygulama aktarılır.

Scenario Bancak sağdaki, tehdit aktörünün web sunucusuna istek gönderebildiği ve herhangi bir kullanıcının hassas kayıtlarını erişimi reddedilmeden alabileceği savunmasız bir uygulamayı tasvir ediyor.

IDORs Vickie Li hakkında daha fazlasını okumak istiyorsanız, bu güvenlik açığı türünün temellerine ışık tutan harika bir blog yazısı var. Buradan kontrol edebilirsiniz .

Yukarıdaki örnek basit bir örnektir, ancak uygulamaya bağlı olarak, etkiyi artırmak için bilgileri raporlamadan önce kullanabilirsiniz, ki bu benim her zaman yapmayı amaçladığım şey.

IDORsArtık ne oldukları, nerede bulunabilecekleri ve etkileri hakkında bir fikrimiz olduğuna göre , ilk bulgularımdan birine geçelim! :)

Keşif

Sorun düzeltilmiş olmasına rağmen, tam olarak kamuya açıklama için izin alamadım, bu nedenle hedef şu şekilde anılacaktır: example.com. Herhangi bir hedefte olduğu gibi, , alt alan numaralandırmasına bağlı olarak, scopesaldırı yüzeyini genişletmenin anahtarıdır. Ancak, hassas bilgiler için dosyaları da analiz edebildiğimiz için, saldırı yüzeyini genişletmenin tek yolu alt alan numaralandırma değildir JavaScript. Google DorkBu durumda , daha fazla sonuç için otomatikleştirilmiş araçları kullanmadan önce herhangi bir ilginç alt etki alanı bulup bulamayacağımı görmek için hızlı bir şekilde kullanmaya karar verdim .

Google Dork'u:site:*.example.com

Example.comyaklaşık 36 alt alan adı vardı, bu nedenle çalışmak için oldukça iyi sayıda alt alan vardı!
Bunları tek tek inceleyerek, birçok işlevi olan iki alt alan adı kaydettim. Bu alt alanlar arasında gezinmek ve farklı özellikleri test etmek için yaklaşık bir veya iki gün ayırdım ve bu uygulamaya özgü daha ilginç özelliklerden bazılarını zihnimde not aldım. Örneğin uygulamada “Ödeme Sorunları” gibi farklı kategoriler altında personelden destek almak için bilet oluşturabileceğiniz bir özellik vardı.

İlk Hata

Bugünlerde neredeyse tüm web sitelerinde uygulanan temel bir özellik olan kaydolma ve oturum açma sürecinin nasıl çalıştığını analiz ederek başlamaya karar verdim. Web uygulamasının kayıt akışı şu şekilde özetlenebilir:

Kullanıcı e-posta yoluyla kaydolur
Hesap oluşturma işlemi bitmeden önce kullanıcıdan bir PIN No.ve bir ayarlaması istenir . security questionBu yalnızca bir kez ayarlanabilir ve değiştirilemez
Oturum açabilmeleri için kullanıcıdan e-postayı onaylaması istenir

kullanarak account A, ateşledim Burpsuiteve biletleme özelliğini test etmeye başladım ve iki test hesabı oluşturdum, ardından test amacıyla farklı destek kategorileri altında birkaç bilet oluşturdum. HTTP Historyİçeriye baktığımızda Burpsuitebazı ilginç aramalar yapılıyordu.

Ödül talepleriyle ilgili bir bilette bir personele yanıt verilirken aşağıdakiler başlatıldı:POST request

POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com

grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...

Şimdiye kadar bulguları sonuçlandırmak için:

Kaydolduktan sonra her kullanıcının bir PIN No.ve oluşturması gerekir.security question
Web sitesi, kullanıcıların yardım için destek bileti oluşturmasına olanak tanır
Kullanıcının destek alabilmesi için hesap kurtarma, ödül talepleri ve ödeme sorunları gibi hassas konularda PIN No.yanıt vermesi gerekir.security question answer
IDORBiletleme sisteminde keşfedilen güvenlik açığı, bir rakibin, bilet sahibi veya personel olmadan herhangi bir destek bileti içinde yorum yapmasına olanak tanır.

Yani, bilet sahibi olmadan veya personel üye ayrıcalıklarına sahip olmadan herhangi bir bilete yorum yazabilirsem... bu kesinlikle herhangi bir bileti de okuyabileceğim anlamına geliyordu, değil mi?

account Avia ' ya ait bir bileti görüntüleme girişimi sırasında aşağıdaki GET isteğini yakaladım account B, ancak bu yasa dışı 403hataya yol açtı! Yani herhangi bir destek biletine yazabiliyordum ama bir tanesinin içeriğini okuyamadım. Bu noktada gerçekten bunu daha ileriye götürmenin herhangi bir olası yolunu bulmak istedim.

Web Uygulamasında bilet okumak için Endpoint'i ALIN

GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close

Biletleme özelliğinden yararlanmaya çalışırken aşağıdaki istekle karşılaştım;

GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:

IOS Uygulamasında API aracılığıyla Bilet İçeriklerinin Sızdırılması

APIİlk keşif sırasında, profil bilgileri alınırken bazı isteklerin gönderildiğini fark ettim , ayrıca hedefin mobile appkapsamı da vardı. API version/endpointWeb uygulamasından diğer kullanıcı biletlerini okumak mümkün olmasa da, web uygulamasından farklı bir kullanım olabileceğinden mobil uygulama üzerinden ulaşılabilir olması kuvvetle muhtemeldir .

BurpsuiteIOS Uygulaması içindeki bilet oturumunu başlatıp gezinerek aşağıdaki uç noktaya ulaştım:

GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com

Şimdi iki hata buldum - herhangi bir bilete yazmak VE başka bir kullanıcıya ait herhangi bir biletin içeriğini görüntülemek mümkündü.

Yükselen Bilet Okuma Kimliği > Hesap Devralma

Bu noktada, hesabı devralmak için gereken tüm unsurlara hemen hemen sahiptim. Herhangi bir bileti okumak mümkün olduğundan, kullanıcı hesabının devralınması aşağıdaki adımlarla gerçekleştirilebilir:

Uç noktayı ziyaret edin ve mümkün olduğu kadar çok bileti numaralandırmak için içeri /api/v1/support-tickets/234567/postsgönderinintruderBurpsuite
Grepgibi anahtar kelimeler için Pin Numberveya Security Questionyanıtlardan
Web sitesinde yeni bir hesap oluşturun ve altında bir bilet açın.account recovery
Tahsis edilen personel, kurtarmak istediğiniz hesabın kullanıcı adını ve ile birlikte isteyecektir security question answer, PIN No.bunların tümü bulunan ikinci IDOR aracılığıyla sızdırılabilir; bu nedenle, bir hesabın devralınmasıyla sonuçlanır.

Hesap devralımı zaten gerçekleştirilmiş olsa da, bilet yazma IDOR'undan da yararlanılabilir. Personel kullanıcı adlarının önüne şirket adı eklenmiştir, örneğin example-John. Bir düşman;