آخرین اخبار
همهٔ اخبار
مدیریت آسیب‌پذیری گزارش بحرانیت ۳/۱۰

کشف آسیب‌پذیری بحرانی در سرویس Titan مایکروسافت؛ دسترسی احتمالی به ۱۷ تریلیون رکورد

کشف آسیب‌پذیری بحرانی در سرویس Titan مایکروسافت؛ دسترسی احتمالی به ۱۷ تریلیون رکورد

یک پژوهشگر ۱۶ ساله با نام مستعار Faav، یک نقص امنیتی در مکانیزم احراز هویت سرویس تحلیل داخلی مایکروسافت (Titan Analytics) کشف کرد که به طور بالقوه دسترسی به حدود ۱۷.۳ تریلیون ردیف از داده‌های پایگاه داده را فراهم می‌کرد.

جزئیات فنی آسیب‌پذیری

این آسیب‌پذیری به مهاجم اجازه می‌داد تا بدون داشتن اعتبارنامه‌های معتبر مایکروسافت، دسترسی‌های مدیریتی (Administrator) را جعل کرده و کوئری‌های SQL غیرمجاز اجرا کند. این نقص در نحوه پردازش JSON Web Token (JWT) ریشه داشت. سرویس Titan مقادیر موجود در Claims توکن را بررسی می‌کرد، اما امضای دیجیتال (Signature) توکن را به صورت رمزنگاری‌شده تأیید نمی‌کرد.

پژوهشگر با ایجاد یک توکن مصنوعی و تنظیم الگوریتم آن بر روی none و خالی گذاشتن بخش امضا، توانست سیستم را فریب دهد. با جایگزینی مقدار فیلد upn با عبارت admin، سیستم کاربر را به عنوان کاربر محلی شماره ۱ شناسایی کرده و نقش Admin را به او اختصاص داد که منجر به اجرای موفقیت‌آمیز کوئری‌های SELECT شد.

دامنه اثرگذاری و دسترسی‌ها

در جریان بررسی‌های کنترل‌شده، دسترسی به موارد زیر شناسایی شد:

  • حدود ۲۵,۰۰۰ رکورد حساب کاربری و ایمیل.
  • بیش از ۱۷,۰۰۰ رکورد ایمیل کارکنان.
  • تنظیمات ۳۵۵ پایگاه داده و بیش از ۲۰,۰۰۰ تعریف SQL برای مجموعه‌های داده مجازی.
  • دسترسی به تحلیل‌های جستجوی Bing.

تخمین ۱۷.۳ تریلیون رکورد از طریق بررسی ۵۶ مقدار مسیریابی (Routing Value) و تحلیل پایگاه‌های داده ClickHouse به دست آمده است. با این حال، پژوهشگر تأکید کرده که این عدد شامل داده‌های تکراری و تاریخی است و به معنای افشای اطلاعات ۱۷ تریلیون شخص مجزا نیست.

پاسخ مایکروسافت و درس‌های امنیتی

پس از گزارش این آسیب‌پذیری به مرکز پاسخگویی امنیتی مایکروسافت (MSRC)، این شرکت در تاریخ ۹ سپتامبر نقطه اتصال (API Endpoint) مربوطه را مسدود کرد و مبلغ ۵,۰۰۰ دلار پاداش (Bounty) به پژوهشگر پرداخت نمود.

این حادثه نشان می‌دهد که تأیید Claims به تنهایی برای امنیت احراز هویت مبتنی بر JWT کافی نیست. برنامه‌ها باید:

  • هر توکن را از نظر امضای رمزنگاری‌شده تأیید کنند.
  • توکن‌های بدون امضا (Unsigned) را رد کنند.
  • الگوریتم‌های مجاز را محدود کرده و مقادیر Issuer و Audience را اعتبارسنجی کنند.
  • از نگاشت مستقیم Claims تحت کنترل مهاجم به حساب‌های محلی دارای سطح دسترسی بالا اجتناب کنند.