Academy and Foundation unixmens | Your skills, Your future

189 viewsyashar esmaildokht 🐧, 11:59

شاید این حمله به گفتار ساده باشد اما در حقیقت دارای پیچیدگی‌های بسیاری است:

نخست آن که دامنه‌ی مورد حمله نباید در Cache سرور Recursive موجود باشد وگرنه آن‌چه در بالا توضیح داده شد، رخ نمی‌دهد و Recursive Resolver بی‌درنگ با دریافت Query از جانب سیستم مهاجم، آدرس IP که در Cache خود ذخیره دارد را برای آن ارسال می‌کند.
دوم آن که مهاجم باید توانایی حدس زدن QID را داشته باشد.
مورد سوم آن که، سیستم مهاجم باید سرعت‌ عملی بیش‌تر از ارتباط میان Recursive Resolver و Root Server داشته باشد تا بتواند پاسخی با QID مورد انتظار در Recursive Resolver را سریع‌تر از Name Server اصلی ارسال کند.

این مشکل نخستین‌بار به‌وسیله‌ی Computer Science Research Group (CSRG) در دانشگاه Berkeley در سال 1989 کشف شد و از آن جایی دارای اهمیت بود که دو برنامه‌ی مشهور UNIX در آن زمان (rsh و rlogin) از DNS برای احراز هویت کاربرانی که قصد ریموت زدن به آن‌ها را داشتند، استفاده می‌کردند. این دو برنامه به آدرس IP نگاهی می‌انداختند و متناسب با آن، hostname را به‌دست می‌آوردند و بدون هیچ پرسش اضافه‌تری که آیا این کاربر معتبر است یا نه، آن را می‌پذیرفتند. پس یک مهاجم به‌راحتی می‌توانست با یک کاربر جعلی به این برنامه‌ها دسترسی پیدا کند. CSRG برای حل این مشکل، Query رکورد PTR علاوه‌بر رکورد A را پیشنهاد کرد. اما این روش نیز با DNS cache poisoning قابل دور زدن بود.

راه‌حل دیگر استفاده ازTransaction ID های تصادفی برای BIND بود. اما بیش‌تر راه‌حل‌های پیشنهادی برای امن‌سازی DNS چندان هم خوب به نظر نمی‌رسیدند و نیاز به یک روش بهتر، هم‌چنان احساس می‌شد. در سال 1997 نهاد IETF نخستین RFC (2065) را در رابطه با راه‌حلی بهتر برای امن‌سازی DNS ارایه کرد. این راه‌حل Domain Name System Security Extensions (DNSSEC) نام داشت اما جز برای محققانی که به‌خوبی بر مشکلات بسیار DNS آگاهی داشتند، مورد استقبال قرار نگرفت و بنا به هر دلیلی، جدی قلمداد نشد.

باگ Kaminsky

در سال 2008، محققی به نام Dan Kaminsky اعلام کرد که شیوه‌ی جدیدی از حملات Cache Poisoning را کشف کرده که بسیار بدتر از انواع قبلی است.

همان‌طور که در بخش قبل توضیح داده شد، در حمله‌ی Cache Poisoning مهاجم قادر بود تا با سمی کردن رکورد مربوط به Host مورد حمله در Cache مربوط به Recursive Server، کاری کند که درخواست کاربران برای دسترسی به آن Host، به‌سمت سرور جعلی او منتقل شوند. اما Kaminsky کشف کرد که مهاجم می‌تواند یک گام فراتر رود و به‌جای سمی کردن رکورد مربوط به یک Host، کاری کند که تمام درخواست‌هایی که مربوط به یک دامنه‌ی خاص هستند، سمی شوند. برای نمونه فرض کنید در تصویر بالا تمام درخواست‌هایی که مربوط به دامنه‌ی example.com هستند (example.com، example2.com و…) به‌سمت سرور جعلی مهاجم منتقل شوند.

در این حمله مهاجم به‌جای هدف قرار دادن رکورد A در پیام DNS، به سراغ Authority رکوردها می‌رود و این‌گونه ادعا می‌کند که name server مورد درخواست نیست اما از آن اطلاع دارد و می‌تواند پاسخ درخواست‌های مربوط به این name server را بدهد. به بیان بهتر خود را به‌عنوان یک Authoritative name server جا می‌زند. به ‌این ‌ترتیب هر درخواستی که به دست Recursive Resolver برسد که مربوط به دامنه‌ی هدف باشد، به‌سمت مهاجم ارسال می‌شود.

پیدا شدن این باگ جامعه‌ی اینترنت را مجاب به یافتن راهی برای حل این مشکل کرد. راه‌حل پیشنهادی، افزایش سایز QID از 16 بیت به 32 بیت، هم‌چنین استفاده از شماره پورت‌های تصادفی برای هر پیام DNS به‌جای یک پورت UDP یک‌سان برای همه‌ی پیام‌ها بود. این راه‌حل‌ها هر چند سبب سخت‌تر شدن کار مهاجمان برای انجام این حمله می‌شدند اما آن را به یک امر ناممکن مبدل نمی‌‌ساختند. پس باز هم نیاز به روشی برای امن‌تر کردن DNS هم‌چنان احساس می‌شد.

تمام این موارد سبب شدند تا ضرورت توسعه و استفاده از DNSSEC که پیش‌تر به‌وسیله‌ی IETF معرفی شده بود، بیش از پیش احساس شود.

289 viewsyashar esmaildokht 🐧, 11:59