قفل معتبر بود، سایت جعلی: توضیح ربایش رجیستری‌های .gh، .sl و .as

در 6 اکتبر 2026، تیم امنیتی Chrome در Google یادداشتی کوتاه با عنوانی خشک و محتوایی نگران‌کننده منتشر کرد: مهاجمان کنترل سه رجیستری دامنه کد کشوری را به دست گرفته بودند، .gh غنا، .sl سیرالئون و .as ساموآی آمریکا، و رکوردهای DNS مرجع را تغییر داده و گواهی‌های HTTPS معتبر گرفته بودند، هم برای دامنه‌های Google و هم برای «چند برند پیشرو جهانی» که نامشان را نبرد. هر کس روی یکی از این سایت‌های جعلی فرود می‌آمد، قفل مرورگری می‌دید که هیچ ایرادی نداشت.

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

یک تعریف بار کل این صفحه را به دوش می‌کشد: گواهیِ اعتبارسنجی‌شده با دامنه (domain-validated) فقط یک چیز را ثابت می‌کند، اینکه متقاضی در لحظه صدور، DNS دامنه را در کنترل داشته است. وقتی رجیستریِ بالای DNS دزدیده شود، دزد از نظر همه بررسی‌های خودکار روی زمین، مالک است.

چه بر سر .gh، .sl و .as آمد؟

رجیستری کد کشوری سازمانی است که پایگاه داده اصلی همه‌چیزِ زیر دامنه دوحرفی‌اش را اداره می‌کند: .gh را Network Computer Systems در آکرا اداره می‌کند، .sl را شرکت مخابراتی Sierratel و .as را AS Domain Registry. اگر آن پایگاه داده را به خطر بیندازید، لازم نیست هیچ وب‌سایتی را جداگانه هک کنید، چون می‌توانید هر نامی را زیر آن TLD به سرورهایی که در کنترل خودتان است واگذار کنید.

اتفاقی که افتاد همین بود، رجیستری به رجیستری. گواهی‌ها در لاگ‌های عمومی برای نام‌های .gh در 22 سپتامبر، .sl در 25 سپتامبر و .as در 27 سپتامبر ظاهر شدند؛ گویی گروهی فهرستی را یکی‌یکی جلو می‌برد. Google می‌گوید مهاجمان «رکوردهای DNS مرجع را تغییر دادند و گواهی‌های HTTPS غیرمجاز برای چند دامنه Google و نیز دامنه‌های متعلق به سازمان‌های دیگر گرفتند» و سیستم‌های خودش دست‌نخورده مانده‌اند.

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

مهاجمان چطور برای دامنه‌های Google گواهی معتبر گرفتند؟

با درخواستی مؤدبانه. The Hacker News با تکیه بر سابقه عمومی شفافیت گواهی (Certificate Transparency) دست‌کم 12 گواهی برای 7 دامنه Google و YouTube شمرد، از جمله google.com.gh، google.sl، google.as و گونه‌های آنها: 11 گواهی صادرشده از Let’s Encrypt و 1 گواهی از ZeroSSL، همه از نوع اعتبارسنجی‌شده با دامنه. یکی از کارکنان Let’s Encrypt صدور و ابطال آنها را در انجمن این پروژه تأیید کرد.

بخش ناخوشایند ماجرا اینجاست: مراجع صدور گواهی طبق قواعدشان عمل کردند. خود Google نوشت که «دلیلی ندارد باور کند مراجع صدور گواهی (CA) که گواهی‌های آسیب‌دیده را صادر کردند کار نادرستی انجام داده‌اند». اعتبارسنجی دامنه از متقاضی می‌خواهد کنترلش بر DNS دامنه را ثابت کند، معمولاً با انتشار یک رکورد. مهاجمان خودِ DNS بودند. از هر بررسی خودکاری که با آن روبه‌رو شدند صادقانه گذشتند، به همان معنای محدودی که ماشین‌ها از صداقت می‌فهمند.

یک جزئیات نشان می‌دهد هوشیاری در این لایه چه شکلی دارد: در رکوردهای ثبت‌شده‌ای که بررسی شد، دست‌کم از 10 سپتامبر به بعد، همه گواهی‌های دیگر google.com.gh، google.sl و google.as از Google Trust Services، یعنی CA خود Google، آمده بودند. دوازده گواهی از دو CA نامرتبط خودش ناهنجاری بود، در یک لاگ عمومی، منتظر اینکه کسی نگاهی بیندازد.

چه کسی متوجه شد و چطور متوقف شد؟

سه سازوکار، به ترتیب سرعت.

اول، شفافیت گواهی اصلاً گواهی‌ها را قابل‌مشاهده کرد. از 30 آوریل 2018، Chrome هر گواهی را که در لاگ‌های عمومی CT افشا نشده باشد رد می‌کند؛ پس مهاجمی که گواهی کارآمد در پرکاربردترین مرورگر جهان می‌خواهد، باید اعتراف‌نامه‌ای امضاشده درباره وجود آن هم به دست جهان بدهد. شمارنده عمومی این اکوسیستم از 2.5 میلیارد گواهی ثبت‌شده گذشته است و Let’s Encrypt به‌تنهایی در اواخر سپتامبر 2025 از مرز ده میلیون گواهی صادرشده در یک روز گذشت؛ پیدا کردن 12 گواهی بد در این انبار کاه دقیقاً همان کاری است که زیرساخت لاگ برایش ساخته شده است.

دوم، Chrome گواهی‌ها را از طریق CRLSets، فهرست مسدودسازی اضطراری‌اش، مسدود کرد؛ فهرستی که از طریق به‌روزرسان مؤلفه‌های مرورگر منتشر می‌شود و بدون به‌روزرسانی یا راه‌اندازی دوباره اعمال می‌شود. تیم امنیتی Chrome سال‌هاست استدلال می‌کند که بررسی‌های آنلاین ابطال دقیقاً همان وقتی شکست می‌خورند که به آنها نیاز دارید، چون مهاجمِ وسط مسیر می‌تواند خودِ بررسی را مسدود کند؛ به همین دلیل فهرست مسدودسازی همراه مرورگر سفر می‌کند. Google سپس داده‌های CT را برای یافتن قربانیان دیگر کاوید، گواهی‌های آنها را هم مسدود کرد و می‌گوید هر جا توانست با سازمان‌های آسیب‌دیده تماس گرفت.

سوم، مسیر کندی که بقیه را پوشش می‌دهد: مراجع صدور هر 12 گواهی را باطل کردند؛ دو گواهی .gh و تک گواهی ZeroSSL در 26 سپتامبر و نه گواهی دیگر در 1 اکتبر. کوتاه‌ترین فاصله میان ظاهر شدن یک گواهی در لاگ و مرگ آن حدود یک روز و نیم بود و طولانی‌ترینش نزدیک به یک هفته. بند صداقت خود Google ارزش نقل کردن دارد: «نمی‌توانیم تضمین کنیم که تحلیل ما همه دامنه‌های آسیب‌دیده را شناسایی کرده باشد و مداخلات Chrome هم به‌طور قابل‌اتکایی از کاربران غیر Chrome محافظت نمی‌کنند.»

آیا DNSSEC یا رکوردهای CAA می‌توانستند جلوی این را بگیرند؟

این رخداد روشن‌ترین نمایش چند سال اخیر از این است که این دو سرواژه چه چیزی برایتان می‌خرند و چه چیزی نمی‌خرند.

اول DNSSEC. با بررسی منطقه ریشه منتشرشده: .gh و .sl اصلاً امضا نشده‌اند و همین آنها را در جمع ccTLDهای فراوانی قرار می‌دهد که هرگز DNSSEC را پیاده نکردند؛ فناوری‌ای که در اروپا 99 درصد پذیرش رجیستری دارد اما در آفریقا 65 درصد. و .as امضاشده است، و باز هم ربوده شد. DNSSEC به resolver امکان می‌دهد بررسی کند پاسخی با آنچه رجیستری منتشر کرده یکی است. وقتی خودِ رجیستری متخاصم باشد، داده‌های مهاجم را منتشر می‌کند، با کلیدهایش. امضای یک دروغ همچنان امضایی معتبر است.

رکوردهای CAA که به صاحب دامنه امکان می‌دهند اعلام کند کدام CAها مجاز به صدور برای آن هستند، شکل ظریف‌تری دارند. در حین ربایش بی‌فایده‌اند، چون رکورد CAA در همان DNS قرار دارد که مهاجم کنترلش می‌کند؛ خودِ استاندارد CAA می‌پذیرد که مهاجمی که می‌تواند DNS را ویرایش کند می‌تواند رکورد را هم حذف کند. بعد از ربایش اهمیت زیادی دارند، چون طبق قواعد فعلی CA/Browser Forum، مراجع صدور می‌توانند یک اعتبارسنجی انجام‌شده را تا 200 روز دوباره به کار ببرند، بازه‌ای که در مارس 2027 به 100 روز و در 2029 به 10 روز کاهش می‌یابد؛ پس مهاجمی که DNS را از دست داده بود هنوز می‌توانست از بررسی‌های ذخیره‌شده گواهی تازه بگیرد. تا 7 اکتبر، هر هفت دامنه شناخته‌شده قربانیِ Google رکوردهای CAA داشتند که فقط CA خود Google را نام می‌بردند. این همان قفلی است که بعد از این دزدی خاص نصب می‌کنید، و قفل واقعی‌ای هم هست.

آیا پیش از این هم چنین اتفاقی افتاده است؟

حمله به رجیستری‌ها و زیرساخت DNS یک ژانر است، نه پدیده‌ای تازه. سابقه تاریخ‌دار:

در میان حدود 1,400 دامنه منطقه ریشه، 316 دامنه سطح بالای کد کشوری وجود دارد که هر کدام به یک کشور یا قلمرو گره خورده‌اند، هر کدام با بودجه، حکمرانی و وضعیت امنیتی خودشان، و برخی را اپراتورهای خصوصی اداره می‌کنند. نهاد قانونی دامنه خود غنا سال‌هاست درگیر مناقشه‌ای علنی بر سر این است که اصلاً چه کسی باید .gh را اداره کند. مدل اعتماد وب تا حدی بر این تکیه دارد که کم‌بودجه‌ترینِ این سازمان‌ها تیم امنیتی خوبی داشته باشند.

چه می‌دیدید و واقعاً چه چیزی از شما محافظت می‌کند؟

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

آنچه از کاربران محافظت کرد هیچ کاری نبود که کاربری انجام داده باشد. ردپای مکتوب اجباری CT گواهی‌ها را آشکار کرد، CRLSets آنها را بدون هیچ اقدامی در Chrome از کار انداخت و ابطال بقیه موارد را پوشش داد. یک لایه دیگر هم شایسته اشاره است: اپلیکیشن‌های بومی که کلیدهایشان را pin می‌کنند. در ماجرای توگو در 2017، pinning در Chrome در هر صورت گواهی جعلی google.tg را رد می‌کرد و اپلیکیشن‌های خود Google و بسیاری از اپلیکیشن‌های بانکی هنوز هم pin می‌کنند. دفاع در عمق اینجا یک شعار نیست؛ پشته‌ای مشخص است و در اواخر سپتامبر، تک‌تک لایه‌هایش بار را به دوش کشیدند.

آیا VPN در برابر این حمله محافظت می‌کند؟

یک صفحه امنیتی صادق به این پرسش دقیق پاسخ می‌دهد، پس پاسخ دقیق این است: برای این دسته از حملات نه، برای خویشاوندان رایج‌ترش بله، و دانستن اینکه کدام کدام است تمام ماجراست.

VPN در TLS مشارکتی ندارد. مرورگر شما گواهی‌ها را بر پایه مخزن اعتمادش روی هر شبکه‌ای به یک شکل اعتبارسنجی می‌کند و این گواهی‌ها معتبر بودند. بدتر از آن برای هر ابزاری که پایین‌دست DNS قرار دارد: مهاجمان رکوردهای مرجع را در خودِ رجیستری مسموم کردند؛ پس همه resolverهای درستکار روی کره زمین، از جمله resolverهای یک ارائه‌دهنده VPN، پاسخ‌های مهاجم را ارائه دادند. هیچ VPNی، از جمله VPN ما، این حمله را مسدود نمی‌کرد. آنچه متوقفش کرد همان زنجیره CT، CRLSet و ابطال بود که بالاتر شرح دادیم.

آنچه VPN واقعاً از آن دفاع می‌کند، سمت شما در اتصال است. روی یک شبکه محلی متخاصم، یک هات‌اسپات جعلی یا شرکت اینترنتی‌ای که دست‌کاری می‌کند، مهاجم میان دستگاه شما و اینترنت نشسته است و پاسخ‌های DNS تزریق می‌کند یا ترافیک را تغییر مسیر می‌دهد. VPN تفکیک نام DNS و مسیر ترافیک شما را به درون یک تونل رمزنگاری‌شده منتقل می‌کند و به تعبیر راهنمای EFF، ترافیک شما را از «شرکت اینترنتی و صاحب شبکه محلی (مثل یک کافه یا هتل)» پنهان می‌کند. این همان سطح حمله رایج و روزمره است، همانی که در راهنماهایمان درباره رمزنگاری VPN و امنیت Wi-Fi عمومی پوشش می‌دهیم، و دقیقاً همان لایه‌ای است که مهاجمان رجیستری هرگز نیازی به دست زدن به آن نداشتند. این دو محافظت مکمل یکدیگرند، نه جایگزین هم، و به همین دلیل صفحه صادقانه جداگانه‌ای هم درباره آنچه سایت‌ها با روشن بودن VPN همچنان می‌توانند ببینند داریم.

صاحبان دامنه اکنون چه باید بکنند؟

توصیه Google به سازمان‌ها دو گام است و برای شرکتی با سه دامنه به همان اندازه صدق می‌کند که برای شرکتی با سه هزار دامنه. لاگ‌های شفافیت گواهی را برای همه دامنه‌هایتان پایش کنید، از جمله دامنه‌های پارک‌شده و منطقه‌ای؛ 12 گواهی جعلی روزها در لاگ‌های عمومی ماندند و برای هر کسی که نگاه می‌کرد قابل‌مشاهده بودند. و رکوردهای CAA محدودکننده‌ای منتشر کنید که CA شما را نام ببرند، ترجیحاً همراه با اتصال حساب ACME تا حتی CA خودتان هم فقط برای حساب شما صادر کند. کتاب قواعد CAها گام سومی هم اضافه می‌کند: اگر گواهی‌ای که درخواستش نکرده‌اید ظاهر شد، یک گزارش مشکل گواهی (Certificate Problem Report) ثبت کنید؛ الزامات پایه (Baseline Requirements) این صنعت، CA را موظف می‌کند آن را بررسی کند و نخستین یافته‌هایش را ظرف 24 ساعت گزارش دهد.

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