Forwarded from Ali Mojaver | علی مجاور
📌 نکات باگ بانتی: 🐛🔐 دسترسی به منابع مهم با دور زدن تأیید ایمیل
اگه روی هدفی کار می‌کنی که تأیید ایمیل نقش حیاتی داره، تصور کن بتونی وارد دامنه‌ای مثل example[.]com بشی؛ این ممکنه بهت اجازه بده وارد محیط کاری قربانی بشی و به اسناد یا محتوای مرتبط با اون دامنه سفیدشده دسترسی پیدا کنی.
معمولاً باگ‌های دور زدن تأیید ایمیل، بدون نشون دادن اثر واقعی گزارش می‌شن یا به‌عنوان پیش‌نیاز تصاحب اکانت (ATO). به همین خاطر، اغلب این ریپورت‌ها با برچسب "Informative" رد می‌شن.
🔍 روش من برای نشون دادن اثر واقعی چنین باگ‌هایی:
🔸 شناسایی قابلیت‌هایی که به دامنه ایمیل وابسته‌ان:
مثلاً اپلیکیشنی که دسترسی به منابع یا جوین شدن به تیم/محیط کاری رو فقط برای کسانی فراهم می‌کنه که ایمیلشون با دامنه خاصی مطابقت داره (مثل sample@victimsitexyz[.]com). یا اپ‌هایی که دسترسی به داکیومنت یا ویدیوها رو فقط برای ایمیل‌هایی از دامنه whitelisted می‌دن.
✅ ترفند ساده برای دور زدن تأیید ایمیل و تصاحب ایمیل ثبت‌نشده از هر دامنه:
1️⃣ وارد اکانت خودت شو و ایمیلت رو به یه ایمیل تحت کنترل خودت تغییر بده (مثلاً attackeremail@attackerdomain.com)
2️⃣ ایمیل تأیید برای اون آدرس ارسال می‌شه (فعلاً تأییدش نکن)
3️⃣ حالا ایمیلت رو به یه آدرس ثبت‌نشده از دامنه هدف تغییر بده (مثلاً victimemail@victimdomain.com)
4️⃣ لینک تأیید جدیدی به victimemail@victimdomain.com ارسال می‌شه (که بهش دسترسی نداری)
5️⃣ حالا سعی کن روی لینک تأیید ایمیل قبلی که برای attackeremail@attackerdomain.com اومده کلیک کنی — اگه سیستم لینک قبلی رو باطل نکرده باشه، ممکنه این لینک ایمیل جدید یعنی victimemail@victimdomain.com رو تأیید کنه!
اگه موفق شدی ایمیلی از یه دامنه سازمانی رو به‌عنوان تأییدشده claim کنی، حالا دنبال فیچرهایی بگرد که وابسته به اون ایمیل باشن تا اثر باگ رو نشون بدی و یه باگ بانتی عالی بگیری! 💰🔥
🎯 نتیجه‌گیری:
هیچ‌وقت دور زدن تأیید ایمیل رو بدون نشون دادن اثر واقعی گزارش نکن. اپ‌هایی که نقش‌ها و سطوح مختلفی تو سازمان/محیط کاری دارن، به دامنه ایمیل وابسته‌ان و بستر مناسبی برای اثبات اثر امنیتی این باگ هستن. 💡🛡️
#ریکان #js
@MojaV3r | چنل هک و امنیت
اگه روی هدفی کار می‌کنی که تأیید ایمیل نقش حیاتی داره، تصور کن بتونی وارد دامنه‌ای مثل example[.]com بشی؛ این ممکنه بهت اجازه بده وارد محیط کاری قربانی بشی و به اسناد یا محتوای مرتبط با اون دامنه سفیدشده دسترسی پیدا کنی.
معمولاً باگ‌های دور زدن تأیید ایمیل، بدون نشون دادن اثر واقعی گزارش می‌شن یا به‌عنوان پیش‌نیاز تصاحب اکانت (ATO). به همین خاطر، اغلب این ریپورت‌ها با برچسب "Informative" رد می‌شن.
🔍 روش من برای نشون دادن اثر واقعی چنین باگ‌هایی:
🔸 شناسایی قابلیت‌هایی که به دامنه ایمیل وابسته‌ان:
مثلاً اپلیکیشنی که دسترسی به منابع یا جوین شدن به تیم/محیط کاری رو فقط برای کسانی فراهم می‌کنه که ایمیلشون با دامنه خاصی مطابقت داره (مثل sample@victimsitexyz[.]com). یا اپ‌هایی که دسترسی به داکیومنت یا ویدیوها رو فقط برای ایمیل‌هایی از دامنه whitelisted می‌دن.
✅ ترفند ساده برای دور زدن تأیید ایمیل و تصاحب ایمیل ثبت‌نشده از هر دامنه:
1️⃣ وارد اکانت خودت شو و ایمیلت رو به یه ایمیل تحت کنترل خودت تغییر بده (مثلاً attackeremail@attackerdomain.com)
2️⃣ ایمیل تأیید برای اون آدرس ارسال می‌شه (فعلاً تأییدش نکن)
3️⃣ حالا ایمیلت رو به یه آدرس ثبت‌نشده از دامنه هدف تغییر بده (مثلاً victimemail@victimdomain.com)
4️⃣ لینک تأیید جدیدی به victimemail@victimdomain.com ارسال می‌شه (که بهش دسترسی نداری)
5️⃣ حالا سعی کن روی لینک تأیید ایمیل قبلی که برای attackeremail@attackerdomain.com اومده کلیک کنی — اگه سیستم لینک قبلی رو باطل نکرده باشه، ممکنه این لینک ایمیل جدید یعنی victimemail@victimdomain.com رو تأیید کنه!
اگه موفق شدی ایمیلی از یه دامنه سازمانی رو به‌عنوان تأییدشده claim کنی، حالا دنبال فیچرهایی بگرد که وابسته به اون ایمیل باشن تا اثر باگ رو نشون بدی و یه باگ بانتی عالی بگیری! 💰🔥
🎯 نتیجه‌گیری:
هیچ‌وقت دور زدن تأیید ایمیل رو بدون نشون دادن اثر واقعی گزارش نکن. اپ‌هایی که نقش‌ها و سطوح مختلفی تو سازمان/محیط کاری دارن، به دامنه ایمیل وابسته‌ان و بستر مناسبی برای اثبات اثر امنیتی این باگ هستن. 💡🛡️
#ریکان #js
@MojaV3r | چنل هک و امنیت
❤13