第三者がドメイン名の登録情報を不正に書き換えてしまうドメイン名ハイジャック。近年、国内でも大手企業や人気サイトなどがその被害に遭っている。誘導先の偽サイトでマルウェアの注入やフィッシング詐欺が行われるケースもあり、企業の信頼や事業継続に関わる致命的な影響を与えかねない。
暗号資産取引所を運営するコインチェックも、ドメイン名ハイジャックの被害に遭った会社の1つだ。2020年6月、同社が利用するドメイン名登録サービスの社有アカウントが不正アクセスを受け、登録情報が何者かによって書き換えられてしまった。
しかしながら、コインチェックによる早期発見と迅速な対応により、甚大な被害には至らなかった。さらに、インシデント発生後に詳細なレポートを公表したことも評価され、コインチェックは今回、「情報セキュリティ事故対応アワード 2020」を受賞した。
当時、現場では何が起きていたのだろうか。そして、そこから得られた教訓とは。同社 サイバーセキュリティ推進部長 喜屋武慶大氏に聞いた。
 |
|
コインチェック サイバーセキュリティ推進部長 喜屋武慶大氏 |
異変の検知から約9時間でアカウントを復旧
異変を一番初めに検知したのは、コインチェックのSREグループだった。2020年6月1日の正午ごろ、通常の監視業務でモニタリングしているサービスのレスポンスタイムが著しく遅延していることに気づいた。
喜屋武氏は当時、そうしたSREグループのやりとりを横で耳にしていたが、「インフラ系の障害であり、セキュリティインシデントだとは考えていなかった。原因が解明されたら共有してもらおう程度に思っていた」とあまり重要視していなかったという。
しかし、SREグループの調査では、アプリケーションやサーバ、ロードバランサの異常は見つからなかった。原因がはっきりしないまま、同日夕方ごろからはユーザーや社内の他部署からもレスポンスが遅いという問い合わせが増えてきたという。このタイミングで、SREグループから全社に対してサービスの遅延が起きているという情報が共有され、喜屋武氏もその原因調査に加わることとなった。
人によってレスポンスの遅延が確認できたりできなかったりしたため、遅延を確認できたメンバーがルーティング経路を調べたところ、なぜかオランダを経由していることがわかった。これを不審に思い、名前解決の結果を確認してみると、AWSの東京リージョンを使用しているはずが、アムステルダムリージョンのIPアドレスが返ってきていたという。
コインチェック側としては心当たりがなかったため、AWSに障害調査のサポートを要請。その結果、AWS側の回答は「設定されているネームサーバの値が、本来のネームサーバに0が1つ追加されただけの異なる値になっている」というものだった。
これにより、攻撃を受けている可能性が高いと判断したコインチェックのチームは、ドメイン名登録サービスのアカウントへログインを試みた。しかし、自社で管理していたIDとパスワードの組み合わせではログインすることができず、パスワードリセットも不可能となっていたため、アカウントが乗っ取られていることが判明した。
こうしてアカウント名ハイジャックの被害が発覚したのは、同日19時過ぎごろ。レスポンスタイムの遅延に気づいてから約半日後だ。ドメイン登録サービスの事業者へ問い合わせて対応を依頼し、21時ごろにはアカウント復旧とドメイン登録情報の修正を完了した。
狙いは社員のGitHubアカウント乗っ取りか
ただしその段階では、アカウントが乗っ取られた根本的な原因については不明で、再び攻撃されてしまう可能性もあった。さらに、影響範囲も明確になっていなかったため、監視と原因調査は並行して進められることとなった。喜屋武氏は「アカウントを取り戻せたことに対しては安堵したが、まだまだ気は抜けないと思っていた」と振り返る。
調査を進めていくと、対象ドメイン宛のメール配送先サーバを定義するMXレコードが書き換えられていたことが判明。顧客からの問い合わせメールを含む対象ドメイン宛のメールが、第三者によって不正に取得できる状態となっていた。
さらに、コインチェックの社員へGitHubアカウントのパスワード変更メールが届いていることもわかった。こうした当時の状況を考えると、社員のGitHubアカウントの乗っ取りが行われようとしていた可能性がある。
「GitHubのパスワードリセットが試みられていたが、当該社員に確認すると、『そんなことはしていない』との回答。攻撃者がGitHubのアカウントを乗っ取り、不正なコードをサービスに埋め込もうとしたのかもしれない」（喜屋武氏）
 |
実際には、多要素認証によってGitHubアカウントの乗っ取りは防ぐことができた。また、コインチェックの業務フロー上、コード変更を本番環境に反映させるには複数人による承認プロセスを経る必要があるため、サービス本体のコードが書き換えられることはなかった。
臨機応変な判断には、日ごろの訓練がなにより重要
対応の一環としてサービスの一部の機能を止めたことにより、コインチェックは、監督官庁である金融庁や加盟する日本暗号資産取引業協会への報告も実施する必要があった。なお、こうしたインシデント発生時の対応フローは、同協会が定める自主規制規則などに則って社内で規定されているという。
その内容について喜屋武氏は次のように説明する。
「当社では大きく分けて、システム障害時の対応フローと、セキュリティインシデント発生時の対応フローの2つが規定されている。しかし今回の件は、規定のフローではフォローしきれない部類のインシデントだった。インシデント対応事務局の立ち上げなどはフローどおりに実施できたが、初動対応の現場の動きなどは規定のフローではカバーできず、その場で判断して動かなければならなかった」（喜屋武氏）
さらに喜屋武氏は、臨機応変な判断が求められる状況で迅速かつ適切な動きを取るためのポイントについて、「対応フローの整備はもちろん、インシデント発生を想定した訓練を日ごろから定期的に行っておくこと。インシデント発生時に担当者が何をすべきか思い出して自発的に動けるだけの数をこなしておくことが重要」と話している。
喜屋武氏が「ようやく落ち着いた」とする状況になったのは、異変の発覚から3日目。ドメイン登録サービス事業者側から、通信を改ざんできる不具合があったこと、それを修正したことが報告されたタイミングだった。
4日目には、最終報告のプレスリリースを発表するとともに、停止していたサービスの一部機能を再開。ドメイン登録サービス事業者の変更も行った。
プレスリリースは「できるだけ正直に」
上記のような対応は、インシデント対応事務局メンバーの半数以上がリモートワークを行う状況下で進められた。常設の対策本部をZoom上に設け、適宜ミーティングを実施していたという。今回のアワードでは、プレスリリースや技術ブログで詳細なレポートを公表したことも評価につながったが、広報部門とのやりとりもそこで行われた形だ。
今回のインシデントの原因は、ドメイン登録サービス事業者の脆弱性を突かれたことによるもので、プレスリリースでの説明が難しい部分もあるが、コインチェックとしてなるべく詳細に報告することを決めたのは、2018年の暗号通貨流出事件が背景にあった。
 |
「我々はお客様の資産を預かっている。サービスを停止するということは、顧客資産に何か影響があったのではないかという懸念を生んでしまうことにつながる。それを払拭するために、影響範囲や起きていることをできるだけ正直に書くべきだという議論をした」（喜屋武氏）
被害規模を軽減した多要素認証
今回のように社外のシステムにインシデントの原因がある場合、自社だけではどうにもできない状況が生まれてしまう一方、原因が明確になるまで外部の事業者に協力的になってもらえないケースが多いということも課題だ。
しかし、企業において多様なクラウドサービスの導入・活用が普及しているなか、1社のみでインシデント対応できる範囲は限られてくる。業界全体として、会社や組織の枠を超えて対応できる仕組みづくりを考えていく必要があるだろう。
また一企業としては、ドメインを管理するDNSというシステムの重要性を認識し、予防策や対応策を整理・実行することが大切だ。今回のインシデントは、GitHubの多要素認証を有効にしていたことで、攻撃者の目的が遂行されず、甚大な被害につながらずに済んだ。
喜屋武氏は「自社サービスに影響のあるSaaS系サービスを洗い出して、多要素認証が設定できているか、できていないものがあれば、他のサービスに乗り換えられるか、回避策が取れるか、チェックしてほしい」とコメントする。コインチェックでも、外部サービスに対する定期的な棚卸しの重要性を改めて認識し、棚卸しでの確認項目を追加したという。
DNSが企業に与える影響は大きいぶん、そこに対する攻撃は後を絶たない。「同じようなことが繰り返されないように、対策をしてほしい」と喜屋武氏は呼びかける。対岸の火事とは思わず、今回の事例を参考に自社の予防・対応方針や訓練内容を今一度見直してみていただきたい。
