攻撃者が第三者の国別コードドメイン（ccTLD）のインフラを侵害し、権威DNSレコードを改ざんすることで、Googleの複数のドメインやその他の組織に対する不正なHTTPS証明書を取得しました。
被害が確認されたのは、ガーナ、シエラレオネ、米領サモアに関連する.gh、.sl、.asの名前空間です。Googleは、自社のシステムが侵害されたわけではないと強調しています。
攻撃者が狙ったのは、外部のccTLDインフラでした。これらのサフィックスで終わるドメインはすべて、影響を受けるおそれがあります。
Googleによると、影響を受けた証明書を発行した認証局（CA）が不適切な対応をしたと考える理由はないとのことです。ただし、攻撃者の正体や影響を受けたドメインの一覧、レジストリが侵害された経緯については明らかにされていません。
今回の攻撃は、DNSインフラを掌握されると、証明書に名前が載る組織自体が侵害されていなくても、HTTPS認証が成り立たなくなり得ることを示しています。認証局は、証明書を発行する前にドメインの管理権限を検証します。
認可された検証方法の一つでは、申請者が指定されたDNSレコードを公開する必要があります。そのため、権威DNSを支配する攻撃者は、正当なドメイン所有の証明に使われる証拠を操作できてしまいます。
Googleは、今回のインシデントで悪用された具体的な検証方法を明らかにしていません。不正な証明書は、攻撃者が管理する暗号鍵を被害者のドメイン名に結び付けてしまいます。
こうした証明書はなりすましに利用され得ますが、Googleの発表では、今回の証明書が通信の傍受やユーザーの侵害に使われたかどうかは確認されていません。
Googleは、自社のプロパティを対象とする不正な証明書を、Chromeの緊急証明書ブロック機構であるCRLSets経由で直ちにブロックしました。Chromiumは、CRLSetsをセキュリティインシデント時に証明書を迅速にブロックするための主要な手段と位置付けています。
Googleは発行元の認証局とも連携して証明書の失効を進め、Chrome以外にも対策を広げました。
その後のCertificate Transparency（証明書の透明性）の分析で、世界的な大手ブランドや広く使われているオンラインサービスなど、影響を受けた可能性のある組織がほかにも見つかりました。Chromeはこれらの証明書も先回りしてブロックし、可能な場合は影響を受けた組織に通知しています。
Chromeのユーザーがこの保護を受けるために、追加の対応は必要ありません。ただしGoogleは、調査で影響を受けたすべてのドメインを特定できるとは限らないと注意を促しています。また、Chromeによる対処は、ほかのクライアントのユーザーを確実に守るものではないとも指摘しました。
Googleは各組織に対し、パークドメインや地域向けプロパティを含む、保有するすべてのドメインについてCertificate Transparencyを監視するよう呼びかけています。これらの公開ログでは証明書の発行状況を確認でき、監視サービスを使えば想定外の証明書を検知できます。
あわせて、制限的なCAA（Certification Authority Authorization）ポリシーを公開することも推奨されます。対応しているACMEアカウントのバインディングや、検証方法の制限も含みます。これらの制御はRFC 8657で定義されていますが、効果は発行元の認証局が対応しているかどうかに左右されます。
攻撃者がDNSを掌握している間は、CAAで証明書の発行を防ぐことはできません。ただし、事後に制限的なポリシーを復旧しておけば、攻撃者がキャッシュされたドメイン検証結果を悪用して、さらに証明書を取得することを防ぐ助けになります。
16,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を削減しています。チーム向けに試す
翻訳元: https://cyberpress.org/attackers-hijack-dns-records/
