در اواخر ماه گذشته ، محققان شرکت امنیتی ابر Wiz یک آسیب پذیری جدید را پیدا کردند که به کاربران Azure اجازه می دهد تا به پایگاه داده های ابری سایر کاربران دسترسی داشته باشند و این امر اصل چندگانگی امن را زیر پا گذاشت. آنها آن را ChaosDB نامیدند.
در این ماه ، آنها یکی دیگر را پیدا کردند. از برخی جهات ، این آسیب پذیری به اندازه آسیب پذیری ChaosDB نیست زیرا چندتایی را از بین نمی برد. اما از جهات دیگر ، آسیب پذیری جدید ، OMIGOD ، در واقع بدتر است.
آسیب پذیری ChaosDB ناشی از خطای پیکربندی اشتباه مایکروسافت بود. وقتی شرکت آن را برطرف کرد ، این آسیب پذیری از بین رفت. مشتریان فقط باید کلیدهای امنیتی خود را تنظیم مجدد کنند. مایکروسافت آن را به سرعت وصله کرد و هیچ سوء استفاده ای گزارش نشده است.
این یک آسیب پذیری جدی بود – محققان Wiz توانستند به پایگاه های اطلاعات شرکت های Fortune 500 دسترسی پیدا کنند – اما تأثیر آن محدود بود.
در مورد جدیدترین ، با نام OMIGOD ، که توسط مهاجمان مورد سوء استفاده قرار گرفته است ، اینطور نیست.
جان بامبنک ، شکارچی اصلی تهدید در شرکت امنیت سایبری NetEnrich و کنترل کننده حوادث در مرکز طوفان اینترنتی SANS ، می گوید: “ChaosDB یک مسیر سوء استفاده پیچیده تر دارد و فقط می تواند به تصرف حساب منجر شود.” “با [the OMIGOD vulnerability]از سوی دیگر ، تبدیل ماشین های قربانی به بات نت بسیار آسان بود ، جایی که بهره برداری در مقیاس بزرگ بسیار منطقی تر است. “
جزئیات مربوط به آسیب پذیری OMIGOD
یکی از محصولات مایکروسافت ماشین های مجازی لینوکس است که بر روی Azure cloud خود کار می کنند. برای مدیریت این ماشین های مجازی ، مایکروسافت یک ابزار مدیریت منبع باز به نام OMI نصب می کند که مخفف Open Management Infrastructure است.
محققان Wiz چهار آسیب پذیری مهم را در OMI کشف کردند ، که می تواند برای اجرای از راه دور کد در شبکه با یک درخواست واحد و افزایش امتیازات root استفاده شود.
مشتریانی که از هر یک از خدمات زیر استفاده می کنند آسیب پذیر هستند: Azure Automation ، Azure Automatic Update ، Azure Operations Suite ، Azure Log Analytics ، Azure Configuration Management ، Azure Diagnostics و Azure Container Insights.
اما OMI همچنین در مراکز داده محلی استفاده می شود هنگامی که شرکت ها از مرکز سیستم مایکروسافت برای لینوکس استفاده می کنند.
بامبنک به Data Center Knowledge گفت: “به احتمال زیاد نصب های پیش از نصب OMI در معرض اینترنت قرار می گیرد.” “اما تا آنجا که آنها انجام می دهند ، همان آسیب پذیری و سوء استفاده باید کار کند.”
به گفته Wiz ، بیش از 65 درصد از مشتریان Azure در معرض خطر هستند.
این بد است ، اما بدترین آن نیست.
بدترین حالت این است که OMI در ماشینهای مجازی مشتریان توسط مایکروسافت مستقر شده است ، اما اکثر مشتریان حتی نمی دانند که آنجا وجود دارد. به گفته نیر اوفلد ، محقق امنیتی Wiz ، هیچ اسناد واضحی در مورد استقرار ، نظارت و به روزرسانی OMI در مورد Azure وجود ندارد.
و از آنجا که OMI در دستگاه های مشتریان اجرا می شود ، مایکروسافت خود را مسئول آنچه در مورد آن اتفاق می افتد نمی داند. به طور معمول ، در زیرساخت های ابری ، “مدل مسئولیت مشترک” به این معنی است که ارائه دهنده ابر مسئول امنیت زیرساخت ها به طور کلی است و مشتری مسئول ایمن سازی آنچه در ماشین های مجازی خود اتفاق می افتد است.
مایکروسافت وصله ای منتشر کرده است ، اما به مشتریان بستگی دارد که سیستم های آسیب دیده را پیدا کرده و وصله را نصب کنند.
اوفلد نوشت: “هیچ راهی آسان برای مشتریان وجود ندارد که بدانند کدام ماشین مجازی آنها OMI را اجرا می کند زیرا Azure در هیچ کجای پورتال Azure به OMI اشاره نمی کند ، که این امر توانایی ارزیابی ریسک مشتریان را مختل می کند.” “این مسئله شکافی در مدل معروف مسئولیت مشترک نشان می دهد.”
Wiz یک لیست بازرسی و شناسایی OMIGOD برای کمک به شرکت ها در رسیدگی به این مشکل منتشر کرده است.
مایکروسافت همچنین راهنمای خود را برای کمک به مشتریان برای رسیدگی به آسیب پذیری OMIGOD منتشر کرده است.
متأسفانه ، قبل از اینکه هکرها از آسیب پذیری مطلع شوند ، همه یادداشت را دریافت نکرده اند یا وصله ها را نصب نکرده اند.
چندین شرکت امنیتی از جمله Bad Packers و GreyNoise تأیید کرده اند که مهاجمان در حال اسکن وب برای ماشین های مجازی Azure Linux آسیب پذیر هستند – از جمله اپراتور بات نت Mirai.
یوناتان آمیتای ، محقق امنیتی در شرکت امنیت سایبری Vulcan Cyber ، می گوید: “تیم های امنیتی فناوری به ارائه دهندگان ابر مانند Azure اعتماد می کنند تا یک سرویس امن ارائه دهند و در صورت بروز اشکال یا آسیب پذیری ، اقدامات فوری را برای کاهش خطر انجام دهند.” تقریباً در همه موارد ، ارائه دهندگان خدمات ابری که ما از آنها استفاده می کنیم آسیب پذیری های موجود در خدمات آنها را قبل از اینکه در مقیاس بزرگ مورد سوء استفاده قرار گیرند ، برطرف می کنند. “
در اینجا چنین نبوده است و کارشناسان امنیتی مانند Amitay می گویند که مایکروسافت در حال کنار گذاشتن توپ است.
آمیتای به Data Center Knowledge گفت: “به نظر شخصی من ، مایکروسافت باید مسئول رفع آن در صورت امکان باشد.” “یا حداقل ، ابزار تشخیص و وصله ای را منتشر کنید که مشتریان می توانند از آن برای انجام خودکار استفاده کنند.”
در عوض ، شرکت هایی که از ماشین های مجازی Microsoft Azure استفاده می کنند ، در حال حاضر مورد حمله بات نت Mirai قرار گرفته و مورد ربوده شدن قرار می گیرند تا از آنها برای استخراج ارزهای رمزنگاری شده استفاده کنند.
آمیتای گفت: “من فکر می کنم این آسیب پذیری به دلیل سهولت استفاده باورنکردنی از آن بیشتر قابل استفاده است.”
وی افزود ، در واقع ، مشکلات امنیتی آنقدر اساسی هستند که شبیه چیزی از دهه 1990 به نظر می رسند.
آرچی آگاروال ، م founderسس و مدیر عامل شرکت امنیت سایبری ThreatModeler ، می گوید: “هیچ شکی در ذهن من وجود ندارد که ارائه دهنده ابری که به دلیل فعال کردن سیستم ورود به سیستم یا مدیریت خدمات را نصب می کند ، مسئول امنیت آن است.”
او به Data Center Knowledge گفت که این واقعیت که سرویس OMI تقریباً ناشناخته بود و با امتیازات root کار می کرد ، بسیار نگران کننده است.
آگاروال گفت: “این امر به طور بالقوه باعث ایجاد یک حفره برای اجرای کد از راه دور شده است که به هیچ وجه تقصیر مشتریان Azure نیست.”
Bambenek از NetEnrich می گوید: “بیشترین افزایش امنیت سایبری در 20 سال گذشته زمانی بود که مایکروسافت به طور پیش فرض وصله ها را به طور خودکار اعمال کرد.” “در دنیای لینوکس نیز باید همینطور باشد.”
او همچنین افزود که مدیران امنیت سایبری مراکز داده می توانند اقدامات پیشگیرانه ای را در برابر آسیب پذیری های احتمالی مشابه انجام دهند.
بامبنک گفت: “هر سیستمی در هر پلتفرمی باید از مدیریت پیکربندی خودکار استفاده کند تا اطمینان حاصل شود که تنها بسته های مجاز نصب شده اند ، پیکربندی ها مدیریت می شوند و سیستم ها به طور مناسب قفل شده اند.”
نرم افزار مدیریت ناامن: فقط لاجورد نیست
آمیتای گفت ، همان مسئله ای که در قلب آسیب پذیری OMIGOD قرار دارد – نرم افزار مدیریت ناامن که بر روی ماشین های مشتری اجرا می شود و برای آن مشتریان ناشناخته است – احتمالاً با سایر ارائه دهندگان ابر ظاهر می شود.
او گفت: “من فکر نمی کنم این موضوع مایکروسافت باشد.” “سایر ارائه دهندگان ابر نیز دارای اجزای آسیب پذیر بودند.”
آمیتای گفت ، برای محافظت از خود ، مدیران امنیت سایبری مرکز داده باید در بالای گزارشات رسانه ها و اطلاعات تهدید قرار بگیرند و در صورت بروز آسیب پذیری ها را اولویت بندی و برطرف کنند.
وی افزود: “همچنین از بهترین شیوه های امنیتی استفاده کنید.” معماری امنیتی همیشه به کاهش تاثیر قرار گرفتن در معرض آسیب پذیری های ناشناخته کمک می کند. “
تایلر شیلدز ، مدیر ارشد بازاریابی در JupiterOne و عضو هیئت مدیره یا مشاور هیئت مدیره چندین شرکت امنیت سایبری می گوید: “چیزی که تقریباً می توانم به شما اطمینان دهم این است که مردم در آینده به دنبال همه ارائه دهندگان این نوع مسائل خواهند بود.” “این مورد برای همه ارائه دهندگان خدمات ابری مورد بررسی قرار می گیرد – هم توسط افراد خوب و هم بد.”
او افزود اگرچه ارائه دهندگان خدمات ابری باید مسئول رفع مشکلاتی از این قبیل باشند ، اما باید وضعیتی با بررسی ها و موازنه های متعدد باشد. شیلدز به Data Center Knowledge گفت: “در نهایت ، شرکت مسئول امنیت کد در حال اجرا در محفظه خود است.”
الیور توکلی ، مدیر ارشد فناوری Vectra ، یک شرکت امنیت سایبری ، می گوید OMIGOD ثابت می کند که برون سپاری مدیریت وصله به ارائه دهنده خدمات ابری بی عیب نیست.
او می گوید: “لایحه موادی که در نتیجه چند کلیک ماوس به یک تصویر نرم افزاری ختم می شود ، تضمین نمی شود.” “این مورد – بیشتر – اعتماد اما – قطعاً – تأیید است.”
خطاهای پیکربندی
آمیتای گفت ، در پایان روز ، این آسیب پذیری های خود ارائه دهندگان ابر نیست که بیشترین مشکل را دارند.
ممکن است بدتر به نظر برسند زیرا خارج از کنترل شرکت هستند. اما تهدید واقعی در خطاهای پیکربندی شماست.
او گفت: “ارائه دهندگانی مانند AWS و Azure به شدت در مورد بهداشت سایبری محصولات خود فعال هستند.” “خطر واقعی در امنیت ابر ناشی از این واقعیت است که 95 درصد از همه نقض های امنیتی ابر به دلیل خطای کاربر و پیکربندی نادرست کاربران سرویس ابری است.”