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

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

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

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

_ چه نقطه‌ای از سامانه‌ها پاتوق شماست؟ به چه نقطه‌ای از سامانه‌ها بیش‌تر از سایر نقاط علاقه داری، بیش‌تر به آن سر می‌زنی و به دنبال آسیب پذیری‌هایش می‌گردی؟

مهدی مرادلو:

بیش‌تر گزارش‌های من مربوط به آسیب پذیری های درگاه‌های پرداخت بوده. اغلب هم آسیب پذیری Race Condition بوده‌اند. چون سامانه‌های میدان‌ها و اهداف متفاوت بودند، حملات و شیوه‌هایشان هم متنوع بودند. برای یک حمله، هوش و ابتکار بیش‌تری لازم بوده برای بعضی هم این‌طور نبود. مثلا آسیب پذیری‌ای که برای شاتل ثبت شده، با آسیب پذیری‌ای که برای مدیانا ثبت کرده‌ام، فرق می‌کرد. من قبل از این‌که سامانه‌ی هدف را باز کنم، با خودم فکر می‌کنم که "این سامانه، باتوجه به نوع کسب‌وکار و نوع سامانه‌اش، چه آسیب پذیری‌هایی ممکن است داشته باشد؟" این سوال خیلی مهم است. وقتی جوابی برای این سوال داشته باشم، قطعا راحت‌تر می‌توانم آسیب پذیری را پیدا و گزارش کنم. مثلا روی سامانه‌ای مثل نماوا، با خودم فکر کنم که یکی از آسیب پذیری های منطقی‌ای که ممکن است وجود داشته باشد، این است که ویدئو منتشرشده باشد و تو مثلا با Status بیایی و در UI جلویش را بگیری که نگذاری نمایش دهد. در Response سرور هم جواب را داشته باشی. این آسیب پذیری الان در نماوا وجود ندارد. ولی به‌طور کلی از نوع آسیب پذیری هایی ست که ممکن است در یک سامانه مثل نماوا وجود داشه باشد. از این ممکن‌ها خیلی هست، وقتی از نوع کسب‌وکار و سامانه شناخت داشته باشی و منطقش (Logic) دستت آمده باشد، این ممکن‌ها را که کنارهم بچینی، دستت برای شکار آسیب پذیری، بازتر است.

یکی از مسئله‌های مهمی که به نظرم این هست که در کمپین‌ها روی امنیت لندینگ پیج‌ها زیاد کار نمی‌شود. لندینگ پیج‌هایی که مثلا برای کمپین‌های نوروز یا شب یلدا می‌گذارند را من می‌توانم بگویم که، به احتمال بالای ۹۰٪ آسیب پذیری روی آن‌ها وجود دارد! چون برنامه‌نویس باید سریع هندل کند؛ در تایم کوتاهی قرار است کدش را بنویسد، deploy کند و بالا بیاورد! این سرعتی که معمولا در فرآیند اجرا پیش می‌آید، و این‌که تایم کوتاهی هم قرار است مورد استفاده قرار بگیرند، باعث می‌شود که حساسیت‌های امنیتی لازم در آن‌ها رعایت نشود و اکثرا آسیب‌پذیر باشند.

مثلا من وقتی می‌خواهم رو هدفی کار کنم، گاهی می‌روم و کمپین‌های قدیمی‌شان را چک می‌کنم تا ببینم آسیب پذیری‌ای وجود دارد که به من دسترسی بدهد؟ یادم است که یک بار آسیب‌پذیری‌ Account Takeoverی گزارش کردم که مربوط به همین کمپین‌ها می‌شد. یادم است که از داخل کمپین‌ها که می‌رفتی و توکنی که بهت می‌داد روی سایت اصلی هم کار می‌کرد. در واقع مشکلی که وجود داشت این بود که در کمپین یک کد چهاررقمی وجود داشت که نسبت به Rate Limit هم آسیب‌‌پذیر بود و می‌توانستی توکن را به دست بیاوری.

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

پیشنهاد خواندنی: گپ‌وگفتی با پردرآمدترین شکارچی راورو در سال ۱۴۰۰؛ مهدی مرادلو (moradlooo)

آرمان محمدتاش:

علاقه‌ی شدیدی به فرم‌های هر سایتی دارم. برایم بخش جذاب هر وبسایتی محسوب می‌شود.

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

یکی از گزارش هایم که یک‌جورهایی Port Injection محسوب می‌شد، این طور آغاز شد که نمی‌دانستم سامانه آسیب پذیری دارد یا نه. گفتم از این Function باید آسیب پذیری پیدا کنم و آن‌قدر کار کردم که به آسیب پذیری رسید. من سناریو آسیب پذیری Dangling Markup را به ۱۰ نفر گفتم و ۹ نفرشان اصلا نمی‌دانستند! کلا آسیب پذیری‌ای هست که کم به آن اشاره شده است. من داشتم این آسیب پذیری را آن‌جا می زدم. یکی از دلایلی که من توانستم آسیب پذیری Port Injection‌ و Host-header Injection را بگذارم همین بوده است که من خواستم اول این را بزنم. بعد دیدم این را نمی‌شود زد، گفتم اگر نمی‌توانم تزریق کنم، بگذار ببینم می‌توانم Open Redirect کنم یا نه؟ گفتم خب بگذار این را تست کنم. تست کردم و دیدم که جواب داد و سناریویی بود که من فقط توانستم در پن‌تستی که می‌زنم، در شرکت دیگری آن را پیاده‌اش کنم.

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

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی جوان راورو؛ آرمان محمدتاش (Arman_Security)

علیرضا رضایی:

اپلیکیشن اندرویدی داستانش با سایت‌ ها کمی فرق می‌کند. اپلیکیشن‌هایی که معمولا کار می‌کنم، یک سری مکانیزم امنیتی دارند که ۴، ۵ مورد هستند. مثلا؛ Root Detection ، frida Detection و چندتا از این کیشن‌های دیگر... . من اول این موارد را چک می‌کنم. کار زیاد سختی نیست. بعد از این‌که این‌ها را انجام دادم، مثلا می‌روم سراغ API هایشان که بتوانم API هایشان را پیدا کنم. معمولا این‌که بروم سراغ آن کار هم داستان خودش را دارد.

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

محمدحسین آشفته یزدی:

قسمت‌های موردعلاقه‌ی من در سامانه‌ها، مربوط به Authorization (کنترل سطح دسترسی) است. خیلی از باگ‌ها آن‌جا به وجود می‌آیند. اگر بخواهم کلاس حملات را بگویم، کلاس حملات Broken Access Control را خیلی دوست دارم. انتخاب اولم این نوع حملات است. بیش‌تر به سراغ آن‌ها می‌روم و بعدش به سراغ حملات فنی‌ای مثل XSS و ... .

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی؛ محمدحسین آشفته‌یزدی (sec_zone64)

بهراد احمدپور:

من معمولا به سراغ صفحه‌ی لاگین سایت‌ها می‌روم. البته که خب اول به دنبال این می‌گردم که" آیا صفحه‌ی لاگینی دارد؟" . در صفحه‌ی لاگین‌ معمولا به دنبال آسیب‌پذیری می‌گردم. مثلا؛ اگر سیستم پیامکی داشته باشند، سیستم پیامکی‌شان را بررسی می‌کنم. یا مثلا در فرآیند لاگین، اگر OAuthشان بخواهد با گوگل باشد، آن را بررسی می‌کنم. معمولا به دنبال این‌جورچیزها می‌گردم. باگ‌هایی هم که تابه‌حال پیدا کرده‌ام، معمولا User Account Takeover بوده. درواقع جریان از این قرار می‌شود که مثلا مهاجم اگر شماره‌ی یک کاربر را داشته باشد، با شماره تماس آن کاربر می‌تواند به‌جایش در سامانه لاگین کند. یعنی دیگر نیازی به رمز عبورش (چه رمز‌عبور ثابت باشد، چه از این رمز‌عبورهایی که برای گوشی کاربر پیامک می‌شود) ، ندارد. معمولا هم با سناریوی یک Race Condition، که درواقع یک اجراکردن یک کدی است که می‌آید حالت ‌Brute Force همه‌ی آن کدها را امتحان می‌کند و خب سامانه درواقع محدودیتی ایجاد نمی‌کند. این سناریو‌ی محبوبم است. زیاد هم از همین سناریو باگ زده‌ام. در سامانه‌های در سطح یک‌ذره پایین‌تر، این باگ رایجی ست که همیشه بوده. ولی معمولا سازمان‌هایی که یک‌ذره سطحشان بالاتر است، یک‌سری ابزارهای دفاعی دربرابرش دارندکه در این‌جور موارد باید خلاقیت به خرج داد، سناریو را عوض کرد و ... .

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی جوان راورو؛ بهراد احمدپور (behrad_amp)

امیر پیامنی:

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

پیشنهاد خواندنی: گپ‌وگفتی با شکارچی راورو؛ امیر پیامنی (amirpayamani)

رضا شریف‌زاده:

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

اگر هم سامانه وب‌سرویس نداشته باشد، بخش جذاب برای من بحث Authentication است. بحث‌هایی مثل لاگین، ثبت‌نام، Reset Password و امثال آن‌ها. تجربه‌ی من هم در این مدت ثابت کرده است که حتی در جاهای بزرگ هم، در این مواردی که نام بردم، سوتی وجود دارد و ممکن است از این نقاط خیلی آسیب‌پذیر باشند.

بگذارید درباره‌ی آسیب پذیر بودن سامانه‌ی کسب‌وکارهای بزرگ از نقاطی که گفتم مثال بزنم یک خاطره بگویم: یکی از شرکت‌های خیلی بزرگ یک بخش Reset Password داشت که OTP Code را پیامک می‌کرد. با SMS Bombing می‌توانستیم درخواست آن را بدهیم که OTP Code به تعداد زیادی ارسال شود. این‌گونه کاربر درگیر حمله‌ی SMS Bombing می‌شد. باگ این کار چه بود؟ OTP Code هایی که برای کاربر ارسال می‌شد، مقادیر مختلفی داشت و همه‌ی آن مقادیر Valid بود. خیلی سناریو جالب شد دیگر!! یعنی مثلا یک OTP Code پنج رقمی، اگر هزارتا OTP Code برایش Generate (تولید) می‌شد، احتمال پیدا‌کردن آن یک به صد می‌شد. اگر بخواهم ساده‌تر بگویم، وقتی شما یک OTP Code پنج رقمی داشته باشید و یک کد برایتان Generate شود، احتمال این‌که با Brute Force به آن برسید، یک بر روی ده به توان پنج است. ولی اگر بتوانید هزارتا OTP Code را Generate کنید و هزارتایش Valid باشد، احتمال این‌که به OTP Code کاربر برسید، ده به توان سه بر روی ده به توان پنج است. از نظر ریاضیات تقریبا بعد از صد بار تلاش برای پیداکردن OTP Code کاربر، می‌شد OTP Code را پیدا کرد. بعد از پیداکردن هم آن را قرار داد و پسورد را از طرف کاربر Reset کرد.

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

سخن آخر:

نقطه‌ی موردعلاقه‌ی شما برای شکار در سامانه‌ها کجاست؟ به چه نقاطی بیش‌تر از سایر نقاط سر می‌زنید؟

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

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

تعریف هک از نگاه هکرها

برخی از مصائب و چالش‌های هکر بودن

کافه روز صفر۱

کافه روز صفر ۲؛ شکارگاه