هدف از اقدامات امنیتی جدید کروم، محدود کردن یک کلاس کامل از حملات وب است


عکس بسیار نزدیک از انگشت بالای نماد کروم در گوشی هوشمند.

برای بیش از یک دهه، اینترنت در برابر دسته ای از حملات آسیب پذیر باقی مانده است که از مرورگرها به عنوان یک ساحل برای دسترسی به روترها و سایر دستگاه های حساس در یک شبکه هدف استفاده می کنند. در حال حاضر، گوگل بالاخره کاری در مورد آن انجام می دهد.

با شروع نسخه 98 کروم، زمانی که وب‌سایت‌های عمومی بخواهند به نقاط پایانی داخل شبکه خصوصی شخصی که از سایت بازدید می‌کند دسترسی پیدا کنند، مرورگر شروع به ارسال درخواست‌ها می‌کند. در حال حاضر، درخواست‌هایی که با شکست مواجه می‌شوند مانع از وقوع اتصالات نمی‌شوند. در عوض، آنها فقط ثبت خواهند شد. تقریباً در کروم 101 – با فرض اینکه نتایج این اجرای آزمایشی نشان‌دهنده خرابی بخش‌های عمده اینترنت نباشد – برای سایت‌های عمومی داشتن مجوز صریح قبل از دسترسی به نقاط پایانی در پشت مرورگر الزامی است.

لغو برنامه‌ریزی‌شده این دسترسی به این دلیل است که Google مشخصات جدیدی به نام دسترسی به شبکه خصوصی را فعال می‌کند، که به وب‌سایت‌های عمومی اجازه می‌دهد تنها پس از درخواست صریح سایت‌ها و اعطای درخواست توسط مرورگر، به منابع شبکه داخلی دسترسی داشته باشند. ارتباطات PNA با استفاده از پروتکل CORS یا Cross-Origin Resource Sharing ارسال می شود. تحت این طرح، سایت عمومی یک درخواست پیش از پرواز را در قالب هدر جدید ارسال می کند Access-Control-Request-Private-Network: true. برای اعطای درخواست، مرورگر باید با هدر مربوطه پاسخ دهد Access-Control-Allow-Private-Network: true.

نفوذ به شبکه از طریق مرورگر

تا به حال، وب‌سایت‌ها به‌طور پیش‌فرض این قابلیت را داشتند که از کروم و سایر مرورگرها به عنوان پروکسی برای دسترسی به منابع داخل شبکه محلی شخصی که از سایت بازدید می‌کند استفاده کنند. در حالی که روترها، چاپگرها یا سایر دارایی های شبکه اغلب قفل می شوند، مرورگرها – به دلیل نیاز به تعامل آنها با بسیاری از خدمات – به طور پیش فرض مجاز به اتصال تقریباً به هر منبعی در محیط شبکه محلی هستند. این باعث ایجاد یک کلاس از حملات به نام CSRF، مخفف جعل درخواست متقابل اسکریپت شده است.

چنین حملاتی بیش از یک دهه است که تئوریزه شده اند و در طبیعت نیز انجام شده اند که اغلب پیامدهای قابل توجهی در پی داشته است. در یکی از رویدادهای سال 2014، هکرها از CSRF برای تغییر تنظیمات سرور DNS برای بیش از 300000 روتر بی سیم استفاده کردند.

این تغییر باعث شد روترهای در معرض خطر از سرورهای DNS مخرب برای حل و فصل آدرس های IP که کاربران نهایی سعی در بازدید از آنها داشتند استفاده کنند. به عنوان مثال، به جای بازدید از سایت معتبر Google.com، سرور مخرب ممکن است آدرس IP یک سایت تقلبی را که کاربر نهایی هیچ دلیلی برای مضر بودن آن باور نداشته باشد، بازگرداند. تصویر زیر که از محققان تیم Cymru گرفته شده است، سه مرحله درگیر در این حملات را نشان می دهد.

سه مرحله از حمله که تنظیمات DNS روتر را با سوء استفاده از یک آسیب‌پذیری درخواست متقابل سایت در رابط وب دستگاه تغییر می‌دهد.
بزرگنمایی کنید / سه مرحله از حمله که تنظیمات DNS روتر را با سوء استفاده از یک آسیب‌پذیری درخواست متقابل سایت در رابط وب دستگاه تغییر می‌دهد.

تیم Cymru

در سال 2016، افرادی که پشت همان حمله بودند بازگشتند تا بدافزار معروف به DNSChanger را فشار دهند. همانطور که در آن زمان توضیح دادم، این کمپین علیه روترهای خانگی و اداری ساخته شده توسط Netgear، DLink، Comtrend و Pirelli به این صورت عمل کرد:

DNSChanger از مجموعه ای از پروتکل های ارتباطی بلادرنگ معروف به webRTC برای ارسال درخواست های به اصطلاح سرور STUN استفاده شده در ارتباطات VoIP استفاده می کند. این اکسپلویت در نهایت قادر است کد را از طریق مرورگر کروم برای ویندوز و اندروید قیف کند تا به روتر شبکه برسد. سپس این حمله روتر قابل دسترسی را با 166 اثر انگشت از تصاویر سفت‌افزار آسیب‌پذیر روتر مقایسه می‌کند.

با فرض اینکه مشخصات PNA به طور کامل اجرا شود، Chrome دیگر اجازه چنین اتصالاتی را نمی‌دهد مگر اینکه دستگاه‌های داخل شبکه خصوصی به صراحت اجازه دهند. در اینجا دو نمودار نشان می دهد که چگونه کار می کند.

گوگل

جاده پیش رو

از نسخه 98، اگر Chrome یک درخواست شبکه خصوصی را تشخیص دهد، یک “درخواست پیش از پرواز” زودتر از موعد ارسال می شود. اگر درخواست پیش از پرواز با شکست مواجه شود، درخواست نهایی همچنان ارسال می‌شود، اما یک هشدار در پانل مشکلات DevTools ظاهر می‌شود.

مهندس گوگل Titouan Rigoudy و توسعه دهنده گوگل Eiji Kitamura در یک پست وبلاگ اخیر نوشتند: “هر درخواست شکست خورده قبل از پرواز منجر به واکشی ناموفق خواهد شد.” “این به شما امکان می دهد تا بررسی کنید که آیا وب سایت شما بعد از مرحله دوم طرح عرضه ما کار می کند یا خیر. خطاها را می توان به همان روشی که هشدارها با استفاده از پانل های DevTools ذکر شده در بالا تشخیص داد.”

اگر و زمانی که Google مطمئن باشد اختلالات گسترده ای وجود نخواهد داشت، برای انجام درخواست های قبل از پرواز باید موافقت شود.