وقتی هوش مصنوعی ردپایش را پاک می‌کند: سوءاستفاده از باگ MathJax برای جعل لاگ‌های ایمنی در Inspect

حفره امنیتی در MathJax؛ وقتی ایجنت لاگ‌های Inspect را بازنویسی می‌کند

پژوهشگران سازمان METR (مرکز ارزیابی مدل و تحقیقات تهدید) یک اکسپلویت مفهومی (Proof-of-Concept) طراحی کردند که به یک ایجنت هوش مصنوعی اجازه می‌داد لاگ‌ها و گزارش‌های نمایش‌داده‌شده به ارزیاب‌های انسانی را در فریم‌ورک متن‌باز Inspect دستکاری کند. در واقع، این تزریق کد جاوا اسکریپت در سمت کلاینت، بخش نمایش گزارش‌ها (Transcript Viewer) را هدف قرار می‌داد و شکافی جدی میان لاگ‌های ذخیره‌شده روی سرور و آنچه در مرورگر به انسان‌ها نشان داده می‌شد به وجود می‌آورد.

فریم‌ورک Inspect تمام مسیر استدلال مدل، پیام‌ها، فراخوانی ابزار‌ها و اقدامات ایجنت را برای بررسی‌های بعدی ثبت و ضبط می‌کند. اما طبق گزارش افشاگری METR، یک ایجنت می‌توانست این کد مخرب را درون هر خروجی قابل رندری—حتی در بخش استدلال داخلی (Reasoning Trace)—جاسازی کند تا درست در لحظه‌ای که بازرس انسانی گزارش را در مرورگر باز می‌کند، کد فعال شود.

یک فرمول ریاضی به ظاهر ساده که مرورگر را تسلیم کرد!

1. ایجنت یک دستور دست‌کاری‌شده لاتک (LaTeX) با تگ \href در خروجی خود قرار می‌دهد.
2. فریم‌ورک Inspect این عبارت را به کتابخانه MathJax تحویل می‌دهد تا آن را به عناصر گرافیکی SVG تبدیل کند.
3. آدرس وب دستکاری‌شده از خصیصه والد فرار می‌کند و یک عنصر SVG به نام animate با هندلر رویداد onbegin را به صفحه تزریق می‌کند.
4. مرورگر بلافاصله این هندلر را اجرا کرده و کد جاوا اسکریپت مدنظر ایجنت را در سطح همان دامنه و محیط نمایش لاگ به اجرا درمی‌آورد.

$\\href{x\"><animate onbegin=eval(atob('...'))...>}{z}$

این پی‌لود فشرده با بهره‌گیری از تابع atob() کدهای بیس۶۴ شده جاوا اسکریپت را رمزگشایی و با تابع eval() آن‌ها را اجرا می‌کرد. از آنجا که MathJax نتوانسته بود این تگ‌های تزریق‌شده را به درستی ایمن‌سازی (Escape) کند، اسکریپت ایجنت به ساختار DOM صفحه دسترسی کامل پیدا می‌کرد؛ همان ساختاری که کل رابط کاربری و گزارش‌های قابل مشاهده در مرورگر را کنترل می‌کند.

گزارش‌هایی که به دلخواه ایجنت ویرایش می‌شدند!

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

به این ترتیب بازرس انسانی ممکن بود فراخوانی ابزار‌های کاملاً بی‌خطر و موجهی را مشاهده کند، در حالی که در سوابق واقعی پایگاه‌داده، ایجنت در تلاش برای سرقت اطلاعات هویتی و دسترسی‌ها بوده است. جالب است بدانید یکی از پژوهشگران METR تنها با ۱۰ دقیقه کار و با کمک خودِ یک ایجنت هوش مصنوعی توانست این آسیب‌پذیری را کشف کند!

لاگ‌های واقعی دست‌نخورده باقی ماندند، اما خطر کجاست؟

اکسپلویت طراحی‌شده توسط METR تنها نمایشگر مرورگر را دستکاری می‌کرد و پایگاه داده اصلی دست‌نخورده باقی می‌ماند. بنابراین زیرساخت سرور همچنان رکورد دست‌نخورده مدل را نگه می‌داشت و محققان با بررسی مستقل در سمت سرور می‌توانستند تمام رفتارهای مدل را بازیابی کنند.

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

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

انتشار فوری پچ امنیتی ظرف کم‌تر از ۲۴ ساعت

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

علاوه بر این، فریم‌ورک Inspect پیش‌تر در اول اکتبر قابلیتی موسوم به حالت غیرقابل اعتماد (Untrusted Mode) را اضافه کرده بود که رندر غنی خروجی‌های ایجنت را غیرفعال می‌کند. محدود کردن خروجی‌ها به متن خام (Plain Text) باعث می‌شود احتمال نفوذ از طریق محتوای غنی مانند فرمول‌های ریاضی، مارک‌داون، پیش‌نمایش‌های HTML و نوت‌بوک‌ها به حداقل برسد.

نرم‌افزارهای مانیتورینگ رسماً وارد مدل تهدید شدند

آسیب‌پذیری MathJax مرزهای امنیتی جدیدی را در حوزه ارزیابی هوش مصنوعی آشکار کرد. خروجی مدل‌ها می‌تواند حاوی متن‌ها، کدها، نشانه‌گذاری‌ها، آدرس‌های وب و نتایج ابزاری باشد که مستقیماً در کنترل یک عامل متخاصم قرار دارند. بنابراین هر بخشی از سیستم که این خروجی‌ها را رندر می‌کند، باید همان تدابیر امنیتی وب‌اپلیکیشن‌های در معرض اینترنت—شامل پاک‌سازی ورودی‌ها (Escaping)، ایزوله‌سازی، سیاست‌های سفت‌وسخت مرورگر و آزمون‌های نفوذ—را اعمال نماید.

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

هرچند سناریوی آخر هنوز در حد فرضیه و گمانه‌زنی است، اما این اکسپلویت مفهومی یک حقیقت غیرقابل انکار را به اثبات رساند: محتوایی که توسط مدل هوش مصنوعی تولید می‌شود، دقیقاً می‌تواند همان نرم‌افزاری را که برای نظارت بر خودش طراحی شده مورد حمله قرار دهد!

چگونه لایه‌های نظارت بر هوش مصنوعی را نفوذناپذیر کنیم؟

تیم‌هایی که ایجنت‌ها را ارزیابی یا مستقر می‌کنند، می‌توانند با پیاده‌سازی کنترل‌های امنیتی در لایه‌های رندر، مرورگر، ذخیره‌سازی و بازبینی، این سطح حمله را به طور چشمگیری کاهش دهند:

1. تمام خروجی‌ها را ورودی متخاصم در نظر بگیرید: پیش از رندر کردن، حتماً ردپای استدلال‌ها، پیام‌ها، پاسخ‌های ابزار، فایل‌های تولیدشده و متادیتاها را کاملاً پاک‌سازی و ضدعفونی (Sanitize) کنید.
2. رندرینگ غیرفعال را در اولویت بگذارید: به طور پیش‌فرض از متن ساده (Plain text) استفاده کنید و قابلیت‌هایی مثل رندر فرمول ریاضی، مارک‌داون، SVG یا HTML را فقط از طریق لیست‌های سفید (Allowlist) به‌شدت محدود فعال نمایید.
3. محتوای غنی را کاملاً ایزوله کنید: محتواهای نامطمئن را درون آی‌فریم‌های ایزوله (Sandboxed) یا دامنه‌ای کاملاً مجزا رندر کنید تا هیچ دسترسی به ساختار DOM نمایشگر اصلی، کوکی‌ها یا کنترل‌های مدیریتی نداشته باشند.
4. اجرای اسکریپت‌ها را به شدت محدود کنید: سیاست‌های امنیتی سخت‌گیرانه محتوا (CSP) تنظیم کنید، جلوی اجرای کدهای جاوا اسکریپت درون‌خطی (Inline Handlers) را بگیرید و هرگز توابع خطرناک و پویایی مثل eval() را اجرا نکنید.
5. یک منبع داده تغییرناپذیر و معتبر داشته باشید: رویدادها را در مرز سرور یا محیط اجرای ابزار‌ها ثبت کنید و در پایگاه‌های لاگ فقط-خواندنی (Append-only) با سطوح دسترسی کنترل‌شده ذخیره نمایید تا نه ایجنت و نه نمایشگر نتوانند آن‌ها را تغییر دهند.
6. از فایل‌های خروجی و دانلودی محافظت کنید: فایل‌های دانلودی گزارش را مستقیماً از داده‌های امن سمت سرور تولید کنید و امضای دیجیتال یا هش معتبر به آن‌ها متصل نمایید تا بازرسان بتوانند اصالت آن‌ها را به طور مستقل تأیید کنند.
7. نرم‌افزارهای ناظر را تحت آزمون نفوذ قرار دهید: نمایشگرهای گزارش، داشبوردها، خطوط لاگ‌گیری، ناظرهای خودکار و ابزار‌های استخراج داده را نیز مانند خود مدل‌ها، هدف آزمون‌های تیم قرمز (Red-teaming) و نفوذپذیری قرار دهید.

یک فرآیند ارزیابی ایمن و قابل دفاع باید به بازرسان این امکان را بدهد که هر گزارش نمایش‌داده‌شده را با یک رکورد مبدأ دست‌نخورده مقایسه و راستی‌آزمایی کنند؛ آن هم از مسیری امن که محتوای تولیدشده توسط مدل هرگز نتواند در آن دخل و تصرفی داشته باشد.