فایلهایی در بیش از ۱۰۰ وبسایت پیدا شدهاند که به محتوای اجرایی بالقوه خطرناکی اشاره میکنند؛ محتوایی که هنگام بازدید توسط بسیاری از Agentهای هوش مصنوعی، بهصورت خودکار نصب و اجرا میشود. چندین ده شرکت، از جمله برخی شرکتهای Fortune ۵۰۰، کدهای Proof-of-Concept را اجرا کردهاند. دستکم یک وبسایت که بهدرستی پیکربندی نشده بود، بازدیدکنندگان—چه انسان و چه Agentهای هوش مصنوعی—را به سمت بدافزار واقعی و فعال هدایت میکرد.
این محتوای بالقوه خطرناک در فایلهای llms.txt و llms-full.txt قرار دارد؛ فایلی که یک استاندارد نوظهور است و وبسایتها از آن برای ارائه خلاصهای قابل پردازش توسط ماشین از محتوای سایت و ساختار کلی آن استفاده میکنند. این فایلها را میتوان معادل مخصوص هوش مصنوعیِ استاندارد robots.txt دانست؛ فایلی که به موتورهای جستوجو اعلام میکند محتوای یک سایت چگونه ایندکس شود.
ابزار Google Lighthouse که برای کمک به توسعهدهندگان وب طراحی شده، توضیحات بیشتری درباره نحوه بررسی llms.txt ارائه میکند. فایلهای llms.txt و llms-full.txt مربوط به Cloudflare نیز نمونههایی از فایلهایی هستند که به درستی پیکربندی شدهاند.
پژوهشگران چگونه این مشکل را پیدا کردند؟
پژوهشگران یک استارتاپ مخفی در اسرائیل، ۶٬۲۱۴ دامنه فعال متعلق به پیمانکاران دفاعی، شرکتهای Fortune ۵۰۰ و شرکتهای بزرگ فناوری را اسکن کردند. از میان ۸٬۲۶۵ فایل llms.txt و llms-full.txt که پیدا کردند—چون بسیاری از سایتها هر دو فایل را میزبانی میکردند—۱۲۰ فایل، که هرکدام روی یک سایت متفاوت قرار داشتند، به یک یا چند پکیج کدی یا نام دامنهای اشاره میکردند که ثبت نشده بودند.
برای بررسی اینکه هنگام پردازش چنین فایلهایی توسط یک Agent هوش مصنوعی چه اتفاقی رخ میدهد، پژوهشگران تعدادی از نامهای بدون مالک را ثبت کردند و پکیجهایی روی آنها قرار دادند که باعث میشد هر سیستمی که آنها را اجرا میکند، با سرور پژوهشگران ارتباط برقرار کند.
کمتر از یک ساعت بعد، پژوهشگران نخستین پاسخ phone-home را از یک شرکت Fortune ۵۰۰ دریافت کردند. در ادامه، چند ده پاسخ دیگر نیز دریافت شد؛ برخی از شرکتهای Fortune ۵۰۰ دیگر و برخی از استارتاپها.
Beacon مورد استفاده پژوهشگران همچنین زنجیره فرایندهای والد (parent process chain) را که هر نصب را ایجاد کرده بودند ثبت میکرد. این اطلاعات در نهایت نشان داد که Agentهای کدنویسی، از جمله Claude، Codex متعلق به OpenAI و Hermes متعلق به Nous Research، در این فرایندها دخیل بودهاند.
Anthropic، OpenAI و Nous Research تا زمان انتشار مقاله به درخواست اظهارنظر پاسخی نداده بودند.
یکی از پژوهشگران، Alon Hertz، در مصاحبهای نوشت:
«مدل اعتماد شکسته است. Agentها مستندات فروشنده را حقیقت مطلق در نظر میگیرند و آنها را به چالش نمیکشند؛ انسانهایی هم که بر آنها نظارت میکنند همین کار را انجام میدهند. استفاده از Agentهای هوش مصنوعی به سرعت در حال گسترش است و این Agentها در تمام لایهها—از SaaS و Cloud گرفته تا Endpoint—در حال نفوذ هستند. هر چه تعدادشان بیشتر شود، سطح حمله زنجیره تامین نیز گستردهتر میشود و سازوکارهای حفاظتی امروزی این سطح جدید را پوشش نمیدهند.»
این فایلها به دلیل پیکربندی نادرست، شامل نام پکیجهای غیرموجود از PyPI، npm و سایر Registryها، به همراه دستورالعمل نصب آنها بودند.
برای مثال، در یکی از فایلها چنین دستوری وجود داشت:
Installation: pip install [نام حذفشده به درخواست پژوهشگران]
و در فایل دیگری:
npm install [نام حذفشده]
از آنجا که نام این پکیجها ثبت نشده بود، یک مهاجم میتوانست یکی از آنها را ثبت کند و پکیجی حاوی باجافزار یا هر نوع کد مخرب دیگری روی آن قرار دهد.
این آسیبپذیری زمانی ایجاد میشود که یک Agent کدنویسی، با مجوز اجرای دستورات Shell، این فایل را بهعنوان مستندات معتبر برای راهاندازی پروژه در نظر بگیرد. در چنین شرایطی، برخی Agentهای هوش مصنوعی پکیج را دانلود و اجرا میکنند.
در موارد دیگر، فایلهای LLM به نام دامنههایی اشاره میکنند که دیگر وجود ندارند یا ثبت نشدهاند. در یکی از موارد، متن فایل میگفت:
«بهعنوان نمونهای برای نوشتن Integration Test برای اپلیکیشنهای [حذفشده] میتوانید از فریمورک تست Citrus استفاده کنید.»
مهاجم میتواند سپس آن دامنه را ثبت کرده و دستورالعملهای مخرب را روی آن قرار دهد.
این دیگر فقط یک تهدید تئوری نیست
Proof-of-Concept پژوهشگران نشان داد که Agentهای کدنویسی دقیقا همین کار را انجام میدهند؛ حتی Agentهایی که در برخی از قدرتمندترین شرکتهای جهان اجرا میشوند.
این موضوع صرفا یک تهدید نظری نیست. دستکم یک حمله فعال در حال حاضر از همین اشتباه سوءاستفاده میکند.
پژوهشگران یک فایل LLM را روی وبسایت قانونی clerk.com پیدا کردند که شامل این دستور بود:
npx clerk-next-fix-auth-protection
برخلاف یک دستور نصب معمولی، npx میتواند یک پکیج را مستقیما در Cache مربوط به npm دریافت کند و Binary ارائه شده توسط آن را اجرا کند، بدون اینکه آن پکیج را به Manifest وابستگیهای پروژه اضافه کند.
پژوهشگران خیلی زود متوجه شدند که فردی نامی را که قبلا بدون مالک بود ثبت کرده و از آن برای میزبانی بدافزار فعال استفاده کرده است.
Clerk از آن زمان مشکل را برطرف کرده است. این شرکت همچنین اعلام کرد که اگر یک Agent قبلا Binary موجود در پکیج @clerk/eslint-plugin را نصب کرده باشد، خطری متوجه سیستم نبوده است. در غیر این صورت، پکیج مخرب نصب میشده است.
البته مشخص نیست که این اشتباه در نهایت به آلودگی واقعی سیستمها منجر شده باشد یا خیر.
مشکل بنیادیتر: محدودیتهای Agentهای هوش مصنوعی
تهدید تازه کشف شده، بار دیگر یکی از محدودیتهای بنیادی هوش مصنوعی را یادآوری میکند.
LLMها نمیتوانند همیشه مرز قابل اعتمادی میان دستورهای واقعی کاربر که مستقیما در Prompt وارد شدهاند و محتوایی که از منابع شخص ثالث و غیر قابل اعتماد دریافت میکنند، ترسیم کنند.
اگر Guardrail مناسبی برای جلوگیری از این رفتار وجود نداشته باشد، دستورهایی که مدل در محتوای بازیابیشده (retrieved content) پیدا میکند، میتوانند درست مانند دستورهایی که خود کاربر وارد کرده است، اجرا شوند.
این ضعف که تاکنون راهحل کاملا قابل اتکایی برای آن پیدا نشده، منشا حملاتی موسوم به Prompt Injection است.
پژوهشگران در مطلبی که روز پنجشنبه منتشر کردند نوشتند:
«یک Agent میان یک صفحه و یک دستور تفاوتی قائل نمیشود. هر چیزی که میخواند، Input است و هر Input نیز میتواند یک دستور باشد.»
به این ترتیب، تقریبا تمام مجموعه دادههای منتشرشدهای که Agentها اکنون به آنها متصل شدهاند و از آنها محتوا دریافت میکنند، عملاً به یک سطح اجرای کد (Execution Surface) تبدیل شدهاند؛ در حالی که تقریباً هیچکدام از این دادهها، تضمینهای یکپارچگیای را که برای کد واقعی در نظر میگیریم، ندارند.
۱۲۰ فایل دارای پیکربندی نادرست که پژوهشگران پیدا کردند، در مجموع شامل ۲۲۷ دستور برای نصب پکیجهای غیرموجود یا بازدید از دامنههای بدون مالک بودند.
مشخص نیست این ورودیهای معیوب دقیقا چگونه ایجاد شدهاند. در بسیاری از موارد، این موارد مربوط به دوران پیش از ظهور هوش مصنوعی بودهاند و ابتدا در فایلهای غیرمرتبط با LLM روی وبسایت قرار گرفته بودند.
این موضوع نشان میدهد که این ورودیهای اشتباه توسط انسانها بهصورت دستی ایجاد شدهاند.
پژوهشگران احتمال میدهند برخی موارد دیگر توسط هوش مصنوعی ایجاد شده باشند؛ یا در نتیجه Hallucination مدل یا به همان دلیلی که Agentهای هوش مصنوعی هنگام مرور این فایلها دچار مشکل میشوند: ناتوانی در تشخیص دستورهای معتبر از دستورهای نامعتبر.
از بین رفتن مرز میان داده و کد
پژوهشگران در مطلب دیگری درباره یافتههای خود توضیح بیشتری ارائه کردند:
«ممکن است این کنترل امنیتی نتواند این حمله را شناسایی کند، چون تمام سیگنالهایی که سیستم بر اساس آنها تصمیم میگیرد، در جهت اشتباه هستند.»
وقتی یک Agent هوش مصنوعی با فایل llms.txt مواجه میشود، میبیند که فایل از طریق HTTPS ارائه شده، روی دامنه رسمی شرکت قرار دارد، از یک فرمت استاندارد طراحی شده برای مصرف توسط هوش مصنوعی استفاده میکند و توسط خود شرکت یا یک شریک مورد اعتماد آن منتشر شده است.
«Agent هیچ دلیلی ندارد که این موارد را زیر سؤال ببرد. فایل، مرجع معتبر است—و اساساً هدف آن همین است.»
بنابراین اگر فایل بگوید:
pip install internal-tool
Agent مکث نمیکند تا بررسی کند آیا internal-tool واقعا متعلق به آن شرکت است یا نه.
Namespace مربوط به پکیج را در PyPI بررسی نمیکند.
متوجه نمیشود که لینک موجود در مستندات به دامنهای اشاره دارد که سه ماه پیش منقضی شده است.
فقط همان کاری را انجام میدهد که فایل به آن گفته است.
زنجیره اعتماد میتواند بهصورت انتقالی ادامه پیدا کند
زنجیره اعتماد حتی به همینجا ختم نمیشود.
فایل llms.txt الزاما نباید روی وبسایت خود شرکت Fortune ۵۰۰ قرار داشته باشد. Agentها میتوانند Context را از منابع شخص ثالث مورد اعتماد دریافت کنند؛ برای مثال:
- مستندات یک Partner
- مرجع SDK یک Vendor
- راهنمای راهاندازی یک پروژه Community
اگر Agent به آن منبع شخص ثالث اعتماد کند و فایل آن منبع به یک پکیج ثبتنشده اشاره کند، همین زنجیره اعتماد میتواند عمل کند.
EDR هم ممکن است متوجه چیزی نشود
حتی سیستمهای تشخیص و پاسخ Endpoint یا EDR نیز ممکن است هیچ هشداری صادر نکنند.
از دید یک EDR یا Proxy، این فعالیت میتواند دقیقا مانند اجرای یک Package Manager قانونی توسط یک توسعه دهنده به نظر برسد:
pip install از pypi.org؛ دامنهای که تقریباً تمام Proxyهای سازمانی از قبل اجازه دسترسی به آن را میدهند، و در عین حال Agent کدنویسی نیز همان برنامهای است که شرکت عمدا روی سیستم نصب کرده و بهعنوان Parent Process در زنجیره اجرا ظاهر میشود.
در این وضعیت:
- Anomalyای مشاهده نمیشود.
- Alertای ایجاد نمیشود.
- مشکل در Endpoint اتفاق نمیافتد.
شکست امنیتی در مرحلهای بالاتر و در فاصله میان دستور و اجرا رخ داده است.
Endpoint ممکن است اساسا فرصتی برای مقابله با حمله نداشته باشد، چون سوال درستی را از ابتدا مطرح نکرده است.
محو شدن مرز میان داده و کد
این پژوهش نشان میدهد که در عصر هوش مصنوعی، مرز مشخصی که زمانی میان داده و کد اجرایی وجود داشت، در حال از بین رفتن است.
هر چیزی که یک Agent بتواند آن را پردازش کند، بالقوه میتواند بهعنوان یک دستور تلقی شود و اگر Agent مجوز اجرای Command داشته باشد، ممکن است همان دستور را اجرا کند.
پژوهشگران درباره مورد Clerk نوشتند:
«مورد Clerk روشنترین نمونه برای اثبات این موضوع است. دستور دقیقاً شبیه چیزی بود که Vendor باید ارائه کند—چون واقعاً در فایل دستورالعمل خود Vendor قرار داشت. تنها چیزی که وجود نداشت، نام آن در Registry بود. تمام لایههای زنجیره اعتماد سالم بودند، بهجز همان لایهای که هیچکس فکر نمیکرد باید آن را بررسی کند.»
منشا این مشکل تازه کشف شده همان چیزی است که در اساس، عامل ایجاد Prompt Injection نیز محسوب میشود؛ با این تفاوت که ضعف جدید دامنه بسیار گستردهتری دارد.
Hertz توضیح داد:
«در Prompt Injection، فردی عمداً دستورهای مخرب را در محتوا قرار میدهد. اما در اینجا خود دستور میتواند کاملاً بیضرر باشد و از یک منبع قانونی—مثلاً مستندات رسمی یک شرکت واقعی—آمده باشد و در زمان نوشتهشدن آن نیز هیچ مهاجمی در کار نباشد.»
«خطر بعدها ایجاد میشود؛ زمانی که پکیج یا دامنهای که دستور به آن اشاره میکند رها میشود و فرد دیگری آن را ثبت و تصاحب میکند.»
این یعنی مشکل بسیار فراتر از فایلهای llms.txt و llms-full.txt روی وبسایتهاست.
دستورها—چه بهصورت ضمنی و چه صریح—تقریبا همه جا که یک Agent در آن حرکت میکند وجود دارند.
این مرز در حال فروپاشی، در کنار شتاب شرکتهای بزرگ فناوری برای قرار دادن هوش مصنوعی در همه جا، چشمانداز چندان آرامشبخشی برای آینده ایجاد نمیکند؛ اما بدون شک باعث خواهد شد متخصصان امنیت—یا Agentهای هوش مصنوعی که جای آنها را میگیرند—برای مدت طولانی با کار و چالش مواجه باشند.
منبع: https://arstechnica.com/security/۲۰۲۶/۰۸/claude-codex-and-hermes-installed-unowned-code-inside-corporate-networks/
