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

آن‌چه در این بلاگ‌پست خواهید خواند:

تجربه‌‌هایی از ارسال گزارش آسیب پذیری برای کسب‌وکارها

در این بلاگ‌پست گفته‌هایی از 5 شکارچی آسیب پذیری را خواهید خواند که تجربیات خود درخصوص ارسال گزارش آسیب پذیری را به اشتراک گذاشته‌اند و از برخورد کسب‌وکارها نسبت به گزارش آسیب پذیری، گفته‌اند.

گفته‌هایی از:

برنا نعمت‌زاده، علی فیروزی، نیما غلامی، محمد دلاور و عرفان توکلی

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

تجربه‌‌هایی از ارسال گزارش آسیب پذیری برای کسب‌وکارها

ما از شکارچیان آسیب پذیری پرسیدیم:

_ چه تجربیاتی از ارسال گزارش آسیب پذیری برای کسب‌وکارها دارید؟

_ پس از ارسال گزارش آسیب پذیری، با چه رفتاری از سوی کسب‌وکارها مواجه شده‌اید؟

در برخی گپ‌وگفت‌ها نیز سوال‌های مرتبط دیگری پرسیده‌بودیم و شکارچیان در پاسخ‌‌هایشان به خاطرات و تجربیات مختلف خود اشاره کردند.

در ادامه، پاسخ شکارچیان آسیب پذیری را می‌خوانید که هر یک به تجربیاتی اشاره کرده‌اند.

برنا نعمت‌زاده:

یک آسیب‌پذیری به مایکروسافت گزارش داده بودم. بعد از اینکه گزارش را دریافت کردند، این آسیب‌پذیری را بستند و Not Applicable خورد. علتش را این‌گونه بیان کردند که این آسیب پذیری به دیزاین این اپلیکیشن ربط دارد و چیزی نیست که بتوانیم به عنوان یک آسیب پذیری درنظر بگیریم. نکته‌ای که باید درنظر داشته باشیم این است خیلی از آسیب‌ پذیری‌ها و حملات منطقی‌ای که ما می‌خواهیم گزارش دهیم، ممکن است جزئی از دیزاین و Functionality اپلیکیشن باشند. به همین دلیل است که این نکته اهمیت پیدا می‌کند که ما documentation اپلیکیشن را خوب بخوانیم. من هم documentation را خوانده بودم و کاملا آگاهی داشتم که چه چیزی از documentation است و چه چیزی نیست. با این حساب بعد از این که ریپورتم ریجکت شد، بی‌خیال نشدم و سعی کردم که دوباره توضیح بدهم. چون خیلی وقت‌ها چیزی که باید درنظر بگیریم، این است که ممکن است تیم امنیتی اشتباه متوجه شده باشند. نکته‌ای که یک هانتر باید درنظر بگیرد، این است که بتواند توضیح خوبی را ارائه دهد و موضوع را کاملا باز کند و اثبات کند که آسیب پذیری ربطی به دیزاین ندارد. بعد از این‌که توضیحات مختلف و بیش‌تری دادم، ریپورتم اکسپت شد و توانستم بانتی بگیرم.

تجربه‌ی دیگری که داشتم و برایم جالب بود، کشف یک آسیب پذیری در یکی از سرویس‌های گوگل بود. بدون این‌که از burp suite استفاده بکنم، چندین Functionality جالب داشت این سایت، که با استفاده از همان‌ها من می‌توانستم یک مکانیزم امنیتی را دور بزنم. گزارشش را برای گوگل فرستادم و اکسپت کردند. از من این تجربه‌ی جالبی برایم بود. سعی می‌کنم رایتاپش را هم بنویسم تا دوستان ببینند که چگونه می‌شود با بازی با منطق وب اپلیکیشن، آسیب پذیری‌های مختلفی را کشف کرد.

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

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی آسیب پذیری تمام‌وقت؛ برنا نعمت‌زاده

علی فیروزی:

اکثر تجربیات من در تعامل با کسب‌وکارها مثبت بوده است. شاید دلیلش این باشد که همیشه سعی کرده‌ام با شرکت‌هایی کار کنم که اهمیت ویژه‌ای برای باگ بانتی و گزارش آسیب پذیری قائل هستند. از هدر دادن زمانم با مجموعه‌هایی که توجه چندانی به امنیت سایبری ندارند، پرهیز کرده‌ام.

با این حال، طبیعتاً هر شکارچی آسیب پذیری ای، با چالش‌هایی روبه‌رو می‌شود. در تجربه شخصی من، خوشبختانه هرگز با مشکلات جدی مواجه نشده‌ام. اما در ابتدای کارم با موقعیت‌هایی مواجه بودم که کمی ناخوشایند بودند. به‌عنوان مثال؛ گاهی پس از ارسال گزارش، شرکت‌ها آسیب‌پذیری را رفع می‌کردند، اما یا پرداخت بانتی به تأخیر می‌افتاد یا اصلاً انجام نمی‌شد. در مواردی هم، پس از دریافت گزارش، دیگر پاسخی دریافت نمی‌کردیم.

علاوه بر این، برخی شرکت‌ها تنها به آسیب پذیری هایی توجه می‌کنند که می‌تواند کل سیستم را به‌طور کامل تحت تأثیر قرار دهد. این شرکت‌ها از آسیب پذیری های ظاهراً جزئی، اما با پتانسیل سوءاستفاده‌ی گسترده چشم‌پوشی می‌کنند. این نوع بی‌توجهی‌ها بخشی از واقعیت دنیای باگ بانتی است که باید آن را در نظر گرفت.

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی آسیب‌پذیری؛ علی فیروزی

نیما غلامی:

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

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی آسیب‌پذیری؛ نیما غلامی

محمد دلاور:

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

یک بار یک گزارش آسیب پذیری XSS Reflected را به همراه یک PoC دقیق و قابل‌اجرا، ارسال کردم. کسب‌وکار، آن آسیب پذیری را رفع کرد، ولی با جواب سربالا گفت: "این به ما ربطی ندارد، بانتی هم نمی‌دهیم."

در یک مورد دیگر هم، یک آسیب پذیری CSRF (Cross-Site Request Forgery) حساس را در یک پلتفرم مالی کشف کردم که می‌توانست به Account Takeover منجر شود. گزارش آسیب پذیری را با تمام جزئیات (شامل یک Exploit Chain کامل) برای کسب‌وکار فرستادم. اما نه‌تنها تشکری نکردند، بلکه با لحن تمسخرآمیزی گفتند: "ما خودمان تیم امنیت داریم، نیازی به این گزارش‌ها نیست."

یک بار هم یک آسیب پذیری IDOR (Insecure Direct Object Reference) را در یک سیستم CRM پیدا کردم که دسترسی غیرمجاز به دیتابیس مشتری‌ها را امکان‌پذیر می‌کرد. بعد از ارائه‌ی PoC و توضیح ریسک‌های Privilege Escalation، صرفاً گفتند: "این باگ نیست، یک فیچر است!". هیچ اقدامی هم نکردند، تا زمانی که خودم با هدف این که آن را جدی بگیرند، تهدید به افشای (Disclosure) عمومی کردم.

این تجربه‌ها نشان می‌دهند که بسیاری از کسب‌وکارهای ایرانی هنوز فرهنگ افشای آسیب‌پذیری (Vulnerability Disclosure) را درک نکرده‌اند. کسب‌وکارها هنور به شکارچیان آسیب پذیری، هکرهای اخلاقی و پژوهشگران امنیتی به چشم تهدید نگاه می‌کنند، نه به‌عنوان یک فرصت برای امن‌سازی ( و Hardening) سیستم‌هایشان.

در تجربه‌ام با راورو اما، داستان کاملاً فرق داشته است؛ راورو به عنوان یک پلتفرم باگ بانتی، پشتیبانی 24/7، تعامل حرفه‌ای و یک فرآیند شفاف دارد که مثل یک هماهنگ‌کننده (Coordinator) بین ما و شرکت‌ها عمل می‌کند. این روند، کار را بهینه‌تر و لذت‌بخش‌تر کرده است. مثلاً در راورو، یک گزارش از آسیب پذیری SSRF (Server-Side Request Forgery) دادم که می‌توانست به Internal Network Enumeration و حتی Lateral Movement در زیرساخت منجر شود. نه‌تنها به سرعت پاسخ دادند، بلکه تیم فنی یک جلسه ترتیب داد تا جزئیات را مرور کنیم و بتوانند یک Patch مؤثر پیاده کنند. این سطح از مشارکت و احترام به شکارچی آسیب پذیری، استاندارد جدیدی را در ذهنم ساخته که امیدوارم بقیه هم به آن برسند.

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی آسیب‌پذیری؛ محمد دلاور

عرفان توکلی:

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

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

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی آسیب‌پذیری؛ عرفان توکلی

سخن آخر:

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

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

تجربه‌ی شما از برخورد کسب‌وکارها چیست؟

بلاگ‌پست‌های مرتبط:

رفتار کسب‌وکارها نسبت به دریافت گزارش آسیب پذیری

متخصصین امنیت سایبری، از امنیت سایبری برای کسب‌‌وکارها می‌گویند

نکاتی درباره تست نفوذ که کسب‌وکارها معمولا به آن‌ها توجه نمی‌کنند

نگاه کسب‌وکارها نسبت به تست نفوذ