در این بخش از دوره آموزشی SEC542 از موسسه SANS با مبحث تکمیلی در SQL Injection آشنا شده و همچنین به معرفی برخی از ابزارهای حمله SQL Injection می پردازیم.
حملات بالقوه SQLi
بررسی تمام حملات بالقوه‌ای که می‌توان با SQLi برای تمام backend ها پیاده‌سازی نمود خارج از محدوده درس ماست. اما بصورت خلاصه بعضی کارهایی که می‌توان با SQLi انجام داد را برمی‌شماریم.
دسترسی به دیتای یک سازمان به منظور تغییر دادن یا پاک نمودن آن، می‌تواند حرکت شوکه کننده‌ای برای یک سازمان باشد. گرچه ما همیشه اجازه این کار را نخواهیم داشت. بسیاری از سازمان‌ها مکانیزم‌های کنترلی مناسبی برای تشخیص یکپارچگی دیتا در مواقع حساس (تغییر ناگهانی و غیرمنتظره دیتا) ندارند. همچنین از بین رفتن دیتا برای سازمان‌ها معمولا ترسناک است.
تکنیک مبتنی بر دیتای دیگری که می‌توانیم استفاده کنیم، وارد نمودن دیتا در دیتابیس، به منظور حمله به کاربران یک اپلیکیشن است. در این مورد نیز دقت زیادی داشته باشید که اجازه ثبت اطلاعات را قبلا از کارفرما گرفته باشید.
خواندن و نوشتن فایل (منظور فایل است نه رکوردهای دیتابیس)، از دیگر تکنیک‌های کاربردی است. توانایی نوشتن/ساختن یک فایل می‌تواند بسیار تاثیرگذار باشد مثلا می‌توان از سرور دیتابیس یک shell وب گرفت. در بخش بعد راجع به این موضوع صحبت خواهیم کرد.
غیر از خواندن و نوشتن فایل، ممکن است بتوانیم ارتباطات دیگری با سیستم‌عامل برقرار کنیم. مثلا در MS SQL Server ، ممکن است به کلیدهای رجیستری دست یافته و بتوانیم عملیات add ، delete ، read یا modify بر روی آن‌ها انجام دهیم.
بطور خلاصه برخی از حملات بالقوه SQLi در زیر لیست شده است:
• حذف و یا تغییر دیتای ارزشمند
• می‌توان انتظار رمز شدن اطلاعات حیاتی دیتابیس توسط یک باج‌افزار را داشت.
• تزریق دیتا به عنوان پیلودهای Stored XSS
• بالا بردن سطح دسترسی در دیتابیس (DB privilege escalation)
• خواندن فایل
• MySQL – LOAD_FILE()
• SQL Server – BULK INSERT
• نوشتن فایل
• MySQL – INTO OUTFILE
• ارتباط با سیستم‌عامل
• SQL Server تعداد زیادی stored procedure دارد که امکان دسترسی به سیستم‌عامل را در اختیار ما قرار می‌دهد.
SQLi -> Write File -> Shell
اگر قابلیت نوشتن فایل بر روی سرور دیتابیس را داشته باشیم، آنگاه ممکن است بتوانیم کارهای جالبی انجام دهیم. یکی از پرطرفدارترین تکنیک‌های اجرا شده با SQL injection، گرفتن shell از سرور دیتابیس است.
می‌توانید این تکنیک را مانند یک باگ file upload روی یک وب‌سرور در نظر بگیرید که به ما اجازه می‌دهد بر روی مسیرهای اجرایی، فایل بنویسیم. در اصل، گرفتن shell با استفاده از SQLi شباهت زیادی به آپلود web shell بر روی وب‌سرور دارد.
واضح است که سرور دیتابیس باید یک وب‌سرور نیز داشته باشد تا بتوانیم از راه دور به آن وصل شویم. همچنین کاربر سرویس دیتابیس باید اجازه نوشتن فایل بر روی web root را داشته باشد. علاوه بر آن، برای رندر کردن فایل نوشته شده، باید به وب‌سرور دسترسی داشته باشیم. پس با یک بررسی کلی می‌بینیم که در خیلی موارد، موانع زیادی بر سر راه ما قرار دارند.
در اکثر مواردی که یک باگ SQLi ما را به یک web shell می‌رساند، تست نفوذپذیری از شبکه داخلی سازمان صورت می‌گیرد که به web root سرور دیتابیس دسترسی داریم یا در سناریوهای پیچیده‌تری که شامل دستکاری در شبکه داخلی سازمان و انجام عملیات pivot است.
تکنیک‌های دیگری نیز برای گرفتن shell از طریق SQLi وجود دارند که نیازمند پشتیبانی شدن stacked queries توسط دیتابیس هستند. در بخش‌های بعد، ابزار sqlmap را بررسی می‌کنیم که رایج‌ترین ابزار/متد استفاده شده برای گرفتن shell از طریق SQL injection است.
SQLi Cheat Sheets
اگرچه بیشتر مفاهیم و تکنیک‌ها در همه ارائه‌دهندگان DB ، مشترک است، اما تفاوت‌هایی نیز بین آن‌ها وجود دارد. در این بخش، لیست برخی از برگه‌های تقلب خوبی که بصورت عمومی در دسترس قرار گرفته‌اند، ارائه شده است.
WebSec SQL Injection Knowledge Base – https://websec.ca/kb/sql_injection
pentestmonkey SQL Injection Cheat Sheets – http://pentestmonkey.net/category/cheat-sheet/sql-injection
SQL Injection Wiki Cheat Sheet – http://www.sqlinjectionwiki.com
برای مقابله و جلوگیری از SQLi نیز، برگه تقلب OWASP را داریم:
OWASP SQL Injection Prevention Cheat Sheet – https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
نکته: اطلاعات اکثر این لینک‌ها به روزرسانی نمی‌شوند بنابراین بهتر است با مراجعه به منابع DB provider خود، از صحیح بودن قواعد دستورات اطمینان حاصل نمائید.
ابزارهای SQLi
با توجه به اهمیت SQL Injection، طبیعی است که ابزارهای مناسب زیادی در این زمینه ایجاد شده باشند. اما متاسفانه همچنین چیزی صحت ندارد. بیشتر ابزارهای در دسترس، قدیمی بوده و به روزرسانی نشده‌اند. علاوه بر آن، این ابزارها معمولا بجز استخراج دیتا، کارایی دیگری در اکسپلویت SQLi ندارند. همچنین بعضی از آن‌ها فقط دیتابیس‌های خاصی را پشتیبانی می‌کنند.
خوشبختانه، ما sqlmap را داریم که ابزاری بسیار قوی بوده و بطور فعال رو به رشد و بهبود است. تا به امروز، sqlmap بصورت متناوب، پکیج جدید منتشر نکرده است اما ممکن است این روند در آینده تغییر کند. با این حال، سورس کد و اسکریپت sqlmap.py دائما به روزرسانی شده و بصورت رایگان ارائه می‌شوند. بنابراین بهتر است بجای استفاده از پکیج sqlmap موجود در توزیع لینوکس خود، از sqlmap موجود در Github استفاده کنید.
ما در یک بخش بطور مختصر به ابزار BBQSQL می‌پردازیم که مانند اکثر ابزارهای SQLi توسعه نیافته است. سپس توجه خود را به sqlmap باز می‌گردانیم.
BBQSQL
BBQSQL یک فریم‌ورک مبتنی بر پایتون است که برای کشف و اکسپلویت باگ‌های blind SQL injection استفاده می‌شود. این ابزار محصولی از Neohapsis Labs بوده که برای اولین بار در DEFCON 20 معرفی شد. BBQSQL ابزاری سریع و نسبتا ساده برای تست باگ‌های blind SQL injection است. گرچه مرور کامل قابلیت‌های این ابزار خارج از بحث ماست، اما چند نکته حائز اهمیت راجع به این ابزار وجود دارد که به آن‌ها اشاره می‌کنیم.
BBQSQL دو تکنیک حمله دارد: binary search و frequency search . با این متدها، BBQSQL یک بازی 20 سوالی برای اکسپلویت blind SQL injection انجام می‌دهد. تکنیک binary search، تکنیک پیش‌فرض این ابزار بوده و نحوه کار آن به این صورت است که با هر سوال، بازه کاراکترهای مورد انتظار را نصف می‌کند. مثلا اگر اولین کاراکتر نام اولین کاربر بزرگتر از m باشد، مقدار true برمی‌گرداند. مقدار false نشان‌دهنده آن است که کاراکتر مورد نظر ما کوچکتر یا مساوی m است. در این حالت BBQSQL بازه a-m را به دو نیمه تقسیم کرده و سوال بعدی را می‌پرسد.
تکنیک frequency search به شیوه دیگری عمل کند. این روش بر اساس آنالیز فرکانس استفاده از حروف در متون انگلیسی، عمل می‌کند. اگر dataset مورد نظر ما، یک متن استاندارد انگلیسی باشد، استفاده از این روش با سرعت بسیار بالایی همراه خواهد بود. اما در صورت وجود اعداد، hash ها یا کاراکترهای رندوم، اوضاع به این صورت نخواهد بود.
چه از تکنیک binary استفاده شود و چه از تکنیک frequency ، BBQSQL را می‌توان به گونه‌ای تنظیم کرد که از بین مقادیر زیاد، به دنبال یافتن تفاوت‌هایی مبنی بر true/false بودن کوئری باشد. این تنظیمات شامل نگاه کردن به زمان پاسخگویی اپلیکیشن، هدرهای HTTP ، محتوای بازگشتی، سایز دیتای برگردانده شده، status code های HTTP ، encoding ، کوکی‌ها و مواردی از این قبیل می‌باشد.
برای کسب اطلاعات بیشتر به لینک زیر مراجعه کنید.
