چالش ۳۰ روزه هانت:‌ شماره ۱

دسامبر ۲۰۲۴ - فوریه ۲۰۲۵

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

پیش از شروع، توجه داشته باشید که در این مدت تقریباً ۶۰ ساعت وقت صرف کردم و ۵ باگ پیدا کردم (۲ مورد duplicate و ۳ مورد informative).

---

روزهای ۱ تا ۳: ایجاد زیرساخت‌های اولیه

۲۰ تا ۲۲ دسامبر ۲۰۲۴

ایجاد حساب کاربری و تعیین دامنه فعالیت:

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

بررسی اولیه:

مانند یک کاربر عادی، عملکرد برنامه را بررسی کردم. Burp Suite را با تنظیمات مناسب (افزونه‌های لازم، تنظیمات SSL و محدودسازی دامنه) پیکربندی کردم تا ترافیک را رهگیری و نقشه برنامه را ترسیم کنم. همچنین، دامنه‌ها و زیر‌دامنه‌های تحت پوشش را جمع‌آوری کردم که بخش مهمی از فرآیند شناسایی است.

یافته‌های اولیه:

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

---

روزهای ۴ تا ۱۰: شناسایی عمیق و ترسیم نقشه برنامه

۲۳ تا ۳۰ دسامبر ۲۰۲۴

استراتژی‌های گسترده شناسایی:

تمرکزم را روی شناسایی عمیق‌تر گذاشتم. با استفاده از ابزارهایی مانند crt.sh، subfinder، dnsx و httpx، فرآیند کشف خودکار زیر‌دامنه‌ها، تحلیل نام دامنه و شناسایی سرویس‌ها را انجام دادم. به عنوان مثال، از یک تابع bash برای استخراج اطلاعات دامنه از crt.sh استفاده کردم:

ترسیم نقشه و تحلیل مسیرها:

برای درک بهتر ساختار برنامه، یک نقشه ذهنی (با استفاده از ابزارهایی مانند XMind) از جریان ورود به سیستم و مدیریت توکن‌های JWT تهیه کردم. این روش هنگام آزمایش مکانیزم‌های احراز هویت بسیار مفید بود، به ویژه زمانی که از ابزارهای JWT و hashcat برای آزمون رمزهای رایج استفاده کردم (اگرچه نتیجه‌ای نداشت، اما تجربه ارزشمندی بود).

تحلیل بایگانی‌های وب و فازینگ:

با استفاده از WaybackURLs به داده‌های تاریخی دسترسی پیدا کردم تا نقاط پایانی مخفی را کشف کنم. یک یافته جالب، یک endpoint حاوی یک UUID بود که به‌طور ناخواسته اطلاعات حساس یک سازمان را فاش می‌کرد، که نمونه‌ای کلاسیک از افشای اطلاعات است.

---

روزهای ۱۱ تا ۱۵: بهینه‌سازی روش‌ها و مقابله با چالش‌ها

۳۱ دسامبر ۲۰۲۴ تا ۶ ژانویه ۲۰۲۵

تحلیل robots.txt و گوگل دورکینگ:

با استفاده از تکنیک‌های Google Dorking، Bing Dorking و حتی GitHub Dorking تلاش کردم سرنخ‌های بیشتری درباره اکوسیستم هدف پیدا کنم. همچنین با استفاده از robofinder مسیرهای پنهان در فایل robots.txt را استخراج کردم، به امید کشف دارایی‌های مهم.

فرسودگی ذهنی و بازیابی انرژی:

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

گزارش‌دهی اولیه باگ‌ها:

پس از ۱۵ روز، حدود ۱۷ ساعت کار مفید داشتم و ۳ باگ پیدا کردم. در این مرحله، وقفه‌ای گرفتم تا روند کارم را ارزیابی کنم و برنامه‌ای برای گسترش سطح حمله تنظیم کنم.

---

روزهای ۱۶ تا ۲۰: گسترش سطح حمله

۷ تا ۱۵ ژانویه ۲۰۲۵

کشف دارایی‌های جدید و شناسایی سرویس‌ها:

با یافتن یک برنامه جدید، دامنه فعالیت را مجدداً مشخص کرده و فرآیند شناسایی را انجام دادم:

• کشف زیر‌دامنه‌ها
• تحلیل DNS
• شناسایی سرویس‌ها

ابزارهایی مانند Shodan و Naabu در این مرحله بسیار مفید بودند. به عنوان مثال، از این تابع bash برای دریافت اطلاعات از Shodan استفاده کردم:

آزمایش API و منطق تجاری:

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

---

روزهای ۲۹ تا ۳۰: تغییر پلتفرم و جمع‌بندی

۱۰ تا ۱۱ فوریه ۲۰۲۵

انتقال پلتفرم:

در روز ۲۹، از HackerOne به BugCrowd مهاجرت کردم. این تغییر نیازمند بررسی دقیق قوانین و دامنه مجاز برنامه‌های جدید بود.

کاوش‌های پایانی:

در روز آخر، روی endpointهای حساس مانند login API و مشکلات مربوط به parameter pollution تمرکز کردم. یک کشف جالب، آسیب‌پذیری open redirect بود که به Referer header خاصی وابسته بود. هرچند این آسیب‌پذیری به‌طور کامل قابل بهره‌برداری نبود، اما نشان داد که حتی endpointهای کم‌اهمیت نیز می‌توانند مشکلات امنیتی داشته باشند.

جمع‌بندی و گام‌های بعدی:

پس از حدود ۴۰ روز شکار باگ، چالش را با جمع‌بندی کارها به پایان رساندم. هرچند همه آسیب‌پذیری‌ها حیاتی نبودند، اما یادگیری مداوم، پایداری و بهبود تدریجی روش‌ها، ارزشمندترین دستاوردهای این تجربه بودند. اکنون در حال آماده‌سازی برای چالش ۳۰ روزه بعدی هستم!

---

درس‌هایی که آموختم:

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

ممنون که این سفر ۳۰ روزه را دنبال کردید. تا چالش بعدی—شکار موفقی داشته باشید و ایمن بمانید! ضمنا این پست رو به زبان انگلیسی اینجا میتونید مطالعه کنید.