نکات جالبی که خالق ++c می گه درباره اینکه حتا خودشم خیلی‌ از توابع رو حفظ نیست و سرچ می کنه

https://www.instagram.com/reel/DcJr4rzhpqx/?igsh=MTd4c2E3cHp4eXN3MQ==

مهندسی Heap در Firefox و تبدیل یک Use After Free به کنترل اجرای برنامه (CVE-2013-0753)

اگر تا حالا درباره Use After Free یا UAF شنیده باشی احتمالا میدونی مشکل اصلی چیه یک Object داخل حافظه ساخته میشه و بعد حافظه اون Object آزاد میشه اما یک Pointer یا Reference هنوز به همون آدرس قبلی اشاره میکنه برای درک بهترش تصور کن یک نفر خونه اش رو ترک کرده و خونه کاملا تخلیه شده اما آدرس اون خونه هنوز داخل دفترچه یک نفر باقی موند. اگر شخص دیگری بیاد و دقیقا همون خونه رو اجاره کنه صاحب دفترچه هنوز فکر میکنه صاحب قبلی اونجاست ولی در واقع فرد جدید داخل خونه قرار گرفته. در UAF هم تقریبا همین اتفاق میفته برنامه فکر میکنه هنوز داره با Object قبلی کار میکنه اما اون حافظه ممکنه توسط داده جدیدی که مهاجم کنترل میکنه اشغال شده باشه

اما اینجا یک مشکل بزرگ وجود داره مهاجم معمولا نمیدونه حافظه ای که برنامه به یک Object اختصاص میده دقیقا کجاست. مدیریت Heap توسط Memory Allocator انجام میشه و Allocator خودش تصمیم میگیره هر Allocation کجا قرار بگیره بنابراین مهاجم باید کاری کنه که این وضعیت تا حد ممکن قابل پیش بینی بشه. اینجا مفهوم Heap Spray وارد میشه فرض کن یک انبار خیلی بزرگ داری و مسئول انبار هر بار که چیزی بخوای خودش تصمیم میگیره اون وسیله رو کجا بذاره اگر فقط یک وسیله سفارش بدی هیچ ایده ای نداری کجا قرار میگیره اما اگر هزاران وسیله مشابه سفارش بدی کم کم بخش بزرگی از انبار توسط وسایل تو پر میشه و احتمال اینکه وسیله بعدی در یکی از قسمت هایی قرار بگیره که تو از قبل آماده کردی بیشتر میشه. Heap Spray هم تقریبا همین ایده رو دنبال میکنه. مهاجم تعداد زیادی Allocation ایجاد میکنه تا Heap به شکل خاصی دربیاد و احتمال قرار گرفتن داده های مورد نظر در محدوده مناسب افزایش پیدا کنه.

در نمونه قدیمی Firefox آسیب پذیری مربوط به XMLSerializer بود مشکل یک Use After Free در Object مربوط به XMLSerializer بود اما برای Exploit کردنش فقط پیدا کردن UAF کافی نبود مهاجم باید حافظه رو طوری آماده میکرد که بعد از آزاد شدن Object مورد نظر کنترل حافظه به دست خودش بیفته برای همین Exploit در چند مرحله انجام میشد.

در مرحله اول یک Heap Spray بزرگ انجام میشد تعداد زیادی String بزرگ ساخته میشد تا Heap به اندازه مشخصی گسترش پیدا کنه در این مثال مهاجم انتظار داشت داده های خودش در محدوده ای مثل 0x117012000 قرار بگیرن. بعد داخل داده های Spray شده مقادیری قرار داده میشد که در ادامه Exploit اهمیت داشتن یکی از مهمترین قسمت ها مربوط به RIP بود RIP یا Instruction Pointer رو میتونی مثل آدرس مقصد یک راننده تصور کنی CPU دائما باید بدونه دستور بعدی رو از کجا بخونه و RIP هم همین اطلاعات رو نگه میداره اگر مهاجم بتونه مقداری که در نهایت به عنوان مقصد اجرای برنامه استفاده میشه رو کنترل کنه میتونه مسیر اجرای برنامه رو تغییر بده در این Exploit حتی یک مقدار مشخص مثل 0x4142434445464748 قرار داده شده بود که بیشتر برای اثبات کنترل جریان اجرا استفاده میشد

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

اما هنوز یک مرحله مهم باقی مونده بود. مهاجم باید کاری میکرد که حافظه آزاد شده دوباره با Allocation های خودش پر بشه اینجا مرحله دوم شروع میشه این بار Allocation های کوچک تر با اندازه 128 بایت ایجاد میشن چرا 128 بایت؟ چون Object مورد هدف هم اندازه ای در همین حدود داشت. دوباره همون انبار رو تصور کن. مهاجم تعداد زیادی جعبه دقیقا با اندازه 128 بایت کنار هم قرار میده و بعد یکی در میان جعبه ها رو خالی میکنه. در نتیجه چیزی شبیه جعبه و جای خالی و جعبه و جای خالی ایجاد میشه این جای خالی ها همون Heap Hole هستن.

اما یک نکته مهم وجود داره وقتی JavaScript یک Object رو Delete میکنه الزاما حافظه همون لحظه توسط سیستم آزاد نمیشه SpiderMonkey موتور JavaScript Firefox هست و خودش مدیریت Garbage Collection رو انجام میده بنابراین مهاجم باید Garbage Collector رو تحریک کنه برای این کار تعداد زیادی Allocation جدید ایجاد میشه با افزایش شدید مصرف Heap موتور JavaScript مجبور میشه Garbage Collection انجام بده و قسمت هایی که دیگر استفاده نمیشن رو جمع آوری کنه حالا Heap به شکل مورد نظر نزدیک شده تعداد زیادی فضای خالی 128 بایتی داریم که دقیقا برای Object هایی با همین اندازه مناسب هستن

مرحله سوم از اینجا شروع میشه Firefox بسیاری از ساختارهای داخلی خودش رو با C++ پیاده سازی کرده HTML Element ها هم توسط Object های C++ پشتیبانی میشن در این مثال HTMLUnknownElement اندازه ای برابر با 128 بایت داشت و دقیقا همان اندازه ای بود که مهاجم برای Heap Hole ها آماده کرده بود
بنابراین Allocation های جدید میتونستن وارد همین فضاهای خالی بشن. اینجا اتفاق مهمی رخ میده. مهاجم تلاش میکنه حافظه ای رو که قبلا متعلق به Object اصلی بوده با داده ای که خودش کنترل میکنه دوباره اشغال کنه این یعنی Pointer قدیمی هنوز به همان آدرس اشاره میکنه اما محتوای آن آدرس دیگر محتوای Object قبلی نیست. در واقع داده جدید مهاجم آنجا قرار گرفته این همان جاییه که UAF از یک Crash ساده میتونه به یک Exploitation جدی تبدیل بشه.

اما یک مفهوم مهم دیگر هم وجود داره و اون VTable یا Virtual Function Table هست در C++ بعضی Class ها دارای Virtual Function هستن و برای این Object ها جدولی وجود داره که آدرس Function های مربوط به Object رو نگه میداره میتونی VTable رو مثل یک دفترچه راهنما تصور کنی که داخلش نوشته شده اگر برنامه خواست این Function رو اجرا کن به این آدرس برو و اگر خواست Function دیگری رو اجرا کن به آدرس دیگری برو. اگر مهاجم بتونه این جدول یا Pointer مربوط به اون رو خراب کنه میتونه مسیر اجرای برنامه رو تغییر بده.

در این Exploit آسیب پذیری در نهایت باعث میشد Objectی که توسط mNextSibling مورد اشاره قرار گرفته بود بعد از آزاد شدن همچنان مورد استفاده قرار بگیره مهاجم با آماده سازی Heap تلاش میکرد حافظه جدیدی رو در همان محل قرار بده. در نتیجه Firefox به چیزی دسترسی پیدا میکرد که تصور میکرد Object قبلیه در حالی که محتوای آن حافظه توسط مهاجم کنترل شده بود. بعد یک دستور مهم مثل callq *0x5f8(%rax) میتونست از داده موجود در حافظه به عنوان یک مقصد برای اجرای Function استفاده کنه.
اگر مقدار مورد استفاده در این محاسبه تحت کنترل مهاجم باشه جریان اجرای برنامه هم میتونه تحت تاثیر قرار بگیره.

پس کل داستان رو میشه اینطوری دید. UAF باعث میشه برنامه هنوز به یک Object آزاد شده اشاره کنه Heap Spray کمک میکنه وضعیت حافظه قابل پیش بینی تر بشه Heap Hole باعث میشه فضاهای مناسب برای Allocation های بعدی آماده بشن Garbage Collector باعث میشه این فضاها واقعا قابل استفاده مجدد بشن Allocation جدید میتونه وارد فضای Object قبلی بشه مهاجم در نتیجه کنترل بیشتری روی محتوای حافظه پیدا میکنه و در نهایت اگر ساختارهایی مثل VTable یا Function Pointer تحت کنترل قرار بگیرن میشه جریان اجرای برنامه رو تغییر داد.

پس Heap Spray خودش آسیب پذیری نیست Heap Spray بیشتر شبیه مرتب کردن زمین بازیه آسیب پذیری اصلی UAF هست اما برای تبدیل اون UAF به یک Exploit قابل اعتماد باید حافظه رو با دقت آماده کرد. مهاجم عملا سعی میکنه Heap رو مثل یک صفحه شطرنج بچینه. میدونه یک مهره قراره از صفحه خارج بشه پس از قبل تلاش میکنه خانه خالی رو طوری آماده کنه که مهره خودش بتونه دقیقا همونجا قرار بگیره. وقتی برنامه دوباره به آدرس قدیمی مراجعه میکنه ممکنه به جای Object قبلی با داده ای روبرو بشه که مهاجم کنترلش میکنه. این دقیقا یکی از تفاوت های مهم بین پیدا کردن یک Memory Corruption Bug و ساختن یک Exploit واقعی محسوب میشه. پیدا کردن Crash فقط شروع ماجراست. قسمت سخت تر اینه که بتونی رفتار Memory Allocator رو تا حد ممکن قابل پیش بینی کنی و از یک وضعیت غیرقابل اعتماد در حافظه به کنترل جریان اجرای برنامه برسی.

خوب مطالعه کنید مطالب پیش پا افتاده شاید باشه برای بعضی ها ولی دیدتون رو باز میکنه و راه رو برای پیدا کردن اولین cve براتون باز میشه👌

Public & Private tricks
OAuth attacks


https://www.instagram.com/p/DcOIQ30CGGL/?igsh=MXF0cXluNDM2ancxdg==&igsi=MXF0cXluNDM2ancxdg==

یه اتکی داریم به این DNS Ampilfication برای dos / ddos

سادست ولی ایدش قشنگه
خلاصش اینه یک کوئری میفرسته به سمت dns server و ولی جوابشو با ip spoofing میفرسته به سمت تارگت

حالا این درخواستی هم که میفرستنو با یکسری تکنیک جوابشو بزرگ میکنن تا فشار بیشتری به تارگت بیاد🤗

Session Fixation

یکی از آسیب پذیری های مربوط به مدیریت Session هست که در اون مهاجم قبل از اینکه قربانی Login کنه یک Session ID رو میگیره و کاری میکنه قربانی با همون Session ID وارد حسابش بشه سناریو خیلی ساده است مهاجم وارد سایت میشه و یک Session میگیره مثلا SESSIONID=12345 مهاجم این Session ID رو میدونه ولی هنوز احراز هویت نشده حالا مهاجم کاری میکنه که مرورگر قربانی از همین Session ID استفاده کنه قربانی وارد سایت میشه و Username و Password خودش رو وارد میکنه سرور هم Session موجود یعنی 12345 رو به عنوان Session احراز هویت شده قربانی ثبت میکنه اینجا مشکل شروع میشه چون مهاجم از قبل Session ID یعنی 12345 رو میدونسته پس مهاجم همون Session ID رو برای درخواست های خودش میفرسته SESSIONID=12345 سرور هم چون این Session متعلق به کاربر احراز هویت شده هست درخواست مهاجم رو هم به عنوان درخواست قربانی در نظر میگیره در نتیجه مهاجم بدون اینکه Password قربانی رو داشته باشه میتونه به Session قربانی دسترسی پیدا کنه راه حل اصلی اینه که سرور بعد از Login موفق Session ID رو تغییر بده مثلا قبل از Login SESSIONID=12345 و بعد از Login SESSIONID=98765 در این حالت Session قبلی دیگه معتبر نیست و مهاجم نمیتونه از Session ID که از قبل میشناخته استفاده کنه تفاوتش با Session Hijacking هم اینه که در Session Hijacking مهاجم اول Session قربانی رو میدزده ولی در Session Fixation مهاجم Session رو از قبل میشناسه و قربانی رو مجبور میکنه با همون Session وارد حسابش بشه

یه کانسپتی وجود داره به اسم Timing Attack خیلیا شنیدین اسمشو و حتی تونستید باهاش کلی کار مختلف کنید مخصوصا برای تست های Broken Authentication استفاده میشه شما میتونید برای حدس زدن کوکی و یا توکن هم از این روش استفاده کنید مثلا ABCXXX سمت سرور ارسال میکنید اگر سرور مقدار واقعی رو ABCDEF در نظر بگیره ممکنه نحوه مقایسه به این شکل باشه A با A برابره پس برو کاراکتر بعدی B با B برابره پس برو بعدی C با C برابره اما X با D برابر نیست پس همینجا متوقف شو حالا اگر مثلا ABXXXX بفرستید سرور خیلی زودتر متوجه میشه که مقدار اشتباهه چون فقط A و B درست بودن و در کاراکتر سوم متوقف میشه اما اگر ABCXXX بفرستید سرور سه کاراکتر اول رو درست پیدا کرده و یک مرحله بیشتر جلو میره در نتیجه ممکنه زمان پاسخ حتی به اندازه چند نانوثانیه یا میکروثانیه متفاوت بشه حالا این اختلاف زمان به تنهایی هیچ ارزشی نداره چون شبکه خودش پر از نویزه ولی مهاجم میتونه تعداد خیلی زیادی درخواست ارسال کنه و با میانگین گرفتن و مقایسه زمان پاسخ ها کم کم متوجه بشه کدوم حدس باعث شده برنامه بیشتر جلو بره مثلا برای کاراکتر اول همه حالت ها رو امتحان میکنه Axxxxx Bxxxxx Cxxxxx Dxxxxx و اگر C به طور میانگین کمی زمان بیشتری گرفت حدس میزنه کاراکتر اول C هست بعد میره سراغ کاراکتر دوم و CAXXXX CBXXXX CCXXXX CDXXXX و همین روند رو ادامه میده تا کم کم Token رو کاراکتر به کاراکتر استخراج کنه به این حمله Timing Attack میگیم چون مهاجم بدون اینکه مستقیما مقدار Secret رو ببینه از زمان اجرای برنامه اطلاعاتی درباره اون Secret به دست میاره برای همین وقتی داریم مقادیر حساس مثل Session Token یا CSRF Token رو مقایسه میکنیم نباید از مقایسه معمولی استفاده کنیم چون خیلی از پیاده سازی ها به محض پیدا کردن اولین کاراکتر اشتباه متوقف میشن و بهتره از Constant Time Comparison استفاده کنیم مثلا در Java میتونیم از MessageDigest.isEqual استفاده کنیم تا مقایسه به شکلی انجام بشه که اختلاف زمان قابل استفاده ای بر اساس محل اولین کاراکتر اشتباه ایجاد نکنه البته Timing Attack همیشه به این معنی نیست که حتما میشه یک Token رو از روی اینترنت استخراج کرد چون نویز شبکه و شرایط اجرا خیلی تاثیر دارن ولی از نظر امنیتی وقتی داریم Secret رو مقایسه میکنیم نباید یک کانال جانبی غیرضروری برای مهاجم ایجاد کنیم

سلام به همه 👋🏻

شارینگان برای تست در دسترسه.
الان می‌تونید یک اکانت رایگان بگیرید و خودتون امتحانش کنید.

🔴 شارینگان چیه؟

شارینگان، مرکز پایش مداوم Attack Surface شماست.

به‌جای اینکه فقط یک بررسی لحظه‌ای از Attack Surface داشته باشید، شارینگان به‌صورت مداوم تغییراتش رو بررسی می‌کنه و موارد مهم رو بهتون اطلاع می‌ده.

🔎 برخی از قابلیت‌ها:

• Continuous Subdomain & Asset Discovery
• DNS Monitoring & Resolution
• HTTP Service Fingerprinting
• Attack Surface Change Detection
• Security Signals
• Telegram Alerts
• MCP / AI Agent Access

🎯 چرا Continuous Monitoring؟

چون Attack Surface شما ثابت نمی‌مونه.

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

شارینگان این تغییرات رو به‌صورت مداوم بررسی می‌کنه و تغییرات مهم رو بهتون اطلاع می‌ده؛ تا لازم نباشه دائماً Attack Surface رو به‌صورت دستی بررسی کنید.

💬 اگه توی زمینه Bug Bounty، Recon یا Security Research فعالیت می‌کنید، خوشحال می‌شیم شارینگان رو تست کنید و نظرتون رو با ما به اشتراک بذارید.

بعد از تست، اگه دیدید شارینگان برای Workflow شما مفیده، می‌تونید پلن موردنظرتون رو انتخاب کنید و اکانتتون رو خریداری کنید.

🌐 Website: SharinganX.ir
📢 Telegram: @SharinganUpdates
📸 Instagram: iSharinganX

سلام کارشون خوب بوده میتونید حتی ایجنت خودتون رو وصل کنید بهش👌

یکی از این سایتایی که قبول دارم
https://bugbountyscam.com/
هرجایی اسکم کرد میتونید ریپورت شیر کنید با بقیه همه با خبر بشن

Mesh network cache poisoning: exploiting BitChat's BLE authentication
Blog: https://barghest.asia/blog/bitchat-cache-poisoning/
PoC: https://github.com/BARGHEST-ngo/PoC_Bitchat1.15.0_iOS-BLEcache-poisoning

https://medium.com/@nexovir/one-click-full-account-takeover-via-chained-xss-bypassing-csp-by-pivoting-through-a-trusted-4f811e6ae8ee

رایتاپ از یکی از آسیب پذیری هایی که چند وقت پیش chain کردم نکات آموزشی خوبی گفتم مخصوصا برای کسایی که تازه شروع کردند شاید بتونه مفید باشه که اگر هرچیزی ‌جلوتون رو گرفت چطوری بایپس کنید مخصوصا برای chain کردن آسیب پذیری هایی که medium هستند به critical

چون استقالبتون خوب بود یک گزارش دیگه هم براتون میزارم از chain آسیب پذیری SSRF و بایپس هایی که داشت از low impact به high impact که نمونش رو جایی احتمالا نشنیدید

شده تا حالا یک سایتی که SSL نداره رو بخواید باز کنید ولی مرورگر اجازه نده ؟
اینجا یه سئوالی پیش میاد که چرا نمیذاره ؟ اصلا چرا بعضیا رو اجازه میده باز کنم ولی بعضیا رو نمیذاره ؟


فرقش در پروتکلی به نام HSTS هستش
برای اینکه بگیم HSTS چیه باید اول بفهمیم مشکل چی بوده که امدن اینو درست کردن

یکسری حملات هستن که بهشون میگن Downgrade Attacks
یعنی هکر میاد و یه کاری میکنه که شما مجبور بشید از یه پروتکل یا مسیری که سطح پایینتری از امنیت رو داره استفاده کنید

حالا یکی از این حملات میشه SSL Stripping
تو این حمله هکر بین شما و سایت قرار گرفته ( MITM)
و زمانی که شما میخواد به سایت وصل بشید شما رو مجبور میکنه که از HTTP استفاده کنید
چون اگه HTTPS باشه نمیتونه ببینه چی رد میشه


حالا واسه حل این مشکل امدن و HSTS رو درست کردن
این پروتکل میاد و تو درخواست اولی که کاربر میزنه میگه فقط با HTTPS میتونی بهم وصل بشی ( این درخواست هم میتونه مورد حمله قرار بگیره ) و نمیذاره ارتباط HTTP برقرار بشه

یعنی درخواست اول رو شما HTTP میزنی و جوابی که برمیگرده یکسری هدر و ریدایرکت شدن به آدرس که SSL داره هستش

این هدر هایی که برمیگرده هم توسط مرورگر ذخیره میشه  تا دفعه های بعدی اصلا نیاز نباشه شما اون درخواست اول رو با HTTP بزنید و از همون اول با HTTPS با سایت صحبت کنید
هدر HSTS مثل اینه

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

میگه تا چه مدت این سیاست ها برای سایت ذخیره بشه
ساب دامین ها هم باشن یا نه



حالا یه قانونی داخل مرورگرا هست
تمام سایت هایی که از HSTS استفاده میکنن در صورت تایید کاربر هم اجازه استفاده از HTTP رو ندارن

2{FUZZ}{FUZZ},000 تومن

JADX MCP: a MCP (Model Context Protocol) server as a jadx-gui plugin

https://github.com/0xdad0/jadx-mcp

سلام دوستان اقا چند وقت پیش داشتم درباره آسیب پذیری open redirect می خوندم.
یهو به ذهنم رسید شروع کنم به ساختن lab های لول بندی شده (php) که بهتر بتونم این باگو درک کنم.
از لول ۱ تا ۱۰ لول بندی کردم از آسان به سخت.
و به شما یاد می ده چجوری با استفاده از open redirect به SSRF , XSS , CRLF , OAuth Token theft برسید.
تمام level هارو بر اساس چیزای که توی real world بوده طراحی کردم.
سورس کد هر لول هم در دسترس هست و حتا راهنما هایی هم وجود داره.

دوس داستید یه سر بزنید و علم خودتونو محک بزنید.

https://github.com/zoly-zoly/Open-Redirect-Lab

از AI خواستم برام یه نمودار بسازه که از ۱ تا ۱۹ سپتامبر نشون بده بر اساس گزارش‌هام عملکردم چطور بوده چند درصد از کارهام با کمک ایجنت انجام شده و بیشتر برای چه بخش‌هایی ازش استفاده کردم


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

https://x.com/nexovir/status/2094671702349217964?s=52