گروهی از محققان دانشگاه تل آویو و مرکز بین رشته ای در هرتزلیا (اسرائیل) روش حمله جدید () به شما امکان می دهد از هر حل کننده DNS به عنوان تقویت کننده ترافیک استفاده کنید و نرخ تقویت تا 1621 برابر بر حسب تعداد بسته ها را فراهم می کند (برای هر درخواست ارسال شده به حل کننده، می توانید به 1621 درخواست ارسال شده به سرور قربانی دست یابید) و از نظر تردد تا 163 برابر.
این مشکل به ویژگی های پروتکل مربوط می شود و همه سرورهای DNS را که از پردازش پرس و جو بازگشتی پشتیبانی می کنند، تحت تاثیر قرار می دهد. (CVE-2020-8616) ، (CVE-2020-12667) ، (CVE-2020-10995) ، и (CVE-2020-12662)، و همچنین خدمات عمومی DNS Google، Cloudflare، Amazon، Quad9، ICANN و سایر شرکت ها. این اصلاح با توسعه دهندگان سرور DNS هماهنگ شده بود، که به طور همزمان به روز رسانی هایی را برای رفع آسیب پذیری در محصولات خود منتشر کردند. حفاظت از حمله در نسخه ها اجرا شده است
, , , .
این حمله بر اساس مهاجم با استفاده از درخواست هایی است که به تعداد زیادی از رکوردهای NS ساختگی که قبلاً دیده نشده بودند، که تعیین نام به آنها واگذار شده است، اما بدون مشخص کردن سوابق چسب با اطلاعات مربوط به آدرس های IP سرورهای NS در پاسخ، اشاره می کند. به عنوان مثال، یک مهاجم برای حل نام sd1.attacker.com با کنترل سرور DNS مسئول دامنه attacker.com، یک درخواست ارسال می کند. در پاسخ به درخواست حل‌کننده به سرور DNS مهاجم، پاسخی صادر می‌شود که تعیین آدرس sd1.attacker.com را با نشان دادن رکوردهای NS در پاسخ بدون ذکر جزئیات سرورهای IP NS به سرور DNS قربانی واگذار می‌کند. از آنجایی که سرور NS مذکور قبلاً با آن مواجه نشده و آدرس IP آن مشخص نشده است، حل کننده سعی می کند آدرس IP سرور NS را با ارسال یک کوئری به سرور DNS قربانی که دامنه مورد نظر را ارائه می دهد (victim.com) تعیین کند.
مشکل این است که مهاجم می‌تواند با فهرست عظیمی از سرورهای NS تکراری با نام‌های زیردامنه قربانی ساختگی (fake-1.victim.com، fake-2.victim.com،... fake-1000) پاسخ دهد. qurban.com). حل‌کننده سعی می‌کند درخواستی را به سرور DNS قربانی ارسال کند، اما پاسخی مبنی بر پیدا نشدن دامنه دریافت می‌کند، پس از آن سعی می‌کند سرور NS بعدی را در لیست تعیین کند، و به همین ترتیب تا زمانی که تمام موارد را امتحان کند. رکوردهای NS لیست شده توسط مهاجم. بر این اساس، برای درخواست یک مهاجم، حل‌کننده تعداد زیادی درخواست برای تعیین میزبان‌های NS ارسال می‌کند. از آنجایی که نام‌های سرور NS به‌طور تصادفی تولید می‌شوند و به زیر دامنه‌های موجود اشاره می‌کنند، از حافظه پنهان بازیابی نمی‌شوند و هر درخواست مهاجم منجر به انبوهی از درخواست‌ها به سرور DNS در خدمت دامنه قربانی می‌شود.
محققان میزان آسیب‌پذیری حل‌کننده‌های DNS عمومی را نسبت به این مشکل بررسی کردند و تشخیص دادند که هنگام ارسال پرس‌و‌جوها به حل‌کننده CloudFlare (1.1.1.1)، می‌توان تعداد بسته‌ها (PAF، Packet Amplification Factor) را تا 48 برابر افزایش داد. (8.8.8.8) - 30 بار، FreeDNS (37.235.1.174) - 50 بار، OpenDNS (208.67.222.222) - 32 بار. شاخص های قابل توجه بیشتری برای مشاهده می شود
Level3 (209.244.0.3) - 273 بار، Quad9 (9.9.9.9) - 415 بار
SafeDNS (195.46.39.39) - 274 بار، Verisign (64.6.64.6) - 202 بار،
Ultra (156.154.71.1) - 405 بار، Comodo Secure (8.26.56.26) - 435 بار، DNS.Watch (84.200.69.80) - 486 بار، و Norton ConnectSafe (199.85.126.10 بار) برای سرورهای مبتنی بر BIND 569، به دلیل موازی سازی درخواست ها، سطح بهره می تواند تا 9.12.3 برسد. در Knot Resolver 1000، سطح بهره تقریباً چندین ده برابر (5.1.0-24) است، از زمان تعیین نام‌های NS به صورت متوالی انجام می‌شوند و بر محدودیت داخلی تعداد مراحل حل نام مجاز برای یک درخواست استوار است.
دو استراتژی دفاعی اصلی وجود دارد. برای سیستم های دارای DNSSEC استفاده کنید برای جلوگیری از دور زدن کش DNS زیرا درخواست ها با نام های تصادفی ارسال می شوند. ماهیت روش تولید پاسخ های منفی بدون تماس با سرورهای DNS معتبر، با استفاده از بررسی محدوده از طریق DNSSEC است. یک رویکرد ساده تر، محدود کردن تعداد نام هایی است که می توان در هنگام پردازش یک درخواست تفویض شده تعریف کرد، اما این روش ممکن است در برخی از تنظیمات موجود مشکلاتی ایجاد کند زیرا محدودیت ها در پروتکل تعریف نشده اند.
منبع: opennet.ru