آشنایی با متدولوژی Burp Suite – بخش بیست و دوم

در این بخش از مجموعه آشنایی با متدولوژی Burp Suite به بخش بیست و دوم از این متدولوژی به استفاده از ابزار Burp Suite به منظور اکسپلویت Blind SQL Injection می پردازیم.

در مقاله شناسایی Blind SQL Injection با استفاده از Burp Suite، چند روش ممکن برای شناسایی آسیب‌پذیری‌های Blind SQL Injection را بررسی کردیم.

در این مقاله ما یک گام فراتر رفته و از آسیب‌پذیری که در بخش Boolean Condition Injection در مقاله قبلی کشف کرده‌ایم بهره‌برداری می‌کنیم.
علاوه بر این، نحوه استفاده از SQLmap با Burp و ارتقاء حمله پایگاه داده برای دستیابی به Command Injection را توضیح می‌دهیم.

Using Burp Intruder to Exploit Blind Bugs

قبلاً یک باگ Blind SQL Injection را در یک برنامه وب آموزشی که عمداً آسیب پذیر بود شناسایی کرده بودیم.

در این مثال ما به دنبال شماره پین هستیم که با cc_number در اسکرین شات مطابقت دارد.

برای پیدا کردن پین، می‌توانیم عدد را در دستور SQL تغییر دهیم و منتظر بمانیم تا برنامه یک پاسخ “True” صحیح ایجاد کند.

برای کمک به سرعت بخشیدن به این کار، می توانیم از Burp Intruder برای خودکار کردن فرآیند استفاده کنیم.

در هر نقطه از درخواست کلیک راست کرده و روی Send to Intruder کلیک کنید.

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

در قسمت Payloads از بخش Intruder، نوع پیلود مورد نظر که در این بخش Numbers هست را انتخاب می کنیم.

در این مثال ما قصد داریم تا هر عدد پین را از 0000 تا 9999 تزریق نماییم. پس از تعیین این بخش، بر روی دکمه Start Attack کلیک کنید.

با شروع حمله، پنجره Intruder Attack باز می‌شود.

ما به دنبال نشانه ای هستیم مبنی بر اینکه برنماه یک پاسخ True دریافت کرده است.

در این مثال، یک پاسخ True، با عبارت Account number is valid نشان داده می شود.

در این بخش ما می‌توانیم از قابلیت Grep – Match به منظور مشاهده پیام های خطای مذکور در پاسخ، استفاده کنیم.

پس از اعمال “Grep – Match” می بینیم که پیلود 2364 یک پاسخ “True” را از برنامه ایجاد می‌کند.

با ارسال پیلود در فرم موجود در صفحه، می‌توانیم صحت آن را تأیید کنیم و شماره پین صحیح را پیدا نماییم.

یک سوء استفاده موفقیت‌آمیز از آسیب‌پذیری تزریق SQL اغلب منجر به دسترسی و به خطر افتادن کل داده‌های برنامه می‌شود.

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

یکی از خطرناک ترین روش ها در ادامه حمله SQL Injection، تزریق دستور یا Command Injection است.

در این مثال ما قابلیت xp_cmdshell را در Microsoft SQL Server توضیح می‌دهیم.

Injecting System Commands Via SQL Injection

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

قابلیت xp_cmdshell به کاربرانی که مجوزهای DBA دارند اجازه می‌دهد تا دستورات سیستم عامل را مانند خط فرمان cmd اجرا کنند.

ابتدا باید وجود یک آسیب‌پذیری تزریق SQL را با استفاده از یکی از روش‌های بیان شده در آموزش‌های قبلی تأیید کنید.

سپس می توانید سعی کنید از یک رویه ذخیره شده (Stored Procedure) برای اجرای دستورات سیستم عامل استفاده کنید.

با این حال، اکثر نمونه‌های Microsoft SQL Server که در اینترنت و یا شبکه‌های داخلی با آن‌ها مواجه می‌شوند، نسخه 2005 یا بالاتر خواهند بود.

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

با این حال، اگر حساب کاربری برنامه وب در پایگاه داده از امتیازات کافی برخوردار باشد(مانند sa)، می‌توان به سادگی با پیکربندی مجدد پایگاه داده بر این موانع غلبه کرد.

اگر xp_cmdshell غیرفعال باشد، در صورت وجود دسترسی لازم، می‌توان آن را با رویه ذخیره شده sp_configure دوباره فعال کرد.