گواهی TLS غیرمجاز برای دامنه‌های گوگل؛ رجیستری سه ccTLD ربوده شد

تیم Secure Web and Networking مرورگر کروم روز ۱۴ مهر ۱۴۰۵ (۶ اکتبر ۲۰۲۶) اعلام کرد مهاجمان رجیستری سه دامنه سطح‌بالای کشوری (ccTLD) را در اختیار گرفته‌اند: .gh (غنا)، .sl (سیرالئون) و .as (ساموآی آمریکا). آن‌ها رکوردهای معتبر DNS را دست‌کاری کردند و با همین دسترسی، گواهی‌های TLS غیرمجاز — همان گواهی HTTPS — برای چند دامنه گوگل و دامنه‌های چند سازمان دیگر گرفتند.

گوگل تأکید می‌کند این رخدادها نفوذ به سیستم‌های خودش نبودند؛ مهاجمان خودِ رجیستری‌های ثالث را در اختیار گرفتند و در نتیجه «هر دامنه‌ای که به .gh، .sl یا .as ختم می‌شد در معرض خطر بود». در این زنجیره مهاجم برای گرفتن گواهی لازم نیست به سرور دارنده دامنه نفوذ کند؛ کنترل DNS معتبر کافی است. الگو آشناست: مثل نشت داده CPR دانمارک، شکست از جایی آمد که سازمان قربانی هیچ کنترلی رویش ندارد.

چرا ربایش DNS به گواهی TLS «معتبر» می‌رسد

پیش از صدور گواهی، مرجع صدور گواهی (CA) باید مطمئن شود متقاضی کنترل دامنه را در دست دارد. این مرحله اعتبارسنجی دامنه (Domain Validation) است و معمول‌ترین شکلش گذاشتن یک رکورد DNS مشخص یا یک فایل روی وب‌سرور است. هرکس روی DNS معتبر دامنه دست داشته باشد، می‌تواند همان چالش را پاسخ دهد و گواهی را از مسیر قانونی بگیرد.

به همین دلیل گوگل می‌نویسد: «با توجه به ماهیت این حملات، دلیلی نداریم باور کنیم مرجع‌های صدور گواهی که گواهی‌های متأثر را صادر کردند کار نادرستی انجام داده‌اند.» قاعده‌ها رعایت شده بود؛ اما آن قاعده‌ها فقط کنترل DNS را می‌سنجند — و سمت دیگر همین زنجیره، تأیید گواهی در کلاینت، خطای خودش را دارد.

واکنش کروم: CRLSets و لاگ‌های Certificate Transparency

کروم بی‌درنگ استفاده از گواهی‌های غیرمجاز سرویس‌های گوگل را با CRLSets بست. CRLSet فهرستی فشرده از گواهی‌های مسدودشده است که کروم بخشی از آن را با پیمایش فهرست‌های ابطال گواهی (CRL — Certificate Revocation List) منتشرشده مرجع‌ها پر می‌کند و طبق مستندات Chromium «ابزار اصلی کروم برای مسدود کردن سریع گواهی‌ها در شرایط اضطراری» به شمار می‌رود؛ همان مستندات می‌گوید نسخه CRLSet فعال را می‌توان در chrome://components دید.

هم‌زمان کروم با CAهای صادرکننده همکاری کرد تا گواهی‌ها باطل شوند و کاربران مرورگرهای دیگر هم محافظت شوند — همان گلوگاه ابطال که در افشای اعتبارنامه‌ها در GitHub هم مسئله اصلی بود. سپس لاگ‌های Certificate Transparency (CT) را مرور کرد و گواهی‌های صادرشده برای سازمان‌های متأثر دیگر را هم پیشگیرانه مسدود کرد. CT که RFC 6962 معرفی‌اش کرده، مجموعه‌ای از لاگ‌های عمومی و فقط‌افزودنی است که وجود هر گواهی TLS در آن ثبت می‌شود؛ یعنی هر صدور، یک رد عمومی به‌جا می‌گذارد.

گوگل نه تعداد گواهی‌ها را اعلام کرده و نه فهرست دامنه‌های متأثر را.

کار تیم شما: پایش CT و انتشار رکورد CAA

توصیه اول گوگل پایش پیوسته CT است، چون «پایش لاگ‌های CT تقریباً هم‌زمان به شما هشدار می‌دهد که گواهی‌ای برای دامنه‌هایتان صادر شده است». این پایش باید همه دامنه‌های سازمان را بپوشاند؛ از دامنه اصلی تا دامنه‌های پارک‌شده و دامنه‌های منطقه‌ای روی ccTLDها که معمولاً کسی سراغشان نمی‌رود.

توصیه دوم انتشار رکوردهای CAA محدودکننده همراه با مقید کردن حساب ACME است. اجازه‌نامه مرجع صدور گواهی (CAA — Certification Authority Authorization) رکوردی DNS است که RFC 8659 تعریفش کرده و با سه برچسب issue، issuewild و iodef مشخص می‌کند کدام CA اجازه صدور دارد، گواهی وایلدکارد مجاز است یا نه، و تخلف‌ها به چه نشانی گزارش شوند. ACME (Automatic Certificate Management Environment) هم پروتکل استاندارد صدور خودکار گواهی است که RFC 8555 تعریفش کرده و هر مشتری‌اش حسابی با یک نشانی یکتا نزد آن CA دارد. RFC 8657 دو پارامتر accounturi و validationmethods را اضافه می‌کند تا صدور به همان حساب مشخص و به یک روش اعتبارسنجی مشخص محدود شود:

; example.gh zone: one CA, one ACME account, one method
example.gh.  IN CAA 0 issue "ca.example.net; accounturi=https://ca.example.net/acme/acct/4242; validationmethods=dns-01"
example.gh.  IN CAA 0 issuewild ";"
example.gh.  IN CAA 0 iodef "mailto:security@example.gh"

مقدار ";" در issuewild یعنی هیچ CA اجازه صدور گواهی وایلدکارد ندارد. برای بررسی آنچه واقعاً منتشر شده است:

dig +short CAA example.gh

حد محافظت سمت مرورگر، به گفته خود گوگل

«کاربران کروم برای محافظت‌شدن لازم نیست کاری بکنند»، اما گوگل صریح می‌گوید نمی‌تواند تضمین کند تحلیلش همه دامنه‌های متأثر را پیدا کرده و «به مداخله سمت مرورگر نباید برای محافظت از کاربرانتان تکیه کرد». اگر دامنه‌ای زیر این سه ccTLD دارید، ورودی‌های اخیر CT را همین حالا مرور کنید؛ هر گواهی‌ای که خودتان درخواست نکرده‌اید، نشانه خطر است.

حد CAA را هم خود گزارش می‌گوید: مهاجمی که DNS معتبر را در اختیار دارد می‌تواند رکورد CAA را بردارد، پس CAA در میانه ربایش جلوی صدور را نمی‌گیرد. ارزشش جای دیگری است؛ به نوشته گوگل بازگرداندن یک سیاست CAA محدودکننده — خصوصاً وقتی صدور را به حساب و روش اعتبارسنجی مشخص مقید کند — مانع می‌شود مهاجم از وضعیت اعتبارسنجی کش‌شده برای صدور گواهی تازه استفاده کند. پس لایه کشف، پایش CT است؛ CAA دامنه خطا را کوچک و بازگشت به وضع عادی را امن می‌کند. اعتبارسنجی دامنه هیچ‌وقت محکم‌تر از رجیستری بالای سر شما نیست.