اپل و آینده یک هکر؛ وقتی مک‌مینی همیشه‌روشن من هک شد و خود عامل هوش مصنوعی نجاتم داد
هک رشد جهان هک رشد

اپل و آینده یک هکر؛ وقتی مک‌مینی همیشه‌روشن من هک شد و خود عامل هوش مصنوعی نجاتم داد

۱۵ مهر ۱۴۰۵ ⏱ ۹ دقیقه مطالعه 👁 ۰ بازدید ✍️ تحریریه رشدینو
✈️ اشتراک در تلگرام 💬 واتساپ 𝕏 توییتر
📌 نکات کلیدی و خلاصه خبر پاسخ سریع در یک نگاه

بن تامپسون روایت می‌کند چگونه آسیب‌پذیری macOS (CVE-2026-65400) روی مک‌مینی همیشه‌روشنش اکسپلویت شد و چرا سیستم مجوزهای TCC اپل برای میزبان‌کردن عامل‌های هوش مصنوعی به معماری نامناسبی تبدیل شده است.

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

مقام‌های هلندی هشدار داده‌اند یک آسیب‌پذیری پرخطر در macOS که به مهاجمان اجازه اجرای کد مخرب می‌دهد، فعالانه در حال اکسپلویت است. مرکز امنیت سایبری ملی هلند (NCSC) اوایل همین هفته هشدار داد: «مرکز امنیت سایبری ملی اعلانی دریافت کرده که نشان می‌دهد سوءاستفاده فعال از این آسیب‌پذیری روی چندین سیستم که پورت ۵۹۰۰ آن‌ها از اینترنت در دسترس بوده، مشاهده شده است. در همه این موارد دسترسی root به سیستم آسیب‌دیده حاصل شده و یک ماینر رمزارز Monero روی آن نصب شده است.»

این آسیب‌پذیری با شناسه CVE-2026-65400 هفته گذشته وصله‌ای از اپل برای macOS Tahoe، Sequoia و Sonoma دریافت کرد. شدت آن ۷٫۱ از ۱۰ ارزیابی شده و ریشه‌اش باگی در قابلیت اشتراک‌گذاری صفحه macOS است که به طرفی راه دور اجازه می‌دهد وقتی ماشین روشن است، صفحه را ببیند و کیبورد و ماوس را کنترل کند. علت زیربنایی، نقصی در «مدیریت وضعیت» است؛ سامانه‌ای که رویدادهای پیشین، تعامل‌های کاربر، متغیرها و دیگر وضعیت‌های سیستم را پیگیری می‌کند.

ویدیویی از اجرای این اکسپلویت در دسترس است. جزئیات CVE-2026-65400 در کنفرانس امنیتی Black Hat هفته گذشته علنی شد. اپل هفته گذشته گفت این آسیب‌پذیری «ممکن است» به مهاجمی بدون اعتبارنامه اجازه دسترسی به یک مک را بدهد. روشن نیست چرا اپل این‌قدر محافظه‌کارانه حرف زده، اما نرم‌کردن لحن در افشای آسیب‌پذیری میان توسعه‌دهندگان فناوری رایج است. اپل این آسیب‌پذیری را به اعتبار شرکت امنیتی Bynario که آن را گزارش کرده، ثبت کرده است.

کامپیوتر مورد بحث، مک‌مینی همیشه‌روشن من بود که هیچ‌چیز جز Claude و Codex روی آن اجرا نمی‌شود؛ و اولین نکته جالب این ماجرا این است که همین موضوع نجاتم داد.

محافظت عامل

درباره Gecko صحبت کرده‌ام — هم در «Writing Things Down» و هم در چند قسمت از پادکست Sharp Tech؛ عاملی که برای کسانی که با من کار می‌کنند ساخته‌ام. Gecko فوق‌العاده است اما عمداً در توانایی و دسترسی محدود نگه داشته شده. عامل واقعی من یک ترد اختصاصی Claude Code است که همه ایده‌هایم را می‌نویسد و وضعیت پروژه‌های متعددی که در ماه‌های گذشته راه انداخته‌ام را پیگیری می‌کند.

چند دلیل دارم که برای این کار از Claude استفاده می‌کنم، هرچند از لحن و زبان Claude خوشم نمی‌آید: Claude در محیط Code، بحث‌های گسترده را بهتر از Codex مدیریت می‌کند و دستورهایم درباره اینکه چطور چیزی را بنویسد، راحت‌تر پیروی می‌کند. Codex هم یک ابزار پایش دائمی دارد که من از آن به‌عنوان صندوق ورودی برای ثبت تعامل‌ها استفاده می‌کنم؛ هم با یک تخته وضعیت که برای پیگیری بصری همه چیزهایی که نوشته‌ام ساختم و هم با یک ربات تلگرام. (ابزار جدید Dots از OpenAI بخشی از این قابلیت را فراهم می‌کند؛ چیزی که در ChatGPT و Codex به‌شدت کم بود.)

همین ابزار پایش هر ۳۰ دقیقه از کار می‌افتد و عاملم آن را طبق زمان‌بندی دوباره راه‌اندازی می‌کند؛ و همین مسئله بود که یک اعلان فوری از Claude فعال کرد:

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

همه این‌ها پیش از آن رخ داد که مقاله Ars Technica را درباره این آسیب‌پذیری پیدا کنم و واقعاً قابل توجه بود. درک می‌کنم که مردم درباره دادن دسترسی عامل‌ها به کامپیوترشان نگران‌اند — همان‌طور که گفتم، مک‌مینی مورد بحث هیچ‌چیز جز Codex و Claude نداشت — اما در این مورد می‌توان ادعا کرد اگر عاملی به‌طور مداوم در حال اجرا نبود، وضعیتم بسیار بدتر می‌شد.

محافظت اپل

به نظر می‌رسد اپل چندان از عامل‌ها خوشحال نیست؛ هفته گذشته سایت توسعه‌دهندگان این شرکت یادداشتی با عنوان «تغییرات دسترسی کامل به دیسک در macOS» منتشر کرد. متن آن را کامل نقل می‌کنم:

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

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

اینکه بگویم از اینکه راه‌حل اپل چه شکلی خواهد بود عصبی‌ام، توصیف بسیار ناکافی است. یک جنبه هست که مک را میزبان بی‌نقص عامل می‌کند: اپل دهه‌ها روی ترکیبی از قابلیت اسکریپت‌نویسی، خودکارسازی و APIهای دسترسی‌پذیری (که اغلب همان یک چیزند) سرمایه‌گذاری کرده و مک را فوق‌العاده مناسب «کاربرد کامپیوتری» عامل‌ها کرده است. از آن مهم‌تر، macOS یک سیستم یونیکس تأییدشده است؛ یعنی عامل‌ها که برای خط فرمان ساخته شده‌اند، به تمام جهان ابزارهای ساخته‌شده برای سیستم‌های یونیکس دسترسی دارند. و البته سخت‌افزار مک فوق‌العاده است.

مشکل اینجاست که برای کاربرد خاص من — یک مک‌مینی بدون نمایشگر و همیشه‌روشن که عمدتاً از کامپیوترهای دیگر و از موبایل از طریق اپ‌های ChatGPT و Claude به آن دسترسی دارم — macOS بسیار سخت‌گیر و خصمانه است. بزرگ‌ترین مشکل، اعلان‌های مجوز فقط-گرافیکی است که برای نرم‌افزارهای در حال اجرا روی همان کامپیوتر، از جمله عامل‌ها، نامرئی‌اند.

این اعلان‌های مجوز بخشی از زیرسیستم macOS به نام Transparency, Consent, and Control یا TCC هستند، هرچند اپل ظاهراً دیگر این نام را به کار نمی‌برد. چیزهای زیادی روی مک شما تحت پوشش TCC است — فهرستش با هر نسخه سیستم‌عامل بلندتر می‌شود — و باید دسترسی هر اپ به هر آیتم پوشش‌داده‌شده را صریحاً تأیید کنید. اگر تا حالا برای دسترسی به دوربین یا، به‌شکل آزاردهنده‌تر، دسکتاپ و پوشه دانلودها اعلان مجوز دیده‌اید، با TCC روبه‌رو شده‌اید.

این سیستم روی مک اصلی شما آزاردهنده اما قابل مدیریت است؛ روی مکی بدون نمایشگر که عامل‌ها را اجرا می‌کند یک فاجعه است، به دو دلیل. اول اینکه عامل‌ها مدام برنامه‌های جدید می‌نویسند و در مورد من این برنامه‌ها به دستگاه‌های شبکه نیاز دارند (اشتراک‌های SMB مثلاً هشدار TCC را فعال می‌کنند). آنچه من لازم دارم یک لایه مجوز برای خود عامل‌هاست، نه برنامه‌هایی که آن‌ها می‌سازند؛ TCC در سطح انتزاع اشتباهی کار می‌کند.

دوم اینکه زیرسیستم TCC اعلانش را در فضایی محافظت‌شده بیرون می‌دهد که هیچ برنامه‌ای نمی‌تواند ببیند؛ یعنی برنامه‌ها بی‌صدا شکست می‌خورند و عامل‌ها نمی‌دانند چرا. کاری که من باید بکنم این است که یادم باشد احتمالاً اعلانی روی صفحه هست، با نرم‌افزار اشتراک صفحه به مک‌مینی لاگین کنم و روی OK بزنم.

برای این طراحی دلیل خوبی هست: هدف TCC محافظت از شما در برابر بدافزار است و اگر اعلان‌ها از سوی برنامه‌های یوزرلند قابل خواندن بودند، بدافزار می‌توانست دورشان بزند. اما من کامپیوتری را اجرا می‌کنم که هدفی جز میزبانی عامل‌ها ندارد؛ برای مورد استفاده من TCC چیزی جز دردسر نیست — دردسری که به شکل غیرمستقیم به هک‌شدنم انجامید.

نارضایتی از اپل

باز هم از Ars Technica: «همان‌طور که NCSC اشاره کرده، از این آسیب‌پذیری وقتی پورت ۵۹۰۰ در معرض اینترنت باشد سوءاستفاده می‌شود. وقتی اشتراک صفحه روشن باشد، فایروال macOS این پورت را باز می‌کند. روترها و فایروال‌های اختصاصی عموماً این پورت را مسدود می‌کنند مگر آنکه برای نقض آن تنظیم شده باشند. کارشناسان امنیت به کاربران مک توصیه می‌کنند این پورت را حتی در زمان استفاده از اشتراک‌گذاری صفحه بسته نگه دارند و به‌جای آن از VPN یا تونل SSH استفاده کنند. جایگزین‌ها اقداماتی خارج از توان بیشتر کاربران است.»

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

طبعاً باید از VPN استفاده می‌کردم و از این پس می‌کنم؛ پایه کل رویکرد من به امنیت Tailscale است. اما این را می‌گویم: TCC اساساً چاره‌ای برایم نمی‌گذارد جز اینکه اشتراک‌گذاری صفحه روشن باشد اگر بخواهم واقعاً از مک‌مینی‌ام آن‌طور که می‌خواهم استفاده کنم. مرتب از اشتراک صفحه استفاده می‌کنم — از جمله از موبایلم — و تقریباً هر بار برای زدن OK روی یک اعلان احمقانه که مدت‌هاست دیگر جدی‌اش نمی‌گیرم. دلیل اینکه از ابتدا تنها به Tailscale تکیه نکردم این بود که می‌خواستم راه دومی هم برای رسیدن به مک‌مینی داشته باشم (که باید تونل SSH می‌بود؛ باز هم، تا حدی خجالت‌آور است و تقصیر خودم).

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

چیزی که نمی‌دانستم این بود که این تنظیم در واقع به بیشتر به‌روزرسانی‌های امنیتی اعمال نمی‌شود. وصله‌های CVE تقریباً همیشه در نسخه‌های نقطه‌ای (point release) می‌آیند؛ و جدیدترین نسخه نقطه‌ای هم دقیقاً برای رفع همین باگ بود. ناگهان فهمیدم سال‌ها خودم را بیش از اندازه در معرض خطر گذاشته‌ام، بر پایه این تصور اشتباه که تیک‌زدن گزینه «نصب خودکار به‌روزرسانی‌های امنیتی» واقعاً به‌روزرسانی‌ها را خودکار نصب می‌کند.

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

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

همین مسئله، یادداشت اپل درباره دسترسی کامل به دیسک را نگران‌کننده‌تر می‌کند. می‌فهمم که کاربران ممکن است درک نکنند دادن دسترسی کامل به دیسک به یک عامل یعنی آن عامل می‌تواند پیام‌های آیمسیج شما را بخواند (فعلاً؛ شرط می‌بندم ذخیره‌گاه آیمسیج در آینده نزدیک رمزنگاری شود، مثل آیتونز در دهه ۲۰۰۰). اما کاربران دیگری ممکن است دقیقاً همین را بخواهند؛ یا مثل من بخواهند واقعاً از مک به‌عنوان کامپیوتر شخصی خودشان استفاده کنند، نه به‌عنوان دستگاهی تحت مدیریت اپل که هر روز بیشتر به آیفون شبیه می‌شود. شاید این ماجرا نشان می‌دهد من برای پذیرش این ریسک بیش از حد نادانم؛ یا شاید فقط یعنی اپل و من بعد از سال‌ها همراهی، دارند از کنار هم رد می‌شوند.

❓ پرسش‌های متداول درباره این خبر

موضوع اصلی گزارش «اپل و آینده یک هکر؛ وقتی مک‌مینی همیشه‌روشن من هک شد و خود عامل هوش مصنوعی نجاتم داد» چیست؟

بن تامپسون روایت می‌کند چگونه آسیب‌پذیری macOS (CVE-2026-65400) روی مک‌مینی همیشه‌روشنش اکسپلویت شد و چرا سیستم مجوزهای TCC اپل برای میزبان‌کردن عامل‌های هوش مصنوعی به معماری نامناسبی تبدیل شده است.

این رویداد چه اهمیتی برای فعالان کسب‌وکار و فناوری دارد؟

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

# هک رشد
🔗 اخبار مرتبط

بخوانید