چرا گزارش‌های آسیب پذیری رد می‌شوند؟ یا به بانتی کمی منجر می‌شوند؟
پس از جست‌وجوها و تلاش فراوان، باگی را می‌یابیم و بلافاصله گزارش آن را به برنامه‌ی باگ‌بانتی ارسال می‌کنیم تا مبادا فرد دیگری هم آن را یافته باشد و گزارشش را زودتر از ما ارسال کند! ساعت‌ها و روزها منتظر می‌مانیم تا پیام خوش‌خبر بانتی از راه برسد. بانتی از راه می‌رسد، اما به آن خوش‌خبری‌ای که گمان می‌کردیم نیست! اول فکر می‌کنیم شاید یک صفرش جا افتاده باشد! اما نه، گویی عددی که به عنوان بانتی در صفحه‌ی مقابلمان نقش بسته است، واقعیت دارد. "چرا؟"ی بزرگی در ذهنمان نقش می‌بندد؛ چرا این مبلغ با مبلغ موردانتظار ما تفاوت دارد؟ مگر باگی که گزارشش را ارسال کردیم، باگ مهمی نبود؟ مگر در دسته‌ی باگ‌های مهم جای نمی‌گرفت؟ مگر...؟ در گاهی موارد نیز گزارشمان برخلاف انتظارمان، رد می‌شود! چرا؟ نمی‌دانیم و می‌پنداریم که احتمالا قربانی داوری نادرست شده‌ایم!
تابه‌حال بارها با چنین سوال‌هایی از جانب شما، شکارچیان آسیب‌پذیری، روبه‌رو شده‌ایم. به همین دلیل در این بلاگ‌پست قرار است به پاسخ به این "چرا"ها بپردازیم و موارد پرتکراری که از دلایل آن هستند را بیان کنیم. ؛)
آن‌چه در این بلاگ‌پست خواهید خواند:
• ممکن است آسیب پذیری گزارش‌شده مطابق قوانین هدف نباشد...
• ممکن است گزارش آسیب‌پذیری، ناقص باشد... ( سناریو، اکسپلویت و سندها )
• ممکن است آسیب پذیری کم‌اهمیت باشد... (لیستی از برخی آسیب‌پذیری‌های کم‌اهمیت)
• ممکن است گزارش آسیب پذیری، تکراری باشد...
• اگر آسیب‌پذیری گزارشم تکراری ست، چرا رفع نشده است؟
• ممکن است آسیب پذیری، دیگر وجود نداشته باشد...
• سایر نکاتی که منجر به رد گزارش آسیب پذیری می‌شوند... ( استفاده از ابزار خودکار، تشریح شناسه CVE بدون PoC )
ممکن است آسیب‌پذیری گزارش‌شده مطابق قوانین هدف نباشد...
بخش قوانین به دلیل شفاف‌سازی شرایط بین شکارچی و میدان تدارک دیده شده است. هر میدان پیش از فعال‌سازی هدف خود، باتوجه به شرایط و موارد پراهمیت کسبوکار خود، اقدام به تعریف قوانین می‌کند. تا هر شکارچی بتواند قبل از صرف وقت و انرژی برروی کشف و شکار هر آسیب‌پذیری، به مطالعه‌ی قوانین هر میدان بپردازد و با آگاهی از آن‌ها و پذیرششان، دست به انتخاب و عمل بزند.
پیشنهاد خواندنی: درباره‌ی این‌که قوانین میدان چگونه باعث ردشدن گزارش‌ها می‌شوند، در بلاگ‌پست "چرا باید حتما قبل از شکار آسیب پذیری، قوانین هدف را بخوانیم؟" می‌توانید بیش‌تر بخوانید.
ممکن است گزارش آسیب‌پذیری، ناقص باشد...
یک گزارش آسیب پذیری استاندارد باید شامل سناریو، اکسپلویت و اسناد لازم، باشد.
کاظم فلاحی، از تیم داوری راورو می‌گوید: "در یک گزارش آسیب‌پذیری لازم است تا به اکسپلویت، سناریو و اسناد ارسالی توجه بیش‌تری شود. ما گاهی گزارش‌هایی دریافت می‌کنیم که تنها شامل یک لینک هستند! نه خبری از سناریو هست، نه خبری از اکسپلویت‌نویسی و نه عکس و فیلمی به‌عنوان اسناد ارائه‌شده! خب در چنین شرایطی، تیم داوری و کسبوکار برای فهم و قانع‌شدن، نیاز به اطلاعاتی دارند. لازم است تا شکارچیان، از مسیری که برای کشف آسیب‌پذیری پیموده‌اند، از چگونگی بهره‌جویی و ... نیز اطلاعاتی ارائه کنند."
سناریو:
در سناریو، لازم است که شکارچی، مسیری که برای کشف آسیب‌پذیری پیموده‌است را توضیح دهد. قانونی نانوشته درمورد گزارش آسیب پذیری استاندارد و سناریوی آن وجود دارد که می‌گوید:" یک گزارش آسیب‌پذیری باید تاحدی ساده و کامل نوشته‌شده‌باشد، که اگر فردی بدون دانش فنی و امنیتی هم آن را خواند، متوجه‌اش بشود." گزارش آسیب‌پذیری و سناریوی گزارش، هنگامی که به دست میدان می‌رسد، نقش فرد سخن‌گویی را دارد که از جانب شکارچی حاوی پیامی مهم است. موقعیتی را تصور کنید که فردی در یک جلسه ظاهر می‌شود؛ آن فرد باید به‌خوبی خود را پرزنت کند، خودش را اثبات کند، از مسیر و نحوه‌ی کارش بگوید و حضار را قانع کند که چه اثری بر کسب‌وکارشان دارد. گزارش آسیب پذیری یک شکارچی هم همان فرد است و وظیفه‌ی مشابهی به عهده دارد. قرار است به نمایندگی از شکارچی، برای کسبوکار از آسیب پذیری‌ای که کشف کرده است بگوید؛ از مسیر اثبات وجود آسیب‌پذیری بگوید و میدان را به‌خوبی متوجه خطری که آن آسیب پذیری برای سامانهی کسب‌وکارش و سرمایه‌های ارزشمندش دربردارد، بکند.
اکسپلویت:
رامین فرج‌پور، از تیم داوری راورو معتقد است:"وقتی دارید آسیب پذیری امنیتی گزارش می‌دهید، باید مدام از خود بپرسید: خب، من این مشکل را پیدا کردم، خب بعدش چی؟ چه‌طور می‌توانم از آن استفاده کنم؟ به واسطه‌ی این آسیب‌پذیری، چه خطری میدان را تهدید می‌کند؟" هم‌چنین معتقد است:" در این مرحله شکارچی باید تمام تلاش خود را به کار گیرد تا چگونگی اکسپلویت، میزان اهمیت و تاثیرگذار بودن باگی که منجر به آسیب پذیری می شود، را نشان دهد."
اکسپلویت، زیرمجموعه‌ای از سناریوی گزارش آسیب‌پذیری ست. این‌که شکارچی بگوید که به‌وسیله‌ی آسیب پذیری‌ای که کشف کرده‌است، چه خطرات و تهدیداتی میدان موردنظر را تهدید می‌کنند، بخش مهمی از سناریوی گزارش آسیب پذیری محسوب می‌شود. اگر سناریو را کتابی شامل دو فصل تصور کنیم، در فصل اول شکارچی باید به توضیح این بپردازد که چگونه و از چه مسیری آسیب پذیری را کشف کرده است؟ و در فصل دوم، باید توضیح دهد که حالا با آسیب‌پذیری‌ای که کشف کرده‌است، چه می‌تواند بکند؟ این آسیب پذیری چه خطراتی را در بر دارد؟ ممکن است منجر به چه اتفاق‌هایی برای میدان موردنظر شود؟
مستندها:
عکس و فیلمی که در ضمیمه‌ی گزارش خود اضافه می‌کنید، در اثبات وجود آسیب پذیری و قانع‌کردن میدان، بسیار موثر هستند. مستندات همراه گزارش شما، سنگی ست که به محکم‌کاری گزارش شما، کمک شایانی می‌کند. در مواردی که تست و بررسی آسیب پذیری توسط تیم داوری، ممکن نیست، مستندات اهمیت بیش‌تری پیدا می‌کنند. چراکه در چنین موقعیت‌هایی، ویدئو و عکس تنها شواهدی هستند که می‌توانند گفته‌ی شما را ثابت کنند.
ممکن است آسیب پذیری کم‌اهمیت باشد...
چه آسیب پذیری هایی معمولا کم‌اهمیت به شمار می‌روند؟
پاسخ این سوال بسیار ساده است؛ آسیب پذیری هایی که تاثیر به‌خصوصی روی کاربر و کسبوکار نداشته باشند، برای آن میدان کم اهمیت به شمار می‌روند. برخی از این آسیب پذیری‌ها نیز، در رده‌بندی میزان اهمیت و حساسیت آسیب پذیری ها _ که شامل ۵ رده‌ی اطلاع‌رسانی (Info) ، کم (Low) ، متوسط ( Medium) ، بالا (High) و حیاتی (Critical) می‌شود_ در دو رده‌ی اطلاع‌رسانی و کم قرار می‌گیرند.
لیستی از برخی آسیب‌پذیری‌های کم‌اهمیت:
• آسیب پذیری Information Disclousre اگر قابل بهره‌برداری نباشد، وابسته به نظر میدان، یا رد می‌شود و یا پاداش کمی در بر دارد.
• آسیب پذیری Self XSS در بیش‌تر مواقع رد می‌شود و اگر نشود پاداش کمی در بر دارد.
• آسیب پذیری Session Fixation هم تاثیری روی دیگر کاربران ندارد و معمولا رد می شود.
• آسیب پذیری SPF- email spoofing توسط بعضی از میدان‌ها تایید و توسط بعضی هم رد می‌شود.
• آسیب پذیری Ratelimit را اکثر برنامه‌نویس‌ها و میدان‌ها به عنوان یک موضوع زیر ساختی که مرتبط به طراحی سامانهی کسبوکار است، به شمار می‌آورند. اگر Ratelimit در یک نقطه از سایت، به دلیل محدودیت دور خورده باشد و شما در گزارشی به اثبات آن پرداخته باشید، کافی ست. اما اگر در چند گزارش مجزا به آسیب پذیری Ratelimit در نقاط مختلف سایت پرداخته‌اید، گزارش‌هایتان تکراری محسوب می‌شوند.
• آسیب پذیری پیداکردن IPهای پشت CDN هم برای بیش‌تر میدان‌ها اهمیت چندانی ندارد. مگر‌این‌که در قوانین اهداف، ذکر شده باشد که جزو موارد موردتایید محسوب می‌شود.
• اگرآسیب پذیری CORS misconfiguration که در آن حالت‌های زیادی سمت سرور تاثیر گذارند، اکسپلویت موفقیت‌آمیزی نداشته باشد، قابل‌قبول نیست. مثل؛ داشتن jwt token در هدر که سمت سرور اگه وجود نداشته باشد رد می‌شود. پس این مورد هم بدون داشتن PoC موردتایید نیست.
• آسیب پذیری Xmlrpc.php هم موردقبول واقع نمی‌شود، مگر‌این‌که منجر به SSRF شود.
• آسیب پذیری Crossdomain.xml
ممکن است آسیب پذیری گزارش‌شده، تکراری باشد...
زمانی که Endpoint آسیب‌پذیری کشف‌شده‌ی شما با Endpoint گزارشی دیگر یکسان باشد. در این صورت عملا دو گزارش به یک نقطه آسیب‌پذیر یکسان رسیده‌اند و گزارش دوم تکراری محسوب می‌شود. اگر گزارشی به آسیب‌پذیری مشترکی با گزارش دیگری اشاره کند که آسیب‌پذیری موردنظر در چندین نقطه از سامانه وجود داشته باشد و اکسپلویت آن تاثیر کلی بر روند عادی سامانه بگذارد، نیز تکراری محسوب می‌شود.
اگر آسیب‌پذیری گزارشم تکراری ست، چرا رفع نشده است؟
برخی میدان‌ها در رفع آسیب پذیری های گزارش‌شده، با تاخیر عمل می‌کنند. این تاخیر سبب می‌شود که شکارچی‌های دیگری نیز در بررسی و جست‌وجوی خود به همان آسیب پذیری بربخورند و وقت خود را صرف ارائه‌ی گزارش آن کنند. راورو تلاش می‌کند براساس مسئولیت‌‌پذیری، پیگیر رفع آسیب پذیری‌های گزارش‌شده باشد. درصورت تمایل میدان نیز، راورو به ارائه‌ی راهکار و راه‌حل در جهت رفع آسیب‌پذیری می‌پردازد. اما محدوده‌ی اختیارات و اعمال پلتفرم، تا همین حد از پیگیری را ممکن می‌سازد.
برخی میدان‌ها قبل از پیوستن به پلتفرم باگ بانتی و فعال کردن اهداف خود نیز، از برخی آسیب پذیری های موجود در سامانهی خود آگاهند. در چنین مواردی، میدان‌ها، گزارش این آسیب پذیری ها را در پلتفرم ثبت می‌کنند تا گزارش‌های مشابه بعدی "تکراری" محسوب شوند و به شناسه‌ی گزارش اولیه، ارجاع داده شوند.
ممکن است آسیب پذیری، دیگر وجود نداشته باشد...
اگر گزارشی را از قدیم‌تر‌ها در صندوقچه‌تان ذخیره کرده‌اید و حالا که کسبوکار موردنظر به لیست میدان‌های فعال باگ بانتی اضافه شده‌‌است، فرصت را برای ارسال گزارش مناسب دانسته‌اید، هم لازم است قبل از ارسال گزارش، حتما مطابقت آسیب‌پذیری کشف‌کرده با قوانین را چک کنید. هم‌چنین توصیه می‌کنیم که قبل از ارسال گزارش، وجود آسیب پذیری را دوباره بررسی و از وجود آن اطمینان پیدا کنید. اگر مدتی ست که مشغول بررسی هدف و کشف آسیب پذیری هستید، نیز توصیه می‌کنیم که قبل از ارسال گزارش نیز، وجود آسیب پذیری را بررسی کنید و از وجود آن مطمئن شوید. چراکه ممکن است در مدت زمانی که شما گزارش را ارسال نکرده‌اید، ساختار سامانهی موردنظر تغییراتی کرده باشد و یا آسیب پذیری موردنظر رفع شده باشد.
سایر نکاتی که منجر به رد گزارش آسیب پذیری می‌شوند:
استفاده از ابزار خودکار (Automatic Tools)
اگر در گزارش خود فقط از ابزارهای آماده استفاده کنید، گزارش شما قابل‌قبول نیست. استفاده از ابزار تنها در صورتی قابل‌قبول است که در برای نشان‌دادن وجود آسیب پذیری از آن کمک بگیرید اما در ادامه‌ی گزارش نیز به صورت دستی، آسیب پذیری را کشف کنید. اگر آسیب پذیری که توسط این ابزاری شناسایی می‌شود همراه PoC ( قابل بهره‌برداری ) باشد، تایید می‌شود.
تشریح شناسه CVE بدون این که PoC یا بازتولید داشته باشد.
سخن آخر
احتمالا شرایط توصیف‌شده، برای شما هم پیش آمده باشد. لحظه‌هایی که تطابقی میان انتظارمان و آن‌چه اتفاق افتاده است، نمی‌یابیم. در چنین شرایطی یکی از احساس‌هایی که در ذهن نقش می‌بندد، نارضایتی ست. ما در این بلاگ‌پست کوشیدیم تا با شفاف‌سازی شرایط موجود، شما را با جزئیات این علل آشنا کنیم تا قدمی در جهت جلوگیری از ایجاد نارضایتی‌ها برداشته باشیم.
سوال دیگری دارید؟ با ما و دیگران درمیان بگذارید.
بلاگ‌پست‌های مرتبط:
از باگ تا بانتی؛ ۴ مرحله‌ای که هر گزارش آسیب‌پذیری در راورو طی می‌کند.