Googleを侵害せずに、攻撃者が信頼済みのGoogle HTTPS証明書を取得

執筆者
eWEEK Staff
eWEEK Staff
Oct 11, 2026
4 minute read
Google Chrome logo representing the browser's response to unauthorized HTTPS certificates obtained through DNS hijacking

Google Chrome blocked identified unauthorized HTTPS certificates following compromises of three country-code domain registries. Image: Google

eWeek のコンテンツおよび製品のおすすめは、編集上の独立性を保っています。パートナーへのリンクをクリックすると、当社が報酬を得る場合があります。 詳細を見る

攻撃者は、Googleのシステムに侵入することなく、Googleのドメイン向けの信頼済みHTTPS証明書を取得した。攻撃者が侵害したのは、第三者が運用するドメインレジストリのインフラであり、ウェブサイトの身元を検証する仕組みの弱点を悪用した。

Googleは2026年10月6日の公表で、攻撃者が3つの国別ドメイン、.gh(ガーナ)、.sl(シエラレオネ)、.as(米領サモア)を支えるインフラを侵害したと明らかにした。権威DNSレコードを操作して、Googleの各種サービスや他の組織向けの不正な証明書を取得したという。Googleは特定した証明書をChromeでブロックし、発行元の認証局と連携して失効させた。

このインシデントは、地域別のウェブサイトを運営する企業にリスクがあることを浮き彫りにした。侵害されたレジストリのインフラがあれば、攻撃者は対象組織のシステムに侵入しなくても、証明書の検証を揺るがすことができる。

攻撃者が不正なHTTPS証明書を取得した方法

認証局(CA)は、申請者が該当ドメインを管理していることを確認したうえで、公的に信頼されるHTTPS証明書を発行する。権威DNSレコードを操作する攻撃者は、正当なドメイン所有者の許可がなくても、こうした確認を通過できる。

Googleのセキュリティに関する公表によると、証明書は確立された検証プロセスを通じて発行されたが、正当なドメイン所有者の承認は得ていなかった。Googleは、発行元の認証局が不適切な行為をしたと考える理由はないとしている。

The Hacker Newsの調査では、9月22日から27日にかけて、GoogleとYouTubeの7つのドメイン名を対象とする12件の証明書が特定された。11件はLet's Encrypt、1件はZeroSSLが発行したものだった。対象となったドメインには、google.com.gh、google.sl、google.asが含まれていた。

12件すべてが10月7日までに失効していた。Let's Encryptの担当者が確認したところ、GoogleとYouTubeのドメイン向け証明書が発行され、失効していたという。

Googleは、特定した不正な証明書をブロックするため、ChromeのCRLSetメカニズムを使用した。Certificate Transparency(CT)のログからは、影響を受けた可能性のある組織がさらに明らかになり、追加のブロックと通知につながった。

Googleによると、Chromeユーザーが追加で対応する必要はない。ただし、同社のブラウザー保護機能では影響を受けたドメインを見逃す可能性があり、他のブラウザーのユーザーを確実に保護することもできないと警告した。

攻撃者がトラフィックもリダイレクトしていれば、これらの証明書によってウェブサイトになりすますことが可能だった。Googleは、証明書が通信の傍受やデータの窃取に使われたとは確認していない。

eWeekの分析:レジストリの乗っ取りが証明書制御の限界を露呈

証明書発行者を制限しても、攻撃者が権威DNSを掌握していれば保護は保証できない。Googleの調査結果は、企業の証明書ポリシーと、ドメインの管理権限を検証するために使われる外部インフラとの間にギャップがあることを示している。

Certificate Authority Authorization(CAA)レコードは、証明書を発行できるCAを制限する。しかし、DNSが乗っ取られている間の発行を防ぐことはできない。Let's Encryptの技術文書には、正当なDNS管理権限を回復した後、対応している場合に追加の保護を提供できる、アカウント単位の制限について説明されている。

CTの監視は別の役割を担う。予期しない証明書の発行が起きた後に、それを検知する仕組みだ。公開記録から特定された12件の証明書は、調査におけるCTの有用性を示しているものの、侵害の全容はなお明らかになっていない。

証明書の監視対象には、クラウドプロバイダーが管理するインフラも含まれる。Google Cloudの量子セキュリティロードマップでは、暗号技術の移行に関する責任をプロバイダーと顧客がどのように分担するかを検討している。

企業は、地域別ドメインやパークドメイン全体で証明書の発行を監視し、制限の厳しいCAAポリシーを適用するとともに、予期しない証明書を調査する手順を整備すべきだ。最近のCISAのレッドチーム評価では、重要インフラにおける検知と対応の弱点が別途明らかになった。同様に、MicrosoftのローカルAIエージェント向けDefenderのアップデートは、既存のセキュリティ資産台帳の外にある資産を発見するという、別の課題に対処している。

Advertisement

Googleは特定した証明書をブロックしたが、影響を受けたすべてのドメインを発見できたとは保証できなかった。したがって企業の証明書監視は、社内で管理するインフラの範囲を超えて実施する必要がある。

詳しく読む:暗号セキュリティ要件が進化する中、組織は量子対応ハードウェアと、そのセキュリティ機能に関する主張を精査してから、ベンダーの説明を検証済みの保護機能として扱うべきだ。

eWeek Logo

eWeek has the latest technology news and analysis, buying guides, and product reviews for IT professionals and technology buyers. The site's focus is on innovative solutions and covering in-depth technical content. eWeek stays on the cutting edge of technology news and IT trends through interviews and expert analysis. Gain insight from top innovators and thought leaders in the fields of IT, business, enterprise software, startups, and more.

TechnologyAdvice が所有・運営しています。 © 2026 TechnologyAdvice. 無断転載を禁じます

広告主に関する開示:このサイトに掲載されている製品の一部は、TechnologyAdvice が報酬を受け取っている企業のものです。この報酬は、製品がこのサイトのどこにどのように表示されるか(表示される順序など)に影響する場合があります。TechnologyAdvice は、市場で入手可能なすべての企業やすべての種類の製品を掲載しているわけではありません。