https://github.com/28Zaaky/khaos-c2

khaos-c2
یک فریم ورک مدرن C2 است که ترافیک عامل را از طریق سرویس های ابری که قبلاً توسط شبکه‌های سازمانی مورد اعتماد قرار گرفته‌اند، مسیریابی می‌کند.
@pfksecurity

بخش صفرم - چگونه تحقیق آسیب‌ پذیری (Vulnerability Research) به یک مهارت افسانه‌ای تبدیل شد؟

زمانی شکار zero-dayها فقط کار دولت‌ ها و چند پژوهشگر مستقل بود.

اما امروز به یک بازار عظیم و پررقابت تبدیل شده. هر روز تعداد آسیب‌پذیری‌ های 0Day کشف‌شده و مورد exploit قرار میگیرد و vulnerability research حالا یکی از کلیدی‌ ترین مهارت‌ ها در امنیت سایبری است.

برای تازه‌ وارد ها در offensive security، این کار تقریباً جادویی به نظر می‌ رسد.

فراتر از تست نفوذ معمولی (black-box) یا هک وب، وارد عمق memory corruption، assembly code و dynamic instrumentation می‌ شوی.

مشکل اصلی؟ بیشتر writeupها فقط می‌گویند «این آسیب‌پذیری چی بود»، اما چگونه کشفش کردند را توضیح نمی‌دهند.

تحقیق آسیب‌پذیری حوزه بسیار وسیعی است؛ هم سخت‌افزار را شامل می‌ شود و هم نرم‌افزار. به همین دلیل روش پیدا کردن هر آسیب‌پذیری کاملاً متفاوت است.

نکته طلایی: قبل از انتخاب هر تکنیک خاص، باید استراتژی کلی داشته باشی.

در اینجا با دنیای vulnerability research آشنا می‌شوی:

• اصول حرفه‌ای گزارش‌ دهی آسیب‌پذیری‌ ها
• ا vulnerability research دقیقاً چیست و چه چیزی نیست

• سه حوزه اصلی: Code Review، Reverse Engineering و Fuzzing

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

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

جمع‌بندی:
تحقیق اسیب پذیری Vulnerability Research فقط دانش فنی نیست؛ یک ذهنیت است: ذهنیت «یادگیری چگونگی یادگیری».


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

بخش اول
@pfksecurity

بخش اول

آیا هر «باگ»ی واقعاً یک آسیب‌پذیری است؟ خیلی‌ ها فکر می‌کنند بله، اما تفاوتشون می‌ تواند سرنوشت یک سیستم را عوض کند.

آسیب‌پذیری دقیقاً چیست؟ (تعریف ساده و کاربردی)


طبق تعریف موسسه استاندارد و فناوری ملی آمریکا (NIST):

«آسیب‌ پذیری، ضعفی در یک سیستم اطلاعاتی، رویه‌های امنیتی، کنترل‌های داخلی یا پیاده‌سازی است که می‌ تواند توسط یک منبع تهدید مورد اکسپلویت قرار بگیرد.»

به زبان ساده:

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

سیستم امتیازدهی آسیب‌ پذیری مشترک (CVSS) برای سنجش seriousness یک آسیب‌ پذیری از مثلث CIA استفاده می‌کند:

محرمانگی (Confidentiality) : مهاجم به داده‌هایی دسترسی پیدا می‌ کند که نباید.

یکپارچگی (Integrity) : مهاجم می‌ تواند داده‌ها را تغییر دهد.

دسترسی پذیری Availability : مهاجم می‌ تواند سیستم را از کار بیندازد یا مختل کند.


مثال:

اگر یک آسیب‌ پذیری به مهاجم اجازه بدهد فایل‌ های دلخواه روی سرور بنویسد، عمدتاً روی Integrity تأثیر می‌ گذارد. این جزئیات وقتی می‌ خواهی گزارش vulnerability disclosure بنویسی، خیلی کمک‌ کننده است.

نکته خیلی مهم:

همه آسیب‌پذیری‌ ها bug هستند، اما همه bugها آسیب‌ پذیری نیستند.

اگر یک باگ در firmware روتر باعث شود روز هفته اشتباه نمایش داده شود، ولی هیچ راهی برای exploitable امنیتی از بیرون وجود نداشته باشد، فقط یک bug معمولی است، نه vulnerability. چون از هیچ security boundary عبور نمی‌کند و تهدید واقعی ایجاد نمی‌ کند.



پست رو ذخیره کن و برای دوستانت که تو امنیت کار می‌کنند بفرست.

بخش صفرم
@pfksecurity

بخش دوم :

خیلی از CVEها در نهایت vulnerability واقعی نیستند. فقط bug معمولی‌ اند که اشتباه گزارش شده‌اند و وقت همه را تلف می‌کنند.

گزارش‌ دهی نادرست آسیب‌ پذیری‌ ها

اشتباه گرفتن مکرر بین bugs و vulnerabilities می‌تواند منجر به گزارش‌ دهی نادرست آسیب‌ پذیری‌ها شود. برای مثال، هم پروژهٔ curl و هم پروژهٔ Postgres گزارش‌ های آسیب‌پذیری‌ هایی را رد کرده‌اند که در واقع bug بودند، نه vulnerability واقعی.

مثال اول: CVE-2020-19909 در curl
یکی از موارد بحث‌برانگیز، CVE-2020-19909 است. توصیف اولیهٔ آن به این شکل بود:

آسیب‌پذیری integer overflow در فایل tool_operate.c در نسخهٔ curl 7.65.2 به دلیل پذیرش یک مقدار بسیار بزرگ به عنوان retry delay.

ا Daniel Stenberg (توسعه‌دهندهٔ اصلی curl) در پست وبلاگی با عنوان «CVE-2020-19909 is everything that is wrong with CVEs» توضیح می‌ دهد که این integer overflow در گزینهٔ خط فرمان --retry-delay رخ می‌دهد. این گزینه تعیین می‌کند curl قبل از retry کردن یک درخواست ناموفق، چند ثانیه منتظر بماند.

اگر کاربر در یک سیستم ۶۴ بیتی عددی مانند 18446744073709552 وارد کند، به دلیل overflow، curl آن را به صورت عدد 384 تفسیر می‌ کند.

این سناریو یک weakness ناشی از integer overflow را برآورده می‌ کند و حتی ممکن است در برخی شرایط exploitable به نظر برسد (مثلاً اگر سیستمی ورودی کاربر را به curl پاس دهد تا درخواست‌ های سمت سرور انجام دهد). اما واقعیت این است که این مسئله از هیچ security boundary مهمی عبور نمی‌کند. حتی اگر مهاجمی بتواند از آن اکسپلویت کند و باعث شود curl درخواست‌ های ناموفق را زودتر از حد انتظار retry کند، به سختی می‌توان آن را یک مسئلهٔ امنیتی واقعی دانست.

در نهایت، رکورد CVE اصلاح‌شده به این شکل به‌روزرسانی شد:

توجه: بسیاری از طرف‌ ها گزارش میکنند که این موضوع اثر امنیتی مستقیمی روی کاربر curl ندارد؛ با این حال، ممکن است باعث denial of service برای سیستم‌ ها یا شبکه‌ های مرتبط شود، اگر مثلاً --retry-delay به عنوان مقداری بسیار کوچک‌تر از مقدار مورد نظر تفسیر شود.

این سناریو بسیار بعید است، زیرا overflow فقط زمانی رخ می‌ دهد که کاربر عمداً بخواهد curl صدها روز (یا حتی بیشتر) قبل از retry کردن یک خطای موقتی منتظر بماند.

علاوه بر این، در استفادهٔ عادی توسط کاربر محلی، این مسئله اصلاً از security boundary عبور نمی‌کند؛ چون کاربر در هر صورت کنترل کامل روی --retry-delay دارد.

مثال دوم: CVE-2020-21469 در Postgres
استدلال مشابهی برای CVE-2020-21469 در PostgreSQL نیز صدق می‌کند. توصیف اولیهٔ این CVE چنین بود:

در PostgreSQL 12.2 مشکلی کشف شده که به مهاجمان اجازه می‌ دهد با ارسال مکرر سیگنال SIGHUP باعث denial of service شوند.

توسعه‌دهندگان Postgres در پاسخی با عنوان «CVE-2020-21469 is not a security vulnerability» تأکید کردند که اکسپلویت از این مسئله نیازمند دسترسی سطح بالا است، مانند:

داشتن دسترسی PostgreSQL superuser (کاربر postgres)

داشتن مجوز اجرای pg_reload_conf از طرف superuser

دسترسی به یک کاربر privileged در سطح سیستم‌عامل

با این سطح دسترسی، مهاجم به راحتی و بدون نیاز به هیچ exploit خاصی می‌تواند دیتابیس را متوقف کند (یا کارهای بسیار مخرب‌ تری انجام دهد). بنابراین، مطرح کردن آن به عنوان vulnerability معنادار نیست.

جمع‌بندی:

همه vulnerabilityها bug هستند، اما همه bugها vulnerability نیستند. قبل از گزارش CVE، حتماً بررسی کنید آیا واقعاً از security boundary عبور می‌کند یا خیر.

این تفاوت‌ ها را در ذهن داشته باشید تا وقتتان را صرف مسائل بی‌ اهمیت نکنید.

این پست رو ذخیره کن و برای دوستانت فوروارد کن!

بخش یکم
@PfkSecurity

تحلیل BIN / دستکاری ALF /

مهندسی معکوس مبتنی بر مرورگر


#مهندسی_معکوس

@PfkSecurity

👩‍💻 تولیدکننده خط فرمان Bash.

• یک ابزار بسیار کاربردی که به شما امکان می‌دهد خط فرمان (prompt) برای استفاده در Bash را پیکربندی کنید. پارامترها را انتخاب کرده، آن‌ها را به ترتیب مورد نظر خود قرار دهید و سپس پیکربندی نهایی را کپی کنید.

https://bash-prompt-generator.org/

@PfkSecurity

❗ تخفیف ویژه ❗

📚 کتابچه "Mimikatz: تسلط عملی بر تکنیک‌های پیشرفته حملات Active Directory" از مقدماتی تا پیشرفته.

📕 جزئیات بیشتر کتاب


💰 قیمت : ۲۵۰,۰۰۰ تومان
💰 تخفیف : ۱۹۰,۰۰۰ تومان


📖 وایرشارک برای ردتیمرها: از پایه تا پیشرفته

📕 جزئیات بیشتر کتاب

💰 قیمت : ۲۵۰,۰۰۰ تومان
💰 تخفیف : ۱۸۰,۰۰۰ تومان

📖 شکار عملی باگ بانتی : از Recon تا Bounty واقعی : متدولوژی و شناسایی و آسیب پذیری های دنیای واقعی

📕 جزئیات بیشتر کتاب

💰 قیمت : ۳۶۰,۰۰۰ تومان
💰تخفیف : ۲۸۰,۰۰۰ تومان


‼️ مهلت تخفیف : 3 روز

📌 جهت خرید به ایدی زیر پیام دهید:

@THBxSupport

چرا باید در برابر تحریف تاریخ ایستاد ؟

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

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

اگر امروز در برابر تحریف تاریخ سکوت کنیم فردا افغانستان مولانا از آن خود خواهد کرد آذربایجان نظامی گنجوی را و دیگر مفاخر تمدنی ایران یکی پس از دیگری مصادره خواهند شد این روند سال‌هاست آغاز شده و هر روز گسترده‌تر می‌شود

#تاریخ
@PfkSecurity

تحلیل بدافزار : فایل‌های مخرب مایکروسافت آفیس بدون استفاده از ماکرو

در این ویدیو، به بررسی دو روش برای بارگذاری و اجرای کد مخرب در فایل‌های مایکروسافت آفیس بدون استفاده از ماکرو می‌پردازیم: افزونه‌های VSTO و قالب‌های external. در پایان، یک چک‌لیست برای تحلیل فایل‌ های آفیس ارائه می‌دهم تا مشخص شود که آیا این فایل‌ ها امن هستند یا خیر.


00:00 مقدمه
01:26 نمونه 1 - افزونه VSTO لوکال و فایل ISO
07:49 نمونه 2 - افزونه VSTO از راه دور
08:53 نمونه 3 - قالب‌ های External
10:52 ابزار Binary Refinery برای بررسی کلی فایل‌های آفیس
16:15 چک‌لیست...

#بدافزار #تحلیل_بدافزار #مهندسی_معکوس
@PfkSecurity

onion.run
یک پروکسی برای دسترسی به وب‌سایت‌ های دارک‌ نت است که امکان دسترسی به سرویس‌های پنهان Tor را از طریق مرورگر معمولی فراهم می‌ کند.

این سرویس در مرورگرهای Chrome، Firefox، Safari و سایر مرورگرها کار می‌ کند. از بیش از 100 نسخه مختلف مرورگر پشتیبانی می‌کند.

نصب و پیکربندی لازم ندارد کافی است پسوند .run را به هر آدرس .onion اضافه کنید و به طور ایمن به وب‌سایت‌ ها دسترسی پیدا کنید.

@Pfksecuritu