گواهی‌های دیجیتال هم از ارتباطات TLS محافظت می‌کنند و هم برای امضای دیجیتال برنامه‌ها به کار می‌روند؛ با این حال، هر از گاهی نمونه‌های جعلی آنها نیز در حملات واقعی مورد سوءاستفاده قرار می‌گیرند. پیش‌تر شاهد سوءاستفاده گروه APT موسوم به DarkHotel و بدافزار Flame از گواهی‌های جعلی یا سرقت‌شده بوده‌ایم. همچنین در سال ۲۰۱۱، پس از به خطر افتادن مرجع صدور گواهی Comodo، تلاش‌هایی برای انجام حمله با استفاده از گواهی‌های آن مشاهده شد.
اجرای چنین حمله‌ای معمولاً به تخصص فنی قابل‌توجهی نیاز دارد. اما در سال ۲۰۲۶، حمله به گواهی‌های eMudhra تقریباً به هیچ مهارت ویژه‌ای نیاز ندارد. مهاجم کافی است عددی بین ۱ تا ۲۵۵ را حدس بزند.
کلیدهای خصوصی مربوط به مراجع صدور گواهی میانی معمولاً اعداد بسیار بزرگی هستند. اما در این مورد، هشت کلید خصوصی به این اعداد تبدیل شده بودند:
۴، ۵۶، ۶۶، ۱۱۵، ۱۵۵، ۱۵۶، ۲۳۰ و ۲۳۷
این مقادیر را می‌شد با استفاده از کلیدهای عمومی موجود در گواهی‌های عمومی، در کمتر از یک ثانیه به دست آورد. در نتیجه، یک مهاجم فرضی می‌توانست با استفاده از یکی از این کلیدهای خصوصی به خطر افتاده، برای هر دامنه‌ای گواهی صادر و آن را امضا کند.
شش مورد از این کلیدها برای صدور گواهی‌های TLS و دو مورد دیگر برای امضای کد (Code Signing) در نظر گرفته شده بودند. هر هشت مرجع صدور گواهی میانی (CA) نیز توسط مرجع صدور گواهی Sectigo به‌صورت متقابل امضا شده بودند. این موضوع به این معناست که کلاینت‌هایی با زنجیره‌های اعتماد متفاوت نیز ممکن بود یک گواهی جعلی را معتبر تلقی کنند.
مرورگرهای اصلی تاکنون زنجیره‌های گواهی خطرناک را مسدود کرده‌اند. با این حال، تیم‌های فناوری اطلاعات و امنیت همچنان باید ریسک موجود در بسیاری از سیستم‌های دیگر سازمان را ارزیابی و برطرف کنند.
اسکریپت‌های مربوط به پردازش زمان‌بندی‌شده داده‌ها، فایروال‌های نسل جدید سازمانی (NGFW)، سرورهای مانیتورینگ، برنامه‌هایی که مخزن گواهی داخلی دارند و دستگاه‌هایی که به‌طور منظم به‌روزرسانی نمی‌شوند، ممکن است گواهی‌های جعلی را بپذیرند و در برابر حملات مرد میانی (MitM) آسیب‌پذیر باشند. کلیدهای موردنیاز برای انجام چنین حملاتی نیز از قبل در ابزارهای رهگیری عمومی موجود هستند.
جدول زمانی رخداد مرجع صدور گواهی eMudhra
کلیدهای مشکل‌دار بخشی از مجموعه‌ای شامل ۲۴ مرجع صدور گواهی میانی بودند که eMudhra در ۳۰ آوریل ۲۰۲۵ ایجاد کرده بود.
به‌جای استفاده از مقادیر کاملاً تصادفی رمزنگاری‌شده برای یک منحنی بیضوی ۳۸۴ بیتی، مشخص شد که هشت کلید دارای مقادیر عددی بسیار کوچک هستند.
بر اساس توضیحات خود eMudhra، یک مرحله با عنوان «wrap/unwrap کلید» هنگام تولید کلیدها باعث ایجاد مجموعه دومی از کلیدهای ضعیف شده بود.
از آنجا که کلیدها در یک دستگاه اختصاصی موسوم به ماژول امنیت سخت‌افزاری (HSM) ایجاد و ذخیره می‌شوند، شناسایی یک کلید ضعیف به‌تنهایی دشوار است. هنوز مشخص نیست چه خطایی باعث شد کلیدها دو بار تولید شوند و مجموعه ضعیف مورد استفاده قرار گیرد؛ بررسی این موضوع همچنان ادامه دارد.
در ماه مه ۲۰۲۵، مرجع صدور گواهی Sectigo هر هشت گواهی میانی را امضا کرد.
سپس در ۱۷ اکتبر ۲۰۲۶، یک پژوهشگر مستقل تیم‌های امنیتی Mozilla، Google و Apple و همچنین خود مرجع صدور گواهی را مطلع کرد که این کلیدها قابل بازیابی هستند.
در ۲۰ اکتبر، Mozilla این رخداد را به‌صورت عمومی اعلام کرد.
این بدان معناست که طی تقریباً یک سال و نیم، امکان بازیابی این کلیدها و جعل گواهی‌ها وجود داشته است.
در ۲۲ اکتبر، eMudhra اعلام کرد که از کسب‌وکار جهانی صدور گواهی‌های SSL/TLS خارج خواهد شد.
مهاجم چه کاری می‌تواند انجام دهد؟
با استفاده از مراجع صدور گواهی میانی آسیب‌پذیر، مهاجم می‌تواند برای دامنه‌ای متعلق به فرد یا سازمان دیگر، یک گواهی جعلی صادر و آن را امضا کند.
کلاینت‌هایی که همچنان به آن زنجیره اعتماد دارند و هیچ سازوکار حفاظتی دیگری روی آنها فعال نیست، گواهی جعلی را به‌عنوان گواهی سرور واقعی می‌پذیرند.
البته داشتن یک گواهی به‌تنهایی برای رهگیری ترافیک HTTPS کافی نیست. مهاجم همچنین باید راهی برای دستکاری ترافیک قربانی یا تغییر مسیر اتصال پیدا کند.
برای مثال، این اتفاق می‌تواند در یک شبکه سازمانی به خطر افتاده، روی یک نقطه دسترسی Wi-Fi تحت کنترل مهاجم یا از طریق دستکاری مسیریابی و DNS رخ دهد. چنین حملاتی در دنیای واقعی نیز اتفاق افتاده‌اند؛ حملات DarkHotel از جمله نمونه‌هایی هستند که این موضوع را نشان می‌دهند.
خطر دیگری نیز وجود دارد: دو مورد از این کلیدها برای امضای کد قابل استفاده هستند.
در تئوری، این موضوع می‌تواند به مهاجم اجازه دهد بدافزاری را منتشر کند که ظاهراً از سوی یک تولیدکننده نرم‌افزار معتبر ارائه شده است و هنگام نصب، هشدارهای امنیتی جدی سیستم‌عامل را نیز فعال نمی‌کند.
آیا از این آسیب‌پذیری‌ها سوءاستفاده شده است؟
متخصصان شرکت‌های مختلف که پیامدهای این رخداد را بررسی کرده‌اند، تاکنون هیچ حمله مخربی را که از این گواهی‌ها استفاده کرده باشد شناسایی نکرده‌اند. eMudhra و CERT-In نیز اعلام کرده‌اند که هیچ موردی از سوءاستفاده مشاهده نکرده‌اند.
تیم Chrome نیز هیچ گواهی صادرشده از سوی شش CA را در لاگ‌های عمومی Certificate Transparency (CT) پیدا نکرده است.
این موضوع نشان می‌دهد سیستم‌هایی که مرورگرهای آنها گواهی‌ها را از طریق Certificate Transparency بررسی می‌کنند، به احتمال زیاد هدف حمله قرار نگرفته‌اند.
اما بسیاری از دستگاه‌ها و برنامه‌ها، به‌خصوص سرورها و دستگاه‌های IoT، اصلاً Certificate Transparency را بررسی نمی‌کنند؛ بنابراین درباره وضعیت آنها نمی‌توان با اطمینان اظهار نظر کرد.
امروزه مهاجمان برای انجام چنین حمله‌ای دیگر لزوماً نیازی به توسعه ابزارهای هک اختصاصی ندارند. نسخه ۱۲.۳ ابزار mitmproxy که یکی از ابزارهای محبوب میان پژوهشگران امنیت است، از قبل قابلیت استفاده از کلیدهای به خطر افتاده را به‌صورت داخلی در اختیار دارد.
کجا ریسک برطرف شده و کجا نمی‌توان از رفع آن مطمئن بود؟
پلتفرم‌های اصلی، گواهی‌های به خطر افتاده را به‌سرعت ابطال کردند. Chrome از همان ۱۷ اکتبر این کار را از طریق CRLSets انجام داد و Firefox نیز از طریق OneCRL اقدام کرد. در ۱۸ اکتبر، خود eMudhra گواهی‌ها را با ذکر دلیل «به خطر افتادن CA» (CA Compromise) ابطال کرد. Apple در ۱۹ اکتبر اقدام مشابهی انجام داد و CA شرکت Sectigo نیز نسخه‌های دارای امضای متقابل را ابطال کرد. Microsoft هم در ۲۰ اکتبر گواهی‌ها را ابطال کرد.
بسته به تنظیمات سیستم‌عامل و برنامه مورد استفاده، ممکن است ابطال حتی بدون به‌روزرسانی خود برنامه نیز اعمال شده باشد؛ زیرا فهرست‌های مسدودسازی اغلب به‌صورت جداگانه به‌روزرسانی می‌شوند.
در همین حال، یک اقدام اساسی‌تر نیز در حال انجام است: سلب اعتماد از Root CA.
Chrome اعلام کرده است که قصد دارد گواهی ریشه «emSign ECC Root CA – G3» را از مرورگر خود حذف کند. گواهی‌هایی که تحت Root CA با نام «emSign Root CA – G1» صادر شده‌اند و همچنین خود این گواهی ریشه، تحت تأثیر قرار نمی‌گیرند. برآورد eMudhra این است که حدود ۳۰ هزار گواهی باید به زنجیره دیگری منتقل شوند.
اما ابطال گواهی تنها در شرایطی مؤثر است که کلاینت بتواند از ابطال آن مطلع شود و سپس اقدامی انجام دهد. بسیاری از برنامه‌ها امضا، نام سرور و بازه اعتبار گواهی را بررسی می‌کنند، اما فهرست‌های مسدودسازی را دریافت یا به‌روزرسانی نمی‌کنند. موارد رایج عبارت‌اند از:
سیستم‌های قدیمی و LTS
وضعیت LTS (پشتیبانی بلندمدت) به‌تنهایی به معنای آسیب‌پذیر بودن یک سیستم نیست. طبق تعریف، سیستمی که چنین وضعیتی دارد همچنان پشتیبانی می‌شود.
اما کانتینرهای قدیمی، ایمیج‌های فریز‌شده سیستم‌عامل و سیستم‌هایی که دیگر به‌روزرسانی نمی‌شوند، ممکن است برای مدت طولانی همچنان به CAهای ابطال‌شده اعتماد کنند.
همه‌چیز به به‌روزرسانی بسته ca-certificates و کتابخانه‌های TLS و همچنین تنظیمات برنامه موردنظر بستگی دارد.
سیستم‌های خودکار و سرورها
در سایتی که توسط علاقه‌مندان برای بررسی نرم‌افزارهای کلاینت و شناسایی اعتماد نادرست به گواهی‌ها ایجاد شده، curl و Zabbix در میان آسیب‌پذیرترین سیستم‌ها در صدر فهرست قرار دارند.
Zabbix معمولاً برای بررسی‌های HTTP از libcurl و مخزن گواهی تنظیم‌شده برای آن استفاده می‌کند.
رفتار مشابهی نیز در curl داخلی macOS مشاهده شده است. در سطح سیستم‌عامل و در Safari، گواهی ابطال شده است؛ اما curl یک فایل ساده با مسیر /etc/ssl/cert.pem را می‌خواند و اصلاح دقیقاً باید در همین قسمت انجام شود.
این یک مثال خوب است: حتی زمانی که سازوکارهای اعتماد و ابطال در سطح سیستم‌عامل به‌درستی کار می‌کنند، برنامه‌های منفرد ــ از جمله برنامه‌هایی که به‌صورت پیش‌فرض همراه سیستم‌عامل عرضه می‌شوند ــ همچنان ممکن است آسیب‌پذیر باقی بمانند.
Python، Ruby، Go، Java و کانتینرها
یک برنامه ممکن است از مجموعه CAهای ریشه اختصاصی خودش استفاده کند؛ مجموعه‌ای که هم‌زمان با سیستم‌عامل به‌روزرسانی نمی‌شود.
بررسی‌های Endor Labs نشان داده است که بیش از ۲۵ بسته محبوب حاوی Root CA تحت تأثیر این رخداد هستند.
Slack، GitHub Desktop و سایر برنامه‌های مبتنی بر Electron
این برنامه‌ها Electron/Chromium اختصاصی خودشان را همراه با برنامه ارائه می‌کنند؛ بنابراین به‌روزرسانی جداگانه Chrome باعث به‌روزرسانی Slack نمی‌شود.
ابطال گواهی‌ها از قبل در نسخه جدید Electron اعمال شده است، اما اکنون هر توسعه‌دهنده باید برنامه خود را با نسخه جدید بازسازی و منتشر کند و هر کاربر نیز باید آن به‌روزرسانی را نصب کند.
البته نمی‌توان گفت که همه برنامه‌های Electron الزاماً آسیب‌پذیر هستند. نتیجه به نسخه مورد استفاده، نحوه به‌روزرسانی فهرست‌های مسدودسازی و نوع Network Stack مورد استفاده برنامه بستگی دارد.
مرورگرهای موبایل و دستگاه‌های IoT
Chrome، Firefox و Safari در تلفن‌های همراه، اطلاعات مربوط به ابطال گواهی‌ها را تقریباً با همان سرعت نسخه‌های دسکتاپ دریافت می‌کنند.
اما در مرورگرهای پیش‌فرض تولیدکنندگان گوشی‌های هوشمند چنین وضعیتی لزوماً وجود ندارد.
در یک آزمایش منتشرشده، Samsung Browser نسخه 31.0.0.64 هر شش زنجیره آزمایشی emSign را پذیرفت، در حالی که زنجیره‌های Sectigo را رد کرد.
در HarmonyOS نسخه‌های ۶ و ۷ نیز پژوهشگران CAهای تحت تأثیر را در فهرست Root CAهای منتشرشده توسط Huawei پیدا کردند و این CAها امکان ابطال دستی ندارند.
در مورد دستگاه‌های بدون پشتیبانی، لوازم خانگی و Firmwareهای قدیمی، ممکن است هیچ‌گاه به‌روزرسانی مخزن گواهی منتشر نشود.
در چنین شرایطی، این مشکل می‌تواند سال‌ها باقی بماند.
تأثیر بر بازرسی TLS در شبکه سازمانی
هنگامی که یک NGFW یا Web Gateway ترافیک رمزنگاری‌شده را بررسی می‌کند، دو اتصال برقرار می‌کند: یکی با کلاینت و دیگری با سرور خارجی.
کلاینت گواهی‌ای را دریافت می‌کند که توسط CA سازمان امضا شده است، در حالی که خود Gateway اعتبار و اصالت سرور خارجی را بررسی می‌کند.
اگر Gateway یک گواهی جعلی eMudhra را بپذیرد، حتی مرورگری که روی رایانه کارمند به‌روز شده است نیز زنجیره خطرناک را مشاهده نخواهد کرد. در عوض، مرورگر همان گواهی آشنای سازمانی را دریافت می‌کند.
در این سناریو، خود ابزار امنیتی مشکل را از دید کلاینت پنهان می‌کند.
البته اجرای چنین حمله‌ای همچنان به امکان رهگیری ترافیک نیاز دارد.
برای اصلاح سیاست اعتبارسنجی و فهرست گواهی‌ها روی خود دستگاه بازرسی، باید دستورالعمل‌های ارائه‌شده توسط سازنده را دنبال کنید؛ البته اگر سازنده چنین دستورالعمل‌هایی منتشر کرده باشد.
در محصولات Cisco، وضعیت این مشکل برای همه محصولات به‌صورت جزئی مستند شده است. بیشتر محصولات همچنان در وضعیت «در حال بررسی» قرار دارند، اما برای دستگاه‌های آسیب‌پذیر، اقدامات کاهشی توصیه شده است.
Sophos و Check Point وعده انتشار به‌روزرسانی نرم‌افزاری برای دستگاه‌های خود را داده‌اند و در همین فاصله، حذف دستی گواهی‌ها را توصیه می‌کنند.
هیچ‌یک از این دو شرکت تاکنون اطلاعیه امنیتی رسمی منتشر نکرده‌اند، اما کارکنان هر دو شرکت در انجمن‌های پشتیبانی خود توصیه‌هایی ارائه کرده‌اند.
برای دستگاه‌های Fortinet نیز دستورالعمل‌هایی برای بررسی و حذف گواهی‌های emSign ارائه شده است.
Palo Alto به‌جای ارائه دستورالعمل مشخص برای محصولات خود، صرفاً توصیه‌های کلی ارائه کرده است.
البته یک Gateway که به‌درستی پیکربندی شده باشد، می‌تواند به‌طور موقت از دستگاه‌های کلاینت قدیمی که همچنان به گواهی‌های خطرناک اعتماد می‌کنند محافظت کند.
برای بررسی دستگاه‌ها، سرویس‌ها، کانتینرها و ماشین‌های مجازی مشخص، می‌توان از یک وب‌سایت اختصاصی برای بررسی وضعیت اعتماد به این گواهی‌ها استفاده کرد.
همچنین یک سناریوی احتمالی برای شکار پیشگیرانه تهدیدها (Threat Hunting) با هدف شناسایی تهدیدهایی که از کلیدهای ضعیف سوءاستفاده می‌کنند یا قبلاً از آنها سوءاستفاده کرده‌اند، ارائه شده است.
