コインチェックが振り返る、「ドメイン名ハイジャック」発生時のあの日のインシデント対応

リクエストが激減してレスポンスが悪化……ドメイン名が乗っ取られた！

　仮想通貨取引所「Coincheck」を運営するコインチェック株式会社の喜屋武慶大氏（サイバーセキュリティ推進部長）は、同社が6月にドメイン名ハイジャックの被害に遭った際のインシデント対応について、11月11日・12日に行われたイベント「JPAAWG 3rd General Meeting」の一部セッションにて、解説を行った。同氏はセキュリティ監視業務の設計、実装、運用とサービス部門のレビューを主な業務としている。

　6月に起こった事件は、同社が利用するドメイン名登録サービス「お名前.com」のアカウントが不正アクセスを受け、ドメイン名登録情報が何者かによって書き換えられた、というものだ。

　問題発覚の発端となったのは同社のSREチームが行っているシステムモニタリング値の異常だった。6月1日の昼ごろに、前日からリクエスト数が異常に減り、通常0.1秒程度の遅延が10倍以上遅くなったことが確認された。

SREチームからレスポンス悪化とリクエスト減少が報告されたのがインシデント発見のきっかけ

　SREチームが調査してもアプリケーションやサーバー、ロードバランサ―には異常が見つからなかったが、夕方ごろから他部署のエンジニアやユーザーからもレスポンスが遅いという連絡が届くようになった。人によって遅延の状況が異なるため「経路の問題ではないか？」と確認したところ、AWS（Amazon Web Services）の東京リージョンを使用しているはずが、なぜかアムステルダムのIPアドレスを経由していたことが判明した。

tracerouteを行ってみるとオランダを経由していることが分かる

　AWSにサポートを依頼したところ「登録されているネームサーバーはAWSが管理しているものではない」ということが判明した。偽ネームサーバーは正しいネームサーバーに0が1つ余計についているだけで、これによって「（単なる）インフラ障害ではなくCoincheckを狙ったインシデント」（喜屋武氏）と判断し、対応が開始された。

問題はネームサーバー情報の改ざんが原因だった。AWS正規のDNSサーバー名に0を付加したものなので気付きにくい

　初動対応として、副社長とシステム担当執行役員に（その後に社長にも）エスカレーションを行い、システム担当役員は障害対応のZoomに参加して対応の指揮をとった。

　DNSレコードは日本時間深夜に最終更新されているが、その時間に変更作業をしておらず、対応のために、レジストラであるお名前.comの該当アカウントへのログインを試みるもエラーとなり、ドメイン名の乗っ取りが確定となった。サポート依頼をしたものの営業時間後であり、喜屋武氏は「翌営業日対応」を覚悟したという。

更新されたのは日本時間で日曜深夜。しかしCoincheckでは最近変更していない

原因はマルウェア感染やパスワードクラックではなかった

　次に社外のセキュリティアドバイザー2名にも協力してもらい、原因究明を行った。

　可能性はいくつか想定された。しかし、エンドポイントのアラートが出ておらず、不審なアクティビティも見当たらないことから端末のマルウェア感染の可能性は薄く、不審なSSO（シングルサインオン）のログや他のSaaSへのログイン履歴もないことから社内システムの乗っ取りの可能性も低いと見た。

　パスワードクラックの可能性に関しては、パスワードジェネレーターによるランダムパスワードなうえ、登録できる最も長い文字数を使用して使い回しもないため、総当たりやリスト型では現実的な突破は不可能と判断。直近ではレジストラへのアクセスがないため、セッションハイジャックの可能性もない。アドバイザーからはクロスサイト攻撃のような手法もあるが（この時点で）他社の被害事例がなく可能性は薄いだろうと判断した。

原因調査。想定した要因は5つあるが、いずれも自社内の調査では問題が出てこない

レジストラの脆弱性は当初想定していなかったが、実際はレジストラの脆弱性が原因だった（bitcoinbank.co.jpも書き換え被害に遭っていた）

　結局、サポート時間外だったもののレジストラが対応してくれたため、ネームサーバーを一応取り戻すことが行えた。「（振り返ってみると）ここまでが緊張感が高かった」と喜屋武氏は語る。

　ネームサーバーは取り戻したものの、アカウント乗っ取りの手法が不明なので再度乗っ取られる可能性がある。加えて影響範囲がまだ分からず、ユーザーへの影響がないとは言い切れない。

　調べてみるとMXレコードが書き換えられていることが分かった。しかしTXTレコードは改ざんされておらず、Coincheckの名前で迷惑メールをばら撒くようではないと判断した。

メールサーバーの指定も変更されていたことが分かった

　さらに社員のメールをチェックしたところ、GitHubのパスワード変更メールが見つかった。GitHubを使っている社員にセキュリティログを確認して欲しいと依頼をすると同時に、他の外部サービスでも同じような事象が発生していないかを確認した。また、通知系サービスを全て停止し、攻撃者のメールサーバーに余計なデータが流れないように対応した。これは、偽メールサーバーを使った攻撃者によるアカウント乗っ取りを防ぐためだ。

メールを調べるとGitHubのパスワードリセットが行われようとしていた（実際には多要素認証によって回避）

これまでに判明した攻撃の全体像。ただし、ドメイン名の乗っ取りが続いていればこれでは済まなかった可能性がある

忙しい2日目……そして終結

　2日目は代替ドメイン名の策定や、当局や関連団体への報告が作業内容となり、最も忙しかった日だった。

　朝、昼、夕方に定期ミーティングを行い、それ以外でも必要に応じてスタッフを召集した。といっても、コロナ禍なのでZoomに常設の対策本部を設定し、システム担当執行役員が常駐して報告や指示を受けるというかたちとなった。

　普段ならば大きな会議室に対策本部を設置して、ホワイトボードに状況や対応を書くだろう。だが、「エンジニアが調べて報告に行き、指示や疑問点を受けてまた作業に戻ることを考えると今回の方が効率が良かった」と喜屋武氏は語る。

コロナ禍ということで、Zoomを利用しての対策本部となったが、効率的にはこれで良かったようだ

　代替ドメイン名として当初「support.coincheck.com」というサブドメインを作成する予定だったが、調べてみると攻撃者側の偽ネームサーバーにも「support.coincheck.com」が作られた。再度乗っ取られる危険性を考えて、別のドメイン名「coincheck.jp」を取得し、設定作業が終了した段階で第一報のプレスリリースを発表した。

対応メールをサブドメインで対処しようと考えたが、偽ネームサーバーにもサブドメインが作られたこともあり、当初は他ドメイン名でメール対応。後日元に戻している

　プレスリリースを出した結果、他の会社でも同様の被害が発生していることが判明したため、レジストラの脆弱性と判断し協力を依頼したところ、3日目に問題を修正したと報告があったという。

　一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）を通じて攻撃者のネームサーバーとメールサーバーのテイクダウンも行えたこともあり、coincheck.comのドメイン名を継続して利用することを判断。4日目に最終報告のプレスリリースを出すとともに、顧客資産保護のために停止していたサービスの一部機能を再開した。

結果的には発覚から4日間でインシデント対応が完了した

日ごろのモニタリングが被害拡大を防いだ

　後日譚として、社内で利用している外部サービスのうち、Coincheckの運用に関わっている重要な情報を取り扱っているサービスのSSOや多要素認証が行われているか、徹底的にチェックしたという。

　今回のインシデントを振り返り、非常に似たようなドメイン名を使われていたので気付きにくかったものの、モニタリングを日ごろから行っていたことでインシデントを早期に発見できた。また、レジストラの協力もあって迅速にネームサーバー乗っ取りを解消した結果、攻撃者の次の一手を避けることができたと評価した。

日ごろのモニタリングと分析により、インシデント発覚や対応完了が早かった

　また、外部のアドバイザーによって被害原因の調査と影響範囲の調査も迅速に行うことができ、レジストラのCSIRTチームに連絡したことも効果があったこと、JPCERT/CCの協力により、不正なネームサーバーおよびメールサーバーのテイクダウンが行えたことを挙げていた。

　最後に、「酷似したドメイン名をネームサーバーに設定されたインシデントは世界初ではないか」と述べた。多要素認証によってさらなる被害が防げたこと、ドメイン名はブランドであり（それを管理する）DNSはとても重要で、アカウント管理やレコードの監視を行うことの重要性を指摘した。

DNSはとても重要であるので、日ごろからチェックを怠らず、多要素認証も行うべきとアドバイス

　インシデントは外部からの指摘で分かることも少なくない。また、今回のようなドメイン乗っ取りのケースでは一般的なキャッシュ期間（48時間）を超えることで影響が拡大する。

　早期発見と早期対応、そして外部機関との連携がCoincheckの被害を最小限にしており、そのためには日ごろのモニタリングが欠かせない。また、多要素認証も被害の緩和に有効だと感じた。