سازوکار حملات DNS Rebinding

در عصر جدید اینترنت فقط کامپیوترهای شخصی نیستن که در یک شبکه محلی وجود دارن. با وجود روترهای بی‌سیم، سرویس‌های مختلفی مثل NAS (مخازن متصل به شبکه)، کامپیتورهایی مثل رزبری‌پای، سیستم‌های خانه‌هوشمند، تلفن ‌های اینترنتی، پرینترها، تلویزین­‌های متصل به شبکه، سنسورها، و کلی Device دیگه، شبکه‌های محلی پر شده از سیستم‌های مختلف. در مفهومی مثل IoT که در اون دیوایس‌ها ضعیف‌تر هستن، بیشتر سازوکارهای امنیتی قابل پیاده‌سازی در خود دیوایس نیستن و اغلب به عوامل خارجی تکیه میشه.

شبکه محلی یک شبکه امن پشت NAT شناخته میشه. جایی­که شخصی خارج از شبکه نمی­تونه به اون دسترسی داشته باشه و خب در لبه (Edge) این شبکه هم دیوارآتش (Firewall) وظیفه کنترل و حراست از شبکه داخلی رو داره. این‌جوری میشه که خیلی‌ها به این شبکه اعتماد میکنن و سیاست‌های ایمنی رو برای اون اغلب نادیده میگیرن.

چرا CSRF چندان کارآمد نیست؟

در پست قبلی درباره حملات CSRF خوندیم، این­که چطوری یک وب‌سایت آلوده می‌تونه کاربر رو مجبور کنه که درخواست‌های ناخواسته ارسال کنه. در این سناریو فرض کنیم که قراره از کاربر بخواهیم که به روتر (Router) خودش یه درخواست از نوع POST ارسال کنه و از روتر بخواد Remote Telnet رو فعال کنه که در نتیجه فرد متخاصم (Attacker) بتونه از راه دور به روتر کابر متصل شه و به اون دسترسی داشته باشه. اما … تمام این سناریو زمانی اتفاق می­افته که کاربر در واقع تو روتر لاگین کرده باشه و Cookie در مرورگر ذخیره شده باشه و شما بتونید از اون برای یک درخواست معتبر استفاده کنید. زمان یک نشست در روترها اغلب کوتاه هست و در زمان کمی منقضی (Expired) میشه. و این‌که کاربر هنگام دریافت محتوای آلوده از شما دارای یک Cookie معتبر در مرورگر خودش باشه خیلی پایینه. باز فرض بر این‌که مرورگر واجد این شرایط بود، این نکته هم باید در نظر گرفته بشه که بیشتر روترها امروزه از سازوکارهای جلوگیری از حملات CSRF استفاده می‌کنن و این سناریو حمله بی‌نتیجه میشه.

هرچند در دنیای IoT هنوز حملات CSRF از دسته حملاتی هستند که بیشتر دیده میشن. با توجه به این‌که اغلب دیوایس‌هایی که در دنیای IoT وب‌سرویس ارئه میدن دارای چهارچوب (Framework) ایمنی نیستند و توسط توسعه‌دهنگان بدون دقت برنامه‌ریزی شدن، وجود مشکلات CSRF بسیار زیاد دیده میشه.

فرض کنیم یک Board کوچک مثل ESP32 داریم که قبلا توسط یک شرکت برنامه‌نویسی شده و قراره باز و بسته کردن در خونه رو با کمک موبایل‌هوشمند انجام بده. و روند این کار به این صورت هست:

1. کاربر در برنامه مربوط به قفل در کلید بازکردن رو میزنه
2. برنامه یک درخواست POST به ادرس http://192.168.1.165/door می‌فرسته که در پیام درخواست کلمه unlock هست.
3. برد ESP32 این درخواست رو دریافت می­کنه و با توجه به متن پیام در رو باز میکنه.

همین سناریو به سادگی می‌تونه توسط یک وب‌سایت آلوده انجام بشه و به صورت ناخواسته در خونه باز بشه. برای همین امروزه اغلب دیوایس­های IoT از سازوکارهای جلوگیری از حملات CSRF استفاده می‌کنند و اغلب این سناریو قابل اجرا نیست.

سناریو حمله

تا الان توضیح دادیم که چرا حملات CSRF نمی‌تونه خیلی کاربردی باشه. از الان می‌خواهیم شروع کنیم برای مطالعه درباره حملات DNS Rebinding. قبل از هرچیزی باید بدونیم که Same-Origin Policy چی هست و البته آگاهی کافی از اینکه DNS چجوری کار می‌کنه. و در این پست قرار نیست Demo اجرا بشه و صرفا مربوط به سازوکار این حمله هست.

اگه یکبار دیگه مرور کنیم می‌بینیم علت ناکارآمدی حملات CSRF این بود که ما نمی‌تونستیم صفحات رو بخونیم و در نتیجه CSRF Token رو داشته باشیم. و علت این SOP بود که اجازا نمی­داد یک مستند یا Script از یک Origin بتونه از Origin دیگه‌ای چیزی GET کنه.

فرض کنیم وب‌سایت مخرب attacker.com با آدرس آی‌پی 1.1.1.1 وجود داره. و یک وب‌سایت دیگه مثل bank.com به آدرس آی پی 2.2.2.2 هم وجود داره. طبق SOP وب سایت attacker.com نمی تونه هیچ درخواستی خواندنی به bank.com بده چون این دوتا در دو Origin متفاوت هستند. حالا چی میشه اگه به نحوی آدرس آی پی attacker.com از 1.1.1.1 به 2.2.2.2 تغییر کنه؟ براساس سازوکار مرورگرها هیچ چیز تغییر نمی کنه فقط شما از این به بعد به­جای ارتباط با attacker.com با bank.com ارتباط می­گیرید. همون طور که می­بینیم، DNS میتونه سازوکار SOP رو دور بزنه.

حملات DNS Rebinding مدت طولانی هست که وجود داشته و داره. که در طول این سال های زیاد خیلی کم به اون اشاره شده. بزرگترین مشکلات پیش اومده از بابت این حمله، آسیب پذیری­های چند وب سایت رمز ارز بود که به متخاصم اجازه میداد با DNS Rebinding، اکانت کاربر رو کاملا در دست بگیره. اما در ژوئن 2018 توجه ها به این حمله خیلی بیشتر شده. وقتی دست کم بیشتر از 500 میلیون دیوایس آسیب پذیر در تشکیلات مهم اقتصادی و صنعتی پیدا شد.

DNS Rebinding چطوری کار می­کنه؟

• صاحب دامنه attacker.com می تونه خودش DNS Server خودش رو میزبانی کنه. با توجه به این موضوع فرد متخاصم یک سرور DNS آلوده اجرا می­کنه.
• فرد با استفاده از روش‌­های مختلف مثل تبلیغات، ایمیل، و یا هر چیز دیگه ای آدرس attacker.com به کاربر میده.
• به محض این­که کاربر به صفحه attacker.com درخواست بده، در ابتدا مرورگر یک درخواست DNS اجرا می کنه تا بتونه آدرس IP مرتبط با دامنه attacker.com رو دریافت کنه و بتونه درخواست رو کامل کنه. سرور DNS به مرورگر آدرس آی پی 1.1.1.1 رو برمی‌­گرونه. همچنین مقدار TTL رو یک می میذاره تا از Cache شدن طولانی مدت جلوگیری بشه (مقدار TTL در پاسخ سرور DNS مشخص کننده زمان معتبر بودن یک پاسخ DNS هست و این پاسخ تو Cache سیست‌عامل ذخیره میشه تا هربار لازم به درخواست نباشه – تا اون پاسخ منقضی بشه)
• مرورگر صفحه attacker.com رو اجرا می‌میکنه. این صفحه دارای یک کد ساده جاواسکریپ هست که از نظر مرورگر آلوده نیست.

• همین‌طور که می‌بینیم بعد از یک درخواست GET به URL مشخص شده فرستاده میشه و از نظر SOP مجاز هست. نکته‌ای که باید دقت کنیم این هست که بعد از یک ثانیه مقدار Cache شده دیگه وجود نداره پس مرورگر مجبوره یک‌بار دیگه درخواست DNS ارسال کنه. این­بار سرور DNS آلوده مقدار 192.168.1.156  رو به عنوان آدرس آی­پی attacker.com برمی­گردونه. و سپس درخواست فرستاده میشه که درواقع به این آدرس فرستاده شده:

https://192.168.1.156/temprature

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

هرچند مقدار دما شاید چندان مهم نباشه ولی این سناریو نشون داد که چطوری DNS Rebinding می‌تونه SOP رو دور بزنه.

نکته مهمی که وجود داره این هستش که بعضی از مرورگرها به TTL خیلی توجه نمی‌کنن و به ارتباط با همون آدرس IP قبلی ادامه میدن. در این مورد بیشتر ابزارهای DNS Rebind درخواست دوم کاربر رو در فایروال DROP می­کنن تا مرورگر مجبور اجرای درخواست DNS بشه.

پیاده سازی حمله با چند A Record

یکی از روش­های دیگه‌ای که میشه توسط اون این حمله رو انجام داد Multiple A Record  هست. این اصطلاح بیشتر به عنوان DNS Load Balancing شناخته میشه. برای مثال وقتی از DNS آدرس آی‌پی google.com رو درخواست می­کنیم با چند پاسخ روبرو می­شویم. که این پاسخ‌ها از بالا به پایین الویت دارن.

همون­ طور که شاید تا الان حدس زده باشید، سرور DNS میتونه چند A Record رو ارسال کنه. و در بالاترین الویت آدرس IP وب‌سایت خودش رو بذاره و در الویت بعدی آدرس IP هدف. به این ترتیب بعد از اولین درخواست کاربر به وب ­سرویس فایروال کاربر رو مسدود می‌کنه و کاربر برای درخواست بعدی مجبور به استفاده از آدرس دوم میشه. و DNS Rebind اتفاق می‌افته.

نکته‌ای که در این روش حائز اهمیت هست: مرورگر در پاسخ‌های بازگشتی از سرور DNS اگه A Record از نوع RFC1918 IP ببینه. بدون در نظر گرفتن الویت از اون آدرس استفاده می­کنه (RFC1918 IP، اصطلاحی هست که به IPهای Private/Local گفته میشه). پس این نوع از پیاده سازی حمله فقط می‌تونه برای IP آدرس­های عمومی استفاده بشه.

الان متوجه شدیم که چقدر تاثیر این آسیب‌پذیری میتونه زیاد باشه، و سناریوهای مختلفی رو میشه با اون پیاده کرد. از جمع­ آوری BotNet ها گرفته تا دسترسی به روترها و دور زدن Firewall ها.

راه­های جلوگیری از DNS Rebinding

راه‌های زیادی برای جلوگیری از این حمله وجود داره که کاوش اون‌ها بسیار وقت گیره. از بازنویسی سیاست‌های SOP گرفته تا استفاده از پروتکل­های مشخص. اما یکی از مرسوم­ترین راه حل­ها بررسی هدر Host درخواست هست.

اساسا وقتی DNS Rebind اتفاق می­ افته تغییری در درخواست­های مرورگر داده نمیشه. به این معنی که برای مثال هدر Host به همون مقدار attacker.com می‌مونه. پس bank.com که این درخواست رو دریافت میکنه با چک کردن هدر Host باید اطمینان حاصل کنه که درخواست مربوط به نام‌دامنه Bank.com هست و نه دامنه دیگری.

یکی دیگه از روش ­های کاربری استفاده از HTTPS هست. البته استفاده از HTTPS چیزی رو عوض نمی‌کنه در صورتی که شما هنوز به HTTP اجازه برقراری ارتباط بدین. سازوکار این روش هم به‌این صورت هست که bank.com از یک اعتبارنامه SSL استفاده می‌کنه که برای attacker.com معتبر نیست و یک هشدار امنیتی این درخواست رو مسدود می­کنه.