ViperNułł

روت‌کیت‌های سخت‌افزاری:

وقتی صحبت از بد افزار ها می‌شه، معمولاً همه ذهنشون میره سمت ویروس‌ها، بدافزارها و باج‌افزارهایی که سیستم‌عامل رو آلوده می‌کنن. اما یه لایه عمیق‌تر و خطرناک‌تر هم هست که خیلی‌ها اصلاً بهش فکر نمی‌کنن: روت‌کیت‌های سخت‌افزاری. اینا مثل جاسوس‌هایی هستن که نه فقط توی سیستم‌عامل، بلکه توی خود سخت‌افزار یا firmware جا خوش می‌کنن. بیاید با هم ببینیم اینا دقیقاً چی هستن، کجا قایم می‌شن و چطوری کار می‌کنن.

کجا قایم می‌شن؟ (حافظه‌های قابل‌نویس سخت‌افزاری)

روت‌کیت‌های سخت‌افزاری برخلاف بدافزارهای معمولی، خودشون رو توی فایل‌های سیستمی یا رم نمی‌ندازن. نه، اونا یه‌جورایی خودشونو "جا می‌کنن" تو دل سخت‌افزار — جایی که معمولاً هیچ‌کس سر نمی‌زنه:

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

Firmware دستگاه‌های جانبی
مثلاً کارت شبکه، SSD یا کارت گرافیک هم یه چیپ مخصوص برای firmware دارن. روت‌کیت می‌تونه اونجا تزریق بشه. برای نمونه، حملاتی مثل USBevil یا SSD firmware rootkit دقیقاً از همین راه وارد شدن.

Intel Management Engine (IME) / AMD PSP
اینا چیپ‌هایی هستن که مستقل از CPU اصلی کار می‌کنن و دسترسی خیلی گسترده به سیستم دارن. یه روت‌کیت اگه وارد این ناحیه بشه، دیگه پاک کردنش تقریباً غیرممکنه چون این چیپ حتی وقتی سیستم خاموشه هم تا حدی فعاله.

چطوری کار می‌کنن؟ (مکانیزم اجرایی)

فرض کن داری کامپیوترتو روشن می‌کنی. قبل از اینکه سیستم‌عامل لود بشه، اول فریمور UEFI اجرا می‌شه. حالا اگه یه روت‌کیت اونجا نشسته باشه، می‌تونه یه سری کدهای مخرب اجرا کنه و مثلاً یه hypervisor ساختگی بارگذاری کنه که کل سیستم‌عامل روی اون اجرا بشه — بدون اینکه سیستم‌عامل حتی بفهمه داره زیرنظر گرفته می‌شه.
روت‌کیت‌های سخت‌افزاری می‌تونن:

خودشون رو از هر آنتی‌ویروس یا اسکنری مخفی کنن.

داده‌ها رو شنود کنن یا تغییر بدن (مثلاً keylogger در سطح سخت‌افزار).

سیستم‌عامل رو با نسخه‌ی آلوده جایگزین کنن.

حتی توی شبکه backdoor باز کنن برای کنترل از راه دور.

نمونه‌های واقعی از این نوع حملات

LoJax
اولین روت‌کیت UEFI کشف‌شده که توسط یک گروه APT (تهدید پایدار پیشرفته) به سیستم‌ها نفوذ کرد. حتی با نصب مجدد ویندوز هم از بین نمی‌رفت.

Thunderstrike
حمله‌ای به فریمور مک‌بوک‌ها از طریق پورت Thunderbolt. با یه درایو دستکاری‌شده، می‌شد فریمور رو آلوده کرد.

BadUSB
USBهایی که firmware داخلشون تغییر کرده بود و مثل یه کیبورد یا شبکه عمل می‌کردن تا کد مخرب تزریق کنن — بدون اینکه آنتی‌ویروس بتونه تشخیصش بده.

چرا انقدر خطرناک هستن؟

پاک‌نشدنی هستن؛ مگر اینکه با ابزار خاصی firmware رو بازنویسی کنی (که خیلی وقت‌ها ممکن نیست).

در سطحی کار می‌کنن که آنتی‌ویروس‌ها دسترسی ندارن.

می‌تونن سال‌ها بدون شناسایی باقی بمونن.

به سخت‌افزار آسیب دائمی بزنن یا اطلاعات حیاتی رو به بیرون نشت بدن.

چطور باید محافظت کرد؟

Secure Boot رو فعال کن تا فقط کدهای امضاشده اجرا بشن.

فریمور مادربورد، SSD و دستگاه‌ها رو همیشه آپدیت نگه‌دار.

سیستم‌هایی که امنیت حیاتی دارن (مثل سرورهای دولتی) بهتره از سیستم‌عامل‌هایی با UEFI Secure Mode و امکانات امنیتی بیشتر استفاده کنن.

از ابزارهای پیشرفته مثل CHIPSEC برای تحلیل فریمور استفاده کن (برای کاربران پیشرفته).


https://t.me/ViperNull

خیلی از شرکت‌های بزرگ دنیا از سونی بگیرید تا علی بابا و یاهو و ... حتی برخی از وب سایت‌های مهم مانند فیسبوک و توئیتر و لینکدین و حتی اشلی مدیسون هک شدند و اطلاعات میلیون‌ها کاربر نشت شد که هیچ، برخی از ساختارهای مرتبط با پروژه‌ها و اطلاعات داخلی این شرکت‎ها هم نشت داده شد. دلیل هم کامل واضح است، امنیت در نگاه مهندسی سیستم‌ها، یک مسئله کاملا نسبی است. شما تحت هیچ شرایطی نمی‌توانید مدعی شوید زیرساخت من ایمن است مگر اینکه از همان ابتدا با نگاه امنیتی آن سیستم و زیست بوم آن را توسعه داده باشید. امنیت یکی از بزرگترین چالش‌های توسعه سیستم‌های‌ دینامیک و استاتیک از همان ابتدا بوده است، چون همانطور که بلوغ امنیتی رخ می‌دهد، شیوه‌های نفوذگری جدید هم ابداع می‌شوند (مایکل سیکروسکی آن را مانند بازی موش و گربه تمثیل کرده است). چه آن زمانی که سیستم‌های سایبرنتیک عمومیت نداشتند چه الان که همه چیز به آن‌ها گره خورده است، بسیاری از متخصصان سال‌ها تلاش کردند تا به مفاهیم ابتدایی مانند Bell-LaPadula Formalism در سیستم‌ها به ایمنی برسند. با این حال، هنوز که هنوزه زیرساخت‌ها مورد نفوذ قرار می‌گیرند و تمامی رویکردها و استانداردهای گذشته تقریبا Failed شدند. به عنوان مثال، الان اگر NSA تصمیم بگیرد، زیرساخت XXXXXX ایران را مورد نفوذ قرار بدهد، هزینه‌اش خرید یک زیرودی Exchange است. البته NSA نیاز به خرید ندارد، چون خودشان توسعه می‌دهند و همواره شاه کلید دست آن‌ها است. اخیرا، یعنی تقریبا از سال 2017 به بعد (مخصوصا بعد ماجرای اوبر و سولارویندز)، نهادهای نظامی در مرحله اول و بعدها ساختارها و شرکت‌های مهم تجاری به سمت رویکرد جدیدی رفته‌اند که آن را می‌توانیم Behavioral Anomaly Detection & Response نامگذاری کنیم. در این رویکرد، دیگر خبری از نگاه‌های سنتی SOC/CSIRT نیست، بلکه همه چیز در فرآیندهای استاندارد و البته خودکار شده است. در این رویکرد جدید تمرکز روی شناسایی انومالی‌ها در تمامی سطوح رفتاری و سیستمی است که این آنومالی هم به ازای هر محیط متفاوت است (Case Study مجزا دارد)، و در نهایت بهینه‌سازی فرآیندها برای واکنش و رفع تهدیداتی که رخ می‌دهد با توجه به سنجه زمان که هر چقدر R(T) کمتر باشد، بهتر است. شخصا در ایران هیچ جا نتوانستم این مسئله را به دلیل وجود تداخل‌هایی که در تصمیم گیری وجود داشت و همچنین عدم دنبال کردن نگاه مهندسی سیستمی توسط مدیران پیاده‌سازی کنم. ولی چه الان چه صد سال دیگر جبر روزگار همه را وادار می‌کند که به این سمت حرکت کنیم و متوجه شویم دیگر با ابزار، محصول و حتی هزاران نیروی متخصص نمی‌توان به امنیت رسید وقتی زیرساخت و فرآیند و Pipelineها مشکل دارد. البته با احترام به تمام متخصصان عزیز، من صرفا نظر خودم را گفتم.

@aioooir | #snapfood

در عملیات ردتیم شما بین اوپریشن‌هایی که انجام می‌دهید فقط یک Delay در حدود 48 ساعت قرار بدهید. به قول معروف، اتمیک و توزیع شده کار خود را پیش ببرید تا جای پای خودتان را محکم کنید. همین یک مورد موجب خواهد شد، 90 درصد افراد تحلیلگر SOC نتوانند زنجیره کارهای شما را شناسایی کنند.

یکی از دلایل مهم که اکنون وجود دارد و عملا T1 و T2 را در معرض حذف قرار داده است، همین باگ در نظارت انسانی است که توانایی Correlation اتفاقات را در محدوده زمانی گسترده ندارد. حال شما فرض کن، از زمانی که بدافزار روی ماشین دراپ می‌شود، تا زمانی که پیلود خود را اجرا کند، دو هفته دیلی تعریف شده باشد. بین هر اکشن تا اکشن بعدی 48 ساعت زمان تعریف شده باشد. بازه فعالیت ها در ساعت 2 تا 4 صبح تنظیم شده باشد آن هم نه به صورت منظم، ترافیک استخراج داده بین نرخ بالا و پایین ترافیک شبکه مقصد Fade شده باشد.

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

این را صرفا مطرح کردم تا در آینده یک موضوعی از سمت آزمایشگاه امنیت سایبرنتیک آیو دراپ شود که خب مرتبط با همین مسئله است.

@aioooir | #anomaly_against_anomaly

ViperNułł pinned «دوستان لینک گپ کانال ، داشته باشید https://t.me/ViperNuL»

Channel photo updated

Channel name was changed to «ViperNułł»

⭕ یه نگاه امنیت محور و دقیقه به Pcode در ARP !!

ARP چیه؟
تو دنیای شبکه، یکی از ساده‌ترین ولی حیاتی‌ترین پروتکل‌ها، ARP یا همون Address Resolution Protocol هست. این پروتکل کارش اینه که آدرس‌های IP رو به آدرس‌های MAC ترجمه کنه. ولی یه بخشی از بسته‌های ARP هست به نام Pcode که تو زمینه‌ی امنیتی خیلی مهم می‌شه، مخصوصاً وقتی صحبت از ARP Spoofing یا همون جعل ARP وسط میاد.

اصلاً Pcode چیه تو ARP؟

حالا بریم سراغ اصل مطلب. تو ساختار یه بسته‌ی ARP، یه فیلدی هست به اسم Opcode یا همون Pcode (خیلی جاها این دو واژه جای هم استفاده می‌شن). این فیلد مشخص می‌کنه که پیام ARP قراره چه کاری انجام بده:

وقتی مقدارش 1 باشه، یعنی یه درخواست (ARP Request) داریم. فرستنده یجورایی داره می‌پرسه: ببخشید، MAC آدرس این IP چنده؟

وقتی مقدارش 2 باشه، یعنی یه پاسخ (ARP Reply) داریم. فرستنده یجورایی جواب می‌ده: سلام منم اون IP، اینم MAC من!

پس، Pcode تعیین‌کننده‌ی نوع عملیاتیه که بسته‌ی ARP قراره انجام بده.

نقش Pcode توی ARP Spoofing دقیقاً چیه؟

اینجا قضیه امنیتی‌تر می‌شه. تو حمله‌ی ARP Spoofing، مهاجم میاد خودش رو به‌جای یه دستگاه دیگه جا می‌زنه، اونم با ارسال بسته‌های جعلی ARP. حالا جالب اینجاست که مهاجم از همون فیلد Pcode برای مشخص کردن نوع بسته‌ی خودش استفاده می‌کنه.
مثلاً:

مهاجم یه ARP Reply (یعنی Pcode = 2) می‌فرسته، حتی اگه کسی ARP Request نکرده باشه!

این جواب جعلی می‌گه: IP آدرس فلان؟ آره، اون مال منه، اینم MAC من!

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

و از اینجا به بعد، ترافیک شبکه اشتباهی به سمت مهاجم می‌ره. یعنی اون وسط می‌تونه اطلاعات رو ببینه، تغییر بده، یا حتی بندازه دور (حمله Man-in-the-Middle یا DoS).

پس چرا Pcode مهمه؟

چون مهاجم برای حمله‌ش به‌طور مستقیم به فیلد Pcode دست می‌زنه. اگه توی شبکه‌ی خودمون بتونیم رفتار بسته‌هایی با Pcode = 2 که بدون درخواست میان رو تحلیل کنیم، می‌تونیم سرنخ‌های خوبی از حمله‌های احتمالی بگیریم.
حتی بعضی از IDS/IPS ها (سیستم‌های تشخیص نفوذ) دقیقاً اینو مانیتور می‌کنن که آیا ARP Reply بدون Request رسیده یا نه.

یه نکته‌ی ظریف ولی کاربردی:

تو دنیای واقعی، ARP هیچ‌گونه احراز هویتی نداره. یعنی هر کسی می‌تونه یه ARP Reply بفرسته با Pcode = 2 و هیچ‌کس نمی‌پرسه: تو برای چی اینو فرستادی من که چیزی نگفتم ؟
همین سادگی باعث شده که حمله‌ی ARP Spoofing جزو پایه‌ای‌ترین و خطرناک‌ترین حملات شبکه‌های LANباشه

@ViperNull

اگه به چلنج های نتورک فارنزیک علاقه دارید

https://cybertalents.com/challenges/network/
➖➖➖➖➖
CHANNEL  
GROUP
DISCORD

Http The Definitive Guide
@ViperNull

کتاب practical packet analysis
@ViperNull

کتاب blue team handbook
@ViperNull

کتاب applied network security monitoring
@ViperNull

کتاب Cybersecurity ops with bash

@ViperNull