ماشین‌حساب CVSS راورو چگونه کار می‌کند؟

راورو در محاسبه‌ی میزان خطر آسیب‌پذیری‌ها از فرمول CVSS استفاده می‌کند. ما در این بلاگ‌پست قصد داریم توضیح دهیم که: CVSS چیست؟ سیستم امتیازدهی CVSS چگونه ایجاد شده است؟ و چرا در راورو مورداستفاده قرار می‌گیرد؟ سیستم امتیازدهی CVSS شامل چه بخش‌هایی است؟ سپس به توضیح تک‌تک پارامترهای موثر در محاسبه‌ی «امتیاز پایه» در ماشین‌حساب CVSS راورو و پیش‌بردن قدم‌به‌قدم یک مثال بپردازیم.

CVSS چیست؟

CVSS مخفف‌شده‌ی عبارت Common Vulnerability Scoring System و مبنایی بین‌المللی برای ارزیابی و تعیین میزان خطر آسیب‌پذیری‌ها برای سیستم‌هاست. هر آسیب‌پذیری بر اساس مجموعه امتیازهایی که بر اساس پارامترهای مشخص در این فرمول کسب می‌کند، در رده‌های مختلف، پایین تا حساس، جای می‌گیرد. بازه‌ی امتیازی CVSS از صفر تا 10 است. هر چه امتیاز بالاتر باشد، به معنی خطر بیش‌تر آن آسیب‌پذیری است.

سیستم امتیازدهی CVSS چگونه ایجاد شده است؟ و چرا در راورو مورداستفاده قرار می‌گیرد؟

در طی سال‌های 2003 و 2004 پژوهش‌هایی توسط شورای زیرساخت ملی ایالات متحده‌ی آمریکا یا NIAC انجام شدند، که منجر به ایجاد نسخه اولیه‌ی CVSS در ماه فوریه‌ی سال 2005 گشتند. نسخه‌ی اول CVSS یا CVSSv1 با هدف "طراحی استانداردی جهانی برای رتبه‌بندی آسیب‌پذیری‌های نرم‌افزاری" منتشر شد.

ماشین‌حساب CVSS وب‌سایت راورو نیز به دلیل اعتبار این مدل، امتیازدهی خود را بر مبنای آخرین نسخه‌ی موجود CVSS (منتشرشده در فوریه‌ی 2019) انجام می‌دهد. امتیازدهی به گزارش‌های آسیب‌پذیری در فرآیند داوری در راورو نیز برهمین اساس صورت می‌گیرند.

سیستم امتیازدهی CVSS شامل چه بخش‌هایی است؟

پارامترهای سنجش و ارزیابی آسیب‌پذیری در ماشین‌حساب CVSS راورو شامل سه بخش اصلی است، که عبارتند از:

• امتیاز پایه: معیارهای اساسی که برای سنجش ویژگی های ذاتی آسیب‌پذیری هستند.

• Temporal Score: معیارهای زمانی برای ویژگی هایی که در طول عمر آسیب‌پذیری تکامل می یابند.

• Environmental Score: معیارهای محیطی برای آسیب‌پذیری‌هایی که به اجرا یا محیط خاصی بستگی دارند.

ما در این بلاگ‌پست به توضیح بخش اول و پایه‌ی امتیازدهی CVSS ،به نام «امتیاز پایه» ، در ماشین‌حساب CVSS راورو می‌پردازیم.

سناریوی حمله‌ی مثالی:

از آن‌جایی که می‌خواهیم در کنار توضیح هر بخش، به عنوان مثال یک سناریوی حمله‌ی مشخص را نیز با استفاده از ماشین‌حساب CVSS راورو امتیازدهی کنیم، بگذارید توضیح کوتاه و خلاصه‌ا‌ی از سناریوی حمله‌ی مورداستفاده به عنوان مثال را، ارائه کنیم.

اکسپلویت آسیب‌پذیری MySQL Stored SQL Injection

ما در این سناریو می‌دانیم که در MySQL Server آسیب‌پذیری‌ای وجود دارد که به مهاجم این امکان را می‌دهد که از راه دور و به وسیله‌ی یک حساب کاربری احراز هویت شده کد SQL‌ای را تزریق کند و این کد را با دسترسی بالا بر روی یک پایگاه‌داده‌ی MySQL اجرا کند. این حمله زمانی موفق خواهد بود که داده‌های پایگاه‌داده‌ی MySQL ذکرشده، قابل‌خواندن و قابل‌تغییر شوند و مهاجم بتواند آن‌ها را بخواند و یا تغییر دهد. حمله از سوی مهاجم، نیازمند یک حساب کاربری بر روی پایگاه‌داده‌ی MySQL Server برای ورود به رابط کاربری پایگاه‌داده است. این اکانت باید دسترسی تغییر identifierها مانند نام جداول را داشته باشد. هم‌چنین این اکانت باید بر روی پایگاه‌داده‌ای باشد که برای رونویسی داده‌ها بر یک یا چند پایگاه‌داده پیکربندی شده باشد. مهاجم با ورود به اکانت، identifier را به مقداری جدید تغییر می‌دهد که این مقدار واردشده، شامل یک کاراکتر کوتیشن و در ادامه‌ی آن کد مخرب SQL است. این کد SQL تزریق‌شده و مخرب بر روی یک یا چند پایگاه‌داده‌ای که گفتیم اجرا می‌شود و حمله با موفقیت صورت می‌پذیرد.

( اگر از علاقه‌مندان به آسیب‌پذیری SQL Injection هستید، در بلاگ‌پست «SQL Injection؛ راهبردها و ترفندها» می‌توانید درباره‌ی این آسیب‌پذیری بیش‌تر بخوانید. )

«امتیاز پایه» در ماشین‌حساب CVSS راورو:

بخش «امتیاز پایه‌» شامل هشت پارامتر سنجش آسیب‌پذیری است، که عبارتند از:

• Attack Vector

• Access Complexity

• Privileges Required

• User Interaction

• Scope

• Confidentiality

• Integrity

• Availability

در ادامه، به توضیح هر یک از پارامترهای سنجش آسیب‌پذیری، به همراه مثال، می‌پردازیم:

Attack Vector

در این پارامتر "نحوه‌ی دسترسی به سیستم برای اکسپلویت" بررسی می‌شود. Attack Vector به طور کلی به دو بخش فیزیکی و منطقی (محلی و ...) تقسیم می‌شود که با توجه به محیط یا حالتی از دسترسی به سیستم که در آن اکسپلویت انجام شده است، باید یکی از موارد زیر انتخاب شود:

• Physical: در صورتی که دسترسی فیزیکی به سیستم، وجود داشته باشد.

• Local: در صورتی که دسترسی به اکانت محلی، وجود داشته باشد.

• Adjacent: در صورتی که به ‌broadcast یا collision domain سیستم آسیب‌پذیر، دسترسی وجود داشته باشد.

• Network: در حالتی که محیط اکسپلویت آسیب‌پذیری مربوط به لایه‌های بالای شبکه مانند Application و ... باشد. این نوع آسیب‌پذیری‌ها اغلب به عنوان قابل‎اکسپلویت از راه دور یا remotely exploitable شناخته می‌شوند.

حالات اکسپلویت مختلفی برای آسیب‌پذیری‌ها وجود دارند که مربوط به یک سیستم محلی که از راه دور در دسترس نیست، هستند. راه‌های اکسپلویت آن‌ها از دو مورد اول یعنی Physical و Local قابل انجام است. به همین شکل، آسیب‌پذیری‌هایی نیز وجود دارند که از راه دور قابل اکسپلویت‌شدن هستند که در این موارد می‌توان Network و Adjacent را مشخص کرد. عمده‌ی آسیب‌پذیری‌ها مشمول گزینه‌ی Network می‌شوند.

به عنوان مثال؛ چون در حمله‌ی MySQL Stored SQL Injection، مهاجم باید با استفاده از بستر شبکه به پایگاه‌داده‌ی MySQL متصل شود. گزینه‌ی مناسب این پارامتر برای این حمله، "Network" است.

پیچیدگی حمله یا Attack Complexity

این پارامتر مربوط به "پیچیدگی اکسپلویت یک آسیب‌پذیری در سیستم" است. در این پارامتر، مشخص می‌شود که "حمله نیاز به اطلاعات بیش‌تر دارد؟ یا خیر؟". گزینه‌های این پارامتر به شرح زیر هستند:

• بالا «H»: در صورتی که شرایط خاصی برای دسترسی وجود داشته باشد و نفوذ پیچیده باشد. به عنوان نمونه race condition یکی از شرایط خاص باشد. در این مواقع اغلب به مهندسی اجتماعی یا حملات Man-In-The-Middle نیاز می‌شود.

• پایین «L»: اگر شرایط و پیچیدگی خاصی برای اکسپلویت وجود نداشته باشد. این به آن معنی است که سیستم برای تعداد زیادی از کاربران در دسترس است یا تنظیمات آسیب‌پذیر موجود بر روی سیستم آشکار است و پیچیدگی خاصی برای انجام حمله وجود ندارد.

فرض کنید هدفی را مورد حمله قرار می‌دهیم و چون به صورت BlackBox پیش می‌رویم ممکن است به طور مکرر به در بسته بخوریم. در این شرایط که گرفتن دسترسی کار آسانی نیست، پیچیدگی حمله بالا می‌رود و نیاز به اطلاعات بیش‌تر درباره‌ی سیستم مورد هدف بیش از پیش احساس می‌شود. در این موارد، اصطلاحا می‌توان گفت: "پیچیدگی حمله بالاست." در غیر این‌ صورت، یعنی اگر نفوذ سخت نباشد پیچیدگی پایین را در نظر می‌گیریم.

به عنوان مثال؛ چون در حمله‌ی MySQL Stored SQL Injection، باید امکان رونویسی بر روی پایگاه‌داده‌ی هدف، فعال باشد و چون فعال است، پیچیدگی خاصی مانع از حمله نمی‌شود. گزینه‌ی مناسب برای این حمله، "پایین «L»" است.

Privileges Required

در این پارامتر "میزان دسترسی‌ موردنیاز برای اکسپلویت آسیب‌پذیری در سیستم" را مشخص می‌کند. گزینه‌های این پارامتر به شرح زیر هستند:

• بالا «H»: در صورتی که برای انجام حمله، ورود به سیستم با دسترسی ادمین نیاز باشد. اگر سطح دسترسی ادمین باشد، احتمال دسترسی به بخش‌های حساس نیز بالا می‌رود.

• پایین «L»: اگر ورود به سیستم به صورت کاربر عادی ( غیر ادمین ) برای اکسپلویت آسیب‌پذیری نیاز باشد. در این حالت معمولا دسترسی به بخش‌های غیرحساس وجود دارد.

• هیچ‌کدام «N»: در صورتی که به ورود به سیستم برای اکسپلویت آسیب‌پذیری نیاز نباشد.

در بعضی سیستم‌ها دسترسی‌های خاصی برای انجام حمله نیاز می‌شود. اگر در فرآیند حمله، برای تغییراتی در تنظیمات سیستم، دسترسی کاربری خاصی مانند دسترسی ادمین نیاز باشد، میزان دسترسی بالا «H» خواهد بود و باید گزینه‌ي بالا «H» را انتخاب کنیم. اما اگر نیازی به دسترسی ادمین نباشد و برای اکسپلویت آسیب‌پذیری، صرفا سطح دسترسی کاربر عادی نیاز باشد، گزینه‌ی پایین «L» را انتخاب می‌کنیم. در غیر این دو صورت نیز، گزینه‌ی انتخابی باید "هیچ‌کدام" باشد.

به عنوان مثال؛ چون در حمله‌ی MySQL Stored SQL Injection، مهاجم فقط یک اکانت با دسترسی عادی لازم داشت ( هر چند این امکانات برای یک اکانت کاربر عادی به طور پیش‌فرض فراهم نیست، اما این‌جا نیازی به اکانت با دسترسی بالاتر نبود.) پس گزینه‌ی مناسب در این پارامتر برای این حمله، "پایین «L»" است.

تعامل کاربر یا User Interaction

این پارامتر مشخص می‌کند که: "اکسپلویت آسیب‌پذیری در سیستم، نیاز به تعامل و یا انجام کاری از سمت کاربر را دارد؟ یا خیر؟". گزینه‌های این پارامتر به شرح زیر هستند:

• مورد نیاز «R»: اگر پیش از اکسپلویت موفق سیستم، نیاز به انجام عملی از سوی کاربر وجود داشته باشد.

• هیچ‌کدام «N»: در صورتی که نیازی به تعامل کاربر با سیستم برای اکسپلویت سیستم، نباشد.

آسیب‌پذیری‌هایی مانند XSS نیاز به تعامل کاربر دارند. این بدین معنی است که کاربر باید عملی را انجام دهد تا آسیب‌پذیری بروز پیدا کند و اکسپلویت شود. برای این نوع آسیب‌پذیری‌ها که نیازمند انجام کاری از سوی کاربر هستند، باید گزینه‌ی "مورد نیاز «R»" را انتخاب کنیم.

به عنوان مثال؛ چون در حمله‌ی MySQL Stored SQL Injection، هیچ تعاملی از سمت کاربر نیاز نیست و رونویسی یا Replication به صورت خودکار انجام می‌شود. گزینه‌ی مناسب برای این حمله، "هیچ‌کدام «N»" است.

Scope

در این پارامتر مشخص می‌شود که: "دایره‌ی تاثیر اکسپلویت آسیب‌پذیری در سیستم به چه میزان است؟" و "آیا اکسپلویت آسیب‌پذیری بر روی بخش‌هایی از سیستم دیگر نیز تاثیر می‌گذارد؟ یا خیر؟". گزینه‌های این پارامتر به شرح زیر هستند:

• Unchanged: اگر اکسپلویت آسیب‌پذیری از سیستم آسیب‌پذیر هدف برروی سیستم یا scope دیگر تاثیر نداشته باشد و مربوط نباشد، باید " Unchanged" را انتخاب کنیم. به عبارت دیگر، سیستم آسیب‌پذیر هدف با سیستمی که تحت‌تاثیر اکسپلویت قرار می‌گیرد، یکسان باشد.

• Changed: اگر اکسپلویت آسیب‌پذیری از سیستم آسیب‌پذیر هدف برروی سیستم یا scope دیگر نیز تاثیر داشته باشد یا مربوط باشد، باید " Changed" را انتخاب کنیم. به عبارت دیگر، سیستم آسیب‌پذیر هدف با سیستمی که تحت‌تاثیر اکسپلویت قرار می‌گیرد، متفاوت باشد.

به عنوان مثال؛ در حمله‌ی MySQL Stored SQL Injection، بخش آسیب‌پذیر، پایگاه‌داده‌ي MySQL Server است که مهاجم برای انجام حمله وارد آن می‌شود. اما در حقیقت پایگاه‌داده‌ی دیگری که داده‌ها از این MySQL Server به آن رونویسی یا Replicate می‌شوند (که با بخشی که کاربر در آن حمله را اجرا می‌کند، متفاوت است)، نیز تحت‌تاثیر قرار می‌گیرند.پس گزینه‌ی مناسب در این پارامتر برای این حمله، "Changed" است.

Confidentiality

این پارامتر مشخص می‌کند که: "چه میزان از محرمانگی داده‌ها پس از اکسپلویت آسیب‌پذیری در سیستم نقض می‌شود؟" به عبارت دیگر "چه میزان از اطلاعات حساس و محرمانه پس از حمله نشت پیدا خواهد کرد؟" . گزینه‌های این پارامتر به شرح زیر هستند:

• بالا «H»: در صورتی که دسترسی به کل داده‌ها حاصل شود و هیچ محرمانگی‌ای باقی نمانده باشد. البته، اگر دسترسی صرفا به بخش‌های محرمانه سیستم هم صورت بگیرد، هم شامل این گزینه می‌شود.

• پایین «L»: اگر تنها بخشی از داده‌ها در پی حمله نشت پیدا کنند.

• هیچ‌کدام «N»: در صورتی که حمله به محرمانگی داده‌های سیستم خدشه‌ای وارد نکند.

به عنوان مثال؛ اگرچه در حمله‌ی MySQL Stored SQL Injection، کد SQL روی پایگاه داده از راه دور اجرا می شود و مهاجم به اطلاعاتی دسترسی پیدا می‌کند که محرمانه‌اند، اما ممکن است این اطلاعات را به عنوان بخشی از دستور SQL دریافت کند. SQL مخرب به دستورات SQL که بخشی از عملکرد Replication هستند تزریق می‌شود و مانع از اجرای دستورات SQL دلخواه توسط مهاجم می‌شود. پس گزینه‌ی مناسب در این پارامتر برای این حمله، "پایین «L»" است.

Integrity

این پارامتر مشخص می‌کند که: " پس از حمله یا اکسپلویت آسیب‌پذیری، چه میزان از داده‌های سیستم در معرض دسترسی برای تغییر در آن‌ها و خدشه‌دارشدن یک‌پارچگی آن‌ها قرار خواهند گرفت؟". لازم به ذکر است که یک‌پارچگی داده‌ها به معنی عدم تغییر غیرمجاز آن‌هاست. گزینه‌های این پارامتر به شرح زیر هستند:

• بالا «H»: در صورتی که یکپارچگی داده‌ها در سیستم به طور کلی خدشه‌دار شود. به عبارت دیگر، امکان تغییر در هر فایل و اطلاعات در سیستم، فراهم شود.

• پایین «L»: اگر تنها، بخش محدودی از داده‌ها در سیستم قابل تغییر باشند.

• هیچ‌کدام «N»: در صورتی که حمله، به یکپارچگی داده‌های سیستم خدشه‌ای وارد نکند. به عبارت دیگر، داده‌ها پس از حمله در سیستم قابل‌تغییر نباشند.

به عنوان مثال؛ اگرچه در حمله‌ی MySQL Stored SQL Injection، کد SQL روی پایگاه داده از راه دور اجرا می‌شود و مهاجم می‌تواند اطلاعاتی را تغییر دهد که محرمانه‌اند، اما ممکن است این اطلاعات را به عنوان بخشی از دستور SQL دریافت کند. SQL مخرب به دستورات SQL که بخشی از عملکرد Replication هستند، تزریق می‌شود و مانع از اجرای دستورات SQL دلخواه توسط مهاجم می‌شود. پس گزینه‌ی مناسب در این پارامتر برای این حمله، "پایین «L»" است.

Availability

در این پارامتر مشخص می‌شود که: " فعالیت سیستم پس از حمله به چه صورت خواهد شد؟" ، " آیا حمله سبب توقف کامل فعالیت سیستم می‌شود؟ یا فقط چند بخش غیرفعال خواهند شد؟ یا هیچ تاثیری بر روند فعالیت سیستم نخواهد داشت؟". گزینه‌های این پارامتر به شرح زیر هستند:

• بالا «H»: در صورتی که حمله سبب توقف همه‌ی بخش‌های سیستم شود و سیستم غیرقابل‌استفاده شود.

• پایین «L»: اگر حمله سبب کاهش عملکرد یا توقف چند عملکرد در سیستم شود.

• هیچ‌کدام «N»: در صورتی که حمله هیچ تاثیری بر دسترسی‌پذیری یا خدمات‌دهی سیستم نداشته باشد.

به عنوان مثال؛ اگرچه در حمله‌ی MySQL Stored SQL Injection، کد SQL تزریق‌شده با دسترسی سطح بالایی اجرا می‌شود، اما طبیعت این حمله مانع از اجرای دستورات SQL دلخواه می‌شود، بر روی دسترسی به پایگاه‌داده‌ها تاثیری نمی‌گذارد و در دسترس خواهند ماند. پس گزینه‌ی مناسب در این پارامتر برای این حمله، "هیچ‌کدام «N»" است.

اعلام نتیجه‌ی ارزیابی سطح خطر آسیب‌پذیری

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

اگر این عدد بین 0 و 3.9 باشد، آسیب‌پذیری سطح پایین یا Low

اگر بین 4.0 و 6.9 باشد، آسیب‌پذیری سطح میانه یا Medium

اگر بین 7.0 و 8.9 باشد، آسیب‌پذیری سطح بالا یا High

اگر بین 9.0 تا 10 باشد، آسیب‌پذیری سطح بحرانی یا Critical

محسوب می‌شود.

به همراه این عدد Vector String این آسیب‌پذیری نیز اعلام می‌شود. این رشته‌ی متنی از روی پارامترها ایجاد می‌شود و هر کدام از پارامترها به وسیله‌ی / از هم‌دیگر و هر پارامتر از مقدار نظیرش نیز به وسیله‌ی : جدا می‌شوند.

به عنوان مثال؛ حمله‌ی MySQL Stored SQL Injection، دارای امتیاز 6.4 است و از نظر میزان خطر، در دسته‌بندی «میانه» قرار می‌گیرد. Vector String آن نیز به صورت زیر است:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

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

در بلاگ‌پست‌های بعدی، به بخش‌های دیگرِ امتیازدهی CVSS در ماشین‌حساب راورو خواهیم پرداخت.

چنان‌چه سوالی در مورد چگونگی محاسبه‌ی «امتیاز پایه» ، در ماشین‌حساب CVSS راورو داشتید، در کامنت‌ها با ما درمیان بگذارید.