🔐 SSL/TLS و نصب Certificate؛ HTTPS دقیقاً چطور کار میکنه؟
وقتی وارد یه سایت میشی و اول آدرسش
حالا وسط این ماجرا یه چیزی داریم به اسم Certificate یا گواهی دیجیتال. Certificate در واقع به مرورگر کمک میکنه بفهمه سروری که بهش وصل شده واقعاً متعلق به همون دامنه‌ایه که کاربر وارد کرده.
مثلاً وقتی وارد
داخل Certificate معمولاً اطلاعاتی مثل نام دامنه، Public Key، صادرکننده گواهی، تاریخ اعتبار و اطلاعات مربوط به امضای دیجیتال وجود داره.
اگر همه‌چیز درست باشه، فرآیند TLS Handshake ادامه پیدا میکنه. در این مرحله کلاینت و سرور روی کلیدهای لازم برای ارتباط امن توافق میکنن و بعد از برقراری ارتباط، داده‌های اصلی با Session Key و رمزنگاری متقارن منتقل میشن؛ چون برای انتقال حجم زیادی از اطلاعات سریع‌تر و بهینه‌تره.
یه اشتباه رایج اینه که فکر کنیم کل اطلاعات HTTPS با Private Key رمزنگاری میشه. ❌
در واقع Private Key برای عملیات مربوط به احراز هویت و Handshake استفاده میشه و قرار نیست تمام ترافیک HTTPS با اون رمزنگاری بشه. بعد از برقراری Session، ارتباط اصلی با کلیدهای Session انجام میشه.
برای راه‌اندازی HTTPS روی سرور معمولاً با سه بخش اصلی سروکار داریم:
🔹 Certificate → گواهی دیجیتال سایت
🔹 Private Key → کلید خصوصی مربوط به Certificate
🔹 Certificate Chain → زنجیره گواهی‌ها، مخصوصاً Intermediate Certificateها
برای گرفتن Certificate میتونی از CAهایی مثل Let's Encrypt استفاده کنی. Let's Encrypt یکی از گزینه‌های رایج و رایگان برای HTTPS هست و امکان تمدید خودکار Certificateها رو هم فراهم میکنه.
🟢 اگر Nginx داشته باشی
بعد از دریافت Certificate باید مسیر Certificate و Private Key رو در تنظیمات سایت مشخص کنی. معمولاً چیزی شبیه این داریم:
برای Certificate و:
برای Private Key.
بعد از تغییر تنظیمات، Nginx رو Reload می‌کنی تا تنظیمات جدید اعمال بشن و سرور بتونه روی پورت
🟣 در IIS ویندوز
Certificate معمولاً داخل Windows Certificate Store وارد میشه و بعد در IIS Manager از قسمت Binding سایت، پروتکل HTTPS و Certificate موردنظر رو انتخاب می‌کنی.
🔴 در Apache
Certificate و Private Key داخل Virtual Host مربوط به HTTPS تنظیم میشن و بعد سرویس Apache Reload یا Restart میشه.
⚠️ Private Key شوخی‌بردار نیست!
Certificate عمومی مشکلی نداره و طبیعتاً برای کلاینت ارسال میشه، اما Private Key باید فقط روی سرور باقی بمونه و با Permission مناسب محافظت بشه.
اگر Private Key لو بره، امنیت Certificate و ارتباطات مربوط به اون میتونه به خطر بیفته.
یه بخش مهم دیگه هم Certificate Chain هست.
گاهی Certificate اصلی روی سرور نصب شده، ولی مرورگر همچنان خطای SSL میده. یکی از دلایل رایج این مشکل اینه که سرور Intermediate Certificateها رو درست ارسال نمی‌کنه و مرورگر نمیتونه زنجیره اعتماد رو تا Root CA کامل کنه.
🔎 بعد از نصب Certificate هم بهتره فقط به سبز شدن قفل مرورگر اکتفا نکنی و تنظیمات TLS رو تست کنی.
موارد مهمی که باید بررسی بشن:
▪️ نسخه‌های TLS
▪️ Cipher Suiteها
▪️ Certificate Chain
▪️ تاریخ انقضای Certificate
▪️ SNI
▪️ تنظیمات HTTP/2
▪️ تنظیمات HTTP/3
▪️ وضعیت Private Key
▪️ پیکربندی صحیح HTTPS
در سرورهای امروزی بهتره TLS 1.2 و TLS 1.3 فعال باشن و نسخه‌های قدیمی مثل TLS 1.0 و TLS 1.1 غیرفعال بشن.
برای بررسی و عیب‌یابی TLS هم ابزارهایی مثل OpenSSL و سرویس‌های تست TLS می‌تونن اطلاعات خیلی خوبی درباره Certificate، Chain، Cipherها و تنظیمات امنیتی سرور بهت بدن.
وقتی وارد یه سایت میشی و اول آدرسش
https:// می‌بینی، یعنی ارتباط بین مرورگر تو و سرور روی TLS رمزنگاری شده. خیلی‌ها هنوز بهش SSL میگن، ولی از نظر فنی SSL یه استاندارد قدیمی و منسوخ‌شده‌ست و چیزی که امروزه استفاده میکنیم TLS هست.حالا وسط این ماجرا یه چیزی داریم به اسم Certificate یا گواهی دیجیتال. Certificate در واقع به مرورگر کمک میکنه بفهمه سروری که بهش وصل شده واقعاً متعلق به همون دامنه‌ایه که کاربر وارد کرده.
مثلاً وقتی وارد
example.com میشی، مرورگر با سرور ارتباط برقرار میکنه و سرور Certificate خودش رو ارسال میکنه. مرورگر بعدش چند چیز مهم رو بررسی میکنه؛ مثلاً اینکه Certificate برای همین دامنه صادر شده باشه، تاریخ اعتبارش نگذشته باشه، امضای دیجیتالش معتبر باشه و زنجیره اعتمادش به یک Certificate Authority یا CA معتبر برسه.داخل Certificate معمولاً اطلاعاتی مثل نام دامنه، Public Key، صادرکننده گواهی، تاریخ اعتبار و اطلاعات مربوط به امضای دیجیتال وجود داره.
اگر همه‌چیز درست باشه، فرآیند TLS Handshake ادامه پیدا میکنه. در این مرحله کلاینت و سرور روی کلیدهای لازم برای ارتباط امن توافق میکنن و بعد از برقراری ارتباط، داده‌های اصلی با Session Key و رمزنگاری متقارن منتقل میشن؛ چون برای انتقال حجم زیادی از اطلاعات سریع‌تر و بهینه‌تره.
یه اشتباه رایج اینه که فکر کنیم کل اطلاعات HTTPS با Private Key رمزنگاری میشه. ❌
در واقع Private Key برای عملیات مربوط به احراز هویت و Handshake استفاده میشه و قرار نیست تمام ترافیک HTTPS با اون رمزنگاری بشه. بعد از برقراری Session، ارتباط اصلی با کلیدهای Session انجام میشه.
برای راه‌اندازی HTTPS روی سرور معمولاً با سه بخش اصلی سروکار داریم:
🔹 Certificate → گواهی دیجیتال سایت
🔹 Private Key → کلید خصوصی مربوط به Certificate
🔹 Certificate Chain → زنجیره گواهی‌ها، مخصوصاً Intermediate Certificateها
برای گرفتن Certificate میتونی از CAهایی مثل Let's Encrypt استفاده کنی. Let's Encrypt یکی از گزینه‌های رایج و رایگان برای HTTPS هست و امکان تمدید خودکار Certificateها رو هم فراهم میکنه.
🟢 اگر Nginx داشته باشی
بعد از دریافت Certificate باید مسیر Certificate و Private Key رو در تنظیمات سایت مشخص کنی. معمولاً چیزی شبیه این داریم:
ssl_certificateبرای Certificate و:
ssl_certificate_keyبرای Private Key.
بعد از تغییر تنظیمات، Nginx رو Reload می‌کنی تا تنظیمات جدید اعمال بشن و سرور بتونه روی پورت
443 درخواست‌های HTTPS رو دریافت کنه.🟣 در IIS ویندوز
Certificate معمولاً داخل Windows Certificate Store وارد میشه و بعد در IIS Manager از قسمت Binding سایت، پروتکل HTTPS و Certificate موردنظر رو انتخاب می‌کنی.
🔴 در Apache
Certificate و Private Key داخل Virtual Host مربوط به HTTPS تنظیم میشن و بعد سرویس Apache Reload یا Restart میشه.
⚠️ Private Key شوخی‌بردار نیست!
Certificate عمومی مشکلی نداره و طبیعتاً برای کلاینت ارسال میشه، اما Private Key باید فقط روی سرور باقی بمونه و با Permission مناسب محافظت بشه.
اگر Private Key لو بره، امنیت Certificate و ارتباطات مربوط به اون میتونه به خطر بیفته.
یه بخش مهم دیگه هم Certificate Chain هست.
گاهی Certificate اصلی روی سرور نصب شده، ولی مرورگر همچنان خطای SSL میده. یکی از دلایل رایج این مشکل اینه که سرور Intermediate Certificateها رو درست ارسال نمی‌کنه و مرورگر نمیتونه زنجیره اعتماد رو تا Root CA کامل کنه.
🔎 بعد از نصب Certificate هم بهتره فقط به سبز شدن قفل مرورگر اکتفا نکنی و تنظیمات TLS رو تست کنی.
موارد مهمی که باید بررسی بشن:
▪️ نسخه‌های TLS
▪️ Cipher Suiteها
▪️ Certificate Chain
▪️ تاریخ انقضای Certificate
▪️ SNI
▪️ تنظیمات HTTP/2
▪️ تنظیمات HTTP/3
▪️ وضعیت Private Key
▪️ پیکربندی صحیح HTTPS
در سرورهای امروزی بهتره TLS 1.2 و TLS 1.3 فعال باشن و نسخه‌های قدیمی مثل TLS 1.0 و TLS 1.1 غیرفعال بشن.
برای بررسی و عیب‌یابی TLS هم ابزارهایی مثل OpenSSL و سرویس‌های تست TLS می‌تونن اطلاعات خیلی خوبی درباره Certificate، Chain، Cipherها و تنظیمات امنیتی سرور بهت بدن.
🍯 Honeypot چیست؟
Honeypot
یا «سیستم طعمه» یک سیستم یا سرویس عمداً آسیب‌پذیر یا جذاب است که در شبکه قرار می‌گیرد تا مهاجم را به سمت خودش بکشاند.
ایده‌اش خیلی ساده‌ست: به‌جای اینکه منتظر باشیم مهاجم وارد سرور اصلی بشه، یک سیستم فیک جلوی دستش می‌ذاریم تا اگر اسکن کرد، لاگین کرد یا حمله‌ای انجام داد، فعالیتش ثبت و تحلیل بشه.
مثلاً فرض کن توی شبکه چندتا سرور واقعی داری و کنار اون‌ها یک سرور Honeypot هم قرار میدی که ظاهراً روی خودش سرویس‌هایی مثل SSH، HTTP یا FTP داره. مهاجم وقتی شبکه رو اسکن میکنه، ممکنه به این سیستم برسه و فکر کنه یک سرور واقعی پیدا کرده.
از اینجا به بعد Honeypot شروع میکنه به ثبت اطلاعاتی مثل:
🔹 IP مهاجم
🔹 پورت‌ها و سرویس‌هایی که بررسی کرده
🔹 نام کاربری و رمزهایی که امتحان کرده
🔹 دستورات و فعالیت‌های انجام‌شده
🔹 روش‌ها و ابزارهای مورد استفاده مهاجم
🔹 زمان و الگوی حمله
نکته مهم اینه که Honeypot معمولاً سیستم اصلی سازمان نیست؛ بلکه یک محیط کنترل‌شده برای مشاهده رفتار مهاجمه.
🧠 یک مثال خیلی ساده
پس Honeypot فقط برای گرفتن مهاجم نیست؛ یکی از کاربردهای مهمش اینه که بفهمیم مهاجم چطور فکر میکنه، چه چیزی اسکن میکنه و از چه تکنیک‌هایی استفاده میکنه.
🔥 انواع Honeypot
Low-Interaction:
ساده‌تره و فقط سرویس‌ها و رفتارهای محدودی رو شبیه‌سازی میکنه؛ ریسک کمتر و راه‌اندازی راحت‌تری داره.
High-Interaction:
یک محیط خیلی واقعی‌تر در اختیار مهاجم قرار میده تا رفتار و تکنیک‌هاش با جزئیات بیشتری قابل تحلیل باشه؛ ولی مدیریت و ایمن‌سازی اون سخت‌تره.
⚠️ نکته امنیتی
Honeypot
نباید تبدیل به راه ورود به شبکه اصلی بشه. باید کاملاً ایزوله و کنترل‌شده باشه، چون اگر مهاجم اون رو تحت کنترل بگیره، ممکنه از همون سیستم برای حمله به بخش‌های دیگه استفاده کنه.
Honeypot
یا «سیستم طعمه» یک سیستم یا سرویس عمداً آسیب‌پذیر یا جذاب است که در شبکه قرار می‌گیرد تا مهاجم را به سمت خودش بکشاند.
ایده‌اش خیلی ساده‌ست: به‌جای اینکه منتظر باشیم مهاجم وارد سرور اصلی بشه، یک سیستم فیک جلوی دستش می‌ذاریم تا اگر اسکن کرد، لاگین کرد یا حمله‌ای انجام داد، فعالیتش ثبت و تحلیل بشه.
مثلاً فرض کن توی شبکه چندتا سرور واقعی داری و کنار اون‌ها یک سرور Honeypot هم قرار میدی که ظاهراً روی خودش سرویس‌هایی مثل SSH، HTTP یا FTP داره. مهاجم وقتی شبکه رو اسکن میکنه، ممکنه به این سیستم برسه و فکر کنه یک سرور واقعی پیدا کرده.
از اینجا به بعد Honeypot شروع میکنه به ثبت اطلاعاتی مثل:
🔹 IP مهاجم
🔹 پورت‌ها و سرویس‌هایی که بررسی کرده
🔹 نام کاربری و رمزهایی که امتحان کرده
🔹 دستورات و فعالیت‌های انجام‌شده
🔹 روش‌ها و ابزارهای مورد استفاده مهاجم
🔹 زمان و الگوی حمله
نکته مهم اینه که Honeypot معمولاً سیستم اصلی سازمان نیست؛ بلکه یک محیط کنترل‌شده برای مشاهده رفتار مهاجمه.
🧠 یک مثال خیلی ساده
مهاجم
│
Network Scan
│
▼
┌───────────────┐
│ Honeypot │
│ SSH / HTTP │
└───────┬───────┘
│
ثبت فعالیت مهاجم
│
▼
┌───────────────┐
│ SIEM / SOC │
│ تحلیل لاگ‌ها │
└───────────────┘
پس Honeypot فقط برای گرفتن مهاجم نیست؛ یکی از کاربردهای مهمش اینه که بفهمیم مهاجم چطور فکر میکنه، چه چیزی اسکن میکنه و از چه تکنیک‌هایی استفاده میکنه.
🔥 انواع Honeypot
Low-Interaction:
ساده‌تره و فقط سرویس‌ها و رفتارهای محدودی رو شبیه‌سازی میکنه؛ ریسک کمتر و راه‌اندازی راحت‌تری داره.
High-Interaction:
یک محیط خیلی واقعی‌تر در اختیار مهاجم قرار میده تا رفتار و تکنیک‌هاش با جزئیات بیشتری قابل تحلیل باشه؛ ولی مدیریت و ایمن‌سازی اون سخت‌تره.
⚠️ نکته امنیتی
Honeypot
نباید تبدیل به راه ورود به شبکه اصلی بشه. باید کاملاً ایزوله و کنترل‌شده باشه، چون اگر مهاجم اون رو تحت کنترل بگیره، ممکنه از همون سیستم برای حمله به بخش‌های دیگه استفاده کنه.
🧅 شبکه Tor چقدر امنه؟
اگه بخوایم منطقی فکر کنیم، Tor یکی از قوی‌ترین ابزارها برای بالا بردن حریم خصوصی و ناشناس‌تر کردن ارتباطاته، ولی قرار نیست فکر کنیم با استفاده از Tor دیگه کاملاً نامرئی می‌شیم. Tor کاری میکنه ارتباطت مستقیم از سیستم خودت به سایت مقصد نره؛ معمولاً ترافیکت از چند نود مختلف عبور میکنه، مثلاً اول به Guard یا Entry Node، بعد چند Relay دیگه و در نهایت اگه مقصد یه سایت معمولی باشه از Exit Node خارج میشه و به سایت می‌رسه. این وسط هر نود فقط بخشی از مسیر رو می‌بینه؛ مثلاً نود ورودی IP واقعی تو رو می‌بینه ولی مقصد نهایی رو نمیدونه و Exit Node مقصد رو می‌بینه ولی به‌صورت معمول IP واقعی تو رو نمی‌بینه. به همین دلیل پیدا کردن ارتباط مستقیم بین «تو» و «سایت مقصد» سخت‌تر میشه.
اما یه نکته خیلی مهم وجود داره؛ Tor به معنی رمزنگاری همه‌چیز نیست. اگه با Tor به یه سایت HTTP وصل بشی، اطلاعات بعد از Exit Node میتونه بدون رمزنگاری روی اینترنت حرکت کنه، پس استفاده از HTTPS همچنان خیلی مهمه. از طرف دیگه اگه وارد حساب شخصی خودت بشی، مثلاً حسابی که اسم و مشخصاتت داخلشه، Tor نمیتونه این واقعیت رو مخفی کنه که صاحب اون حساب کیه؛ Tor بیشتر IP و مسیر شبکه رو مخفی میکنه، نه اطلاعاتی که خودت داخل سایت وارد می‌کنی.
یه ضعف مهم دیگه هم Traffic Correlation یا همبستگی ترافیکه. فرض کن یه مهاجم خیلی قدرتمند بتونه هم ترافیکی که از سمت تو وارد شبکه Tor میشه و هم ترافیکی که به سمت مقصد خارج میشه رو زیر نظر داشته باشه؛ حتی بدون دیدن محتوای رمزنگاری‌شده، میتونه با بررسی زمان ارسال، حجم و الگوی بسته‌ها تلاش کنه بفهمه کدوم ارتباط مربوط به کدوم کاربره. بنابراین Tor در برابر یک مهاجم خیلی قدرتمند که توانایی مشاهده بخش بزرگی از شبکه رو داره، ناشناس‌بودن صددرصدی رو تضمین نمی‌کنه.
خود سیستم کاربر هم خیلی مهمه؛ اگه کامپیوتر یا موبایلت آلوده باشه، Tor دیگه نمیتونه معجزه کنه، چون ممکنه اطلاعات قبل از ورود به Tor از روی دستگاهت دزدیده بشه. همین‌طور نباید فکر کنیم هر برنامه‌ای که روی سیستم باز میکنیم خودکار از Tor عبور میکنه؛ فقط برنامه‌هایی که واقعاً برای استفاده از Tor تنظیم شدن یا از طریق Tor Browser استفاده میشن، مسیر موردنظر رو طی میکنن.
Tor Browser
هم فقط یه مرورگر معمولی با Proxy نیست؛ برای کاهش Fingerprinting و افزایش حریم خصوصی طراحی شده و تنظیمات امنیتی مختلفی داره. هرچی سطح امنیتی رو بالاتر ببری، بعضی قابلیت‌های سایت‌ها محدود میشن ولی سطح حمله هم کمتر میشه. همچنین نصب افزونه‌های اضافی یا دستکاری زیاد تنظیمات مرورگر میتونه باعث بشه از حالت استاندارد خارج بشی و حتی شناسایی‌پذیری بیشتری پیدا کنی.
یه بخش جالب Tor هم Onion Serviceها یا همون سایت‌های .onion هستن. اینجا ارتباط داخل شبکه Tor باقی می‌مونه و برخلاف سایت‌های معمولی نیازی نیست برای رسیدن به مقصد از Exit Node خارج بشی؛ در نتیجه هم هویت کاربر و هم موقعیت سرویس می‌تونن بهتر محافظت بشن.
پس اگه بخوای خیلی خلاصه بگیم، Tor برای مخفی کردن IP، افزایش حریم خصوصی و سخت‌تر کردن ردیابی شبکه‌ای خیلی قدرتمنده، ولی ضدگلوله نیست. اشتباهات کاربر، سیستم آلوده، ورود به حساب‌های شخصی، استفاده از HTTP، Fingerprinting و مخصوصاً Traffic Correlation می‌تونن حریم خصوصی رو ضعیف کنن.
در نهایت هم Tor رو با VPN یکی نگیریم؛ VPN معمولاً یه نقطه متمرکز برای اعتماد ایجاد میکنه، ولی Tor ارتباط رو بین چند Relay پخش میکنه تا یک نود به‌تنهایی نتونه هم مبدأ و هم مقصد ارتباط رو ببینه. پس Tor یعنی ناشناس‌تر شدن و افزایش حریم خصوصی، نه نامرئی شدن کامل در اینترنت.
اگه بخوایم منطقی فکر کنیم، Tor یکی از قوی‌ترین ابزارها برای بالا بردن حریم خصوصی و ناشناس‌تر کردن ارتباطاته، ولی قرار نیست فکر کنیم با استفاده از Tor دیگه کاملاً نامرئی می‌شیم. Tor کاری میکنه ارتباطت مستقیم از سیستم خودت به سایت مقصد نره؛ معمولاً ترافیکت از چند نود مختلف عبور میکنه، مثلاً اول به Guard یا Entry Node، بعد چند Relay دیگه و در نهایت اگه مقصد یه سایت معمولی باشه از Exit Node خارج میشه و به سایت می‌رسه. این وسط هر نود فقط بخشی از مسیر رو می‌بینه؛ مثلاً نود ورودی IP واقعی تو رو می‌بینه ولی مقصد نهایی رو نمیدونه و Exit Node مقصد رو می‌بینه ولی به‌صورت معمول IP واقعی تو رو نمی‌بینه. به همین دلیل پیدا کردن ارتباط مستقیم بین «تو» و «سایت مقصد» سخت‌تر میشه.
اما یه نکته خیلی مهم وجود داره؛ Tor به معنی رمزنگاری همه‌چیز نیست. اگه با Tor به یه سایت HTTP وصل بشی، اطلاعات بعد از Exit Node میتونه بدون رمزنگاری روی اینترنت حرکت کنه، پس استفاده از HTTPS همچنان خیلی مهمه. از طرف دیگه اگه وارد حساب شخصی خودت بشی، مثلاً حسابی که اسم و مشخصاتت داخلشه، Tor نمیتونه این واقعیت رو مخفی کنه که صاحب اون حساب کیه؛ Tor بیشتر IP و مسیر شبکه رو مخفی میکنه، نه اطلاعاتی که خودت داخل سایت وارد می‌کنی.
یه ضعف مهم دیگه هم Traffic Correlation یا همبستگی ترافیکه. فرض کن یه مهاجم خیلی قدرتمند بتونه هم ترافیکی که از سمت تو وارد شبکه Tor میشه و هم ترافیکی که به سمت مقصد خارج میشه رو زیر نظر داشته باشه؛ حتی بدون دیدن محتوای رمزنگاری‌شده، میتونه با بررسی زمان ارسال، حجم و الگوی بسته‌ها تلاش کنه بفهمه کدوم ارتباط مربوط به کدوم کاربره. بنابراین Tor در برابر یک مهاجم خیلی قدرتمند که توانایی مشاهده بخش بزرگی از شبکه رو داره، ناشناس‌بودن صددرصدی رو تضمین نمی‌کنه.
خود سیستم کاربر هم خیلی مهمه؛ اگه کامپیوتر یا موبایلت آلوده باشه، Tor دیگه نمیتونه معجزه کنه، چون ممکنه اطلاعات قبل از ورود به Tor از روی دستگاهت دزدیده بشه. همین‌طور نباید فکر کنیم هر برنامه‌ای که روی سیستم باز میکنیم خودکار از Tor عبور میکنه؛ فقط برنامه‌هایی که واقعاً برای استفاده از Tor تنظیم شدن یا از طریق Tor Browser استفاده میشن، مسیر موردنظر رو طی میکنن.
Tor Browser
هم فقط یه مرورگر معمولی با Proxy نیست؛ برای کاهش Fingerprinting و افزایش حریم خصوصی طراحی شده و تنظیمات امنیتی مختلفی داره. هرچی سطح امنیتی رو بالاتر ببری، بعضی قابلیت‌های سایت‌ها محدود میشن ولی سطح حمله هم کمتر میشه. همچنین نصب افزونه‌های اضافی یا دستکاری زیاد تنظیمات مرورگر میتونه باعث بشه از حالت استاندارد خارج بشی و حتی شناسایی‌پذیری بیشتری پیدا کنی.
یه بخش جالب Tor هم Onion Serviceها یا همون سایت‌های .onion هستن. اینجا ارتباط داخل شبکه Tor باقی می‌مونه و برخلاف سایت‌های معمولی نیازی نیست برای رسیدن به مقصد از Exit Node خارج بشی؛ در نتیجه هم هویت کاربر و هم موقعیت سرویس می‌تونن بهتر محافظت بشن.
پس اگه بخوای خیلی خلاصه بگیم، Tor برای مخفی کردن IP، افزایش حریم خصوصی و سخت‌تر کردن ردیابی شبکه‌ای خیلی قدرتمنده، ولی ضدگلوله نیست. اشتباهات کاربر، سیستم آلوده، ورود به حساب‌های شخصی، استفاده از HTTP، Fingerprinting و مخصوصاً Traffic Correlation می‌تونن حریم خصوصی رو ضعیف کنن.
در نهایت هم Tor رو با VPN یکی نگیریم؛ VPN معمولاً یه نقطه متمرکز برای اعتماد ایجاد میکنه، ولی Tor ارتباط رو بین چند Relay پخش میکنه تا یک نود به‌تنهایی نتونه هم مبدأ و هم مقصد ارتباط رو ببینه. پس Tor یعنی ناشناس‌تر شدن و افزایش حریم خصوصی، نه نامرئی شدن کامل در اینترنت.
Zoly
مخابرات: سرعت اینترنت به زودی ۸۰ برابر افزایش پیدا میکنه. هوراا قراره ژاپن بشیم. پ‌ن: منظور از رشد، کیفیت نیست! قیمت خدمات هستش.
کلودفلر :
ترافیک اینترنت بین الملل ایران از ۹۰ درصد به ۵۹ درصد رسیده ، وضعیت الان اینترنت ایران دقیقا مثل روزای قبل از قطعی ۸۸ روزه ی اینترنته و با اختلالات بسیار سنگین همراه شده.
دیدی گفتم؟؟😂
نکات جالبی که خالق ++c می گه درباره اینکه حتا خودشم خیلی از توابع رو حفظ نیست و سرچ می کنه
https://www.instagram.com/reel/DcJr4rzhpqx/?igsh=MTd4c2E3cHp4eXN3MQ==
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 هایی با همین اندازه مناسب هستن
اگر تا حالا درباره 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 رو تا حد ممکن قابل پیش بینی کنی و از یک وضعیت غیرقابل اعتماد در حافظه به کنترل جریان اجرای برنامه برسی.
بنابراین 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 رو تا حد ممکن قابل پیش بینی کنی و از یک وضعیت غیرقابل اعتماد در حافظه به کنترل جریان اجرای برنامه برسی.
RadvanSec
مهندسی Heap در Firefox و تبدیل یک Use After Free به کنترل اجرای برنامه (CVE-2013-0753) اگر تا حالا درباره Use After Free یا UAF شنیده باشی احتمالا میدونی مشکل اصلی چیه یک Object داخل حافظه ساخته میشه و بعد حافظه اون Object آزاد میشه اما یک Pointer یا Reference…
خوب مطالعه کنید مطالب پیش پا افتاده شاید باشه برای بعضی ها ولی دیدتون رو باز میکنه و راه رو برای پیدا کردن اولین cve براتون باز میشه👌
Forwarded from PentesterLand
Public & Private tricks
OAuth attacks
https://www.instagram.com/p/DcOIQ30CGGL/?igsh=MXF0cXluNDM2ancxdg==&igsi=MXF0cXluNDM2ancxdg==
OAuth attacks
https://www.instagram.com/p/DcOIQ30CGGL/?igsh=MXF0cXluNDM2ancxdg==&igsi=MXF0cXluNDM2ancxdg==
یه اتکی داریم به این DNS Ampilfication برای dos / ddos
سادست ولی ایدش قشنگه
خلاصش اینه یک کوئری میفرسته به سمت dns server و ولی جوابشو با ip spoofing میفرسته به سمت تارگت
حالا این درخواستی هم که میفرستنو با یکسری تکنیک جوابشو بزرگ میکنن تا فشار بیشتری به تارگت بیاد🤗
سادست ولی ایدش قشنگه
خلاصش اینه یک کوئری میفرسته به سمت 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 وارد حسابش بشه
یکی از آسیب پذیری های مربوط به مدیریت 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 رو مقایسه میکنیم نباید یک کانال جانبی غیرضروری برای مهاجم ایجاد کنیم
Forwarded from Me?!
سلام به همه 👋🏻
شارینگان برای تست در دسترسه.
الان میتونید یک اکانت رایگان بگیرید و خودتون امتحانش کنید.
🔴 شارینگان چیه؟
شارینگان، مرکز پایش مداوم 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
شارینگان برای تست در دسترسه.
الان میتونید یک اکانت رایگان بگیرید و خودتون امتحانش کنید.
🔴 شارینگان چیه؟
شارینگان، مرکز پایش مداوم 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
sharinganx.ir
Sharingan — See Everything. Miss Nothing.
Sharingan — Continuous attack surface intelligence for security professionals. Discover subdomains, track DNS changes, fingerprint HTTP services.
RadvanSec
سلام به همه 👋🏻 شارینگان برای تست در دسترسه. الان میتونید یک اکانت رایگان بگیرید و خودتون امتحانش کنید. 🔴 شارینگان چیه؟ شارینگان، مرکز پایش مداوم Attack Surface شماست. به‌جای اینکه فقط یک بررسی لحظه‌ای از Attack Surface داشته باشید، شارینگان به‌صورت مداوم…
سلام کارشون خوب بوده میتونید حتی ایجنت خودتون رو وصل کنید بهش👌
یکی از این سایتایی که قبول دارم
https://bugbountyscam.com/
هرجایی اسکم کرد میتونید ریپورت شیر کنید با بقیه همه با خبر بشن
https://bugbountyscam.com/
هرجایی اسکم کرد میتونید ریپورت شیر کنید با بقیه همه با خبر بشن
BugBountyScam
BugBountyScam — Expose Bug Bounty Scams & Protect Researchers
The community-driven platform where security researchers report and expose fraudulent bug bounty programs worldwide. No more unpaid bounties.
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
Blog: https://barghest.asia/blog/bitchat-cache-poisoning/
PoC: https://github.com/BARGHEST-ngo/PoC_Bitchat1.15.0_iOS-BLEcache-poisoning
Barghest
BitChat cache poisoning and replay in Bluetooth mesh
BARGHEST found a cache poisoning attack in BitChat and replay flaw in BLE mesh synchronization that enabled durable network disruption before patching.
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 کردم نکات آموزشی خوبی گفتم مخصوصا برای کسایی که تازه شروع کردند شاید بتونه مفید باشه که اگر هرچیزی جلوتون رو گرفت چطوری بایپس کنید مخصوصا برای chain کردن آسیب پذیری هایی که medium هستند به critical
Medium
One-Click Full Account Takeover via Chained XSS: Bypassing CSP by Pivoting Through a Trusted…
Intro
RadvanSec
ted-4f811e6ae8ee
رایتاپ از یکی از آسیب پذیری هایی که چند وقت پیش chain کردم نکات آموزشی خوبی گفتم مخصوصا برای کسایی که تازه شروع کردند شاید بتونه مفید باشه که اگر هرچیزی جلوتون رو گرفت چطوری بایپس کنید مخصوصا برای chain کردن آسیب پذیری هایی که
رایتاپ از یکی از آسیب پذیری هایی که چند وقت پیش chain کردم نکات آموزشی خوبی گفتم مخصوصا برای کسایی که تازه شروع کردند شاید بتونه مفید باشه که اگر هرچیزی جلوتون رو گرفت چطوری بایپس کنید مخصوصا برای chain کردن آسیب پذیری هایی که
چون استقالبتون خوب بود یک گزارش دیگه هم براتون میزارم از chain آسیب پذیری SSRF و بایپس هایی که داشت از low impact به high impact که نمونش رو جایی احتمالا نشنیدید
شده تا حالا یک سایتی که SSL نداره رو بخواید باز کنید ولی مرورگر اجازه نده ؟
اینجا یه سئوالی پیش میاد که چرا نمیذاره ؟ اصلا چرا بعضیا رو اجازه میده باز کنم ولی بعضیا رو نمیذاره ؟
فرقش در پروتکلی به نام HSTS هستش
برای اینکه بگیم HSTS چیه باید اول بفهمیم مشکل چی بوده که امدن اینو درست کردن
یکسری حملات هستن که بهشون میگن Downgrade Attacks
یعنی هکر میاد و یه کاری میکنه که شما مجبور بشید از یه پروتکل یا مسیری که سطح پایینتری از امنیت رو داره استفاده کنید
حالا یکی از این حملات میشه SSL Stripping
تو این حمله هکر بین شما و سایت قرار گرفته ( MITM)
و زمانی که شما میخواد به سایت وصل بشید شما رو مجبور میکنه که از HTTP استفاده کنید
چون اگه HTTPS باشه نمیتونه ببینه چی رد میشه
حالا واسه حل این مشکل امدن و HSTS رو درست کردن
این پروتکل میاد و تو درخواست اولی که کاربر میزنه میگه فقط با HTTPS میتونی بهم وصل بشی ( این درخواست هم میتونه مورد حمله قرار بگیره ) و نمیذاره ارتباط HTTP برقرار بشه
یعنی درخواست اول رو شما HTTP میزنی و جوابی که برمیگرده یکسری هدر و ریدایرکت شدن به آدرس که SSL داره هستش
اینجا یه سئوالی پیش میاد که چرا نمیذاره ؟ اصلا چرا بعضیا رو اجازه میده باز کنم ولی بعضیا رو نمیذاره ؟
فرقش در پروتکلی به نام HSTS هستش
برای اینکه بگیم HSTS چیه باید اول بفهمیم مشکل چی بوده که امدن اینو درست کردن
یکسری حملات هستن که بهشون میگن Downgrade Attacks
یعنی هکر میاد و یه کاری میکنه که شما مجبور بشید از یه پروتکل یا مسیری که سطح پایینتری از امنیت رو داره استفاده کنید
حالا یکی از این حملات میشه SSL Stripping
تو این حمله هکر بین شما و سایت قرار گرفته ( MITM)
و زمانی که شما میخواد به سایت وصل بشید شما رو مجبور میکنه که از HTTP استفاده کنید
چون اگه HTTPS باشه نمیتونه ببینه چی رد میشه
حالا واسه حل این مشکل امدن و HSTS رو درست کردن
این پروتکل میاد و تو درخواست اولی که کاربر میزنه میگه فقط با HTTPS میتونی بهم وصل بشی ( این درخواست هم میتونه مورد حمله قرار بگیره ) و نمیذاره ارتباط HTTP برقرار بشه
یعنی درخواست اول رو شما HTTP میزنی و جوابی که برمیگرده یکسری هدر و ریدایرکت شدن به آدرس که SSL داره هستش
Zoly
شده تا حالا یک سایتی که SSL نداره رو بخواید باز کنید ولی مرورگر اجازه نده ؟ اینجا یه سئوالی پیش میاد که چرا نمیذاره ؟ اصلا چرا بعضیا رو اجازه میده باز کنم ولی بعضیا رو نمیذاره ؟ فرقش در پروتکلی به نام HSTS هستش برای اینکه بگیم HSTS چیه باید اول بفهمیم مشکل…
این هدر هایی که برمیگرده هم توسط مرورگر ذخیره میشه تا دفعه های بعدی اصلا نیاز نباشه شما اون درخواست اول رو با HTTP بزنید و از همون اول با HTTPS با سایت صحبت کنید
هدر HSTS مثل اینه
میگه تا چه مدت این سیاست ها برای سایت ذخیره بشه
ساب دامین ها هم باشن یا نه
حالا یه قانونی داخل مرورگرا هست
تمام سایت هایی که از HSTS استفاده میکنن در صورت تایید کاربر هم اجازه استفاده از HTTP رو ندارن
هدر HSTS مثل اینه
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
میگه تا چه مدت این سیاست ها برای سایت ذخیره بشه
ساب دامین ها هم باشن یا نه
حالا یه قانونی داخل مرورگرا هست
تمام سایت هایی که از HSTS استفاده میکنن در صورت تایید کاربر هم اجازه استفاده از HTTP رو ندارن