نقص امنیتی Titan مایکروسافت؛ نوجوان ۱۶ ساله چگونه با هک‌بات AI ادمین شد؟

یک پژوهشگر امنیتی ۱۶ ساله با نام مستعار Faav توانست با سوءاستفاده از یک نقص ساده در احراز هویت، به‌عنوان «ادمین» وارد سرویس تحلیلی داخلی مایکروسافت به نام Titan شود، کوئری‌های SQL بدون مجوز اجرا کند و به‌صورت بالقوه به پایگاه‌داده‌هایی با برآورد حدود ۱۷.۳ تریلیون ردیف داده دسترسی پیدا کند. نکتهٔ جالب ماجرا این است که او این کار را با کمک یک «هک‌بات» هوش مصنوعی به نام Antares انجام داد که خودش ساخته بود. مایکروسافت پس از گزارش، نقص را برطرف کرد و به او ۵٬۰۰۰ دلار جایزهٔ باگ‌بانتی داد.

Titan چیست و چرا مهم است؟

Titan یک پلتفرم تحلیلی داخلی مایکروسافت است. رابط وبِ آن پشت یک صفحهٔ «VPN REQUIRED» قرار دارد و دسترسی به آن فقط برای کارکنان مایکروسافت باز است. یعنی اگر یک کاربر بیرونی سراغ رابط کاربری Titan برود، در همان درِ ورودی متوقف می‌شود.

اما نکتهٔ کلیدی اینجاست که درِ جلویی قفل بود، نه درِ پشتی. Faav توضیح می‌دهد که API مربوط به Titan جایی در فرانت‌اند لینک نشده بود، اما Antares با جست‌وجو در زیردامنه‌های مایکروسافت یک endpoint جداگانه پیدا کرد که به یک میزبان روی Azure Cloud Services اشاره می‌کرد. فایل Swagger عمومیِ این endpoint چهار مسیر را فهرست کرده بود که یکی از آن‌ها، یعنی /v2/Query، کوئری خام SQL را می‌پذیرفت و دقیقاً همان‌جایی بود که کار از آن شروع شد.

این نقص امنیتی دقیقاً چه بود؟

برای درک ماجرا اول باید بدانیم JWT چیست. JWT (مخفف JSON Web Token) یک «بلیت ورود» دیجیتال است؛ یک رشتهٔ متنی که سرویس برای تشخیص هویت کاربر از آن استفاده می‌کند. هر JWT سه بخش دارد که با نقطه از هم جدا می‌شوند: header.payload.signature.

• header می‌گوید توکن از چه نوعی است و با چه الگوریتمی امضا شده.

• payload محتوای ادعاها را نگه می‌دارد؛ مثلاً چه کسی هستید، متعلق به کدام سازمان‌اید و چه نقشی دارید.

• signature یک مُهر رمزنگاری‌شده است که ثابت می‌کند محتوای توکن واقعی است و کسی وسط راه آن را دستکاری نکرده.

کل امنیت JWT به همین بخش سوم، یعنی امضا، بند است. سرویس باید امضا را بررسی کند تا مطمئن شود توکن واقعاً از سمت یک منبع معتبر صادر شده. اگر سرویس فقط محتوای payload را بخواند و امضا را چک نکند، هر کسی می‌تواند هر محتوایی را داخل توکن بنویسد.

و دقیقاً همین اتفاق در Titan افتاده بود. Titan محتوای توکن را اعتبارسنجی می‌کرد — یعنی سازمان (tenant)، مخاطب (audience)، شناسهٔ اپلیکیشن (app ID) و کاربر را چک می‌کرد — اما هیچ‌وقت امضای توکن را بررسی نمی‌کرد؛ همان مهم‌ترین بخش احراز هویت. خود Faav این وضعیت را با یک تشبیه عالی توصیف می‌کند: مثل هتلی که هر در یک کارت‌خوان سالم دارد، اما هر کارت‌کلیدی هر اتاقی را باز می‌کند. تمام منطق کنترل دسترسی وجود داشت، اما یک قطعهٔ گمشده همه را بی‌اثر می‌کرد.

Faav در نهایت یک JWT مصنوعی ساخت که header آن این بود:

• {"alg":"none","typ":"JWT"}

یعنی توکنی که صراحتاً می‌گفت «الگوریتم امضا: هیچ». بخش سوم (امضا) هم خالی بود و توکن با یک نقطهٔ تنها تمام می‌شد. Titan این توکن بی‌امضا را هم پذیرفت.

چرا تغییر upn به admin کار کرد؟

اینجاست که هوش انسانی وارد ماجرا می‌شود. فیلد upn (مخفف User Principal Name) معمولاً یک شناسهٔ ایمیل‌مانند در Entra است. به همین دلیل Antares مدام مقادیری شبیه ایمیل را امتحان می‌کرد — ایمیل‌های آزمایشی، نام‌های مستعار سرویس‌ها و آدرس‌های کارمند‌مانند — اما Titan هیچ‌کدام را نمی‌شناخت و پیام User not found برمی‌گرداند.

Faav می‌گوید بعد از آن‌که از حدس زدن دست کشید و به این فکر کرد که بک‌اند واقعاً با این فیلد چه می‌کند، یک فرضیهٔ ساده به ذهنش رسید: شاید سرویس از upn برای یافتن یک «نام کاربری محلی» استفاده می‌کند. پس مقدار آن را به admin تغییر داد. Titan آن را به کاربر محلی با شناسهٔ ۱ تطبیق داد که نقش ادمین داشت و SQL اجرا شد. به قول خودش، گاهی جواب واقعاً همان admin است.

هوش مصنوعی Antares چه نقشی داشت؟

Antares هک‌بات شخصی Faav است؛ ابزاری که او خودش برای خودکارسازی فرایند شکار باگ ساخته. طبق نوشتهٔ Faav، Antares در پشت صحنه از مدل‌های Codex و Claude روی این سرنخ استفاده می‌کرد.

کاری که Antares انجام داد چشمگیر است: حدود ده روز کار را به‌تنهایی پیش برد — شمارش زیردامنه‌ها، عبور از پیام‌های خطای JWT یک فیلد در یک فیلد، نقشه‌برداری از کل سطح حمله و عبور دادن توکن بی‌امضا از چهار لایهٔ اعتبارسنجی. اما کاری که نتوانست انجام دهد این بود که بفهمد upn در عمل یک UPN واقعی نیست. چون admin یک UPN معتبر به نظر نمی‌رسد، هیچ‌وقت آن را امتحان نکرد.

این شاید مهم‌ترین درس انسانیِ کل ماجرا باشد: ترکیب پشتکار ماشین و شهود انسان. Antares کار تکراری و خسته‌کنندهٔ ده‌روزه را انجام داد، اما جرقهٔ نهایی از یک انسان آمد که حاضر شد نام فیلد را دیگر سرراست نگیرد. به بیان خود Faav، نه Antares به‌تنهایی به این‌جا می‌رسید و نه خودش.

چه داده‌هایی در معرض خطر بود؟

پس از دستیابی به نقش ادمین، Faav به پایگاه‌دادهٔ متادیتای Titan رسید و از آن‌جا می‌توانست مستقیماً جدول‌های اپلیکیشن را کوئری بزند. در این متادیتا این موارد یافت شد:

• حدود ۲۵٬۰۰۰ رکورد حساب و ایمیل

• ۱۷٬۹۹۰ رکورد ایمیل کارکنان

• ۱۵٬۰۰۱ رکورد سازمانی کارکنان

• ۳۵۵ پیکربندی پایگاه‌داده

• ۲۰٬۹۷۹ تعریف SQL از نوع virtual-dataset

• ۲۴٬۵۶۹ داشبورد، ۴۲۵٬۸۹۱ چارت و ۲۷٬۳۴۷ تعریف dataset

دایرکتوری کاربران Titan، عنوان‌های شغلی، دپارتمان‌ها و سلسله‌مراتب مدیریتی بخشی از کارکنان را افشا می‌کرد — داده‌ای که می‌توانست برای حملات مهندسی اجتماعی (Social Engineering) هدفمند مفید باشد، هرچند Faav تأکید می‌کند که هرگز این را آزمایش یا اثبات نکرد. او همچنین اشاره می‌کند که فیلد رمز عبور در این رکوردها فقط یک هش جایگزین از مدل کاربر محلی Superset بود، نه یک گذرواژهٔ واقعی مایکروسافت.

سپس او به یک منبع جداگانه برخورد: داده‌های تحلیلی Bing. برای تأیید، فقط دو ردیف را به‌صورت تک‌ردیفی تست کرد. این ردیف‌ها شامل اطلاعات جست‌وجو، شناسه‌ها و اطلاعات مکانی سطح‌بالا (در حد کشور یا استان، از روی reverse IP) بودند. او تصریح می‌کند که مقادیر مکانی، موقعیت دقیق کاربر را نشان نمی‌دادند و او هیچ فردی را شناسایی نکرد و هیچ پروفایلی نساخت.

عدد ۱۷.۳ تریلیون از کجا آمد؟

Faav هر ۵۶ مقدار مسیریابی (routing value) بازیابی‌شده از پیکربندی آرشیوی را با یک کوئری سادهٔ SELECT 1 آزمایش کرد. ۳۰ مورد از آن‌ها هنوز فعال بودند. هر مقدار به یک پیکربندی بک‌اند اشاره می‌کرد و هر پیکربندی یک یا چند پایگاه‌داده داشت؛ در مجموع این ۳۰ مقدار فعال به ۲۴ پیکربندی و ۱۷ پایگاه‌دادهٔ تحلیلی متصل با ۹٬۸۶۳ نام جدول یکتا رسیدند.

او شمارش ردیف‌ها را از متادیتای پایگاه‌داده‌های ClickHouse جمع زد و از دو مسیر مختلف (system.tables.total_rows و system.parts فعال) آن را راستی‌آزمایی کرد. عدد نهایی این بود:

• ۱۷٬۳۳۳٬۳۳۵٬۱۲۴٬۳۱۵

خود Faav صادقانه توضیح می‌دهد که این یک «برآورد ذخیره‌سازی» از روی متادیتاست و احتمالاً شامل داده‌های تاریخی، تکراری و مشتق‌شده می‌شود — اما به قول او، عددِ بالایی است به هر حال. جملهٔ ماندگار او از آن شب این است: ساعت ۲ بامداد بود، والدینش خواب بودند و او فقط آن‌جا نشسته بود و به عدد خیره شده بود و دوباره حساب‌وکتاب را چک می‌کرد.

مایکروسافت چه واکنشی نشان داد؟

Faav می‌گوید به‌محض یافتن رکوردهای کارکنان شروع به نوشتن گزارش برای MSRC (مرکز پاسخ‌گویی امنیتی مایکروسافت) کرد و پس از دیدن داده‌های Bing بلافاصله آن را ثبت کرد؛ پرونده با شمارهٔ ۱۴۴۰۵۱ در همان روز ۵ سپتامبر باز شد.

بین ۶ تا ۸ سپتامبر، مایکروسافت از او خواست آزمایش را متوقف کند و آدرس IP او را درخواست کرد تا مطمئن شود هیچ فعالیتی فراتر از پژوهش امنیتی رخ نداده. یک روز بعد، در ۹ سپتامبر، endpoint محدود شد. جایزهٔ ۵٬۰۰۰ دلاری در ۱۷ سپتامبر اعطا شد و در ۲۲ سپتامبر جلسه‌ای برای هماهنگی افشا برگزار شد.

نکتهٔ مهم برای شفافیت: Faav می‌گوید نوشتهٔ خود را به‌درخواست مایکروسافت بازنویسی کرده، بخش‌ها و اعداد را حذف یا کم کرده و شیوهٔ توصیف تأثیر را تغییر داده است. مایکروسافت نیز در بیانیه‌ای از او بابت «افشای هماهنگ آسیب‌پذیری» تشکر کرد و گفت این گزارش به سخت‌تر کردن سرویس‌هایش و محافظت بهتر از مشتریان کمک کرده است.

این ماجرا برای توسعه‌دهندگان و تیم‌های امنیتی چه درسی دارد؟

درس اصلی فنی ساده اما حیاتی است و خود Faav هم روی آن تأکید می‌کند: همیشه و پیش از هر چیز، امضای توکن را بررسی کنید. بررسی محتوای یک JWT بدون تأیید امضای آن عملاً یعنی هیچ احراز هویتی انجام نشده است.

چند نکتهٔ عملی که از این رخداد می‌توان بیرون کشید:

• الگوریتم alg: none را در سمت سرور به‌طور صریح رد کنید. این یک حملهٔ شناخته‌شده و قدیمی است و استاندارد RFC 8725 (سندِ بهترین‌روش‌های امنیتی JWT) دقیقاً دربارهٔ همین موضوع هشدار می‌دهد.

• اعتبارسنجی محتوا (tenant، audience و...) هیچ‌وقت جایگزین اعتبارسنجی رمزنگاری‌شدهٔ امضا نیست؛ هر دو باید با هم انجام شوند.

• APIهای «داخلی» را امن فرض نکنید. Titan پشت VPN بود، اما یک endpoint فراموش‌شده روی Azure همهٔ آن حفاظت را دور زد. امنیت مبتنی بر پنهان‌بودن (Security through Obscurity) کافی نیست.

• فایل‌های Swagger عمومی و پیکربندی‌های آرشیوشده (مثل آن‌چه در Wayback Machine هست) خودشان یک سطح حمله‌اند و می‌توانند نام جدول‌ها و مسیرها را لو بدهند.

هک‌بات‌های هوش مصنوعی آینده، امنیت را چطور تغییر می‌دهند؟

این ماجرا فراتر از یک باگ‌بانتی معمولی است، چون یک نمونهٔ واقعی و مستند از همکاری انسان و عامل هوش مصنوعی (AI Agent) در شکار آسیب‌پذیری است. Antares توانست کار تکراریِ ده‌روزه‌ای را انجام دهد که برای یک انسان خسته‌کننده و زمان‌بر بود. این یعنی سرعت و مقیاس شکار باگ در حال تغییر است — هم برای پژوهشگران کلاه‌سفید و هم، به‌طور بالقوه، برای مهاجمان.

اما همین ماجرا مرز توانایی این ابزارها را هم نشان می‌دهد: Antares در گام آخر گیر کرد، چون نتوانست از یک پیش‌فرض ساده (اینکه upn حتماً یک ایمیل است) عبور کند. آن جهش خلاقانه از سمت انسان آمد. جالب است که در روزهای اخیر خودِ مدل‌های هوش مصنوعی هم به ابزار شکار باگ بدل شده‌اند؛ The Register به‌تازگی از مدلی گزارش داده که در یافتن آسیب‌پذیری‌ها عملکرد قابل‌توجهی دارد.

پیام روشن است: احتمالاً به دوره‌ای وارد می‌شویم که در آن عامل‌های هوش مصنوعی به‌طور پیوسته سطح حملهٔ شرکت‌ها را اسکن می‌کنند. تیم‌های امنیتی که هنوز روی اصول اولیه‌ای مثل تأیید امضا سهل‌انگاری می‌کنند، در برابر این موج خودکارسازی آسیب‌پذیرتر از همیشه خواهند بود.

جمع‌بندی

ماجرای Faav و Titan یک یادآوری تلخ و درعین‌حال آموزنده است: پیچیده‌ترین سیستم‌ها هم می‌توانند به‌خاطر یک قطعهٔ کوچکِ گمشده فرو بریزند. مایکروسافت تمام منطق کنترل دسترسی را پیاده کرده بود، اما فراموش کرده بود امضای توکن را چک کند و همین یک نقطه کافی بود تا دری به‌سوی برآورد ۱۷.۳ تریلیون ردیف داده باز شود. خوشبختانه این در را یک پژوهشگر مسئولیت‌پذیر ۱۶ ساله باز کرد، نه یک مهاجم؛ او هیچ دادهٔ مشتری یا PII را لمس نکرد، ماجرا را گزارش داد و از مسیر افشای هماهنگ پیش رفت. درس فنی در یک جمله خلاصه می‌شود: امضا را تأیید کنید، همیشه و قبل از هر چیز.