گزارش نویسی برای باگ بانتی برای دریافت پاداش بیشتر

گزارش نویسی برای باگ بانتی برای دریافت پاداش بیشتر

دراین مقاله ترجمه صحبت هایی که در برنامه لایو با عنوان گزارش نویسی برای باگ بانتی برای دریافت پاداش بیشتر در  برنامه لایو پنجشنبه های بانتی یوتوبر معروف باگ بانتی هانتر STÖK صورت گرفته رو برای شما قرار داده ایم. دراین برنامه که به اسم BOUNTY THURSDAYS – ON AIR در تاریخ 22 می 2022 از کانال یوتوب استوک پخش شد، Jason Haddix و KUGG مهمان استوک بودند و به همراه او به سوالات افراد حاضر در لایو و اسپیس توییتر پاسخ میدادند. پس با ما همراه باشید تا پاسخ های فنی و کاربردی و به روز این متخصص های باگ بانتی را در کنار هم بخوانیم.

STÖK: توی این لایو قراره درمورد بایدها ونبایدهای گزارش نویسی باگ بانتی حرف بزنیم، همچنین قراره درمورد گزارش‌های تست نفوذ هم صحبت کنیم. نوشتن گزارش درست برای باگ بانتی و پن تست تفاوت های زیادی باهمدیگه داره، Jason میتونی درباره شون برامون حرف بزنی و با مثال تفاوت هاشون رو برامون توضیح بدی؟

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

STÖK: کریستوفر هم میخواد درمورد مدلهای نشانه گذاری یا مارک داون برامون حرف بزنه. کوگو بهمون بگو که مارک داون چیه؟ علاقه تو به مارک داون از کجا میاد؟

KUGGO: به نظرمت همکاری داشتن خیلی مهمه، استفاده از مارک داون تو همه مباحث تامین امنیت خیلی راحته، فرمت راحتی داره که همیشه ثابته، اگر به عبارتی دست تون کنده و بقیه فرمت ها اونجورکه دلتون میخواد جواب نمیده، میتونید از مارک داون استفاده کنید که باهاش همکاری و ادغام خیلی راحت تره و اینها دلایل من برای استفاده از مارک داونه.

STÖK: درسته و همه مونم میدونیم که هر2 پلتفرم اصلی باگ بانتی از مارک داون استفاده می‌کنن. پس الان نوشتن توی مارک داون خیلی آسونه.
می‌بینی خیلی راحت می‌تونی تمام کارهات رو تو اون فضا بسازی و انجام بدی و ذخیره کنی. من یه ایده ای دارم و اون اینه که می خوام درمورد اتوماسیون گزارش نویسی صحبت کنم. اینجوری می تونید با ابزارهای جالب زیادی آشنا بشید، بنویسید یا ایجاد کنید. یک پلتفرم تشخیص یا یک بسته ابزار ریکان به اسم reconengine هست که الان براتتو github پیداش میکنم. چیز جالبی که درمورداین ابزار وجود داره اینه که افرادیکه اون رو ساختن، گزارش نویسی خودکار رو به صورت داخلی، داخل ابزارشون قرار دادن، بدینصورت شما زمانیکه دارید اسکن می‌کنید و اطلاعات جمع‌آوری می‌کنید و م یخواییداین اطلاعات به صورت خودکار مثلا به H1 ارسال بشه، این ابزار به شما اجازه می ده تا اینکار رو به صورت خودکار انجام بدین.
Jason بهمون بگو چرا گزارش ها مهم هستن؟

JHADDIX: به نظر من قسمت عمده مبلغی که به عنوان پاداش به شما پرداخت میشه به گزارشی که نوشتین بستگی داره. خیلیا از این موضوع آگاه هستن و خب هیچ کسی از پول زیاد هم بدش نمیاد. من خودم قبلا مسئول تریاژ باگ کراود بودم و از دیدن گزارش های حرفه ای خیلی خوشحال میشدم. چنین گزارش هایی نه تنها توسط تیم تریاژ مورد قدردانی قرار می‌گیرن و اعتمادشون رو جلب میکنه، بلکه روی صاحبان نرم افزارها هم اثر مثبتی دارن. همه مون میدونیم که تو برنامه های باگ بانتی خاص که زیاد هم نیستن افرادیکه گزارش های خوب و آراسته ارائه میدن گاها حتی در صورت ثبت باگ تکراری هم پاداش بهشون تعلق میگیره، چون این پلتفر‌ها می‌خوان مشوق افرادی باشند که گزارش های خوب و درست ثبت می‌کنند. این یکی از چیزهایی که من روش تمرکز کرد. اگر تو باگ بانتی به ابزارهایی مثل recon engine یا سایر ابزارهای مشابه دسترسی ندارید کاری که باید روش متمرکز بشید اینه که حداقل چند قالب آماده داشته باشید. یه جایی توی نوت پد یا Notion یا Mind map یا هرجای دیگه ای که میشناسید درست کنید تا برای تمام چیزهای دم دستی و عمومی ای که پیدا می کنید یک قالب آماده داشته باشید. تمام این موارد باید نوشته بشن، منظورم اینه که من تمام این چیزارو توی کامپیوترم داخل مارک داون نگه می‌دارم، که از لحاظ ساختاری خیلی شبیه گزارش های تست نفوذ هستند. مثلا مثل گزارش پن تست جایی برای توضیحات مشکل قرار دادم، یا محلی برای نوشتن توضیحات آسیب‌پذیری مثل توضیح کامل و جز به جز اثرات آسیب‌پذیری تا گزارش زیادی کلی گویی نباشه، ارائه لینک‌های خارجی تا بتونن بعدا باهام در ارتباط باشن، چون ممکنه سوال یا نظری داشته باشن. 2 تا چیز هست که اغلب افراد اونها رو از قلم میندازن، یکیش شرح داستان چگونگی پیدا کردن باگ هست. من گزارش های باگ بانتی زیادی دیدم که قصد داشتم قسمتی از روش ریکانم رو بهشون یاد بدم تا اون باگ رو بتونن خودشونم پیدا کنن.
من اینکارو رو زیاد با چیزهایی که تو Github پیدا کردم انجام دادم، بهتره بگم چندتا داده حساس ورودی کشف کردم که مربوط به یک شرکت توی github بود و داخل یک ریپازیتوری ذخیره شده بود. ابزارهایی که عموما ازشون استفاده می‌کنم رو به همراه توضیحات مربوط به اینکه آسیب‌پذیری رو چجوری و با استفاده از چه ابزارهایی پیدا کردم، دنبال چه کلمه کلیدی گشتم که این آسیب‌پذیری رو پیدا کردم و اینکه علاوه بر این یک کریدیشینال، 6 تای دیگه هم پیدا کردم اما اگر درآینده خودتون قصددارید اینکار رو انجام بدین یا این آسیب پذیری که من پیدا کردم مهم نیست براتون، از این روش و دستورالعمل ها میتونید تو فرایند امنیتی اون استفاده کنید. من درقبال انجام دادن این کار پاداش گرفتم، شاید نتونستم باگ پیدا کنم ولیکن باز پاداشم رو گرفتم. بنابراین شرح این داستان که باگ رو به چه صورت پیدا کردی و از چه روش ها و مسیرهایی برای پیدا کردن این باگ استفاده کردی برای افراد پشت صحنه مهم و جالبه. پس چیزای زیادی رو میتونید تو گزارش هاتون بگنجونید که می تونه وجه تمایز شما با یه هانتر دیگه باشه که فقط با نوشتن یه URL داخل گزارش ثبت شده، فقط یه گزارش سرهم کرده باشه.

STÖK: دقیقا همینطوره، من خودم شخصا طرفدار این هستم که توی تمام گزارشهام فایل ویدیویی هم قراربدم. این کار برای اطمینان حاصل کردنه، بااینکه نمیشه توی هرگزارش از یه ویدیو تکراری استفاده کرد. ممکنه اتفاق خاصی بیفته،بک آپ برگردونده بشه، یا شب قبلش هدف مورد حمله قرار گرفته باشه و افراد تیم تریاژ نتونن اون رو بازسازی و بازتولید کنن. من برای تک تک حرفایی که میزنم مدرک دارم. دومین دلیل من برای انجام دادن اینکار اینه که به من این قابلیت رو میده تا در زمانهایی که وقت کم دارم از ماکسیمم مقدار قابلیت های خودم بتونم استفاده کنم. پس ویدیو ضبط میکنم و توی ویدیو با تیم تریاژ صحبت میکنم و کارهایی که انجام دادم روبراشون توضیح میدم. مثلا میگم:” سلام ‌بچه های تریاژ تیم امنیتی من این آسیب‌پذیری رو پیدا کردم و اینایی که میگم مراحل بازتولید این آُیب پذیریه، برای اینکار به این ابزارها نیاز دارید.” ، همه چیز رو آماده میکنم و اسکرین رکوردرو روشن می کنم و از تمام مراحل و حتی کارهایی که علاوه براون هم میتونن برای ویرایش نرم افزار انجام بدن رو هم بهشوشن میگم و از همشون ویدیو تهیه میکنم. توی این ویدیو ها فقط زمان های بارگذاری‌ها رو حذف میکنم. چون همونجور که میدونیم، تمام مراحل اینکار زمانبر هستن که هیچ کدوممون دوست نداریم زمانمون سر اونا تلف بشه. من سعی میکنم تمام این تایم های پرت رو دور تند بذارم یا تمام این تایم های بارگذاری ها رو حذف کنم از ویدیو، چون زمان طلاست، هم برای ما و هم برای طرف مقابل، پس بهتره اونا هم هرچه زودتر به اصل ماجرا پی ببرن.
اما اینم بگم که درصورتیکه من از نتایج کاری مطمئن نباشم این کار رو براش انجام نمیدم. زمانیکه مطمئن شدم واقعا حرفی برای گفتن دارم و مطمئن هستم که این آسیب پذیری اثراتی داره که ارزش داره وقت بذارم و داستانش رو تعریف کنم و تاثیرات اون رو تو ویدیو نشون بدم، اینکارو انجام میدم.
خب ابزار rengine که بهتون معرفی کردم رو پیدا کردم. این ابزاری که من الان پیدا کردم موتور ریکان هست. یک چارچوبه که برای برخی از ابزارهای ریکان محصول ساخته شده، یک پلتفرم مبتنی بر وب، جاییکه توش کلی کار میتونیدانجام بدین، یه جورایی شبیه شبیه recon for win هست، میشه باهاش کارهایی مثل ایجاد پورتال انجام داد. درکل چیز جالبی که من از این ابزار یادگرفتم این بود که به آدم این امکان رو میده تا قالب های خودش رو بااستفاده از api هکروان ایجاد کنه. اینجوری تمام چیزهایی که میخواهید رو میتونید به صورت آماده داشته باشید و زمانیکه یک آسیب پذیری خطرناک پیدا کردید و توضیحاتتون رو داخل قالب آماده تون توی nuclei نوشتید و از چیزی که پیدا کردین مطمئن هستید و می خواهید گزارشش رو ثبت کنید، می تونید از این چارچوب استفاده کنید و این گزارش رو داخل برنامه های مختلف که توشون ثبت نام کردید منتشر کنید.
اگر دوست دارید قالب هاتون رو خودتون ایجاد کنید با codingo کار کنید، که ما دوهفته پیش درمورداون صحبت کردیم. کدینگو یه ابزاری به اسم bbr ساخته که اگر نگاه کنید کاملا متوجه می‌شید که که یک گزارش‌ساز باگ بانتی است، یک ابزار مبتنی بر دستورات (Command-line) که به شما این امکان رو میده تا قالب های آماده خودتون رو ایجاد کنید. تمام این متغیرهای گوناگون و متنوع رو توی این ابزار مشاهده می‌کنید. پس فقط کافیه یکبار یک قالب زیبا و منسجم برای گزارش‌هاتون بسازید،همونجوریکه دلتون میخواد، جوریکه تمام توضیحات رو داخلش داشته باشه.
میبینین! وقتی زندگی و کارتونرو باابزارهایی مثل nuclei جلو میبرین چقدر همه چیز آسون میشه! تو فرآیند ریکان کم یا زیاد از اتوماسیون استفاده می‌کنیم. من با سازنده این ابزار صحبت کردم و گفت که بالغ بر 4000 گزارش داره که هوز ثبتشون نکرده!!!
در ادامه میخوام درمورد این ریپازیتوری که توسط Ivan Modin ایجاد شده باهاتون صحبت کنم. ایشون رو بیشتر با اسم Reddlexc میشناسیم و این ریپازیتوری گزارشات هکروان هست و نکته جالبش اینه که اون تمام دسته بندی های باگ ها و گزارش های برتر مختلف رو اینجا جمع آوری کرده که این ریپازیتوری دائما درحال آپدیت شدنه. بالغ بر 100 گزارش برگزیده شده و مبالغ پاداش های پرداخت شده به این گزارشات اینجا گردآوری شدن. من اینجوری فکر میکنم که که این ریپازیتوری با فراهم کردن این امکان که ببینید بقیه چگونه گزارش می‌نویسند و بااستفاده از نکات هر گزارش موفق چگونه می‌تونید یک گزارش خوب بنویسید به شما انگیزه می‌ده.

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

JHADDIX: به نظرمن نوشتن گزارش اثرات آسیب پذیری باید تا حدودی مرسوم شده باشه، اکثر افراد حالت پیشفرض OWASP رو برمیدارن و سعی می کنن اثرات آسیب پذیری رو داخل اون قرار بدن. من بعضی ازین مدل گزارش ها که استاندارد نیستند رو دیدم که اثرات آسیب پذیری مرسومی رو دربرداشتند که مهم بودند، مثل gdpr Violation. برای مثال اگر درحال کارکردن روی یک شرکت اروپایی هستین، به عبارتی یه جورایی این شاخه ای از GDPR است، حتی اگر داده‌ی مهم و حیاتی‌ای داخل گزارش ثبت شده باشد. چنین گزارش هایی اساسا باگ را به صورت داخلی تشدید می‌کنند.
اما درادامه، استوک داشت درمورد قرار دادن ویدیو و اسکرین شات داخل گزارش ها صحبت می کرد. طبق تجربه ای که از پشت پرده اینکار دارم و به مدت 5 سال با باگ کراود همکاری کردم، زمانیکه یک باگ خیلی خیلی فنی هست، جوریکه تیم تریاژ به تنهایی قادر به بازتولید اون باگ نیست یا نیازمند زنجیره پیچیده‌ای هست و …، تیم تریاژ معمولا در چنین مواقعی از هانتر درخواست ویدیو میکنن، پس اگر باگی که پیدا کردین فراتر از XSS هست، ضبط کردن ویدیو از مراحل کار یک مزیت براتون میتونه به حساب بیاد. کلی نرم افزار برای اسکرین شات گرفتن اون بیرون وجود داره که میتونید ازشون استفاده کنید. همونطورکه استوک هم گفت بااینکارمسیر فرایندی که طی کردین رو هم ذخیره کردین. من تعداد زیادی ثبت گزارش باگ بانتی داشتم که آسیب‌پذیری تزریق SQL داشتن و شرکتی که من دنبالش بودم گروه عملیات امنیتی داشت که اونها این گزراش ها رو توسط وصله مجازی waff بهم متصل کرده بودن، که من دیگه نتونستم دوباره به اون هدف حمله کنم. اما من گزارش رو ثبت کردم. از طرف دیگه تیم باگ بانتی یک تیم متفاوتیه که داخل این کسب و کار قرار گرفته و قادر به بازتولید مجدد باگ نیستند، حتی باگ کراود هم نتونست اونو مجددا ایجاد کنه. برای همین گفتن نمیتونیم پاداش پرداخت کنیم چون آُیب پذیری ای که پیدا کردی معتبر نیست. اما من از مراحل کار فیلم گرفته بودم و اسکرین شات داشتم که همه اینها تو این شرایط من رو نجات دادن و حرفم رو ثابت کردن. من چنین مدارکی رو زمانهاییکه می خوام دسترسی به دیتاها رو ثابت کنم یا نشون دادن اینکه من به اسم جداول میتونم دسترسی داشته باشم ارائه می‌دم. و خب داشتن اسکرین شات و ویدیو از مراحل کار شما رو از سوتفاهم ها و دردسرهای احتمالی بعدی که ممکنه با افرادیکه تیم های عملیاتی سریع دارند و امکان داره موارد رو به هم وصل کرده باشن، در امان نگه داره. یا حتی ممکنه بخاطر اینکه رشته های تزریق SQL به سمتشون میفرستید، توسط Waff یا هچین چیزایی داخل لیست سیاه قرار بگیرین و … . درکل دلایل زیادی وجود داره تا شما رو ایجاب کنه از مراحل فرایندی که طی می کنید ویدیو و اسکرین شات تهیه کنید.

STÖK: ما الان یادگرفتیم که تعیین میزان حساسیت و موقعیت آسیب‌پذیری خیلی مهمه، اما درادامه می خواییم بدونیم چه چیزها و چه کارهایی قابل و اجرا و ادغام هستن؟
یکی از ترفندها اینه که بتونی فکر اون سازمان ذو بخونی، درک کنی و بفهمی که این هدف به چه چیزی نیاز داره. اگر ارزش‌های اون سازمان او ن سازمان رو درک کنید. بهتره بگیم GDPR میتونه جالب باشه ولیکن کشت GDPR (GDPR Farming) زیاد جالب نیست.
اما اگر شما امکان این رو دارید که وارد اون شرکت بشید، آدرس های IP، ایمیل ها را پیدا کنید بهتر بگیم Mailchimp پیدا کنید که برای خودش یه دنیاییه. مثلا اگر IP آدرس یا ایمیل یک راننده یا مسافر Uber رو پیدا کنید، این اتفاق برای شرکت خیلی مشکل ساز خواهد بود. فهمیدن این نکته که هرشرکت دنبال چه نوع آسیب‌پذیری‌ میگیرده و درک ارزش این مساله به شما دید خوبی میده که به کمک اون می تونید گزراش هایی بنویسید که بتونید باهاشون پاداش دریافت کنید.

JHADDIX: اجازه بدید من دراینمورد یه مثالی بزنم، داستان کاری که من به عنوان یک باگ بانتی هانتر در اینمورد برای یک مشتری انجام دادم رو براتون میگم الان. من تصمیم گرفتم فقط با ابزار بروت فورث دایرکتوری یک آسیب‌پذیری دورزدن احراز هویت بگیرم و یک اندپوینت پیدا کردم که هیچ قانون کنترل دسترسی روش اعمال نشده بود، که باعث شد تا من بتونم از مرحله ورود (Login) بدون هیچ سختی عبور کنم و وارد crm بشم. من همونجا متوقف شدم و گزارش Authorization bypass به crm رو ثبت کردم. احتمال می‌دادم که که توی bugcrowd به این آسیب پذیری P1 یا P2 بدن. کاری که من کردم این بود که دنبال یک اپلیکیشن کاربردی گشتم و متوجه شدم که این crm به چه چیزهایی دسترسی داره و باهاش چه کارهایی انجام میدن، بعدا متوجه شدم که این crm به یک پنل sms دسترسی داره که صدها و هزاران شماره تلفن متعلق به افراد داخل اون نگهداری میشه. من تمام این موارد رو داخل گزارش اثرات آسیب‌پذیری نوشتم و تمام کارهایی که من میتونستم با استفاده از این دسترسی به cms انجام بدم رو براشون توضیح دادم، مثلا گفتم من الان میتونم به تک تک مشتری هاتون sms ارسال کنم، میتونم javascript بفرستم براشون، تمام اینها رو همین الان میتونم به موبایل تک تک اونها ارسال کنم، و کلی اطلاعات اساسی از مشتری ها میتونم گردآوری کنم. و این با این صحبت ها میزان حساسیت آُسیب‌پذیری از P1 یا P2 به P0 رسید. اینجوری شد که من از این گزارش تونستم امتیاز و پاداش بالاتری کسب کنم.

KUGGO: یه نفر پرسیده که اگر من توی یک برنامه باگ بانتی 2 تا آُسیب‌پذیری پیداکنم، بهتره برای هردوشون یک پزارش بنویسم و اینجوری میزان حساسیت اثرآسیب‌پذیری رو بیشتر نشون بدم یا بهتره 2 گزارش جداگانه بنویسم و به‌هم یگه ارجاع بدم؟

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

STÖK: دقیقا درسته، ریدایرکت های URL و ریدایرکت‌های باز هم همینطور هستن. اگر از این دست آُسیب‌پذیری ها پیدا کردین زود گزارش ثبت نکنید براشون، ازشون نگهداری کنید تا بعدا با استفاده از اونا ssrf انجام بدین.

یه سوال دیگه اینجا داریم که میخواد برای گزارش بد هم مثال بزنیم.

یک گزارش کلاسیک داریم که به گزارش راننده تاکسی (taxi driver) معروفه و روی هکروان قرار داره. بدی این گزارش اینه که کلا رشته کلام از دست نویسنده در رفته، جریکه حس میکنی یه بچه 6 ساله اونو نوشته، یه جورایی بهت یاد میده که برای ارتباط برقرار کردن چه کارهایی رو نباید انجام بدیم. چون اگر روی افراد برنامه باگ بانتی داد بزنی، اونا رو احمق و اینجور چیزا موردخطاب قرار بدی، این حرفها و جملات باعث برقراری ارتباط نمیشن. باید اینو بفهمی، زمانیکه دارید یک گزارش رو در خدمت یک برنامه باگ بانتی قرار میدین،باید مهارت گزارش نویسی و برقراری ارتباط داشته باشید. این گزارش یک پل ارتباطی بین شما و افراد سمت برنامه به حساب میاد. اگر شما اینکار رو به صورت اصولی انجام می دین و داخل گزارش اصول برقراری ارتباط موثر رو رعایت می‌کنید، یک ارتباط آرامش بخش و قابل اعتماد بین خودتون و طرف مقابل ایجاد میکنید. باگذشت زمان اهمیت این حرفها بیشتر براتون مشخص خواهدشد. یک تستی که اینجا میتونید انجام بدین تا مطمئن بشید که شرکت طرف مقابلتان به اندازه کافی رفتار خوب و دوستانه ای دارد یانه، این است که درابتدا یک آسیب‌پذیری با شدت کم رو براشون بفرستید و منتظر عکس‌العملشون باشید. اگر توجه کافی بهتون نشون ندادن، این ممکنه به این معنی باشه که این برنامه مناسب شما نیست.

JHADDIX: درسته و لطفا با افراد تیم تریاژ هم بدرفتاری نکنید. اونا هم مثل شما آدمای معمولی هستن و این نباید باعث بشه که جاهای دیگه ای مثل توییتر یا یوتوب بهشون توهین کنید و باهاتشون رفتار نامناسب داشته باشید. باگ بانتی هانترهای زیادی رو میشناسم که با افراد تیم تریاژ خصومت دارند. افراد تیم تریاژ در پشت صحنه روزانه بالغ بر 100 گزارش براشون ثبت میشه. اونا افراد فنی بسیار باهوشی هستن که باید هم در زمینه گزارش‌ها و هم در سمت کامیونیتی حضور فعالی داشته باشن و هیچ وظیفه‌ای ندارند که به سوالات شما جواب بدن یا با خوشرویی با شما رفتار کنن. سعی کنید با این افراد با کلمات و جملات مناسب و محترمانه صحبت کنید.

STÖK: درسته، شما نمیدونید گزارش شما رو چه کسی قراره بعدا بخونه. شاید بگین هیچ کس حق نداره گزارش من رو اون بیرون منتشر کنه، کاملا اشتباه میکنید، برگزار کننده برنامه می تونه هرکاری دلش میخواد با گزارش شما انجام بده. ممکنه آدمی که اون پشت نشسته کارفرمای بعدی تون باشه، چون افرادیکه تو این زمینه کار میکنن تاحاللا دیده نشده برای مدت طولانی یک جا بند بشن و ممکنه اون فرد رو بعد از 3 یا 5 سال جای دیگه ملاقات کنی. اصلا منظورم این نیست که اونا آدمای کینه‌ای هستن، ولیکن جوری رفتار کنید که خودتون رو یک فرد خوش مشرب با روابط عمومی خوب نشون بدین و نشون بدین که واقعا به کاری که انجام میدین علاقمند هستید، و جوری رفتار نکنید مثل اینکه دارید بانتی رو گدایی می‌کنید.
چون اکثر برنامه ها وقتی ببینن واقعا شما یک فرد کاردرست هستین کم یا زیاد بانتی پرداخت می‌کنند. اگرم پرداخت نکردن و اونقدری که انتظار داشتین باهاتون خوب نبودن، رد بشین ازشون و روی برنامه بعدی کار کنید.

JHADDIX: من حدود 3 یا 4 هفته پیش یه تجربه‌ای داشتم. لیستی از یافته هایی در سطح nuclei داشتم، مثل گواهی های منقضی شده و کلا چیزهایی که هیچ وقت اونا رو گزارش نمیدیم. میخواستم یک گروه کنترلی رو روی کل لیست بانتی های مختلف اجرا کنم تا ببینم اگر یک سازمان 6 تا، 7 تا یا 10 تا یا 15 تا از این موارد رو اگر داشته باشن و من اونها رو به عناون یک بسته 15 تایی داخل یک گزارش بهشون گزارش بدم، به من چیزی پرداخت می‌کنن یا نه؟! تقریبا برای تمام برنامههای باگ بانتی این کارو انجام دادم، اکثرشون درحد یک مشکل کم اهمیت کشف شده پاداشی به من پرداخت کردن. نظر شما درباره این کار چیه؟ مشتاقم نظر شما رو هم بشنوم.

STÖK: منظورت اینه که برای یک حل مشکل (fix)، یه پاداش دریافت کنیم، یا کلی از این چیزهایی که هیچ وقت گزارش نمی‌دیم رو پیدا کردی، مثلا منظورت اینه که 100 تا ssrf رو یکجا پیدا کردی و براشون فرستادی؟

JHADDIX: نه نه، اینایی که من پیدا کردم چیزای خیلی دم دستی‌ای بودن، مثل افشای اطلاعات، پیام‎‌های خطا، گواهی SSL، گاها لیستی از دایرکتوری‌های بی‌اثر، چیزهایی که ذاتا باید درست بشن، چراکه ممکنه بعدا امنیت سیستم رو به خطر بندازن، اما تاثیر زیادی ندارن. من این موارد رو به صورت دسته بندی شده ثبت گزارش کردم. و اونها به پکیجی که گزارشش رو ثبت کرده بودم پاداش یک آسیب‌پذیری سطح پایین رو پرداخت کردند. حتی درابتدای گزار هم براوشن نوشتم که :”سلام، من متوجه این موضوع هستم که درکل برای این مواردیکه من براتون میفرستم هیچ پاداش پرداخت نمی‌کنن، اما ممکنه بخوایید این مشکلات رو خودتون حل کنید، من لیستی از این آسیب پذیریها رو براتون میفرستم و به خودتون بستگی داره که بخواهید پاداشی درحد یک آسیب پذیری کم اثر براش درنظر بگیرید و پرداخت کنید”.

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

STÖK: کریستوفر من کاملا باهات موافقم. من خودم طرفدار گزارش‌های فله‌ای هستم حتی اگر ازشون چندتا چندتا هم داشته باشه، مثلا تو یک موقعیتی 16تا ssrf روی IP آدرس‌های مختلف داری، می دونم که همه اینا درآخر قراره رفع بشن، چون همشون داخل جعبه ابزار مشابهی هستن که IPآدرس‌ها و امواج متفاوتی دارند. شاید دفعه اول که پول بگیرم باخودم بگم آره خودشه، خیل یباحاله، ولی درآخر نه، جواب من به این ایده یه نه بزرگه، چون اینکار بیشتر شبیه به خودکشیه!

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

JHADDIX: به نظرم منم زمانی بااین مشکل مواجه شده بودم. وقتی میخواستم با قوانین gdpr ارتباط برقرار کنم، چیزهایی مثل قوانین امنیتی محلی که تمام اینها م یتونن عواملی باشن که شدت یک آسیب پذیری رو تعیین می‌کنند. من درمورد قوانین جمهوری دومینیک اطلاعی نداشتم ولیکن میدونم تو این زمینه قوانین بی سرو ته زیادی جود داره، یه جاهایی حتی افشای نام کاربری یا اسم واقعی کاربر و … خیلی جاها تو قراردادها و قوانین امنیتی لحاظ می‌شن که واقعا چیزهای مهمی نیستن.

پرسش در چت KUGGO: در رتبه بندی CVSS، PII چگونه ترجمه میشه؟ من دیروز یک نشتی I-DOR پیدا کردم که حاوی حجم زیادی از اطلاعات مثل ایمیل، نام و نام خانوادگی، کد تخفیف (500 هزار یورویی) و … بود و اما گروه تریاژ به گزارش من بخاطر استفاده از CVSS رتبه High داد.

CVSS ها نشت اطلاعات بدون توضیح اضافی هستند و یه جورایی به شکارچی سرنخ میدن تا ببینه بااستفاده از اون چندتا چیز دیگه رو میتونه پیداکنه. به نظر من چیزهایی که تو پیدا کردی با ارزش هستند.

JHADDIX: تمام اینهارو باید تو گزارشت بنویسی. من اگر جای تو بودم اثرات آسیب‌پذیری رو بالا و درابتدای گزارش قرار می‌دادم. مثلا می‌نوشتم درسته که این‌ها صرفا یکسری الاعات هستند که توسط CVSS یا نشت اطلاعات فراهم شدن، با توجه به حجم داده ها این اطلاعات اطلاعات افشا شده هستن و باتوجه به قوانین امنیت داده که این کسب و کار از آن پیروی می‌کند، این گزارش، یک گزارش با حساسیت بالاست. از کلمه بحرانی استفاده نمی‌کنم چون دلم نمیخواد بهشون بگم چه کاری انجام بدن، اما بهشون میگم این ها صرفا اطلاعات معمولی‌ای نیستن که افشا شدن و این موضوع رو بالای گزارش یعنی درابتدای اون مینویسم. خیلی خوبه که از چیزی بنویسی که مطمئنی بتونه نظر مشتری رو جلب کنه. توی bugcrowd من این کار رو زیاد انجام دادم. مثلا می‌گم “سلام، این یک گزارش ساده یا معمولی نیست.” یه کاری بکن، یه چیزی بنویس که مشتری توجهش جلب بشه، چون ممکنه از gdpr استفاده کرده باشن یا یه چیزایی به برنامه وصل کرده باشن. تو سعی خودت رو بکن، اما اینکه به حرفت گوش بدن یانه کسی چیزی نمیدونه، و تمام این ها به تیم تریاژ بستگی داره. گروه تریاژ اولین دیواریه که باید ازش رد بشی و PI بگیری. اما من میگم که یگ باگ این چنین ینباید فقط توی CVSS رتبه بندی بشه. من فکر میکنم که CVS اصلاح گر جایی مثل یه ماسین حساب داره که فقط تعیین کننده سطح آسیب پذیری نیست و میتونه تعیین سطح کننده امنیتی باشه. شایدم من دارم به جای CVSS در موردامتیاز و رتبه بندی خطر OWASP صحبت می‌کنم. اما حسابگرهای رتبه بندی خطر زیادی اون بیرون هستن که در دسته بندی باگ تاثیر فنی دارند. همچنین جایی برای تعیین سطح تاثیر PII هم دارند. توی باگ بانتی زیاد درموردش صحبت شده، اکثر پلتفرم‌ها از کلمه به کلمه CVSS استفاده می‌کنن و درصورتیکه حتی ممکنه به عنوان یک پلتفرم این واحد مناسبی برای رتبه بندی باگ نباشه .

KUGGO: من با حرفات موافقم. منظورم اینه که دراین مورد خاص که کدهای تخفیف که احتمال داره قبلا توسط افراد دیگری استفاده شده باشن، کدهای تخفیفی هم که توی این فروشگاه مثلا به ارزش 500 دلار پیدا کردی مخصوص یک نفره، این به این معنیه که شما نه تنها از فروشگاه دزدی می‌کنید، بلکه از کشتری هم دزدی می‌کنید تو این شرایط. ازنظر من این مساله باعث میشه تا شدت آسیب‌پذیری بسیار بالا باشه، چون هم میتونه شما رو پولدار کنه و هم بهتون کمک میکنه تا شخصی رو که قراره ازش دزدی کنید رو هم پیدا کنید ؛)
اما فکر میکنم این مساله به استدلال هم بستگی داشته باشه، چون CVS ، CBS ها رو در برنمی‌گیره. بهرته بگم من از CVS زیاد خوشم نمیاد. برای توصیف اکثر آسیب‌پذیری‌ها مخصوصا آسیب‌پذیری‌های مرسوم زیاد جالب نیست. اما دراینمورد خاص مثال اصلی ما در زمان شکست است.

JHADDIX: باید تو گزارش نویسی مهارت خیلی خوبی داشته باشی، باید روی مهارت نوشتاریت کارکنی، باید از ابزارهای بررسی کننده املا کلمات و گرامر متنی و جملات استفاده کنی و عادت کنی تا گزارش ها رو به صورت داستانی و روان بنویسی و همه چیز رو داخلش به خوبی توضیح بدی.

STÖK: با این بحث به بخش بعدی برنامه امروز میریم که قرار بود درمورد گزارش های تست نفوذ صحبت کنیم، و گزارش نویسی برای باگ بانتی رو همینجا تموم می‌کنیم. نوشتن گزارش تست نفوذ هم برای من و هم برای کریستوفر خیلی راحته، چون بیشتر از 20 ساله که داریم اینکارو انجام می‌دیم. من ازش متنفرم! دوباره اشاره میکنم که گزارشهای باگ بانتی و پن تست در کل داستان های متفاوتی دارن. پس بیایید بریم سراغ این قسمت. جیسون نظر تو چیه، حرفی یا اطلاعاتی هست که بخوای در اینمورد باما درمیون بذاری؟

JHADDIX: خب از باگ بانتی عقب نشینی میکنیم و وارد بحث گزارش نویسی تست نفوذ میشیم. قبل از هرچیزی اگر می‌خواهید اطلاعاتی درمورد گزارش نویسی و اینکه گزارش نویسی داخل تست نفوذ به چه صورته بدست بیارید، میتونید به سایت Pentestreports.com مراجعه کنید. این سایت تقریبا تمام قالب های آماده یا گزارش های نمونه که نظرات کارشناسی و مشاوره‌‌های خوب زیادی براشون نوشته شده رو در خودش جا داده. اینجا می‌تونید با فرمت‌های گزارش‌ها آشنا بشید و اگر به تنهایی کارتست نفوذ انجام میدید یا قرارداد کاری دارید یا می‌خواید اطلاعاتی در مورد اینکه این افراد و مشاورها چگونه گزارش های پن تست رو فرمت می‌کنند بدست بیارید و یا ببینید که یافته‌های شخصی شون چی هست و یک گزارش رو چجوری به قسمت های مختلف تقسیم می‌کنند، میتونید داخل این سایت برید و تعدادی از بهترین گزراش‌های موجود در صنعت تست نفوذ رو اونجا مشاهده کنید. اینجا ساختار گزارش نویسی رو می‌تونید مشاهده کنید یا اگر یک تست نفوذگر مبتدی هستید می تونید اطلاعاتی درمورد اینکه گزارش‌ها چطور هستند و شما هم اگر قرارباشه گزارش بنویسید چه کار باید بکنید، که تو این سایت می‌تونید شکل کلی چیزی که قراره بنویسید رو ببینید.
من شخصا این سایت رو خیلی دوست دارم چون توی گزارش نویسی و تست نفوذ به آدم خیلی انگیزه میده.حتی برای باگ یانتی هم میتونید ازش استفاده کنید، سازندگان این مرجع از باهوش ترین اعضای مهندسی معکوس دنیا هستن و دراین زمینه خیلی حرفا واسه گفتن دارن. مثلا اینجا برای امنیت TCM هم چیزهایی دارند، درکل یک منبع عالی برای یادگرفتن گزارش نویسی پن تست هست که به صورت سنتی کارشده و خروجی فایلها به صورت PDF دراختیار شما قرار می‌گیره. اگر بعدها دران زمینه سوالی براتون پیش آمد می‌تونید به این سایت مراجعه کنید. میتونید ببینید که از نظر یه آدم فنی، گزارش حرفه‌ای چجور گزارشیه یا می‌خواید مشاور جدیدی برای خودتون پیدا کنید یا سبک گزارش نویسی تون رو تغییر بدید، می‌تونید تو این سایت سبک‌های نختلف گزارش‌نویسی که افراد محتلف بکار می‌برن و گزارش هایی که تولیدمی‌کنند رو مشاهده کنید. درآخر گزارش‌های ساخته شده به‌صورت PDF درمیان. نرم‌افزارهای زیادی اون بیرون وجود داره که مشاورها ازشون استفاده می‌کنن که تعدادی از اینها پولی هستند و برخی دیگر رایگان هستند. اما بزرگترین نرم افزاری که افراد زیادی به سمتش می‌رن PlexTrac هست. دراصل PlexTrac یک پلتفرم گزارش نویسی‌ه‌. نقطه قوت این نرم‌افزار قابلیت ساختن قالب‌اش ه. قابلیت‌های گوگل داکز رو هم داره که اجازه میده به صورت همزمان بیشتر از یک نفر روی یک پروژه کشف کار کنه. تست‌نفوذگرهای زیادی هستند که برای گزارش نویسی به سمت استفاده از Plextrac می‌رن.
من قبلا از ابزار دیگه‌ای به اسم dradis استفاده می‌کردم که پولی بود، ولیکن نسخه رایگان هم داره این چارچوب. درکل اینجا جای خوبی برای شروع کار تست نفوذ هست، اگر بودجه اولیه کافی برای شروع اینکار رو ندارید، اینجا نسخه کامیونیتی مبتنی بر وب dradis رو داریم که به شما کمک می‌کنه تا گزارش خودتون رو بسازید. یک چارچوب گزارش نویسی که به شما این اطمینان رو میده وقتی دست تنها کار می‌کنید بتونید ازش استفاده کنید، یا اگر عضو یک تیسم مشاوره هستید هم میتونید ازش استفاده کنید. اینجوری زیاد عذاب نمی‌کشید، چون پروسه گزارش نویسی از عذاب آورترین مراحل کار پن تست ه. اینجا آشنایی با یک چارچوب خوبیه که به شما اجازه میده مراحل تست نفوذتون رو تاجاییکه امکان داره تکه تکه کنید. درفضای تست نفوذ اکثر افراد درحال کشیده شدن به این سمت هستند. درواقع اینکه فقط یک کار تست نفوذ داشته باشید و از یک نویسنده حرفه‌ای کمک بگیرید تا یک گزارش خوب بسازید، می‌تونید برنده این بازی باشید.
اینها تماما امکانات پولی بودند که بهتون گفتم و اگر شما الان میگید من به عنوان یک پن تستر دست تنها هیچ پولی ندارم، قرارداد کاری می‌بندی یا برای پلتفرم‌هایی مثل هکروان و باگ کراود یا اینتگریتی که همشون برنامه ‌های تست نفوذ هم برگزار می‌کنند، دارم کار تست نفوذ انجام می‎‌دم. امکاناتی وجود دارند که به صورت پروژه‌های متن باز در اختیار شما هستن که می تونید از اونها برای گزارش نویسی استفاده کنید. برای پیدا کردن این ابزارها از کلیدواژه چارچوب های گزارش نویسی تست نفوذ استفاده کنید. یکی از این ابزارهای که برای تست نفوذ ساخته شده اسمش vulnrepo هست که یک پروژه گیت‎‌هاب‌ه که خودتون میتونید راه‌اندازیش کنید و گزارش های تست نفوذتون رو با فرمت html و txt بسازید یا حتی خروجی PDF هم میتونید اززش بگیرید. این ابزرایه که من واقعا ازش خوشم میاد و به نظرمن امکانات کافی‌ای برای انجام دادن کارها داره.
وقتی دارید دنبال نرم‌افزارهای گزارش نویسی می‌گردین گزینه دومی که می‌تونید درنظربگیرید pwndock هست که واقعا کارش درسته. به نظر من 4 یا 5 تا ازیان چارچوب ها هستند که به شما اجازه میدن تا فایل docx ایجاد کنید و چارچوب های که به شما اجازه میدن قالب‌هایی که خودتون ایجاد کردید رو نگه دارید.
همونطور که قبلا هم درموردش صحبت کردیمِ، اگر برای کشف آسیب‌پذیری خودتون یک قالب دارید، این چارچوب‌ها بهتون اجازه می‌دن تا قالب‌هاتون رو داخل چارچوب ذخیره کنید و روی هرگزارشی که قراره بنویسید اضافه کنید. من زمانیکه یک پن تستر تمام وقت بودم تنها کارهای قراردادی انجام میدادم، 24 ساعت از 7 روز هفته رو کار می‌کردم و هیچ کدام از این امکانات رو نداشتم و اون اندک امکاناتی هم که بود هزینه‌های واقعا بالایی داشتن و نوشتن گزارش در اون دوران واقعا کار طاقت فرسایی بود و آدم رو از پا درمیاورد.

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

JHADDIX: جاییکه قالب هاتون رو ذخیره می‌کنید مهم نیست. خیلی‌ها از برنامه Notion استفاده می‌کنن که شما هم اشاره کردید که اگر کارتون شکار جایزه آسیب‌پذیریه Notion جای خوبی برای ذخیره کردن قالب‌هاست. حتی اگر شما مشغول انجام دادن تست نفوذ هستین می‌تونید متن‌هاتون رواونجا ذخیره کنید و بابقیه افراد به اشتراک بذارید. یه راه قدیمی برای انجام اینکار Google Docs هست که فقط کافیه یه قالب تو گوگل داکز ایجاد کنید. سپس یک قالب برای کشفیات و یک قالب برای داکیومنت کشفیات به صورت جداگانه ایجاد کنید. یکی ز این فایل‌های قالب گزارش نویسی تون قراره باشه و دیگری قالب آسیب‌پذیری‌هاتونه و تنها کاری که لازمه انجام بدین اینه که اطلاعات موردنیازتون رو داخل گوگل داکز واین فایل‌ها کپی و پیست کنید.
مشکلی که اینجا میتونید باهاش مواجه بشید اینه که مثل بقیه مشکلات مرتبط با کپی و پیست، همیشه وقتی که دارید همزمان با جلو رفتن پروژه این کار رو انجام میدیدن، باید به یاد داشته باشید که تمام محل‌های نگهدارنده داده‌ها رو قبل وارد کردن داده‌های جدید پاک کنید که چارچوب‌های موجوددراینترنت این مشکل رو برای شما حل کردن. تو این چارچوب‌ها برای نام مشتری متغیرهایی درنظر گرفته شده که به شما در نوشتن گزارش کمک می‌کنه و اینجوری گزارش شما طوری به مظر نمیرسه که از یه جایی کش رفتین و یا اطلاعات نامفهوم و مبهم که فراموش کردین پاک کنین مشتری رو به اشتباه نمیندازه.

STÖK: من باگ بانتی رو به چشم یک کار تمام وقت نمی‌بینم شخصا و ازنظر من این کار به سرگرمی شیرینه که باهاش میتونم شیطنت های خودم رو روی اخداف سخت خالی کنم و تاجاییکه احساس امنیت دارم به اطرافم سرک بکشم. یه جورایی برای من مثل دوییدن با وزنه‌اس، سخته ولی باعث رشم میشه. درمقایسه با تست نفوذ از خیلی جهات باعث قوی‌تر شدنم می‌شه. اما تفاوت خیلی بزرگی بین باگ بانتی و تست نفوذ وجودداره و اون اینه که من توی باگ بانتی میتونم از گزارش خیلی از باگ ها صرف‌نظر کنم که شما تو تست نفوذ نمیتونیداینکارو انجام بدین!

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

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

STÖK: این به این معنی نیست که اونها به این دسته از باگ ها اهمیتنمیدن. هیچ وقت قدرت یافته‌های جدید رو دست کم نگیرید. چراکه گفتن این جمله که آره دیگه از این کار نمی‌کنیم خیلی راحته ولیکن اینجوری نیست. مثلا الان IOT تازه پا گرفته و ما باید امنیت همه‌چیز رو دوباره از اول بررسی و تامین کنیم و فکر همه جاش رو باید بکنیم، چراکه همه با سرعت زیاد فقط دارن کارها رو انجام میدن و جلو میرن. همه چیز به سرعت درحال پیشرفته و این به این معنیه که مشکلات هم به همین سرعت درحال گسترش هستند.

JHADDIX: بچه‎‌ها آیا شما مطالبی که Shubs درمورد افشای 0-day خودش تو توییتر رسانه‌ای کرد رو دنبال کردین؟
Shubs یک فرد معروف و شناخته شده توی کامیونیتی باگ بانتی هست که الان برای assets کار میکنه، یادم نمیاد کدوم نرم‌افزار بود ولیکن اینا یه آسیب‌پذیری 0-day توی یه نرم‌افزاری پیدا کردن و گزارشش رو به صورت سراسری منتشر کردن، اونها گزارش رو علاوه بر صاحب نرم‌افزار به مشتریان مربوط به قسمت پولی نرم افزار هم فرستادن که افرادی زیادی از این قسمت داشتن استفاده می‌کردن. این آسیب پذیری کاملا مناسب بازی باگ بانتی بود. اونها آسیب‌پذیری رو گزارش دادن، خیلی‌ها به عنوان مشتری این نرم افزار اون رو قبول کردن، خیلی ها گفتن نه و این مشکلیه که باید توسط ارائه دهندگان بالادست نرم افزار حل بشه، اما این موضوع چند وروزی توی توییتر خیلی سروصدا کرد. جوری که مردوم بهشون حمله کردن و گفتن این کار خیلی ناجوانمردانه بود. من نظرم رو درمورد اینکار یعنی انتشار گزارش سراسری شرکت طرف حساب، توی کامنتهای رشته توییت چندبار نوشتم، اول از همه اینکه از بازیکن متنفر نباش، از بازی متنفر باش. این دقیقا رویه‌ای یه که باگ بانتی داره کار می‌کنه، آسیب‌پذیری ای که به هر شرکتی گزارش میشه و شرکتی که گزارش آسیب‌پذیری رو دریافت می‌کنه، اینجا مساله خطر مطرح میشه، اگر شرکتی انتخاب می‌کنه که نمی‌خواد خطرِ زمانیکه قراره صرف بشه تا ارائه دهندگان بالادست نرم افزار مشکل نرم افزار رو حل کنند رو قبول کنه، حتی زمانیکه دیگه آسیب‌پذیری افشا شده و اون بیرون همه ازش خبردار شدن یا حتی ممکنه بهش حمله شده و مورد بهره برداری قرار گرفته. شرکت این تصمیم رو گرفته، یعنی خودشون تصمیم گرفتن که پاداش این بانتی رو پرداخت کنن یانه. به نظر من تصمیم‌گیری برای شرکت دراین مواقع نباید به دست ارائه دهندگان بالا دستی سپرده بشه.
مثلاالان من یک کسب و کار دارم به اسم jhaddix.com و شما هم یک آسیب‌پذیری 0-day توی ووردپرس پیدا کردین و من شاید تصمیم خطرناکی بگیرم و بگم اطلاعات شخصیم اینجاست. اگر شما تونستین اینها رو اینجا پیداکنید، مسلما افراد دیگه‌ای هم می‌تونن پیداش کنن و من دوست ندارم که این تاخیر به وجودآمده بین من و زمان انتظار برای آپدیت وردپرس اطلاعات من رو به خطر بندازه. پس من بهت پول میدم تااین مشکل رو برام حل کنی، مثلا من اون رو داخل waff یا Hot patch قرار می‌دم. و خوشحالم که شما این خطا رو به من گزارش دادین. این نظر من بود، خوشحال میشم نظرات شمارم بشنوم.

KUGGO: من خودم بارها تو این شرایط قرار گرفتم و الان بازم درچنین شرایطی قرار دارم. ولیکن من الان باگ رو گزارش نمی‌کنم، چون دلم نمی‌خواد چنین شرایطی برام پیش بیاد و مشکل رو بخوام رسانه‎‌ای کنم. ولی خیلی دوست دارم و دلم میخواد گزارش این باگ رو ثبت کنم. آخرین باریکه این کارو انجام دادم زمانی بود که یک گزارش rce بود که به شما اجازه دسترسی مستقیم از اینترنت به یک ماشین IBM می‌داد. یه‌جورایی میشه گفت تو اینترنت درمعرض دید بود و توسط بانک‌ها مورداستفاده قرار گرفته بود. یک شرکت بزرگ بودیم و تقریبا با تک تک این بانک‌هایی که در سراسر دنیا وجود دارند درارتباط بودیم و ارتباط کاری داشتیم باهاشون و در قبال همشون مسئول بودیم. اما ما اول با IBM ارتباط برقرار کردیم و بهشون اخطار دادیم. این کاری بود که از دستمون برمی‌آمد، چراکه کانال‌های محرمانه‌ای داشتیم که ازشون کمک گرفتیم و IBM کار ما رو زیاد جدی نگرفت. ازنظر خودم کار درست رو انجام دادم، چراکه یک بسته instant root بود.

JHADDIX: آره به نظر منم کارت منطقی بود. چراکه هیچ کدوم ازاین بانکها دوست ندارن تا بایک خطر پنهان به مدت طولانی دست و پنجه نرم کنن. گاهی اوقات اصلاح آسیب‌پذیری‌های گزارش شده گاها بین 30 تا 60 و گاها تا 90 روز طول می‌کشه. مثلا پروژه zero day گوگل به شما اساسا 30 روز برای افشا فرصت می‌ده، برای تعمیم، وارسی کدها و رفع مشکل که گاها به اون راحتی که فکر می‌کنن نیست به زمانی بیشتر از این 30 روز نیاز دارند.

KUGGO: به نظر من چیزیکه اینجا مهمه اینه که اگر پروژه یه پروژه متن بازه، این مشکل به صورت کاملا متفاوتی حل میشه تا این که یک نرم افزار اختصاصی باشه، مثلا برنامه ای باشه که از یه قسمت برنامه بتونی بهش وصل بشی. اگر درحال همکاری با یک اکوسیستم متن باز هستی و داخل زبان اون یک باگ پیدا کردی (که من شخصا خیلی دوست دارم اینکارو انجام بدم)، برای اینکه بتونی اون رو در بهترین شرایط حل کنی باید با کامیونیتی همکاری کنی. این دلیل این کاریه که من الان دارم انجام می‌دم، باگ زبانی که من الان دارم روش کار می‌کنم، نمی‌تونم روی یک پروژه اون گزارش رو ثبت کنم، که البته اوایل قاصد داشتم این کارو انجام بدم و گزارش رو برای زبان ثبت کنم تا این مشکل از مرکز حل بشه.

STÖK: من از بازی کردن بدم نمیاد. نظرمن اینه که اگر یک گزارش و تحقیق رو تو دستت داری و امکان انجام دادن هرکاری رو داری، چند لحظه درموردش فکرکن، اینجوری بگم که تو داری توی اینترنت یک سری اطلاعات رو افشا می‌کنی که نباید افشاشون می‌کردی. چیزهایی مثل پورتال مدیریتی یا چیزی شبیه به این، به خودت مربوطه. بااینکه ما سوم شخص ولیکن حل کردن اون مشکل بایک راه‌حل برای تو خیلی آسونه. اگر اتفاقی توی سیستم بیفته که تو میتونی مشکلش رو رفع کنی، اختیار اینو داری تا باگ رو با چیزی عوض کنی و تو درعوضش بهره‌برداری از باگ رو انتخاب می‌کنی. مایکروسافت اون مشکل رو رفع می‌کنه، دوباره دور زده میشه، دوباره مشکل رو رفع می‌کنه و … . ماهم همین مشکل روداشتیم، به j یک گزارش ارسال کردیم، مشکل رو حل کردن، دوباره فرستادیم، دوباره حلش کردن، دوباره نیازمند تعمیر شد، اگر من جای شرکت بودم و هی یک نفر می‌گفت ما اینو پیدا کردیم که واقعا یک تحقیق بی‌مانندی بود که گزارشش رو برای سازنده‌ اش فرستادیم و گفتیم توسط این گزارش ما به شما داریم اخطار می‌دیم و گرنه این گزارش رو قراره برای 2 تا برنامه باگ بانتی ثبت کنیم. اینها مراحلی هستن که می‌تونید انجام بدین تا مشکلی براتون پیش‌نیاد. هدفم از انجام دادن اینکار این بود که بهشون بفهمونم که باید پاداش پرداخت کنن، مشکلت رو حل کن ولی پاداش رو هم باید پرداخت کنی. من مشکلی تو این کار نمی‌بینم، این حسن نیت من رو میرسونه، اگر کسی موضوع رو رسانه‌ای میکنه 2 تا دلیل میتونه داشته باشه یا از حسودی اینکارو کرده یا قاعده بازی رو بلد نبوده.

JHADDIX: به نظر من مقدار مبلغ پرداختی‌ای که برای یک باگ از برنامه های مختلف درمیاد یه چیزی حدود 100 هزار دلاره، یه جاهایی مبلغی بیشتر از این مقدار میدن. اگر درمورد این فکر کنیم که 100 هزار دلار کافی نیست و خیلی کمتر از ارزش اون باگه، دارک وب میاد وسط. دارک وب رو همه مون می‌شناسیم، منظور من دارک وب واقعیه، جاییکه پول خوبی در ازای اطلاعات میدن.

STÖK: یه چیز خراب تو اینترنت گذاشتی، برای درست شدنش یا پولت می‌ره یا آبروت. اما از راه درستش بهشون اخطار می‌دیم. این مشکل شماست که بهتون داریم اخطار می‌دیم، مثلا باید این مقدار پول پرداخت کنید و اینم راه‌حل مشکلتونه.

JHADDIX: درسته، بهتره بهشون بگیم ما اخیرا متوجه شدیم که شما بااین مشکل روبه روهستین، ما به شما این فرصت رو می‌دیم تا ازش مطلع بشید، این یک مشکل جدیه و بعد منتظر می‌مونیم تا مشتری برای رفع مشکل بیاد سراغمون. مایه سیسات کاری داریم که می‌گه 0-day ها تا 30 روز چیزی پرداخت نمی‌کنیم. همچنین من شرکت‌هایی رو می‌شناسم و پشت بسیاری از بانتی‌هایی بودم که حتی از قوانین خودشون پیروی نمی‌کردند. مثلا این قانون 30 روزه رو دارن، اما زمانیکه شما براشون یه گزارش 0-day شبکه از راه دور می‌فرستید، مثل پکیجی که کریستوفر درموردش صحبت کرد، اونام میگن درحالت عادی ما 0-day ها رو تحت پوشش قرار نمی‌دیم، ولیکن چون این گزارشی که شما فرستادید خیلی خطرناکه، ما تصمیم گرفتیم تا پاداشی رو برای شما درنظر بگیریم.

STÖK: این تناقض خوبیه، اگر بلد باشی ارتباط برقرار کنی و نشون بدی نگران مشتری هستی نتیجه خوبی میتونه داشته باشه. مثلا بگین که امتیاز CBS اش چقدره و جوری که میدونید درسته پیام رو برای مشتری بفرستید، رهاش کنید و برید سراغ گزینه بعدی.

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

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

KUGGO:یک نفر سوال پرسیده که آیا منبع به روز روزانه‌ای درزمینه تکنولوژیوجود داره که معرفی کنید تا در تحقیقاتمون ازشون استفاده کنیم؟
نظر من اینه که من شخصا با ارتباط برقرار کردن با شما متوجه میشم که روزانه درحال ازدست دادن چه حجم از اطلاعات جدید هستم.

JHADDIX: آره منم باهات موافقم، وقتی بایک تیم داری کار می‌کنم، هم تیمی هام کمکم می‌کنن تا ضعفهام رو بهتر بشناسم

STÖK: بچه ها جواب من به این سوال /netsec تو reddit هست، جاییکه میتونی اطلاعات به روز رو ببینی و هم چنین حساب توییتری infosec

JHADDIX: منم روزنامه های اینترنتی secureb ، intigrities bug bite رو پیشنهاد می‌کنم، که اتفاقاتی که درطول هفته توی باگ بانتی اتفاق میفته رو تحت پوشش قرار میدن

STÖK: و اینکه وقتتون رو توی لینکدین برای پیدا کردن اطلاعات به روز هدر ندین، چون اونجا برای بازاریابیه!

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *