چگونه یک گزارش آسیبپذیری بنویسیم؟
گزارش یک آسیبپذیری، سند قابل ارائه‌ی شکارچی از آسیبپذیری کشف‌کرده‌ی خود به میدان است. به همین خاطر، محتوای یک گزارش آسیبپذیری میتواند به ارزش گزارش کمک قابل‌توجهی کند. در این مطلب به بخش‌های مختلف یک گزارش آسیبپذیری و بایدها و نبایدهایی که رعایت آنها در نگارش یک گزارش لازم است، می‌پردازیم. اگر شما نیز مشتاقید که شکارچی شوید و یا می‌خواهید به عنوان شکارچی گزارش‌های بسیار بهتر از گذشته بنویسید، تلاش کرده‌ایم در این مطلب همه چالش‌های احتمالی که در روند نوشتن گزارش آسیبپذیری با آنها برخورد خواهید کرد و تمام نقاط مهم و ضروری یک گزارش آسیبپذیری را برای شما برشمرده و درباره نکات و موارد لازمی که در صورت رعایت آنها، اعتبار گزارش شما را ارتقا می‌بخشد با شما در میان بگذاریم.
نکته‌ای که بسیار مهم و قابل‌توجه است، مطالعه‌ی سیاست یا قوانین هر برنامه‌ی باگ‌بانتی قبل از شروع به کشف آسیبپذیریها در میدان است. در سیاست برنامه‌ی باگ‌بانتی که بین پلتفرم باگ‌بانتی و میدان تعیین میشود، بخش‌های شرکت‌کننده و ابزارهای قابل‌استفاده در برنامه مشخص شده‌اند و حاوی مطالب دیگری از جمله محدودیت‌ها و الزاماتی است که رعایت هر چه بهتر آنها میتواند به فرآیند بررسی گزارش شکار شکارچی کمک کند.
مواردی که باید در هنگام گزارش‌نویسی رعایت و در گزارش گنجانده شوند به شرح زیر است:
۱. توضیح کامل در مورد آسیبپذیری
۲. مراحل دقیق بازسازی آسیبپذیری
۳. میزان خطر آسیبپذیری
۴. سناریوی حمله و سوءاستفاده
۵. اثبات آسیبپذیری و نحوه‌ی اکسپلویت
۶. ابزارها، payloadها و کدهای استفاده شده در عملیات کشف آسیبپذیری و بهره جویی از آن
۷. بخش‌های اختیاری و تکمیلی
قبل از هر کاری چه باید کرد؟
همان‌طور که گفته شد، لازم است که شما قوانین هر برنامه‌ی باگ‌بانتی را قبل از شروع فعالیت کشف آسیبپذیری هر میدان مطالعه کنید و از بخش‌های مدنظر برنامه برای ارزیابی امنیت میدان آگاه شوید. اگر یک آسیبپذیری را خارج از بخش‌هایی که در قوانین برنامه باگ‌بانتی میدان موردنظر آمده است کشف کنید، متاسفانه به گزارش شما ترتیب اثری داده نخواهد شد. بنابراین، ابتدا سیاست برنامه‌ی باگ‌بانتی را مطالعه کنید، سپس اقدام به کشف آسیبپذیری در بخش‌های مشخص‌شده بپردازید و گزارش آسیبپذیری را با توجه به اصولی که به آن در ادامه می‌پردازیم نوشته و درنهایت منتظر تایید گزارش خود باشید. لازم به ذکر است که، وقتی شما یک آسیبپذیری را کشف می‌کنید، توقع تیم داوری از محتوای گزارش شما این است که آسیبپذیری کشف‌شده را توصیف کنید و با سند و مدرک اثبات کنید که این آسیبپذیری چه اثری بر سامانه می‌گذارد و خسارتی که میتواند از آن ناحیه به سامانه وارد شود چگونه خواهد بود. با این‌که ممکن است یک گزارش آسیبپذیری ضعیف نیز به تایید تیم داوری برسد، اما گزارش آسیبپذیری خوب گزارشی‌ست که احتمال پذیرش خود به‌عنوان گزارشی معتبر را افزایش دهد و از زمان لازم برای پاسخ‌گویی تیم امنیت سازمان بکاهد. رعایت ادب و کوتاه‌نویسی و به‌کارگیری دقت بالا در رعایت اصول نگارش آسیبپذیری، ارزش گزارش آسیبپذیری شما را ارتقا می‌بخشد.
در گاهی موارد، شکارچی یک آسیبپذیری امنیتی را مشاهده و کشف می‌کند که جزو رفتار عادی و از موارد کاربرد سامانه است. قاعدتا این آسیبپذیری امنیتی را نمی‌توان به عنوان یک آسیبپذیری معتبر برای این برنامه‌ی باگ‌بانتی دانست، در حالی که همان آسیبپذیری میتواند در یک برنامه‌ی باگ‌بانتی دیگر امتیاز زیادی داشته باشد. به عبارت بهتر، این موارد کاربرد به شکلی انجام می‌شوند که کنترل شده و سبب سوءاستفاده از کسی نمی‌شود و یا به سامانه خللی وارد نمی‌کند. حتی ممکن است آسیب‌پذیری‌ای پیدا کنید که در محدوده‌ی مشخص‌شده‌ی برنامه باگ‌بانتی نباشد، اما وابستگی‌ای بین بخش‌های مجاز برنامه و محل کشف آسیبپذیری برقرار باشد.
پیش از نوشتن گزارش آسیبپذیری
یکی از اجزای مهم گزارش آسیبپذیری شما که در نگاه نخست دیده میشود، عنوان گزارش آسیبپذیری شماست. عنوان مناسب و دقیق، نوید یک گزارش آسیبپذیری خوب و اصولی را می‌دهد. برای انتخاب یک عنوان برای گزارش آسیبپذیری لازم است مواردی را در نظر بگیرید. به طور کلی آسیب‌پذیری‌هایی که شما گزارش می‌کنید دو حالت دارند:
۱. آسیب‌پذیری‌هایی که به طور مستقیم در چهارچوب قوانین برنامه‌ی باگ‌بانتی قرار می‌گیرند.
۲. آسیب‌پذیری‌هایی که به طور غیرمستقیم در چهارچوب قوانین برنامه‌ی باگ‌بانتی قرار می‌گیرند.
به منظور انتخاب عنوان برای آسیب‌پذیری‌هایی که به طور مستقیم و غیرمستقیم در چارچوب قوانین برنامه باگ‌بانتی قرار می‌گیرند، دو فرمول زیر میتواند راهنمای خوبی برای انتخاب عنوان باشند:
اگر آسیبپذیری کشف‌شده به طور مستقیم در چهارچوب قوانین برنامه‌ی باگ‌بانتی بود، عنوان باید به ترتیب ترکیبی از نام یا نوع آسیبپذیری، نام عملکرد یا نقطه آسیب‌پذیر و میزان اهمیت آسیبپذیری باشد.
نام یا نوع آسیبپذیری + نام عملکرد یا نقطه آسیب‌پذیر + میزان اهمیت یا درجه آسیبپذیری
به عنوان نمونه: آسیبپذیری XSS در بخش تماس با ما با درجه بحرانی اگر آسیبپذیری کشف‌شده به طور غیرمستقیم در چهارچوب قوانین برنامه‌ی باگ‌بانتی بود، لازم است که نام هر دو آسیبپذیری خارج از قوانین و آسیبپذیری در چارچوب قوانین که به صورت زنجیره‌ای در چارچوب قوانین برنامه باگ‌بانتی قرار می‌گیرند، در ابتدای عنوان، گنجانده شود.
نوشتن گزارش آسیبپذیری
۱- توضیح کامل در مورد آسیبپذیری
بهتر است گزارش آسیبپذیری را با توضیحات کاملی در مورد آسیبپذیری کشف شده شروع کنید و لینک مرتبط به آسیبپذیری را از یک مرجع معتبر به گزارش آسیبپذیری اضافه کنید. به عنوان یک نکته مهم، ارائه لینک از مراجع معتبری مانند OWASP به درک بهتر مخاطب از آسیبپذیری کشف شده کمک خواهد کرد. به عنوان نمونه، اگر آسیب‌پذیری‌ای که کشف کرده‌اید، نوعی از یک آسیبپذیری SQL Injection است، می‌توانید در گزارش آسیبپذیری خود به یک مطلب معتبر درباره آسیبپذیری مدنظر خود ارجاع دهید.
اکثر آسیبپذیریها، مربوط به بخش کسب‌وکار یک سازمان یا شرکت هستند. زمانی که با چنین آسیب‌پذیری‌هایی مواجه هستید، ابتدا رفتار عادی سامانه و یا همان بخش آسیب‌پذیر را شرح بدهید و سپس بیان کنید که به واسطه‌ی این آسیبپذیری، چه خطراتی متوجه‌ی سامانه و یا سایر کاربران عضو در آن سامانه است.
۲- مراحل دقیق بازسازی آسیبپذیری
آسیبپذیری باید برای تیم داوری کاملا قابل‌فهم باشد تا بتوانند آن را بازسازی کنند. به همین منظور، باید مراحل دقیق بازسازی آسیبپذیری کشف شده به صورت گام به گام توضیح داده شود.
به عنوان نمونه:
۱. وارد صفحه لاگین شوید.
۲. بر روی لینک فراموشی رمز عبور کلیک کنید.
۳. ایمیل قربانی را برای دریافت ایمیل بازنشانی رمز عبور وارد کنید.
۴. منتظر بمانید شخص روی لینک کلیک کند.
۵. با کلیک کاربر، مقدار توکن قربانی استخراج میشود.
در بین مراحل بالا، ترجیح بر توضیح متنی مراحل است اما اگر تصویری از درخواست و یا بسته HTTP نیز گذاشته شود مفید خواهد بود.
همچنین، دقت کنید که برخی آسیبپذیریها فقط در یک محیط خاص قابل‌کشف هستند. برای این نوع آسیبپذیریها لازم است محیطی که آسیبپذیری در آن کشف شده را نیز ذکر کنید.
۳- میزان خطر آسیبپذیری
میزان خطر آسیبپذیری را به‌طور دقیق مشخص کنید؛ به عبارت بهتر حساسیت آسیبپذیری را اعلام کنید، امتیاز CVSS آن را دقیق محاسبه کنید و در این بخش از گزارش آسیبپذیری بگنجانید. شما می‌توانید برای مطالعه درباره‌ی ارزش‌گذاری آسیبپذیریها مطلب زیر را بخوانید: «چگونه آسیبپذیری در راورو ارزش‌گذاری میشود؟»
۴- سناریوی حمله و سوء استفاده
در این قسمت حتما باید سناریوی حمله را مشخص کنید که براساس این آسیبپذیری کشف شده، مهاجم چه کاری میتواند انجام دهد و کاربران یا سرور در معرض چه خطراتی قرار می‌گیرند و یا به عبارت بهتر، حالا چه کاری قابل‌انجام است که در حالت طبیعی امکان‌پذیر نبود. شکارچی باید واقع‌بین باشد، فرآیند و سناریوی حمله انجام‌شده را بنویسد و از نظریه‌پردازی و پرداختن به احتمالات پرهیز کند. در نهایت، اگر چه برای حمله‌های مشخص که ممکن است به هدف‌های میدان آسیب برساند، این سناریو کامل نمی‌شود اما باز هم باید برای تیم امنیت و تیم داوری قابل‌فهم و قابل‌اثبات باشد. توجه کنید که ابزارهای خودکار نمی‌توانند سناریوهای حمله را توصیف کنند و فقط توصیفات ضمیمه‌شده از این آسیبپذیریها را ارائه می‌دهند.
۵- اثبات آسیبپذیری و نحوه‌ی اکسپلویت
یکی از مواردی که باید کاملا واضح و دقیق بیان شود، نحوه‌ی اکسپلویت آسیبپذیری است. به عنوان نمونه، در آسیبپذیری XSS، قرارگیری کد اکسپلویت به همراه سناریوی حمله الزامی است. دقت کنید که برای گزارش آسیبپذیری XSS فقط alert(1) گزارش نکنید. نکته مهم و قابل توجه باید به آن توجه داشته باشید این است که گزارش آسیبپذیری بدون سناریوی حمله، فاقد ارزش است. بنابراین، سناریوی حمله یکی از ضروری‌‌ترین بخش‌های یک گزارش آسیبپذیری است. همچنین، گزارش آسیبپذیری بدون پرداختن به اکسپلویت و نحوه‌ی سوء استفاده از آسیبپذیری و همچنین عدم بیان نحوه‌ی نفوذ، فاقد ارزش است. بنابراین، بیان نحوه‌ی بهره‌جویی از آسیبپذیری نیز یکی از ضروری‌‌ترین بخش‌های یک گزارش آسیبپذیری است.
۶- استفاده از ابزارها و کدها برای اکسپلویت آسیبپذیریها
کلیه‌ی ابزارها و کدهای استفاده شده باید به گزارش آسیبپذیری ضمیمه شوند. دقت کنید که در این قسمت ذکر ابزارهای هک فاقد ارزش است. شما باید کد و ابزاری که به صورت اختصاصی برای آسیبپذیری کشف شده نوشته‌اید را ذکر کنید.
۷- بخش‌های اختیاری و تکمیلی
بارگذاری عکس و فیلم از فرآیند حمله میتواند به روند بررسی کمک کند.
فیلم ضمیمه شده نیز باید:
• تا حد امکان کوتاه باشد.
• کیفیت مناسبی داشته باشد.
• حجم بالایی نداشته باشد.
• شامل موارد متفرقه نباشد و به عبارت دیگر فقط متمرکز بر یک موضوع باشد.
فراموش نکنید که عکس و فیلم باید فقط در پنل راورو برای ثبت گزارش آسیبپذیری بارگذاری شود. در صورت بارگذاری در فضاهای اشتراکی، این کار طبق قوانین راورو به منزله‌ی انتشار عمومی اطلاعات آسیبپذیری تلقی میشود که سبب تعلیق فرآیند دریافت پاداش شما شده و همچنین شامل پیگرد حقوقی خواهد شد.
پیشنهاد می‌کنیم که راه‌حل رفع آسیبپذیری را نیز در گزارش آسیبپذیری بگنجانید. همچنین لینک‌هایی که در مورد آسیبپذیری کشف شده و حمله مرتبط به آن وجود دارد را می‌توانید در انتهای گزارش آسیبپذیری ذکر کنید. در نهایت با گزارشی که نوشتید، خودتان حمله را تکرار کنید تا کم و کاستی‌های آن را پیدا کنید تا نسخه‌ی نهایی گزارش آسیبپذیری را جامع و بهینه ارسال کنید.
نمونه‌هایی از گزارش‌های مطلوب و مورد‌انتظار
لینک‌های زیر مربوط به گزارش‌هایی است که نویسندگان آنها با دقت اصول لازمی که گفته شد را رعایت کرده‌اند و در آنها نکاتی وجود دارند که به طور مشهودی کیفیت گزارش آسیبپذیری را تحت‌الشعاع قرار می‌دهد و از درجه‌ی کیفیت بالایی برخوردارند:
https://hackerone.com/reports/56828
https://hackerone.com/reports/32825
https://hackerone.com/reports/73567
نمونه‌هایی از گزارش‌های نامطلوب
سه گزارش آسیبپذیری زیر از مواردی هستند که از نکات و اصول لازم برای نگارش یک گزارش آسیبپذیری برخوردار نیستند و طبیعتا ارزش پایین‌تری دارند. با بررسی اصولی که در آنها رعایت نشده، می‌توانید تا حد قابل‌توجهی ارزش گزارش‌های خودتان را بالا ببرید. شایان ذکر است که نمونه‌های زیر برگرفته از مطلب «نکاتی که هنگام گزارش آسیبپذیری باید رعایت کنیم» سایت مموری‌‌لیکز می‌باشند.
بررسی گزارش آسیبپذیری ۱
یک آسیبپذیری XSS در دامنه site.com کشف شده است. لینک نقطه‌ی آسیب‌پذیر:
مشکلات گزارش آسیبپذیری ۱ و حداقل توضیح مناسبی که باید داده می‌شد بدین شرح است:
هیچ سناریوی حمله و کد اکسپلویتی ندارد:
با استفاده از این آسیبپذیری، مهاجم میتواند اطلاعات کاربری را سرقت کرده و یا تغییر دهد. به دلیل استفاده سامانه از تگhttpOnly، امکان سرقت کوکی وجود ندارد، اما امکان تغییر اطلاعات با استفاده از exploit1.js را داراست. همچنین مهاجم میتواند با استفاده از exploit2.js اطلاعات محرمانه کاربر اعم از لیست ایکس را سرقت کند. مراحل اکسپلویت: مهاجم URL را در یک iframe گذاشته و کد را در سایت خود قرار می‌دهد، سپس آدرس سایت خود را به قربانی داده و با اولین کلیک، در صورت لاگین بودن قربانی، اطلاعات ایشان استخراج میشود. مراحل بازسازی آسیبپذیری بیان نشده است که به عنوان نمونه باید به صورت زیر مراحل ذکر شود: ابتدا وارد حساب کاربری شوید، سپس یک سایت جدید در قسمت parked domains بسازید، سپس بر روی اتصال به اپلیکیشن گوگل کلیک کنید، درخواست را نگه دارید، قسمت google_aps_uri را به پیلود XSS تغییر دهید. به محیطی که در آن آسیبپذیری کشف شده، مانند زیر اشاره نشده است: این آسیبپذیری بر روی تمامی نسخه‌های فایرفاکس قابل سوءاستفاده است.
بررسی گزارش آسیبپذیری ۲
با بررسی‌های صورت گرفته مشخص شد هیچ محدودیتی روی کد ورود فعال‌ساز اپلیکیشن وجود ندارد. مهاجم میتواند شماره‌ی قربانی را وارد کرده و کد ۶ رقمی فعال‌ساز را بروت‌فورس کند (یک تصویر از بروت‌فورس که حاوی حدودا ۳۰ سطر است گذاشته شده است.) مشکلات گزارش آسیبپذیری ۲ و حداقل توضیح مناسبی که باید داده می‌شد بدین شرح است: دارای کد اکسپلویتی نیست: علی رغم وجود سناریوی حمله، کد اکسپلویتی وجود ندارد. کد اکسپلویت میتواند مراحل تنظیم Intruder در نرم‌افزار Burp Suite و یا یک کد به زبان پایتون باشد. آسیبپذیری به‌صورت کامل اکسپلویت نشده است: آسیبپذیری به صورت کامل اکسپلویت نشده و فقط بر اساس یک سری درخواست، نتیجه‌گیری شده است (ممکن است نادرست و یا درست باشد). در نهایت، سوالاتی که مطرح میشود به این شرح است: آیا این کد ۶ رقمی دارای انقضا است؟ اگر جواب مثبت است، کد پس از چند دقیقه منقضی خواهد شد؟ اگر در T دقیقه منقضی میشود، آیا امکان بروت‌فورس و کشف در آن بازه زمانی وجود دارد؟ اگر به عنوان شکارچی واقعا معتقدید که محدودیتی اعمال نشده است، این عدم محدودیت تا چند درخواست در دقیقه است؟ ممکن است سامانه پس از ۱۰۰ درخواست در دقیقه، حتی در حالتی که کد درست وارد شود نیز خطا بدهد. به همین خاطر، باید شکارچی خیلی سخت‌گیرانه این آسیبپذیری را اکسپلویت کند و به تمامی جوانب این موضوع در گزارش آسیبپذیری بپردازد.
بررسی گزارش آسیبپذیری ۳
با استفاده از پویش امنیتی کشف سرویس، مشخص شد که نسخه نرم‌افزار ۳.۲ می‌باشد که نسبت به Remote Command Execution آسیب‌پذیر است. مشکلات گزارش آسیبپذیری ۳ و حداقل توضیح مناسبی که باید داده می‌شد بدین شرح است: کد اکسپلویت ندارد و آسیبپذیری به‌صورت کامل اکسپلویت نشده است: همان‌طور که در بسیاری از برنامه‌های باگ‌بانتی تاکید می‌کنند، صرفا انجام ارزیابی امنیتی بدون اکسپلویت هیچ ارزشی ندارد. اگر سرویس یا نرم‌افزاری آسیب‌پذیر است، تلاش کنید آن را اکسپلویت کنید.
هیچ چیز را فرضی در نظر نگیرید فرض نکنید که تیم امنیتی می‌توانند همه مواردی که شما در گزارشتان ذکر کرده‌اید را متوجه شوند. همیشه به یاد داشته باشید که شاید شما به قسمتی که مورد هدف شما بوده یک هفته تمام متمرکز بوده‌اید اما اطلاعات گزارش آسیبپذیری شما برای تیم امنیتی که گزارش آسیبپذیری شما را بررسی می‌کنند، جدید و تازه است. بنابراین نیاز است که آسیب‌پذیری‌ای که کشف کرده‌اید را شیوا و حرفه‌ای توضیح دهید. هر آن چیزی که فکر می‌کنید برای جزئیات بیشتر نیاز است به گزارشتان اضافه کنید. شاید بعضی بخش‌ها از نظر شما حاشیه به نظر برسند اما احتمالا بتوانند به درک سریع‌تر و بهتر گزارش آسیبپذیری شما کمک کنند. دقت داشته باشید که این موضوع بدین معنی نیست که در گزارش آسیبپذیری اضافه‌گویی کنید. گزارش‌های بلند هم باعث کاهش کیفیت گزارش آسیبپذیری شما می‌شوند و حوصله‌بر خواهند بود اما در کنار این موضوع پرداختن به جزییات مهم یکی از موارد الزامی است که باید در نگارش به آن توجه کنید.
اعضای تیم داوری هم انسان هستند
تا حد امکان ساده بنویسید. از کوتاه‌نویسی و ضرب‌المثل و ... استفاده نکنید چون فقط متن خود را سخت‌تر می‌کنید و حوصله‌ی خواننده را از بین می‌برد. به یاد داشته باشید که همه‌ی ما مرتکب اشتباه می‌شویم. اگر در هر کدام از مراحل فرآیند بررسی گزارش آسیبپذیری شما، اشتباهی رخ داده و یا سهل‌انگاری‌ای صورت گرفته، با مسئول مربوطه ارتباط بگیرید و مشکل خود را با حوصله مطرح کنید. ناهماهنگی‌ها اجتناب‌ناپذیرند اما شما به‌عنوان شکارچی، قدرت این را دارید که احتمال این ناهماهنگی را با نگارش یک گزارش آسیبپذیری دقیق و شفاف به حداقل برسانید. با این کار شما در کنار نمایش تخصص خود در کشف آسیبپذیری، مهارت‌های ارتباطی خود را نیز در کاهش اتلاف وقت دیگران و ارتقای شایستگی خود به عنوان شکارچی به نمایش می‌گذارید.
مواردی که در این مطلب به آن پرداختیم شامل نکاتی بود که به‌طور مکرر در گزارش آسیبپذیری شکارچیان دیده میشود. امیدواریم توانسته باشیم که با در میان گذاشتن این نکات با شما، از زمان فرآیند بررسی گزارش‌ها و تعداد گزارش‌های اشتباه بکاهیم.