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

نکته مهمی که خیلی‌ها موقع پیدا کردن Origin IP یک وب‌سایت ازش غافل می‌شن اینه که فقط به تاریخچه‌ی DNS و سرتیفیکت‌ها نگاه میکنن.

توی بعضی از کیس‌ ها، مخصوصاً پیکربندی‌های قدیمی‌تر، می‌تونید به‌سادگی IP اصلی وبسایت رو از طریق MX Record مربوط به Mail Server پیدا کنید؛ چون توی بعضی از سایت ها ممکنه خود Mail Server رو همون اپی بالا اومده باشه .

ولی این روش روی وب‌سایت‌های امروزی معمولاً جواب نمیده و یه راه حلی داریم :

با استفاده از SecurityTrails و دیتای MX History میتونین تمام رکوردهای MX قدیمی رو بررسی کنید و اگه توی گذشته Mail Server روی همون IP اصلی اجرا شده باشه، احتمالش بالاس که توی همین تاریخچه دیده بشه و اپی اصلی سایت در دسترستون قرار بگیره 🤌

@Dagen_security

یکی از بهترین ابزار ها برای پارامتر دیسکاوری و پیدا کردن پارامتر های مخفی یه صفحه ابزار "X8" هستش .

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

یکی از بهترین و کاربردی ترین سوییچ ابزار , اینه که شما میتونی یه کاستوم ولیو بهش بدی و بر اساس اون برای شما فاز کنه. یعنی چی ؟

x8 -u TARGET —custom-value "company name"

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

همین نکته ساده نتایج فاز پارامتر منو دوبرابر کرده و چیزیه که یه کامند فاز معمولی پیدا نمیکنه و میتونه به شما پارامتر های حساسی رو بده که منجر به xss و open redirect بشه
+ اگه صفحه نیاز به احراز داشت حتما توکن خوتودنم به ابزار بدید و با پروکسی چک کنید تا فاز بیهوده و بی نتیجه نداشته باشید.

@Dagen_security

قبل از اینکه بریم سراغ روال عادی چنل و گذاشتن پست های باگ بانتی ,

توی این چنل قراره عمیق تر شیم و بریم سراغ تحلیل وب اپلیکشن و این موضوع رو جدی تر برسی کنیم و اپلیکشن ها رو مپ کنیم ✍

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

۲ - دانشی که از شمارو از یه جونیور و یه فرد سنیور جدا میکنه تحلیل وب اپلیکشنه

همه هانترای خفن امروزی بیشتر روی دانش "application mapping" زمان میزارن و این علم خودشون رو قوی تر میکنن

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

ولی یه فرد هانتر باید روال غیر عادی رو تشخیص بده و به نوعی از این اشتباه و دست بردن برنامه نویس به کد باگ بسازه !

۳ - خب من چه جوری میتونم روال غیر عادی رو بشناسم ؟

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

ایا مثلا اگر از google oauth  برای احراز هویت داره استفاده میکنه ایا طبق داکیومت رسمی داره انجام میده یا برنامه نویس دست برده توی فرایند ؟

برای اینکه جزو تاپ های حوزه بشید باید صبور و دقیق و مهم تر از همه خلاق باشید ـ!

دنبال فلان ابراز نباشید چیزی که شما رو از بقیه هانترا جدا می‌کنه تحلیل بلک باکس و وایت باکس و فرض گرفته !

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

در ادامه چنل قراره تمرکز روی بحث های زیر باشه :

نحوه کارکرد وب اپلیکشن + سیستم احراز هویت + تکنولوژی استفاده شده

به چنل‌ یه انرژی جون دار بدید 🔥
وقته پست های تخصصی تره ، بریم ؟

@Dagen_security

داستان یه xss که فقط روی گوگل کروم اجرا میشد ✍️

داستان از این قراره که من یه تارگت رو باز کردم ;
اولین کاری که معمولا میکنم اینه که گوگل دورکینگ رو انجام میدم تا به ادرس هایی برسم که توسط گوگل ایندکس شده و به نوعی در دسترسه ;

هدف من برای این سناریو پیدا کردن یه xss بود و تنها روشی که بتونیم این اسیپ پذیری رو پیدا کنیم و اکسپلیوتش کنیم اینه که بدونیم ورودی ما دقیقا کجا میشینه ؟

به عنوان یه هانتر باید یه مفهوم مهم رو بدونیم : صفحات مختلف یه وبسایت میتونن باعث آپدیت شدن و لود شدن جاوا اسکریپت های جدید بشن و توی این مورد هم باید برسی بشه که آیا ما میتونیم با پیدا کردن سورس ها و سرچ کردن سینک های خطرناک توی dom جایی رو پیدا کنیم که مستقیما پارامتر رو از آدرس بگیره و داخل سینک خطرناک قرار بده ؟ که میشه dom xss

توی سناریوی من وقتی وبسایت رو با ip آمریکا باز کردم یه منو و دکمه برای کلیک برای من بالای صفحه وجود داشت وقتی روش کلیک کردم :

Target/shops/models

منو رو میبرد یه شاپ لوازم آرایشی بدون هیچ‌ پارامتر اضافه تری !
چون این پیچ و صفحه فقط با اپی آمریکا باز میشد با این طرز تفکر که افراد کمتری روی این صفحه کار کردند جلو رفتم و
توی مرحله بعد یه فاز نسبتا سنگین پارامتر از نوع post,get انجام دادم , که در نتیجه یه کلمه کلیدی پیدا شد که ورودی من توی سورس صفحه رفلکت میشد :

IsOveride=test

مقدار تست توی یک تگ div رفلکت شده بود و تنها کاری که من باید میکردم این بود که تگ رو بریک کنم و اسکریپت خودمو اجرا کنم :

IsOveride=test</div><noscript>alert(origin)</noscript>

ولی تارگت یه چکر یا یه وف کاستوم داشت جلوی xss من رو میگرفت با این هشدار :

malicious request blocked

حالا وقت فرض گرفتنه , با خودم گفتم وف ممکنه وقتی تگ اسکریپت رو ببینه در جا منو بلاک کنه و شاید تارگت یه بلک لیست تعین کرده باشه ;

پس من بیام و تگ های مختلف رو امتحان کنم با این چیت : xss cheat sheet

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

target/shops/models?IsOveride=test</div><div onreadystatechange='alert(origin)'>

و بله بلک لیست بود ✅
و اون چکر یا وف دور خورد و پیلود من توی سورس نشست , همه چیز درست بود ولی یه جار کار میلنگید و پیلود اجرا نشد ❌

تصمیم گرفتم به جای فایر فاکس برم روی brave و safari تست کنم و در نهایت پیلود من فقط و فقط روی کروم اجرا شد و من تاییده reflected xss رو گرفتم👌🔥

ولی چرا این اتفاق افتاد ؟

@Dagen_security

ریشه امنیتی این باگ دقیقا چیه چرا پیلود من فقط روی کروم اجرا شد ؟

هرکدوم از مرورگر هایی که ما میشناسیمشون ممکنه از render engin برای لود کردن و پارس کردن کد js و html استفاده میکنند

Firefox —> Gecko
Safari —> webkit
chrome and edge —> Blink

پس مرورگر ها میتونن توی پیاده سازی تفاوت هایی داشته باشن و چون blink یه نسبت یه رندر انجین های دیگه تفاوت توی js engin,html parse داشته این فقط روی کروم جواب میده چون کروم داره از این انجین استفاده میکنه پس xss هم داریم .✅

بریم سراغ بخش پیلود :
همونطور که میدونید ایونت هندلر کارش اجرا کردن جاوااسکریپته ;

توی این پیلود اینونت هندلر اصلا برای div استاندارد نیست و از یه کلاس و ابجکت قدیمی اومده مثل (document,XMLHttpRequest) ولی blink این غیر استاندارد رو پارس میکنه و میگه :

تو اینو نوشتی ولی عیبی نداره من پارسش میکنم !
و این دقیقا میشه مغز اسیپ پذیری 👌

ولی مرورگر هایی مثل firefox و safari اینو پیلود رو نمیشناسن و ایگنورش میکنن .🫡


دقیقا توی متن گزارش نوشته شد :

following this link in the google chrome , xss will be popped up ;

@Dagen_security

سم کری نویسنده و هانتر تاپ هکروان یه تریک جذابی برای دور زدن otp توی کرانفراسش اراعه کرده , اون گفتش که :

فرض بگیریم ما یه فرمی داریم که وقتی ایمیل رو وارد میکنیم مثل هر لاگین معمولی دیگه ای یه otp کد یا همون کد تایید رو برای ما ارسال میکنه , حالا سم کری میگه وقتی میخوای otp کد رو وارد کنی , یه OTP اشتباه وارد کن و میبینی که مثلا 400 میگیری .

حالا برو همین ریکوست رو دوباره توی برپت کپچر کن و به جای مقدار OTP اینو قرار بده :

otp=../sms

و میبینی که دور میخوره :)

دلیل و منطقش چیه ؟

به عنوان یه هانتر چون همیشه بلک باکس تست میکنیم کار ما فرض گرفتنه فرض میکنیم : بکند یه سرور اینترنال داره مثل این :

http://internal-ip/sms/1234 — > 400 bad request

که کد تاییدی که وارد میکنی با اون اینترنال چک میشه , حالا اگه تویه مهاجم 1234 رو وارد کنی و کد اشتباه باشه از اینترنال یه 400 میاد ولی وقتی تو اینو وارد میکنی ../sms توی اینترنال این اتفاق میوفته :

http://internal-ip/sms/../sms

این یه مسیر میاد عقب و چون دایرکتوری sms توی اینترنال وجود داره پس تو از طرف اینترنال یه استاتوس کد 200 میگیری و otp رو بایپس میکنی :)

ایا همیشه جوابه ؟ نه
ایا همیشه اسم دایرکتوری sms هستش نه ! باید فاز کنی و بدستش بیاری
این سناریو فقط با وقتی جوابه که بکند سرور و پیاده سازی برنامه نویس بر اساس استاتوس کد چک رو انجام میده 🤝

امیدوارم درک کافی از این سناریو داشته باشید 🌷

@Dagen_security

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

@Dagen_security

عزیزانی که پی وی پیام داده بودند همه پیام ها جواب داده شد ✅

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

برای همین یه تصمیم گرفتم xmind owasp top 10 رو که خودم اول راهم با اون شروع کردم و صفر تا صد دانشمو داخلش نوشتم رو برای اعضای چنل پاپ کنم تا ازش استفاده کنید و به نوعی مرحله به مرحله با اون پیش برید و کار خودتون رو راحت تر کنید ;

برای دریافتش فقط به پشتیبان پیام بدید تا شرایط رو برای ارسال بگه خدمتتون 🙏👇

@bookmind369

چجوری dompurify رو دور زدم و از ناهمانگی با مرورگر باگ xss زدم ؟

خیلی خلاصه بریم سراغ اصل مطلب, چجوری این لایبری امن توی چه شرایطی و با چه پیلودی ناامن شد ؟
همونطور که میدونید و باید بدونید xss جزو باگ هایی که هیچ وقت تمومی نداره و روز به روز بیشتر هم میشه ولی یه باگی مثل sqli کلا ریت کشف اسیب پذیریش 1 درصده و داره منقرض میشه چون کتابخونه به اسم orm اونو به صورت کامل امن میکنه .
همونطور که ثابت شده xss کتابخونه ای و یا راه حلی برای امن شدنش نیومده که کاملا 100 درصد دقیق باشه و جلوشو بگیره .

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

سوال من اینه ایا ui جای درستی برای جلوگیری از پیلود مخرب جاوا اسکریپته ؟
بله , بهترین راه برای جلوگیری xss همون مرحله اخر و جلوگیری ازش توی Ui هست

اینجا دلوپر سایت میتونه از وف استفاده کنه میتونه از encoding های مختلف و .. استفاده کنه .

ولی بازم یه سوال مهم داریم که ایا کافیه ؟

ایا ممکن نیست اون وف با یه پیلود خاصی گیج بشه و دور بخوره ؟

قطعا ممکنه .!
اینو بدونید اخرین ورژن و نسخه نهایی پیلود شما توی dom میشینه نه سورس !

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

بریم سراغ سناریو اسیپ پذیر :

هفته پیش یه ریسرچ عمیق راجب mxss ها کردم روال کار این پیلود ها در واقع پیلود هاییه که با ترکیب کردن چند نوع تگ پیلود ساخته میشه و خروجی پیلود باعث xss میشه .

تارگت من از dompurify استفاده میکرد و فرض بگیرین یه قسمت سرچ معمولی داشت :

target/q=test

و وقتی یه پیلود وارد میکردم خودکار توسط dom تگ غیرمجاز برداشته میشد و پیلود اجرا نمیشد ❌

توی تحقیقاتم به یه پیلود مثل این رسیدم :

<nonoscript><style></nonoscript><img src=X onerror=alert(orgin)>

و من همینو توی پارامتر گذاشتم و xss اجرا شد و من الرت رو دیدم :)

سوالی که پیش میاد اینه که چرا XSS شد و چرا یه لایبرری امن با همچین پیلودی نا امن شد ؟

عدم توافق بین دو عنصر و یا مرورگر و DOMPURIFY باعث باگ من شد.

لایبرری dompurify این پیلود رو XSS نمی دید و نمیشناخت و اول تگ nonoscript رو میدید که باز شده و بعدش یه استایل وجود داره که باز شده پس ادامه پیلود داخل تگ استایله و nonoscript/ اجرا نمیشه و به عنوان یه ولیو بی ارزش در نظر گرفته میشه و بهش گیر داده نمیشه :

<style></nonoscript><img src=X onerror=alert(orgin)> —> dompurify

ولی وقتی این پیلود به dom مرورگر میرسه اول no noscript با هر ولیوی که داخلشه کنار میره و img اجرا میشه :

<img src=X onerror=alert(origin)> —> browser

هیچکدوم از این پارس ها بین مرورگر و این لایبرری نا امن نبود ولی فقط توافقی بین مرورگر و dom purify وجود نداشت این عدم ناهماهنگی بین دو عنصر امن باعث xss شد :)🌷

@Dagen_security

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

امیدوارم این کمک کنه تا یه فضای جذاب و بدرد بخور داشته باشیم که هم برای من و هم مخاطب این کانال مفید باشه ❤️🔥

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

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

در ضمن Xmind بالا میتونه موضوع تحقیقاتی خوبی براتون باشه , چرا اون پروتکشن خاص همیشه امنه ؟!
ریکشن و انرژی کم باعث از بین بردن و نیست شدن پست بعدی میشه.

@Dagen_security

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

پیام بالا رو بخونید👆

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

ولی 10 درصدی که عزم رو جزم میکنن و میرن سراغ خودخوان بودن و کتاب خوندن درسته که مسیر سخت تره و گمراه تره ولی به شما نظم میده و سختی که به شما میده شما رو تبدیل به یه فرد خود اموز میکنه که در ادامه اینقدی که مسیر بالا و پایین داشته بلاخره راه درستو پیدا میکنین

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

هوشمند باشید 🌷

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

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

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

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

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

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

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

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

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

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