مقالات

از هش‌ها برای فرایند شناسایی استفاده نکنید (و چه زمان باید از آن‌ها استفاده کرد؟)

sindadsec

یک حقیقت جالب! هرم درد (Pyramid of Pain) که در سال 2013 آن را منتشر کردم، چندان با نسخۀ امروزی آن مطابقت ندارد. در زیر تصویر اولیه از هرم درد را مشاهده می‌کنید:

sindadsec

آیا متوجه تفاوتی شده‌اید؟ سطح پایین هرم در اصل مربوط به آدرس‌های IP بوده است. اما تقریباً یک سال پیش این هرم دستخوش اصلاحاتی شد و لایه‌ای جدید برای هش‌های ایستا (برای مثال MD5 یا SHA1) به‌عنوان لایۀ سطح پایین به آن افزوده‌شده است.

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

چرا هش‌ها برای فرایند شناسایی خوب نیستند؟

من دوره جرم‌شناسی شبکه (دورۀ فارنزیک شبکه) را تدریس می‌کنم و به‌عنوان بخشی از این دوره از هرم درد برای تشریح انواع شواهد و IOC هایی که جرم‌ها به وجود می‌آورند، استفاده می‌نمایم. من با سطح پایین هرم شروع کردم و به‌تدریج در مسیر موفقیت گام برداشتم، درنتیجه اولین مسئله‌ای که در مورد IOC ها به دانشجویان خود متذکر می‌شوم این است که مقادیر هش گرفته‌شده از دیگران (که ما آن‌ها را هش‌های ثالث می‌نامیم) برای شناسایی مناسب نیستند. زیرا از میان تمامی انواع رایج IOC ها، هش‌ها ناپایدارترین جزء بوده و به‌سادگی قابل‌تغییر هستند به‌طوری‌که با تغییر یک بیت یا صرفاً کامپایل مجدد می‌توان آن­ها را تغییر داد.

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

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

من بر اساس تجربۀ شخصی و با اجرای یک برنامۀ شناسایی در یک شرکت عظیم چندملیتی به این جمع‌بندی رسیدم و از آن زمان هنوز بر این باور هستم. بااین‌حال اخیراً به این نتیجه رسیدم که «تجربۀ شخصی» قابل‌اندازه‌گیری نیست و درنتیجه برای رسیدن به چنین جمع‌بندی نباید به آن بسنده کرد. اگرچه متوجه شدم ممکن است شیوه‌ای برای اندازه‌گیری و سنجش تأثیر شناسایی مقادیر هش به‌صورت هدف‌دارتر وجود داشته باشد.

فرضیه‌

برای شروع کار بهتر است به جزئیات فرضیۀ حقیقی بپردازیم. من استفاده از هش‌ها در فرایند شناسایی را به این دلیل نمی‌پسندم که فکر نمی‌کنم مقادیر هش دریافتی از بخش‌های دیگر، در شبکه‌های دیگر قابل‌مشاهده باشد. می‌توان این عبارت را بکار برد: «بعید است مقادیر هش قابل‌مشاهده در یک شبکه در شبکۀ دیگری نیز قابل‌مشاهده باشد.» 

داده

خوشبختانه من به همۀ پایگاه‌های داده قابل جستجو از تمامی نمونه‌های بدافزار ارسال‌شده به VirusTotal دسترسی دارم که شامل مقادیر منحصربه‌فرد هش به ازای هر فایل ارسال‌شده، تعدادی محصولات AV برای شناسایی آن فایل به‌عنوان بدافزار و یک شناساگر منحصربه‌فرد و ناشناس برای سازمانی که آن فایل را ارسال کرده، می­شود. هر ورودی همچنین شامل فیلدی است که حاوی تعداد کل ارسال‌کنندگان منحصربه‌فرد هر فایل است. این فیلد نهایی کمی پیچیده است، زیرا هر ورودی درواقع شامل خلاصه‌ای از زمان ایجاد ورودی است. یک فایل مشابه می‌تواند در طول زمان ورودی‌های پایگاه داده‌ای متعدد داشته باشد. در این موارد، از بیشترین مقدار فیلد ارسال‌کنندگان کل از تمامی ورودی‌های پایگاه داده برای آن فایل استفاده می‌کنم.

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

  1. آیتم دارای مقدار هش MD5 باشد. این معیار موجب ارائۀ صرفاً فایل‌ها و نه URLهایی می‌شود که ممکن است برای نظارت ارسال‌شده باشند. من از مقادیر MD5 منحصربه‌فرد برای شناسایی تمامی فایل‌های مختلف استفاده کرده‌ام.
  2. حداقل پنج محصول مختلف AV آن را به‌عنوان بدافزار نشان‌گذاری کرده باشند. این آستانه قراردادی است، اما من در جستجوی صرفاً فایل‌هایی هستم که احتمالاً بدافزار بوده و ازنظر یک فروشندۀ AV در مقابل مثبت کاذب قرار دارند.
  3. فایل در طول سال 2021 ارسال‌شده باشد. ازنظر فنی این محدودۀ زمانی شامل ساعت 00:00:00 اول ژانویۀ 2021 و تا پیش از ساعت 00:00:00 اول ژانویۀ 2022 است. تحلیل داده‌های یک‌ساله این اطمینان را به وجود می‌آورد که اندازۀ نمونۀ ما برای رسیدن به جمع‌بندی دقیق به‌اندازه کافی بزرگ است.
  4. فایل باید حداقل یک ارسال‌کننده داشته باشد. این مورد عجیب به نظر می‌رسد اما تعداد کمی فایل وجود دارند که ظاهراً هیچ ارسال‌کننده‌ای ندارند (تقریباً 1200 فایل). این مسئله درست به نظر نمی‌رسد زیرا این فایل‌ها باید از سمت کسی ارسال‌شده باشند تا در پایگاه داده قرار گیرند. من این فایل‌ها را از مجموعه داده حذف کرده‌ام.

این معیارها منجر به 11,316,757 فایل منحصربه‌فرد و فراداده‌های مرتبط با آن‌ها شد.

فرضیات

با این تحلیل‌ها می‌توان فرضیاتی را ارائه کرد که در ادامه مطرح می‌شوند:

  1. یک نگاشت یک‌به‌یک میان ارسال‌کنندگان و سازمان‌ها وجود دارد. این مورد شاید برای همۀ موارد درست نباشد، زیرا یک سازمان ممکن است که چندین ID ارسال‌کننده داشته باشد. اما به‌طورکلی این فرض را درست تلقی می‌کنیم. VirusTotal برای هر حساب کاربری منحصربه‌فرد ID های ارسال‌کننده را تخصیص می‌دهد که معمولاً به افراد مرتبط هستند. بااین‌حال سازمان‌هایی که فایل‌ها را به‌طور منظم ارسال می‌کنند، این امر را از طریق فرایندهای خودکار انجام می‌دهند که معمولاً از یک حساب کاربری و درنتیجه یک ID ارسال‌کننده اجرا می‌شود. انتظار می‌رود تعداد قابل‌توجهی ارسال دستی وجود داشته باشد اما تعداد مطلق ارسال‌های خودکار بر آن‌ها غالب است.
  2. تعداد ارسال‌کنندگان، سیاست خوبی برای تعداد سازمان‌هایی است که فایل را مشاهده می‌کنند. اعتبار جمع‌بندی‌ها مبتنی بر این فرض است. از آنجایی که با بدافزارها سروکار داریم، ممکن است سازمان‌هایی متوجه وجود فایل‌ در شبکۀ خود نشوند اما با توجه به تعداد زیاد ارسال کنندگان که به‌طور منظم فایل‌هایی را به این سرویس ارسال می‌کنند، این احتمال که بدافزار مانع از شناسایی در تمامی سایت‌ها و به مدت یک سال باشد بسیار کم می‌شود.

تحلیل

ازآنجایی‌که مجموعه داده حاوی تعدادی ارسال‌کنندۀ منحصربه‌فرد به ازای هر فایل است، تحلیل ساده می‌شود: من هیستوگرامی برای شمارش دفعاتی که هر مقدار «تعداد ارسال‌کنندگان» رخ می‌دهد، ایجاد کردم؛ یعنی مشخص می‌کنم چند بار واقعاً یک ارسال‌کننده، واقعاً دو ارسال‌کننده و به همین ترتیب وجود دارند. من تا 10 ارسال‌کننده شمرده‌ام و سپس هر مورد بیشتر از ده را در طبقه‌بندی «بیشتر از ده ارسال‌کننده» قراردادم. در جدول زیر، تعداد در هر طبقه‌بندی خلاصه‌شده است و همچنین درصد کل طبقه‌بندی نشان داده می‌شود:

sindadsec
  • هیستوگرام زیر نمایش بصری جدول بالا است:

sindadsec

همانطور که ملاحظه می‌کنید اغلب فایل‌های بدافزار (91.81%) از فقط یک منبع ارسال‌شده‌اند. همچنین مقدار قابل‌توجهی از فایل‌ها توسط دقیقاً دو (5.74%) یا سه (1.02%) منبع ارسال‌شده‌اند. روی‌هم‌رفته این سه طبقه‌بندی مسئول 98.57% تمامی فایل‌های بدافزار است. تمامی طبقه‌بندی‌های دیگر کمتر از 1% فایل‌ها را شامل می‌شوند (4 ارسال‌کننده به میزان 0.42% هستند).

حتی قرار دادن مقادیر باقیمانده در طبقه‌بندی «بیشتر از ده ارسال‌کننده» هم میزان 0.33% از فایل‌های کل را به خود اختصاص داد. اگر انتظار شناسایی مقادیر هش ثالث را در شبکه‌های خود داشته باشیم، باید به سراغ فایل‌های قرارگرفته در این طبقه برویم. آستانۀ مشخص خاصی برای اینکه هش‌های ثالث در فرایند شناسایی مفید واقع شوند، وجود ندارد اما 0.33% کمتر از هرگونه آستانۀ مؤثر و معقولی است.

چه زمانی هش‌ها برای فرایند شناسایی مفید هستند؟

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

موقعیت دیگر زمانی است که هش ثالث در سازمان دیگری که ارتباط نزدیک با شما دارد مشاهده شود، برای مثال یک شریک تجاری یا یک شرکت فرعی. در موارد خاص شاید سازمان‌های دیگری که مشخصات مشابه با شما داشته باشند نیز مورد توجه باشند، یعنی سازمان‌هایی که در زمینۀ صنعتی شما فعالیت کنند یا در مکان جغرافیایی مشابه شما قرارگرفته باشند. در این موقعیت هش‌های ثالث می‌توانند مفید واقع شوند، بخصوص اگر سازمان‌های مختلفی مورد هدف یک عامل قرار گیرند.

جمع بندی

با استفاده از ارسال‌های انجام‌شده به VirusTotal به‌عنوان عاملی برای تعیین اینکه چه تعداد سازمان هر فایل را مشاهده می‌کنند، داده‌هایی به دست آمد که از فرضیۀ اولیۀ ما مبنی بر اینکه مقادیر هش یک شبکه بعید است توسط شبکه‌های دیگر مشاهده شوند، پشتیبانی می‌کنند. 91.81% از تمامی فایل‌ها توسط یک ارسال‌کننده ارسال می‌شوند، همان‌طور که انتظار می‌رفت. تعداد فایل‌هایی که توسط 2 یا 3 ارسال‌کننده ارسال‌شده‌اند، مورد انتظار نبوده است اما همچنان مطابق با فرضیه است. فقط 0.33% از فایل‌ها توسط بیش از ده سازمان ارسال‌شده‌اند. برای اینکه هش‌های ثالث در فرایند شناسایی مؤثر باشند، این عدد باید خیلی بزرگ‌تر باشد.

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

از آشنایی با شما خوشحالیم 👋

برای باخبر شدن از آخرین خبرهای دنیای امنیت، لطفا در خبرنامه سیندادسک عضو شوید.