Transcript مراحل تست نفوذ

‫بسمه‌تعالی‬
‫ت ـســت نـف ــوذ‬
‫‪1‬‬
‫رسول جلیلی‬
‫به ــار‪92‬‬
‫‪2‬‬
‫‪‬‬
‫مرور تکـ صفحه‌ای جلسه قبلـ‬
‫‪‬‬
‫مباحث ـ ت ـسـت ن ـف ــوذ‬
‫‪ ‬معرفـی تست نفــوذ‬
‫‪ ‬مراحلـ تست استاندارد‬
‫‪ ‬ابزارهای ـ تست ـ‬
‫‪ ‬نــتیج ‌هگ ــیریـ‬
‫‪3‬‬
‫هرگزپختن املت بدون شکستن تخم‌مرغ‌ها ممکن نیست‬
‫‪ ‬تست نفوذ چیست؟‬
‫رویه ارزیابی امنیت برنامه از طریق شبیهسازی حمالت از طرف‬
‫حملهکنندگان بیرونی یا درونی (با سطوح دسترس ی متفاوت انتسابی‬
‫یا اکتسابی آنان)*‬
‫به تعریف توجه کنید! بیشتر منابع موجود در زمینه تست نفوذ‪ ،‬تنها به‬
‫جنبههای امنیت شبکهای و تست برنامههای تحت وب توجه میکنند‪.‬‬
‫‪4‬‬
‫‪*http://www.isaca.org/Pages/Glossary.aspx?tid=651&char=P‬‬
‫‪ o‬تست کارکردی معمول به دنبال ویژگیهای عملکرد صحیح برنامه بر اساس کارکردهای تعیین‬
‫شده است‬
‫‪ o‬ولی‪ ،‬امنیت نرمافزار یک یا چند کارکرد یا ویژگی نیست‬
‫‪ o‬حتی اگر در برنامه کارکردهای امنیتی مثل رمزنگاری و ‪ ...‬داشته باشیم <<<<اغلب‬
‫آسیبپذیریها مستقیما به این کارکردها مربوط نیستند <<<به سوء استفاده حملهکننده از‬
‫کارکردها باز میگردند‪.‬‬
‫‪ o‬تست کارکردی<<<< تست مثبت‌ها (وجود کارکردها)‬
‫در کارکرد خاص ی نمی‬
‫‪ o‬تست نفوذ <<<< تست منفی‌ها (عدم وجود حفره‌هایی که الزاما ‌‬
‫گنجند)‬
‫‪5‬‬
‫‪ ‬در هر زمینهای تست منفیها چالش بزرگتری از تست مثبت هاست‬
‫‪ ‬چند تست لزم است تا بتوان گفت که این سیستم به حد کافی تحت حمله‬
‫امن است؟!‬
‫‪ ‬اگر تست منفیها هیچ خطایی را نشان دهد تنها به معنای نبود خطا تحت‬
‫یک تست خاص است و به هیچ وجه به معنای نبود کلی خطا نیست‬
‫‪6‬‬
‫تولد آسیبپذیری در ‪ 3‬مرحله کلی حیات نرمافزار ‪:‬‬
‫‪ .1‬تعریف ویژگیها و طراحی‬
‫•‬
‫کشف عیوب طراحی دشوار بوده و در جلسه گذشته و آینده بدان پرداخته شده و میشود‬
‫‪ .2‬توسعه‬
‫•‬
‫به دلیل پیادهسازی نادرست و یا نامطلوب رخ داده است‬
‫‪ .3‬به‌کارگیری در محیط عملیاتی‬
‫•‬
‫‪7‬‬
‫به دلیل تنظیمات پیشفرض و یا مستندسازی نادرست برای به کارگیری امن نرمافزار رخ داده است ‪.‬‬
‫تست نفوذ نیازمند هر دو کاله ‪:‬‬
‫‪ ‬کاله سفید برای اطمینان از عملکرد درست کارکردهای امنیتی برنامه‬
‫‪ ‬کاله سیاه برای اطمینان از عدم نفوذ حملهکننده به کل برنامه یا سیستم‬
‫‪8‬‬
‫‌افزار به ندرت نیازمندی‌های امنیتی‪،‬‬
‫در توسعه‌های فعلی نرم ‌‬
‫‪‌ ‬‬
‫سناریو‌های سوء کاربرد‪ ،‬دانش ریسک‌های امنیتی ‌و نیز الگوهای حمالت‬
‫قرار می گیرد‪.‬‬
‫در طراحی مورد توجه ‌‬
‫نیز همین وضعیت را دارد‪.‬‬
‫‪ ‬تست ‌‬
‫در نتیجه ‪:‬‬
‫‪‌ ‬‬
‫در‬
‫در میان تیم‌های مختلف ‌و ‌‬
‫یافته‌های امنیتی قائم به شخص بوده ‌و ‌‬
‫تکرار نیستند‪...‬‬
‫طول‌ زمان قابل ‌‬
‫در عمل تست نفوذ تنها بخش کوچکی ‌از ریسک‌های امنیتی‬
‫‪ ‬با این وضع ‌‬
‫موجود را می یابد‪.‬‬
‫‪ ‬نتیجه نهایی<<< القای امنیت دروغین‬
‫امنیت نداشته اند‪....‬‬
‫‪9‬‬
‫به نرم‌افزارهایی که‬
‫‪10‬‬
‫‪ .1‬اقدامات پیش ‌از درگیری‌ اولیه‬
‫‪ .2‬جمع‌آوری اطالعات‬
‫‪ .3‬مد‌سازی‌ تهدید‬
‫‪ .4‬تحلیل آسیب‌پذیری‌‬
‫‪ .5‬اکسپلویت نمودن آسیب پذیری‌‬
‫‪ .6‬انجام عملیات بعد ‌از اکسپلویت‬
‫‪ .7‬گزارش‌دهی‬
‫بر اساس استاندارد ‪PTES‬‬
‫‪Penetration Testing‬‬
‫‪Execution Standard‬‬
‫‪11‬‬
‫‪‬‬
‫فراهم سازی ابزارهای عمومی نفوذ‬
‫‪‬‬
‫ابزارهای خاص بسته به نوع و عمق نفوذ‬
‫‪‬‬
‫در بخش بعد به تفصیل به ابزارها خواهیم‬
‫پرداخت‬
‫‪12‬‬
‫‪o‬‬
‫یک حملهکننده به چه اطالعاتی نیاز دارد و آنها را از چه منابعی خواهد‬
‫یافت؟‬
‫مکانیابی فیزیکی‬
‫مکانیابی مراکز داده‬
‫جمعآوری اطالعات درباره کارکنان سازمان از منابع باز‬
‫ایمیلها و ارتباطات درونسازمانی‬
‫اسکن پورتهای باز‬
‫انبوه ابزارهای غیرقابل باور در‬
‫‪o‬‬
‫هر حوزه!‬
‫‪o‬‬
‫اطالعات ‪DNS‬‬
‫شنود فیزیکی بیسیم و با سیم در جستوجوی کلیدها و ‪..‬‬
‫جستوجوی اطالعات ‪SNMP‬‬
‫‪o‬‬
‫‪VoIP mapping‬‬
‫شناسایی سیستمها‪ ،‬سیستم عاملها‪ ،‬نسخه برنامههای کاربردی و سرورها‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫‪o‬‬
‫قابل بحث در ‪Mailing‬‬
‫‪ list‬درس در صورت تمایل به‬
‫اطالعات بیشتر‬
‫‪o‬‬
‫‪o‬‬
‫‪13‬‬
‫‪ ‬تست آسیبپذیری‬
‫• فعاالنه ‪‌‌:‬سریعتر و مطمئنتر اما با ریسک بیشتر باقی گذاشتن نشانه‬
‫•‬
‫ابزارهای پویش آسیبپذیری و ‪Fuzzing‬‬
‫• منفعالنه‪ :‬ریسک و نتیجه کمتر‬
‫•‬
‫‪‬‬
‫تایید آسیب‌پذیری‬
‫•‬
‫‪‬‬
‫ابزارهای شناسایی نوع سیستم مثل ‪ ،P0f‬ابزارهای ثبت ترافیک مثل ‪Wireshark‬‬
‫پیداکردن کد یا منابع الزم و تایید انجام‌پذیری اکسپلویت‬
‫تعیین راه‌های حمله‬
‫•‬
‫تهیه درخت حمله‬
‫•‬
‫شناسایی مکانیزم‌های حفاظتی (در سطح شبکه و سیستم)‬
‫‪ ‬گزارش در سطح مدیران اجرایی‬
‫‪14‬‬
‫‪‬‬
‫‪‬‬
‫اثرات تجاری‬
‫به همراه گزارش اولویت‌دهی ریسک‬
‫• گزارش فنی‬
‫‪ ‬شناسایی موارد سیستماتیک و تحلیل فنی ریشه آسیب پذیری‌‬
‫‪ ‬یافته‌های فنی‬
‫•‬
‫•‬
‫•‬
‫•‬
‫توضیحات‬
‫صفحه تصویرها(‪!)Screenshot‬‬
‫ارسال و دریافت‌های صورت گرفته‬
‫مثال‌هایی برای اثبات مفهموم (‪)PoC‬‬
‫‪ ‬نتایج قابل تکرار‬
‫•‬
‫•‬
‫موارد آزمون‬
‫ماشه‌های خطا‬
‫‪ ‬قابلیت‌های رصد و پاسخگویی به واقعه (‪)Incident Response‬‬
‫•‬
‫•‬
‫•‬
‫•‬
‫اطالعات جمع آوری شده‬
‫ْ‬
‫تحلیل آسیب‌پذیری و اکسپلویت‌ها‬
‫معیارهای تست نفوذ‬
‫اثرات باقی‌مانده‬
‫‪ ‬موارد متداول‌‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫متدولوژی‬
‫اهداف‬
‫حوزه‬
‫خالصه یافته‌ها‬
‫پیوستی از اولویت‌بندی ریسک‬
‫نیاز به خالصه برای مدیران اجرایی که‬
‫احتماال قدم به قدم اعمال تست‬
‫برایشان چندان جالب توجه نیست‬
‫مهم‌ترین بخش گزارش که باید به دقت‬
‫نگاشته شود‬
‫یادآوری محرمانگی و حفظ مسائل حریم‬
‫خصوص ی (در متن گزارش اصلی نیز بایست‬
‫اشاره شود)‬
‫لوگوی سازمان تست‌کننده‬
‫‪15‬‬
‫‪16‬‬
‫اقداماتی که بعد از اکسپلویت بایست انجام شود‬
‫‪‬‬
‫جمع آوری اطالعات احتمالی مورد نیاز (فایلها‪،‬‬
‫پیکربندیها و ‪)...‬‬
‫‪‬‬
‫پاک کردن اطالعات ممیزی(‪)log‬‬
‫‪‬‬
‫غیر فعال کردن نرمافزارهای حفاظتی‬
‫‪‬‬
‫جمعآوری درهم شده (‪‌)hash‬کلمات عبور یا خود آنها‬
‫‪‬‬
‫اجرای برنامههای مورد نظر‬
‫‪‬‬
‫‪...‬‬
‫‪17‬‬
‫هدف از این بخش تنها آشنایی با رویکردهای‬
‫مختلف موجود در ابزارهاست و نه آموزش نحوه‬
‫کارکرد آنها‬
‫‪‬‬
‫کیفیت ابزارهای استفاده شده در تست نفوذ تا حد زیادی می تواند کیفیت تست را هم‬
‫تحت تاثیر قرار دهد‪.‬‬
‫‪‬‬
‫وجود ابزار برای مراحل مختلف و انواع تست علیه حمالت گوناگون‬
‫› هرچند در اکثر منابع<<< معرفی ابزارهای تست نرمافزار تحت وب‬
‫محل بروز حمالت مختلف‬
‫علیه سیستم نرم‌افزاری‌‬
‫‪18‬‬
‫‪ ‬فوائد استفاده از ابزار‪:‬‬
‫‪‬خودکار کردن اکثر رویههای مورد نیاز در تست‬
‫‪‬تولید خروجی قابل استفاده برای محاسبه معیارهای کنترلی‬
‫‪ ‬توجه! ابزار هیچگاه جایگزین مرور یک تحلیلگر امنیتی ماهر نمی شود‪.‬‬
‫مخصوصا اینکه ابزارهای موجود ذاتا به سطح طراحی قابل اعمال نیستند‪.‬‬
‫‪19‬‬
‫‪20‬‬
‫‪ ‬غالبا نام این ابزارها را به عنوان ابزار تست نفوذ خواهید شنید<<<الزم ـ ولی ناکاف ــی‬
‫‪‬‬
‫ابزار های شناسایی شبکه به صورت برون خط و ابزارهای نگاشت توپولوژی شبکه‬
‫‪‬‬
‫ابزارهای پویش آسیبپذیری ‪acunetix‬‬
‫‪‬‬
‫ابزارهای اخذ ترافیک وب مثل ‪ieinspector‬‬
‫‪ ‬رویکرد‬
‫‪Continuous Dynamic Application Security Testing‬‬
‫محصول ‪ Cenzic‬برای تست ‪ Cloud, Mobile‬و برنامههای تحت وب‬
‫‪21‬‬
‫‪ ‬ابزارهای تزریق خطا‬
‫‪ ‬دیباگر ها‪ ،‬دیساسمبلرها و دیکامپایلر‬
‫‪ ‬ابزارهای بررس ی فراخوانیها و ‪ Dll‬ها مثل ‪DLLSPY‬‬
‫‪ ‬ابزارهای بررس ی پیمانه ها و وابستگیهای مابین مثل‬
‫‪dependencywalker‬‬
‫‪Fuzzing ‬‬
‫‪ ‬تزریق کد به برنامه یا پیمانههای محیطی در جستوجو برای یافتن خطاهای‬
‫مربوط به کد اداره خطا (که در انواع دیگر تست ممکن است یافته نشوند)‪‌.‬‬
‫‪ ‬انتقال برنامه به حالت تعریف نشده یا اداره نشده (آیا برنامه همه خطاهای‬
‫احتمالی را اداره میکند؟)‬
‫‪ ‬دارای انواعی کلیتر(در مباحث تحملپذیری خطا)‌‪:‬‬
‫› تزریق خطای سختافزار‬
‫› تزریق خطای نرم‌افزار‬
‫‪ ‬زمان کامپایل‬
‫‪ ‬زمان اجرا‬
‫› تزریق خطای پروتکل‬
‫‪ ‬تزریق خطای نرمافزاری قابل انجام در محیطهای کامال مجازی شده تا محیط‬
‫عادی برنامه‬
‫‪22‬‬
‫‪ ‬یک ابزار تزریق خطای قوی‬
‫‪ ‬استفاده در توسعه دهندگان سرشناس ی چون‬
‫‪Adobe, McAfee‬و مایکروسافت‬
‫‪ ‬محیط شبیهسازی شده برای تست‬
‫‪ ‬شبیهسازی شکست در فراخوانی سیستمعامل ( برای‬
‫شبیهسازی شرایطی مثل در حال استفاده بودن فایل‬
‫انحصارا قابل دسترس ی‪ ،‬پر بودن حافظه‪ ،‬یا پایین بودن‬
‫شبکه و ‪) ...‬‬
‫‪ ‬امکان تعریف خطاهای خاص توسط توسعهدهنده‬
‫‪ ‬دارای دیباگر تجمیعی برای اشکالیابی همزمان‬
‫‪ ‬و ‪....‬‬
‫‪23‬‬
24
‫‪ ‬مکانیزم کشف آسیبپذیریهای نرمافزار با فراهم کردن ورودیهای غیر‬
‫منتظره و رصد عکسالعمل برنامه‬
‫‪25‬‬
‫تصویر از ‪blog.rootshell.be‬‬
‫‪‬‬
‫فازر‌های ایستا و قالب‪-‬مبنا‪‌‌:‬اینگونه فازرها تنها پروتکلهای شامل درخواست و‬
‫پاسخ و یا فایل فرمت های ثابتی را تست میکنند ‪‌.‬هیچ ویژگی پویایی در آنها‬
‫نیست و نیز هیچ آگاهی از پروتکل مورد تست ندارند‪‌.‬‬
‫‪‬‬
‫فازرهای بلوک‪-‬مبنا ‪‌‌:‬این فازرها ساختار پایه برای یک پروتکل درخواست و پاسخ‬
‫را پیادهسازی کرده اند و میتوانند کارکردهای پویای ثابتی مثل محاسبه‬
‫‪ CHECKSUM‬و ‪‌..‬داشته باشند‪‌.‬‬
‫‪‬‬
‫فازر‌های تکاملی یا نسل پویای فازر‌ها‪‌‌‌:‬اینها الزاما پروتکل یا فایل فرمت مورد‬
‫تست را نمی فهمند اما بر اساس بازخورد از سیستم آن را یاد میگیرند‬
‫‪‬‬
‫فازر‌های مدل‪-‬مبنا یا شبیه‌ساز‪‌‌:‬این فازرها با پیاده سازی همه پروتکل یا مدلی از‬
‫آن و یا شبیهسازی آن نه تنها ساختار پیامها را ‪ fuzz‬می کنند بلکه توسط آنها‬
‫پیامهای غیر منتظره نیز در ترتیب پیامها قابل تولید خواهد بود ‪‌.‬‬
‫‪26‬‬
‫‪ ‬ابزارهای‪ fuzzing‬به صورت محلی‬
‫› مثل ‪ iFuzz‬برای تشخیص ‪ format string‬و سرریز در برنامههای سیستم محلی‬
‫و یا رفتار در برابر بازگرداندن متغیرهای محیطی نادرست‬
‫› فازرهای فایل فرمت که انواع فایلهای مشکلدار را برای برنامههایی با وروی‬
‫فایل تولید میکنند‪.‬‬
‫‪ ‬ابزارهای ‪ fuzzing‬از راه دور‌‬
‫› فازرهای تشخیص آسیبپذیریها در پروتکلهای شبکه همچون ابزارهای فریم‬
‫کاری ‪SPRIKE‬‬
‫› فازرهای برنامههای تحت وب مثل ‪ web Scarab‬متعلق به ‪owasp‬‬
‫› فازرهای مرورگر‬
‫‪ ‬ابزارهای ‪ fuzzing‬درون حافظه‬
‫‪27‬‬
‫با اینکه تست نفوذ از جمله متداولترین مراحل توسعه امن نرمافزار است اما ‪:‬‬
‫‪ ‬توسط افراد امنیتی بر تیم نرمافزار اعمال میشود<<< همه تیم عصبانی‬
‫هستند!‬
‫‪ ‬رویکرد از بیرون به درون <<<<دید لزم ولی ناکافی‬
‫‪ ‬تالش خیلی ناچیز‪-‬خیلی دیر برای پیگیری مشکالت امنیتی در پایان چرخه‬
‫توسعه!‬
‫‪ ‬رفع مشکالت در این برهه هزینهبر است<<< اغلب بجای درمان تنها پانسمان‬
‫میشوند!‬
‫‪ ‬اغلب اقدامات در نتیجه تست نفوذ ذاتا واکنش ی ‌و منفعالنه هستند‪.‬‬
‫‪ ‬در عمل تست نفوذ استاندارد مورد قبولی که در حال استفاده باشد ندارد!‬
‫‪28‬‬
‫‪29‬‬
‫‪‬‬
‫بر سطح سیستم داشته باشد و ویژگیهای سیستمهای‬
‫تمرکز ‌‬
‫‌‬
‫تست نفوذ نرمافزار بایست‬
‫نرمافزاری تجمیعی را نیز در نظر بگیرد‪.‬‬
‫‪‬‬
‫دانش ریسک‌های نرم‌افزاری‌‪ ،‬نیازمندی اصلی تست نفوذ‬
‫‪‬‬
‫در‬
‫بیشتر مشکالت تست نفوذ به دلیل درس نگرفتن از تجربیات گذشته و باقی نماندن آن‌ها ‌‬
‫سازمان است‪.‬‬
‫‪‬‬
‫بار انجام نمی‌شود‪ ،‬تستهای پشت سرهم میتوانند نقصهای به ترتیب‬
‫تست نفوذ یک ‌‬
‫جزئیتری را افشا سازند ‪.‬‬
‫‪‬‬
‫از تست نفوذ به عنوان « آخرین چک» استفاده کنید نه اولین ژست امنیتی فرآیند توسعه!‬
30
‫‪31‬‬
‫‪ ‬تست امنیتی ریسک‌مبنا‬
‫‪ ‬رویکردی بینابینی تست در مراحل‬
‫اولیه‬