Dagen | Security

Broken Acesss Controll

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

Channel : @criticalthinking_persian

Broken Acesss Controll

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

Channel : @criticalthinking_persian

به ۱۱۰۰ تا رفیق رسیدیم، مگه میشه یه تخفیف خوب نزاریم؟ 🔥 از همین حالا تا فردا شب ساعت 8، 40٪ تخفیف روی تک‌به‌تک کتاب‌های ترجمه‌شده وقت شکار کتاب‌هاست برای اعمال تخفیف، کتاب مورد نظرتون رو به همراه کد All%40 رو به پشتیبان ارسال کنید 👇 ID : @Typhonx01 خانواده بوک‌مایند هر روز بزرگتر از دیروز ❤️‍🔥 Channel : @Sec_Book_Mind

⭕️ هک چت بات ها از طریق پرامت انجیکشن (Prompt injection)

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

Channel : @Sec_Book_Mind

📌 موقع یاد گرفتن و دوره دیدن شکار باگ به نظر آسون میاد.. اما وقتی وارد دنیای واقعی میشی، می‌بینی پروژه‌های بزرگ و باگ‌های بحرانی به راحتی و با ابزار ها پیدا نمیشن. هکر های خفن کارهایی رو بلدن که توی هیچ دوره عمومی تدریس نمیشه. اگه دنبال یه مسیر کلیشه ای و خسته کننده نیستین. بریم سراغ این ۵ کتاب (که توسط ما فارسی شده ) چون این کتاب ها ذهنیتتون رو نسبت به امنیت زیر و رو می‌کنه شماره ۱ - کتاب Black Hat GraphQL :

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

شماره ۲ - کتاب Practical Social Engineering:

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

شماره ۳ - کتاب Exploring The Dark web :

همه ادعا می‌کنن دارک وب رو می‌شناسن، اما این کتاب نوشته یه هکر سابقه که توی دارک وب فعالیت داشته و تجربشو توی این کتاب نوشته اگه میخوای دارک وب رو یاد بگیری خواندنش واجبه

شماره ۴ - کتاب Javascript For Hackers :

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

. شماره ۵ - کتاب The israel Mosad Training Manual:

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

سرفصل‌ها و چند صفحه نمونه از این ۵ شاهکار توی کانال آماده‌ست تا راحت‌تر اولویت‌بندی کنید. پیشنهاد می‌کنم حتماً یه نگاه بهشون بندازید ارادت ❤️‍🔥 Channel : @Sec_Book_Mind

چجوری با دستکاری لاگین تایپ(LoginType) 2factor رو دور زدم و اکانت تیک اور کردم سناریو این پست به تایتل پست قبلی گره خورده اگه پست قبلیو خونده باشید میدونید که ما اینجا یه پکت داریم که یه درخواست میزنه به این ای پی آی

api/authentication/sign-in

جدای از این که خیلی تست روی پارامتر otp این پکت زدم که بعضی از پیلود های json پارس نمیشد و پکت رو خراب میکرد پارامتری که من باهاش کار دارم یه پارامتره که من بهش ورودی دادم من یه لاگین تایپ دارم که از بین دو تا پروایدر انتخابش کردم sms و email

{
  "LoginType": "email",
  "password": "mypass",
  "user": "dagen@gmail.com",
  "session": "randommmmmmmmmmmmmmmmmm",
  "locale": "en_us"
}

همونطور که میبینید من توی ریکوست قبلی ایمیل رو انتخاب کردم و یه ریکوست قبل ترش یه ایمیل خودم و شماره موبایلمو داده بودم به سایت سوالی که مغزم منو میخورد این بود چی میشه اگه لاگین تایپ رو توی همین ریکوست فعلی نفرستم؟ یا خالی بفرستمش و برم مرحله بعدی ؟ یکم فکر کنید , سایت چه واکنشی نشون میده ؟ یه سری فرض ها با خودمون میکنیم . یعنی میشه اگه من اینو نفرستم به کل 2fa بره کنار و من وارد اکانت بشم ؟ حالا وقته عمل چن تا تست محدود توی ذهن من باید اجرایی بشه بیاین بریم رو ریپیتر یه بار میام پارامتر LoginType رو آش با جاش ور میدارم چون ممکنه اون سمت سرور این نفرستادنه به سرور یه null برگردونه در خواست رو send میکنم —> fail شد چرا ؟ چون منو ریدارکت میکرد همون ریکسوتی که که میگفت پرووایدر انتخاب کن پس این تست بدرد من نخورد تست بعدی مقدار ایمیل رو بر میدارم هیچی میفرستم به این حالت : "LoginType": "" نوبت اینه send رو بزنم وقتی ریسپانس رو دیدم یه successful داد ولی تو خالی بود و پیش فرض کد تایید رو به شمارم اس ام اس میکرد :) این هم fail شد و نتیجه ای برام نداشت . میرسیم به تست اخر این همون تست طلاییس که میخوامش و میشه مغز اسیپ پذیری که اشتباه یه برنامه نویس رو اشکار میکنه و پستو باهاش تموم میکنم اگه این مقدارا سمت فرانت‌اند تعریف شدن پیش خودم اومدم فکر کردم چرا نرم این پارامتر(LoginType) رو توی dom سرچ کنم ؟ سرچ کردم همچین چیزی جلوی چشای منه —>

export enum LOGIN_TYPE {
    EMAIL : "email"
    PHONE : "phone"
    NONE : "none"
}

میشه به من بگی اون none چیه ؟ مگه ما داشتیم همچین چیزی ؟ چه تستی کنم ؟ یه راه برای فهمیدنش وجود داره میام توی پارمتر لاگین تایپ میزارمش :

"LoginType": "none"

تمام . باگ دوم برای منه 2fa رفت کنار و من کافی بود هر ایمیلی که دوست دارم رو بدون تایید برم توش حدس و احتمال پشت صحنه سمت سرور این مقدار یه مقدار معتبره , اشتباه فاجعه بار یه برنامه نویس که احتمالا در حال تست این سایت بوده یا یادش رفته بوده نمیتونم با قطعیت بگم دلیلش چیه ولی احتمال میدم ممکنه برنامه نویس سایت برای لاگین کردنش توی محیط تست خودشو به زحمت نمیندازه تا بره ایمیل و اس ام اسش رو چک کنه و میاد یه پروایدر تستی برام خودش میسازه تا سریع لاگین کنه . یه همچین چیزی احتمال داره و ما به عنوان اتکر اومدیم این فرصت رو به نفع خودمون تغیر دادیم و یه گزارش ولید رو به ثبت رسوندیم امیدوارم نهایت درک رو از این سناریو گرفته باشید 🌷 پر قدرت بریم سر وقت باگای بیشتر...

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

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

ترجمه فارسی کتاب Iran Cyber Threats رو خوندم و عجیب و غریب به دل نشست ، کتاب کار درست و سنگینیه. با بچها صحبت کردم قرار شد این کتاب رو کاملا رایگان بزارن توی @sec_book_Mind تا همه ازش بهره مند بشن. شرایط سختیه من واقعا درک میکنم بعضیا از ته دل دوست دارن ترجمه این کتاب رو بخونن و به هر دلیلی نمیتونن. ترجمه کتاب همین امروز توی چنل SecBookMind قرار داده میشه تنها چیزی که ازتون می‌خوایم اینه که حمایتی کنید که کار بچها دیده بشه چون دارن انرژی و زمان زیادی صرف میکنن و طبیعتاً نیاز به بازخورد دارن همین. منتظرش باشید 🔥

سری پادکست های کانال یوتیوب Critical Thinking Bug bounty Padcast بزودی فارسی میشه و بدون هیچ منتی در اختیارتون قرار میگیره ♥️ لینک کانال بزودی همینجا گذاشته میشه.

زرنگ اونیه که روی هر لاگین پیجی این تریک رو تست کنه! من خودم این بای‌پاس رو اختراع نکردم؛ من فقط تجربه هانترهای مختلف رو یاد می‌گیرم. راستش، تجربه تاپ ها برای من میشه اعتمادبه‌نفس و بهم امید ادامه دادن میده. وقتی ناامید باشی، ذهن قفل میکنه و نمی‌تونی باگ بزنی باگ زدن زوری نیست! باید با حال خوب و ذهن باز تارگتت رو باز کنی. بهت قول میدم اگه حالت خوب باشه و هوشیار باشی، کار تمومه. نباید به خودت سخت بگیری؛ توی این مسیر باید خاک خورد. ارزشِ واقعی همیشه به سختی لینک میشه. ماموریت تو اینه که از دل سناریوهای مختلف، باگ بکشی بیرون. باگ نخورد؟ فدای سرت برو تارگت بعدی. ولی اگه ناامید بشی، بازی رو باختی. قبول کن که یه روز بالایی و یه روز پایین، ولی باید برای نتیجه تلاش کنی. در نهایت، رضایت واقعی از دیدن نتیجه میاد، مگه نه؟ یه نکته مهم : توی این پست اشاره به یه لاگین تایپ اشاره کردیم ولی چون مرتبط نبود با تایتل اصلی پستمون، راحت ازش رد شدیم اونجا هم یه باگ تپل خورد تا پست بعدی یکم بهش فکر کنید و سناریو های مختلف که باگ میشه رو توی ذهنتون برای لاگین تایپ تداعی کنین اول باید برسی کنم چقدر مشتاق داریم انرژی هست تا تا یه سناریو دیگه رو با هم برسی کنیم ؟ @Dagen_security

در واقع من می‌تونستم هر ایمیلی که دلم می‌خواد رو با استفاده از این بایپس Account Takeover کنم! داستان فنی پشت صحنه چیه؟ دلیل این باگ این بود که سرور روی تعداد ورودی‌های داخل آرایه لیمیتی اعمال نکرده بود (Rate Limiting روی درخواست بود نه اعضای آرایه)، و اینکه سمت دیتابیس یا کد سرور، به جای مقایسه کردن دقیق و تک‌به‌تک کدها، فقط چک می‌کرد که آیا «حداقل یکی» از این کدها درسته یا نه ! همین تست به ظاهر ساده باعث شد کلی آدم این باگ رو میس Miss بدن و من گزارشش بدم. امیدوارم که ساده از این سناریوی ریل‌ورد رد نشید و حتماً حتماً توی تست‌کیس‌هاتون بذاریدش. ممنون که وقت و انرژی گذاشتید 🌷

چجوری با یک تریک ساده OTP ایمیل رو دور زدم و می‌تونستم بدون تایید ایمیل وارد هر حسابی بشم؟ توی پست قبلی به این اشاره داشتیم که عرف یه ثبت‌نام به چه شکله و اگه یه فلو مخالف داشتیم چه تست‌هایی رو می‌تونیم روی اون فلو بزنیم. پس ما نسبت به سیستم احراز هویتی که جلومونه تغییر جهت می‌دیم و تست‌های مربوط به اون سیستم رو اجرا می‌کنیم. سناریوی من یه سناریو روی یه تارگت واقعی Real-World هستش؛ پس آماده بشید بریم سراغ یه سناریوی کمی پیچیده‌تر. سناریوی من یه ثبت‌نام عادی بود با چند تا مرحله اضافه‌تر: صفحه ریجستر تارگت از من یه ایمیل + شماره موبایل و پسورد می‌خواست. زمانی که من روی confirm کلیک می‌کردم، منو می‌برد به یه صفحه‌ای که ازم سوال می‌پرسید: «کدت رو به شماره موبایلت اس‌ام‌اس کنم یا به ایمیل بفرستمش؟» روی ایمیل کلیک کردم. همون‌طور که داشتم با فرآیند آشنا می‌شدم، برپ‌سوییت Burp Suite هم دونه به دونه درخواست‌ها رو می‌گرفت. در واقع زمانی که من روی continue کلیک کردم، یه درخواست زده شد مشابه این: یه درخواست POST زده می‌شد به این ای پی آی 👈 (/api/authentication/sign-in) کانتنت بادی من جیسون JSON بود که این دیتا رو می‌فرستاد:

{
  "LoginType": "email",
  "password": "mypass",
  "user": "dagen@gmail.com",
  "session": "randommmmmmmmmmmmmmmmmm",
  "locale": "en_us"
}

تا اینجا درست. سرور بهم میگه تو لاگین تایپت ایمیله، درستم میگه چون خودم انتخابش کردم. ولی یه چیزیو نمیگه؛ اینکه آیا ما فقط دو حالت داریم؟ یعنی فقط SMS و ایمیل؟ زیاد واردش نمیشیم چون هدف ما فعلاً تست کردن این قسمت نیست و ازش رد می‌شیم. توی پارامتر بعدی ما یه پسورد داریم که خودمون فرستادیمش. پارامتر بعدی یه سشن (session) داشتیم که توی هر درخواست ارسال می‌شد و بعد از وریفای شدنم تبدیل به access-token می‌شد. بسیار خب، پارامترهای مهم رو بهش پرداختیم. نوبت به این می‌رسه که درخواست رو فوروارد کنم. وقتی فوروارد رو زدم، یه صفحه برام باز شد که من باید OTP که به ایمیلم ارسال شده بود رو وارد می‌کردم. اینتر رو زدم و اومدم توی برپ؛ یه درخواست POST دیگه زده شد که مربوط به کانفِرم کد تایید بود: (/api/authentication/confirm-otp) توی دیتای جیسون هم دو تا پارامتر بیشتر نداشتیم:

{
  "otp": "11111",
  "session": "randommmmmmmmmmmmmmmmmm"
}

پارامتر otp همون کد ولیدیه که به ایمیل من ارسال شد و پارامتر سشن هم همون سشنیه که توی هر درخواست ارسال میشه. همین درخواست رو بردم توی تب Repeater و روی دکمه Send کلیک کردم. انتظار میره همه‌چیز درست باشه؛ ریسپانس سرور من یه 200 بود با یه بدنه جیسون که از کلاس usersigninsession توی پارامتر access-token توکن احراز شده منو بهم می‌داد:

{
  "usersigninsession": {
    "access-token": "myToken"
  }
}

(اینم اضافه کنم که اگه اشتباه وارد می‌کردم به من ۵۰۰ می‌داد با یه جیسون که ارور مسیج داشت). ثبت‌نام با این فلو به پایان رسید و قدم آخر اینکه سایت یه چیزیو از من ذخیره کنه تیک خورد ✅ بریم سراغ مغز آسیب‌پذیری من تمام مراحل رو طی کردم. اینجا یه OTP ولید داشتم، درسته؟ زمانی که درست بود سرور به من یه اکسس توکن می‌داد و زمانی که اشتباه بود من ارور مسیج داشتم. توی ذهن من مدام یادآوری میشه که من باید کاری کنم که این منطق دور زده بشه و در نهایت سشن من آپگرید بشه و تبدیل به access-token بشه. چه تستی کردم؟ "Array in SMS code" توی کانتنت جیسون تست‌های ما محدوده چون سمت سرور ما جیسون‌پارس داریم و این پارامترها می‌شینن توی آبجکت. برعکس خیلی‌ها که میان این‌جوری تست می‌کنن و کد دلبخواهی رو توی ارایه میزارن:

{
  "otp": ["false-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

و بعدش یه ارور مسیج خوشگل می‌گیرن و بی‌خیال ادامه می‌شن، من اومدم این‌جوری تست کردم: کد ولیدی که به ایمیلم ارسال شده بود رو گذاشتم توی آرایه!

{
  "otp": ["true-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

دکمه Send رو زدم و بوممم! access-token برام برگشت! داستان جذاب شد؛ این به این معناست که من الان می‌تونم دونه به دونه کدهای مختلف رو تست کنم؟

{
  "otp": ["true-code", "111", "222", "333"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

ولی من نمی‌خوام دستی این کار رو انجام بدم چون عاقلانه نیست. در آخر اومدم یه پکت ارسال کردم که توش ۱۵,۰۰۰ کد با کاما توی این آرایه از هم جدا شده بود و وقتی سند رو می‌زدم یکی از کد با کد ولیدی که برای ایمیل اومده بود مچ میشد و باگ در میومد

چجوری با یک تریک ساده OTP ایمیل رو دور زدم و می‌تونستم بدون تایید ایمیل وارد هر حسابی بشم؟ توی پست قبلی به این اشاره داشتیم که عرف یه ثبت‌نام به چه شکله و اگه یه فلو مخالف داشتیم چه تست‌هایی رو می‌تونیم روی اون فلو بزنیم. پس ما نسبت به سیستم احراز هویتی که جلومونه تغییر جهت می‌دیم و تست‌های مربوط به اون سیستم رو اجرا می‌کنیم. سناریوی من یه سناریو روی یه تارگت واقعی Real-World هستش؛ پس آماده بشید بریم سراغ یه سناریوی کمی پیچیده‌تر. سناریوی من یه ثبت‌نام عادی بود با چند تا مرحله اضافه‌تر: صفحه ریجستر تارگت از من یه ایمیل + شماره موبایل و پسورد می‌خواست. زمانی که من روی confirm کلیک می‌کردم، منو می‌برد به یه صفحه‌ای که ازم سوال می‌پرسید: «کدت رو به شماره موبایلت اس‌ام‌اس کنم یا به ایمیل بفرستمش؟» روی ایمیل کلیک کردم. همون‌طور که داشتم با فرآیند آشنا می‌شدم، برپ‌سوییت Burp Suite هم دونه به دونه درخواست‌ها رو می‌گرفت. در واقع زمانی که من روی continue کلیک کردم، یه درخواست زده شد مشابه این: یه درخواست POST زده می‌شد به این ای پی آی 👈 (/api/authentication/sign-in) کانتنت بادی من جیسون JSON بود که این دیتا رو می‌فرستاد:

{ "LoginType": "email", "password": "mypass", "user": "dagen@gmail.com", "session": "randommmmmmmmmmmmmmmmmm", "locale": "en_us" }

تا اینجا درست. سرور بهم میگه تو لاگین تایپت ایمیله، درستم میگه چون خودم انتخابش کردم. ولی یه چیزیو نمیگه؛ اینکه آیا ما فقط دو حالت داریم؟ یعنی فقط SMS و ایمیل؟ زیاد واردش نمیشیم چون هدف ما فعلاً تست کردن این قسمت نیست و ازش رد می‌شیم. توی پارامتر بعدی ما یه پسورد داریم که خودمون فرستادیمش. پارامتر بعدی یه سشن (session) داشتیم که توی هر درخواست ارسال می‌شد و بعد از وریفای شدنم تبدیل به access-token می‌شد. بسیار خب، پارامترهای مهم رو بهش پرداختیم. نوبت به این می‌رسه که درخواست رو فوروارد کنم. وقتی فوروارد رو زدم، یه صفحه برام باز شد که من باید OTP که به ایمیلم ارسال شده بود رو وارد می‌کردم. اینتر رو زدم و اومدم توی برپ؛ یه درخواست POST دیگه زده شد که مربوط به کانفِرم کد تایید بود: (/api/authentication/confirm-otp) توی دیتای جیسون هم دو تا پارامتر بیشتر نداشتیم:

{
  "otp": "11111",
  "session": "randommmmmmmmmmmmmmmmmm"
}

پارامتر otp همون کد ولیدیه که به ایمیل من ارسال شد و پارامتر سشن هم همون سشنیه که توی هر درخواست ارسال میشه. همین درخواست رو بردم توی تب Repeater و روی دکمه Send کلیک کردم. انتظار میره همه‌چیز درست باشه؛ ریسپانس سرور من یه 200 بود با یه بدنه جیسون که از کلاس usersigninsession توی پارامتر access-token توکن احراز شده منو بهم می‌داد:

{
  "usersigninsession": {
    "access-token": "myToken"
  }
}

(اینم اضافه کنم که اگه اشتباه وارد می‌کردم به من ۵۰۰ می‌داد با یه جیسون که ارور مسیج داشت). ثبت‌نام با این فلو به پایان رسید و قدم آخر اینکه سایت یه چیزیو از من ذخیره کنه تیک خورد امیدوارم درک کرده باشید بریم سراغ مغز آسیب‌پذیری من تمام مراحل رو طی کردم. اینجا یه OTP ولید داشتم، درسته؟ زمانی که درست بود سرور به من یه اکسس توکن می‌داد و زمانی که اشتباه بود من ارور مسیج داشتم. توی ذهن من مدام یادآوری می‌شد که من باید کاری کنم که این منطق دور زده بشه و در نهایت سشن من آپگرید بشه و تبدیل به access-token بشه. چه تستی کردم؟ "Array in SMS code" توی کانتنت جیسون تست‌های ما محدوده چون سمت سرور ما جیسون‌پارس داریم و این پارامترها می‌شینن توی آبجکت. برعکس خیلی‌ها که میان این‌جوری تست می‌کنن:

{
  "otp": ["false-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

و بعدش یه ارور مسیج خوشگل می‌گیرن و بی‌خیال ادامه می‌شن، من اومدم این‌جوری تست کردم: کد ولیدی که به ایمیلم ارسال شده بود رو گذاشتم توی آرایه!

{
  "otp": ["true-code"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

دکمه Send رو زدم و بوممم! access-token برام برگشت! داستان جذاب شد؛ این به این معناست که من الان می‌تونم دونه به دونه کدهای مختلف رو تست کنم:

{
  "otp": ["true-code", "111", "222", "333"],
  "session": "randommmmmmmmmmmmmmmmmm"
}

ولی من نمی‌خوام دستی این کار رو انجام بدم چون عاقلانه نیست. در آخر اومدم یه پکت ارسال کردم که توش ۱۵,۰۰۰ کد با کاما توی این آرایه از هم جدا شده بود و وقتی سند رو می‌زدم باگ در میومد

⭕️ اولین کتابی که برای شروع هک باید توی اولویت قرارش بدی

نسخه فارسی کتاب : ( Linux basic For Hackers Persian )

Channel : @Sec_Book_Mind

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

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

✍ من فقط توی ایمیل قربانی یه اینتر اد کردم، چجوری باعث اکانت تیک‌اور شد؟ تایتل این پست یه تایتل عجیب و کاملاً منطقیه. قبل از اینکه بریم سراغ توضیح این باگ، بیاین یه روال عادی ثبت‌نام یه سایت رو بررسی کنیم. یه روال عادی ثبت‌نام توی یه وب‌سایت همچین چیزیو برای ما بازگو میکنه: من به عنوان یه کاربر دوست دارم توی وب‌سایت مورد نظرم ثبت‌نام کنم؛ یه یوزرنیم وارد میکنم، یه ایمیلم میدم به همراه یه پسورد و دکمه تاییدو میزنم. سایت یه پیام بهم میده میگه برو کد چند رقمی رو وارد کن و اگه کد درست بود، کوکی یا توکن برات ست میکنه. این میشه یه روال عادی و عرف همه ثبت‌نام‌ها پس من اینو برای خودم ثابت میگیرم و به عنوان یه روال عادی ثبت‌نام میرم هانت میکنم و هر بخش ثبت‌نامی که از این فلو پیروی نکنه، روش کمی عمیق میشم. ببینید توی این سناریو من وارد یه وب‌سایت شدم، بخش signup ازم میخواد یه سری فیلدو پر کنم؛ یه یوزرنیم، ایمیل و پسورد. دکمه تایید رو میزنم و مستقیم میرم توی اکانتم! چی شد؟ یه مرحله از یه روال عادی حذف شد و ما اینجا یه ریجستر فوری داریم اصطلاحاً (immediate login registration)، کاری که پینترست میکنه. در واقع سایت لاگینت می‌کنه و میگه بعداً برو ایمیلتو تایید کن خب این یعنی اگه من ایمیل یه قربانی رو وارد کنم (victim@gmail.com) که توی این سایت قبلاً ثبت‌نام کرده و یه پسورد دلبخواه هم واسش بزنم، چون تایید ایمیل نداره میرم توی حسابش؟ مسلماً نه، به این راحتیا نیست؛ سایت یه پیام زیبا بهت میده، میگه این ایمیل از قبل ثبت‌نام کرده و اجازه ورود نمیده بهت. اینجا یه تست‌کیس قشنگ داریم که باید روی هر ریجستریشنی بی قید و شرط تستش کنید. کاری که کردم ساده بود؛ فرم ثبت‌نام رو پر کردم، روی دکمه تایید کلیک کردم و پکت رو با برپ‌سویت گرفتم. توی پارامتر ایمیل:

email = victim@gmail.com

اول یا آخر ایمیل یه اینتر زدم:

email = victim@gmail.com%0a

درخواست رو فوروارد کردم، رفتم پنل کاربری و تمام ❗️ من وارد اکانت قربانی شدم؛ زیرو کلیک اکانت تیک‌اور بعضیاتون ممکنه کمی گیج شده باشید، شاید سوال براتون پیش بیاد آیا این ایمیل ولیده اصلاً؟ چی شد؟ برگردیم به یه مبحث که حتی امروز بهترین باگ‌ها از دل این مفهوم میزنن بیرون: عدم هماهنگی بین دو عنصر. یه چک داریم —> ایمیل من سمت دیتابیس چک میشه (victim@gmail.com%0a)؛ برای دیتابیس، این یه ایمیل جدیده. اما زمانی که میخواد پشت صحنه ریجسترش کنه، اینو نرمالیزه (Normalize) میکنه به این: victim@gmail.com متوجه شدید؟ این شد سناریوی آسیب‌پذیری که دو تا ایمیل متفاوت رفت توی یه اکانت. در چه صورتی آسیب‌پذیری نداریم؟ زمانی که من اینو وارد کنم (victim@gmail.com%0a) و برای من یه اکانت جدا بسازه و هیچ نرمالیزیشنی اتفاق نیفته! حتی بعضی از سیستم‌ها چه اینتر رو وارد کنی یا وارد نکنی، بهت میگن از قبل این اکانت وجود داره. ریشه این آسیب‌پذیری اتفاقی بود که اون پشت می‌افتاد؛ این ایمیل از چند لایه رد میشد و نرمال میشد. بهترین راه جلوگیریش اینه که همون لایه اول چک بشه و با ایمیلی که از قبل وجود داشته مقایسه بشه. این باگو عیناً یک سال پیش زدم و هنوز که هنوزه روی هر ریجستر کدهای مختلف رو میزنم: آخر ایمیل، اول ایمیل، وسط ایمیل. و اصلاً ضرر نداره که کاراکترهای هکس 00 تا 20 (Hex 0x00 to 0x20) رو هم روش تست کنید و فقط %0a نزنید این تست رو شاید ده هزار بار روی چک‌لیست‌های آماده دیده باشید، چیزی که ارزش داره اینه که مفهوم پشتشو بدونید و فکر کنید چه تستی برای چه لاگینی مناسبه. خیلی مهمه یه سری از کارها رو دستی انجام بدید، نه اینکه فقط با ابزار اسپری کنید. اتنتیکیشن مبحثیه که خیلی باید روش فکر کنید، فلوها رو بشناسید و سعی بکنید ازش باگ بکشید بیرون. این یکی از بیسیک‌ترین و ساده‌ترین نوع تست‌کیس‌ها بود؛ برای بچه‌هایی که هنوز نمیرن سمت اتنتیکیشن چون درکی از تست کردنش ندارن، این پست مفیدترینه. توی این پست بذر این مفهوم رو کاشتیم، همینجوری میریم جلو و میرسیم به تست‌های قشنگ oauth، کلاسیک تکون دادن توکن‌ها، 2fa و... همینجوری بهش شاخ و برگ میدیم. امیدوارم براتون مفید بوده باشه. اگه کانال زنده باشه و انرژی داشته باشید، همینجوری براتون مینویسم و با انجام دادنش خودمم یاد میگیرم. 🌷 @Dagen_security