コインチェック 2018年暗号資産NEMの流出

顧客から預かった NEM を、ネットワークにつながるホットウォレットで管理していた。攻撃者は従業員の端末から社内のネットワークに入り、NEM のサーバで通信を傍受して秘密鍵を取り、約8時間で5億2,630万10XEM を外へ送った。暗号資産では、秘密鍵を持つ者が送金できる。鍵がオンラインにあることが、そのまま資産がオンラインにあることだった。

2018年のコインチェックの発表と、関東財務局の2度の業務改善命令に沿って書いています。当時の法令の呼び名は仮想通貨で、現在の法令では暗号資産です。不正プログラムが端末に入った経路、遠隔操作の道具の名前、攻撃者は発表に無い。手当ての時点は、2018年11月26日の全通貨の取引の再開と、2019年1月11日の仮想通貨交換業者の登録までです。法令の条文は2026年11月時点の e-Gov によります。

要点

不正に送られたのは5億2,630万10XEM。2018年1月26日の午前0時2分から8時26分までの間に送られた。保有していた顧客は約26万人。
調査の結果の想定は、従業員の端末にマルウェアを感染させ、その端末を経由して社内のネットワークに入り、遠隔操作の道具で NEM のサーバの通信を傍受して秘密鍵を取り、その鍵で送金した、というもの。
会社は、NEM をホットウォレットで管理していたため不正送金を防げなかったと書いた。
異常の検知は同じ日の11時25分頃で、最後の送金の約3時間後だった。
根本の直しは、顧客の資産を動かす鍵をネットワークにつながる機器に置かないこと。現在の内閣府令は、利用者の暗号資産を移す情報を、原則として常時インターネットにつながない機器などで管理するよう求める。

何が起きたか

図1 1月26日の時刻と、その後の経緯

日時	発表の内容
2018年1月26日 0時2分から8時26分	預かっていた NEM のうち5億2,630万10XEM が、不正アクセスによって外部へ送られた。NEM 以外の仮想通貨と日本円の不正送金は無かった[3]
1月26日 11時25分頃	社内で異常を検知[1]
1月26日 12時7分から18時50分頃	NEM の入金、売買、出金を止め、続いて日本円を含む全通貨の出金、ビットコイン以外の売買、カードなどの入金を止めた[1]
1月26日	関東財務局が資金決済法63条の15第1項に基づく報告を求めた[6]
1月28日	約26万人の保有者へ、1XEM あたり88.549円で日本円により返金する方針。原資は自己資金[2]
1月29日	報告の内容が不十分として、関東財務局が資金決済法63条の16に基づく業務改善命令。事実関係と原因の究明、顧客への対応、システムリスク管理の態勢の強化と責任の明確化、再発防止策を、2月13日までに報告するよう命じた[6]
2月2日	金融庁が立入検査に着手[7]
3月8日	2度目の業務改善命令。扱う仮想通貨のリスクを評価せず、業容の急な拡大に内部管理と内部監査の態勢が追いついていなかったと認定[7]。同じ日に会社が原因と再発防止策を公表[3]
3月12日	NEM の保有者へ日本円で補償。一部の仮想通貨の出金と売却を再開[4][5]
11月26日	扱う全部の仮想通貨の入出金と売買が可能になった[8]
2019年1月11日	仮想通貨交換業者として関東財務局に登録[8]

発表の間で違う数字

1月26日の最初の発表は、事象の発生を2時57分頃とし、1月28日の補償方針は総額を5億2,300万XEM とした[1][2]。3月8日の発表は、調査の結果として、送金の時間を0時2分から8時26分、総額を5億2,630万10XEM に改め、当初の公表から変動があると断っている[3]。以下は3月8日の数字による。

通った道筋

図2 3月8日の発表で想定された道筋。鍵が取られた後の送金は、正規の署名を持つ取引として流れた

3月8日の発表の言葉では、外部の攻撃者が、従業員の端末にマルウェアを感染させ、外部のネットワークから当該従業員の端末経由で社内のネットワークに不正にアクセスし、遠隔操作の道具で NEM のサーバ上で通信を傍受して NEM の秘密鍵を窃取したうえで、その鍵で外部の不審な通信先に NEM を送金したと想定されている。調査は情報セキュリティの5社の外部専門家に依頼し、通信のログの解析、従業員のヒアリング、端末のフォレンジック調査を行った[3]。

ブロックチェーンの上では、正しい秘密鍵で署名された送金は、正規の送金と区別できない。サーバへの侵入が止まらなかった時点で、守りに残っていたのは、鍵がそのサーバに無いことだけだった。

悪い例。架空の送金サービス。署名の鍵が、ネットワークに出られるサーバの中にある

// wallet-service.js  架空の例。名前は本物ではない
const key = loadPrivateKey("/srv/wallet/hot.key");   // 顧客の預かり分すべての鍵
export async function withdraw(req) {
  const tx = buildTx(req.to, req.amount);
  return broadcast(sign(tx, key));                   // 上限も宛先の確認も無い
}

直した例。オンラインの側は依頼を作るだけ。署名は切り離した側で、条件と承認を経て行う

// オンラインの側に鍵は無い。少額の払い出し用の分だけ、別の鍵と別の上限で持つ
export async function withdraw(req) {
  const tx = buildTx(req.to, req.amount);
  await policy.check(tx, { dailyLimit, allowlistForUser, velocity });
  return signingQueue.enqueue(tx);   // 署名は常時接続しない機器で、複数の承認の後
}

どこで止められたか

図3 流出が進む5段と、それぞれで止める仕組み

段	発表と命令で書かれたこと	止める仕組み
1 置く	預かった NEM をホットウォレットで管理していたため、不正送金を防げなかった[3]	利用者の資産を移す情報を、常時インターネットにつながない機器などで管理する。オンラインに置く分は必要最小限で、上限を決める[9]
2 入る	従業員の端末にマルウェアが感染した[3]	業務の端末を入れ替え、端末の認証を強め、社内のネットワークに接続できる端末を限った[3]
3 届く	端末を経由して社内のネットワークに入り、NEM のサーバまで届いた[3]	社内のネットワークを作り直し、入口と出口を多層にし、サーバ間の通信を絞り、重要な情報を暗号化した[3]
4 送る	約8時間にわたって、5億2,630万10XEM が送られた[3]	1回と1日の上限、宛先の確かめ、複数人の承認を、署名の前に置く
5 気付く	検知は送金の終わりの約3時間後だった[1][3]	社内の監視に加えて、外部の専門機関による監視を置いた[3]。ウォレットの残高と出金の量に警告を置く

1 置く。根本の段

2から5は、オンラインにある鍵に攻撃者を近づけない策である。端末、ネットワーク、サーバのどれかが破れれば鍵に届く。鍵がネットワークにつながる機器に無ければ、サーバを丸ごと取られても、取れるのはオンラインに置いた少額の分だけになる。

2026年11月時点の暗号資産交換業者に関する内閣府令27条は、利用者の暗号資産を移すために必要な情報を、常時インターネットに接続していない電子機器や記録媒体などに記録して管理する方法か、それと同等の技術的安全管理措置をとる方法を求める。それ以外の方法で管理してよいのは、利便と円滑な業務に要る最小限で、本邦通貨に換算して利用者の暗号資産の100分の5を超えない分に限られる[9]。

鍵をどこに置き、誰がどう使えるかは、暗号資産に限らない。API の鍵や署名の鍵でも同じで、置き場所と権限の考え方は秘密の鍵の扱いにある。

書面の発表に無いこと

報道では、署名に複数の鍵を要するマルチシグを NEM で使っていなかったことが、原因の1つとして広く伝えられた。会社の書面の発表と関東財務局の命令は、ホットウォレットでの管理には触れているが、マルチシグには触れていない。

4 送る。署名の前の条件

攻撃者が持っていたのは鍵であって、会社の送金の画面ではない。鍵そのものを取られたら、会社の側の上限や承認は効かない。上限と承認が効くのは、鍵がそれを経ないと使えない所にあるときだけである。だから4の網は、1の置き場所と組で成り立つ。上限と回数の決め方は A06 安全性を欠いた設計の回数と量の上限にある。

組織の態勢

2度目の業務改善命令は、取締役会が顧客保護とリスク管理を経営の最重要の課題と位置付けず、業容の拡大を優先したこと、監査役も機能していなかったことを認定した[7]。会社は、業務部門から独立した部門にシステムセキュリティの責任者を置き、システムリスクの委員会と内部監査を強めると発表した[3]。預かる額が急に増えたとき、鍵の管理の仕組みが同じ速さで変わらなかった。

守り方

根本の直し

顧客の資産を動かす鍵を、常時インターネットにつながない機器に置き、署名はそこで行う。オンラインに置く分は最小にし、上限を決める[9]。
オンラインの側の鍵も、用途ごとに分け、1つの鍵で動かせる額を絞る。秘密の鍵の扱い
署名の前に、上限、宛先の確かめ、複数人の承認を置き、鍵がそれを経ずには使えない形にする。

緩和の策

業務の端末を認証し、社内のネットワークに接続できる端末を限る[3]。
端末のネットワークと、鍵や顧客の資産を扱うサーバのネットワークを分け、サーバ間の通信を必要な組だけにする[3]。
ウォレットの残高と出金の量と宛先を常に監視し、閾値を超えたら人に知らせ、自動で止める。A09 セキュリティログとアラートの不備
定期にペネトレーションテストを行い、安全性を確かめる[3]。
業容の拡大に合わせて、リスク管理と内部監査の態勢を見直す[7]。

参照

Coincheckサービスにおける一部機能の停止についてコインチェック、2018年1月26日。Internet Archive の写し
不正に送金された仮想通貨NEMの保有者に対する補償方針についてコインチェック、2018年1月28日。Internet Archive の写し
仮想通貨NEMの不正送金に関するご報告と対応についてコインチェック、2018年3月8日。Internet Archive の写し
不正に送金された仮想通貨NEMの保有者に対する補償についてコインチェック、2018年3月12日。Internet Archive の写し
一部仮想通貨の出金、売却再開のお知らせコインチェック、2018年3月12日。Internet Archive の写し
コインチェック株式会社に対する行政処分について関東財務局、2018年1月29日
コインチェック株式会社に対する行政処分について関東財務局、2018年3月8日
仮想通貨交換業登録に関するお知らせコインチェック、2019年1月11日。親会社マネックスグループの適時開示に添付
暗号資産交換業者に関する内閣府令第27条利用者の暗号資産の管理 e-Gov法令検索

コインチェック 2018年 暗号資産NEMの流出

要点