مقدمه

سلام، من محمدحسین از آکادمی Pentesterland هستم و حدود دو ساله که تو حوزه امنیت کار می‌کنم.

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

قبل از اینکه سناریو و روش حمله رو توضیح بدم، بهتره اول نحوه کار برنامه رو بگم تا راحت‌تر متوجه بشید حمله چطور انجام شده.

این شرکت توی زمینه نقشه‌برداری دیجیتال و سرویس‌های مکان‌یابی فعالیت داشت. بعد از ثبت‌نام، ادمین می‌تونست روی پلتفرم برنامه‌ها و پروژه‌های مختلفی بسازه و افراد رو با نقش‌های مختلف دعوت کنه. کاربرای عادی هم می‌تونستن برای خودشون پروژه بسازن و افرادی رو به پروژه خودشون دعوت کنن و بهشون یه role بدن، ولی دسترسی‌های دیگه‌ای مثل دعوت بقیه به پلتفرم اصلی یا مدیریت پلتفرم رو نداشتن.

شروع حمله

• برای شروع، من یه حساب کاربری به عنوان ادمین اصلی پلتفرم ساختم و اکانت دومم به اسم Attacker رو به‌عنوان یه کاربر معمولی به پلتفرم دعوت کردم.

• اولین سناریویی که معمولاً به ذهن می‌رسه، اینه که از نقطه پایانی (API) ادمین استفاده کنی و نقش خودت رو به مدیر تغییر بدی، اما تو ۹۹٪ مواقع، پلتفرم همچین اجازه‌ای بهت نمی‌ده.

  

• در تصویر بالا، من سعی کردم با استفاده از توکن Attacker (کاربر معمولی) یک درخواست به API ادمین بفرستم و نقش خودم رو به مدیر سازمان تغییر بدم. اما همون‌طور که انتظار می‌رفت، سیستم جلوی من رو گرفت.

• رفتم به Burp تا درخواست‌های رد شده رو بررسی کنم و این چیزی بود که متوجه شدم:

  • یک Endpoint وجود داشت که id مرتبط با هر role رو برمی‌گردوند. این id برای هر سازمان متفاوت بود.

• تا اینجا تونستیم id مربوط به هر role رو به دست بیاریم.

• به بخش پروژه ها رفتم و بعد از ایجاد یک پروژه، کاربری رو دعوت کردم و به اون نقش ProjectAdmin اختصاص دادم.

• سپس درخواست مربوط به این عملیات رو به Repeater فرستادم.

• در بخش زرد، id مربوط به ProjectAdmin قرار داره و در بخش دوم (خط سبز) id کاربر.

• اینجا یک نکته جالب به ذهنم رسید!!! یعنی امکان داره یه رابطه ایی بین role های پروژه با role های اصلی پلتفرم وجود داشته باشه؟؟؟ اگه داشته باشه ، آیا برنامه چک میکنه فقط به role های مربوط به پروژه دسترسی داشته باشم؟؟؟پس احتمال داره بتونم با این Endpoint به role سطح بالاتر دسترسی پیدا کنیم. بریم چکش کنیم.

• در بخش زرد، id مربوط به OrgAdmin رو وارد کردم و در فیلد user_id شناسه خودم (Attacker) رو وارد کرده و درخواست رو ارسال کردم.

• انتظار داشتم که پاسخ ۲۰۰ دریافت کنم، اما دوباره ۴۰۳ به من داد.

• درخواست رو چندبار پشت سرهم ارسال کردم و پاسخ همچنان ۴۰۳ بود. اما یک چیز توجه من رو جلب کرد.

• در درخواست‌های اول و دوم، زمان پاسخ (Response Time) ۲۲۷ میلی‌ثانیه بود، اما در درخواست سوم، زمان پاسخ به‌طور ناگهانی به ۱۳۳۱ میلی‌ثانیه رسید!!!

• به فکرم رسید که اینجا Race Condition رو تست کنم. برای همین درخواست رو به Turbo Intruder فرستادم.

• تعداد درخواست‌ها رو روی ۳۰ تنظیم کردم و حمله رو شروع کردم. ناگهان توی یکی از پاسخ‌ها، یک پاسخ ۲۰۴ دیدم!

• و در آخر بخش کاربران در صفحه اصلی رفتم و صفحه رو رفرش کردم و دیدم که حساب من با موفقیت به عنوان مدیر سازمان (Org Admin) تنظیم شده بود!

نتیجه گیری

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

نویسنده: محمدحسین محیط