در این بخش از دوره آموزشی SEC504 شما با حمله DNS cache poisoning و راه های مقابله با آن آشنا خواهید شد.
DNS cache poisoning
یکی از روش‌های ترجمه نام، DNS Recursive Query می‌باشد. هنگامی که یک مشتری می‌خواهد به یک سرور وصل شود، باید نام آن را اصطلاحا Resolve نماید.
Resolver کلاینت بررسی می‌کند تا مشخص کند که آیا قبلا آدرس IP آن ثبت شده است یا خیر. در غیر این صورت، کلاینت آن را از سرور نام محلی (Local name server) درخواست می‌کند. سرور نام محلی، درخواست را دریافت می‌کند. اگر اطلاعات مربوط به جست و جو در Cache سرور وجود داشت، پاسخ آن را ارسال می‌کند.
اگر این اطلاعات وجود نداشته باشد، یک جستجوی بازگشی(Recursive) انجام خواهد شد. هنگامی که یک جستجوی بازگشتی انجام می‌شود، سرور نام داخلی با سرورهای Root مشورت می‌کند تا رکورد مربوط به آدرس مورد نظر را به دست آورد. اگر سرور Root این اطلاعات را نداشته باشد، آدرس سرورهای میزبان دامنه (Top Level Domain) مانند org، com و یا موارد دیگر را ارسال می‌کند. در مرحله بعدی سرور نام محلی یک درخواست را به سرور میزبان org ارسال می‌کند. اگر سرور میزبان org اطلاعات آن را داشته باشد، به آن پاسخ می‌دهد. در غیر این صورت، به سرور Sans.org اشاره می‌کند،
در این سناریو در هر گام ما به سرور مورد نظر نزدیک و نزدیک تر می‌شویم.
در انتها هنگامی که به یک سرور نام سطح پایین (Low Level Domain) می‌رسیم، اطلاعات به سرور نام محلی ما ارسال می‌شود تا این سرور اطلاعات را به کلاینتی که درخواست را ارسال نموده است، تحویل نماید.
نکاتی در خصوص DNS
برای جلوگیری از ترافیک زیادی که می‌تواند بر روی سرورهای Root و سرور نام ایجاد شود، سرور DNS محلی، پاسخ‌هایی که ارسال شده است را در Cache ذخیره می‌نماید. اگر در هنگام درخواست از سمت کلاینت، پاسخ در Cache موجود باشد، نیازی به تکمیل فرآیند DNS Recursive Query نیست و پاسخ به کلاینت برگردانده می‌شود.
علاوه بر این، هر DNS Query یک شناسه به عنوان Query ID دارد که در برخی موارد به عنوان Transaction ID شناخته می‌شود.
این Query ID ممکن است بر اساس Query ID پیشین قابل پیش بینی باشد.
شاید شما با خود فکر کنید که یک حمله مبتنی بر DNS را می‌توانید با استفاده از ثبت نام یک دامنه با نامی شبیه دامنه اصلی، انجام دهید. به عنوان مثال برای سایت مایکروسافت باید دامین‌هایی مانند mlcrosoft.com یا micr0soft.com را ثبت نمایید.
با این کار می‌توان کاربر را فریب داده و او را به وب سایت خود هدایت نماییم. اما این واقعا یک حمله علیه DNS نیست و چنین حملاتی در دسته مهندسی اجتماعی قرار می‌گیرند
سناریوی DNS Cache Poisoning
در این سناریو، Alice قصد دارد تا برخی از فعالیت‌های بانکی خود را انجام دهد. Eve یک نفوذگر می‌باشد که قصد دارد با هدایت کردن Alice به سایت مورد نظر خود، اطلاعات بانکی وی را به سرقت ببرد.
برای انجام این سناریو، نفوذگر باید Query ID درست را حدس بزند. در واقع این یک مسابقه بین نفوذگر و سرور DNS می‌باشد. پس اگر نفوذگر بخواهد، سناریو را به درستی انجام دهد، باید در این مسابقه پیروز گردد. در غیر این صورت، پاسخ صحیح از سرور DNS قانونی ارائه خواهد شد.(DNS cache)
مدت زمانی که پاسخ ذخیره شده در Cache سرور DNS باقی می‌ماند بستگی به تنظیمات Time to Live دارد که توسط مدیر سرور DNS پیکربندی شده است. این زمان احتمال دارد چند دقیقه، چند ساعت و یا حتی چند روز باشد.
مهاجم یا باید منتظر بماند تا رکورد مورد نظر منقضی شود و تلاش کند تا سرور را با یک رکورد برای یک نام دامنه مختلف اصطلاحا Poison نماید، یا به سرور DNS دیگری به عنوان هدف مراجعه نماید.
یک محقق امنیتی به نام Dan Kaminsky یک روش مناسب برای از بین بردن محدودیت‌ها در DNS Cache Poisoning طراحی کرده است که تکنیک وی در برخی از ماژول‌های متاسپلویت اجرا شده است. در ادامه به جزئیات آن می‌پردازیم.
مرحله اول از حمله با ارسال یک Query از سیستم نفوذگر به DNS سرور dns.good.com آغاز می‌شود. هدف نفوذگر در واقع بارگذاری یک رکورد جعلی از www.bank.com داخل DNS Cache مربوط به سرور dns.good.com می‌باشد.
نفوذگر در این زمان اقدام به ارسال یک درخواست برای مشاهده سایت www.bank.com نمی کند اما یک نام جعلی و اشتباه را که در همان دامین bank.com می‌باشد، درخواست می‌کند که ما در اینجا به آن RANDOM1.bank.com می‌گوییم.
در مرحله دوم، DNS سرور قانونی، یک درخواست را به dns.bank.com ارسال می‌کند تا نام RANDOM1.bank.com را جست و جو نماید.
در مرحله سوم، نفوذگر اقدام به ساختن و ارسال پاسخ به سرور dns.good.com می‌نماید. در این زمان نفوذگر، بیش از صدها پاسخ را به سمت سرور ارسال می‌کند و با این کار تلاش می‌کند تا به درخواست مرحله دوم پاسخ دهد. پاسخ‌ها در این مرحله با یک آدرس منبع جعلی بوده و به نظر می‌رسد که این پاسخ از طرف dns.bank.com می‌باشد. نفوذگر Query ID حدس زده خود را در هر پاسخ قرار می‌دهد.
اما این پاسخ‌ها در مرحله سوم، متفاوت از پاسخ‌هایی است که ما در نسخه‌های پیشین DNS Cache Poisoning دیده‌ایم. به جای ارسال پاسخ با یک آدرس IP برای RANDOM1.bank.com، پاسخ نفوذگر در واقع به سرور dns.good.com می‌گوید که سرور dns.bank.com آدرس مربوط به RANDOM1.bank.com را نمی شناسد.
در عوض این پاسخ شامل یک DNS redirect می‌باشد که می‌گوید dns.bank.com آدرس IP مربوط به آدرس RANDOM1.bank.com را نمی داند اما DNS سرور www.bank.com آن را می‌داند و آن در آدرس 10.10.10.2 قرار گرفته است.
در صورتی که Query ID این پاسخ‌ها با تغییر مسیرها (redirects) در مرحله سه نادرست باشد، سرور dns.good.com آن‌ها را به سادگی حذف می‌کند.
در مرحله چهارم همانطور که در تصویر بالا قابل مشاهده می‌باشد، با توجه به اینکه شماره‌های مربوط به Query IDهای استفاده شده توسط نفوذگر نادرست می‌باشد، پاسخ‌ها رد (reject) می‌شوند.
بخش دوم حمله
در نهایت سرور dns.good.com درخواست را رها می‌کند، زیرا یا پاسخ از dns.bank.com می‌گوید که آدرس RANDOM1.bank.com وجود ندارد یا هیچ گاه پاسخ درستی برای آدرس RANDOM1.bank.com دریافت نمی‌شود.
در مرحله پنجم، نفوذگر می‌تواند اقدام به ارسال یک Query برای یک نام تصادفی ایجاده شده دیگر نماید که مربوط به دامین bank.com می‌باشد. این نام برابر با RANDOM2.bank.com است.
در مرحله ششم، سرور dns.good.com درخواست نفوذگر را همانند قبل به سرور dns.bank.com فوروارد می‌کند همچنین نفوذگر در مرحله 7 ارسال پاسخ‌های جعلی خود را آغاز می‌کند.
نفوذگر با تکرار مراحل پنج، شش و هفت، در نهایت یک شماره Query ID معتبر را به دست می‌آورد.
توجه داشته باشید که در کل، تنها 65536 شماره Query ID مختلف وجود دارد و نفوذگر می‌تواند در هر مرحله 5 (که تکرار مرحله یک می‌باشد) تعداد حدود 100 پاسخ را ارسال نماید.
در مرحله هشتم، یک شماره Query ID معتبر را شناسایی می‌کند که حاوی یک پیام redirect می‌باشد و می‌گوید سرور www.bank.com پاسخ را می‌داند و آدرس IP آن 10.10.10.2 است. آدرس مذکور توسط مهاجم انتخاب می‌شود. سرور اصلی و قانونی این رکورد را Cache می‌کند!
در مرحله نهم، سرور dns.good.com یک درخواست را برای سروری که تصور می‌کند www.bank.com می‌باشد، ارسال می‌کند تا آدرس RANDOM2.bank.com را اصطلاحا resolve نماید.
بر اساس Cache نادرستی که در سرور DNS ایجاد شده است، وی جهت resolve نمودن آدرس RANDOM2.bank.com، درخواست را به 10.10.10.2 ارسال می‌کند که احتمالا یکی از ماشین‌هایی است که نفوذگر در اختیار گرفته است.
درخواست ارسال شده توسط dns.good.com نمایانگر موفقیت آمیز بودن حمله Cache Poisoning است. در ادامه نیاز نیست تا نفوذگر پاسخ مرحله نهم را ارسال کند زیرا پیش از این در مرحله هفتم و هشتم، مسمومیت یا Poisoning اتفاق افتاده است.
راه‌های مقابله با DNS Cache Poisoning
بهترین گزینه برای مقابله با حملات DNS، اطمینان از نصب آخرین نسخه وصله‌ها می‌باشد. همچنین بروز رسانی سرورهای DNS و ایجاد پورت مبدا تصادفی برای ارسال درخواست‌ها یکی از راه‌های مقابله با روش Dan Kaminsky می‌باشد(به عنوان مثال در مراحل 2 و 6). زیرا نفوذگر پورت مربوط به ارسال پاسخ را نمی داند و او علاوه بر حدس زدن Query ID به شماره پورت نیز، نیاز خواهد داشت که این موضوع کار وی را مشکل می‌کند. همچنین اگر بروزرسانی‌های لازم برای سرورهای DNS انجام شده باشد، سرور DNS پاسخ‌های مربوط به دامنه‌های دیگر را تایید نمی نماید.
کنسرسیوم نرم افزار اینترنتی Internet Software Consortium که آدرس سایت آن www.isc.org می‌باشد، پیشنهاد می‌کند که بنا به دلایل امنیتی، نسخه BIND را به آخرین نسخه ارتقا دهید چراکه امکان کشف آسیب‌پذیری‌های مختلف برای این سرویس وجود خواهد داشت.
یکی از راه‌های دیگر عدم اجازه ورود به درخواست‌های خارجی از اینترنت به سرور DNS خارجی شما برای انجام Recursive Lookup می‌باشد.
روش دیگر استفاده از Split-Split DNS می‌باشد که موجب حذف مراحل یک و سه می‌گردد.
در این سناریو سرور نام محلی (Local Name Server) تنها قادر به Resolve نام‌ها برای سیستم‌های محلی خواهند بود و به درخواست‌های دستگاه‌های خارجی پاسخ نمی دهند. ماشین‌های خارجی باید Resolve نام‌های سیستم‌های محلی را با استفاده از Name Server کاملا متفاوتی انجام دهند(Externa External DNS).
البته این یکی از بهترین راهکارهای برای مقابله با حملات DNS Cache Poisoning می‌باشد ولی به دلیل پیچیده بودن و هزینه بالای راه اندازی معمولا به صورت گسترده مورد استفاده قرار نمی گیرد.
توجه داشته باشید که این روش متفاوت از روش Split DNS سنتی می‌باشد.
یکی از راه کارهای دیگر استفاده از SSL می‌باشد که به شکست این حمله کمک می‌کند زیرا کاربران ممکن است تشخیص دهند که ارتباط برقرار شده با بانک، ایمن نیست. البته کاربران باید آموزش‌های لازم را در این زمینه دیده باشند که نباید به یک بانک با ارتباط نا امن متصل شوند.
البته تنها وجود نشان قفل در گوشه نوار آدرس مرورگر نشان دهنده ایمن بودن وب سایت نیست و کاربران باید نسبت به نحوه بررسی اعتبار سایت‌هایی که در حال بازدید از آن‌ها هستند نیز آموزش‌های لازم را دیده باشند.
برای این منظور باید بر روی قفلی که معمولا سبز رنگ می‌باشد کلیک نموده و مشخصات گواهینامه آن را مشاهده نمایند تا از اعتبار آن اطمینان حاصل نمایند.
راه کار دیگری که می‌توانید به منظور حفاظت از سرور DNS خود انجام دهید، محافظت از Zone فایل‌ها می‌باشد. استفاده از ابزارهایی مانند Tripwire یا ابزارهای مشابه برای کنترل یکپارچگی فایل‌ها به صورت مرتب، می‌تواند تغییر در رکوردها و Zoneها را تشخیص داده و به شما هشدار دهد.
در نهایت نیز استفاده از DNSSEC برای رمزنگاری رکوردها پیشنهاد می‌گردد. این سرویس به شما اجازه می‌دهد تا رکوردهای DNS خود را با استفاده از رمزنگاری کلید عمومی نشانه گذاری نمایید که به شما اطمینان می‌بخشد که سیستم‌های شما تشخیص خواهند داد که آیا رکورد DNS باید مورد اعتماد واقع شود و یا اینکه مسموم شده و شما را به یک مکان نادرست هدایت می‌کند.
لازم به ذکر است قسمت‌هایی از موارد بالا از وب سایت گویا آی تی برداشت شده است.
