DNS Rebinding چیست و چگونه کار می کند؟

کنسول های مبتنی بر وب (Web-based consoles) به طور گسترده توسط نرم افزارهای مدیریتی و دستگاه های هوشمند برای ارائه داده به صورت تصویر های تعاملی و پیکربندی کاربر پسند مورد استفاده قرار می گیرند. این امر با پیچیده‌تر شدن سیستم‌های رایانه‌ای شرکت‌ها و استفاده از دستگاه‌های مدرن‌تر اینترنت اشیا (IoT) در خانه، شتاب بیشتری می‌گیرد. این برنامه های وب معمولاً در محیط های داخلی یا شبکه های خصوصی محافظت شده توسط فایروال ها قرار دارند. بنابراین معمولاً سطح اعتماد بالایی برای بازدیدکنندگان دارند. آنها معمولاً فرض می‌کنند که همه بازدیدکنندگان مجاز هستند و بنابراین اطلاعات حساس را در معرض دید قرار می‌دهند یا امتیازات سرپرست را بدون محافظت قوی در سطح برنامه ارائه می‌کنند.

اگرچه قرار است سرویس‌های وب در شبکه‌های خصوصی از اینترنت جدا باشند و سیاست یکسانی از تعامل وب‌سایت‌های خودسرانه با سرورهای داخلی جلوگیری می‌کند، هکرها همچنان می‌توانند با سوء استفاده از سیستم نام دامنه از کنسول‌های مبتنی بر وب برای سوء استفاده از شبکه‌های داخلی استفاده کنند. (DNS) از طریق تکنیکی به نام DNS rebinding. این تکنیک می‌تواند سطوح حمله برنامه‌های وب داخلی را پس از راه‌اندازی در مرورگرهای قربانیان، در معرض وب‌سایت‌های مخرب قرار دهد.

در این وبلاگ، مکانیسم و شدت حمله rebinding DNS را با نمونه‌های نفوذ ارائه می‌کنیم. پس از آن، روش‌های اصلی کاهش این حمله و محدودیت‌های آن را معرفی می‌کنیم. اگر میخوای در مورد DNS بیشتر بدونی روی این لینک کلیک کن

مکانیسم DNS Rebinding

اجازه دادن به درخواست‌های cross-origin بسیار خطرناک است. بنابراین اکثر مرورگرهای مدرن این درخواست ها را مسدود می کنند. با این حال،Rebinding DNS راهی برای دور زدن این محدودیت فراهم می کند. این بخش اهمیتsame-origin policy نحوه عملکرد Rebinding DNS را معرفی می کند.

Same-origin Policy

برنامه های کاربردی وب معمولاً به منابع مختلفی مانند جاوا اسکریپت، تصاویر و CSS برای ارائه صفحات وب نیاز دارند. یک صفحه وب می‌تواند این منابع را از همان سروری که خودش یا از مبداهای مختلف دریافت کند، به دست آورد. درخواست cross-origin، برنامه را قادر می سازد از منابع مشترک مانند کتابخانه های اسکریپت شخص ثالث بهره مند شود. با این حال، اجازه دادن به یک وب سایت برای دسترسی به منابع از منابع دلخواه می تواند یک فاجعه باشد. بدون کنترل دسترسی، یک صفحه وب مخرب می تواند از اعتماد اعطا شده به یک کاربر قانونی سوء استفاده کند و درخواست های غیرمجاز را از طرف آن شخص به یک برنامه وب مهم ارسال کند. این اکسپلویت به عنوان جعل درخواست بین سایتی (CSRF) شناخته می شود.

مرورگرهای مدرن برای کاهش این تهدید، سیاست یکسانی را اعمال می کنند. این سیاست یک اسکریپت را از دسترسی به منابع یا محتوا وب از منابع مختلف منع می کند. تحت این سیاست، یک صفحه وب همچنان می‌تواند منابع cross-origin را در تگ‌های HTML خود بارگیری کند. به عنوان مثال، می‌تواند یک iframe برای نمایش تبلیغات شخص ثالث تعبیه کند. با این حال، وب سایت های مخرب نمی توانند محتوای پاسخ درخواست های cross-origin را از طریق اسکریپت ها بخوانند.

DNS Rebinding

same-origin policy، یک مکانیزم امنیتی در مرورگر ها است که اوریجین (origin) های مختلف را با ترکیب طرح URI، نام میزبان (hostname) و پورت (port) شناسایی می کند. در میان این مؤلفه ها، مرورگرها برای شناسایی سرورهای مختلف در اینترنت به نام هاست متکی هستند. با این حال، نام میزبان به طور مستقیم به دستگاه های شبکه متصل نیست. در عوض، آنها به آدرس های IP توسط DNS حل می شوند. سپس آدرس های IP به صورت ایستا یا پویا به دستگاه ها متصل می شوند. از آنجایی که صاحبان دامنه کنترل کامل سوابق DNS خود را دارند، می توانند نام میزبان خود را به آدرس های IP دلخواه حل کنند. حمله Rebinding DNS از این امتیاز سوء استفاده می کند. پس از اینکه مرورگرهای قربانی بارهای حمله را از سرور هکر بارگیری کردند، مهاجمان می‌توانند نام میزبان خود را به آدرس‌های IP داخلی که به سرورهای هدف اشاره می‌کنند، دوباره پیوند دهند. این به اسکریپت‌های مهاجم اجازه می‌دهد تا از طریق نام‌های میزبان مخرب به منابع خصوصی بدون نقض same-origin policy همان origin دسترسی پیدا کنند. در واقع یک زنجیره ای از حملات را با این حمله میشه انجام داد !

[ آموزش هدر های امنیتی HTTP ]

شکل 1 مکانیسم حمله DNS Rebinding را با یک مثال فرضی نشان می دهد. در این مثال، قربانی، Alex، یک وب سرویس خصوصی در شبکه داخلی خود با آدرس IP 192.0.0.1 دارد. این سرور حاوی داده های محرمانه است و قرار است فقط توسط رایانه الکس قابل دسترسی باشد. در سمت حمله، Bob دو سرور را کنترل می کند: یک DNS resolver (1.2.3.4) و یک وب سرور (5.6.7.8) که میزبان وب سایت مخرب است. علاوه بر این، Bob یک دامنه، attack.com را با رکورد سرور نام (NS) آن به 1.2.3.4 ثبت می کند.
هنگامی که Alex attack.com را در مرورگر خود باز می کند، یک درخواست DNS به DNS resolver Bob ارسال می کند و آدرس سرور مخرب 5.6.7.8 را بازیابی می کند. پس از بارگذاری در مرورگر alex، اسکریپت مخرب در وب سایت Bob تلاش می کند تا DNS resolution  دیگری را برای دامنه خود راه اندازی کند. با این حال، این بار DNS resolver به جای آن 192.0.0.1 را برمی گرداند. بنابراین attack.com به آدرس IP مورد نظر باز می گردد. پس از آن، اسکریپت مخرب می‌تواند به ارسال درخواست‌ها برای attack.com ادامه دهد، که در نهایت به سرور خصوصی می‌رسد. از آنجایی که مرورگر alex این درخواست‌ها را به‌عنوان cross-origin تشخیص نمی‌دهد، وب‌سایت مخرب می‌تواند secrets بازگردانده شده را بخواند و تا زمانی که در مرورگر قربانی باز باشد، داده‌های دزدیده شده را استخراج کند.

DNS Rebinding در حملات دنیای واقعی

با استفاده از پیوند DNS Rebinding، مهاجمان می توانند از مرورگرهای قربانیان به عنوان پروکسی خود برای گسترش سطح حمله به شبکه های خصوصی سوء استفاده کنند. این تکنیک به طور قابل توجهی آسیب پذیری های احتمالی در معرض هکرها را افزایش می دهد زیرا برنامه های کاربردی وب بیشتری در شبکه های سازمانی و خانگی راه اندازی می شوند. علاوه بر این، سطح اعتماد پیش فرض سرویس داخلی بالا است. بنابراین، اتصال DNS Rebinding می تواند نقشی محوری در حملات دنیای واقعی با ترکیب تکنیک های مختلف نفوذ و سوء استفاده های آسیب پذیری ایفا کند. این بخش نشان می‌دهد که چگونه در نفوذ عملی با Singularity، یک پلت‌فرم DNS Rebinding منبع باز نقش دارد.

نفوذ به شبکه خصوصی با DNS Rebinding

مرحله اولیه حمله DNS Rebinding مانند سایر حملات مبتنی بر وب است: فریب دادن قربانیان برای باز کردن وب سایت های مخرب از طریق تکنیک های مختلف مهندسی اجتماعی مانند ارسال ایمیل های فیشینگ و سایبری.

پس از راه‌اندازی وب‌سایت‌های مخرب در مرورگرهای قربانیان، هکرها باید آدرس‌های IP خصوصی و پورت‌هایی را که میزبان سرویس‌های آسیب‌پذیر هستند، قبل از اجرای حمله DNS Rebinding شناسایی کنند. وب سایت های مهاجم می توانند خدمات وب باز در شبکه های محلی را با تکنیک WebRTC اسکن کنند. Singularity یک استراتژی ساده‌تر را پیاده‌سازی می‌کند: مستقیماً درخواست‌های cross-origin را ارسال می‌کند و مدت زمان دریافت پیام‌های خطا را اندازه‌گیری می‌کند. اگر سرور درخواستی وجود داشته باشد، استثنا سریعتر مطرح می شود. شکل 2 نحوه عملکرد Singularity را هنگام اسکن محیط آزمایشی نشان می دهد. سرویس های داخلی میزبانی شده در 10.0.0.6:80 و 10.0.0.6:8080 را در ثانیه تشخیص می دهد. این مرحله اهداف موجود برای اتصال DNS rebinding را نشان می دهد. از طریق پورت های باز، مهاجمان همچنین می توانند بررسی کنند که چه برنامه های وب در پشت این آدرس های IP قرار دارند و آیا آنها آسیب پذیر هستند یا خیر.

پس از مکان یابی سرویس های مورد نظر، وب سایت مهاجم می تواند حمله rebinding DNS را در iframe خود انجام دهد. اولین درخواست پیلود rebinding  را از نام میزبان مخرب بازیابی می کند. این اسکریپت مهاجم، resolution مکرر را برای نام میزبان خود آغاز می کند تا زمانی که به آدرس IP هدف مجدداً متصل شود. سپس iframe می تواند بدون آگاهی قربانی به ارتباط با سرویس داخلی ادامه دهد.

در حملات دنیای واقعی، یکی از اهداف بالقوه پیوند rebinding DNS، دستگاه‌های زیرساخت شبکه با کنسول‌های مبتنی بر HTTP است. به عنوان مثال، روترهای شخصی می توانند در برابر حمله آسیب پذیر باشند. بسیاری از آنها با پیکربندی پیش فرض و رمزهای عبور ضعیف تنظیم شده اند. این بدان معناست که نفوذگرهای بالقوه می توانند به راحتی آدرس IP خود را حدس بزنند و نام میزبان های مخرب را دوباره به آنها متصل کنند. پس از اینکه مهاجمان وارد پنل های پیکربندی شبکه شدند، می توانند بسته های شبکه را در شبکه قربانی sniff کنند، حملات انکار سرویس (DOS) را انجام دهند و ترافیک را hijack کنند.

نوع دیگری از تهدید ناشی از دستگاه های هوشمند است که امروزه در اطراف بسیاری از خانه ها و ادارات وجود دارد. علاوه بر کنسول‌های مبتنی بر وب، اتصال rebinding DNS می‌تواند سایر API‌های Restful و سرورهای پروتکل‌های Plug and Play جهانی (UPnP) را که در معرض شبکه‌های داخلی دستگاه‌های IoT مدرن قرار دارند، هدف قرار دهد. این APIها برای پیاده سازی یا نگهداری عملکرد رزرو شده اند. با این حال، برخی از آنها فاقد محافظت کافی در برابر اتصال مجدد DNS هستند. هنگامی که مهاجمان مرورگرهای قربانیان را به خطر می اندازند و نام هاست آنها را به آدرس IP مورد نظر دوباره متصل می کنند، این سرویس ها امتیازات خاصی مانند اسکن شبکه، استخراج داده های حسگر و کنترل از راه دور بدون هیچ گونه احراز هویت را برای آنها فراهم می کند. آسیب‌پذیری‌های DNS در چندین دستگاه هوشمند شرکت‌های مطرح از جمله Google Home، Sono WiFi Speaker و Roku یافت شده است. همانطور که در شکل 3 نشان داده شده است، از سال 2015، هر سال حداقل یک رکورد CVE مربوط به اتصال rebinding DNS وجود داشته است. تعداد CVE های مرتبط از سال 2018 به طور قابل توجهی افزایش یافته است

برای شرکت ها، برنامه های کاربردی وب مدیریت داخلی بسیار مهم هستند. آنها میزبان اطلاعات محرمانه هستند و قابلیت های مدیریت سیستم را در اختیار مدیران قرار می دهند. بنابراین، بسیار خطرناک است که یک وب‌سایت با اتصال DNS rebinding روی دستگاهی در شبکه‌های شرکت اجرا شود.

در اینجا، برای نشان دادن خطر، یک حمله DNS rebinding را روی محیط شبیه سازی شده خود راه اندازی می کنیم. برنامه وب داخلی هدف یک رابط وب داخلی Hadoop است. همانطور که در شکل 4a نشان داده شده است، قربانی می تواند با URL 10.0.0.6:8088/cluster از این UI بازدید کند و وضعیت cluster را در حالی که به صورت خارجی در دسترس نیست بررسی کند. شکل 4b درخواست rebinding را نشان می دهد که توسط وب سایت مهاجم در مرورگر قربانی ایجاد شده است. در این آزمایش، نام میزبان مخرب s-54.183.63.248-10.0.0.6-1609933722-fs-e.dynamic.dns-rebinding-attack.com است. درخواست HTTP به نام میزبان در واقع به 10.0.0.6 ارسال شد و کد وضعیت موفق را دریافت کرد. پس از این، مهاجم می تواند از مرورگر قربانی به عنوان یک تونل استفاده کند و به طور مستقیم با سرویس هدف تعامل داشته باشد. همانطور که در شکل 4c نشان داده شده است، مهاجم می تواند همان اطلاعاتی را که قربانی می تواند از cluster Hadoop از طریق دامنه مخرب به آن دسترسی داشته باشد، بدست آورد. علاوه بر سرقت اطلاعات، مهاجم همچنین این امتیاز را دارد که jobs  در حال اجرا را در صفحه مدیریت از بین ببرد. همانطور که در این مثال با Hadoop دیدیم، بسیاری از پلتفرم‌های توسعه و مدیریت پرکاربرد می‌توانند در معرض عوامل تهدید مجهز به rebinding DNS قرار بگیرند، اگر به درستی محافظت نشوند.

Cross-origin Request Forgery Protection Bypass

علاوه بر تونل سازی ساده ترافیک برای مهاجمان، وب سایت های مخرب می توانند از تکنیک DNS rebinding برای دور زدن حفاظت CSRF مبتنی بر توکن استفاده کنند. در حالی که DNS rebinding ترافیک cross-origin را پنهان می کند، CSRF مستقیماً درخواست های cross-origin را ارسال می کند تا از اعتماد سرور هدف برای قربانی استفاده کند. CSRF یک تهدید شناخته شده است و بسیاری از برنامه های کاربردی وب در برابر آن دفاعی را پیاده سازی کرده اند. یکی از استراتژی های اصلی حفاظت، یک توکن منحصر به فرد را در صفحه پاسخ اولیه تعبیه می کند. تمامی درخواست های زیر باید با این توکن ارسال شوند تا توسط سرور پذیرفته شوند. این راه حل مبتنی بر محدودیت یک منبع است که از خواندن محتوای response درخواست های متقابل توسط وب سایت های مخرب جلوگیری می کند. از آنجایی که مهاجمان نمی توانند توکن را از response دریافت کنند، شانسی برای ارسال درخواست های معتبر بین سایتی ندارند.

با این حال، مرورگرها تحت حمله دوباره DNS rebinding هیچ درخواستی از cross-origin را متوجه نمی شوند. این بدان معنی است که آنها به اسکریپت های مخرب اجازه می دهند تا رمز CSRF را از پاسخ های اولیه دریافت کنند و از آن برای جعل درخواست های بعدی استفاده کنند.

ما برای نشان دادن این تهدید، payload اجرای فرمان از راه دور (RCE) Singularity را در محیط شبیه سازی خود راه اندازی کردیم. این حمله Rails را هدف قرار می دهد، یک framework توسعه وب که به زبان روبی نوشته شده است. یکی از API های PUT رزرو شده به درخواست کننده اجازه می دهد تا دستورات سیستم دلخواه را روی سرور اجرا کند. مشابه توکن CSRF، این API از بازدیدکننده می خواهد که URL درخواست را با شناسه session پویا (رشته ای که در شکل 5 با رنگ قرمز مشخص شده است)، که در صفحه اصلی تعبیه شده است، تولید کند. برنامه وب یک توکن جدید در حال تولید ایجاد می کند و برای هر session یک توکن را ترسیم می کند. پیش‌بینی نقطه پایانی معتبر API بدون خواندن پاسخ‌های سرور غیرممکن است. با این حال، payload Singularity RCE می تواند رمز را از صفحه فهرست پس از اجرای DNS rebinding دریافت کند. در نسخه ی نمایشی، به سایت مخرب اجازه می دهیم شناسه session به سرقت رفته را در کنسول مرورگر چاپ کند. سپس URL مورد نظر را با موفقیت ساخت و از API آسیب پذیر برای اجرای یک فرمان دلخواه در سمت سرور استفاده کرد که پیام “Hello from rebinding test” را در پایانه های سرور نمایش می دهد. پس از اینکه تیم Singularity این اکسپلویت را منتشر کرد، Rails یک فیلتر سمت سرور را برای تأیید فیلد میزبان همه درخواست‌های دریافتی اعمال کرد.

جلوگیری از DNS rebinding

استراتژی‌های مختلف تلاش می‌کنند تا حمله DNS rebinding را در هر جزء شبکه مرتبط کاهش دهند. در این بخش مکانیسم های دفاعی مختلف و محدودیت های آنها را معرفی می کنیم. پس از آن، ایده اصلی آشکارساز DNS rebinding و مزایای آن را ارائه خواهیم کرد.

کاهش مبتنی بر مرورگر

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

با این حال، راه های متعددی برای دور زدن حفاظت pining DNS وجود دارد. یک راه ساده این است که اسکریپت مخرب را طراحی کنید تا درخواست ها را به طور مکرر ارسال کنید تا زمانی که حافظه پنهان مرورگر منقضی شود. سپس نام میزبان مخرب به آدرس IP هدف مجدداً متصل می شود. سپس وب سایت مهاجم می تواند پاسخ مورد انتظار را از سرویس هدف دریافت کند.

یک پیاده‌سازی پیچیده‌تر به نام چندین حمله A-Records می‌تواند حتی با حفاظت از پین کردن DNS به DNS rebinding پایدارتر و کارآمدتر برسد. شکل 6 روش های حمله را نشان می دهد. در این مورد، رفتار DNS با حمله سنتی متفاوت است: مرورگر قربانی فقط یک بار نام میزبان مخرب را حل می کند. اما هر دو آدرس IP مهاجم و هدف برگردانده می شوند. هنگامی که اسکریپت مخرب درخواست دوم را ارسال می کند، مرورگر ابتدا آدرس IP عمومی را امتحان می کند. اما وب سرور مهاجم آدرس IP قربانی را به خاطر می آورد و ترافیک ورودی را توسط فایروال مسدود می کند. عدم موفقیت این درخواست، مرورگر قربانی را مجبور می‌کند تا با آدرس IP خصوصی ارتباط برقرار کند و روند DNS rebinding را تکمیل کند.

کاهش مبتنی بر DNS

نوع دیگری از کاهش روی مرحله وضوح DNS متمرکز است. سرویس امن DNS، OpenDNS، پاسخ‌های DNS را که به RFC 1918 و آدرس‌های IP Loopback اشاره می‌کنند، حذف می‌کند. نرم افزارهای کش DNS مانند Dnsmasq و Unbound نیز سیاست های فیلترینگ مشابهی را برای آدرس های IP خصوصی پیاده سازی می کنند.

این استراتژی همچنین یک راه حل حفاظتی متمرکز است، اما همچنان محدودیت هایی دارد. اول از همه، همه سرویس‌های DNS ایمن فهرست کامل آدرس‌های IP را که به سرویس‌های خصوصی اشاره می‌کنند مسدود نکرده‌اند. به عنوان مثال، آدرس IP غیرقابل مسیریابی 0.0.0.0 می‌تواند نشانی‌های IP ماشین محلی را نشان دهد و می‌تواند توسط یک حمله DNS rebinding مورد هدف قرار گیرد. با این حال، چندین سیاست فیلترینگ آن را از دست داده است. علاوه بر آدرس‌های IP خصوصی، مهاجمان می‌توانند نام میزبان خود را با سوابق CNAME به نام میزبان داخلی مجدداً متصل کنند. resolver های داخلی قربانیان یا دستگاه‌های آن‌ها، resolution را به آدرس‌های IP خصوصی مهاجمان تکمیل می‌کنند. به عنوان مثال، نام میزبان مخرب را می توان به لوکال هاست بازگرداند. سپس تمام ترافیک بعدی به سرویس محلی خواهد رسید. به طور خلاصه، فیلتر مبتنی بر IP نمی تواند در برابر همه انواع حملات DNS بایند شوند.

علاوه بر این، فیلتر کردن تمام آدرس‌های IP خصوصی می‌تواند باعث بسیاری از موارد مسدود کردن موارد مثبت کاذب شود. ما مشاهده کردیم که برخی از سرویس‌های قانونی، رفتارهای resolution DNS مشابهی را به عنوان اتصال DNS rebinding ارائه می‌کنند. به عنوان مثال، برخی از خدمات اینترنت اشیا برای هدایت ترافیک در شبکه های خصوصی به نام هاست متکی هستند. این بدان معنی است که نام میزبان آنها فقط به آدرس های IP داخلی حل می شود و می تواند به اشتباه توسط این راه حل مسدود شود. علاوه بر این، برخی از نام‌های میزبان بی خطر نیز به آدرس‌های IP عمومی و خصوصی که این policy حفاظتی را نقض می‌کنند، حل می‌شوند. 

کاهش مبتنی بر سرور

دفاع در سمت برنامه های کاربردی وب می تواند DNS rebinding را به طور موثر مسدود کند. یکی از راه حل ها، پیاده سازی ارتباط HTTPS در تمامی سرویس های خصوصی است. مرحله handshake HTTPS به دامنه صحیح برای تأیید گواهی SSL نیاز دارد. در طول یک حمله DNS rebinding، مرورگرها فکر می کنند که با دامنه های مخرب ارتباط برقرار می کنند در حالی که گواهی های SSL از سرورهای داخلی برای دامنه های مختلف است. بنابراین، اسکریپت های مهاجم نمی توانند اتصالات SSL را به سرویس های هدف برقرار کنند. از طرف دیگر، اجرای احراز هویت با اعتبار قوی در تمام خدمات خصوصی نیز موثر است. با استفاده از این حفاظت در سطح برنامه، حتی اگر مهاجمان دوباره DNS rebinding را با موفقیت راه اندازی کنند، نمی توانند به اطلاعات محرمانه دسترسی پیدا کنند.

با این حال، این نوع کاهش بستگی به توسعه دهنده خدمات داخلی دارد. این بدان معنی است که مقیاس پذیر نیست. از آنجایی که برنامه های کاربردی وب شخص ثالث هم در محیط های خانگی و هم در محیط های سازمانی پر می شوند، برای صاحبان شبکه سخت تر است که از همه سرورهای بالقوه آسیب پذیر محافظت کنند. در همین حال، شکارچیان تهدید، آسیب‌پذیری‌های DNS را از برنامه‌های وب شخص ثالث جستجو می‌کنند – مانند اکسپلویت RCE کنسول Rails که در بخش قبل ذکر شد.

نتیجه

حمله DNS rebinding می تواند مرورگرهای قربانیان را به عنوان تونل های ترافیکی برای بهره برداری از خدمات خصوصی به خطر بیاندازد. با این تکنیک، مهاجمان می توانند اطلاعات محرمانه را سرقت کرده و درخواست های جعلی را به سرورهای قربانیان ارسال کنند. مرورگرها، resolver ها و برنامه‌های کاربردی وب استراتژی‌های حفاظتی مختلفی را برای دفاع در برابر آن اعمال کرده‌اند. با این حال، اکسپلویت های پیشرفته ای وجود دارند که می توانند دفاع های سنتی را دور بزنند. علاوه بر این، با پیچیده تر شدن محیط شبکه داخلی، اجرای حفاظت کامل سخت تر است.