هشدارهای افتایی
محققان دانشگاه‌های چینهوا و کالیفرنیا روشی جدید برای اجرای حملات موسوم به مسموم‌سازی حافظه نهان DNS یا DNS Cache Poisoning کشف کرده‌اند.
به گزارش معاونت بررسی مرکز افتا به نقل از سایت bleepingcomputer، این کشف جدید باگی را که در سال 2008 شناسایی شد و تا پیش از این تصور می‌شد که برای همیشه ترمیم شده است احیا می‌کند.
وظیفه سامانه DNS یا Domain Name System تبدیل نامه دامنه به نشانی IP است. در زمان فراخوانی یک دامنه، مرورگر با کمک سرور DNS، نشانی IP آن را شناسایی می‌کند. به‌منظور بهینه‌سازی این فرایند، نشانی‌های استخراج شده، بر روی دستگاه و سرورهای میانی به اصطلاح کش (Cache) می‌شوند.
عبارت مسموم‌سازی حافظه نهان DNS به دست‌درازی مهاجمان به حافظه نهان (Cache) موجود بر روی سرورهای میانی این سامانه‌ها اشاره دارد.
تصور کنید زمانی که کاربر نشانی www.gmail.com را در مرورگر خود وارد می‌کند بجای نشانی IP صحیح، نشانی IP مورد نظر مهاجم که سایتی جعلی اما کاملا مشابه با Gmail است به مرورگر او باز گردانده شود. با این تکنیک مهاجم قادر به ضبط تمامی اطلاعات وارد شده توسط کاربر در سایت مذکور خواهد بود.


این روش حمله در سال 2008 توسط یک محقق امنیتی با نام Dan Kaminsky کشف شد.
زمانی که دستگاه به دنبال پیدا کردن نشانی IP یک دامنه از طریق DNS است یک شناسه منحصربه‌فرد با عنوان Transaction ID نیز در درخواست ارسالی از سوی دستگاه به سرور DNS درج می‌شود.
هنگامی که سرور به دستگاه، پاسخ (نشانی IP متناظر با نام دامنه اعلامی) را ارسال می‌کند، دستگاه تنها پاسخی که در آن به شناسه Transaction ID صحیحی اشاره شده است را می‌پذیرد. سازوکاری که هدف آن جلوگیری از دریافت نشانی‌های IP جعلی از سوی سرورهای DNS در کنترل مهاجم است.
Kaminsky دریافته بود که تعداد کل شناسه‌های Transaction ID ممکن 65,536 عدد است.
بنابراین مهاجم می‌تواند با ارسال چندین پاسخ DNS جعلی با شناسه 0 تا 65,536 ضمن دستیابی به شناسه صحیح، همزمان باعث جلوگیری از کش شدن اولین پاسخ شود.
برای جلوگیری از کش شدن اولین پاسخ، مهاجم اقدام به تغییراتی در دامنه اعلامی می‌کند؛ برای مثال، هر پاسخ شامل یک زیردامنه متفاوت از دامنه مورد نظر است (نظیر 1.gmail.com، 2.gmail.com و ...).
با این تکنیک در نهایت مهاجم موفق به کشف شناسه Transaction ID صحیح می‌شود.
بدین‌ترتیب، دفعه بعد که کاربر به gmail.com مراجعه می‌کند، او به سرور مهاجم هدایت شده و در نتیجه حمله با موفقیت اجرا می‌شود.
برای مقابله با حملات مسموم‌سازی حافظه نهان DNS تصادفی‌سازی درگاه مبداء (Source Port Randomization) به‌کار گرفته شد.
هدف از به‌کارگیری آن این بود که حتی اگر مهاجم شناسه Transaction ID را هم به‌درستی حدس زد همچنان نتواند پاسخی جعلی را به دستگاه ارسال کند؛ چرا که از درگاه مبداء که آن هم در تئوری می‌تواند 65,536 حالت مختلف داشته باشد اطلاع ندارد.
دور زدن این سازوکار مستلزم حدس میلیاردها احتمال است و عملا غیرممکن تصور می‌شد.
اکنون محققان دانشگاه‌های چینهوا و کالیفرنیا روشی را ارائه کرده‌اند که در آن از یک حمله کانال جانبی (Side-channel Attack) برای کشف شماره درگاه انتخاب شده توسط دستگاه بهره گرفته می‌شود.
با دانستن شماره درگاه، باز هم اجرای موفق حملات مسموم‌سازی حافظه نهان DNS که توسط Kaminsky شناسایی شده بود ممکن می‌شود.
امکان تشخیص درگاه مبداء از نحوه پردازش درخواست‌های ICMP در برخی سیستم‌های عامل ناشی می‌شود.
در این سیستم‌های عامل به‌منظور صرفه‌جویی در میزان اشغال پهنای باند یک Rate Limiter (محدودکننده درخواست) لحاظ شده تا درخواست‌های ورودی در هر ثانیه بیشتر از مقدار تعیین شده در تنظیمات نباشد. این مقدار در Linux به‌طور پیش‌فرض 1000 بسته در هر ثانیه است. برای ردیابی این درخواست‌ها نیز از یک شمارنده (Counter) استفاده می‌شود.
برای هر درخواست دریافتی که در آن به یک درگاه غیرباز اشاره گردیده مقدار شمارنده یکی کسر شده و به فرستنده پاسخ Unreachable ارسال می‌شود.
بنابراین اگر در یک ثانیه 1000 بسته به درگاه‌های مختلفی ارسال شود که هیچ‌یک باز نیستند ارتباط مهاجم با آنها قطع می‌شود. اما در عین حال با این روش مشخص می‌شود که تمامی 1000 حدس نادرست بوده است.
جالب اینکه مقدار شمارنده برای هر درخواستی که به درگاه صحیحی اشاره دارد کسر نمی‌شود و بدیهی است که پاسخ Unreachable نیز ارسال نمی‌گردد.
پس در هر ثانیه مهاجم می‌تواند با سرریز کردن یک هزار بسته جعلی بر روی درگاه‌های تصادفی سرویس‌گیرنده DNS دستگاه را مورد حمله قرار دهد.
با این رویکرد، در عرض چند ثانیه مهاجم قادر به دستیابی به درگاه‌های باز بر روی دستگاه هدف خواهد بود.
با اطلاع از درگاه صحیح، مهاجم می‌تواند باگ Kaminsky را مورد بهره‌جویی (Exploit) قرار داده و موجب اجرای موفق حمله مسموم‌سازی DNS شود.
چندین سیستم DNS از جمله BIND، Unbound و dnsmasq از این آسیب‌پذیری جدید که منجر به مسموم‌سازی حافظه نهان DNS می‌شود تأثیر می‌پذیرند.
آسیب‌پذیری مذکور، SAD DNS – برگرفته شده از Side-channel AttackeD DNS – نامگذاری شده و به آن شناسه CVE-2020-25705 تخصیص داده شده است.
و اما راهکار...
همچون انتخاب تصادفی درگاه مبداء که با افزایش پیچیدگی، مانع از اجرای موفق حمله می‌شد، تخصیص تصادفی مقدار Rate Limiter، بجای استفاده از عددی ثابت نیز می‌تواند در مقابله با حمله SAD DNS مؤثر باشد.
سازوکار اصلاحی اشاره شده در 25 مهر ماه در Linux Kernel اعمال شده که جزییات آن در زیر قابل مطالعه است: بدین‌منظور در فایل icmp.c یک مقدار تصادفی به شمارنده – که با عنوان Credit شناخته می‌شود – تخصیص داده می‌شود. اما می‌توان انتظار داشت که اعمال آن بر روی تمامی سرورها زمان‌بر خواهد داد.


سایر راهکارهایی که از سوی محققان پیشنهاد شدند به تخریب کانال جانبی توجه دارند؛ برای مثال از طریق غیرفعال کردن ICMP، کاهش مهلت (Timeout) پرس‌وجوی DNS – برای به حداقل رساندن فرصت حمله – و استفاده از فناوری‌هایی نظیر DNSSEC، کوکی‌های DNS یا استفاده از کدگذاری به‌منظور افزودن رمز در پیام‌های DNS.
با این حال، برخی محققان مسدودسازی کامل ترافیک ICMP را به دلیل استفاده‌های معتبر از آن در مواردی همچون در فرایند IPv6 Fragmentation و بروز اختلال در بعضی معماری‌های جاری توصیه نمی‌کنند.
محققان شرکت بلو کت نیز استفاده از یک اسکریپت Shell را برای تغییر مستمرRate Limiter  پودمان ICMP به‌عنوان راهکاری موقت در برابر حملات SAD DNS پیشنهاد کرده‌اند. نمونه‌هایی از این اسکریپت‌ها در لینک زیر قابل دریافت است:
https://github.com/bluecatlabs/network-vip/tree/main/icmp_ratelimit
DNS پودمانی نسبتاً غیرامن است که در طراحی آن بیشتر از آن که به الزامات امنیتی توجه شده باشد بر روی سرعت و کارایی بالا تمرکز شده است. حتی لحاظ کردن بهبودهایی نظیر DNS-over-HTTPS یا همان DoH هم نتوانسته از مورد سوءاستفاده قرار گرفتن DNS جلوگیری کند.
به گفته این محققان علاوه بر Linux 3.18-5.10 سیستم‌های عامل زیر نیز البته با Rate Limiter  کمتر – 200 در Windows و FreeBSD و 250 در MacOS – آسیب‌پذیر هستند:
  •     Windows Server 2019 version 1809+ (نسخ قدیمی‌تر بررسی نشده‌اند)
  •     macOS 10.15+ (نسخ قدیمی‌تر بررسی نشده‌اند)
  •     FreeBSD 12.1.0+ (نسخ قدیمی‌تر بررسی نشده‌اند)
با این توضیح که اصلاحیه اشاره شده در نسخه 5.10 سیستم عامل Linux یکپارچه شده است.

منبع:
(با تشکر از شرکت مهندسی شبکه گستر برای همکاری در تهیه این گزارش)

 
 

 
امتیاز دهی
 
 

  • ارسال به دوستان
نام ارسال کننده :  
ایمیل ارسال کننده:
نام دریافت کننده :
ایمیل دریافت کننده :  
موضوع ایمیل :
کد تصویری :
 
 
امتیاز دهی
 
 


آدرس:
تهران، خیابان استاد شهید مطهری، خیابان میرزای شیرازی، کوچه شهدا، پلاک یک، مرکز مدیریت راهبردی افتا


ایمیل:
info@afta.gov.ir

.