آسیب‌پذیری‌های زنجیره‌ای در Azure: دستیابی به دسترسی بین‌مشتری با سوءاستفاده از API Connections — Azure's Weakest Link – Five Full Cross-Tenant Compromises
خلاصه
یک پژوهشگر امنیت با سوءاستفاده از ضعف‌های معماری در بخش API Connections مربوط به Azure Logic Apps توانست به اطلاعات حساس سرویس‌های مختلف دسترسی پیدا کند. این آسیب‌پذیری‌ها که در مجموع جایزه ۲۰۰ هزار دلاری به همراه داشتند، اهمیت اعتبارسنجی ورودی‌ها در سیستم‌های ابری بزرگ را نشان می‌دهند.
مقدمه و زمینه
سیستم‌های ابری بزرگ مانند Microsoft Azure از اجزای پیچیده‌ای تشکیل شده‌اند که یکپارچه‌سازی سرویس‌ها را تسهیل می‌کنند. یکی از این اجزا، Azure Logic Apps و زیربخش آن یعنی API Connections است. این بخش به توسعه‌دهندگان اجازه می‌دهد تا اپلیکیشن‌های خود را به سرویس‌های خارجی و داخلی مانند Key Vault، پایگاه‌های داده Azure SQL، و حتی ابزارهای شخص ثالث مثل Salesforce متصل کنند. معماری این سیستم بر پایه یک لایه مشترک به نام API Management (APIM) و ارتباط با Azure Resource Manager (ARM) استوار است.
جزئیات فنی آسیب‌پذیری‌ها
پژوهشگر امنیت با بررسی این معماری متوجه شد که با استفاده از نقاط پایانی خاص در ARM REST API (مانند DynamicInvoke)، می‌توان درخواست‌هایی را ارسال کرد که به جای اتصال متعلق به کاربر، به اتصال‌های دیگران اشاره کنند. این نقص در واقع یک آسیب‌پذیری کلاسیک Path Traversal بود:
- درخواست‌های ارسالی از ARM به APIM بدون تفکیک دقیق مالکیت به تمامی کانکشن‌ها دسترسی داشتند.
- با استفاده از کاراکترهای مسیردهی مانند
..در URL، امکان خواندن اطلاعات محرمانه‌ای مثل کلیدهای موجود در Key Vault دیگران فراهم شد.
پس از اینکه مایکروسافت این مسیر را مسدود کرد، پژوهشگر با استخراج کدهای مربوطه از طریق یک Standard Logic App اختصاصی، توابع مستندنشده دیگری مانند DynamicList را کشف کرد که دقیقاً همان منطق آسیب‌پذیر را داشتند و اجازه اجرای پرس‌وجوهای مخرب روی پایگاه‌های داده قربانی را می‌دادند.
بهره‌برداری از Logic Apps مصرفی (Consumption)
مرحله بعدی تحقیق روی تفاوت میان Consumption Logic Apps و Standard Logic Apps تمرکز داشت. اپلیکیشن‌های نوع Consumption از کانکشن‌های نسخه ۱ استفاده می‌کنند که هویت مدیریتی اختصاصی ندارند. با بررسی دقیق بخش کدنویسی در این اپلیکیشن‌ها، پارامتر پنهانی به نام host.api.RuntimeUrl کشف شد.
با دستکاری این پارامتر، سیستم فریب می‌خورد تا از یک URL زمان اجرای جایگزین استفاده کند؛ مادامی که دامنه نهایی به azure-apihub.net ختم می‌شد، هدرهای احراز هویت معتبر به درخواست تزریق می‌شدند و دسترسی غیرمجاز به کانکشن‌های دیگر تننت‌ها شکل می‌گرفت.
چرا این مسئله برای مهندسان مهم است؟
این رشته از آسیب‌پذیری‌ها که در نهایت به دریافت پاداش قابل‌توجه ۲۰۰ هزار دلاری منجر شد، چند درس کلیدی برای طراحان سیستم‌های توزیع‌شده و ابری دارد:
- خطرات اعتبارسنجی دستی: متکی بودن صرف به لیست سیاه (Blacklisting) برای مسدود کردن مسیرها یا پارامترها معمولاً ناکافی است، زیرا مهاجمان می‌توانند نقاط پایانی مستندنشده یا راه‌های جایگزین پیدا کنند.
- ایزوله‌سازی در سیستم‌های ابری چندمشتری (Multi-Tenant): اطمینان از اینکه توکن‌ها و دسترسی‌های پشت صحنه به شدت به مالک واقعی خود محدود شده‌اند، حیاتی است.
- کدهای ارث‌بری شده: حضور کدهای داخلی سیستم در برخی منابع، گاهی به عنوان یک نقشه راه برای مهندسان معکوس عمل می‌کند و سطوح حمله جدیدی را نمایان می‌سازد.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل