خبر

  • تک بورد - محققان امنیتی در Wiz یک آسیب پذیری بزرگ دیگر Azure را کشف کردند

    محققان امنیتی در Wiz یک آسیب پذیری بزرگ دیگر Azure را کشف کردند
    1 روز و 19 ساعت قبل

    یک سرویس مدیریتی ناشناخته دسترسی ریشه مهاجمان بدون احراز هویت را به آنها داد.

    خواندن بیشتر

    «بدترین آسیب پذیری ابری که می توانید تصور کنید» در Wiz فروشنده امنیتی AzureCloud مایکروسافت کشف شد-که اخیراً با کشف آسیب پذیری گسترده در سرویس پایگاه داده تحت مدیریت CosmosDB مایکروسافت خبرساز شده است-حفره دیگری در Azure پیدا کرده است.

    آسیب پذیری جدید روی ماشین های مجازی لینوکس بر Azure تأثیر می گذارد. آنها با یک سرویس کمی شناخته شده به نام OMI نصب می شوند که به عنوان یک محصول جانبی قادر به گزارش دهی و/یا مدیریت گزینه های ورود به سیستم در رابط کاربری Azure است.

    در بدترین حالت ، آسیب پذیری OMI را می توان به اجرای کد ریشه از راه دور-اگر چه خوشبختانه ، فایروال Azure بصورت پیش فرض ، خارج از VM ، فقط به شبکه های داخلی بیشتر مشتریان محدود می شود.

    OMIGOD

    انتخاب گزینه هر یک از چندین سرویس زیرساخت جذاب Azure (مانند ورود به سیستم توزیع شده) به طور خودکار یک سرویس کمی شناخته شده را در داخل ماشین مجازی Azure مورد نظر نصب می کند. این سرویس ، OMI - مخفف Open Management Interface - در نظر گرفته شده است که مانند سرویس WMI مایکروسافت عمل کند و مجموعه ای از گزارشات و معیارها و همچنین برخی از مدیریت از راه دور را قادر می سازد.

    بخشی از مشخصات OMI نیاز به احراز هویت دارد به منظور اتصال دستورات و درخواست ها به یک شناسه کاربری خاص (UID) - اما متأسفانه ، یک اشکال باعث شد درخواست های ناقص که از محدوده احراز هویت صرف نظر می کنند ، به طور خودکار توسط کاربر اصلی پذیرفته شود.

    وقتی OMI که برای مدیریت از راه دور پیکربندی شده است ، یک سرور HTTPS را بر روی پورت 5986 اجرا می کند ، که می تواند با یک سرویس گیرنده استاندارد HTTPS مانند curl به آن متصل شود و دستورات قابل قبول قابل خواندن توسط انسان در پروتکل SOAP مشتق شده از XML داده شود. در پیکربندی های دیگر ، OMI فقط روی یک سوکت محلی یونیکس در /var/opt/omi/run/omiserver.sock اجرا می شود که بهره برداری از آن را فقط برای کاربران محلی محدود می کند. او با نشان دادن این آسیب پذیری ، بیشتر آن را از نظر افزایش امتیاز توصیف کرد - مهاجمی که در دستگاه مجازی آسیب دیده به هر چیزی دست می یابد می تواند با استفاده از نحو OMI هرگونه دستور دلخواه را به عنوان root صادر کند.

    در محیط های بزرگتر جایی که OMI به یک پورت شبکه گوش می دهد ، نه فقط یک سوکت محلی یونیکس ، این یک راه عالی برای چرخاندن جانبی است - مهاجمی که در یک ماشین مجازی در شبکه محلی Azure مشتری پوسته می گیرد ، معمولاً می تواند از OMI حشره دار برای کنترل هر چیزی استفاده کند. دستگاه مجازی دیگر در همان بخش شبکه. سازمانهایی که مرکز سیستم مایکروسافت (که در هر نصب جدید ویندوز سرور 2019 و بالاتر تبلیغ می شود) را تصویب می کنند و میزبان های لینوکس را بر روی یا خارج از آن مدیریت می کنند ، با نسخه اشکالی OMI که بر روی میزبان های مدیریت شده نصب می شود ، خاتمه می دهند.

    همانطور که من و نیر در مورد دامنه آسیب پذیری صحبت می کردیم ، به احتمال اینکه برخی از مشتریان Azure ورود به سیستم رابط کاربری را فعال کرده و قانون "مجاز پیش فرض" را به فایروال آزور لینوکس VM اضافه کنند ، اشاره کردم - مطمئناً این عمل نادرست است ، اما اتفاق می افتد من فریاد زدم: "وای خدای من" و تیم ویز از خنده ترکید. همانطور که معلوم شد ، دقیقاً همان چیزی است که آنها این آسیب پذیری را نامیده اند - OMIGOD.

    جمع آوری پاداش دشواری

    با وجود شدت آشکار OMIGOD - که شامل چهار اشکال جداگانه اما مرتبط است ویز کشف کرد - این شرکت با مشکلاتی مواجه شد که مایکروسافت برای کشف و افشای مسئولانه آن پاداش پرداخت کند. در مجموعه ای از ایمیل های Ars که مورد بررسی قرار گرفت ، نمایندگان مایکروسافت در ابتدا این آسیب پذیری ها را به عنوان "خارج از محدوده" Azure نادیده گرفتند. به گفته ویز ، نمایندگان مایکروسافت در یک تماس تلفنی اشکالات موجود در OMI را به عنوان یک مشکل "منبع باز" توصیف کردند.

    این ادعا با این واقعیت پیچیده است که مایکروسافت در ابتدا OMI را تأسیس کرده است ، گروه باز در سال 2012. از آن زمان ، اکثریت قریب به اتفاق تعهدات به OMI از طرف مشارکت کنندگان مستقر در ردموند و شاغل در مایکروسافت انجام می شود-منبع باز است یا خیر ، این به وضوح یک پروژه مایکروسافت است.

    در علاوه بر مالکیت واقعی مایکروسافت بر پروژه ، سیستم مدیریتی خود Azure به طور خودکار OMI را مستقر می کند - از مدیران خواسته نمی شود که خط فرمان را زده و بسته را برای خود نصب کنند. در عوض ، هر زمان که یک گزینه وابسته به OMI در Azure GUI کلیک شود ، به طور خودکار در داخل ماشین مجازی مستقر می شود.

    حتی هنگامی که مدیریت Azure OMI را مستقر می کند ، اطلاع چندانی واضح از سرپرست دستگاه وجود ندارد. ما دریافتیم که به نظر می رسد اکثر سرپرستان Azure فقط متوجه می شوند که OMI وجود دارد اگر پارتیشن /var آنها با دامپ های اصلی پر شود. با مجموع 70،000 دلار برای چهار اشکال شامل آن.

    گوشه گرد و غبار زنجیره تامین

    اوهفلد به Ars گفت. "OMI مانند پیاده سازی لینوکس از زیرساخت مدیریت ویندوز است. "فرض ما این است که وقتی آنها به ابر رفتند و مجبور به پشتیبانی از ماشین های لینوکس شدند ، آنها می خواستند فاصله را از بین ببرند ، و رابط کاربری یکسانی را برای دستگاه های ویندوز و لینوکس داشته باشند."

    گنجاندن OMI در Azure Management -و در مرکز سیستم مایکروسافت ، که مستقیماً در هر نصب ویندوز سرور جدید تبلیغ می شود-به این معنی است که به عنوان یک جزء سطح پایین بر روی تعداد سرسام آور ماشینهای بسیار مهم لینوکس ، مجازی و غیره نصب می شود. این واقعیت که در برخی از پیکربندی ها با استفاده از پروتکل های بسیار معروف (SOAP over HTTPS) به دستورات یک پورت شبکه باز گوش می دهد ، آن را به یک هدف بسیار جذاب برای مهاجمان تبدیل می کند.

    تبلیغات

    با محدوده هر دو استقرار و آسیب پذیری بالقوه ، می توان منطقی انتظار داشت که تعداد زیادی کره چشم روی OMI باشد - به اندازه کافی که یک آسیب پذیری خلاصه شده به عنوان "فراموش کرده اید تا مطمئن شوید کاربر تأیید شده است" به سرعت کشف شود. متأسفانه ، اینطور نیست - OMI در مجموع 24 نفر مشارکت کننده ، 90 چنگال و 225 "ستاره" (اندازه گیری علاقه نسبتاً معمولی توسعه دهندگان) در طول نه سالی که در Github خانه داشته است ، بسیار نگران کننده است.

    در مقابل ، پروژه مدیریت ZFS من Sanoid - که به هیچ پورتی گوش نمی دهد و دقیقاً اگر غیرمنطقی به عنوان "چند هزار خط اسکریپت پرل" توصیف شده است - بیش از دو برابر مشارکت کننده و فورک و نزدیک به 10 برابر ستاره دارد .

    بر اساس هر معیار منطقی ، یک جزء زیرساختی با اهمیت بسیار زیاد OMI باید بسیار بیشتر مورد توجه قرار گیرد-که این س questionsالات را در مورد اینکه چگونه بسیاری از گوشه های گرد و غبار زنجیره تامین نرم افزار به طور یکسان زیر بازرسی و تحت بازرسی قرار می گیرند ، ایجاد می کند. -حفظ شد.

    یک مسیر ارتقاء نامشخص

    دیپاک جین ، کارمند مایکروسافت ، در 11 اوت اصلاحات لازم را در مخزن GitHub OMI انجام داد -اما همانطور که Ars به ​​طور مستقیم تأیید کرد ، این اصلاحات هنوز به کار گرفته نشده است به Azure از 13 سپتامبر. مایکروسافت به Wiz گفت که سه شنبه CVE را اعلام می کند ، اما محققان Wiz در مورد نحوه یا زمان اجرای این اصلاحات به صورت جهانی ابهام دارند.

    "مایکروسافت برنامه کاهش خود را با ما به اشتراک نگذاشته است" ، Wiz CTO آمی لوتواک به Ars می گوید: "اما بر اساس دور سنجی مشتریان خود ، این می تواند مشکل ساز باشد. OMI در چندین سرویس Azure تعبیه شده است و هر کدام ممکن است به یک مسیر ارتقاء متفاوت نیاز داشته باشند. "

    برای سیستم های دلخواه لینوکس که از راه دور از مرکز سیستم مایکروسافت مدیریت می شوند ، ممکن است مسیر ارتقاء پیچیده تر باشد - زیرا عوامل لینوکس برای System مرکز منسوخ شده است. مشتریانی که هنوز از System Center با لینوکس مجهز به OMI استفاده می کنند ، ممکن است نیاز داشته باشند که عامل OMI را به صورت دستی به روز کنند. با نگرانی از اینکه ممکن است OMI را اجرا کنید ، می توانید با جستجوی پورت های گوش دادن در TCP 5985 و 5986 (TCP 1270 ، برای عوامل OMI مستقر در مرکز سیستم Microsoft و نه Azure) یا سوکت یونیکس در زیر/var/opt/ omi.

    اگر سوکت یونیکس را دارید اما پورت ها را ندارید ، تا زمانی که مایکروسافت وصله ای را نصب نکند ، همچنان آسیب پذیر هستید - اما دامنه فقط به افزایش امتیازات محلی محدود می شود.

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

    به طور خاص ، مدیران با امنیت باید دسترسی به این و سایر خدمات شبکه را فقط به آن شبکه محدود کنند. بخشهایی که در واقع نیاز به دسترسی دارند. ماشین آلاتی که مرکز سیستم مایکروسافت را اجرا می کنند ، بدیهی است که به سیستم Olient در سیستم های سرویس گیرنده ، مانند زیرساخت خود Azure ، نیاز دارند - اما خود مشتریان نیازی به دسترسی OMI از یکدیگر به یکدیگر ندارند.

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

    در مواردی که عملی نیست - برای مثال ، در یک محیط Azure که سرپرست مطمئن نیست که بخشهای شبکه مایکروسافت برای دسترسی صحیح به OMI برای دسترسی به OMI به چه چیزی نیاز دارند - به سادگی عدم دسترسی سایر ماشین های مجازی در همان بخش شبکه ، حداقل از حرکت جانبی مهاجمان از یک دستگاه جلوگیری می کند. به دیگری.





خبرهای دیگر از فناوری اطلاعات