仮想通貨取引所のセキュリティが非常に話題になっています。
仮想通貨は中央管理者のいないシステムのため、一度盗まれると取り返しがききません。フォークを話し合って決めた後でさえ、ハードフォークの場合、ハッキング自体を受け入れる世界線としてチェーンが進んでいくこともありえます。
お金がWEBの世界に取り込まれ始めた事で、主にWEB系ベンチャーから仮想通貨取引所は生まれています。ただし、私は取引所システムの本質は「金融システム」だと思っています。WEBの知見と、セキュリテイの知見を組み合わせる事が非常に重要だと思います。
なるべくハッキングにあわないよう対策を講じること。過去から学ぶ事が重要です。Goxした情報、ハッキングの手口をまとめておくことで業界の一助になれば、と思いこの記事にまとめていきます。
私一人では調べきれなかった情報もあるので、どんどん教えてもらいたいと思っています。
ハッキング事例の概要
ハッキング事例の概要を以下表にまとめました。 個別の事例については次の章で見ていきます。
| 時期 | 取引所 | 被害額 | 攻撃手法 | ハッキング後の結果 |
|---|---|---|---|---|
| 2011年6月 | Mt.gox | 750,000BTC | トランザクション展性をついた攻撃 | 破産 |
| 2012年9月 | BitFloor | 24,000BTC | サーバーに侵入し、暗号化されていない秘密鍵のバックアップを取得 | 取引所を閉鎖し、残りの資金を全て顧客に払い戻し |
| 2014年3月 | Poloniex | 総預り資産の12.3%のBTC（金額は不明） | 出金コードの脆弱性をついた攻撃 | 全額を顧客資産に保証 |
| 2015年1月 | Bitstamp | 19,000BTC | 不明（知っている人がいたら教えてください） | 1週間後に営業再開。マルチシグウォレットの導入含む、セキュリティ強化 |
| 2016年8月 | Bitfinex | 120,000BTC | マルチシグのうち2つが盗難された | BFXトークンの発行と8ヶ月かけての補償 |
ハッキングの個別事例
Mt.GOXのトランザクション展性を利用した攻撃
時期
- 2011年6月
被害額
- 750,000Bitcoin
攻撃手法
- Bitcoinの当時の仕様であるトランザクション展性をついた攻撃
- その他、不明点もあり
ハッキング後の結果
- 破産
攻撃手法について
Mt.GoxはBitcoinの当時の仕様であるトランザクション展性をついた攻撃を受けて流出しました。
トランザクション展性攻撃の流れは以下の通りです。
Bitcoinのトランザクションのハッシュ値を変更する事で攻撃を行っています。
- トランザクション検証スクリプトの意味を変えないまま、スクリプトを変更することで、トランザクションのハッシュ値（TXID)を変化させる
- 取引所のウォレット実装がTXIDによる送金確認を行なっている場合、変化前のTXIDを追いかけて送金完了していないと誤認させる事ができる
- 送金されていないと誤認させて、二重送金させる
Mt.Goxは度々攻撃を受けています。
今回取り上げるのはこの攻撃だけですが、他にも明らかになっていない攻撃があるなど、不明点があるとも言われています。
- 参考
参考として、Mt.Goxの攻撃について解説したレポートをWIDE テクニカルレポート インデックスより掲載します。
ビットコインにおけるトランザクション、その展性と影響（2014-05-16） http://member.wide.ad.jp/tr/wide-tr-ideon-bitcoin-transaction2014-00.pdf
前述のように、取引データを署名する際には、入力のスクリプトは署名の対象から除外されている。従って、 入力のスクリプトの意味を変えず、その表現を変化させることができれば、トランザクションの意味を変えず、 署名も検証可能なまま、取引データの内容を改ざんすることが可能になる。 このことが問題となるのは、トランザクションが、そのハッシュ値である TXID により識別されるからであ る。トランザクション展性が利用されると、同一の取引でありながら、TXID が変化してしまうことになる。 （中略） トランザクション展性の問題は、遅くとも 2011 年にはビットコインの開発コミュニティの中で知られており、 Mt.Gox にて混乱があったような問題に関しては、現在のリファレンス実装では改修されている。 交換所のソフトウェアは、多くの顧客を相手に大量のトランザクションをさばく必要があるため、Mt.Gox に 限らず、ウォレットに独自の実装を採用している場合が多い。特に Mt.Gox は古くから営業を始めた交換所だっ たため、処理に古いスタイルが残ってしまったと考えられる。
BitFloorのオンラインバックアップ秘密鍵のハッキング
- 時期
- 2012年9月
被害額
- 24,000BTC
ハッキングの原因
- サーバーに侵入し、暗号化されていない秘密鍵のバックアップを取得
ハッキング後の結果
- 閉鎖し、残りの資金を全て顧客に払い戻し
システムのアップグレードを行ったあと、暗号化していないディスク領域にバックアップを置いてしまったようで、サーバーに侵入したハッカーから秘密鍵を盗まれてしまっています。
bitfloorの管理人shtylmanの投稿では、
Yes. It was made when I manually did an upgrade and was put in the unencrypted area on disk.
システムのアップグレードを行ったあと、暗号化していないディスク領域にバックアップを置いてしまったようです。 それに対して
Why was the majority of this not in a cold wallet?
なぜコールドウォレットに入れておかなかったのか、と質問している人もいます。
- 参考
bitfloorの管理人shtylmanの投稿
bitfloorの閉鎖を報道する記事
Poloniexの出金コードの脆弱性攻撃
時期
- 2014年3月
被害額
- 総預り資産の12.3%のBTC（金額は不明）
攻撃手法
- 出金コードの脆弱性をついた攻撃
ハッキング後の結果
- 全額を顧客資産に保証
Poloniexの出金プロセスは以下の通りです。
- 入力した値の検証。（おそらくマイナスなど不正な値でないかなど）
- あなたの残高が十分かどうかを確認するために残高がチェックされる
- 十分であれば残高が差し引かれる
- 出金処理がデータベースに挿入される
- 確認メールが送信される
- ユーザーが出金を承認したら、プログラム側で出金が処理される
この2の処理の時、同じタイミングで複数の出金依頼をかけると、チェックをすり抜けて出金が処理されてしまうと言う脆弱性がありました。 これらの出金処理をキューに入れて直列に処理せずに、並列に処理していた部分があった事が問題と説明しています。
- Input validation.
- Your balance is checked to see if you have enough funds.
- If you do, your balance is deducted.
- The withdrawal is inserted into the database.
- The confirmation email is sent.
- After you confirm the withdrawal, the withdrawal daemon picks it up and processes the withdrawal. The hacker discovered that if you place several withdrawals all in practically the same instant, they will get processed at more or less the same time. This will result in a negative balance, but valid insertions into the database, which then get picked up by the withdrawal daemon.
- 参考
BitcointalkフォーラムのPoloniex管理人の投稿
Bitstampのホットウォレット攻撃
- 時期
- 2015年1月
- 被害額
- 19,000BTC
ハッキングの原因
- 不明。見つけられませんでした。（知っている人がいたら教えてください）
ハッキング後の結果
- 1週間後に営業再開
- マルチシグウォレットの導入含む、セキュリティ強化
コールドウォレットに85％から90％の資産を保管していたため、 全体の預かり資産額からすると大きくはなく、被害が抑えられたようです。
- 参考
bitstampのハッキング報道記事
Bitfinexのマルチシグウォレットのハッキング
時期
- 2016年8月
被害額
- 120,000BTC
攻撃手法
- マルチシグのうち2つが盗難された
- Bitfinexに2つ（管理者、ユーザーにそれぞれ1つ）、BitGoに1つの3つのキーを配布して、そのうち2つで署名する「2 of 3」構成だった
ハッキング後の結果
- BFXトークンを発行して、8ヶ月に渡って顧客に補償した
ユーザーから出金要請を受けると、
「Bitfinexでトランザクションに署名を行う→BitGoに署名依頼を行う」
というオペレーションで業務が回っていたようです。 原因として言われているのは、
- Bitfinex、BitGo共にハッキングを受けた
- BitGoのみがハッキングを受けて、BitGoの提供ウォレットに脆弱性があった
- Bitfinexのみがハッキングを受けて、BitGoのマルチシグ確認がうまく機能していなかった
- Bitfinex、あるいはBitGo共犯の内部犯行
といった事のようです。
- 参考
bitfinexのハッキング報道記事
bitfinexのハッキングについて質問しているスレッド
対策に関わるキーワード
こちらでは、対策となるキーワードを羅列していこうと思います。
- マルチシグ
送金などに複数の署名を必要とするアドレス。シングルよりも、マルチシグの方が堅牢であることは間違いないですが、ホットウォレットで同じ場所に複数の秘密鍵を置いていたら、ハッキングに対してはあまり効果を発揮しません。
複数のサーバーに分散して鍵を置いておく事などでセキュリティを高める事ができると考えられます。ただしbitfinexのように分散化していてもハッキングされた事例があります。
ビットコイナー反省会で言及されていましたが、マルチシグは内部的な犯行に対する統制、またオペレーションミスを防ぐという役割が強いと考えられます。
なお、Ethereum、Rippleなどはマルチシグの実装方法が確立しきっていないため、現段階ではマルチシグを導入しない取引所も多いようです。
- コールドウォレット
オフラインのウォレット。秘密鍵の作成から署名までオフラインで実施する。 6年前のbitfloor事件からもコールドウォレットに入れておけばハッキングされることは無かった、とbitcoinforumで議論されています。
- ホットウォレットの秘密鍵保管
ホットウォレットの秘密鍵をどのように保管するかは悩ましいところです。
もちろん、暗号化の方法などは焦点になると思います。
ただし、ブロックチェーン関係なく、アプリケーション、ネットワークなど、セキュリティ一般の話が密接に絡まってくると思います。
- Crypto Currencies Security Standard
暗号通貨のセキュリティスタンダード規定を自主団体が作成しています。 秘密鍵のシードが堅牢なものであるか、管理者権限を渡すプロセスが規定されているかなど。 こちらも参考になるでしょう。
- システム以外の話
ホットウォレットは、GOX積立金みたいなものを積んで考えておいたほうがいいのかもしれません。
より細かいキーワードについては、こちらに為になる記事が書かれています。
