بررسی ضعف‌های امنیتی در DNS

در پست قبلی سازوکار پروتکل DNS رو بررسی کردیم. در این پست میخواهیم درباره ضعف‌های امنیتی مرتبط با پروتکل DNS صحبت کنیم و در آخر پست هم قرار هستش یکی از روش‌های سوءاستفاده از DNS یعنی DNS Tunneling رو بررسی کنیم.

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

مهاجمین سایبری، روش‌های مختلفی برای سواستفاده از این پروتکل توسعه دادن. همچنین حملات اخیر نشون داده که حمله به زیرساخت DNS میتونه خیلی مخرب باشه. اهمیتی نداره DNS کجای شبکه در حال سرویس دهی هست. حفاظت از اون، برای اطمینان از در دسترس بودن سرویس‌ها اهمیت بالایی داره.

چالش های امنیتی DNS

هدف ایجاد DNS انجام وظیفه‌ای هست که همه از اون اطلاع داریم یعنی انجام موارد مربوط به نام‌گذاری در شبکه‌های‌کامپیوتری. تمرکز اصلی هنگام توسعه این پروتکل روی عملکرد و مقیاس پذیری (Performance & Scalability) اون بوده. در اوایل دوران اینترنت، مباحث امنیت و حریم خصوصی جز الویت‌ها نبوده چون این موارد به اندازه امروز اهمیت نداشتن. نتیجه این شد که ویژگی‌های ذاتی DNS، اون رو امروزه تبدیل به یک چالش امنیتی مداوم کرده. در زیر این ویژگی‌های ذاتی و چالش هاشون رو باهم مرور میکنیم:

1. DNS یک پروتکل Stateless هست. به این معنی که هیچ جلسه‌ای (session) بین client و server وجود نداره. یعنی تمرکز سرور روی ارائه سرویس هست و هیچ داده‌ای از client ذخیره نمیشه. این امر باعث شده مهاجم در حملات به این سرویس هویت خودش رو پنهان نگه داره.
2. این پروتکل بدون احرازهویت کارمیکنه یعنی راهی وجود نداره که حتی بررسی کنه که درخواست دهنده خوب یا بد هستش. مهاجم میتونه از این زیرساخت حفاظت نشده سوءاستفاده کنه و حملات پیچیده‌ای با درخواست‌ها و پاسخ‌های جعلی و پی‌درپی طراحی کنه.
3. در اغلب موارد دسترسی به این سرویس آزاده و Firewall ها Port 53 (درگاه پیش فرض DNS) رو بازرسی نمی‌کنن. این امکان دسترسی آزاد رو برای همه، از جمله مهاجم فراهم میکنه.
4. DNS ممکن هست اثر تقویت کننده بالایی رو ایجاد کنه، گاهی ممکنه یک درخواست، پاسخی تا 100 برابر بزرگتر از درخواست رو داشته باشه. برای مثال رکورد TXT تا 255 بایت میتونه فضا داشته باشه.
5. این پروتکل قادر به تایید اعتبار بسته‌ها نیست و نمیتونه تشخیص بده که آیا یک بسته معتبر هست یا نه. تا زمانی که بسته دریافتی با RFC مطابقت داشته باشه، DNS اون رو درنظر می‌گیره و در صف بررسی قرار میده. مهاجمین از این طراحی سوءاستفاده می‌کنن و حملاتی مثل Cache Poisoning و یا Tunneling رو پیاده میکنن. بیشتر راه‌حل‌های ارائه شده نمی‌تونن تضمین بدن که قادر به تفکیک قطعی بسته‌های معتبر و غیر معتبر هستند.

به علاوه تمام موارد ذکر شده، این موضوع هم باید در نظر گرفته بشه که زیرساخت به ندرت تغییر میکنه اما حملات روز به روز در حال پیشرفت هستن و تشخیص اون‌ها سخت تر میشه.

حملات رایج

حملات رایج روی DNS رو میشه به موارد زیر تقسیم کرد:

• Denial of service: حملات منع سرویس از رایج‌ترین حملات در زمینه DNS هست. مهاجین با روش‌های زیادی میتونن این حمله رو پیاده سازی کنن که در پست‌های بعدی اون‌هارو بررسی میکنیم. فراموش نکنیم که خارج شدن از دسترسی به اندازه دزدیده شدن اطلاعات برای یک کسب‌وکار مخرب هست.
• Cache Poisoning: حملات آلوده‌سازی Cache از سال‌ها قبل بوده و هنوز هم مشاهده میشه. در این حمله مهاجم تمام ترافیک سرویس شمارو به سمت دیگه‌ای هدایت میکنه. این حمله هم میتونه بابت به سرقت بردن اطلاعات کاربران شما بشه هم میتونه به نوعی DOS باشه.
• False Authoritative Server: این نوع حمله یکی از زیرمجموعه‌های DNS Poisoning هست و بشدت مخرب‌تر هست. در حملات Cache Poisoning سنتی، مهاجم فقط ترافیک یک دامنه رو منحرف میکرد. اما در این حمله مهاجم میتونه در واقع سرور پاسخ‌گو به یک Zone رو تصاحب کنه و در نتیجه ترافیک یک Zone رو منحرف کنه. یکی از دلایل ایجاد DNSSec این حمله بود. در پست‌های بعدی به این حملات می‌پردازیم.
• Modify Zone Data: یکی دیگه از حملات رایج که بارها دیده شده تغییر اطلاعات یک سرور DNS بوده. مهاجم به نحوی تونسته وارد شبکه بشه و به سرور دسترسی پیدا کنه و اطلاعات مربوط به Zone رو تغییر بده و در نتیجه مسیر ترافیک رو به میل خودش تغییر بده.

حملات Dyn (بات‌نت ‌Mirai)

در گذشته حملات سیلی DDoS توسط روش‌های تقویت و بازتاب (amplification & reflection) بسیار رایج بود. اما در عصر IoT، مهاجمین تونستن با سوءاستفاده از وسایل متصل به اینترنت که آسیب پذیر هستن، در سطح وسیعی Botnet برای حملات بخصوص در زمینه DNS جمع آوری کنن. این باعث شد حملات تقویت و بازتاب به شدت قوی‌تر بشن.

اگه جستجو کنیم حملات سایبری زیادی در طول تاریخ می‌بینیم که به کسب‌وکارها و حتی دولت‌ها خسارت زیادی رو وارد کرده. وقتی درباره این حملات مطالعه میکنیم درصد قابل توجهی از اون‌ها به سوءاستفاده از DNS مربوط بوده.

یک نمونه از این حملات، Mirai Botnet هست که در یک حمله گسترده در 21 اکتبر 2016 استفاده شد. باور متخصصین این هست که این بات‌نت برای استفاده در یک حمله هماهنگ از نوع DNS Water Torture استفاده شد که تونست با هدف قرار دادن سرورهای DNS شرکت Dyn، وب سایت‌های بزرگ رو برای چند ساعت از دسترسی خارج کنه.

بعد از Mirai، بات‌نت‌های IoT جدیدتر و پیشرفته‌تری دیده شده. با توجه به آمارها، امروزه بیشتر از ‌20 میلیارد Device متصل به اینترنت در دنیا وجود داره. این مساله به عنوان یک چالش جدی مطرح میشه و علت اون رشد سریع‌تر تعداد کامپیوترها نسبت به ظرفیت زیر ساخت هست.

رشد بی‌رویه و کنترل نشده deviceهای متصل به اینترنت میتونه بیشتر از پیش چالش افزایش بات‌نت‌ها رو به وجود بیاره و پروتکل هایی مثل DNS که از ضعف‌های امنیتی مختلفی در زیرساخت‌شون رنج میبرن، میتونن هدف خیلی خوبی برای این botnetها باشن.

این نکته رو هم باید توجه کرد که DNS فقط مربوط به نام‌دامنه یک وب‌سایت‌ نیست و تغریبا همه سرویس‌ها به نحوی وابسته به این سرویس هستن. به این معنی که هرگونه اختلال در این سرویس منجر به ضربه خیلی سنگینی به سازمان‌ها میشه.

بررسی DNS Tunneling

برای این پست تصمیم گرفتم یکی از آسیب‌پذیری‌های ‌DNS رو باهم بررسی کنیم. شاید به طور کلی نشه اون رو آسیب‌پذیری عنوان کرد، ولی تعریف کلیش اینه.

همون‌طور که میدونیم پورت پیش‌فرض DNS شماره 53 هست. این پورت تغریبا روی تمام Firewallها باز هست. علاوه بر این در قسمت قبلی خوندیم DNS از پروتکل UDP استفاده میکنه. علت هم این هست که DNS طراحی شده تا در کمترین زمان، با کمترین ترافیک و کمترین استفاده از منابع کار کن. UDP هیچگونه خطایابی یا قابلیت کنترل نداره و همچنین هیچ‌ حالتی وجود نداره که از صحت اطلاعات اون اطمینان حاصل بشه.

اگه برگردیم به سال‌های خیلی دور یعنی بازه 2000-2004 میتونیم botnetهایی رو ببینیم که به علت‌های مختلفی توسعه داده شدن. تو مبحث بات‌نت‌ها یک اصطلاحی هست به عنوان Command and control (C2). که اشاره داره به پروتکلی که مهاجم میتونه باهاش بات‌ها رو کنترل کنه. در اون بازه از زمان محصولات زیادی شکل گرفتن تا شبکه‌ها رو از ارتباط بیرونی کنترل کنن. خیلی از بات‌ها نمی تونستن از پروتکل‌هایی مثل Telnet یا IRC استفاده کنن چون به در بسته Firewallها میخوردن.

استفاده از DNS به عنوان C2

با وجود Firewallها و محصولات امنیتی دیگه، مهاجمین اومدن و از DNS به عنوان C2 استفاده کردن. چطوری؟

همون‌طوری که اشاره کردم، DNS در اغلب موارد – حتی امروزه – در فایروال‌ها باز هست و هیچ کنترلی روی اون صورت نمی‌گیره. بعلاوه بالاتر خوندیم که DNS هر بسته‌ای که مطابق RFC باشه رو قبول میکنه و هیچ راهی‌نداره برای این‌که تشخیص بده این یک درخواست معتبره یا نه.

مهاجمین اومدن و از این دو ویژگی DNS استفاده کردن و به نوعی پروتکل خودشون رو پیاده کردن.

همون‌طوری که می‌بینیم، مهاجم یک دامنه به نام badsite.com رو برای خودش ریجستر کرده. و به صورت قانونی میتونه خودش سرور Authoritative این دامنه رو کنترل کنه. در اون سمت bot موردنظر برای نشون دادن فعالیتش (به اصطلاح ضربان قلب)، هر چند ثانیه یک بار یک بسته درخواستی DNS میفرسته. و در اون یک زیردامنه از سایت badsite.com رو درخواست میکنه. همون‌طور که در تصویر می‌بینیم، bot اطلاعاتی موردنیاز مهاجم رو مثل نام‌کاربری، آدرس IP، و … رو کد میکنه و طبق قالب بالا به DNS سرور ارسال میکنه (علت کد کردن این هست که خیلی از کاراکترها تو درخواست قابل قبول نیستن و bot با تبدیل اطلاعات به base64 و یا هر سیستم coding دیگه‌ای اطمینان حاصل میکنه که یک درخواست معتبر درست کنه.)

در اون سمت‌ هم سرور Authoritative مهاجم درخواست‌هارو دریافت میکنه و با NXDOMAIN یا هر چیز دیگه‌ای به درخواست پاسخ میده. به علاوه مهاجم در تمام بسته‌ها مقدار TTL=1 رو قرار میده تا از cache شدن جلوگیری کنه. حالا سرور زیردامنه رو decode میکنه و پایگاه‌داده رو بروز میکنه تا جدیدترین وضعیت بات اضافه بشه. به این صورت یکی از وظایف مهم C2 که ارسال ضربان قلب هست انجام میشه بدون اینکه هیچ فایروال و یا ابزار دیگه‌ای مشکوک بشه.

در ادامه مهاجمین اومدن انواع روش‌هارو برای فرستادن دستورات اضافه کردن. مثلا هر وقت میخواستن به بات دستور بدن کاری رو انجام بده به‌جای NXDOMAIN یک رکورد A میفرستادن که 32 بیت بود (رکورد A مقدار IPv4 معادل دامنه درخواستی رو برمی‌گردونه) و هر مقداری میتونست یه معنی داشته باشه. مثلا اگه 1.1.1.1 فرستاده میشد، bot متوجه میشد که باید تو درخواست بعدی برای مثال وضعیت پورت‌های باز فلان ماشین رو ارسال کنه که IP اون ماشین توی پاسخ بعدی میومد. یا مثلا bot با یک درخواست TXT که 255 بیت جا داره می‌تونست فایل بفرسته (فایل رو به چند قسمت تقسیم کنه و هربار در چند بیت ابتدایی TXT اضافه کنه که حجم کلی فایل چقدره و این بسته چندمه، دقیقا مثل TCP).

همون‌طور که میبینید ایده داره شکل می‌گیره. ما می‌تونیم هر مقداری که بخواهیم رو توی بسته‌های ‌DNS جا بدیم و به هیچ پروتکل خاصی هم محدود نیستیم. به این صورت مهاجمین حتی امروزه اطلاعات رو از طریق DNS جابه‌جا می‌کنن و هیچ هشدار امنیتی به وجود نمیاد.

یک مقدار جلو تر تو بازه 2004-2008، مهاجین این ایده استفاده از DNS رو پرورش دادن و تونستن بسته‌های TCP رو با استفاده از پروتکل DNS ارسال کنن. تو این بازه کلی مقاله و ویدئو پیدا می‌کنیم با این عنوان که “چطوری از اینترنت کافه و هتل به صورت رایگان استفاده کنیم؟”

اون زمان در انگلیس و ایالات متحده کافه‌ها، هتل‌ها‌ و … به کاربرانشون اینترنت بی‌سیم می‌دادن. کاربرها میتونستن به WiFi وصل بشن ولی باید چند دلار پرداخت می‌کردن تا یک username و password دریافت میکردن که برای مثال تا 1 ساعت فعال بود.

نکته‌ درباره این سرویس‌ها این بود که وقتی کاربران توی کامندلاین از google.com پینگ می‌گرفتن هیچ خطایی که نشون بده اینترنت ندارن موجود نبود یعنی میتونستن درخواست به dns بدن و پینگ بگیرن.

تو این مقالات استفاده از اینترنت مجانی توضیح داده بود که چطوری یک دامنه ریجستر کنید و یک سرور بخرید و روی اون سرورتون یک سرور DNS اجرا کنید. همه این کارها با یه نرم‌افزار انجام میشد به نام dns2tcp. این نرم افزار دو قسمت داشت که یکی در server اجرا میشد و یکی در client. این نرم افزار یک پراکسی ایجاد میکرد که با استفاده از DNS بسته‌های TCP رو ارسال میکرد و نسخه server این نرم‌افزار اون بسته رو بررسی میکرد و پاسخ رو در غالب یک بسته DNS ارسال میکرد (یعنی بسته‌های tcp در غالب پرس‌وپاسخ‌های DNS رد و بدل میشد و نرم افزار dns2tcp یه واسط برای تبدیل بود). در آخر هم با استفاده از این پراکسی یک پراکسی SSH ایجاد میشد که حالا مرورگر می‌تونست با استفاده از اون پراکسی به اینترنت متصل بشه.

درباره سرعت DNS Tunneling، آمارها نشون میدن که این روش تونسته به سرعت 110 کیلوبایت بر ثانیه با تاخیر 150 میلی‌ثانیه (latency) برسه که عملکرد قابل قبولی هست.

تعداد نرم افزارهایی که DNS Tunneling رو انجام میدن زیاده به علاوه هرکدوم یک ویژگی دارن و tunneling رو به روش خودشون پیاده‌سازی کردن. در زیر می‌تونید تعدادی از تصاویر مانیتور بسته‌های DNS Tunneling رو ببینید، در آینده سعی میکنم این روش‌هارو مورد بررسی قرار بدم.

پیشگیری

همون‌طور که در تصاویر بالا دیدید تغریبا بی‌نهایت روش وجود داره برای DNS Tunneling. روش کلی و مشخصی در رابطه با جلوگیری از این کار نیست یا حداقل ساده نیست. کسب‌وکارهای بزرگ در زمینه کشف و تشخیص بدافزار هنوز هم درحال تحقیق و گسترش ابزارها برای جلوگیری از این نوع حملات هستن. روش‌های زیادی مطرح شده که بیشتر اون‌ها توسط هوش مصنوعی و شبکه‌های عصبی انجام میشه. و باز هم میشه گفت روش‌هایی روزبه‌روز توسط مهاجمین تولید میشه تا این سازوکارهارو دور بزنن. دقیقا مثل دنیا بدافزارها که روز‌به‌روز پیشرفت می‌کنن تا از زیر ذره‌بین آنتی‌ویروس‌ها بگذرن.

اما اگه شما مسئولیت ایمن‌سازی یک کسب‌وکار رو دارین باید از روش‌های موجود تو این زمینه استفاده کنید تا حداکثر میزان امنیت رو پیاده کنید.

اگه علاقه‌مند هستید بیشتر در زمینه DNS Tunneling مطالعه کنید، این مقاله از آقای Greg Farnham رو به شما پیشنهاد میدم. هرچند برای سال 2013 هست ولی هنوز هم مفیده.

https://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152