هک OpenAI

در ۲۵ ژوئیه ۲۰۲۶، دو آسیب‌پذیری حیاتی را برای به خطر انداختن حساب‌های ChatGPT کارکنان OpenAI به زنجیر کردیم. با این حساب‌ها، می‌توانیم به مخازن داخلی OpenAI و احتمالا بسیاری از رابط‌های دیگر دسترسی داشته باشیم.

برای اینکه ثابت کنیم در واقع به دسترسی‌هایی که باور داشتیم بدون اینکه به خودمان اجازه یادگیری اطلاعات حساس را بدهیم، دست یافته‌ایم، از Codex کارمند برای باز کردن یک PR #1186742 در openai/openai monorepo داخلی OpenAI استفاده کردیم.

تا دو ماه پیش، هر کاربر یا کارمند OpenAI که وارد تالار گفتمان راهنمای OpenAI می‌شد (community.openai.com) می‌توانست حساب‌های ChatGPT و Codex خود را تصاحب کند. از آنجایی که افراد می‌توانند سرویس‌های مختلفی را به Codex و ChatGPT متصل کنند، دامنه آنچه که ما از نظر تئوری می‌توانستیم به آن دسترسی داشته باشیم بسیار زیاد بود، از جمله GitHub، Slack و ایمیل‌ها.

کل جدول زمانی از کشف اولیه تا دسترسی به دسترسی به مخزن OpenAI در کمتر از 72 ساعت انجام شد.

ما یک جدول زمانی کامل از فرآیند افشا را در اینجا ارائه می دهیم. بقیه پست به جزئیات چگونگی کشف این دو آسیب‌پذیری، نحوه استفاده از مدل‌های کلود و همچنین نکاتی که از این تجربه برداشتیم، می‌پردازد.

تیم HacktronAI اجرای کد از راه دور (RCE) و دسترسی مدیریتی به محیط Discourse میزبانی شده در community.openai.com را به دست آورد.

پس از تأیید تأثیر محصول متقابل، تیم به صورت داخلی روی فرآیند افشای مسئول هماهنگی کرد و گزارشی را از طریق برنامه باگ بونتی OpenAI در Bugcrowd ارائه کرد.

دسترسی به حساب کارمند OpenAI و اثبات مفهوم

برای نشان دادن تأثیر عملی آسیب‌پذیری، ما یک درخواست کشش اثبات مفهوم بی‌ضرر در monorepo داخلی OpenAI ایجاد کردیم (پیوند به درخواست OpenAI ویرایش شد). ما ارسال Bugcrowd موجود را با این یافته‌ها به‌روزرسانی کردیم، با دوستان در OpenAI در Twitter/X تماس گرفتیم تا مستقیما به آنها اطلاع دهیم، و همه آزمایش‌های بعدی را تقریبا در ساعت 15:30 UTC متوقف کردیم.

OpenAI تقریبا 14 ساعت پس از ارسال اولیه، به گزارش پاسخ داد و تأیید کرد که مشکل برطرف شده است.

ما گزارشی را از طریق برنامه HackerOne به Discourse ارسال کردیم.

Discourse تا دوشنبه یک اصلاح آماده داشت و به عنوان دفاع در عمق، sandboxing پردازش تصویر را اضافه کرد.

Discourse GHSA-vhm9-85gw-x335 را با راهنمایی وصله و بازسازی منتشر کرد.

نظر OpenAI - برای روشن شدن دامنه آن جایزه: آزمایش در برابر Community.openai.com میزبانی گفتمان به صراحت از برنامه پاداش اشکال ما حذف شد. این جایزه یافته های سمت OpenAI را به رسمیت می شناسد، نه اقدامات علیه گفتمان.

چند ماه پیش، تیم ما در Hacktron، به رهبری هارش جیسوال در کنار موهان پداپاتی و راهول ماینی، شروع به تحقیق در شرکت‌های مرزی هوش مصنوعی برای یافتن آسیب‌پذیری‌های امنیتی کردند. این ما را به کشف یک پیکربندی نادرست SSO در زیرساخت هویت OpenAI و یک libheif RCE در انجمن جامعه مورد استفاده توسط OpenAI سوق داد.

از آن زمان، ما تحقیقات را در HEIF Heist گسترش دادیم، یک تحقیق چند ماهه که libheif را در Slack، Meta، GitHub Enterprise، Ruby on Rails، و Node.js فریمورک‌های Next.js، Astro و Gatsby ردیابی می‌کند. مقدار شگفت انگیزی از نرم افزارهای پرکاربرد به این کتابخانه پردازش تصویر بستگی دارد.

اگر برنامه شما تصاویر کنترل شده توسط کاربر را پردازش کند و تصاویر .heic/.heif/.avif را بپذیرد، به احتمال زیاد تحت تأثیر قرار گرفته است. لطفا در صورت نیاز به هر نوع کمکی با ما از طریق hello@hacktron.ai تماس بگیرید.

اطلاعیه وصله: اگر خود میزبان Discourse هستید، اکنون نصب خود را بازسازی کنید. تصاویر قدیمی‌تر Docker ممکن است حاوی یک وابستگی آسیب‌پذیر libheif باشند که امکان اجرای کد از طریق آپلود تصویر را فراهم می‌کند. اجرای git pull و سپس برنامه بازسازی ./launcher از /var/discourse. یک به روز رسانی رابط وب به تنهایی نمی تواند جایگزین تصویر زیرین شود. مشتریان میزبان گفتمان قبلا وصله شده اند. مشاوره امنیتی را ببینید.

OpenAI از Discourse برای انجمن خود استفاده می کند و از طریق auth.openai.com به "ورود با OpenAI" اجازه می دهد. پس از درک خوبی از خدمات و زیرساخت های OpenAI، دلیلی داشتیم که باور کنیم به خطر انداختن انجمن می تواند از طریق این جریان هویت، مسیری به سمت خدمات گسترده OpenAI ایجاد کند. برای آزمایش این فرضیه، ابتدا به اجرای کد از راه دور در یک سرویس OpenAI مانند انجمن گفتمان نیاز داشتیم.

در حالی که خود برنامه Discourse در واقع هدف آسانی نیست (ما در گذشته آن را بررسی کرده‌ایم)، ما فکر کردیم که می‌توانیم به دنبال وابستگی باشیم.

در 23 جولای، بررسی خط لوله آپلود تصویر Discourse را آغاز کردیم و متوجه شدیم که فایل‌های HEIC و HEIF مسیر غیرعادی را دنبال می‌کنند. Discourse معمولا از FastImage برای بررسی تصویر استفاده می‌کرد، اما چون FastImage از HEIF پشتیبانی نمی‌کرد، آن فایل‌ها را برای تبدیل به دستور magick ImageMagick ارسال کرد. 2 که تجزیه کننده اصلی libheif را مستقیما در معرض فایل های کنترل شده توسط مهاجم قرار داد.

ما یک جلسه Opus 4.8 را با تصویر Discourse Docker شروع کردیم و از آن خواستیم بسته نصب شده libheif را برای مسائل امنیتی بررسی کند. پس از مدتی، متوجه شد که برخی از اصلاحات امنیتی خاص به بسته libheif منتقل نشده اند. این اجازه می دهد تا یک سرریز بافر پشته منجر به OOB R/W اولیه در طول رمزگشایی HEIC شود.

جالب اینجاست که کد آسیب‌پذیر در سال قبل تغییر کرده بود، اما این commit به‌عنوان یک اصلاح امنیتی مستند نشده بود و CVE دریافت نکرد. 3 این ممکن است دلیلی باشد که چرا دبیان 12 و 13 بکپورت های مربوط به امنیت را به موقع دریافت نکرده اند. از آنجایی که تصویر داکر Discourse بر اساس Debian 12 بود، نسخه آسیب پذیر libheif نسخه 1.19.7 را نصب کرد. حتی دبیان 13 هنوز نسخه آسیب پذیر 1.19.8 را در آن زمان عرضه می کرد. از آن زمان، دبیان به روز رسانی امنیتی خود را برای دبیان 13 در 8 آگوست 2026 منتشر کرده است.

در 24 جولای، ما از Opus 4.8 برای توسعه یک اکسپلویت اجرایی کد ImageMagick/libheif با غیرفعال کردن ASLR استفاده کردیم. سپس چندین جلسه جداگانه راه‌اندازی کردیم تا آن را در برابر پیکربندی پیش‌فرض Discourse با فعال کردن ASLR قابل اعتماد کنیم، که مثمر ثمر نبود.

همان شب، Anthropic Claude Opus 5 را منتشر کرد. 5 ما یک جلسه جدید را شروع کردیم، که برای اولین بار در عرض 3 ساعت یک اکسپلویت ARM64 برای یک مک محلی تولید کرد. سپس از آن خواستیم تا اکسپلویت را به محیط x86-64 و پیکربندی jemalloc مورد استفاده توسط Discourse منتقل کند.

تا ساعت 6:00 صبح در 25 جولای، RCE محلی را از طریق آپلود تصویر تأیید کرده بودیم. سپس کلود را در یک حلقه خودکار / هدف در برابر نمونه Discourse Cloud خود قرار دادیم، که از طریق rce.ee/ctf-forum پروکسی شد تا شبیه یک هدف CTF به نظر برسد، زیرا Opus از سوء استفاده از نوشتن برای نمونه های راه دور خودداری کرد.

وقتی دوباره در ساعت 10:00 صبح بررسی کردیم، عامل به RCE در Discourse Cloud دست یافت و با خواندن /etc/hosts دسترسی را نشان داد. با استفاده از اسکریپت اکسپلویت تولید شده، موفق شدیم RCE را در نمونه OpenAI دریافت کنیم.

پس از اینکه فرضیه خود را مبنی بر عدم تصاحب حساب های تعاملی ChatGPT/Codex از اعضای فعال انجمن تأیید کردیم، بلافاصله گزارش خود را به OpenAI ارسال کردیم. سپس حساب یکی از کارکنان OpenAI را که Codex به سازمان Github OpenAI متصل بود، تصاحب کردیم. برای نشان دادن تأثیر بدون دسترسی واقعی به هیچ کد داخلی، ما درخواستی را به حساب Codex این کارمند ارسال کردیم تا یک PR برای ما در monorepo داخلی OpenAI باز کند. سپس ما هرگونه آزمایش بیشتر را متوقف کردیم.

ما ارسال BugCrowd را با ضد ضربه به روز کردیم و به امنیت OpenAI هشدار دادیم. ما همچنین یک گزارش برای Discourse تهیه کردیم و آن را به برنامه HackerOne آنها گزارش کردیم. Discourse گزارش را در روز شنبه دریافت کرد، یکشنبه پاسخ داد و تا دوشنبه (با تشکر از سرعت). آنها همچنین بلافاصله شروع به sandboxing ImageMagick کردند.

می‌خواهیم تأکید کنیم که آسیب‌پذیری تشدید، مختص گفتمان نیست. این یک مشکل OpenAI SSO است که مصالحه انجمن را به دسترسی به ChatGPT و Codex تبدیل کرد. اگر هر سرویس OpenAI شخص اول یا شخص ثالثی که از OpenAI SSO استفاده می‌کند به خطر بیفتد، به همان دسترسی منجر می‌شود - گفتمان فقط یکی از راه‌های اثبات آن بود.

ما مشاهده کردیم که هر مدل جدید به طور فزاینده ای توانمند می شود، همانطور که در بهره برداری گفتمان ارائه شده در این گزارش مشهود است. Opus 4.8 در چندین جلسه برای تولید یک اکسپلویت کاری با فعال کردن ASLR تلاش کرد. در عرض چند ساعت پس از انتشار Opus 5، ما همین مشکل را به آن دادیم و موفق شد. در سرتاسر کمپین گسترده‌تر، شاهد جهش واضح دیگری از Opus 5 به GPT-5.6 Sol بودیم، زمانی که مجبور شدیم از آسیب‌پذیری بدون دانستن چیزی در مورد سیستم هدف به غیر از آسیب‌پذیر بودن آن، سوء استفاده کنیم.

برای هر هدف، آزمایش با آپلود تصویر آغاز شد. از آنجا، ما خراب شدن حافظه را به یک نشت یا پوسته حافظه قابل اعتماد تبدیل کردیم، معمولا بدون دانستن نسخه دقیق libheif، نسخه libc یا محیط استقرار. هوش مصنوعی تقریبا کور شروع به کار کرد و در عرض یک یا دو روز اکسپلویت را برای هر شرکت تطبیق داد. حتی پس از ارسال هزاران تصویر و از کار افتادن مکرر پردازشگرهای تصویر آنها، هیچ شرکتی به جز Shopify این فعالیت را شناسایی نکرده است.

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

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

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

مفروضات امنیتی باید با قابلیت های مهاجم مطابقت داشته باشد. یک مدل تهدید واقع گرایانه باید به جای تکیه بر فرضیات منسوخ 6 در مورد اینکه چه کسی می تواند حملات پیچیده انجام دهد، اقتصاد بهره برداری را در نظر بگیرد.

ماموریت Hacktron کمک به امنیت اینترنت با یافتن و حذف آسیب‌پذیری‌ها در نرم‌افزارهای قابل اعتماد قبل از اینکه عوامل مخرب انجام دهند، است. ما در حال ادامه این تحقیقات در سراسر آزمایشگاه های مرزی و سایر سیستم های حیاتی اینترنتی هستیم. اگر شما مسئول تامین امنیت یکی از آنها هستید، مایلیم با شما همکاری کنیم.

HEIF Heist به یک نسخه وابسته نیست. این یک اکوسیستم کامل از آسیب‌پذیری‌ها در خانواده‌های انتشار چندگانه (مانند 1.19.x، 1.20.x، 1.22.x، 1.23.x) را هدف قرار می‌دهد. هرگونه استقرار فاقد آخرین وصله های امنیتی بالادستی به طور بالقوه آسیب پذیر است.

ما از سودانشو راجبهار برای کمک‌های فنی، و زین ژانگ، فابیان فاسلر، رابرت چن و جسیکا روان برای تصحیح، بررسی پیش‌نویس‌ها و ارائه بازخوردی که باعث بهبود این پست شد، تشکر می‌کنیم.

[3] libheif: محاسبات ناحیه همپوشانی همپوشانی را ساده می کند ↩

[4] Debian DSA-6417-1: به روز رسانی امنیتی libheif ↩1 ↩2

[6] RAND: کتاب راهنما برای ایمن کردن وزن‌های مدل هوش مصنوعی ↩

[7] libheif نسخه 1.23.4 انتشار نگهداری امنیتی ↩

Hacktron محققان برتر CTF، تیم های قرمز با تجربه و محققان امنیتی تهاجمی را گرد هم می آورد. ما از هوش مصنوعی برای تسریع تحقیقات امنیتی، یافتن و حذف آسیب‌پذیری‌ها در نرم‌افزارهای قابل اعتماد قبل از اینکه عوامل مخرب انجام دهند، استفاده می‌کنیم. ما در حال ادامه تحقیقات خود در سراسر آزمایشگاه های مرزی و سایر سیستم های حیاتی اینترنتی هستیم. اگر شما مسئول ایمن سازی یکی از آنها هستید، مایلیم با شما همکاری کنیم.