Bad Sector
14th March 2012, 07:44 PM
پاسخ به 7 پرسشی که همیشه می خواستید از یک محقق آسیب های امنیتی بپرسید - قسمت اول
http://www.uc-njavan.ir/images/675yp1p4qolqyg0vxip.png
مصاحبه میرکو زورز –سردبیر مجله 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) را مورد بازبینی و مطالعه قرار بدهیم.
به طور کلی باید بگویم ما برای کارهای مختلف از ابزارهای متفاوت استفاده می کنیم.
منبع (http://negahbaan.com/article/2012/jan/638)
http://www.uc-njavan.ir/images/675yp1p4qolqyg0vxip.png
مصاحبه میرکو زورز –سردبیر مجله 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) را مورد بازبینی و مطالعه قرار بدهیم.
به طور کلی باید بگویم ما برای کارهای مختلف از ابزارهای متفاوت استفاده می کنیم.
منبع (http://negahbaan.com/article/2012/jan/638)