دوره آموزشی SEC504 – بخش نهم

آنالیز آسیب پذیری و ابزارهای پاسخگویی به رخداد

Vulnerability Analysis

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

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

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

NeXpose
Qualys
OpenVAS
GFI LANGuard
Recovery

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

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

Monitor

نیازی به گفتن این مطلب نیست که اگر Eradiction به صورت کامل انجام نشود، موجب بازگشت مشکل و حادثه خواهد شد. پس باید تمامی موارد مربوط به Eradiction را با جزئیات کامل اجرا نمایید. البته با تمام این موارد باز هم امکان بازگشت حادثه متصور خواهد بود، ممکن است شما نوع حمله یا Attack Vector را کشف نکنید و حادثه دوباره اتفاق بیافتد.

به همین دلیل پیشنهاد می‌کنیم که فرآیند مانیتورینگ را پس از بازگردانی انجام دهید. در این بخش شما باید ساختار ارتباطی سیستم را به منظور شناسایی وجود احتمالی Backdoor‌ ها بررسی نمایید. علاوه بر این استفاده از سیستم‌های IDS/IPS نیز برای شناسایی حملات و حذف آن‌ها بسیار موثر می‌باشد و می‌توانید یک Signature جدید و سفارشی برای حملات پیشین ایجاد کنید تا در صورت بازگشت نفوذگر و تلاش برای دسترسی به سیستم، آن را شناسایی نمایید.

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

Lessons Learned

فرض کنید که یک حادثه در ساعت 4 و 30 دقیقه روز چهارشنبه برای شما اتفاق افتاده است درست همان زمانی که شما باید به منزل رفته و برای تعطیلات آخر هفته آماده شوید. شما به این دلیل باید تمام شب را در شرکت مانده و به پیگیری حادثه بپردازید. در فرآیند پاسخگویی و پیگری حادثه شما خسته می شوید و شاید حالت بیمارگونه ای برای شما ایجاد شود و ترجیح می دهید تا مشکل هر چه زودتر برطرف شده و همه چیز به حالت عادی خود برگردد. اما باید همواره انرژی خود را حفظ نمایید و نظم لازم را برای تهیه گزارش داشته باشید.

حادثه در نهایت به پایان می‌رسد و شما به حالت عادی خود باز می گردید ولی نکته مهم مرحله Lessons Learned می‌باشد که در این مرحله شما باید از اشتباهات رخ داده درس بگیرید و به جای تکرار آن‌ها سعی کنید اشتباهات جدید را تجربه کنید.
توجه داشته باشید که مهاجمان همواره در حال ارتقاء دانش خود هستند پس ما هم به عنوان Incident Handler برای رویارویی با نفوذگران باید دانش خود را بهبود ببخشیم. این هدف اصلی بخش Lessons Learned می‌باشد.

Report

هدف اصلی در مرحله Lessons Learned مستندسازی اتفاق‌های رخ داده و همچنین بهبود توانایی و قابلیت‌های خودمان است.
تنها کسی که ‌می‌تواند این گزارش را بنویسد، Handler ای است که در صحنه حادثه حضور داشته است. پس از نوشتن گزارش می بایست آن را تحویل سرپرست تیم Incident Handling داد. وی این سند را ویرایش نموده و با Handler هماهنگ می‌کند تا اطمینان حاصل شود، سند در واقع همان اتفاقاتی است که رخ داده است. سپس باید با افرادی که درگیر این حادثه بوده اند هماهنگی انجام شده و این افراد باید محتوای گزارش را تایید و امضا نمایند.

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

Meeting

پس از بررسی گزارش، یک زمان برای جلسه Lessons Learned هماهنگ نمایید. به طور کلی هدف اصلی چنین جلسه ای، اجماع و توافق در خلاصه اجرایی (Executive Summary) گزارش می‌باشد. پیشنهاد می‌شود که این جلسه ظرف دو هفته پس از شروع مراحل Incident Handling تشکیل شود، زیرا هنوز رویدادها و مشکلات در ذهن افراد باقی می‌باشد.

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

همچنین شما باید جلسه را به گونه ای برگزار نمایید که زمان زیادی به طول نیانجامد.

Apply Fixes

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

این رویکرد ‌می‌تواند شامل تغییر در فرآیندها، تکنولوژِی‌ها و یا بهبود قابلیت‌های تیم Incident Handling باشد.

Enterprise Incident Response

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

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

Ingress and Egress Data

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

توجه داشته باشید که در موقعیت‌هایی مانند یک حادثه، هدف این نیست که یک حمله را متوقف نمایید بلکه باید قادر باشید تا نقاط فرماندهی و کنترل (Command and Cotrol) را تشخیص داده و سیستم‌های داخلی دیگری که ممکن است به خطر بیافتند را شناسایی نمایید. و اگر یک شبکه به درستی پیکربندی شده باشد، تمام ترافیک خروجی باید از طریق یک فایروال ، Resolve یک دامنه از طریق DNS و ارتباطات وب از طریق پروکسی وب به خارج هدایت شوند. پس استفاده از لاگ‌های ثبت شده در این سامانه‌ها تا حد زیادی ‌می‌تواند به ما در مراحل شناسایی و پاسخگویی به حادثه کمک نماید.

DNS Data

داده‌های DNS ‌می‌توانند یکی از قوی ترین ابزارهای تشخیص ترافیک مخرب باشند. با توجه به اینکه برخی از آنتی ویروس‌ها قادر به شناسایی برنامه‌های مخرب نبوده و همچنین برخی از بات نت‌ها از دامنه‌ها برای ارتباطات خود استفاده می‌کنند، پس آنالیز DNS و Cache آن و مقایسه آدرس‌های آن با لیست آدرس‌های مخرب می توان به شما بسیار کمک نماید.

یکی از تکنیک‌هایی که به عنوان بخشی از پاسخگویی به حادثه می توانیم مورد استفاده قرار دهیم، مقایسه Cache سرور DNS با لیست از آدرس‌های IP مخرب (Evil IP) است که این کار با استفاده از ابزار مبتنی بر پایتون dns-blacklists قابل انجام است. شما می‌توانید این ابزار را از طریق لینک زیر دانلود نمایید:

https://bitbucket.org/ethanr/dns-blacklists

همچنین برای مشاهده لیست آدرس‌های Malware می‌توانید به آدرس زیر مراجعه نمایید:

https://www.malwaredomainlist.com/mdl.php

Web Proxy Data

امروزه اکثر محیط‌های سازمانی، از فیلترینگ محتوا با مجموعه ای از Web Proxy‌ها برای محدود سازی دسترسی کارمندان به برخی سایت‌های خاص استفاده می‌کنند. البته از نگاهی دیگر این ابزارهای برای پاسخگویان به حادثه نیز بسیار کاربردی می‌باشند. به همین منظور با بررسی منظم سامانه‌های Web Proxy می‌توانید سیستم‌های تسخیر شده ای (Compromised) که با سایت‌های مخرب C2 ارتباط دارند را شناسایی نمایید.

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

مورد بعدی بررسی User Agent‌های مربوط به کاربر است. در صورتی که بیشتر سیستم عامل‌های مورد استفاده در شبکه سازمان شما ویندوز 7 بوده و آخرین نسخه اینترنت اکسپلورر نیز بر روی آن نصب است ولی شما User Agent مربوط به ویندوز xp و اینترنت اکسپلورر 6 را مشاهده می‌کنید، این ممکن است نشاندهنده وجود یک بدافزار باشد. بسیاری از نمونه‌های بدافزارها از User Agent‌های قدیمی استفاده می نمایند.

Connection Data

یکی دیگر از مولفه‌هایی که اغلب نادیده گرفته می‌شود، جست و جوی داده‌های خاموش یا (Beaconing Data) است. اغلب فرض می‌شود که نرم افزارهای مخرب یک ارتباط پایدار به سیستم‌های فرماندهی و کنترل خود برقرار می‌کنند. اما بدافزارهای امروزی این گونه نیستند. این بدافزارها در عوض تمایل دارند که ارتباط خود را با فاصله‌های منظم یا نا منظم با مرکز فرماندهی خود برقرار نمایند.

برای شناسایی این متد ارتباطی، ما نیازمند آنالیز و بررسی لاگ‌های مربوط به کانکشن‌های ارتباطی خروجی فایروال هستیم. البته شخصی به نام Eric Conrad یک ابزاری را به منظور تجزیه فایل‌های لاگ جهت شناسایی تلاش برای برقراری ارتباط طراحی کرده است که شما می‌توانید از آدرس زیر آن را دانلود نمایید:

http://tinyurl.com/505and511

البته این ابزار مربوط به کلاس Continuous Monitoring دوره آموزشی SEC511 است.

WMIC

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

wmic product get narne,version

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

wmic /node:@systems.txt product get description,name,vendor /format:csv> Softwarelnventory.txt

/node:@systems,txt به شما اجازه می‌دهد تا دستور یکسانی را بر روی چندین سیستم اجرا نمایید.

SCCM

ابزار بعدی SCCM یا System Center Configuration Manager است. کاملا مشخص است که راه اندازی SCCM کار آسانی نیست. ولی هنگامی که شما آن را در اختیار داشته باشید، شما مجهز به قوی ترین سلاح در زاردخانه Incident Response خود خواهید بود. مولفه بسیار قدرتمند SCCM که برای IR مناسب می‌باشد، گزارش‌های آن است. با استفاده از این گزارش‌ها شما می‌توانید اطلاعات لازم در خصوص برنامه‌های نصب شده بر روی سیستم را در اختیار داشته باشید.

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

https://www.windows-noob.com/forums/topic/4550-using-sccm-2012-rc-in-a-lab-part-11-adding-the-reporting-services-point-role/

What about PowerShell

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

https://github.com/davehull/Kansa

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