هک Grok بدون یک کلیک؛ حملهای که میتواند تاریخچه چت کاربران را بدزدد
یک حمله Zero-Click جدید به Grok میتواند با Prompt Injection رمزنگاریشده، تاریخچه چت و اطلاعات کاربران را بدون کلیک آنها استخراج کند. جزئیات حمله را بخوانید.
اگر فقط یک صفحه وب را برای Grok بفرستید، ممکن است اطلاعات چت شما در معرض خطر قرار بگیرد؟
تصور کنید از Grok میخواهید یک صفحه وب را برایتان خلاصه کند. نه روی لینک مشکوکی کلیک کردهاید، نه فایلی دانلود کردهاید و نه رمز عبوری وارد کردهاید.
اما همان صفحه وب میتواند حاوی دستوراتی مخفی باشد که هوش مصنوعی را وادار کند بخشی از اطلاعات خصوصی گفتوگوی شما را استخراج کرده و به یک سرور تحت کنترل مهاجم ارسال کند.
این سناریو در یک اثبات مفهوم (PoC) توسط پژوهشگران شرکت امنیتی Adversa AI علیه نسخه وب Grok بررسی شده است. پژوهشگران این روش را Cryptographic Context Injection نامیدهاند؛ تکنیکی که در آن دستور مخرب بهجای قرار گرفتن به شکل متن ساده، داخل داده رمزنگاریشده پنهان میشود و سپس از محیط اجرای کد خود مدل برای رمزگشایی آن استفاده میشود.
نکته نگرانکننده اینجاست:
در آزمایش پژوهشگران، کاربر پس از درخواست اولیه برای خلاصهسازی صفحه، هیچ کلیک یا تأیید دیگری انجام نمیدهد.
پژوهشگران میگویند در نمونه آزمایشی، اطلاعاتی مانند نام کاربر، موقعیت تقریبی، سطح اشتراک و تاریخچه گفتوگوی فعال میتوانست در زنجیره حمله قرار بگیرد.
در این مقاله میخوانید
- حمله Zero-Click به Grok دقیقاً چیست؟
- Cryptographic Context Injection چیست؟
- هکر چگونه بدون کلیک کاربر به چت او میرسد؟
- چرا رمزنگاری AES-256-GCM به بخشی از حمله تبدیل شده است؟
- چه اطلاعاتی در PoC قابل استخراج بود؟
- آیا این یعنی همین الان Grok هک شده است؟
- وضعیت واکنش xAI چیست؟
- این حمله چه خطری برای Agentهای هوش مصنوعی دارد؟
- کاربران برای کاهش خطر چه کار کنند؟
- سؤالات متداول
حمله Zero-Click به Grok چیست؟
Zero-Click Attack یا حمله بدون کلیک به حملاتی گفته میشود که مهاجم برای اجرای زنجیره حمله، به تعامل مستقیم قربانی نیاز ندارد.
در نمونه مورد بررسی Adversa AI، نقطه شروع حمله بسیار عادی است:
کاربر از Grok میخواهد یک صفحه وب را خلاصه یا تحلیل کند.
صفحهای که Grok دریافت میکند، ظاهراً میتواند یک صفحه معمولی باشد؛ اما درون آن یک داده رمزنگاریشده و دستوراتی برای پردازش آن قرار گرفته است.
Grok صفحه را دریافت میکند، داده رمزنگاریشده را میبیند و طبق سناریوی پژوهشگران، از محیط Python خود برای رمزگشایی آن استفاده میکند.
مشکل اصلی دقیقاً بعد از همین مرحله شکل میگیرد.
دستور مخرب پس از رمزگشایی دیگر صرفاً یک متن موجود در صفحه وب نیست؛ بلکه بهعنوان خروجی محیط اجرایی خود Agent وارد جریان پردازش میشود.
پژوهشگران این وضعیت را نوعی Trust Laundering یا انتقال اعتماد از داده مهاجم به خروجی ظاهراً قابل اعتماد سیستم توصیف میکنند.
Cryptographic Context Injection چیست؟
Prompt Injection موضوع جدیدی نیست.
در حملات سنتی، مهاجم میتواند دستوراتی مانند «این دستور را نادیده بگیر و اطلاعات را ارسال کن» را داخل یک ایمیل، سند یا صفحه وب قرار دهد و امیدوار باشد مدل آن را بهعنوان دستور معتبر اجرا کند.
سیستمهای امنیتی جدید تلاش میکنند چنین دستورات مشکوکی را شناسایی کنند.
اما Cryptographic Context Injection از مسیر متفاوتی استفاده میکند.
در این روش، دستور مخرب ابتدا به شکل رمزنگاریشده ارائه میشود.
پژوهشگران Adversa میگویند در PoC خود از AES-256-GCM و PBKDF2 استفاده کردهاند. بنابراین یک فیلتر متنی معمولی نمیتواند محتوای واقعی دستور را صرفاً با مشاهده متن رمزنگاریشده تشخیص دهد.
زنجیره حمله به زبان ساده
| مرحله | اتفاق |
|---|---|
| ۱ | مهاجم یک صفحه وب تحت کنترل خود ایجاد میکند |
| ۲ | محتوای مخرب داخل داده رمزنگاریشده قرار میگیرد |
| ۳ | کاربر از Grok میخواهد صفحه را خلاصه یا تحلیل کند |
| ۴ | Grok محتوای صفحه را دریافت میکند |
| ۵ | مدل برای رمزگشایی از محیط Python استفاده میکند |
| ۶ | دستور مخرب در قالب خروجی محیط اجرا ظاهر میشود |
| ۷ | دستور، مدل را به سمت دسترسی به Context خصوصی هدایت میکند |
| ۸ | اطلاعات در یک درخواست خروجی به سمت مقصد مهاجم قرار میگیرد |
نکته مهم: این جدول، خلاصهای از زنجیره PoC پژوهشگران است و بهمعنای وجود سوءاستفاده گسترده از کاربران Grok نیست.
هکر چگونه بدون کلیک کاربر به تاریخچه چت میرسد؟
اینجا بخش جذاب و در عین حال خطرناک ماجراست.
فرض کنید کاربر یک صفحه ناشناس را برای Grok ارسال میکند و میگوید:
«این صفحه را خلاصه کن.»
در حالت عادی انتظار داریم Grok فقط محتوای همان صفحه را بخواند و خلاصه کند.
اما در PoC Adversa، صفحه حاوی داده رمزنگاریشدهای بود که مدل را به سمت اجرای کد و سپس پردازش دستور رمزگشاییشده هدایت میکرد.
پس از رمزگشایی، دستور مهاجم تلاش میکرد Context خصوصی جلسه را استخراج کند.
طبق گزارش پژوهشگران، این Context شامل مواردی مانند:
- نام کاربر
- موقعیت تقریبی
- نوع اشتراک
- Promptهای فعال در گفتوگو
- تاریخچه مکالمه جاری
بود.
در مرحله بعد، مدل بهجای اینکه اطلاعات را مستقیماً در پاسخ خود نمایش دهد، طبق PoC به یک URL دیگر هدایت میشد.
اطلاعات جمعآوریشده در پارامترهای URL قرار میگرفت و درخواست به سمت سرور تحت کنترل مهاجم ارسال میشد.
به زبان ساده:
صفحه وب → Grok → رمزگشایی → دسترسی به Context → ساخت درخواست خروجی → ارسال اطلاعات
و در نمونه آزمایشی، این زنجیره بدون نمایش هشدار یا دریافت تأیید جدید از کاربر تکمیل شد.
چرا AES-256-GCM در این حمله اهمیت دارد؟
ممکن است این سؤال مطرح شود که:
چرا مهاجم دستور خود را Base64 یا یک روش سادهتر رمزگذاری نکرد؟
پژوهشگران میگویند تفاوت مهم همینجاست.
روشهایی مانند Base64 یا برخی رمزگذاریهای ساده، در بسیاری از موارد توسط مدل قابل تشخیص یا بازسازی هستند.
اما AES-256-GCM یک الگوریتم رمزنگاری قوی است و مدل نمیتواند صرفاً با تکیه بر دانش درونی خود متن رمزگشاییشده را حدس بزند.
بنابراین مهاجم کاری میکند که خود Agent عملیات رمزگشایی را انجام دهد.
اینجا محیط اجرای کد به حلقه حمله وارد میشود.
به بیان ساده:
فیلتر نمیتواند دستور را قبل از رمزگشایی ببیند؛ اما خود Agent آن را رمزگشایی میکند.
مشکل امنیتی مورد بحث Adversa دقیقاً از همین نقطه شکل میگیرد: خروجی حاصل از اجرای کد ممکن است بهجای اینکه همچنان «داده غیرقابل اعتماد» محسوب شود، در ادامه بهعنوان Context معتبر پردازش شود.
چه اطلاعاتی ممکن است در معرض سرقت قرار بگیرد؟
طبق PoC منتشرشده توسط Adversa، پژوهشگران توانستند زنجیرهای طراحی کنند که برای استخراج اطلاعات Session تلاش میکند.
اطلاعات مورد اشاره شامل موارد زیر است:
| نوع اطلاعات | وضعیت در PoC |
| نام کاربر | قابل دسترسی در Context آزمایشی |
| موقعیت تقریبی | قابل دسترسی در Context آزمایشی |
| سطح اشتراک | قابل دسترسی در Context آزمایشی |
| تاریخچه Promptهای فعال | مهمترین بخش PoC |
| اطلاعات موجود در گفتوگوی جاری | بسته به Context در دسترس Agent |
| رمز عبور حساب | گزارشی از سرقت Password ارائه نشده است |
| اطلاعات بانکی | گزارشی از سرقت ارائه نشده است |
بنابراین نباید این خبر را به شکل «هکرها رمز عبور تمام کاربران Grok را دزدیدهاند» بازنشر کرد.
موضوع اصلی این پژوهش، نشت Context و تاریخچه مکالمه از طریق یک Agent دارای قابلیت مرور وب و اجرای کد است.
آیا همین الان Grok هک شده است؟
نه به این معنا که یک حمله گسترده به کاربران Grok در جریان باشد.
این تفاوت برای فهم درست خبر بسیار مهم است.
Adversa AI یک اثبات مفهوم ارائه کرده است. پژوهشگران میگویند این حمله را علیه Grok 4.5 Fast روی وبسایت Grok آزمایش کردهاند و تا ۱۹ آگوست ۲۰۲۶ همچنان توانستهاند زنجیره حمله را بازتولید کنند.
طبق گزارش آنها، در حدود ۲۰ تلاش از ژوئن، نرخ موفقیت حدود ۴۰ درصد بوده است.
در عین حال:
- CVE برای این موضوع اعلام نشده است.
- شواهدی از سوءاستفاده واقعی در طبیعت ارائه نشده است.
- یک Patch عمومی برای رفع آن اعلام نشده است.
- Payload عملیاتی کامل نیز توسط پژوهشگران منتشر نشده است.
بنابراین عنوانهایی مانند «هک شدن میلیونها حساب Grok» یا «سرقت گسترده اطلاعات کاربران Grok» دقیق نیستند.
اما اصل یافته مهم است؛ چون نشان میدهد یک Agent مجهز به مرور وب + اجرای کد + دسترسی به Context خصوصی + ارتباط خروجی با اینترنت میتواند سطح حمله بسیار متفاوتی نسبت به یک چتبات معمولی داشته باشد.
xAI از این حمله خبر داشت؟
طبق گزارش Adversa، این آسیبپذیری در ۳ ژوئن ۲۰۲۶ به xAI و برنامه HackerOne آن گزارش شده است.
پژوهشگران میگویند xAI دریافت گزارش را تأیید کرده، اما زمانبندی مشخصی برای رفع مشکل ارائه نکرده است.
آنها همچنین اعلام کردهاند که در ۴ و ۱۰ آگوست پیگیریهایی انجام دادهاند اما پاسخی درباره زمانبندی اصلاح دریافت نکردهاند.
Adversa در نهایت تصمیم گرفت جزئیات تحقیق را منتشر کند، اما Payload عملیاتی را برای جلوگیری از سوءاستفاده عمومی منتشر نکرد.
چرا این حمله برای آینده هوش مصنوعی مهم است؟
شاید مهمترین بخش این خبر اصلاً Grok نباشد.
موضوع بزرگتر، Agentic AI است.
نسل جدید ابزارهای هوش مصنوعی دیگر فقط متن تولید نمیکنند. آنها میتوانند:
- وب را جستوجو کنند؛
- فایل بخوانند؛
- کد اجرا کنند؛
- به APIها متصل شوند؛
- ایمیل ارسال کنند؛
- اطلاعات را از سرویسهای مختلف جمعآوری کنند؛
- و در برخی محیطها حتی تغییرات واقعی در سیستمها ایجاد کنند.
در چنین محیطی، Prompt Injection دیگر فقط یک دستور مخرب داخل متن نیست.
مهاجم میتواند تلاش کند مسیر تصمیمگیری Agent را تغییر دهد.
به همین دلیل Adversa استدلال میکند که سطح حمله از خود Prompt فراتر رفته و شامل Tool Output، Runtime Output و Context داخلی Agent نیز شده است.
یک مثال ساده
فرض کنید یک Agent سازمانی به ایمیل، GitHub و سیستم مالی شرکت دسترسی دارد.
اگر فقط «مدل» را ایمن کنیم اما به محتوای دریافتشده از اینترنت اجازه دهیم مستقیماً روی ابزارهای قدرتمند اثر بگذارد، یک صفحه مخرب میتواند تبدیل به نقطه شروع حمله شود.
یعنی:
داده غیرقابل اعتماد + ابزار قدرتمند + دسترسی زیاد = ریسک جدی
کاربران برای کاهش خطر چه کار کنند؟
برای کاربران عادی، مهمترین اقدام این است که هر صفحه وبی را که برای خلاصهسازی یا تحلیل در اختیار Agent قرار میدهند، کاملاً قابل اعتماد فرض نکنند.
بهخصوص زمانی که ابزار هوش مصنوعی قابلیت اجرای کد یا انجام عملیات آنلاین دارد.
چند توصیه کاربردی
۱. صفحات ناشناس را بدون دلیل در Agentهای قدرتمند وارد نکنید.
اگر فقط میخواهید محتوای یک صفحه را بخوانید، لازم نیست همیشه آن را به Agentی بدهید که دسترسیهای گسترده دارد.
۲. اطلاعات بسیار حساس را در گفتوگوهای غیرضروری وارد نکنید.
هرچه Context یک Session حساستر باشد، در صورت وجود نقص در Agent، ارزش بیشتری برای مهاجم خواهد داشت.
۳. برای Agentهای سازمانی، دسترسی را حداقلی کنید.
یک Agent خلاصهکننده خبر نباید الزاماً به ایمیل، فایلهای محرمانه، مخزن کد یا سامانه مالی دسترسی داشته باشد.
۴. به قابلیتهای خودکار Agent توجه کنید.
هرچه Agent بتواند بیشتر «انجام دهد»، نه فقط «پاسخ دهد»، اهمیت کنترل دسترسی و خروجی شبکه بیشتر میشود.
۵. به هشدارها و مجوزهای ابزار توجه کنید.
اگر یک Agent ناگهان قصد دارد به یک دامنه ناشناخته متصل شود یا عملی خارج از درخواست اولیه انجام دهد، ادامه کار بدون بررسی منطقی نیست.
راهحل اصلی فقط «بهبود مدل» نیست
یکی از نکات مهم تحقیق Adversa این است که مشکل الزاماً با ساخت یک مدل قویتر حل نمیشود.
کنترل امنیتی باید در لایه اطراف Agent نیز وجود داشته باشد.
برای مثال:
| کنترل امنیتی | هدف |
| جداسازی محتوای وب غیرقابل اعتماد | جلوگیری از ورود مستقیم دستور مهاجم به Context privileged |
| محدود کردن دسترسی Agent | کاهش خسارت احتمالی |
| کنترل خروجی شبکه | جلوگیری از ارسال خودکار داده به مقصد ناشناس |
| ثبت Tool Callها | امکان تشخیص و بررسی حمله |
| ثبت منبع هر دستور | مشخص شدن اینکه یک دستور از کاربر آمده یا صفحه وب |
| تأیید عملیات حساس | جلوگیری از اجرای اقدامات پرریسک بدون کنترل |
Adversa نیز توصیه میکند محتوای دریافتشده از منابع غیرقابل اعتماد از Contextهای دارای ابزار و Credentialهای حساس جدا شود و برای عملیات خروجی، مقصدهای جدید و اقدامات غیرقابل بازگشت کنترل اعمال شود.
Grok تنها هدف این تکنیک نبود
پژوهشگران Adversa همچنین روشی مشابه را روی Google Gemini در حالت Deep Thinking آزمایش کردهاند.
در این آزمایش، داده رمزنگاریشده پس از رمزگشایی در محیط Python به شکلی طراحی شده بود که مدل آن را مانند یک خروجی معتبر از محیط اجرا تفسیر کند.
Adversa میگوید موفقیت این روش علیه Gemini تا آگوست بهشدت کاهش یافته است؛ بنابراین وضعیت آن با نمونه Grok یکسان نیست.
این بخش اهمیت دیگری دارد:
مشکل فقط یک محصول خاص نیست؛ بلکه به معماری Agentهایی مربوط میشود که همزمان میتوانند محتوای خارجی را بخوانند، کد اجرا کنند و اقدامات آنلاین انجام دهند.
یک «خلاصهکردن ساده» دیگر همیشه ساده نیست
شاید مهمترین پیام این تحقیق برای کاربران عادی همین باشد.
تا امروز، بسیاری از کاربران تصور میکردند خطر اصلی زمانی است که:
- روی لینک آلوده کلیک کنند؛
- فایل مخرب دانلود کنند؛
- رمز عبور را در صفحه جعلی وارد کنند.
اما در دنیای Agentic AI، سناریوی متفاوتی در حال شکلگیری است:
ممکن است خود هوش مصنوعی محتوای مهاجم را بخواند و آن را پردازش کند.
در PoC مورد بررسی، کاربر قرار نبود کد اجرا کند یا اطلاعاتش را برای مهاجم ارسال کند.
او فقط یک درخواست معمولی داشت:
«این صفحه را خلاصه کن.»
و همین موضوع است که این تحقیق را مهم میکند.
جمعبندی
حمله Cryptographic Context Injection نشان میدهد که Prompt Injection در Agentهای مجهز به ابزار میتواند فراتر از یک دستور مخرب ساده باشد.
در PoC منتشرشده توسط Adversa AI، دستور مهاجم داخل محتوای رمزنگاریشده قرار گرفت، Agent آن را در محیط اجرای خود رمزگشایی کرد و سپس، طبق گزارش پژوهشگران، خروجی رمزگشاییشده بهعنوان Context معتبرتر مورد استفاده قرار گرفت.
در نمونه Grok، این زنجیره برای استخراج اطلاعات Session و تاریخچه گفتوگوی کاربر و ارسال آن به یک مقصد خارجی طراحی شده بود. پژوهشگران میگویند این کار در آزمایش بدون کلیک یا تأیید اضافی کاربر انجام شده است.
با این حال، هیچ شواهدی از سوءاستفاده گسترده در دنیای واقعی ارائه نشده و این یافته فعلاً در سطح اثبات مفهوم پژوهشی قرار دارد.
اما پیام آن برای آینده امنیت هوش مصنوعی روشن است:
وقتی هوش مصنوعی بتواند وب را بخواند، کد اجرا کند و خودش به اینترنت متصل شود، دیگر فقط متن ورودی مدل را نمیتوان مرز امنیتی در نظر گرفت.
سوالات متداول
آیا Grok هک شده است؟
پژوهشگران یک PoC برای سوءاستفاده از زنجیرهای در Grok ارائه کردهاند؛ اما شواهدی از حمله گسترده یا سوءاستفاده واقعی از کاربران ارائه نشده است.
آیا تاریخچه چت Grok واقعاً قابل سرقت است؟
طبق PoC Adversa AI، زنجیره حمله میتواند به Context گفتوگوی فعال دسترسی پیدا کرده و آن را برای خروج به مقصد خارجی آماده کند. این موضوع در محیط آزمایشی نشان داده شده است.
آیا برای این مشکل CVE منتشر شده است؟
طبق گزارش پژوهشگران، در زمان انتشار تحقیق CVE، Patch عمومی یا شماره آسیبپذیری رسمی برای این مورد وجود نداشته است.
آیا کاربر باید روی لینک خاصی کلیک کند؟
در PoC منتشرشده، خیر. سناریو با درخواست معمولی برای خلاصهکردن یا تحلیل یک صفحه وب آغاز میشود و پژوهشگران آن را یک حمله Zero-Click توصیف کردهاند.
آیا فقط Grok در معرض چنین حملاتی است؟
خیر. Adversa روش مشابهی را علیه Gemini نیز آزمایش کرده و گزارش کرده است که موفقیت آن تا آگوست کاهش یافته است. نگرانی اصلی به معماری Agentهای هوش مصنوعی و نحوه برخورد آنها با محتوای غیرقابل اعتماد مربوط میشود.
آیا کاربران ایرانی هم باید نگران باشند؟
اصل تکنیک به کشور خاصی محدود نیست. هر کاربری که از Agentهای هوش مصنوعی دارای قابلیت مرور وب، اجرای کد و دسترسی به Context خصوصی استفاده میکند، از نظر معماری با همین نوع ریسک مواجه است.
-
Adversa AI — منبع اصلی پژوهش: جزئیات تکنیک Cryptographic Context Injection، نحوه اجرای حمله علیه Grok و نتایج PoC.
-
Cyber Security News — گزارش خبری ۲۲ آگوست: توضیح حمله Zero-Click و امکان استخراج اطلاعات کاربر و تاریخچه مکالمه.
-
GBHackers — تحلیل فنی: بررسی استفاده از AES-256-GCM، PBKDF2 و محیط Python برای اجرای زنجیره حمله.