IPImen ، Firewall ، NGFirewall-UTM، آیپی ایمن، فایروال ایرانی ، فایروال بومی، یوتی ام بومی، یوتی ام ایرانی، فایروال نسل بعدی ایرانی، فایروال نسل بعدی بومی

یک آسیب پذیری امنیتی پچ نشده که بر پلتفرم  Compute Engine گوگل تأثیر می گذارد، می تواند توسط مهاجمان مورد سواستفاده قرار گرفته و ماشین های مجازی را از طریق شبکه در اختیار و کنترل بگیرد.

ایمره راد، پژوهشگر امنیتی در تحلیلی که روز جمعه منتشر شد، گفت: "این کار با جعل هویت سرور متادیتا از طریق ماشین مجازی که هدف قرار گرفته است، انجام می شود. با برقراری این بهره برداری، مهاجم می تواند از طریق SSH (کلید عمومی احراز هویت) به خود اجازه دسترسی دهد تا بتواند به عنوان کاربر اصلی و روت وارد سیستم شود".

پلتفرم Google Compute Engine (GCE) یک مولفه infrastructure-as-a-service (IaaS) در پلتفرم Google Cloud  است که کاربران را قادر می سازد ماشین های مجازی (VM) را در صورت تقاضا، ایجاد و راه اندازی کنند. GCE روشی را برای ذخیره و بازیابی متادیتا در قالب سرور متادیتا ارائه می دهد که یک نقطه مرکزی برای تنظیم متادیتا را به شکل جفت key-value ارائه می دهد که سپس در زمان اجرا در اختیار ماشین های مجازی قرار می گیرد.

به گزارش هکرنیوز و به گفته این محقق، این مسئله نتیجه ضعف اعداد شبه تصادفی است که توسط کاربر ISC DHCP استفاده می شود، و در نتیجه سناریویی ایجاد می شود که در آن مهاجم چندین پکت DHCP را با استفاده از مجموعه ای از شناساگرهای تبادلات از پیش محاسبه شده (با نام مستعار XID) را میسازد و کاربر قربانی DHCP تحت هجمه قرار میدهد که در نهایت منتج به جعل هویت سرور متادیتا می شود.

پروتکل پیکربندی فعال میزبان (DHCP) یک پروتکل مدیریت شبکه است که برای خودکار سازی فرآیند پیکربندی دستگاه ها در IP های شبکه استفاده می شود. یک سرور DHCP به صورت پویا یک آدرس IP و سایر پارامترهای پیکربندی شبکه را به هر یک دستگاه سرویس گیرنده در شبکه اختصاص می دهد تا بتوانند با شبکه های دیگر ارتباط برقرار کند.

راد در این مقاله فنی توضیح داد: "اگر XID صحیح باشد، دستگاه قربانی پیکربندی شبکه را اعمال می کند. این یک فضایرقابتی ایجاد میکند، اما از آنجا که هجمه و حمله سریع و بصورت همه جانبه است، سرور متادیتا هیچ شانسی برای پیروزی ندارد. در این مرحله مهاجم در موقعیت پیکربندی مجدد استک شبکه قربانی میباشد".

با توجه به اینکه می توان از سرور متادیتا برای توزیع و مدیریت کلیدهای SSH استفاده کرد، کاربر (اکنون اتصال TCP را به سرور ناپایدار برقرار کرده است) می تواند کلید عمومی SSH مهاجم را بازیابی کرده و پس از آن توسط مهاجم می تواند جهت دسترسی shell از راه دور را به عنوان کاربر اصلی و روت مورد استفاده قرار گیرد.

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

گوگل در مورد این مسئله در تاریخ 27 سپتامبر سال 2020 مطلع شد، که از آن زمان گزارش را تأیید کرده است و اصطلاحا آن را "کشف خوب" توصیف کرده است؛ اما هنوز هیچ پچی منتشر نکرده و یا جدول زمانی برای اصلاح این نقص ارائه نکرده است.

راد خاطرنشان کرد: "تا زمان برطرف شدن مشکل و حصول اطمینان از اینکه ارتباط DHCP از سرور متادیتا (169.254.169.254) حاصل می شود، از DHCP استفاده نکنید و هیچگونه فایروال با سطح دسترسی هاست را اعمال ننمایید. UDP/68 بین VM ها مسدود کنید تا فقط سرور متادیتا بتواند DHCP را انجام دهد".

این مورد بسیار متفاوت از اولین باری است که راد در Google Cloud Platform، مواردی را شناسایی کرد.

در سپتامبر سال 2020، گوگل یک آسیب پذیری محلی برای افزایش اختیارات را در ابزار پیکربندی سیستم عامل اصلاح کرد که می توانست توسط مهاجمی که دارای اجازه اجرای کد در GCE ماشین های مجازی تحت تاثیر است، برای انجام عملیات غیرمجاز مورد سواستفاده قرار بگیرد.

در اوایل ماه ژانویه سال جاری میلادی، راد همچنین دریافت که دستیابی به امکان اجرای کد دلخواه در یک ماشین مجازی با در دست گرفتن shell در سرویس پایگاه داده Cloud SQL امکان پذیر است. گوگل نهایتا در 16 ماه فوریه سال 2021 به این ورود کرده و آنرا رفع کرد.