استفاده‌ی بدافزارها از پروتکل DNS

ناگفته می‌دانید که پروتکل 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 دیگری ارجاع دهد و پس از یک توالی جواب را دریافت کند و به کاربر باز پس فرستد.

تصاویر زیر به روشن شدن آنچه تا کنون ذکر شد، کمک می‌کنند:

گفتیم برای 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 مطالب مفصلی خواهیم داشت.

در انتها صمیمانه شما رو هم به نظرات مثبت و منفی، که مسلما همه‌ش به بهبود کیفیت این پست و پست‌های آتی کمک می‌کنند، دعوت می‌کنم. هر ایراد فنی/نگارشی رو از طریق نظرات بهم اطلاع بدید اصلاح می‌کنم. ممنون که [تا اینجا] خوندید.