داستان چند IDOR در یک پروگرم بانتی

سلام من سپهر هستم، حدودا یک سال و نیم هست که بدون هیچ پیش زمینه‌ای وارد دنیای امنیت شدم و شروع مسیر یادگیریم با رودمپی بود که یاشار توی کانال یوتوبش گذاشته بود. از منابع و سایت‌های تمرینی مثل Hack the box و Port swigger شروع کردم و کم کم توی مسیر یادگیری و پیشرفت افتادم. اولای مسیر یادگیریم، زمان خیلی زیادی رو صرف یادگیری مطالب به صورت تئوری میکردم و کارعملی خیلی کمی انجام میدادم اما با گذشت زمان کم کم روند تغییر کرد و زمان بیشتری برای کار عملی گذاشتم، چون تقریبا بیشتر مطالب پایه رو یادگرفته بودم و وقتش بود که توی عمل و متدولوژی خودم پیادشون بکنم که همین باعث شد ضعف‌ها و مشکلاتی که دارمو شناسایی کنم و به مرور زمان برطرفشون بکنم. امروز میخوام مسیر کشف چند تا از آسیب پذیری‌هایی که روی یک پروگرم بانتی پیدا کردم رو براتون توضیح بدم.

فاز Wide Recon

قبل از اینکه به آسیب پذیری‌ها بپردازم، فکر کنم بد نباشه که باهم بخشی از پروسه ریکانی که برای پیدا کردن این asset آسیب‌پذیر رو طی کردم باهم بررسی کنیم.

برنامه‌ای که من روش کار کردم scope خیلی خیلی بزرگی داشت و هر دامین یا سابدامینی که متعلق بهش بود رو به عنوان in-scope قبول میکرد. معمولا در اینجور مواقع من شروع میکنم به پیدا کردن دارایی‌هایی که اون سازمان داره و طریق اون دارایی‌ها اول به دامین و بعد به سابدامین‌های اون سازمان میرسم. ابزارها و روش‌های مختلفی برای پیدا کردن این دارایی‌ها وجود داره اما برخی از روشی‌هایی که من خودم استفاده کردم موارد زیر بودن:

سایت whoisamplapi

از طریق این سایت میتونید با استفاده از reverse whois لیست دامین‌هایی که مربوط به کمپانی هستند رو دربیارید. طریقه استفاده ازش خیلی ساده هست، فقط باید یک حساب برای خودتون بسازید و بعد از وارد شدن به حسابتون در قسمت Reverse WHOIS Search اسم اون کمپانی که مدنظرتون هست رو سرچ کنید و نتیحه رو دانلودکنید.

سایت crunchbase

یکی دیگه از این سایت‌ها crunchbase هستش که خب هانترها هم خیلی ازش استفاده می‌کنند و واقعا هم نتایج خوبی برمیگردونه، اما همونطور که میدونید تعداد نتایجی که برمیگردونه کامل نیست و برای دیدن همه‌ی نتایج باید اشتراک داشته باشید. برای دور زدن این محدودیت می‌تونیم از dork زیر استفاده کنیم (به طور مثال فرض کنید میخواییم دارایی‌های yahoo رو پیدا کنیم):

site:crunchbase.com "acquired by yahoo"

همونطور که توی نتایج میبینید میتونیم لیست داریی‌ها رو از رو عنوان هر سرچ ببینیم و اینطوری لیست دارایی‌ها رو پیدا کنیم.

سایت Google Dork/Wikiped

با استفاده از دورک‌های مختلف و کمی خلاقیت میتونید دارایی‌های بیشتری از کمپانی موردنظرتون پیدا کنید. چند تا از گوگل دورک‌هایی که من استفاده کردم اینا بودن:

"acquired by [CompanyName]"
"[companyName] acquires"
"[companyName] buys"
"[companyName] acquisition"
"[companyName] All rights reserved"

یک منبع خیلی غنی دیگه که میتونید استفاده کنید wikipedia هستش، من زیاد تکنیک خاصی برای استفاده ازش ندارم و صرفا به عنوان یک کاربر عادی ازش استفاده کردم تا ببینم کمپانی موردنظر من چه شرکت‌ها و زیرمجموعه‌هایی داره که بتونم از طریق اونا به دامین و دارایی‌های بیشتری از تارگتم برسم.

سایت Crt.sh

استفاده از این سایت خیلی سادس، برای راحتی میتونید از دستور زیر استفاده کنید (حتما قبلش unfurl رو نصب داشته باشید و اسم کمپانی که مد نظرتون هست رو خودتون توی دستور بنویسید):

curl -sk 'https://crt.sh/?o=[companyName]&output=json' | jq -r '.[].common_name' | unfurl apexes | sort -u

این دستور لیست دامین‌ها رو به شما برمیگردونه ولی شما میتونید بر حسب نیاز خودتون خروجی دلخواه رو از دستور cURL بالا بگیرید.

یادتون باشه که مبحث Wide Recon خیلی گستردس و هر هانتر روش‌های مختلفی رو برای پیدا کردن دارایی‌های تارگت موردنظرش انتخاب میکنه. شما هم باتوجه به خلاقیت خودتون و منابعی که وجود داره باید متدولوژی ریکان خودتونو به مرور زمان درست کنید. بعد از اینکه از منابعی که بالا گفتم استفاده کردم، به تعداد زیادی از دامین‌ها و سابدامین‌ها رسیدم که نیاز بود ۲ کار روشون انجام بشه: اول نیاز بود که دامین‎ها و سابدامین‌ها verify بشن، یعنی مطمئن بشیم که متعلق به تارگت هستند و شامل موارد in-scope میشن. روش‌های زیادی برای verify کردن وجود داره که ساده ترینشون از طریق ssl certificate هست. بعد از verify کردن assetهایی که جمع کردیم، باید با کمک ابزارهایی مثل httpx، ببینیم که کدوما روشون سرویس http بالا هست که بتونیم روشون کار کنیم. خب اینجا دیگه بحث Wide Recon تموم میشه و میریم سراغ مرحله بعد که Narrow Recon و خود آسیب پذیری‌ها رو شامل میشه.

فاز Narrow Recon

وقتی به این دامین آسیب‌پذیر از تارگت رسیدم شروع کردم به کار کردن باهاش و سعی کردم از تمام قسمت‌ها مثل یک کاربر معمولی استفاده کنم. تارگت در واقع یک سایت فروشگاهی بود که کاربر میتونست برای خودش محصولی که میخواد رو سفارش بده. پروسه Narrow Recon زیاد طول نکشید چون کلا تارگت جمع و جوری بود و زمان زیادی برای شناختش لازم نبود اما یک بخش که همیشه ازش باگ‌های خوبی میتونه به‌وجود بیاد، قسمت‌های مربوط به Authentication/Authorization هستش.

بعد از ساخت حساب کاربری شروع کردم به کار کردن با قسمت‌های مختلفی که بعد از ورود به حساب کاربری قابل دسترس بودن. قسمت‌های زیادی نداشت ولی شروع کردم به ترتیب هر کدومو تست کردن اما نتیجه ای نداشت و کم کم داشتم ناامید میشدم. توی تارگت یک قسمت وجود داشت که کاربر میتونست برای خودش لیست خرید درست کنه و بهشون محصول اضافه بکنه (اکثر سایت‌های فروشگاهی این قسمتو دارند). این قسمت‌هم مثل بقیه قسمت‌های تارگت شروع کردم به تست کردن. اول از درخواست مربوط به ایجاد لیست خرید جدید شروع کردم، ساختار درخواست شبیه این بود:

چیزی که توی نگاه اول ممکنه به چشم بخوره مقدار variable هست که به نظر یک مقدار base64 شده هست، بعد از Decode کردن این مقدار به این دیتای جیسونی میرسیدیم:

{"user":"user@gmail.com","name":"list1"}

که مقدار user ایمیل حساب کاربری خودم بود، ولی خب شاید این سوال پیش بیاد که اگر ایمیل یک کاربر دیگه رو بدم چی؟ آیا لیست خرید برای اون حساب ساخته میشه؟ بله ساخته میشه! و این شد اولین IDOR 🙂

معمولا وقتی یک قسمت از تارگت باگ داره، احتمال پیدا کردن باگ‌های بیشتر در همون قسمت هست. در این قسمت بخش‌های دیگه‌ای هم وجود داشتند که بعد از پیدا کردن این باگ با اشتیاق بیشتری شروع کردم به تست کردنشون. توی تارگت درخواستی وجود داشت که کاربر میتونست لیست یا لیست‌های خرید مربوط به حساب کاربری خودشو ببینه. درخواست مربوط به این بخش شبیه این بود:

با base64decode کردن مقدار variable به این مقدار جیسونی میرسیدیم:

{"user":"user@gmail.com"}

که باز هم همون تست باگ قبلی اینجا هم جواب داد و با عوض کردن ایمیل به ایمیل قربانی میتونستیم لیست خرید قربانی رو ببینیم! و در آخر برای باگ سوم هم یک قسمتی بود برای اضافه کردن محصول به لیست خرید کاربران که درخواستش به این صورت بود:

ولی این‌بار با base64decode کردن مقدار variable به مقدار جیسونی زیر میرسیدیم:

{"user":"user@gmail.com","name":"list","items":[{"id":"44197","qty":1,"notes":""}],"id":"1f5617e1-0722-11ef-8452-0affd175d2a9"}

که اینجا علاوه بر داشتن ایمیل قربانی، باید id مربوط به لیست خرید اون هم میدونستیم! که خب اینجا 2 راه حل وجود داره:

• چون UUID ورژن یک بود، میتونستیم بر اساس timestamp تولیدش بکنیم و اینطوری به UUID های بیشتر برسیم.
• توی وب اپلیکیشن دنبال مسیرهایی بگردیم که به ما UUID کاربرهای دیگه رو نشون بده. خوشبختانه همچین مسیری توی وب اپلیکیشن وجود داشت! توی آسیب پذیری دومی که باهم برسی کردیم که میشد باهاش لیست خرید کاربرهای دیگه رو دید، در جواب درخواست UUID مربوط به اون لیست خرید هم افشا میشد و به راحتی میتونستیم ازش استفاده کنیم.

این‌ها آسیب‌پذیری‌هایی بودن که روی این تارگت پیدا کردم ولی آیا اینجا باید متوقف بشیم؟ قطعا نه!

همونطور که گفتم تارگت از اسکوپ خیلی بزرگی استفاده میکرد و همین احتمال وجود این آسیب‌پذیری‌ها رو در دامین‌های دیگه این کمپانی بیشتر میکرد. پس شروع کردم به گشتن دنبال این آسیب‌پذیری‌ها در دامین‌های دیگه کمپانی و حدسم درست بود 🙂 دقیقا همین آسیب‌پذیری‌ها در یک دامین دیگه از کمپانی پیدا شد و مجموعا ۶ آسیب پذیری IDOR به کمپانی گزارش داده شد.

در آخر دوست دارم چندتا نکته که به نظر خودم توی پیدا کردن این آسیب‌پذیری‌ها برام جوابگو بودن رو باهم مرور کنیم:

• همیشه تا جایی که میتونید تارگت رو بشناسید و تمام بخش‌هارو قبل از شروع تستتون مثل یک کاربر عادی چک کنید
• هیچ وقت خودتونو دست کم نگیرید و اینو بدونید که احتمال پیدا شدن باگ توی هر تارگتی وجود داره
• اگر اسکوپ تارگتتون خیلی بزرگ بود، احتمال وجود یک باگ یکسان در دامین‌ها و سابدامین‌های دیگه اون تارگت خیلی زیاد هست

خیلی ممنونم که تا اینجا وقت گذاشتید و مطالعه کردید.

امیدوارم براتون مفید بوده باشه.