2020年6月に発生したドメイン名ハイジャックのインシデント対応について

はじめまして、サイバーセキュリティ推進部の喜屋武です。
今回は2020年6月に発生したお名前.com上の当社アカウント乗っ取りによる「coincheck.com」のドメイン名ハイジャックのインシデントについて、発覚までの経緯とその後のインシデント対応についてご説明します。

1 発覚までの経緯

1.1 サービスの応答時間の遅延の確認

当社利用のドメイン登録サービス「お名前.com」で発生した事象について（最終報告） | コインチェック株式会社 でもタイムラインを記載しましたが、最初の異変は日頃からモニタリングしているサービスのレスポンスタイムが著しく遅延していたことでした。

当時のサービスのレスポンスタイム

この異常を確認し、SRE チームが調査に乗り出しましたがこの段階では他に問題は確認されず、レスポンスが遅延している原因の特定には至っていませんでした。

1.2 他部署やユーザーからの問い合わせ

夕方頃からは他の部署のエンジニアやユーザーからも 「coincheck.com」 のサイトや API からのレスポンスに時間がかかっているという情報が上がってくるようになりました。
ユーザーにも影響が出始めているということで、このタイミングで SRE チームから社内にサービスのレスポンスが遅延していると情報が共有されました。
この頃から私も調査に参加しましたが、既に SRE チームの調査によりアプリケーション、サーバー、ロードバランサーには異常が見つからず、問題の原因は CDN かそれより前のネットワークだろうという見当がつけられていました。

1.3 経路と DNS の異常の確認

この頃から調査にあたっていた SRE チームの中にもサイトのレスポンスが遅いことを確認できるメンバーが出始めました。試しに dig コマンドに trace オプションを付けて名前解決を試みると time out することが確認できはじめていましたが、モニタリング上は DNS についても遅延や名前解決できない等の問題は確認できていませんでした。

DNSのレスポンスタイム

手元でレスポンスが遅延するようになったメンバーが試しに traceroute をかけてみたところ次のような結果が返ってきていました。

[~]$ traceroute coincheck.com
traceroute to coincheck.com (*.*.*.*), 64 hops max, 52 byte packets
 1 *.*.*.* (*.*.*.*) 8.848 ms 1.440 ms 1.231 ms
 2 * * *
 3 *.jp (*.*.*.*) 39.671 ms 31.535 ms 48.041 ms
 4 *.jp (*.*.*.*) 49.228 ms 30.629 ms 40.791 ms
 5 *.jp (*.*.*.*) 39.525 ms 66.073 ms 32.224 ms
 6 * * *
 7 *.net (*.*.*.*) 349.044 ms 323.057 ms
   *.net (*.*.*.*) 347.276 ms
 8 *.net (*.*.*.*) 3.641 ms
   *.net (*.*.*.*) 49.727 ms
   *.net (*.*.*.*) 51.372 ms
 9 *.net (*.*.*.*) 151.669 ms 150.529 ms
   *.net (*.*.*.*) 204.721 ms
10 *.net (*.*.*.*) 209.535 ms
   *.net (*.*.*.*) 248.627 ms 150.673 ms
11 *.us.bb.gin.ntt.net (*.*.*.*) 213.621 ms
   *.us.bb.gin.ntt.net (*.*.*.*) 209.251 ms 212.087 ms
12 *.nl.bb.gin.ntt.net (*.*.*.*) 309.269 ms 312.889 ms 314.210 ms
13 *.nl.bb.gin.ntt.net (*.*.*.*) 306.177 ms 323.874 ms 306.553 ms
14 *.nl.bb.gin.ntt.net (*.*.*.*) 307.962 ms
   *.nl.bb.gin.ntt.net (*.*.*.*) 306.440 ms 295.733 ms
15 * * *
16 * * *
17 * * * 

リクエストの経路にオランダが含まれていることを不審に思い改めて名前解決の結果を確認したところ、オランダのアムステルダムにある CloudFront の Edge が返ってきており、この経路がレスポンスの遅延の原因だろうということが判明しました。

[~]$ dig coincheck.com.

; <<>> DiG 9.10.6 <<>> coincheck.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53814
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;coincheck.com.                 IN      A

;; ANSWER SECTION:
coincheck.com.          286     IN      A   54.192.85.80

;; Query time: 162 msec
;; SERVER: *.*.*.*#53(*.*.*.*)
;; WHEN: Mon Jun 01 18:42:03 JST 2020
;; MSG SIZE  rcvd: 58

 実はこの時点で AWS の Trusted Advisor では次のようなエラーが出ていました。

Trusted Advisor のエラー

 Trusted Advisor のエラーは上記の名前解決の結果のせいだろうということは想定できましたが、Route53 の設定を確認しても正しい値が設定されており何故 DNS の名前解決の結果で アムステルダムにある CloudFront の Edge が返ってくるのか原因が分からなかったため AWS のサポートの協力を仰ぐことにしました。

1.4 NS レコード異常の確認

AWS のサポートチケットを切り、テクニカルアカウントマネージャ (TAM) とのやりとりの中で、通常はどの程度のレスポンスタイムなのが今はどうなっているのか、直近でどういった変更を加えたのか、リクエストがアムステルダム経由になっていること、DNS の名前解決がおかしいこと、Trusted Advisor 上でもエラーが発生していることを共有し問題の原因を調査していく中で NS レコードの値がおかしいことに気付きました。
そして、元の正しい NS レコードと当時設定されていた NS レコードの値があまりにも似通っていることや、更に調査すると AWS とは全く関係のない別の事業者が割り当てられていることから、これは何らかの攻撃を受けて NS レコードを改竄されてしまっている可能性に行き着きました。

[~]$ dig NS coincheck.com

; <<>> DiG 9.10.6 <<>> NS coincheck.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49358
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;coincheck.com. IN NS

;; ANSWER SECTION:
coincheck.com. 315 IN NS ns-1985.awsdns-056.co.uk.
coincheck.com. 315 IN NS ns-650.awsdns-017.net.
coincheck.com. 315 IN NS ns-1515.awsdns-061.org.

;; Query time: 150 msec
;; SERVER: *.*.*.*#53(*.*.*.*)
;; WHEN: Mon Jun 01 19:09:02 JST 2020
;; MSG SIZE rcvd: 151

また、この時点で WHOIS を確認したところ 5月31日の0時5分頃にアップデートされていることが確認できましたが、誰もその時間帯に作業を実施した記録もありませんでした。

2. 発覚後の対応

2.1 ドメインレジストラのアカウント乗っ取りの確認

NS レコードが不正な値になっていることを確認してすぐにドメインレジストラである お名前.com の認証情報を持っているメンバーがログインを試みて設定がどうなっているかを確認しようとしましたが、管理していた ID とパスワードの組み合わせでログインすることができず、更にパスワードの再設定を試みましたがこちらも管理していたお名前IDとメールアドレスの組み合わせで不正ですと返ってきたことから、お名前.com 上の「coincheck.com」を管理していたアカウントが完全に乗っ取られていることが判明しました。
こうなってしまってはもう当社ではできることが限られてしまうので、サポート等を通じてお名前.com へコンタクトを取り、NS レコードの修正とアカウントの復旧を依頼しました。

2.2 アカウント乗っ取りの原因の調査と NS レコードの復旧

メールアドレスも書き換えられてしまっている以上、お名前.com の運営側の対応を待つしか NS レコード復旧のためにできることがなかったため、その間に普段からご相談をさせていただいているセキュリティのアドバイザーの方にも対応へのご協力をお願いして、お名前.com のアカウントが乗っ取られてしまった原因の調査にとりかかることにしました。
一番最初に可能性として上がったのは、お名前.com の認証情報にアクセス可能なユーザーが既にマルウェア感染やソーシャルハッキングを受けているということでしたが、ログの洗い出しや本人へのヒアリングを通じても不審な点は一切見つかりませんでした。しかし、保険として該当ユーザーのアカウントを停止する措置を講じました。

この際にお名前.com に脆弱性があるという可能性も考慮されましたが、それなら当社以外にも多数の被害が出ているはずだという結論になり、特にそういった話は聞いてないということでその可能性については低いという整理をしていました。

その調査の間に whois を監視していた人から WHOIS のアップデートが入ったこと、そしてお名前.com 側から NS レコードを修正したとの連絡が入りました。

2.3 緊急事態対策本部設置とMXレコード改竄の発覚

アカウント乗っ取りの原因調査の間に社長の元にも情報が届いており、当初は事態の推移を見守っていましたが NS レコードを正しい値に修正してもまだ影響範囲が未知数なことから緊急事態対策本部の設置宣言が出されました。

その後、原因調査と並行して影響範囲を確認するために攻撃者の用意した権威サーバーを調査していたところ、MXレコードに見覚えのないドメイン名が挿入されていることが確認できました。

[~]$ dig @ns-1515.awsdns-061.org coincheck.com any

; <<>> DiG 9.10.6 <<>> @ns-1515.awsdns-061.org coincheck.com any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23067
;; flags: qr aa rd; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;coincheck.com.			IN	ANY

;; ANSWER SECTION:
coincheck.com.		33000	IN	SOA	ns-1985.awsdns-056.co.uk. ns-1515.awsdns-061.org. 2020050775 864000 72000 1209600 360000
coincheck.com.		360000	IN	NS	ns-1515.awsdns-061.org.
coincheck.com.		360000	IN	NS	ns-1985.awsdns-056.co.uk.
coincheck.com.		360000	IN	NS	ns-650.awsdns-017.net.
coincheck.com.		300	IN	A	54.192.85.80
coincheck.com.		60	IN	MX	5 mail.coincheck.com.
coincheck.com.		300	IN	TXT	"atlassian-domain-verification=tTCWNrSNtNaqGqVPgZWhLMryhgrJD+iSmpgHI61+3D1Qv/zqWlrXgHJRWYymh+KT"
coincheck.com.		300	IN	TXT	"apple-domain-verification=HYRwkB7d1bV30n6U"
coincheck.com.		300	IN	TXT	"facebook-domain-verification=la8geuy2tp70oh91bzf9qv80norcko"
coincheck.com.		300	IN	TXT	"v=spf1 +include:servers.mcsv.net +include:amazonses.com +include:_spf.google.com ~all"
coincheck.com.		300	IN	TXT	"MS=ms23516971"
coincheck.com.		300	IN	TXT	"google-site-verification=9Vdf1PUnTUg7DQpW_amjVI_CLQAzBs4KpH58W1EBgew"

;; ADDITIONAL SECTION:
mail.coincheck.com.	300	IN	A	45.77.24.250

;; Query time: 258 msec
;; SERVER: *.*.*.*#53(*.*.*.*)
;; WHEN: Mon Jun 01 21:59:37 JST 2020
;; MSG SIZE  rcvd: 679

「mail.coincheck.com」は当時は当社では運用していなかったドメイン名であり、IP アドレスも全く見覚えのないVPS事業者のものであったこと、該当の IP アドレス上で 「coincheck.com」 を返すメールサーバーが動いていることを確認したことから、メールについても影響を受けている可能性があることを確認しました。

2.4 その後

その後は引き続き原因や影響範囲の調査、受信しているメールのヘッダの調査、影響を受けたユーザーの洗い出し、関係機関への報告などに取り組んでいました。

後書き

今回は2020年6月に発生した「coincheck.com」のドメイン名ハイジャックのインシデントについて、発覚の経緯とその後のインシデント対応についてご説明しました。

本件に関して、ご迷惑及びご心配をおかけしてしまったユーザーの皆様には謹んでお詫び申し上げます。

この後に、その他の影響範囲の調査やユーザーのサポート業務に使用していたメールアドレスを「coincheck.com」以外のものにする議論、影響を受けた対象ユーザーの洗い出し等の作業がありましたがここでは割愛させていただきます。

この記事を読まれている皆さんが、今回の当社のインシデントを見てドメイン名を乗っ取られた時の影響範囲と被害の大きさについて認識し、ドメインレジストラの設定の確認や DNS のレコードの監視に取り組むきっかけになれば幸いです。