🥇ممیزی امنیتی پلتفرم ابری MCS

غروب آسمان کشتی توسط SeerLight

ساختن هر سرویسی لزوماً شامل کار مداوم روی امنیت است. امنیت یک فرآیند مداوم است که شامل تجزیه و تحلیل مستمر و بهبود امنیت محصول، نظارت بر اخبار مربوط به آسیب‌پذیری‌ها و موارد دیگر است. از جمله ممیزی. ممیزی ها هم در داخل و هم توسط کارشناسان خارجی انجام می شود، که می توانند به طور چشمگیری به امنیت کمک کنند، زیرا آنها در پروژه غوطه ور نیستند و ذهن باز دارند.

این مقاله در مورد این دیدگاه بسیار فیلتر نشده از کارشناسان خارجی است که به تیم Mail.ru Cloud Solutions (MCS) برای آزمایش سرویس ابری کمک کردند، و در مورد آنچه که آنها پیدا کردند. به عنوان "نیروهای خارجی" MCS امنیت دیجیتال را انتخاب کرد که به دلیل تخصص بالای خود در محافل امنیت اطلاعات شناخته شده است. و در این مقاله، ما برخی از آسیب‌پذیری‌های جالبی را که به عنوان بخشی از یک ممیزی خارجی یافت می‌شوند، تجزیه و تحلیل می‌کنیم - به طوری که هنگام ایجاد سرویس ابری خود، همان رنک را دور می‌زنید.

продукта Описание

Mail.ru Cloud Solutions (MCS) بستری برای ساخت زیرساخت های مجازی در فضای ابری است. این شامل IaaS، PaaS، بازاری از تصاویر برنامه های آماده برای توسعه دهندگان است. با توجه به معماری MCS، لازم بود امنیت محصول در زمینه های زیر بررسی شود:

حفاظت از زیرساخت های محیط مجازی سازی: هایپروایزر، مسیریابی، فایروال ها.
حفاظت از زیرساخت مجازی مشتریان: جداسازی از یکدیگر، از جمله شبکه، شبکه های خصوصی در SDN.
OpenStack و اجزای باز آن؛
S3 طراحی خودمان؛
IAM: پروژه های چند مستاجر با الگوی نقش.
Vision (دید ماشین): API و آسیب پذیری ها هنگام کار با تصاویر.
رابط وب و حملات وب کلاسیک؛
آسیب پذیری های مؤلفه PaaS؛
API همه اجزا.

شاید، از ضروری برای تاریخ بیشتر - همه چیز.

چه نوع کاری انجام شد و چرا نیاز است؟

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

در طول کار، که به طور متوسط 1-2 ماه طول می کشد، حسابرسان اقدامات مهاجمان احتمالی را تکرار می کنند و به دنبال آسیب پذیری در بخش های مشتری و سرور سرویس انتخاب شده می گردند. در زمینه ممیزی پلت فرم ابری MCS، اهداف زیر شناسایی شد:

تجزیه و تحلیل احراز هویت در سرویس. آسیب‌پذیری‌های موجود در این مؤلفه به ورود سریع به حساب‌های افراد دیگر کمک می‌کند.
بررسی الگوی نقش و کنترل دسترسی بین حساب‌های مختلف. برای یک مهاجم، توانایی دسترسی به ماشین مجازی شخص دیگری یک هدف مطلوب است.
آسیب پذیری های سمت مشتری XSS / CSRF / CRLF / و غیره شاید امکان حمله به سایر کاربران از طریق لینک های مخرب وجود داشته باشد؟
آسیب پذیری های سمت سرور: RCE و انواع تزریق ها (SQL/XXE/SSRF و غیره). آسیب‌پذیری‌های سرور معمولاً سخت‌تر یافت می‌شوند، اما منجر به به خطر افتادن بسیاری از کاربران در یک زمان می‌شوند.
تجزیه و تحلیل جداسازی بخش های کاربر در سطح شبکه. برای یک مهاجم، فقدان انزوا سطح حمله را برای سایر کاربران بسیار افزایش می دهد.
تحلیل منطق کسب و کار آیا می توان یک کسب و کار را فریب داد و ماشین های مجازی را به صورت رایگان ایجاد کرد؟

در این پروژه، کار بر اساس مدل "جعبه خاکستری" انجام شد: حسابرسان با امتیازات کاربران عادی با سرویس تعامل داشتند، اما تا حدی متون منبع API را در اختیار داشتند و این فرصت را داشتند که جزئیات را با توسعه دهندگان روشن کنند. . این معمولاً راحت‌ترین و در عین حال کاملاً واقع‌بینانه‌ترین مدل کار است: اطلاعات داخلی هنوز می‌تواند توسط مهاجم جمع‌آوری شود، فقط مسئله زمان است.

آسیب پذیری پیدا کرد

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

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

IDOR

آسیب‌پذیری‌های IDOR (مرجع مستقیم اشیاء ناامن، ارجاع مستقیم ناامن به اشیا) یکی از رایج‌ترین انواع آسیب‌پذیری‌ها در منطق تجاری هستند که به هر طریقی به اشیایی که واقعاً مجاز به دسترسی نیستند، دسترسی پیدا می‌کنند. آسیب پذیری های IDOR امکان به دست آوردن اطلاعات در مورد کاربر با درجات مختلف بحرانی را ایجاد می کند.

یکی از گزینه های IDOR انجام اقدامات با اشیاء سیستم (کاربران، حساب های بانکی، کالاهای موجود در سبد) با دستکاری شناسه های دسترسی برای این اشیاء است. این منجر به غیر قابل پیش بینی ترین عواقب می شود. به عنوان مثال، به امکان جایگزینی حساب ارسال کننده وجوه، که به دلیل آن می توانید آنها را از سایر کاربران سرقت کنید.

در مورد MCS، حسابرسان به تازگی یک آسیب پذیری IDOR مرتبط با شناسه های غیر ایمن را کشف کردند. در حساب شخصی کاربر، از UUID ها برای دسترسی به هر شی استفاده می شد، که به گفته کارشناسان امنیتی، به طور قابل توجهی غیر وحشیانه به نظر می رسید (یعنی محافظت از یک حمله brute-force). اما برای نهادهای خاص مشخص شد که از اعداد قابل پیش بینی معمولی برای به دست آوردن اطلاعات در مورد کاربران برنامه استفاده می شود. فکر می‌کنم می‌توانید حدس بزنید که می‌توان شناسه کاربر را یک‌بار تغییر داد، دوباره درخواست را ارسال کرد و بنابراین اطلاعات را با دور زدن ACL (لیست کنترل دسترسی، قوانین دسترسی به داده‌ها برای فرآیندها و کاربران) به دست آورد.

جعل درخواست سمت سرور (SSRF)

خوبی در مورد محصولات OpenSource این است که تعداد زیادی انجمن با توضیحات فنی دقیق از مشکلات پیش آمده و اگر خوش شانس باشید، با توضیح راه حل است. اما این مدال یک جنبه منفی دارد: آسیب پذیری های شناخته شده نیز به تفصیل بیان شده است. به عنوان مثال، انجمن OpenStack توضیحات بسیار خوبی از آسیب پذیری ها دارد [xss] и [SSRF]که بنا به دلایلی هیچکس عجله ای برای رفع آن ندارد.

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

آسیب‌پذیری‌های SSRF می‌توانند تا حد زیادی توسعه یک حمله را پیش ببرند. یک مهاجم می تواند دریافت کند:

دسترسی محدود به شبکه محلی مورد حمله، به عنوان مثال، فقط از طریق بخش های شبکه خاص و طبق یک پروتکل خاص.
دسترسی کامل به شبکه محلی، در صورت امکان کاهش از لایه برنامه به لایه انتقال و در نتیجه مدیریت بار کامل در لایه برنامه؛
خواندن دسترسی به فایل های محلی روی سرور (در صورت پشتیبانی از طرح file:///)؛
و خیلی بیشتر

OpenStack مدتهاست که آسیب پذیری SSRF را می شناسد که ماهیت آن "کور" است: وقتی به سرور دسترسی پیدا می کنید، پاسخی از آن دریافت نمی کنید، اما بسته به نتیجه درخواست، انواع مختلفی از خطاها / تاخیرها را دریافت می کنید. بر این اساس، امکان انجام اسکن پورت بر روی هاست های موجود در شبکه داخلی، با تمام عواقب ناشی از آن وجود دارد که نباید دست کم گرفت. به عنوان مثال، یک محصول ممکن است یک API پشتیبان داشته باشد که فقط از طریق شبکه شرکت قابل دسترسی است. با مستندسازی (در مورد اینسایدرها فراموش نکنید)، مهاجم می تواند از SSRF برای دسترسی به روش های داخلی استفاده کند. به عنوان مثال، اگر توانستید به نحوی فهرست تقریبی از URLهای مفید را دریافت کنید، با کمک SSRF می توانید آنها را مرور کرده و درخواستی را اجرا کنید - به طور نسبی، پول را از حسابی به حساب دیگر منتقل کنید یا محدودیت ها را تغییر دهید.

این اولین بار نیست که یک آسیب‌پذیری SSRF در OpenStack کشف می‌شود. در گذشته امکان دانلود تصاویر ISO ماشین های مجازی از لینک مستقیم وجود داشت که همین امر نیز منجر به عواقب مشابهی می شد. این ویژگی در حال حاضر از OpenStack حذف شده است. ظاهراً جامعه این را ساده ترین و مطمئن ترین راه حل برای مشکل می دانست.

و در این در یک گزارش در دسترس عموم از HackerOne (h1)، اجرای یک SSRF دیگر کور با توانایی خواندن ابرداده‌های نمونه منجر به دسترسی Root به کل زیرساخت Shopify می‌شود.

در MCS، آسیب‌پذیری‌های SSRF در دو مکان با عملکرد مشابه یافت شدند، اما به دلیل فایروال‌ها و سایر حفاظت‌ها، استفاده از آنها تقریبا غیرممکن بود. به هر حال، تیم MCS این مشکل را به هر حال، بدون اینکه منتظر جامعه باشد، برطرف کرد.

XSS به جای بارگیری "شل"

علیرغم صدها مطالعه مکتوب، سال به سال XSS (حمله اسکریپت بین سایتی) هنوز بیشترین میزان را دارد. مشترک آسیب پذیری وب (یا حمله کردن؟).

آپلود فایل مکان مورد علاقه هر محقق امنیتی است. اغلب معلوم می شود که می توانید یک اسکریپت دلخواه (asp / jsp / php) بارگیری کنید و دستورات سیستم عامل را در اصطلاح pentesters - "load a shell" اجرا کنید. اما محبوبیت چنین آسیب‌پذیری‌هایی در هر دو جهت کار می‌کند: آنها به خاطر سپرده می‌شوند و راه‌حل‌هایی علیه آنها در حال توسعه است، بنابراین اخیراً احتمال "بارگیری پوسته" به صفر می‌رسد.

تیم مهاجم (با نمایندگی امنیت دیجیتال) خوش شانس بود. خوب، در MCS سمت سرور، محتویات فایل های آپلود شده بررسی شد، فقط تصاویر مجاز بودند. اما SVG نیز یک تصویر است. و چگونه تصاویر SVG می توانند خطرناک باشند؟ این واقعیت که شما می توانید قطعه های جاوا اسکریپت را در آنها جاسازی کنید!

مشخص شد که فایل های دانلود شده برای همه کاربران سرویس MCS در دسترس است، به این معنی که سایر کاربران ابر، یعنی مدیران، می توانند مورد حمله قرار گیرند.

فرم ورود فیشینگ مثال حمله XSS

نمونه هایی از بهره برداری حمله XSS:

اگر اسکریپت بارگیری شده می تواند فوراً به API منبع دسترسی پیدا کند، چرا سعی کنید یک جلسه را بدزدید (مخصوصاً از آنجایی که اکنون کوکی های فقط HTTP همه جا هستند و با استفاده از اسکریپت های js از سرقت محافظت می شوند؟ در این حالت، payload می‌تواند پیکربندی سرور را از طریق درخواست‌های XHR تغییر دهد، به عنوان مثال، کلید عمومی SSH مهاجم را اضافه کند و به سرور دسترسی SSH پیدا کند.
اگر خط مشی CSP (سیاست حفاظت محتوا) تزریق جاوا اسکریپت را ممنوع کند، مهاجم می تواند بدون آن کار کند. در HTML خالص، یک فرم ورود جعلی ایجاد کنید و رمز عبور مدیر را از طریق چنین فیشینگ پیشرفته بدزدید: صفحه فیشینگ برای کاربر در همان URL است و تشخیص آن برای کاربر دشوارتر است.
در نهایت، یک مهاجم می تواند ترتیب دهد سرویس گیرنده DoS - کوکی های بزرگتر از 4 کیلوبایت را تنظیم کنید. کافی است کاربر یک بار پیوند را باز کند - و تا زمانی که به فکر تمیز کردن عمدی مرورگر نباشید، کل سایت از دسترس خارج می شود: در اکثریت قریب به اتفاق موارد، سرور وب از پذیرش چنین مشتری خودداری می کند.

بیایید به نمونه ای از XSS دیگری که این بار با بهره برداری ظریف تر در معرض دید قرار گرفت نگاه کنیم. سرویس MCS به شما امکان می دهد تنظیمات فایروال را در گروه ها ترکیب کنید. نام گروه حاوی XSS کشف شده بود. ویژگی آن این بود که بردار بلافاصله کار نمی کرد، نه هنگام مشاهده لیست قوانین، بلکه هنگام حذف یک گروه:

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

برای توسعه دهندگان MCS برای محافظت در برابر XSS در تصاویر SVG آپلود شده (اگر نمی توان آنها را انصراف داد)، تیم امنیت دیجیتال توصیه کرد:

میزبان فایل های آپلود شده توسط کاربران در یک دامنه جداگانه است که هیچ ارتباطی با "کوکی ها" ندارد. اسکریپت در زمینه یک دامنه دیگر اجرا می شود و تهدیدی برای MCS نخواهد بود.
هدر "Content-disposition: attachment" را در پاسخ HTTP سرور ارسال کنید. سپس فایل ها توسط مرورگر دانلود می شوند و اجرا نمی شوند.

علاوه بر این، اکنون راه‌های زیادی برای توسعه‌دهندگان برای کاهش خطرات بهره‌برداری XSS وجود دارد:

با استفاده از پرچم «فقط HTTP»، می‌توانید سرصفحه‌های جلسه «کوکی‌ها» را برای جاوا اسکریپت مخرب غیرقابل دسترس کنید.
سیاست CSP به درستی اجرا شود به طور قابل توجهی بهره برداری از XSS را برای یک مهاجم پیچیده می کند.
موتورهای قالب سازی مدرن مانند Angular یا React به طور خودکار داده های کاربر را قبل از ارائه به مرورگر کاربر پاک می کنند.

آسیب پذیری در احراز هویت دو مرحله ای

برای افزایش امنیت حساب ها، همیشه به کاربران توصیه می شود که 2FA (احراز هویت دو مرحله ای) را فعال کنند. در واقع، این یک راه موثر برای جلوگیری از دسترسی مهاجم به یک سرویس در صورت به خطر افتادن اعتبار کاربر است.

اما آیا استفاده از فاکتور دوم احراز هویت همیشه امنیت حساب را تضمین می کند؟ در اجرای 2FA، چنین مشکلات امنیتی وجود دارد:

شمارش تقریبی کد OTP (کدهای یکبار مصرف). با وجود سهولت استفاده، خطاهایی مانند عدم محافظت در برابر OTP brute در شرکت های بزرگ رخ می دهد: کیس شل, کیس فیس بوک.
الگوریتم تولید ضعیف، مانند توانایی پیش‌بینی کد بعدی.
خطاهای منطقی، مانند اینکه بتوانید OTP شخص دیگری را در تلفن خود درخواست کنید، مانند این بود از Shopify.

در مورد MCS، 2FA بر اساس Google Authenticator و پیاده سازی شده است اواز یا موسیقی دو نفری. خود پروتکل قبلاً توسط زمان آزمایش شده است ، اما اجرای تأیید کد در سمت برنامه ارزش بررسی دارد.

در MCS، 2FA در چندین مکان استفاده می شود:

هنگام احراز هویت یک کاربر در اینجا محافظت brute-force وجود دارد: کاربر فقط چند بار تلاش می کند تا رمز عبور یک بار مصرف را وارد کند، سپس ورودی برای مدتی مسدود می شود. این کار توانایی اعمال فشار بی رحمانه OTP را مسدود می کند.
هنگام تولید کدهای پشتیبان آفلاین برای انجام 2FA و همچنین غیرفعال کردن آن. در اینجا محافظت brute force اجرا نشد، که این امکان را فراهم کرد، در صورت وجود رمز عبور برای حساب و یک جلسه معتبر، کدهای پشتیبان را دوباره تولید کنید یا 2FA را به طور کلی غیرفعال کنید.

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

فرآیند انتخاب OTP برای غیرفعال کردن 2FA با استفاده از ابزار "Burp: Intruder"

نتیجه

به طور کلی، MCS به عنوان یک محصول ایمن به نظر می رسد. در طول ممیزی، تیم پنتستر نتوانست به ماشین‌های مجازی مشتری و داده‌های آن‌ها دسترسی پیدا کند و آسیب‌پذیری‌های یافت شده به سرعت توسط تیم MCS برطرف شد.

اما در اینجا ذکر این نکته ضروری است که امنیت یک کار مستمر است. خدمات ثابت نیستند، آنها دائما در حال تکامل هستند. و توسعه یک محصول به طور کامل بدون آسیب پذیری غیرممکن است. اما می توانید به موقع آنها را پیدا کنید و احتمال تکرار آنها را به حداقل برسانید.

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

انجام ممیزی های منظم توسط شرکت های خارجی؛
حمایت و توسعه مشارکت در برنامه Bug Bounty گروه Mail.ru;
با امنیت برخورد کنید 🙂

منبع: www.habr.com

ممیزی امنیتی پلتفرم ابری MCS