نتیجه یه هفته ریسرچ خفن روی oauth و autorization شد یه xmind با تاپیک های عظیمو جثه ای که بالا میبینید .👆

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

بروز بودن خیلی مهمه و اینکه شما هر روز از هر مبحث یه نکته اضافه تری یاد بگیرید و درک کنید قطعا در اینده براتون هینتی میشه که باگای خلاقانه تر و قشنگ تر بزنید .

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

مثال میزنیم اگه یه روزی وب اپلیکشنی مثل تارگتتون به عنوان یه احرازهویت جدید از oauth استفاده کرد تا کاربراشون راحت تر لاگین انجام بدن یه مهاجم چه چیزهایی رو تست میکنه و چه باگ هایی از دل این پیاده سازی میزنه بیرون !؟

خیلی از مباحث نمیتونه در قالب یه پست تموم بشه چون نیاز به درک عمیق و زمان زیادی داره ولی همیشه سعی کردم دید کلی رو منتقل کنم تا یه هینتی بشه برای اینکه شروع کنی و خودتو تکون بدی .

در ضمن دوستانی که از قبل xmind اوسپ پیش نیاز من رو گرفتند و به عنوان یه رودمپ کامل برای پیشنیاز ازش استفاده کردند
به پشتیبانیم پیام بدن و web application vulenrability xmind اسیپ پذیری و تست کیس هایی که روی تارگت واقعی انجام دادم و هر نکته ای که توی مسیر کارم بهش اضافه کردم برای تست وب اپلیکشن , و باهاش باگای زیادی زدم رو به عنوان هدیه رایگان ازم دریافت کنن .

و دوستانی که به هر دلیلی رودمپ رو ندارند و به کار من ایمان دارند و میخوان xmind پیشنیاز اوسپ + هانت رو داشته باشند کافیه به پشتیبانی من پیام بدن تا شرایط رو بدونن و به عنوان یه اهرم از این تست کیس ها توی هانت خودشون استفاده کنن .

ایدی پشتیبان : @bookmind369

چون معتقدم اشتراک دانش مفید باعث خلق باگای بیشتر میشه و جامعه متخصص ها قوی تر و بیشتر میشه 🙌

همین الان با بچه های تیممون روی یه سامانه کار کردیم و دقیقا یکی از تست های oauth مون خورد :)

بچها باگه اینجوری بود که توی oauth وقتی پارامتر scope که پرمیزشن ها رو برای گرفتن اکسس توکن نهایی تعیین می‌کنه رو مقدار ایمیل رو ازش بر می‌داشتی و بدون ایمیل میفرستادی :

scope=openid%20name

میرفتی توی اکانت آخرین نفری که توی سایت ریجستر کرده 😂


شدیداً دوسش داشتم چون تست خیلی قشنگ و سریعی بود که منجر به یه باگ high لول شد :)

تبریک نداره ؟🫶

@dagen_security

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

اولین سوالی که باید از خودمون بپرسیم اینه : csrf چیه ؟

وقتی من به عنوان یه مهاجم کاربری مجبور کنم کاری کنه که نمیخواد این میشه crsf .
خب یه سوال دیگه برامون پیش میاد : من چجوری میتونم کاربر رو مجبور به انجام کاری کنم ؟

دقیقا قراره راجب همین موضوع صحبت کنیم ; ما میتونیم از طرف کاربر درخواست ارسال کنیم و اون درخواست میتونه کوکی داشته باشه و اگه اون کوکی privilage باشه چه اتفاقی میوفته !؟

موضوع اول : درخواستی که کاربر میخواد انجام بده حتما باید با یه state یا یه حالتی داخلش تغیر بکنه مثال forget_password که پسورد یوزر داخلش تغیر میکنه

با موضوع اول توضیحم تکمیل تر شد باید کاربر رو مجبور به کاری کنیم که نمیخواد و توی این کار باید حتما یه استیت و یا پروفایل و یا پسورد کاربر تغیر بکنه
یعنی کاربر باید http requset بفرسته .

بریم سراغ شرط های این اسیپ پذیری :

1 - برای اینکه یه وبسایت به csrf اسیپ پذیر باشه حتما باید با کوکی کار کنه چون مرورگر به صورت اتوماتیک رو میزاره توی هر درخواست هر چیزی جز این باعث اجرا نشدن حمله میشه
2 - قوانین same site نباید فعال باشه - حمله شکست میخوره ! مگه اینکه شرایط خاصی وجود داشته باشه
3- درخواست http که ما میخوایمcsrf کنیم باید حتما simple باشه و گرنه یه preflight زده میشه . یعنی چی شما از کجا میفهمی یه درخواست simple هست؟

HTTP methods: GET,POST,HEAD
headers: referer,user-agent,cookie (browsers header automaticity send )
content-type: application/X-www-form-url-encoded , text/plain , multipart/form-data

4- فرض کنیم پکت HTTP ما همه این شرایط رو داشت ایا csrf ممکنه ؟

نه یه چیز دیگه حتما باید چک بشه ,درخواستی که شما ارسال میکنی , حتما باید تکرار پذیر باشه و توی بادی نباید پارامتری یا شناسه ای داشته باشه که توی هر درخواست تغیر کنه اگه یه رندوم استرینگ و یا نامبر مخصوص یه کاربر باشه این باعث شکست خوردن حمله میشه ( کاری که وردپرس میکنه !)

بریم سراغ پروتکشن ها , برنامه نویس ها برای جلوگیری از این اسیپ پذیری کجا ها چک های امنیتی رو میزارن !؟

راه اول : گذاشتن csrf token هستش که توی هر درخواست قرار داده میشه و خیلی راه برای دور زدنش وجود داره .

راه دوم : چک کردن ریفرر ( اگه من به عنوان کلاینت چینچ پسورد انجام بدم و ریدارکت بشم ریفرر من خود سایته و ولیده ) پس من اگه حمله انجام بدم ریفرر میشه یه سایت جز سایت اصلی و حمله شکست میخوره و اجرا نمیشه که تقریبا پروتکشن خیلی خوبیه ولی همیشه نمیتونه سیف باشه (کاری که فیسبوک قبلا انجام میداد!)

راه سوم : که من یه راه فول سیف میبینمش اینه که اینه وب سرور توی هر درخواستی که ارسال میکنه یه هدر کاستوم بزاره مثل x-test که با این کار باعث میشه هیچ درخواست simple وجود نداشته باشه و حمله ها شکست میخورن .

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

امیدوارم یه درک نسبی راجب csrf گرفته باشید و هینت گرفته باشید که شرایط اجرای این حمله دقیقا چیه , حمایت از پست ها فراموش نشه 🌷

@Dagen_security

برای پست بعدی قراره دوباه بریم سراغ sql-injection ولی نه یه تزریق معمولی توی کوعری استرینگ . تزریق sql توی هدر user-agent بود که تایم بیس sql-injection میخورد
باگی که روی یه پروگرم نسبتا ریت خوب توی پلتفرم integrity زدم و میخوام براتون شرح بدم که درسته sqli در حال منقرض شدنه ولی دقیقا کجا ها میتونید در حال حاضر پیداش کنید .🫡
ریکشن و انرژی بدید تا بریم برای اماده سازی پست بعدی رفقا 🙌

شکار باگ SSTI؛ چطوری مهاجم از یه فیلد ساده به SSTI رسید ؟

توی این رایتاپ، شکارچی نشون میده که چطوری با زیرکی تونسته آسیب‌پذیری SSTI (تزریق به قالب سرور) رو پیدا کنه. این باگ وقتی پیش میاد که سرور، ورودی کاربر رو مستقیم بذاره وسط کدهای Template خودش.

فلو و مراحل هانت:

1️⃣پیدا کردن هدف: یک فیلد ورودی (مثل اسم کاربر یا نام پروفایل) که حدس می‌زد توسط موتور قالب‌ساز (مثل Jinja2 یا Twig) پردازش می‌شه.

2️⃣ تست جادویی (Polyglot Payload): هانتر از عبارت‌های محاسباتی استفاده کرد؛ مثلاً وارد کردن {{7*7}}. اگه سایت عدد 49 رو نشون بده، یعنی تبریک! موتور قالب داره کد شما رو اجرا می‌کنه.

3️⃣ شناسایی موتور (Fingerprinting): هر موتور قالب (Template Engine) سینتکس خاص خودش رو داره. با تست کردن پی‌لودهای مختلف، مشخص شد که سیستم از چی استفاده می‌کنه.

4️⃣ حمله نهایی (Exploit): حالا که راه باز شده، هانتر به جای عدد، کدی زد که بتونه فایل‌های سرور رو بخونه یا دستورات سیستم‌عاملی رو اجرا کنه (RCE).

✅ نکته طلایی: همیشه لازم نیست دنبال باگ‌های پیچیده باشید؛ گاهی اوقات تست کردن یک عبارت ریاضی ساده توی فیلد پروفایل، می‌تونه کل دسترسی سرور رو بهتون بده!

🔗 لینک مقاله: SSTI on YesWeHack

جزئیات فنی هک میلیون‌ها خودروی KIA 🔥

تیم سم کری (Sam Curry) نشون داد که چطوری یه اشتباه توی طراحی API می‌تونه فاجعه بسازه. اینجا بحث هک کردن خودِ ماشین نبود، بحث دور زدن پورتال مدیریت کیا بود.

فلوچارت دقیق حمله:

1️⃣ دور زدن ثبت‌نام (HTTP Request Tampering): اونا دیدن که پورتال نمایندگی‌های کیا (kiadlp.com) موقع ثبت‌نام، چک نمی‌کنه که آیا ایمیل شما واقعاً متعلق به یه نماینده‌ست یا نه. با تغییر دادن پارامترها در ریکوئست ثبت‌نام، تونستن یه Token سطح بالا (مخصوص تعمیرکارها) بگیرن.

2️⃣ نقطه ضعف در API (IDOR): این هکرها به یه پکیج از APIها رسیدن که وظیفه‌اش وصل کردن اپلیکیشن موبایل به ماشین بود.

اونا فهمیدن با داشتن VIN (شماره شناسایی خودرو)، می‌تونن دستور get_owner رو صدا بزنن.

خروجی این API چی بود؟ ایمیل و شماره تماس صاحب ماشین!

3️⃣ تزریق ایمیل هکر به ماشین: حالا که ایمیل صاحب رو داشتن، از یه متد دیگه به اسم add_command استفاده کردن. اونا یه درخواست فرستادن که: "این ایمیل (ایمیل هکر) رو به عنوان دسترسی ثانویه به این ماشین (با این VIN) اضافه کن."

نکته حساس: سیستم هیچ تاییدیه یا OTP برای صاحب اصلی ماشین نفرستاد!

4️⃣ اجرای فرمان در ۴۰ ثانیه: تیم یه اپلیکیشن ساده نوشتن که کل این پروسه (پیدا کردن ایمیل صاحب -> اضافه کردن هکر -> ارسال دستور باز شدن در) رو در کمتر از ۴۰ ثانیه انجام می‌داد. یعنی فقط با داشتن پلاک، ماشین زیر پای طرف باز می‌شد!

⚠️ باگ‌های کلیدی که باعث این فاجعه شد:

عدم احراز هویت درست (Broken Authentication): پورتال نمایندگی به هر کسی اجازه ورود داد.

افشای اطلاعات حساس: API نباید ایمیل صاحب ماشین رو به بقیه برمی‌گردوند.

نبود کنترل دسترسی (BOLA/IDOR): هر کسی می‌تونست برای هر ماشینی دستور "اضافه کردن کاربر" بفرسته.

لینک مقاله : Hacking Kia

SSTI یه چک لیست ساده واسه تست اولیه

این تصویر خیلی تصویر قشنگ و درستیه 🫡

1 - این تصویر به ما میگه برای تست اولت ${{7*7}} رو تست کن
اگه جواب داد و به سمت خط سبز رفتی اسیپ پذیره و برو برای ادامه تست و اکسپولیتش .

2 - اگه جواب نگرفتی و عدد 49 رو ندیدی و به سمت خط قرمز رفتی , برای تست دومت علامت ($) رو بردار و بدونش تست کن :

{{7*7}}

اگه دوباره جواب نگرفتی و عدد 49 رو ندیدی , بیخیال تست شو چون اسیپ پذیری نیست !

و اگه 49 رو دیدی یعنی اسیپ پذیره یه هفت رو استرینگ کن این پیلود رو تست کن :

{{7*'7'}}

این پیلود باعث چاپ شدن هفتای زیادی توی صفحه میشه
اگه جواب داد یا jinja2 هستش و یا یه انجینی که نمیدونیم :)

@Dagen_security

فرایند کشف آسیب پذیری PDF-based Stored XSS روی یک وبسایت فروشگاهی ایرانی ✍

اول از همه بریم ببینیم اصلاً PDF-based Stored XSS چیه.

همون‌طور که می‌دونید Stored XSS جزو آسیب‌پذیری‌های خطرناک محسوب می‌شه، چون Payload روی سرور ذخیره می‌شه و هر کسی که بهش دسترسی داشته باشه، اکسپولیت می‌شه.

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

ولی خیلی وقت‌ها WAF ( Application Firewall) اجازه نمیده Payload های مخرب xss  جواب بدن و باعث بلاک کردن پیلود میشن .


اینجاست که آپلود فایل PDF مخرب می‌تونه راه خوبی برای رسیدن به Stored XSS باشه، چون PDF می‌تونه javanoscript parsing داشته باشه و خیلی از سایت‌ها این موضوع رو جدی نمیگیرن.

چطور به این آسیب‌پذیری می‌رسیم؟

اول باید Payload یا کد کد مخرب جاوا اسکریپت رو داخل یک فایل PDF تزریق کنیم. بعد اون فایل رو توی بخش‌هایی که سایت اجازه آپلود فایل میده، آپلود می‌کنیم؛
مثل:
حساب کاربری، تیکت‌های پشتیبانی، ارسال مدارک، نظرات و موارد مشابه
وقتی فایل مخرب پشت صحنه آپلود می‌شه، اگه سایت فایل PDF رو مستقیم داخل مرورگر نمایش بده و محدودیتی روی محتوای فعالش نداشته باشه، مرورگر میاد کدهای JavaScript داخل PDF رو اجرا می‌کنه. Payload ما (مثلاً alert) اجرا می‌شه و یعنی به Stored XSS رسیدیم.

نکته مهم: این رفتار معمولاً روی مرورگر Chrome بهتر دیده می‌شه.

چه زمانی باگ حساب نمی‌شه؟

بعضی وقت‌ها بعد از آپلود فایل مخرب، مرورگر به‌جای اجرا کردن PDF، فایل رو دانلود می‌کنه یا اصلاً اجازه اجرای کد رو نمی‌ده. این یعنی سایت تنظیمات امنیتی بهتری داره و عملاً به Self XSS یا عدم بهره‌برداری می‌خوریم و باگ قابل سوءاستفاده‌ای وجود نداره.

چطوری این باگ رو کشف کردم؟

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

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

@dagen_security

چجوری یه sqli توی سرویس api تارگتم زدم !؟

داستان از این قراره که توی پرورگرم پابلیکی که سه ماه توش مشغول به کار بودم یه باگ خیلی خطرناک پیدا کردم. چجوری این باگو پیدا کردم ؟
پرورگرم هر اشکال امنیتی از سابدامین های خودش رو به عنوان یه باگ لجیت قبول میکرد .

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

برای مثال : api-prod.target.com

وقتی صفحه رو باز کردم چیزی به چشمم نخورد و با صفحه خالی مواجه شدم . چیزی که هر هانتری برای تست میره سراغش این مورداست :

1 - فاز معمولی و فاز با اکستشن های مختلف
2- وی بک
3 - گوگل دورکینگ با انجین های مختلف
4- سرچ توی گیتهاب یا بیت باکت و ..

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

ولی من به شاید ها کاری ندارم , من باید به عنوان یه هانتر برم و باگو پیداش کنم و گزارشش بدم .

Time based SQL injection :

پکت رو توی برپ سوییت باز کردم و فقط به پکت نگاه کردم .

گوشه ذهنم میدونستم که وبسایت ها میتونن یه سری داده و اطلاعات رو از کاربر ذخیره کنن و یدونه از اون اطلاعات User-agent هستش و این User-agent ممکنه بشینه توی دیتابیس و یا نوعی insert بشه .
پس ترت مدل من این بود که برم یه time-base-sqli توی user-agent تست کنم و با خواب رفتن سرور متوجه این بشم که اسیپ پذیری وجود داره .

خب بیایم یه شبیه سازی تو ذهنمون داشته باشیم فرض بگیریم یه همچین چیزی(insert) توی دیتابیس وجود داره :

insert into table ('user-agent') VALUE ('$INPUT')

اگه همچین چیزی اون پشت داشته باشیم پس من باید با ' بریک کنم و کوعری sleep رو اجرا کنم . پیلودی که به ذهنم رسید رو تست کردم :

' + sleep(15) + '

اتفاقی که واسه پشت صحنه میوفته :

insert into table ('user-agent') VALUE ('$INPUT' + sleep(15) + '')

این دقیقا چیزی بود که من تستش کردم و کاملا منطقی بود, ما از پلاس توی sql استفاده میکنیم تا رشته ها رو به هم کانکت و به نوعی عملیات جمع انجام بدیم . تست کردم ولی هیچ اتفاقی نیوفتاد ✖️

سریع از لابراتور انلاین sql استفاده کردم و همین کد با همین فرضیه رو تست کنم و به یه خطای مهم رسیدم :
پارسر sql میگفت من گیج شدم و نمیتونم اینو اجرا کنم. چرا ؟ چون تو میخوای یه استرینگ خالی رو با استرینگ پر و یه اسلیپ رو با هم کانکت کنی ! همچین کاری رو نمیتونی انجام بدی !

اهاا. یه تریک ریز به ذهنم رسید. چی میشه اگه من مقدار User-agent رو پاک کنم و پیلود خودمو بزارم ؟

User-agent: ' + sleep(15) + '

insert into table ('user-agent') VALUE ('' + sleep(15) + '')

15 ثانیه رفت به کما و تمام. باگ تایید شد ☺️

تمام نکته این بود که باید رشته پاک میشد تا جواب بگیری . فقط کپی پیست پیلود کافی نیست باید تحلیل کنی .🫡

امیدوارم از این سناریوی باگ ریل ورد دید خوبی گرفته باشید انرژی فراموش نشه ⚡️

@Dagen_security

وقتی رایتاپ های هانتر هایی مثل اورنج , سم کری و فرنس روزن رو میخونی و از این هانترای فوق العاده یاد میگیری ناخود اگاه حس خوشحالی بهت دست میده چون هر تیکه ای از رایتاپ های این افراد لذت خالصه
بهت یاداور میشه که تو به عنوان یه هانتر کجای مسیرو توی تستایی که انجام میدی داری میس میدی و از کنارشون بی تفاوت میگذری ؟

+ رایتاپ رو مداوم بخون و اگه میخوای هانتر موفقی بشی حتما به تاپ صد هکروان رجوع کن ✔️
@Dagen_security

نام کتاب : Web hacking 101

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

+ نسخه فارسی این کتاب آماده تحویله . برای دریافت به پشتیبان پیام بدید ⬇️

@bookmind369