پاسخ به 7 پرسشی که همیشه می خواستید از یک محقق آسیب های امنیتی بپرسید

مصاحبه میرکو زورز –سردبیر مجله insecure – با میتجا کلوسک، مدیر کل شرکت امنیتی ACROS  و یک محقق سرشناس آسیب های امنیتی

میتجا کلوسک، مدیر کل شرکت امنیتی ACROS  و یک محقق سرشناس آسیب های امنیتی است. کلوسک در طول 13 سال فعالیت در زمینه امنیت، در حوزه های امنیت سیستم های بانکی، محصولات تجاری، شبکه های کامپیوتری و پروتکل ها، تحقیق در مورد آسیب های غیرمعمول و یافتن راهکارهای موثر برای آنها فعالیت می کند. بیشتر علاقه مندی وی به تحقیق و مطالعه در رابطه با یافتن مشکلات جدید امنیتی و پیدا کردن باگ های امنیتی ویژه در سیستم های بانکداری و تجارت الکترونیک است.

در اینجا 7 سوال از میتجا کلوسک پرسیده شده است که بدون شک برای علاقه مندان به امنیت و فناروی اطلاعات بسیار جالب خواهد بود.

۱- هنگام مطالعات آسیب های امنیتی، تفاوت اساسی بین منابعی که کد آنها را در اختیار دارید با آنهایی که کد بسته ای دارند چیست؟

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

نخست – بسیاری از آسیب های امنیتی را می توان از میان کدهای منابع به راحتی پیدا کرد. به طور مثال، می توانم به الگوی ساده “<%=Request.QueryString" در برنامه نویسی ASP دات نت اشاره کنم که بیشتر مواقع نشان دهنده حملات تزریق کد یا cross- site scripting است. دوم – شما می توانید بر فرض مثال، همه کد یک محصول را بخوانید. به این دلیل می گویم «برفرض مثال» که مسلما اگر بخواهید همه کدهای یک محصول را بخوانید باید زمان بسیاری صرف کنید و این چندان جالب نیست و به نظر من باید بیشتر زمان خود را بر قسمت های کلیدی و مهم آن متمرکز کنید. بعلاوه، شما همیشه هم نمی توانید همه کدهای محصول را داشته باشید. به دلیل اینکه بسیاری از محصولات کدهای جانبی بسیاری در خود دارند و همه کدهای آنها یا قابل دسترسی نیست یا بسته و مخفی هستند. یا به دلیل اینکه جمع آوری همه کدهای منبع محصولات پیچیده و مجموعه ای که یک گروه برنامه نویسی آن را منتشر کرده اند، چندان آسان به نظر نمی رسد و به همین دلیل شرکت ها ترجیح می دهند از روش های بهینه سازی استفاده کنند. در ضمن اینکه مشتری های شما نیز چندان تمایل ندارند برای بازخوانی کد کالای شرکت های دیگر به شما پول پرداخت کنند. سوم – راحت ترین راه برای یافتن اشکالات و باگ های منطقی مرتبط با شغل، جست‌وجو در کد منبع است. به طور مثال، در بانکداری الکترونیک، یکی از مسایل مهم این است که مطمئن شوید کاربر شما نمی تواند بیش از مبلغ تعیین شده از حساب خود برداشت یا منتقل کند. بهترین روش ممکن این است که در میان کد اصلی محصول به دنبال راهی برای میان بر زدن و یافتن راه های فرعی و جانبی باشید. این روش بسیار موثر از صدها بار سعی و خطا کردن برای یافتن باگ مورد نظر است که شاید در انتها هم از نتیجه کارتان مطمئن نباشید. چهارم – آسان ترین راه برای پیدا کردن سوراخ های امنیتی، جست و جو در کد اصلی است. به طور نمونه، بازبینی جعبه سیاه  برای کنترل اعتبار سنجی ضد حملات تزریق کد در سایت،  فقط از طریق ارسال کارکترها و الگوهای خطرناک به اپلیکیشن سرور و امید به اینکه یکی از روش های حمله سیستم اعتبار سنجی را دور بزند، ممکن است. اما با کنترل کد منبع می توانید فورا متوجه شوید کدام حملات بر روی این سایت کار نمی کنند. پنجم – به محض اینکه یکی از آسیب ها را شناسایی کردید، داشتن کد منبع به شما کمک می کند تا راهکار بهتر و مناسب تری برای فهمیدن کد مخرب پیدا کنید. این راه، یکی از بهترین روش ها برای برنامه نویس ها به شمار می رود. البته اگر بتوانید یک تغییر کد خاص را پیشنهاد و جایگزین کنید. به طور مثال، به جای استفاده از کد memcpy(d,s,strlen(s)) از memcpy(d,s,sizeof(d)) استفاده کنید. به هر صورت، بازخوانی کدهای منبع بهتر از تست جعبه سیاه نیست. زیرا برخی از اشکالات و سوراخ های امنیتی یک محصول را اعم از کامپیوتر یا سرور، می توان با یک آزمایش و تست ساده شناسایی و پیدا کرد. در حقیقت، باید گفت بررسی امنیت جعبه سفید (مبتنی بر کد منبع) و جعبه سیاه (تعامل با سایت) مکمل یکدیگر هستند و باید در مواقع لازم هر دو در راستای هم انجام بشوند. شاید احساس کنید که همه آسیب ها باید از طریق خواندن کد منبع مشخص و نمایان شوند. اما فاکتورهای متفاوتی در کدهای منبع وجود دارند که برخی از سوراخ ها و باگ های کد منبع را یا نمایش نمی دهند یا کدهای مخرب دیگری را نشان می دهند. دو نمونه از مثال های بارز این موضوع، بارگذاری کتابخانه یا library است که در برخی سیستم عامل ها وجود دارد و در برخی دیگر وجود ندارد. همچنین می توان به بازنویسی ruleهای وب سرور آپاچی اشاره کرد که باعث پاک شدن اطلاعاتی  می شود که کاربر وارد کرده است. ما بیشتر مواقع، هنگامی که به باگ مخرب در کد منبع برخورد کردیم، سعی می کنیم آن را در محصول آماده تست کنیم تا مطمئن شویم این باگ یا اشکال واقعا وجود دارد. یکی از مواردی که بیشتر مشتری ها از آن متنفر هستند، دادن گزارش های غلط از آسیب هایی است که هنگام اجرای برنامه ها به هیچ وجه وجود ندارند. آنها از اینکه صدها یا هزاران مورد از آسیب و باگ امنیتی برای آنها فهرست کنید، در حالیکه فقط چند مورد از این آسیب ها جدی و قابل توجه هستند، خوششان نمی آید. به همین دلیل، پیدا کردن آسیب ها و باگ های امنیتی از کد منبع پروسه زمان گیری است. زیرا بعد از یافتن باگ موردنظر باید آن را در مرحله اجرایی نیز تست کنید و ببینید آیا واقعا اشکالی در محصول ایجاد می کند یا خیر. به طور مثال، در مورد اپلیکیشن سرور، درخواستی بنویسید که باعث اجرا شدن باگ بشود تا بتوانید آن را تست کنید. البته این کار چندان ساده نیست. شاید کدی که برای اجرای باگ نوشته اید، خوانده نشود یا از طریق ماژول های دیگری شناسایی و اجرا شود. یا شاید حتی اتفاق بیافتد که اشکالی که شما یافته اید اصلا قابل دسترسی نباشد.   ۲-  از چه ابزاری برای کارهای روزانه خود استفاده می کنید؟ شهرت شرکت ما برای داشتن راهکارهایی است که انجام آنها دشوار است. یعنی بخش اعظم مشتری های ما را شرکت هایی تشکیل می دهند که به هر طریق ممکن محصولات خود را اسکن و مورد بررسی امنیتی قرار داده اند، اما به نتیجه دلخواه نرسیده اند. بنابراین به ما مراجعه می کنند تا اشکالات امنیتی آنها را پیدا و برطرف کنیم. اصولا این محصولات، توسط کارشناسان داخلی و خارجی مورد مطالعه قرار گرفته اند. اما این به این معنا نیست که ما دوباره از نو آنها را مورد بررسی و اسکن قرار نمی دهیم. زیرا ممکن است فردی از ابزارهای اتوماتیک استفاده کرده باشد و ممکن است باگ و ویروسی که تمایل به مخفی بودن دارد را پیدا نکرده باشد. تقریبا همه می توانند از ابزار خودکار برای یافتن آسیب کدهای امنیتی استفاده کنند. اما هدف و وظیفه ما این است تا با دقت کامل و تا حد امکان،  آسیب های امنیتی که مخفی هستند و به راحتی قابل شناسانی نیستند را پیدا و برطرف کنیم. برای این منظور نیز باید از فکر و پیشینه تجربی خود استفاده و بهترین روش را پیدا می کنیم. بیشترین ابزاری که استفاده می کنیم، انواع مانیتورها و ابزار دیباگینگ هستند که به ما کمک می کنند تا واکنش های محصول را هنگام اجرا در محیط خودش (همچون Process Monitor، Fiddler یا Wireshark)، ارتباطات درونی (WinObj) و اجرای کدهایش (WinDbg یا WinAPIOverride32) را مورد بازبینی و مطالعه قرار بدهیم. به طور کلی باید بگویم ما برای کارهای مختلف از ابزارهای متفاوت استفاده می کنیم.

 

۳- برای افرادی که علاقه مندند  وارد حوزه کاری شما یعنی آسیب شناسی امنیتی بشوند، چه پیشنهاداتی دارید؟ لازمه آغاز به کار چنین فعالیتی چیست؟

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

اگر نمی توانید همه جزییات را در یک مکان واحد به دست بیاورید، به مطالعه مداوم white papers که در واقع گزارش ها و راهنماهای معتبر و رسمی برای حل مشکلات هستند و پیگیری  کنفرانس هایی که در این زمینه هستند، بپردازید. به دنبال یافتن اطلاعات درباره اقدام متقابل و سپس اطلاعاتی در رابطه با راه های جانبی دیگر این اقدامات باشید.

۴- چه نوع تجهیزاتی را به افرادی که به طور جدی می خواهند وارد حوزه آسیب شناسی امنیتی بشوند، توصیه و پیشنهاد می کنید ؟

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

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

۵- مطمئنم این سوال برای دیگران هم مطرح است که روزهای زندگی یک محقق آسیب های امنیتی به چه شکلی می گذرند؟

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

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

۶- نظر شما در مورد کدهای بسته و کدهای باز یک محصول چیست؟ بر اساس تجربیات شما، آیا یکی از آنها می تواند امن تر از دیگری باشد؟

در شرایط ایده آل که گروهی از محققان امنیتی باید هر دو کدهای بسته و کدهای باز یک محصول را مورد بازبینی قرار بدهند، فرض قوی ما بر این است که تعداد کمی از آسیب ها و باگ ها در محصولات اپن سورس (کد باز) غیر قابل کشف شدن باقی می مانند. اما ممکن است در محصولاتی که کدهای بسته دارند، این رقم بالاتر باشد.

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

۷- نظر شما در مورد مبلغ پیشنهادی شرکت های کامپیوتری به محققان امنیتی چیست؟

به عنوان یک محقق امنیتی حرفه ای، ما همیشه دستمزد خود را از مشتری هایمان برای یافتن اشکالات و باگ های آنها دریافت کرده ایم. همچنین، برنامه های bug bounty (اهدا جوایز به محققان امنیتی) که بیشتر شرکت ها اجرا می کنند نیز روش تجاری دیگری برای این کار محسوب می شود.

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

اما در بیشتر مواقع، شرکت های بونتی این کار را می کنند و بسیار مایه خوشحالی است که شرکت ها و مشتری ها، خودشان را با این مساله وفق داده اند.

 

 

 

 

 

 

منبع: نگهبان

درباره نویسنده

پست های مرتبط

پاسخ دهید


خبرگزاری هرانا

نشانی ایمیل شما منتشر نخواهد شد.


Type The Red Captcha Characters Below.