تجربیات و نکات تست نفوذ؛ با علی فیروزی
تجربیات و نکات تست نفوذ؛ با علی فیروزی
در این بلاگ‌پست، به سراغ یک متخصص تست نفوذ در دنیای امنیت سایبری رفته‌ایم تا با او گپ‌وگفت کوتاهی درباره‌ی تجربیاتش در تست نفوذ داشته باشیم؛ علی فیروزی (@afssec)
علی دو سه سالی ست که در حوزه‌ی امنیت سایبری فعالیت دارد. تمرکزش بر روی تست نفوذ وب اپلیکیشن هاست. در زمینه‌ی مشاوره‌ی امنیت و آموزش‌های امنیتی به نیروی انسانی کسب‌وکارها هم تجربیاتی دارد. یک شکارچی آسیب پذیری پاره‌وقت هم هست. آسیب پذیری های مورد‌علاقه‌اش، آسیب پذیری های authentication هستند.
ما مصاحبه‌ی دیگری هم با علی داشته‌ایم:
گپ‌وگفتی با شکارچی آسیب‌پذیری؛ علی فیروزی
از نگاه شما، تفاوت میان یک تست نفوذ خوب و یک تست نفوذ بد، در چیست؟
یکی از مسائل کلیدی در فرآیند تست نفوذ، نوشتن گزارش است. در نوشتن گزارش تست نفوذ، باید توجه ویژه‌ای به این نکته داشت که آیا هدف تنها تهیه‌ی یک فهرست از موارد آسیب‌پذیری است، یا این که می‌خواهیم با ارائه‌ی اطلاعات دقیق و توضیحات شفاف، کاری کنیم که گزارش و آسیب پذیری ها قابل‌فهم و اثربخش باشند؟ این امر باید به‌گونه‌ای باشد که هم برای تیم فنی مفید واقع شود و هم در مراحل رفع آسیب‌پذیری‌ها کمک‌کننده باشد. من در تجربه‌ام شاهد این بوده‌ام که برخی ازمتخصصین تست نفوذ گزارش‌هایی تهیه می‌کنند که تیم فنی پس از مطالعه‌ی آن‌ها به‌راحتی نمی‌تواند آسیب پذیری ها را شناسایی کند، یا نمی‌داند که چرا آسیب پذیری ایجاد شده است و چگونه باید آن را برطرف کند. به‌نظر من، متخصص تست نفوذ باید در نظر داشته باشد که تیم فنی معمولاً دیدگاه برنامه‌نویسی دارند و ممکن است دانش امنیتی تخصصی نداشته باشند. بنابراین، مهم است که متخصص تست نفوذ گزارشی تهیه کند که برای تیم فنی قابل‌فهم باشد و به آن‌ها کمک کند تا آسیب‌پذیری‌ها را رفع و از وقوع اکسپلویت‌ها توسط مهاجمین جلوگیری کنند.
علاوه بر گزارش‌های متنی، افزودن توضیحات ویدئویی هم می‌تواند تأثیر قابل‌توجهی در انتقال بهتر اطلاعات داشته باشد. زیرا در برخی موارد، توضیحات متنی ممکن است برای تیم فنی کافی نباشد و منجر به سوءتفاهم یا عدم درک صحیح شود. ویدئوها می‌توانند به‌طور مؤثرتری جزئیات را منتقل کنند. به کمک ویدئوها این اطمینان حاصل می‌شود که تمام نکات به‌درستی درک شده‌اند.
در فرآیند تست نفوذ، معمولاً پیش می‌آید که متخصصین تست نفوذ بر اساس چک‌لیست‌های مشخصی پیش می‌روند. بسیاری از افراد تست نفوذ را به همین شیوه می‌شناسند و پیروی از چک‌لیست را یک روال استاندارد می‌دانند. اما از نظر من، محدود‌کردن خود فقط به چک‌لیست، ایده‌آل نیست. علاوه بر استفاده از چک‌لیست، یک متخصص تست نفوذ باید از خلاقیت خود بهره‌برداری کند و سناریوهای ترکیبی را نیز به‌کار گیرد. به این معنا که پس از کسب درک و دید مناسب از اپلیکیشن، به آسیب پذیری های لاجیکال نیز توجه داشته باشد. این رویکرد، امکان شناسایی آسیب پذیری های بیشتری را فراهم می‌آورد. این خلاقیت یکی از تفاوت‌های رایج میان شکارچی آسیب پذیری ومتخصص تست نفوذ هم هست. یک شکارچی آسیب پذیری معمولا صرفاً بر اساس چک‌لیست پیش نمی‌رود، بلکه از خلاقیت خود برای بررسی سناریوهای مختلف بهره می‌برد. این ترکیب‌های خلاقانه می‌تواند به کشف آسیب‌پذیری‌هایی منجر شود که ممکن است در یک تست نفوذ عادی شناسایی نشوند.
_ آیا نکته‌ای در خصوص تست نفوذ وجود دارد که کسب‌وکارها به آن توجه نمی‌کنند؟
کسب‌وکارهای مختلفی به انجام تست نفوذ می‌پردازند، اما شیوه‌های انجام آن در هر کسب‌وکار ممکن است متفاوت باشد. در بسیاری از موارد کسب‌وکارهای بزرگ‌تر، چندین نفر را به عنوان متخصص تست نفوذ استخدام می‌کنند. به‌عبارتی برای تست نفوذ نیروی کار حضوری دارند. در چنین کسب‌وکارهایی، روند کاری به‌طور معمول به این صورت است که توسعه‌دهندگان ابتدا بخش‌هایی از اپلیکیشن را توسعه می‌دهند و پس از تکمیل آن بخش‌ها، خودشان تست‌های برنامه‌نویسی را انجام می‌دهند تا مشکلات و باگ‌های آن قسمت را شناسایی کنند. به مرور زمان، این روند به فاز اجرایی منتقل می‌شود. من شاهد این بوده‌ام که در این مرحله، تست‌کردن به‌عنوان یک تسک به متخصص تست نفوذ واگذار می‌شود. یک شرکت ممکن است ده متخصص تست نفوذ داشته باشد، اما برای تست یک فیچر توسعه‌یافته، این تسک فقط به یکی از آن‌ها واگذار می‌شود. متخصص تست نفوذ هم با استفاده از دانش و خلاقیت خود آن فیچر را تست می‌کند و گزارش می‌دهد که آیا آسیب‌پذیری وجود دارد یا خیر. در صورتی که آسیب‌پذیری‌ای شناسایی شود، متخصص تست نفوذ آن را گزارش می‌کند و به تیم توسعه‌دهندگان می‌دهد تا اصلاحات لازم صورت گیرد. اما اگر آسیب پذیری ای وجود نداشته باشد، اعلام می‌کند که هیچ‌گونه آسیب پذیر ای یافت نشده است.
به‌نظر من، مشکلی که این روند دارد، محدود بودن نگاه افراد است. افراد مختلف دارای خلاقیت‌های متفاوتی هستند. همان‌طور که در برنامه‌های باگ بانتی مشاهده می‌کنیم، بسیاری از آسیب‌پذیری‌هایی که در تست نفوذ کشف نمی‌شوند، توسط شکارچیان آسیب پذیری در این برنامه‌ها شناسایی می‌شوند. در فرآیند تست نفوذ نیز می‌توان این‌گونه عمل کرد که وقتی یک فیچر برای بررسی به متخصص تست نفوذ داده می‌شود، پس از انجام تست، نتایج آن به سایر منابع انسانی حوزه‌ی امنیت نیز منتقل شود. این انتقال به این منظور است که افراد دیگر نیز یک بررسی اجمالی انجام دهند و شاید خلاقیتی به ذهن آن‌ها برسد که در ذهن فرد اول نبوده است.
پیشنهاد خواندنی: هکرهای مختلف، چه ارزشی را به یک برنامه امنیتی جمع سپاری شده می‌افزایند؟
مسئله‌ی دیگری که وجود دارد این است که یک فیچر در فاز توسعه ممکن است با شرایط سامانه‌ی اصلی تطابق نداشته باشد. گاهی تست نفوذ فقط در فاز توسعه انجام می‌شود و وقتی فیچر به سامانه‌ی اصلی منتقل می‌شود، متخصصین تست نفوذ اجازه و آزادی کامل ندارند که روی آن سامانه‌ی اصلی تست نفوذ انجام دهند. این نگرانی وجود دارد که تست نفوذ در سامانه‌ی اصلی ممکن است به اختلال در عملکرد آن منجر شود. اما مفهوم ناسازگاری (Inconsistency) در اینجا مطرح است. ممکن است فیچری که در فاز توسعه تست شده، برخی از آسیب پذیری هایش کشف شده باشد. اما وقتی که بر روی سامانه‌ی اصلی پیاده‌سازی می‌شود، آن فیچر ممکن است با سایر فیچرهای قبلی ناسازگار شود و آسیب پذیری های لاجیکال و منطق‌محور بروز پیدا کنند. این آسیب پذیری ها ممکن است توسط مهاجمان بیرونی شناسایی شوند.
کسب‌وکارها ممکن است به‌خاطر غفلت از این نکته، احساس کنند که با وجود هزینه‌ای که برای تست نفوذ صرف کرده‌اند، متخصصین تست نفوذ قادر به شناسایی آسیب پذیری های ساده نبوده‌اند. اما دلیل اصلی این موضوع این است که معمولاً به متخصصین تست نفوذ، شرایط مناسب و کافی برای انجام تست نفوذ کامل و جامع داده نمی‌شود. به‌عنوان مثال، نداشتن دسترسی به نسخه‌ی کامل دمو در کنار نسخه‌ی اصلی سامانه باعث می‌شود که متخصص تست نفوذ نتواند به‌درستی سامانه را بررسی کند. این نقص در بسیاری از سازمان‌ها و ارگان‌ها وجود دارد و باعث می‌شود تست نفوذ ها کمتر و سطحی‌تر انجام شوند. دلایل این محدودیت معمولاً نگرانی از اختلالات و مشکلات احتمالی است، اما نتیجه‌اش این می‌شود که مهاجمان خارجی به‌راحتی می‌توانند آسیب پذیری ها را شناسایی و آن‌ها را اکسپلویت کنند.
_ در تجربه‌ی خود، چه در شکار آسیب پذیری و چه در تست نفوذ، آیا شاهد این بوده‌ای که نقطه‌ی خاصی از کسب‌وکارها آسیب پذیرتر بوده باشد؟
بله، معمولاً در پیاده‌سازی سرویس‌های اکسترنال، این فرآیند باید بر اساس داکیومنت‌های موجود انجام شود. اما متاسفانه در برخی موارد، توسعه‌دهندگان تمایلی به مطالعه‌ی کامل داکیومنت‌ها ندارند و تنها بر اساس قسمت‌هایی که مطالعه کرده‌اند، پیاده‌سازی را آغاز می‌کنند و به تدریج پیش می‌روند. این رویکرد باعث می‌شود که بسیاری از نکات و جزئیات مهم از قلم بی‌افتد. در این مسیر، گاهی اوقات برخی از جوانب به طور کامل بررسی نمی‌شوند یا پیاده‌سازی به شیوه‌ای اصولی‌تر انجام نمی‌شود.
برای مثال، در پیاده‌سازی درگاه‌های پرداخت، اغلب شاهد وجود آسیب پذیری هایی هستیم که به دلیل رعایت‌نکردن تمام موارد امنیتی در داکیومنت‌ها، بروز می‌کنند. بسیاری از کمپانی‌های داخلی که با آن‌ها روبرو شده‌ام، معمولاً در بخش درگاه پرداخت حداقل یک آسیب‌پذیری دارند. فارغ از درگاه‌های پرداخت، طیف آسیب‌پذیری‌ها می‌تواند بسیار متنوع باشد، از جمله مشکلات امنیتی در پیاده‌سازی سرویس‌های خارجی برای فایل‌ها. همه‌ی این موارد معمولا به دلیل ضعف دانش امنیتی تیم‌های توسعه‌دهنده حتی در بزرگترین سازمان‌ها نیز اتفاق می‌افتند و لازمه‌ی جلوگیری از این اتفاقات، توجه بیشتر به امنیت سایبری است.
_ ممنون که در این مصاحبه همراه ما بودی و تجربیاتت در زمینه ی تست نفوذ را به اشتراک گذاشتی علی عزیز.
بلاگ‌پست‌های مرتبط: